top of page

システム導入に於ける成功への秘訣

Ⅰ.失敗の原因

失敗の原因

 ゴールの認識がバラバラ

 ステムをITベンダに丸投げ

業務を変更せずPKGシステムを強引に導入しようとする

 業務機能に必要なシステム機能(特にPKGにおいて)が欠落

     言い換えれば⇒使える機能がほとんどなく、使えない、利用しない機能が沢山ある

現場担当者の声を聴きすぎ(現状にこだわる)
​ 
  言い換えれば⇒自分にとっての都合は、他部門・経営層にとっての不都合

❻ ベンダ選定・PKG選定で失敗

​      い換えれば⇒しっかりした提案書がなく、カタログ資料説明で判断

システム・PKGが想定している業務モデルと顧客が構築したい業務モデル機能と

 比較せずにPKGを構成しているプログラム機能と比較しているために、

 業務運用面の検証ができず、使えないシステムになってしまう

現場担当者の要望を聞きすぎて、コストアップ・納期延伸が起こり、結果として

     投資対効果割れとなる

​❾ 目的・手段の勘違いが関係者の不幸を招く

     ⇒目的:ビジネスをよくする⇒そのために:どのようなシステムを作るべきか!

そして、システム構築に於いて注意すべきことが3つある

1)誰にシステム作りを任せるか!

2)システムより先に考えることは!

3)何故、こんなに計画がぶれるか!

➓ 企業のIT化はSEに任せるな!

⇒投資対効果は!/効率・合理化中心で顧客サービスが犠牲になる!

/営業と経理部門の対立!(管理中心で営業活動の足かせに)

更に現場の担当者で判断がつかない事柄は経営者の判断が重要!

⇒プロジェクトの問題状況は絶えず経営者に上げさせる!

⇒業務部門から見て「何のシステム」を作っているか!をわかるように、

 また理解が得られるようにする

「3社の調整をする役割はPMにある」、PMの役割を間違うな!

「IT部門+ベンダ」は作る人!

    経営者及び業務部門は、それで会社は良くなるか!を目的に参加

    ⇒Why(必要性は「現状の課題・問題」)

    ⇒How(解決策は業務モデル)

    ⇒What(実現策は、ターゲット業務システム)

業務部門

経営

PM

IT部門

失敗しないための要件

Ⅱ.失敗しないための要件

Why:必要性の証明⇒現状・課題の列挙とどこまで解決されれば成功か!

How:将来ビジョン含めて解決の方向性を策定そしてプロジェクトの基本計画

       解決の手段として、システム・業務ルール(業務フロー図・運用基準など)・    

       システム/業務変更導入・運用体制・投資対効果

What:そのためにどのようなシステムを作るか?/どの様に作るか?
                   /誰に作らせるか?/期間・費用は?

                 ⇒パートナー評価?/PKGあるいはスクラッチ開発選定/参加・参画する要員スキルは?

提案イメージ共有:PKGプロトタイプでの業務運用模擬実験あるいは

          提案書で表現させている業務フロー図による業務検証

提案書に表現されている現行業務フロー図及び課題・問題解決を想定した提案業務フロー図を基に業務設       計工程で業務を固める。そしてシステムへの要件、業務変更要件、運用体制組織・役割変更要件、

     その他投資対効果を検証

Ⅲ.重要工程である業務設計とシステム設計

上記で作成した業務設計書の業務要件をシステム開発者は業務設計者と共有し、
そして当初の経営及び業務問題・課題が解決されるか?を意識して、次工程である
システム設計(要件含む)を上流工程の業務設計者とシステム設計者が一緒に設計する。

重要工程である業務設計とシステム設計

システム設計の重要ポイント 
ⅰ)誰でもが操作できる
 ⅱ)業務運用との重要な接点であるコード設計・マスタ設計は完ぺきか? ⅲ)データの移行は大丈夫か? ⅳ)本稼働テスト計画(時期・体制・対象範囲・データ確保)は、出来たか? ⅴ)バックアップとリカバリ処理(機械は必ず止まる。障害を起こす。壊れる。)ⅵ)予算・工期・プロジェクト体制(品質管理含む)は大丈夫か?ⅶ)要員スキル・お客様体力に応じて積算されているか?ⅷ)お客様の体力に合わせて本稼働ステップ切りしているか?ⅸ)システム運用維持体制は大丈夫か!?ⅹ)意思決定権者を巻き込んだプロジェクト推進会議体は大丈夫か?

注意すべきこと
   ⅰ)業務設計で全体の30%の工数を見込む(従来は軽視されてきた)
   ⅱ)業務設計所要期間の目安として、大手企業を想定して
     販売物流システムで8か月
     生産管理と財務会計は各々5か月
   ⅲ)社内で100%決められる業務と取引先の影響を大きく受けるパートを明確に
     区分けして優先順位や仕様の決め方に注意すること

Ⅳ.教訓

教訓

「ゴール」は迷った際の判断を下す価値観
      ⇒「何のため」のゴールなのか?
   EX,同じ顧客でも工場単位に業務が異なることがあるが、
         処理のタイミング(リアルタイムか日時バッチなど)は共通に価値を持つ

「素晴らしいツールが手に入れば」症候群に注意
   システムツールは何もしない。どの様に利活用するかが重要!

  目的をもって現状調査をする
     ⇒ざっくり調査して「大きな課題・問題」を特定化、そして課題・問題を深堀して、
        課題・問題発見型の「問題ネットワーク図」を作成し、実現に向けた正しい原因を
        発見、見つけ出し適切に解決する
      ちなみに、現行システムを調査するに当たり、現行システムがどこまでカバーして
        いるか?を洗い出す棚卸型もある。現行システムを大幅に生かし活用する際に便利

  業務設計~システム開発工程の中で使用する七つ道具
   ⅰ)業務設計書式
     ・現行業務フロー図
     ・業務部門別、役割別、作業内容
   ⅱ)システムフォーマット
     ・全体システム構成図(ハード・ネットワーク・DB関係)
     ・システムモジュール構成図(業務システム関連)
       ・システム一覧
     ・I/P一覧
     ・処理チャート図
     ・マスタ/ファイル一覧
     ・マスタ項目一覧
     ・コード体系

  全工程で立ち上げから本稼働・メンテナンスが落ち着くまで
     ・問題・課題一覧

以 上

bottom of page