業務フローができるまで

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

まずは業務設計

電話・FAXでのコミュニケーション、紙やExcelファイルでのデータの管理から脱却し、業務効率化を図ろう! コストダウン、要員数削減、スピードアップ、品質アップを図ろう!

よく聞く話です。

そのためには、まず、現行業務分析を行い何が問題なのかを明らかにし、しかる後に新業務の設計を行うことになります。このとき、新業務は「新業務フロー」という形で記載することになります。

様々な業務フロー

ひとくちに「業務フロー」といいましても、様々な表記方法があります。

代表的な表記方法といえば

  • BPMN(Business Process Model and Notation)のビジネスプロセス図(BPD)
  • UMLのアクティビティ図
  • 産能大式フローチャート
  • 日本能率協会方式フローチャート
  • EA(Enterprie Architechure)の業務の流れ図(WFA)
  • IPAのシステム化業務フロー(発注者ビューガイドラインより)

あたりでしょうか。

どの表記方法がよいかはケース・バイ・ケースです。

作業マニュアルなどにはBPMNや産能大式がよいと思いますが、システム開発を念頭に新しく業務の流れを設計するのであれば、UMLのアクティビティ図やIPAのシステム化業務フローに準拠した表記方法がよいと思います。

業務の流れとデータの流れ

同じく場合によりけりですが、私は、業務フローからシステム的な要素(データベースや情報システムの処理)は排除しておき、業務フローとは別にデータフロー(機能関連図)を作成する方法を推奨しています。

先にあげたIPAのシステム化業務フローや、EAの業務の流れ図などは、業務とシステムの動きが一体となって描かれており、ちょっとしたシステムであれば業務とシステムの流れを一体でみることができて便利なのですが、場合によってはフローが複雑になりすぎて、業務の流れもデータも流れも、どちらもよくわからなくなってしまうことがあります。

業務設計は衆知を集めて行う

とはいえ、いくら表記方法を学んだからといって、業務をよりよく設計できるわけではありません。業務改善を検討する際には、ECRSの原則をヒントを考えるといいと言われています。

このECRS(すなわち、E:排除、C:統合、R:交換、S:簡素化)を実現できるかどうか?は情報システムで何ができるか?に影響を受けます。

 

例えば(極端な例ですが)、情報システムに明るくない人であれば「サーバー集中型のシステムを採用することにより、各営業拠点へのFAX送信はやめる」なんて案は出てこないかもしれません。

反対に、情報システムに明るいだけでは現実的な業務改善案とならないこともあります。ビジネス上の取り決めごとや現場の作業環境を考慮すると、むしろFAX送信したほうがいい場合もあるかもしれません。

その結果「サーバー集中型管理システムを利用しデータを一元管理し、各営業拠点へFAXを自動送信する」という案がでてくるかもしれません。

 

当たり前ではありますが、表記方法が重要なのではなく「衆知を集める」ことが重要です。

表記方法は衆知を集めるための共通言語と言えます。表記の精緻さよりもわかりやすさを重視して選択するのがいいでしょう。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

カテゴリーIT