コンサルタントの仕事術〜ITILプロセス設計編（変更管理）〜

おはようございます。atomです。

今日はITコンサルタントの業務の一つであるルール文書（規程、基準）などの作成についてお話しします。

私の主要コンサルティングの領域はITサービスマネジメントの領域なので、インシデント管理、変更管理などのルール作りをプロセス設計として取り組む事が多いです。

プロセスとは、特定されたトリガーを起因として、定められた成果を出すための一連の活動といった感じに定義されています。

プロセス設計をする上では２つの軸で考えます。

１つはここの変更の始まりから終わりまでの一連の流れ、もう１つは変更を束でどう管理するか。

前者を作業プロセス、後者を管理プロセスという軸で表現します。

例えば変更管理を例に取ると、変更の起因と種類を特定して、類型化し、類型化されたケースごとに承認のチェックデジットを設け、リリースとの連携などを決めていきます。

どういう流れを設けるべきかは、大体書籍を見れば分かります。顧客の成熟度に合わせてどの粒度に設定するかといった所にノウハウがあったりします。

一方で管理プロセスは、変更管理の作業プロセス全体をどうPDCAするかという観点で設計していきます。

誰が、どのタイミングで、どういったチェックを、どういった評価指標で実施するか。どんな評価指標を設定するかなどに特にノウハウの要素があると思います。

この両者を考える上ではもちろん体制なんかも考えます。

ツール導入に合わせてプロセス設計をする場合、ここでいう作業プロセスの設計がされるものの管理プロセスの設計がされず、プロセスとしての成熟度が回した結果分からないといった事があります。

ITILを活用してプロセスを改善するといった議論から、いつの間にかいかに現状の業務をツールに載せるかに議論が終始してしまうというケースに陥りやすい所です。

ここで重要になるのが、何を成果とするかです。ここも顧客にあった成果レベルの指針を事例などから提示する事が求められます。

そして、この成果レベルの合意が甘いとどこまで議論すれば良いのか分からなくなり、プロセス作りが長期化したりします。

コンサルタントとしての求められるのは、当初描いた成果レベルを実現するための設計において、いかに先回り出来るかだと思います。

先回りが必要なのは、議論の中で都度軌道修正をしないといけないので、先回りしておかないと、その場で最適解が出せないからです。その場で指摘できないと、流れは引き戻すのは非常に大変です。

したがっていかに準備して臨めるかが非常に重要になります。

前半プロセス設計手法、後半コンサルタントの心得みたいになってしまいましたが、どちらも大事なので、今後も少しずつお話しできればと思います。