アドオンはさらなるアドオンを招く

一度嘘をつくと、その嘘を守るためにさらに嘘を重ねなければならなくなります。

ERP導入プロジェクトでも、これに似たことが起きます。一度アドオンを認めると、そのアドオンを成立させるために、さらに別のアドオンが必要になるのです。

最初のきっかけは、たいてい小さな要求です。

「この項目を追加したい」
「手間を減らしたい」
「現行の帳票と同じ形で出したい」
「このケースだけ、今まで通りの処理にしたい」

一つひとつを見ると、それほど大きな話には見えません。むしろ、現場に寄り添った親切な対応に見えることもあります。

しかし、ERPではこの「少しだけ」が厄介です。

例えば、項目を一つ追加する場合を考えます。最初は「この項目を持ちたい」という小さな要求に見えます。しかし、その項目を追加すると、まず入力画面や参照画面に表示する必要が出てきます。画面に表示するなら、誰が入力し、誰が参照するのかを決めなければなりません。

さらに、その項目を他システムにも渡す必要があるとなれば、データ連携の改修が必要になります。帳票に出したいとなれば、帳票の改修が必要になります。検索条件に使いたいとなれば、検索画面の改修が必要になります。分析に使いたいとなれば、BIやレポート側にも項目を追加する必要があります。

最初は「項目を一つ足すだけ」だったはずです。

ところが実際には、その項目を使えるようにするために、画面、帳票、連携、検索、分析、権限、移行、テストまで影響が広がっていきます。

これが、アドオンがさらなるアドオンを招く構造です。

アドオン要求で大切なのは、その背景を確かめることです。

例えば、「手間を減らしたい」という要求が出た場合、その手間がどの頻度で発生し、1回あたりどれほどの時間を要し、誰の業務にどの程度影響しているのかを確認する必要があります。そこを見ないまま「現場が困っているなら作りましょう」と判断すると、アドオンは簡単に増えていきます。

「現行どおりにしたい」という要求にも注意が必要です。現行業務には長年の工夫があります。一方で、過去のシステム制約や例外対応が、そのまま業務として残っていることもあります。それを新しいERPに持ち込むと、ERP導入は業務改革ではなく、古い業務の引っ越しになります。

もちろん、法令対応、取引先との制約、業界固有の要求など、標準機能だけで対応しきれないものもあります。そのようなアドオンは、必要な投資として検討すべきです。

「すぐに追加できるから作る」
「現場が欲しいと言っているから作る」
「今までそうだったから作る」

このような判断を重ねると、最初は標準機能を活かしたシンプルな運用を目指していたはずなのに、気づいたときには、例外処理と個別ルールだらけのシステムになってしまいます。

アドオンを検討するときに問うべきことは、作れるかどうかよりも、そのアドオンが業務目的に本当に必要かどうかです。

その要求は、どれほどの頻度と影響を持っているのか。
標準機能や運用変更で吸収できる余地はないのか。
そのアドオンは、未来の運用に価値をもたらすのか。
それとも、過去のやり方を守るためのものなのか。

SaaS ERPをFit to Standardで導入する上で重要なのは、アドオンを我慢することではなく、本当に必要なものを見極めることです。

最初の判断が曖昧なままアドオンを認めると、その判断を守るために、次の説明や追加対応が必要になります。だからこそ、最初の一つにこそ、最も厳しく向き合うべきなのです。