チャイナ・プラスワンの現場：日本工場とインド工場をひとつのERPで動かす

状況

愛知に本社工場を持つ中堅の精密部品メーカーを想像してください。自動車のティア1サプライヤー向けにバルブアセンブリを造り続けて15年。日本での生産は成熟し、消費税の運用も固まり、工場長はすべてのワークセンターを名前で把握しています。

そこで経営会議が決断を下します。顧客がチャイナ・プラスワンの調達体制を求めており、その行き先はインドです。18か月以内にプネ郊外に第二工場を開設し、同じバルブファミリーの一部をインドとASEAN向けに組み立てることになります。突如として2つの法人、2つの通貨、2つの税制度が発生し、COOからひとつの厄介な問いが飛んできました。

両方の工場をどうすればひとつのシステムで回せるのか。バックオフィスを二倍にせずに。

これが今、多くの日本メーカーが直面するクロスボーダーのシナリオです。インドで事業を展開する日本企業は約1,500社で、そのうちほぼ半数が製造業であり、国を挙げた目標は2029年までにインドへ5,000社とすることです。この流れは現実のもので、その背後にある基幹システムの選択が、第二工場を成長エンジンにするかコンプライアンスの悪夢にするかを決めます。

課題

陥りやすいのは、インド工場に現地で人気のあるツールを後付けし、本社がスプレッドシートで全部つじつまを合わせるやり方です。この道はすぐに行き詰まります。四半期のうちに三つの痛みが顔を出します。

第一にBOMが乖離します。愛知が部品構成を更新しても、プネが古いレシピで造り続け、原価差異は月末にならないと見えません。第二に税です。日本は国内売上に10パーセントの消費税を課しますが、インドは複数税率のGSTであり、インプットタックスクレジットという日本の勘定科目に相当しない仕組みを持ちます。第三に可視性です。COOは「来週、両工場で何個のバルブアセンブリを出荷できるか」という単純な問いに答えられません。二つのシステムが同じ言語を話さないからです。

より深い問題は、二つのシステムが二つの真実の源泉を作ることです。在庫数値が合わず、ロットの追跡が国境で途切れ、チャイナ・プラスワン戦略が本来もたらすはずの需要の統合視点はいつまで経っても現れません。会社が本当に必要としているのは、各法人が自らの税と通貨の下で独立して動きつつ、製品を定義する製造モデルだけを共有できる、ひとつのERPなのです。

実装の実際

名古屋のチームは、両法人を単一のERPの中に立ち上げ、それぞれを独自のデータ空間を持つ独立した組織として扱う道を選びました。同じアプリケーション、同じログイン画面、同じリリースサイクルですが、記録が混ざり合うことのない二つの明確に分離された法人です。日本法人は円と消費税で動きます。インド法人はルピーとGSTで動きます。両者は同じ画面、同じ承認フロー、同じ商品マスタの構造を共有します。

ひとつの共通製造モデル

基盤となるのは、製品の造り方を共通の言葉で記述する仕組みです。この基幹システムでは、BOM（部品表）は、順序付けられた一連の構成明細から定義された基準数量の完成品を造るための構造化されたレシピであり、各明細は商品と数量と単位を持ちます。BOMには参照欄があり、名古屋の技術陣はこれに図面番号を入れることで、プネのチームが全く同じ仕様で造れるようにします。両法人が同じアプリケーション内に存在するため、日本で洗練されたレシピは、構成を再入力することなくインド法人へ複製できます。

作業は製造オーダーとして流れます。製造オーダーは、元の場所から原材料を消費し、仕上げ先の場所で完成品を受け取る生産指示であり、完成品単位での要求数量を持ちます。ライフサイクルはDRAFTからCONFIRMED、COMPLETED、あるいはCANCELLEDへと進み、各書き込みの操作項目がその遷移を駆動します。愛知の計画担当もプネの計画担当も同じオーダー構造を使うため、視察に来たCOOはどちらの工場の生産ボードも翻訳なしで読めます。

制御された完了とロットの追跡性

複数工場の生産で最も難しいのは、在庫を正確に保つことです。オーダーが完了すると、システムは製造-out移動で元の場所から原材料を引き落とし、ロット管理対象の完成品については在庫ロットを検証または生成し、製造-in移動で仕上げ先の場所に完成品を受け入れます。決定的に重要なのは、完成品がロット管理対象に設定されている場合、ロットが割り当てられていないとオーダーを完了できないことです。システムは追跡不可能な在庫が倉庫に入るのを黙って許すのではなく、完了をブロックします。

自動車向けにバルブを売るメーカーにとってこれは重要です。インドでのリコールは、正確なロット、正確な部品バッチ、正確な製造オーダーまで遡れなければなりません。両工場が同じロットモデル、自動生成されるロット番号、先入れ先出しのための有効期限、検査留保やブロックのステータスを実行しているため、追跡性はどちらの工場で造られたかによらず一貫しています。

法人間の在庫移動

最終組立のためにサブアセンブリを愛知からプネへ出荷するとき、チームは在庫移動オーダーを使います。移動オーダーは、元の場所から仕上げ先の場所への在庫移動の意図を記録し、両者が異なることを要求し、作成時に在庫移動を発生させません。移動が実際に起るのはライフサイクルが進んだときだけなので、計画担当者は現在の在庫を歪めることなく、国境を越える出荷を数日前にステージングできます。各オーダーは担当者、配送方法、到着予定日を持ちます。これはまさに、複数国にまたがる運営に求められる規律です。

ひとつの台帳で二つの税の世界

インド法人は必要なGSTの税率構成を設定し、日本法人は消費税の設定を維持します。会計エンジンは明細ごとに設定された税率で税を計算するため、同じ仕訳のロジックがインド法人にはルピー建ての正しいGST産出を、日本法人には円建ての正しい消費税を生成します。並行するスプレッドシートも、期末の手動換算も、地域ツールの追加ライセンスも不要です。

結果

プネ工場が本格稼働してから二四半期以内に、会社は二つの工場が連携して動く仕方について測定可能な改善を報告しました。両法人間のBOMの差異はほぼゼロに落ちました。どちらも図面参照を組み込んだ同じレシピ定義から造るようになったからです。月末決算の所要時間は、経理チームが手作業で二つの切り離された在庫元帳をつき合わせる必要がなくなったため、約12営業日から8営業日未満に短縮されました。

コンプライアンス面では、インド法人は最初のGST申告をERPの税率適用済み明細から直接行い、日本法人は消費税のワークフローを変更せずに継続しました。かつて品質チームが紙の記録を頼りに丸一日かかっていたロットベースのリコール訓練は、それぞれの完成ロットが一つのシステム内で製造オーダーと構成ロットに紐づくため、数分で解決するようになりました。この規模の会社にとって、二つ目のツール、二つ目の連携プロジェクト、二つ目のサポート契約を避けたコストは、3年間で数千万円単位と試算されました。

戦略的な恩恵は節約額より大きかったのです。COOはついにチャイナ・プラスワン戦略が約束したもの、両工場の需要の合計、産出の合計、在庫の合計を、間に一枚のスプレッドシートも挟まずに見られる単一のダッシュボードを手に入れました。

デュアル市場移行の教訓

同じ道を検討するすべての日本メーカーにとって、三つの教訓が際立ちます。

製品の定義はグローバルに、税の定義はローカルに扱いなさい。BOM、製造オーダー、ロットモデルは両法人で同一にし、技術者も計画担当者も共通の言語で話せるようにします。税率、通貨、勘定科目は法人固有のままにし、各法人のコンプライアンスを保ちます。優れたERPは、まさにその境界線に沿って分割できるように作られています。

任意ではなく強制された追跡性を要求しなさい。納期の圧力の下でロットの割り当てをスキップできるなら、それはスキップされ、最初のリコールがその隙間を露呈します。正しいシステムは、ロット管理対象の製品にロットがないとき完了をブロックします。監査の下で持ちこたえるのは、それだけの挙動だけです。

希望ではなく意図に基づいて在庫を動かしなさい。国境を越える移動には、ステージングと承認と到着予定日が必要です。実際の在庫移動とは別に意図を記録する在庫移動オーダーこそが、貨物が輸送中のあいだも両工場の在庫数値を信頼に足るものに保つ仕組みです。

あなたのビジネスに合うか

このアプローチは、単なる二つ目の倉庫ではなく、二つ目の法人を追加するメーカーに適合します。インド工場の開設、合弁の設立、新市場向けの販売法人の分社化のいづれかを進めるなら、ひとつのシステム上の独立した法人というモデルはまさにあなたの状況のために設計されています。拡張が純粋に国内であれば、よりシンプルな単一法人の構成で十分です。

また、継ぎ接ぎのツールを使い果たしたチームにも適合します。経理チームが毎月最終週を二つのシステムの突合に費やし、品質チームが工場をまたいでロットを追跡できなくなっているなら、あなたはすでに二つの真実の源泉のコストを支払っています。独立した法人を持つひとつのERPへ統合することが、その支払いを止める方法です。

よくある質問

ひとつのERPで二つの法人を動かすと、データは混ざってしまうのでしょうか。

いいえ。各法人は、要求ごとに解決される専用のデータ空間を持つ独立した組織として動くため、親会社の法人と海外子会社の法人が互いの取引を見ることはありません。利用者は学ぶべきアプリケーションをひとつに済ませられ、記録は監査とコンプライアンスのためにきれいに分離されたまま保たれます。

同じシステムでGSTと消費税を同時に扱えますか。

はい。各法人が独自の税率と通貨を設定します。会計エンジンは設定された税率で明細ごとに税を計算するため、GSTを適用する法人はルピー建てのGST適用仕訳を、消費税を適用する法人は円建ての消費税適用仕訳を、手動換算なしで産出します。

構成部品が二つの工場間を移動するとき、ロットの追跡性はどう働きますか。

ロット管理対象に設定された各完成品は、番号、有効期限、検査留保やブロックなどのステータスを持つロットを与えられます。製造オーダーが完了するとき、システムは完成品を受け入れる前にロットを検証し、工場間の移動は在庫を動かす前に意図を記録する移動オーダーを通じて行われるため、追跡性は複数事業体間の越境にまたがって生き残ります。

重要なポイント

チャイナ・プラスワンの移行が報われるのは、両工場がひとつの真実の源泉の上で動くときだけです。BOMと製造オーダーのモデルを法人間で共有し、税と通貨はローカルに保ち、完了時にロットの追跡性を強制し、越境する在庫は移動オーダーでステージングしてください。これが、スケールする第二工場と、突合に溺れる第二工場の違いです。海外展開を計画しているなら、Kikan System は独立した法人、ひとつの台帳でのGSTと消費税、BOM駆動の製造オーダー、強制されたロット追跡を、ひとつの基幹システムで提供します。

両方の工場をひとつのシステムで動かし始めましょう

Kikan System は市場をまたいで拡張するメーカー向けに作られています。日本法人とインド法人をひとつのERPに立ち上げ、法人ごとにGSTと消費税を設定し、チームがデータを混ぜることなくBOM、製造オーダー、ロット追跡を共有できるようにします。無料プランは最大2ユーザーまで対応し、クレジットカードは不要なので、コミットする前に両方の工場をモデル化できます。/#get-started から始めましょう。

関連記事

• 実践的なGST対応ERPのインド購入ガイド
• 多段BOM管理で製造現場を正確に
• ひとつのシステムで法人間のデータを分離する