アップグレードのプロセス：Frontline Operations と従来のMESの比較

小さなアップグレードやバグ修正が、日々のワークフローの改善、新機能の活用、あるいは直面している重大な問題の解決にどれほど大きな効果をもたらすか、私たちは皆、身をもって実感してきたことでしょう。

システムの最適な稼働を維持し、不具合を修正し、ベンダーが開発した新たなイノベーションの価値を最大限に引き出すためには、アップグレードが不可欠です。しかし、一部のメーカーでは、必要なアップデートを入手するのに数か月を要しています。

Tulip オリヴィエ・ネロン氏と話しているうちに、MESのアップグレードにおいて、数ヶ月待つことなど、最も厄介な問題ですらないということが明らかになった。

オリヴィエは過去25年間、ライフサイエンス業界において、 主要5社の従来型MESシステムの導入に携わってきました。 オリヴィエは、中小企業（ELAN、Propack-Data、Werum）および大企業（Honeywell、Körber、Rockwell Automation）で勤務する機会を得て、XFP、PMX、PharmaSuite、POMS/POMSnet、PAS-Xなど、多種多様なMESシステムの導入に携わってきました。

この記事では、MESソリューションの総所有コストに影響を与える、アップグレードに伴う隠れた（そして残念ながら一般的に容認されている）コストについて考察します。その後、Tulipなどのノーコードアプリプラットフォームによって可能になるアプローチと、それによるメリットについて解説します。

本題に入る前に、MESのアプローチと、Tulipノーコードプラットフォームを用いた新しいアプローチを比較する際、「カスタマイズ」と「設定」の違いを明確にしておくことが重要だと思います。「カスタマイズ」とは、ベンダーやインテグレーターが顧客により適したソリューションを提供するために製品に対して行うコードの変更を指します。これらのコード変更は、基本機能に影響を及ぼします。「設定」とは、顧客がコードに触れることなく、既存の機能を設定して自社のプロセスにより適したソリューションを構築することを指します。いずれの場合も、これらの変更は顧客の要件に基づいています。

従来のMESベンダーが顧客に最適なソリューションを提供する際のアプローチは、コードの変更による製品のカスタマイズです。オリヴィエ氏や、私が話を聞いた他の数名のMES業界のベテランによると、これはごく一般的な手法だそうです。後で見るように、システムの更新が必要になるまでは、カスタマイズは問題なく、むしろ有効な手段です。

製品の更新情報

MESソフトウェア（およびほとんどのソフトウェア製品）には、メインの製品ブランチと、それに付随する製品パッチブランチがあります。メインの製品ブランチでは、6か月から1年ごとにメジャーリリースが行われ、通常は大きな新機能や更新が含まれます。

製品パッチブランチには、新機能と不具合修正（10件から450件程度）が混在しています。メインの製品ブランチで利用可能な最新機能への更新時期が来ると、ベンダーはブランチ版に対して、顧客向けの不具合修正のバックポートを適用します。これには、更新によって問題が発生しないことを確認するための回帰テストが伴います。

カスタマイズを行わないこのシナリオでは、状況がすぐに混乱してしまうことがわかりますが、MESベンダーであれば、数日あるいは数週間という比較的短期間で修正を提供することができます。

メーカーごとのカスタマイズを追加する

ここで、カスタマイズがもたらす影響についてさらに考えてみましょう。ベンダーは顧客ごとに、製品のソースコードからコピーしたプロジェクトインスタンスを作成し、顧客の要件を満たすソリューションを実現するために、製品の適応（カスタマイズ）に数千時間もの時間を費やします。これらのカスタマイズは、ハードコーディングによる変更で行われます。こうして顧客はカスタマイズされたソフトウェアバージョンを手に入れますが、これを検証し、展開する必要があります。

新製品のアップデートが利用可能になるたびに、ベンダーの担当者は、顧客のカスタマイズ版製品に合わせて調整したバックポートを提供する必要があります。修正作業には数週間から数ヶ月を要します。

製造拠点ごとのカスタマイズを追加する

さらに事態を複雑にしているのは、1つのメーカーであっても、実際には複数の拠点を持っており、そのすべてに拠点ごとのカスタマイズが必要となる場合があるという点だ。

新製品のアップデートがリリースされるたびに、ベンダーの担当者は、顧客がカスタマイズした各製品バージョンに合わせて、個別にバックポートを提供する必要があります。修正作業には1～2ヶ月を要します。

MESアプローチの影響

このMESアプローチには、多くの欠点や問題点が伴います。

新製品のアップデートに惹かれ、メーカーはメインの製品ブランチに再び合流し、大規模なアップグレードプロジェクトを完了させたいと考えるかもしれません。同じ製品の複数のバージョンを維持することにうんざりしたメーカーは、単一のバージョンのみを採用しようと試みるでしょうが、各拠点は自分たちのカスタマイズが最良だと主張するでしょう。

コードの更新を行うたびに、システムが正常に動作することを確認するための検証手順が必要です。

アップグレードに伴う複雑な事情により、ベンダーによる製品アップデートが提供されても、当サイトでは数か月間は最新の更新内容を確認することができません。

Tulip Frontline Operations Tulip、ソリューションのカスタマイズを少し異なる方法で扱っています。 前述の通り、Tulip 顧客ごとに製品をカスタマイズするTulip 。その代わり、Tulip のノーコードプラットフォームは設定変更が可能であり、インターフェース、データ構造、トリガー、接続設定などを、ご自身で、Tulip サポートを受けながら更新することができます。またTulip クラウドネイティブなTulip 、AWS、Azure、またはAWS GovCloud上でデプロイ可能です。

アップグレードの観点から見ると、これはプラットフォームの更新が極めて簡単かつ迅速に行えることを意味します。2週間ごとのプラットフォーム更新をご希望の場合、新機能やバグ修正を自動的に利用開始できます。Tulip アップグレードのタイミングをより細かく管理したいお客様向けに、Tulip 年に2～3回、長期サポート版Tulip 提供しています。いずれの場合も、メインのプラットフォームブランチのまま、設定に影響を与えることなく最新の機能やバグ修正を利用できます。

お客様Tulip 修正が必要な場合は、Tulip 数日以内にマイナーアップデートとしてTulip 。このアップデートは、ご希望のお客様ならどなたでもご利用いただけます。また、修正内容は次回のメジャーリリースに向けたメインのプラットフォームブランチに統合されるため、アップデートを待ってもリスクはありません。

Tulip 、修正を数時間から数日で反映Tulip 。ソリューションのカスタマイズが必要な変更についても、ベンダーやインテグレーターに頼ることなく、社内で対応可能です。

Tulip 、更新のたびに検証プロセスをTulip Tulip 監査可能な品質管理システム（QMS） Tulip 、6ヶ月ごとに完全に検証済みのプラットフォームリリースを提供します。顧客のビジネスニーズに基づいてApps 、検証の観点からは「構成」とみなされ、それ自体がMBR（マスター・ビルド・レコード）の文書となります。MBRはバージョン管理されており、Tulipアクセス可能です。Apps 、完全に準拠した履歴記録が生成され、これは完全にデジタル化されており、MBRのバージョンと紐付けられています。

MESsは、Tulip 企業の課題解決をTulip 範囲の一部に対して、解決策を提供します。

Tulip現場業務プラットフォームは、作業指示書、作業日誌、品質レポート、リーン生産方式など、より幅広いユースケースに対応できるソリューションを提供します。アプリ、テンプレート、コネクタが揃ったTulip をご覧ください。

TulipプラットフォームTulip、機械やセンサーだけでなく、人間、カメラのトリガー、各種デバイスからも情報を収集できます。生産データにさらなる文脈を与え、より包括的な全体像を把握しましょう。このデータには、閲覧権限を持つユーザーのみがアクセスでき、組み込みの強力な分析機能を活用して、主要指標のリアルタイムダッシュボードを作成することも可能です。

Tulip 更新が簡単Tulip 、ノーコードのアプリエディタにより、企業は単純な変更を行うためにベンダーやインテグレーターに依存することなく、自社でシステムを管理しやすくなります。

Tulip、貴社の業務運営の改善にどのように役立つかご興味をお持ちでしたら、ぜひ今すぐ弊社チームまでお問い合わせください！