R/3導入　機能の理解の前に - 肩書「シニアコンサルタント」のつぶやき

SAP R/3 は、よくできている。

入力画面のとっつきにくいだとか、日本の商習慣に合っていないだとか、バグが多いだとか、
カスタマーサポートセンターの対応はムカつくだとか、まーいろいろ言われるが、（客観のふりをした主観全開）
しかしながら、こんなに理詰めのシステムはないんじゃないか、と、思うのである。

私見ではあるが、いわゆる企業成熟度３の企業ならば、このシステムはほとんど手直しせずに
導入可能なのではないか、と思う。

企業成熟度とは、まあ、企業の管理レベルがどの程度か、という指標である。
おおざっぱに言うと、
レベル１は、月次の会計だけをあわせている状態、
レベル２は、取引の明細レベルで実績を登録している状態、
レベル３は、予定に対して実績を登録している状態
というように思っていただいてかまわない。（厳密な定義は違います。わかりやすさ優先）

逆に、成熟度レベルが２以下の企業に導入しようとすると、大変である。
成熟度をそのままに、システムだけを入れると、オペレーション工数が増えてしまうのだ。

モノを買う、という行為を例にとろう。

レベル２の状態というのは、モノを買った結果をシステムに入力する。
もうちょっと具体的なイメージを書くと、一目で見渡せるモノの置き場があって、
なくなりそうになったら電話で注文する。
モノが来たら、「買った」という実績をシステムに登録する。
在庫に関しては、出入りは帳簿でつけて、月末に在庫残高を数えてシステム登録するという状態である。

この状態そのままで、R/3を導入するとどうなるか。
・「発注」の伝票を入力する。
・「入庫」の実績を入力する。
・倉庫から出す際に「出庫」の実績を入力する。
・「請求額」の実績を入力する。
以上の3ステップが必要となる。
レベル２と比較すると、「入庫」「出庫」は、帳簿管理をシステムにしたもの、
「請求額」は「買った実績」に該当するのだが、発注に対応する入力がレベル２にはない。
つまり、予定伝票である「発注」の伝票を入力する手間が単純に増える、「悪いシステム」になってしまうのだ。

R/3が想定している組織は、複数の倉庫があり、モノの移動は業者（もしくはブルーワーカー）がやっており、
管理部門でその在庫数量の変化を集中的に管理している。
発注は、管理部門が行い、入庫の実績事態は、モノの移動を担当する業者（もしくはブルーワーカー）が
担当する、という組織である。
このような組織体だと、トランザクションの増加の観点から「発注残の管理」が必然となり、
今入庫したものが、いつの、どの発注に対するものなのか、を把握するため、「発注番号」が必然となる。
だから、「発注」の入力が必然となるのだ。
（ほかにも「発注」という予定を入力するメリットはあるのだが、割愛）

これが、「R/3のビジネスプロセスにあわせるとBPRができますよ」というセールストークの真実である。
R/3を入れるからBPRができるのではなく、企業の成長に伴い、より効率のよい組織に脱皮しようとしたときに、
一番マッチしている既存システムというのが、R/3だ、というのが、私の解釈である。
（R/3が大企業向けといわれる所以でもある）

逆に、「R/3にあわせる」ことを、上記のような組織体に対する考察を抜きに、現場に強制すると、
「どこがベストプラクティスだ」「単にめんどくさいだけじゃないか」
という、非常にもっともなお話になり、プロジェクトは崩壊するのである。

とうことで、R/3導入を円滑に行うために必要なスキルの第一優先は、
・企業の成長に伴う、一般的な効率性をもった業務プロセスを理解していること
ということになる。
極論ではあるが、R/3が提供している機能の理解は後回しでもいいと思う。
大抵、「機能」はあるのだから。