MES 多くは、人のせいにされがちです。導入チームは研修のせいにし、現場責任者はオペレーターの理解不足のせいにします。どちらの見方も必ずしも間違っているわけではありませんが、どちらも不完全なものです。
複数の拠点や部門でシステムの導入が停滞する場合、その原因として挙げられるのは、たいていアーキテクチャの問題です。システムが業務に必要なスピードや細やかさで対応できないため、従業員がシステムに合わせて業務を調整せざるを得なくなるのです。
マッキンゼーの報告によると、製造業者の少なくとも70％が「パイロット段階の停滞」に陥っており、デジタル化の取り組みを初期導入の段階から拡大することができていません。企業がチェンジマネジメントを捉え、取り組む姿勢は改善されているにもかかわらず、その割合は比較的横ばいのままです。
この記事では、複数拠点での導入においてMES 頓挫しやすい最も一般的な要因、その根本的な原因がほぼ常にアーキテクチャ（運用上の問題ではなく）にある理由、そして現場の業務に合わせてシステムが構築された場合に、導入がうまくいくとはどのような状態なのかについて解説します。
最終的には、次回の導入が前回と同じ場所で停滞してしまう可能性がある理由を運営委員会に説明するための語彙と、次回のベンダーへのRFPに記載すべきアーキテクチャに関するチェックリストが手に入るでしょう。
MES 失敗が通常どのように診断されるか
これMES に携わったことがある方なら、標準的な導入アプローチがどのようなものかご存知でしょう。多くのベンダーやインテグレーターは同様の導入手順書を提供しており、変更管理に関するガイダンスも、明確な目標の策定、段階的な導入、役割に応じたトレーニングへの投資、変更内容の周知、経営陣の支援の確保、そして関連するチームやステークホルダーを早期に設計の議論に巻き込むことといった、同じ推奨事項に重点を置いています。
業界を問わず、強力な変更管理プログラムを導入しているプロジェクトは、そうでないプロジェクトに比べて、予定通りに完了する確率がおよそ5倍高くなります。また、明確なコミュニケーションを行うことだけでも、成功率の著しい向上につながることが分かっています。研修、コミュニケーション、経営層の支援、そして部門横断的な関与が、いずれも成功に役立ちます。
しかし、このプレイブックで抜け落ちているのは、上流工程の部分です。このプレイブックでは、導入を「展開の管理方法」による下流の成果として扱っていますが、実際には、導入は「システムの構築方法」によっても左右されるものなのです。
同じ変更管理プログラムを2つの異なるMES 適用しても、その結果は大きく異なることがあります。ある企業は10工場への展開に成功する一方で、もう一方の企業は最初の1工場を超えることさえ困難な状況に陥っています。
このギャップの原因は、通常、アーキテクチャが実際の運用環境で日々発生する変動に柔軟に対応できるかどうかにあります。運用責任者の方々と協力して、デプロイが停滞してしまった事例を振り返る際、彼らが指摘する課題は、より優れた変更管理計画があれば解決できたような問題であることはほとんどありません。それらは、システムが業務のペースについていけなかった部分に起因しているのです。
MES 頓挫するケース
MES 停滞する場合、その失敗パターンは似通っていることがわかりました。私たちは、様々な複雑な業界にまたがる複数拠点を持つ製造企業と協力してきましたが、以下の4つの問題は、私たちが立ち会ったほぼすべての事後検証で指摘されています。これらはすべて、同じアーキテクチャ上の問題に起因しています。つまり、業務の変化のスピードにプラットフォームが追いつけないため、現場のチームは回避策を講じざるを得なくなるのです。
プロジェクト計画の段階から見れば、そうした回避策は研修の不備や組織文化の問題のように見えます。しかし、実際に詳しく見てみると、それらはチームのニーズに合っていないシステムに対する合理的な対応なのです。
時代遅れのインターフェースと新しい労働力
従来のMES 多くは、製造現場の従業員が長年同じ職務に就き、メニューを操作するノウハウを身につけていた時代に設計されました。インターフェースは使いにくかったものの、オペレーターはそれに慣れ、必ずしもより良い代替手段があったわけではありませんでした。
デロイトとマニュファクチャリング・インスティテュートは、2024年から2033年の間に、米国の製造業では純増で380万人の新規労働者が必要となる可能性があり、そのうち最大190万人のポストが埋まらない恐れがあると予測しています。現場に参入する新世代の従業員は、消費者向けアプリに近い体験、つまり、洗練されていて、タッチ操作を重視し、すぐに習得できるような環境を期待しています。一方、従来のMES 、文字通り一世代前に設計されたメニュー駆動型の企業向け画面を彼らにMES 。
このミスマッチは、各拠点において導入期間の長期化という形で現れています。従来のMES では、操作に習熟するまでに数日ではなく数週間を要し、工場側では経験豊富なオペレーターの残業時間を増やすか、生産立ち上げ時の生産性低下を許容することで、そのギャップを埋めています。離職率が高まるにつれ、これらのコストはさらに膨らんでいきます。
「その場しのぎの経済」と変革のコスト
現場の業務フローは時とともに変化します。例えば、品質管理チームが、既存の処理フォームでは対応できない新しい不適合パターンに直面したとしましょう。MESでは、フォームの変更にはITチケットの発行、ベンダーとの調整、そしてリリースサイクルが必要となります。「来四半期に対応します」というやり取りが何度か繰り返された後、品質管理チームは要求を諦め、システムを回避する形で業務を進めるようになります。
稼働開始から6ヶ月が経つと、通常、工場に足を運べば、いわゆる「ワークアラウンド経済」を目の当たりにすることになります。これは、公式のシステムがMES 周りに形成された、並行して存在するスプレッドシートや「暗黙の知識」に基づくプロセスのことです。
品質チームはExcelで不適合記録を管理しており、保守部門は独自の作業指示書ツールを使用しています。その他の部門も、それぞれ独自のシステムを使用しています。MES は技術的にはMES 、実際の業務は各チームが独自に構築した並行システムで行われています。
公式システムの変更にかかるコストが、回避策にかかるコストよりも高い限り、チームは常に回避策を選ぶでしょう。公式システムの使用についてより厳格なルールを設けたとしても、その状況は変わりません。
多部位の硬直
複数拠点への展開には、別の問題が生じます。各工場は、取り扱う製品、設備、規制上の要件、オペレーターの文化、デジタル化の成熟度など、それぞれ異なる運営形態をとっています。通常、単一MES 、こうした多様な差異を一度にすべてカバーすることはできませんが、多くの従来のテンプレートは、それが可能であるという前提で設計されています。
複数拠点への展開における経験則として、グローバルテンプレートは通常、展開全体の70～80％をカバーし、残りの20～30％は各拠点固有の要因に対応するために確保されています。標準化をその上限を超えて進めると、各拠点は工場の運営方法に合わないワークフローを受け入れるか、あるいはテンプレートを分岐させて独自の構成とし、中央チームが別途メンテナンスを行わなければならないかのいずれかを選択せざるを得なくなります。
コンポーザブル・アーキテクチャは、全社的に標準化すべきデータモデル、ガバナンス、コンプライアンス体制を共有しつつ、各拠点が自社の運用実態に合わせてソリューションを適応できるようにすることで、このトレードオフを解決します。
導入スケジュールも、問題をさらに複雑にする要因の一つです。従来のMES 、最初の拠点での稼働開始までに18～36ヶ月を要することが多く、複数拠点への展開となると、さらに数年を要することになります。展開が3つ目や4つ目の拠点に到達する頃には、当初のシステムはすでに最初の拠点での現在の業務状況と合致しなくなっているのです。
なぜリアルタイムの可視化が現場まで届かないのか
MES 、記録管理システムとして MES 。オペレーターが各工程で入力したデータは記録され、レポートとしてまとめられ、監督者、工場長、そして経営陣向けのダッシュボードへと順次送信されます。コンプライアンス部門に必要な情報が提供され、主要な指標が算出され、監査証跡が作成されます。
必ずしも行われていないのが、逆方向の情報共有です。MES 、リアルタイムの文脈に応じた情報を現場にフィードバックするようには設計されていません。自分のラインが現在予定通りに進んでいるかどうかを知りたいオペレーターは、シフトごとに現場責任者が更新するホワイトボードを確認するしかありません。
同様のギャップは、数時間遅れた情報に基づいて意思決定が行われる管理職レベルや、リアルタイムのデータではなくバッチエクスポートを基に根本原因の分析が行われるプロセスエンジニアリングの現場でも見られます。
その根底にあるアーキテクチャの選択こそが、「システム・オブ・レコード」です。MES 、何が起きたかを記録するためにMES 、次の意思決定を支援するものではありません。「システム・オブ・エンゲージメント」は、システムが収集したデータを、現場で活用できる人々に提供することで、このギャップを埋めます。リアルタイムの可視性とは、もはや企業がレポートについて語る際の決まり文句ではなく、現場が実際に体験するものとなるのです。
なぜアーキテクチャが根本的な原因なのか
これら4つの課題はすべて、システム設計に起因しています。MES 、従業員が同じ職務に就き続け、ワークフローに大きな変化がなく、工場ごとに業務内容が似通っており、データの流れも上流から下流への一方向のみであった時代をMES 。しかし、今日の製造業者のほとんどにおいて、こうした前提条件はもはや当てはまりません。また、これらの旧来のシステムは、現代の工場の運営方法に柔軟に対応できるようには構築されていなかったのです。
MES モノリシックな構造で構築されており、単一のシステム内であらゆる機能が相互に密接に結びついています。品質チェックにデータフィールドを1つ追加するだけで、コードベース全体に影響が波及するため、わずかな調整であっても、開発、検証、そして調整を要する展開に数週間を要することがあります。内部の一貫性とガバナンスをもたらすこの密接な結合こそが、システムの変更を構造的にコストのかかるものにしてしまっているのです。
モジュールMES、その構築方法が異なります。単一のブロックとしてではなく、アプリやサービスからなるエコシステムから構成されているため、ワークフローを個別に追加、変更、または削除することができます。ある品質管理ワークフローに変更を加えたとしても、それとは無関係な保守ワークフローの再検証が必要になることはありません。運用チームは、スタック全体を統一されたリリースサイクルに合わせる必要なく、自身の業務に最も近いアプリを調整することができます。
このアーキテクチャ上の違いは、変更にかかるコストに表れます。MES 、独自のプログラミング言語や複雑な基盤データスキーマを採用しているため、製造メーカーは些細な調整を行う際でさえ、サードパーティのシステムインテグレーターに依存せざるを得ません。多くのチームはこれを「インテグレーター税」と呼んでいますが、総所有コストを算出する際、そのコストを過小評価しがちです。 ワークフローの変更には、実際の金銭的コストと時間的コストが伴います。そのため、メーカーはシステムの変更を一切行わず、その場しのぎの対応でやり過ごす傾向があります。
コンポーザブルなシステムアーキテクチャは、必ずしも導入を保証するものではありません。コンポーザブルなプラットフォームの不適切な実装は依然として失敗に終わります。通常、チームがそのプラットフォームを白紙の状態として扱い、導入が自然と進むことを期待してしまう場合に、そのような事態が生じます。
とはいえ、コンポーザブル・アーキテクチャは導入を容易にしてくれます。それがうまくいくかどうかは、チームがそのプラットフォームの上に構築する運用モデル次第です。
大規模な導入における成功事例
部門や拠点を超えてデジタル業務を拡大させることに最も成功している企業には、従来のノウハウでは見落とされがちな、3つのアーキテクチャおよび運用モデルの選択が見受けられます。それぞれの選択は、前述の課題に直接対処するものであり、これらを総合することで、私たちが「導入を前提にゼロから設計されたシステム」と表現する際の意味が明らかになります。
標準化と地域ごとの柔軟性
多くの導入プロジェクトが失敗する原因は、標準化すべきでない部分を標準化してしまうことにあります。私たちが規模拡大を目の当たりにしてきた導入事例において、その解決策は、私たちがしばしば「グローバルな標準化とローカルな柔軟性の両立」と呼んでいるものです。つまり、データモデル、セキュリティプロトコル、監査証跡、プラットフォームレベルのガバナンスについては厳格な標準化を図りつつ、ワークフローレベルでは各拠点が自社の製品、設備、レガシーシステム、そしてオペレーターの文化に合わせてアプリをカスタマイズできる柔軟性を併せ持つことです。
これには通常、フェデレーテッド・ガバナンス・モデルが必要となります。センター・オブ・エクセレンス（COE）は、全工場で統一する必要がある事項を管理します。一方、各拠点のチームは、拠点ごとに異なる必要がある事項を管理します。この役割分担により、グローバルチームは監査やセキュリティの要件を満たしつつ、現場の実際の運用状況にそぐわない同じワークフローを全工場に強制することなく、各拠点のニーズに対応できるようになります。
ガバナンスに基づく市民開発
「俊敏性と統制」のトレードオフは、ガバナンスがプロジェクトレベルで実施される場合に最も顕著になります。ワークフローの変更はすべて、レビュー、承認、検証、そして展開というプロセスを経る必要があり、その結果、変更の速度は中央チームが変更リクエストを処理できる速度によって制限されてしまいます。ガバナンスがプラットフォーム自体に移行すれば、このトレードオフは解消されます。
ガバナンス付き市民開発とは、業務に最も近いドメインの専門家（エンジニアや運用担当者）が、本番環境向けの製造アプリケーションを直接構築・修正する運用モデルです。これには、IT部門やコンプライアンス部門が設定した境界を、プラットフォームレベルのガバナンス、権限制御、承認ワークフロー、および監査証跡によって強制する仕組みが備わっています。 業務を行う担当者がソリューションの構築や改良も自ら行うため、変更は業務のスピードに合わせて行われます。また、境界線はプロジェクトごとに交渉して決めるのではなく、プラットフォームの機能として強制されるため、確実に維持されます。
ITチームはこのモデルに対して、注目に値する正当な異議を唱えています。プラットフォームに適切なガバナンスが組み込まれていない場合、シチズン開発はすぐにシャドーITへと変貌してしまう可能性があります。製造の文脈がなく、承認ワークフローや監査証跡、権限管理の仕組みも備えていない汎用的なローコードツールは、まさにそのような結果を招くものであり、過去にITチームがこれに苦しめられた事例も見てきました。
Tulip こうした懸念に直接的にTulip 。ガバナンスは、プラットフォームのアクセス権限モデル、バージョン管理、変更承認ワークフロー、および監査証跡に組み込まれています。つまり、現場でワークフローを構築するエンジニアは、デフォルトで承認された範囲内で作業を行っていることになります。
このモデルが導入に有効なのは、業務内容を理解している人々がワークフローを構築しているからです。私たちの経験上、導入が停滞してしまうケースは、現場の担当者から2段階離れた立場の人物が設計したものであり、一方で、うまく拡大・展開できるケースは、実際に業務を行うチームメンバーからのフィードバックを直接取り入れているものです。
単なる記録システムではなく、エンゲージメントシステム
データ層は3つ目の要素です。エンゲージメントシステムでは、データは双方向に流れます。オペレーターはワークフローを通じてデータを生成する一方で、次の判断を下すためにシステムからデータを受け取ります。経営陣は依然として上流のデータや監査証跡にアクセスできますが、オペレーター、監督者、プロセスエンジニアは、現場でリアルタイムの判断を下すために必要な可視性を得ることができます。
データは、作業を行う際の副産物として、センサーの計測値や機械からの信号、そしてオペレーターが本来行うべき工程に組み込まれた確認作業を通じて、自動的に収集されます。別途記入するフォームもなく、覚えておくべき追加の手順もありません。
MES 推進するための実践ガイド
多くの導入プロジェクトは、アーキテクチャと運用モデルがすでに決定された状態で始まります。残された決定事項は戦術的なものに限られ、私たちが手がけるすべての導入プロジェクトにおいて、初期段階では以下の5つの分野に重点を置いています。これらの取り組みの成果は、その後の展開過程を通じて相乗効果を生み出していきます。
まずは、オペレーター1名、作業場1か所、作業1つから始めましょう
私たちが手がけるあらゆる展開において、最も確実な最初の導入方法は、単一の拠点で単一のオペレーター向けに構築された、単一のコンポーザブル・アプリです。オペレーターが毎シフト実行している具体的な業務を選びましょう。理想的には、チームがこれまで紙を使って対応してきたような、手間のかかる業務が適しています。その業務をより円滑に進められるようなワークフローを構築し、それを導入します。そして、より多くのアプリや拠点、あるいはサイトへと拡大する前に、オペレーターや監督者がその価値を判断できるようにします。
ボトムアップ型のアプローチは、導入の可否がオペレーターごとに個別に決定されるため、有効です。あるアプリが1つのステーションで定着すれば、チームは次のアプリを展開するための信頼を得ることができます。いくつかのアプリが部署全体で定着すれば、チームはサイト全体に展開するために必要な基盤を築くことができます。
展開を代表するパイロットサイトを選定してください
最も扱いやすいプラントほど、パイロットとしては不向きな傾向があります。ロールアウトが最終的に直面する摩擦こそが、パイロットが克服すべき摩擦であり、最も扱いやすいプラントで訓練を受けたパイロットが得る成果は、他の状況には応用できないものとなります。
より有用なパイロットサイトとは、本展開の後に直面するであろう課題を明らかにできる場所のことです。例えば、現場にMES 工場や、独自の監査サイクルを持つ規制対象の生産環境などが挙げられます。パイロットサイトの役割は、第3工場や第4工場でより大きなコストがかかってから問題が表面化する前に、不具合の発生箇所を特定することにあります。
各部署にワークフローの管理権限を委譲する
多くの場合、各部門間でワークフローが共有されていません。品質管理部門の不適合処理ロジックは、生産スケジューリングにはそのまま適用できませんし、保守部門の予防保全（PM）サイクルには、品質管理部門には不要な独自の工数・部品ロジックが存在します。現場の業務を単一のフォーム構造で標準化しようとすると、通常、ある部門には適しているものの、他の部門には不向きになってしまいます。
コンポーザブル・アプリはこの課題の解決に役立ちます。各部門は、前述したプラットフォームレベルのガバナンスの範囲内で、運用するアプリを適応させることができます。変更はプラットフォームがすでに適用している境界内で行われるため、ワークフローの変更ごとにカスタマイズ依頼を出す必要はありません。チームは業務に必要な機能を備えたシステムを利用でき、中央チームも必要な監査証跡とセキュリティ体制を維持することができます。
トレーニング時間をアーキテクチャのKPIとして捉える
新規オペレーターが熟練に至るまでの期間は、システムが業務にどれだけ適合しているかを示す指標となります。もし新規オペレーターが、ある作業ステーションで監督なしで作業を行えるようになるまでに3週間を要するならば、そのシステムは、本来インターフェースが代行できるはずの業務を、オペレーターの記憶に頼っていることになります。この習得期間を短縮するのは、オペレーターの画面に次の適切な手順を表示する、 ガイド付きのデジタルワークフローです。上流工程での教室形式の研修を増やしただけでは、それだけではこのギャップを埋めることはほとんどできません。
Dentsplyインプラント部門を例に挙げましょう。10億通り以上のキット組み合わせに対応するように設計Tulipシステムを導入した結果、同チームは、従来のワークフローと比較して、新規オペレーターの研修時間を75％短縮することができました。この改善は、これまでオペレーターの記憶に頼っていた作業の多くを、システムが担うようになったことに起因しています。 Dentsply Tulip 導入に関する詳しいストーリーはこちらでご覧いただけます。
初日から複数の拠点での展開を計画してください
マルチサイト展開における最も一般的な失敗例は、2つ目のサイトのクローン化です。1つ目のサイトの展開が順調に進むと、チームはその展開をテンプレートとして扱い、2つ目のサイトには不適切なワークフローが引き継がれてしまいます。その結果、展開チームはその後1年間、2つ目のサイトで明らかになった問題に対処できるよう、1つ目のサイトを修正することに追われることになります。
実際には、変動への対応を計画するとは、グローバルなコア部分を最小限に抑え、サイトレベルの構成レイヤーを柔軟に設計することを意味します。工場間で統一する必要がある要素が少なければ少ないほど、新しいサイトの立ち上げは容易になり、また、サイト1で暗黙的に行われていた処理がサイト2で明らかになった際に、展開チームが後付けで修正しなければならない作業も減ります。
Stanley Black & Decker そのStanley Black & Decker 。Tulip 、「スタンレー・プロダクション・システム（SPX）」は、単一拠点での取り組みから、50以上の工場と1,000を超えるアプリケーションを結びつけるグローバルな枠組みへと拡大しました。
スタンレー社は長年にわたりTulip 拡大し、改善を重ねてきた結果、20億ドル以上の在庫削減、サービスレベルの15ポイント向上、そして品質と安全性の持続的な向上を実現しました。全拠点での導入を推進する鍵となったのは、グローバルな中核機能を最小限に抑えつつ、各拠点が柔軟に対応できるようにすることで、スタンレー社の事業ポートフォリオを構成する多様な環境、製品、プロセスを支えることでした。
拡張性MES の導入
MES 成功するケースには、共通するアーキテクチャの形態が見られます。具体的には、チームがIT部門への依頼なしに変更できるモジュール式のアプリ、各拠点がテンプレートを分岐させることなくその上に設定できる小規模なグローバルコア、そして現場の作業員にも、管理者に送信されるのと同じリアルタイムの可視性を提供するデータ層です。
ソリューションの規模拡大に伴い生じる導入上の課題の多くは、導入当初に下されたアーキテクチャの選択に起因しています。次回のベンダーとの打ち合わせで検討すべきより有益な問いは、本番稼働から6か月後に、そのアーキテクチャによって何が容易になり、何が困難になるかということです。
オペレーター、各部門、各拠点MES 評価や導入について検討されている場合は、 Tulip メンバーまでお気軽にお問い合わせください。当社は、まさにこのような意思決定に関して、複数の拠点を持つ製造業者様と協力してまいりました。