業務:経費の申請と精算

いわゆる『経費精算クラウド』は、システム導入がラクだ。

経費(立替金)の精算業務に特化したシステムなので、申請画面も、管理画面も、最初から経費精算業務向けになっている。初期設定についてアレコレ深く悩む必要はない。


一方『ワークフロー・クラウド』でも「経費申請」のシステム化は可能だ。

ただ、ワークフローシステムは汎用システムなので、申請項目を考えたり、上司承認・会計記帳・経理振込といった業務手順を考えたりと、意外と手間だったりする。。。


もっとも、、、実際に申請を行う社員の視点で言えば、『経費精算クラウド』でも『ワークフロー・クラウド』でも同じだ。「特化システム vs 汎用システム、どちらが良いか?」については結局のところ、単に「組織の考え方次第」ということになるのだろうか?? いやぁ、20世紀末の「ワープロ専用機 vs パソコン」という論争を思い出す。。。(シャープの『書院シリーズ』が好きだった)

※ 当時は、ワープロ機能をROM化して組み込んであるワープロ専用機と、汎用的なパーソナルコンピュータで動作するワープロソフトが、よく比較された。

課題:提出遅れ

しかし問題は、、、経理部から「経費申請が出てない!」と怒られてしまうことだ。

たとえば展示会出展準備を頑張る担当者は、「稟議フロー」(事前申請)で決裁を取るところまでは頑張るのだが、展示会が終了し支出内容について「経費申請」するのは苦手なのだ。

担当者の[マイタスク]画面に、すでに「〇〇展示会への出展」という申請タスクが並んでいればなぁ。。。

経費申請の画面で、すでに「稟議書のID」や「稟議書の決裁概要」が自動的に入力されていればなぁ。。。

[経費精算フロー]


業務:「資料請求」の受付

  1. 資料請求の受付件数
  2. 見積の提出件数
  3. 契約件数

古典的なマーケティング手法ではあるが「1.資料請求の受付件数」は「3.契約件数」に直結する指標だ。その相関は極めて強い。したがって多くの会社で KPI 設定されている。車会社、保険会社、引越会社、設計事務所、、、規模の大小や業種業態を問わないのだろう。

今どき、スムーズなワークフローを実現すべく、顧客からの申込をクラウド型ワークフローの「フォーム開始イベント」で受け付ける会社も少なくない。ワークフローを使うことで、「宛名印刷」や「配送」といった下流工程もヌケモレなく実行される。

そして「受付完了メール」の自動送信(メール送信イベントの配置)も「王道」と言ってイイ。顧客は「リクエストを受け付けてもらえた」と認知することができる。また、本文には『受付番号』を記述する。そうすれば『受付番号』をたよりに電話やチャットで疑問点を問い合わせることができる。

課題:受付番号だけの本人確認

『受付番号』は「プロセス連番」(#{processInstanceSequenceNumber})が都合良い。何と言っても KPI 管理がラクだ。

しかし同時に「類推されやすい番号」でもある。たとえば電話やチャットで「申込のキャンセル」が来た際、「本人確認」をせざるをえない状況になりうる。つまり、誠実そうな声で「受付番号123番をキャンセルして下さい」と言われればそのまま受け付けても良いのだろうが、悪意のありそうな方を相手にした際に「エントリの氏名」や「メールアドレス」を聞いて本人確認することになる。これは顧客差別とも言われかねない。

かと言って、「類推されにくい番号」として暗号文のような長い番号にするとイロイロ不便だ。「KPI 管理」がメンドウになるだけではない。電話口で伝えてもらいにくいし、一意であることを担保するのも意外とムツカシイ。うーむ。。。

[資料請求への対応プロセス]

業務:大量の月末請求

月末のカード請求業務が、ヌケモレなく実施されるようになった!

それぞれのお客様への「請求金額」について、、、いつ誰が入力し、いつ誰が承認したのか、全てがリアルタイムに捕捉できるようになった。しかも、クレジット会社 API (Stripe API)にアクセスしてくれる「自動工程」のおかげで、ワークフローシステムからダイレクトにカード課金される。つまり、経理システムへの「二重入力」といった二度手間もなくなった。

課題:人間依存の低減

しかし、、、この業務プロセス(第556話)は、いまだ「人間のデータ入力」に依存している。つまり、肝心の「課金額」の入力については人間(担当営業)が担当している。

たしかに、「お客様情報」は自動でセットされているし、「カード請求コード」(Stripe CustomerID)だって予めセットされている。更には「請求作業の一覧」もヌケモレなく引き受け待ちリストに表示されているので、複数人で協調して請求作業を行うこともカンタンになっている。つまり「入力の省力化」については、かなり高いレベルで実現できているとは思うのだが。。。

もっとも「課金額」(請求額)の情報は、ワークフローシステムから見て「外部システム」にあたる「売上管理システム」にある。なんとかして売上集計を自動取得させることはできないものか? (「APIエコノミー」が叫ばれる今日、業務プロセス改善の行きつく先は「無人化」だと思う。。。)

[クレジットカード課金プロセス-再帰呼出&全自動]


業務:毎月のカード課金

月末の請求業務が、大幅に省力化された!

新しいワークフローアプリでは、担当営業が登録した「今月の請求金額」が部長承認されれば、そのまま自動的に「クレジットカード課金」が行われる。経理サイドが「請求書の印刷/押印/郵送」といった作業を行う必要はナイ。当然ながら「銀行入金確認」といった作業もイラナイ。Stripe 万歳! API エコノミー万歳! Questetra 万歳!

ちなみに、お客様にも好評だ。

「請求書の承認」や「振込の手続」といった実作業がなくなった事(!)もさることながら、費用明細が「通知メール」で確認できるのがイイ(!!)、らしい。(ペーパレス)

(「銀行API」も早くオープン化されればイイのに…)

課題:誰に請求してないか?

ただ、、、現状では「全てのお客様に請求できたか?」が分かりにくい。

たしかに『1r.課金額の入力』からワークフローを手動開始(再利用開始)するだけだ。しかし、その開始を「手動」に依存すると、たとえば「前月請求したお客様全員にヌケモレなく請求する」が実現しづらいのだ。

請求件数が増えれば、いつの日か「請求し忘れ」が発生するだろう。。。(ハテサテ)

[クレジットカード課金プロセス-再帰呼び出し]

業務:登録カードへの課金

「クレジットカード登録」の仕組みはできた! (前回記事参照)

『カード番号』や『CVC』といったカード情報は Stripe 社(決済代行会社)に預けられ、ワークフロー側にはその「預かり番号」としての『Stripe Token』(tok_{24文字})だけが流れる仕組みだ。つまり、日本政府が「2018年3月までにクレジットカード情報の非保持化を!」と言っている要件についても満たすことができたと言える。(非保持化=カード情報保護のための第一の対策)

コレで「自社システムからカード情報が漏洩するリスク」はゼロになったと言ってもイイ! 安心して Web 登録してもらえる!!

※ Stripe Token は一度の処理にしか使えない仕様(single-use token)となっており、この例では『Stripe Token』から『Stripe CustomerID』(cus_{14文字})への自動変換も同時に行われています。(自動工程「Token to Cus_ID」)

課題:課金オペレーションにおける手作業の排除

しかし、良く考えてみれば、、、実現したのは「カード情報の保護」だけだ。

たとえば『課金金額』を間違えたり、たとえば『課金相手』を間違えたり、、、そんな「課金オペレーション」のミスリスクについては、ゼロになっていない。たとえば「Xさんのメールアドレス」に「Yさんの名前宛」で課金予告を送ってしまったとか、、、、考えるだけで寒すぎる。「課金業務フロー」における
  • お客様の名前
  • お客様のメールアドレス
  • Token or CustomerID
あたりのデータは、自動的にあらかじめ入力されているようにしたい。そうなっているだけでミス率はゼロに近づくハズだ。下流工程でチェックを担当する「頼りない上司」の負担も、少しは軽減されるだろう。

[クレジットカード課金プロセス]