山田氏：さて、来週の経営会議に向けて、IT戦略企画書と整理したいのだが、
どこからはじめればよいのだろうか。
中川氏：そうですね。資料は十分出来ていると思いますのでどうまとめていくか
ですね。
上野氏：今年発表された新PGLのITCプロセスを参考にしてみたらいかがでしょ
う。
えーと、ITCプロセスではIT戦略企画書でIT化のテーマを取り上げ、
IT戦略実行計画書として、後続フェーズの実施方針を作成しています。
山田氏：来週の会議用としてはIT戦略企画書で良さそうです。順番に項目を整理
してみましょうか。
中川氏：まず、経営戦略との関係を抑える必要がありますね。
山田氏：そう、経営戦略との整合性。そのためには、IT戦略テーマに対する
「経営課題と解決テーマ」、IT化すべき領域の記述としての「IT領域
戦略課題」が必要だし、結論としての「IT戦略テーマと方針」を最初に
まとめたいね。
中川氏：なるほど、結論を先に書いて、その後に裏づけを記述すると言うこと
ですね。
そうすると、解決テーマの裏づけとして、IT環境に対する世の中の流れ
とも合致していることをサマリーしましょう。「IT動向と先進事例」辺
りでいかがでしょう。
上野氏：外的IT環境の裏づけが記述されたら、内部のIT環境ですから、先日討議
した「現行とあるべきビジネスプロセスモデルのギャップ分析」を記述
しましょう。プロセス改革のためのIT戦略の基礎データですね。
山田氏：そうすると、次期システムが見えてくる。「IT化ビジョンと次期シス
テム」を項目として時期システムイメージを記述しよう。
詳細項目は・・・
上野氏：それはCOBITの７つの基準から導いた「IT化の目的と達成目標」で
しょう。
中川氏：俺にも少し発言させてよ。システムイメージとしては、新しいIT環境を
反映した「新業務プロセスイメージ」とIT 動向を反映した「新IT環境
イメージ」が必要ですね。
山田氏：イメージでよいのかな？
私 ：調達フェーズのITベンダーからの提案の選定に基づき、最終的な次期
システムが確定されますので、ここではイメージと言ってもよいで
しょう。
山田氏：ここでのイメージと言っているのは、私どもでは・・・・（案）という
感じですね。調達フェーズを通して詳細に確定されていくことになる
ということですね。
その後の項目は「IT化ビジョンと次期システム」の具体化としての「新IT
システムのプロジェクトと優先順位」、「ITシステム導入スケジュー
ル」、「推進組織体制」を記述すれば実施イメージがつかめますね。
それぞれの詳細項目は、えーと・・・
上野氏：「新ITシステムのプロジェクトと優先順位」では全社システムでいくつ
かのプロジェクトが計画されますので「プロジェクトの目的と要件の
定義」、「プロジェクトの優先順位」でしょう。「ITシステム導入スケジ
ュール」には「全体概要スケジュール」、「プロジェクト別概要スケジュ
ール」、「要員/資源調達/資金計画」の項目を記述すればよいでしょう。
中川氏：「推進組織体制」では「プロジェクト実施体制」と「プロジェクト
モニタリング体制」辺りですか。
山田氏：それでよいでしょう。最後に「投資対効果」として、「ITシステム投資
（一時費用、運用費用）」と「ITシステム効果」を記述して、IT戦略企画
書としましょう。
・・・・・・・（作業）
私 ：どうやらIT戦略企画書が出来上がりましたね。
山田さんの役割はここまでの様ですが、後続のプロジェクト推進メンバ
ーへこの企画書を後続フェーズで具体的に実施するための実施方針を
まとめた「IT戦略実行計画書」まで作成することが必要です。
山田氏：そうですね。了解しました。漸く、このプロジェクトも1区切りつき
ました。ご苦労様でした。打ち上げやりましょう。
みんな：賛成！！ 山田さんのおごりで。
山田氏：いいですよ。喜んでご馳走させていただきます。
第１１１回はここで終了します。
今回は「IT戦略企画書」として、IT戦略企画書の構成を討議しました。
今回で、山田氏、中川氏、上野氏を中心としたIT戦略策定プロジェクトは終了です。
どこからはじめればよいのだろうか。
中川氏：そうですね。資料は十分出来ていると思いますのでどうまとめていくか
ですね。
上野氏：今年発表された新PGLのITCプロセスを参考にしてみたらいかがでしょ
う。
えーと、ITCプロセスではIT戦略企画書でIT化のテーマを取り上げ、
IT戦略実行計画書として、後続フェーズの実施方針を作成しています。
山田氏：来週の会議用としてはIT戦略企画書で良さそうです。順番に項目を整理
してみましょうか。
中川氏：まず、経営戦略との関係を抑える必要がありますね。
山田氏：そう、経営戦略との整合性。そのためには、IT戦略テーマに対する
「経営課題と解決テーマ」、IT化すべき領域の記述としての「IT領域
戦略課題」が必要だし、結論としての「IT戦略テーマと方針」を最初に
まとめたいね。
中川氏：なるほど、結論を先に書いて、その後に裏づけを記述すると言うこと
ですね。
そうすると、解決テーマの裏づけとして、IT環境に対する世の中の流れ
とも合致していることをサマリーしましょう。「IT動向と先進事例」辺
りでいかがでしょう。
上野氏：外的IT環境の裏づけが記述されたら、内部のIT環境ですから、先日討議
した「現行とあるべきビジネスプロセスモデルのギャップ分析」を記述
しましょう。プロセス改革のためのIT戦略の基礎データですね。
山田氏：そうすると、次期システムが見えてくる。「IT化ビジョンと次期シス
テム」を項目として時期システムイメージを記述しよう。
詳細項目は・・・
上野氏：それはCOBITの７つの基準から導いた「IT化の目的と達成目標」で
しょう。
中川氏：俺にも少し発言させてよ。システムイメージとしては、新しいIT環境を
反映した「新業務プロセスイメージ」とIT 動向を反映した「新IT環境
イメージ」が必要ですね。
山田氏：イメージでよいのかな？
私 ：調達フェーズのITベンダーからの提案の選定に基づき、最終的な次期
システムが確定されますので、ここではイメージと言ってもよいで
しょう。
山田氏：ここでのイメージと言っているのは、私どもでは・・・・（案）という
感じですね。調達フェーズを通して詳細に確定されていくことになる
ということですね。
その後の項目は「IT化ビジョンと次期システム」の具体化としての「新IT
システムのプロジェクトと優先順位」、「ITシステム導入スケジュー
ル」、「推進組織体制」を記述すれば実施イメージがつかめますね。
それぞれの詳細項目は、えーと・・・
上野氏：「新ITシステムのプロジェクトと優先順位」では全社システムでいくつ
かのプロジェクトが計画されますので「プロジェクトの目的と要件の
定義」、「プロジェクトの優先順位」でしょう。「ITシステム導入スケジ
ュール」には「全体概要スケジュール」、「プロジェクト別概要スケジュ
ール」、「要員/資源調達/資金計画」の項目を記述すればよいでしょう。
中川氏：「推進組織体制」では「プロジェクト実施体制」と「プロジェクト
モニタリング体制」辺りですか。
山田氏：それでよいでしょう。最後に「投資対効果」として、「ITシステム投資
（一時費用、運用費用）」と「ITシステム効果」を記述して、IT戦略企画
書としましょう。
・・・・・・・（作業）
私 ：どうやらIT戦略企画書が出来上がりましたね。
山田さんの役割はここまでの様ですが、後続のプロジェクト推進メンバ
ーへこの企画書を後続フェーズで具体的に実施するための実施方針を
まとめた「IT戦略実行計画書」まで作成することが必要です。
山田氏：そうですね。了解しました。漸く、このプロジェクトも1区切りつき
ました。ご苦労様でした。打ち上げやりましょう。
みんな：賛成！！ 山田さんのおごりで。
山田氏：いいですよ。喜んでご馳走させていただきます。
第１１１回はここで終了します。
今回は「IT戦略企画書」として、IT戦略企画書の構成を討議しました。
今回で、山田氏、中川氏、上野氏を中心としたIT戦略策定プロジェクトは終了です。
今日は構築する情報システムのライフサイクルを5年と定めたことから、IT動向の
調査の議論になっていました。
中川氏：新ITCプロセスガイドラインを見ていましたら、ITに関する外部環境調査
としては、業務プロセスに関するベンチマークリファレンスとITインフ
ラ動向調査による最適ITの選択が必要と書いてありましたよ。
山田氏：今日はITインフラ動向にはなしの焦点を当てよう。何か、良い参考資料
が無いかなあ。
上野氏：そうですね。私も中川さんと同じで、ガイドラインを見ていましたら、
最適ITインフラの選択のリファレンスとしてTRM、SRMがありました。
中川氏：なんですか？そのTRM、SRMって。
上野氏：私も調べてみましたら、経産省がEA(Enterprise Archtecture)による
業務・システム設計のために公表している参照モデルで、後続の業務・
システムを構築する際に検討しなければならない事項を標準化し参照でき
るようにしたものらしいです。TRMはTechnical Reference ModelでSRM
はService ｃｏｍｐｏｒｎｅｎｔ Ｒｅｆｅｒｅｎｃｅ Ｍｏｄｅｌと
言われ、TRMはハードウエアやソフトウエアのリファレンスそしてSRMは
SOA（Service Oriented Approach）による業務サービスコンポネントの
リファレンスです。SRMはサービスコンポーネントの考え方ですが、TRMは
具体的なリファレンスが作られています。
（http://www.meti.go.jp/policy/it_policy/ea/gainen/model/trm/3.html）
中川氏：どんな構造になっているの？
上野氏：TRMではそれぞれの技術を「現在の技術」、「標準」、「将来の技術」の
3段階に分けて、システムのライフスパンに合わせて選択できるようにし
ています。
例えば、分散コンピューティングでは現在の技術を「CORBA、HTTP」、
標準を「HTTP」、将来の技術を「グリッド」と表示しています。
中川氏：使い方としては、長期のライフスパンのシステムの場合、HTTPを採用
するが、グリッド（アクセスグリッドと思われる）への移行も十分考えて
おく必要があると言うこと？
上野氏：それで良いと思います。
山田氏：TRMやSRMはIT領域の外部環境分析のための情報共有システムですね。
良い仕組みです。
私 ：これらのリファレンスはEAを用いた行政の「業務・システム構築の最適
化計画」において使用されています。現在は先進事例として米国国防総省
のモデルが使用されていますが、電子政府の最適化計画が進むにつれて、
より具体的なリファレンスになっていくと思います。
山田氏：了解です。TRM、SRMも参考に出来るところがあれば、積極的に参照して
行きましょう。
第１０７回はここで終了します。
今回は「IT領域外部環境分析−リファレンスモデル」として、EAにおけるTRM、
SRMリファレンスモデルの概要をご紹介しました。
次回は、このプロジェクトの最終回で「IT戦略企画書」を取り上げます。
調査の議論になっていました。
中川氏：新ITCプロセスガイドラインを見ていましたら、ITに関する外部環境調査
としては、業務プロセスに関するベンチマークリファレンスとITインフ
ラ動向調査による最適ITの選択が必要と書いてありましたよ。
山田氏：今日はITインフラ動向にはなしの焦点を当てよう。何か、良い参考資料
が無いかなあ。
上野氏：そうですね。私も中川さんと同じで、ガイドラインを見ていましたら、
最適ITインフラの選択のリファレンスとしてTRM、SRMがありました。
中川氏：なんですか？そのTRM、SRMって。
上野氏：私も調べてみましたら、経産省がEA(Enterprise Archtecture)による
業務・システム設計のために公表している参照モデルで、後続の業務・
システムを構築する際に検討しなければならない事項を標準化し参照でき
るようにしたものらしいです。TRMはTechnical Reference ModelでSRM
はService ｃｏｍｐｏｒｎｅｎｔ Ｒｅｆｅｒｅｎｃｅ Ｍｏｄｅｌと
言われ、TRMはハードウエアやソフトウエアのリファレンスそしてSRMは
SOA（Service Oriented Approach）による業務サービスコンポネントの
リファレンスです。SRMはサービスコンポーネントの考え方ですが、TRMは
具体的なリファレンスが作られています。
（http://www.meti.go.jp/policy/it_policy/ea/gainen/model/trm/3.html）
中川氏：どんな構造になっているの？
上野氏：TRMではそれぞれの技術を「現在の技術」、「標準」、「将来の技術」の
3段階に分けて、システムのライフスパンに合わせて選択できるようにし
ています。
例えば、分散コンピューティングでは現在の技術を「CORBA、HTTP」、
標準を「HTTP」、将来の技術を「グリッド」と表示しています。
中川氏：使い方としては、長期のライフスパンのシステムの場合、HTTPを採用
するが、グリッド（アクセスグリッドと思われる）への移行も十分考えて
おく必要があると言うこと？
上野氏：それで良いと思います。
山田氏：TRMやSRMはIT領域の外部環境分析のための情報共有システムですね。
良い仕組みです。
私 ：これらのリファレンスはEAを用いた行政の「業務・システム構築の最適
化計画」において使用されています。現在は先進事例として米国国防総省
のモデルが使用されていますが、電子政府の最適化計画が進むにつれて、
より具体的なリファレンスになっていくと思います。
山田氏：了解です。TRM、SRMも参考に出来るところがあれば、積極的に参照して
行きましょう。
第１０７回はここで終了します。
今回は「IT領域外部環境分析−リファレンスモデル」として、EAにおけるTRM、
SRMリファレンスモデルの概要をご紹介しました。
次回は、このプロジェクトの最終回で「IT戦略企画書」を取り上げます。
今日はIT戦略策定のためのギャップ分析です。中川氏がまず提案です。
中川氏：ギャップ分析と言うには分析のための切り口というか、視点みたいなも
のがないとギャップが見えないよね。
上野氏：目標ビジネスプロセスはIT化目標である7つの情報基準の要件に基づいて
作成されてます。このビジネスプロセスを実現するためには「ITの機能
面」、「導入技術面」、「運用管理面」のギャップを捉えていかなけれ
ばなりませんね。
中川氏：何故、その３つの観点になるの？
上野氏：と言うのは、業務機能は変わりませんが、ビジネスプロセスを短縮した
り、集約化できるのはIT機器を使ったシステム機能ですね。そうすると
現在使っていないIT 機器やシステム機能が出てきますので、そのギャッ
プを押える。次にこれを導入し、運用していく業務機能を抑える。
この機能はIT ガバナンスと言われるCOBITの4つのIT化業務機能のギャッ
プを見ていけば良いと思います。
中川氏：ちょっと、まとめさせてください。IT機能面と言うのは目標ビジネス
プロセスに合わせるためにモバイルアクセスやERP等のIT機能環境のギャ
ップですね
上野氏：そうです。
中川氏：IT導入技術面、運用管理面とはCOBITの４つの業務プロセスのことと考
えて良いですか
上野氏：良いですね。ただし、現在「企画/計画」を進めていますので、この後の
プロセスである「調達・開発」が導入技術面、「デリバリー＆運用」と
「モニタリング」が運用管理面です。これらを実行するためのギャップ
です。
私 ：それで良いでしょう。追加しますと、このギャップはIT成熟度を考慮
したギャップなのです。その意味は、目標ビジネスプロセス、目標IT
環境は経営企画書の情報化テーマからのトップ−ダウン展開ですから、
IT成熟度と言う現状の能力を踏まえたボトムとのギャップ分析なので
す。
上野氏：IT成熟度は現行の運用成熟度を調査し、目標ビジネスプロセスを実践
するための能力目標としてのIT成熟度レベルになるのでボトムアップ
のためのギャップ分析と言うことですね。
私 ：そうです。上野さん、補足していただいて感謝！
中川氏：IT化を成功させるためには、調達・開発、運用、モニタリングの仕組み
づくりやステイクホルダーの教育・育成が必要ということですね。
私 ：その通りですね。目標としての育成レベルの設定が必要ですね。
山田氏：よし、7つの情報基準の目標とIT成熟度目標を基に3つの観点で、ギャッ
プ分析をしていこう。
・・・・・・・（作業）
第１１０回はここで終了します。
今回は「IT戦略策定-ギャップ分析」として、IT戦略策定-ギャップ分析の要件を
討議しました。
次回は、「IT 戦略企画書」を取り上げます。
中川氏：ギャップ分析と言うには分析のための切り口というか、視点みたいなも
のがないとギャップが見えないよね。
上野氏：目標ビジネスプロセスはIT化目標である7つの情報基準の要件に基づいて
作成されてます。このビジネスプロセスを実現するためには「ITの機能
面」、「導入技術面」、「運用管理面」のギャップを捉えていかなけれ
ばなりませんね。
中川氏：何故、その３つの観点になるの？
上野氏：と言うのは、業務機能は変わりませんが、ビジネスプロセスを短縮した
り、集約化できるのはIT機器を使ったシステム機能ですね。そうすると
現在使っていないIT 機器やシステム機能が出てきますので、そのギャッ
プを押える。次にこれを導入し、運用していく業務機能を抑える。
この機能はIT ガバナンスと言われるCOBITの4つのIT化業務機能のギャッ
プを見ていけば良いと思います。
中川氏：ちょっと、まとめさせてください。IT機能面と言うのは目標ビジネス
プロセスに合わせるためにモバイルアクセスやERP等のIT機能環境のギャ
ップですね
上野氏：そうです。
中川氏：IT導入技術面、運用管理面とはCOBITの４つの業務プロセスのことと考
えて良いですか
上野氏：良いですね。ただし、現在「企画/計画」を進めていますので、この後の
プロセスである「調達・開発」が導入技術面、「デリバリー＆運用」と
「モニタリング」が運用管理面です。これらを実行するためのギャップ
です。
私 ：それで良いでしょう。追加しますと、このギャップはIT成熟度を考慮
したギャップなのです。その意味は、目標ビジネスプロセス、目標IT
環境は経営企画書の情報化テーマからのトップ−ダウン展開ですから、
IT成熟度と言う現状の能力を踏まえたボトムとのギャップ分析なので
す。
上野氏：IT成熟度は現行の運用成熟度を調査し、目標ビジネスプロセスを実践
するための能力目標としてのIT成熟度レベルになるのでボトムアップ
のためのギャップ分析と言うことですね。
私 ：そうです。上野さん、補足していただいて感謝！
中川氏：IT化を成功させるためには、調達・開発、運用、モニタリングの仕組み
づくりやステイクホルダーの教育・育成が必要ということですね。
私 ：その通りですね。目標としての育成レベルの設定が必要ですね。
山田氏：よし、7つの情報基準の目標とIT成熟度目標を基に3つの観点で、ギャッ
プ分析をしていこう。
・・・・・・・（作業）
第１１０回はここで終了します。
今回は「IT戦略策定-ギャップ分析」として、IT戦略策定-ギャップ分析の要件を
討議しました。
次回は、「IT 戦略企画書」を取り上げます。
今日は目標ビジネスプロセスモデルの検討日です。山田氏が口火を切ります。
山田氏：あるべき姿である目標ビジネスプロセスモデルを作成するのだが、作成
するための要件を整理しておきたいのだが
中川氏：経営戦略を策定したときに、情報化テーマとプロジェクトの概算予算が
決まっていますね。現行業務プロセスの分析を行いましたので、その
ときの課題を改善したプロセスを作成すればよいのではないですか？
山田氏：それは現状課題改善プロセスとしては良いのですが、上野さんはどう思
いますか？
上野氏：あるべき姿のビジネスプロセスですから、中川さんのおっしゃるのも
含めて2つのことをまとめなければいけませんね。
１つは、経営企画書で作成された情報化テーマを情報化目標に変換する
ことです。
そうすることで、情報化の改革目標が設定できます。２つ目は現行業務
プロセス分析での現行課題と情報化テーマの改革目標を加えたビジネス
プロセス作成ですね。構造化設計を使ってまとめるとよいと思います。
私 ：そうですね、今回の情報化は複数の同種システムが存在しませんので、
DFDと構造化設計で良いでしょう。
ちなみに、複数の同種業務がある場合のシステム化ではEA（Enterprise
Archtecture）のガイドにあるようにDFD、業務プロセスの抽象化、構造
化設計を使用して行きますが・・・
http://www.meti.go.jp/policy/it_policy/ea/data/report/index2.html
中川氏：私のお客様で複数企業のシステムのASP化の話が来ているのですが、そん
なシステム化はEAに合うのですか？
私 ：合いますね。この企画書の作成が終わったら、EA適用設計をしてみまし
ょう。
話を戻して、上野さん、構造化設計の手順を説明いただけますか？
上野氏：分かりました。手短にやりましょう。作成手順は「現物理モデル」→
「現論理モデル」→「新論理モデル」→「新物理モデル」の順で、
「現物理モデル」は現行の業務プロセスで、現論理モデル設計は現行の
あるべきプロセス、「新論理モデル」は情報化テーマ要件を反映した
現論理モデル、「新物理モデル」がIT成熟度を考慮した新論理モデルで
目標ビジネスプロセスになります。
中川氏：良く分からないな！
私 ：じゃ、補足しましょう。現物理モデルと言うのは現行の物理的要素
（組織、場所、人、2重作業等）をありのまま業務フローをDFDに記述し
た業務フロー図です。現物理モデルはこの物理的要素を取り外し、ある
べき情報に流れで置き換えたDFDです。新論理モデルは現論理モデルに
情報化テーマ要件を加えて記述したDFDで、新物理モデルは新論理モデル
にIT成熟度を考えて物理的要素を加えたDFDです。
上野氏：情報化目標要件に合うよう目標ビジネスプロセスを作成していくわけで
すね
山田氏：目標にはビジネスプロセスに対応したSLAのようなIT環境・サービスに
対する目標も設定することになりますか？
私 ：そうですね。システムライフスパンを考慮して、ビジネスプロセスと
IT環境目標を設定することになります。
山田氏：じゃ、目標ビジネスプロセスモデル作成の要領書をまとめて進めていこ
う。
第１０９回はここで終了します。
今回は「目標ビジネスプロセスモデル策定」として、ビジネスプロセスプロセス
要件を討議しました。
次回は、「IT戦略策定-ギャップ分析」を取り上げます。
山田氏：あるべき姿である目標ビジネスプロセスモデルを作成するのだが、作成
するための要件を整理しておきたいのだが
中川氏：経営戦略を策定したときに、情報化テーマとプロジェクトの概算予算が
決まっていますね。現行業務プロセスの分析を行いましたので、その
ときの課題を改善したプロセスを作成すればよいのではないですか？
山田氏：それは現状課題改善プロセスとしては良いのですが、上野さんはどう思
いますか？
上野氏：あるべき姿のビジネスプロセスですから、中川さんのおっしゃるのも
含めて2つのことをまとめなければいけませんね。
１つは、経営企画書で作成された情報化テーマを情報化目標に変換する
ことです。
そうすることで、情報化の改革目標が設定できます。２つ目は現行業務
プロセス分析での現行課題と情報化テーマの改革目標を加えたビジネス
プロセス作成ですね。構造化設計を使ってまとめるとよいと思います。
私 ：そうですね、今回の情報化は複数の同種システムが存在しませんので、
DFDと構造化設計で良いでしょう。
ちなみに、複数の同種業務がある場合のシステム化ではEA（Enterprise
Archtecture）のガイドにあるようにDFD、業務プロセスの抽象化、構造
化設計を使用して行きますが・・・
http://www.meti.go.jp/policy/it_policy/ea/data/report/index2.html
中川氏：私のお客様で複数企業のシステムのASP化の話が来ているのですが、そん
なシステム化はEAに合うのですか？
私 ：合いますね。この企画書の作成が終わったら、EA適用設計をしてみまし
ょう。
話を戻して、上野さん、構造化設計の手順を説明いただけますか？
上野氏：分かりました。手短にやりましょう。作成手順は「現物理モデル」→
「現論理モデル」→「新論理モデル」→「新物理モデル」の順で、
「現物理モデル」は現行の業務プロセスで、現論理モデル設計は現行の
あるべきプロセス、「新論理モデル」は情報化テーマ要件を反映した
現論理モデル、「新物理モデル」がIT成熟度を考慮した新論理モデルで
目標ビジネスプロセスになります。
中川氏：良く分からないな！
私 ：じゃ、補足しましょう。現物理モデルと言うのは現行の物理的要素
（組織、場所、人、2重作業等）をありのまま業務フローをDFDに記述し
た業務フロー図です。現物理モデルはこの物理的要素を取り外し、ある
べき情報に流れで置き換えたDFDです。新論理モデルは現論理モデルに
情報化テーマ要件を加えて記述したDFDで、新物理モデルは新論理モデル
にIT成熟度を考えて物理的要素を加えたDFDです。
上野氏：情報化目標要件に合うよう目標ビジネスプロセスを作成していくわけで
すね
山田氏：目標にはビジネスプロセスに対応したSLAのようなIT環境・サービスに
対する目標も設定することになりますか？
私 ：そうですね。システムライフスパンを考慮して、ビジネスプロセスと
IT環境目標を設定することになります。
山田氏：じゃ、目標ビジネスプロセスモデル作成の要領書をまとめて進めていこ
う。
第１０９回はここで終了します。
今回は「目標ビジネスプロセスモデル策定」として、ビジネスプロセスプロセス
要件を討議しました。
次回は、「IT戦略策定-ギャップ分析」を取り上げます。
