業務:大量の月末請求

月末のカード請求業務が、ヌケモレなく実施されるようになった!

それぞれのお客様への「請求金額」について、、、いつ誰が入力し、いつ誰が承認したのか、全てがリアルタイムに捕捉できるようになった。しかも、クレジット会社 API (Stripe API)にアクセスしてくれる「自動工程」のおかげで、ワークフローシステムからダイレクトにカード課金される。つまり、経理システムへの「二重入力」といった二度手間もなくなった。

課題:人間依存の低減

しかし、、、この業務プロセス(第556話)は、いまだ「人間のデータ入力」に依存している。つまり、肝心の「課金額」の入力については人間(担当営業)が担当している。

たしかに、「お客様情報」は自動でセットされているし、「カード請求コード」(Stripe CustomerID)だって予めセットされている。更には「請求作業の一覧」もヌケモレなく引き受け待ちリストに表示されているので、複数人で協調して請求作業を行うこともカンタンになっている。つまり「入力の省力化」については、かなり高いレベルで実現できているとは思うのだが。。。

もっとも「課金額」(請求額)の情報は、ワークフローシステムから見て「外部システム」にあたる「売上管理システム」にある。なんとかして売上集計を自動取得させることはできないものか? (「APIエコノミー」が叫ばれる今日、業務プロセス改善の行きつく先は「無人化」だと思う。。。)

[クレジットカード課金プロセス-再帰呼出&全自動]


業務:毎月のカード課金

月末の請求業務が、大幅に省力化された!

新しいワークフローアプリでは、担当営業が登録した「今月の請求金額」が部長承認されれば、そのまま自動的に「クレジットカード課金」が行われる。経理サイドが「請求書の印刷/押印/郵送」といった作業を行う必要はナイ。当然ながら「銀行入金確認」といった作業もイラナイ。Stripe 万歳! API エコノミー万歳! Questetra 万歳!

ちなみに、お客様にも好評だ。

「請求書の承認」や「振込の手続」といった実作業がなくなった事(!)もさることながら、費用明細が「通知メール」で確認できるのがイイ(!!)、らしい。(ペーパレス)

(「銀行API」も早くオープン化されればイイのに…)

課題:誰に請求してないか?

ただ、、、現状では「全てのお客様に請求できたか?」が分かりにくい。

たしかに『1r.課金額の入力』からワークフローを手動開始(再利用開始)するだけだ。しかし、その開始を「手動」に依存すると、たとえば「前月請求したお客様全員にヌケモレなく請求する」が実現しづらいのだ。

請求件数が増えれば、いつの日か「請求し忘れ」が発生するだろう。。。(ハテサテ)

[クレジットカード課金プロセス-再帰呼び出し]

業務:登録カードへの課金

「クレジットカード登録」の仕組みはできた! (前回記事参照)

『カード番号』や『CVC』といったカード情報は Stripe 社(決済代行会社)に預けられ、ワークフロー側にはその「預かり番号」としての『Stripe Token』(tok_{24文字})だけが流れる仕組みだ。つまり、日本政府が「2018年3月までにクレジットカード情報の非保持化を!」と言っている要件についても満たすことができたと言える。(非保持化=カード情報保護のための第一の対策)

コレで「自社システムからカード情報が漏洩するリスク」はゼロになったと言ってもイイ! 安心して Web 登録してもらえる!!

※ Stripe Token は一度の処理にしか使えない仕様(single-use token)となっており、この例では『Stripe Token』から『Stripe CustomerID』(cus_{14文字})への自動変換も同時に行われています。(自動工程「Token to Cus_ID」)

課題:課金オペレーションにおける手作業の排除

しかし、良く考えてみれば、、、実現したのは「カード情報の保護」だけだ。

たとえば『課金金額』を間違えたり、たとえば『課金相手』を間違えたり、、、そんな「課金オペレーション」のミスリスクについては、ゼロになっていない。たとえば「Xさんのメールアドレス」に「Yさんの名前宛」で課金予告を送ってしまったとか、、、、考えるだけで寒すぎる。「課金業務フロー」における
  • お客様の名前
  • お客様のメールアドレス
  • Token or CustomerID
あたりのデータは、自動的にあらかじめ入力されているようにしたい。そうなっているだけでミス率はゼロに近づくハズだ。下流工程でチェックを担当する「頼りない上司」の負担も、少しは軽減されるだろう。

[クレジットカード課金プロセス]


業務:決済カード登録の受付

「クレジットカード決済」を推進したい…。

サービス利用実績にあわせて自動的に「カード課金」できれば、非常にスムーズな決済が可能となる。もし「明細発行」も電子化できれば、売上回収コストは大幅に低減できるだろう。

電気会社・ガス会社・ケータイ会社のように「カード課金できる体制」を整えたい。

課題:カード情報の漏洩リスク

しかし、セキュリティ要件が厳しくなった今日、「クレジットカード番号を保有すること」は大きなリスクらしい。

ウチは、電力会社でもなければ、Google Facebook といった大会社でもない。つまり「PCI DSS」が言っているような要件は維持できそうにない。カード会社(アクワイアラー)も言っているが「持たないこと(非保持)が大切」なのだろう。

よし、、、日本政府が「2018年3月までに非保持化を目指す」と言う書類にあるように、PAN PIN CVC といったカード情報等は「決済代行業者」に預けようと思う・・・。(どうやって??)
  • PAN:Primary Account Number (カード番号)
  • PIN:Personal Identification Number (暗証番号)
  • CVC: Card Verification Code/Value (3桁数字。正確にはCVC2。CIDとも)
※参考: クレジット・カード業界データ・セキュリティ標準(PCI DSS Ver.3.2 2016-04)
※参考:EU の法改正(決済サービス指令 2015年)、日本の法改正(改正割賦販売法 2016年)

[クレジットカード情報の受付プロセス]

業務:脆弱性対応プロセス

「弱点のないソフトウェアはない」、、、らしい(涙)

つまり、無数のソフトウェアが組み込まれているコンピュータや通信機器は「弱点だらけ」なワケだ。それにもかかわらず、会社には沢山のコンピュータや通信機器がある。社員が使うパソコンもあれば、会社ホームページのためのサーバコンピュータもある。売上や給与を管理する業務システムだってある。。。


情シス部による「脆弱性(ぜいじゃくせい)対応」とは、カンタンに言えば「ソフトウェアの補修作業」だ。

具体的に言えば、情シス部は日頃から「IT情報サイト」や「Google Alert メール」で脆弱性情報を収集し、それが会社のコンピュータで使われているソフトウェアに関する情報であれば、「パッチの適用」や「バージョンアップ」といった作業を行うのだ。最近は「自動パッチ」や「自動更新」が行われるソフトも多くなっているとは言え、それでも「手動対応しなければならない事案」は少なくない。

なお、年に1・2度、日ごろの補修作業がキチンと行われているかのチェックをかね、専門業者によるセキュリティテスト(「脆弱性検査」という)が行われる。

課題:属人的な対応

ただ、、、今日では、凄まじい数の「攻撃方法」が毎日毎日発見されている。

古いソフトウェアに関する「攻撃方法」も毎日のように報告される。日々の補修によって「弱点」は克服されていっているハズなのだが、攻撃アイデアや攻撃力も日々向上しているのだろう。永遠に無くなりそうにない。たとえば CVE 公表される「脆弱性」は年間1万件以上にものぼる。(CVE:Common Vulnerabilities and Exposures / 脆弱性情報データベース)

もはや、情シス部が全てに目を通せる量ではない。ベテラン社員がその「嗅覚?」と「属人的な情報ネットワーク?」によって機転を利かせて対応しているのが現実だ。

うーむ、、、もう少し組織的に対処できないモノだろうか?

もっと言えば、「緊急を要する脆弱性」について誰がどのような判断をしたのか・しているのか、についてキチンと記録・共有したいものだ。たとえば「ShellShock」や「Heartbleed」といった世間を騒がせた脆弱性に、いつ誰がどのような対応をしたのか、振り返りたいと思うのだが。。。 (OpenSSL, GNU bash)

「ゼイジャクセイ、対策しろと、言われても…」(情シス川柳)

[脆弱性対応プロセス]


業務:カイゼンを社内募集

日本政府は本気で『働き方改革』をさせたいようだ。

たしかにウチの社内にも「誰も見ない書類の作成」や「非効率なヤリトリ」がある。「◇◇業務に〇〇クラウドの導入」とか「IoT活用」とか、、、具体的な「改善アイデア」を、もっと積極的に吸い上げる方法を考えたい。たとえば「中途社員」や「派遣社員さん」が給湯室や飲み会の席でグチってるだけ…なんて、ほんとモッタイナイ。

とは言え、、、社長が「業務プロセスを改善して生産性を高めよう!」と朝礼で叫んだくらいでは、具体的な「改善提案」は上がってこないだろうな。。。


そうだ。まずは、いわゆる「目安箱」のイメージで、『内部監査室』に「アイデア投稿」を受け付けてもらおう。

そして良いアイデアについて「現場ヒアリング工程」や「社長報告工程」に進める、、、そんなワークフローを運用してもらうのだ。(業務改善アイデア受付プロセス)

課題:社内なら誰でも投稿できるフォーム

しかし、ワークフロー基盤への「ログインID」は、全員が持っている訳ではない。

もしアイデア投稿に「ログインID」が必須なら、派遣社員さんやアルバイトさんが投稿できなくなる。(現場の非効率は、きっとアルバイトさんや派遣社員さんに押し付けられてるんだろうに。。。)


ん?、よく考えれば、ある程度の「匿名性」も担保したい。

たとえば「部長の不正リスクを下げる改善アイデア」といった大胆なアイデア投稿も推奨したいものだ。

う~む、「インターネットに完全オープンなWebフォーム」でアンケート募集する、というのも一手なのだろうが、やはりチョット気持ち悪い。。。(URLがサラされたり。。。ゼンゼン関係ない人が提案してきたり。。。)

[業務改善アイデア受付プロセス]



業務:週次売上報告へのフィードバック

「一週間分の売上」が Google Sheets に書き込まれるようになった。(参照:第550話

全店長が一つのファイル(例:『売上報告2017-08-27to2017-09-02』)を同時編集するので、
  • 各店長は他店を意識するようになった
  • 店長同士で誤入力を指摘し合うようになった
  • 本部での集計作業は(Spreadsheet任せなので)不要になった
  • 役員達もファイルを閲覧し、各店舗の動向を能動的に確認するようになった
などのカイゼンが図られている。つまり、各店長のコメントを含む「売上データ」が、社内でイキイキと活用されるようになった。(これまでは「売上データ」が死んでいた?)

課題:管理職側のコメントがない

しかし、本部マネージャから全店長に「フィードバック」があっても良いのではないだろうか?

セッカク全店長が頑張って報告してくれているのに、本部のマネージャ達から何も感想がないのは寂しい。「目標達成を頼む」の一言でもイイ。マネージャの笑顔を待ちわびる店長達に伝えてやってくれ。。。

そうすれば「実績データについて本部のマネージャ達がどう考えているか/どんな助言をしているのか」を役員達が知ることもできる。

[週次売上報告プロセス-フィードバック]

業務:週次売上報告

各店長には「一週間分の売上」を週次報告してもらっている。

確かに、メールやワークフローを使い、
  1. 一人一人の『店長』が報告し、
  2. 本部の『マネージャ』が確認する
というシンプルな「売上報告プロセス」を回すのも悪くない。しかし各店長は『本部マネージャの顔色』だけを見てシゴトしているような気がする。


たとえば、もっと「他店の動向データに触れる機会」を作っても良いのではなかろうか?

もし『Google Spreadsheets』であれば、全店長が同じドキュメントを編集できる(※50人まで)ワケだし…。 副産物的な話として、『本部マネージャ』の「集計する」という工程が省力化されるハズだ。「入力ミス」についても、他店とデータ比較されることで店長自身が気づくかもしれない。あるいは店長同士で「入力ミス」を指摘し合うかもしれない! (更には店舗間のコミュニケーションも活発になり、生産性向上に…悶々)

課題:新しい SpreadSheet の準備がメンドウ

しかし、そうなると誰かが「報告用の Spreadsheets」を毎週準備する必要がある。

本部の『マネージャ』達には無理だ…。彼らは他人には厳しく、自分にはアマイ。たとえば「経費精算」など、今まで締切日が守られたタメシがない…。う~む「毎週キッチリと、新しいファイルを準備して全店長にアナウンスする」という第一工程がネックだなぁ。

[週次売上報告プロセス]

人事情報の発表方法

「人事異動の情報(配置変更や地位変更)を社内に公表する」という業務はフクザツです。

昇格・降格・採用・退職・休職・部署異動・関係会社出向…と、さまざまなパターンがあり、また個別の事情もそれぞれに異なります。

人事担当者の気持ちとしては、たとえば「信任の厚いベテラン社員が晴れて定年退職される」というケースなら何か月も前から周知しておきたくなるかも知れません。しかし一方で「競合他社に転職する」というケースなら秘密にしておきたいと思うかも知れません。また「家族介護のために休職する」といったケースでも、同僚や関係者に対して(守秘義務違反に配慮し)積極的に事前連絡しようとする人もいれば、黙っていたいと考える人もいるでしょう。

基本的には『既定の解禁ルール』にのっとって、粛々と「人事部内秘の情報」を「社内公知の情報」に切り替えるべきなのでしょう。(人事通達)

業務上の課題

公表方法として「社内掲示」という手法がとられている会社は少なくありません。

しかし、紙に印刷して「掲示板」や「壁」に張り出すという手法では、外出が多い人、長期休暇中の人、あるいはリモートワーカーにとっては見る機会が非常に少ないものになってしまいます。他方、人事部門としても「決められたタイミングで掲示作業を行う」や「決められたタイミングで掲示を終了させる」といった業務は、意外と大きな負担となります。

また「朝礼での口頭発表」という手法がとられている会社もあります。

しかし、これもまた長期休暇中の人やリモートワーカーは、朝礼出席者と同じだけの情報量を得ることは難しいと言わざるを得ません。さらに、口頭であるが故に「異動の日付」や「異動部署」などが正確に伝わらないリスクもあります。

[人事異動情報の公表]

アナリティクスいわく「○×工務店さんが困ってマス!?」

前々回記事前回記事では、「先週のWebアクセス動向」が社内通知される(ほぼ無人の)ワークフローを紹介しました。

この業務プロセスが運用されれば、社員は毎週月曜日の朝、「Google Analytics Reporting API」を通じて得られた最新情報について、メールで確認できるようになります。その結果、日々の「サポート業務」や「セールス業務」は、より効率良いものになるでしょう。

ただ、もう少し欲を言えば、「Analytics に無い情報」も併記しておいてもらいたいものです。つまり、
  • 先週火曜日、プレスリリースを配信した
  • 先週木曜日、ユーザ向けセミナーを実施した(○×工務店さんも居た!)
もしこういった Analytics に無い情報も併記されていれば、「流入の多いリンク元」や「特定の顧客が調べているページ」といった動向情報について、もっと深い理解・洞察が可能となるかも知れません。

カレンダー情報も API 取得

以下の業務プロセス定義は、社内カレンダー『広報予定およおび出展予定』(Google Calendar)に書き込まれているイベント(先週分)が、通知メールの文頭に付加される仕組みです。

これにより、通知メールを受ける社員達は、「Webアクセスに影響を及ぼしたかもしれない関連情報」についても、同時に確認することが可能となります。

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

人気ページのランキング

前回記事では、『Google Analytics Reporting API』との自動通信によって「週次レポート」が自動的に生成される方法を紹介しました。

ポイントは、
  • ディメンジョン: ga:hostname, ga:pagePath, ga:pageTitle
  • メトリックス(指標): ga:pageviews, ga:sessions
というルールで集計データを自動取得する自動工程(サービス工程Addon)です。

この工程では「沢山アクセスを得たWebページのリスト」が複数行テキストとしてまとめられます。もし「フィルタ」に『ga:pagePath=~/blog/』の様な設定をすれば「blog フォルダ以下のWebページ」を対象としたランキングも自動的に取得することが可能です。

これらの文章が挿入された通知メールは、マーケティング・チームにとって非常に有用な情報となるでしょう。

他にも数万パターンの集計方法

しかし Google Analytics のデータは、もっと他の角度からも集計したい所です。

前回例では、上述の「3つのディメンジョン」と「2つのメトリックス」でランキング集計されましたが、Google Analytics には他にも約260のディメンジョンと約230のメトリックスが存在しています。つまり、組み合わせを変えることによって、多種多様な集計が可能となります。

たとえば、サイトコンテンツの視点(『行動(BEHAVIOR)』)だけでなく、『ユーザー(AUDIENCE)』や『集客(ACQUISITION)』の視点で集計すれば、「どんな人がアクセスしているのか?」や「どんなサイトから誘導されてきたのか?」といった情報も抽出できるハズです。

参考: ディメンジョン名とメトリックス名

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

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

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

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

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

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

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

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

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

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

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

[検収対応フロー]

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

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

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

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

報告値の確からしさ

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

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

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

[翻訳フロー]

ミス発生に伴う生産性ダウン

決裁者さんにとって「差し戻し処理」は、億劫(おっくう)です。

申請内容を読み『無言』でOKすれば良いハズ(3分)のところ、(無言でNGするワケにも行かず)、更に10分かけて『差し戻す理由』を書かなければなりません。しかもそれが「単純ミスや誤記の指摘」であり、それが一日に5件・10件も発生するとなれば、流石に気分も滅入ってしまうでしょう。

そして当然、帰宅する時刻も1時間・2時間と遅くなってしまいます。

システム改良で下げられるミス率

『日付』をまちがう、『金額』をまちがう、『顧客の名前』をまちがう。

申請者さん達も、好き好んで間違っている訳ではありません。基本的には(?)、「業務プロセス定義の工夫や改良」によってミス率を下げることを考えたいものです。(プロセスを憎んでヒトを憎まず!)
  • 入力画面の「注意書き」や「入力チェック」を改良する
  • 業務フローに同僚による「レビュー工程」を追加する

[申請系プロセスのベースフロー-スクリプト]

各案件のログ

業務プロセスの最適化を考えるとき、「マスタ系のデータ」と「トランザクション系のデータ」の2分類における後者データを分析します。

具体的に言えば、『商品マスター』や『顧客マスター』などの「マスタ系データ」ではなく、『見積書No123の詳細』や『請求書No123の詳細』といった発生記録としての「トランザクション系データ」を分析します。

分析に有用なログ

ワークフローシステムに流れる『〇〇案件の詳細』は、案件が開始されるたびに蓄積されるデータであり、全て「トランザクション系データ」に該当します。

しかしながら、業務プロセス内で定義された『データ項目』に、全てのトランザクション情報が格納されている訳ではありません。たとえば『第2工程に到達した時刻』や『ループ構造を周回した回数』といった「システム側で保持されている情報」(案件それぞれのログ)は、エクスポートしやすい形で格納されていません。

以下のワークフローは『差し戻された回数』(ループ構造を周回した回数)という「システム側で保持されている情報」が、業務プロセス側の『データ項目』に自動的に取り込まれる設定となっています。

[申請系プロセスのベースフロー]

小さく始める

「システムに慣れるには、どうしたら良いでしょうか?」

投資効果だけを考えれば「既存の非効率な業務」をシステム化するのが効果的です。もし「紙ベース」で行われている業務があるのなら、その業務のシステム化を検討すべきです。もし、受注・出荷・請求といった「基幹業務」に適用すれば、比較的容易に『効果』が『投資』を上回ることでしょう。

しかし、(1)管理者:システムの設定ノウハウが高くない、(2)一般社員:システムの利用リテラシが高くない、といった状況なのであれば、全く『効果』が出せない危険性もあります。それは「原稿用紙に手書き」してきた小説家に「パソコンでの制作」を強要するようなものです。

「システムの導入で、業務効率を悪化させてしまうかも」。そんな不安がある場合、まずは「小さな業務」で、(できれば毎日必ず行う業務で)、試運転するのが良いかも知れません。

改良し続けるという習慣

ペーパレスやテレワークを推進する際には、「ワークフローシステム」の導入が検討されます。

最初に適用する業務を何にすべきかは、非常に悩ましいところですが、たとえば、以下の「勤務時間報告」という小さなワークフローは有力な候補と言えるでしょう。何と言っても「必然的に毎日利用することになる」のが良いところです。

実際に「データ入力」を行ってみて、実際に「承認」を行ってみて、、、何が必要で、何が省略できるのか、おのずと理解が深まるでしょう。また、その利用の中で、様々なアイデアも生まれてきます。
  • 管理者: 業務フローの設計ノウハウが高まる
  • 一般社員: 工程を担当するという基本的な使い方を理解できる

[出退勤報告フロー]