失敗へのプロローグ

あんまり書くと、秘密の漏洩になるので、
詳しくは書けないのだけれども、
今度お話をもらったプロジェクト、
このままいけば、確実にアウトである。


某プライムベンダーから、プロジェクトが立ち上がるから、
人を出してくれないか、という打診があった。
ということで、のこのこ面談に行ったのだが・・・
はてはて、大変である。


「R/3を入れるとBPRができますよ」
という、少し昔にはやったセールストークがある。
このセールストークは、ある意味あたっていて、
ある意味間違っている、ということは、
たこふじシリーズの前段でもお話したことである。
つまり、BPRの手順は、R/3の「機能」にあわせるのではなく、
その機能を実装する前提となっている、
「標準的な会社組織とその機能分担」に
まずあわせてみて、そこでおきるギャップを、どう吸収するか、
それを考える、というステップが正しいわけである。


しかし、今回、ユーザ側が、このことを勘違いしている気配が濃厚である。
企画書によると、導入期間は半年であり、平行してBPRを行うことになっている。
そして、そのBPRは、「R/3を前提にしたもの」ではなく、
「競争優位を確立するための」BPRを目指す・・・
とまあ、こうなっているのである。
で、その「競争優位を確立するためのBPR」とやらが
どこまで進んでいるかというと・・・なっはっは。
プロジェクトがスタートしていないから、
進捗ゼロなのである。
ひっさしぶりに、あいた口がふさがらなくなった。


こういう場合には、構想力と説得力がまず必要である。
まず、「競争優位の確立」とは、どの部分で行うのか、
というポイントをリストアップし、それに優先順位をつけるわけである。
そして、優先順位の低いところを、まずスタートさせる。
大抵、この部分は、いわゆる「実行系」・・・
オーダーを受けてから購買・生産・出荷する、
一連の流れが該当することが多い。
逆に、R/3の企業モデルを適用すれば、
少なくとも「標準並」に、引き上げることができるのである。
これが、構想力である。


そして、競争優位の確立が必要だ、
と、なった部分は、ユーザと一緒に、「検討」を行う。
所詮、コンサルファームであろうが、システム会社であろうが、
「競争優位」を作る仕掛けを、「持って」いるわけではない。
本に書いてある仕掛けを、ユーザの実行力に合わせて
修正するのが関の山である。
そして、この「検討」という部分は、
ユーザの実行力を測り、ユーザに「あきらめてもらう」という
ステップに他ならないのである。
これが、説得力である。


この、構想・説得のステップを踏んで、やっとこさ
「プロジェクトスコープの確定」が、できるのである。
普通は、これをやって、初めてシステム構築の見積もりを出すのである。
しかし、今回は、このステップを含め、実装・テスト・移行、
全部で半年、お金はFix・・・

アホか！
アホか！！
アホか！！！
アホか！！！！
このどアホがああああああ！


これで、一緒にいく会社の連中は、
「コントロールができていない」
だの、
「先が見えず、マネジメントできていない」
だの、聞いたふうな文句をたれるに決まってる。

じゃあ、この手の仕事を断って、
てめえ、自分のおまんまが食えると思ってたら、
とっとと独立して自分で仕事とってきやがれ！！
ばかやろー！！！


すこし取り乱してしまった。
地方のお仕事だし・・・単価があわない、か、そんな理由で、
向こうから断ってくれないかなあ、と思う、今日この頃である。