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

分析ツールなのか、集計ツールなのか

Web 業界に関わる人であれば、誰でも『Google Analytics』の存在を知っています。

改めて説明するまでもありませんが、『Google Analytics』（グーグル・アナリティクス）とは、自社サイトのアクセス数や訪問者数などが分かるサービスで、「人気ページ」や「不人気ページ」を確認したり、「ネット広告の投資効果」を確認したりと、「その道の人」には無くてはならないツールとなっています。

しかし一方で、多くの人にとっては「多機能すぎるツール」とも言えます。

見たい情報を表示するための操作は、多機能であるが故に複雑な手順を踏むことになります。たとえば「社内週報」を作るために毎週『Google Analytics』にログインしているような方でも、ごく一部の機能しか使わないのが実情です。そこで、毎回の作業を効率化すべく『カスタムレポート』（ダッシュボード）や『カスタムアラート』（メール通知）を使っている人も少なくありません。

今週も集計値に異常なし！

以下の業務プロセス定義は、週次で行われる「自社サイト運用状況報告プロセス」です。

毎週月曜日の朝には、「Google Analytics の集計データがプリセットされた報告文草稿」が用意されます。したがって、マーケティング担当者は一言コメントを入力するだけで全社への報告を完了させることが可能です。特段の変化が発生していない限り『Google Analytics』にログインする必要がありません。

[自社サイト運用状況報告プロセス]

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

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

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

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

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

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

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

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

[MLメンバー確認]

※この記事には「改善編」があります

メーリングリストの管理

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

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

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

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

複数の 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請求書発行プロセス-キャンセル通知]