PMIで「処理済み」を取り違えない。業務の状態をすり合わせる

「処理済み」の意味を、会社の境界で確かめる

買収後に受発注の情報をつなぐとき、同じ言葉が使われていると安心しやすいものです。「受注済み」「確定」「出荷済み」「完了」。ところが、一方の会社では担当者が入力した時点を「確定」と呼び、もう一方では在庫と納期を確認して顧客へ回答した時点を指しているかもしれません。列の名前を合わせるだけでは、仕事の状態まで一致しません。

この記事で扱うのは、PMIにおける業務状態の意味のすり合わせです。システムの選定や大規模なデータ移行の手順ではなく、両社が使う状態名について、何が終わり、何が残り、誰が次に動くのかを確認する方法を整理します。経営者、統合責任者、営業・物流・管理部門の担当者が、一つの具体例から話せることを目指します。

中小企業庁は、PMIを主にM&A成立後に行われる統合に向けた作業として紹介し、目的や現状から優先課題を整理する分析ワークシート、具体的な取組を管理するアクションプラン、関係者への説明に使う統合方針書を公開しています。本記事の確認日は2026年11月10日です。以下の状態対応表や試行方法は、その考え方を業務の接続に応用した編集部の提案であり、公式に定められた必須様式ではありません。[1]

特に注意したいのは、言葉の違いが担当者の能力の差とは限らないことです。取引条件、顧客との約束、製品、納品方法、日々の役割が違えば、必要な区切りも変わります。買い手の呼び方を正解として置き換える前に、現在の言葉が何を守っているのかを聞きます。現場への聞き取りを、既存の運用を否定する場にしないことが出発点です。

対象は、まず一つの仕事と一つの引継ぎ点に絞ります。例えば、営業から倉庫へ出荷を依頼する場面です。あらゆる部門の用語集を先に作ると、重要な違いが辞書の中へ埋もれます。変更によって顧客への回答や現物の動きが変わる部分から確認し、他の業務へ広げるかは結果を見て決めます。

個別の契約上の義務、売上計上、税務上の扱いは、状態名だけでは判断できません。本記事は法律・税務・会計上の結論を示すものではなく、現場の説明と専門家の判断をつなぐ準備です。分類を変えたことで権利義務や計上時点まで自動的に変わると考えないようにしてください。

名称ではなく、状態に入る条件と出る条件を読む

最初の聞き取りでは、画面に表示された名前を集めるだけで終えません。その状態に入る直前に、何が確認されているのかを聞きます。注文の内容が揃ったこと、担当者が入力したこと、承認を受けたこと、相手へ回答したことは別の出来事です。一つの状態に複数の出来事をまとめている場合は、内側の順序も確認します。

次に、その状態になった後に、誰が何をしてよいのかを確かめます。倉庫が商品を取り出してよい、運送を手配してよい、顧客へ予定を伝えてよい。画面の表示は同じでも、許される行動が違えば、連携先へ渡す意味は異なります。状態名の説明には、後工程の担当者の理解も加えます。入力する人だけの説明で対応表を完成させないことが大切です。

状態から抜ける条件も必要です。「保留」は便利な表示ですが、誰の回答を待つのか、何が揃えば解除できるのかが分からなければ、待ち続けることになります。解除する権限者、必要な証拠、再確認の時期を分けて記録します。すべての保留へ同じ期限を付けるのではなく、顧客との約束や業務の影響に応じて判断します。

編集部は、対応表の一行に「元の状態名」「入る条件」「この時点で確定していないこと」「次に動く担当」「動いてよい内容」「例外」を置くことを提案します。両社の表を横に並べ、同じものを探すより、どこまでなら同じ意味で受け取れるかを考えます。対応できない状態が残ることも、調査としては有用な結果です。

例えば、売り手の「出荷済み」が倉庫で梱包を終えた時点なら、買い手の「運送会社へ引渡し済み」とは違います。前者を後者へそのまま変換すると、顧客へ伝える配送状況が事実とずれる可能性があります。このときは、一方の呼称を即座に廃止するより、連携する情報に実際の引渡し時点が含まれるかを確かめます。

時刻の意味も揃えます。担当者が状態を更新した時刻と、現場で出来事が起きた時刻は同じとは限りません。後からまとめて入力する運用があるなら、その遅れを把握したうえで情報を使います。日時の書式だけを統一しても、記録された出来事が異なれば比較できません。集計や顧客への案内に利用する前に、何の時刻かを説明できる必要があります。

最後に、状態が戻る場合を確認します。注文変更や取り消しで前の工程へ戻るとき、過去の処理が消えるのか、取り消しの記録が残るのか、関係者へ通知されるのか。通常の順番だけを図にすると、この戻り道が抜けます。誰が変更できるかという権限の整理も、言葉の定義と一緒に扱います。

通常の一件と、困りやすい一件を並べて試す

対応表ができたら、現場の担当者と具体例で確かめます。最初は、機密情報や個人情報を含まない架空の注文を使います。顧客名や取引金額を実データから写す必要はありません。商品の種類、数量、納期など、状態の違いを確認するために必要な条件だけを置きます。実際のデータが不可欠な場面では、権限者と閲覧範囲を別途合意します。

通常の一件では、受付、確認、承認、出荷指示、引渡しまでを順に追います。それぞれの担当者に「今、何が終わっているか」「次に何をしてよいか」を説明してもらいます。同じ名前を復唱できるかではなく、同じ行動を選べるかを見るのが目的です。説明が違えば、担当者の記憶違いと決め付けず、定義の不足か運用の違いかを調べます。

次に、部分出荷を試します。注文の一部だけを出したとき、注文全体を完了にするのか、明細ごとに状態を持つのか。残りの数量をどこで管理し、誰が顧客へ連絡するのか。全件を一つの状態へまとめるシステムと、明細単位で管理するシステムでは、一対一の変換ができない場合があります。無理に一つへ寄せる前に、残っている仕事を表す方法を考えます。

取消しや変更も別の例として扱います。出荷指示の後に注文が変わった場合、営業側の変更だけで倉庫の作業まで止まるのか。既に引渡しが済んでいれば、通常の取消しではなく別の対応になるかもしれません。この記事は対応の正解を決めるものではありません。画面の更新がどの担当まで伝わり、どの確認を必要とするかを見えるようにする方法です。

一つの例に、複数の問題を詰め込まないことも重要です。部分出荷、納期変更、返品、入力の遅れを同時に入れると、何が原因で判断が分かれたのか追えなくなります。まず条件を一つだけ変え、必要に応じて組み合わせます。試した条件と試していない条件を残せば、確認の限界も説明できます。

結果の記録には、正解・不正解だけでなく、解釈が分かれた箇所を残します。「倉庫へ連絡済みだと思った」「承認待ちと理解した」といった違いは、説明文や通知の改善に使えます。個人の評価資料にするためではなく、仕事を受け渡す条件を改善するための記録であることを参加者へ伝えます。

また、試行の所要時間も確認します。新しい定義が正確でも、入力項目が増えて現場が処理できないなら、運用の見直しが必要です。必要な記録と、二重に入力している項目を分け、既存の情報を参照できる方法を検討します。ただし、時間を短くするために確認そのものを省略してよいかは、別の判断です。

違いを残すか、共通化するかを決める

すべての状態を同じ名前へ統一することが、PMIの目的ではありません。顧客や製品が異なる業務では、違いを残した方が分かりやすい場合もあります。経営側が知りたい進捗を共通の区分で集計し、現場では詳しい状態を使い続ける方法も考えられます。共通化する範囲と、その外側に残る意味を説明できることが重要です。

判断の際は、違いによって起きる影響を具体化します。単に一覧の見た目が違うのか、後工程が誤って動くおそれがあるのか、顧客への回答が変わるのか。影響が大きい箇所ほど、定義、証拠、権限、通知を詳しく確認します。件数が少ないから重要でないとも限りません。例外の一件が、納期や品質上の重大な問題へつながる可能性は個別に検討します。

共通化すると決めた場合は、変更を承認する人と、業務上の影響を確認する人を明確にします。システム担当が列名を直せることと、業務の意味を変更する権限を持つことは別です。営業、物流、管理部門など、影響を受ける側の確認を経て、いつからどの定義を使うかを決めます。変更前の注文をどう扱うかも忘れずに整理します。

対応表には版を付けます。改訂日だけでなく、何が変わり、どの業務へ影響するのかを短く残します。以前の意味で処理された記録を、新しい意味だったものとして読み替えないようにします。過去データを分析する場合には、期間によって定義が違うことを利用者が分かる必要があります。

変更しないと決めた場合も、放置とは区別します。違いを残す理由、連携時に必要な補足、問い合わせ先を残します。例えば、経営向けの集計では「未完了」とまとめても、現場では「顧客回答待ち」と「在庫確認待ち」を区別する。その二つの見方が併存する理由を説明すれば、会議と現場で言葉が食い違っても混乱を減らせます。

ここまでの調整が難しいときは、ツールの機能一覧より先に、誰の判断を支えるための共通化なのかへ戻ります。専門家や支援者へ相談する際も、両社の状態名、判断が分かれた架空例、残しておきたい違いを示すと、問題の所在を伝えやすくなります。個別の取引情報を必要以上に含める必要はありません。

中小企業庁のアクションプランは「いつ・誰が・何を行うか」を具体化するツールとして紹介されています。定義の決定だけで終えず、説明資料の更新、担当者への周知、試行、確認結果の整理までを作業として割り当てる際に参考になります。以下の運用方法は編集部の提案であり、公式資料が特定のシステムへの統一を求めているわけではありません。[1]

切替の前後で、未完了の仕事を失わない

状態の定義を変える日は、処理が終わっていない注文が残っているかもしれません。新しい定義だけを決めて、既存の案件をどちらで読むかを決めないと、担当者がそれぞれ違う判断をします。切替対象、基準時点、継続中の案件の扱い、判断に迷った場合の窓口を、切替計画へ含めます。

準備では、未完了の仕事を確認するための一覧を作ります。ただし、顧客名簿や全履歴を丸ごと複製することを意味しません。対象の仕事を識別する番号、現在の状態、次の担当、期限、照合に必要な情報など、目的に必要な範囲を定めます。保存先とアクセス権限は、案件の情報管理方針に沿って設定します。

切替前後で比べるものは、件数だけでは足りない場合があります。全体の件数が同じでも、同じ注文が重複し、別の注文が抜けている可能性はあります。識別番号や数量など、対象業務に合った照合方法を選びます。数値の一致が何を確認したことになるのか、何をまだ確認していないのかを記録します。

最初から全件を新しい運用へ移すか、限定した範囲で試すかは、業務の性質と実施条件で判断します。試行が可能なら、対象、期間、担当、観察する項目を決めます。問題が起きたときに元へ戻す場合も、途中で発生した処理をどう整合させるかが必要です。単に旧画面へ戻せることを、業務全体を戻せることと同一視しません。

並行運用にも注意点があります。旧方式と新方式の両方へ入力する期間を設けると、確認材料は増えますが、二重処理の可能性や負担も増えます。どちらを正式な記録とするか、差が出たときに誰が解消するかを決めます。並行運用を長く続ければ安全になると考えず、終了の判断条件をあらかじめ置きます。

切替後の最初の確認では、予定どおり動いた一件だけでなく、保留や取消しなど試行で難しかった状態を見ます。定義の理解、通知の到達、次の担当への受渡しが確認できるかを確かめます。問題の報告がないことだけを成功の根拠にせず、利用者が疑問を伝えられる窓口が機能しているかも確認します。

システムの設定や権限を変更する場合は、権限を持つ担当者が合意した手順で行います。状態対応表を作る担当者が、そのまま本番変更をしてよいとは限りません。実施者、確認者、中止条件、結果の記録を分け、業務上の合意と技術的な操作の権限を混同しないようにします。

切替の責任者は、作業を終えたという報告と、後工程が受け取れたという確認を分けて集めます。送信側で処理が成功しても、受信側の担当者が異なる意味で読んでいるなら、業務の接続は終わっていません。双方の確認結果を一つの記録へ対応付け、片側だけで完了の印を付けない運用を検討します。これはすべての案件に共通する義務ではなく、引継ぎの漏れを見つけるための編集部の提案です。

また、現場へ知らせる内容は、変更点だけでなく、変更しない点も含めます。今回変わるのは集計用の分類であり、顧客への回答手順は従来どおりという場合には、その境界を明示します。説明が曖昧だと、関係のない手順まで自主的に変えてしまうかもしれません。問い合わせへの回答は関係する部署へ共有し、同じ質問へ異なる説明が出ないように整理します。共有に当たっては、個別の注文や顧客の情報を含める必要があるかを確かめます。

会議の数字を、現場の意味へ戻せるようにする

統合後の会議で「未処理が減った」と報告されたら、何が減ったのかを確認します。作業が進んだのか、分類を変更したのか、対象範囲が変わったのか。どれも数字へ影響しますが、経営上の意味は異なります。状態名の統一と同時に集計方法を変えた場合には、単純な前後比較ができるかを点検します。

報告資料には、集計対象、基準時点、単位、対象外の状態を添えます。注文単位と明細単位が混在していると、件数だけを比較できません。片方は受付日、もう片方は更新日で集めている場合も、同じ期間の仕事を見ているとは限りません。会議で毎回口頭説明するのではなく、定義へたどれる注記を残すと確認がしやすくなります。

ただし、定義書を厚くすることが目的ではありません。日常の報告で迷う可能性がある違いを、短い説明と具体例で示します。詳細は別の資料へ分け、利用者が最新版へアクセスできるようにします。資料の保管先が増えるほど分かりにくくなるなら、参照元を絞り、更新の責任者を明確にします。

現場からの疑問には、質問と決定を分けて対応します。「この注文は完了か」という質問に、その場の担当者が便宜的に回答しただけなら、全体の定義変更とは区別します。継続して使う判断にする場合は、必要な関係者の確認を経て、対応表や手順書へ反映します。口頭の例外が積み重なると、同じ言葉の下に違う運用が再び生まれます。

関連するFUNDNOTEの面談後の記録の記事は、確認の場で得た回答、自社の解釈、残った宿題を分ける考え方を扱っています。資金調達を勧めるためではなく、定義のすり合わせ会議でも、誰が何を回答し、何がまだ決定していないかを整理する際の補助として紹介します。業務状態の判断自体は、今回の関係者が確認してください。

経営向けの指標と現場の状態をつなぐ際は、異常を見つけたときに元の仕事へ戻れることも大切です。集計結果から対象の一覧を確認し、担当者が状況を説明できるかを見ます。必要な権限の範囲で追跡できれば、数字の変動を単なる印象で議論せず、具体的な改善へ結び付けやすくなります。

最初の打合せで揃えたい、四つの問い

まず、「この言葉は、何が終わった状態か」を聞きます。入力の完了、確認の完了、顧客への回答、現物の引渡しを区別してください。次に「この状態になったら、誰が何をしてよいか」を確かめます。状態名の意味は、後工程の行動とつながって初めて、業務の接続に使えるものになります。

三つ目は「例外が起きたら、どこへ戻るか」です。部分的な完了、取消し、変更、保留を、通常の流れとは別に試します。最後に「いつの定義で、どの仕事を処理したかを追えるか」を確認します。更新の履歴と切替対象を残すことで、後から数字や判断を見直す際の手がかりになります。

打合せの成果は、全用語の統一でなくても構いません。意味が一致した箇所、違いを残す箇所、追加確認が必要な箇所を分け、次の担当と期限を決めます。未決定の内容を空欄にせず、誰の何の判断を待っているかを示せば、後の会議で同じ説明を繰り返す負担を減らせます。

そのうえで、実際に使う人へ説明できるかを確認します。管理者が理解していても、注文を受ける人や出荷を担当する人が以前の意味で使っていれば、接続の問題は残ります。架空の一件を使い、必要な行動を説明してもらう確認は、資料の受領確認だけでは分からない点を見つける機会になります。

買収後の統合では、同じ仕組みへ揃えることが目立ちます。しかし、言葉の意味がずれたまま仕組みだけをつないでも、次の担当者は正しく動けません。「処理済み」という短い表示の裏側にある確認、権限、残った仕事を言葉にする。それは大きなシステム投資の前にも始められる、事業をつなぐための具体的な準備です。

最初の範囲を終えた後は、次の業務へ広げるかを判断します。今回作った表をそのまま横展開するのではなく、別の商品や拠点でも同じ前提が成り立つかを確認します。担当者の役割や顧客との約束が異なるなら、共通部分を使いながら例外を追加する方が適切な場合もあります。小さく試して得た知見と、まだ試していない領域を明確に区別してください。

最後に、資料の管理者を決めて終えます。担当者の異動、新しい取引条件、システム更新があれば、状態の意味も変わる可能性があります。定義が一度決まったことを永久の完了とせず、どんな変更が起きたときに見直すかを決めます。定例会議を増やすより、業務の変更と定義の確認を結び付ける方が、更新が必要な場面を見つけやすくなります。