ワークフローサンプル

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

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

たとえば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件ずつ行う仕組みになっている。

[取引先マスタ登録商号の自動チェック２]

『会社名（商号）が変わります』
『グループ再編で取引会社が変わります』

取引先から「社名変更の通知ハガキ」が届くことは多い。しかし、この手のハガキだけを頼りに「取引先マスタ」のメンテナンスを行う、、、と言うのは、実に心もとない。

2015年12月1日、日本政府は『法人番号システム』の『Web-API 機能』を稼働させた。

もし、アプリケーション側が「取引先の法人番号」(13桁数字)を把握していれば、取引先の商号や所在地等の登記情報をいつでも参照できる。加えて「商号変更」「吸収合併」「会社解散」などの変化情報（処理区分）についても検知できるようになったのだ。

以下のワークフロー定義は、この『Web-API 機能』を活用し「商号変更」を自動検知する仕組みだ。

ここでは、ワークフロー基盤に「取引先マスタ」（Business-Connection.xml）が存在していることを前提にしている。つまり、「取引先マスタ」に登録されている商号が登記情報と同一であるかを確認している。毎週日曜日の朝に自動実行される設定だ。

[取引先マスタ登録商号の自動チェック]