終わるプロジェクトではなく、変わり続ける製品

いいえ。おすすめもしません。ひとつのモジュールがひとつのチームで稼働し、その間ほかはそのままです。次のモジュールは、最初のものが役に立つと分かってから始まります。守るべき切替日はありません。

意図して、両方です。最初の価格設定は、そちらの見積担当者と一緒に組みます。ルールが正しくなり、どう組み上がったかを担当者が見られるからです。そのあとはコード不要のエディタになり、たいていの変更に当社は要りません。独自のルールと連携は、引き続き当社の仕事です。

たいていは逆で、それは意図してのことです。必要とされているものがパッケージ業界一般にとって筋の通るものであれば、製品に入ります。そうすれば、特殊事例として生き延びるのではなく、他と同じように保守され、試験され、更新されます。自社の原価モデルや、そちらだけが使っているシステムとの接続のような、本当に固有のルールは、お客様のものとして分けて保持します。そうすることで、それが今後のアップグレードを妨げることもありません。

今のやり方より本当に楽な場合だけです。そしてそれは担当者の問題ではなく、当社の問題です。今見積もっている人たちから始め、その人たちのために作るのではなく、一緒にモデルを組み、手が止まる画面を直します。チームがついてこない場合、正直な読み方はたいてい、画面がまだ多くを要求しすぎているというものです。

早い段階でそうお伝えします。ほとんどのプロジェクトが飛ばすのがこの部分です。やっていることが業界の常識ではなく本当に特殊である場合、選択肢をお示しします。業務を変えるか、そのまま残して、保守費用の伴う個別開発になることを受け入れるか。大きなERPの失敗は、たいてい誰も口に出したがらなかったずれから始まり、更新できなくなるところまで改造されたシステムで終わります。

そうお伝えし、そこまで一緒に進みます。たいていは、ひとりの頭の中にしかない価格ルールを書き出すことか、顧客と製品のデータが実際にどうなっているかを、どこかへ移す前に確かめることです。この作業は、当社から何かを買うかどうかに関わらず価値があります。

価格を所管して決められる人がひとり、実際の案件をいくつか見られること、そしてデータが本当はどこにあるかを知っている人。従来型の一斉導入が求めるものより、かなり少なくて済みます。会社全体を事前に文書化しようとしないからです。