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

電気設備等の受注Know-how

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

05.システム業務の7つ道具

2019-04-20 23:47:30 | 08.受注後フェーズ

システム業務の7つ道具とは、
  顧客からシステム受注を受けた場合(量産受注ではありません。顧客固有
  受注です)に顧客と弊社でシステム事業を遂行するための7対道具が有り
  ます。



上記以外に、工事を含めた受注時には、「工事完成図書」がある。


04.委託会社等に対する役割分担

2019-04-19 23:34:35 | 08.受注後フェーズ

受注の契約書は注文書だけで処理されるケースも多々あります。

その場合、注文書に記載されている発注内容が不明確の場合、後工程においてトラ
ブルの原因となるために、発注書の備考欄や特記時事項に明記していただくよう依
頼する必要があります。


本来であれば、量産製品の部材発注と異なるシステム発注のため、委託する業務内
容を契約書として発行し両者が持参します。
契約書の型式に捕らわれず、MOU(覚書)で発行するケースも有ります(すでに取引
契約が締結されている相手方の場合ですが)。

どちらにしても、仕事として請け負う内容を明確にすることが、発注する場合は、
発注の仕様を明確にすること。これが第一義で、会社対会社としてのマナーと言え
ます。

弊社からシステムに関する委託物を発注する場合、
   外注仕様書 や、見積仕様書 を依頼会社に発行し、委託内容を明確にした
   うえで、取引を行う。

   発注会社は、少なくとも、システム委託として、NDAや、委託契約書、決裁
   条件等も事前に取り交わしておけばよいが(調達等の支援を受けるなど)

   緊急案件に対しては、そのような悠長な事をしていたら、受注すらできない
   ことになる。

従って、最低限必要な契約NDA、そして、商法に定めた取引契約(伝教等の発行受
領)、発注時の仕様(外注仕様や見積仕様など)をもって経理上の齟齬がない仕事
として委託会社を活用する。


03.量産製品と受注システム品の工程差異

2019-04-18 23:51:13 | 08.受注後フェーズ

要約:
  受注確定前
    案件を管理する番号
      引合い案件や見込み案件、次年度予算度地案件など
  受注確定後
    受注した案件の納入までを管理していく番号
      同一案件で検収や納入先が複数ある場合、
      受注番号に追い番号などを付与し一つの案件ではあるが、
      分割納付(検収)が出来るようにしておくことも考慮。
              
  物品受注時の確定
    量産製品(標準品)の場合のみと標準品に他社製品が含まれる場合、
    機材等を指名されて受注した場合、自社が機材を決めて納品する場合、
    それぞれで大きくは異なるので注意が必要(責任の範囲が異なる)。


02.システム維持/継続のための図書

2019-04-18 23:03:49 | 08.受注後フェーズ

システム事業は、納入後の対応を担保しておかなくてはならない。

納入した後、運用している顧客の問合せなどに対し、納入物の対応が出来ること
が必要条件です。
何もなくても対応が出来る(場合もある)が、現地に出向かなければ、システム
の把握が出来ないという状況になり、初期対応までの時間が掛かってしまう。

また、保守/メンテナンスなども含めた納入後のビジネスチャンスの為にも、納入
物の資産管理は必須です。

何よりも、納入されたシステムの図書があれば、再利用可能な構成要素など参考
にすることも可能となり、システム構築時間の短縮にも繋がる(直課時間の短縮
は、コスト低減として、利益に直結する)。


定義
 顧客要件毎の受注システム時の図書体系として納入設計時の可視化を行うとと
 もに、納入後の問合せや異常時の一時解析資料、保守に活用する。また、類似
 案件等で再利用する資産として位置づける。

解説
 システム事業は、顧客の要求により動作振舞が異なるい。また、納入機材等の
 構成要素も異なる。このシステム機材を案件毎にサンプル保管することはでき
 ない(量産商品であれば、技術検討サンプルや品質保証サンプル等保有する事
 も可能だが)。
 このために、納入したシステムは図書(ドキュメント)として案件毎に管理し
 ていく必要がある。
 また、管理することで、顧客の営みに変更が発生した場合、事前検討等、実機
 を頼らなくとも机上検討が出来る。
 そして、最大の図書のメリットは、再利用にある。再利用として引用できる
 システムの図書があることで、特に類似案件では、過去の品質を基点として
 スタートできるために、システム検討/設計時間の大幅圧縮が可能となり、顧
 客に対してレスポンスのある商談が実現できる。

 別の視点では、営業が納入したシステムは、営業がフォローする思想を変える
 ことにある。納入物のフォローは、システム出荷保証に対して、事業運営組織
 (品質保証やそれをサポートするシステム設計)等で対応する処方にしていく
 ことにある。一依存から、組織依存にしていく解決方法でもある。

指針
 基本図書構成に対し、必要性は顧客以上に弊社にある図書も多い。また、納入
 物には、システムを維持していく為の顧客が手元に保管しておく完成図書もあ
 り、最低限顧客側での始業点検や、異常時の意客先切り分けなども示唆できる
 図書にしていく必要が有る。


顧客の運用
 システムでは、自社標準製品を用いた場合、事標準商品としての機能は、取扱
 説明書や設計資料から読み取る事ができるが、システムとして納入した動作振
 舞は、必ずしも標準しょうy品の機能だけを用いているわけではないため、運
 用としての要件を明記しておく事がシステムでは必要条件になる。
 運用のための動作振舞を定めているからこそ、顧客が納入システムを活用でき
 ることになる。

本題
 顧客の要件を具現化するシステムでは、それぞれのフェーズ(工程)に合った
 図書が要求される。顧客が要求しない場合でも、弊社が必要とする図書もあり
 、客先承認を得ておくことも、両者のネゴシエーション(承認履歴)と言える。
 単に成果物(納品物)の図書と言う位置付けから、納入物の品質を維持する図
 書、保守や修理、更新を速やかに行うための図書、そして、再利用といしての
 図書と多様な目的が付随している。

 ソリューション(受注全般として)で必要な書面の概要(とりあえずリスト化
 したものです。抜けなどもあると思うが、代表的な図書を掲げた)。

 提案書
   弊社の商品、納入事例から提案書等として弊社一存の意思を明示する書面
 要求仕様書
   客先発行が無いものは要件書として代行作成する
 要件定義書
   要件を具現化する思想を記載する
 見積仕様書
   見積仕様(システム設計の前段として原価見積時に必須)
   依託する業務は見積依頼書(外注仕様書)を作成し見積の条件を明示する。
 原価積算書
   費目ごとの原価をリストアップし費目ごとに積算した計算書(一覧表)
 見積書
   営業発行書面
 納入仕様書
   納入するシステムの仕様を明示し、客先承認をいただく(運用が客先とつ
   められている証となる) 見積仕様書からモデファイする。
 システム設計書
   納入仕様書からモデファイして作り上げることで最短時間で作成できる。
 詳細設計書
   ここの機材の設計資料(図面、布線図、動作概要書、画面(UI)仕様書、
   など)
 検査仕様書
   試験仕様書は設計妥当性を加味した一元管理にすることで、自社内(設計
   内)検査、出荷検査、立会検査などの基本検査仕様書として使える。
   立会検査は、伽k酢秋指定もあり、十分な客先との打合せで書面承認まで
   終わらせておく。
 試験成績書
   検査項目のデータ、もしくは、評価書(客差によっては、検査時の写真も
   要求される。)
 工事計画書
   工事見積からモデファイし工事計画書を作成する。
   工事計画書には、取付要衝書(取り付けによりシステムの品質が変化する
   ような場合、取り付けの注意点を明確にして工事依頼する。
   書面で明示することで、工事内容が明確になるために、コストの信憑性が
   高くなり、工事見積精度が格段にあがる。
 完成図書
   出荷検収、工事検収でそれぞれ分離して明示する場合がある。客先の要求
   しだい(物品納入時の完成図書、工事を伴う納入時の工事完成図書、2種類
   完成図書がある)。

 図書は、最初、再利用する図書がない場合、何を書いてよいか、書き慣れていな
 いとなかなか書けないこともある。このために、他のシステム納入事例などを
 参照にすることで、容易にまとめられるようになる。
 そして、幾つかの案件の図書が蓄積されてくると、再利用の促進に繋がってい
 く。再利用できるようになり始めると、設計工数は半減以下に圧縮(コスト
 ダウン)が出来るようになる。

その他
 書面管理として文書番号、レビューの記録(OJTの目的含む)、照査/承認され
 た組織の議事録や設計資料など。


補足:

 機器納入仕様書
    機器の諸元を明確にする目的で発行する。
 システム納入仕様書
    顧客要件による仕様と諸元を明確にする目的で発行する。
    いわゆる納品物の身分証明書です。

 以下の詳細を参照ください。

 機器納入仕様書は、
    工事で使用する主だった機器の仕様。
    メーカー名、機器の概要、1次電源系などの電源確保目的の仕様程度の
    みの仕様としてにして提出します。
    納入機材の単品仕様です。
    提出して10日後に施主より何も指摘事項がなければそのままその機器
    を使い設置していきます。

 システム納入仕様書は、
    動作振る舞いを伴う納入物に対して運用面でシステムの仕様を明らかに
    する目的の納入仕様書です。
    機器納入仕様書に含まれている自火報設備も他棟で運用が伴う場合には
    、システム納入仕様書として動作振る舞いが必要荷なります(他棟の場
    合、建屋毎の主要制御装置と、統合制御を行う集中制御装置の優先権な
    どの運用が含まれるためです)。

 電気設備の慣習では、機器を取り付け、通電すれば動作する物品という位置づ
 けの「機材が機器納入仕様書」の慣習の範囲となります。
 運用が密接に係る電気設備では、機器納入仕様だけでは、納入後のトラブル回
 避が出来ないために、国交省と社団法人建設設備技術者協会が上記の指針を意
 見招請を行い運用面を明確にする指針が出ている。

システム設計会社にとっても重要性
 顧客も認識していない場合が多く有りますので、何を出しても通過する可能性
 が有ります。
 そのときの信憑性は、承認した事実で進めている。と言うことになります。

 また、システムとしての納入仕様書があることで、出荷時の試験成績書(出荷
 検査仕様書)を容易に作り変えることができる。
   システム提供会社にとってのメリットはここにあります。
   検査仕様書は、客先立会時、検査要件を予め定めておくことで、検収時の
   試験成績書(後に完成図書の一部になる)の検査項目内用を顧客と詰める
   作業も大幅に削減できます。

 受注前段階から検収までの一連の作業を簡素化する手法は、見積仕様書と納入
 仕様書(システム納入仕様書です)がしっかり作られていることで、システム
 品質も向上し、尚且つシステム設計工数が大幅に削減できる由縁です。


05.システム受注でこんな経験はありませんか(11の事例から)

2019-04-16 21:55:01 | 08.受注後フェーズ

1)工事後の電源投入で動作が不安定だったり、稀に誤動作する。
2)立会検査で種々の仕様にクレームが入った。
3)数ヶ月後にクレーム
4)検収時は問題なく正常稼働したが、顧客運用開始後誤動作が発生。
5)納入するシステムの全体像が、納入後にならないと明らかにならない
6)納入過程の打合せごとに、システムの動作要求が出てくる。
7)システム全体が設計されていないため、その下位の設計業務で統制が出来なくなる。
8)納入直前でスケジュールが遅れだす。
9)数年後に異常が発生したが、どんなシステムか担当者がいなかったのでわからない。現場直行で、手探り状態で対処するしかない。
10)納入後に異常が発生した。PC(ディスクトップPC(ワークステーション))を用いたシステムにスクリーンセーバー(市販アプリやフリーソフトウェア)をインストールされていた。
11)納入後、異常が発生した。システムで用いたL2(/L3)スイッチ(HUBスイッチ)の空きポートに顧客の機器を接続して利用していた。

こんな経験がありませんか、
この様な状況になると、人海戦術で対応することが多々あります。
顧客のクレームや現在進行中の案件は、人海戦術で対応せざるを得ませんが、
そうならない仕事に改善しなければ、いつになって苦労が報われません。

1)工事後の電源投入で動作が不安定だったり、稀に誤動作する。
  機材の不具合が逸早く頭をよぎることです。
  それ以外は、接続は正しいのか、設定がある機材の場合、設定は意図
  した設定となっているのか。
  コネクタはしっかり勘合しているのか。接続ケーブルの処理は電気的
  に正常か(ツイストペア線/シールド線/インピーダンス(終端抵抗)
  など、不具合と思われた製品は、解析等の手順で不具合を調査します
  (工数は掛かりますが品質の原因を解明するため必須)。
  また、解析後の状態は、戻入再生が可能な製品を対象として実施。
  他社購買品は、製品不良か否かを判断する。しかし、他社購入品は
  入れ替え対象となるケースが多いため、保管(貯蔵品扱いなど)
  になるケースも出てくる。

  現場で困った状態にしないための仕事にするには、工事要領など取付
  時の注意点や、可動条件(設定含め)等の予め確認した機材を利用す
  る(事前に疑似可動させる)事が納品に不可欠と言える。

2)立会検査で種々の仕様にクレームが入った。
  納入したシステムの動作振る舞い(運用仕様)は顧客の承認を受けて
  いますか。
  納入仕様書に顧客が運用するときの方法(要求されている運用や、顧
  客が暗黙の了解としている運用)が網羅されているのか。
  これらは、見積段階で洗い出され見積に反映される内容です。
  仕様が違う。検収差し戻し。
  顧客との商談で打合せした要求に漏れはありませんか、入札仕様書が
  有っても、その解釈により顧客と弊社で解釈が異なったりしていませ
  んか。

  思い込みでシステムを設計した場合の代償は、とても大きな金額にな
  りますので、思い込みは御法度です。必ず要件と実現の考え方(要件
  定義書)や納入仕様書を発行し客先承認を得ておくことがシステム事
  業では必須です。そして試験項目や判断基準は客先承認を得る。

3)数ヶ月後にクレーム
  顧客業務で利用し始めると不具合が多発する。運用面の不整合による
  クレーム(操作方法や動作の解釈違い)

  納入試験(立会検収など)は何の意味で行うのか。
  納入検収時の試験成績書が網羅されていない。
  各運用毎のレクチャーを行っていない。

  顧客の業務を想定した運用を全て通しで行う(システムの使い方の
  教育目的)で実施されていない。

4)検収時は問題なく正常稼働したが、顧客運用開始後誤動作が発生。
  検収状態と実運用状態の違いによる動作不安定が発生。

  →検収時、顧客の業務が停止している(業務が実稼働していない休日
   や営業時間外)時に行うケースが多い。納入したシステムの周囲環
   境(ノイズ状態など)が異なっているために、実運用で誤動作して
   しまうケースが発生する。

  誤動作の原因
   機器と機器の接続方法が電気的に整合が取れていなかった。
   →インピーダンス/平衡・不平衡/危機感の電位差(シグナル
    グラウンドの不備など)
      ・RE-485などの制御線を部分的に平行線で配線されていた。
      ・伝送路インピーダンスが開放で利用されていた(終端抵抗
       が接続されていなかった)
      ・機器と機器の電位が数ボルトあり、ローレベル信号の閾値
       (判断電位)が高くなり誤動作
      ・動力線や電力線に沿った信号(微弱)信号線を配線した。
       →発生した事例では、空調のコンプレッサーが稼働するとき
        のインラッシュ電流(瞬時のパルス成分)が納入したシス
        テムの信号線に回り込み誤動作した。

    複条ロスによる誤動作
       →信号系のラインを多数束ねて配線することで、通過できる
        電流値が下がります。検収時、周囲のノイズ等が無い状態
        ではギリギリの状態で稼働していた場合、周囲が稼働した
        状態では、信号線のノイズなどでカレントループ電流が規
        格外となり、誤動作する場合が出てくる。

    良かったのに、なぜ誤動作したの。
    機材の交換を繰り返し行っても改善できない。
    システム全体を俯瞰し、異常系の絞込みをすることがシステムの
    エンジニアの技(スキル)になります。

5)納入するシステムの全体像が、納入後にならないと明らかにならない
  顧客は、何時になったら全体像が判るのか不安になってくる。 

  納入仕様書の取り交わしがない。
  そのうちに種々の要求事項が新たに発生し、その対処でさらに納期を
  圧迫する。

6)納入過程の打合せごとに、システムの動作要求が出てくる。
  ・追加要求により、処理を作らなくてはならなくなり、設計時間が増え
   ていく。
  ・分散納入している機器との整合性が取れなくなっていくばかりか、
   システム動作に支障が出てくる(異常処理が網羅できなくなる)。
  ・納入日程が後ろにズレていく。
  ・納入済みの機材の改修をしなければならなくなり、本来行う取付工事
   の予定がズレてしまう。

  なぜ、お客さんがその都度の要求を言うか。仕様の取り決めや発注
  (お客さん内部の調達部門)の組織の違い等が多くかかわります。
  そして運用は実務者(現場の担当)です。
  システムの要件がシステム仕様や納入仕様として明確になる資料が出な
  いと、お客さん内部の情報伝達不足が解消できない場合が有ります。
  これも、契約後(通例1週間(官公庁)から1ヶ月(その他)程度)で納
  入仕様書を発行し、ある顧客に納入すべきシステムの全貌を明らかにし
  ます。そのため、納入仕様書は、客先承認を必須で行う必要があるの
  です。

7)システム全体が設計されていないため、その下位の設計業務で統制が
  出来なくなる。
  システム全体の作りこみが出来ないまま、機能単位の設計を行っている
  ために、システム動作全体が誰も把握できていない。
  単機能としては正常に稼働するが、システム全体で運用した場合、どう
  なるのか誰もわからないシステムとなる。

  システム基本設計書やシステム仕様書が記載されていない。全体像の仕
  組みが無ければ、機能単位の動作が無機的に接続されているだけのシス
  テムとなってしまう場合も多くあります。

8)納入直前でスケジュールが遅れだす。
  出来合いシステムの納入であれば受注、納入かもしれませんが、顧客固
  有の動作振る舞いを実現するシステムでは、そうは行きません。
  受注後には、仕様の客先確認し、それが承認されれば、着手が出来るこ
  とは言うまでもありません。

  そのシステムを設計し、擬似稼動させ評価していくスケジュールは関連
  部門と協議して作られていますか。
  顧客の打合せごとに仕様の変更が発生する。
  事前の仕様の取り決め(納入仕様書の客先承認)を実施しましたか。

9)納入後、数年後に異常が発生したが、どんなシステムか担当者がいな
  かったのでわからない。
  現場直行で、手探り状態で対処するしかない。
  納入物を設計した組織や担当は有限です。人事異動で担当者が入れ替わ
  る場合も多々あります。そこでも納入システムが引き継げていることで
  す。

  現物確認では、時間、実費、即検討ができないです。納入物の動作や原
  理が記載されている完成図書や納入仕様書が納品物の解析に役立ちます。
  これらの成果物は納品物と同等の重要管理物です。これがシステム事業
  と量産事業の差異の一つです。

10)納入後、異常が発生した。PC(ディスクトップPC(ワークステーション))
  を用いたシステムにスクリーンセーバー(市販アプリやフリーソフトウェア)
  をインストールされていた。
  納入時と納入後のシステム構成物(PCにインストールされている構成物
  も同様)の差異による障害です。


  システム保証で重要なことは、納入したシステムは、特定の要件に対応
  した専用機器(制御装置)になります(顧客の汎用機材ではない)。
  この専用の機材として用いているPCに、納入後、他のアプリケーション
  をインストールしたことで、PCの動作条件が変化する場合が出てきます。

  一つは、スリープ状態に出来ることや、処理装置(CPU)以外の電源系を
  部分シャットダウンできる機能も有しているばあいがあります。
  スクリーンセーバーが解除され、同時にスリープ状態が解除されても、
  外部制御等の制御系が再起動できなくなる場合も出てきます(過去も何
  度か発生あり)。
  特に、USB-RS-232C変換機(ドングル)によるインタフェースをしてい
  るか場合などは、スリープ状態から立ち上げる場合、再起動しなければ
  正常稼働しない機器も多くあります。

  納入システムでPCを用いた場合、指定されたソフトウェア以外は搭載し
  ないことが必須事項になります。

  この回避のために、事前活動として顧客聴取段階でアプリケーションの
  インストール有無を確認し、その条件でシステム稼働の試験を行う事が
  必要になります。

  スクリーンセーバーには、画面だけの処理(システム画面を他の写真な
  どに置き換える機能)のみの場合もありますが、納入システムとして試
  験条件に入れ正常稼働することが、受注会社としてのシステム保証の責
  務になります。
  システム仕様書やシステム取扱説明書には、インストールアプリケーシ
  ョンの注意事項を明記し、検収時(引渡し)時に十分な説明を加えて対
  処することです。また、組織は人事異動があるため、その場の説明だけ
  では継承できないことが多く出てきます。必ず書面で判るようにしてお
  くことです(説明した/しないの議論にしないためにも)。

11)納入後、異常が発生した。システムで用いたL2(/L3)スイッチ(HUB
  スイッチ)の空きポートに顧客の機器を接続して利用した。
  伝送との帯域が増えたことにより、帯域制限を超え、システムの運用で
  支障が発生。
  →実例として、事務用のPCを接続し、VoIP電話アプリで会社内の内線電
   話として利用していた(その場所には、内線電話が引けなかったとの
   事で利用したらしい)。
   音声圧縮されたADPCMを用いていたが、伝送路帯域がオーバーし、UDP
   -IPの破棄が多く発生。またTCP-IPは最小多発で、システム制御で
   ペンド(待ち状態)が多くなり、処理レスポンスの悪化として顧客の
   視点では壊れたと判断した。
   システムとして専用回線(クローズされたIP網)で構築される場合、
   スイッチHUBの空きポートを塞いでおく。等の考慮が必要です。
   また、機器に注意書きを添える(テプラなど)で人が変わっても判る
   ようにしておく。(当然仕様書には明記必要です)。

納入前、受注、納入後、いろいろなことがおきるのも、それぞれ個性あるお客さの受注業務だからです。
上記のような経験が一つでも見つかった場合、次の受注には「そうならない改善」を出し合って進めていける組織で無ければ、
利益が出せる事業になならないと思います。

フィードバック改善怠っていくと、アッという間に工数や不具合が堆積してしまい、身動きが取れなくなってしまいます。
→こうなったら、現状維持(惰性)で進めることになりますので、断崖絶壁状態とも言えますが、受注契約の履行をする必要があるので、致し方ありません(おそらく事業は消滅していくと思う)。
こうならないように、新規受注では、可能な限り顧客の望んでいる納入の姿を可視化(客先も自社も見える形で共有する=ドキュメント)し、進めていくことが必須となります。