August 2013 Archives

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

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

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

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

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

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

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

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

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

依頼受付.JPG

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

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

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

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

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

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

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

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

見積プロセス要素表.png
  

■    標準品見積提示プロセス(設計)
最初に毎度おなじみの見積のプロセスを取り上げます。世の中には見積に関する業務アプリがたくさんあります。しかし、名前からどんな内容なのかわからないことが多いと思いませんか。単に見積書を作るアプリだったり、見積書の格納・検索アプリだったり、対象商品が標準品、在庫品、特注品、仕入販売品、はたまたサービスだったり様々です。

ですから、アプリ名は、そのあたりがわかるようなネーミングにします。今回は、システムキッチンを例にそのなかの標準品の見積依頼を受けて見積書を提示するまでのプロセスを対象としたアプリとします。ですから、お客さんから、ある商品の見積を依頼されるのが始点になります。そして、終点は見積書送付になります。「標準品見積提示プロセス」という名前になります。

つぎにこの始点と終点との間にどんなアクティビティがあるのかを見ていきます。書類を作って送るような例では、書類に書き込む必須データを確定するのがそれに当たります。ですから、言い方を変えると、まっさらの見積書からデータを転記していくのがプロセスとも言えるのです。見積書の記載事項は浮かびますよね。品名、型式、型番、サイズ、数量、単価、合計額、納期、納入条件といったものになります。品名や数量、納入条件などは見積依頼の時に指定されますから、結局、型式や型番などが特定された品名、数量×単価である売価、それと納期が中間のアクティビティとなります。そして作業としては見積書作成があります。

つまり、「見積依頼を受付ける→提供商品を選定する→納期を確定する→売価を決定する→見積書を作成する→見積書を送付する」というプロセスになります。さて、次にこれをベースに「プロセス要素表」を書いていくことになります。下記の空欄を埋める作業です。

プロセス要素表.pngのサムネール画像

始点の「見積依頼受付」アクティビティでは、お客さんからの依頼内容を確定します。ですから、確定データは依頼内容ということですが基本的には5Wが確定データになります。いつどこの誰から、どういう目的でどんな案件の依頼があっていつまでに答えるのかを記します。具体的には、依頼日、依頼会社、担当者名、案件名、依頼内容、提出期限となります。それにIDをふって置きますが、自動付番もできるのでまかせてもまかいません。
 
最低限このくらいのデータを配置しますが、このアクティビティはあくまでどんな依頼なのかをわかることが目的で、受付けるということが意思決定となります。従って、受付を承認するには、この会社との取引履歴を見たいとか、財務状況を知りたいといったことがあれば参照情報として登録してきます。また、受付承認の責任者は誰なのか、部長なのか課長なのか、担当者なのかを決めアクセス権を設定します。ここでは担当者の鈴木さんにしておきます。

次が商品選択になります。見積依頼は、商品名から型式やサイズなどを細かく指定してくる場合もありますが、要望に従ってこちらから選んであげるということもあると思います。そんなケースだと、タイプ、扉グループ、間口、数量といったものが確定データとなります。この決定にはカタログをみて決めるようなことがるかと思いますので、参照情報として商品カタログを設定します。(続きは次回)
 


■    はじめに

さて、今回からは新しい章が始まります。題して「業務アプリ作成」ということで、これまで、心構えと下準備・企画・設計・開発ときたので、実際のアプリを作ってみようという試みです。ライブコーディングというのがありますが、いわば誌上ライブインプリメンテーションといった趣でしょうか、紙の上で表現するのは難しいのですがやってみたいと思います。

まず始める前に前提条件や前置きを確認しておきます。
・    プロセス設計から入ります。
・    対象プロセスは、筆者が経験したものや見聞きしたものが中心となります。
・    詳細でスペシフィックな設計ではなく、基本的な部分についてになります。
・    インプリするプラットフォームはサイボウズ社の「kintone」になります。
・    実際に動くものをつくって、その画面をキャプチャしたものをお見せします。

それと、少しおさらいをしながらどういう進め方になるかをお話しておきます。プロセス志向アプローチ(プロセスを中心に据え、アクティビティとそのフローを先行させて記述するアプローチ)であることは何度も申し上げています。プロセスというのは「ユーザからのサービス要求に対して、いくつかの意思決定を連鎖させて、満足のいくサービスを提供する過程」のことですから、どんな要求があって、それに対する答えをどう決めて、そろったところで何を報告するというのを決めることが先決になってきます。

そのあとに、要求に対する答えを用意する、すなわ単位意思決定を行うために必要な判断は誰がどんな情報にもとづいて行い、コントロールし管理しているのかなどを記述することになります。これを、「プロセス要素表」というワークシートに記入して、それをそのままに近い形で実装していきます。できるだけ早く動くものにしていくことが大事です。

こうしたプロトタイピング手法では、生煮えでもいいからまず作って見せることで改良点や新たな発見があるものです。これを反復することでよりいいものに仕上げていく(イテレーション)というやり方になります。そして、プロセス要素が全部完璧に揃うなんてことはあり得ないのだから、そこもあるものだけで使いだし、不足は人間が手作業で補うことで始めたらいいと思います。

「適用領域の適正化がものすごく大事なこと」という別のエントリーで書いていることなのですが、こうしたやり方が通用するプロセスが主体となった領域が対象となっています。というかプロセス志向アプローチはプロセスが重要であるからプロセス志向なのです。つまり、データを集約してそれを計算してレポートを作成するといった領域では、プロセスはあまり意味を持たない、あるいは機械的に手順化できるので対象にしていません。ここは、よく理解しておいてください。