ラベル 情報管理 の投稿を表示しています。 すべての投稿を表示
ラベル 情報管理 の投稿を表示しています。 すべての投稿を表示

前回、「イベント参加者アンケートに回答期限を設定」では、サービス工程を利用して『7日後に締め切り』をセットしました。アンケートに期限を設けることで、未回答であった場合にも、業務プロセスが滞留し続けることを防ぐことができます。

[イベント受付フロー-アンケート(期限セット)]

『7日後』の設定には、データ設定式を利用しています。
「#now.addDays(7)」と書くことで、「回答期限設定」工程にトークンが到着した時点(#now)から『7日後』を「回答期限(日付)」にセットすることができます。

<「回答期限設定」設定画面>

日付日時を表すデータ設定式には、他にも、
  • ・2時間30分後:#now.addHours(2).addMinutes(30)
  • ・月末:#now.getLastTimeInMonth()
  • ・翌月5日:#today.getFirstTimeInMonth().addDays(4)
といったものがあります。
(他のデータ項目でも「データ設定式」を利用可能です。詳細は「M227: 業務データの結合や四則演算が自動実行されるように設定する」を参照)


前回は、「少人数セミナー」といったイベント受付を行うためのワークフローに、イベント開催後にアンケートを行うための仕組みを追加しました。参加者にアンケート回答してもらい、イベントの感想やフィードバックをもらうことで、次のイベントをより良いものに変えていくヒントになります。

ただ、前回のワークフローでは「アンケート回答されるまで待ち続ける」必要がありました。全ての参加者がすぐにアンケートに回答してくれたら、業務もスムーズに進みますが、残念ながらそういう訳にもいきません。(自分も含めて)アンケートに回答しないときもありますよね。。。

ということで、今回は、「アンケート回答に期限を設ける」ようにワークフローを改良します。期限を過ぎても回答がない場合、案件は自動的に終了するようになっています。


[イベント受付フロー-アンケート(期限セット)]



前回は、「少人数セミナー」といったイベント受付を行うためのワークフローを紹介しました。

担当者によるメール対応を卒業し、受け付けの仕組みをワークフロー化しておくことが、A. データ管理、B. フロー改善、の視点からも望まれます。

イベントが無事に開催された後には、参加者にイベントの感想やフィードバックを聞きたいものです。参加者の声を聞き、次のイベントに反映することで、「イベント開催業務」自体もカイゼンしていくことができます。そのイベントが、セミナーであれば、セミナー内容の見直しにも繋がりますね。

「イベントアンケート」収集用のワークフローを準備して、回答用URL(フォーム開始)をイベント参加者に一括でメール連絡する方法もありますが、今回は、「イベント受付フロー」の後工程にて、アンケートの入力を待ち受ける方法(フォーム待ち受け)を紹介します。

[イベント受付フロー-アンケート]


「ワークフローを試すのにオススメの業務は何ですか?」

よくある質問ですが、どんな組織にもオススメできる業務が「作業依頼フロー」です。「誰かに(ちょっとした)仕事を依頼する」というとメールや電話、口頭で行うことが多いと思いますが、シンプルな依頼こそワークフローを活用したいところです。

「ワークフロー」とは文字通り、「仕事の流れ」「仕事の依頼の流れ(連鎖)」を表したものです。すなわち、組織で仕事を行う上でもっともシンプルな行為である「誰かが誰かに仕事を依頼する」ということこそ、ワークフローの基本(本質)と言えます。

クラウド型ワークフロー『Questetra BPM Suite』では、無料版にお申し込みいただくと、次の「作業依頼フロー」がプリインストールされており、すぐにお試しいただくことが可能です。

[作業依頼フロー]


業務:チェックアウト業務と清掃業務の関係

お客様(宿泊客)が「チェックアウトした」という情報をリアルタイム確認できるようにした。

スタッフは、いつでもスマホ・タブレットで「チェックアウトされた部屋」を確認できるので、手の空いた人は正社員でも「客室清掃のシゴト」を引き受けることができるようになった。(第568話:プロセス改善物語(ホテル編1)、参照)

他のお客様に配慮しつつも「チェックアウトされた部屋」から順次清掃できるようになったので、10時から15時に見られた「清掃タイムトライアル」は無くなり、またレイト・チェックアウトの方や滞在中の方との「ハチアワセ事故」も無くなった。

「チェックアウト工程」から「客室清掃工程」への、ワークフロー、、、「進捗の可視化」って、ホント大事。

課題:夜勤担当からの情報共有

が、しかし、一方でフロント担当は「チェックアウト完了という情報をワークフローシステムにインプットする」という手間が増えた。

たしかに「順次、清掃に着手できる」の意味は分かる。また、自動精算機のおかげもあってチェックアウト時には「部屋のカギを受け取る」くらいしかヤルコトがない。つまり、そのインプット自体が大きな手間だとも思わない。。。が、単純作業というか何と言うか、、、もう少し「ワークフロー」を有効活用できないモノか?

たとえば、フロント担当自身も、何か情報を受け取れないものか?

そこで、、、BPMコンサルタントとも相談しつつ、夜勤担当に「苦情記録」を入力してもらうこととした。つまり「ホテル側のサービスに不手際があった」や「他の部屋に対する騒音クレームを連絡して頂いた」といった夜勤担当からの情報もワークフローに乗せてもらうのだ。そうすれば、フロント担当の「部屋のカギを受け取る」という業務も、マゴコロこめて対応できるようになるかもしれない。。。

[客室清掃業務フロー-苦情記録]

業務:ホテル業務、モロモロ

「生産性革命」の流れは、ホテル業界にも。。。

つまるところ「分業制」は、もはや限界と考えるべきなのだろう。「客室清掃業務」「出迎え業務・見送り業務」「夕食サポート・朝食サポート」「ブログ発信」「売上集計」などなど、、、一つの仕事ができればイイなんて時代は終わった。労働者は、ある程度「マルチなスキル」を持たなければならないのだ。

たしかに同じ24時間営業のコンビニ業界では、アルバイトさんでも「レジ業務」「棚卸業務」「清掃業務」と数多くの業務を担当している。かの「星野リゾート」さんも、もう随分前から「マルチタスク」で回しているらしいし。。。

(政府統計でも「日本の宿泊業の労働生産性は他産業と比較して低い」と明記されてしまうくらいだから、ホント何とかしなければならんのだろう。)

観光産業における人材育成をはじめとした 課題と今後の対応について (2017-02-10)
星野リゾートの取り組み (2014-11-19)

課題:清掃時間の固定化

BPMコンサルタントにも相談し、まずは全正社員で「客室清掃業務のスキル」を持とう、という事になった。

たしかに、清掃はパートさんにマルナゲの状態で、「10時のチェックアウトから15時のチェックインまでしか働けない」とか「スキルアップして正社員にという道もあまりない」といった労働環境については、何となく問題だなぁと思っていた。しかも、その時間帯の正社員たちは、実は結構ヒマだったりする。。。

もし「チェックアウトされた部屋」から順に清掃できれば、正社員だけでもカバーできると思う。

[客室清掃業務フロー]

 

業務:ユーザの所属情報

「管理部」「営業部」「開発部」、、、

たとえば、ホームページの問い合わせをトリガーに発生する「見積作成依頼に対応する」というタスク。自動的に「営業部の誰か」に対してオファーされるが、当然ながら、「営業部に所属していないユーザ」は永久に引き受けることができない。

やはり、ワークフローシステムの運用においては、「組織」の所属メンバが最新状態にメンテナンスされていることが極めて重要だ。もし、こういった基本情報がきっちりメンテナンスされていなければ、プロセスオーナー達の日々の業務プロセス改善も徒労と化してしまうだろう。

※ もちろん、「申請のたびに "上司:田中" と入力させる」といった業務プロセスも定義できる。しかし、それでは効率が悪い。。。(と言うか、違反や不正が常態化してしまいそう。。。)

組織ツリーのサンプル

課題:組織ツリーにない集団

メンバの「所属情報」については、API を使った追加予約や削除予約で自動化されている。(参照:第565話:自動化で実現するIT全般統制)。

しかし、「情報セキュリティ資格保有者」「研修中社員」「テニス同好会」、、、(ん??)、といったユーザの集まりはどうしたものか??? これらを「組織」と呼ぶに、はばかられる。そもそも、組織階層のツリー構造において、どこに位置づけられるべきか分からない。。。たしかに「テニス同好会」はオフィシャルな会社業務を担当しないのでメンテナンスする義理もないのだが、、、「情報セキュリティ資格保有者」や「研修中社員」といったユーザ集団はプロセスオーナーによっては「引き受けルール」の設計に活用したいと思うかもしれない。。。

[アカウント発行およびML登録-予約更新]

業務:ユーザ管理

「社員さんの所属部署変更」が発生したら、情報システム部門の雑務が増える。(風が吹けば…的な?)

例えばイチローさんが『営業部』から『カスタマーサービス部』へ異動するという辞令ケース。。。 Google Group で言えば、『ichiro@example.com』というメールアドレスを『sales@example.com』からメンバ削除し、『cs@example.com』にメンバ追加する処理をしなければならない。

ただし、こういった場合「引き継ぎ」を考慮し、加入組織へのメンバ追加は4月1日に、脱退組織からのメンバ削除は4月30日にセットする、というオペレーションを取っている。

課題:所属情報変更の自動化

Google Group 設定については、『第544話:Google Group 連携で、ラクラクML管理(2)』の業務テンプレを使って、自動化できている! 「API 連携」でタイマー処理についても自動化されているため、ミスやヌケモレはほとんど発生しない。

しかし、、、他にも「グループ設定の変更」は沢山あるのだ。(ディレクトリ・サービスは万能ではない)

あれれ? ワークフロー基盤の組織所属設定も自動変更したいのだが、、、どうやって??

[アカウント発行およびML登録-IT全般統制]

業務:FAXでの受注処理

FAX で注文を受け、受注の判断をする。

一昔前なら「人間がやって当然だったこと」も、クラウド時代の今日では「省力化・無人化の対象」だ。

実際、クラウド型FAXサービス(インターネットFAX)『eFax』を使いはじめたので、「紙」は存在しなくなった。そして、その受信ファイルもクラウド型ワークフロー『Questetra BPM Suite』に自動的に連携されるようになったので、「注文内容の確認」といったヒューマン処理もオンラインでキチンと記録されるようになった。(単純なメール連携)

もう「紙」を探すことは無い。すでに大きく業務改善されてはいる。しかし同時に、もっともっとカイゼンできそうな気がしている。

課題:FAXファイルの総覧

たとえば、こういった「クラウド化」「デジタル化」が進むことによって、業務監査への対応に意外と困っている。

つまり「注文書FAXファイルの存在」について、会計士や内部監査担当に確認してもらいづらくなった。もちろん、ワークフローシステムにログインしてもらい、モニタリング機能やデータ参照機能を使って見てもらえば良いのだが、、、ワークフローシステムには「彼らにとって不必要な機能」が多すぎるため操作に慣れてもらうに時間がかかる。(いろいろ説明がメンドクサイ)

そして彼らの口から「時代に逆行するような一言」が飛び出した、、、「注文書は紙に印刷して綴じておいてくださいよ」と。。。(ガーーーン)

なんとかして「沢山の注文書FAXファイル」を、総覧しやすい形/探しやすい形にできないものだろうか??

[受注FAX処理フロー]


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

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

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


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

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

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

課題:属人的な対応

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

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

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

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

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

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

[脆弱性対応プロセス]


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

[MLメンバー確認]

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

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

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

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

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

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

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

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

各案件のログ

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

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

分析に有用なログ

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

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

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

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

プロセス見直しの季節

4月。

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

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

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

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

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

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

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


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

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


[請求書発行プロセス-滞留]
過去3回の記事
では、「業務プロセス内」の自動化について
  • A. 業務プロセス内の「次の工程」に自動的に進むようにする
  • B. 業務プロセス内の「とある工程」が無人で処理されるようにする
という2視点の違いを解説するとともに、それぞれの設定方法について述べました。


今回(最終回)の記事では「業務プロセス間」の自動化について、整理してみたいと思います。


業務プロセス同士の接続

◇ 業務プロセスの位置づけ

これまでは『見積書承認プロセス』や『受注報告プロセス』といった「個々の業務プロセス」にフォーカスして議論しました。しかし、全社視点での自動化(生産性の向上)を推進するには「業務プロセス同士の接続性」についても考えなければなりません。

このようなステージでは、あらかじめ社内の「業務プロセス」を可能な限り列挙しておくことが改善議論の近道となります。

つまり、全体俯瞰によって各業務プロセスの位置づけや依存関係が明らかになり、また各業務プロセスのあるべき「インプット」と「アウトプット」が明確になります。伴って、業務プロセスの責任者(プロセスオーナー)が目指すべき運用方法や改善方向も明らかになるでしょう。

◇ 業務プロセスの列挙

では社内には、どのような「業務プロセス」があるのでしょうか?

事業内容や組織規模によって大きく異なるのは言うまでもありません。同時に「社内全ての業務詳細を把握できている人は居ない」と考えるべきでしょう。つまり「業務プロセスの列挙」は誰が担当するにしても、ある程度の現場ヒアリングが必要となります。

そして、調査結果の列挙の際は、全体俯瞰しやすいようにカテゴリ分類して列挙するのが重要と言えます。

方法論としては、会社の損益を計算する際の「製造原価」「販売費」および「一般管理費」といった費用区分や、研究機関のプロセス分類法を活用して、社内の業務プロセスをマッピングするのが現実的となります。

<APQCによるプロセス分類手法>
  1. 戦略立案プロセス (Develop Vision and Strategy)
  2. 製品開発プロセス (Develop and Manage Products and Services)
  3. 製品販売プロセス (Market and Sell Products and Services)
  4. 製品納入プロセス (Deliver Products and Services)
  5. 顧客支援プロセス (Manage Customer Service)
  6. 人材開発プロセス (Develop and Manage Human Capital)
  7. IT管理プロセス (Manage Information Technology)
  8. 財務管理プロセス (Manage Financial Resources)
  9. 設備管理プロセス (Acquire, Construct, and Manage Assets)
  10. リスク管理プロセス (Manage Enterprise Risk, Compliance, and Resiliency)
  11. 渉外関係管理プロセス (Manage External Relationships)
  12. 遂行能力開発プロセス (Develop and Manage Business Capabilities)

[見積承認プロセス-受注報告を起動]

[受注報告プロセス-見積承認から起動]

前々回記事『第518話:業務プロセスの自動化とは?(その1)』では、
  • [A] 工程間における案件情報の受け渡しを自動化する
  • [B] とある工程における処理を自動化する
という業務プロセスの自動化についての2つの視点について述べました。

また、前回の記事『第519話:業務プロセスの自動化とは?(その2)』では、『[A] 受け渡しの自動化』が適用可能な範囲と実現方法について述べました。


今回の記事では『[B] 処理の自動化』が適用可能な範囲と実現方法について、整理してみたいと思います。


どの様な「処理」が自動化できるのか

◇ 完全な自動化(自動工程)

『[A] 受け渡しの自動化』が「とある工程から次の工程への案件情報受け渡し」をコンピュータに任せてしまう発想だったのと同様に、『[B] 処理の自動化』は「とある工程内の作業」をコンピュータに任せてしまいます。

たとえば「見積書の作成承認」のような人間依存度の高い業務プロセスにあったとしても、
  • 見積書 PDF ファイルを作成する
  • ファイルを添付してメール送信する
  • 見積概要を社内ソーシャルに投稿する
といった工程であれば、完全にコンピュータに任せてしまうことが可能です。

※ ちなみに『[A] 受け渡しの自動化』と対比させる必要が無い場合には、(『自動化』という言葉を使わず)、『業務プロセスの一部工程を「無人化」する』といった表現の方が分かりやすいかも知れません。


◇ 部分的な自動化

一方で、完全に任せてしまうわけではない工程もあります。

たとえば「見積書の作成承認」という業務プロセスにある「見積案を作成する」という工程で言えば、
  • 見積総額を計算する
  • 消費税額を計算する
といった支援機能は業務の省力化に貢献します。しかし、このケースは「見積書の作成」という工程が無人化できている訳ではなく、何らかの人間入力(ヒューマンインターフェース)が必要です。したがって、この様な工程は「ヒューマン工程」(人間工程)に分類すべきだと言えるでしょう。

[見積書の作成承認プロセス]

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

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

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

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

<トップ5記事>

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

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

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

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

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

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

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

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

しかし、特に『売上高』に関して言えば、『入金』のタイミングを待っていたのでは遅すぎる。やはり『請求書』を発行した時点で『売掛金売上』にしたい。。。というか、しなければならない。
  • 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 ファイルを、会計システムにアップロードするだけで「入力作業」を終えることができる。

[請求書発行プロセス]
「正式な社名で入力して!」

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


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

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

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

[取引先マスター追加]