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

"1.受注" から "2.納品" 、そして、、、"3.請求書発行" と "4.入金確認" へと続く業務の流れ。。。

確かに "社内に閉じていない業務プロセス" は、改善による投資効果は大きい。例えば、より早く・よりミス無くレスポンスできる企業体質になれば、業績は自ずと向上するだろう。

しかし、、、

全ての処理記録を残す
案件属性に応じてフローを自動分岐させる
請求書PDFは手作業では無く自動的に生成させる
全案件の現在進捗を、いつでもモニタリングできる様にする

最初から "完璧な業務プロセス" を定義しようとしてはイケナイ。業務プロセス管理活動（BPM活動）のキモは "小さく始める" 所にある。例えば、全工程ではなく部分的な工程で始めるのも良い。例えば、全案件ではなく例外案件は無視した形で始めるのも良い。

以下のプロセス図は、ホームページ制作会社の "受注納品請求フロー" だ。初見、長大にも見えるが、１分ほど眺めると "意外とシンプルな業務プロセス" と分かる。要するに１つの受注登録に対して、１つの請求書が発行される仕組みだ。言い換えれば、請求（納品）が２段階に分割される様なケースは想定していない。

さて、、、実運用の過程で "２段階納品" の案件が、無視できない発生頻度となってきた、とする。どの様なプロセス改善が考えられるであろうか？

[受注納品請求フロー]

「月単位」での、あるいは「年単位」でのサービス契約なんて、イッパイある。保険の契約、新聞購読の契約、通信回線の契約、税理士や弁護士との契約、クラウドサービス（IaaS/PaaS/SaaS）の契約。。。

この手の契約では「新規契約時」だけでなく、「更新時」にも手続きが必要になるケースが少なくない。コンシューマ向け（一般消費者向け）サービスであれば「新規契約×自動更新」と言うパターンも多いが、法人向けサービスであれば、契約オプションの追加提案をしたり、契約期間を前回より長くする提案をしたり、あるいはサービスの説明を改めて行ったり、と言ったケースも少なくない。
まさに販売スタッフが活躍する瞬間なのだが、、、、だからこそ、ミスモレなく、効率よく、スムーズに対応して行きたいところだ。それは、何よりお客さんのタメと言える。

以下のワークフロー定義は、サービスの新規契約手続きと契約更新手続き、更には契約途中での契約変更などを一元的に管理し、また併せて請求書発行／入金確認までも管理する業務プロセスだ。このフロー図１枚について解説するだけでも「２時間くらいのセミナー講習会」が開けそうだが、大雑把に言えば「営業担当」が受注内容を入力し「管理部門」が請求書発行を行う、と言う流れになっている。

[サービス開始/延長/変更の手続き（受注⇒請求）]

「取引先の一覧」は『表』で管理したい。

『表』（Table）は本当に便利だ。「名簿」にせよ、「商品マスタ」にせよ、もし『文章』だけで記述されていたとしたらゾッとする。「法律文」とか、「規程」とか、あるいは「口頭会話」など、『表』が使いづらい状況では全容の把握が困難になる。（『表』＝視覚的な情報管理ツール）

業務システム全体で「共通選択肢」を管理する際も、その選択肢情報をどの様にマスタ管理すべきかは議論が分かれる。ただ、「行(row)と列(column)で管理する」と言うレベルについては、多くに支持されるところだろう。

以下のワークフローは、ワークフローシステム内の「取引先の一覧」を更新する仕組みだ。システム設定の更新を行う特殊なワークフローでもある。実業務としては、「表計算ソフト」である『Google SpreadSheet』等で「取引先の一覧」を管理し、その内の『取引先ID／取引先社名』を第一工程『1.取引先のIDと社名の入力』でペーストする。

この業務プロセス定義（プロセスモデル）の秀逸な点は、「設定有効にする時刻」を決められる点と、「設定そのもの」が記録として残る点だ。

[取引先リスト（表示選択肢）を更新する業務：「1.取引先のIDと社名の入力」画面]

業務データの入力に「選択肢型入力フォーム」を活用する方法を紹介してきた。

そもそも「業務データ」なるものは、(A)マスター情報を参照コピペして入力すべきデータと、(B)自由に記述すべきデータに大別される。もちろん両者に明確な境界は無いのだが、「(A)の度合い」が強い入力フォームは「選択肢」の活用が検討される。

つまり「取引先名」などの入力フォーム（データ項目）は、「マスター管理すべき」と判断される可能性が高い。

しかし、クラウド時代を迎えつつある今日、果たして「社内だけのマスター管理」で良いのだろうか？　言うまでもない結論だが、社会全体の業務効率を高めるためには各社が「標準的な分類コード」を積極的に採用して行く必要がある。

ここでは、その第一歩として、ISO（国際標準化機構）で定められた都道府県コードに、自社の営業所コード(a～f)を追加したケース（標準コードの自社アレンジ）について考える。（純粋なISOコードではなくなってしまうが、将来的なデータ分析には十分使える。「日々の業務効率」と「将来的なデータ活用」の両立は、ナカナカ難しい…）

＜都道府県コード『ISO 3166-2:JP』と担当営業所＞

▼a.仙台営業所
01:北海道
02:青森県 03:岩手県 04:宮城県 05:秋田県 06:山形県 07:福島県
▼b.東京本社
08:茨城県 09:栃木県 10:群馬県 11:埼玉県 12:千葉県 13:東京都 14:神奈川県
15:新潟県 16:富山県 17:石川県 18:福井県 19:山梨県 20:長野県
▼c.名古屋営業所
21:岐阜県 22:静岡県 23:愛知県 24:三重県
▼d.大阪営業所
25:滋賀県 26:京都府 27:大阪府 28:兵庫県 29:奈良県 30:和歌山県
31:鳥取県 32:島根県 33:岡山県 34:広島県 35:山口県
▼e.高松営業所
36:徳島県 37:香川県 38:愛媛県 39:高知県
▼f.福岡営業所
40:福岡県 41:佐賀県 42:長崎県 43:熊本県 44:大分県 45:宮崎県 46:鹿児島県
47:沖縄県

[選択肢フォームの入力テストおよび選択肢XML生成：「1.選択肢データの入力」画面]

ワークフローだって、【取引先マスタ】が欲しい。
もし「法人名」がユラギなく入力されていれば、どれほど素晴らしいだろう。

資料請求対応、往訪報告、見積提出、受注報告、請求書郵送、問合対応、、、そしてそれらの業務データの集計や分析。。。もし、法人名の「ゆらぎ」が無ければ、「見積書発行額と請求書発行額から成約率を確認」したり、「資料請求から受注までの平均時間」を分析したり、、、戦略立案のための基礎情報もすぐに確認する事が、カンタンにできるようになる。≪綺麗なデータ≫から得られる≪情報≫は、果てしなく大きい。（ビッグデータになるなら尚更）

業務プロセス（業務ルールや業務手順）がある程度整備されたアカツキには、事業特性や会社の規模に合わせた【取引先マスタ】を構築したくなる。

ここでは、(1)『取引先マスタの更新申請』と、(2)『取引先XMLの作成』の２つの業務フローに分けて考えたい。すなわち、各部署の社員が日常業務において、「移転のお知らせ」を受け取った際や「社名変更」の事実を知った際に申請するワークフローと、管理部門において一元的に取引先マスタを更新する業務を分ける事にする。

第一弾は、上司への往訪報告（面談報告）の業務フローにおいて、ついでに(1)『取引先マスタの更新申請』を行える仕組み（ワークフロー）を考える。

[面談報告フロー：「1.面談内容を入力」画面]