インドネシアで『使えるシステム』と『使いやすいシステム』

生産管理システム導入プロジェクトの成功とは、スケジュールどおりにプロジェクトが完了し、当初の要件どおりに『使えるシステム』が動くという2つが満たされることで、『使えるシステム』に盛り込めなかった機能や帳票、UI/UXの変更は、導入後サポートとして有料で行うことで、より『使いやすいシステム』に改良していきます。

よくあるシステムと現場オペレーションの乖離（GAP）

システムと現場オペレーションの乖離（GAP）については、ある程度運用でカバーするという発想がないと、生産管理システム導入プロジェクトはうまくいかないのですが、インドネシアで業務システムを導入する際に発生しがちなGAPとして、私が過去に経験した中では以下のようなものがありました。

• 事例1
  工場での製造実績の入力は生産管理部スタッフによって翌日朝10:00に行われる一方で、夜勤の現場では完成即出荷しているため、システム上製品在庫不足で出荷伝票（Surat Jalan）が発行できない。
• 事例2
  商社が商品を仕入れる場合、モノは到着していてもインボイスが未着であればシステム上仕入登録が出来ないため、入荷済みの商品がシステム上在庫化されず出荷処理ができない。
• 事例3
  現場では翌日出荷分の出荷指示は前日に出力して前準備しておくのが普通だが、システム上出荷指示が在庫引当を前提としている場合は、在庫不足のため出荷指示が出せない。
• 事例4
  受注100個に対して20個の出荷指示を出した時点で、受注済み未出荷指示残として80個を把握したいが、システム上は出荷完了処理が終わるまで受注残0個の状態で、出荷完了処理が終わってはじめて受注残80個が把握できる。
  • 受注:出荷指示＝1:1
  • 受注:出荷完了＝1:N

  「受注 > 引当 > 出荷指示 > 出荷完了」というシステム処理の流れの中で、受注と出荷指示が1対1の分割しかできないのは、システム上正しい動きだとしても、運用上不都合が生じる。

• 事例5
  工場で材料を仕入れる場合、仕入先から月まとめでインボイスが翌月に到着する場合、当月内にインボイスNOが判明しないので入荷即投入されて当月製造原価化している材料に対するインボイス登録ができず、原価計算対象受払が生成されない。
• 事例6
  受注登録から出荷処理してインボイス発行という一連の処理をシステムで行なう中で、月末締処理前に各種の修正作業が必ず発生するが、この修正作業が終わらないと実地棚卸をシステムに反映出来ない。
• 事例7
  現品票のバーコードを読ませることで材料払出と戻入処理を行い、NGや別管理品発生のたびに実績入力し現品票貼付けるなど、システム上で想定したフローに現場が付いていけないケースがある。
• 事例8
  実地棚卸で実績入力に間違いが発覚し、月中の生産実績に遡って修正を行おうとしても、ロットが既に客先まで流動している場合には、川下のインボイスや出荷伝票から順番にキャンセルする必要があるが、それに伴いインボイス番号や出荷伝票番号が新たに採番され、その結果客先や取引先のドキュメント管理に影響を及ぼすため修正が出来ない。

『使える』と『使いやすい』の定義

インドネシアの日系製造業は、中国やタイに比べて圧倒的に業務フローのシステム化が遅れており、近年になってExcelによるマニュアル運用を業務システムに置き換えようという動きがようやく出てきました。

『システムが使える』または『システムが使いやすい』の私の定義は以下のとおりです。

『使える』があってはじめて『使いやすい』があるのであり、その逆は有り得ません。

このようなお叱りの声も聞こえてきますが、業務がシステムで回るというレベルに到達するには、導入する側にもされる側にも結構なエネルギーが必要になります。

システムを使えるように導入するには？

誰でもお金を払ってシステムを導入すると決めたら、普通は「プロジェクトが成功するだろうか」と不安を感じます。そもそも「プロジェクトが成功する」というのは以下の2点に集約されます。

システムの使いやすさをプロジェクト期間中に追求するのは限界があるため、機能やレポートの種類と数からある程度の線引きをした上で、それ以上の『使いやすさ』は保守期間に有料でやらせていただけるようお客様を納得させることが、インドネシアでITの仕事をする日本人の大きな役割と言っても過言ではありません。

計画期間内に完了するか

期間内に完了するかどうかはシステム導入時の問題です。システムのカットオーバー（インドネシアではGo Liveと呼ぶことが多い）は年度初めの1月や4月にあわせることが多いのですが、そこに間に合わないと旧システムとのダブルインプットが必要になるケースもあるので、お客様に負荷がかかり業務のための時間が奪われて機会損失を生みます。

スケジュールが遅延する原因を挙げてみると、

パッケージソフトの場合はタスクがほぼ決まっているのでタスクの計上漏れというのはあまり発生しないのですが、開発中心のプロジェクトの場合には、工数見積もりミスが発生し得ます。

システム導入のステップとしては、お客様（発注側）が情報提供依頼書（Request For Information）と通して業者を絞り込み、提案依頼書（Request For Proposal＝RFP）をお客様からいただいて、RFPに基づいて提案書と見積もり作成となりますが、この段階でユーザーのリクエストは100％ヒアリングできていないのが普通なので、一旦工数を「えいや」で見積もらざるを得ないのが現実です。

そのため実際に導入が決まり、最初の要件定義をはじめようとした段階で、予想外に例外処理が多く工数が増えることがあります。

またインドネシアを含むイスラム圏での断食期間中は、お客様のスタッフは家族と一緒に断食明けを行うために早めの帰宅が原則であり、無理な残業を強いることもできません。さらにインドネシアでは労働者によるデモのため、工場が稼働出来なくなるなど不測の事態も発生します。

『使えるシステム』が完成しているか

これはシステム導入が終わった後の稼動後の問題であり、言い換えれば『システムで業務がキチンと回るか』ということであり、パッケージソフトを採用する際に「自社業務とパッケージがマッチするか否か」を慎重に検討していればある程度リスク回避できます。

システムがキチンと動かない原因はさまざまです。

パッケージシステムはいろんな会社で使えるように最大公約数的に機能を持たせますので、80％がFITしても20％はGAPが出ます。ただその20％が業務の根幹にかかわるGAPだった場合、大きな投資損失を生む可能性があります。

ある会社で移動平均単価計算と先入先出法にしか対応していないシステムを導入したものの、実際の業務は日本からの指示で総平均法を使うことになったので、システムがそのまま使えなかったケースを見たことがあります。

また現品票でロット管理を行うつもりでも、実績入力が正しいロットに対して行われなかったり、ロットが見つからないために入力を勝手にストップしていたり、棚卸しの精度が悪く現品票のないロットが現場に散らばっていたりなど、インドネシアの工場では普通にあることです。

理論先行型で新しいビジネスフローを設計し、それにあうようにアプリケーション設計を行うと、稼動後に現場がついていけないことになりかねません。

リスク回避のためには

実はシステム導入スケジュールの中で遅延を発生させやすいポイントと要因はだいたい予測がつきます。

これはスケジュールを作成する際に、マスタースケジュールとして月次から週次、日次までブレイクダウンし、そして縦軸にタスクを細かく分解していくと、タスクと時系列が縦横で見られるのでイメージが湧きやすいです。

スケジュール遅延となりうる要因ですが、これは導入サイドの問題とお客様側の問題があります。

この全体スケジュールの中の青い部分が、ユーザーリクエストとシステムの標準仕様の間でFitする部分とGapのある部分を洗い出し、業務フローとアプリケーションフローを定義していく要件定義の部分です。また赤い部分が、遅延が発生しやすく次フェーズのタスクを押し出してしまう部分です。

システムを導入するお客様の状況は、工場の新規立ち上げ、Excelによるマニュアル運用中、既存システム運用中の3パターンありますが、新規工場立ち上げ時のまっさらな状態が一番導入しやすく、一番難度が高いのは単体のシステムが部署ごとに散らばっている工場であり、既存システムが動いている状況に新しいシステムを持っていくと、プロジェクト進行中にいろんな摩擦が発生します。

既存のERPシステムがある工場なら総入れ替えなので、全部門条件は同じであり、不公平はないのでしぶしぶでも入力を行うと思いますが、購買用P/O発行システム、ローカルの安い会計パッケージとか特定業務に特化した単体システムが分断されて、部門間のコミュニケーションなしに部署内で完結して運用されているケース、これが一番難しいです。

これらを事前に意識した上でプロジェクトを進めて行く、週次ミーティング時に逐次現状についての予実を共有することで遅延リスク減らすことができると思います。

『使いやすいシステム』を導入するには？

ここまでの幾多の苦難を乗り越えて、システムで業務が回るようになれば、エンドユーザー側から新たな要求が必ず出てきます。

使いやすいとは「操作しやすく便利な機能が揃っている」ということですが、まずは「やりたい操作」がすぐ見て分かる優しい画面構成であることが大前提です。

私はこの3つがインドネシアでは必須の仕様だと思っているのですが、これらを備えた上でさらにインドネシア独自の商慣行や税制に対応できる機能を揃えるには、それなりのカスタマイズが必要になります。

これらはインドネシアの日系企業のエンドユーザーにとってはあったら使いやすい機能例ですが、逆に言うとなくても使える訳です。

便利な機能をどこまでシステムに実装して、どこをマニュアル対応するかの線引きが必要になりますが、この線引きのためには「カスタマイズには工数がかかる」ということをエンドユーザーにキチンと理解してもらう必要があります。