02．システム事業を進めるに当たり（心得）

ソリューションに限らず、システム受注全般で必須になる要件は、

１）納入物の履歴を克明に残すこと。
　システムの納入は、量産品と異なり、サンプルは有りません。納入した物が全てになり、顧客の設置場に置かれてしまいます。
　どこかの処理部に異常が発生しても、挙動不審な動作振る舞いになっても、実機は顧客とところにあるだけです。
　問い合わせを受けた品質保証部門などは、調べることが出来なければ、お客さんの質問など、システムの全貌が分らないまま聞くだけしか出来ないことになります。
　電話連絡時の確認事項などもシステム設計図書から紐解けるようにしておくことが、顧客への礼儀、システムを納入した会社としての責務になります。
　（担当者が変わっても、設計資産で継承できることがシステム事業の強みになる）

２）顧客のネゴシエーション
　受注したシステムの仕様などで、顧客とのコンセンサスに問題が有りませんか。
　具体的なシステムを構築していくことは、システム設計がキッチリ出来ていれば、実現することが出来ると思います。
　その実現したシステム構築物を顧客に納品し、運用教育し、実運用し、その時点では、可もなく不可もなくであっても検収されれば納入完了となってしまいます。
　しかし、昨今のクレームは、検収後の発生する内容が多いです。本質を正すせば、顧客の想定していたシステムと、納入システムに食い違い（解釈の違い）が出たことが理由です。
　　　　　　
　なぜ解釈の違いが物を作って納品し、稼動させるまで見つからなかったのか。

　システム納品物は、出来た結果で良い悪いの判断するのは、ありえません。
　受注が確定した段階で、納入仕様書を取り交わすことが大原則です。その行為を行わないで、物作りをしている結果として、最終工程で手戻りにおなってしまうケースです。

　手戻りが発生すると言うことは、時間も必要になる、人も必要になる。そして、設計物の仕様も再構築の場合も出てきます（作り直し）。
　全て無料稼動で対応しなくてはなりません。厳しいコスト競争にかって受注したシステムでは、なおさらの如くに、案件の収益は、赤字に落ち込みます。

　こうならないためには、システム設計の具体的な発注前に、納入仕様書（機材の使用や数量、系統図だけではなく、運用やそして無の動作振る舞いも明記する）を取り交わし顧客との返却承認を得てからシステムのこうちくを進める。

３）システム事業は、納入責任が付いて回る
　システムを納入しました。5年後で事業を撤退しました。
　お客さんのシステムはどうなるのでしょうか。
　事業を撤退したとしても、お客さんに納入したシステムの問い合わせは、どうしたらよいでしょうか。
　品質保証（システム品質として）としていかなくてはなりません。
　このために、組織としての覚悟が必要になります。安易な気持ちでシステム事業が儲かるからでは、この事業に参入する資格が無いと思ったほうが良いです。
　遣るからには、最後まで責任を持って販売したシステムをフォローしていくことです。
　（そのためにも1項の納入物の履歴は、とても重要なことになります。事業譲渡をする場合でも、資産がなければ、事業価値は無いとみなされてしまう場合も有ります）

　リスクがあっても認識したリスクにしていくこと。そしてそのリスクの対処方法を想定しておくこと。
　それを行っても突発的なリスクは付き物、その突発的なリスクを解決できる時間を作るためにも事前に分かるリスクは前段階で対処しておくことです。

01.ソリューションってなに？

ソリューションとは、
　単語の意味は、「回答」や「解決すること」、そして、「回答を得ていくための経過」としても用いられています。
「ソリューション」と言う「商品」ではないことを理解していただく。


　回答することや、解決することは、顧客の課題によって困難な状況に陥る可能性も有ります。
　また、顧客の課題にっては、過去に経験していなかった解決方法を考えなければならない場合も出てきます。
これがリスクと言われる範疇です。

　ソリューショ事業を進めるにあたり、考え方（見方や視点）の角度を変えていくことがとても大切です。
　なぜ、考え方の角度を変えるのか・・・・
　　納品物から発想を展開するのではなく、
　　顧客の課題から、利用できる機材を引き出していく。
　からです。

　こうした考える方向を変えないと、、顧客の真意がぼけてしまい、納入仕様で的確な表現が出来なかった運用が、皆無となった仕様で納入されてしまうケースに繋がるからです。

　　
ソリューションビジネスで大切なこと。
　それは、顧客の話をよく聞くこと、顧客の仕事を理解すること、そこから、見えてくること顧客が言っていることが解釈できるようになります。
そこまで到達したら、顧客の課題を整理し、解決策を考えていくこと。
　　
　課題を解決するための方法は、今ある「もの」、「仕組み」を徹底的に利用することです。
　よく聞く話として、課題解決に一から新規に開発をする。量産受注の世界では、これも正しい手法ですが、顧客にあわせた一品システムの場合、どうなるでしょうか。
　開発費の回収、開発期間、開発物の品質・・・・・全てリスクとなって、膨大な投資を要することになります。

　ソリューションビジネスを進めるとは、あるものを徹底的に知り尽くし、それを活用する。と言い換えても良いくらいです。

ソリューションと入札仕様には落とし穴がある
　顧客の課題（したいこと）を仕様書で提供してもらえる。俗に言う入札などは全てこの方式だと思います（一般競争入札）。
　この入札仕様書、項目別に理路整然として纏められています。
　しかし、仕様をよく見ると、8割、9割の仕様書が、物理的な仕様や機材の仕様を中心として観点で記載されていることが理解できると思います。
　そして、運用などは、数行、もしくは、一言で終わっているケースが見受けられます（仕様作成を手伝ったメーカの思惑もあります）。
　　
　この「運用」が盲点です。
　盲点だからこそ、抜けやすい。そして検収時点でも、物理的検収が主体となってしまい、そこには、運用が薄れてしまい、実運用になり改修の要望やクレームとしてあがってくる。

　機材がアナログ方式であれば、機材の機能と、機材間の接続で動作するシステムです。昨今のIPネットワークでは、機材の機能だけでは運用方法が定まらない、良い言い方で言えば、自由度が高いシステムが提供できるということに尽きます。

ソリューションで気をつけることは、
　機材にとらわれない発想で顧客の課題を掘り下げる。
　機材間の接続だけでは、その仕様が最適に機能しない場合もあること。
　顧客のIPネットワークを用いる場合、トラフィックや、輻輳時の対処を十分に考慮すること。
　IPネットワークを用いたシステムでは、自由度が高いシステムで提供できるため、顧客の思惑をしっかり聞き出すこと。
　そして、運用する場合のプライオリティをはっきり得ていくこと。
　具体的な機材の手配（発注）をする前段階で机上設計し、設計品質の確度を高めた状態で発注する。
　（発注時に支払うお金は、顧客から預っているお金と考え、手戻りは最小限に抑えられる仕事のやり方で進める）

　などが、ソリューションで解決していける最大のメリット（顧客にっとてメリット）になります。

とはいっても、
　客先の要望をしっかり聞き出して、聞いたことを話したことが、打合せ覚書にまとまっていれば、その覚書からお客さんがしたいと思われることを抽出できますので、素の状態で聞くことがとても大切なことです。
　この場合、会社紹介など、最小限5分程度で済ませることも重要なことです。
　そして、提案書は不要。固定概念と、顧客がしたい事を話さなくなるケースが多いため（提案書で出来るだろう、という顧客側の解釈が、心理的に膨らむからです。）