インドネシアで生産スケジューラの営業と導入を行う際のポイント

インドネシアでの生産スケジューラの知名度はまだまだ低いですが、金型や人員など副資源の日別負荷計算や、それらを制約条件とした機械など主資源の生産スケジュール作成という、高額なERPパッケージにも出来ない生産管理業務のコアの部分に対応しています。

インドネシアでの生産スケジューラのプリセールス

インドネシアで生産スケジューラAsprovaという、製造業向けアプリケーションソフトの技術営業をしていますが、このソフトはインドネシアではまだ知名度が低いため費用対効果をイメージしにくく、相手が否定から入ってくるとまでは言わないものの、プレゼンやデモの際にはだいたいがマイナスからのスタートになります。

日々こんな風に言われていれば営業トークも卑屈になりがちです。

ところが生産スケジューラには、高額な生産管理パッケージシステムにも出来ない2つのことが出来ます。

実際のところこの2つこそが製造業の生産管理業務のコア部分にあたると言っても過言ではなく、本来なら『それを生産管理パッケージよりもゼロ一桁安い金額で導入できるんで滅茶苦茶評判いいんですけど知らないんですか？』『圧倒的にコスパいいのに、こっちやらないなんて珍しいっすね』くらいの言い方してもおかしくないわけです（実際はもっと丁寧な言い方しますが）。

ただ私は生産管理パッケージ導入の成否はマスタと在庫の精度だと考えており、これらの情報が正しくなければ生産スケジューラの導入も難しいというのが前提の話です。

中国に『鶏を叩いて犬を叱る』という鶏が可哀そうな故事がありますが、生産スケジューラの場合は若干あてこすりが入った営業、よく言えば引きの営業をします。

インドネシアにおける日本人技術者（SE）の存在意義

インドネシアの工場でシステム営業を行うときは、お客様側からは日本人責任者とインドネシア人担当者が同席することが多く、インドネシア人担当者にインドネシア語で説明しながら、要所要所で日本語を織り交ぜて決定権を持つ日本人担当者に訴えかけるというのが一般的で、インドネシア人担当者から出やすい質問パターンをあらかじめデモに織り交ぜておくことで、質問が出たらポケットの引き出しから取り出すように「はい、これです」と目の前で実演できる準備が重要になります。

ここでインドネシアで日本人がわざわざSEをやる必要性はあるのかという問題意識が出てくるわけですが、まず営業には日本人は必ず必要で、日系企業を相手に営業するわけですから、決定権を持つ日本人担当者への営業は当然日本人でないと話にならないし、よほど英語を共通語とし国籍や母国語が意味をもたないグローバルカンパニーでない限り、インドネシア日本人村社会での営業にはコミュニケーション能力の高い日本人が絶対必要だと考えます。

それではSEはどうか？はっきり言って技術力の高いインドネシア人は山ほどいますし、むしろインドネシアで優秀な日本人SEを探すより、日本人より能力の高いインドネシア人SEを探すほうが簡単であり、インドネシアの日本人SEには必然的に営業能力が問われることになります。

ただの技術屋ならインドネシア人のほうが優秀で安いので、私見ですがインドネシアに日本人SEは必要ないと考えています。

受注を取るために日本人営業がマーケティング活動を行い、目星のついたプロスペクトにインドネシア人の技術者を連れてデモすればお客様からの信頼は十分得られるわけであり、もちろん営業にも多少の技術知識は必要とはいえ、長い時間をかけて技術のお勉強をする時間があったら、リストマーケティングや接待ゴルフに精を出すほうが効率的であり仕事はとれるはずです。

こういう事情を踏まえた上で、インドネシアで敢えて日本人SEの存在意義を挙げるとしたら、お客様側に「日本人で技術に詳しい人が居るから何かあったときには日本語で質問できるだろう」という安心感を持ってもらえることくらいであり、この安心感をより強く印象付けるためには日本人がデモを行うことが効果的かもしれません。

私はインドネシア語でインドネシア人担当者にもデモを行いますが、自分なりに上出来と思われるデモができたとしても「インドネシア人の技術者はいないのか？」と必ず聞かれ、要はインドネシア人はインドネシア語で質問したいし、日本人は日本語で質問したいのです。

英語がほぼ通用し日本よりもグローバル化が進んでいるインドネシアでも、やはり「腐っても母国語」です。

インドネシアで知名度の低い生産スケジューラを理解してもらう際の苦労

生産管理システムの場合は処理フローがおおよそ予測できるものであり、お客様側は生産管理システムが何であるか、どんなことができるか、どんなことができないかを売る側よりも良く知っている場合が多いため、生産管理システム導入後には日々の業務フローはこうなりますよ、こんな情報が得られるようになります、こんな分析ができるようになります、というのを訴えかけることになります。

想定外の質問「こんなことできるか？」と聞かれてもよほど難しいことでなければとりあえずは「標準のパッケージではできませんがカスタマイズを入れるかサブシステムをアドオンすればできるようになります」と答えることができるため、お客様側はそれ以上の回答をその場で求めることはできなくなり、「できません」という否定的な回答をしなくて済み、デモが荒れることは少ないです。

ところがインドネシアでまだまだ知名度が低い生産スケジューラのデモの場合はそうはいかず、そもそも「生産スケジューラって何？」からはじまるため、何ができて何ができないかを説明する必要があります。「生産管理システムと何が違うの？」「在庫の管理もできるんでしょ？」「標準装備の帳票がいっぱいあるんだよね？」などの質問は「たぶんスケジューラは生産管理システムと似たようなもの」という前提で発せられるものです。

「在庫管理もできるんでしょ？」「標準のP/O（発注書）とINVOICEのフォーマットを見たい」と言われても、本来そんな機能はない、というよりそういう目的のためのシステムではないので「できない」または「システムの目的が違う」としか答えようがなく、生産管理システムとは違って「できないことはできない」とはっきり言わざるを得ません。

結果としてデモが荒れやすくなるわけですが、この第一関門をクリア、つまりお客様側に「生産スケジューラには生産管理システムのような在庫管理やINVOICE発行などの機能はない」ということを納得していただいてから、ようやく生産スケジューラ本来の機能についてのデモと評価が始まります。

生産管理システムは過去の実績データを元に現状分析を行うシステムですが、生産スケジューラは数々のパラメータの設定を駆使して、欲しい結果が出力されるようにリスケジュールを繰り返すシステムであり、お客様側が「こんなことできますか？」と聞いてきたら、仮に生産スケジューラでできることだとしても、その場で実演できなければ「できない」のと同じです。

「ASSYで組み込まれる部品は1日前には完成させておきたい」「メインの成形機で製造するがキャパが一杯になったら違うサブの成形機に割り付けたい」「プレス機が壊れた場合の対処法のデモをして欲しい」「段取りを減らすために同じ品目はまとめて製造したい」「実績を入れるときNG品についてはどんな対処をするの？」などなど、日々現場で実際に起こっている事象への対処法を「今、この場であんたが売り込もうとしているそのスケジューラーでデモしてみろ」と要求されます。

ここまできてはじめて生産スケジューラのデモとしてお客様側と弊社との間でキャッチボールが成立したことになり、まさに今ボールがこちら側に投げられて手元にある状態です。

ここでお客様のミットに直球ど真ん中を返すか、スライダーで変化させるか、大暴投でワイルドピッチになるか、敬遠フォアボールを選ぶか、この決定的な大事な場面のために事前にプロジェクトファイルへの仕掛け作り、デモのシュミレーションをすることになるのですが、現実には「隠し球で一塁走者タッチアウト」というケースが一番多く、これが第二関門になります。

生産スケジューラのデモには、普通この2つの関門が必ず立ちはだかり、これが生産スケジューラのデモを難しくしています。

生産スケジューラのデモが難しい最大の理由

上記2つはお客様との対人関係が絡む難しさですが、生産スケジューラのデモが難しい最大の理由は、生産スケジューラ自体のシステムとしての性格にあります。

生産管理システムは「実績データを下に現状分析を行うシステム」であるため、システムからの処理結果は正しく筋の通ったものでなければシステム自体の信頼性に影響しますが、生産スケジューラは「パラメータの設定を駆使して欲しいスケジュール結果に近づけるべくリスケジュールを繰り返す」システムであり、計画パラメタ、マスタ、オーダなどにあるプロパティの数が非常に多く、スケジュール結果に影響を及ぼす要素が非常に複雑です。

割付き資源を決定する評価値の算出プロセスにも数多くの要素が絡むため、プロパティの重みを「正しく」設定しさえすれば必ずしも望みどおりの最適化されたスケジュール結果が得られるというわけではなく、あくまでもスケジュール結果に特定の傾向を与える程度でしかありません。

だからなかなか思い通りのスケジュール結果に導くことが出来ず試行錯誤する、これは暴れ馬の調教みたいなものです。

生産スケジューラのデモでよくある誤解は「あんたのシステムは自動的に我々の工場にとって最適なスケジュールを組んでくれるんでしょ？」というもので、要はシステムのAI（人工知能）エンジンか何かが、事前に設定した生産資源パラメタとオーダを見て、何が最適なのかを判断して、生産管理担当者の望みどおりのスケジュール結果に導いてくれるというものですが、そんなことができるわけがありません。

生産計画の最適化を最大公約数的に表現すれば「キャパオーバーしないように、納期遅れもしないように、稼働率を平準化した生産計画」と言えるのかもしれませんが、インドネシアのように需要変動、為替変動、物流網の混乱などの影響を受けやすい国で一番問題となるのは、原材料不足による設備のライン停止であり、受注に対して原材料在庫（絶対量）と購買オーダ発注残（増減量）を見ながらライン停止が発生しない順番で製造指図を発行することが重要になります。

「最適化って何？」という質問は「世界で一番おいしい食べ物は何？」という質問と同じく人それぞれ答えは違うわけであり、「何が最適なのか」は人、時、場所によって異なり、リスケジュールを行う時点で最適なスケジュール結果を頭に思い描けるケースはほどんどないため、生産スケジューラに出来ることは、今現在の製造現場にとって「何が最適なのか」を探す手助けをすることと言えるのかもしれません。

部分最適化と全体最適化

生産スケジューラでは工場の中の工程の流れを一気通貫で見える化することができるので、工程単位ではなく全体最適化を考えるのに役立ちます。

生産管理システムは工程ごとに管理を分けている場合が多いですが、これではリードタイムを短縮するのに限界があります。各工程が工場内で工程ごとに仕切りがあったり建屋が分かれていたりすると、工程間の在庫は山積みとなり生産リードタイムが長くなります。

工程間を隔てる壁こそが、モノの流れと情報の流れを滞留させ、リードタイムが緩くなり仕掛在庫が増える要因であり、生産工程を串刺し状につなげ、生産に流れを作ることの重要性が判ります。

生産スケジューラによって材料の所要量、工程への投入タイミングを明確にすることで、各工程間の在庫が削減されます。

オーダが入ってくるとすぐに生産スケジューラで納期からバックワードに生産スケジューリングし、着手日、原材料の確認をして生産スケジュールをFIXすることでJust in Timeな生産スケジュールを作成します。

特急オーダはフォワードでリスケジュールすることで、最短でいつ生産が完了するかが確認できるので納期回答が迅速に可能になります。

直近の納期のオーダはフォワード割付で納期に間に合うかどうかを確認、遠くの納期のオーダはバックワード割付でいつ着手すればよいか、いつまでに材料を揃えばよいを確認します。

好景気時と不景気時のスケジューリング方向

経済成長のど真ん中にあるインドネシアのように好景気時は在庫削減とかリードタイム短縮よりも、スループットの増大が最大の課題になります。

ラインが空いていればとにかく手短なオーダを突っ込みたいところですが、 生産スケジューラを活用して現有資源でのキャパ最大化をシュミレーションできます。

一方、先のリーマンショックや中国経済の需要鈍化により、インドネシア国内製造業に対する需要が低下したときに、製造現場はオペレータが忙しいフリをするので無駄な動きが出来やすいです。

生産スケジューラがあれば、実際のところどのくらい忙しいかが論理的に解り、暇なら余計なものを生産しないで別の仕事をしてもらったほうがいいという判断がつきます。

2013年に入りインドネシアでは労使交渉が激しくなり労働者デモが頻発するようになりました。デモが発生すれば生産はストップし納期は遅れ、取引先に損害を与えることになります。

不測の事態を想定して事業継続の視点からBCP（Business Continuity Plan）を準備すると同時に、スケジューラに起きてしまった事象を反映させリスケジュールを行なうことにより具体的な対応策を考えることができます。

生産スケジューラ導入直後に起こる納期遅れ

ERPのMRPによって生成される製造指示を元に動いていた現場に「生産スケジューラが生成した製造指図を元に製造してください」と言ったら製造現場は大ブーイングになります。

インドネシアでの実例ですが、SAPから初工程→第2工程→最終工程の3つの製造指図を発行している製造現場に、最終工程納期を基準にスケジューラが生成した製造計画を導入し、双方に製造実績を入れたところ後者は納期遅れで真っ赤になりました。

スケジューラ導入当初は納期遅れだらけの真っ赤っかなガントチャートになりますが、これはあくまでもリードタイム短縮化の過程であると考え、無視する精神力が必要になります。この生産スケジューラのパラメータをチューニングして、製造リードタイムを段階的に短くしていくことも可能です。

生産スケジュールに悪影響を及ぼすリスケジュール前後の要因を意識する

生産管理システムの機能の中で、MRPやスケジューラなど計画系の機能は、現場で運用するにあたって難易度が高いと思うのですが、その一方でシステム化が遅れているインドネシアでも、スケジューラがキチンと運用されている工場は実際に存在しています。
ライン（機械）の数が多いほど、サイクルタイムを品目別ライン別に管理するのは大変なので、ライン単位の標準負荷を元に負荷計算を行うケースが多いと思います。

今キチンと整備されていない品目ごとライン単位のサイクルタイムを整備するより、まずはライン単位の標準負荷をスケジューラのマスタにセットして、負荷あふれが発生しないリスケジュール結果を得ることからはじめます。

生産スケジュールに悪影響を及ぼす要因は、リスケジュール前後にあります。

つまりリスケジュール前の要因を克服して100%正確なデータに基づいて理論的に正しいスケジュールが出来たところで、リスケジュール後にも悪影響要因がある以上、どっちみち誤差が発生するわけです。

大事なことは製品の作り漏れがないよう出荷スケジュール（受注オーダ）を正しく取り込むこと、出荷ロットと製造ロットが違う場合はMPS（基準生産計画）を正しく取り込むこと、末端親オーダと子品目の製造オーダの紐付きを意識することであり、これさえ守っていればマスタの間違いは運用しながら修正することができます。

受注と製造ロットの紐付きを意識する

工程間のロットが違うと、スケジューラ導入開始当初にシステム上のロットを現品の動きに合わせることが難しくなり、ガントチャートで全体感を見たときに、現場の動きと乖離します。

実績数量のみ入力した状態

ましてや、計画と実績の差をスケジューラが自動補充（需給調整1対1）してしまうとトレースはほぼ不可能になりますし、現場の動きとシステム上のロットの紐付きをマッチさせるのが難しくなります。

実績計上時に実績数量のみ入力してリスケジュールすると、計画期間内で計画数量との差異分を製造するのに必要な時間分ラインを占有します。

よって計画数量に満たないまま製造完了する場合は実績数量だけでなく実績取得日を入力し、ステータスを完了させることで、計画期間内に占有されたラインを解放します。

実績取得日なしでステータスのみ完了した状態

実績取得日なしにステータスだけ完了させると、スケジューラが何時から何時までに割り付けたら良いのか判断できず未割付になりますが、製造完了しているのであれば計画期間に影響を及ぼさないという意味では問題ありません。

受注オーダに対して製造オーダを１対１で割り付けると現品とシステムのマッピングがしやすいですが、それが難しければ受注オーダからMPSを作成しMPSから1対１で割り付ける、いずれにせよスケジューラのロットNO（作業コード）を現品票に記載して、システムと現品を一致させる必要があります。

オーダ別の製造指図とライン別の差立表と生産スケジュールの目的の違いを意識する

「スケジューラが運用される」ということは「生産スケジュールをシステムから出力する」ということであり、生産スケジュールは製造現場のホワイトボードにライン単位で貼り付けられると差立表になり、製造品目ごとに投入品目を記載すると製造指図になります。

生産スケジュールの出力形式は縦横の2通りしかなく、縦書（縦軸が日付）の差立表形式なら帳票作成も簡単ですが、横書（横軸が日付）のタイムテーブル形式なら帳票作成の難易度が上がり、現場の実績収集の単位が時間単位かシフト単位かに合わせて1日の計画数量を、生産能力に応じて按分表示する必要があります。

このようにアウトプットの形式が異なるのは、生産管理システムは工程ごとの数量管理を重視し、生産スケジューラはラインごとの時間管理を重視するという目的の違いがあるためです。