第520話：業務プロセスの自動化とは？（その３）

前々回記事『第518話：業務プロセスの自動化とは？（その１）』では、

• [A] 工程間における案件情報の受け渡しを自動化する
• [B] とある工程における処理を自動化する

という業務プロセスの自動化についての２つの視点について述べました。

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


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

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

◇ 完全な自動化（自動工程）

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

たとえば「見積書の作成承認」のような人間依存度の高い業務プロセスにあったとしても、

• 見積書 PDF ファイルを作成する
• ファイルを添付してメール送信する
• 見積概要を社内ソーシャルに投稿する

といった工程であれば、完全にコンピュータに任せてしまうことが可能です。

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

◇ 部分的な自動化

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

たとえば「見積書の作成承認」という業務プロセスにある「見積案を作成する」という工程で言えば、

• 見積総額を計算する
• 消費税額を計算する

といった支援機能は業務の省力化に貢献します。しかし、このケースは「見積書の作成」という工程が無人化できている訳ではなく、何らかの人間入力（ヒューマンインターフェース）が必要です。したがって、この様な工程は「ヒューマン工程」（人間工程）に分類すべきだと言えるでしょう。

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

第519話：業務プロセスの自動化とは？（その２）

前回記事『第518話：業務プロセスの自動化とは？（その１）』では、

• [A] 工程間における案件情報の受け渡しを自動化する
• [B] とある工程における処理を自動化する

という業務プロセスの自動化についての２つの視点について述べました。

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

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

◇ フローの定義方法

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

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

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

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

第518話：業務プロセスの自動化とは？（その１）

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

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

たとえば、多くの企業で日常的に発生する「受注報告プロセス」でいえば、

• [1] 営業部社員：受注内容を登録する
• [2] 営業リーダ：受注内容を確認する
• [3] 営業部部長：受注内容を承認する

といった「工程」で形成されます。

自動化、２つの視点

そして今日、「生産性向上」のキーワードのもと、話題にあがることが多くなった「業務プロセスの自動化」は、

• [A] 工程間における案件情報の受け渡しを自動化する
• [B] とある工程における処理を自動化する

のいずれかの意味で、あるいは両方の意味で議論されています。

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

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

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

「ワークフロー・システム」と呼ばれる製品にとっては、必要条件ともいえる機能でしょう。そして、その様な自動化環境では、

• [1]の工程のアウトプットが入力されれば[2]の工程に、
• [2]の工程のアウトプットが入力されれば[3]の工程に、

自動的に伝達されるようになります。

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

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

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

たとえば、以下の業務プロセス定義（業務フローの設定）は、

• [1] 営業部社員：受注内容を登録する
• [1x] 営業部社員：（差し戻し受け）改めて受注内容を登録する
• [2] 営業リーダ：受注内容を確認する
• [3] 営業部部長：受注内容を承認する
• [4] 営業部部長：100万円超案件の内容を役員報告する

を表現しています。（国際標準表記法 BPMN： Business Process Model and Notation による）

[受注報告プロセス]

第517話：ワークフローを大量に起動する方法

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

前回の記事『第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ワークフロー間の連携も可能となります。つまり、

• “納品プロセス” から “請求プロセス” が自動開始されるように設定する (M411)
• “次回の請求” を忘れないように、次回処理分が自動開始されるように設定する (M412)
• フロー途中でサブプロセスを呼び出し、その処理結果を待つように設定する (M413)
• 複数の業務プロセスに流れたデータを集約するための特別な業務プロセスを用意する (M414)

といったことが実現できます。


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

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

[電話アンケート・プロセス（子プロセス）]

第516話：ワークフローを「メール」で起動しておく方法

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

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

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

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

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

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

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

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

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

[メール開始プロセス]

第515話：契約書の承認はワークフローで！（改善編）

2016年も「契約書フロー」や「稟議書フロー」が根強い人気

今年最後の投稿です。2016年も毎週欠かさず業務テンプレを配信することができました。これもひとえに読者の皆様からの「応援メッセージ」や「いいね」のおかげです。

はい。来年（2017年）も頑張ります。

さて当ブログでは、これまで過去7年間に渡る合計500本以上の記事（と800近くのテンプレート）を公開していますが、今年2016年は、どんな記事が良く読まれたのでしょうか？　早速、今年一年間のアクセスログを調べてみました。

＜トップ5記事＞

• 2010-11-12: 契約書締結をワークフローで管理しよう！
• 2015-07-06: マイナンバー制度をワークフロー化する(4)
• 2011-10-03: 障害発生時こそワークフロー手順に従った報告を！
• 2013-03-25: 上司とその上司に稟議を回す業務フロー図の書き方２
• 2011-05-02: 稟議書フローの「承認タスク」は同時並行処理で！

やはり「契約書」や「稟議書」のオンライン承認（ペーパレス化）は根強い人気テーマの様です。（注：日本語版の調査結果です）

今ならどう書く？「契約書承認フロー」

しかし、この記事、すでに6年も前の記事です。

毎日毎日、業務プロセスを描いている身としては、やっぱり「今なら違うプロセスをお勧めするなぁ」などと思うワケです。（現在、日本語での Google 検索で「契約書 ワークフロー」の検索１位になっているので、「よく読まれる」のは仕方ないのですが。。。）

ということで、今年最後の記事は「契約書承認プロセス」をシンプルに描き直してみたいと思います。

[契約書承認プロセス（2010-11-12）]

第514話：政治家こそ「生産性向上」を実践して見せよ！

政治家や官僚達のワーク・ライフ・バランス

日本も他の先進国と同様、既存の「福祉国家の路線」に限界を感じている。

つまり「行政のスリム化」（簡素な効率的政府）という基本方針については、どの政党も合意するところとなっている。時代の流れには逆らえない。

※ ◆1930年代に起きた倒産の連鎖（世界恐慌）を経て、人類は「単なる自由放任主義」を否定し、大きな政府による「社会保障」を肯定するに至った。　◆1970年代に起きた経済の停滞（オイルショック）を経て、人類は「福祉国家の非効率」を自覚し、小さな政府による「競争社会」への回帰を容認するに至った。　◆1990年代以降の企業活動は国境を越え税収確保も困難となり、またインフラ維持や医療費増加もあり、結果として既存の「福祉国家路線」は立ち行かなくなる。


しかしながら「国会における行政効率化の議論」は全くかみ合わない。

たとえば、(1)「ハンコ行政」をやめる、(2)「特殊法人の民営化」を推進する、(3)「健保・年金・所得税などのバラバラ徴収」を一元化する。。。 議論すべき改革の方向性は多種多様だ。しかしどんな方向であっても、大きくなってしまった政府を「小さくする方法」や「小さくする手順」について、合意を形成するのは容易ではないようだ。

その結果、国会議員達は同じような質問を繰り返し、内閣は同じような答弁を繰り返す。

『質問書』は深夜に提出され、『答弁書』は夜中に作成され、『大臣レクチャー』は早朝に行われる。国会自身が「行政の肥大化」を助長させている。彼らの言う「生産性向上」は、もはや寝言でしかない。

国会議員による質問方法

そもそも国会議員の仕事は、テレビ映りの良い「議場パフォーマンス」ではない。

民間に言わせれば、朝9時から夕方まで大臣ほか時給の高い人達を拘束しつづける委員会審議なんぞ、単なる「長時間会議」にしか過ぎない。もし「取締役会」が朝から晩まで開催され、挙げ句の果てに一部の取締役達が「退席アピール」をしているとすれば、投資家達はどう思うだろう？

内閣提出法案や国政全般について正すべき事項があると感じるなら、「質疑」よりも「質問」（質問主意書）をもっと多用すべきだ。そして、（民間のFAQサイトではないが）、質問をするときは過去の質問（FAQ）を参照すべきだ。あえて同じ質問をしたいなら、「FAQ-20161213-01 の答弁内容に変化はないか？」と聞けば良い。そうすれば内閣は「はい」とクリックするだけでよくなる。

「審議時間が短い」とだけ連呼する議員に、「国益」を語る資格はない。（むしろ質問の数をKPIとせよ）

[内閣答弁作成プロセス]