システム開発者が使うドキュメント手法には色々あります。

・データの流れを中心に記述するDFD

・色々な図を使用して対象をモデリングしていくUML

・フローチャート記号を使って伝統的に書かれる業務フロー図

などなど。

 

　

各々に長所・短所があるのは当然ですが、一様に言えるのはシステム開発者側（システム開発者が作る）のドキュメント手法である。と言う事でしょう。

これも、ある意味当然かもしれません。

 

業務システムを設計・開発するのはシステム開発者ですから、その人が社内（つまり従業員）であっても、社外（システム会社の人間）であってもシステムを設計・開発する為の手法が必要となるのです。

ただ、この人達はシステム構築の「プロ」ですので結構難しい記述方法でも理解しますし使いこなします。

 

ここで問題は、業務が複雑になっている（Webやスマホ等インターフェースの多様化など）にも関わらず社内にシステム開発のプロが居なくなっている事です（大企業は除きます）。

そうなると、システムの設計・開発は外部のシステム会社になるのですが、その人達は対象の会社の業務プロセスに精通していません。

 

つまり、設計する前の「業務のプロセスを知っている」と言う前提が崩れ始めています。

その状態で、いきなりシステム開発者が自分の情報・理解だけでドキュメントを作ってもユーザーはそれを正確に読めないので「認識のずれ」が発生していても指摘できません。

 

これは致命的なのです。

 

 

そこで、"BPMNレベル１"です。

ユーザーのユーザーによるユーザーの為のドキュメント手法なのです。

ただ、これもドキュメント手法ですので最低限の記述ルールがありますので、その習得は必要です。

また、業務にある程度精通している人達が一緒に作り上げていく必要があります。

そうなりますと、中小企業では人選とその人達の時間調整が結構大変になるでしょう。

 

私は今、中小企業がBPMNを使って自社の業務プロセスを整理・分析する為のサポートが出来ないか　を模索しています。

 

「BPMNをいざ書こうとすると結構大変なんだよね」という点を少しでも減らしたいと思っています。

 

「ユーザーの業務システム」のドキュメントが「ユーザーの為になっていない」と言うのは、やはり「おかしい」と思うからです。

 

 

 

次回は、「BPMN・・・結構地味な作業が・・・」です。