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

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


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

・・・・・

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

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

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

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

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

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

しかし・・・

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


              <Time Slip>
           ☞ 前回   ☞ 第1話 

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


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

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


前回、システム要件定義について話を始めました。
今日はその続きです。

・・・・・

要求定義も要件定義も、どちらもシステム構築の生命線と言える重要なものです。


静的な要件と動的な要件とがあります。
静的な要件とは、画面や帳票書式と言ったものがあります。
動的な要件には能動的な要件と受動的な要件があります。

能動的な要件とは定型パターンに沿って処理が進む要件です。

受動的な要件とは、例外処理や条件分岐のように、状況に寄り処理が変化するものです。やっかいなものになると、条件分岐自体が状況により変化するものがあります。

難しいのはこの動的要件を定義するところです。
ですので、要件定義の作業の中で、静的な要件と動的な要件を区別して管理することが助けとなります。


(続きはこちらへ・・・)





              <Time Slip>
           ☞ 前回   ☞ 第1話 




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


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

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


前回までは現状把握の勘所について話してきました。
現状把握が終ったら次に行なうのが要件の確定です。

・・・・・

ICTシステムを構築する場合、特に重要なのがシステムの要件定義です。
システムの要件定義は

「何をゴールとしてシステム構築をするのか」を決めることだ

と言い換えられます。

大切な言葉は
「ゴール」

「決める」
です。

これがとても至難とも言える難しいタスクなのです。
システム開発を主導してきたエンジニアの皆さんなら、一度くらい痛い目に遭っているのでは無いでしょうか?



(続きはこちらへ・・・)



              <Time Slip>
           ☞ 前回   ☞ 第1話 



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


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

情報節という考え方(第6話)


前回は「通過節」というものを紹介しました。
今日は情報節の2つめです。

・・・・・

2.分岐節(ぶんきせつ)

情報内容によって異なる処理(作業)に振り分ける節です。

通過説同様にこの節でも情報の内容が変わったり、何か新しい情報が加わったりしません。

しかし「判断」が行なわれています。

見落としてしまうような例外処理がアルゴリズムの中に生じるリスクが高い節と言えます。





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



              <Time Slip>
              ☞ 前回   ☞ 第1話 



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


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

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


現状把握のために行なうヒアリングの方法における留意点について話してきました。

今日はその続きです。
・・・・・

ヒアリングは実態を知るために行なうのですが、あまりにもそれに捕らわれすぎて尋問口調になってしまってはいけません。

また完全主義にならないような寛容さも大事です。

あまり厳しく求めてしまうと相手が萎縮して思い出すものもの思い出せなくなってしまいます。
そもそも現状を聞いている相手のその人は、現状調査の後に行なう業務改革実施フェーズでは当事者もしくは関係者になるのです。

一緒に改革していく仲間になる人たちなのです。

だからヒアリングの機会を通じて信頼関係が築けるようにしないといけないのです。



(続きはこちらへ・・・)





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


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

テーマ : 思い入れ - ジャンル : 日記

情報節という考え方(第5話)


前回、情報の流れを理解して整流化するには「情報節」というものを理解すると助けになりますよという話をしました。
今日からいろいろな「情報節」について順番に見ていくことにします。

・・・・・

1.通過節(つうかせつ)

文字通り、情報が通過しているだけの節です。

情報の内容が変わったり、何か新しい情報が加わったりしません。

メモ用紙に書いてきたので、それをワープロに打ち込んで・・・なんていうこともしません。
(難しい言葉で言うと、媒体変換もしないと言います)







(続きはこちらへ・・・)



              <Time Slip>
              ☞ 前回   ☞ 第1話 




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


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

テーマ : 日々のつれづれ - ジャンル : 日記

情報節という考え方(第4話)


活動の生産性を左右する情報の流れ。
では、情報の流れにはどんな特徴があるのでしょうか?
・・・・・

川の流れを思い浮かべればわかるように、情報の流れも時には淀んだり、止まったり、場合によっては消えてしまうこともあります。

それらの情報の流れを上手にコントロールしてあげることが重要です。

敵を知り、己を知れば、負け知らずの戦を100回でもできるという有名な格言がある通り、この情報の流れとはどんなものかを知りましょう。


情報の流れを理解するには「情報節」(じょうほうせつ)というものを考えるといいと思います。

「節」(せつ)とは、情報の接続点と言う意味です。

情報を受け取る、情報を発信する、情報を加工する・・・など情報と結ばれた作業=プロセスが「節」です。



「情報節」は私の独自の見方なので一般的ではありませんが、この「情報節」の種類を頭に置いておくと役に立つと思います。


次回から「情報節」の種類と特徴を見ていってみましょう。




(続きはこちらへ・・・)



              <Time Slip>
              ☞ 前回   ☞ 第1話 



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


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

テーマ : 思い入れ - ジャンル : 日記

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


現状把握のためのヒアリングは、先入観と偏見を持たずに謙虚な気持ちで向き合わなければいけません。
しかしだからといってただ素直に聞いているのもダメなのです。

今日はその続きです。
・・・・・

私は初めから終わりまで相手の話全体を振り返り、今発言している内容で矛盾点はないか?飛躍は無いか?とリアルタイムでチェックします。

そこにはそれまでの経験を総動員した「勘」がアンテナを張っています。

またあるときは、とぼけて同じ内容の質問を時間をずらしたり、表現を少し変えたりしてぶつけたりしてみます。

時にはどんな答えが返ってくるのかほぼ想定できるような質問も混ぜながら相手の気付きを誘います。

時折、オブザーバー的に入る第3者がわかったような口を挟んでこのテクニックの足を引っ張ることもありますが、その場合でも少し時間を置いてリトライします。

「事実は小説より奇なり」という言葉はありますが、業務分析の世界では事実の積み重ねには納得性が伴うのです。

納得できないと「勘」が「おかしいぞ!」っていうシグナルを発します。




(続きはこちらへ・・・)





              <Time Slip>
           ☞ 前回   ☞ 第1話 





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


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

テーマ : 思い入れ - ジャンル : 日記

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


現場の生の声を聞くことが重要なのだけれど、それは結構難しいものだというお話をしました。
でもそれを乗り越えなければ現状把握が進みません。

今日はその続きです。
・・・・・

現状把握の為の聴き取りは、先入観を挟まずにしっかりと聞くことが大切です。
しかし、相手の言葉の中に事実と違うものや事実から離れた表現が混ざっていることがしばしばあります。

そう言う場合、相手を責めることは百害あって一利無し。
聴き取りが壊れてしまうこともあります。

別に相手が意図的に嘘を付いているわけではないのですから。

不正確な言葉混じりの回答をできるだけ浄化して、事実を浮かび上がらせるためには、会話が重要です。
ただ素直に聞いているだけではダメなのです。それなら素人でもできます。




(続きはこちらへ・・・)




              <Time Slip>
           ☞ 前回   ☞ 第1話 




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


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

テーマ : 思い入れ - ジャンル : 日記

ICTと焼売(第3話)


ICT業界から焼売作りに転身したYさん。その焼売ってどんなものなんでしょう?
・・・・・

博雅というのは、横浜で老舗の焼売屋さんだったそうで、何でも日本で最初に焼売を作ったとか。

しかしせっかくの歴史も後継者難から途絶えかけていたんだそうです。

早速食べてみると・・・。
なかなか大粒で、ジューシー。
一口噛むととたんに口の中に肉汁が浸み通ります。


焼売と言えば横浜に限らずたくさんの専門店が味を競っています。
さてこの焼売、老舗の味を日本中にまた届けられる日はいつでしょうか。

今日もYさんはブランド再興に東西奔走しています。


              <Time Slip>
           ☞ 前回   ☞ 第1話 


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


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

テーマ : 日々のつれづれ - ジャンル : 日記

10人10色

10人10色とはよく言ったものです。
本当に人は1人1人個性が違うものですね。(^^)

じっくりと慎重に考える人もいれば、逆に即断即決で行動が素早い人もいる。

何かの事象に反応する時も、まず受け止めてから態度を決める人もいれば、瞬間湯沸かし器のように反射的に湯気を立てて怒り出す人もいますね。

容姿ばかりでなく、考え方、反応の仕方、喜怒哀楽の現われ方、・・・。
ほんとうに様々です。


さて、今日はそんな人間の特性を踏まえた私の対人術を1つご紹介します。
対人術と言っても、これはマネージメントの話です。

あくまで私のやり方ですが、部下や誰かに作業をしてもらうといった時のヒントになれば幸いです。


人には「動作のスローな人」や「せっかちな人」、「なかなかスタートしないがエンジンが掛かるとものすごく早い人」・・・などなど、それぞれ特性(持ち味?)があります。

その中のひとつのパターンですが、何か作業を頼むと「さっさと済ませてしまう人」と「〆切までの時間いっぱいずうっと作業をしている人」がいます。

前者の人は、いつも時間を大切にしている要領の良い人なのではないでしょうか。
一方、後者のような人は完全主義的な責任感の強い人が多いのではないかと思っています。

そんな人たちに作業や仕事をお願いする時、一律に対応するのはあまり得策でないのではないでしょうか。
特にマネージャーとか管理職と言った人たちは、預けられた部下たちと協力して最大限の効果を発揮する責任があります。




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




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


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

テーマ : 日々のつれづれ - ジャンル : 日記

情報節という考え方(第3話)


作業をつなぐ情報の流れは、活動を円滑に確実に行なうために必要な管理ポイントです。

今日はその続きです。
・・・・・


作業から次の作業へ流れる情報が整流化されていることが重要だというお話をしました。

言い換えれば、活動の各プロセスの間に流通している情報が、無駄なく、不足なく、適時に流れているかということです。


そこをよく注意して見て、問題の所在を見つけて改善してあげると活動の効率が高まるのです。

別の言い方をすれば、「活動の生産性が高まる」ということになります。


もう少し「情報の流れ」について考えてみましょう。


情報の「流れ」と言いましたが、なにもいつも動いているばかりではありません。


川の流れを見て下さい。

水がサラサラと流れている瀬もあれば、淀んでいる淵もあります。

途中で分岐して行ってしまう流れや、時には土手の破れから外に流れ出てしまうこともありますね。




(続きはこちらへ・・・)



              <Time Slip>
              ☞ 前回   ☞ 第1話 

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


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

テーマ : 日々のつれづれ - ジャンル : 日記

データフローダイアグラムの使い方(第2話)


データフローダイアグラム(Data Flow Diagram、データフロー図)を取り上げて話し始めました。

今日はその続きです。
・・・・・

DFDの書き方を紹介している記事は多いですが、使い方について触れた話題というのは少ないようですね。

「DFDの書き方」と「DFDの使い方」はとても近い概念ですが、「使い方」の方がより強く「意図」が込められることになります。

習った「書き方」に捕らわれることなく、「意図」「目的」によりその作法や使う記号などをアレンジして構わないと思います。道具なんですから。

通常では、DFDを書くことは目的でもゴールでもありません。
あくまで目的を達成するための通過点です。中間生成物です。

だから自由な発想で使って良いのです。


ただし得意なこと、不得意なことがあるのでそこはよくわきまえている必要はありますが。


まず心構えとして、DFDは

「概要を」「短期間に」把握するための道具

だということを忘れてはいけません。
そこからはみ出していくとDFDの最大の特長である「シンプル表現」という特性を失ってしまいます。

さきほどの「作法や記号をアレンジして構わない」という記述と矛盾しているように受け取られては申し訳ないのですが、

角を矯めて牛を殺す

の轍を踏んではいけないということを理解しておいて欲しいのです。


繰り返しますが、DFDは対象業務のおおよそのイメージが理解できていればいいのです。

抽象的な表現になってしまいましたが、例えば5W1H(When,Where,Who,What,Why,How)が解れば上出来ですが、「誰が何をしている」のように主語、目的語、述語の3つだけが揃うだけでもいいのです。

書き方の説明の中で、

DFDでは「誰が」を書かない/書けない

と記述したものも時折見掛けますが、そんなことはありません。多くの場合「誰が/どこが」は重要な情報なのです。






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




              <Time Slip>
           ☞ 前回


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


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

テーマ : 日々のつれづれ - ジャンル : 日記

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


「敵を知り、己を知れば、百戦危うからず」という格言が、プロセスバリュー・エンジニアリングにも通じるという話をしました。
今日はその続きです。
・・・・・

敵を知るということは、よく言われる言葉では「現状把握」というものが当てはまります。

ただ、把握だけしてもアクションにつながらないので、把握した結果を分析するところまですることが重要です。

分析までを含めて「現状把握」と呼んでもいいし、もっと明示的に「現状分析」と呼んでも構いません。

PVEでは後者、すなわち「現状分析」という呼び方で現状の把握から分析までを含めています。


現状分析の良し悪しで、その後の活動が大きく左右されます。
通常はそこで発見されるもしくは共通認識される事実によって、活動の方向性が決まるからです。


現状を把握するためには、対象となる業務に携わっている人たちからいろいろ聞かせてもらわなくてはいけません。
資料も重要ですが、生の声をきちんと拾い上げないと本質的な部分が見えてきません。

なので生の声を聞くことが非常にキーポイントとなるのですが、そこが結構難しいのです。

難しい理由の1つに、聞かれる側の人たちがうまく言葉で言い表わせないケースがあります。
普段何となく感じていることでも、いざ人にきちんと説明しようとすると相応しい言葉が浮かんでこないようです。

また、「こんなこと言ったらまずいよな」みたいに感じるのでしょう、知らず知らず防衛的な姿勢となって言葉を濁してしまうこともあります。

そういったハードルを乗り越えないと、重要な事実を聞かせてもらえることができなくなるのです。




(続きはこちらへ・・・)


              <Time Slip>
           ☞ 前回   ☞ 第1話 





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


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

テーマ : 日々のつれづれ - ジャンル : 日記

データフローダイアグラムの使い方(第1話)


データフローダイアグラム(Data Flow Diagram)の話題を結構取り上げてきました。DFDとかデータフロー図ともいいますね。

DFDを使い始めてもう20年以上経ちましたが、いろいろな場面で役に立ってきてくれました。

DFDは一粒で2度も3度もおいしい、とても応用の利く手法です。

時々思い出して、このデータフローダイアグラムの使い方を振り返ってみたいと思います。
まず今日はその第1話。
・・・・・


DFDはいろいろな観点で描かれます。

それはこの手法を使う人がどのような思いで使うかにより色付けされるからです。

業務改革者、業務管理者、システムエンジニア、プログラマー、経営スタッフ・・・

立場や役割により興味や関心が違ったり、普段身についている発想方法が異なるからです。

もちろん、うまい/下手 はあるでしょう。

過去、そんな事に触れたこともありましたね。
    ※ 「システム屋にはDFDが描けない?」

しかしそう言うことと違って、手法の使い手によって色が変わるのです。


色が違っていても、適正にできあがったDFDは、その後でいろいろな加工ができます。

例えば機能分解して、業務の機能が関連している、もしくは目的を同じくする一連の作業の塊に編集した機能指向のDFDに再構成することができます。

また、組織で層別して組織毎のDFDにしたり、コンピュータシステムに着目して各システムというまとまりで再構成した実態指向のDFDに描き直すこともできます。


それだけで、随分見た目の印象も変わります。

目的に合わせて再構成するというのもDFDの活用方法のひとつです。




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






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


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

テーマ : 日々のつれづれ - ジャンル : 日記

プロフィール

sugimotom

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

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

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

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