ITIL活用〜導入の意義とポイント〜
ITIL導入したいという事で声をかけていただき、仕事をする事が多いですが、結構誤解が多いので今日は意義とポイントについて事例を交えて述べてみます。
まずITILを導入する意義はどんなところにあるでしょうか。
押さえておくべきはシステム運用からITサービスマネジメントへの変革が挙げられます。
システムを安定稼働させるという品質の観点から、ビジネスが求めるサービスレベルを実現するというサービスレベルの観点に変わります。
そこには必ず誰が顧客で、顧客が求める事は何かという視点が加わります。
IT部門で社内においては売上を上げる機能ではなくコストセンターとして貢献度を問われる様な場合、顧客の期待と業務を整合させる効能があります。
例えば、多少使い勝手が悪くてもコストが少ない方が良いとか、ビジネスのスピードに追従して、迅速なシステム利用を促すなど。
期待値をサービスレベルとして定量評価が可能になります。
では、導入に際してのポイントとは何か。
前述した想いをマネジメントが持ち、部下にITILを導入せよと指示を出すときにその目的が正しく伝わらない事がよくあります。
すると目的も理解がされないまま、何となく書籍を読んでITILのプロセスを見様見真似で実務に適用し、プロセスを書き換える事を主眼においた活動となってしまいます。
教科書になぞる事は目的ではないです。そもそも顧客のニーズは何なのか。それを押さえない限り成果には繋がりません。ITILベースの運用にしたという事実しか残らないのです。
明確なこうしたいという目的、我々は成果と表現しますが、成果を定義する事から始める必要があります。
次回は実際に事例を述べてみたいと思います。
ITIL活用〜プロセス適用の順序と最低限実装すべきプロセス〜
久しぶりにITILの話です。
今まで、ITILプロセスを導入してしていない企業がITIL導入したいから支援してほしいという相談があります。
今日はオススメの順番とITILに基づいてITサービスマネジメントに取り組むのであれば個人的に最低限取り組むべきプロセスをあげます。
①要求実現
②インシデント管理
③イベント管理
④問題管理
⑤構成管理
⑥変更管理
⑦リリース及び展開管理
⑧サービスカタログ管理
⑨サービスレベル管理
⑩情報セキュリティ管理
適用の順序と最低限は上記だと考えます。
適用の段階としては、
①②
③
④
⑤⑥⑦
⑧⑨
⑩
この塊で実施するのが良いと思います。
次回はどの位の期間を見込めばいいかについてお話ししたいと思います。
官公庁案件における調達仕様書の解釈のせめぎ合い
官公庁の案件では調達仕様書という民間でいうRFPがバイブルとなって、その解釈によって利害の不一致が発生します。
曖昧さの残る表現となるので、官公庁としてはなるべく多くの要求を通したいですし、実施業者としては、範囲をコントロールしなくては、キャッシュアウトしてしまいます。
民間と比べてより、文書遊びととも取れる論理の攻防が繰り広げられます。
論理の攻防においては、己の主張を押し通す一貫性が重要となります。言い切れるかどうかとも言えます。
論理のほつれがあれば、そこにつけ込まれて交渉は苦しくなります。
プロジェクトが大きくなればなるほど、現場とマネジメント側でガバナンスを確保する事が難しくなり、現場で起きている事を抑える事が難しくなります。
そう言った中で、現場で起きている情報を精度高く抑えて、自社の論理展開に一貫性を持たせるか。
官公庁案件では非常に重要になるので、これから取り組んでいきたいと思われる方は気をつけてみてください。
コンサルタントの力量、コンサルタントの育て方
久しぶりの投稿。大規模プロジェクトの参謀として睡眠時間を確保するのが大変な日々を送っています。
大きいプロジェクトだとどうしてもチームで仕事する必要があり、どうしてもチームの中には能力が高くないメンバーがいます。
コンサルタントの力量とはどう決まるのか。
どれだけの問題解決をしてきたかの量に尽きると考えます。
言い換えるならどれだけ問題を自分ごととして解決にもがいてきたか。
問題解決は逃げよう思えば簡単に逃げる事が出来ます。
自分の仕事ではない。これは上司の仕事だ。言い出せばきりがないです。これを自分事として向き合ってもがいた量が、大きな差になっているのかなと。
そういった問題解決を自分で経験しないと育たないと思ってしまうので、優しく一から十まで教えるということはせず、問題解決を部下自身にやってもらうアプローチを人材育成の取り組みをしています。
結果としては、潰れる人4に対して成果をあげる人6といった印象です。内訳をさらにいうと、言わなくてもどのみち成長した人と、言い続けて何年かして目が出た人もいます。
結局言っても本人に腹落ちするまでに個人差はあると思います。
ただ例外なくできる様になった人はエース級の存在になってます。
そして部下に問題解決を丸ごとやってもらうとともに、説いているのは、結局それを乗り越えていかないと、コンサルをする上では損するよ説いて話しています。
今の自分でいることは、自分の過去の選択の結果となのだよと。
小さなチーム、大きな仕事 働き方の新スタンダードを読んで
本業とは別に、社内の研究会で自社の新規事業開発を推進するにはどうしたら良いかとかねてより研究しています。
そこで最初は新規事業開発の制度を構築してみようとトライしてみました。制度によりアイデアを募り、公式な検討の機会を提供する事で、今より新規事業を考える数が多くなったら、考える文化を養おうといった感じです。
結論からいうと自社の規模や文化からだとそれは適さないという結論に至りました。
ビジネスを自分でやりたいと強い意志や行動力は、制度では作れない。新規事業開発の主要な成功要因は人に依存する領域が多く良さそうな事業計画を作ることではないというのが、我々の自社のケースでは結論です。
そこから一旦研究が煮詰まったので人のすすめもありこの本を読んでみました。
小さなチーム、大きな仕事――働き方の新スタンダード (ハヤカワ・ノンフィクション文庫)
- 作者: ジェイソンフリード,デイヴィッドハイネマイヤーハンソン,黒沢健二,松永肇一,美谷広海,祐佳ヤング
- 出版社/メーカー: 早川書房
- 発売日: 2016/12/08
- メディア: 文庫
- この商品を含むブログを見る
Ruby on Railsを作ったベースキャンプ（旧社名37シグナルズ）のジェフリーフリードをはじめとするメンバで書かれています。 新規事業や働き方に関するテーマで元はブログだったのか短いトピックスで読みやすい書籍です。
硬直化した官僚型の組織を変革していきたいという時に皆で読むといいかもしれません。
あまり内容は触れませんが、本質的でない事をいかに削ぎ落とせるか。という点は自分達の制度作りのアプローチの大きな問題点に刺さるものでした。
そもそも新規事業開発の制度自体が本質的でない部分をはらんでいたのです。
公式化された事業開発のプロセスは公式化された故に、どうしても承認にロジックが必要となります。机上で設計されたもの承認するには承認する側も判断材料を求めるので、説明が増えます。
それ自体が事業開発のハードルを上げてしまうのです。
しかしながら、非公式で事業開発をするというのは、それができるポジションでなければできません。例えば新しいサービスの反応を本業のかたわら訪問時に聞いてみるといったことも、内勤のひとはできません。
また、会社が関知せず事業開発計画が誰かに作成されるのを待つというのは何もしないと同じです。
ではどうすれば本質的な活動だけに絞り込むことができるのか。
次回に続きます。
顧客思考は自分事から。その先のコンサル視点
前回問題解決には顧客思考と論理的思考が重要だというお話をしました。
顧客の思考を考えるにはどうしたら良いか。
顧客だったらどう考えるか。顧客の立場によっても推測が可能です。管理者ほど企業自体の目標に資することを求められます。一方で現場ほど企業の目標ではなく、現場の業務をどう回していくかということに目線が行きます。
クライアントの立場は様々ですがベースは自分の立場ならどう考えるかだと思います。自分が顧客企業の部門長ならどう動くか。担当者なら何を思うか。自分事に置き換えることが重要だと思います。自分にフォーカスする必要があります。
一方で気をつけなくてはいけないのは、相手の立場を理解しつつ、相手の立場に縛られない事です。例えば現場の気持ち考えすぎて動けなくなるということもあります。
コンサルに求められる機能ということを念頭に置いた上で、あくまでも外部の立ち位置である事が重要です。
自分の問題として捉えられるか、一方で客観的な立場で捉えられるか。バランス能力が求められる気がします。
ちなみに私はまだ30代前半なので、キャリア的に部門長クラスのマネジメント視点は不足しがちです。そこを補う上でも、書籍などからマネジメントの方の視点を得ようと試みており、それは成果として繋がっている気がします。
日々勉強ですね。これホント大事。
問題解決能力を科学する
コンサルにおいて最も重要な能力は問題解決能力であると以前話をしましたが、どの様に向上させるのかについて考えていきたいと思います。
コンサルティングを行う際、全く同じ経験を使いまわせるケースというのはそんなに多くないです。
お客様から事例を求められても、その事例が必ずしもそのお客様にFitするものではなく、お客様に合った解決策を導き出して行かなくてはいけません。
もちろん仮説や持っていくべき方向性も見出すことができない様なケースは提案は慎重になります。提案段階ですり合わせをして合意をもらえた際には、その合意に基づいて進めます。
問題解決能力とは、答えのないところから答えを導く能力とも言えると思います。その一つとしては、概念を資料化して認識を合わせ合意形成を図る事があると思います。
物事を進めるのが上手い人とそうではない人の違いとして、考えを資料化できるかどうかというのが挙がります。特に成果イメージや進め方などは徹底的に資料化する事に慣れるべきです。これはそのまま提案力向上にも繋がります。
次に、分からない事を調べる調査能力も一つだと思います。人に聞く、ウェブ、書籍など情報を取ろうとするときに、どういった調べ方をすれば知りたい情報が導き出せるか。そこに対して、シナリオを組める必要があります。
順番が前後しましたが、調査能力によって得た情報から仮説を立てていきますが、仮説立案において重要となるのが論理的な思考能力と顧客思考です。
あえて顧客思考と書いたのは、顧客の立場ならこう考えるであろうという観点です。それが論理形成の前提となります。論理は前提を捉え間違うと意味がありません。なるべく精度高く顧客思考するために必要なのが、経験となります。こんなケースのお客様ではこんな悩みがあるといった感じです。それを正確に捉えれば論理が成り立っていれば説明が筋が通るため合意が得やすくなります。
こういった事の繰り返しが問題解決なんだと思う様になってきました。
顧客思考と論理的思考についてはもう少し深掘りして次回お話していきたいと思います。
コンサルタントの仕事術〜成果を示すデータ作り〜
コンサルタントの成果は時として非常に定性的で、最終成果を報告する際の特に上級マネジメントへの説明をする際に数値で成果を示さないと成果に納得してもらえないという事態が発生します。
例えばルールを作る仕事。
標準化されました。属人化が解消する仕組みができましただけでは納得感はないです。
そのためコンサルタントとしては、必ず成果を示すデータを作り込む必要があります。
これはコンサルタントだけでなく、自社で改善をする時も同様だと思います。
分かりやすい例は、顧客満足度向上。
顧客満足度向上の施策だけを設計しても、成果が施策を考えましたでは、通用しません。
施策を設計する前に、現状の顧客満足度を調査して、基準点が分かって初めて施策を実行した後の成果が説明できます。
いかにデータを作り込むことこそが、案件を上手くクロージングできるかどうかに関わってくるのです。
提案の際は顧客担当者は施策を打つ事にしか興味がなかったとしても、コンサルとしてデータ作り込む段階を設けるようにしましょう。
データの作り込みの例は次の機会でお話しできればと思います。
コンサルに求めるの機能とは
前回受注の秘訣として顧客が求めるコンサルの機能を理解する事、その機能をいかに際立たせるかという点をお話ししました。
では、どんな事を求められているのでしょうか。
いくつか挙げてみます。
①専門知識
②客観性
③リソース
③は労働集約型で単価は余り上げることは難しく、①は知識集約型となり、単価は高くなります。
私は①の仕事を常駐ではなく、訪問型にし複数進めることで、月当たりの単価を上げています。
担当者レベルでは①と③のニーズが高く、部門長以上では①②のニーズが高いと思います。
問題解決の主体を自社で担えるようになりたいという一種教育要素が強いと④のニーズも出てきます。
①の専門知識についても傾向があるように思います。
一つ目は業界動向。上級マネジメント程自分達が進むべき方向性を考える必要があるため、事業課題に対するITをどうしていくかという視点が必要になります。これに応えるためには社会背景や技術革新、業者、規模に応じたIT活用の形やIT組織のあり方などを語れる必要があります。
二つ目は業務知識。新しい事に取り組んでいくためには、実際に何をどこまでやればいいという点について知見が必要になります。例えばインフラをサービス化して提供する際にはどう行ったサービスをどんなSLAを設けて取り組めばいいかなど細部の事例が求められます。
担当者レベルで話をしていると後者のニーズを満たす事が求められますが、実は決裁者となる上級マネジメントの方は前者を求めてたりします。
提案をする際は、この様な求められてる機能を決裁者の視点で考える必要があります。
お客様の言われた課題を解決するだけの提案では、自社でやれと言われてしまいます。
競合他社との選定もありますが、社内リソースとの競合にも勝たなくてはいけないです。
ツールが社内リソースと競合しないのは、機能性が代替できないからとも言えますね。要はコンサルも代替ができないという論理をいかに作るかだと思います。
それでは今日はこの辺で。
コンサルとしての受注の秘訣
最近嬉しい事が二つありました。
一つは大型の官公庁案件が取れた事、もう一つは2年近くコンサルしていた企業の役員に直接話がしたいと言われた事。
特に二つ目は、いつもはIT組織の部門長とお話をしていましたが、
成果を報告後直接役員から2人で話したいとお言葉をいただきました。
直接話したいといってもらえるのは、話す事で何らかの気づきを得れると思っていただけだからかと思います。
実はこの二つの成果には共通点があり、特に受注につながる秘訣があると考えます。
それは、求められるであろう機能とは何かを理解する事だと思います。
コンサルを始めた頃、私はある小さなIT組織のコンサルに入りましたが、途中先方の部門長から「コンサルとしての資質を疑う」と痛烈な一言を言われた事があります。
当時の自分は、経験がとにかく浅いため、現状の問題点からあるべき姿を導き出すアプローチを取ってました。
このアプローチは現実解は出やすいですが、そもそもあるべき姿自体が既にシュリンクしており、ビジネスが求めるものに達していませんでした。
必ずしもこのアプローチが間違っているわけではないですが、この場合先方の部門長はコンサルに先生的な側面を求めており、取りまとめ役を求めていたわけではなかったと反省しています。一方で取りまとめ役、ファシリテーターを求められるケースもあります。
成熟度が高い組織ほど、コンサルに求めるのはファシリテーターで低い組織ほど先生的なコンサルティングな気がします。
私見ですが、コンサルファームでもこのコンサルティングと呼べるニーズに答えられる人は少なく、ほとんどがエンジニアリングの領域でしかないと感じます。
多くのケースでコンサルに求められる機能としては専門知識が挙がります。
先方がコンサルに期待する機能を如何に精度高く捉えるか、そして、その機能をいかに先方がそもそも実現したい事の中で必要性を高められるのか。
なんて事を考えたりしてます。
頼む側の立場にたってみれば、社内で発注する稟議などをあげるわけなので、会社を説得させる説明を担当の方からしてもらわないといけません。
機能として必要性を説く。
コンサルとしての求められる機能については専門知識以外にもあるので、その辺は次回お話したいと思います。
