何十年もの間、生産を司るシステムは、プロセスが安定しており、製品サイクルが長く、変化は常態ではなく例外であるという前提に基づいていました。しかし、その前提はもはや成り立たず、かつては「制御」のように見えたその硬直性は、今やあらゆるシフトや拠点において「摩擦」として現れています。今日の製造業者には、3つの選択肢があります。従来のMES を導入するか、社内で独自に構築するか、あるいはコンポーザブル・プラットフォーム上に構築するかです。これらは、今後の展開に対して、それぞれ適性が異なります。
このガイドの内容
- 従来型、自社開発、およびコンポーザブルなソリューションを、導入初日の機能チェックリストではなく、長期的な価値を決定づける7つの観点から比較しました。
- 検証、インフラ、変更依頼といった項目を含め、各項目が3年から5年間でどれほどの費用がかかるか。これらの項目は、多くの予算モデルでは見落とされがちです。
- Tulipを含むあらゆるベンダーを徹底的に検証するための12の質問と 、デモの際に活用できる評価シートをご用意しました。
- メーカー各社は、一斉入れ替えを行わずにどのように対応しているのか、また導入初年度はどのような状況になるのでしょうか。
3つの道の比較
どのベンダーも「柔軟性」を謳います。その多くは「設定可能」という意味であり、これは変更できない構造の中で、値を変更したりオプションを切り替えたりできる能力を指します。その限界は2年目に現れます。プロセスが変更されても、データモデルがそれに追随しないからです。本ガイドでは、従来のソリューション、自社開発ソリューション、およびコンポーザブルなMES を、データアーキテクチャ、価値実現までの時間、所有権、人材との適合性、接続性、マルチサイトでの拡張性、検証という7つの観点から比較しています。
ベンダー評価スコアカード
これら7つの側面は、デモの際に尋ねることができる12の質問へと展開されます。それぞれの質問には、ご安心いただける回答と、会話を打ち切るべき回答が用意されています。当社を含め、候補リストに挙げたすべてのベンダーに対して、ぜひこの質問を投げかけてみてください。
| 販売店にお問い合わせください | 「良い答え」とはどのようなものか | 失格となる回答 |
|---|---|---|
| 1. 成果：私たちが責任を負っている目標に対して、責任を持つ顧客を提示してください。このシステムによって、具体的にどのような成果が実現可能になったのでしょうか？ | 同様の目標を持ち、具体的な「実施前」と「実施後」の事例がある顧客の事例 | 一般的な機能のデモであり、比較対象となる参考例はありません |
| 2. データモデル：実装後、貴社の関与なしに、当社チームだけでデータ構造を変更することは可能でしょうか？ | はい、注文レベル、単位レベル、バッチレベルでのバリエーションを含め、ライブで実演いたします。 | 「ご要望をお寄せいただければ、その範囲を明確にします」 |
| 3. プロセスの変更：開発者ではない人物を起用し、オーサリング環境において、プロセスの変更を本番環境に反映させる | デモで、開発者ではない人が、数分で完了しました | 開発者またはベンダーのリソースが必要です。構成可能ですが、組み合わせ可能ではありません。 |
| 4. AIの基盤：データ基盤はどのようなものか、またAIには別途パイプラインが必要でしょうか？ | 通常の運用によって生成されたコンテキスト付きデータであり、後付けの改修は行われていません | データ層で回答がないAI機能の一覧 |
| 5. 接続性：新しい機器はどのように接続されるのでしょうか。接続にはどのくらいの時間がかかり、誰が担当するのでしょうか。また、最新のインターフェースを備えていない旧式の機器についてはどうでしょうか。 | 設定作業、社内チーム、日数 | プロフェッショナルサービス、カスタムコード、またはベンダーとの契約 |
| 6. マルチサイト：各サイト間で基準はどのように遵守されているのでしょうか？ ローカルでの変更が企業基準と矛盾した場合は、どうなりますか？ | 管理対象のテンプレート、本番リリース前の承認ワークフロー | 標準化は、手作業による調整に依存しています |
| 7. アップグレード：プラットフォームの更新は、既存のデプロイメントにどのように適用されるのでしょうか？ | スムーズに処理され、顧客はメインブランチに残ります | カスタムバージョンごとのベンダー管理によるバックポート |
| 8. 検証：再検証はどのような場合にトリガーされますか？その範囲は変更されたコンポーネントのみですか、それともシステム全体ですか？何が自動的に生成されますか？ | コンポーネント単位のスコープであり、プラットフォームは公表されたスケジュールに従って検証されています | 有意義な変化をもたらすためのシステム全体の再検証 |
| 9. 拡張：プラットフォームの変更を行わずに、1つのユースケースから複数のサイトへと拡大した顧客の事例を挙げてください | 具体的かつ参照可能な、既存のアートファクトの拡張 | 仮定の話ですが、あるいは、拡張のたびに新しいプロジェクトとなる場合 |
| 10. チームの入れ替わり：アプリや自動化機能を構築した担当者が退職した場合、それらはどうなるのでしょうか？ | プラットフォームによって記録されるドキュメントとバージョン履歴。ガバナンスにより、作成者とは独立して基準が遵守されます。 | 「当社の顧客は、作業を進めながら記録を残しています」 |
| 11. 責任の所在：セルフサービスによる変更が逸脱や監査上の指摘の原因となった場合、誰が責任を負うのでしょうか？ | 「本番環境導入前の承認ゲート」と称し、プラットフォームとソリューションの責任範囲を明確に区分しています | 責任はすべてお客様が負うものとし、免責条項は設けられません |
| 12. 関連する実績：当社の状況に最も近い顧客を挙げてください。その案件でどのような点が難しかったでしょうか？ | 具体的に名指しされた、非常に類似した事例であり、そこに生じた困難についても率直に説明されています | ロゴの一覧、あるいは「当社には何百もの顧客がいます」 |
各ルートの実質的な費用
ライセンス料にコストの差が生じることはめったにありません。インテグレーターにかかる費用は、ライセンス料の2倍から4倍になることが多く、規制対象の業務では、その上に検証費用が上乗せされます。自社開発システムでは、これらのコストを社内のエンジニアリング工数と引き換えにしていますが、社内で賄っているため、コストが安く感じられるのです。水面下にはその他のコストが隠れており、その中には請求書に決して記載されないものもあります。それは、変更待ちのキューに滞留しているプロセス改善であり、後になって歩留まり、スループット、監査結果として表れてくるものです。
AIの基盤として必要なもの
製造業におけるAI導入の取り組みの多くは、同じ段階で足踏みしてしまいます。パイロット運用は成功するものの、その基盤となるデータが、導入されたプロセス以外を想定して構造化されていないため、第2の生産ラインや別の拠点へ展開することができないのです。現在、システムが生成している運用データこそが、将来、あらゆるAI導入の取り組みの基盤となるものです。これは、AIプロジェクトを開始する時点ではなく、アーキテクチャを選択する時点で決まるのです。
正常に動作している様子は以下の通りです
VEKA 性能が追いつかなくなった自社開発のMES に代わって導入されました。まず、課題が最も顕著だった部分、すなわちセットアップと初回品検査から着手し、次にトレーサビリティとロット追跡機能を追加しました。その後、静的な管理計画から動的な工程内検査へと移行し、さらに生産追跡、保守、ダウンタイム、スクラップ、不適合の管理へと機能を拡充していきました。
その期間中、品質上の不具合は年間530件から66件へと減少しました。さらに3か所への拡張については、それぞれを個別のプロジェクトとして進めるのではなく、1か所あたり数週間かけて実施されました。
- ↓品質基準を満たさない製品が88％も流出しています
- ↓60％の返品率
- 初品検査時間を50％短縮
- ↓不適切な金型による不良品が96％
工場内には山のような書類が散らばっており、品質上の問題を追跡しようとすると、まるで干し草の山から針を探すようなものでした。
オペレーショナル・エクセレンス担当ディレクター、マット・ラナロ氏、VEKA
-
「設定可能性」とは、固定された構造の範囲内で調整を行うことを指します。具体的には、値の変更、オプションの切り替え、あらかじめ定義されたモジュールからの選択などが挙げられます。一方、「構成可能性」は、構造そのものを変更するものです。新しいデータフィールド、ワークフロー、連携機能、ロジックは、それらを管理するチームによって作成されます。その実用性を測る基準は、誰が変更を行えるか、そしてその変更にどれくらいの時間がかかるかという点にあります。
-
従来の実装では、初期導入までに12～36か月を要し、さらに規制対象の運用環境における検証に6～12か月かかります。一方、コンポーザブル・プラットフォームでは、最初の動作可能なバージョンがおよそ3か月で完成し、システムは本番稼働時に完成した状態で納入されるのではなく、その後も継続的に改良されていきます。
-
ライセンス費用以外にも、ライセンス費用の2倍から4倍に上るインテグレーター費用、重要な変更のたびに実施される検証サイクル、サイトごとの修正、インフラストラクチャとパッチ適用、そしてカスタマイズされたサイト向けのアップグレードのバックポートなどが含まれます。このガイドでは、こうした項目をすべて個別に解説しているほか、多くの予算モデルでは完全に省略されがちなプラットフォームの移行についても取り上げています。
-
一度インストールされて稼働し始めると、そのシステムがサポートするプロセスが変更されることはめったになく、作業現場での人的介入も限られています。そのような状況では、切り替えにかかるコストがメリットを上回る可能性があり、ガイドにもそのように記載されています。
-
はい、それが通常の流れです。コンポーザブル・レイヤーは、既存のMES 、ERP 、および品質管理システムと並行して稼働し、現行システムが十分に処理できていないワークフローを引き受けます。そうしたギャップが埋まっていくにつれて、レガシーシステムの必要性は薄れ、プロセスは一斉切り替えではなく、段階的に移行されていきます。
12の質問ですね。どうぞ、お聞かせください。
デモの際、このスコアカードをお持ちいただき、開発者ではない方と一緒に、オーサリング環境上でプロセス変更を実際に実行してみてください。私たちは、信頼されるよりも、実際に試していただくことを望んでいます。