構想策定フェーズにおけるコンサルファームとシステム導入ベンダの違い

アプローチからして大きく異なるため何を目的とするかが重要

フリーコンサルの羽生です。
先日までベンダのコンサルティングチームの一員としてクライアントのBPR構想策定プロジェクトにアサインしておりました。ファーム出身者の私は、これまでコンサルファームやクライアントサイドで支援することはあっても、ベンダの立場で働くことはありませんでした。それゆえか、構想策定の進め方やアウトプットに対するこだわりのようなものが、ファームのソレとは違う部分があったので、今回はこのことをざっくばらんに書いてみようと思います。

もちろん、一案件の経験を「ITベンダとは、～である」と一般化するつもりもないので、「あー、そんなこともあったのね（笑）」というお気持ちでお読み頂けると幸いです。

■どんな案件だった？

クライアント名は明かせませんが、ある大手企業で、他社から受注しているBPO業務のクラウド化を行なうにあたり、働き方改革も兼ねつつ、システム化方針を検討しよう！という案件でした。当然、受注しているBPO業務がたくさんあるので、抽出してまずは10個を検討することとなりました。

カウンターは、現場の方はあまり前面に出てこず、システム部門の方が主担当でした。

成果物は、関係者一覧、現行業務フロー、あるべき業務フロー、システム概要図、システム化方針書、機能一覧、非機能要件、などなどで、期間は数ヶ月というタイトな計画でした。

■コンサルファームのアプローチ

ファームでしたら、まずは現行の業務/システム整理から入り、次にToBeの検討に入ると思います。少なくとも過去の案件ではそうでした。

したがって、私の進め方のイメージは、要件定義書や設計書の読み込み、現場有識者のヒアリングを通じて、現行の課題点含め整理しながらToBeの検討に入っていく流れを想定していました。成果物の因果関係もあるので、関係者一覧→業務フロー（現）→システム概要図（現）→機能一覧（現）→ToBe系の成果物、といった流れでしょうか。

———————————————————–——–——–——–
構想策定フェーズ等コンサル案件をお探しの方はこちら
———————————————————–——–——–——–

■ベンダのアプローチ

ベンダの場合は、「現在どうなっているか？」という分析に重きを置かず、「どの技術で何ができるか？」という点を重視する進め方でした。ゆえに、現行の業務整理はほどほどの品質でよく、クライアントの主担当も業務の有識者ではないシステム部門メンバということもあいまって、いきなりToBeのシステム概要図や利用する技術を説明する流れでした。BPR案件のはずなのに、業務の現/新整理もあまりせず、いきなり構築システムの青写真を描いていたということになります。

私としては、業務整理もせずに進めると、少なくともUATで現場が荒れるのでは？と思いました（今でも思っています）。

■考察：ファームとベンダが補完しあえば、クライアントはハッピーになる（かも）

ファームの強みがあればベンダの強みもあると感じました。

ベンダの強みは何といっても具体的なシステム像を提示することができるという点です。構想策定段階で具体的なテクノロジーを選び提案し、出来上がる“モノ”を説明できることは、相手を安心させることにつながると思います。

一方、弱みはシステム外の領域です。業務のFit&Gap分析や、リリースされたときの業務オペレーション、教育トレーニング、プロジェクト全体を含めたマネジメントといった領域は不得手かもしれません。こういった領域をファームにカバーさせると、クライアントも少しは楽に（？）プロジェクトを進められるのではと感じます。