ワークフローサンプル

※この記事には「改善編」があります

「日付は、和暦で！」

日本において「年の表記」は複雑だ。つまり、行政や学校では「2016年」とは言わない。あくまでも今年は「平成28年」なのだ。『住民票』であれ『戸籍謄本』であれ、ハタマタ『卒業証書』であれ、、、少しでも重みある書類には「和暦」が記入される。

しかし、現実、、、「ことしは平成28年！」と即答できる日本人は少ない。。。
とは言え、この「数十年に一度、元年（１年）にリセットするという仕組み」は、もう1400年以上も続いている。時の政府の一存で止めてしまえるものでもないのだ。。。（そして、現在の天皇が亡くなった日には、また新しい『元号』が発表されるハズだ）

以下のワークフローは『在職証明書』の発行フローだ。

上流工程で在職者の「氏名」や「生年月日」が入力され、フロー途中の［自動工程］で証明書 PDF が自動生成される仕組みとなっている。特筆すべきは「生年月日」や「証明書発行日」などの日付データが自動的に和暦に変換される点だ。たとえば『卒業証明書』や『保護者だより』のなどの発行フロー等にも転用できるだろう。

[証明書発行フロー]

「ミンナの出張申請、オレ１人では承認してらんねぇ…」

どのような組織図であったとしても、各部署それぞれに「リーダ」が必要だ。特に「部署の方針」や「部署の目標」を決定する際の「リーダ」の役割は大きい。しかし、日常の承認業務について言えば、必ずしも「ひとりのリーダ」で全てを行う必要はない。

たとえば10人から20人程度の「課」における「出張の承認」の様な業務であれば、積極的に『課長代理』や『課長補佐』に代理承認をさせるべきだ。その部署内での責任や序列を明確にする意味もある。（会社の業務規程にも「課長に事故等があるときの職務代理者」と言った定義があるだろう）

ちなみに、手続きの空白期間が許されない「行政府の運営」においてもこの様な制度は良く見られる。（例：「物品管理法、代理官の制度」　代理をさせる場合についての規則）

[出張申請フロー]

※この記事には「改善編」があります

「あらゆる仕事をワークフローで回してるんだから、出退勤報告もワークフローで出来るようにして！」

勤怠管理（出退勤報告）を「タイムカード」で行っている会社は多い。（月次チェック）

しかし、もしルーティーン業務をワークフローで回しているなら、「出勤の報告」や「帰宅の報告」も、ワークフローで報告（申請）できるようにすることを検討したい。何と言っても、『監督若しくは管理の地位にある者』（日本の労働基準法の第41条）等が、リアルタイムに確認できる意義は大きい。（日次チェック）

このワークフローでは、平日の朝７時、『1.出勤時刻の報告』という［マイタスク］が全社員に割り当てられる仕組みだ。

社員は業務開始の際に［Now］ボタンクリックで業務開始時刻を記録し、『1.出勤時刻の報告』を完了させれば良い（もちろん手入力で任意の時刻を入力しても良い）。そして業務終了の際にも同様に『2.退勤時刻の報告』を処理するのだ。ちなみに、もし退勤時刻の報告をせずに帰宅してしまった場合には、自動的に「定時退勤」が記録される。（「定時出勤・定時退勤」の日でならば、朝の出勤報告だけでも構わない。）

「テレワーカ」「リモートワーカ」「外回り営業マン」などが多く在籍する会社では、むしろこの様な仕組みの方が自然かもしれない。

[出退勤報告フロー]

2016年版の「基本業務パック」を考える。

今回はシリーズ第３弾、シンプルな「立替金精算フロー」（経費申請フロー）を紹介する。

このワークフローは、「スマホ撮影」した領収書画像をメールすることで開始される。（メール開始）

立替金精算といえば、月末に「一括」して申請する仕組みの会社が多いとは思うが、この例は「逐次」に申請してもらう形だ。領収書画像との対応を管理しやすくするところに主眼がある。つまるところ、タクシー代や飲食代などの領収書を取得した瞬間にメール申請する業務フローだ。注意すべきは、会社用メールアドレス（ワークフローの［ログインID］）で送信しなければならない点といえる。

（Google Apps などのクラウド型メールシステムを導入している企業であれば難しい話ではない）

ちなみに、改めて言うまでもない事かも知れないが、このワークフローは「スマホ撮影の領収書画像で領収書原本を破棄できるようになる制度」（2017年1月ごろ）を見越した業務プロセスだ。

2016年版の「基本業務パック」に入れるには「時期尚早感」もあるが、来たるべき「領収書スマホ撮影」の時代にむけて、次世代の「あるべき姿」を先取りすることは非常に有意といえるだろう。積極的に試運転し、運用上の様々な課題を事前に整理しておきたい。（2016年中は「領収書原本」を保管する必要があるので注意が必要。なお、2015年10月に開始された制度は「スキャナ読取の領収書画像」という点で異なる）

[立替金精算フロー]

2016年版の「基本業務パック」を考える。

今回はシリーズ第２弾、シンプルな「物品購入依頼」を紹介する。

この調達フローは、「買うべき／買ってほしい」と思ったモノを、気楽に申請できるワークフローだ。
つまり「コピー用紙」「飲料水」「洗剤」といった消耗品から、「机」「掃除機」「パソコン」といった備品まで、、、社員であれば何でも申請できる。ただし、実際に購入されるか否かについては調達部門に委ねられる。特に、必要性や緊急性が判断しづらいものについては、「購入判断保留中」のステータスが長く続くことになる。

なお「10万円を超える申請」については、「事前に『稟議フロー』にて決裁承認されていること」が購買条件となる。

[物品購入依頼]

2016年版の「基本業務パック」を考える。

今回はシリーズ第１弾、シンプルな「稟議フロー」を紹介する。

何ということはない、基本的には、

社員が稟議書を「申請」し、
申請者の上司が「承認」する。

それだけの業務フローだ。

この業務フローは、オンラインのワークフロー・システムに「慣れる」には、ちょうど良いテンプレートだ。入力フォームにある「注記」（入力ヒント）をアレンジする程度で十分だ。それでいて長く使える可能性も高い。。

紙の稟議書を止めようと考えている方、
MS-Excel や Google Spreadsheet での稟議書管理に限界を感じている方

は、無料のワークフロー基盤『Questetra BPM Suite』にインポートし、まずは小規模チーム内で試運転してみてほしい。

[稟議フロー]

前回は『法人番号システム』（Web-API 機能）との連携事例を公開した。

◇2015-12-07: 顧客マスタを「法人番号システム Web-API」でクリーニング

この業務プロセスは、「取引先の商号が変更されていないか」を、毎週自動チェックする仕組みだ。日曜日の朝6時に自動的に開始される。人間は、「顧客マスター」（XML）に修正すべき点が発生したことを、自然と検知できる。

ただ「全ての取引先が法人番号を持っている」と言う前提に立っている。つまり、全ての取引先について、1件1件「Web-API 機能」に問い合わせているのだ。現実には『法人番号』を持たない取引先（個人事業主や海外企業など）も存在する。

以下の業務プロセス定義では、「顧客マスター」にダミー番号「9999999999999」（13桁の9）の存在を許容する。

すなわち、海外顧客など法人番号を持たない取引先は「13桁の9」を登録するというルールだ。また『Web-API 機能』へのリクエストも、10件ずつ行う仕組みになっている。