製造業のデジタル化は技術の問題ではなく、順序の問題である

順序付けこそが難しい部分であり、ベンダー資料が飛ばす部分でもあります。正直に順序を語れば、今年は買う量を減らしてくださいと顧客に言うことになるからです。このページは、その順序そのものです。

製造業のデジタル化プロジェクトが止まる理由

原因のほとんどは四つに収まります。四つとも製品の欠陥ではなくプログラムの欠陥であり、そこが要点です。つまり工場側が握れる要因です。もちろんソフトウェア自体が失敗することもあり、その一覧は調達段階に属します。トランザクション設計、規模を上げたときの性能、稼働開始で関与が終わるベンダー、といった項目です。

一つ目は、スポンサーの下にオーナーがいないこと。スポンサーは予算を承認し、月次会議に出席します。オーナーは現場に立つ時間を持ち、業務プロセスを変える権限を持ち、一年後に工場の動き方が変わっているかどうかが自分の評価に紐づいています。二つ目は、存在しないデータを前提にした投資対効果の試算です。停止時間を分析する計画が、シフト日報の自由記入欄にぶつかります。三つ目は、展開を前提に作られていないパイロット。四つ目は、問いが定まらないうちにプラットフォームを買うことです。結果として、能力はあるが最初の用途がないシステムを工場が抱えます。

最初のデジタル化テーマをどう選ぶか

最初のテーマは、モジュール一覧からではなく、その工場の制約から出てきます。多くの工場で損失は地味なところにあります。標準より長い段取り替え、見つからない材料、誰も報告しない2分のチョコ停です。

候補は三つの問いで素早く絞れます。その損失は、不良（廃却）、残業、特別便、納期遅延ペナルティといった形で、すでに工場自身の会計に現れていますか。答えが手元にあったとして、同じシフトの中で誰かの行動が変わりますか。効果があったかどうかを、1生産サイクル以内に判定できますか。四半期ではなくサイクルです。多品種の繰り返し生産なら3か月は妥当な検証期間ですが、航空宇宙や医薬品のキャンペーン生産では意味を持ちません。そこでの単位は1キャンペーン、1オーダーです。

ソフトウェアが答えではない場合もあります。制約が物理的なものなら、どんなデータも機械を速くはしません。測定がするのは、能力がどこへ消えているかを示すことです。そしてそれはたいてい、設備投資の申請を裏づけるのではなく、宛先を変えます。候補に挙がった機械の実稼働時間は、チョコ停を数え始めた途端、誰の想定よりも悪く見えます。ところが失われた時間の大半はその機械自身のものではありません。上流からの供給待ち、下流の詰まり、段取り替え、2ステーション掛け持ちのオペレーター待ちです。その機械は最初から制約ではなく、金を投じるべき場所は別にあります。

着手前に何を測っておくか——後で効果を示すために

罠は定義にあります。稼働開始前は、チョコ停が書かれていないシフト日報から時間稼働率を拾っています。稼働開始後は停止が自動検知されるので、測定されるOEEは下がります。もともとあった損失がようやく数えられるからです。以前の定義と以前の数値を誰も記録していなければ、3か月目は後退に見え、プログラムは自らの弁明に信用を使い果たします。

ですから、現在の数値とその定義を丸ごと書き出してください。百分率が使っている時間の母数、理想サイクルタイムの出どころ、停止の分類方法、計画保全を除外するかどうか、手直しの扱い方です。大勢を決めるのは最初の二つです。暦時間、計画時間、有人時間のどれを使うかで、同じ工場が同じデータから三つの違う数字を出します。理想サイクルタイムも、銘板値か、実績最良値か、一度決めてから見直されていない工順上の数値かで変わります。

次に、定義を変えにくく、しかも会計と突き合わせられる事実を押さえます。出荷数、支払工数に対する実働工数、遅延した受注明細、赤伝、残業です。変えにくいことは不可能を意味しませんから、OEEの定義と並べて、それぞれの定義とソースシステムを固定してください。納期遵守率は独立した文書上の決定が要ります。日付の基準は、どの工場でも最も繰り返し蒸し返される定義だからです。当初回答納期か最終変更納期か、オーダー単位か明細単位か、出荷時点か着荷時点か。

何が先か——接続、マスタデータ、そのあとに分析

接続とマスタデータはすべての土台にあり、分析はその上に載っていて、土台の価値以上にはなりません。そして一貫して過小評価される依存関係がマスタデータです。実行システムは工順に存在しない工程を指示できませんし、スケジューラーはこの10年のうちに誰かが実測した標準時間なしに順序を決められません。ですから稼働日を約束する前に数えてください。工順のない品目、キリのいい数字のままの標準時間、実際には存在するのにどのシステムにも登録されていないロケーション、重複した部品表の数です。

最後ではなく最初にスコープを切るべきもう一つの継ぎ目がERP連携です。ここでの難しさはコードではなく合意にあります。実績計上が双方にとって何を意味するのか、現場が入力するのかバックフラッシュで落とすのか。分割数量やオーダー分割がどう着地するのか。材料が動いた後の取り消しで何が起きるのか。不良（廃却）は標準原価に対してどこへ計上されるのか。どの答えも、これまで合意する必要のなかった部門間の意思決定です。

技術ロードマップにはめったに現れない、リードタイムの長い依存関係が二つあります。一つは、産出・停止・不良を個人名のオペレーターに紐づける実行記録です。これはドイツをはじめ欧州の多くで個人の業績を監視しうるシステムに当たるため、稼働開始前に従業員代表と交渉した労使協定が必要になります。承認には数か月かかるので、マスタデータと並行して1年目に着手してください。中身は短いものです。オペレーターの識別情報をそもそも保存するのか、誰が見られるのか、保存期間はどれだけか、レポートは設計上集計値にするのか。

もう一つは規制対象の生産に当てはまります。医薬品、医療機器、食品の多くでは、品質判定を記録または強制するシステムはバリデーション対象です。バリデーション計画、適格性評価、監査証跡、署名義務、そしてそれ以降の遅くなる変更管理が伴います。レポート、停止収集、スケジューリングはその線の外側です。ロット保留、可否判定、検査システムが使うモデルのバージョンは内側です。モジュールを買う前にスコープを決めてください。バリデーションはプログラム中で単一項目としては最長になることが少なくありません。

なぜAPSよりMESが先で、AIによる品質予測より品質データが先なのか

仕掛かりがどこにあるかについて昨日の前提しか与えられなければ、先進的な計画システムの出す順序はシフト開始前に手で並べ替えられます。計画担当者は数週間で表計算に戻り、「スケジューリングソフトが悪かった」という判定が下ります。悪かったのではなく、目が見えていなかっただけです。

実データの入力はスケジュールを実行可能にはしますが、そのまま回せるものにはしません。この隙間にAPSの失望のほとんどが住んでいます。完璧なデータの上に立ったスケジュールでも、目的関数を間違えていれば無視されます。納期で評価される工場で段取り時間の最小化を目指す、といった場合です。副次的な制約が欠けていても同じです。実際の順序は治工具、スキルマップ、共有される要員で決まります。凍結期間がない場合も同じで、連続的に再計算する最適化エンジンは、班長が画面を見るたびに新しい計画を差し出します。凍結期間を合意し、最適化の揺らぎはその外側でやらせてください。

品質予測も形は同じです。不良を予測するモデルには、発生した工程で記録された不良が、原因と、機械・治工具から材料ロットまでのプロセス文脈とともに必要です。

保全には、売り文句で飛ばされがちな区別があります。振動や電流波形の異常検知は故障履歴なしで動きますが、それはデータなしで動くことと同じではありません。運転領域全体をカバーする正常状態のデータが数週間分必要で、それがなければ損傷ではなく段取り替えのたびに警報を出します。加えて、対象としたい故障モードに合わせて取り付け・サンプリングされたセンサーが要ります。それでも分かるのは「いつもと違う」ことまでです。どの異常が意味を持ったかを知るには、故障モード付きの作業指示履歴が必要になります。

画面に合否を映すカメラも、それだけでは工場を変えていません。判定は、実行記録と品質記録の中でオーダー、ロット、モデルバージョンに紐づかなければなりません。だから外観検査は入口ではなく、後段の能力です。有限能力スケジューリング、APSのスケジュールが満たすべき条件、CMMSがどこで終わり予知保全がどこから始まるかについては、別のガイドで扱っています。

誰がプログラムを回すのか、そしてなぜ現場は実績入力を嫌がるのか

情報システム部門はパートナーであってオーナーではありません。情報システム部門がプログラムを持つと、連携とセキュリティに最適化し、そこは上手くこなし、定着のところで止まります。その系統には、オペレーターが画面を使うかどうかに責任を負う人がいないからです。オーナーの下にはキーユーザーが付きます。エリアごとに1人、名前を挙げ、工数を割り当てます。画面が何をどの順で聞くかを決めるのは彼らで、現場は彼らの言うことを聞きます。

定着の障害として語られるのはほぼ常に人です。実際の障害はたいていトランザクションの設計です。段取り替えの最中の実績入力を観察してください。手袋をしたまま、次のオーダーが待っています。停止理由を入れても目に見えて何も変わらないなら、その入力はシフトに課された税金であり、できるだけ後回しにされ、たいていは終業時に作り話をまとめて入れることで支払われます。入力が保全に通知を出し、シフトボードを更新し、次のオーダーの順序を変えるなら、それは仕事の一部になります。

良い入力設計は具体的です。機械のそばの端末、手袋のまま片手で操作できること、初期値はオーダーから引いてくること、そして機械種別ごとの短い理由リスト。分類体系を作り込んでも、実際に使われるコードは数種類です。トランザクションが仕事に合っていれば、教育はシフト中に機械のそばで済むほど短くなります。合っていなければ、座学を何時間積んでも直りません。教育を増やしてほしいという要望は、設計の問題を人の問題と誤診したものであることがよくあります。

教育計画で抜け落ちるものが二つあります。一つは訂正です。良品数を確定する操作は教えやすい一方、誤った数量を取り消す、あるいは違うオーダーに計上してしまった実績をほどく操作こそ、未習熟の利用者が本当の損害を出すところです。もう一つは、教育が一度きりの行事ではないということです。班長はオペレーターより多く必要としますし、新人、派遣、多言語の現場は継続的に入ってきます。

パイロットを工場全体へ——複製できるパイロットの条件

パイロットが展開に至らない理由は、最初から設計に組み込まれています。一番良いライン、古い設備は避ける、ベンダーが毎日常駐、マスタデータは手作業で整える。展開を前提に作られたパイロットは、代表的なラインで走り、少なくとも1台は扱いにくい設備を含み、ライン当たりの工数を記録します。その単位当たりコストだけが、展開計画に入れられる正直な入力値だからです。

終了基準と展開可否の判断日は、パイロット開始前に合意します。そして終盤はベンダー抜きで走らせます。この終盤について重要なのは長さではなく網羅性です。パイロットが通常運転中に失敗することはめったにありません。失敗するのは最初の月次締めです。数字をERPと突き合わせる段になって、誰かが不良の二重計上を見つけます。もう一つは停止明けの最初の立ち上げです。ゲートウェイは復帰したのに、バッファしていたカウントは戻ってこない。ですから網羅範囲を規定してください。突合を含む月次締めを1回、そのラインが流す全製品構成、計画停止と立ち上げを1回。多くの工場ではそれは2週間ではなく、1か月または1サイクル分です。

デジタル化の予算に含まれるもの、そして稼働後のランニングコスト

最も厳しく交渉される行はライセンスですが、結果を左右する行は別のところにあります。ERPと機械への連携、ゲートウェイやパネルからレトロフィットセンサーまでのハードウェア、マスタデータの整備、教育とそれが消費する生産時間、そして社内工数です。社内工数は最も頻繁に抜け落ちる行です。キーユーザー、オーナー、情報システム部門、ゲートウェイを取り付ける保全担当、切り替え時の生産ロス。これらの時間を誰も原価計算していないなら、ライセンスをどれだけ上手く交渉しても予算は間違っています。

物理工事は、日程の性質が異なる二つに分かれます。ケーブル敷設、スイッチのポート、制御系と業務系ネットワークの分離は、リードタイムの長い通常のエンジニアリングであり、生産と並行して進められます。機械の制御盤の中はそうはいきません。そこは隔離作業であり、ロックアウト・タグアウトと計画停止が必要で、多くの工場では通電中の盤を開けることが常時禁止されています。ですから接続工事の日程を実際に縛るのは、今年あと何回停止枠が残っていて、そのうちどれだけを保全がすでに押さえているかです。接続工事はソフトウェアの計画ではなく、保全カレンダーに対して計画します。

次にランニングコストです。どのプロジェクト予算にも入っていない一方、財務責任者が最初に聞いてくる項目、つまり4年目の費用です。サブスクリプションまたは年間保守は続きますし、産業用パネルやゲートウェイはオフィス機器より早く寿命が来ます。何より、ベンダーが去った後にシステムを回すのは社内の誰かです。マスタデータの維持、停止理由コードと工順の変更、ユーザー管理、各リリースの適用。稼働開始後12か月の改修は別枠で予算化してください。資金を投じる価値のある要望は、現場がシステムの言う数字を信じ始めてから初めて出てくるからです。

スマートファクトリー3年ロードマップの組み立て方

カレンダーは、依存順序だけでは足りないものを足します。各境界で誰が決めるのか、そしてお金と工数がどう配分されるのかです。1年目は、後から覆すと高くつく決定を片づけます。それを決めるのはプロジェクトチームではなくオーナーで、相手は財務、情報システム部門、従業員代表です。KPIの定義、マスタデータの構造、ERPとの継ぎ目、オペレーターの識別、そして規制対象工場ならバリデーションのスコープ。ライセンス支出に対して社内工数がここで最大になるので、通常のIT案件のような形をした予算は、その時点ですでに間違っています。工場が先送りしがちな項目を一つ1年目に入れてください。最大の電力負荷の計量によるベースライン確立です。これはモデリングではなく計装であり、エネルギー規格や監査の下ではしばしば裁量の余地がありません。

2年目への境界は日付ではなく判断です。現場がシステムの数字を無視するのではなく、その数字に反論し始めたときに越えます。ループを閉じるとは、班長や品質責任者が判断をルールに委ねることですから、そのスコープは権限が動く当事者と交渉します。支出は社内工数からライセンスと連携へ移ります。3年目は2年分の記録の上でモデルを使う層を手にしますが、その境界条件は所有者の有無です。能力ごとに、しきい値と再学習のスケジュールを持つ担当者を名前で決める必要があります。製品単位に按分したエネルギーはここに属します。按分には、最初の2年で作った実行記録が要るからです。

承認には停止条件を二つ入れてください。1年目のデータを現場が信用していないなら、2年目は始めません。そして、役員会がAI施策を求めたからといって3年目を前倒しすれば、このページの冒頭で述べた止まったプロジェクトができあがります。

続けるべきかどうかの判断——各段階のゲート基準

各段階には、懐疑的な相手に見せられる証拠を伴うゲートが必要です。接続の後は、収集された生産数が1シフト通しの手集計と、事前に合意した許容差の中で一致するか。最初の数値報告の後は、以前の表計算が横で維持され続けているか。それが静かに更新されなくなったとき、その数値は受け入れられたということです。

最初の実行系稼働に付くゲートで、ほぼ必ず飛ばされるものが一つあります。システムが無いとき、そのラインは何をするのかです。オペレーターが機械で実績を入力し、品質がルールでロットを保留するようになった時点で、スイッチ1台や連携1本の障害が生産を止めます。工場はクリップボードを単一障害点と交換したわけです。ですから縮退運転をまず定義して試験してください。端末が何をどれだけの間ローカルにバッファするのか、紙の代替手段は何か、システム無しでの運転を誰が承認できるのか、そして溜まった分を二重計上せずにどう入力し直すのか。稼働中のシフトで接続を抜いて試験します。試験していないフェイルオーバーは、稼働開始が生産トラブルに変わるごく普通の理由です。

実行記録が入った後は、1つのオーダーを、停止、不良、合意した識別レベルでの作業者まで含めて、人に聞かずに再構成できるか。計画系の前には、シフト開始時点の仕掛かりが正確か。単独のどのゲートよりも重要な傾向が一つあります。新しいラインを追加するたびに前と同じコストがかかっているなら、そのプログラムは方法ではなく個別施工を積み上げてきたということです。

Meta Smart Factoryはどこに位置するか

Meta Smart Factoryは、ここまでに挙げた層を個別のモジュールとして提供します。MES、MRP、APSから、品質、保全、倉庫、画像検査、そしてERP連携までです。モジュール構成はこの順序付けを購入可能にしますが、最初の購入はモジュールだけではありません。1つのエリアの、名前の付いた1つの制約に対する1つのモジュールと、その下の土台です。接続、マスタデータの整備、ERPとの継ぎ目、合意された定義。この土台が1年目の工数の大半を占め、しかもどの価格表にも載りません。ですからライセンスの中に含まれていると仮定せず、承認資料に独立した1行として計上してください。

難しい部分は、どのプラットフォームを選んでも残ります。数字の意味を確定すること、マスタデータを整えること、催促されなくてもオペレーターが最後まで入力するトランザクションを設計すること、そして何をやめるかを決めること。これらは共通の作業です。もし今そこにいるのであれば、製品デモよりも、あなたの制約に合わせた順序についての会話のほうが役に立ちます。