業務パッケージにどこまで合わせる？ 標準機能と個別対応の比較

新しい業務パッケージの導入会議で、「標準機能に合わせれば安く、早く導入できる」と説明された。現場は「この帳票がないと困る」と答える。開発側には古い習慣への固執に見え、現場には仕事を知らない押し付けに見える。どちらかの姿勢を直せば解決するとは限らない。

帳票の見た目を残したいだけなのか、その帳票が特定の契約や出荷条件を確認する唯一の手段なのか。同じ「現行どおり」という要求でも、失うものが違う。逆に、必要な確認が標準機能でできるなら、画面の配置まで同じにする費用は避けられるかもしれない。

本稿は、違いを機能名ではなく、守るべき業務結果へ翻訳する。標準で結果を満たせる部分は業務を合わせ、満たせない重要な差だけを、維持費を含めて拡張すると提案する。「標準か個別開発か」の二択へ入る前に、差を失う費用を明らかにしたい。

「標準でできる」の中にも設計がある

Brehm、Heinzl、Markusの2001年の会議論文は、ERPの調整を、設定かプログラム改変かという単純な二分で扱う限界を指摘した。文献・現場調査・関係者への聞き取りを踏まえ、調整方法の違いと保守・更新への含意を整理している。現代のクラウド製品の成功率を測った比較実験ではない。Tailoring ERP Systems: A Spectrum of Choices and their Implications・著者掲載原稿

この考え方を現在の導入へ使うなら、まず何を変えるのかを区別する。提供済みの設定を変える、外側に連携を作る、帳票を追加する、製品の深い部分を書き換える。いずれも要望への対応だが、更新時の確認範囲や引継ぎの難しさは同じとは限らない。

「標準だから保守不要」という理解も危うい。設定した権限や計算条件が自社の仕事に合うかは、利用側が確認しなければならない。製品の修正を提供者が担っても、その変更で自社の締め処理が正しく動くかという問いは残る。

現行の形ではなく、残す理由を聞く

MicrosoftのDynamics 365導入指針は、標準機能に沿って業務を検討した後、必要な差を分析する進め方を説明する。一方、事業価値や競争上の強みを持つ独自プロセスでは拡張を検討する余地も認める。自社製品の導入指針であり、標準化の経済効果を独立に実証した研究ではない。Microsoft Learn「Fit-to-standard and fit-gap analysis」

現場への問いは、「この機能は必要ですか」より「ないと、誰が何を判断できなくなりますか」がよい。必要と答えた人へ説明責任をすべて返すのではなく、実際の取引を一緒に追う。

例えば色分けした一覧が必要だと言われたら、その色で区別する条件を確かめる。単なる好みなら表示変更を見送れるかもしれない。しかし出荷を止める対象を識別する手掛かりなら、その判断を標準機能の別の表示や制御へ移す必要がある。

必要な差と、なくせる差を同じ要望一覧にしない

検討表には、要望の名称に加えて次を記録する。本稿の編集上の整理であり、欄を埋めれば導入が成功するという実証ではない。

外部の制約を理由にする場合は、根拠となる契約や要件を確かめる。「規則だから」とだけ書かれた要望は、そのまま個別開発の承認理由にしない。反対に、製品が対応していないという理由だけで守るべき制約を外してよいわけでもない。

同じ帳票の追加でも、採否が逆転する

仮に、社内会議で使う受注一覧の列順を現行と同じにしたいという要望を考える。必要なデータは標準画面から確認でき、会議の進め方を変えても判断の精度が落ちないなら、個別帳票を作らず業務を合わせる案を選べる。

次に、取引先ごとに異なる納入条件をまとめ、出荷前の判断に使っている帳票を考える。標準では条件を識別できず、担当者が毎回別ファイルを見なければ誤出荷を防げないなら、同じ「帳票一枚」でも意味が変わる。条件を保持する設定、表示、連携などの代替案を先に検証したい。

さらに、その特殊な契約が近く終了するなら、長く残る個別機能を作るより、期限付きの補助手順でつなぐ方が合理的な場合がある。ただし手作業の対象を識別でき、確認者と終了日が決まっていることが条件になる。仮想例であり、特定の製品や契約への推奨ではない。

手作業へ逃がした部分も、導入費に含める

個別開発を減らしても、毎日データを抜き出し、表計算で加工し、別システムへ戻すなら、その作業は残っている。誰が担うか、誤った際にどう検出するか、担当者不在でも続くかを費用へ含める。

手作業が必ず悪いわけではない。頻度が低く、影響を限定でき、終了時期が分かる処理には、軽い運用で対応する理由がある。一方、件数が増えるほど担当者の時間を使い、入力誤りが重要な取引へ混ざるなら、安い回避策とは言いにくくなる。

導入会議では、標準採用、外部拡張、暫定手作業の三案を同じ期間で比べる。開発費だけでなく、通常の処理費、例外処理費、更新時の確認費を並べる。試算に不確実性がある部分は、値を一つに固定せず、どの条件で案が入れ替わるかを示す。

例えば、残り一年で終了する契約に必要な帳票なら、改修費を一年で回収する案と、一年間の手作業を比較する。継続契約へ使うなら、複数年の処理と製品更新の確認まで含める。同じ帳票でも、必要な期間をそろえなければ「安い案」は逆転する。これは比較のための仮想例である。

拡張が必要だと分かっても、選んだ製品を前提に作り続けるとは限らない。事業に不可欠な差が多数残り、別製品なら自然に満たせるなら、製品選定へ戻る案も比較する。逆に、近い将来の標準機能で補えるという説明だけで待つ場合は、その機能が必要な時期と確実性を確認する。まだ提供されていない機能を、今使える機能と同じ欄で評価しない。

期間を三年にそろえた仮定で、三案を比べてみます。設定50万円＋年20万円なら110万円、拡張200万円＋年50万円なら350万円、手作業0円＋年100万円なら300万円です。必要な業務結果を満たす案について、更新時の再試験、誤りと代行、業務変更の費用もそろえます。過去のERP分類は変更の種類を考える材料で、現行製品の保守費予測ではありません。

三年の費用差が逆転する条件

この仮定では、標準設定で必要な結果を満たせるなら、三年110万円が比較の基準になる。標準では残せない重要な差について拡張と手作業を比べると、三年では手作業が50万円安い。年額が変わらず同じ仕事を続けるなら、拡張の初期200万円を、年50万円の費用差で割った四年が分岐点だ。四年では両案400万円、四年を超えると拡張の方が小さくなる。必要な業務結果が同じであること、契約や製品をその期間使い続けられることが、この計算の前提になる。

三年のままでも、まだ見積もっていない費用で順位は変わる。以下は既存の年額に含めていない費用だけを追加する感度例であり、実際の価格や損失を調べた結果ではない。

表は左右にスクロールできます。

両案に追加費用がある場合、手作業側の追加額が拡張側を50万円上回ると同額になり、それを超えると費用の順位が逆転する。照合や再試験が既に年額に含まれるなら、二重に足さない。誤出荷を許容できない取引など、業務の必須条件を満たさない案は、安さで採用しない。

差を残す費用を計算する前提は、候補製品で何ができ、何が残るかが分かっていることだ。まだ確認できていなければ、同じ業務を候補製品で試す比較へ戻る。試用で残った差について、ここで必要な期間と追加費用をそろえる。

標準化の成果は、稼働後の例外で分かる

稼働前の試験では、よくある取引だけでなく、返品、取消し、締め後の修正など、判断が変わる場面を選ぶ。製品の画面が一通り動くことと、自社の取引が最後まで成立することを混同しない。

稼働後に増えた補助ファイルや確認メールは、要望を削った成果の裏側を示す。必要な例外が標準へ吸収されたのか、見えない場所へ移ったのかを確かめる。新たな手作業が常態化するなら、標準に合わせるという判断そのものを更新する材料になる。

標準で必要な結果を満たせるなら、業務を合わせる。満たせない重要な差は、更新まで含めた費用で残し方を選ぶ。 パッケージへの適合を目標にするのではなく、必要な仕事を維持できる構成を選ぶために、標準を使いたい。