業務設計・RFP・要件定義の“天動説”―ユーザーの主体性発揮を!
ちょっと前に読んだ本の紹介を。。。
業務設計・RFP・要件定義の“天動説”―ユーザーの主体性発揮を!
木ノ下 勝郎 (著)
ユーザー主導による業務設計の考え方を天動説、ベンダー主導によるシステム導入の考え方を地動説に例えて明確に分け、ユーザー主導プロジェクトの必要性、その効果、進め方などを提案しています。
要件はユーザーの中にあるので、また、導入効果の判断もユーザー側でなとできないので、プロジェクトオーナーはユーザであるべきかなと思ったりします。となるとユーザ主導はより自然な形なのかなと。といっても要件定義のすべてユーザ側で、ということではないです。あくまでも主役はユーザ側ということすね。
業務設計・RFP・要件定義の“天動説”―ユーザーの主体性発揮を!
木ノ下 勝郎 (著)
ユーザー主導による業務設計の考え方を天動説、ベンダー主導によるシステム導入の考え方を地動説に例えて明確に分け、ユーザー主導プロジェクトの必要性、その効果、進め方などを提案しています。
要件はユーザーの中にあるので、また、導入効果の判断もユーザー側でなとできないので、プロジェクトオーナーはユーザであるべきかなと思ったりします。となるとユーザ主導はより自然な形なのかなと。といっても要件定義のすべてユーザ側で、ということではないです。あくまでも主役はユーザ側ということすね。
COMMENTS
いま会社でシステム部門が作ったシステムを軌道に
乗せようか思案してるのですが、あまりに「地動説」的な
作りになってて、もう全然使えないというか、
多機能は無機能の典型のような感じで。
勿論私はシステムは作りませんが、もう少し
リサーチやヒアリングをすべきじゃないかなぁと
思います。
とあるシステムの再構築(僕は発注側)
パッケージのカスタマイズですが、
それでも仕様書を作るために、
コンサルと1年間かけて詰めて、
コンサルに支払ったお金は1500万円以上だったかなぁ。(システム構築本体は何憶で落札されたか、その前に異動したので知りません。)
こういう業務だからこういう機能が必要だ。みたいに業務要件からカスケードされた機能定義になっていないと
システム側に業務をあわせる事になってしまい、苦労されることが多いようです。
パッケージを導入される場合、カスタマイズで業務に機能を寄せることはできますが限界があります。
業務要件とパッケージ機能とのFit&Gap分析がポイントになりますね。
でもその業務要件がまとまりきれないという事もよくあり、各方面でいろいろご苦労されてるようです。
杯を乾かすさん>
しっかりやろうとすると其れくらいの期間もコストも掛かってしまうことはあると思います。
一見遠回りのようで一番近道だったりします。
数億規模なら尚更ですね。