| 失敗しないｼｽﾃﾑ化 経験を元にユーザ側に立って考慮すべき点は！ is22未然に防げる”金銭的ロスト”！ |
| ｼｽﾃﾑ化は単にｿﾌﾄを導入すればよい訳ではありません。機械化の目的(省力化・管理向上・平準化・販促など）を達成する事が大切です。できるだけ少ないコストで・・・。 事前に"知っておきたい５％知識"。結果的に何千万ものｺｽﾄ流出防止に繋がる！（無形購入の怖さ！） |
| ここでは営業や全社関連のｼｽﾃﾑ化に焦点を当てています。因みに会計ｿﾌﾄ導入では失敗は無いはずです。 ｼｽﾃﾑ導入比較参考 |
| ・①担当者に明確な指示 | ・省力化・管理レベル向上などを推進責任者に明確に指示 |
| ・②開発する立場で違い | ・ＴＯＰは管理(管理資料・分析資料等の提供）、現場は省力化（仕事が楽に・・）と基本的な違い |
| ・③事前にチェック・・ | ・かかる費用、システムの範囲・内容、実施後の安定までの期間、ｻﾎﾟｰﾄ対応 等の最終的な形 |
| ・導入実績ではない・・・本当に満足しているユーザ数 | |
| ・導入ユーザの推薦・・・紹介してもらい自分で訪問しヒヤリング | |
| ・内容は聞いて納得でなく、見て確認する・・・デモ用でなく稼働するｼｽﾃﾑが好ましい | |
| ・稼働しているソフトの品質や取組姿勢をチェック・・・普段の対応を第三者に確認 | |
| ・④ﾍﾞﾝﾀﾞｰの営業手法！ | ・見積価格（一回目の見積）・・・様子見でコストのｽﾀｰﾄ（総額でない）。ｶｽﾄﾏｲｽﾞなど上積みｱﾘ |
| ・何でもできる発言・・・ｶｽﾄﾏｲｽﾞ(追加開発・追加費用）で金をかければ対応が殆ど | |
| ・成約までは”YES”が殆ど。後日もめるｹｰｽ多く、具体的な議事録等あれば好ましい | |
| ・営業と技術屋が分離（分業）・・・正確な内容が伝わってない(把握していない）事が多い | |
| ・ｶｽﾄﾏｲｽﾞは言われた通りに作る・・・正しいか否かは別。理解度に差でも全てﾕｰｻﾞ責任 | |
| ・⑤契約までの進め方 | ・導入ﾕｰｻﾞを訪問・・・自分で確認(内容、追加費用、ｶｽﾄﾏｲｽﾞ、ｻﾎﾟｰﾄ） |
| ・要望事項・帳表等の具体的な中身でやり取り（打合せ事項を記録し確認する・・後日の証拠） | |
| ・実際の操作・・・デモ品でなく完成品内容での確認が好ましい | |
| ・費用総額の事前把握・・・後出しの追加費用（指導料、残移行など）は意外に高額 | |
| ・⑥プレゼンの中身 | ・手段(入力）でなく、目的(出力）を確認。入力画面等は容易に開発可(不具合が出にくい） |
| ・⑦ベンダーの力 | ・組織の知名度でなく個人の力が重要（大学入試と同様）、会話の中から能力判断する |
| ・⑧導入前のヒヤリング | ・重要。具体的な質疑応答が良い。？は後日問題の可能性大 |
| ・⑨費用の経営(決算）への影響 | ・月次の負担は総額の約２％程度、感覚的には決算への負荷を感じない（注意） |
| ・⑩ＥＲＰ | ・経営に役に立つ(例えば、資料をそのまま使える、矛盾がない・・） |
| ・⑪現状調査・分析の目的 | ・対象業務全体の事前把握（漏れの防止、日々の作業他）・・・成功確率のｳｪｰﾄ大で重要 |
| ・既存使用の帳表・・・利用目的の正確な把握が目的（ｼｽﾃﾑ上の都合での変更に注意） | |
| ・業務の流れをｼｽﾃﾑに合わされる事がある(本来の流れか見極め要！） | |
| ・⑫ベンダーの能力 | ・単なるプログラム作成者（業務・実務知識は殆どない、勉強する機会がない）、ｽｰﾊﾟｰﾏﾝではない |
| ・⑬ﾊｰﾄﾞの価格 | ・安ければ何かがある（一般的には機能かｻｰﾋﾞｽ） |
| ・ﾊｰﾄﾞ知識がある業者が好ましい。絶えず連絡が取れる事、全体的なｻﾎﾟｰﾄ相談ができればより良い・・ | |
| ・⑭ｼｽﾃﾑ（品質） | ・ｿﾌﾄは知名度やﾌﾞﾗﾝﾄﾞでなく、ある意味個人。使いやすさより業務的欠陥がない事が優先 |
| ・⑮ｶｽﾄﾏｲｽﾞ費用 | ・当初の見積もりの倍以上が多い。言った言葉で対応されるので青天井になる（注意） |
| ・垂れ流しになる危険がある。対応は、不具合無くし安定稼働後の数か月後が良い | |
| ・⑯見積 | ・第一回の提示価格（通常の買物と違い、上積みのｽﾀｰﾄで、値引きはﾅｲ） |
| ・⑰導入実績 | ・ﾕｰｻﾞへの販売数で、ﾕｰｻﾞ満足実績ではない。営業力で売れる（一概に評価基準にならない） |
| ・⑱開発単価（ｶｽﾄﾏｲｽﾞなど） | ・SE、PGMの識別は困難でﾍﾞﾝﾀﾞｰ都合で区別。単価は４～６万位／日が相場 |
| ・⑲ﾊﾟｯｹｰｼﾞ | ・ｶｽﾄﾏｲｽﾞせずそのまま使用がﾍﾞｽﾄ・・・安易に手直しは大きなﾘｽｸがある |
| ・ｼｽﾃﾑ統合のﾃﾞｰﾀ自動連結に注意（ｼｽﾃﾑ上の問題が生じる事多々で、ﾜﾝｸｯｼｮﾝの連結をお勧め | |
| ・⑳ﾌﾟﾛｼﾞｪｸﾄ会議(対ﾍﾞﾝﾀﾞｰ） | ・内容で分ける①点（個別明細）→担当者間② 線(業務の流れ・ｼｽﾃﾑ）→関係者全て。 |
| ・内容の影響度・・・個別の打合せを全体的な流れに影響させない様考慮する（安易な妥協をしない） | |
| ・21、会議の議事録 | ・ﾕｰｻﾞが作成する事が好ましい(作成側の都合の良い表現になる、相手が作成ならﾒﾓとる事必須） |
| ・具体的な内容で記述（揉めた時の寄り処・・特に金銭的な決着になる）＆確認印を取る | |
| ・22、開発の進捗度 | ・個々のﾌﾟﾛｸﾞﾗﾑの進捗度（％）は単なる目安、完成項目で評価（人日消込）する。 |
| ・開発は基幹部分の完成で2割、例外等が8割といわれる。（表面上での楽観は危険すぎる） | |
| ・23、開発体制 | ・一人のワンマンと優秀な複数のスタッフが良い（多ければ良いとは言えない） |
| ・ﾄｰﾀﾙ・ｼｽﾃﾑ(総合管理）のﾘｰﾀﾞｰは一般的な業務・実務・商業一般及び会計など多くの知識が要 | |
| ・実質ﾘｰﾀﾞｰはｱｸﾃｨﾌﾞな性格、責任感、根気、健康、実行力、経験など必要 | |
| ・24、ﾍﾞﾝﾀﾞｰ対応(付き合い） | ・安定稼働までは食事程度（ｺﾞﾙﾌ・接待は慎む・・Noと言えなくなる） |
| ・25、ﾍﾞﾝﾀﾞｰとの打ち合わせ | ・必ずメモをとる（出来たら日付、確認など残る形） |
| ・26、実務現場と理論派 | ・現場実務者ほど流行語などには疎い。勉強する時間的余裕がない(知識ある程実務？かも） |
| ・27、ｶｽﾄﾏｲｽﾞの限界 | ・ﾍﾞﾝﾀﾞｰ側は開発できない場合、高額見積の提示がある。事後対応の約束は書面で保存必須 |
| ・ﾊﾟｯｹｰｼﾞをｶｽﾄﾏｲｽﾞすると、共通部分がﾊﾟｯｹｰｼﾞでなくなる。以降のﾊﾞｰｼﾞｮﾝ・ｱｯﾌﾟは個別 | |
| ・ﾊﾟｯｹｰｼﾞでの統合ｼｽﾃﾑでは同一要件のｶｽﾄﾏｲｽﾞは2，3回が限度（対応できる見極めが要） | |
| ・28、ｺﾝｻﾙ | ・ある意味喋る辞書のようなもの。評論家、ｱﾄﾞﾊﾞｲｻｰで責任は持たない。実務経験が豊富な人は稀 |
| ・29、検収 | ・ﾍﾞﾝﾀﾞｰは期末に未完成でも検収印の要請が多い(決算対策で）。その場合は必ず覚書を取る |
| ・どんな形でも検収印後はｻｰﾋﾞｽ・ﾚﾍﾞﾙが低下(以降ｸﾚｰﾑしにくい） | |
| ・30、瑕疵担保 | ・ｿﾌﾄ(ｼｽﾃﾑ）に対する本番後からの保証期間・・・3～14か月程度(ｼｽﾃﾑの大きさ、内容により異なる） |
| ・期間経過後は不具合対応も有料になる。問題が発生した場合、早急な対応が必要である。 | |
| ・31、稼働後の問題対応 | ・同じ様な内容のｶｽﾄﾏｲｽﾞは対応できない場合、2，3回で捨てる勇気も必要(能力的な見極め要） |
| ・問題解決は発生後1ヶ月程度が最長の目安。強い要請が必要な場合も・・ | |
| ・32、ｼｽﾃﾑの検収内容 | ・例外も含めﾁｪｯｸ項目を記述し多くの項目でﾃｽﾄ確認を行う。確認作業は例外処理に重点を置くのがﾎﾟｲﾝﾄ |
| ・画面等ﾃﾞｰﾀ処理時間をﾁｪｯｸ(複数同時操作含め）。問題点解決策として安易なﾊｰﾄﾞの切替提案も多い | |
| ・33、稼働後のｻﾎﾟｰﾄ内容 | ・不具合(ﾊﾞｸﾞ）対応が大半。ﾚﾍﾞﾙｱｯﾌﾟは殆どない |
| ・業務の質問には答えられない（ﾌﾟﾛｸﾞﾗﾑ的な内容のみ） | |
| ・34、中途採用 | ・知識とできるは別物。実務に強い人材は少なく貴重な存在、勉強する時間も少ない！ |
| ・具体的な実務経験を聞く（実際に対応した役割、業務の内容など） | |
| ・試行期間（1～3ヶ月程度）必須。理論型より実務型が賢明。男性より女性か！ | |
| ・35、ﾍﾞﾝﾀﾞｰの開発経験 | ・殆どの人が単一ｼｽﾃﾑのﾌﾟﾛｸﾞﾗﾑ開発。2・3年までﾌﾟﾛｸﾞﾗﾏｰそれ以降ＳＥという！ |
| ・ﾄｰﾀﾙ・ｼｽﾃﾑの開発経験者は全体でせいぜい1～2%、大半の人は経験がない(そういう機会がない） | |
| ・36、得意分野の識別 | ・全てに強い人はいない①ﾊｰﾄﾞ･os等②ﾌﾟﾛｸﾞﾗﾑ開発③業務対応 など・・ 理論型・実践型あり |
| ・37、開発の種類・内容 | ・①総合の業務ｼｽﾃﾑ→単一ｼｽﾃﾑを組合せた統合ｼｽﾃﾑが主流②単一ｼｽﾃﾑ→会計･販売･給与などのｿﾌﾄ |
| ・①HP・・見た目で評価しやすい②業務ｼｽﾃﾑ・・使ってみないと判断できない。慣れで評価が変わる | |
| ・単一ｼｽﾃﾑはｶｽﾄﾏｲｽﾞしやすいが、総合ｼｽﾃﾑはｶｽﾄﾏｲｽﾞしにくい | |
| ・38、開発予算 | ・社外秘・・・ﾍﾞﾝﾀﾞｰには教えない（ﾍﾞﾝﾀﾞｰの見積提示がmaxになる。開発過程で支障をきたす） |
| ・39、ｼｽﾃﾑ化の成功確率 | ・一般的に言われる程は高くない(10%以下)・・・稼働したからと成功ではなく『投資対効果』で判断する |
| ・実施後半年位でｼｽﾃﾑ・ﾚﾋﾞｭｰは必要。見直し後の小さな見直改善は大きな効果がある場合が多い |