前々回記事『第518話:業務プロセスの自動化とは?(その1)』では、
  • [A] 工程間における案件情報の受け渡しを自動化する
  • [B] とある工程における処理を自動化する
という業務プロセスの自動化についての2つの視点について述べました。

また、前回の記事『第519話:業務プロセスの自動化とは?(その2)』では、『[A] 受け渡しの自動化』が適用可能な範囲と実現方法について述べました。


今回の記事では『[B] 処理の自動化』が適用可能な範囲と実現方法について、整理してみたいと思います。


どの様な「処理」が自動化できるのか

◇ 完全な自動化(自動工程)

『[A] 受け渡しの自動化』が「とある工程から次の工程への案件情報受け渡し」をコンピュータに任せてしまう発想だったのと同様に、『[B] 処理の自動化』は「とある工程内の作業」をコンピュータに任せてしまいます。

たとえば「見積書の作成承認」のような人間依存度の高い業務プロセスにあったとしても、
  • 見積書 PDF ファイルを作成する
  • ファイルを添付してメール送信する
  • 見積概要を社内ソーシャルに投稿する
といった工程であれば、完全にコンピュータに任せてしまうことが可能です。

※ ちなみに『[A] 受け渡しの自動化』と対比させる必要が無い場合には、(『自動化』という言葉を使わず)、『業務プロセスの一部工程を「無人化」する』といった表現の方が分かりやすいかも知れません。


◇ 部分的な自動化

一方で、完全に任せてしまうわけではない工程もあります。

たとえば「見積書の作成承認」という業務プロセスにある「見積案を作成する」という工程で言えば、
  • 見積総額を計算する
  • 消費税額を計算する
といった支援機能は業務の省力化に貢献します。しかし、このケースは「見積書の作成」という工程が無人化できている訳ではなく、何らかの人間入力(ヒューマンインターフェース)が必要です。したがって、この様な工程は「ヒューマン工程」(人間工程)に分類すべきだと言えるでしょう。

[見積書の作成承認プロセス]

前回記事『第518話:業務プロセスの自動化とは?(その1)』では、
  • [A] 工程間における案件情報の受け渡しを自動化する
  • [B] とある工程における処理を自動化する
という業務プロセスの自動化についての2つの視点について述べました。

今回の記事では『[A] 受け渡しの自動化』の適用範囲について、整理してみたいと思います。
※『[B] 処理の自動化』については次回記事で整理します。


どの様な「受け渡し」を自動化できるのか

◇ フローの定義方法

日常業務において「案件情報」がスムーズに受け渡しされるようになるには、(当然ながら)、「業務の流れ」が定義されていなければなりません。

案件情報を「紙」や「カンバン」で管理していた時代であれば、「業務の流れ」は業務マニュアルなどの自然言語(文章)で記述しておけば良かったと言えます。しかし、コンピュータに回付してもらうためには「コンピュータに理解できる方法」で「業務の流れ」を定義する必要があります。

言い換えれば「コンピュータに理解させられるフロー」こそが『[A] 受け渡しの自動化』の適用可能範囲と言えるでしょう。

[受注報告プロセス-役員通知]

そもそも「業務プロセス」とは何か?

業務プロセスとは「いくつかの工程」を並べたものです。

たとえば、多くの企業で日常的に発生する「受注報告プロセス」でいえば、
  • [1] 営業部社員:受注内容を登録する
  • [2] 営業リーダ:受注内容を確認する
  • [3] 営業部部長:受注内容を承認する
といった「工程」で形成されます。

自動化、2つの視点

そして今日、「生産性向上」のキーワードのもと、話題にあがることが多くなった「業務プロセスの自動化」は、
  • [A] 工程間における案件情報の受け渡しを自動化する
  • [B] とある工程における処理を自動化する
のいずれかの意味で、あるいは両方の意味で議論されています。

「A:受け渡しの自動化」とは?

第1の視点は「案件情報の受け渡しを自動的に行いたい」というニーズです。

「自動」の反対語は「手動」や「人手」であり、つまるところ「人間でない何か」に受け渡しを担ってもらうと言う話になります。今日においてはやはり、「コンピュータとインターネットによる自動化」が基本となります。

「ワークフロー・システム」と呼ばれる製品にとっては、必要条件ともいえる機能でしょう。そして、その様な自動化環境では、
  • [1]の工程のアウトプットが入力されれば[2]の工程に、
  • [2]の工程のアウトプットが入力されれば[3]の工程に、
自動的に伝達されるようになります。

もちろん「あらかじめ業務フローを設定しておく必要があります。そしてまた、現実的には、個々の案件情報が「デジタルデータ」で管理されていること(ペーパレス)が前提となります。

ワークフローによる「受け渡し」

そして今日では、フローの分岐やループに対応する製品が数多く存在します。

たとえば、以下の業務プロセス定義(業務フローの設定)は、
  • [1] 営業部社員:受注内容を登録する
  • [1x] 営業部社員:(差し戻し受け)改めて受注内容を登録する
  • [2] 営業リーダ:受注内容を確認する
  • [3] 営業部部長:受注内容を承認する
  • [4] 営業部部長:100万円超案件の内容を役員報告する
を表現しています。(国際標準表記法 BPMN: Business Process Model and Notation による)

[受注報告プロセス]

外部トリガーによるワークフロー開始

前回の記事『第516話:ワークフローを「メール」で起動しておく方法』では、「メール着信」をトリガーとするワークフローについて書きました。きっと『メール以外にも「ワークフローを開始する方法」はありますか?』という質問をいただくことになるでしょう。(まだ頂いておりませんが…)

はい、あります!

クラウド型ワークフロー『Questetra BPM Suite』の場合、提供されている API は以下のような体系になっています。この中にある『B1.プロセスの開始』は HTTP/WebForm/Email のすべてに対応しています。つまり「メール着信」に限らず、「Webフォーム入力」や「HTTPリクエストの受信」をトリガーにしたワークフローを設計することが可能です。
  • A. ワークフローシステムが常に提供する『ソフト開発 API』 (OAuth2/Basic)
    • A1. ユーザの操作 (ワークフローAPIs)
    • A2. システム管理者の操作 (システム設定APIs)
  • B. 各業務アプリが提供する『プロセスモデル接続 API』
    • B1. プロセスの開始 (メッセージ開始イベント) (HTTP/WebForm/Email)
    • B2. プロセス途中での待ち受け (メッセージ受信中間イベント) (HTTP)
    • B3. プロセス途中で外部発信 (メッセージ送信中間イベント/自動工程) (HTTP/Email)

ワークフローを開始させるワークフロー

少し「応用編」になるのですが、、、『B3. プロセス途中で外部発信』という機能もあるので、
  1. Xプロセスで「HTTPリクエスト」が『送信』されるように設定し、、
  2. Yプロセスが「HTTPリクエスト」の『受信』で開始されるように設定しておけば、
XYワークフロー間の連携も可能となります。つまり、
といったことが実現できます。


さて、、、今回の記事では更に踏み込んで、CSVデータを使った「複数案件の一括開始」について考えてみたいと思います。

[電話アンケート・プロセスの一括呼び出し(親プロセス)]

[電話アンケート・プロセス(子プロセス)]

新年あけましておめでとうございます

日本のお正月は、1月1日から3日が「休日に近い状態」となり、4日から少しずつ「平常」に戻っていきます。

たとえば『証券取引所』が取引を始めるのは、(土日が重ならない限り)、1月4日と決められています(12月31日から1月3日は全面休場)。また『行政機関の休日に関する法律』では、12月29日から1月3日が「行政機関の休日」と定められています。

ということで、今日(1月2日)は、日本中の多くの社会人が、ぼぉ~っと過ごしています。

しかし、企画系のオシゴト(※)をしている人であれば、こんな休日であっても「閃いたアイデア」をワークフローに載せておきたいと考えるかも知れません(??!) ※ 記者、作曲家、新商品企画、などなど

メールでも開始できる業務プロセス

以下のワークフローは、一般的な申請系ワークフローの様に〔1.アイデア登録〕から「プロセス開始」させることもできますが、別途、メールによって〔1x.アイデア登録〕を開始させておくことが出来るワークフローです。

ポイントは、メールの「Fromアドレス」を使って、最初の処理工程(先頭工程のあるスイムレーン)の処理担当者が決められているところです。

「閃いたアイデア」程度なら自分あてにメールするだけでも十分だ、、、というウワサもありますが、この仕組みを理解しておけば、たとえば「他システムとのメール連携」などへの応用もできます。連休を活かして、クラウド型ワークフローの無料版で「業務モデリング」の体験をしてみるのも良いかも知れません。

[メール開始プロセス]