アジアの大手パッケージメーカーが営業業務を自動化するまで

出発点

一世紀近く取引を続け、現在は400名から500名の従業員と4つの工場を持つパッケージ企業。数十年前に見積と受注のシステムを自社で作り、以来ずっと拡張してきました。事業がその上で回っているという意味では、機能していました。同時にそれは、価格の知識が誰も触りたがらないコードの中にあり、新しい材料や原紙寸法がひとつ増えるたびに開発依頼になり、大きな営業組織が、システムを使うのではなく避けて仕事をすることを覚えてしまった、ということでもありました。

求められたこと

求められていたのは今風の画面ではありません。要件は同等性でした。旧システムにできたことはすべて、少なくとも同じ水準で。そのうえで、旧システムには一度もできなかったこと、つまり仕入先の調達を同じ場所で扱うこと、顧客データを構造化すること、書き出しなしで読める集計を足すこと。

現地の商習慣が、それ自体で高い基準を課していました。書類の形式的な作法と納期の表記が、正確でなければなりません。そこを外した見積は読まれません。そしてこの規模の営業組織では、機能一覧よりも移行のリスクのほうが重く効きます。

原価計算を自動化する

まず価格からでした。既存の原価計算ルールを、版管理された価格ルールとして組み直します。製品と材料ごとに範囲を切り、10種類の手順を組み合わせ、材料コード、坪量、フルート、原紙寸法を複合キーとする原価表の上で動かしました。その地域で標準的な原紙寸法は、裁断係数の計算とともにすでにエンジンに入っており、あとから足す必要はありませんでした。

旧システムとの同等性は、結果を一行ずつ比べられなければ示せません。原価計算を実行するたびに一手順ずつの計算根拠が残るので、新しいシステムが古いシステムと一致するかという問いは、議論ではなく突き合わせになりました。専門家の記憶を必要としていた原価計算が、価格ルールを見られる人なら誰でもたどれる計算になり、その変更はもう開発依頼ではありません。新しい材料、原紙寸法、割増は、価格を所管する人が Pricing Studio で設定します。

同じ計算根拠が、粗利分析を変えました。どの見積も原価要素を持って動くので、粗利はもう四半期末に組み立て直すものではありません。見積が書かれたその瞬間に、見積ごと、顧客ごと、製品ラインごとに見えています。

プロジェクトの実際の進み方

業務を理解する前に設定したものは何ひとつありません。最初の仕事は聞くことでした。原価を計算する人、売る人、帳簿を締める人の隣に座り、問い合わせが届いてから受注が精算されるまでに実際に何が起きているかを、旧システムが要求するからという理由だけで存在していた工程も含めて書き取ります。

その記録から2つの文書ができました。今そのまま動いている業務のフロー図と、各工程の隣に、Packative One が標準で備えているもの、設定が必要なもの、開発が必要なものを並べた機能一覧です。以降はすべて、この2つに対して計画しました。単一の稼働開始日に対してではなく、モジュール単位で。

構築は重なり合う複数の流れで進みました。原価計算は、すでに見積を出したことのある実物の見本で組み上げ、そのうえで過去の実績値に合わせて補正しました。画面と書類の作法は、顧客がどう書かれることを望むかに合わせました。連携の作業は製造側をつなぎ、受注、作業データ、実績値が Packative One と、すでに工場を動かしているシステムのあいだを行き来するようにしました。研修は自社の案件で行い、テストデータではなく実物の受注を使いました。各回のフィードバックは、次のチームが加わる前に設定へ反映しました。

営業を止めずに移行する

一斉切替の日は設けませんでした。機能は営業チームごとに順に開放し、Form Studio によって、各チームがもともとやっていたやり方で仕様を記録できるようにしました。最小公倍数を押しつけることはしていません。旧システムはその間ずっと使えるままで、営業組織の残りは売り続けました。