Tweet

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

システムと現場オペレーションの乖離（GAP）については、ある程度運用でカバーするという発想がないとシステム導入はうまくいかないですが、インドネシアで業務システムを導入する際に発生しがちなGAPとして以下が挙げられます。

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

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

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

「使える」と「使いやすい」の定義

インドネシアの日系製造業は中国やタイに比べて圧倒的にシステム化が遅れており、Excelによるマニュアル処理を業務システムに置き換えようという動きが、ようやく当たり前になってきました。お断りしておきますが、システム化が必ずしも吉とは言えませんので。

「システムが使える」または「システムが使いやすい」の僕の定義は

ということになるのですが、「使える」があってはじめて「使いやすい」があるのであり、その逆は有り得ません。

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

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

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

この2点に集約されます。

計画期間内に完了するか

「期間内に完了するかどうか」はシステム導入時の問題です。システムのカットオーバー（インドネシアではGo Liveのほうが主流？）は年度初めの1月や4月にあわせることが多いですが、そこに間に合わないということは旧システムとのダブルインプットが長く続くということなので負荷が高くなり、本来やるべき作業ができないという意味でこれは機会損失になります。

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

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

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

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

さらに非稼働日考慮漏れというのがあり、ご存知のとおりイスラム圏では断食期間が毎年ずれますが、これの考慮ミス。断食期間中はお客様のスタッフは早めの帰宅が原則で無理が利きません。またインドネシアでは選挙やデモで工場半日休みなど予測が難しい事案も発生します。

システムがキチンと動くようになるか

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

システムがキチンと動かない原因を挙げると・・・

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

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

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

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

リスク回避のためには

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

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

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

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

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

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

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

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

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

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

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

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

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

インドネシアにはタダで何でもやらせようという輩が多すぎますので。