Recently in ビジネスサービスのつくり方 Category

さて、いちおう第1章の「心構えと下準備」から第6章の「業務適用」まで(本は第5章が「プロモーションと運用」なっていますが、業務アプリなので、「アプリ作成」と「業務適用」に分けました)を書いてきましたが、書いているうちに補足したほうがよいものが出てきましたのでそれを付記しておきます。

ここで取り上げた事例である「標準品見積提示プロセス」では、プロセスがすんなりと一本になっていますが、現実にそういうものばかりでしょうか。また、作業アクティビティが見積書作成といった簡単な作業だけなのだろうかという疑問を持たれたかもしれません。そう単純にはいかないようですね。そこで、ここから「ケース分割」と「タスク分解」という考え方を採り入れることにします。

まずはケース分割という考え方です。プロセスはアクティビティが順番に並んだものですが、全部が独立してあるとは限りません。前のアクティビティの結果に影響される、あるいは前の結果が決まらないと次のアクティビティの内容が定まらないといったことがあります。そうした場合にアクティビティの確定データが複数になたったときにケース分割ということをします。たとえば、営業プロモーションでキャンペーンの方法を選定するというアクティビティで展示会への出展とWebサイトを活用というのが選ばれたようなケースです。この2つの方法では、後のアクティビティが違ったものになります。 

これは分岐ですねと言われそうですが、分岐とはちょっと違います。分岐はorが主ですがあくまでand回路だからです。そのとき同じプロセスで扱うと複雑になり混乱してしまいますから、ケースを分けてプロセス化したほうがよいと思います。まあ兄弟プロセスを作るというイメージですね。この検討は、プロセス要素表を書く前に、「業務コンテ作成」というステップを入れてそこでやることにします。コンテというのは、どんな依頼があって、確定すべきことや判断すべきことだけを並べて見ることで、その時複数になったら、別の名のプロセスにするということです。

次に、作業アクティビティをどう扱うかという問題です。何が問題かというと、作業を外側においてしまって(ブラックボックス化)いいのだろうかということです。簡単な作業、例えば書類を作成 するなんてはそれでいいかもしれませんが、この例のように複数の人間が多くの作業を協働するなんていう場合は、ちゃんと見えるようにしておいたほうがいいと思うからです。そこで「タスク分解」という考え方をとって、別にタスク管理アプリを作成(kintone で作成できます)して連携するのがよいでしょう。作業依頼をして作業結果を返してもらう感じです。

これもサブプロセスを作ればいいのではと言われそうですが、この場合はプロセス的な部分が薄いタスク管理なのでサブプロセスとは呼ばないようにしています。では、サブプロセスとはどういうものなんのでしょうか。メインプロセスがあってそこから従属的なプロセスへ落とし込むも親子関係になるわけですが、この方法論だとあまりないように思います。むしろ、サービス要求を別のプロセスへ投げることと考えられるので入れ子構造のプロセス間連携というふうに捉えています。

いずれにしろ、きっちりとしたフォームに嵌めこまなくてはいけないということではありません。意思決定の項目と順番を決め、各意思決定を素早く正しく行うために必要な要素を定義し、必要とあらば他プロセスやタスク管理、データベースなどと連携する仕組みと仕掛けができれば、組織目的を達成する業務オペレーションがやりやすくなるのではないでしょうか。(完)
  




オペレーション(2)
前回は、最初のアクティビティの「依頼受付」のオペレーションを行いました。このフィールドグループのデータを登録してステータスを完了にしました。一旦保存しておき、次のアクティビティである「商品選択」に行くわけですが、再びポータルから「標準品見積提示プロセス」を開きます。そうすると一覧表が出てきます。そこで該当する案件の左端をクリックすると案件のデータ登録された画面が出てきます。まだ、受付のところにデータが入っただけのものです。

ここから、追記していくというイメージになります。従って、編集モードに切り替えます。アクティビティは「商品選択」ですから、タイプ、扉グループ、間口から該当するものを選択し、数量を入力します。こうした作業をするときどの商品にするのかをカタログを見て選ぶケースがあるかもしれませんので、そのために商品カタログにリンクを張って参照できるようにしておきますが、開くときは"リンクを新しいウインドウで開く"で見に行った方がよいでしょう。ここでデータが確定するとステータスを確定済みに進めておき保存します。
 
image12.bmp

   
これで、プロセスは受付と商品選択が済んで、次は「納期確定」に行きます。これも同様にポータルからアプリを選んでそこから案件を開き、編集モードにします。納期確定では、納入日、納入場所、納入条件を入れますが、それを確定するには在庫の状況を確認して、例えば工場とか倉庫とかで納入品を確保しておく必要があるという想定で商品確保というラジオボタンをつけています。そこで確保済みになるとステータスを確定済みに進めます。
  
image13.bmp

   
次が価格決定で、価格は担当営業が勝手に決めるわけにはいかないのでルールに従って決めます。ルールは簡単で大事なものであると別のDBから参照するより直接書き込んでおくということも有効ですのでそうしてあります。そのルールで、見積金額は仕切り価格+営業経費+利益というふうにして、仕切り価格が決まると自動的に見積もり金額がきまるというシンプルな例でテーブル化しています。簡単な計算はkintoneでできます。ステータスは、価格決定にします。
   
image14.bmp


  
5番目は作業アクティビティです。「見積書作成」になります。ここでは、それまでに確定したデータを集約して見積書に記載することを行います。Kintoneは帳票作成は苦手ですから実際にはオフラインで行います。ただCSVで吐き出せますのでそこからExcelで見積書作成も可能です。作成された書類は、添付資料という形で収めておくと参照することができます。ステータスは作成済とします。

最後の報告・登録アクティビティは、「見積書送付」になります。ここでの入力は送付日と送付先にしてあります。そして、相手方が受領を確認したらステータスを受領確認にしてこの案件は完了します。あくまで簡単なモデルですので実際にはまだ多くの登録データや他システムとの連動などがあり、またグラフの設定をしていませんが、担当者別案件数だとか、月別の見積件数だとか見積金額総計だとか見たければそうした設定を行います。
 
image15.bmp


  
以上で業務適用を終わりますが、感じられたと思いますが、多少ぎごちないところがあるのは否めません。というのも残念ながら業務プロセスをオペレーションするのに適したソフトウエアは少なく高価です。その中にあってkintoneは比較的シンプルでかつ機能的にも優れているので何とか使えると思っています。何よりも協働的な業務オペレーションに向いているからです。
   
オペレーション(1)
前章で作成されたアプリは「標準品見積プロセス」という名前が付けられて「kintone」のポータルのアプリリストに入っています。まずは、なんらかの手段で営業の窓口のところに見積の依頼がきます。電話、FAX、メール、訪問といった手段で来ることが多いと思いますが、これからはWebサイトからとか、会員制みたいにして「kintone」のアプリに直接入って来れるようにすることも可能になるでしょう。

さて、依頼を受け付けた営業担当者は、ポータルのアプリをクリックします。そうすると「進捗表」の画面が出てきます。全く最初からだと"データがありません"と表示されるので新たにデータの登録をします。それ以後は、案件ごとの進捗が表示されることになります。ここでは、すでに2件が進行中であるとします。その画面は下のようになっています。
   

image01.bmp

  
進捗表は、アプリ作成で説明したように、各アクティビティのステータスを表示していますが、ここでJavaScriptAPIを使って色替えするようにしましたので、アクティビティが完了していると緑色に変わっています。色は好きなものでかまいませんが、こうして見やすい工夫は必要になっていきます。

新規のデータ登録画面に行くには、左上にある「+」ボタンをクリックします。そうすると、次のような画面が出てきます。
   
image02.bmp
  
    

最初のアクティビティである「見積依頼受付」のステータスが「受付中」(デフォルトでそうしている)になっている以外はまだデータは入っていません。また、グループフィールドに設定したところは、畳まれていて名称だけが表示されています。ここから順番にデータを入力していきます。カテゴリーは提供商品によって選択しますが、商品選択したあとで設定してもかまいません。とりあえず「キッチン>標準」を選択しておきます。

次に、ステータスはさておき、最初のアクティビティである「見積依頼受付」を拡げます。そうすると、下記画面が現れます。
  
image04.bmp

   
依頼日は、初期値を登録時の日付にしているためにその日付が表示されています。空欄にしたかったら、設定でチェックを外しておきます。案件Noは自動付番されるようにしていますのでそのままにします。次が依頼会社名の入力です。ここでも工夫は、ルックアップというパーツを使っていることで、会社名をいれて"取得"というボタンを押すと付属情報である、郵便番号、住所、電話番号が自動的に表示されます。これは、別の「顧客リスト」というアプリで登録されているデータを引っ張ってきています。

さらにここでもJavaScriptAPIで住所からGoogleの地図を表示させるようにしています。その他のデータも入力すると、最初のアクティビティが完了します。次のような画面になります。
   
image05.bmp
   
  
ここで一旦保存しておきます。また、ステータスのところを「受付完了」に進めておきます。そして、次の商品選択のアクティビティが開始されたら、2番めのアクティビティである「商品選択」のステータスを「選択中」にしておきます。このあたりは、自動ではなく人間が手で進めていくので面倒かもしれませんが、みんなで確認しながら進める意味もあるので手間を惜しまずやっていきましょう。
    

はじめに

さて、今回からは新しい章が始まります。題して「業務適用」ということで、前章で作っったアプリを使って業務を行っててみようという試みです。これも実際に動くものを見るのがいいのですが、紙の上での説明となります。従来のシステム開発では、業務アプリを作って終わりというケースが多いように思います。理由は作り手側と使い手側の乖離です。

使い手側いわゆるユーザーが、SIerとかの開発会社に頼んで業務システムを作ってもらうという図式で、作り手側はできたものを納品して終わりという関係である。従って、いざ使おうとするとうまく動かないという事態が発生する。システム的にバグだとか行ったものは改修してくれるのですが、業務オペレーション上で問題が生じるとそこは直してくれない。

というのも、仕様は最初の方に決められていて、その時って業務オペレーションがどうなるかのイメージが乏しいわけで、できて動かしてみて初めてこんなはずではなかったとなる。また、これもよくあるのだが、システム開発のプロジェクトにアサインされる担当ってキーパーソンでない場合が多い。仕様決めは彼らがやるわけだから、インフォーマルにやられているような部分は仕様から外れてしまうので、表層的な機能しか実装できないことになって使えないとなる。

だから、そうならないためにはシステム開発のプロジェクトでは、作り手と使い手の共同作業にしなくてはいけません。前章では実装編ということでインプリメンテーションをとりあえずやったという段階です。その段階でもユーザだけでやる場合は問題ないのですが、開発ベンダーが入っている場合でもユーザは必ず入ってむしろ主導権をとるようにして行います。

そして、業務適用という段階に入っていくわけですが、ちゃんと使えるように実装されたかというと難しいものがあります。動かさないと分からない、あるいは動かしてみてこんなはずではなかったと気がつくこともあります。ですから、まだプロトタイプと言ってもよいでしょう。ここから、プロトタイプを動かしながら実装に戻ることもしながらブラッシュアップしていきます。

このようなプロトタイピング手法が重要なメソッドになります。動かしてみて追加修正が出てきたらまた設計しなおして実装してという繰り返しを行います。ですから、そういったことができるプラットフォーム、ツールでなくてはいけません。いちいちコードを書きなおしたり、高いスキルでないとできないというのは不適です。Kintoneを採用しているのはIT専門家でないユーザ部門のひとでもできるからです。次回から、実際にオペレーションをしながら検証していきます。
  
標準品見積提示プロセス(実装その5)

前回は、その他の設定でカテゴリーを取り上げました。つぎに通知の設定とアクセス権の設定を行っていきます。前提として、ここでは説明しませんが、cybozu.comで組織/ユーザーの設定が終わっているものとします。すなわち、kintoneの対象となっているアプリに参加する組織と人が登録されているという前提になります。

通知というのは、何かのアクションをきっかけに通知をするというもので、その条件としては、レコード追加、レコード編集、コメント書き込み、ステータスの更新、ファイル読み込みがあります。誰が何をした時誰に通知するかを設定することになります。通知はメールが飛んで行きますし、アプリのポータルでもわかります。下記のような設定になります。

通知.bmp

また、リマインダーという設定があります。これは、ある条件(通知のタイミング)になったらお知らせというかアラートを発するのですが、これが、実はパフォーマンス管理に使うことができます。つまりあるフィールド項目に条件を与えて、通知内容を設定するとそれを通知してくれます。ここでの例でいうと、見積提出期限の5日前になったら"見積作成急いでください!"という通知を担当者に送るわけです。

使い方としては期日管理が多いかもしれませんが、例えば、金額とか数量がある限度を超えたら注意をうながすということもできます。この機能を使ってパフォーマンス管理を行うようにします。リマンダーの設定は下記のようになります。
   
リマインダー.bmp

つぎは、アクセス権の設定になります。アクセス権がかけられるのは、「アプリ」「レコード」「フィールド」ごとにできます。それぞれの許可されるものが違っていて、アプリでは、レコード閲覧、レコード追加、レコード編集、レコード削除、アプリ管理、ファイル読み込み、ファイル書き出しで、レコードでは閲覧、編集、削除で、フィールドになると閲覧、編集となっています。このアクセス権によって担当者はだれなのか、責任者はだれなのかがわかるようになりますし、承認などのボタン(フィールド)は権限を持った役職者しか編集できないようにします。

さらに最近各種APIが提供されるようになってきました。その中で、「アプリのJavaScriptカスタマイズ」を行ってみましょう。その設定は、アプリの管理画面にある詳細設定を開きます。そこに「JavaScriptによるカスタマイズ」という項目がありますので、そこをクリックするとJavaScriptファイルをアップロードする画面になりますので、適用するファイルを参照ボタンから選択します。

JavaScriptファイルはもちろん自分で書くことができますが、下記のようなサンプルが用意されています。
レコード一覧でステータスに応じて書式を設定する
住所から地図を表示する
To Do をガントチャートで表示する
自動採番して、レコード登録する
経過年数を表示する
ここでは、最初の2つを実装してみます。サンプルコードの項目名を変更して適当な名前を付けておきます。「進捗一覧表」のアクティビティのステータスに応じて色が変わるようにします。そのアクティビティが完了すると文字が緑色になるように設定しました。また、住所からGoogleMapが表示できますので、例えば、依頼会社の住所とか納入先住所などを入力すると自動的にその地図が表示されるようにしました。

以上で、「標準品見積提示プロセス」の実装フェーズの説明は終わります。普通はこれで終わってしまうのですが、次回からはオペレーションについてエントリーしていきます。作っておわりではなく、使ってみてまた改善してというサイクルを回すのがゴールですので大事なところになります。
  
標準品見積提示プロセス(実装その4)

さて、一般設定、フォームの設定ときたので次は一覧の追加になります。アプリを見るときに最初に出てくるのが一覧表ですので、玄関のところをどういうものにするかを考えます。やはり最初のところですから全体を見通せるものがよいと思います。つまり案件ごとの進捗がわかるものが必要です。また、プロセスというのは案件の処理だとも言えますから、その案件がどんな内容なのかも知りたいところです。

従って、基本的な一覧表としては、プロセス進捗と案件一覧を作ります。その他にも好きなように作れますが、条件ごとでソートできる絞り込みの機能がありますのでそれを使えば、切り口を変えて一覧表をみることができます。ですから、ここでは「進捗表」と「見積案件一覧」の2つを作成します。

一覧表は、フォームの設定で配置した各フィールドとその並び順を指定することを行います。一覧の追加をクリックすると、設定したフィールドが左側に自動的に置かれていますので、それをドラッグ&ドロップで配置します。順番としては案件Noと案件名をキーにして、各アクティビティのステータスを持ってきます。登録画面(閲覧画面)でも上段にステータスを表示させましたが同じことをここでもします。登録画面では案件ごとの進捗しか見れませんが、一覧表では複数の案件を同時にみることができます。進捗表は次のように設定されます。
  
進捗表.bmp


  
次は、見積案件一覧表になります。これも同じように左側に配置されたフィールドパーツをドラッグ&ドロップで置いていきます。ここでは、案件NO 、依頼日、案件名、納入日、担当営業名、見積金額としておきます。もちろん項目は自由に追加してかまいません。見積案件一覧表は次のようになります。
  
案件一覧.bmp

  

さて、基本的な設定が終わったので、その他の設定について見ていきましょう。まずはカテゴリーです。単純なプロセスだとカテゴリーに分けなくてもいいのですが、例えば、見積プロセスでも商品が単一ではなく種類が多くなったりすると商品カテゴリーで分けたくなりますよね。そのために、カテゴリーを設定することができます。

ここでは、住宅設備を対象にしていますので、キッチン、バスルーム、洗面所、トイレというふうにカテゴライスしました。また、キッチンにも標準のものと特注のものがあるとして、階層的に分けるようにします。下記のように設定しておきます。
  
カテゴリー.bmp

  

   
標準品見積提示プロセス(実装その3)

前回までは、「見積依頼受付」「商品選択」「納期確定」というアクティビティについてプロセス要素表か該当するパーツを選んで設定を行いました。次に残りのアクティビティの設定を行います。「価格設定」です。見積書に記載する売価で非常に重要なところですね。この決め方は、一義的に決まらないし、各社各様の決め方があると思います。

ひどい場合は、営業の胸三寸で決めるなんてこともあるかもしれませんが普通はルールというものがあるはずです。それは別に明文化されいなくても何らかの形で共有化されていればよいと思います。このケースでは、外部を参照するのではなくアプリのフィールドグループの中に直接記述してしまおうというものです。こんなルールにしておきました。

見積価格の決定は次のルールに従って決定してください。
1)価格構成は、仕切り価格+営業経費+利益とする。
2)営業経費は仕切価格の20%とする。最終的には営業部長判断とする。
3)利益は、仕切価格+営業経費の30%とする。

ですから見積金額は、仕切り価格を入力すると自動的に計算するというフォーマットにしています。では仕切り価格はどう決まるのかはここでは言及していませんが、製造原価から出すかもしれませんし、仕入れ価格かもしれませんが、外部アプリからの情報に依ります。データ連携で自動的に持ってきてもかまいません。

まず、ここで入力する仕切り価格は、数値というパーツを持ってきます。そして、このああと計算に使いますので、フィールドコードをわかりやすいように「仕切り価格」としておきます。(何もしないと数値_1といったように自動的にふられています)営業経費、利益、見積価格はそれぞれが計算されるものなので、計算というパーツを選択します。この場合の設定は、例えば営業経費であれば、フィールド名は「営業経費」となり、計算式のフィードには「仕切り価格*0.2」というふうに登録します。表示形式を選んでここでもフィールドコードを「営業経費」としておきます。価格決定のアクティビティは次のようになります。

価格決定.bmp


次は見積書作成アクティビティです。いわゆる作業のアクティビティで、前段の意思決定にに従って要求に対する報告を作成する作業になります。ここでは、見積書を作成するのに必要なデータが決定されたかどうかのチェックをするようにします。複数のチェックになりますのでチェックボタンのパーツを使います。また、作成された見積書がどんなものであるかがわかるように添付ボタンを付けて参照できるようにしておきます。見積書のような帳票はkintonで作るは無理なので、Excelや帳票ツールで作成したものを添付します。

最後は、見積書送付です。ここの確定データは送付日にしてあります。ステータスだけでもいいのですが、日付と送付先のほうが確実なのでそうしてあります。見積書作成と見積書送付のアクティビティは下記のようになります。

見積書作成.bmp

次に、各アクティビティのステータス表示をどうするかという問題があります。それぞれのフィールドグループの最後に置いても構わないのですが、折りたたんでしまうと見えなくなってしまうので、プロセスの進捗がわかるように全体の頭のところに横に並べることにしました。それぞれステータス表示で設定した名称を入れたドロップダウンパーツを並べておきます。以上で基本的なフォーム設定は終わります。
  
ステータス.bmp
  

標準品見積提示プロセス(実装その2)

前回は「見積依頼受付」というアクティビティのフォーム設定を行いました。次は「プロセス要素表」の2番めにある「商品選択」というアクティビティになります。前と同じようにグループというパーツをドラッグアンドドロップして名前を「商品選択」と入力します。次にプロセス要素の中の確定データをみると、タイプ、扉グループ、間口、数量となっています。

タイプは、それほど数があるわけではなく決まったものが数種類なのでラジオボタンを選択します。フィールド名をタイプとし、項目と順番にAAとASという名前を登録します。扉グループは、比較的数が多いので、ラジオボタンだとずらっと並んで表示されるので、ドロップダウンを使うことにします。1Aだとか2Bだとかといった設定を行います。間口も同様な設定となります。数量は数値データですので数値というパーツにします。

次に、参照情報が商品カタログとなっています。商品カタログがどこにあるのかで設定も変わってくるのですが、ここではHP上にアップしてある商品カタログを参照して、お客さんの要求にあったタイプ、扉グループ、間口を選定するということにします。この場合、ラベルというパーツを使います。ラベルに書いた文章の言葉にリンクを貼ることにします。"商品カタログ参照"という中の商品カタログにリンクを設定し、参照先のURLを入力します。「商品選択」は次のようなフォームとなります。

商品選択.bmp

「商品選択」の次は「納期確定」になります。確定データは納入日ですから、日付というパーツを選択し、名前を納入日とします。付帯登録情報として、納入場所、納入条件、商品確保があります。納入場所と納入条件は文字列パーツを使い、商品確保は、依頼中なのか確保済みなのかの2通りなのでラジオボタンにします。納入場所も住所を入れると地図が表示されるようにしたかったら、依頼受付アクティビティと同様にGoogleマップと連動させることもできます。

参照情報の在庫状況は前の商品カタログと同様にラベルでリンクを貼っていますが、同じkintoneに用意してある在庫管理アプリをリンク先にしてあります。ですから、もしリンクではなく、「見積依頼受付」でやったようにルックアップを使って、商品が入力されたら、自動的に在庫数を表示させることもできます。結局、「納期確定」というアクティビティは次のようになります。
  
納期確定.bmp
  

■    標準品見積提示プロセス(実装その1)

前回「プロセス要素表」を書きましたが、それをそのまま実装していきます。実装はサイボウズ社の「kintone」を使います。最初に基本的な約束ごとと前提条件を言っておきます。「プロセス管理表」に記述した「標準品見積提示プロセス」を全部同じアプリに実装していきます。ただし、参照情報や業務ルールで使うデータベースなど別アプリにしておきます。例えば、顧客台帳だとか業務ルール集といったものは他のデータベースに持ちます。

こうしたデータベースは、連携のしやすさから「kintone」上にもつことをおすすめします。Excelだとか他のDBソフトなどで持っている場合ありますが、移行したほうが便利です。「プロセス要素表」の左端にあるアクテイビティはその単位でフィールドグループとしてまとめておきます。そのフィールドグループの中に、確定データや付帯情報、参照情報、業務ルールなどを設定していくことになります。

一覧表は、基本的にはプロセス全体の進捗がわかるものと案件ごとの内容がわかるものと2種類を用意するのがよいと思います。その結果をグラフ化してどう見るかといったところまでは含めません。また、組織/ユーザ登録やセキュリティの設定などは、cybozu.comの共通管理であらかじめ行ってあるという前提にしておきます。

それでは、「プロセス要素表」を横において、「kintone」ログイン画面からID、PWを入力して入ります。そしてポータル画面を開きます。アプリを作成するから"はじめから作成" というボタンを押します。アプリ名を「標準品見積提示プロセス」とします。一般設定は、アイコン、デザインテーマ、アプリグループ、アプリの説明がありますが、適当に選択し、記述します。

続いて、フォームの設定になります。左側にパーツが配置され、右側は白紙のキャンバスが現れます。最初のアクティビティは「見積依頼受付」です。従って、"グループ"というパーツをドラッグアンドドロップして先頭に置きます。歯車印をクリックして設定画面を開き、フィール名を「見積依頼受付」と入力して保存します。

このグループの中にプロセス要素表に書いた各要素を入れていきます。まずは確定データである依頼日、案件No、依頼会社名、案件名、依頼内容、担当営業名を当てはめます。依頼日は、"日付"、依頼会社名、案件名、担当営業名は"文字列"(1行)、依頼内容は長くなりますので"文字列(複数行)というパーツを選択します。案件Noについては、自動付番で構わなければ"レコード番号"というパーツにすると自動的に番号をふってくれます。

次いで付帯登録情報である依頼会社住所、提出期限についても同様に、"文字列"(1行)と"日付"パーツを使います。ただ、依頼会社住所については、既存顧客のような場合都度入力するのではなく、顧客リストとか顧客台帳といったところ(同じkintoenのアプリとして作成しておく)に情報を持っておけば、そこから取得できいちいち入力することがなくなります。それには、"ルックアップ"というパーツを使います。その設定画面で関連付けるアプリを顧客リストとして、コピー元のフィールドを会社名とします。次に顧客リストのフィールドと作成するフィールドの対応付けを行います。こうしておくと、案件登録時に会社名を入力して取得というボタンを押すと、郵便番号、住所、電話番号が自動的に入力されます。

そして、参照情報にある地図については、JavaScriptAPIを使って、Googleマップと連動させます。これはまた後で説明します。最後にこのアクティビティ(フィールドグループ)の登録のステータスを表示するフィールドを置きます。"ドロップダウン"パーツで、プロセス要素表で定義したステータス表示の受付中と受付完了を設定しておきます。なお、ステータス表示は各フィールドグループごとに配置してもよいのですが、折りたたんだ時に見えなくなるため一覧性が損なわれるので外出しすることにします。これもまた後で説明します。結局、「見積依頼受付」は次のようなフォームとなります。

依頼受付.JPG

■    標準品見積提示プロセス(設計続き)

次に納期の確定を行っていきます。確定すべきデータは納入日となります。その他付帯情報として、納入場所や納入条件、また提供商品を確保できているかどうかを設定します。ここでは、営業だけでは納入日を決めることはできませんから、工場だったり、出荷倉庫だったりから在庫情報ばどを入手して決めるか、決定する部門があったらそこから直接納期情報を取得します。関係部署とコミュニケーションをとることが重要となります。

商品選択と納期確定が終わると最も重要な見積価格の決定に入ります。この価格決定は各社あるいは各部門でやり方が異なるケースが多く見られます。極端な話、その場その場の営業の個人判断で決めているなんてこともあるかもしれません。ただし、こうしなくてはいけないということはありませんが、準拠するルールは何か、それが共有化されているのかどうかが大事なポイントです。

プロセスを先行させ、プロセスを中心にして設計するという利点というか意義はここのところで、つまりその意思決定はどんな業務ルールにのっとって誰が責任をもって決定しているのかということを書き出すことで明らかにするからです。いやー、うちにはルールはありませんというところがあるかもしれませんが、明文化されていなくて、誰かの頭のなかにあるかもしれませんが、大切なことはそれを表に出すことです。暗黙知から形式知にすることです。

最初はそんな立派なルールでなくてもかまいません。いくつもの案件をこなしていくうちに、こんな場合にどうしたらいいのかが書いてないので足しておきましょうとか、事業方針が変わったのでルールも改変しましょうとかすればいいのです。また、ガチガチのルールをむりやり作る必要はありません。プロセスオペレーションでは必ずといっていいほど裁量の余地が生じてきます。一部は人間の判断に任すようなものでもかまいません。

ここでも、納期確定と同様に原価だとか、仕切価格などの情報をもらってそこに営業経費や利益を載せて売価を決定していきます。さらに、値引きなどの扱いも入ってくるでしょう。そこの決定手順が残っていることも重要で、そうすることで後々のなぜ受注できたのかあるいは逆に成約にいたらなかったのといった解析ができるのです。

さて、見積書に記載する基本情報を決定すると見積書の作成を行います。作業のアクティビティです。ここでは、確定データは作成済というものでもいいですし、作成日という日付でもかまいません。見積書は通常は帳票として作成されますが、kintoneで直接見積書を作成するのは難しいのでデータを伝送してExcelなどの外部ツールで作成します。作成された帳票は参照できるように設定しておきます。最後のアクティビティは見積書の送付です。この場合の確定データは送付日と送付先になります。

以上、基本的なプロセス設計が終わると、「プロセス要素表」を埋めることで実装に向かっていきます。「標準品見積提示プロセス」のプロセス要素表は次のようになります。

見積プロセス要素表.png