「カタログ郵送、、、意外とミスが多いんデス」

公開Webフォームで受け付けた「資料請求」には素早く対応したいものだ。しかし、お客様に入力していただいた『住所』や『会社名』を間違えるとサムイ。。。たとえば「Word送付状」にコピペする時に、参照すべきレコードが一件ずれてしまい、
  • ウチ、そんな社名じゃないよ
  • ウチに、そんな社員はいないよ
などというクレームにつながれば、場合によっては「個人情報漏洩事件」とすら言われる可能性がある。


以下の業務プロセス定義は、『受付担当者』が
  • 入力途中で送信してしまった様な未完成な住所だったりしないか?
  • イタズラ目的のデタラメ住所になってないか?
  • 省略表記や無用なスペースなどが混ざっていないか?
などをチェックした後に「送付状PDF」は自動生成され、『郵送担当者』はそのPDFを印刷して資料を封入流れとなっている。そこに人手は介在しない。

秀逸な点は、この業務において「リスト」が作られることもない点だ。情報漏洩リスクは極めて低くなる。そして封入作業が完了し次第、「会社名」や「電話番号」などのデータは自動的にクラウド型データベースに追加される。(一目瞭然ではあるが、「あわせて見積も欲しい」などの書き込みがあった場合に『営業担当者』に依頼する流れも想定されている)

[資料請求対応業務]

前回記事では、

> kintone API から JSON レスポンスを受け取り、ワークフロー環境共通の「顧客マスタ」を更新する

という全自動ワークフローを紹介した。今回の記事では

> kintone API に JSON データを送信して、kintone 上の「顧客マスタ」を更新する
を紹介する!

具体的には、「与信管理ワークフロー」において取引開始が承認された瞬間、 kintone 上の「顧客マスター」に取引先(顧客コードと顧客名)が追加される仕組みだ。

つまるところ、当該ワークフローの下流で

{
  "app": "3",
  "record": {
    "customerCode": {
      "value": "9999999999999#www.example.com"
    },
    "customerName": {
      "value": "XYZ Inc"
    }
  }
}

という JSON テキストが kintone API に POST される設定となっているのだ!(←説明する気、あんのか?!?)

※ JSON: JavaScript Object Notation (「キー」と「値」のペアが列挙されたデータのかたまり)

[与信管理フロー]
『顧客リスト』は、代表的な「データベース」だ。(紙管理にせよ、コンピュータ管理にせよ)

そもそも「データベース」に格納されるデータは、
  • (A) マスター情報 (マスター系データ)
    • 商品マスター
    • 顧客マスター
    • 価格表、など
  • (B) ログ情報 (トランザクション系データ)
    • 支払履歴
    • 受注記録
    • アクセスログ、など
に大別されるが、日常業務において「(A)マスター系データ」に属するデータを参照したくなる機会は多い。


以下の業務プロセスは、クラウド型データベース『kintone』で管理されている顧客マスター情報を、ワークフロー環境の『顧客マスター』として日次同期させる仕組みだ。(バッチ処理と言っても良い)。全工程が自動化されているだけでなく、任意の時刻に手動で同期させることも可能な点が秀逸といえる。

つまるところ、「見積提出プロセス」「受注報告プロセス」「請求プロセス」など、様々な業務において、最新の『顧客マスター』を参照できるようになる。いわゆる「ユラギ」や「ナヨセ」と決別できるかも知れない。(更には kintone データの自動バックアップという意味もある)

[顧客マスタ同期プロセス]
「12か月後の今日、保守契約更新のリマインド通知を行う」

たとえば「契約プロセス」を設計していると『12か月後に通知』というアラート・メール(リマインド・メール)が欲しくなる。つまるところ、メール送信イベントを業務フローの最下流に配置したくなる。「プロセスモデリング」の専門用語(BPMN用語)で言えば[メッセージ送信中間イベント(メール)]と呼ばれるアレだ。

しかし、その設定をすると、「全工程の完了」までに1年間を要する業務プロセスとになってしまう。
(契約締結までの作業工程はすべて完了しているのに。。。)

やや個人の趣向に依存する話になるが、、、この「リマインド・メール」が送信されていないがために、案件ステータスが「Running」のママとなってしまうのは、何とも気持ち悪い。もし「全工程が完了するまでの時間」を KPI として計測しているような組織であれば、非常に「邪魔な存在」と言えるだろう。

以下のワークフローは、この「リマインド・メール」の部分だけを独立させた業務プロセスだ。(業務プロセスと言うには、あまりにもシンプルすぎるが) 要するに、様々な業務プロセスから「メッセージ」を預かり、「リマインド日時」にメール送信するだけの仕組みとなっている。

[リマインド通知プロセス]

「もっとスムーズに入力できたら、、、」

業務システムは、多かれ少なかれ「入力画面」で評価される。たとえば「出退勤の報告」「稟議の申請」「受注の報告」「問合に対する回答」などなど、、、日々の業務を思い返してほしい。そこで発生する遅延や手戻りは、その多くは『上流工程における誤入力や不適切入力』が原因となっている。

以下のワークフロー・サンプルは、「入力例ボタン」のクリックで入力できる様に工夫されている。

ボタンがあるだけで、入力者の集中力は持続され、延いてはケアレスミスの発生も減少する。そんな「入力例ボタン」の良さは、実際に体験してもらわなければ伝わらないのだが、、、選択肢を選ばせる手法、データ初期値を設定しておく手法、などとは少し違った入力支援だ。ボタンとは言え、自ら入力しているので「やった感」を積み上げて行けるのだ!?? そして、入力者の脳にあたえる「CPU負荷」(みたいなもの)が大幅に下がる。

[入力フォームのテストフロー]