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

請求を自動化する

前回記事では、「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アカウント決済）をすませることができるので非常にラクです。もちろん「経理担当者への社内転送」が必要な場合も、メーラでの転送操作だけでよいので、とても簡単です。

請求書を発行する側の視点で見ても、たとえば従来型の「紙請求の業務プロセス」が、

請求書のExcelデータの作成し
請求書を印刷し
請求書を郵送し
指定銀行口座に入金されたかを確認する

といった手順を踏んでいたのに比べて、

PayPal にログインして請求データの入力する
(決済完了通知が来る)

といった非常に簡素なものになります。しかも、クレジットカード情報は受け取らないので「漏洩リスク」もありません。

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

＜受信したメールの例：メーラ画像＞

ワークフローとのAPI連携

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

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

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

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

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

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

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

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

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

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

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

世界中で

クライアントの為に「検収報告書」のサンプルを添付する
文書名を『納品書』とせず『検収依頼書（兼納品書）』といった名前にする

といった涙ぐましい努力や工夫が行われています。

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

しかし、現実の「検収報告の受領」は、

A. 納品当日に「検収報告書」を渡してくれるケース

ばかりではありません。

B. 検収期限ギリギリに「検収報告書」を送ってくれるケース
C. 検収報告書の提出は行われず「みなし検査合格に関する規定」の適用を前提とするクライアント

など、様々なケースが発生してしまいます。更に言えば、

D. 「成果物が仕様を満たしていない」と判断されて検収期間の延長を迫られるケース
E. 「成果物が仕様を満たしていない」と判断されて再納品を迫られるケース

もあるでしょう。

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

[検収対応フロー]

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

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

しかし、その方式では、各翻訳者に

着手時刻を手元にメモしておく
昔ながらのストップウォッチを使う
作業時間を計測するストップウォッチソフトを使う
翻訳結果を入力する画面に表示させた『ストップウォッチ・ボタン』を使う

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

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

報告値の確からしさ

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

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

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

[翻訳フロー]