見積取得プロセス/２社以上取得・KPI・KGI

社員(担当者)は妥当性のある見積を見積依頼先から取得し、妥当性を含めて見積内容を上司(管理者)や経理部門に示し、見積の決裁を取る.

概要

 * 1) 管理者は担当者へ見積取得の指示を行う.
 * 2) 担当者は見積依頼書の作成及び見積先(複数)を選定する.
 * 3) 見積依頼に関する承認を管理者より得る.
 * 4) 見積先に対して見積を依頼する.
 * 5) 見積結果を管理者へ報告し管理者の承認を得る.
 * 6) 管理者は承認した見積結果を経理部門へ提出し決裁を得る.
 * 7) 経理部門は見積先及び過去見積を参照しチェックを行う.
 * 8) 経理部門は見積情報をシステムへ登録する.
 * 9) 経理部門は見積情報のシステムへの登録結果を管理者と担当者に通知する.

プロセス担当者

 * 管理者(leader-section@company.com)
 * 担当者(person@company.com)
 * 経理部門(generalAccounting@company.com)

プロセスオーナー
経理部門(generalAccounting@company.com)

見積の精度や見積結果の記録／利用について徹底を図りコストダウンを目指すことから経理部門が多くの場合、 プロセスオーナーとなるだろう.

リスク

 * 見積取得の遅延
 * 複数社から見積を取得しての管理者の承認チェックとなる為、予定見積先のいずれかが見積を提出してこない場合、見積取得の全体作業が遅延する.

プロセスダイアグラム例
digraph obtain_estimate { compound=true; graph [size="13,5",rankdir=LR]; // graph [rankdir=LR]; node [shape=box, style=rounded]; edge [color="#444444", labelfloat=true]; //label text float OFF(=true)

subgraph clusterStaff{ labeljust=l; label="generalAccounting@company.com(経理部門)"; G1 [label="G1:Confirm of \n report of estimate \n (見積結果書の承認)"]; G2 [label="G2:Regist \n report of estimate \n (見積結果書の登録)"]; GY [label="",shape=circle, width="0.2", style=bold]; G1->G2 [weight=10,arrowtail=rcrowlvee]; }

subgraph clusterManager { labeljust=l; label="leader-section@company.com(管理者)"; LX [label="",shape=circle, width="0.2", style=bold]; LY [label="",shape=circle, width="0.2", style=bold]; L1 [label="L1:Request \n of obtainning estimates \n (見積取得依頼)"]; L2 [label="L2:Confirm \n of a letter of request \n (見積依頼書の承認)"]; L3 [label="L3:Confirm \n of report of estimate \n (見積結果書の承認)"]; L4 [label="L4:Confirm \n of registration \n report of estimate \n (見積結果書 \n 登録の確認)"]; LX->L1 [weight=10]; L1->L2->L3->L4 [style=invis, weight=10]; L4->LY [weight=10]; } subgraph clusterMember{ labeljust=l; label="person@company.com(担当者)"; PY [label="",shape=circle, width="0.2", style=bold]; P1 [label="P1:Write \n a letter of request \n (見積依頼書の作成)"]; P2 [label="P2:Request estimate \n (見積依頼／取得)\n [+] ",style=dotted]; P3 [label="P3:Write \n report of estimate \n (見積結果書の作成)"]; P4 [label="P4:Confirm of \n registration \n report of estimate \n (見積結果書 \n 登録の確認)"];

P1->P2 [style=invis,weight=10]; P2->P3 [weight=10,style=dotted]; P3->P4 [style=invis,weight=10]; P4->PY [weight=10]; }

L1->P1 [headport=w]; P1->L2; L2->P2 [arrowtail=rcrowlvee]; L2->P1 [arrowtail=odiamond, taillabel="NG",tailport=sw]; P3->L3; L3->G1 [arrowtail=rcrowlvee,tailport=w,headport=s]; L3->P2 [arrowtail=odiamond, taillabel="NG"]; G2->L4; G2->P4; G1->L3 [arrowtail=odiamond, taillabel="NG"]; }

(*)「見積依頼／取得」のアクティビティにおいては担当者が見積依頼書において表明している見積先に「見積の依頼及び見積書の取得」を行う作業を示している.

プロセスデータ例
※見積結果書については見積依頼書、複数見積先からの見積書、見積結果のまとめのファイル群が圧縮されたファイルを想定している.

KGI例

 * 見積妥当性確認によるコストダウン
 * 見積結果書内の最高／最低見積額の差異が発注額の10%.
 * 見積妥当性確認の徹底
 * 見積案件の全ての見積結果書が登録されている.

KPI例

 * 計測対象内の発注案件の見積が100%見積結果書としてシステムに登録されている.
 * 経理部門での見積チェックにおいて過去の見積書との比較が50%の案件で行われている.
 * 見積結果書内の最高／最低見積額の差異が最低見積額の10%未満である場合、管理者の承認コメントが100%記入されている.