プロセス設計はユーザと決めないと後悔する

ITIL V3の考え方で、4つのPというものがあります。
内容としては、Process(プロセス)、People(人)、
Products(プロダクトまたはツール)、Partners(パートナー)となります。

この4つのPはバランスよく組み合わせて機能していく事で効果が出ると言われています。
どのPから機能させていけばいいの？というのは、一概には言えませんが、
今回は「なぜ、システム開発は必ずモメるのか？」という本の内容を交えて、
タイトルにも記載している、なぜ、プロセス設計をユーザと決めないと後悔するのか、というのを記載していきます。

まず、本の概要ですが、システム開発における苦悩と、著者からの教訓が会話形式にて記載されています。
IT紛争の判決内容、プロジェクトを行う上で使用できるチェックリストの記載があり、個人的に参考になっています。

本の内容で取り上げていきたいのは、「システム開発はユーザとベンダーの共同作業」という点です。

ベンダーだけでシステム開発を行うと、ユーザの業務を考慮したシステムにならず、効率が悪化してしまい、
投資目的でのシステム化がコストとして逆転してしまいます。
こうした事を防ぐ為としての対策として、ユーザに積極的に関わってもらう為に、演じ物を用意する等の、
言わば啓蒙活動を行っていきます。

これは、システム開発だけでなく、プロセス設計にもあてはまります。

設計の時点でユーザの意見が考慮されていれば良いのですが、
マネージャーの人間が設計を行い、さらに、業務に追われる等で、
ユーザの設計に対する参画意識が保てない、といった事が発生すると、業務と乖離があるプロセスができてしまいます。

業務と乖離のあるプロセスを設計してしまうと、ユーザの努力(負荷)による対応が増えます。
これではユーザのモチベーションが下がり、他のPが良いものであっても機能しなくなってしまうので、
効果が出にくくなります。

乖離のあるプロセスでユーザが努力していて、その場その場では機能していても、
抜本的な解決にはなっていない為、ふとしたきっかけで、ある日突然破たんします。

破たんして初めて予兆が出ていた事に気付き、リアクティブな対応を続けてしまう事になります。
想定外のコストも発生し、負の連鎖が始まってしまいます。

以上が、プロセス設計をユーザと決めないと後悔する理由です。

効果の出るプロセスを設計する為には、プロセス改善を行う目的、アウトプット例をユーザへ積極的に出していく事によって、
興味付けを定期的に行っていきます。
ユーザより意見をヒアリングし、ユーザが実施しやすいプロセスに変えていく形となります。

弊社はコンサルティングもありますが、プロダクトを使用してプロセス改善のお手伝いをしています。
プロダクトに需要がある為、現在も後悔している/後悔しそうなお客様はまだまだいる状態です。

競合製品もありますが、興味がありましたらご相談いただければと思います。