請求システム」をコントロールする仕組みを紹介しました。これらの仕組み(ワークフローアプリ)には、フロー図の途中に自動工程(Addonサービス工程)が配置されています。Check)といった「リクエスト」がワークフローシステムから自動的に発信されます。ステータス確認」といった経理業務が「無人化」されています。通信)今日では、この例のような「決済システム」(*1)に限らず、様々な情報システムの操作が自動化され、生産性向上が図られています。「Storageシステム」(*2)への見積書保存や、「表計算システム・データ管理システム」(*3)での商品マスタ管理などが代表的な例と言えるでしょう。Check>#プロセスオーナーはAddon自動工程のプロパティを設定するだけで良くなった(プログラミング知識が必要なくなった)という点も普及要因どの様な状態変化まで無人対応させるべきかしかし工程の無人化は「メリットばかり」ではありません。前回記事では、電子請求書のステータスが『PAID』(支払い済み)になるまで確認し続ける(ループし続ける)という業務フローになっていました。確かにヒトは介在しないので「確認作業」そのものには人的コストは発生しません。「発注キャンセル」や「他の決済方法での送金」といった事象が発生しているのなら、場合によっては「出荷処理」という業務を止める必要があるかも知れません。場合によっては「売上計上」という処理にも修正が必要になってくるかも知れません。大きい状態変化ついては、業務プロセス定義として「想定外」のままにするのではなく、できるだけ「想定の範囲内」にしたい所です。以下の業務プロセス定義では、比較的発生頻度の高い「CANCELLEDステータス」(キャンセル)について考慮されています。支払いが拒否された場合などにアラートメールを発信する、という工夫が追加されています。Check]工程は12時間おきに処理されます。レスポンス」から、当該電子請求書のステータスが自動的に上書きされます。ステータスが『PAID』(支払い済み)になっていれば正常に終了します。(そして、この例では単に終了していますが、この後に「出荷する」や「サービスを提供する」といった工程が続くケースや別プロセスが起動されるケースも想定されます)注目すべきはステータスが『CANCELLED』(支払いキャンセル)になった際に、自動的に確認ループを抜けアラートメールが発信される点です。アラートメールから「なぜキャンセルになったのか」までは分かりません。(1)発注自体がミスだったのか、(2)請求額が合意できていなかったのか、(3)銀行送金で対応してしまったのか、その〔理由確認〕は、ヒトの仕事(ヒューマン工程)として発生することになります。支払」ではなく「銀行送金」や「手渡し」で対応されるケースが多くなった場合、どうすれば良いのでしょう。発生件数が小数であれば、逐一手動で『PayPal請求書』を削除すれば良いかも知れません。それでもミスの発生は大きなリスクです。間違った『PayPal請求書』を削除してしまうとオオゴトにもなりかねません。そのような処理が多くなってきたあかつきには、業務プロセス定義を拡張し「削除リクエスト」が自動送信されるような「Addonサービス工程」を追加配置すべきです。paid」といったメソッドが用意されているものの、あらゆる「Addonサービス工程」がネット上から入手できるとは限りません。numberその様なケースでは「Addonサービス工程」を自作することも選択肢の一つです。効率化すべき処理、なのであれば、積極的に検討すべきかもしれません。「他社でも使ってもらってイイよ」という広い心をお持ちなのであれば、是非その設定ファイル(Addon-XML)を世界公開していただければと思います。