ITサービスマネジメント実践編-プロセスとフロー詳細版

こんにちは。本日は、よく混乱して使われているプロセスとフローの話。

なお、これは、本当に全てのITSM実務者に理解してほしい最重要概念です。

※なお、本日の内容は、ITILv3のファウンデーションを理解している前提で書いています。

突然ですが、インシデント管理プロセスとインシデント管理フロー。この違いを明確に説明できますか？

本日結論を先に書きますと。

インシデント管理プロセス＝インシデントマネジメント処理標準
インシデント管理フロー＝インシデントコントロール手順

です。英語でマネジメントは「管理」、コントロールは「制御」ですが、実務としてこの管理と制御を厳密に区別せず取り扱っている人が多いです。

さらに、プロセスとフローの違いも明確に区別しない（できていない）人が多い。

プロセスは「処理」です。フローは「流れ」です。

大事な概念なので、再度記載しますが、本来的にITILv3及びITIL4で謳っていることはプロセスは「管理」するための「標準」です。マネジメントの考え方を整理しているだけであって、制御方法を定義していません。従って、それら管理するための標準を具体的な手順及び流れに落としたものがフローです。(図1参照)

従って、プロセスはあくまで処理のガイドラインとして使うものなので、具体的な事象にフォーカスしたものをプロセスと名乗ってはいけないのです。あくまで汎用的に示したものである必要があります。

さらに、「フロー」と「作業管理フロー」を同一視してはいけません。

ちょっとごちゃっとしてきたので整理すると変更管理で例えて整理します。

変更管理プロセス＝変更が必要となる作業を実施するために汎用的に定めた処理標準
変更管理フロー＝変更が必要となる作業を実施するためITSMで定めた手続きの流れ
変更作業管理フロー＝「変更管理」を必要とする作業をE2Eで管理するために定めた手続きの流れ

です。

したがって、「変更管理フロー」は「変更管理を必要とする作業管理フロー」ではありません。それが成立できるのは、ユーザが「自分の依頼した作業は変更管理を必要とする作業である」と理解している場合のみです。（細かく説明しなくてもE2Eに関わる全ての関係者が知っている状態）
しかし、ユーザおよび顧客は自分の依頼する作業が変更管理を必要とするものかどうかなんて知ったこっちゃないですし知りません。正確に言えば知る必要がない。よって持って、それらの基準は変更管理フローに至る以前の段階で判断する必要があって、そうなると当然インシデント作業管理フローにそのエッセンスを取り入れる必要がある。

それらプロセス同士の関係性を加味してフローという具体的な手順に落とし込んでいく。それがフローになるので、「変更管理を必要とする作業管理フロー」を定義したいのに、その作業管理フローの名前を「変更管理フロー」と定義してしまうと、変更管理プロセスと混同してしまう可能性があります。加えて、そもそも具体的に変更管理を行う上での登場人物と役割、手続を整理した「変更管理フロー」が必要なので、お勧めしません。「変更管理を必要とする作業管理フロー」が正しい言い方になります。(図2参照)