請求を自動化する

前回記事では、「PayPal Create」と「PayPal Send」という2つの自動工程を配置することで、『PayPal請求書』が自動的に送信されるワークフローを構築しました。

すなわちヒューマン工程でのチェックや承認を経た「請求データ」が自動的に PayPal 側に POST され『PayPal請求書』が生成されます。そして指定時刻になると(送信指令が届けられ)メール送信されます。何と言っても、「Addonサービス工程」だけで定義できる為、(=「スクリプト工程」が使われていない為)、プログラミング知識が無くても、自社の業務フローにあわせた「自動請求システム」を構築できるのが魅力です。

しかし「『PayPal請求書』が決済されたか確認する業務」については対象外(スコープ外)となっていました。

着金確認まで自動化する

以下の業務プロセスでは、更に「PayPal Check」という自動工程(Addonサービス工程)が追加されています。すなわちこのワークフローシステムは、送信させた『PayPal請求書』について、その決済ステータスを定期的・自動的に確認し続ける設定となっています。

具体的には、「(3.未決済滞留)」の工程にある案件が、
  • 経理担当者が案件を進めるたび
  • 12時間の滞留時間を経るたび
に自動工程「PayPal Check」に到達します。そして、セキュア通信(OAuth2通信/PayPal Invoicing API)を通じて決済状況が問い合わせられます。もし、ステータスが「決済された(PAID)」になっていれば、「(3.未決済滞留)」の工程に戻らず「決済された時刻」と「決済された金額」を格納して、全工程終了となる仕組みです。

[Paypal請求書発行プロセス-決済チェック]

決済に直結する請求書

『ペイパル請求書』は「メールタイプ」の電子請求書です。

メールを受信した人の視点で見れば、『請求書の表示および支払い』のボタンをクリックし、スグに決済処理(カード決済・PayPalアカウント決済)をすませることができるので非常にラクです。もちろん「経理担当者への社内転送」が必要な場合も、メーラでの転送操作だけでよいので、とても簡単です。

請求書を発行する側の視点で見ても、たとえば従来型の「紙請求の業務プロセス」が、
  1. 請求書のExcelデータの作成し
  2. 請求書を印刷し
  3. 請求書を郵送し
  4. 指定銀行口座に入金されたかを確認する
といった手順を踏んでいたのに比べて、
  1. PayPal にログインして請求データの入力する
  2. (決済完了通知が来る)
といった非常に簡素なものになります。しかも、クレジットカード情報は受け取らないので「漏洩リスク」もありません。


昨今では、「生産性向上」や「テレワーク環境整備」の観点からも非常に注目されています。(PayPal 請求書

<受信したメールの例:メーラ画像>

ワークフローとのAPI連携

『ペイパル請求書』は、特別なシステム導入が要りません。

しかし、「Paypal にログインすれば請求書が送信できる」というこの手軽さは、同時に「上司承認が曖昧になる」や「複数人でのミスチェックがしづらい」といった新たな課題を抱えることにもなります。特に「業務プロセス」を重視する会社であれば、ガバナンス上の問題として議論される可能性があります。


以下の業務プロセス定義サンプルでは、ワークフローシステムから API 制御させることによって

「PayPal にログインせずに PayPal 請求書を活用する」

という方針を実現しています。すなわち、ワークフローシステム内で承認・チェックされたデータが API を通じて自動的に PayPal 側に連携され、「請求メールの送信指令」もワークフローシステムから API を通じて届けられます。そして「いつ誰が何をしたか」という業務記録は全てワークフローシステム側に記録されます。

※ クラウド型ワークフロー『Questetra BPM Suite』であれば、無料で実現することが可能です。(業務プロセス定義をインポートすれば数時間で構築できます)

[PayPal 請求書発行プロセス]

「検収報告を受ける」という受け身な工程

イラスト制作・Webサイト制作・内装工事。。。そんな受託事業には「検収対応」がツキモノです。

請負契約に基づく案件は、単に、(1)成果物を「納品する」だけではなく、(2)クライアントから「検収報告書を受け取る」という段階を経て始めて、(3)委託費を「請求する」ことが可能となります。

(もっとも、特別な取引関係にあっては「検収工程」が省略され「納品即請求」が許されるケースもありますが…)


世界中で
  • クライアントの為に「検収報告書」のサンプルを添付する
  • 文書名を『納品書』とせず『検収依頼書(兼 納品書)』といった名前にする
といった涙ぐましい努力や工夫が行われています。

何をする工程か決まってない?

しかし、現実の「検収報告の受領」は、
  • A. 納品当日に「検収報告書」を渡してくれるケース
ばかりではありません。
  • B. 検収期限ギリギリに「検収報告書」を送ってくれるケース
  • C. 検収報告書の提出は行われず「みなし検査合格に関する規定」の適用を前提とするクライアント
など、様々なケースが発生してしまいます。更に言えば、
  • D. 「成果物が仕様を満たしていない」と判断されて検収期間の延長を迫られるケース
  • E. 「成果物が仕様を満たしていない」と判断されて再納品を迫られるケース
もあるでしょう。

ではこの様な場合、どのように業務プロセスを描けばよいのでしょうか? とくに「何もせずに期限がきて終わる」という(C)は、どのように表現すれば良いか悩みます。

[検収対応フロー]

とある工程の作業時間を計測したい

たとえば翻訳工程における「翻訳に要した時間」を計測したい場合、「翻訳結果」とともに「実作業時間」を報告(入力)してもらう方式が考えられます。

しかし、その方式では、各翻訳者に
といった手段で実作業時間を計測してもらう必要があります。この「作業時間を自己計測して報告する」という行為は、大きな手間と言わざるを得ません。

※もっとも「離席休憩」や「割り込み作業対応」といった除外すべき時間が途中発生した際に、計測を一時停止させる等の柔軟な対応が出来るメリットもあります。

報告値の確からしさ

また、結果として「正確でない実作業時間」が報告されてしまう可能性もあります。

たとえば人事考課や能力査定などの面で、「翻訳時間」を短く見せる(長く見せる)ことに何らかのインセンティブが働く制度なのであれば、その「作業時間」は少しずつ事実とは異なる数値が入力されるでしょう。

あるいはまた、シゴトの成果そのものに誇りを持ち、「翻訳時間」などに全く興味を持たない作業者がいたとすれば、「イイカゲンなデータ」が入力されることを想定せざるを得ません。

[翻訳フロー]

ミス発生に伴う生産性ダウン

決裁者さんにとって「差し戻し処理」は、億劫(おっくう)です。

申請内容を読み『無言』でOKすれば良いハズ(3分)のところ、(無言でNGするワケにも行かず)、更に10分かけて『差し戻す理由』を書かなければなりません。しかもそれが「単純ミスや誤記の指摘」であり、それが一日に5件・10件も発生するとなれば、流石に気分も滅入ってしまうでしょう。

そして当然、帰宅する時刻も1時間・2時間と遅くなってしまいます。

システム改良で下げられるミス率

『日付』をまちがう、『金額』をまちがう、『顧客の名前』をまちがう。

申請者さん達も、好き好んで間違っている訳ではありません。基本的には(?)、「業務プロセス定義の工夫や改良」によってミス率を下げることを考えたいものです。(プロセスを憎んでヒトを憎まず!)
  • 入力画面の「注意書き」や「入力チェック」を改良する
  • 業務フローに同僚による「レビュー工程」を追加する

[申請系プロセスのベースフロー-スクリプト]

各案件のログ

業務プロセスの最適化を考えるとき、「マスタ系のデータ」と「トランザクション系のデータ」の2分類における後者データを分析します。

具体的に言えば、『商品マスター』や『顧客マスター』などの「マスタ系データ」ではなく、『見積書No123の詳細』や『請求書No123の詳細』といった発生記録としての「トランザクション系データ」を分析します。

分析に有用なログ

ワークフローシステムに流れる『〇〇案件の詳細』は、案件が開始されるたびに蓄積されるデータであり、全て「トランザクション系データ」に該当します。

しかしながら、業務プロセス内で定義された『データ項目』に、全てのトランザクション情報が格納されている訳ではありません。たとえば『第2工程に到達した時刻』や『ループ構造を周回した回数』といった「システム側で保持されている情報」(案件それぞれのログ)は、エクスポートしやすい形で格納されていません。

以下のワークフローは『差し戻された回数』(ループ構造を周回した回数)という「システム側で保持されている情報」が、業務プロセス側の『データ項目』に自動的に取り込まれる設定となっています。

[申請系プロセスのベースフロー]

小さく始める

「システムに慣れるには、どうしたら良いでしょうか?」

投資効果だけを考えれば「既存の非効率な業務」をシステム化するのが効果的です。もし「紙ベース」で行われている業務があるのなら、その業務のシステム化を検討すべきです。もし、受注・出荷・請求といった「基幹業務」に適用すれば、比較的容易に『効果』が『投資』を上回ることでしょう。

しかし、(1)管理者:システムの設定ノウハウが高くない、(2)一般社員:システムの利用リテラシが高くない、といった状況なのであれば、全く『効果』が出せない危険性もあります。それは「原稿用紙に手書き」してきた小説家に「パソコンでの制作」を強要するようなものです。

「システムの導入で、業務効率を悪化させてしまうかも」。そんな不安がある場合、まずは「小さな業務」で、(できれば毎日必ず行う業務で)、試運転するのが良いかも知れません。

改良し続けるという習慣

ペーパレスやテレワークを推進する際には、「ワークフローシステム」の導入が検討されます。

最初に適用する業務を何にすべきかは、非常に悩ましいところですが、たとえば、以下の「勤務時間報告」という小さなワークフローは有力な候補と言えるでしょう。何と言っても「必然的に毎日利用することになる」のが良いところです。

実際に「データ入力」を行ってみて、実際に「承認」を行ってみて、、、何が必要で、何が省略できるのか、おのずと理解が深まるでしょう。また、その利用の中で、様々なアイデアも生まれてきます。
  • 管理者: 業務フローの設計ノウハウが高まる
  • 一般社員: 工程を担当するという基本的な使い方を理解できる

[出退勤報告フロー]