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

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

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

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

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

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

さて、、、
以下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) 1時間おきに電力需給を記録(API活用)、
  • (3) 使用率が「89%」を超えた際に『警戒アラート』、
  • そして「94%」を超えた際には、ヒトが『節電措置を実践』する
と言う「自動検知の仕組み」を考えた。これはある意味「危機管理マニュアルをシステム化した」と言っても良い。クラウド型ワークフローを使えば、3・4時間で構築できるだろう。

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

[節電実施フロー(再掲)]
「1時間おきに確認する、、、1日で10回。。。」(ループ)

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

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

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

[節電実施フロー]

この際、、、『稟議フロー』を定義しなおそう!
  • 上場準備に向けて社内規程も整備されたコトだし、
  • 組織構造もフラットになったコトだし、、、
せっかくシンプルな業務ルールになるのだから、これまでの「業務プロセス定義」(ワークフロー)を修正するのではなく、スクラッチ(白紙)から書き直そう!! そう思って、稟議フローの「業務プロセス定義」を書き直してみた。(心機一転、業務プロセス管理、ナウ!)

なの、、、だけど、、、あー!! やはり、今まで稟議データ(ワークフロー・データ)を捨てる訳には行かないな。 実際、「参照」もしたいし「検索」もしたい。「四半期集計」もしたいし「部署別集計」もしたい。。。

クエステトラ: クラウド型ワークフロー、v10 で無料枠拡大
= 業務プロセス改善のためのグラフ分析機能を追加 = (2014-11-07)

特に前年同月のデータを参照しやすい状態にしておく事の意味は大きいと思う。新しい「企画」や「判断」を行う上においてとても重要な参考情報になる。うーむ、新しく運用開始する『稟議ワークフロー』に、過去の業務データを流し込んでおく方法(データ移行しておく方法)は無いものか。。。

[稟議決裁フロー]
「保守契約の更新」って、意外と営業力が要るのよねー。

ウチは「通信機器の保守サービス」を提供してるんですけど『自動継続』にはなってなくて、毎回お客さんに『更新手続き』と『支払い』をしてもらわないとダメなんですわ。。。 きっと、生命保険とか損害保険とかの営業さんも同じなんだろうけどタイヘン。。。

で、業務マニュアル的には、まずはメールを送る訳ですよ「契約更新して下さい」と。。。 (もっとも、更に担当セールスが電話したり往訪したりしなきゃダメなんですけど)

  1. 契約終了日の60日前 「契約更新のご案内」
  2. 契約終了日の30日前 「更新期限が近づいています」
  3. 契約終了日の7日前 「更新期限が間近です」
  4. 契約終了日の7日後 「長きにわたり有り難うございました」

都合4回のメールは、メール本文やら送信日やらはワークフロー・システムが予めセットしてくれていて、、、普段は編集すること無くそのまま送るだけの作業なんですが、コレが結構送り忘れてしまうのです。

なので、もし「送信日」なって放置されてたら(多少「入れ違い」になっても構わないし)自動的に送られるようにならないかな、と妄想してました。

[契約更新のセールス活動]
請求のシゴト?、「請求書 PDF」を印刷して『窓付き封筒』に入れるだけー!(経理の視点で言えば、だけどね。。。)

「納品内容」とか、「請求先住所」とか、そんな請求データは『受注納品プロセス』のデータがセットされてるし、、、「請求書 PDF」もワークフローの中で自動生成されるし。。。 だから経理が入力ミスする、なんて事は、もうないのデス。 いやぁホント、便利な時代になったもんデス。。。 字が汚いから「宛名書き」しなくてイイって、マジ最高ぉ!とか思ってマス。 (ちなみに、請求金額とか、請求日付とか、、、そう言うトコロはキッチリ見てますよぉー)

でも、、、

実は、そんな請求業務にも、「テク」(技!?)が必要とされる工程があったりシマス。。。 ソレは『未入金』が発生したときの報告。つまり 「入金期限の日、お客様からの入金が確認できなかった時に、如何にスマートに社内報告するか?」 何ともクダラナイように聞こえて、でも地味に難しいシゴトなのデス!

たとえば、その日の夕方、社内の担当営業さんに「XX社からの入金が確認できておりません」なんて味気ない一行メールを送ると、やっぱり何となく空気が悪くなります(経理って「コジュウト」みたいな位置付けなの?)。。。 でも、かと言って報告が遅くなると今度はエライさん達に怒られてしまいます。。。 (どちらにせよ、褒められるコトは全くナイのでアリマス)

うーん。入金期限の日が来たら自動的に、(1) 関係者に定型メールが届く、、、(2) 担当営業に督促タスクが割り当たる、、、とか、、、そんな業務プロセスに改善できないかな??

[請求&入金確認フロー1]

朝、自分の「マイタスク」に『11月4日の日報』というタスクが増える!

悪くナイ。

もしこの機能が無かったら、週の半分で「日報」の提出を忘れる。(…自信アル)。 ちなみに、ルールとしては「帰る時までに提出。もし忘れたとしても翌日提出、最悪でも翌々朝までに提出」ということになってる。

でも、、、

メンバ全員、それなりに機嫌よく、このワークフローで「日報」を流してるケド、、、この【自動開始】という機能、、、、少し問題やとも感じてる。

つまり、仕組みとしては月曜から金曜の毎朝に全員の「マイタスク」に自動追加されるんやけど、、、数日休むと「日報提出タスク」が無駄に溜まってしまう。。。例えば、
  • 忌引き、大型連休、年末年始休暇とか、
  • 育休、産休、介護休暇とか、
  • (あと、変則出勤の人もオルな…)
まぁ、数日分なら1つ1つ頑張って消すんやけど、30日分とか、60日分とか。。。もし1年分なんてなると、消すに消せんのよ。。。(いや、やればデキル子なんやで…)

[日報フロー 1]

『業務プロセス改善』(Business Process Improvement)なる言葉がある。

BPI などと略して言う人は、かなり重度の「カイゼン病」だ。しかし、常日頃から「業務プロセス」のあるべき姿(To-Be)を妄想し続ける事はスバラシイ。所詮、全ての日常業務は科学技術の進歩とともにカイゼンされるべき存在なのだ。『業務プロセス管理システム』(BPMS)なんてカイゼンを構想するためのツールにすぎない。そうだ。カイゼンなくして、成長なし!(荒、鼻息)

さて、、、各社員が「業務カイゼン案」を報告する業務プロセスは、これまでにも紹介してきた。すなわち
の2つのフローは、組織として改善アイデアを集約する上で非常に有効な仕組みと言える。

しかし、アイデアと言うものは、ふとした瞬間に舞い降りてくるもの。特に、「良いアイデア」ほど、舞い降りてくるタイミングが悪い。。。 寝床の中、トイレの中、風呂の中。。。 そして次の瞬間から徐々に揮発していく。(もう少し都合良いタイミングで舞い降りてきて頂きたいものだ。 by ピタゴラス)

そんな時には、(防水)スマホのメーラで「アイデア」をメモしておこう。

以下の業務プロセス定義は、「アイデア乱文メモ」をメール受信するとメール送信者のマイタスクに下書き保存しておく仕組みが追加されている。つまり、次に仕事デスクに座った時に、その「アイデア乱文メモ」を清書しキチンとした「改善案」として提出するのだ。

[カイゼン提案フロー(強制割当・メール開始対応)]

業務プロセス管理(BPM)の目的は、「継続的な業務改善」だ。

確かに、一度「業務プロセス定義」を作成すれば、業務データは効率よく受け渡しされるようになり、業務標準化の名のもとノイズの少ない業務データが蓄積されていくだろう。つまり大きく改善された気になる。しかし一方で、もしそのままその「業務プロセス定義」を使い続けたとすれば、やがて業務の進め方は陳腐化し市場環境の変化に対応できなくなるだろう。

言うまでも無い話だが、継続的な改善を実現するためには、「業務プロセス定義」の改良案が社内から自然と湧き上がり続けることが望ましい。すなわち、
  • 【業務の流れ】をXXXの様に変えてはどうか?
  • 【入力画面の文言】をXXXの様に変えてはどうか?
といった改善案が各社員の自由意思によって継続的に発信されるべきだ。前回記事『業務プロセスを改善するための業務プロセス!?』では、全社員がいつでも提案できる環境について考察した。

ただ、現実的に継続的に課題を指摘し続ける事はムツカシイ。 そこで今回は前回サンプルをさらに拡張し、なかば強制的に改良案を提出させる仕組みについて考察する。

[カイゼン提案フロー(強制割当対応)]

業務プロセスを改善し続けたい。みんな、そう思う。
  • 「フロー」を変えたい
  • 「データ項目」を変えたい
  • 「チーム編成」を変えたい
とは言っても、(a)「改善すべきポイント」が何なのか?、を把握できている上司は少ない。いくつもの課題を把握できているとして、(b)今どの改善の優先度が高いのか?、も把握している上司は珍しい。更に課題の優先度を把握しているとして、(c)どの様に改善すべきか?、まで把握している上司はほとんど居ない。。。

業務プロセスを改善するプラットフォーム(BPMシステム)があっても、実際にルールの変更を行うのは人間だ。

コンピュータが、会社の方針、メンバの個性、社会の情勢、、、などを理解して、人間に対して「このような改善が宜しいかと」と、、、「あるべき業務プロセス」を提言してくれる日は残念ながらマダマダ先の話だ。まずは改善すべきポイントの把握から、地道に実践していくしかない。
  • a. 改善ポイントの把握
  • b. 改善ポイントの優先順位の考察
  • c. 改善方針の策定(コンセンサス)
以下のワークフローは、(まずもって)、上司が「a.改善ポイントの把握」を行えるように、現場社員が「改善ポイント」を提案する業務プロセスだ。仮に全社員が週に一つ提案するだけでも、相当な数の「改善すべきポイント」が蓄積されるだろう。

ちなみに、コレ、、、「言うは易し、行うは難し」だ。
  • すべての提案に対して、一律500円の報奨金を出す
  • 最も価値ある提案に対して、毎月 MVP (Most Valuable Proposal) の表彰をする
などの工夫を講じるべきかもしれない。

[カイゼン提案フロー]

前回に引き続き「社内アンケート業務」とよばれる業務について考えたい。前回は、最大8人に対して「任意のアンケート」を実施できる汎用ワークフローについて考察した。ポイントは、
  • 8人分のスイムレーンを用意し、
  • 8人分の回答データを格納できるように設計した
の2点だ。いつでも色々なアンケートを実施できる所はスバラシイ。

しかし、この方式のワークフローでは50人や100人に対するアンケートは現実的ではない。もちろん、
  • A. 100のスイムレーンを用意し(!!)、さらに
  • B. 100人分の回答データを格納できるように定義する(!?!)
と言う拡張を行うのも悪くはないのだが、、、やはり色々な意味でナンセンスだ。 中でも特に問題視すべきは、データ集計を行うに「非常に使い勝手の悪いフォーマット」になってしまう点だ。集計という視点に立てば、「アンケート実施」の単位で記録されるのではなく、「アンケート回答」の単位で記録されるようにしたい。

以下の業務プロセス例は、まず「B.データ項目が発散する問題」を解決すべく、「アンケート準備」の業務プロセスと「アンケート回答」の業務プロセスの2つの業務プロセスに分けて定義した例だ。準備が1に対して回答がN、、、その「繰り返し単位」の違う業務プロセスをつなげる事で、それぞれ集計しやすいフォーマットになる。

[アンケート準備フロー]

[アンケート回答フロー(ユーザ指定開始)]

「社内アンケート業務」とよばれる業務について考える。ナンてことは無い、社内に対して行われるアンケートだ。

(1) たとえば「回答用の Web フォーム」を作成し回答してもらうという方式。
Questetra の業務プロセス定義でいえば、先頭に [フォーム開始イベント] を配置すればよい。「回答用の Web フォーム」が自動生成され、アンケート回答が入力されるたびに、ワークフローが起動する。(社内ユーザに限らない)
使い方220 自動開始 公開フォーム画面に入力があった時に自動的に開始されるように設定する

(2) あるいは定期的に「アンケートに回答する」というタスクが割り当たるという方式。
Questetra の業務プロセス定義でいえば、先頭に [タイマー開始イベント] を配置すればよい。「毎月1日」や「年に4回決まった日時」など、セットされた時刻になると関係者のマイタスク一覧に「アンケートに回答する」という仕事が一つ増える。
使い方217 自動開始 決められた日時に先頭処理が自動的に開始されるように設定する

いずれの方式もその下流工程において、「アンケート回答に対して御礼を送る」や「どちらとも解釈できる記述について回答者に確認する」といった様々な作業工程を設計する事ができる。だが、、、これらの方法は、アンケートごとに業務プロセス定義を作成する([プロセスモデル] を作る)ことを意味する。重要なアンケートであったり、何度も行われるアンケートであれば、これらの方法で良い。

多様なアンケートを、もっと気軽に流せないものか?

たとえば、理解度を確認したり、意見集約をしたり、飲み会のお店候補に投票してもらったり、、、、、汎用的に使えるアンケート・ワークフローとは、どの様なプロセス図になるのだろうか? (もちろん [プロセスモデル] の複製を行い、編集すべきトコロを編集し、別の業務として定義すれば良いだけではあるが。。。)

[汎用アンケート・レビュー]
「リモートワーク基盤」の進化も凄まじい。たとえば
  • メール
  • カレンダー
  • ファイル管理
  • Web会議
  • ワークフロー(!)
などのクラウド型サービスは急速に進化している。5年前・10年前には社内LANでしか実現できなかった様な「ファイル共有」も、今や「いつでもローカル同期されている状態」にすることができる。つまり、翻訳の仕事であれ、Webデザインの仕事であれ、サポートサービスの仕事であれ、、、もう仲間とのファイル共有に空間的制約はない。

最近では、無料利用枠が拡大されたリモートワークツール『Sqwiggle』(スクウィグル)なども注目だ。簡単に言えば、自宅等での勤務の様子(リモートワークの様子)を、「5分おきの静止画」でチーム共有する仕組み。動画でライブ中継される訳ではないので、自然な形でお互いの「在席」を確認できる。つまるところ「デスクを並べて仕事をしている様な緊張感」を実現できる。まぁ、細かい話をすれば「カメラ画像から社内情報が漏洩される可能性がある」とか、「カメラが CPU をムダ遣いしている」とか、色々なレベルでネガティブ意見は上がるだろうが。。。 (Questetra からも連携させる?)

いずれにせよ、今までは体験できなかった新しい「働き方」を簡単に体験できる環境が整ってきた。

企業としては、新しい情報通信技術を取り入れ、新しい「働き方」を体験し続けるしかない。試行錯誤の中で順次体験して行かなければ、次の道具を体験する事すらできなくなる。(「パソコン入門講座」を学びに行く人に対して同情しているだけでは、いつしか同情される側に回る)

さて、以下は、日報を兼ねたオンライン・タイムカードの仕組みだ。

ワークフローの1つとして提供しておけば、他のワークフローに流れてくる仕事をこなすのと同じように毎日の作業報告を行う事ができる様になる。わざわざ専用のタイムカードシステムを導入する必要もない。『リモートワーク』(テレワーク/テレコミューティング)の第一歩として『仕事時間』の開始と終了をハッキリさせる試みとして体験してみては如何だろう。(リモートワークは『仕事時間』と『仕事成果』の計測がポイント)

[日次報告フロー]
「業務効率」をカイゼンする。
「業務フロー」をカイゼンする。
ん?? 「業務コスト」をゼロにできたりするのかなぁ??

日々「業務のあるべき姿」を考えていると、ふと究極的な姿を妄想するものだ。何とも単純な発想ではあるが、「手間」がゼロになり、「費用」もゼロになれば、それは究極の姿なのではないか、と。。。

実際、「オンライン見積の自動応答」や「イベント参加証の自動発行」など、人間による処理工程を完全に無くす事が可能な業務プロセスは少なくない。「株式の取引」や「為替の取引」に至っては、売買ロボット達に任せた方がより良い結果になるだろう。

しかし、一足飛びに全工程を無人化してしまうのもまたリスクだ。

たとえば「例外」についての考察が足りなかったり、たとえば「悪意のある利用」が想定できていなかったり、自動システムであるが故の(人間であれば対処できたハズの)トラブルに遭遇してしまうケースもある。はたまた、自動化ツールを使いこなせていなかったが故の、新たなヒューマントラブルに見舞われるケースもあるだろう。

以下のワークフロー『社内リマインダ』は、人間による処理工程の無い業務プロセスだ。(完全自動化業務)

ナンて言う事はない、四半期決算日の半月前に「あと半月で四半期決算だよ!」と言うメールを社内に送るだけの、非常に初歩的で、、、そう!これは非常に小さな業務プロセスだ。。。 しかし、、、だが、しかし、、、だがしかしだ、、、、「可能な限りの無人化を目指す組織」にとっては、実は『偉大な第一歩』となるのかも知れない。。。

[社内向け定時リマインダ]

「受け身」で仕事をする!?

とてもネガティブな表現に聞こえる。しかし、そもそも「業務」を概念的に種類分けすると、
  • A. リーダ主導型の業務プロセス
  • B. メンバ主導型の業務プロセス
といったカテゴリがあって、この「A.リーダ主導型」に分類される業務工程(タスク)は非常に多い。例えば以下の様なトリガーで始まる業務だ。
  • a1. 上司が原稿の翻訳を依頼する
  • a2. 上司が企画書をまとめる様に指示する
  • a3. 上司が顧客問合の回答担当者を割り当てる

一方で「B.メンバ主導型」に分類される業務工程は、以下の様なトリガーで始まる業務プロセスだ。
  • b1. 上司に日報を提出する
  • b2. 上司に稟議書を提出する
  • b3. 上司に客先に提出する見積の承認をとる

想像するに容易な話だが、リーダから降ってきた仕事をこなす「A.リーダ主導型」の方がラクなのだ。人間そう言うものだ。話が脱線しかねないが、、、現実、会社組織の中ではガンガンと仕事を流す側の鬼部長も、家に帰れば「受け身」だったりする!(はへ??)

さて、以下に紹介する「時刻が来たら仕事をする」類のワークフローは、「A.リーダ主導」でも「B.メンバ主導」でもない。「T.タイマ起動」と言うべきトリガーだ。コレは、いわゆる「ルーティンワーク」と言う業務に該当する。

実は、これはこれで非常にラクだ。月曜日や金曜日に「T.タイマ起動」系の仕事を入れる人は少なくない。つまるところ自動的に起動される案件は、仕事のリズムを整えてくれる。

[時限メール-タイマー起動]

業務フロー図は、主に「チーム内」の業務改善を目的として描かれる。

しかし、なにも「複数人」で行われるシゴトだけが業務ではない。「たった1人」で完結する業務だって、世の中には沢山存在する。以下のワークフロー(業務フロー図)は『未来の誰か』を勇気づけると言う業務だ。(ん?)

まずは『未来の自分』を勇気づけてみよう!(完全にヒトリ・・・)

方法はカンタンだ。未来の自分にメールが届くようにすればよい。今日(9月1日)から新学年になる人も居るだろう。まずは1週間後の朝9時の自分に「三角関数の加法定理、もう全部暗唱デキテルよね!」とメールしてみては如何だろうか? (ん??!)

確かに、「1人シゴト」に対して業務フロー図を書くのはナンセンスだ。しかも
  • その業務フローを説明する相手がいない、
  • そこに流れる案件の業務進捗をモニタしてもらう相手もいない
と言う状況であれば「全く」と言って良いほどに意味が無い。しかし良く考えてみて欲しい。。。

[時限メール]

「稟議 (RINGI-system)」をペーパレス化するとなると、アレコレ「あるべき姿」を考えたくなるモノだ。

特に日本企業の場合、(a)他部門の責任者にも承認を求める日本の伝統的な流儀を継承するのか、(b)決裁権限者にのみ素早い判断を求める体制に移行するのか、、、まずは基本的なトコロから考え直さなければならない。

以下の業務プロセス定義は、「Proposal (企画)」を会社に提出すると、起案者から見た組織ツリー上の決裁者に対し、ダイレクトに決裁判断を求めるフローだ。つまり日本の伝統的な流儀を継承していないスピード重視のフロー図だ。もちろん「稟議システム」と言っても良いが、ココはあえて「企画決裁システム」と表現しておこう。秀逸なポイントは、決裁までに要した時間が自動的に計算される仕組みだ。

ちなみに起案者と決裁者が同一人物の場合について、条件分岐を付けたがる人が居る。しかし、ソコは役割や人格が違う訳であり、自分で起案し自分で決裁すれば良い。

[企画決裁フロー]

ココだけの話だが(?)、「システム障害対応」は盛り上がる(!!)

情報システム(コンピュータシステム)に『障害』はツキモノだ。一般の方からは「さぞや身も心も疲弊するのだろう」とか「タイヘンな仕事だね」などと思われがちだが、実はそうでもない。いざコトに当たっては、アドレナリンが分泌され、脳味噌は覚醒し、何故か分からないが、仮にそれが真夜中であったとしても一心不乱に障害の原因を探究する事ができるのだ。そして対応完了時にはスガスガしい気分になれる。意外と健康的な仕事だ。(もっとも、その直後に覇気を失う)

そして、こういった「非常事態」を共に乗り越えると、これまでの知識も整理され、また組織としてのチームワークも醸成される。技術鍛錬の観点でも意外と悪くない。(もちろん、その発生頻度が頻繁なモノであれば耐えられないのかも知れない。。。)

(改めて書いておくが、ココだけの話だ!!?)

以下の業務プロセス定義は、「障害チケット」(トラブルチケット)と呼ばれる緊急対応案件を管理するワークフローだ。障害チケットがオープンされれば関係者に一斉通知され、各対応者が指名される。役員や従業員の内で [データ閲覧権限] がある人は、リアルタイムに状況をモニタリングするだろう。(そして社内SNS機能では、「『断続的』って頻度は?」や「『一部のユーザ』って誰?」などの会話で盛り上がる)

なお、この業務プロセスの最終成果物は「事後レポート」だ。対応チームとWeb公開チーム、両方のチームでそれぞれに作成される。

[障害対応フロー]

「メールを送信する家電」と言えば、2001年登場の「賢い給湯ポット」だ。(通信の仕組みが特殊だけど)

離れて暮らす年老いた両親をさりげなく見守る電気ポットは、日本ではちょっとした人気商品だ。今や「おでかけボタン」なるものまで装備され、「給湯した時刻」や「電源を入れた時刻」だけでなく「帰宅や外出の時刻」までもメール本文にシタタメテ、毎日送信してくれる。(ちなみに「i-POT」と言う製品名だが、アップル社の製品ではナイぞ)

そして2014年、見渡せばメールを送信する安価な機器が沢山ある。。。(色んなモノがインターネットにつながった、と言ってもイイ)中でもスキャナとウェブカメラは、かなり成熟した「データ入力装置」と言えるだろう。今や3万円程度だ。非常に投資対効果の高い業務改善ツールと呼べるかも知れない。

以下の業務プロセス定義は、紙アンケートの集計フローだ。

フランチャイズ飲食の来店アンケートや生命保険の契約者アンケートなど、回収アンケート用紙が各店舗でスキャナにかけられると本部でテキスト化作業が始まる、と言う仕組みだ。つまり、本部ワークフローは「スキャナから届いたメール」がトリガーとなって起動され、担当者はスキャン画像(PDF,JPG)をモニタで確認しながら人力でデータ化するのだ。なんと言っても、データ化の進捗がリアルタイムで把握できるようになるのが素晴らしい。それでいてデータ作業者の実績集計もラクラクだ。

ちなみにこのサンプルは、データ入力作業の「二者入力」(二重入力/ダブルエントリー)にも対応している。もちろんクラウド型ワークフローなら、テレワーカの活用やBPOサービス会社への委託も検討されることになるだろう。

[アンケート集計フロー]

「内部統制」と言われても、今一つピンと来ない。
「内部統制の例を幾つか説明してみて」なんて言われたら、逃げ出したくなる。

しかし、それほど難しく捉える必要はない。内部統制は「不正を無くすための活動」と言うだけの話だ。
  • a. 壁に「不正経理は絶対ダメ」と言うポスターを貼る (統制環境)
  • b. 事務所の現金をチョロマカス奴でるか?を分析する (リスクの評価と対応)
  • c. 部長やメンバの権限を、キッチリと規程にまとめる (統制活動)
  • d. 顧客からのクレームが必ず複数人に伝わる仕組みにしておく (情報と伝達)
  • e. 他部署の管理職者にも業務日報が閲覧できるようにしておく (モニタリング)
例えばこれらの活動も「不正を起こさないための活動」と言える。(当然すぎて発想できない)

ただ、今日に至り注意すべきは、こういった活動もコンピュータやインターネットの活用を無視できない点だ。すなわち、全ての会社は、(1)会社を取り巻くIT環境を理解し、(2-1)これらの活動を支える様なITの利用を促進し、また同時に、(2-2)活用ITそのものをキッチリと管理できなければならない。事実、日本の内部統制は、上記5つに「ITへの対応」を加えた6つの観点で評価される。

以下のワークフロー定義は、情報システムの「利用者アカウントを新規発行」する業務だ。「内部統制」の根幹を支える業務と言っても過言ではない。

業務フロー図を眺めてもらえば分かるが、「アカウント発行」の他に「アカウントの削除」や「緊急時の発行削除」にも対応している。つまり、今現在の活用されている全てのユーザアカウントは、いつ申請され、いつ上司承認されたモノなのか、いつでも確認できるようになる。加えて、ここに流れた申請データは、
  • 「適切な時期に申請されているか?」
  • 「無用なアカウントが発行されていないか?」
  • 「アカウント発行のチェック体制は十分に機能しているか?」
など、経営者自身が作成する統制報告においても重要な基礎資料にもなる。

[システムID管理業務(PWリセット業務を除く)]

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

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

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

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

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

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

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

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

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

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

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

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

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

[受注納品請求フロー]