2つの大きなリスクが存在する

斎藤さんは、

システムインテグレータから提案しないのは、システムインテグレータの知識不足か、もしくは怠慢でしかない。導入企業からすると、複数のオプションを提示されなければ検討もできないわけであり、提案をうのみにするしかない。

と原因はSIの姿勢であるとしている。

これに対し、古澤さんが、

「システムインテグレータから提案しないのは」認定製品をもつソフトウェアベンダーの営業力不足だからかもしれないではないか！彼らがそのソフトウェアの存在を知り、使えると判断すれば、敢えて作りこむ提案などしないだろう。

と反論を加えている。

また、斎藤さんは、提案されない理由として

その存在を知りながら適用しない理由としては、「プロジェクトスケジュールを守るためにその接続方式に関するSAPシステムの新たな機能や技術を学ぶ時間がない」とか、「アドオンプログラムの開発をした方が、その経験から開発費用を下げることができる」などが挙げられる。

　確かに、要件によってはアドオンプログラムで対応した方が開発および運用においてコスト削減できるケースもある。しかし、標準インターフェイス方式を採用するか、アドオンプログラムを採用するかの適正な判断をすることなく、つまり“問答無用”でアドオンプログラムが適用されているケースが多いのではないかと考えられる。

と、技術的な側面からしか見ていない。

ここに、違和感を感じる。導入を実行する側からすると、2つの大きなリスクを抱えることになる。この視点が欠けている。

そのリスクとは、

1. ライフサイクルを通したリスク
2. プロジェクト自体のリスク

リスクを回避するのは、実行者としては、当然なことである。

ライフサイクルを通したリスクとは、アップグレード時の対応である。

SAPが保証しているのは、そのバージョン限りではないか。アップグレードを行っても、その製品の認定が同時に行われたことはない。アップグレードを行いたいと考えても、補完製品の認定が降りるまで待たなければいけない事態も発生する。

また、プロジェクト自体のリスクとは、ベンダーのサポート力である。

確かに標準で用意されているものを使うと言うのは、正しいように思う。しかし、元SAPのプロマネとしても、経験のないものは、提案できないのである。ましてや、SIとしてはである。

某帳票ツールを採用して、そのベンダーのサポート力が非力であるため煮え湯を飲まされた経験のあるコンサル諸氏も多いのではないだろうか。私もその1人である。ちなみに、このツールは、RFCに対応していながら、ベンダーからの提案で、CSVファイルを吐き出して、それを取り込むという仕様にせざるを得なかった。

私の元SAPの経験から考えると、古澤さんの方の言い分に賛成したい。その経験談を披露しておきたい。

私が経営管理モジュールのコンサル兼プロダクトマネジャーをしていたころの話である。年代的には古いが、了承してほしい。そのころは、BWが発表されたばかりで、使えるかどうかわからなかった時期である。

私が関わっていたプロジェクトで、顧客がビジネスオブジェクツのライセンスを持っているから、EISと連携させたいと要望が出された。ちょうどそのころ、アメリカでは、まさにビジネスオブジェクツをフロントとして使用するEIS導入が盛んに行われていたのである。

そこで、ビジネスオブジェクツの日本法人と打ち合わせを持った。その時の回答は、「それは、アメリカでのことであり、日本では、展開予定がない。」ということであった。

これでは、当然、顧客には勧められない。何も、ビジネスオブジェクツの姿勢を批判しているのではない。方針だから、仕方がないのである。

そこで、ドイツで推薦されていたインサイトという製品を日本に持ってきた。このベンダーは、日本進出に熱心であり、ヤマハさんを紹介し、日本総代理店となってもらった。またミノルタさんがその導入第1号となった。この時、ベンダーからインストラクターを派遣してもらって、SAPジャパン、ヤマハ、ミノルタで合同トレーニングを行った。

その後、十数社導入したが、BWが立ち上がってきたので、うやむやになってしまう運命をたどったのだが。

要は、補完製品のベンダーの本気度をつかまなければならないのだ。

また、私が、トレーニングセンター長として、コンサルを離れた時、補完製品のトレーニングを行う企画を立てた。実行して見ても、少数の製品以外、集客できなかったのである。