生産スケジューラーのデモの現場で直面する困難

本記事のポイント

誤解を恐れず書いてしまうと、インドネシアでのシステム営業ではシステムそのものの評価は二の次で、客とのコネや販社の実績や営業担当者の第一印象で決まってしまう。要は優れたシステムが売れるとは限らないし、売るという目的を達成するためだけならシステムの品質は重要でないとさえ言える。客側で何を導入したいかはっきりしていれば、あとは1回訪問して会社紹介、実績紹介、そしてデモを行い、「こいつらならまあなんとかするだろう」という印象を与えればそれで決まりである。

デモの出来はあまり関係ない、というより客はデモそのものをあまり見ていない。訪問してきた担当者と会社の印象が重要だと思う。

インドネシアでの生産スケジューラーのデモ

こう書くと私のようなSEの立場がなくなってしまう。「どんな凝ったデモやったってあんまり意味ないじゃん」ということになりかねないが、だからといって上記のような現状をどうこうできるわけでもないので、開き直って「粛々と」デモの質を上げる努力をするしかない。

インドネシアの工場でデモを行うときは、日本人責任者とインドネシア人担当者が同席する。そしてインドネシア人担当者にインドネシア語で説明しながら、要所要所で日本語を織り交ぜて決定権を持つ日本人担当者に訴えかける、というのが一般的なパターンである。

ここで重要なのがインドネシア人担当者から出やすい質問パターンをあらかじめデモに織り交ぜておくこと、質問が出たらポケットの引き出しから取り出すように「はい、これです」と目の前で実演できること。

ところが生産スケジューラーのデモはERPのデモに比べて違った特有の難しさがある。

インドネシアでの日本人SEの存在意義

随分暑苦しいことを言うようだが、インドネシアで日本人がわざわざSEをやる必要性というのは何だろうか?

営業には日本人は必ず必要である。日系企業を相手に営業するわけだから、決定権を持つ日本人担当者への営業は当然日本人じゃないと話にならない。

英語を共通語とするグローバルカンパニー(早い話が欧米系企業)にとっては営業担当者の国籍、母国語はあまり意味はもたないのかもしれないが、インドネシア日本人村社会での営業にはコミュニケーション能力の高い日本人が絶対必要である。

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

自分の首を絞めるようだが、インドネシアに日本人SEは必要ないと思う。受注を取るために日本人営業がマーケティング活動を行い、目星のついたプロスペクトにインドネシア人の技術者を連れてデモすれば客からの信頼は十分得られる。

もちろん営業にも多少の技術知識は必要だが、長い時間をかけて技術のお勉強をする時間があったら、リストマーケティングや接待ゴルフに精を出すほうが効率的であり仕事はとれるだろう。

こういう事情を踏まえた上で、インドネシアで敢えて日本人SEの存在意義を挙げるとしたら、客側に「日本人で技術に詳しい人が居るから何かあったときには日本語で質問できるだろう」という安心感を持ってもらえることくらいか。

この安心感をより強く印象付けるためには日本人がデモを行うことが効果的かもしれない。私はインドネシア語でインドネシア人担当者にもデモを行うが、自分なりに上出来と思われるデモができたとしても「インドネシア人の技術者はいないのか?」と必ず聞かれる。

要はインドネシア人はインドネシア語で質問したいし、日本人は日本語で質問したいのである。英語がほぼ通用し日本よりもグローバル化が進んでいる(と私が思っている)インドネシアでも、やはり「腐っても母国語」である。

何故スケジューラーのデモは難しいのか?

話を戻すが、ERPの場合は処理フローがだいたい決まっており、客側はERPが何であるか、どんなことができるか、どんなことができないかを売る側よりも良く知っている場合が多い。

客側で行っている日々の業務フローをERPで置き換えたらこれだけ楽になります、こんな情報が得られるようになります、こんな分析ができるようになります、というのを訴えかける。

想定外の質問「こんなことできるか?」と聞かれてもよほど難しいことでなければとりあえずは「標準システムではできませんがカスタマイズすればできるようになります」と答える。

そうすれば客側はそれ以上の回答をその場で求めることはできなくなり、「できません」という否定的な回答をしなくて済むのでデモが荒れることは少ない。

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

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

ERPとは違って「できないことはできない」のである。その結果デモが荒れやすくなります。これが第一関門。

第一関門をクリア、つまり客に「スケジューラーにはERPのような在庫管理やINVOICE発行などの機能はない」ということを渋々納得していただいてから、ようやくスケジューラー本来の機能についてのデモと評価が始まる。

客が「こんなことできるか」と聞いてきたら、仮にスケジューラーでできることだとしてもその場で実演できなければ「できない」のと同じである。

ERPは過去の実績データを元に現状分析するシステムだが、スケジューラーは数々のパラメータの設定を駆使して欲しい結果が出力されるようにリスケジュールを繰り返すシステムである。

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

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

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

スケジューラーのデモにはこの2つの関門が必ず立ちはだかる。これがスケジューラーのデモが難しい理由である。

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

上記2つはお客との対人関係が絡む難しさだが、スケジューラーのデモが難しい理由はスケジューラー自体のシステムとしての性格にある。

ERPの場合、前にも書いたとおり「実績データを下に現状分析を行うシステム」なので、当たり前だがシステムからの処理結果は正しく筋の通ったものでなければシステム自体の信頼性に影響する。

ところがスケジューラーは少し違う。「パラメータの設定を駆使して欲しいスケジュール結果に近づけるべくリスケジュールを繰り返す」システムであり、計画パラメタ、マスタ、オーダなどにあるプロパティの数が非常に多く、スケジュール結果に影響を及ぼす要素があまりに複雑である。

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

プロパティの設定によって完璧に最適化されたスケジュール結果を得られるというものではなく、あくまでもスケジュール結果にある傾向を与える程度に過ぎない。

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

最適化とは

スケジューラーのデモで一番よくある誤解は「あんたのシステムは自動的に我々の工場にとって最適なスケジュールを組んでくれるんでしょ?」というもの。

要はシステムのAI(人工知能)エンジンか何かが事前に設定した生産資源パラメタとオーダを見て、何が最適なのかを判断して生産管理担当者の望みどおりのスケジュール結果に導いてくれるというもの。そんなことができるわけがない。

最適化を公約数をとって表現するとすれば「キャパオーバーしないように、納期遅れもしないように、稼働率を100%にキープした生産計画」といったところだろうか。

特にインドネシアのような今現在非常に景気がよろしい地域ではライン停止が一番よくない。受注に対して材料在庫(絶対量)と購買オーダ注残(増減量)を見ながらライン停止が発生しない順番で製造指図を発行することが重要になる。

「最適化って何?」という質問は「世界で一番おいしい食べ物は何?」という質問と同じである。当然ながら人それぞれ答えは違う。「何が最適なのか」は人、時、場所によって異なり、リスケジュールを行う時点で最適なスケジュール結果を頭に思い描けるケースはほどんどない。

スケジューラーに出来ることは、今現在の製造現場にとって「何が最適なのか」を探す手助けという程度のことだけであり、実は非常に慎ましやかなシステムなのだと思う。