紙からパイプラインへ:複数工場のプレキャストスラブ生産・倉庫・配送のデジタル化

プレキャストコンクリートメーカー、特にホロコアスラブ(中空スラブ)の生産者は、確かな物理プロセスの上に、非常に脆弱な紙の記録を積み重ねていることが多いものです。打設そのものは実績のある工程です——プレストレスストランド、押出成形またはロングライン打設、年によってほとんど変わらない養生スケジュール。壊れているのは打設の周辺にあるすべてです——同じプロジェクトの寸法データがスプレッドシートに3回入力される、誰も端材でまかなえるか確認しないままパネルレイアウトが手描きされる、グループ内の別工場が今週何を生産しているかまったく把握できていない工場。

本稿では、複数のプレキャストメーカー——同じホロコア工程を運用する4つの打設工場——向けに用いてきたデジタル化フレームワークを、一般化した形で紹介します。根底にあるパターン(堅実なプロセス、脆弱なツール、ERPNextかカスタムかという本質的な判断)は、この案件に限らず、ほぼすべてのプレキャストや受注生産型製造業のデジタル化案件で繰り返し現れるからです。

1. 摩擦は実際どこにあるのか

一般的な製造業向けソフトウェアのテンプレートから始めるのではなく、プレキャストメーカーの実際の生産伝票、倉庫用紙、配送記録をレビューすると、たいてい同じ一群のギャップが浮かび上がります。

• 生産番号とプロジェクトデータが手作業で管理され、複数の厚みを持つプロジェクトデータが各工程で繰り返し入力される。
• パネルレイアウトの計画は生産システムに入力される前に手作業で行われ、材料端材を減らすための自動最適化がない。
• 倉庫入荷と完成品在庫は分断されたスプレッドシートで管理され、プロセスの他の場所に既に存在するデータを再入力する必要がある。
• 配送スケジュールとトラック積載計画は手作業・スプレッドシートベースのままである。
• 品質記録(不適合報告書)は手書きで、不具合の原因となった生産記録へのリンクがない。
• 各工場が孤立して稼働しており、拠点をまたいだ共有可視性がない。ある工場から別の工場へ作業を移すには、共有可視性がないためゼロからすべて再入力する必要がある。

これらのどれも、打設プロセス自体を自動化する必要性を示しているわけではありません——労働力とクレーンに頼るプレキャスト生産を、PLC駆動に変える必要はこのギャップを解決するためにはありません。必要なのは、その周辺のワークフローをデジタル化し、受注から配送まで一貫してつなげることです。

flowchart LR
    A[受注と販売] --> B[生産計画と最適化]
    B --> C[倉庫と在庫管理]
    C --> D[配送とロジスティクス]
    B --> E[品質管理]
    D --> F[現場設置トラッキング]
    B --> G[施工図承認]
    C --> H[全工場横断レポートダッシュボード]
    D --> H
    E --> H

受注時にプロジェクト詳細を一度だけ入力し、その後の生産スケジュール、在庫台帳、配送計画、品質記録のすべてが、各引き渡し地点で再入力するのではなく、その単一のソースから引き出されるべきです。その上に置かれる全工場横断ダッシュボードは、紙や分断されたスプレッドシートでは構造的に実現できない唯一のもの——全拠点をまたいだリアルタイムの可視性——を経営陣にもたらします。

一つの機能だけは特別に触れる価値があります。この種のプロジェクトでは通常、単独で最も価値の高い項目になるからです。それが自動パネルレイアウト最適化です。端材ロスを最小化するように切断・打設の順序を組み、新しい材料を切る前に再利用可能な端材が既存在庫にないか自動でチェックする——これはまさに、手作業では退屈でミスが起きやすく、ソフトウェアには機械的に向いているタスクです。単純なビンパッキング型の最適化問題であり、研究プロジェクトではありません。

2. 本当の判断:機能一覧ではなくプラットフォームの土台

モジュール範囲に合意したあと、コスト・タイムライン・長期的な所有権を実際に左右する判断は、どの機能を含めるかではありません——現実的な2つの経路はどちらも同じ範囲を提供するからです。決め手となるのは、どの技術基盤の上に構築するかです。

オプションA — オープンソースERPプラットフォーム(ERPNextなど)の上に構築。販売・製造・倉庫を標準でしっかりサポートする成熟したプラットフォームなら、コアワークフローをより早く提供できます。一方でプレキャスト特有の部分——パネルレイアウト最適化、寸法図面、品質トレーサビリティ、複数工場レポート——は、その上で完全にカスタマイズされます。このようなプラットフォームに標準で付属するバックオフィス用インターフェースは、作業靴を履いた工場現場ではなく、オフィスでのデータ入力向けに設計されています。そのため、この選択肢を正しく実装するには、専用の現場・フロア向けWebアプリ——生産スタッフ向けのレーン・キャスティングベッド画面、倉庫チェックイン、ドライバー向けの配送・積載計画、現場技術者向けの設置進捗報告——と組み合わせ、プラットフォームとはAPI経由でやり取りしながら、基盤となる記録とビジネスロジックはプラットフォーム側が静かに管理する形にする必要があります。

オプションB — 完全なカスタム構築システム。サードパーティプラットフォームに依存せず、メーカーの正確なプロセスに合わせてゼロから構築します。設計とソースコードの完全な所有権、将来のカスタマイズに対する最大限の柔軟性、工場現場とモバイル利用に最も高速なインターフェースを得られる一方、構築期間は長く、価格も高くなります。

flowchart TD
    A[同じモジュール範囲] --> B{プラットフォームの土台}
    B -->|提供が速い プラットフォーム依存| C[オプションA オープンソースERPと現場アプリ]
    B -->|完全な所有権 構築期間が長い コストが高い| D[オプションB 完全カスタムシステム]

どちらのオプションも絶対的に優れているわけではありません——提供速度と長期的なプラットフォーム独立性の間の、正真正銘のトレードオフです。そして、これはスコープの詳細をさらに進める前に、まず決めておく価値がある最初の判断です。なぜならタイムラインと投資額の両方を大きく左右するからです。私たちがこれまでスコープしてきた同規模(4工場)のプレキャスト案件を大まかな目安として見ると、ERPNext基盤の構築は3〜4か月程度、完全カスタム構築は5.5〜7か月程度に収まる傾向があり、コストも同じ比率でついてきます——同じモジュール範囲であれば、カスタム経路はプラットフォーム基盤の経路よりも通常60〜80%程度高くなります。

3. より小さく始める:MVPという道

すべてのメーカーが最初から8モジュールのフルスコープにコミットしたいわけではありません。生産計画と最適化、倉庫と在庫管理の2モジュールによるMVPは、最もインパクトの大きい領域を先に押さえます——自動生産番号採番、レーン/スケジュール計画、パネルレイアウト最適化、そしてパネルの生産完了に合わせて自動更新されるリアルタイム・ロケーションレベルの在庫追跡です。レーン/生産スタッフと倉庫チェックイン向けの現場アプリはMVPに含まれます。まさにこれらのユーザーのために作られたMVPだからです。販売・受注、配送・ロジスティクス、品質管理、設置トラッキング、施工図承認、全工場横断ダッシュボードは第2フェーズで続き、その間は残りの業務が現行の紙・スプレッドシートのプロセスのまま稼働し続けます。私たちの経験では、MVPの範囲は、どちらのプラットフォーム基盤を選んでも、対応するフル構築のおよそ半分のコストとタイムラインに収まります。

4. AIが本当に役立つ場面と、まだ早い場面

自動パネルレイアウト最適化は初期構築に含めるべきです。ビジネスケースの土台となるモジュールだからです。第2階層のAI機能は、明示的に名前を挙げておく価値があり、同時に初日から意図的に作らないべきものです。

• 自動視覚品質検査 — 生産時点でカメラベースにより目視可能なパネル欠陥を検出し、品質記録に自動で写真証跡を添付する。
• インテリジェント文書検索 — 過去の生産・品質記録を自然言語で横断検索する。既存の紙archiveのデジタル化を含む。
• 予測インサイト — 十分な稼働履歴が蓄積され、パターンが意味を持つようになった段階で、スクラップ率、品質傾向、配送実績の異常パターンを早期に検出する。

最後の条件が重要です。予測型・パターン検出型の機能が価値を持つには、実際の稼働データが必要です。コアシステムがその履歴を生み出す前にこれらを構築することは、合成的な仮定に対して構築するに等しくなります。誠実な順序は、まずコアシステムを稼働させ、運用させ、その後に実際のデータが示すものに対して第2階層のスコープを決めることです。提案書で見栄えがするものに対してではありません。

5. ホスティング:デフォルトはクラウド、ポリシー要件があればオンプレミス

4工場、本社、現場デバイスにまたがるシステムは、どこか一箇所がサーバーを所有するメリットがありません——クラウドホスティングなら、標準的なインターネット接続を通じて、すべての工場とすべての現場ユーザーが同じ稼働中システムにアクセスでき、ハードウェア・電源・ネットワークの信頼性はプロバイダー側が担います。継続的なホスティングは、一回限りの開発投資とは別の、通常は月額の費用であり、サーバー容量・バックアップ・セキュリティ監視に応じてサイズが決まり、ディスカバリーフェーズで確定する実際のユーザー数とデータ量に応じてスケールします。この規模の導入であれば、現地通貨で月あたり数万円台前半程度が一般的な目安です。特定のデータ所在地要件やITポリシー要件を持つ組織にとっては、オンプレミスまたはハイブリッド展開が妥当な代替案であり、最初から除外するのではなく、ディスカバリーの場で取り上げる価値があります。

6. 実際の納品ゲートに沿って支払いを構成する

キックオフ、コアモジュールが機能的に完成しUAT準備が整った中間地点、UATサインオフとゴーライブ時の最終支払いという、実際の納品に紐づいたマイルストーンベースの請求は、カレンダーに沿って支払うのではなく、両者が進捗に対して誠実であり続けることを可能にします。ホスティングはゴーライブ以降、開発マイルストーンとは別に月次で請求されます。継続的な運用コストであり、開発マイルストーンではないからです。第2フェーズのAI機能は、実際に合意された時点で、同じマイルストーン構造の下でスコープされ請求されます。当初の固定料金に組み込まれるのではありません。

7. どのような企業に向いているか

このフレームワークは、確かな物理プロセスを脆弱な事務プロセスの上で運用している、複数拠点・受注生産・エンジニア・トゥ・オーダー型のあらゆるメーカーに適合します——プレキャストコンクリートメーカーが最も直接的な例ですが、精密加工、モジュラー建築、そしてプロジェクトデータが各引き渡し地点で再入力され、各拠点が他拠点の状況を把握できていないその他の工場にも同じ形が当てはまります。ERPNextかカスタムかという判断、MVPによる段階的導入という選択肢、そして「コアシステムを稼働させてから、その上に予測AIを構築する」という順序立ては、いずれもホロコアスラブに限らず一般化できます。

8. 始め方

生産・倉庫・配送のプロセスが複数拠点にまたがって紙と分断されたスプレッドシートのまま動いているなら、有用な最初の一歩は、一般的な製造業ソフトウェアのデモではなく、実際の帳票とワークフローに基づくディスカバリーセッションです。Simplicoは、ERPNext基盤の経路と完全カスタム経路の両方を、現場・フロア向けアプリ、パネルレイアウト最適化、全工場横断レポートを含めてスコープし、提供しています。

工場数、現在使用しているツール、実際に摩擦が生じている場所についてご相談されたい方は hello@simplico.net までお問い合わせください。