「SAP認定コンサルタント」その微妙な存在

さてさて、SAP R/3の導入に必要なスキルはなにか、ということを考察するにあたり、
少し私の肩書きについて考察してみることにしよう。


まず最初に、システム開発において、コンサルタントとSE/プログラマーとの違いはなにか、
ということについて、私なりの定義をしてみたい。


「コンサルタントを目指す人へ」の中で、一度書いたのだが、
・コンサルタント→お客さんの意思決定を助ける人
　　お客さんが決めなければいけないことに対して、こういう観点からはこうです、
　　こっちの観点からはこうです。より大事なのはこちらの観点でしょうから、
　　こうするのがいいのではないでしょうか、と投げかけることで、
　　お客さんの意思決定を促す
・SE/プログラマ→意思決定に基づいて、設計およびプログラミングをする人
　　こう決まりました。でしたらこういうやり方がありますね。じゃあこうしましょう、
　　というように、意思決定に基づき、実際の作業を行う。
というように、まずは定義してみよう。


さてと、そうするとだ。
上記の定義によると、「SAP認定コンサルタント」なる肩書きは、
必ずしも「コンサルタント」を表そうとしているものではない、という事実に突き当たる。
あの「コンサル」資格の試験は、あくまでも、お客さんの意思決定に基づいて、
あるモジュールの設定ができるか、を見ているのであり、「意思決定を促す」の能力を
テストしているわけではないからだ。


一つ例をあげよう。
営業担当にヒアリングに行ったところ、製品出荷時の運送費については、
できるだけ細かく把握したい、という要件があがった。
出荷担当にヒアリングに行ったところ、個別の運賃登録は現実的に不可能なので、
なにか簡易的な方法で行いたい、という要件があがった。


要するに、実担当ベースでの要件のコンフリクトが起こっている状態である。


このような状態の、基本的な問題解決アプローチはこうだ。
１．製品ごとの特性・地域ごとの特性などがないか調べ、どこまで「粗く」するかで、
　　両者の合意をとる。
２．両者の合意のもと、具体的なR/3の入力方法を決める。
　　例：運賃伝票を採用。もしくは、会計伝票を採用。
　　　　場合によっては、会計伝票登録時に収益特性を入力し、収益性分析上での付け替えを行う
３．入力方法に基づくR/3の設定を行う。


私が定義した、「意思決定を助けるのがコンサルである」をベースに考えると、
１．の仕事をするのがコンサルの役割である。
ところが、実は、「SAP認定コンサルタント」が担保しているのは、厳密には3.の能力のみである。
２．くらいやれるだろう、と、世間は思うかもしれないが、「認定」はモジュールごとに出される。
運賃伝票というのは、「SD」というモジュールだし、会計伝票は「FI」、
収益性分析の付け替えは、「CO」のモジュールということになるので、
「普通」の「SAP認定コンサルタント」では、できない仕事、ということになってしまう。


以前の日記に、まともに導入作業ができる人で、一つのモジュールだけしかわからない、なんて人はいない、
というコメントを書いたことがあるが、これが理由である。
すくなくとも、機能のアウトラインを知っていなければ、２．の仕事すらできないのだから。


ということで、「コンサル」なんだけど「コンサル」ではない、不可思議な存在が、
「SAP認定コンサルタント」なのである。


いまさら断る必要もないかもしれないが、「SAP認定コンサルタント」を名乗る人で、
１．２．ができる人は当然いる。
しかし、全員ができるわけではない。
そうなると、世間の「コンサルタント」というイメージとの乖離が当然問題となり、
「設定屋がコンサルなのか？？高い金取りやがって！！」
という、一部導入失敗企業の怨嗟と、
「決めることも決めないで、全部こっちのせいにしやがって！！」
というベンダーの叫びが交錯する事態が発生する。
はてはて・・・相互理解とはかくも難しい・・・不幸である・・・