各案件のログ

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

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

分析に有用なログ

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

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

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

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

小さく始める

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

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

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

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

改良し続けるという習慣

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

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

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

[出退勤報告フロー]

入力ミスが多い?

ワークフロー・システムでは、ヒューマン工程における「入力ミス」が避けられません。

たとえば「請求書発行日」と「入金期限」の2つの日付を入力する必要があるワークフロー工程であれば、
  • データ複製のまま1年前の日付を入力してしまう
  • 請求書発行日と入金期限を逆に入力してしまう
といったミスが発生しがちです。(折々に、実際の発生率を計算してみるのも良いでしょう)

もちろんミスをした担当者が不注意なのかも知れません。あるいは、集中力を高めれば、その瞬間だけはミスなく入力できるかも知れません。しかし、100件・1000件と「ミスなし」を続けることは、むしろ困難と言わざるを得ないでしょう。もし入力項目数が多い業務なら、5件・10件でもミスなく入力することですら難しいかも知れません。

初期値を設定する

システム機能として「初期値の設定」が可能なら積極的に利用したい所です。

クラウド型ワークフロー『Questetra BPM Suite』の場合、日付データ項目の初期値として「今日から3日後」や「来月の末日」を設定できます。「データ複製」のケースには無力ですが、新しい案件データを業務プロセスに流す場合には、とても有効な方法です。

<設定画面>

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

入力ミスが多い?

ワークフロー・システムでは、ヒューマン工程における「入力ミス」が避けられません。

たとえば「単価」と「数量」の2つの数値を入力する必要があるワークフロー工程であれば、
  • 12000 が 1200 と一桁が足りない数値を入力してしまう
  • 金額を入力すべき場所に数量を入力してしまう
といったミスが発生しがちです。(折々に、実際の発生率を計算してみるのも良いでしょう)

もちろんミスをした担当者が不注意なのかも知れません。あるいは、集中力を高めれば、その瞬間だけはミスなく入力できるかも知れません。しかし、100件・1000件と「ミスなし」を続けることは、むしろ困難と言わざるを得ないでしょう。もし入力項目数が多い業務なら、5件・10件でもミスなく入力することですら難しいかも知れません。

最大値・最小値を設定する

システム機能として「入力値の制限」が可能なら積極的に利用したい所です。

クラウド型ワークフロー『Questetra BPM Suite』の場合、数値データ項目には「最大値」と「最小値」を設定できます。もし「単価」の入力値を「10,000円~100,000円」と制限しておけば、その入力制限によって「1200円」という誤入力の発生率をゼロにすることが可能です。

<設定画面>

<動画:ミス発生の様子>

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

プロセス見直しの季節

4月。

日本では「新しい1年が始まる月」です。

国の会計、地方自治体の会計、学校の新学年などが、4月に始まるだけでなく、新社会人の入社式も4月に一斉に行われます。(約2割の日本企業は4月に会計年度を始めます)

日本において4月は、「業務プロセスの改善モチベーションが上がる月」あるいは「業務プロセス改善にはモッテコイの月」と言えるでしょう。

そして当ブログを運営している Questetra 社においても、4月は業務プロセスの更新量(ワークフロー・アプリのバージョンアップ回数)が増えます。

あえて所要時間を伸ばす?

今回紹介する業務プロセスは、「全工程の所要時間を伸ばす」という少し変わった改善例です。

普段の業務改善は、日頃の業務中に感じた「不満」や「課題」に対して『フローの改善』や『データ入力画面の改善』を考えるのが常です。
  • 工程の自動化
  • ダブルチェック工程の追加
  • ガイド文の追加
  • 便利ボタンの設置
そして、その多くの場合、「トータル所要時間を少しでも早める方向性」を模索します。


しかし、年度の区切りである4月においては、「全体集計作業を通じて感じた非効率」について対処したくなる場合もあります。この業務プロセス(ワークフロー・アプリ)では、あえて途中滞留させる変更が行われています。(ヒューマン工程「x.差戻滞留」の追加)

※ 改善前の業務プロセス: 第511話:振替伝票ファイルを自動生成させる(Excel-CSV)


[請求書発行プロセス-滞留]

情報収集は「業務」か?

色々な意見がありそうです。テレビ番組も会議室で視聴すれば「業務」なのでしょうね。

ただ、たとえば百貨店に勤めている方なら「百貨店」のニュースは気になるものです。あるいはネット企業に勤めている方なら「AI」「IoT」「ビッグデータ」といったキーワードが気になるものです。

もし、それらのキーワードに関係する「特集番組」がテレビ放送として企画されているなら、見逃す訳には行きません。とくに公共放送で取り上げられるとなれば、社会への影響も非常に大きなものがあります。

<NHK API 管理画面>

誰でも使える NHK API

日本の公共放送であるNHKは、『番組表API』を公開しています。2016年6月にはVer.2の提供が開始され、「7日先」の番組情報まで取得できるようになりました。

レスポンス抜粋

"id" : "2017041215654",
"event_id" : "15654",
"start_time" : "2017-04-12T04:30:00+09:00",
"end_time" : "2017-04-12T05:00:00+09:00",
"title" : "NHKニュース おはよう日本",
"subtitle" : "▼国内外の最新ニュース ▼スポーツ情報 ▼地域の課題や話題のリポート ▼日本と世界の気象情報",
"content" : "※番組内容は変更になる場合があります ▼番組HP http://www.nhk.or.jp/ohayou/",
"act" : "【キャスター】森田洋平,【気象キャスター】酒井千佳",


この API は非常にシンプルな OPEN API です。

ユーザー登録さえすれば、誰でもスグにアクセスでき、利用上のルールに関しても「1日300アクセスまで」と非常に明快です。OAuth1/OAuth2といった認可フローもなく、セキュア通信(HTTPS)ですらありません!


一方で、標準仕様に厳格な API と言うこともできます。

日頃いろいろな API を活用している方であれば、Web サイトで使用できる文字(UTF-8)は、そのまま通信されるものと思い込んでしまっています。しかし、ソコは「流石NHK」です。「英数記号(ASCII 文字)だけで送受信」(Unicodeエスケープ)というルール(JSON RFC7159)をしっかり守り、日本語一文字一文字が \nXXXX と変換されています。(通信ログの検証等では使いづらいのですが)

[テレビ番組のキーワード検索]

銀行口座の自動操作

日本では『銀行API』が盛り上がっています。

この Workflow Sample ブログを運営しているクエステトラ社においても、「『MFクラウド』(会計クラウド)と『みずほビジネスWEB』(銀行オンラインサービス)とのAPI連携の恩恵」によって、入金情報のリアルタイム確認が可能となり、会計システムへの記録もおよそ当日処理(日次決算)されるようになりました。(ワークフローによってしか作成できない売掛金等の情報は「CSVインポート」のままですが…、MFクラウドさん自身がAPIを提供する日も遠くないハズ…)
※ちなみに「スクレイピング方式」(会計クラウドに銀行パスワードを預ける方式)による連携は使用禁止にしていました

そして、この入出金情報のデータ連携を可能とする『銀行API』という政策は、2017年中にも「改正銀行法」として法整備される見込みであり、また FinTech 業界も好意的に受け止めていることから、銀行システムと様々なオンラインサービスが密接に接続されていく将来が予想されています。

まずは「参照系API」から

ただ、目下のところは、一部の事業者しか『銀行API』にアクセスできません。

今後についても、そのアクセスできる事業者となるには一定の審査が入ることが予想されています。また、今国会における議論如何によっては、「許認可制」になってしまう可能性もゼロではない状況にあります。


銀行側のアクセス許可についても、当面は「参照系API」に限定される可能性があります。

つまり、「APIサービス」の試運転期間のようなものとして、「入出金情報の取得」や「残高情報の取得」といった資産の移動を伴わないデータ参照通信に限定したサービスとして開始されることが想定されます。(既にこの2017年4月から「更新系API」の事例も出てきましたが…)


ちなみに「日本独自の課題」も見え隠れしています。

すなわち、大半の口座名が「半角カナ」で処理されてきた歴史的経緯があり、長音、拗音、中黒点といった文字データが、(少なくとも現時点では)、正式なカナ名称として表示されません。
  • キヨウトダイガクガクチヨウ ヤマギワジユイチ
  • カ)リクル-トホ-ルデイングス
つまるところ、少なくとも当面はAPIアクセスするシステム側で「データ変換」を行う必要があります。(「自動仕訳ルール」など)

[送金プロセス]