急速に変化する市場において、物流システムが顧客のニーズを満たすには！？ | オープンソースの倉庫管理システム(WMS)【インターストック】

`急速に変化する``市場において、物流システムが顧客のニーズを満たすには！？`

画像素材：Graphs / PIXTA

＜目次＞

１．BtoBのEC取引が進む中、物流に求められる機能とは？

２．ウォーターホールを基礎とし、アジャイルで変化させる

３．従来の仕事の仕方がそのままシステムに置き換わる危険性

４．おわりに

１．BtoBのEC取引が進む中、物流に求められる機能とは？

BtoCに続いて、BtoBも今後EC取引が急速に進んでいきます。BtoB取引のEC化は物流にどのような変化を求めるのでしょうか。

筆者は”出荷手配業務”の自動化の仕組みが重要性を高めていくと考えています。BtoCでは従来の店舗販売をベースにしたシステムからEC販売の業務フローに合わせた在庫管理システム、物流システムの刷新が進んでいます。

BtoBにおいては、従来は電話やFAXで受注を受け付けてその後に納期回答という属人的作業をベースにしたシステムから、EC取引による業務フローに合わせた在庫管理システム、物流システムが必要になってきます。

出荷手配業務の自動化は、そうしたシステムを設計する上で、中枢を担う重要な機能になります。しかし、従来のアナログ業務を単純にシステムに置き換えるだけでは、その効果性を発揮できません。

そこに求められるのは“顧客中心主義”、”コラボレーション”、”変化に対してオープン”なシステムです。このような設計思想で開発されたシステムは、ITでありながら、人を中心とした組織モデルを推進し、顧客や取引先との信頼と尊敬にもとづく価値観を共有することで、これまで組織の階層や機械的制限の多いプロセスに苦しんできた組織に新たな道筋を提供するはずです。

このようなシステムを構築するには、これまでのように机上や紙の上で全てを設計するやり方では実現が難しいでしょう。
不確実性が増す今の物流に柔軟に対応していくには、組織や顧客で実際に起こっていることに対してうまく適応していくことが重要になるからです。

最近ではソフトウェアやプロダクトの開発に「アジャイル」な開発手法を用いることが一般的になってきました。
しかし、物流システムのような業務オペレーションを支援するシステムにおいて、全てをアジャイルで構築するには、コストと時間に無駄が生じます。その理由については、過去の記事で詳しく解説しているので、そちらをご参考下さい。

⇒中堅企業が物流システムで競争力を向上するための導入方式とは！？

２．ウォーターホールを基礎とし、アジャイルで変化させる

BtoB取引のEC化に伴う市場の急激な変化に対応し、バリューチェーン全体を最適化していくために出荷手配の自動化と最適化が重要な機能になっていきます。オーダーに対して、どの在庫を引き当て、どこの拠点からどの配送キャリアを利用するといった現場への最適な指示を作成する仕組みです。しかし、この領域はこれまで長い間経験と勘に頼った属人的な作業であるため、最適解を見出すことが難しいです。

予めベースとなる機能については、ウォーターホール型で設計、構築し、最適解を導き出すフェースにおいては、アジャイルでどんどん変えていく方法が、筆者が最近考える最も効果的な手法です。

アジャイルのフェーズにおいては、プロセスやツールよりも顧客との対話を重視し、包括的なドキュメントよりも動くソフトウェアを作成し、契約交渉よりも顧客との協調を大切にし、計画に従うことよりも変化への対応を価値とします。

アジャイルというと、開発手法の一つとして見られがちですが、単なる手法ではなく、「マインドセット」の役割も期待出来ます。プロジェクトマネジメント、エンジニア、ユーザーがアジャイル的な思考に大きく転換することによって、チーム内の各自が、共通の目標と価値観に向かって協力することができるようになると考えます。

以下の図は弊社が現在進めている「セミスクラッチ型」による物流システムの構築法を簡単に俯瞰した図です。

bcnfpoflcdmcchmg

物流システムのベースとなる機能については、基本的にどの現場においても共通ですので、WMSパッケージを基礎として利用します。
そこから、現在の業務や予めやることが決まっていることを要件定義し、設計に落とし込み、カスタマイズが必要であればカスタマイズを実施します。ここまでは、ウォーターホール型で設計に沿って進めていきます。

顧客とのシミュレーションのフェーズでは、機能検証やシステムの効果性の検証を行います。このフェーズになるとアジャイル型に切り替えます。機能や効果性に問題点や改善点が見つかればプログラムを改良し、必要な機能をどんどん組み込みます。

３．従来の仕事の仕方がそのままシステムに置き換わる危険性

物流システムを刷新するアイディアが企業で持ち上がった時、誰しもが従来の仕事の仕方を大きく変えて、イノベーションを起こすことを期待します。しかし、プロジェクトが進むにつれて、組織の構造、予算、計画といった様々なしがらみによって結局大きな変化もなく、従来の仕事がそのままシステムに置き換わるといったことで終始してしまうケースが殆どです。

なぜこのようなことが起こってしまうのでしょうか。それは、私たちが習慣の奴隷となってしまっているからです。今私たちが働いている会社は、私たちが何年も従来の仕事の仕方を続けて築きあげてきた習慣が形になって残ったものです。

ウォーターホール型を採用してシステムを導入するということは、当初の計画通りにシステムを仕上げることを意味します。
つまり、その計画は習慣の奴隷となった人たちによって作成されます。

一方アジャイル方式では、計画通りに進まない不確実なイベントを機能として実装し、それを繰り返すことで最適解を仕組み化し、従来の習慣から抜け出すことを目指すものです。

例として、実店舗のある小売店がECを販売チャネルに追加し、オムニチャネルに対応した物流システム構築をしているとします。
従来のウォーターホール型なら、長文の要件定義書を作成し、物流システムに必要な機能、それらの機能がどう動くかといったことが詳細に設計書に落とし込まれます。

その後、仕様書をプログラマーに渡し、プログラム実装が完了するとテスト担当者によって完璧にテストされ、当初の設計通りにシステムが完成することでしょう。しかし、これまでオムニチャネル物流の経験がない人たちによって作られた要件をベースにしたシステムは、実際に動かすと多くの不都合を生み出します。しかし、バグではなく仕様上の不都合を修正する場合は、仕様変更となるため、
ベンダー側も前向きに取り組んではくれません。以下図によく顧客とベンダーのやり取りをご紹介します。

mlbgibcldgnkniaf

果たして、こうしたケースをオムニチャネル未経験の顧客が、全て当初の計画に盛り込むことは現実的でしょうか？

では、同じシステムをウォーターホール型とアジャイル型を組み合わせた「セミスクラッチ型」で構築する例を見てみましょう。
基本的な機能はパッケージを利用し、カスタマイズが必要だと予め分かる範囲については、ウォーターホール型で進めます。
現場にシステムを導入し、動かす中で発生する現場や顧客ニーズに対して、小さなリリースに優先順位をつけて、1週間から2週間のタイムボックスの中で順次リリースしていきます。そして頻繁にフィードバックを集めながら必要に応じて軌道修正を行い、機能横断的にリリースとフィードバックを繰り返していきます。

もしかしたら、それはあなたが当初計画したとおりの物流システムではないかもしれません。

cekililmlnlmpfbo