業務では100の結果を出すために、50の結果を確認してから次の50の結果を出すというプロセスを経るのと同じように、システムから出てきた結果が、どのようなプロセスを経てきたのかを提示してあげないと、インドネシアでのシステム導入プロジェクトはうまく進みません。
-
-
インドネシアのビジネス
インドネシア市場でのビジネスで重要な要素は価格とブランド、コネの3つと言われますが、必ずしもこれらを持ち合わせない日本人はどのように戦えばよいのか。これはインドネシアに関わり合いを持って仕事をする人にとっての共通の問題意識かと思います。
続きを見る
システム化を検討するときの理由
2018年現在、インドネシアへのシステム投資が検討されるようになったのは、インドネシア工場の重要性が高まったことにより、正確で迅速な情報管理と、情報の有効活用が求められるようになったからに他なりませんが、大きく分けて日本本社からの要請で現地のシステム化が検討されるケースとインドネシア現法で必要に駆られてシステム化が検討されるケースがあります。
日本本社の方針で
- 全社統一して運用負荷を減らしたい。
- 日本からデータを監視できるようにしたい。
- 日本のシステムににデータを連携したい。
- 日本のルール（在庫評価方法・帳票の表示項目など）と同じに合わせたい。
インドネシアで必要に駆られて
- データの正確性が低い。
- データの入力が遅い。
- データ入力の負荷が高い。
- 必要なデータ（帳票）が足りない。
- 入力したデータが有効活用されていない。
日本主導型とインドネシア主導型のシステム化の問題
日本主導型のシステム化の話が起こるのは比較的大企業であることが多く、日本本社からの依頼で導入の話が進み、日本の工場と同一システムを日本本社の情報システム部からの導入支援の元に導入しますが、高価なシステムを使いこなせない、本社導入者が帰国後に使われなくなる、入力される情報の精度が確保できない、マスタメンテナンスができないなどの問題が発生しがちです。
一方でインドネシア主導型のシステム化の話が起こるのは比較的中小規模の会社であることが多く、インドネシア工場独自でシステムを選定し、必ずしも業務全体を同一システムに統一させるとは限らず一部はEXCEL管理が残るケースが多いのですが、この場合二重入力が多発する、システム上の業務のつながりがない、個人に依存したシステムになってしまうという問題が発生しがちです。
システム導入の最初に現行業務を見直してどのようにシステムに落とし込んでいくかを決める要件定義というフェーズがありますが、インドネシアでは大きく3パターンに分かれます。
完全本社主導型はPerintah langsung（トップからの直々の命令）であり日本本社による仕様をインドネシアに展開する方法であり、現地多数決型はPengambilan suara（多数決）が基本ですが、部門間の力関係がシステムの仕様に影響するので現地の調整役となるキーマンが重要となり、ムシャワラ型（Musyawarah）は話し合いに基づく合議制で納得いくまで話合って全員一致を目指します。
インドネシア人スタッフが考えること
1990年代に世界中に名を轟かせた日本的経営の代名詞であった終身雇用，年功序列，企業別組合という三種の神器も、中国やアジア諸国の台頭で益々厳しくなるビジネス環境の中にあって今は昔という感が強いですが、いまだに日系企業に残る決定事項を敢えて明確にしない「あうんの呼吸」は、明確なJob Descriptionによる指示を当たり前とするアメリカスタイルのインドネシア人オフィスワーカーにとっては、日本人駐在員や日本本社とのコミュニケーション上の支障となっています。
おそらく海外の日系企業の現地スタッフが日本人に対して考えることはおおよそ同じではないかと思われ「なぜ自分達が納得いくまで説明してくれないのか」という言葉はインドネシアのシステム導入の現場で何度となく聞いてきた言葉です。
インドネシアに最適なシステム導入手法
自分も長年、とにかく異論を挟ませず標準業務フローとしてパッケージソフトをノンカスタマイズで導入してしまう、という半ば強引な手法こそがインドネシアのシステム導入の現場で最も有効だと信じて疑いませんでした。
しかし最近になっていくらシステムを標準形として受け入れてもらおうとしても、新業務フローと現行業務フローとの乖離が大きすぎると、出てきた結果に対してインドネシア人スタッフは懐疑的になり、心情的に受け入れられないというあたりまえのことに気がつきました。
例えば100の結果を出すために、現行業務では50の結果を確認してから次の50の結果を出すというプロセスを経ているにも関わらず、新システムでいきなり100の結果を出して、しかも微妙に結果が異なっていたりすると、仮に結果がより正確な数値に改善されていたとしても、インドネシア人スタッフは結果に懐疑的になります。
そこで新システムの機能ではいきなり100を出すことが出来るにも関わらず、敢えて0から50までは外部アドオンで現行業務と同じプロセスを実行させ、出てきた結果を確認してもらった上で、残りの51から100までを新システムの機能で実装します。
システム化の目的は現行業務の改善という意味があり、現行業務と全く同じ流れをシステムに置き換えても改善の効果は少ないわけですが、それ以上にシステムを使うユーザーの心情に配慮して「システムから出てきた結果がどのようなプロセスを経てきたのか見える」ことを優先し、パッケージのカスタマイズではなくアドオンによるユーザー支援機能の実装を重視しています。
手前味噌ではありますが、業務システム開発テンプレートHana Firstはこのような長年のインドネシアでのシステム導入の現場での試行錯誤の結果として生み出された、柔軟性の高いカスタマイズ前提の半パッケージ製品です。