製造システムへの投資
製造プラットフォームに関しては、購入決定は複雑です。
多くのベンダーが多種多様なソリューションを提供しているからだと思うかもしれません。
しかし、購買決定が複雑なのは、単に混雑した競争のためだけではありません。多くのメーカーにとって、決断はどの ベンダーを信頼するかということではありません。むしろ、社内でソリューションを構築すべきかどうかです。
つまり、購入の意思決定は、多くの場合、「作るか、買うか」という古くからの問いに集約されるのです。
建てるか、買うか？
以下は、あなたが尋ねるべき7つの質問です：
- 社内で建設する場合、費用はどのくらいかかりますか？
- 継続的なコストを計算していますか？
- 規模は拡大しますか？
- 複雑さをどのように管理しますか？
- IT部門は製造業務を理解していますか？
- 使い方は簡単ですか？
- 柔軟性は？
それでは、それぞれの質問を掘り下げていきましょう。
1.内製化にはどれくらいのコストがかかりますか？
ソフトウェア開発者のチームがある組織であれば、社内で構築するのが論理的な解決策かもしれません。
社内のチームと協力することで、プロジェクトのスケジューリングがより正確になり、実行をよりコントロールできるようになり、ベンダーから購入する場合に発生するプロジェクト管理の難しさの多くを緩和することができます。
しかし、それが最も費用対効果が高いということではありません。また、最速でもないかもしれません。
コストを把握するには、簡単な計算が必要です。
どの情報源を参考にするかにもよりますが、平均的なソフトウェア・プロジェクトは完成までにおよそ10ヶ月かかります。小規模なプロジェクトであれば4ヶ月程度、大規模なプロジェクトであれば1年以上かかることもあります。
平均的な開発者の時給が60～100ドルだとすると、ソフトウェア・プロジェクトのコストは、1年間のプロジェクトでおよそ107,400～179,000ドルになります。一人の開発者の場合
さらに、ソフトウェア・エンジニアがプロジェクトに費やす時間の機会費用も考慮するとよいでしょう。エンジニアが現場のアプリケーションを構築している間、どのようなプロジェクトを保留にしていますか？
2.計算には継続的な費用も含まれていますか？
私たちの経験では、ソフトウェアのコストは最初の納品だけでは終わりません。(継続的なサポート・コストが発生する、あるメーカーの経験談は後述しますので、お楽しみに）。
多くの場合、自社製の製造アプリケーションは、製造プロセスの変更を考慮して修正および更新する必要があります。
ソリューションが社内で構築されている場合、変更のたびにチケットの提出、履行、再デプロイが必要になります。変更をプッシュするのに2週間（変更にはスプリントがかかると仮定）かかるとすると、請求にかかるソフトウェアエンジニアリングの時間は2週間となり、プロセス改善の遅れによる収益の損失も発生します。
3.拡張性は？
社内でカスタムビルドされたソリューションの大きな利点は、生産ライン、セル、またはプロセスの固有のニーズを考慮できることです。
しかし、そのカスタムソリューションは複数のラインで機能するのでしょうか？工場内のすべてのラインで機能するのでしょうか？地域全体、あるいは国際的に展開できますか？
特注ソリューションの懸念事項の1つは、拡張性がないことです。新しいコンテキストにソリューションを移行すると、最初のソリューションと同様のプロジェクトコストとタイムラインが発生する可能性があります。
4.複雑性をどのように管理しますか？
自家製システムが拡大するにつれ、範囲と複雑さのトレードオフが生じます。
システムがより広範なプロセスやオペレーションを包含するようになると、システムはより複雑になります。
これは自然法則ではありませんが、何十年も前から製造業では事実です。
社内ソリューションの規模が大きくなればなるほど、複雑さも増していくのでしょうか。
5.ITは最も効率的な製造プロセスを構築するか？
コンサルタントにアンケートを取ると、エンジニアは繰り返しこう言います：「IT部門はOTの問題を理解していない！」。
このため、製造ITグループを社内に設置する必要がありますが、これ自体にもコストがかかります。
製造現場で本当に必要なソリューションの種類は、製造オペレーション（エンジニア）だけが知っています。
IT部門は通常、製造オペレーション・グループに対するサービス・プロバイダーとして機能します。どのようなサービス契約でも、成功するかどうかは、強固な協力関係と明確なコミュニケーションにかかっています。
しかし、ITグループがOTグループに代わってソリューションの開発を担当する場合、要件が誤って解釈されたり、完全に見落とされたりすることがよくあります。
これは、ITとOTの間に不必要な緊張を生む可能性があります。そしてその緊張は、プロジェクトの結果を最適なものへと導きます。
6.それを必要とする労働者はそれを使うことができますか？
現場のユーザー・インターフェース（UI）の多くは、Windows 95/98時代にデザインされたように見えます。
その結果、オペレーター、監督者、新人プロセス・エンジニアは、データ入力に苦労することが多く、これらのシステムを使用するために幅広いトレーニングを受けなければなりません。
2020年、私たちは高度に最適化されたユーザー体験に慣れています。
私たちが気づいていようといまいと、消費者インターフェースは私たちの目標や意図を容易にするように設計されています。
仕事では、スマートフォンのようなシームレスな体験を可能にするソリューションと接することができるはずです。
7.社内ソリューションの柔軟性は？
製造工程は変化します。おそらく微妙に。しかし、製品ライン、顧客の需要、技術が変われば、製造プロセスも変わります。
社内のソリューションで対応できますか？
開発者が変更をプッシュするのにかかる時間は？製品の小さなバリエーションを管理することで、大きな頭痛の種になることはありませんか？
ビルドとバイの実際：大手多国籍メーカーの決断
柔軟性についてのこの最後の質問から、この記事のポイントをうまく要約したような話が浮かんできました。
最近、ある大手多国籍メーカーの幹部が、社内でソリューションを構築するのではなく、Tulip 協業することを決断した背景について説明する機会を得ました。
これです：
その経営幹部はまず、リーン原則に対する組織の取り組みについて説明しました。彼のすべての工場は、継続的改善を積極的に追求していました。
そのため、作業セルのレイアウトや工程設計は非常に柔軟でした。
エンジニアが新しいワークセル構成を提案したり、会社が製品ラインを更新したりするたびに、IT部門は微妙だが時間のかかるソフトウェア更新を行う必要がありました。これは、すべての変更をC++でハードコーディングすることを意味していました。
このような状態はすぐに受け入れられなくなりました。最前線で働く従業員は、小さなプロセス改善でもIT部門との時間のかかるやり取りが必要なことに不満を持ちました。IT部門は、小さな現場の変更がソフトウェア開発者に過酷な時間を強いることに不満を募らせました。
最終的に、製造業の経営幹部は、社内でソリューションを構築するよりも、製造プラットフォームベンダーと協力する方が簡単だと判断しました。
エンジニアがアプリケーションに小さな変更を加える必要が生じた場合でも、パワーポイントで変更を加えるのと同じように、ITサポートなしで簡単に行うことができます。
結論カスタムソフトウェアはカスタム - 良くも悪くも
自社でソリューションを構築する一番のメリットは、特定のニーズに合わせてカスタム開発できることです。
ソフトウェアプロジェクトを社内で行うことで、製造業は最終製品をよりコントロールしやすくなります。社内で作業することで、プロジェクト管理の多くの困難が解消されます。
しかし、このような潜在的な利点は、カスタム・ソフトウェアの最大の欠点である、コストの膨張、要件の肥大化、設定可能性の欠如の原因でもあります。
最終的には、プロジェクトの要件、予算、リソースの問題です。