ワークフローサンプル: 計画

ラベル計画の投稿を表示しています。すべての投稿を表示

情報収集は「業務」か？

色々な意見がありそうです。テレビ番組も会議室で視聴すれば「業務」なのでしょうね。

ただ、たとえば百貨店に勤めている方なら「百貨店」のニュースは気になるものです。あるいはネット企業に勤めている方なら「AI」「IoT」「ビッグデータ」といったキーワードが気になるものです。

もし、それらのキーワードに関係する「特集番組」がテレビ放送として企画されているなら、見逃す訳には行きません。とくに公共放送で取り上げられるとなれば、社会への影響も非常に大きなものがあります。

＜NHK API 管理画面＞

誰でも使える NHK API

日本の公共放送であるNHKは、『番組表API』を公開しています。2016年6月にはVer.2の提供が開始され、「７日先」の番組情報まで取得できるようになりました。

レスポンス抜粋

"id" : "2017041215654",
"event_id" : "15654",
"start_time" : "2017-04-12T04:30:00+09:00",
"end_time" : "2017-04-12T05:00:00+09:00",
"title" : "ＮＨＫニュース　おはよう日本",
"subtitle" : "▼国内外の最新ニュース　▼スポーツ情報　▼地域の課題や話題のリポート　▼日本と世界の気象情報",
"content" : "※番組内容は変更になる場合があります　▼番組ＨＰ　ｈｔｔｐ：／／ｗｗｗ．ｎｈｋ．ｏｒ．ｊｐ／ｏｈａｙｏｕ／",
"act" : "【キャスター】森田洋平，【気象キャスター】酒井千佳",

この API は非常にシンプルな OPEN API です。

ユーザー登録さえすれば、誰でもスグにアクセスでき、利用上のルールに関しても「１日300アクセスまで」と非常に明快です。OAuth1/OAuth2といった認可フローもなく、セキュア通信（HTTPS）ですらありません！

一方で、標準仕様に厳格な API と言うこともできます。

日頃いろいろな API を活用している方であれば、Web サイトで使用できる文字（UTF-8）は、そのまま通信されるものと思い込んでしまっています。しかし、ソコは「流石NHK」です。「英数記号（ASCII 文字）だけで送受信」（Unicodeエスケープ）というルール（JSON RFC7159）をしっかり守り、日本語一文字一文字が \nXXXX と変換されています。（通信ログの検証等では使いづらいのですが）

[テレビ番組のキーワード検索]

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

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

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

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

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

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

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

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

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

[メール開始プロセス]

『業務プロセス改善』（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）の表彰をする

などの工夫を講じるべきかもしれない。

[カイゼン提案フロー]

前回に引き続き「社内アンケート業務」とよばれる業務について考えたい。前回は、最大８人に対して「任意のアンケート」を実施できる汎用ワークフローについて考察した。ポイントは、

８人分のスイムレーンを用意し、
８人分の回答データを格納できるように設計した

の２点だ。いつでも色々なアンケートを実施できる所はスバラシイ。

しかし、この方式のワークフローでは50人や100人に対するアンケートは現実的ではない。もちろん、

A. 100のスイムレーンを用意し(!!)、さらに
B. 100人分の回答データを格納できるように定義する(!?!)

と言う拡張を行うのも悪くはないのだが、、、やはり色々な意味でナンセンスだ。中でも特に問題視すべきは、データ集計を行うに「非常に使い勝手の悪いフォーマット」になってしまう点だ。集計という視点に立てば、「アンケート実施」の単位で記録されるのではなく、「アンケート回答」の単位で記録されるようにしたい。

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

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

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

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

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

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

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

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

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

[汎用アンケート・レビュー]

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

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

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

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

確かに、「1人シゴト」に対して業務フロー図を書くのはナンセンスだ。しかも

その業務フローを説明する相手がいない、
そこに流れる案件の業務進捗をモニタしてもらう相手もいない

と言う状況であれば「全く」と言って良いほどに意味が無い。しかし良く考えてみて欲しい。。。

[時限メール]

【会社の意思】は取締役会で決まる。

多くの場合、「議論の深まり」の中で決まっていく。と言うか、典型的なパターンは社長が取締役達を説得し、「あーだ、こーだ」と事前のヤリトリがあった後、取締役会の場で決まる。当然ながら【取締役会議事録】には、『慎重審議の結果、提案は全員異議なく可決』とのみ記録される。込み入ったヤリトリや各取締役の当初意見などは、公式記録に残らない。

しかし【最も大切な情報】は、決まるまでの「過程」だ。
未来の取締役達が読みたくなる情報は、決まるまでの「過程」だ。

以下のワークフローは、各取締役が独立して意見を記録できるシステムだ。まず『-2.反対』『-1.どちらかと言えば反対』『0.分からない/判断保留』『+1.どちらかと言えば賛成』『+2.賛成』を選び、その上で、自分の意見を自由に記録する。とかく形式主義に陥りやすい『議事録』とは別に運用される。つまり、会議の前に意見や考えを表明しておくため、あるいは会議の後に議論後の意見や議論感想を記録しておくために活用される。単なる「電子採決システム」とは違う。

[事案に対する意見表明フロー]

受託開発ソフト会社にせよ、BPO受託会社にせよ、お客様との約束事である『納品日』はゼッタイだ。一度の遅延が会社の信頼を大きく失墜させる。しかし、その『納品日』を十分に共有できているとは言い難い。

チームメンバーはむしろ「自分の処理」についての締切を認識し続ける。つまり「全工程」の締切である『納品日』については認識する機会が少ないのだ。≪ワークフローシステム≫の画面を見ていても、各工程担当者にとって「自分が引き受けた処理」についての締切（処理締切）は分かりやすいが、チーム全体として大切なハズの「全体納期」は認識しづらい。

ましてや…「今月末は納品日が集中しているゾ」と言った"案件横断的な情報"は、把握できるハズもない。

以下のワークフローでは「納品日データ」が≪カレンダーシステム≫と同期される仕組みが用意されている。具体的には「受注情報」の中の「納品日データ」が、OAuth （オーオース）と言うセキュア通信を使って Google Calendar に自動的に書き込まれる。カレンダーを見れば、いつでも「納品日の分布」を全体俯瞰する事ができる。これはチームメンバだけでなく、取締役や監査役にとっても非常に重要な情報源となる。

[受託～納品フロー]

各支店からの「売上高報告」、その速報値を集計したい？

前回紹介した日報ワークフロー（※）があれば、いつでも売上高の日次変動を確認できる様になる。絞り込み機能を使えば、任意の期間の売上高を集計する事も容易だ。しかし一部の売上高報告が、異なる通貨になっていればどうか？？？
※ 「日報」に気象データを取り込む意味（天気API活用）

以下のワークフローは前回紹介の『営業日報フロー』をベースに、当日の為替レートで売上高を変換する機能が追加されている。すなわち、その日の為替レート情報をインターネットから自動的に取得し、海外店の店長が入力した売上高（現地通貨）を本店通貨表記に自動変換する仕組みだ。実際に本店の通貨に換金するタイミングは異なるにせよ、売上高の「速報値」を自動集計できるようになるのはスバラシイ。

[営業日報フロー-為替]

「天気」に左右される業務は少なくない。

良く議論される事例として「ビールの仕入業務」がある。ウェザー・マーチャンダイジングなどと言われる事もあるが、要するに「売れ行き」を予想して「仕入」を行う業務だ。担当者は天候や予想最高気温などを見て（更に祭事やイベントをチェックして）その発注数量を決めるのだ。

もちろん他にも色々ある。
「建設現場の週間計画」、「農業の悪天対応」、「イベント体制の準備」、「ゴルフ場のキャンセル対応」などなど、様々な業務で天気が影響する。また、一見『屋外』とは縁の無さそうな「通販業の問合対応」なども、実は天候に左右されるらしい。

以下の業務フローは飲食業の売上日報だ。典型的な「日次報告型のワークフロー」と言える。
ここでは天候と気温も併せて報告させ「気象による売上変動」を分析するための基礎データとなるようにしている。特筆すべきは、その気象データがあらかじめ自動的に入力されている点だ。報告担当者は『天候』や『気温』を入力する必要が無い。この雛形は、清掃業・建設業・人材派遣サービス等でも転用できるだろう。（「夏休みの絵日記」に転用してはイケナイ…）

[営業日報フロー-天気]

震災後の日本ではＢＣＰに関連する商品やサービスが「特需」だ。ＩＴ業界でもクラウド関連製品などの需要が伸びている。（新聞紙面に「節電」「在宅勤務」「ＢＣＰ」の文字を見ない日は無い）

※ BCPとは「Business Continuity Plan」の略で『事業継続計画』と訳される。『非常事態発生時対応計画』（コンティンジェンシープラン）が「非常時にとるべき行動」に主眼が置かれているのに対し、BCPは「事業を復旧させるための行動」と比較的長期にわたる行動を規定する。

しかし『事業継続計画』（BCP）の作成は容易なことではない。例えば、「社屋の停電」や「交通網の寸断」などの想定シナリオの下で、「主要な業務プロセスをどの様な形で復旧させるべきか」を平時から検討しておく必要がある。すなわちこの検討には、平時の業務の流れを熟知している必要があるだけでなく、場合によっては高度に経営視点での考察も必要となろう。

以下は『「想定する条件下での業務フロー」を準備する業務フロー』だ。

＜各タスク名＞
1.業務フローおよび想定条件の指定、2.業務フロー図の検討、2b. 相談対応、3.検討業務フロー図のレビュー、4.検討業務フロー図の確認