第521話：業務プロセスの自動化とは？（その４）

過去3回の記事

• 『第518話：業務プロセスの自動化とは？（その１）』
• 『第519話：業務プロセスの自動化とは？（その２）』
• 『第520話：業務プロセスの自動化とは？（その３）』

では、「業務プロセス内」の自動化について

• A. 業務プロセス内の「次の工程」に自動的に進むようにする
• B. 業務プロセス内の「とある工程」が無人で処理されるようにする

という２視点の違いを解説するとともに、それぞれの設定方法について述べました。


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

業務プロセス同士の接続

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

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

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

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

◇ 業務プロセスの列挙

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

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

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

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

＜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. ＩＴ管理プロセス (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)

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

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

第520話：業務プロセスの自動化とは？（その３）

前々回記事『第518話：業務プロセスの自動化とは？（その１）』では、

• [A] 工程間における案件情報の受け渡しを自動化する
• [B] とある工程における処理を自動化する

という業務プロセスの自動化についての２つの視点について述べました。

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


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

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

◇ 完全な自動化（自動工程）

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

たとえば「見積書の作成承認」のような人間依存度の高い業務プロセスにあったとしても、

• 見積書 PDF ファイルを作成する
• ファイルを添付してメール送信する
• 見積概要を社内ソーシャルに投稿する

といった工程であれば、完全にコンピュータに任せてしまうことが可能です。

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

◇ 部分的な自動化

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

たとえば「見積書の作成承認」という業務プロセスにある「見積案を作成する」という工程で言えば、

• 見積総額を計算する
• 消費税額を計算する

といった支援機能は業務の省力化に貢献します。しかし、このケースは「見積書の作成」という工程が無人化できている訳ではなく、何らかの人間入力（ヒューマンインターフェース）が必要です。したがって、この様な工程は「ヒューマン工程」（人間工程）に分類すべきだと言えるでしょう。

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

第508話：法人番号APIで「顧客マスター」を正式商号化

「正式な社名で入力して！」

仕入元や得意先など、取引先は「マスター管理」したいものだ。しかし「正式な社名でマスター登録を！」と言い続けても、

• アルファベットだったり、カタカナだったり、
• 大文字だったり、小文字だったり、
• 全角だったり、半角だったり、
• スペースがあったり、無かったり、

どうしても入力者によって「ゆらぎ」が発生してしまう。


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

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

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

[取引先マスター追加]

第507話：スケジュール情報を『Calendar 連携』で！

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

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

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

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

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

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

[製品デモ業務]

第504話：監査書類を Dropbox に自動保存！

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

事業会社はそう思っているかも知れないが、会計監査人だってツライ。この「印刷書類の山との闘い」、何とかスマートにならんものか・・・と日々悶々としているのだ。

• 「必要書類がナイ」とか
• 「不要な書類がアル」とか

そんな事態が連発すれば、心がポキっと折れてしまう。

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

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

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

すばらしい！

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

[見積作成フロー-Dropbox]

第499話：ナンデ見積提出の概況が分からないんだ！

「いま提出済の見積書、合計は幾ら？」

営業部長なら誰でも気になる売上予算。いや、営業部長でなくても、会社の売上進捗が気になって仕方がない人は多い。

• 何枚の見積書が提出されているのか？
• その見積書の総額は幾らなのか？？
• そろそろ「受注報告」が上がってきても良さそうな案件は何？？？

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

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

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


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

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

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

[見積作成フロー]

第485話：「カタログ送付先リスト」に対して自動追記する（kintone API）

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

公開Webフォームで受け付けた「資料請求」には素早く対応したいものだ。しかし、お客様に入力していただいた『住所』や『会社名』を間違えるとサムイ。。。たとえば「Word送付状」にコピペする時に、参照すべきレコードが一件ずれてしまい、

• ウチ、そんな社名じゃないよ
• ウチに、そんな社員はいないよ

などというクレームにつながれば、場合によっては「個人情報漏洩事件」とすら言われる可能性がある。


以下の業務プロセス定義は、『受付担当者』が

• 入力途中で送信してしまった様な未完成な住所だったりしないか？
• イタズラ目的のデタラメ住所になってないか？
• 省略表記や無用なスペースなどが混ざっていないか？

などをチェックした後に「送付状PDF」は自動生成され、『郵送担当者』はそのPDFを印刷して資料を封入流れとなっている。そこに人手は介在しない。

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

[資料請求対応業務]

取引先マスターを参照する見積書作成フロー

最近の『ワークフローシステム』は、見積現場のニーズにも上手に応えている。

• A. 「本社にいる上司」の "承認" が必要
• B. 「顧客」に提出するための "紙" も必要

つまり単に「スマホ対応」しているだけでなく、いわゆる「帳票出力機能」を持つワークフローも多くなっているのだ。しかし、そんなワークフローシステムであっても、

• X. 「セールスマン別」の集計もしたい
• Y. 「顧客別」の集計をしたい

となれば更なる工夫が必要となるだろう。つまり、、、たとえば、顧客名の入力で「ゆらぎ」が多発してしまう様な現場であれば、スムーズな集計は望めなくなる。すなわち、次の３つの視点を事前考察しておかなければならないと言える。

• o. 「見積書」の Group 管理
• x. 「セールスマン」の ID 管理および Group 管理
• y. 「顧客」の ID 管理および Group 管理

以下のワークフローは、顧客名の入力に「取引先マスター連動フォーム」を利用する。（検索コンボボックス）

[見積書作成業務]

法人番号を使った取引先マスターの管理（一括更新編）

仕入元の「名称」（商号）が変わる。良くある話だ。

得意先の「優先度」を変える。これも良くある話だ。

以下は「取引先マスター」を一括してメンテナンスする業務フローだ。営業事務チームによって、定例の「月次見直し」と、随時任意の「臨時見直し」が行われる。

この特別なワークフローで「取引先マスター」を更新すると、ワークフロー基盤上の多くワークフローで表示される『顧客の一覧』（選択肢プルダウン・コンボボックスのリストなど）を一斉に切り替えることができる。言い換えれば、「見積書承認フロー」「請求プロセス」「修理依頼対応プロセス」など、それぞれの業務プロセスを設計運用している各プロセスオーナーは、『顧客の一覧』のデータについて、メンテナンスする必要がない。

※ 取引先マスターへの「個別追加」については前回記事を参考されたい

[取引先マスターのメンテナンス業務]

法人番号を使った取引先マスターの管理（追加更新編）

ワークフロー基盤が『顧客マスター』を持っていれば、色々と都合が良い。

もし「自由なテキストフォーム」で入力させていると、

• 「NTT」だったり、「日本電信電話株式会社」だったり
• 「NTT西日本」だったり、「西日本電信電話株式会社」だったり
• 「NTTデータ」だったり、「エヌ・ティ・ティ・データ」だったり
• 「NTTドコモ」は、「NTTドコモ」のままで良かったのに…

そして「株式会社」が、前株だったり後株だったり、、、（そもそも）、あったりなかったり。。。 ナンにせよ法人名の入力が発散して仕方ない。。。俗に『名寄せ』ど呼ばれる作業は「非常に不毛な作業」と言わざるをえない。


以下のワークフローは「取引口座開設業務」だ。

一見すると前回記事（与信管理フロー）とほぼ同じフローだが、、、新しく取引先を登録する際に『顧客マスター』（Business-Connections.xml）が自動的に更新される仕組みとなっている。

この『顧客マスター』は、他の業務フローから、「プルダウンメニュー選択」や「テキスト入力中にリストが絞られるコンボボックス」として呼び出せる。つまり「見積書承認フロー」「請求プロセス」「問合対応プロセス」において、入力される法人名は、必ず『顧客マスター』から選択され、常に「正式な社名」が入力されるようになるのだ。

[取引口座開設業務]

法人番号を使った取引先マスターの管理

「商品と現金は同時に交換される」、、、とは限らない。 むしろ企業間取引においては「同時に交換されない」の方が一般的だ。つまるところ、企業間取引においては、、、

どちらかが相手方を『信用』する必要がある。

1. 商品と請求書を渡し、翌月末までに送金してもらう （売掛金）
2. 現金を振り込み、後日商品を配送してもらう （前払金）

そこで多くの企業は、全ての取引相手に対して『信用限度額』を設定する。初めて設定する際の手続きを特に「取引口座開設の手続き」と言う場合もある。 （ちなみに、どちらが『信用』を与える側（与信者）になるかは、「商品が先」か「現金が先」かによって決まる。ドラマや映画で目にする「身代金の受け渡しシーン」と同じ構造だ。）


以下のワークフローは、非常にシンプルな「与信管理」の業務フローだ。特定の取引先に対して『信用限度額』を設定する。具体的には、「相手方から直接もらった財務書類」や「信用調査会社からの情報」、あるいは「これまでの取引実績」や「事業戦略上の優先度」などの情報から上司が判断し、最終的には CFO が決裁する。（そして日々の「売掛金」は、そこで設定された限度額の中で総額コントロールされる）

このワークフロー定義の注目すべきは、2015年10月に日本政府が運用を始める「法人番号」(マイナンバー法)を活用している点だ。「名寄せの失敗」（限度額の多重設定）を防ぐことができる。

[与信管理フロー]

マイナンバー制度における「チェックディジット」の役割

いよいよ、後１か月。。。

日本でも個人番号制度「マイナンバー制度」が始まる（2015年10月5日）。当ブログでも『個人番号の収集プロセス』について、いくつかのワークフロー（業務プロセス）を例示してきた。

• X. (基本パターン)
• A. 中小企業パターン
• B. 支店毎に本人確認
• C. 本店のみで本人確認
• D. 複雑な申請ルートで本人確認

そして、次週以降は「法人番号」の利活用についても、その事例を紹介していく予定となっている。法人番号システム『Web-API 機能』の活用事例についても、「事前検証環境」にて動作確認でき次第、順次公開していく予定だ。


今回は「マイナンバー」を取り扱う業務でかかせない「誤り検出」についてまとめておく。
以下のワークフロー定義は、入力データの「正確性チェック」を体験できるサンプルだ。[1] 入力中データが自動的にチェックされる仕組み(入力画面での JavaScript)と、[2] サーバ側にてデータチェックされる仕組み(スクリプト工程での JavaScript)の両方が設定されている。

なお、チェックディジットとは「検査用文字」という意味だ。『クレジットカード番号』や『商品コード』(EAN/JANバーコード)や『国際標準図書番号』(ISBN)などでも幅広く活用されている。日本の『マイナンバー』の場合は、

• 法人番号（13桁数字）: 左端の数字
• 個人番号（12桁数字）: 右端の数字

が「一定の計算式」によって算出され、付加されている。

[Check Digit サンプル：「TEST Form」画面]

見積データの一元管理（PDFの自動生成）

「"値引き要求" に応じてでも、売りたい！」

もちろん業種に依存する話だが、ビジネスの現場において「承認が必要な見積書」が必要になるケースは少なくない。「納期」や「見積金額」などが微妙に違う見積書、、、が何枚も必要になることだってある。

しかし上司にしてみれば、似たような「見積書」をタクサン見せられても、スグには承認できない。

• 「納期」はコレで良いのか？
• 「値引金額」はコレで良いのか？？
• 「見積有効期限」はコレで良いのか？？？

承認者のシゴトは、他の見積書と比較して判断するコトだ。（転記ミスや誤植を探すのがシゴトではない）

以下の見積承認プロセスでは、見積データが承認された後に、自動的に「見積書PDF」が生成される仕組みだ。承認判断の工程では、業務データに集中して承認できる。たとえば、過去に承認した見積書や、過去に否決した見積書の［データ項目］を比較して判断する事もカンタンだ。

当然のことだが、このワークフローに従って日頃の見積承認業務を処理していれば、見積データが綺麗に蓄積されていく。また、承認された見積書PDFも全て自動的に蓄積されていく。前任者のナレッジも引き継ぐことが出来る。すばらしい。

[見積承認フロー]

自動処理スクリプトで、案件タイトルをセット

"プログラミング不要"。。。 業務システムの世界でも、相変わらずホットなキーワードだ。

• A.プログラミング知識が不要
• B.プログラミング知識が必要

意味する所は Java や Python や Ruby といったプログラミング言語を使わないと言うだけの話だが、斬新で自分に合った IT 環境を創りたいと言うニーズが、そこにある。

少し乱暴なたとえになるが、たとえば "A.既製品の衣服をいじって使うべき" か "B.完全オーダーメイドの衣服を創るべき" かといった議論にも近い。どちらの方法にも長所短所があり、必要とされる IT 環境や、その運用者のスキルによって、採用すべき方法が異なる。

さて、以下の業務プロセス定義には [スクリプトタスク] と呼ばれるプログラミング知識を使う工程が組み込まれている。

業務の流れ全体は "A.標準処理アイコン" で表現しつつ、一部の工程において "B.独自の演算処理" が組み込まれている。実は、前回記事で紹介した "顧客名を入力する上流工程、そのテンプレート" を [スクリプトタスク] によってブラックボックス化させたにすぎない。つまり、データ処理の内容は全く同じだ。

[見積・受注・請求等の上流フロー]

顧客名を入力する上流工程、そのテンプレート

日常の業務記録、、、"少しの工夫" で大きく価値が変わるかも知れない。例えば、もしも、全てのワークフロー履歴において、

• 顧客名のユラギが無い
• 顧客名が案件の [件名] に正確に表示されている

が実現されたとすれば、様々な "データ活用" が実現するだろう。

例えば、過去の記録を容易に検索できるようになる。（特定案件の検索）
例えば、特定の大企業に対して全営業マンが延べ何回往訪しているのかが集計できるようになる。（業務に閉じた集計）
例えば、"資料請求" から "見積提出" に至るコミュニケーションの推移や期間を分析できるようになる。（業務横断的な集計）

更には普段の活動も変わってくるかも知れない。例えば、闇雲に OJT を唱えるより、実際の業務記録を眺め見てもらう方が、新人教育になるかも知れない。ベテラン社員とディスカッションするより、実際の業務記録を眺め見ている方が、戦略案を発想しやすいかも知れない。

以下の業務プロセス定義は、実際に "顧客名入力" が行われる上流工程だけを記述した、言わばテンプレートだ。下流工程を加筆すれば、例えば "往訪報告" や "資料請求対応" など、様々な業務プロセス定義を簡単に作成できる。

[受注納品請求フロー]

取引先フォームを全て「選択入力」にするためのマスタ管理

「取引先の一覧」は『表』で管理したい。

『表』（Table）は本当に便利だ。「名簿」にせよ、「商品マスタ」にせよ、もし『文章』だけで記述されていたとしたらゾッとする。「法律文」とか、「規程」とか、あるいは「口頭会話」など、『表』が使いづらい状況では全容の把握が困難になる。（『表』＝視覚的な情報管理ツール）

業務システム全体で「共通選択肢」を管理する際も、その選択肢情報をどの様にマスタ管理すべきかは議論が分かれる。ただ、「行(row)と列(column)で管理する」と言うレベルについては、多くに支持されるところだろう。

以下のワークフローは、ワークフローシステム内の「取引先の一覧」を更新する仕組みだ。システム設定の更新を行う特殊なワークフローでもある。実業務としては、「表計算ソフト」である『Google SpreadSheet』等で「取引先の一覧」を管理し、その内の『取引先ID／取引先社名』を第一工程『1.取引先のIDと社名の入力』でペーストする。

この業務プロセス定義（プロセスモデル）の秀逸な点は、「設定有効にする時刻」を決められる点と、「設定そのもの」が記録として残る点だ。

[取引先リスト（表示選択肢）を更新する業務：「1.取引先のIDと社名の入力」画面]

「滞留マップ」で日報ワークフローを加速させよ

調達部門や営業部門に付き物の「日報」。
成果や感想をまとめ、毎日マネージャに提出する仕組みだ。業種業態によっては、非常に有効な情報共有手法だ。提出する側も、コメントを書く側も、毎日のサイクルの中で処理できるのが都合良い。

しかし、一方でこの「日報」、、、マネージャ以外に参照される事は少ない。せっかくの生きた情報なのに、、、せっかくの履歴なのに、、、、何ともモッタイナイ話だ。

以下の報告フロー例『面談報告業務』では、その報告頻度が、「日次」ではなく「都度」を想定している。つまり報告書のタイトルは、『X年Y月Z日 佐藤一郎』ではなく『京都株式会社 X年Y月Z日往訪』となる。

こうしておくと、「取引先名」で検索した際に参照しやすい。ワークフローシステム全体を「取引先名」で検索すれば、『面談報告業務』に格納された履歴情報だけでなく、『発注業務』や『見積提出業務』などの履歴情報も、併せて一覧できるだろう。
例えば、経理担当者が外部からの請求書に疑念を持った際には、過去のコンタクト履歴を素早く参照する事が出来るようになる。例えば、経営者が初期コンタクトから見積業務・成約処理・請求業務と言った時系列の情報を得ることが出来るようになる。社内の情報が一気に整理される。

[面談報告フロー]

SFA 案件登録に至る「プロセス」こそが大事なんチャウ？

多くの営業支援ツール(SFA)では、『商談データ』を登録する。

各商談案件のステータスが可視化され、『将来の受注』（見込み）が精度良く予想できるようになる。具体的には、商談の金額や「20％・80％・100％」などの受注確度を登録する。「引合があった」とか「見積依頼を受けた」とか、登録すべき『商談案件』の定義は各社様々だ。

「もうすぐ【案件】になりそう、、、なんだケド。。。」

しかし、この『登録すべきの判断』は意外とヤッカイである。たとえば「まだまだネタレベル」の案件を積極的に登録する営業マンも居れば、「受注が見えてきた状態」になってから案件登録する営業マンも居る。

上司は言う。「全部だ！ 全部登録するんだ！」

以下の業務プロセスは、活動記録に対する考え方が、少しチガウ。。。
ここでは『案件の視点』ではなく、『面談(接触)の視点』でセールス履歴を記録する。日々の面談活動を登録すれば良いため、特別な「判断」は必要ない。顧客候補との往訪面談・来訪面談・電話会談・Web会議などの完了後(帰り道)に、記録する。「営業日報」と言っても良いだろう。往訪ベースの会社であれば、業務プロセス自体の名前を「往訪報告フロー」と言い換えても良い。

[商談前案件を可視化する面談報告フロー]

ワークフローで「提案書の書き方」を標準化できるか？

4月1日、、、日本では「新年度」だ。
学生達は新しい学年に進級し、新社会人達は始めての出社日を迎え、社会人達は（前期のコトはマーサテオイテ）新しい年度の新しい目標を立てる！

言うまでも無く「業務プロセス」を見直すには絶好の機会だ。
しかし、既に4月1日を迎えてしまっている今日に至って、改めて複雑な業務の改善アイデアを提示するのは「ヤボ」と言うもの。。。以下は、簡単に始められる『提案書レビュー』のオンライン化を提案したい。コレなら、30分で業務フロー図が書けて、30分でワークフローシステムを稼働できる。

この『提案書レビュー』を稼働させれば、チーム内の提案書がどんどん可視化される。
すなわち、「いま誰が、どんな提案書を書き、どんな指摘を受け、どんな改良をしようとしているのか」が可視化され、記録されるるようになる。また、提案書データが日々蓄積される状態になれば、新たに提案書を書こうと思った時にラクだ。過去のイケテル提案書を検索し、それを参照して作ればよい。

[提案書フロー]

ルート営業の活動報告も「業務フロー」だ！その書き方は？

会社の「利益の源泉」はセールス活動にこそある。

そのセールス活動（営業活動）を単純に大別すれば、(a)「新規顧客」に対する販売と、(b)「既存顧客」に対する販売に分けられる。(a)系のセールス活動は「飛び込み」とか「テレアポ訪問」と呼ばれる事もあり、また(b)系のセールス活動は「ルート営業」と呼ばれる事もある。

以下のワークフロー図は、(b)「ルート営業」の業務日報だ。大切な点は、日次報告型ではなく逐次報告型になっているところだ。建材品・飲食業食品・人材派遣サービスなどなど、幅広い様々な業界で活用できる。
「セールス担当」は往訪完了後、主にスマートフォンを使って訪問実績を入力する。すなわち、訪問先の企業名を選択し、「問い合わせを受けた製品(話題の発生)」や「見積依頼を受けた製品(商談の発生)」等について記録する。
セールスメンバの多くに「往訪後スグに報告する習慣」がつけば、自ずと往訪件数がリアルタイムに可視化される。上司視点で言えば、営業戦略の遂行状況（戦いの状況）をつぶさに把握できるようになる。また折々に往訪実績と成約実績を分析する事で、人材配置や新しい営業戦略についても、そのあるべき姿が見えてくるだろう。

[ルート営業報告フロー]