「現場の知恵」を蓄積・活用する「考動知図」

「現場の知恵」を積上・活用する「考動知図」(こう・どう・ち・ず))

TEL.025-531-1151 

〒942-0036 新潟県上越市東中島1943-91

  hidetoshi@teoria.co.jp
使えない情報システムが開発されてしまう体験

使えない情報システムが開発されてしまう体験

このエントリーをはてなブックマークに追加

jyoho

使えない情報システムが開発されてしまう体験

導入してから業務内容が打ち合わせと違うことが発覚します。

私は、もともと中小企業に情報システムを
導入するSE(システムエンジニア)でした。
これまで、たくさんの企業のシステム開発にたずさわりました。

そこでの体験です。

打ち合わせ内容に忠実にシステムを開発しました。
でも、導入すると....『違うんです!』と言われます。

  『打ち合わせ通りですよね』と言うと、
  『そうは言ったが、実は違うんだ』となります。

打ち合わせ記録にも書かれています、ハンコもあります。
でも、違うのです。
担当者は、逃げます。

そのままでは運用できませんので、システムの改造が必要です。
はじめから、そのように作っていれば改造コストはかかりません。
もちろんシステムの稼動は遅れます。
導入のテストも余分にかかります。

システムの改造は、開発側・導入側の両方に大きな負担となります。

どうしたら?、望んでいるコトでシステム開発ができるのか?

社内の業務の仕組みがあやふやなままシステム開発をして、
コンピュータの導入をしている場合が多いのです。
導入して上手くいかない体験の多くはそこにあります。

その問題を解決するには、
その会社の”ビジネスの仕組み”を明確にする必要があると痛感しました。

そこで、効果があったのは「図解」です。

聞いたことを図解すると書けないところが出てきます。
部分的に空白になります。
そこを尋ねます。

図解の空白が埋まると、整合性の不備が見えます。
そこを尋ねます。

それを繰り返すと、
仕事の仕組みの全体像が見えてきます。

だんだん経験を積んでくると、
テストや導入後に、どの部分に変更を要求されるか
予測できるようになりました。

打合せでユーザー担当者が「A」と言うのですが、
私は「B」に、ひっくり返るだろうと予測できます。
そこで、「B」ではないですか?
「A」で良いですか?
と念を押して確認します。

でも「A」だと主張される場合があります。

その時は、システムの設計は「A」から「B」に
スイッチ一つで切りかわるようにします。

そして、導入テストで「B」となったら?

こう言います。
 困りました。
 この段階で大きな変更です。
 「B」ではないですか?と何度も確認しました。 
 打合せ記録もあります。
 でも、修正が必要なんですね!
 これに間違いありませんか?
と、言い..
困った風にして会社に戻ります。

でも、どっちでも対応できる設計にしてあるので、
すぐに修正できます。

そして、そこでは追加見積もりをしません。
でも、他に修正部分がでたら?
あそこで泣いたんだから、こっちは追加お願いします。
と言うと受容れてくれます。

そんなことをしながら..

そこでビジネスの体系を明確にすることを意識するようになりました

経営者の考える”仕事の仕組み”を
図解で判りやすく表現するということに行きつきました。

« »

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA