自社倉庫移転に伴うスケジュールの管理。
倉庫オペレーションの設計からWMSシステム連携の設計。
同タイミングで仕入先が運用する受発注システムの設計と構築、新コンセプトECの構築とローンチ。
物流拠点の新設、仕入れにおける受発注システム、新ECのローンチ、既存のECシステムへの整合性管理。
これらは仕入れから販売、そして出荷というユーザーに商品が届くまでのすべてのフローを通過しています。
あまりにも大きい複雑な要件が絡んだプロジェクトであり、遅れが許されない状況の中でのプロジェクトでした。
目指すべき理想があり、現在地からどう進んでいけばいいのかを考えます。
しかし、目指すべき理想をそのまま反映すると工数が際限なく膨れ上がっていきます。
時間とお金かければ達成することは難しくないですが、限られたリソースの中で成功へと導かなければいけません。
選択と集中を行うため一度すべてステークホルダーの業務整理からスタートしました。
膨大な業務整理が完了すると、目指すべき理想から逆算して、業務を簡略化できる点はないか、業務フローにおいてイレギュラーが起きる箇所はどこなのか、イレギュラーが起きた場合どのようにリカバリーするといいのかなど、すべての業務フローを誰がいつ何をやればいいのか？どのような考慮をしておく必要があるのか？を再度フロー図に落とし込んでいきました。
目指すべき全体像が掴めたところで、大まかに分けられた多くの業務フロー単位ごとに、懸念点を更に探りました。
新ECシステムにおける制約、WMSを用いた入荷〜検品〜出荷のフローが円滑に行えるのか、といった点を実際にテストするなど、多くの懸念点を探った上で検証できることは先に検証し、リスクを潰していくことでプロジェクトが遅延して崩壊するリスクヘッジを行っていきました。
今回の同時並行のプロジェクトにおいて、最も大きな問題点は様々なシステムや業務フローに影響する範囲の大きさでした。
リスクの洗い出しに時間がかかり、またリスクを低減するために小さく検証することも時間がかかることでした。
すべてが選択と集中であり、何をやらないかを決める必要がありました。
すべてのプロジェクトを100%完璧に仕上げられるほどの時間が無かったため、今回のプロジェクトでは受発注システムにおける管理側の画面は作らず、すべてCSVから更新するだけで管理者側のオペレーションを実行できるようにするなど、工数を圧縮できる点は圧縮することで開発期限を短くしました。