Google Group 登録者のメンテナンス

前回記事および前々回記事では、『Google Group』のメンバー追加やメンバー削除が自動的に実行される業務プロセス定義を紹介しました。

Google Group を「社内の情報共有ツール」として活用している会社であれば、この自動追加や自動削除といった機能は、「適時更新を保証する仕組み」として非常に有効と言えるでしょう。

求められる信頼性要件の高さ

しかし、この様な仕組みを導入してもなお、「正しいメンバーを維持すること」は容易ではありません。

たとえば、急ぎの依頼を受けて「間違った Group にメンバー追加」(システム管理画面)してしまうケースもあるでしょう。あるいは、ユーザ自身が「退会処理」(ユーザ設定画面や unsubscribe メール)をしてしまうケースもあるかもしれません。その様なケースは、「届くべきでないヒトに情報が届いてしまう状態」あるいは「届くべきヒトに情報が届かないという状態」になってしまいます。

「えっ? そんな通達、あったっけ??」

何か月もメーリングリストの情報を受け取らずに仕事をしていた、、、なんかヘンだと思った、、、、といった悲劇は、(非常に恐ろしい事ではありますが)、いつか必ず発生してしまうものです。

[MLメンバー確認]

メーリングリストの管理

前回記事では、ワークフローの流れの中で、「メルマガ購読希望者」(のメールアドレス)が自動的に『Google Group』に追加される業務プロセス定義を紹介しました。(資料請求に対応する業務)

これは、1つのメールアドレスが「1つのメーリングリスト」に自動追加される仕組みです。

しかし、社内で運用されているメーリングリストを見渡せば、(いわゆる『チャットツール』の普及によって減少傾向にあるとは言うものの…)、「方針の通達」「部署内限定にしたい情報の共有」「システムアラートの受信」など、様々な業務において、様々な社内メーリングリストが日常活用されていることでしょう。

メーリングリスト管理の観点においては、「複数のメーリングリスト」に一括追加したいケースの方が、むしろ多いのかも知れません。

複数の Google Group に一括登録

以下の業務プロセス定義は「アカウント申請フロー」です。

社内からの『アカウント申請』があれば、「アカウント新規発行」や「LDAPの設定変更」など、情報システム部は必要なシステム設定を行います。

特筆すべきは「複数のメーリングリスト」への追加削除工程が自動化されている点です。(工程の無人化)

すなわち、案件が[Groupメンバ追加]や[Groupメンバ削除]の工程に到達すれば、ワークフローシステムから追加・削除のリクエスト(OAuth2)が送信されます。つまり、「メーリングリストへの追加削除」という作業について情報システム部の担当者は『メンバ追加されるGoogleGroup』(Checkbox)や『メンバ削除されるGoogleGroup』(Checkbox)が正しく選択されていることを確認するだけで良く、『G Suite』の管理画面にアクセスして Group 設定を一つ一つ編集する必要はありません。(Admin SDK Directory API v1)

[アカウント発行およびML登録]

メールでの情報共有

メーリングリストは便利です。

組織内の「情報共有」に使ったり、お客様への「情報通知」に使ったりと、多くの企業で日常的に活用されています。しかし、その「メンテナンス作業」がオロソカになってしまうケースは少なくありません。
  • メールが届くべきではないヒトに届いている(情報漏洩?)
  • メールが届くべきヒトに届いていない(新入悲劇あるある?)
そんな状況が、世界中で発生していることでしょう。

購読メンバーの自動追加

以下の業務プロセス定義は「資料請求対応フロー」です。

このワークフローはお客様の「Web申込」によって開始されます。そして、その申込案件が自動工程『メルマガ追加』に到達すれば、自動的に「お客様のメールアドレス」がメーリングリスト(Google Group)に追加される仕組みとなっています。

この様な処理の「無人化」は、G Suite 管理者が管理画面にアクセスして手動でデータコピーする手間を無くすだけでなく、設定ミスやタイムロスによるトラブルを未然に防ぐことにも寄与します。また手動設定では困難だった「アドレス追加の履歴記録」をも実現します。

[資料請求対応]

工程の無人化による生産性向上

前々回記事前回記事では、ワークフローシステムから「PayPal 請求システム」をコントロールする仕組みを紹介しました。

これらの仕組み(ワークフローアプリ)には、フロー図の途中に自動工程(Addonサービス工程)が配置されています。つまり、請求案件がこれらの工程に流れ着く度に、
  • 『PayPal請求書』を生成せよ(PayPal Create)
  • 『PayPal請求書』を送信せよ(PayPal Send)
  • 『PayPal請求書』の決済ステータスは何か?(PayPal Check)
といった「リクエスト」がワークフローシステムから自動的に発信されます。言い換えれば「電子請求書の生成」「電子請求書の送信」「電子請求書のステータス確認」といった経理業務が「無人化」されています。(PayPal Invoicing API との REST/OAuth2 通信)

今日では、この例のような「決済システム」(*1)に限らず、様々な情報システムの操作が自動化され、生産性向上が図られています。たとえば「Storageシステム」(*2)への見積書保存や、「表計算システム・データ管理システム」(*3)での商品マスタ管理などが代表的な例と言えるでしょう。

*1: PayPal, Stripe, etc. *2: Dropbox, Box, Google Drive, etc. *3 Google SpreadSheet, Kintone, etc.


<設定画面:Paypal Create>

<設定画面:Paypal Send>

<設定画面:Paypal Check>

#プロセスオーナーはAddon自動工程のプロパティを設定するだけで良くなった(プログラミング知識が必要なくなった)という点も普及要因

どの様な状態変化まで無人対応させるべきか

しかし工程の無人化は「メリットばかり」ではありません。

たとえば前回記事では、電子請求書のステータスが『PAID』(支払い済み)になるまで確認し続ける(ループし続ける)という業務フローになっていました。

確かにヒトは介在しないので「確認作業」そのものには人的コストは発生しません。

しかしながら、もし「発注キャンセル」や「他の決済方法での送金」といった事象が発生しているのなら、場合によっては「出荷処理」という業務を止める必要があるかも知れません。場合によっては「売上計上」という処理にも修正が必要になってくるかも知れません。やはり「影響度×発生確率」が大きい状態変化ついては、業務プロセス定義として「想定外」のままにするのではなく、できるだけ「想定の範囲内」にしたい所です。

以下の業務プロセス定義では、比較的発生頻度の高い「CANCELLEDステータス」(キャンセル)について考慮されています。すなわち、支払いが拒否された場合などにアラートメールを発信する、という工夫が追加されています。

[Paypal請求書発行プロセス-キャンセル通知]

請求を自動化する

前回記事では、「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)は、どのように表現すれば良いか悩みます。

[検収対応フロー]