システム導入時に判るインドネシアの環境的特性 【アウトプットから機能を理解してもらい導入効果をイメージしてもらう】

インドネシア人業務担当者はWEBベースのシステムを好む傾向があるため、WEBによる情報の社内共有によって分業化、進捗状況の見える化を実現するすることが、業務システムの運用負荷を下げるための説得力ある提案となり、これはアジア諸国全般で当てはまる傾向かもしれません。

クライアントサーバーとWEBベース

インドネシアの日系製造業でシステムを導入を円滑に推進させるための重要なキーワードとして以下が挙げられます。

そしてこれを実現するのが「WEBによる情報の社内共有」であり、システム導入の際に最大のボトルネックとなるマスタメンテナンス作業と実績入力作業に大きな効果をもたらします。

またイギリスのBBCの調査で2014年の「世界で交通渋滞が酷いワースト10」でジャカルタが見事ワースト1のありがたくない称号をもらいましたが、このような土地柄では導入後のサポートのし易さが非常に重要になります。つまり基本はオンラインでのサポートで完結させオンサイトでのサポートの手間をかけないことです。

またまた話がずれますが、世の中には本来の機能としてはすばらしいにもかかわらず相手への訴求アプローチが十分でないため、相応の評価を得られていない商品がたくさんあると思いますが、そのような商品はちょっとした工夫・発想の転換によって大きな効果を生み出しうる潜在能力があると思います。

僕は業務システムのサブシステムがWEBベースであることはプリセールスやプロジェクトの成否を左右する重要なファクターだと思っているのですが、その理由は上記の重要キーワードを消化できるのがWEBの持つ特性だと思うからです。

インドネシア人担当者の特徴

デモでプロモーションする相手は主に日本人工場長とインドネシア人マネージャーであり、意思決定が日本人主導のケースもあれば、インドネシア人スタッフの意向を最大限尊重するケースもありますので、結局は両者にアピールするようなデモが必要になります。

アジアに赴任経験のある日本人なら東南アジアの人々のおおらかさを理解していますので、プロジェクトを円滑に進めるための手順を理解してもらうという視点でデモを行います。

逆にインドネシア人担当者にはシステム自体の機能を中心にデモを行い「シンプル」「多機能」「柔軟性（カスタマイズ）」という観点から、最終的に「現状業務がいかに楽になるか」をアピールします。

以下生産スケジューラーのデモ・導入の例で説明します。

機能を理解してもらうのに苦労する。

生産計画を作成するために必要なデータは何か？逆に言うとどのようなデータがないと生産スケジューラーが動かないのかをキチンと説明する必要があります。

まずは正確な受注情報（または製造オーダ）とBOM（品目情報と設備情報を含む）と在庫情報をインポートして「正確な生産計画」を作成され、次に最適化のための設定を行った上で「最適な生産計画」を作成される2段階のプロセスを説明します。

効果を理解してもらうのに苦労する。

会計システムや生産管理システムとは違い生産スケジューラーの効果が理解しにくいのはインプットとアウトプットが不明確であるからだと思います。

「正確な生産計画」を自動生成し、生産資源の最適化を実現する「最適な生産計画」を作成することができる、というのは工場経営にとって実際大きな効果だと思いますが、残念ながらこれだけだとインドネシア人スタッフから「Microsoft Projectと何が違うの？」という質問が来ます。

これが上述の「相手への訴求アプローチが十分でないため、相応の評価を得られていない」実例です。

よって相手に理解してもらえないのはデモする側に問題があると真摯に考えるべきであり、そのために有効なのはインプットとアウトプットをグラフィカルに製造の現場イメージで説明できることです。

インドネシア人担当者はアウトプットを重視する。

インドネシア人マネージャーはシステムで形のあるものとして何が得られるのかを非常に重要視します。そしてアウトプットが現在自分が使用しているフォームと限りなく近いものであることを要求してきます。

これが日本人担当者であれば同じ目的を達成できるのであればフォームにこだわない、という柔軟性があります。

生産計画があまり重視されていない。

実績主義で計画の重要性がそれほど高くないように感じます。詳細は前エントリー「計画と実績のリンク（製造指図の必要性）」に書いたとおりです。

運用スタッフが多忙で導入時のマスタメンテや実績入力が遅れる。

本来システム導入プロジェクトも業務の一環であるはずですが、Dailyの業務優先で「忙しい」を理由にマスタ作成や実績入力がなかなか進みません。出荷を遅らせないことが最優先であるため有る程度仕方のないことですが、そうばかり言っていてはマスタの準備や実績入力が進みません。

新しいことをやるのは手間がかかりますし、人間誰しも面倒なことに取り掛かるのに腰が重いのは万国共通ですから、相手が物理的心理的負担を感じないためにはどうしたらよいかを導入する側が突き詰めて考える必要があります。

現行システムを変えることへの抵抗。

サッカーでも「勝っているときはメンバーは替えない」と言われますので、現状オペレーションが回っている状態を変えたくないというのはある意味理にかなっています。

ただその「現状オペレーションが回っている状態」が本当に効率的なものかどうかについては疑問はもたない、持ちたくないというのが問題な訳です。カイゼンという言葉は非常に奥深いです。

生産スケジューラの導入のしやすさの基準

工場の生産管理業務のシステム化の進み具合は多種多様で、高額なERPシステムを導入し、MRPを回して購買オーダと製造オーダを発行し、実績入力を行うことでシステム内で予実管理出来ている稀なケースもあれば、ERPは導入済みだがMRPは使っておらず、ERPから必要な情報をExcelにエクスポートし、外で生産スケジュールを作成しているケースもあります。

生産スケジューラを導入するには部品構成表（BOM）や品目別の標準作業手順、や標準作業時間（能率）が必要であるため、当然ながらERPシステムのマスタがきちんと整備された工場のほうが導入しやすく、マスタはExcel管理されているものの分散化しており、情報を統合するのに一苦労するようなシステム化が遅れている工場は、導入準備に工数を取られます。

また製品点数や工程数が多く、リスケジュールした結果作業数が膨大な数になる工場は、一般的に生産資源に対する制約条件が多いため、最適と考える生産スケジュールに近づけるのに苦労しますが、製品点数や工程数も少なく、受注に対する生産能力が十分に確保されている工場では導入しやすいと言えます。

このような生産スケジューラ導入に必要となる最低限の基本情報は、導入前のヒアリングで得られるため、事前に導入プロジェクトの難易度を測ることができます。

プロジェクト開始後に発覚する組織内外の問題

しかし事前に製品情報や工程情報など、スケジューリング必要な基本情報を貰っていたとしても、プロジェクト開始後に判明する導入の難易度を上げる問題が出てくるケースがあり、その多くは組織上の問題に起因します

スケジューラの導入では営業部、生産管理部、製造部、購買部など社内業務フローで主体となる部署間で、今後は受注情報が生産計画に落とし込まれ、製造現場で作業を行い、それに必要な原材料の購買がどのように行われていくかというコンセンサス取られている必要がありますが、社内の意思決定が個人や部署の政治的意図によって押し切られたり、部署内の要求事項が多く横の連携が取れない縦割り組織の場合、プロジェクト開始後に必ずどこかの部門がボトルネックとなります。

また社内業務は社外の顧客や取引先、外注先との関係に影響されますので、サプライチェーンの制約が原因で商慣習が変更されるような環境では、スケジューリングに必要な情報が安定して貰えなかったり、フォーマットが変更されることで、システムの外部インターフェイスを頻繁に改修する必要が出たりします。

このように組織の業務はサプライチェーン全体の中でモノと情報を流すことで成立していますが、プロジェクト開始前に組織環境の現状は明確に文書化されているわけではないため、いざ蓋を開けたら想定外の問題が山積みだったという事態が起こりうるわけです。

総括