プロジェクトの立ち上げにあたり、同社は複数の既存FA(ファクトリーオートメーション)メーカーに相談を持ちかけました 。しかし、そこで提示された提案の多くは、工場内に「ローカルサーバーを設置する」ことを前提とした、従来型のオンプレミスシステムでした 。
当時の佐伯工場が直面していた課題は、大きく分けて以下の3点でした。
① 強固な「セキュリティの壁」とクラウド活用のジレンマ
同社が目指していたのは、将来的な拡張性や、高度なデータ解析・AI連携を見据えた「クラウド(AWS等)をベースとしたデータ駆動型プラットフォーム」の構築でした 。 しかし、工場の制御ネットワーク(FAネットワーク)は、万が一にも外部からのサイバー攻撃やウイルス感染による操業停止を招いてはならない極めて機密性の高い領域です。社内の一部からは、「FAネットワークからインターネットに直接データを出すなど、セキュリティ上絶対にNGである」という非常に強い抵抗と懸念の声が上がりました 。クラウドを活用したいという理想と、インターネット接続の危険性を排除したいという現実のセキュリティルールの間で、プロジェクトは大きなジレンマに陥っていたのです 。
② テクノロジー制限による「妥協に満ちた現場業務」
従来のシステム環境にはテクノロジー的な限界があり、現場のオペレーションは多くの「妥協」によって成り立っていました 。
アナログな情報管理: 工場内の発生事象や計器の記録は、依然として「紙」や「写真」ベースで行われていました 。
転記と集計の手間: 現場の工程担当者がDCS(分散型制御システム)画面や計器から条件、投入量、出来高を目視で読み取り、作業報告書を手書きで作成 。それを工程管理者がExcelに入力し、さらに生産管理者が月次で原価計算システムへ手動で集計・入力するという、重層的な転記作業が発生していました 。
評価のタイムラグ: データの集計や会議での検討には数時間から数日を要しており、何かが発生した後の「結果」でしか判定できない状態でした 。
「報告書を作ることやデータをExcelに転記することが仕事になっていないか? そもそもなぜ監視し、報告するのか。本質は製造プロセスの状態を適切に判断し、最適な状態に制御すること(オペレーションの最適化)であるはずだ」
同社はこの状態を「テクノロジー制限による妥協」と捉え、最新のITを活用して本来の姿(リアルタイムな状況把握と自律対応)へ変革する必要性を痛感していました 。
③ 膨大なエネルギー消費と「見えないムダ」
広大な敷地に点在する各種貯蔵タンクや加温タンク、撹拌機などの設備において、具体的にどこで、どれだけの電力や蒸気、熱水が「無駄に消費されているか」をリアルタイムに突き止める手段がありませんでした 。全体としてのエネルギー消費量は把握できても、個々の設備ごとの詳細な挙動とエネルギー消費の因果関係(相関性)がブラックボックス化していたため、有効な省エネ施策を打つことが困難だったのです。