システム構築って失敗が多いの？

質問

中小企業の基幹系のシステム（ERP）を構築を担当する事になりました。構築の失敗しないように事前に構築知識（=失敗しない知恵）等を
集めたいと考えます。一般的なスキルからでも良いので構築知識（=失敗しない知恵）で参考になるURL等を教えて頂けますでしょうか？宜しくお願い致します。

回答No.5

se-goiken

SEをやっているものです。 基本的には出来ること(対応可能)はできる、出来ないことは出来ないと判断することです。 と言ってもそれが大変なんですが・・・。
(1)優先順位(実現したい機能、要望)
最近はスケジュール、金額的に無茶な要望が多いので、最低限必要な要望、後からでも構わないものの判断が必要です。 もちろんお客さんが納得できる説明、資料も必要ですよ。
(2)コスト面
予算が限られている場合には慎重に吟味しないと苦労します。
(3)打合せ
お客さんにある程度のイメージを持ってもらうためにこまめにシステムイメージの意識あわせをしておいた方がいいです。 あとでリスケや機能追加などの問題が発生しますよ。
(4)技術面
新しい物好きなお客さんだと、技術者がいなくて人の管理が大変になるので注意です。
まあ色々ありますが、構築前、構築中、構築後とそれぞれにやることを一つ一つクリアすればいいと思いますが。 それでも失敗するシステムもあるぐらいですからね。

お礼

ありがとうございました。金額的に無茶な要望って分かりますね！

回答No.4

noname#140971

私はＳＥでもプログラマでもありません。
で、発注サイドの視点から・・・。

１、過去に自社の仕組みを背景に発想し「これを実現してくれ」という無茶への対応。
２、「こんなことが出来りゃ御の字」という嘘八百への対応。
３、「そんなに予算は出せんぜよ」という出し渋りへの対応。

思うに、基幹業務のバラシと組み立てが勝負だと思いますね。

対象の基幹業務はとにもかくにも可能な限りバラしてしまうことでしょう。
で、非本質的なもの、副次的なものは大胆に捨象。
そうすれば、抽象的な基幹業務の概念ってのが見えてくると思いますよ。

＜抽象的な基幹業務の概念＞を持って＜これを実現してくれ＞との無茶に対峙。
でも、ここで顧客と論争しても意味がありませんので、そこそこに必要最低限にが注意事項。
でも、やはり、既存の仕組みを否定するには、より確かな＜抽象的な基幹業務の概念＞の獲得が肝心。
私が思うに、これを手中にできるか否かが勝負じゃーないでしょうか？

さて、そういうことで、重要なのは＜抽象的な基幹業務の概念＞の新システムへの転化。
基幹業務のバラシが下向的な分析ならば、新システムの設計は上向的な具体化。
ここでは、「こんなことが出来りゃ御の字」という＜嘘八百を信じない設計＞が大事でしょうね。
ここでは、顧客の打ち合わせ担当の言い分よりも＜現場との刷り合わせ＞が大事でしょうね。
大抵は、新システムに関する顧客の理解ってのは後追いです。
で、「こんなことが出来りゃ御の字」という顧客に限って、後から色々と言い出すものです。
で、「そんなんでＯｋじゃーないの」という顧客に限って、後から色々と言い出すものです。
実際の＜入力はこのようになる＞と＜出力はこのようになる＞を目で確認してもらって印鑑ももらう。
基幹システムと言えども、(1)入力、(2)演算、(3)出力が構成の３要素。
で、とにもかくに、(2)演算はさておき、(1)入力と(3)出力とは＜現場との刷り合わせ＞も含めて十分に。

最後に、折角の分析と総合というプロセスが無駄にならないように＜出し渋り＞と闘われること。

我が社の経営者の発想を見ていれば、このように思いますね。

お礼

ありがとうございました。お客様って後から色々と大変ですね！

回答No.3

noname#96023

システム化の目的
システム化の範囲
業務フロー変更の有無などなどの要件定義ですかね

ちなみに、ERP初心者しかいないのであればプロジェクトの失敗確立はかなり高いですよ

お礼

ありがとうございました。正に未経験者ぞろいです

回答No.2

yossy0426

どうもです。
ユーザーの仕事の流れ
トラブル発生時の処理方法

お礼

ありがとうございました。トラブル発生時の処理方法は気が付きませんでした

回答No.1

mappy0213

いかにユーザーさんのあいまいな希望を具体的な形で聞きだせるかですね

お礼

早速の回答ありがとうございました。