私の体験の図解 目指しているのは!「仕事を分解して打つ手を明らかにすること!」:ビジネス・デザイナー 目指しているのは!「仕事を分解して打つ手を明らかにすること!」  図解メソッドで、働く手応えと成果を実現するビジネスモデルを設計するテオリア 図解メソッドで、働く手応えと成果を実現するビジネスモデルを設計するテオリア
自分で体験したことを図解で、分かりやすくしています
システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのJHOME > 会社の問題点を整理すると! > システムが業務に合わない・使えない!

システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのJシステムが業務に合わない・使えない!(トラブル発覚)
システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのテオリア コンピュータが業務に合わないと悩んでいませんか?

せっかく開発したシステムが業務に合わないと...
業務の効率が悪くなり、使わないで終わることになります。

新規事業を立ち上げようとしている場合は大きな問題です。

新規事業の場合は分析する業務がありません。
モデルとなる事業や会社があれば良いのですが、
全く新しい事業をゼロから立ち上げる場合は、
社長も幹部も業務の具体的な内容まで頭に描いていません。

そして、その状態でSEに丸投げしてしまうと...
担当SEの過去の知識・経験の範囲で設計します。
それで大丈夫なのでしょうか?

ビジネスの構造が明確でないままに開発したシステムは、
その新規事業の運用で使えるのでしょうか?
上手く運営できないとしたら...
その新規事業の成功は難しいものとなります。

新たに作りなおの開発を考えても...
2重に開発費を捻出することは難しいのが現実です。

システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのテオリアそして、新規事業は終焉に向かいます!

システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのJシステムが業務に合わない・使えない!(依頼者側の言い分)
システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのテオリア 依頼側の立場から考えると

ソフト会社に依頼したシステムの内容が...
期待したレベルになっていないという不満があります。
導入してから使えないことが発覚するのです。

その不満を整理すると
 ●導入したシステムが満足に動かない
   できるはずの機能に不備や力不足がある
   何度も連絡するが、言い逃れをされて先延ばしになる
 
 ●開発者が納得できる対処をしてくれない
   開担当者が替わった、実情が引き継がれていない
   あやふやな態度や小手先の対処しかしてくれない
  
 ●満足な開発資料がない
   開発したSE本人にしか対処できない、実は本人も??
  業務とシステムの全体がわからない、確認できない

「木を見て森を見ず」のようにシステムができているのでは?

依頼側の言い分:中小企業のシステム導入時の困った..そして結果は:ビジネス・アーキテクトのテオリア
せっかく高いお金を使ったのに使えないのでは困る

システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのJシステムが業務に合わない・使えない!(発注者側の言い分
システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのテオリア 開発側の立場から考えると

経営者や担当者と何度も打ち合わせをして..
システムを開発し導入し運用が始まると....
  『ここが違う!』と言われます
  『その部分は、打ち合わせ通りですよね』と言うと
  『そうは言ったが、実は違うんだ』となります
議事録にも書かれています、ハンコもあります。

担当者はうそを言ったつもりはありません。
でも、業務の実態と違うのです。

細かく議事録を作って、ハンコをもらっても...
でも、このようなことは起こるのです。

●開発者の立場で考えると
  導入企業の担当者が責任ある発言をしてくれない
  見積り時点では無かった条件や項目がどんどん出てくる
  機械を購入する感覚で金額をたたくだけ!
  社長でないと話が決まらない

追加・変更の繰り返しが増えると満足なシステムにならない。

開発側の言い分:中小企業のシステム導入時の困った..そして結果は:ビジネス・アーキテクトのテオリア
これでは金額の範囲で損をしない程度で..となる

システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのJシステムが業務に合わない・使えない!(その結末は、どうなるか!
システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのテオリア 結局はどうなるか...

開発したソフト会社を一方的に責めても解決しません。
発注者の権力を行使して、開発会社の社長を呼びつけて
 ●一方的にシステムの不備を挙げて...
 ●開発会社の社長を、謝罪させても...
何も解決しません。事態はかわりません。

依頼した会社の社長・幹部は開発会社が悪いと言います。
確かに、その言い分には間違はありません。
でも、依頼側には何の問題もなかったのでしょうか。
実は、開発側が一方的に悪い場合は少ないのです。

一方的に責任追及するとどうなうでしょうか?
開発側も、営利を追及する企業です。
担当者も、会社に帰れば上司に責められるサラリーマンです。
依頼側、開発側が、どのように取り組んで解決するかという
視点なしに責められたら...
仕方ありません...
  「言われたことを無難にこなす」
  「表面上、責任追及をかわすことを主に考えます」
となると...
それは、システムの完成度や価値を高める動きではありません。

結局は!!:中小企業のシステム導入時の困った..そして結果は:ビジネス・アーキテクトのテオリア
どっちにとっても不満と不利益が残ったままで終わります

システムが業務に合わない・使えない!:会社の問題点を整理すると!:図解で描く仕事の設計図でビジネスの仕組みを創る:ビジネス・アーキテクトのJHOME > 会社の問題点を整理すると! > システムが業務に合わない・使えない!
会社概要経営理念代表者プロフィール経営に役立つ言葉集プライバシーポリシー著作権メール連絡
有限会社 テオリア 〒942-0036  新潟県上越市東中島1943-91 電話番号 025-531-1151 FAX番号 025-531-1152
このサイトは仕事の図解屋:テオリアが管理しています。ホームページに関するご意見、ご質問はこちらまでお願い致します。
Copyright(C) by Teoria ltd. All Rights Reserved.