製造実行システム（MES）の2022年ガートナー®マジック・クアドラント™におけるチャレンジャーとしての位置づけに関するブログシリーズでは、これまで、コンポーザビリティの概念と、それが さまざまな業界でどのように 適用されるかについて、多くの具体的な内容を取り上げてきました。
では、なぜTulip フロントラインオペレーションプラットフォームが MES クアドラントのチャレンジャーに選ばれたのか、そしてそれが従来のMES何を物語っているのかについて考えてみましょう。
サービスとしてのプラットフォーム（PaaS）と従来のMES 主な違いは、前者のアーキテクチャがコンポーザブルなソリューションを可能にすることです。
コンポーザブル・アーキテクチャとは？
コンポーザブル・アーキテクチャには4つの柱があります。
敏捷性
アジリティには、やるべきことに合わせてプロセスを調整できることが必要です。この柱の特徴は、迅速な実装、更新、反復と、柔軟でアクセスしやすいデータ構造です。
拡張性
コンポーザブル・アーキテクチャーは、他のソリューションと接続する能力をモジュール化し、事前に構築されたコネクターでオープンAPIを提供します。また、ノーコードのエッジ接続とローコード機能を備えている必要があります。
アクセシビリティとスケーラビリティ
コンポーザブル・アーキテクチャーは、同じようなサイトや状況に対してソリューションを複製できるものでなければなりません。信頼性が高く、成長に合わせてパフォーマンスを発揮できること。そして適切なデータは、特定のステーションやサイトだけでなく、どこからでも、人々が必要とするデータ構造でアクセスできなければなりません。
人間中心
コンポーザビリティは、その性質上、人間中心です。コンポーザブル・アーキテクチャは、直感的なインターフェイスと、作業者のデバイスからのデータを使用した合理的なワークフローを特徴とする必要があります。これらの要件は、今日の製造業の労働者の要望と期待を表しています。人々は、自分の経験を大切にする革新的な企業で働くことを望んでいます。
過去のモデルはどのようなものでしたか？
従来のMES 、プラットフォームのようにコンポーザビリティを扱うことはできません。
あるサイトに従来のMES ロールアウトしたいとします。要件プロセスや業務フロー図を検討し、ベンダーを選びます。ベンダーはMES展開を開始します。
ほとんどの場合、お客様側でのカスタマイズが必要になります。システムの統合やプロセスの要件に合わせなければなりません。
MES 選択した時点と、それを完全に導入した時点とで、何も変わっていないのです。
さて、あなたは別の場所に配備したいと思います。そこでは状況が異なります。追加の対応が必要です。(例えば、最初の実装ではマシンがすべてだったのに対して、その場所にはマシンがないかもしれません）。次に、これを3つ目の場所に追加したいとします。同じMES実装するにしても、コアとなるコードベースへの変更やカスタマイズは、前回とは少しずつ異なります。
では、2つ目のサイトから3つ目のサイトに直接適用できるベストプラクティスを特定したいとします。ここで問題が発生します。モノリシックなコードベースという概念そのものが、各サイトの実装にカスタマイズを必要とします。
マイクロサービス・アプローチはそうではありません。
では、クラウドへの移行を躊躇している人がいる一方で、このアプローチへの移行を躊躇している人がいるのはなぜでしょうか？
レガシー。製造業者は、すべてのソフトウェアがオンプレミスで使用するために構築されたときに行われたアーキテクチャ上の決定の結果に、まだ対処しなければなりません。そのコードベースを単純に持ち上げてクラウドに出荷し、それが実行されることを期待することはできません。
クラウド・ネイティブ・アーキテクチャーによって構築できるようになる方法を、そこから構築し始めなければ再創造するのは困難です。
つまり、行き詰まっているわけです。クラウドネイティブを始めていなければ、ベストプラクティスを取り入れて次のサイトに移行するのは難しすぎます。MES 1.0からMES 2.0、あるいは2.1、2.2へのアップグレードは、おそらくさらに困難です。それは苦痛であり、時間がかかります。
それはあなたの視点からの話です。しかし、従来のMES ベンダーがどうなるかを想像してみてください。ベンダーにとってどのような影響があるでしょうか。
12サイトずつ12人の顧客を管理している場合、144の異なるバージョンのコードベースを維持する必要があります。コアとなるサービスに加える変更は、そのコードの144の異なるフォークと逆互換でなければなりません。これは複雑で困難なソリューションになります。
このことが、MES見られる技術革新の変化のスピードの遅さを説明しています。ゼロ日目のアーキテクチャの決定がすべてを左右します。
要約すると、従来のMES モデルは次のとおりです：
人間ではなくシステムにフォーカス
アップグレードが困難
更新が遅く、コストが高い
複雑でサイロ化
Tulip 従来のMESどのように挑戦していますか？
前回説明したアーキテクチャ（これもオンプレミスで生まれたもの）と比較すると、クラウドネイティブ・アーキテクチャは物事をより簡単かつ迅速にします。
Tulip プラットフォームには1つのコードベースがあり、アプリはコード化されたカスタマイズではなく、コンフィギュレーションです。コンポーザブル・アーキテクチャの柱を思い返すと、アジリティと拡張性がこれを要求しています。
単一のコードベースにより、コードベース全体の定期的で迅速なアップデートが可能になり、オーバーホールやカスタマイズではなく、すべてのサイトにわたって隔週または四半期ごとにプラットフォームをアップグレードすることができます。新しい機能へのアクセスも早くなります。
また、ベストプラクティスをアプリを介してサイト間で簡単に複製することができます。
Stanley Black & Decker社で現場のオペレーターのためにソリューションを構築したソフィアを覚えていますか？もし彼女が、そのアプリケーションをさらに10カ所の拠点に展開し、その恩恵を受けられると考えたら、それはごく簡単なことです。もしSB&D社が以前のアーキテクチャと従来のMESアプリケーション開発の旅を始めていたら、それは事実上不可能だったでしょう。
要約すると、クラウドネイティブプラットフォームとコンポーザブルモデルの利点です：
すべてのサイトで同じコードベースが動作
ベストプラクティスのアプリ共有
事業全体を俯瞰
2週間ごとのサイレントアップグレード
イノベーションへの早期アクセス
コード不要のアプリで柔軟性を実現
製造実行システム（MES）の2022年ガートナー®マジック・クアドラント™では、市場の変化の意味について多くの思慮深いコメントを見ることができます。また、「MES アーキテクチャ・イノベーション」ケイパビリティの導入では、ベンダーが、今日の成功する製造企業に必要とされる俊敏性と開発スピードをサポートするマイクロサービスアーキテクチャを提供することを想定しています。
従来のMES それができません。だからTulip チャレンジャーなのです。
それでも、従来のMES コンポーザビリティへの変化は、Tulipではないことに注意することが重要です。
もっと根本的なことです。それは、ソフトウェア開発に対する考え方と、それをどこで行うべきか、どこで行えるかということです：従来のソリューションはオンプレミスのアーキテクチャの決定に基づいて構築されていましたが、コンポーザビリティにはクラウドネイティブのアーキテクチャが必要です。私たちは、製造業を前進させる準備ができています。
Tulipデータ収集を自動化し、生産性を向上
アプリのシステムがどのように御社の業務全体の作業員、機械、デバイスをつなげることができるのか、弊社チームのメンバーにご相談ください。