2016年も「契約書フロー」や「稟議書フロー」が根強い人気

今年最後の投稿です。2016年も毎週欠かさず業務テンプレを配信することができました。これもひとえに読者の皆様からの「応援メッセージ」や「いいね」のおかげです。

はい。来年(2017年)も頑張ります。

さて当ブログでは、これまで過去7年間に渡る合計500本以上の記事(と800近くのテンプレート)を公開していますが、今年2016年は、どんな記事が良く読まれたのでしょうか? 早速、今年一年間のアクセスログを調べてみました。

<トップ5記事>

やはり「契約書」や「稟議書」のオンライン承認(ペーパレス化)は根強い人気テーマの様です。(注:日本語版の調査結果です)

今ならどう書く?「契約書承認フロー」

しかし、この記事、すでに6年も前の記事です。

毎日毎日、業務プロセスを描いている身としては、やっぱり「今なら違うプロセスをお勧めするなぁ」などと思うワケです。(現在、日本語での Google 検索で「契約書 ワークフロー」の検索1位になっているので、「よく読まれる」のは仕方ないのですが。。。)

ということで、今年最後の記事は「契約書承認プロセス」をシンプルに描き直してみたいと思います。

[契約書承認プロセス(2010-11-12)]

政治家や官僚達のワーク・ライフ・バランス


日本も他の先進国と同様、既存の「福祉国家の路線」に限界を感じている。

つまり「行政のスリム化」(簡素な効率的政府)という基本方針については、どの政党も合意するところとなっている。時代の流れには逆らえない。

※ ◆1930年代に起きた倒産の連鎖(世界恐慌)を経て、人類は「単なる自由放任主義」を否定し、大きな政府による「社会保障」を肯定するに至った。 ◆1970年代に起きた経済の停滞(オイルショック)を経て、人類は「福祉国家の非効率」を自覚し、小さな政府による「競争社会」への回帰を容認するに至った。 ◆1990年代以降の企業活動は国境を越え税収確保も困難となり、またインフラ維持や医療費増加もあり、結果として既存の「福祉国家路線」は立ち行かなくなる。


しかしながら「国会における行政効率化の議論」は全くかみ合わない。

たとえば、(1)「ハンコ行政」をやめる、(2)「特殊法人の民営化」を推進する、(3)「健保・年金・所得税などのバラバラ徴収」を一元化する。。。 議論すべき改革の方向性は多種多様だ。しかしどんな方向であっても、大きくなってしまった政府を「小さくする方法」や「小さくする手順」について、合意を形成するのは容易ではないようだ。

その結果、国会議員達は同じような質問を繰り返し、内閣は同じような答弁を繰り返す。

『質問書』は深夜に提出され、『答弁書』は夜中に作成され、『大臣レクチャー』は早朝に行われる。国会自身が「行政の肥大化」を助長させている。彼らの言う「生産性向上」は、もはや寝言でしかない。


国会議員による質問方法


そもそも国会議員の仕事は、テレビ映りの良い「議場パフォーマンス」ではない。

民間に言わせれば、朝9時から夕方まで大臣ほか時給の高い人達を拘束しつづける委員会審議なんぞ、単なる「長時間会議」にしか過ぎない。もし「取締役会」が朝から晩まで開催され、挙げ句の果てに一部の取締役達が「退席アピール」をしているとすれば、投資家達はどう思うだろう?

内閣提出法案や国政全般について正すべき事項があると感じるなら、「質疑」よりも「質問」(質問主意書)をもっと多用すべきだ。そして、(民間のFAQサイトではないが)、質問をするときは過去の質問(FAQ)を参照すべきだ。あえて同じ質問をしたいなら、「FAQ-20161213-01 の答弁内容に変化はないか?」と聞けば良い。そうすれば内閣は「はい」とクリックするだけでよくなる。

「審議時間が短い」とだけ連呼する議員に、「国益」を語る資格はない。(むしろ質問の数をKPIとせよ)

[内閣答弁作成プロセス]

「現場の業務プロセスが見えない」?


2016年秋、日本では『キュレーション・メディア』による「パクり行為」が大きく報道されている。

そもそも「情報を整理する行為」は価値のある作業であり、誰でも整理記事を投稿できる「情報共有サイト」(キュレーション・プラットフォーム)も価値ある存在と言える。しかし、サイト運営会社(東証一部上場企業)自身がクラウドソーシングを通じて記事を量産し、そのアウトソースの中で「パクり」をマニュアル化していた実態が明るみになったのだ。

キュレーション記事の制作プロセス

たしかに、
"当社は、この記事の情報及びこの情報を用いて行う利用者の判断について、正確性、完全性、有益性、特定目的への適合性、その他一切について責任を負うものではありません。"
という免責注記はあった。しかし、当のサイトが「健康や命に関わる記事」を集める情報共有サイトであったため、「著作権侵害」というよりもむしろ「モラル」が問われた形だ。そして、結果としてCEOが「記事制作のプロセスに問題がある」と謝罪する状況になったのだ。

DeNAプレス:CEOからのお詫びとご説明
"他サイトからの文言の転用を推奨していると捉えられかねない点がございました。この点について、私自身、モラルに反していないという考えを持つことができませんでした。(中略)。自分自身として心の底から自信の持てるプロセスを構築していくことを約束します。"

真実かどうかは知る由もないが、おそらくは「本当に業務プロセスが見えていなかった」のだろう。(と信じたい)。では、運営会社が責任をもって記事を書く必要がある場合、どのような業務プロセスを構築すれば良かったのだろうか?

[記事作成プロセス]
「業務フロー設計を試してみたいのですが…」

『プログラミング』の世界においては「唯一の道はプログラムを書いてみること」と言われる。事実、プログラミングを始める時、誰しもが "Hello World" という文字列を表示させるプログラムを書く。これと同様に『モデリング』の世界でも「業務プロセスを描いてみること」はとても大切だ。


以下の業務プロセスは、「メール受信」で開始され、「チャット投稿」で終わる。

そもそも業務プロセスとは、何かの『キッカケ』で始まり、そして幾つかの『工程』が続くものだ。しかし、この例には『チャットに投降する』という処理工程が1つあるだけだ。しかもそれは「コンピュータによる処理」(自動処理)であって「人による処理」は一切ない。(何ということだ!)

[チャット投稿フロー]

「請求データの入力、面倒。。。」

銀行入出金やカード支払などのログが「自動仕訳」されるようになり、ひと昔前と比べて「経理の入力作業」は随分とラクになった。

しかし、特に『売上高』に関して言えば、『入金』のタイミングを待っていたのでは遅すぎる。やはり『請求書』を発行した時点で『売掛金売上』にしたい。。。というか、しなければならない。
  • 2016-11-22: 売掛金 120,000 / 売上高 120,000 = ホームページ制作(A社向け)
  • 2016-12-31: 普通預金 120,000 / 売掛金 120,000 = ホームページ制作(A社向け)

ちなみにその逆に、『請求書』を発行した時点では、(『入金』があった時点でも)、『売上高』にできないケースだってある。
  • 2016-12-31: 普通預金 120,000 / 前受金 120,000 = 保守2017-01~2017-12(A社向け)
  • 2017-01-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-01分
  • 2017-02-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-02分
  • 2017-03-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-03分
  • 2017-04-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-04分
  • 2017-05-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-05分
  • 2017-06-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-06分
  • 2017-07-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-07分
  • 2017-08-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-08分
  • 2017-09-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-09分
  • 2017-10-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-10分
  • 2017-11-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-11分
  • 2017-12-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12(A社向け)2017-12分

いわゆる「振替伝票」(振替レコード)の作成方法や作成タイミングについては、業種業態だけでなく会社方針によっても様々だ。とは言え、その作成作業そのものは、ぜひとも「自動化」したい。

以下のワークフローでは、『請求書』が上司承認された瞬間、
  • 顧客に請求書PDFがメール送付され、
  • 複数行の「振替レコード」が自動計算され
  • インポート用ファイルが自動生成される。
経理担当は自動生成された Excel-CSV ファイルを、会計システムにアップロードするだけで「入力作業」を終えることができる。

[請求書発行プロセス]
「法人カードのセイで、経費全体が把握しづらい」

業務プロセス改善は「ムダな業務」や「手間のかかる手続き」を減らす。しかし、それにともなって「人間によるチェック」は手薄になる傾向がある。

たしかに「ワークフローの4大アプリ」
  • 立替金精算フロー
  • 調達購買フロー
  • 勤怠報告フロー
  • 稟議フロー
のような発生頻度の高い業務において、「業務効率化をすすめた結果、抜け道(不正方法)ができてしまった」とすれば問題だ。ただ「省力化・無人化」と「チェック体制の強化」はトレードオフの関係になることが多い。結局のところ「自社に合わせた落としどころ」を模索しかないのだ。


以下の経費精算フローは『立替金を精算すること』が主目的の月次申請型の業務フローだ。

この例では、同時に立替金としての精算を要しない経費(ゼロ円立替)について、承認を得られるように工夫されている。これは「クレジットカードでの支払い」や「仮払金を受けている旅費」についての事前の上司承認を無くしてしまうという発想だ。

申請者自身にとっても、一度の申請で「手間が省ける」だけでなく「毎月どの程度の会社経費を使っているか自覚できるようになる」という効果があるだろう。

[経費および立替金の報告]
「年末調整、書くの、メンドクサァーイ!」

日本では年末になると、全ての会社で「2枚の書類」の提出が命じられる。給与所得者達は毎年恒例の紙を見て「あぁ年の瀬なんだなぁ」などと思う。そして、記入し始めると相変わらずの面倒さにイライラする。(その後、管理部門は記入モレの多さに溜息をつく。)

◆[マル扶]扶養控除等(異動)申告書の受理と内容の確認
「家族の住所は "(同上)" って書いてイイんだったっけ?」
「マイナンバーは "提供済番号と相違なし" って書くんだっけ?」
「ていうか、家族の生年月日がワカラナイ・・・」

◆[マル保]保険料控除申告書/配偶者特別控除申告書の受理と内容の確認
「定期保険特約付終身保険、、、長いって」
「60歳支払開始据置終身年金保険、、、長いって」
「郵便貯金・簡易生命保険管理機構、、、だから長いって」

たしかに年に一度きりの「季節行事」ではあるのだが、楽しめるものではない。日本中の5000万人が30分イライラするとして、どれほどの GDP が損なわれている事だろう?? (せめて「手書き」からは早々に脱却したい)
※ ちなみに「1億枚の紙」や「それを保管するための書庫」がモッタイナイという話については、『電磁的方法による提供の承認』という話になる。要するところ、『源泉徴収に関する申告書に記載すべき事項の電磁的方法による提供の承認申請』の提出が必要となるのだが、詳細については、また別の機会に。。。


以下の2つのワークフローは、申請者が申請し、管理部が確認受理するワークフローだ。すべてがオンラインで完結する。

しかも次年度からは前年の申請データを「再利用して開始」すれば良い。前年申請をこのフローで提出した人なら、[マル扶]の『平成28年』を『平成29年』に、[マル保]の『平成27年』を『平成28年』に書き換えるだけで終わる。(「家族が増えた」とか「保険を変えた」とか、そう言った事情がないという前提)

[扶養控除申請フロー / 保険控除申請フロー]
「正式な社名で入力して!」

仕入元や得意先など、取引先は「マスター管理」したいものだ。しかし「正式な社名でマスター登録を!」と言い続けても、
  • アルファベットだったり、カタカナだったり、
  • 大文字だったり、小文字だったり、
  • 全角だったり、半角だったり、
  • スペースがあったり、無かったり、
どうしても入力者によって「ゆらぎ」が発生してしまう。


2015年10月、日本政府(国税庁)は全ての国内法人に対して『法人番号』を割り振った。そこでは「正式な社名」(商号)などが厳格に管理されている。しかも無料で使える Web-API も運用されている。コレは、もはや「インフラ」であり、使わない手はない。

以下のワークフローは、新しい取引先の情報を入力すれば、自動的に「取引先コード」と「取引先名称」が SpreadSheet 追記される仕組みだ。やや手間にはなるが「法人番号」の入力によって「正式な社名」が担保される。「名寄せ」や「データクリーニング」の悩みから解放されるという点において、極めて大きな意味がある。

そう、これで、「ビッグデータ」が「ビッグ・ノイズデータ」になってしまわなくて済む。

[取引先マスター追加]

「やってしまった…、ダブルブッキング…」

『往訪対面』での商談スタイルから、"Google Hangout" などによる『オンライン・セールス』というスタイルに変えた。。。かつては1日に3件の商談を入れれば「スケジュールが一杯!」と思ったものが、今では倍の6件の商談予定を入れても余裕がある。ただ、商談回数の視点から見えれば、いわゆる『生産性の向上』が実現できたのだが、「スケジュール調整が煩雑になってきた」という新たな課題が顕著になっている。。。。

以下のワークフローは「製品デモ」の業務フローだ。

基本的な流れは、お客様からの「製品デモ依頼」(希望日時)に対して、対応可能なセールスマンが自主的に引き受ける、というフローだ。実際の「スケジュール調整」については電話やメールで行い、日程が確定すれば第2工程[2.デモ日程の決定]にてスケジュールを書き込むという流れだ。

秀逸な点は、(一見地味にも思える機能だが)、「確定スケジュールが自動的に Google Calendar に追記される」という仕組みだ。スケジュール情報が「カレンダー」の上で確認できるのは、とても分かりやすい。(というかCSV風なデータリストはとても見づらい)。これで「ダブルブッキング」の発生が大幅に下がった。

しかも「Questetra の案件詳細ページ」への直接リンク(※)も貼られているので、[3.デモ実施報告]の工程もスムーズだ。マッシュアップ万歳!
※ ${var[applicationRoot]}OR/ProcessInstance/listView?processInstanceId=#{processInstanceId}

[製品デモ業務]
「あのプレゼン資料、PDFではなく、PPTファイルで下さい!」

社内のファイル共有。。。イマドキであれば「クラウド型ストレージ」を活用しているだろう。(昔は「ファイルサーバ」ってのがありましたが。。。)

ただ「関連会社や代理店とのファイル共有」や「共同プロジェクトにおけるファイル共有」といった場合、相手が『社内』ではないので、色々とメンドウだ。もし「メール添付で共有する」となれば、催促するまで届かなかったり、関係ないファイルも一緒に届いてイラっとしたり、逆に自分自身も「欲しいと言われるまでは共有しなくてもイイか…」と躊躇してしまったりしてしまう。(そもそもメールプロトコルには、セキュリティ面での不安もある)

そんな時には「ユーザ数10億人」の Google アカウントを活用するのが良い。

「Google Drive」にプロジェクト用のフォルダを作って、そのフォルダの共有設定でチーム全員の「Google アカウント」を追加しておけばよいのだ。(「Google アカウントを持ってない人」が居ませんように・・・・)


以下はチーム内のワークフローで承認されたファイルが、自動的に「Google Drive」にアップロードされる仕組みだ。

もし『G Suite』(Google Apps)のユーザが居て「社外共有」が認められているのであれば、Questetra 標準の[サービスタスク(Googleドライブ)](M229)を配置すれば済むのだが、、、このケースでは「Google Drive」が、一般の gmail.com / googlemail.com アカウントで運用されることが想定されている。

[ファイル承認フロー]
「毎月の入金確認、メンドウだわぁ」

決済にまつわる悩みは尽きない。「オンラインバンキング」が便利になってきたとはいえ、「請求書の発行」から「入金の確認」には、それなりの手間がかかる。

さらに「未入金」が発生すると「督促する」という作業まで発生する。これは単に「手間がかかる」(工程が増える)というだけの話ではなく、払う側・受け取る側の双方に、精神衛生上の負担までもかかってしまう。もっともっと「電子決済化」できないものか??


以下の業務プロセス定義は、「ピアノ教室の月謝」がカード決済されるワークフローだ。

この例では、(「毎月固定の月謝」ではなく)、「レッスン回数に応じた費用」が月末にカード課金される仕組みとなっている。たとえば、レッスンを2回受けた月は2000円、5回受けた月は5000円、といった具合だ。(オンライン決済には『Stripe』が使われる)

このワークフローでレッスン費用の電子決済化を実現すれば、レッスンを受ける生徒に「請求書」を手渡しする必要がなくなる。レッスンを受けさせる親にしてみても、毎月銀行にレッスン費用を振り込みに行かなくてよくなる。

ちなみにクラウド型ワークフロー『Questetra BPM Suite』は、「スタッフ10名以下」なら無料で使える。しかし、ログインの間隔が15日を超えると「サービス停止」になってしまうので注意が必要だ。もっとも、レッスンの終了の度に「レッスン実施日」(課金情報)を書き込みにログインすれば問題ない。

[レッスン費用カード課金]

「監査法人への書類提出、メンドクサイ!」

事業会社はそう思っているかも知れないが、会計監査人だってツライ。この「印刷書類の山との闘い」、何とかスマートにならんものか・・・と日々悶々としているのだ。
  • 「必要書類がナイ」とか
  • 「不要な書類がアル」とか
そんな事態が連発すれば、心がポキっと折れてしまう。

以下のワークフローでは、成約に至った見積書がリアルタイムに共有される。何と言うことはない、監査法人側が管理する Dropbox フォルダに対してデジタルファイルが逐次アップロードされる仕組みとなっているのだ。「工程の無人化」というヤツだ。

しかも、人間が「提出すべき書類」を選んでコピー機にかけるのとは違い、ヌケモレは発生しない。ファイルの検索だって簡単だ。

そして、事前に調査できることも多く、現場におもむく回数だって減らせるに違いない。

すばらしい!

※ この例は『第499話:ナンデ見積提出の概況が分からないんだ!』とほぼ同じ(自動工程が一つ追加されている)
※ 既存プロセスに工程を追加する際は、あらかじめ[アドオンXML]を入手し、機能追加ファイル(プロセスモデルファイル)としてインポートする

[見積作成フロー-Dropbox]

「顧客マスターは kintone で管理したい!」

『kintone』は日本で人気の「クラウド型データベース」だ。同じく簡易なクラウド型データベースである『Google SpreadSheet』と比べると、機能面では限定される部分が多いものの、その分、クラウド初心者には使いやすい。

そして「顧客管理」は、最も多い kintone 利用用途の一つだ。


以下のワークフローは『kintone 上の顧客マスター』を参照して、『ワークフロー環境上の顧客マスター』を更新する同期プロセスだ。前回記事『第502話:ユラギを無くすには「マスター参照」でしょ!』と全く同じフローで、毎朝5時に自動実行される。

異なるのは『Google SpreadSheet 上のマスター』を参照するのではく、『kintone 上のマスター』を参照するようになっている点だけだ。

[取引先マスター同期-kintone]
法人名の「ゆらぎ」が頻発!

見積書や請求書の宛先データが、「日本電信電話株式会社」になってたり、「日本電信電話(株)」になってたり、「NTT株式会社」になってたり・・・。やはり、見積書作成フローや請求書作成フローの入力フォームは、(TEXT フォームではなく)、セレクト方式にせざるを得ない。でなければ、集計に耐えないデータが溜まっていく一方だ。

いわゆる『顧客マスター』はスプレッドシートで管理しているのだが。。。


以下のワークフローは、『ワークフロー環境の顧客マスター』が、Google スプレッドシート内のデータによって自動更新される仕組みだ。様々な業務フローで「顧客名選択」というセレクト方式の入力フォームを設置することができるようになる。しかも、その入力フォームは、常に最新の『顧客マスター』が維持されるのだ。

※ ここで使われている[Sheet参照]という自動工程(サービスタスク)は、あらかじめ[アドオンXML]によって機能拡張しておく事で利用可能となる。(v11.1: 2016-09-05)

[取引先マスター同期]
「今期の "接待費"、いくら使ったんダロ?」

営業部長たるもの、これまでに「稟議決裁した外部支払の総額」については、キチンと把握しておきたい。できることなら「稟議決裁を要しない支出」も含めてキッチリ把握しておきたいものだ。(平たく言えば、営業部の「オコヅカイ帳」をマジメに管理したい。。。堅く言えば「予算管理」をしたいという話。)

以下のワークフローでは、決裁依頼が回ってくるときに「今までの支出総額」があわせて表示される。具体的には Google シート「予算消費ログ」(通称:オコヅカイ帳)にある支出の総額が自動的に計算される仕組みとなっている。しかも、新たに決裁した瞬間、その決裁した支払予定が「予算消費ログ」に自動追記される仕組みでもある。


もし「予算消費ログ」の精度を上げたくなった場合には、
  • 実際には消費されなかった決裁ログは削除する
  • イレギュラーな少額経費については手作業で追記する
と言った運用の工夫や
  • 稟議不要の「広告出稿フロー」から自動追記させる仕組みを作る
  • 立替金申請フローからも予算消費に該当する費目について自動追記される仕組みを作る
と言った業務プロセス改善が必要になってくるのだろう。が、しかし、まずは概算が把握できるようになるだけでも大きな進歩だ。(たぶん)

ちなみにこのサンプルを使えば、半日もあれば「専用の稟議クラウド」を構築できる。申請者をダンナに、決裁者をヨメに設定して、家庭内で運用してもらっても構わない。(たぶん)

[稟議フロー-Spreadsheet記録]

ここ数年、会計システムにも「クラウド化」の波が押し寄せている。

日本においては、老舗のソフトメーカが『クラウドサービス』を開始したのが大きい。具体的に言えば『MFクラウド会計』と『freee』のマーケットに、2015年7月『やよいオンライン』が参入してきたのだ。中堅・大手向けの機能も拡充されつつあり、もはや「ベンチャー企業」や「個人事業主」だけのツールとは言えない。

最大の利点は「銀行入出金」と「クレジットカード利用」の『明細データ』を一括して取り込めるところにある。すなわち、全ての明細レコードは売上伝票や支払伝票として自動的に取り込まれる。しかも、経理部門が手入力すべき各伝票の勘定科目についても「自動仕訳機能」によってあらかじめセットされているのだ。(仕訳性能は目に見えて向上している)


しかし、そんなクラウド会計も、人間判断に基づく伝票生成については、そう簡単には自動化できそうにない。

※ たしかに「前受金にして売上高計上しない」や「売掛金にて売上高計上する」などについては、いつ誰がその判断を行ったのかキッチリと記録する必要もある。(粉飾決算の抑止、内部統制)

以下の業務プロセスは、前受金登録に関する経理ワークフローだ。たとえば「12か月分のサービス代金」が前払いされた際に12件の「振替伝票データ」が自動的に生成される仕組みだ。
  1. 経理担当が「前受金」として判断し、
  2. 上司が承認し、
  3. 会計担当が「振替伝票データ」を登録する
という流れになっている。

[前受金登録フロー]
「いま提出済の見積書、合計は幾ら?」

営業部長なら誰でも気になる売上予算。いや、営業部長でなくても、会社の売上進捗が気になって仕方がない人は多い。
  • 何枚の見積書が提出されているのか?
  • その見積書の総額は幾らなのか??
  • そろそろ「受注報告」が上がってきても良さそうな案件は何???

当然の話だが、、、「売上高」を予想したいなら『見積書トラッキング』が欠かせない。

もし「見積起案」や「見積承認」や「結果報告」といった一連の見積業務が進捗管理されていれば(ワークフローで管理されていれば)、『どの工程に、どんな案件が、何件あるのか?』が一目瞭然となるだろう。フローを流れた過去の案件を集計すれば『受注率』だって簡単に算出できる。

(ていうか、見積書の提出総額がワカラナイなんて「営業部の生産性」が問われる…)


以下のワークフローは「1.見積内容の起案」に始まり「4.受注失注報告」に終わる『見積作成フロー』だ。(将来的には『請求プロセス』に接続したい)

見積作業が開始されれば、営業部長も、営業も、自分が今やらなければならないこと(「見積書を承認しなければならない」、「見積書を客先提出しなければならない」など)が明確になる。そこに「ムダな待ち時間」はない。もちろん「対応モレ」や「報告モレ」なども一切ない。

そして役員連中は、四半期決算ごとに「提出済みで受失注報告待ちの見積書」(第4工程に滞留している見積書)をチェックするのだろう。

[見積作成フロー]
「翻訳した文章、チーム内で共有したいな」

たしかに「メール共有」も悪くない。翻訳作業の完了と同時に、自動的にチームML(メーリングリスト)に送信される設定にしておけば、素早く翻訳文をチーム共有できるだろう。誤訳やブラッシュアップについてのフィードバックを得られる可能性もある。

しかし、受信した人が「指摘したい」と思った時に「メールでの返信」になってしまうのは、うれしくない。今どき、社内の情報交換は「社内SNS」がメインだ。


以下のワークフロー定義では、翻訳作業完了と同時に、社内SNSである[オープンチャット]に自動投稿される仕組みとなっている。クオリティの高い翻訳文に、素早く「いいね」することも可能となる。

[翻訳プロセス-OpenChat投稿]
  • 多言語で説明されている取扱説明文
  • Webサイトの原稿(HTML)
  • ソースコード

そんな原稿制作フローであれば、(「文字数」だけでなく)、「ハッシュ値」も自動記録される仕組みにしておきたい。

ハッシュ値とは、データに対する「要約文字列」(メッセージダイジェスト)だ。「指紋」(フィンガープリント)と呼ばれることもある。要するに、どんなデータからでも瞬時に「32個の16進数文字」(MD5方式の場合)が出力でき、1文字のデータ改竄ですら簡単に検証できるようになる。(詳しくは Wikipedia あたりを参考にしていただきたい)

以下のワークフローでは「ハッシュ値取得(MD5)」および「ハッシュ値取得(SHA256)」という[自動工程](サービスタスク)が使われている。どちらも[アドオンXML]によって機能拡張しておけば利用可能だ。(Questetra BPM Suite v11.1, 2016年9月初旬リリース?)

[翻訳プロセス-ハッシュ値]
この業務に必要な自動工程アイコン、、、欲しー!

業務プロセスを設計(モデリング)していると、さまざま処理を「自動化」したくなるものだ。

2016年8月末にもリリースされるクラウド型ワークフロー『Questetra BPM Suite』(v11.1)では、自動工程アイコンを追加で利用できるようになる。具体的には、パッケージ化された[アドオンXML]を入手し、機能追加ファイル(プロセスモデルファイル)としてインポートすることで、オリジナルの自動工程アイコンが利用できるようになる仕組みだ。


その[アドオンXML]は、多くの場合、
  • Questetra社のサイトからダウンロードする
  • サードパーティ各社から提供を受ける
と言った形で入手するだろう。しかし[アドオンXML]と言う表現からも容易に想像できるように「自作」する事も可能となっている。


以下のワークフローは、前回記事で紹介した『翻訳プロセス』にある[スクリプト工程]を、自作の[自動工程]に置き換えたものだ。

[翻訳プロセス-アドオン]
  • A. 翻訳前の原稿
  • B. 翻訳後の原稿
それらの「文字数」を自動的に記録しておきたい。

たしかに「人間が文字数をカウントしなければならない」なら絶対ヤラナイ作業だが、「ワークフローシステムが自動的に数えてくれる」なら記録として残しておこうと思う。。。


クラウド型ワークフロー『Questetra BPM Suite』の場合、以下に列挙したような自動処理であれば、自動工程アイコンが予め組み込まれているので、簡単に業務プロセスに追加することができる。
  • 文字列Aと文字列Bを結合する(M227)
  • 数値Aと数値Bを足す(M227)
  • 文字列を台紙 PDF に挿入された PDF を生成する(M228)
  • ファイルを Google Drive に保存する(M229)
しかし、この「文字数を数える」の例の様な作業を自動化するには、[スクリプト工程](スクリプトタスク)(M230)と呼ばれる万能型の自動工程を配置し、そのプロパティとしてのスクリプト(ECMA-Script/JavaScript)をセットする必要があった。(Ver. 11.0 時点)

[翻訳プロセス]
特定の「業務データ」を加工したい。
特定の「業務データ」のデータ型を変換したい。
特定の「業務データ」のプロパティとしての文字数を取得したい。

基本的な話として、「ワークフローシステム」は業務データの「受け渡し」を自動化する。ただ「受け渡し」だけでなく、「作業そのもの」についても出来る範囲で自動化(無人化)したいものだ。特に「機械的な作業」であれば尚更。。。

クラウド型ワークフロー『Questetra BPM Suite』の場合、
  • 文字列Aと文字列Bを結合する(M227)
  • 数値Aと数値Bを足す(M227)
  • 文字列を台紙 PDF に挿入された PDF を生成する(M228)
  • ファイルを Google Drive に保存する(M229)
と言った作業であれば、最初から組み込まれている自動工程でサーバサイド処理させることができる。しかし、少しでも「オリジナリティが高い作業」となれば、そうも行かない。

たとえば、以下のワークフローにある『文字数カウンタ』は、上流工程で入力された文字列型データXについて、(サーバサイドにて)、その文字数を数え、数値型データYに格納させる自動工程だ。こういった場合には[スクリプト工程](スクリプトタスク)(M230)と呼ばれる万能工程を配置し、スクリプト(ECMA-Script/JavaScript)をセットする必要がある。(Ver. 11.0 時点では…)

[文字数カウンタ]
日常業務は「共有パスワード」だらけ。。。

ルータを置けば「管理者パスワード」を設定する。ネットプリントに申し込めば「法人アカウント」を登録する。スキャナを買っただけでも「ユーザ登録」が必要となる。幼い日から「絶対にパスワードは他人に教えてはなりません」と教わって大人になったのに、、、現実の大人の世界には「組織内で共有(共用)せざるをえないパスワード」が沢山あるじゃないか!! (そして会社のファイルサーバには、門外不出の秘密ファイルが。。。)

以下のワークフローは「共有パスワード」を管理する業務プロセスだ。

組織用の「パスワードマネージャ」と言っても良い。社員からのリクエストがあった際、その10分後にパスワードが自動開示される仕組みだ。誰が・いつ・どのパスワードを利用したか、すべて自動的に記録されるようになる。(加えて管理者側の「パスワード変更」も記録されるようになる)

[共有パスワード問合]
「顧客リスト」を表計算ソフトで管理している会社は多い。

ただ、、、10年前は当たり前のように『Excel ファイル』が作られていたのに、今では、クラウド型データベースである『Google SpreadSheet』や『kintone』が利用されるケースの方が多くなってきたと思う。つまるところ、
  • いつでも・どこからでもアクセスできる
  • データが消失するリスクを小さくできる
  • データを複製して持ち運ぶ必要が無い
  • サービスプランによっては閲覧履歴を全て残せる
といった利便性をリーズナブルな価格で(もしくは無料で)享受できるのだから、特に中小零細企業には有り難い。

<API 通信のイメージ図>

しかも、クラウド型データベースを使えば、外部システムにも「顧客リスト」を参照させることが可能となる。(API 機能:Application Programming Interface)

以下のワークフローは、「Google SpreadSheet 上の顧客リスト」をワークフロー環境に取り込ませる自動フローだ。この例では、毎日深夜 1:00 に「顧客リスト」が自動的に同期されるようになる。(フローそのものは、以前紹介した kintone 同期とほぼ同じだ)

[顧客マスタ同期プロセス-スプレッドシート連携]

「通帳のログ、転記してるの?」

日本の銀行は「通帳」という冊子をくれる。ATM に挿し込めば、入出金の記録を全てキレイに印字してくれる。しかし「通帳」が紙としての冊子である限り、そこに記載された情報にアクセスできる人間が限られてしまう。かと言って「銀行帳.xls」に手入力するのもメンドウだ。

以下の業務フローは、銀行の入出金ログを Google SpreadSheet に流し込むという業務だ。

銀行のオンラインサービスで入手できる「入出金ログ」をインポートすれば、指定した SpreadSheet に、自動的に追記される仕組みとなっている。この例では「みずほ銀行」や「多くの地銀」が提供している『ANSER-API形式』というタブ区切りファイルを取り込むスクリプトがセットされている。

「オンライン通帳」とでも言えば良いのだろうか。。。便利だ。



[入出金のログ登録]