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

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

たとえば、多くの企業で日常的に発生する「受注報告プロセス」でいえば、
  • [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アドレス」を使って、最初の処理工程(先頭工程のあるスイムレーン)の処理担当者が決められているところです。

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

[メール開始プロセス]

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

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

はい。来年(2017年)も頑張ります。

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

<トップ5記事>

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

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

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

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

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

[契約書承認プロセス(2010-11-12)]

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


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

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

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


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

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

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

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


国会議員による質問方法


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

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

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

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

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

「現場の業務プロセスが見えない」?


2016年秋、日本では『キュレーション・メディア』による「パクり行為」が大きく報道されている。

そもそも「情報を整理する行為」は価値のある作業であり、誰でも整理記事を投稿できる「情報共有サイト」(キュレーション・プラットフォーム)も価値ある存在と言える。しかし、サイト運営会社(東証一部上場企業)自身がクラウドソーシングを通じて記事を量産し、そのアウトソースの中で「パクり」をマニュアル化していた実態が明るみになったのだ。

キュレーション記事の制作プロセス

たしかに、
"当社は、この記事の情報及びこの情報を用いて行う利用者の判断について、正確性、完全性、有益性、特定目的への適合性、その他一切について責任を負うものではありません。"
という免責注記はあった。しかし、当のサイトが「健康や命に関わる記事」を集める情報共有サイトであったため、「著作権侵害」というよりもむしろ「モラル」が問われた形だ。そして、結果としてCEOが「記事制作のプロセスに問題がある」と謝罪する状況になったのだ。

DeNAプレス:CEOからのお詫びとご説明
"他サイトからの文言の転用を推奨していると捉えられかねない点がございました。この点について、私自身、モラルに反していないという考えを持つことができませんでした。(中略)。自分自身として心の底から自信の持てるプロセスを構築していくことを約束します。"

真実かどうかは知る由もないが、おそらくは「本当に業務プロセスが見えていなかった」のだろう。(と信じたい)。では、運営会社が責任をもって記事を書く必要がある場合、どのような業務プロセスを構築すれば良かったのだろうか?

[記事作成プロセス]
「業務フロー設計を試してみたいのですが…」

『プログラミング』の世界においては「唯一の道はプログラムを書いてみること」と言われる。事実、プログラミングを始める時、誰しもが "Hello World" という文字列を表示させるプログラムを書く。これと同様に『モデリング』の世界でも「業務プロセスを描いてみること」はとても大切だ。


以下の業務プロセスは、「メール受信」で開始され、「チャット投稿」で終わる。

そもそも業務プロセスとは、何かの『キッカケ』で始まり、そして幾つかの『工程』が続くものだ。しかし、この例には『チャットに投降する』という処理工程が1つあるだけだ。しかもそれは「コンピュータによる処理」(自動処理)であって「人による処理」は一切ない。(何ということだ!)

[チャット投稿フロー]