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


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

・・・・・

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

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

システム構築において、

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

それがセオリーです。

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

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

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





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


              <Time Slip>
           ☞ 前回   ☞ 第1話 

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


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

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


システム構築いきなり「To Be」から入るやり方の危うさについて触れてきました。
今日はその続きです。

・・・・・

「As Is」の定義を飛ばしていきなり「To Be」から入るやり方をしたがためによく火を噴くのは、
幸運な場合ならカットオーバー以前でのユーザーレビューの時が挙げられます。

それは要件説明の会議かも知れませんし、システムテスト結果の報告会かも知れません。
場合によっては、ユーザーによる試行運用かも知れません。
いずれにしても、構築関係者の範囲での影響に済みます。

そして、最悪のケースは、本番リリースした後です。

「どうしてこんな動作するんだ?」
「どうしてこんな出力なんだ?」
「どうしてこんな操作手順なんだ?」
     ・・・

今までと違う業務手順を突きつけられたユーザーから一気に不満が噴き出すのです。
そして完成してしまった後の修正はとても費用が掛かるのが通例です。


ところで実は火を噴く前に予兆があったはずです。

「どっちの要件にしようかな?」
「どっちのパターンにしようかな?」

要件を詰めていくに当って、システム設計者が判断基準を持っていないために迷った瞬間があったはずです。
あの時にそっち仕様にしておけばこんな炎上は起きなかったのに!Y(>_<、)Y

みたいな後悔するはめにはならなかったのではないでしょうか?



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


              <Time Slip>
           ☞ 前回   ☞ 第1話 
                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


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

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


システム構築いきなり「To Be」から入るやり方の危うさについて触れました。
今日はその続きです。

・・・・・

これは価値観の問題にもなるのでしょうが、
いきなり「To Be」から入るやり方でも大丈夫な場合は、
その方が好ましいという考え方もあろうかと思います。

そのような考え方を支持する方がいらっしゃることについて、別に私は反対しません。

理学的なものの見方をしているのか、
それとも
工学的なものの見方をしているのか、

そういった違いに近いところだと考えるからです。

問題にすべきは、「As Is」の定義を飛ばして「To Be」に進むことが相応しくない場合の対応です。

それで行けるか行けないかは、一体誰がその「To Be」の設計者なのかでだいたい想像が付きます。
構築したそのシステムの想定ユーザーと「To Be」設計者との関係を見れば、おおよその場合当ります。


さて前々回で

現状分析は構築したシステムが受入れられるかどうかの生命線とも言える

と書きました。
もう一言足すならば、

現状分析は構築するシステムの要件に対する納得性や支持を得られるかどうかの生命線である

と言うこともできます。


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


              <Time Slip>
           ☞ 前回   ☞ 第1話 

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


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

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


前回、システム構築の生命線と言える要件定義について、静的な要件と動的な要件を区別して行なうことの重要性について触れました。
今日はその続きです。

・・・・・

要件定義がシステム構築の生命線だとすると、現状分析は構築したシステムが受入れられるかどうかの生命線と言うこともできます。

手間を惜しんでか、費用を惜しんでかわかりませんが、いきなりシステム構築またはシステム導入をするケースがありますね。

いわゆる「As Is」の定義を飛ばして「To Be」を描き、それに突き進むのです。

果たしてそう言った活動のウチどのくらいの割合が成功しているでしょうか?

システム構築またはシステム導入の推進者と、そのシステム利用者がほぼ同じ人間と言える場合なら、いきなり「To Be」から入るやり方でも大丈夫でしょう。

もしくは力関係がハッキリしていて、システム利用者に「押付け」が通用する状況下でも大丈夫なことが多いと思います。

しかし・・・

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


              <Time Slip>
           ☞ 前回   ☞ 第1話 

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


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

政治家的 システムエンジニア的(第8話)


平気で大変な嘘をつく政治家や役人を見かけることが多いのは、日本に限ったことでは無さそうなニュースが飛び込んで来たのでちょっとだけ触れてみました。

今日は話を先に進めます。

・・・・・

ついた自分の嘘で墓穴を掘った政府高官を話題に挙げました。

しかし、こんな結末ばかりではありません!(▼皿▼≠)

困ったことに、それを言い続けるといつの間にかマスコミもトーンダウンして、嘘を付いていた事実が立ち消えになってしまうケースも結構あるんですね。

お隣の国だったら、もう国民がみんな感情を爆発して大騒ぎになっていることでしょうが、日本人の国民性はそうでもないみたいですね。

しかし国民性だけの問題で済まされないことがあることを少し前に知りました。

なんと、選挙に当選するためには嘘を言っても良いという法律が有ったことです。 ヾ(゜□゜;)ノ




(続きはまたいつか・・・(^^)/  )





           <Time Slip>
        ☞ 前回   ☞ 第1話 

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


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

プロフィール

sugimotom

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

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

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

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