プロセスバリュー・エンジニアリングとは(第12話)


いきなり「To Be」から入るようなシステム構築の進め方が火を噴くケースの話をしました。
今日はその続きです。

・・・・・

開発側にとっては開発工数や難易度に大きな差が無いような仕様の違いであっても、どちらを選んだかでユーザーから思わぬ批判を招くといった不幸な事件は時代やICT技術が変わっても相変わらず発生しています。

決して誰にも悪意などないのに、です。

システム構築において、

システム要件で迷ったときには、現状の仕様に近い方を選ぶ

それがセオリーです。

それはお分かりのように、現状のやり方には実績があるからです。
要件をどうしようか迷う程度の、問題視されていない部分の要件なら現行の仕様がいいのです。

ところが、「As Is」の作業を飛ばしてしまっていると、その「現行」がわかりません。
システム設計者にとって、重要な判断基準が得られていないことになるのです。

「As Is」をきちんとやっておくことで運用をスムーズに開始できることもあります。





(続きはまた今度・・・(^^)/ )


              <Time Slip>
           ☞ 前回   ☞ 第1話 

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

コメント

コメントの投稿

管理者にだけ表示を許可する

トラックバック


この記事にトラックバックする(FC2ブログユーザー) URL

プロフィール

sugimotom

Author:sugimotom
ようこそ!
職業は業務改革パートナー。余暇は篠笛や和太鼓の響きを楽しんで過ごしています。
そんな私の仕事のこと、趣味のこと、日々感じたことなど 徒然に書き留めています。

私も気が付けば半世紀もの月日を重ねてしまっていました。
飛び去るように過ぎて行く貴重な人生の合間に、ほんの少しだけ立ち止まって、さぁ深呼吸!

大切な今を思いっきり感じましょう。
    → → → プロフィール

最新記事
FC2カウンター
月別アーカイブ
最新コメント
最新トラックバック
..
ブログパーツ アクセス解析