業務フローの話です。
僕は現状のBPMNのみを書くことが多いです。
システム導入後のBPMNは必要に応じてですね。
設計書や資料の価値は、どれだけ見返されるかで測定できると思います。
問題や課題に関するビフォー・アフター（現状とあるべき姿）の洗い出しは困難を極めますが、
業務フローのビフォー・アフターは簡単です。
業務フローは、人の動きを観察またはヒアリングし、書き起こしていくだけです。
事実と見比べるだけなので、合ってるか間違ってるかの判断がしやすい。
システムに精通した人であろうがなかろうが、
実際にその業務に携わっている人となら業務フローで話ができるものです。
最初は拒否反応を示す人もいますが、多くの場合自分の業務の流れを再確認できるため喜ばれます。
案外現状の業務フローを見ると、普段の作業では気付かなかった簡単に改善できるポイントが見つかります。
システム化する前にカイゼンが始まったりもします。
業務に直接携わっていない人が担当の場合、詳細で話合う事は難しいです。
詳細に書いても詳細はわかりませんし、その人にとって作業者の正確な業務フローなどどうでも良かったりします。
とはいえ、システム開発者からすると合意に必要なので、かなりデフォルメした絵で説明することになります。
厳密には違うけど大体合ってる。
何とも言えない合意で進めることになります。
プロジェクトの担当者にちゃんと実態を説明できる人がいないと、
現場導入の際、実態とズレてトラブルになる場合があります。
少し矛盾した話をします。
正確な業務フローはありがたいのですが、
システム開発の視点から見た場合、「そこまでの詳細はいらない」という場合が良くあります。
直接、業務に携わっている人はシステムの事がよくわからない場合が多く、不安で全てを盛り込みたがります。
一方で、システム屋はシステム開発に関連する部分しかいらないというのが本音です。
業務に携わっている人が業務フローを書くと、
現状の仕事に不満や想いがあるため余計な情報が増えます。
平たく言えば読みづらい。
また、全ての不満をシステムに反映するわけにはいかない上に、
書かれた内容が仕様になってしまう可能性もあります。
やらないことを決める意味でも業務フローは大事です。
対象外を明確にしておくのが鉄則です。
業務フローは開発側が書き、合意を取りながら完成させていく方が効率が良いように感じます。
個人的な意見ですので、ご参考まで。
雑音の少ない業務フローは事あるごとに見返せるので重宝します。
アフターは当然システムが出てきますが、ビフォーもシステムが出てくる場合があります。
昨今、システムは業務に欠かせないので、まず登場します。
人の作業フローは上側にシステムは下側としっかりわけて作業とシステムの関係を線でつなぎます。
そうすることで、視覚的かつ直観的に人の作業のみもしくはシステムのみの関係を見ることができます。
我々システム屋にとって"既存"システムは脅威です。
既存システムと仲良く共存する方向でいくのか、排除する方向にいくのか運命の分かれ道です。
なるべく旧システムの仕事を奪わないようにかつ干渉しないようする方が良いのですが、
ヨシっ！！この際この古い仕組みも刷新しよう！！
みたいになると地獄です。
良くしようと取り組み始めたプロジェクトなのに、ゼロを目指す方針に早変わり。
融通が利かない、でも痒い所に手が届く、長い付き合いの元カノ（旧システム）と未来永劫比べられます。
仕様：
既存通り
以上男はつくづくリプレイス作業に向きません。
別れた相手は「名前を付けて保存」。
アフターの業務フローは書きたければ書けばよいと思います。
さほど見返すこともないでしょう。
大抵僕はこんな感じで業務フロー資料を用意します。
- デフォルメしたビフォー・アフター（ただの絵です。イラストたくさん。）
- 真面目に書いたビフォーBPMN
ついでに、現場猫がかわいいので初コラボ。
工場勤務には沁みます。
業務フローのビフォーDX、アフターDX
おわり
コメントを残す