ERPの落とし穴part6～業務とERPの間の微妙な関係

ERP導入のポイントについて優れた記事を見つけたのでメモ。

【元ネタ】
第1回 ERPの概要と導入のポイント | Think IT

第2回 アンバランスな業務とERPの関係 | Think IT

第3回 海外進出する日本のパッケージベンダ | Think IT

第4回 「SOX法」に踊らされないために知っておくべき内部統制とERPの関係 | Think IT

第5回 ユーザができるリストを用いた自社の内部統制のチェック | Think IT

【1】ERPの本質は2つ。
一つはマスタ管理の一元化。
例えば、発注管理で使われる仕入マスタと経費精算や請求管理で使われる仕入マスタが一元化されていなければ、どこにどれだけの経費や売上を請求すべきか、分からない。
日本の会社は普通、月末に売掛金や買掛金を締めて一括請求・一括支払いするので、金額を正しく計算できなくなる。
つまり、仕入マスタというデータに整合性が取れていないわけだ。

最近は、CRMを導入したい場合、POSレジで売上計上したデータに顧客情報が顧客マスタと連動する仕組みを作っていないと難しい。
トランザクションデータにある顧客情報が記録されていなかったり、登録されていてもデータの形式が揃っていないために、顧客情報を抽出するためのデータクレンジングが必要だったりするのだ。

もう一つは、データのターンアラウンド。
例えば、商談を受注したとしても、製品を出荷した時に売上計上と同時に売掛金が発生し、翌月末締めで売掛金を締め請求し、顧客が当座預金へ入金したら、売掛金と相殺しなければならない。
それら一連の処理では、受注データが売上、請求、入金の各プロセスでデータが流れると同時に、ステータスも次々に更新されていく。
だから、一つのデータのライフサイクルをシステムで一元管理できるようにするのはとても重要。

【2】ERPの歴史をたどると、「マスタの一元化」をめぐる問題をずっと引きずっているのが分かる。
下記の記事が分かりやすい。

第3回 海外進出する日本のパッケージベンダ | Think IT

業務がシステム化された頃、企業内の経費管理・販売管理・発注管理などはバラバラに作られていた。
しかし、業務システムが対応する範囲が広くなるに連れて、統合業務システムの必要性が言われ始めた。
これがERPの起源。

普通のERPは、クライアント・サーバーという2階層の設計思想が普通。
クライアントでは企業内の担当者が入力運用するので、それほど人数はいないし、サーバーでデータを一括管理すればいい。

しかし、Webシステムがどんどん普及して広がったことで、ERPのC/SシステムとフロントのWebシステムの違いが浮き彫りになった。
例えば、Eコマース、CRM・BIなどの情報系システムがWebシステムとしてERPの外側にあると、ERPとは、データ連携するために、SOAPなどのリアル連携、または、バッチ処理による非同期連携が必要になる。
つまり、性質の違う複数のシステムを接続するためのサービス指向アーキテクチャというSOAのような考え方が必要になってくる。
これが、いわゆる外部接続という方式であり、ERPでは開発のボトルネックになりがちな部分。
以前、下記の記事でまとめた。

ERPの落とし穴part3～外部システム連携がプロジェクトのボトルネック: プログラマの思索

また、EnterpriseArchitecture(EA)という考え方も、サイロのように各システムが乱立した状況を解決するために、全体最適の観点からメタ・システムを作ろうとする発想とも言える。
EAは一時期流行したけれど、今は下火になっているように見える。

Enterprise Architectureの悲劇: プログラマの思索

【3】ERP導入は以前から大変難しい案件だ。
なぜ難しいのか？
それは、ERPと現場の業務にズレがあるから。

それゆえに、ERPをそのまま導入しても、業務改善や業務の効率化につながるとは限らない。
そのあたりの事情は下記に書かれている。

第2回 アンバランスな業務とERPの関係 | Think IT

中小企業ならば、ERPがカバーしていない業務は運用で逃げることができる。
イレギュラーな業務、例えば、年1回の帳票作成や年1回の在庫棚卸しさぎょうなどは、手運用でカバーすることも可能。
しかし、大企業では、トランザクション量が多いために、運用で逃げることが現実上、不可能なケースが多い。
年1回のイレギュラーな業務をERPがカバーしていないと言っても、手作業の運用でカバーできないならば、機能追加して作る他無い。
だから、大企業では、ERPのカスタマイズは必要悪。
カスタマイズしなければ業務が滞るのだから、お金をかけてでも作るしか無い。

【4】既存のパッケージ製品を導入する場合、ポイントはいくつかある。
一つは、パッケージ製品から流用する機能とカスタマイズする機能を見極めるフィットギャップ分析をすること。
フィットギャップ分析することで、コストや納期の制約条件を考慮して、どの機能はERPを流用するのか、別の機能はERPにないのでカスタマイズしてでも新規に作るのか、という判断資料になる。

もう一つは、パイロット運用や並行運用しながら、導入を進めていくこと。
フィットギャップ分析に時間をかけすぎても、実際の現場で運用しなければ分からない時が多い。
ERPを導入してみたら、実はユーザインターフェイスが使いにくかったり、現場でよく使われる業務が機能として不足していたりする。
ERPを導入することで、逆に、現場の担当者が混乱したり、現場の作業量が増えて逆効果になったりする場合もある。

だから、普通は、特定の部門へ先行導入して、ERPと運用のミスマッチから上がる問題を抽出して、その対策を講じた後に、他部門へ順次展開するパイロット方式を選択する場合が多い。

あるいは、既存の業務システムと並行して、新規導入したERPも2重運用しながら、業務に支障が発生しないように運用する場合もある。
並行運用は、ERPへ一括・単純移行する場合に比べると、現場の業務がいきなり変わるわけではないので、業務が滞るリスクは小さい。
しかし、2つのシステムを運用するためにコストがかさむし、現場の担当者も2重入力する手間がかかる。

【5】業務とERPの関係は正直微妙だ。
業務をシステム化して、効率化するのが目的なのに、実際は、システム化するほど、証跡としての紙の帳票が増えて過ぎたり、カスタマイズしていない機能は手運用でカバーするために逆に作業量が増えたりする。
結局、ビジネスの現場でどのようにシステムは使われるべきなのか、という事実を開発者がもっと知らなくてはならないのだろう。

ERPを「受託案件の業務システム」に置き換えてみれば、自分たちが開発したシステムが本当に顧客の価値になっているのか、疑問に思える時があるのではないだろうか？