• 業務のムダを省くぞ!
  • データの受け渡しを円滑にするぞ!
 そんな "ペーパレス化" や "脱Eメール" のプロジェクトで真っ先に思い浮かぶ業務は、やはり "販売関連業務" だ。
  • "見積書" の承認フロー
  • "受注情報" の共有フロー
  • "製品出荷" の作業進捗管理
確かに、これらの業務効率の改善は "売上の改善" に直結する。しかも毎日の様に "案件" を流す事になるので、それに伴って改善サイクルも短くなるだろう。

しかし、(a)業務フロー図を書いた経験が少ない、(b)BPMSツールの使い方に慣れていない、そんな組織の場合、、、実際に "業務プロセス管理(BPM)ツール" を使って、(1)業務の流れを定義し、(2)業務データの受け渡しに使ってみると、
  • 業務プロセスの定義範囲が大きすぎる
  • 業務データの入力項目が多すぎる
  • 条件分岐の設定が細かすぎる
  • 入力フォームの注意書きに統一感が無い
といった壁に直面してしまう可能性が高い。これが "販売に関連する業務" であれば、延いてはお客様への影響も出てしまうかも知れない。。。

もし、業務プロセス管理活動(BPM活動)を堅実に進めたいなら、工程数が少なく社内に閉じた業務をパイロットプロジェクトとして指定するのも一手だ。以下の "業務プロセス定義" は、工程数が少ない "経費申請(外部支払依頼)" となっている。口頭やメールでのやり取りをやめ、業務プロセス管理システムで案件データを流すようにすると、相互牽制や内部統制の観点で非常に意味がある。また、その集計データも非常に価値ある業務データとなるだろう。

[外部支払依頼(立替金精算およびクレジットカード番号登録支払を除く)]

"プログラミング不要"。。。 業務システムの世界でも、相変わらずホットなキーワードだ。
  • A.プログラミング知識が不要
  • B.プログラミング知識が必要
意味する所は Java や Python や Ruby といったプログラミング言語を使わないと言うだけの話だが、斬新で自分に合った IT 環境を創りたいと言うニーズが、そこにある。

少し乱暴なたとえになるが、たとえば "A.既製品の衣服をいじって使うべき" か "B.完全オーダーメイドの衣服を創るべき" かといった議論にも近い。どちらの方法にも長所短所があり、必要とされる IT 環境や、その運用者のスキルによって、採用すべき方法が異なる。

さて、以下の業務プロセス定義には [スクリプトタスク] と呼ばれるプログラミング知識を使う工程が組み込まれている。

業務の流れ全体は "A.標準処理アイコン" で表現しつつ、一部の工程において "B.独自の演算処理" が組み込まれている。実は、前回記事で紹介した "顧客名を入力する上流工程、そのテンプレート" を [スクリプトタスク] によってブラックボックス化させたにすぎない。つまり、データ処理の内容は全く同じだ。

[見積・受注・請求等の上流フロー]

日常の業務記録、、、"少しの工夫" で大きく価値が変わるかも知れない。例えば、もしも、全てのワークフロー履歴において、
  • 顧客名のユラギが無い
  • 顧客名が案件の [件名] に正確に表示されている
が実現されたとすれば、様々な "データ活用" が実現するだろう。

例えば、過去の記録を容易に検索できるようになる。(特定案件の検索)
例えば、特定の大企業に対して全営業マンが延べ何回往訪しているのかが集計できるようになる。(業務に閉じた集計)
例えば、"資料請求" から "見積提出" に至るコミュニケーションの推移や期間を分析できるようになる。(業務横断的な集計)

更には普段の活動も変わってくるかも知れない。例えば、闇雲に OJT を唱えるより、実際の業務記録を眺め見てもらう方が、新人教育になるかも知れない。ベテラン社員とディスカッションするより、実際の業務記録を眺め見ている方が、戦略案を発想しやすいかも知れない。

以下の業務プロセス定義は、実際に "顧客名入力" が行われる上流工程だけを記述した、言わばテンプレートだ。下流工程を加筆すれば、例えば "往訪報告" や "資料請求対応" など、様々な業務プロセス定義を簡単に作成できる。

[受注納品請求フロー]

  1. 第三者の生命財産をおびやかす可能性がある情報
  2. 業務記録として保存必要のない個人情報
  3. 犯行予告など法令に違反する可能性のある記述
  4. わいせつなど公序良俗に反する記述
といった情報が業務データに含まれてしまっている場合、どうすべきか?

あまり考えたくない話ではあるが、"目安箱フロー" や "内部告発処理" といった匿名性を高めた業務フローなど、業務によっては良くある話だ。ここでは、特権ユーザによる [データ編集] について考えたい。

そもそも業務データは、承認者のチェックを受けたり、差し戻し工程で修正されたり、、、最終工程に至るまでに何度も編集されるモノだ。案件が [終了イベント] に到達する頃には、会社の記録として仕上がった業務データになっているだろう。そして、その後は誰も編集しない。
この完成したデータについて多くのワークフロー製品では、(クラウド型ワークフロー Questetra においても同様)、特権ユーザですらデータ改変できない仕様になっている。もし仮に "後で編集ができてしまう" となれば、それはデータ改竄を許す仕組みであり "データ信頼性" あるいは "監査証跡" (コンプライアンス) の視点で問題になる。過去のデータに誤りを見つかけ場合には、新しい案件として然るべき手続をやりなおすべきだ。 (集計上のノイズになるなら、元のデータは [削除] する)

以下のワークフローは、 "Google アラート" (や "Analytics アラート" など) を自動的に取り込み、インターネット上の新着コンテンツ情報等を検知し、必要なリアクションを取ると言う業務だ。機械的に収集される情報であり、多くの場合は "情報共有不要" を選んで終了させる事になる。しかし、中にはその一部を [データ編集] すべきデータが含まれてしまう案件もある。この例は、特権ユーザに対して [データ編集] できる猶予を与えている所が、非常に地味な配慮ではあるが、秀逸だ。

[インターネットネット監視業務]