よくあるシステムと現場オペレーションの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発行システム、ローカルの安い会計パッケージとか特定業務に特化した単体システムが分断されて、部門間のコミュニケーションなしに部署内で完結して運用されているケース、これが一番難しいです。
これらを事前に意識した上でプロジェクトを進めて行く、週次ミーティング時に逐次現状についての予実を共有することで遅延リスク減らすことができると思います。
使いやすいシステムを導入するには？
ここまでの幾多の苦難を乗り越えてｗｗ、システムで業務が回るようになれば、エンドユーザー側から新たな要求が必ず出てきます。
- もっと使いやすくしてくれYO
使いやすいとは「操作的しやすく便利な機能が揃っている」ということですが、まずは「やりたい操作」がすぐ見て分かる優しい画面構成であることが大前提です。
- メニューが少なく（必要最小限）
- ボタンが大きく（視覚に訴えるのは大事）
- 階層が浅い（最大2階層）
僕はこの3つがインドネシアでは必須の仕様だと思っているのですが、これらを備えた上でさらにインドネシア独自の商慣行や税制に対応できる機能を揃えるには、それなりのカスタマイズが必要になります。
- 輸入品の船上管理を会計にも反映させたい。
- 入荷ベースで仮買掛（未払費用）を計上したい。
- 輸入申告書（PIB）や物品搬出承認書（SPPB）の税金や費用を原価へ参入したい。
- バーコードでロット単位の現品票をスキャンし簡単に実績入力したい。
- 税関用（保税区）・社内用にWEB上で情報共有したい。
これらはインドネシアの日系企業のエンドユーザーにとってはあったら使いやすい機能例ですが、逆に言うとなくても使える訳です。
月並みですが、便利な機能をどこまでシステムに実装して、どこをマニュアル対応するかの線引きが必要になります。この線引きのためには「カスタマイズには工数がかかる」ということをエンドユーザーにキチンと理解してもらう。
インドネシアにはタダで何でもやらせようという輩が多すぎますので。
