業務:経費の申請と精算

クラウド型ワークフローで「経費申請フロー」のシステム化を実現した!(第559話参照)
多角的な「グルーピング」(クラスタリング分析)の仕組みも導入した!(第560話参照)
経費サマリーが Spreadsheet にリアルタイム追記される仕組みも導入した!(第561話参照)

今では、部長や社長は、暇さえあれば「最新の経費リスト」を眺めているらしい。スマホでも見やすい Google Sheets (Google スプレッドシート)は、管理職者たちを「24時間営業化」させてしまったのかも知れない??

課題:意外と気づかない日付ミス

しかし「解決すべき課題」は、次々と現れる。。。

経費申請に慣れはじめた3か月目くらいから「入力ミス」が目立つようになってきた。過去データの再利用で申請するケースが多くなってきたからだろうか、特に「日付のミス」が目立つ。

課長が確認し、部長が確認し、経理が確認したハズなのに、、、ナンデ日付がズレているんだ??(by 社長)

たしかに『立て替えた日』は非常に重要なデータ項目だ。月次試算表の集計月を決定するデータにもなる。とはいえ課長や部長にしてみれば、他にも沢山のチェック項目があるのだ。。。もし「2017-11-20」が「2016-11-20」になっていても、その間違いに気づかず「承認」してしまう。

一方で社長が眺め見る「経費リスト」はダイジェスト・サマリーだ。「6項目」しかない。だから、日付がズレていたらかなり目立つ。。。(困った!)
  • A. 立て替えた日
  • B. 計上月(YYYY-MM)
  • C. 勘定費目分類
  • D. 精算金額
  • E. 立替人所属組織
  • F. 稟議書ID

[経費精算フロー-入力チェック]

業務:経費の申請と精算


クラウド型ワークフローで「経費申請フロー」のシステム化を実現した!(第559話参照)

しかも「多角的なグルーピング」(クラスタリング分析)を実現するための仕組みも導入した!(第560話参照)

経理チームは、「48時間の滞留で自動的に部長決裁されたものとみなす」というルールが適用された経費申請(案件ステータス115~155)に対して、目を光らせているらしい。

課題:監査法人とのデータ共有

しかし、、、情報量は「多ければ多いほど良い」というモノではない。

ワークフローには、『立替金額』や『計上月』といった基本情報だけでなく『立替申請を行ったヒト・時刻』や『支払を証明する書類』あるいは『プロジェクトの名称』や『取引先企業名』といった関連情報まで、様々なデータが含まれている。たしかに社内の人間であれば、様々なデータから「情報」を抽出することは重要なシゴトと言える。

ただ、例えば、会計監査人にしてみれば「審査過程」や「所要時間」などは無用なデータだ。例えば、社長や会長といった経営トップにしてみれば「誰が多くの経費を使ったか」まで見る時間がない。彼らにとっては「多角的な集計フィルタリング」より、必要なデータが簡潔に一覧されている方が重要なのだ。

う~む、ならば報告用の Spreadsheet を「手作り」するか???(悪夢)

[経費精算フロー-Spreadsheet出力]

業務:経費の申請と精算

クラウド型ワークフローで「経費申請フロー」のシステム化を実現した!(第559話参照)

もともとワークフローシステムには、他にも様々な「業務フロー」が定義されている。なので、立替金の申請だからといって「経費申請のためのシステム」にログインし直す必要はない。

しかも「課長承認」や「部長承認」といった工程での滞留状況が、業務フロー図上に可視化される。申請した社員も、決裁した上司も、取締役達も、、、「どの工程にどんな申請があるのか」を折々に確認するようになった! そして他人のアウトプットについて助言やコメントが付けられるケースも増えてきた! やはり「どこで滞留しているのか?」が分かる事って、ホント大事だ!

課題:リアルタイム集計

しかし、、、「決裁一覧や決裁総額が的確に把握されているか?」については、やや疑問だったりする。。。

つまり、申請の中には「経費申請を取り止める」に至ったものも多数混ざっている。全ての申請を単純集計しただけでは「正確な経費の総額」にならないからだ。。。

う~む、精算業務に特化された『経費精算クラウド』を使った方がイイのだろうか??

[経費精算フロー-案件ステータス]

業務:経費の申請と精算

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

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


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

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


もっとも、、、実際に申請を行う社員の視点で言えば、『経費精算クラウド』でも『ワークフロー・クラウド』でも同じだ。「特化システム 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.課金額の入力』からワークフローを手動開始(再利用開始)するだけだ。しかし、その開始を「手動」に依存すると、たとえば「前月請求したお客様全員にヌケモレなく請求する」が実現しづらいのだ。

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

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