システム設計よりも業務プロセスの設計をやっている

業務プロセス設計についてラフなメモ書き。
主張は特に無く、アイデアをメモ。

【1】業務システムを設計・開発していると最近、システムを設計しているという感覚がない。
むしろ、業務を設計しているという感覚に近い。

すると、既存の業務フローを簡素化してシステム化するという仕事になりやすい。
特にERP導入の場合はそうだ。
既存の手作業のフローがどこまでERPの機能に吸収されて効率化されるか、がERP導入の一つの目的だから。

しかし、既存の業務フローを変更するのがとても難しい経験を何度もしている。
現場にとって、長年の業務フローが変わると、担当者の作業が増えたり減ったりするために、組織に影響をおよぼすのはご法度なのだ。

組織構造に関わるBPRの場合、ユーザ企業の責任者に承認を得て、業務フローを変更しなければならない。
既存の業務フローが変わることをきちんと合意しておかないと、せっかく決めた要件はユーザ担当者に簡単にひっくり返されてしまう。

今の業務が変わるのは困る。
長年このやり方でやってきたのだから、皆に説明してくれ、と。

だから、ERP導入や業務プロセスの改善は、経営者からのトップダウンの指示でなければ成功しにくい。
既存の組織が抵抗勢力になってしまうから、トップダウンで解決するしか無いのだ。

【2】僕はアジャイル開発が好きなので、ボトムアップでプロセス改善していくのが好き。
現場の創意工夫を生かして、自分たちの業務プロセスを少しずつ地道に改善していく方が好きだ。

でも、ERP導入やBPRは、経営層の力を使って上からのトップダウンで進めないと成功しないという経験をしている。
組織の壁を打ち破るには、社内政治が上手くなければ、何も進まない。

【3】情報システムの設計は、画面や帳票を決めるだけではない。
ユーザの操作や業務フローも考慮して、設計しなければならない。

ユーザの操作は、システムと人間の相互作用であり、そのインターフェイスが画面や帳票になっているだけ。
システムと人間の相互作用の流れを一連の手続きとしてまとめたものが、業務フローになる。

UMLやDOAでは、システムの設計技法は整っているが、肝心の業務プロセスの設計技法が不足している気がする。
BPMNが業務プロセスの設計技法を目指そうとしているが、何か物足りない。