ワークフローサンプル: 2014/12

2014年も残すところ、あと数日。。。

今年も読者の皆さんに支えられ、何とか「毎週投稿」を実現する事ができました。このエントリーで2014年の52本目、通算で411本目（※）の業務プロセス提案になります。 Wokflow Sample 読者の皆様、、、特に「××なプロセスを書いてみて」とリクエストを下さった皆様(!)に、、、また投稿に対して「とっても参考になった」などのコメントや感想を下さった皆様(!!)に、この場を借りて御礼申し上げマス。

※ 2014年＝51本、2013年＝52本、2012年＝53本、2011年＝186本、2010年＝68本
※ 各記事に添付の業務サンプル [QAR] は１つ２つ、と言うコトで通算のサンプル数は約700本位になっています？？

振り返れば、、、特に当ブログの開設当初は、内外から「3日坊主」がウワサされていたモノです。まぁ確かに、中には大したことない業務プロセス提案も混ざってはいるのですが、、、いや、これからも、細く(?)、永く(!)、シブトく(!?!)、続けていこうと思っております。今後とも「叱咤激励」および「忌憚のないフィードバック」につき、宜しくお願いします。

◆2014年に、最も読まれた日本語記事

◆2014年に、最も読まれた英語記事（に対応する日本語記事）

Improving Your Accounts Payable Process in Steps (2011-05-13)

（買掛金プロセスを少しずつ改善する）

Reporting Each Client Visit Right After Returning to the Office (2011-02-15)

（往訪直後に「１件ずつ」の往訪報告フロー）

Visualization of Testing Process in Software Development (2010-12-20)

（ソフトウェア開発におけるテストフローを可視化する）

Workflow Across The Enterprise, From Quotation To Payment Confirmation (2011-06-05)

（企業をまたぐワークフロー、見積から入金確認まで）

Is Complaint Management Perfect for Training New Employees? (2011-04-01)

（クレーム対応は新人育成に最適？）

さて、、、
以下2014年最後のエントリーは、非常にシンプルな「Blog エントリー業務フロー」の御紹介です。

[Blog エントリ業務]

「後は任せた！！」

前回エントリでは『郵便物郵送システム』というバックエンドについて色々なパターンを紹介した。つまり、

社員が上流工程にある「入力画面」で申請
別業務のワークフローが API 経由で通知

などを経て『郵送ファイル・送付先情報』が届く仕組みだ。バックエンド側では、そのデータにもとづいて「書類の印刷、押印やサイン、封入郵送」といった作業がシステマチックに行われる。

フロントエンド側の工程（上流工程）において、「契約書表現のカケヒキがあった」とか、「時候の挨拶を調べるのがタイヘンだった」とか、、、そう言う案件事情に左右されることはない。粛々とミスなく遅滞なく郵送するのがバックエンドとしての使命だ。（まさに「裏方」）

さて今日、、、『バックエンド』と言う言葉は「Backend as a Service」と言うフレーズで見聞きする事が多くなった。要するに、エンドユーザの目に直接触れるスマホアプリ開発に注力し、バックエンド側の処理は「Backend as a Service」に任せてしまうのだ。もって全体システムの開発工期が短くなる。

業務アプリの世界でもスマホアプリ開発ニーズは高い。

たとえば、オフィスに BEACON 発信器を置く。そしてスマホがその日初めて検知した時刻を「出社時刻」としてバックエンドに投げる。またその BEACON 発信を2時間以上検知しなくなった時には、その検知しなくなった時刻を「帰宅時刻」としてバックエンドに投げる。そんな Bluetooth Low Energy （BLE）テクノロジを用いたアプリも積極的に業務改善に活用する企業もある。

では以下の様な「日報」のワークフローにおいて、その「出社時刻」と「帰宅時刻」を自動的に取り込むには、どの様な API を追加したら良いのだろうか。

[日報ワークフロー]

「Backend としての BPMS を強化する！」（Business Process Management System）

ナニコレ？じゅもん？？しかしコレ… IT 業界人の間では「珍しくない表現」らしい。要は、（沢山のコンピュータで構成される） IT システムを構成するコンピュータについて、

人間に遠い側のコンピュータを「Backend」、
人間に近い側のコンピュータを「Frontend」

と呼んでいるだけのようだ。（マーケティングの世界で「バックエンド」と言えば「本命商品」のコトだが…）

具体的に言えば、ユーザ管理、データベース管理、ファイル管理、などを担当する仕組み（コンピュータ）が Backend と呼ばれ、パソコンアプリやスマホアプリが Frontend と呼ばれている。最近では「Backend as a Service」や「mobile Backend as a Service」なる言葉もあって、より利便性の高い「フロント開発」に注力するのがトレンドになっている。

しかし、、、

情報通信が進化した時代、「ヒト」だって常にネットワーク上に居る。バックエンドと言う仕組み、、、何もコンピュータだけで構成される必要は無い。業務プロセス管理（BPMS）は、ヒトを含むバックエンド・システムだ。（「（クラウド）コンピューティング」とは言えなくなるが…）

例えば「請求書発行システム」にヒトが介在していても良い。いや、むしろヒトが介在した方が成果物品質は向上するような気がする。。。そこで、ここでは「郵便物の送付依頼システム」と言うバックエンドについて考えてみた。このワークフローにおいては、送付状こそ自動生成されるが、封入や投函はヒトによって行われる。

ん？、、、更にこれに API を追加すれば、より自動化された「バックエンド・システム」になるような。。。

[郵便物郵送システム]

一般市民が「節電」に協力する。

「消費者」がサービス提供者（電力会社）の事情をくみとって「購入を控える」のだから、なんとも奥ゆかしい話・・・。「経済合理性」とは縁遠い。しかし今の日本では多くの市民がその必要性を認識し協力している。自治体や公的機関であれば尚更、率先して節電意識を高めていかなければならない。（「省エネ化」と「再生エネルギーの省コスト化」にむけたイノベーションが望まれる）

前回記事『「電力使用率」などの外部環境変化で開始されるワークフロー』では、

(1) 平日の朝にワークフローが自動起動され、、、
(2) １時間おきに電力需給を記録（API活用）、
(3) 使用率が「89%」を超えた際に『警戒アラート』、
そして「94%」を超えた際には、ヒトが『節電措置を実践』する

と言う「自動検知の仕組み」を考えた。これはある意味「危機管理マニュアルをシステム化した」と言っても良い。クラウド型ワークフローを使えば、３・４時間で構築できるだろう。

しかし、この設定では「一時間以内に88％から96％に一気に上昇するケース」といった業務シナリオを想定に入れなかった。現実的には、まずありえない話（レアケース）と言っても良い。しかし、もし微細な変更で対応できるのなら、設定に組み入れたい。さて、どうすべきか？

[節電実施フロー（再掲）]

「1時間おきに確認する、、、1日で10回。。。」（ループ）

実に面倒な作業なんだけど仕方ない。。。ウチは公的機関なので、率先して「節電」を行わなければならないのだ。ここで言う確認作業とは、電力会社が発表している「電力使用率」のコト。1時間平均の実績値が89%を超えると警戒し、94%を超えると、(1)複合機とシュレッダーの電源オフ、(2)給湯設備の電源オフ、(3)オフィス内の消灯、(4)エレベータの停止、などの節電を実施する。

2011年に起きた「3.11」（大震災＆原発事故）以降、日本の電力会社は3分おき（もしくは5分おき）に「電力使用状況」を公開してて、、、真夏以外の秋や冬でも「電力使用率」が90％を超える事が月に1-2度はある。

確かに「電力を本当に必要としている方々」を優先せねばならんのだが、正直メンドウな業務だ。Twitter やメールの通知サービスも使ってるけど、ウチの業務にぴったりフィットする訳ではないし。。。 API とか使って、何とかならないかな？？？

[節電実施フロー]