WMSのデモについて、不都合な真実から始めよう。それらは劇だ。入念にリハーサルされ、台本どおり、振り付けされた劇だ。そして多くの購買担当者は劇場を出て契約に署名し、その後1年間、プロジェクターの画面ではあんなに簡単そうに見えたソフトウェアが自社の倉庫ではなぜ崩壊するのか、と悩み続ける。
私は2019年、ロサンゼルス郊外のホーム用品ディストリビューターでその様子を目撃した。デモは完璧だった——バーコードをスキャンすれば波動リリースは一瞬で、ピッキング経路は教科書の図のように最適化されていた。オーナーはその場で契約した。9か月後、本番稼働の週、倉庫は6,000件のバックオーダーを抱え、オーナーはドックの向こうから私に怒鳴った。「デモではうまく動いたじゃないか！」
もちろん動いた。それが目的なのだから。
注意すべきデモの3つの手口
1つ目、清浄化されたデータ。デモのデータベースには、せいぜい500の完璧なSKUしか入っていない——すべての品物にバーコード、すべてのロットはクリーン、すべてのスロットは割り当て済み。自社の倉庫には20,000のSKUがあり、バーコードの欠けたもの、つぶれたカートン、1パレットに3ロットが混ざったものも含まれている。ソフトウェアが速く見えるのは、汚いデータに出会ったことがないからだ。
2つ目、ハッピーパス。営業デモは必ず黄金ルートをたどる。入荷、格納、ピッキング、梱包、出荷。返品処理について聞けば「設定できます」と返ってくる。シリアル番号のトレーサビリティについて聞けば「対応しています」と返ってくる。この2つの言葉——「設定できます」「対応しています」——は、実装段階でカスタム開発の2枚目の請求書に化けるのが常だ。実際の返品フローを、その場でライブで回してみるよう求めてみよう。ほとんどのベンダーはやらない。
3つ目、間違った操作者。デモを行うのは、たいてい目隠しでもシステムを操れるプリセールスエンジニアかシニア導入コンサルタントだ。実際にプロジェクトを導入するチームは別人——研修から3か月のコンサルタントかもしれない。デモの滑らかさと、導入の良し悪しはほぼ無関係だ。
台本をベンダーから取り上げろ
本物のPoCの原則は1つだけ。買い手がシナリオを書くことだ。
ベンダーが何かに触れる前に、自分で書く。シナリオは10個程度に絞り、すべて過去3か月に自社倉庫が実際に処理した受注から拾う。私のおすすめは、標準入荷・格納、破損ありフルパレット入荷、緊急注文の波動挿入、ショートピックの再割り当て、シリアル品の返品、破損パレットからの補充、循環棚卸の差異調整、ラベル再貼付。実データも添える——「汚いもの」を含む実際のSKUを最低2,000、さらに実在の1週間分の受注ボリュームも。
次にルールを決める。ベンダーのプリロードデータは禁止、自社データをその場でインポートすること。操作者は自社の倉庫スーパーバイザー、ベンダーのコンサルタントがマウスを握るのは不可。各シナリオはタイム計測する。
この「手伝いなし」ルールが最も重要だ。私は、ベンダーのコンサルタントが操作者の背後に立ってすべてのクリックを実況し、ほぼマウスを動かしてやっているPoCを見たことがある。それはコンサルタントをテストしているのであって、ソフトウェアをテストしているのではない。一番テクノロジーに弱いスーパーバイザーを椅子に座らせよう。その場で習得できれば、そのシステムは使える。
合格ラインを定量化するか、やらないか
PoCが終わったら、会議室に「どうでしたか？」と絶対に聞いてはならない。感覚は、史上最悪の受け入れ基準だ。
PoCシナリオの1ページ目に合格基準を書き、ベンダーに署名させろ。例えば、ベンダーの支援なしに8シナリオ中7つ以上をエンドツーエンドで完了すること。500件の波動リリースを2分以内に完了すること。循環棚卸の調整は5クリック以内。スーパーバイザーが2時間、エラーなしで単独操作すること。
ラインに届かなければ選択肢は2つ。ベンダーはカスタム開発が必要だと認め、スコープと価格を文書化するか、さもなければ落選だ。恐れるべきフレーズは「検討します」——「今日は動きません」という意味だ。
特に指摘すべき落とし穴が1つある。ガイド付きツアーだ。一部のベンダーは、あなたのシナリオを代わりに回して——ベンダーのコンサルタントが操作し、あなたの人は見学——それをPoCと呼ぶ。それは自社のロゴをかぶせたデモであって、概念実証ではない。あなたのチームよりベンダーの手がキーボードにある時間が長ければ、セッションを止めてルールをリセットしろ。買い手がソフトウェアに一度も触らないPoCが証明するのは、ベンダーが自社製品を操作できるという、最初から疑いのなかった事実だけだ。
もう1つの手は、ITリーダーをPoCに連れて行き、連携層を評価させることだ。WMSはERP、TMS、ECプラットフォームと会話する。APIドキュメントが本物か、サンドボックス環境があるかは、半日あれば分かる。APIのレート制限も聞いておけ。1時間に数百コールに絞られるシステムは、受注ボリュームが急増した瞬間に詰まる。インターフェースが腐っているシステムは、導入を泥沼に引きずり込む。
契約前の3つの質問
PoCに合格した。契約の前に、この3つの回答を契約別紙として文書で取り付けろ。
1つ目。PoCで合格したシナリオのうち、本番稼働で動かなかった場合、カスタム開発の費用は誰が払うのか？多くの契約は導入費用を「見積もり」として提示し、超過分は別請求する。合格シナリオのリストを受け入れ基準として添付しろ。動かなければ、それはベンダーの問題だ。
2つ目。導入チームのメンバーは具体的に誰か？リードコンサルタントの名前を契約に明記し、交代には承認が必要という条項を入れろ。「最高のチーム」という口約束に価値はない。
3つ目。本番稼働後90日間の応答時間。何かは必ず壊れる——問題は、どれだけ速く駆けつけるかだ。書面にしろ。重大障害は4時間以内のリモート対応、24時間以内のオンサイト。
あのホーム用品の顧客は？システムを乗り換えた。2回目の選定では、私は彼らに実データと200件以上の実受注で3週間のPoCをやらせた。新システムの本番稼働日、倉庫は2時間の残業で締めた。オーナーは後に、最初からそうすればよかったと私に言った。
PoCは、署名前にベンダーに本物の仕事をさせられる唯一の機会だ。無駄にするな。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
