業務分析とは業務を標準テンプレート化することである

多くのERP ベンダーは、後にするべきだと言います。なぜですか？

理由は、

開発プロジェクトの期間が長くなる

要求も多くなる

ERP の標準機能で対応できなくなる

からです。結果として追加開発で対応することになってしまいます。SAP でも、初期のころは、業務改善を同時に行うことを推奨していましたが、ある時期から、

「業務改善は、異なるプロジェクトで、異なる期間でやる」

「組織改正も導入後にやる」

という方向になってしまいました。

実際、同時にやられると、プロジェクト自体が大変になります。本番稼動直前で、組織変更のために設定をやり直すこともしばしばありました。

しかしこれは、本末転倒です。

ERP を導入する目的が、あいまいなままであることを逆に利用しています。しっかりと導入効果を見るためには、業務改善を踏まえて導入するべきではないでしょうか。

ERP の導入は、業務という観点で考えるとどのような意味がありますか？

ERP の導入は、全社業務を「標準テンプレート」にするという意味があります。

標準テンプレートとは、「作業標準」と言い換えても良いです。さらに、部門間で「データベースを共有化」して、リアルタイム更新を行うシステムがERP です。

従来の業務の標準化手法は、紙に書かれた業務マニュアルであり、トレーニングでした。標準テンプレートでは、PC画面が指定する入出力作業を行えば、個々の業務が作業標準になります。

さらに、標準テンプレート上には、「ワークフロー」というシステム概念があります。

ある１塊の業務（遂行したい目的）を選択すれば、標準手順と必要データをテンプレート化して示します。（IT業界でワークフローと言えば、電子承認の方に話が行きがちですが、それは、ワークフローの１機能です。）

ユーザは、画面指示に従って、入力を行えば、標準的に業務が遂行できることになります。それが経理作業であって、出荷作業であっても、同じです。

従来のシステムでは、どうだったでしょうか。

細切れなメニューを選択し、作業を遂行していました。

ユーザは、作業の熟練と、システム内部への知識が必要で、しかも使いにくかったのではないでしょうか。

当然、担当者が替われば、そのやり方も変わる。標準作業は、存在しませんでした。

わが社だけの固有の業務と思っていたものが、業務を組み立てている最小の作業単位にまで分解すれば、各社の業務は、共通のものになります。

予実対比の分析表を作ると言う作業は、財務省であっても、大企業であっても、中小企業であっても同じです。複雑になりますが、商品仕入れの発注方法も同じです。

この考え方が進んでいるのは、医薬業界です。

上位のほとんどの企業がSAP R/3 を導入し、基幹業務の標準かなされています。医薬業界の競争力は、製品開発にありますから、そちらは各社各様です。

また、各社の基幹業務が横に標準化され、情報が共有化されたものが、サプライチェーンになります。

標準テンプレート化された業務を外部に委託すれば、それがアウトソーシングになります。

この標準テンプレートを組み合わせて、プロセステンプレートを作り、ビジネスプロセスとして定着させることが、業務の効率化、可視化につながるわけです。

標準業務テンプレートと標準業務プロセステンプレートが入っているものがERP です。

翻って、現実には、基幹業務プロジェクトで行われる業務フロー分析では、どのようなことがなされていますか？

よくあるパターンは、

現状業務フローをフローチャートにして、あるべき姿を考える。

あるいは、現状業務フローそのままを将来のシステムに置き換えるということではないでしょうか。

上に書いたようなことを念頭において行っているでしょうか。

業務要件ヒアリングでも、ユーザからは、「現状は、こういう風に業務をしているのですが、それをそのまま実現できますか」と聞かれます。

このような質問がくるたびに、「その業務の本来の目的は、何ですか」とか「何を達成するためにその業務は存在しているのですか」というような逆質問をしなければなりません。

この質問に対して、明確な回答をくれたユーザは、ほとんどいないのが現状です。ほとんどの回答は、「いやぁ、昔からやっているので...」です。

業務要件とは、現状行っているやり方ではなく、その業務の目的そのものです。

現状業務のやり方は、現状のシステムの制約条件の下で行われているやり方であって、それは、新システムに移行する場合の要件には成り得ないのです。

新しいシステムには、新しいシステムでのやり方があって、その業務の目的とするところが実現できるのであれば、そのやり方を変更するの当然であると考えていただきたいとおもいます。

こういうお話をしても、納得してもらえず、結局は、今までのやり方をそのまま実現する方向で、アドオンを開発する無駄な投資をすることが多いのが現状です。

以下は、日産自動車で初めてR/3 の会計モジュールを導入したときの話です。その時の日産自動車のPMは、私の大学時代のクラブの同期で、学生時代よく一緒に遊んだ仲でした。その彼と、２人だけで飲みに行ったときの会話です。

PM「会議で、大砂古から、そんなことをするんならなぜSAP を使うんだと言う質問が出たときは、うちのメンバーは、ベンダーからあんな発言があるとはと、みんな目を丸くしていたよ。でも、大砂古はだめなものはだめとはっきり言ってくれるから安心できるよ。」

私「ありがとう。購入前に良く、これだけ調べて、どのように使えばよいかを考え抜いたのは、さすがだな。あの質問の趣旨は、SAP が想定していない業務フローに日産が挑戦しようとしていることを、メンバーに知ってもらいたかっただけだよ。それに、SAP 側のメンバーに心してかかれよと言いたかっただけだ。」

PM「でも、R/3 の標準機能だけを使い、つなぎ合わせているだけだから、できると思わないかい。」

私「実は、俺もできると思っている。ただ、SAP が想定していない分、何処に影響があるかわからない。仮にフローが動かないことがあっても、バグだと決め付けて、騒がないでくれ。これは、日産、SAP 双方にとってチャレンジだから。」

この要求仕様は、夜の飲み会でGOサインが出て、その後、多少のトラブルはあったものの順調にカットオーバーを迎えることができました。トラブル時には、SAP側のコンサルタントから「大砂古さんとあろう人が、こんな仕様を認めるなんて」とぼやかれましたが。

ちなみに、現在の日産自動車が使用しているSAP はルノーのプロセスをテンプレートとして導入し直したものです。その時、上記の会計システムは廃棄されました。