ITIL活用とコンサル的戦略思考ブログ

ITコンサルタントが身を持って学んだこと、フレームワークの使い方、書評などを挙げていきます。IT企業や企業内IT部門の管理者やリーダ層の方、ITコンサルタントを目指す方に参考になる情報発信できればと思います。

顧客思考は自分事から。その先のコンサル視点

前回問題解決には顧客思考と論理的思考が重要だというお話をしました。

 

顧客の思考を考えるにはどうしたら良いか。

 

顧客だったらどう考えるか。顧客の立場によっても推測が可能です。管理者ほど企業自体の目標に資することを求められます。一方で現場ほど企業の目標ではなく、現場の業務をどう回していくかということに目線が行きます。

 

クライアントの立場は様々ですがベースは自分の立場ならどう考えるかだと思います。自分が顧客企業の部門長ならどう動くか。担当者なら何を思うか。自分事に置き換えることが重要だと思います。自分にフォーカスする必要があります。

 

一方で気をつけなくてはいけないのは、相手の立場を理解しつつ、相手の立場に縛られない事です。例えば現場の気持ち考えすぎて動けなくなるということもあります。

 

コンサルに求められる機能ということを念頭に置いた上で、あくまでも外部の立ち位置である事が重要です。

 

自分の問題として捉えられるか、一方で客観的な立場で捉えられるか。バランス能力が求められる気がします。

 

ちなみに私はまだ30代前半なので、キャリア的に部門長クラスのマネジメント視点は不足しがちです。そこを補う上でも、書籍などからマネジメントの方の視点を得ようと試みており、それは成果として繋がっている気がします。

 

日々勉強ですね。これホント大事。

問題解決能力を科学する

コンサルにおいて最も重要な能力は問題解決能力であると以前話をしましたが、どの様に向上させるのかについて考えていきたいと思います。

 

コンサルティングを行う際、全く同じ経験を使いまわせるケースというのはそんなに多くないです。

 

お客様から事例を求められても、その事例が必ずしもそのお客様にFitするものではなく、お客様に合った解決策を導き出して行かなくてはいけません。

 

もちろん仮説や持っていくべき方向性も見出すことができない様なケースは提案は慎重になります。提案段階ですり合わせをして合意をもらえた際には、その合意に基づいて進めます。

 

問題解決能力とは、答えのないところから答えを導く能力とも言えると思います。その一つとしては、概念を資料化して認識を合わせ合意形成を図る事があると思います。

 

物事を進めるのが上手い人とそうではない人の違いとして、考えを資料化できるかどうかというのが挙がります。特に成果イメージや進め方などは徹底的に資料化する事に慣れるべきです。これはそのまま提案力向上にも繋がります。

 

次に、分からない事を調べる調査能力も一つだと思います。人に聞く、ウェブ、書籍など情報を取ろうとするときに、どういった調べ方をすれば知りたい情報が導き出せるか。そこに対して、シナリオを組める必要があります。

 

順番が前後しましたが、調査能力によって得た情報から仮説を立てていきますが、仮説立案において重要となるのが論理的な思考能力と顧客思考です。

 

あえて顧客思考と書いたのは、顧客の立場ならこう考えるであろうという観点です。それが論理形成の前提となります。論理は前提を捉え間違うと意味がありません。なるべく精度高く顧客思考するために必要なのが、経験となります。こんなケースのお客様ではこんな悩みがあるといった感じです。それを正確に捉えれば論理が成り立っていれば説明が筋が通るため合意が得やすくなります。

 

こういった事の繰り返しが問題解決なんだと思う様になってきました。

 

顧客思考と論理的思考についてはもう少し深掘りして次回お話していきたいと思います。

コンサルタントの仕事術〜成果を示すデータ作り〜

コンサルタントの成果は時として非常に定性的で、最終成果を報告する際の特に上級マネジメントへの説明をする際に数値で成果を示さないと成果に納得してもらえないという事態が発生します。

 

例えばルールを作る仕事。

 

標準化されました。属人化が解消する仕組みができましただけでは納得感はないです。

 

そのためコンサルタントとしては、必ず成果を示すデータを作り込む必要があります。

 

これはコンサルタントだけでなく、自社で改善をする時も同様だと思います。

 

分かりやすい例は、顧客満足度向上。

 

顧客満足度向上の施策だけを設計しても、成果が施策を考えましたでは、通用しません。

 

施策を設計する前に、現状の顧客満足度を調査して、基準点が分かって初めて施策を実行した後の成果が説明できます。

 

いかにデータを作り込むことこそが、案件を上手くクロージングできるかどうかに関わってくるのです。

 

提案の際は顧客担当者は施策を打つ事にしか興味がなかったとしても、コンサルとしてデータ作り込む段階を設けるようにしましょう。

 

データの作り込みの例は次の機会でお話しできればと思います。

コンサルに求めるの機能とは

前回受注の秘訣として顧客が求めるコンサルの機能を理解する事、その機能をいかに際立たせるかという点をお話ししました。

 

では、どんな事を求められているのでしょうか。

 

いくつか挙げてみます。

 

①専門知識

②客観性

③リソース

ファシリテーション

 

③は労働集約型で単価は余り上げることは難しく、①は知識集約型となり、単価は高くなります。

 

私は①の仕事を常駐ではなく、訪問型にし複数進めることで、月当たりの単価を上げています。

 

担当者レベルでは①と③のニーズが高く、部門長以上では①②のニーズが高いと思います。

 

問題解決の主体を自社で担えるようになりたいという一種教育要素が強いと④のニーズも出てきます。

 

①の専門知識についても傾向があるように思います。

 

一つ目は業界動向。上級マネジメント程自分達が進むべき方向性を考える必要があるため、事業課題に対するITをどうしていくかという視点が必要になります。これに応えるためには社会背景や技術革新、業者、規模に応じたIT活用の形やIT組織のあり方などを語れる必要があります。

 

二つ目は業務知識。新しい事に取り組んでいくためには、実際に何をどこまでやればいいという点について知見が必要になります。例えばインフラをサービス化して提供する際にはどう行ったサービスをどんなSLAを設けて取り組めばいいかなど細部の事例が求められます。

 

担当者レベルで話をしていると後者のニーズを満たす事が求められますが、実は決裁者となる上級マネジメントの方は前者を求めてたりします。

 

提案をする際は、この様な求められてる機能を決裁者の視点で考える必要があります。

 

お客様の言われた課題を解決するだけの提案では、自社でやれと言われてしまいます。

 

競合他社との選定もありますが、社内リソースとの競合にも勝たなくてはいけないです。

 

ツールが社内リソースと競合しないのは、機能性が代替できないからとも言えますね。要はコンサルも代替ができないという論理をいかに作るかだと思います。

 

それでは今日はこの辺で。

コンサルとしての受注の秘訣

最近嬉しい事が二つありました。

 

一つは大型の官公庁案件が取れた事、もう一つは2年近くコンサルしていた企業の役員に直接話がしたいと言われた事。

 

特に二つ目は、いつもはIT組織の部門長とお話をしていましたが、

成果を報告後直接役員から2人で話したいとお言葉をいただきました。

 

直接話したいといってもらえるのは、話す事で何らかの気づきを得れると思っていただけだからかと思います。

 

実はこの二つの成果には共通点があり、特に受注につながる秘訣があると考えます。

 

それは、求められるであろう機能とは何かを理解する事だと思います。

 

コンサルを始めた頃、私はある小さなIT組織のコンサルに入りましたが、途中先方の部門長から「コンサルとしての資質を疑う」と痛烈な一言を言われた事があります。

 

当時の自分は、経験がとにかく浅いため、現状の問題点からあるべき姿を導き出すアプローチを取ってました。

 

このアプローチは現実解は出やすいですが、そもそもあるべき姿自体が既にシュリンクしており、ビジネスが求めるものに達していませんでした。

 

必ずしもこのアプローチが間違っているわけではないですが、この場合先方の部門長はコンサルに先生的な側面を求めており、取りまとめ役を求めていたわけではなかったと反省しています。一方で取りまとめ役、ファシリテーターを求められるケースもあります。

 

成熟度が高い組織ほど、コンサルに求めるのはファシリテーターで低い組織ほど先生的なコンサルティングな気がします。

 

私見ですが、コンサルファームでもこのコンサルティングと呼べるニーズに答えられる人は少なく、ほとんどがエンジニアリングの領域でしかないと感じます。

 

多くのケースでコンサルに求められる機能としては専門知識が挙がります。

 

先方がコンサルに期待する機能を如何に精度高く捉えるか、そして、その機能をいかに先方がそもそも実現したい事の中で必要性を高められるのか。

 

なんて事を考えたりしてます。

 

頼む側の立場にたってみれば、社内で発注する稟議などをあげるわけなので、会社を説得させる説明を担当の方からしてもらわないといけません。

 

機能として必要性を説く。

 

コンサルとしての求められる機能については専門知識以外にもあるので、その辺は次回お話したいと思います。

慌しい日の始まり

あけましておめでとうございます。ブログを始めて初めての年越しとなりました。

 

今年も少しずつアップできればと思います。

 

新年早々の仕事は、企業を様々な観点で評価し現状を明らかにするアセスメントモデルを設計しています。

 

なるべく使いやすくて手軽な物を模索中。。

 

1年あっという間で重たい案件の合間に物作りに勤しみます。

 

ITコンサルをしていると山ほどアセスメントフレームワークと出会います。今後そういったものも紹介していければと思います。

 

今日はこの辺で。

ITIL 活用〜要求実現で取り組むべき申請統合〜

久しぶりにITIL についてです。

 

本当はブログのタイトルになってるくらいなのでもっと書いていきたいところですが、興味あることばかり書いてしまってるので、のんびりお付き合いいただければ幸いです。

 

要求実現とは、サービス要求(ユーザーからの作業の依頼などユーザーからの作業を伴うリクエストの対応)を管理するプロセスです。

 

一昔前はインシデント管理の一要素として管理されていましたが、サービスの計画外の中止などで定義されるインシデントとは主旨が異なることから分けて管理する事が推奨されています。

 

サービス要求の例としてはパスワードのロック解除やPCのキッティング依頼など、業務としては申請を受け付けて対応する業務が挙がります。

 

これらをITIL に準拠させて標準化したり効率化していく際に多く取るのが、バラバラに行われていた申請をツールに載せていく事に合わせて整理するというアプローチがあります。

 

 申請業務をツールに載せる上で一番やってはいけない事は、現状の業務をそのまま載せようとする事です。

 

特に組織が大きく利害関係者が多い企業ほど、整理をしてから移行する事が求められます。それは以下の理由からです。

 

・大企業だと軽く100を超える申請があったりします。それをそのままツールに載せるのはコストがかかりすぎる。

→そもそも同じ意味合いでも申請が分かれていたり、項目もバラついている

 

・ユーザー視点で申請が統合されずシステム別の提供者視点の申請となっている。

→ユーザーは異動やなんらかの事業上の要件によって申請を出してきます。それらのユースケースではなく、申請対象ごとに申請が設けられたりするので1つのイベントで複数申請を出さなくてはいけないと言った手間が発生します。ひどい時には申請先がそれぞれ異なって状況説明を都度必要となります。

 

どんなツールでも、無制限にバラついた申請をそのまま載せるには、仕様上の制約やメンテナンス工数が膨大となり、現実的ではなくなります。

 

申請自体の統廃合や申請項目などの統廃合を行う事で、移行に伴うコストの削減や、ユーザーの手間も削減する事ができます。

 

まずは、整理するという大方針の元に進めるようにしてください。 

 

より細かい統廃合のポイントや移行の方法についてはまた後日お話できればと思います。

食から学ぶ持続可能性システム思考

今日は仕事に関係なくプライベートなお話です。

 

最近妻が建築士をしている関係で、漆喰塗りなど手伝った方にお呼ばれされて食事をしました。そのご夫婦は奥さんの方が野菜を扱う仕事をしているのですが、そこで興味深い話を聞きました。

 

そこで挙がったのはダンバーバーというシェフの方のお話です。ちなみにtedでプレゼンしたり本も非常に面白いです。

 

食の未来のためのフィールドノート・上: 「第三の皿」をめざして:土と大地
 

彼の話が面白くてNETFLIXの動画まで見てしまいました。

 

料理を突き詰めると、食材に行き当たり、食材を突き詰めると、食材の生産現場にたどり着きます。それを持続可能性なシステムの中で作り上げるある種当たり前が生み出すこの上ない美味。共感するのが、それが一番美味しいというところです。

 

他にも面白いと感じたのは牛の話。牛は名前をつけると美味しくなるそうです。また、実は沢山の牛の乳を混ぜてバターは作られるのが一般的ですが、一頭一頭同じ餌を与えても味が全然違うとのことでした。

 

人間に置き換えれば当たり前ですよね。一人ひとり異なると人間だと分かるのに牛に対してはそうは見れない。

 

当たり前だけど、なかなかそういった視点で考えることがないことってありますね。

 

 ダンバーバーさんではないですが、持続可能性なシステムを作り上げるという点に自分は凄く魅力を感じます。ビジネスにおいても、関係者がそれぞれメリットを享受できるスキームを考えたり、一過性ではなく続ける事でさらなるメリットが享受できる。そんな仕組みを作り上げることに自分はロマンを感じてしまいます。

 

ご興味があるかたは、是非ご一読を。

 

 

官公庁のITマネージャーに知っておいてほしい事

以前官公庁のトレンドとして運用に課題があると述べました。今回は問題点と意識すべきことについて触れていきたいと思います。

 

官公庁における問題点は長期間の入札案件の調達仕様の不足という点が挙がります。比較的大きな規模では3年から5年の委託となります。入札参加ベンダーは官公庁の発行する調達仕様書に基づき提案をしますが、そこに記載する情報が十分なものとは言い難いのが実情です。

 

私は官公庁に呼ばれてその調達仕様を入札参加ベンダーが精度の高い金額を出せる様に必要な情報を整備したり、場合によっては入札業務として提案を作る支援をしたりします。そこで実情を知る訳ですが、もちろん精度の高い金額で契約できている官公庁もあるとは思いますが、本当に必要となる金額と実際に契約している金額では大体1.5倍程度の開きがある様に感じます。官公庁は必要以上の金額を払っているのです。

 

最終的にはそれは税金となって皆さんから徴収されている訳です。。。

 

入札参加企業の立場からするといかにリスクヘッジしつつ、指名業者として選ばれる為の提案内容を作らなければなりません。戦略的な提案といった便利な言葉が使えないほど、大規模入札案件では想定外によるダメージが大きくなります。その為、どうしても調達仕様の情報の精度が低いほどリスク分が積まれ金額が上がります。

 

一旦その金額で契約すると、今度はそれがベースとなり、ある種ベンダーの既得権益となります。官公庁の大規模案件は、費用がとても大きい為、ベンダーとしてはそれをいかに守るかが重要視される為、自ら実態を精度高く報告しコスト削減の余地を与える必要がなくなってしまいます。

 

対象業務の品目が変われば、年次の契約更新の際に見直しの対象となりますが、そうでもない限りは基本当初の入札金額での契約が保証されてしまうのです。

 

では、官公庁のITマネージャーは何をすべきか。私は以下だと考えます。

 

①数多くのベンダーと関係を築く事

②業務可視化と標準化は必ず取り組んでおく事

③第三者の視点を取り入れる事

 

①は付き合いがないほど、内情を知ってもらう事が出来ないので、入札参加の敷居は高くなります。どの程度の成熟度で調達仕様書がかかるのかどうかの肌感覚もベンダーにとっては重要な情報となります。

 

②は精度が高い調達仕様書を書くには、業務の可視化が前提となります。業務の全体像が伝えられないのに適正な提案など受けれるはずもありません。また、標準化されていないほど整備に費用が上乗せされてしまい膨らみます。

 

③は第三者視点というのが重要です。そもそも前述した構図が生まれている要因としては、官公庁のIT担当者自体にコスト意識が高くないこともあるのではないでしょうか。随意契約が続き指導が入るくらいの状況であれば別ですが、そうでもなければ敢えて適正な競争の元に入札させるよりは、つづがなく入札を完了させ色々言わなくてもツーカーでやってくれる方が楽だからです。

 

世の中悪意まではいかなくてもビジネスという観点においては、多くの人材が怠惰であると思います。その惰性のスパイラルを定期的に引き締めるには外部の人材を使って、実態を明らかにする事が有効であると感じます。中にはもちろん惰性ではなく、革新者とも呼べる人材がいるはずです。そういった人達に援護射撃できる外部の人材を使うべきだと思います。

 

とコンサルの立場の自分が言ってもというのはありますが、実際に支援するとかなり感謝されたりします。既存ベンダーとの関係に一石を投じてくれたなど。

 

今回は官公庁のITマネージャー側の立場ですが、願わくば官公庁のITマネージャーが成果を挙げて影響力を発揮していってくれることを願う今日この頃です。

 

 

 

 

 

 

中小企業のIT部門長が持つべき視点とコンサル仕事の本質

最近長くコンサルティングを実施していた企業が区切りを迎えようとしており、部門長の方に結果を報告するとともに将来こうなっていってほしいとの想いを述べる機会がありました。

 

その企業のIT部門の部門長は現場叩き上げで高い問題解決能力を持っているものの、そもそも全社におけるIT部門の立ち位置が重要性が低く、IT自体が全社への貢献がまだ弱いため、限られた範囲でのパフォーマンスを発揮するに留まっていました。

 

ITのビジネス貢献とはよく叫ばれることで、事業のデジタル化が進む中では、より貢献の範囲やスピードを大きくする必要があります。そういった背景の中では、全社におけるITの立ち位置を変えていく必要があります。

 

ではどうやって変えていくか。それを経営に納得してもらうためには、事業におけるITが果たすべき役割を説いていかないといけません。自部門の視点ではなく、より経営的な視点で話が出来ないとこれを実現できません。

 

我々コンサルタントが出来ることは、部門長に対して水先案内として、事業構造から推測されるIT貢献の可能性を伝えるとともに、一部門長の視点から経営視点に引き上げる事だと考えています。

 

いつも思いますが、コンサルティングの本質はクライアントが評価される事に資することなのかと思います。自分がコンサルで入った企業の相手がその後偉くなっていたら、それは自身の提供したサービスの成果としてカウントできるものだと思います。ドキュメントを作るのも、プロセスを設計するのも全てはそこに繋がっているのではないかと考えたりします。

 

願わくば経営視点を持ったITにおけるリーダ、CIOとも呼べる方を増やし一緒に改革を進めていきたいなぁと思う今日この頃です。

 

 

 

コンサルタントのスキルアップ術〜ラーニングピラミッド〜

スキルを伸ばす、理解を深める上では人に教える事程理解力が上がる事はないと思います。

 

皆さんはラーニングピラミッドという考え方はご存知でしょうか。

学習効果アップの鍵「ラーニングピラミッド」とは? [学習・勉強法] All About

 

ITILの講師をしていると、説明を繰り返す事で自身の理解が深くなっていく事を日々感じます。

 

説明の為に、人に伝えるための概念化を繰り返すことで、解釈が変わっていく感じでしょうか。

 

深く学びたい事こそ、人に教える事をお勧めします。