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


「As Is」をきちんとやっておくことでユーザーの方たちに納得のいく説明をしてあげられるという話をしました。
今日はその続きです。

・・・・・

いきなり「To Be」から入った場合、そのシステムの導入効果が抽象的にしか説明されていない場合が少なくありません。

「コスト削減を目指す」
「品質の向上」
「業務の刷新を図る」

とかの類いです。

どの部分をどう変えるからコストがこの位削減できるんだ

とか、

どこの作業がどう刷新されるんだ

といった根拠が具体化されないことが多いです。

それは無理もありませんよね。
現状を具体化する作業を行なっていないのですから、そこからの変化を具体的に表現することなんかできません。

「As Is」をきちんとやっておけば、システム構築に関わっていないユーザーの皆さんにもきちんと説明できる材料を得られるので、新しいシステムのスムーズな運用開始につなげられるのです。




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


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


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

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


「As Is」をきちんとやっておくことで運用をスムーズに開始できることもあるという話をしました。
今日はその続きです。

・・・・・


「As Is」をきちんとやっておくことで運用をスムーズに開始できることもあると言うのは、

ユーザーの方々と同じ視点で問題を捉え、違う見方の解決策を提示できることがある

からです。

バグでも何でもないのにユーザーから不満を寄せられていると言うときに、
およそそのユーザーの方たちは現状との差異を問題にすることが多いです。

だからその「現状」を知らなければユーザーの方たちの不満の原因を理解してあげられません。

さらに言うと、そのシステムを構築することにより得られるメリットが、現状が変わることよりもどれだけ優位性が有るのかと言うことを納得してもらうこともできません。




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


              <Time Slip>
           ☞ 前回   ☞ 第1話 

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


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

プロセスバリュー・エンジニアリングとは(第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
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロフィール

sugimotom

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

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

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

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