NetWeaverという困惑 その2 今まであった優位性

さて、このNetWeaverという仕組みに対する困惑その2は、
エンドユーザにはともかく、企業の情報システム部のみなさんに受け入れられるのだろうか?
という疑問である。


情報システム部のみなさんがR/3を積極的に推していた理由。
それはいくつかあるのだが、
「それはできません」
というのを、パッケージのせいにして堂々と言える、というのが、実は大きい。
本当は、開発すればなんでもできるのだが、今までのABAP開発コストは、通常の開発コストより
はるかに高くついていたため、とりあえずR/3のせいにしちゃって、
「これはパッケージなので、できないんですよ、すいません」
と、言えるのだ。


まあ、第三者からみると、仕事をしたくないだけかよ、という話になるのだが、
「情報システム部」がおかれている立場を考えたときには、話はそう簡単ではない。


一般的に、エンドユーザからみた情報システム部に対する意識、というのは、
自分たちの業務を楽に、便利にするために存在する人々、というものである。
で、問題は、「楽に便利に」が最優先となり、それを実現するためのシステム投資コストを
意識する人が、絶対的に少ないのである。
「ちょっとこういうことしたいんだよね」
「えっ?本当に必要なんですか?」
「必要に決まってるだろ!!」
業務に関しては、当然エンドユーザのほうが知識が多いから、この押し問答は、
大抵情報システム側の敗北に終わる。
しかも、「必要ですか」と聞けば「必要だ」と、答えるのが人間だから、一度作ったモノを
消してしまおうと思っても、エンドユーザの承認がもらえることは、ほとんどない。
結果として、情報システム部に対する要求は、システムを運用している最中でも膨れ上がり、
どんどんシステムが肥大化していく。
(私は従業員の数の5倍の帳票種類をもつシステムに出くわしたことがあるが、
そんなに珍しいことでもなさそうである)
当然、情報システム部員は、トラブル対応で日々をすごし、
スキルアップもなにもあったもんじゃない、という状態になってしまう。
しかも、コストは「間接費」。
エンドユーザは痛くも痒くもないのである。
一般的には、課金体制の構築が、この手の話の解決策になるのだが、そこはそれ、
社内政治ってやつは、お金を稼ぐエンドユーザ側に有利なようにできていて、
「今うまく行っているんだから、いいじゃないか」で、終わるのである。


ここで登場するのが、「理詰めのシステム」R/3である。
乱暴な話だが、
「R/3に機能がないってことは、あんたの仕事のやり方が悪いんだよ!」
と、言える、「グローバル・スタンダード」という武器を情報システム部は、
初めて手にするわけである。
会話例としては・・・
「こんなんじゃ業務がまわらないぞ!」
「それはR/3に業務をあわすという方針で」
と、まあ、こんな感じである。
(もちろん、これの乱用が、R/3導入失敗の原因であることには異論はない。
失敗しないための考え方は、「たこふじ」シリーズ等で、じわじわ今後とも主張予定)


上記のような背景を踏まえ、システム提案をする際の「売り文句」を考えてみる。
システム提案をする場合、「なぜR/3か」ということを主張しなければならない。
競合は、Oracleであったり、手作りシステムであったりする。
OracleERPは、基本部品をそろえてあります、足りない分は開発しましょう、という
コンセプトに立っているし、手作りシステムは、ユーザ要件に合わせて柔軟に設計、なのである。
で、R/3の優位点は、「容易に追加開発できないこと」であり、結果として
「システム構築コストの肥大を防ぐ」のだ、という論旨が、情報システム部向けには有効だったわけだ。


ところがである。
NetWeaver君は、こう主張する。
「いままでよりも低コストで開発が簡単にできますよ〜」
SAPさんも、
「アドオン開発するなら、NetWeaverを使うの推奨よ〜」と言ってくる。
うーん、困ったのである。
開発が大変なこと、が、優位性だったのに、自分から優位性をぶち壊してどうすんだ!?ということである。


まあ、実は問題の本質は、ユーザ側の情報マネジメントだ、という指摘は正しい。
要は、情報システム部がしっかりすれば、なんのパッケージを使おうが、手作りしようが、
余分なコストは発生しないんだ、という考え方である。
しかし、この指摘があまりにも正しいが故に、自分たちがしっかりしていないことを白状するような、
上記メリットは、ほとんど公になることはない。
SAP社は、いわゆるサイレントマジョリティのニーズを読み誤ったのではないか、
そんな気がするのである。