DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 竹内博樹の記事一覧 > 【第20回】どのような業務・システムを実現するのか? IT化の構想・企画段階における“What”を明確にする。


【第20回】どのような業務・システムを実現するのか? IT化の構想・企画段階における“What”を明確にする。


< 前回 | 目次 | 次回 >

前回のメルマガでは、IT化の構想・企画段階における“要求の取りまとめ(Why)”、つまり何のためにこの企画を計画し、実施する必要があるのかを明確にすることについてお伝えしました。

 この“要求の取りまとめ(Why)”では、

  • トップダウン、ボトムアップ両面から新業務・システムに対する要求(何のために必要なのか)を取りまとめる。
  • 実現を目指す「あるべき姿」が、どのような効果をもたらすのかを明らかにする。

ことを目的としたフェーズでした。またこのフェーズを通じ、IT化の構想・企画段階の最終成果物であるシステム企画書の中で、次の目次に相当する部分の記載が出来ます。

1. 方向性の確認
1.1 背景と目的
1.2 ビジネス上の課題
1.3 対象範囲/前提事項
2. 業務・システムの現状
2.1 現行業務の主な機能と流れ
2.2 現行業務の主なデータ
2.3 現行システムの構成と資産
2.4 現行業務およびシステムの問題点
3. 改善案の検討
3.1 重要成功要因
3.2 要求とソリューション

さて“要求の取りまとめ(Why)”が終わったら、次は“業務・システムの概要定義(What)”を行います。つまり今後の業務の概要、必要となる役割や組織、情報システムの構造、現状からの移行を検討し、その実現性や効果を確認することで“どのような業務・システムを実現するのか?”を明確にします。

 その定義を行うためには、下図の“2.業務・システムの概要定義”に書かれたプロセスを実施します。

takeuchi_chart110208

 その内容は次のとおりです。

  1. 新たな業務プロセスやそこで必要となるデータを明らかにし、今後の業務の基盤となるモデルを作成します。(2.1業務プロセスと概念データのモデルを作成する)
  2. 1の検討と並行し、新業務の運用を実施することを想定し、体制と各組織での役割を明確にします。(2.2業務運用時の体制を定義する)
  3. 1,2を実施した上で、配置や負荷分散を検討の上、全体として整合の取れたシステムの構造を設計します。(2.3技術的なアーキテクチャを定義する)
  4. その後に、現行の業務・システムから新たな業務・システムへ移行するための業務・システムを変更するにあたっての影響と対応を検討します。(2.4移行を検討する)

 このフェーズを進めるために大切なこととして、4点挙げられます。

  • 価値の具現化
    -このシステムを構築することによるメリットを明らかにする。
    -システムを「見える化」することにより、関係者が求めている価値を明確化する。
  • 価値の実現にこだわる
    -実現性とメリットにこだわる。
    -本当に業務が回るのか。
  • スピード感
    -無駄な作業に時間を使わない。
    -早期に具体的なソリューション候補を示す。
  • 役者を揃える
    -“考えるチーム”を創る。
    -パートナーを活用する。

 なおこの“業務・システムの概要定義(What)”で作成する、システム企画書の目次例は次のとおりです。

4. 新業務・システムの概要
4.1 主要な業務プロセス
4.2 主要なエンティティ
4.3 システム化の領域
4.4 新業務・システムにおける役割
4.5 サービスレベルの定義
4.6 新システムのアーキテクチャ構成
4.7 業務への影響と対応策
4.8 他システムへの影響と対応策

(追伸)
東証一部上場のユーザ企業の情報システム部門で、人材育成をご担当されている方とお話しをする機会がありました。その方曰く、「弊社はシステム会社ではないため、情報システム部門に配属されるメンバーも数年~十数年、現場の営業等を担当してきた人が突然システム部門に配属されるケースが多い。よって経営から同部が求められている“ITガバナンス”を実践しようとしても、経験やスキルが追いついていない。またそのため、システム子会社から挙がってくる成果物に対する検収も、正しく出来ていないケースの方が多い。」とのことでした。
一方で同システム子会社の方も先だってお話しをする機会がありました。すると「親会社の情報システム部門は、システム開発においては機能していない。よって自分たちが直接ユーザと交渉しながら、システム構築をしている。」とのことでした。
過去企業のIT化を、システム子会社ではなくユーザ企業の情報システム部門の方々が主導してきた時代を担ってきた方々が、現役を引退される近年、今回のようなケースが増えてきたように思えます。
ユーザ企業の情報システム部門が存在する意義は? 企業にとっての価値は?
ユーザ企業の情報システム部門から有識者が居なくなる前に、早急にあり方を真剣に考えなければならない、待った無しの時期が来ている、そんな気がしています。

< 前回 | 目次 | 次回 >

| 目次

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
竹内博樹
1991年 筑波大学卒業後、三和銀行のシステム子会社である三和システム開発株式会社(現、三菱UFJインフォメーションテクノロジー株式会社)入社。同社にて銀行業務のリテール、法人、国際の各分野において、大規模プロジェクトにおける企画・設計・開発に、主にプロジェクトマネジメントを実行するマネージャとして携わる。また開発後の保守にも従事するなど、幅広い業務でマネージャとして活躍。2004年より当社にて、大規模プロジェクトにおけるPMOの運営およびプロジェクトマネジメント支援や、IT部門の組織改革等、幅広くコンサルティングを手がける。 保有資格:情報処理 プロジェクトマネージャ、PMPほか。PMI会員、PM学会会員。

Recent Entries最近の記事