goo blog サービス終了のお知らせ 

電気設備等の受注Know-how

長年、通信設備などのシステム受注の仕事で得たKnow-howをまとめたブログです。
何かの参考になれば幸いです。

04.納入システムの構成変更時の対応

2019-04-23 17:51:58 | 09.リスク回避

システム納入の検収後、システム構成要素の変更が発生した場合、下記の対処が必要になる。

1)システム構成要素の変更(機材の変更)
   例:機材の変更、型番の変更など、
   同一型番であっても、バージョンによる再がある場合、異なる機材の認識絵行う
2)自社製品のファームバージョンの変更(バージョンの違い、バージョン変更)
   自社標準製品のファームバージョンが、混在して最小した場合、そのバージョンに対してシステム
   の接続性試験以外に、混在時の接続性試験、及びシステム動作動作の動作振る舞い(顧客運用でも
   実試験です)を経て、システム保証とすること。
3)伝送路の変更
   システムを構成する機材間の接続ケーブルの変更においても、変更するケーブルのインピーダンス、
   容量特性、減衰特性から、互換仕様として採用出来ることをシステム設計者が判断し、承認を出し
   採用すること。
   また、伝送路の混在は、系統図もしくは布線図に線種を明記し、特記記事として、混在利用できる
   型番を明記する。
   工事調達品の場合、システム設計品詞を維持するために、工事要領書(用紙1枚の要領書でも)
   必ず発行し、指定線材の注意点を明記する。
     特に2W系の伝送路(ツイストペアーケーブルの工事の注意は、システム品質多きkな影響を与え
     る)
4)機材等の設置変更
   単純な置き場所の変更であっても、機器と機器の接続方式によりターミネート(終端)位置が異な
   る場合があります。従って、機材の変更時、固定ターミネート(機材による終端)の場合、ターミ
   ネート位置が異なり誤動作に繋がる場こともある。
   システム納入品の機能を維持するためにもシステム設計者に変更を連絡する。
   また、連絡を受けたシステム設計者は、布線図や系統図、建屋設置図などの図面修正を行い、
   同時に完成図書の差し替えを行う。(このようにすることで、変更後の履歴が残る仕組みできる。)
5)他社がシステム設計した納入物に弊社標準品が使われている場合
   自社以外の製品変更時、設計した会社の責任として、弊社に連絡するか、システム設計会社の
   責任の中で品質を保証することになる。
   よって弊社は物納に係る品質を担保するしか出来ない。
   しかし、システムとして用いる機材の場合、適合相手(対向する機器)などの関わりがあるため、
   物納契約であっても、保証を担保するための範囲を納品書(納品伝票など)に明記するとリスクが
   さらに最小になる。
6)客先承認後や、検収後の変更
   客先の承認後の機材の変更や、検収済みのシステムに対して、機材の変更が発生した場合、
   客先承認を再度取り直すこと。また検収後の場合は、客先に相談し、部分検収を行うなど、
   客先が任四区出来るような仕事のやり方でシステム構成要素(機材など)の変更を実施すること。
   また、変更は、客先承認を得て変更が出来る。
   また、上記の前段階では、システム設計等にs妥当性や接続性が係るため、1)項から5)項の対応
   が必要となります。


03.課題解決方法

2019-04-23 17:48:33 | 09.リスク回避

体制の課題 
   
 概要
  各分門の標準的な手順が定まっている事。
     活動で得た情報をどの様に扱っていくのか。
        → 成果物の有り方、伝達方法、依頼方法
     成果物から実施することは、
        → 得られた情報の精査と追加情報の深堀(必要情報の取得)
     早い段階で顧客が望む情報を作成する。(後になればなるほど、他の案件活動が増えて
          何もできなくなる)

 詳細  
  商談から引合や見込案件等の受注活動には欠かせない打合せや問合せが来る。
  この情報の可能性を判断することが第一の業務。

  情報をさらに取得していく事となれば、営業御情報として後工程や、類似案件など、精査してい
  く作業が始まる。

  営業情報  → 商談や問合せで入った、引合や見込案件から、要件を纏めていく。
  同時に
  技術精査として、どの様に使うモノ(システム)を望んでいるのか。
          既設設備の更新であれば、既設設備の完成図書を入手する交渉を営業に依頼する。
                    (もしくは、営業が判断する)
                    新規設備の場合、設備により何を主眼として導入するのか。
          業務の質を高める、業務の効率を高める、運用コストを下げる、など、導入する
          理由が必ずある。そこを得ておくことが、システム設計のスタート地点。
          そして、予算の範囲、委託経路(商流)により、原価構造が変化するので、係わ
          る業者の流れを理解する。
  この段階で、各部門の役割分担は、
      営業:必要な情報を集めて整理する。
      技術:営業から得られた顧客情報から要件定義書(したい事と実現の手段)を纏め、そこ
         から納入物の全体像を書いていく。
      
  規模の判断:要件や定義から案件規模が見えてくる。概ね、要件定義から受注金額の目安や、納入
        時期(分散納入の必要性等)から、詳細なシステム設計が必要となるか判断する。

  判断で詳細システム設計が必要となれば、見積をするためのシステム設計依頼を行う。

  逸早く受注案件の情報を展開し、必要判断を経て、活動出来るか、がスムーズな業務フローをこな
  せる秘訣です(数週間や数日前に依頼が来ても、何一つシステム設計の精査はできない)。
  

 

その他の顧客の課題の解決思考

  顧客ビジネスは、明確に纏められている案件であっても(入札案件)、顧客の意図することは顧客
  が詳細を持っていると考え、仕様を一つ一つ分解していく。そして、その分解した要求事項から、
  真意を聞き出していく(質問していく)。
  また、聞き出した内容は、箇条書きに列挙し、それを実現する考え方を書き出していく。

  これが要件定義書のあるべき姿。

  しかし、ここに到達するまでには、知識や経験も必要になる。
  それがないと顧客の課題の深堀も出来ない。

  それでは、どの様にして、深堀をしていくか。
  これが課題の発掘に繋がる。

課題の発掘は、お客さんの課題を聞いたときに、もしくは、仕様を見たときに、機材の仕様という見方
をするのではなく、どの様に使おうとしているのかという視点で考えていきます。

どの様に使うのか、これが運用(システムとしての運用に作り上げる)です。
運用が見えないまま、この製品を使えば機能があります。では、システムにはならない。
その機能を同のように使うのかまで掘り下げる。

運用が見えてくると、お客さんのメリットに置き換えてみる。

この機能をこの運用により使う。何の目的で使うのか、何のメリットで使うのか。
そのメリットが見出せると、直接顧客の利益に繋がるシステムに近づけることが出来る。

多くの顧客メリットは、
  既設の更新の場合、同等であれば良い。と考えるかもしれないが、
       確実に案件を受注していくために、既設同等では、コスト効果が顧客メリットになりか
       ねない。
       それ以外で顧客メリットを引き出すことが課題の発掘として重要な目利きのシステム営
       業です。

発掘が出来たら解決をする思考が必要。
どの様に実現していくのか。

一番簡単な思考は、
  事実に基づくことや、根拠を明確にして考えることです。
  根拠が無いままに、機材リストが作られても、システム提供したときの顧客の運用として理に適う
  システムになるか、根拠が無ければ納入も出来無いことになる。

  事実や根拠があって始めて原価見積の精度が高まり、そして、受注が出来た段階で事実と根拠を具
  体化すればよいという道筋が容易に出来るようにする。

  従って解決する思考は、
     事実や誰でも知っている事柄、そして、これらの根拠によって裏付けされた筋道が明確に理
     解でき、その目的にあった結論になっていること。
  これがシステム受注時の要件とその要件を解決する回答。すなわち要件定義となる。

  この要件定義が出来上がれば、お客とのコンセンサスを得て、見積設計(見積仕様)に進めること
  が出来る。
  見積書の提出に見積仕様がないという事は、見積する要件が無い、機材としての売買に等しい事と
  言える。
  また、その機材の稼働保証等、現地依存で行うリスクがある事を考えなければならない。

課題の解決は、
  「弊社の目的を達成するための手段(利益を確保した事業を行う」に直結し、顧客に納得の行く高
  付加価値の受注を促せる処方といえます。

  ただし、目先の受注の場合(すでに顧客が前年度に予算取りした金額を得ている場合、上乗せした
  コストを要求することは出来ない。顧客の予算どりの金額を聞き出してその中で納入出来る納入物
  と労務で構築していく。

案件は、早ければ早いほど請負メリットが出しやすくなると言われる事が理解できると思う。


02.リスク管理表

2019-04-23 17:32:01 | 09.リスク回避

実際のリスクは、その場で容易に書き出せない場合が多い。
下記のような分類や要素で洗い出せば、楽に抽出できることが多い。

抽出したリスクを各部門の中で津日仕込を掛けていくと、その業務の改善に繋がって行きます。
どうしても解決できないことも出てきますので、全体で議論する場も適宜設けていきます。

リスク回避の原則は、担当だから担当外だから、という視点を無くすことです。
案件という一つに向かっていくために、フラットなたちが出リスクを出し、回避方法を密稀有ことで
す。

 


01.仕事を受けるときに!!リスクを出し/潰していく

2019-04-22 17:26:05 | 09.リスク回避

多くの受注のスタートは、打合せや書面によってしたいことや実現したいことを纏め
上げて行きます。
この机上での仕様の作りこみや検討では、必ずと言っても過言ではないリスクが潜ん
でいます。

言い換えれば、受注事業はリスクを伴う事業ともいえます。このリスクがあるから受
注しないでおこう、そう判断するのであれば、受注事業は成り立たないと思っている。
少なくとも、危機的なリスクであれば辞退することもあるが、「リスクがある辞退」
では事業が成り立たない。リスクがなければ誰がやってもできる仕事として受注コス
トも低額が当然の結果になる。リスクを見つけ対策し、そこから受注ノウハウを得て
いくことで、事業の成長とエンジニアの成長が益として得られる。

これらを前提として、

条件が揃わなくても、受けなくてはならないことが多々ある。
その場合でも、一緒になって必要な情報を集め、場合によっては作っていくこと。
そして、事前にリスクを洗い出し認識し、そのリスクを回避していく事前活動をして
いくことが広義の意味での仕事になります。

 1.目的(用途やしたいこと/依頼されたこと)は何か
 2.誰が実施するのか
 3.インプットされる情報は何か
 4.その情報はこれから行う仕事で足りる情報なのか
 5.インプットをどのような成果としてアウトプットするのか
 6.いつ開始すべきか、
 7.開始するときの判断基準はなにか
 8.終了はいつになるか、
 9.周流おとする判断基準はなにか
 10.この仕事を遂行するために何を行えば良いか(はっきり判るように洗い出す)
 11.行う内容は、平行作業になるのか、直列作業で大丈夫か
 12.他の成果を出す方法があるのか
 13.実施する。

リスクのない仕事(誰でもできる仕事)は、付加価値が生まれません。
リスクを乗り越えていくことで、スキルも経験もさらに向上していきます。