コンサルティングの最近のブログ記事

最近仲良くしていただいている建築会社の社長がテレビに出ていたので録画して見させていただきました。

女性の目線でリフォームを提案するという事ですが、感銘を受けたのはリフォームのカウンセリングの方法です。

「どんな料理がお好きですか?」「洗濯はいつしますか?」「好きな雑誌は?」「冷蔵庫の中見ていいですか?」
リフォームと一見関係なさそうな質問が実はどのような家が必要かを提案するベースとなっている。
「どんな部屋にしたいですか?」という質問を投げかけてもお客さんの本当のニーズは引き出せない。
収納スペース、火力、洗濯機の置き場所、等々。。。 これらの質問によって顧客が気付かないニーズを引き出せる。

システムの要件定義も同じようなものですね。
どんなシステムが必要かをとりまとめられる顧客は普通いません。
本当のニーズを引き出さないと、システム上の制約によって、現在の業務が制約されている事に気付かず、
現在の運用をベースにシステムをデザインする可能性があります。

システムの要件定義もいかに顧客の本当のニーズを引き出す質問ができるか、それが重要ですね。

企業向け情報システム構築プロジェクトは建築プロジェクトなどに比較しても予算やスケジュールの観点から測る成功率は低いのです。

様々な要因があるのですが、要因のひとつにコストに対するプレッシャーがあると思います。

担当者、ベンダーに対する経営からのコストに対するプレッシャーが、無茶な提案につながり、結果としてトラブルを招くというケースがけっこうあります。

こんな提案、無茶だなぁ、という提案書を何度も見た事があります。

提案者の経験不足・想像力不足に起因するケースも多々ありますが、受注プレッシャーから無茶な提案につながるケースも多いように思います。

 

ITは単なるインフラという位置づけで投資をするとシステム構築の提案は金額が安い方がいいという事になり、金額に対するプレッシャーが強くなります。

逆にIT投資が企業にとって大きなメリットを生み出す場合、金額の妥当感が問われるので、単なる値下げプレッシャーにさらされずに済みます。

要は付加価値のあるシステム化の企画が大事です。

 

 

改革のテーマを実際の現場に落としていく際に、プロジェクトオーナーが
実際の現場のリーダーと改革の実現イメージを共有できない場合、
プロジェクトの実行は非常に困難なものになります。

コンサルタントが現場のリーダーと一緒に計画を作成しても、オーナーと
意識があっていない限り、内容は評価されません。
また、オーナー側の考えをコンサルタントが無理やり現場リーダーを含めた
クライアントのメンバに伝えても反発され、何もできあがりません。

このような状況になるのは、コンサルタントが自分で改革のイメージを
発信していない、あるいは共有できていないからです。


 

今まで多くのプロジェクトに携わってきたので、
プロジェクトがうまくいくかどうか、良い状態かどうかというのは
理屈よりも先に肌で感じられます。

前に勤めていたコンサルティング会社のプロジェクトレビューアとして
様々なプロジェクトを見た経験もあるのかもしれません。

プロジェクト監査というのがありますが、私自身がマネジメントをする
プロジェクトも監査を受けた事があります。

しかし、実際にITプロジェクトのプロジェクトマネジメントを行ったことが
無い方が監査をするケースが多く、実質的なレビューにならないという印象を受けました。
もちろん、何もしないより、リスクは低下するのでしょうが、監査を受けるプロジェクト側に
負担がかかる事なので、「わかりきっている指摘」より、「気づきをもらえる指摘」が
欲しいところです。


私自身がプロジェクトマネジメントの支援を行う際には、実質的なマネジメントの
改革を心がけるようにしています

システム開発・変更を行う際に、既存のシステムベンダーに見積りを依頼するとします。

この際、要件を曖昧にしたまま見積りを出して出てくる金額が思ったより大きくて驚く。

ベンダーからすると曖昧な要件では様々な「想定」をして見積りを行います。

一度出した見積りはなかなか金額を上げられないという立場のベンダーからすると

当然の行動のようにも思えます。

 

一方、システムの見積もり依頼を行った方は、こんなにお金がかかるのかと驚き、

その金額で実行判断をしてしまいます。

 

要件を整理し、システム化の範囲、規模感の整理を行う事で開発コストが10分の1に

なる事もあり得ます。

また、将来的な拡張性や変更時のコストなどもトータルに考えてくれるコンサルタントを

活用するのは非常に費用対効果が高いことだと思います。

(良識あるコンサルタントは自分の費用に見合う利益を生み出せない仕事は

極力受けないのではないでしょうか。)

 

某大手企業では情報システム子会社にシステムの修正を依頼したところ、

かなり大きな見積りが出てきました。

私の感覚では桁がひとつ多いようにも思いますが、確かに見積り依頼をしている内容が

ラフすぎるという問題がありました。

「この子会社は言われたことを言われたとおりにします」というスタンスで、

「こうやったら安くできます」という提案はまったくしてくれません。

システムを知らない担当者はいわゆる「落とし所」がわからず、金額に悩みます。

しかも要件も決まらずに一括で発注するのですから、何とももったいな話しです。

(まぁ、どちらにしろ同じグループ内の取引ではありますが)

 

世の中にはこういう状況が山ほどあるように思います。

 

システム、サブシステムの定義をどのような括りで定義するかは結構様々なように思います。

例えば受注管理業務機能に対してシステム導入を行う場合、受注管理システムなどど呼ぶと

して、これが受発注管理機能のシステム導入になると、受注管理サブシステムとなったり。

 

ホストからオープン系システムへ移行した際にオープン化された新システムを「○○システム」

と呼んで、それらを構成するサブシステムの単位が他のシステムと業務機能的に同レベルだったり

すると混乱する可能性があります。

 

神経質になるほどの事でないかもしれませんが、システム名称は大事ですので、

良く考えてつけたいものです。

 

 

優秀なコンサルタントを雇って高いお金を支払えば

儲かるシステムができあがると思えば大間違いです。

 

企業を変える、しくみを変えるというのはカルチャーも含めて変革しなければ難しく、

カルチャーを変えていくには経営トップのコミットが必要です。

 

システムの要件定義を行う際に実務を知る方々が時間が無いという理由で参画しない場合、

あるいはプロジェクトの方針としてユーザ要件を聞かないという方針であったりすると

多くの場合、実務に支障のきたすシステム、使われないシステムができるでしょう

 

大切なのは、新しい仕組みを構築する上で社内の各部署の人間が集まり、情報や意見の交換を

行い要件を決めていく、そして自らプロジェクトの参画者であるという意識を持って臨むことです。

プロジェクトに参画する事により、他部署や会社への理解が深まり、企業内での人脈が拡がるなど

の副次的な効果もあります

 

基幹系システム導入にあたって現状業務の理解、問題点の抽出などのためにヒアリングを

行うのが一般的かと思います。

事前に業務分掌などを入手し業務理解をした上でインタビューを行うのも良い方法かと思いますが、

単純にインタビューを実施するよりも効果的な方法があります。

 

それは該当業務に関係する方々を集めて2時間程度のセッションを行い、

現状業務の分析を行う事です。

セッションのアウトプットでDMMやDFDを作成してもらいます。

作成の過程で業務の無駄、負荷などの意見が出てくるので、それらを記録し、改善テーマとして

管理します。

 

 

ITプロジェクトの計画づくりから実行まで、様々なシーンでヒアリングを行います。

ヒアリングを行う際には事前に想像力を働かせる事が重要です。

例えば、システム化計画において、ある部門にヒアリングを行う際に、

「この部門が困っていることはこんな事ではないか、こんな事が実現できたら、どうだろう?」

といった事を想像しておくと、深いレベルで理解ができます。

 

ヒアリングされる人は、たいがい構えるものです

自分がヒアリングされる立場になったつもりで、一度想像するのも良いヒアリングをするのに

効果的です。

「あなたたち、誰?」「何しに来たの?」

「システムの不満なんて、いつも聞くだけで実現してくれない。時間の無駄だ」

「自分の言ったこと、評価につながったりしないよね?」

こういう気持ちをいかに取り除いてヒアリングを行うかと同時に

場合によっては期待値コントロールもヒアリングの際に出来ると良いでしょう

 

このアーカイブについて

このページには、過去に書かれたブログ記事のうちコンサルティングカテゴリに属しているものが含まれています。

前のカテゴリはカテゴリを追加です。

次のカテゴリはスケジュール管理です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1