全社システムを一本化する前に決めたい、そろえるデータと残す業務

本社はシステムを一本化したい。現場は「うちの業務は違う」と反対する。双方がこの言葉のまま議論すると、全社統一か現状維持かの二択になる。しかし、顧客を同じ番号で識別することと、全拠点の見積もり手順を同じにすることは、別の意思決定だ。

共通化したいのは、データの意味なのか、部門間の受け渡しなのか、仕事の手順なのか。この区別を置くと、標準化は製品選定の話から、事業をどうつなぐかという話へ戻る。

本稿の提案は、部門をまたぐ仕事に必要な情報と接続のルールを先にそろえ、業務の違いは残す理由を確かめて判断することだ。顧客データを共有する企業を主な例にするが、共有自体が不要な事業まで統一するという主張ではない。

統合することと、同じやり方にすること

MIT CISRのJeanne W. Rossは2005年の研究ブリーフで、事業運営のモデルを、業務プロセスの統合と標準化に必要な水準から考える枠組みを示している。ここで使うのは公開要旨で確認できる概念であり、特定の製品導入による費用削減率を示す研究結果ではない。MIT CISR「Forget Strategy: Focus IT on Your Operating Model」

この区別を実務へ引き寄せると、同じ顧客に複数部門がサービスを提供する会社では、顧客を識別し、契約や対応履歴を受け渡す仕組みが必要になる。一方、部門ごとに提供物が違えば、営業や承認の手順まで同じとは限らない。

逆の構成も考えられる。顧客を共有しない多数の店舗でも、同じ商品を同じ品質で提供するために、発注や検品の手順をそろえる価値はある。共有するデータの量と、そろえる仕事の範囲は、必ずしも一緒に増減しない。

したがって「全社システムを入れるか」を問う前に、一つの取引を追いたい。どこで情報を受け渡し、その意味が食い違うと誰が困るのか。その関係が説明できれば、先に統一すべき範囲が見えてくる。

製品を統一しても、数字の意味が違えばつながらない

仮に、すべての部門が同じ顧客管理製品を使っているとする。それでも、A部門は契約した会社を顧客と呼び、B部門は実際に利用する支店を顧客と呼ぶ。同じ画面に「顧客数」が表示されても、そのまま足し合わせられない。

この例で先に決めるべきなのは画面の配置ではなく、会社と拠点の関係、重複した登録の扱い、名称変更を反映する責任である。共通の製品はそれを実装する手段になり得るが、定義を決める代わりにはならない。

標準化の対象を整理するなら、次の三層に分けると議論しやすい。これは本稿の整理であり、研究で最適と証明された分類ではない。

例えば、見積もりの作成方法を現場に残しても、受注として引き渡す時点の金額、納期、契約主体の意味はそろえられる。全部を自由にすることと、全部を統一することの間に、実務上の選択肢がある。

「現場ごとに違う」にも、残す理由と解消する理由がある

独自のやり方は、必ずしも非効率の証拠ではない。Ruruaらの2019年の論文は、国際的なハイテク企業の電子請求業務を対象に、国ごとの規制などによる違いを企業の業務・IT構造に表現する方法を検討している。探索的な一社事例で、提案は社内専門家によって評価された。独自性を残した場合の投資収益を比較した研究ではない。Representing Variability in Enterprise Architecture – A Case Study

対象は中南米の国別の税務上の違いを含む業務であり、論文は、顧客要求によるもっと複雑な違いへの適用は明らかでないと述べている。規制対応の事例を、あらゆる現場独自の売り方が合理的だという証拠に広げることはできない。著者所属大学で公開された論文本文・6.2節

この事例は、差異をすべて消すという前提への反例になる。ただし、「現場が違うと言えば残す」根拠にはならない。日本国内だけでも顧客との契約や提供サービスが異なる場合はあるが、その違いがどの処理を必要にするかを個別に示す必要がある。

現場の要望は、操作の好み、歴史的な慣習、事業上必要な差異に分けて聞くとよい。「この欄は残してほしい」に対し、誰が何の判断に使い、なくすとどんな誤りや損失が生じるかを尋ねる。必要な目的が分かれば、元の画面を再現しなくても達成できる場合がある。

逆に本社も「統一すれば管理しやすい」だけでは足りない。共通化によって減る二重入力や照合、保守の作業を具体化し、その代わり現場に増える入力や例外申請と比較する。管理する側の都合だけを便益として数えないことで、残すべき違いを説明しやすくなる。

同じ顧客を扱う二部門で、どこまで統一するか

仮の会社に、定型商品の販売部門と、個別設計のサービス部門があるとする。両部門は同じ顧客を担当し、経営は顧客別の取引状況を把握したい。

この条件なら、まず契約主体と顧客ID、取引状況の定義をそろえる。販売部門の即時見積もりと、サービス部門の技術確認を伴う見積もりは、必要性が説明できる限り残す案が有力になる。即時回答を前提とする手順に全社を合わせると、技術確認が表の工程から消え、別の表計算やメールへ移る可能性があるからだ。

ここで条件を変える。二部門が実際には同じ定型商品を同じ条件で売り、見積もり手順の違いは買収前の慣習だけだったとする。異なる手順が顧客価値や必要な統制を支えていないと確認できれば、見積もりから受注まで共通化する理由が強くなる。データだけをそろえて二系統の保守を続ける案を、当然の結論にはしない。

さらに、二部門が顧客も供給網も共有せず、事業別の集計だけを本社へ渡せばよいなら、顧客IDを全社で統一する利益自体を問い直す。顧客データをそろえる判断が有効なのは、共有する業務上の必要がある場合である。

共通化の投資に、例外を維持する費用も載せる

独自業務を残す判断には、その維持方法まで含めたい。必要な差異であっても、担当者の記憶だけに依存した個別改修にすれば、更新のたびに確認が必要になる。

本稿の提案は、例外ごとに理由、利用部門、責任者、共通部分への影響、見直す契機を記録することだ。単に「特例」と呼ぶのではなく、どの契約条件が変われば不要になるか、どの業務が共通化されれば統合できるかを残す。必要性が続く例外に、形式的な廃止期限だけを設けることは避けたい。

選択肢の比較では、製品の利用料と移行費に加え、接続部分の保守、データ照合、教育、例外対応を入れる。同じ製品に統一しても、多数の個別改修を残せば保守が単純になるとは限らない。複数製品でも、共有する情報と受け渡しが安定していれば、事業上十分な場合がある。

試行の評価も、導入拠点数だけでは足りない。顧客の重複登録を減らしたいなら、照合のやり直しや誤った統合がどう変わったかを見る。受注の受け渡しをそろえたいなら、受け付け拒否や確認の差し戻しを見る。何を統一したかに対応した結果を追う。

標準化の判断は、「本社と現場のどちらに合わせるか」で決める必要はない。仕事をつなぐための共通部分はそろえ、事業上必要な差異は理由と維持責任を付けて残す。理由のなくなった差異は共通化する。 この順番なら、全社共通の製品を買うことと、会社の仕事をつなぐことを取り違えずに投資を選べる。