IT経営戦略バイブル

先日、ＩＴ販売・サービス事業の１つとして創出したＣＳＦである「顧客別の24時間
365日の統合ヘルプデスクができること」から、コアコンピタンスを関連付ける作業が
始まっています。

上野氏：コアコンピタンスというのは「同業他社に比べて優位にある企業のコンポー
ネントや組織能力」ということですから、従業員のスキルや設備の優秀性、
短納期の仕組みなどの優位性と考えて良いのですか。
　私　　：それで良いと思います。「ひと」、「もの」、「かね」といった経営資源と
「販売組織」、「生産組織」、「物流組織」、「経理組織」などの経営機能
の強みです。
ですから、現有のコアコンピタンスはＳＷＯＴ分析での強み要因として既に
整理していますので、これを引用して現有のコアコンピタンスが関連づく
ＣＳＦと関係付ければ良いことになります。
上野氏：この事業の強みとして挙げました「大手顧客に対するカストマイズヘルプ
デスク体制」や「ＣＡＴＶ局のＢ２Ｃヘルプデスク実績スキル」などの強み
はこのＣＳＦのコアコンピタンスになりますね。
　　　　 (注)Ｂ２Ｃ：Ｂｕｓｉｎｅｓｓ　Ｔｏ　Ｃｏｎｓｕｍｍｅｒ
中川氏：そういうことがいえるな。さらに、今後のコアコンピタンスとはどう考えれ
ばよいのでしょうか？
私　　：ＣＳＦはあるべき姿から創出していますので、現有のコアコンピタンスだけ
ではカバー出来ない要因を含んでいます。
ですから、ＣＳＦを実現するために不足の経営資源、経営機能は何かと考え
て行く必要があります。
ＣＳＦを事業方針（＝経営方針）と考えてみますと、今後のコアコンピタン
スは下位の経営施策になると位置づけておけば良いでしょう。
　中川氏：それでは今後のコアコンピタンスを考えて見ましょう。現在討議している
　　　　　ＣＳＦ「顧客別の24時間365日の統合ヘルプデスクができること」の実現に
　　　　　不足の要因は“24時間365日”と統合ヘルプデスクの“統合”が現在の
　　　　　仕組みや能力にはありませんね。
　　　　　“24時間・365日”稼動状態となれば、インターネットによるサービスを考え
　　　　　るかありませんね。
　　　　　統合ヘルプデスクの“統合”とはＢ２Ｂの技術相談とＢ２Ｃの技術相談の
　　　　　統合でしたか？
　上野氏：その通りです。Ｂ２ＢもＢ２Ｃもレベルの違いはあっても技術的問題解決の
　　　　　ＦＡＱを作るための情報共有が必要ですね。
　　　　　そうそう、本社のヘルプデスクと共有すべきではないですか。
　　　　　　　　(注)ＦＡＱ：Frequently Asked Question（多い質問に対する回答）
　山田氏：今後のコアコンピタンスが出てきたようですね。
　　　　「インターネットヘルプデスクの整備」と「技術Ｑ／Ａの共有によるＦＡＱ　
　　　　ＤＢの構築」ですかね。
　みんな：それで良いと思います。
　私　　：良い感じになってきました。他のＣＳＦも進めて行きましょう。

　みんな：了解。
　　　　　・・・・・（作業）

　山田氏：現有と今後のコアコンピタンスが出て、概ね、ＣＳＦとコアコンピタンスの
　　　　　連携ができたようです。
　　　　　これから、本来の目的である「事業定義」と「事業の選定」へと進めたい　　　　　　ですが、・・・
　私　　：そうしましょう。まず、「事業定義」をやってみましょう。
　　　　　そうすると、ＣＳＦの選定が見えてきます。

第８６回はここで終了します。今回はコアコンピタンスとＣＳＦとの関係を議論しま
した。
次回は、テーマ「ＣＳＦの選定－事業定義」で定義されたＣＳＦとコアコンピタンスを
用いて事業を定義してみます。

Comments(0)

　今日伺いますと、先日のＣＳＦとコアコンピタンスを関連付け、事業定義を進めていました。
　山田氏：ＣＳＦとコアコンピタンスを関係付けてみると当事業部のみで施策として実施するに
　　　　　　予算と要員能力の観点で荷が重い今後のコアコンピタンスがありますね。
　　　　　　たとえば、今回出てきました「ポータルサイト構築事業」ですが、ＣＳＦが「企業と
　　　　　　生活者を結ぶポータルサイトの構築」に対する現有のコアコンピタンスは「ｗｅｂサイト
　　　　　　設計,構築実績」と「ＣＡＴＶ局のサーバー運用」で楽天やライブドアのようなポータル
　　　　　　サイトにするための今後のコアコンピタンスとして「ビジネスモデル構築スキル」が
　　　　　　上がりました。
　　　　　　このコアコンピタンス育成するのは大変な気がします。
　私　　：そうですね。大変かどうか事業化の考え方を整理してみましょう。そうするとより明確
　　　　　に見えてくるでしょう。
　　　　　まず、相当の投資が必要でも事業としての収益の可能性があれば、事業として成り
　　　　　立ちますので、今後のコアコンピタンスを育成して事業すれば良いですね。
　　　　　事業としての可能性が無ければ、事業としては止めるか、またはこのコアコンピタンス
　　　　　をはずして、「ホームページ作成ビジネス」として他の事業の１つのビジネスとして位置
　　　　　づけることになります。
　　　　　いづれにしても、事業を定義してみることが必要で、そうすることでより明確になると思
　　　　　います。
　山田氏：そうですね。
　　　　　事業定義では事業が良く分かるように記述したいのですね。事業と言うからには収益
　　　　　が上がるという記述が必要ですね。
　中川氏：当然、お客さんや市場といった販売対象とそのニーズの見極めが必要ですね。
　上野氏：販売対象に売るべき商品やサービスもいるのではないでしょうか。
　山田氏：そうだな、事業を定義するに必要な要件を整理してみよう。
　　　　　　ＣＳＦは事業方針と考えれば良いから、この下で、
　　　　　　まず、コアコンピタンスを持ったビジネスの対象となる「商品やサービス」の定義が
　　　　　　必要ですね。　次に、この商品やサービスを購入いただける「顧客」の選定、そして
　　　　　　その顧客の「ニーズ」の想定が必要ということかな。
　上野氏：このコアコンピタンスで想定したビジネスは
　　　　　　１つは現有のコアコンピタンス「Ｗｅｂサイト設計・構築実績」による「ｗｅｂサイト設計
　　　　　　と構築ビジネス」、もう１つは「ＣＡＴＶ局のサーバー運用」によるアウトソーシング
　　　　　　としての「ＩＤＣサービスビジネス」、今後のコアコンピタンス「ビジネスも出る構築
　　　　　　スキル」からは「ポータルサイト構築コンサルティングビジネス」辺りでしょうか？
　　　　　　（注）ＩＤＣ：Ｉｎｔｅｒｎｅｔ　Ｄａｔａ　Ｃｅｎｔｅｒ
　中川氏：想定ビジネスとしてはそんなところでしょう。
　　　　　　この想定ビジネスをもとに「顧客」と「そのニーズ」があるかをみていくことになり
　　　　　　ますか？
　私　　：そうゆうことになりますね。それでは、その顧客とニーズを見極めて「ポータル
　　　　　サイト構築事業」を定義してみましょうか。
　
第８７回はここで終了します。今回は事業定義の前提となる想定ビジネスを定義しました。
次回は、事業の市場を定義である事業ドメインを「事業定義－２　事業の選定」として取り上げ
ます。

Comments(0)

今日は事業ドメインの定義です。“コアコンピタンスに裏打ちされた想定ビジネスをどのお客や市場へ提供できるのか”が検討事項です。事業の絞込みと選定が焦点です。
中川氏：
さて、コアコンピタンスを活かした想定ビジネス「ｗｅｂサイト設計・構築ビジネス」と「ＩＤＣサービスビジネス」が出てきました。しかし、このビジネスの売り先を見つけることが必要ですね。

山田氏：
そうそう。売れるお客は既存顧客か、新規顧客か。そのニーズは？などなど、その辺が明確にならないと、事業の可能性が見えてこないのですよね？

私　　：
そうですね。事業ドメインとは事業できる領域のことですから、売り先としての顧客とニーズを設定することが必要になります。今後のコアコンピタンスは企業の能力育成の可能性を判断できますが、この顧客とニーズの設定は市場開拓の可能性を判断できます。

上野氏：
どういうことですか？　新規顧客と既存顧客の観点で事業の可能性が変わるということですか。

　私　　：
そうなんです。
たとえば、新しい業務パッケージを開発したとしましょう。既存顧客ですと、少なくとも話は 聞いてくれるでしょうが、新規顧客ですと訪問の約束すら取れないかもしれません。
すなわち、既存顧客に比して新規顧客ですと、新たに販売仕組みや要員のコアコンピタ ンス育成に多大な投資が必要になってきます。

　中川氏：
商売のネタとしての想定ビジネスが出来ても、売りやすい顧客とそのニーズが組み合わないと事業としては成り立たないということですね。

　山田氏：
事業は想定ビジネスとしての「商品やサービス」、売り先としての「顧客」、「そのニーズ」 の組み合わせで定義にないと事業の成功可能性が見極められないということか。

　私　　：
その通りですね。したがって、この組み合わせを事業ドメインとして定義するわけです。
それでは、今検討している「ポータルサイト構築事業」の顧客とそのニーズを設定してみましょう。

　中川氏：
機械、電気の大手3社が既存客としてありますが、ポータルサイトを持つニーズよりホームページ整備の方がニーズとして強そうですね。
約50社の中小・中堅企業も同様でしょう。CATV局は可能性がありますね。新規事業展開が必要な状況ですし、生活者と密着していますので、企業からの広告やテナント依頼がありそうですね。

山田氏：
とすると、CSF「企業と生活者を結ぶポータルサイトの構築」に対する事業定義は「CATV局を中心とした顧客の新規事業展開のニーズに対し、ポータルサイト構築コンサルティング、Webサイト設計ビジネス、IDCビジネスで収益を上げる事業」ということになりますか。
現在、見込みの顧客1社でコアコンピタンスの育成も困難そうですね。

上野氏：
そうですよ。この事業は時流ではあるのですが、今後のコアコンピタンスの “ブランドを付けるためのビジネスモデルの構築スキルを如何に取得するか”が重要です。
そう簡単にはこのスキルを付けることは出来ませんね。

　私　　：
事業の優先度は事業収益の成長を示す「成長性」、販売領域の広さを示す「市場の大きさ」と「成功度」を示すコアコンピタンスの観点で見ていけばよいのですが、その観点ではいかがですか。

上野氏：
この「ポータルサイト構築事業」は他の定義された事業「IT販売・サービス事業」や「ERP構築事業」等に比べると「成功度」の観点で優先度が低くなってきます。
これは事業として成り立たないかもしれませんね。止めましょうか。

中川氏：
ちょっと待って、そんなに簡単に止められてはもったいない。なぜなら、今後のコアコンピタンスである「ビジネスモデル構築スキル」をはずせば、他のビジネスは現有の体力でも十分可能性があります。せっかくコアコンピタンスもありますが、

山田氏：
この事業の現有のコアコンピタンスはITインフラの販売・導入事業である「IT販売・サービス事業」に組み入れたビジネスとして捉えるとシナジー効果をもって事業価値が上がりそうですね。
CSF「企業と生活者を結ぶポータルサイトの構築」は当事業部で独立の事業として実施するには事業体力としてムリですね。

　私　　：
どうやら結論が出たようですね。コアコンピタンスを活かして現有の事業にシナジー効果をもたらす方向で事業をまとめてよいと思いますよ。

　山田氏：
よし！！　事業は現事業にシナジーを活かした「IT販売・サービス事業」と当事業部には新規事業になるが、本社で実績のある「ERP構築事業」の2つに絞って経営計画作りに進もう。

　上野氏：
事業定義が出来たら、次のステップは「事業施策」作りでしたか？
　　　　　　　　　
第８８回はここで終了します。今回は「事業の選定」の討議でした。
次回は、事業施策を策定するための最初のテーマに「経営施策策定－１　バランススコアカードとは？」として取り上げます。

Comments(0)

事業定義ができて、経営施策（事業施策）への展開のために「バランススコアカード」の復習が
行われています。
中川氏：えーと、バランススコアカードといえば4つの視点での施策展開と業績管理指標作り
でしたね。
上野氏：そう。「財務の視点」で経営目標の設定後、「顧客の視点」→「内部業務プロセスの
視点」→「学習と成長の視点」へと「目的→手段＝目的→手段・・・」の関係で施策の策定
をするのですが、ちょっと難しいですよ。
　山田氏：実は私も難しいなと悩んでいるのだが、“顧客の視点というのは顧客満足度を上げる
ための施策でしょうが、何をもとに考えて施策を出せばいいのか”ちょっと困りますね。
　上野氏：そのことです。事業施策ですから発想に抜けがあってはいけませんし、思いついた
施策だけで良いはずはありません。やはり、施策発想の基になるメタフレーム（発想の
構造基盤）が必要ではないでしょうか。
　私　　：その通りだと思います。作ってみましょうか。財務の視点は経営目標に対する施策
ですから、売上高向上、利益率向上、生産性向上などの施策になりますね。
　上野氏：それは分かりますが、問題は顧客の視点ですね。顧客満足度向上という施策は分か
るのですが、高品質で低価格な商品とかサービスは顧客満足度を上げますよね。
これらも顧客の視点で捉えるべきでないでしょうか。
　中川氏：他にも、同じ価格ならブランド物が良いし、商品を良く知っていて説明してくれる店員の
いる店も満足感がありますよ。
　私　　：皆さんが挙げられた項目はすべて顧客の視点の施策として捉えてよいと思います。
　　　　　項目として整理すると、「品質」、「価格」、「納期」、「機能」、「サービス」、「リレーション」、
「ブランド」があり、事業の特性によって選択すべきでしょう。
　中川氏：なるほど、顧客満足度施策の下位構造の施策として、事業特性を考慮して策定する
　　　　　　ことで、施策の抜けが少なくできますね。ところで、「リレーション」とは何ですか？
　私　　：顧客との関係性のことで、2種類あります。関係性はお客様が信用してくれる関係の
ことを言うのですが、良好な人間的関係による信用とインターネットなどでの問題解決の
FAQのデータベースサービスなどはお互いの業務遂行を円滑にする関係性を築けます。
上野氏：このフレームは事業戦略目標によって、「品質向上」、「原価低減」、「納期遵守」、
「複合機能化」などの顧客の視点施策を設定することになりますね。
　　　　　この視点の下位である「内部業務プロセスの視点」の施策もここの施策設定で決まって
くることになりませんか。
　私　　：そうです。この顧客の視点がキーとなります。顧客の視点はお客に満足していただいて
売上を向上できるためのWin-Winの施策を設定することになります。外向きの施策で
すね。
　中川氏：その“外向きの施策”とはどういう意味ですか？
　私　　：バランススコアカードのバランスの意味は外向きの施策と内向きの施策がバランスしてい
ることが必要という観点です。外向きの施策とは財務の視点の施策と顧客の視点の
施策、内向きの施策とは内部業務プロセスの視点の施策と学習と成長の視点の施策
です。
　山田氏：ふーむ。売上は企業内の問題ではなく、企業の外にあるお客様からだから、お客様に
対する施策は外向き、お客様に買っていただくための仕組みや商品、サービス作りは
企業内の施策になるから内向きということですか？
　私　　：そうです。解説いただいてありがとうございます。

第８９回はここで終了します。今回は財務の視点と顧客の視点の討議でした。
次回は、バランススコアカードの下位の視点である、「内部業務プロセスの視点」と「学習と成長
の視点」の事業施策の考察を「経営施策策定－１　バランススコアカードとは？－その２」として
取り上げます。

Comments(0)

「バランススコアカード」の復習のつづきが行われてます。 山田氏：バランススコアカードのバランスとは外向きの施策と内向きの施策のバランスのこと でしたか？ 私　　：そうです。もう少し補足しますと、企業の経営活動にはその企業体力でのバランスの 保てた状態でないと収益を上げることが出来ません。そのための施策のバランスです。 上野氏：その意味は営業力が強くて、受注をたくさんとってきても、ＳＥや技術力が無いと オーバーワークになって問題が発生したりして、収益が食い潰ぶされるようなことですか。 私　　：逆も真なりですね。経営活動を行う上で業務プロセス上でのバランスが崩れますと、ムダ やムリが出て、収益を損なってしまうことになります。 山田氏：それはそうですね。企業機能のバランスが取れるように、且つ競争優位を保てる施策を 策定すべきですね。 ただ、内向きの施策で「内部業務プロセスの視点」、「学習と成長の視点」でも何か発想 するためのメタデータが必要ですね。 中川氏：そうですよね。提案型営業の出来るスキルとか、商品配送の仕組みやお客様相談窓口 の仕組みなどありますが、メタデータがナイト漏れが出そうで怖いですね。 上野氏：中川さんの言うのをまとめますと、ここでの「スキル」というのは、学習と成長の視点の 施策でしょう。「商品配送の仕組み」とか「お客様相談窓口の仕組み」などは内部業務 プロセスの視点で良いと思いますが、 中川氏：言っている意味は顧客の満足を上げるために顧客に接した業務はだから「内部業務 プロセスの視点」で、スキルはそのプロセスの質を上げる要因だから「学習と成長の視点」 ということかな。 私　　：良い議論ですね。ポイントを突いてますね。それでは、メタデータを作ってみましょうか。 「内部業務プロセスの視点」は顧客の満足度を上げる競争優位に立てる業務の仕組み づくりですから競争優位となる差別化プロセスでないといけません。 上野氏：そうそう、思い出しました。差別化理論！ 競争優位に立つための差別化には「製品・サービスの差別化」、「顧客関係・維持の差別 化」、「オペレーション効率化の差別化」がありましたね。 中川氏：顧客の視点の指標を目標に内部業務プロセスの視点の施策を差別化の施策として 捉えるということかな？ 山田氏：両方の視点のメタデータを合わせてみると、顧客の視点の「品質」、「価格」、「納期」、 「機能」などは内部業務プロセスの「製品・サービスの差別化」の施策でカバーできそう ですね。 同様に「サービス」や「リレーション」、「ブランド」は「顧客関係・維持の差別化」の施策、 「オペレーション効率化の差別化」の施策は「価格」と「納期」をカバーしそうですね。 上野氏：ようやく分かってきた。ところで、「学習と成長の視点」ではどんなメタデータになります か？　「スキル」が入ってくることは分かるのですが。 私　　：内部業務プロセスの視点の施策を遂行するための「スキル」、すなわち、「従業員の業務 遂行のコンピテンシー」向上の施策が一つの視点。そのほか、情報の伝達や共有により 業務支持の迅速化や業務遂行の効率化を図るための「ITインフラ整備」の施策、リーダー シップによる「競争力を育む風土や文化の醸成」の施策などがあります。 山田氏：施策展開のメタフレームは理解できたので、施策を作ってみましょう。 みんな：了解。 第９０回はここで終了します。今回は「内部業務プロセスの視点」と「学習と成長の視点」の討議 でした。 次回は、事業施策の展開を「経営施策策定－２　事業施策展開」として取り上げます。

Comments(0)

　今日伺いましたら、以前選定した事業である「IT販売・サービス事業」と「ERP構築事業」の財務
の視点の施策の検討に入っていました。

　山田氏：財務の視点の施策は売上や利益、コストといった経営目標に対する施策ですから、
「売上高向上」、「利益率向上」や「原価低減」などの目標でしたので、同じ施策を設定
して、経営目標を設定すれば良いのかな。
　上野氏：ちょっと待ってください。「IT販売・サービス事業」と「ERP構築事業」を見てみますと、
既存事業と新規事業の違いがありますね。同じ経営目標で良いのでしょうか。
　中川氏：そうですね。「IT販売・サービス事業」は今までの事業にIDCサービスビジネス等を加
えた既存の事業強化だが、「ERP構築事業」は当事業部にとってはゼロからの出発
です。
　山田氏：新規事業の「ERP構築事業」を1年目から利益目標を設定しても、無理があるかもしれ
ないね。既存事業で利益を出し、新規事業はしばらく導入実績や市場開拓に重点を置
いた目標にした方が良いかもしれないな。
　私　 　：山田さんの言われるとおりですね。新規事業はまず、導入実績が無いと成長できません
ので財務の視点の目標は顧客実績が出るまでは利益目標よりも売上目標の方が妥当
ですね。
その施策としては、「売上高向上」で、IT販売・サービス事業の施策は「売上高向上」と
「利益率向上」等になり、事業目標を設定することになるでしょう。
上野氏：了解。そうすると、「顧客の視点」の施策も違ったものになってきますか？
　　　　 　「ERP構築事業」の方は顧客も現在はありません。「IT販売・サービス事業」の場合は、
現在の顧客により浸透する施策を品質、納期、価格、サービス等の観点で作成すれば
良いと思うのですが、「ERP構築事業」はまず、市場としての顧客を作るための施策です
よね。
また、ERPを入れるというと中堅以上の企業さんでしょうし、この事業部は中小企業も含め
ても50社しかありません。
中川氏：顧客ね――　・・・、私どもの提携メーカーさんは沢山の中堅企業を持ってますよね。
　山田氏：中堅といえば、大手顧客の事業部も対象になりそうだな
　　　　　　とすれば、顧客の視点の施策の一つは「新規顧客の獲得」として、顧客目標数が定義
できそうですね。
　中川氏：顧客の視点では商品やサービスを購入してくれるための満足度向上に関する施策が
欠かせませんでした。ERPの場合のメタデータは何を考えたらよいのだろう。
　上野氏：システム構築全般に言えるのですが、特にERPを導入する顧客は“予算内で目標納期
を守ってシステムが稼動できるか”が一番の関心事でしょう。その次の関心事は、・・・
　　　　　　システム保守でしょう。ERPシステムは顧客にとってブラックボックスですので、
何か起こったときの対処の仕組みがあることが必要でしょう。
　山田氏：「ERP構築事業」に対する顧客の視点が決まったようだな。３つの施策、
　　　　　　まず、「新規顧客の獲得」、その下位施策として「予算内の納期遵守」、「システム
ヘルプデスク体制の整備」としよう。
　中川氏：「IT販売・サービス事業」の顧客の視点は任せてください。
　　　　　　えーと、「顧客数の増大」は上位施策、下位施策は大手企業で情報部門以外の部門
取引が少ないですから、「部門取引比率の拡大」はどうですか。その他は「納期遵守」、
「保守サービス体制の強化」辺りでしょうか
　山田氏：中川さん、すごいね。わたしと役職変わっても大丈夫そうだね。
　中川氏：いいや、恐れ多いですよ。
　私　　：「財務の視点」と「顧客の視点」の施策はどうやら出揃ったようですね。
　　　　　「内部業務プロセスの視点」と「学習と成長の視点」の施策を考えて見ましょうか。
　中川氏：これはちょっと難しくなるぞ

第９１回はここで終了します。今回は「財務の視点の施策」と「顧客の視点の施策」展開の討議
でした。
次回は、「内部業務プロセスの視点」と「学習と成長の視点」の事業施策の展開を「経営施策
策定－２　事業施策展開－その２」として取り上げます。

Comments(0)

　今日はIT販売・サービス事業とERP構築事業の「内部業務プロセスの視点」と
「学習と成長の視点」の施策の検討です。山田氏が「IT販売・サービス事業」
を取り上げ、発言しています。
　
山田氏：えーと、顧客の視点の施策は上位施策が「顧客数の増大」、下位施策は
「部門取引比率の拡大」、「納期遵守」、「保守サービス体制の強化」
でした。さて、まず「内部業務プロセスの視点」からの展開になるが、
この視点のメタデータは「製品・サービスの差別化」、「顧客関係・
維持の差別化」、「オペレーション効率化の差別化」でしたね。
上野氏：顧客の視点の施策に対して、“この施策目標を達成するために何をやれ
ばよいか”を「内部業務プロセスの視点」のメタデータの観点で施策
展開することになりますね。
中川氏：ちょっと分からないな。顧客の視点には上位施策と下位施策があった
よね。どっちとも展開することになるのか？
上野氏：それは無いですよ！上位施策は顧客数の増大で、そのために下位施策が
あるのですから、この内部業務プロセスの視点は顧客の視点の下位施策
に焦点を当てて展開すれば良いと思いますよ。
中川氏：そりゃそうだ。じゃ、「部門取引比率の拡大」施策からみていこう。
この施策を達成するには、お客様の各部門の責任者に私たちを知って
もらわなくてはいけませんね。関係性強化の問題だな。
上野氏：大手顧客の未取引部門の一覧を作って弊社の説明に行きましょうか。
　　　　 ただ、これだけでは会ってくれそうも無いですね。時間の無駄言われ
そうですね。
　　　 　相手に何かメリットがないと・・・・・
山田氏：弊社から納めたＰＣ／サーバー、ネットワーク機器等のリース切れや
減価償却を取っ掛かりにしたらどうだろう。
中川氏：それはいいですね。訪問する話の取っ掛かりが出来ます。確か、大手の
Ａ社に対して弊社納入品のインベントリー管理をやってました。
この仕組みが広がると弊社にとっても未取引部門との接触をとることが
出来ます。
　上野氏：で、顧客のメリットは？
　中川氏：営業やっているとリース切れや償却切れは資産の買い替えをお客は考え
ているし、購入した資産管理は本業とは余り関係のない業務だから、
やってもらえると助かるのですよ。
　上野氏：なるほど、では施策、１つ決まり。「顧客インベントリー管理しくみの
構築・拡大」。
　　　　　関係性ですと、大手顧客に対して、注文品の納入予定のイントラＷｅｂ
サービスを提供していましたね。この仕組みも強化すべきでは？
　中川氏：そうそう、お客からも一方的な情報提供ではなくて、双方向で会話の
出来るようにしてくれないかとクレームが出てますよ。
　山田氏：双方向になると、お客の問題をより把握できるようになるし、適切な
対応が出来れは、一番重要な顧客満足度があがりますね。
　　　　 「２ＷａｙＷｅｂ取引コミュニケーションシステムの構築・拡大」も施策
にしよう。
　　　　 関係性の方は出来てきたが、他のメタデータの観点からも考えて
みよう。
　みんな：（討議がつづく）
　　　　　・・・・・・・・・・
　私　　：みんな、良く理解されてどんどん進んでいきますね。私、余り必要ない
みたいですね。
　上野氏：そんこと無いですよ！！ＥＲＰ構築事業は新規なので、また質問が
　　　　　あるんです。

　第９２回はここで終了します。今回は既存事業の「内部業務プロセスの視点」の
　施策展開の討議でした。
　次回は、新規事業の「内部業務プロセスの視点」の事業施策の展開を「経営施策
　策定－２　事業施策展開その３」として取り上げます。

Comments(0)

　今日は新規事業であるERP構築事業の「内部業務プロセスの視点」の施策の検討
です。上野氏から早速質問です。

上野氏：ＥＲＰ事業の場合、当事業部には何もコンピタンスがありません。
こんな場合、事業化できるまでのプロセスが施策となっていくと思う
のですが、どんな順序で施策を打てばよいのでしょうか
中川氏：新規事業の市場開発は大変だよ。顧客がまず信用してくれないから
な。 最初にやることは契約してくれる顧客をまず探すことでは
ないかな。
私　　：そうですね。　新規事業の場合は一番重要なことは実績ですね。
そのための見込み顧客をできるだけ多く抑えることでしょう。
　　　　　実績が出来れば拡大も可能になります。
上野氏：言われたことをまとめますと、施策を打つ順序は「顧客開拓の施策」、
「実績作りの施策」、「事業拡大の施策」と言うことになりますか？
山田氏：さすが、その顧客と言うのは中堅企業向けＥＲＰの適用の体力のある
顧客だよな。
当事業部の中小中堅企業の約50社はあるが、ちょっと事業をやるには
顧客の数が少ないな。
中川氏：まだありますよ、大手顧客の事業部もターゲットにしたらどうでしょう
か。８事業部ありますね。営業としてはそれでも見込み客として少ない
ですね。
　　　　　私どものコンピュータメーカの顧客を見込み客に出来ると良いのです
が。
山田氏：じゃ、それを施策にしよう。内部業務プロセスの視点の施策で「メーカ
とのＥＲＰ協業体制の確立」だな。ＩＴインフラ機器での関係は出来
ているので、メーカの営業さんに協業を依頼するのは新規顧客を直接
狙うよりは簡単になると思う。
上野氏：メーカの営業さんに信頼してもらえるような「販売手順や導入作業標準
等の整備」も内部業務プロセスの視点で必要になりますね。
中川氏：なるほど。そうするとこれらの施策を支えるには営業やＳＥがＥＲＰを
良く知っていないと協業体制も組めませんね。学習と成長の視点での
施策として「ＥＲＰ販売スキル営業の育成」や「ＥＲＰコンサルタント
の育成」などが施策として必要と思うのですが。
私　　：その通りです。学習と成長の視点の施策として考えて良いでしょう。
　　　　 その他にはありませんか。
上野氏：学習と成長の視点のメタデータ（考え方の枠組み）はスキルと情報共有
ですよね。
　　　　 としますと、本社を含めた「ＥＲＰスキルの情報共有システム構築」は
施策になりませんか？
山田氏：この視点の施策として良いと思う。もう無いかな・・・、事業サイクル
の観点で考えて、特にアフターフォローなどは今のままでよいかな？
上野氏：「ＥＲＰサービスデスクの設置」！！　そのほかにはモニタリング辺り
で「モニタリング指導スキルの育成」などいかがでしょうか。
私　　：論理的な展開が出来ましたね。ＢＳＣではまず、上位からの展開は
「目的→手段」、その後下位からは「原因→結果」の関係を抑え、施策の
論理性を見極めて、施策の確定をしていきます。
　　　　 ちなみに、下位からの積み上げた施策ロードマップを戦略マップといい
ます。

第９３回はここで終了します。今回は新規事業の「内部業務プロセスの視点」、
「学習と成長の始点」の施策展開の討議でした。
次回は、展開した事業施策を戦略マップとして構成する検討を「経営施策策定－２
　戦略マップ　その１」として取り上げます。

Comments(0)

　今日は策定した事業施策で戦略マップをつくる作業に入っています。サーバーや
ネットワーク機器販売の「ＩＴ販売・サービス事業の戦略マップ」の検討で
す。 上野氏から早速、質問です。

上野氏：戦略マップは経営施策体系と言うことですが、バランススコアカード
でもメタデータを用いて経営施策体系として作成してきたのですが、
なぜ最下位の「学習と成長の視点」から「財務の視点」まで再び施策を
積み上げるのですか？
私　　：1つは施策の漏れの検証でしょう。もう1つは施策の整合性の確認です。
　　　　 こんなこと経験ありませんか。“原因分析をして行って見つかった原因
が、逆に、この原因から問題を見ると多くの問題を発生の要因であっ
た”というようなこと。
中川氏：あります、あります！以前、保守契約書を営業員個人の保管をやって
いたことが問題発生時の営業員の対応の負荷を増加しましたし、ヘルプ
デスクの負荷も増加させていました。
山田氏：予算もトップダウン後、ボトムアップで調整して策定します。同じこと
ですね！
上野氏：要するに、ボトムからの積み上げは現場に近い観点からの原因→結果の
検証になるということですね。
　　　　　それでは、この事業の施策を見てみましょうか
　　　　　えーと、学習と成長の視点には「先端ITインフラ技術スキル教育」と
「営業・技術情報共有システム強化」がありますね。
中川氏：つづいて、内部業務プロセスの視点では「顧客資産管理の仕組み
構築」、「年間契約サービス体制強化」、「アセットレンタル契約方式
　　　　　の確立」、「２WayWeb取引コミュニケーションシステム構築」、「IT
　　　　　事業サイクル体制強化」があります。
　　　　　学習と成長に視点とのつながりを見ていきましょうか
　　　　(注) ２WayWeb取引コミュニケーションシステム構築：取引情報をお客と
　　　　　　　双方向でコミュニケーションできるＷｅｂシステム
　上野氏：「先端ITインフラ技術スキル教育」と「営業・技術情報共有システム
　　　　　強化」の施策は上位の「IT事業サイクル体制強化」から展開されてきた
　　　　　のですが、つながりが漠然としてますね。
　　　　　「先端ITインフラ技術スキル教育」はIT事業サイクルでの導入時の実装
　　　　　技術体制の強化の観点でしたから、この原因の結果としては「IT実装
　　　　　技術体制の強化」の方がよいですね。
　中川氏：「営業・技術情報共有システム強化」もおかしいな？
　　　　　戦略マップの観点で行くと、営業情報共有は売上向上戦略マップの方の
　　　　　施策体系だし、技術情報は実装技術でしたので生産性向上戦略マップの
　　　　　施策体系になります。
　山田氏：なるほど、下位の視点からの積み上げをやると、整合性の無理な点が
　　　　　よく分かりね。
　　　　　中川さんの疑問も「営業・技術情報共有システム強化」を「営業情報
　　　　　共有システム強化」と「技術情報共有システム強化」の2つに分解し、
　　　　　上位の「IT事業サイクル体制強化」も「ITインフラ販売体制強化」と
　　　　　「IT実装体制強化」の2つに分解しましょう。
　上野氏：上位との整合性はその方が取れますね。また、そうした方が施策として
　　　　　明確になります。
　　　　　戦略マップ作成でもうひとつ分からないのが、「２ＷａｙＷｅｂ取引
　　　　　コミュニケーションシステム構築」とその上位にある顧客の視点の
　　　　　「顧客満足度向上」施策のつながりにギャップがありますね。
　私　　：そうなんですね。上位からは「・・すべき」で展開してきますが、下位
　　　　　からは原因→結果ですので影響因子が無いと繋がりがよく分からなく
　　　　　なります。そこで施策の漏れもチェックできるわけです。
　山田氏：たとえば、「２ＷａｙＷｅｂ取引コミュニケーションシステム構築」に
　　　　　よって、“顧客は取引進捗か即時把握できる”、だから“顧客の業務
　　　　　生産性が上がる” 、その結果「顧客満足度向上」になるということです
　　　　　かね。
　私　　　：その通りですね。
　中川氏：山田さん、偉い。やはり私の上司だけのことはある！
　山田氏：おいおい、からかうなよ！！

　    ・・・笑い・・・・
    
第９４回はここで終了します。今回はＩＴ販売・サービス事業の戦略マップの討議
でした。
次回は、展開した事業施策をビジネスモデルとして展開する「ビジネスモデル作成
インフルエンスダイアグラムその１」として取り上げます。

Comments(0)

　今日は策定した事業施策でビジネスモデル確立するための最初のステップである
　インフルエンスダイアグラムの必要性確認の論議に入っています。

　中川氏：ビジネスモデルと言うのは儲かる仕組みでしたね。戦略マップで財務の
　　　　　 視点で利益目標までの施策体系を作成しました。同じことになりません
か。
　私　　：ちょっと違いますね。ビジネスモデルは事業ですからバリューチェーン
の仕組みを使って確かめなければいけません。
　上野氏：バリューチェーンと言うのは仕入れ、製造、販売、物流、サービスを
基幹業務とする企業業務プロセスですね。私たちは簡略化して事業サイ
クルとして「企画／計画」、「販売」、「実装（製造）」、「アフタ
フォロー（保守）」として捉えてましたね。
　中川氏：あなた、いつも良く覚えてるね。感心する！！
で、なぜまたバリューチェーン？　ここでの事業サイクルで捉える必要
があるのですか。
　私　　：以前、“経営はバランス” と申し上げました。事業は業務プロセスで
捉えるべきで、如何に論理的に展開した戦略マップの事業サイクルで
施策の漏れやムダを再確認する必要があります。
　　　　　その手法にインフルエンスダイアグラムを使用します。
　上野氏：とすれば、バランススコアカードの戦略マップ展開で事業サイクルを
考えて展開するメタフレームを考えておけば良いことになりますね。
　私　　：おっしゃる通りなのですが、戦略マップ展開のメタフレームとバリュー
チェーンのメタフレームの両方を考えて経営施策を作成するのはなか
なか難しいですよ。それで段階を踏んでやることにしようと言うこと
なのですよ。
　上野氏：そうですね。段階を踏んでやることで、2重チェックが可能ですね。
この施策を間違えると大変ですから。
　山田氏：戦略マップは「施策の整合性や論理性」を見ていきましたが、ビジネス
モデルはバリューチェーンですから、「施策による事業の実現可能性」
を判断することになりますね。
　　　　　ところで、ビジネスモデルを表現するインフルエンスダイアグラムの
メタフレームは何だったかな？
　上野氏：確か、売上や利益といった事業価値からスタートし、販売施策によって
「受注が増大する」までの影響因子の販売フェーズ、受注が増えたこと
に対する実装（製造）施策が「成功裏な導入（成功裏な製品出荷）」の
影響因子に至る導入（製造）フェーズ、最後に導入（出荷）が増大した
ことに対するアフタフォロー（保守）施策が「顧客満足向上」の影響
因子に至るアフタフォロー（保守）フェーズの3つのフレームでしたね。
　中川氏：また、よく覚えてるな！ただ、その後は私も覚えている。
　　　　　「顧客満足向上」は[売上向上]の影響因子を導き、「成功裏な導入
（成功裏な製品出荷）」の影響因子は「コストの低減」を導き、「利益
の向上」と言う事業価値に戻るというフレームでした。
　上野氏：戦略マップであった財務の視点と顧客の視点の施策は施策として出て
こないのですか？
　私　　：良いところに気付きましたね。インフルエンスダイアグラムでは事業
価値が財務の視点になりますし、顧客の視点はその前の影響因子となり
ます。ですから、このダイアグラムでの施策は「内部業務プロセスの
視点」と「学習と成長の視点」の施策を使用します。さて、ほとんど
理解されているようなので、既存事業の「ＩＴ販売・サービス事業」の
強化施策のインフルエンスダイアグラムを描いて見ましょうか。
　山田氏：知ってることと、出来ることは違いますからね。まず、描いてみないと
何が問題かも分からないな。
　上野氏、中川氏：始めましょう！！
　　
第９５回はここで終了します。今回はビジネスモデルにおけるインフルエンス
ダイアグラムの必要性の討議でした。
次回は、「ＩＴ販売・サービス事業」の事業施策を書いてみる作業に入りま
す。「ビジネスモデル作成　インフルエンスダイアグラムその２」としてその
課題を取り上げます。

Comments(0)

今日は策定した「ＩＴ販売・サービス事業」の事業施策をビジネスモデルとして
確認するインフルエンスダイアグラムの作成の論議に入っています。サーバーや
ネットワーク機器販売する事業の「ＩＴ販売・サービス事業」のバランススコア
カードで展開した施策が検討対象になってます。

中川氏：営業課長の立場として申しますと、この事業のインフルエンスダイアグ
ラムの開始点である事業価値は売上高になるのですが、それで良いです
か？
山田氏：大阪事業部として会社から求められているものは売上もあるけど、利益
の方に重点が置かれてます。
上野氏：事業価値は通常、既存事業の場合は企業の生き残りのビジネスとなるの
で「利益高」となり、新規事業の場合は顧客認知度や実績作りが必要な
ので利益を見込むより「売上高」で考えていくということとメルマガの
知識編で勉強しませんでしたか？
私　　：上野さんの考え方でよいですね。この事業は既存事業の強化ですので
事業価値を「利益高」としましょう。
中川氏：了解。まず、販売フェーズの施策とコアコンピタンスをバランススコア
カードで展開した内部業務プロセスの視点と学習と成長の視点から拾っ
て見ましょう。
えーと、施策には「２WａｙWｅｂ取引コミュニケーションシステム
構築」、「営業情報共有システム強化」、「顧客資産管理システム
構築」などがありコアコンピタンスで「ユーザー会」、「技術相談
窓口」があります。
利益という事業価値が上がると、コアコンピタンスを活かして実施する
経営施策がビジネス上、好影響を与えるかを確認するということです
ね。
(注) 「２WａｙWｅｂ取引コミュニケーションシステム構築」：顧客の
技術相談、取引上のＱ／ＡをWｅｂを使って双方向で行うシステム
構築の施策
私　　：そうですね。
中川氏：「営業情報共有システム強化」は影響因子として、「顧客の課題を良く
掴める」→「より良い改善案の提案」→「顧客の了解が得られやすく
なる」→「受注が増加する」につながります。コアコンピタンスの
「ユーザー会」や「技術相談窓口」はこの施策の基盤になっています。
上野氏：「２ｗａｙｗｅｂ取引コミュニケーションシステム構築」の施策は影響
因子として、「顧客の業務生産性が上がる」→「顧客の信頼が高まる」
→「顧客の了解が得られやすくなる」→「受注が増加する」と続きます
ね。この施策のコアコンピタンスは「技術相談窓口」があるから出来ると
いえます。
山田氏：「受注が増加する」のメタフレーム影響因子に届いたら、実装（製造）
フェーズの展開で「ＩＴ導入体制の強化」や「契約社員のＩＴスキル
確保」へ繋がることになるのか。
上野氏：「ＩＴ導入体制の強化」の施策は「ＩＴスキル要員が増大できる」し、
「契約社員のＩＴスキル確保」は「実装の量的対応体制ができる」の影響
因子を導きます。この両方の影響因子は「システムの成功裡の導入」の
メタフレーム影響因子を導きます。
山田氏：「システムの成功裡の導入」が出来れば、当方は「コストが下がる」
し、お客様は「満足度が上がる」→「売上が上がる」の影響因子になら
ないかな。
私　　：それで、「利益高向上」という事業価値へ繋がり、事業サイクルが概ね
出来てます。
山田氏：よし！　他の残っている施策もこの流れで当てはめれば完成だ！
・・・・・・（作業継続）
私　　：新規事業の「ERP構築事業」事業は事業価値が[売上高向上]になりま
す。   ＯＫですか？
上野氏：了解です。実績作りが中心なので、実績が出来るまでは「利益高
向上」にはならないということですね。
・・・・・・・（作業継続）

どうやら、既存事業の「ＩＴ販売・サービス事業」と新規事業のインフルエンス
ダイアグラムが出来上がりそうです。第９６回はここで終了します。
今回は事業のインフルエンス記述の作業討議でした。
次回は、戦略マップで経営施策として作成され、インフルエンスダイアグラムで
確認された事業施策の業務管理指標化を行います。「経営管理指標の作成　指標
の作成原則」としてその課題を取り上げます。

Comments(0)

　今日は、戦略マップで経営施策として作成され、インフルエンスダイアグラムで
確認された事業施策のモニタリングのための経営管理指標化の前提論議に入って
います。

　中川氏：事業施策の整合性と実現可能性を戦略マップとインフルエンスダイアグ
ラムで確認しましたが、この施策をモニタリングできるように管理指標
化するって・・・・・
　上野氏：事業施策の中には、指標化し易い施策とそうでない施策がありますね。
たとえば、ＩＴ販売・サービス事業の「財務の視点」の事業施策は利益
高向上ですから
　　　　　事業目標として利益高として決まりますので、経営管理指標としては
“売上高利益率”のように設定は容易ですが、「顧客の視点」施策の
顧客満足度向上と言うのは“顧客満足度”でいいのでしょうか？　
確か、モニタリングの指標は客観性のある指標でなければいけないと
聞いたような気がしますが。
私　　：そうですね。客観性が必要ですね。顧客満足度は客観的ですか？
　山田氏：日経の調査のように第3者ですと可能でしょうが、お客ですから私などが
訪問して聞くことになります。そうすると、お客様は担当者や私に気兼
ねして余り悪い評価が出てこない傾向にあります。
　私　　：そうなんですね。この手の経営管理指標が多いんです。このような
場合、顧客満足度が向上した状態を想定して、顧客満足度の代替指標を
発想することです。しかも、その指標は、業務プロセスの中で収集で
き、且つ計数化できる指標であることが必要です。
　中川氏：そうか、顧客満足度の代替指標か。顧客満足度が向上すると顧客はたく
さん買ってくれるようになりますよね。これを指標化すれば良いのか
な？
上野氏：そうですよ。業務プロセスでも通常に収集できて、計数化できる指標と
言うことですから、お客がたくさん買ってくれると受注数が増えますの
で、“受注数”を管理指標にしたらいかがでしょう。
山田氏：いいんじゃないかな。他に、顧客が満足すれば、お客様も増えていくで
しょうから“顧客数”なども管理指標として可能ですね。業務プロセス
上のデータとして収集も可能ですし、・・・・
中川氏：なるほど、分かった。客観性があり、計数化できる指標へ置き換えた
代替指標と言うのはビジネス活動で収集できるデータで測定できる指標
と言うことですね。そうすると、情報システムで集計しているデータ
だから、余分な手間を取らずに収集できるということになりますね。
私　　：中川さん、その通り。業務プロセスで取れますから。
ところで、お気づきのように、事業施策の指標化は指標の発想の仕方に
２つの方法があるのです。と言うのは利益高向上のようにそのまま指標
化できる施策と顧客満足度向上のように代替指標を設定しないと無理な
施策です。
中川氏：あれぇー、確定した施策を見ると、そのまま指標化出来る施策はほと
んどありませんよ。　　　
私　　：財務の視点の施策はそのまま指標化できる施策が多いのですが、その
下位の視点の施策はほとんどが代替指標を発想しないとモニタリングの
出来ない施策です。
　　　　 また、指標化の原則としての“費用対効果が分かること”という条件も
加わってきます。
上野氏：面白くなってきましたね。顧客の視点からの施策の検討から早速、始め
ましょう！！

第９７回はここで終了します。
今回は事業施策の経営管理指標化の前提論議でした。
次回は、顧客の視点以下の経営管理指標を作成検討として「経営管理指標の作成
　ＢＳＣ視点の指標」としてその課題を取り上げます。

Comments(0)

　今日は、昨日の経営管理指標化の作成原則を基に「顧客の視点」の施策から指標
化を検討・討議中です。
　山田氏：指標化の作成原則は「計数化できること」、「ビジネスプロセス上で
　　　　　収集できる」、そして「費用対効果が分かること」かな。
中川氏：この3つの原則を当てはめて考えてみましょう。えーと、顧客の視点の
施策は上位施策が「顧客満足度の向上」、下位施策は「顧客内部門取引
シェア向上」、「保守サービス契約の増大」でした。上位施策はやりま
したので、下位施策の「顧客内部門取引シェア向上」からです。
　　　　　（注）顧客内部取引シェア：顧客の部門数に対する取引部門の数の比率
　上野氏：この管理指標は顧客内シェアを目標とし、顧客内シェア比率で良いと思
いますね。3つの原則を満足しています。
　　　　　「保守サービス契約の増大」もそんなに難しくありませんね。年間保守
契約数を目標にし、年間保守契約増加率を指標とすればいかがでしょ
う。
山田氏：おー、いいじゃないか。意外と簡単だな！
中川氏：そうでもないんじゃないかな？　内部業務プロセスの視点の施策は指標
化には難しそうなのが並んでますよ。
私　　：中川さん、良い感覚されてますね。以前、申し上げたかもしれません
が、「財務の視点」と「顧客の視点」の施策は事業目標の施策なのです
ね。「内部業務プロセスの視点」と「学習と成長の視点」の施策は投資
施策ですから、目的が明確にならないと指標が見えてきません。
上野氏：つまり、施策の達成状態を想定して代替指標を設定するということです
ね。
　　　　 施策には「契約社員のITスキル育成」、「2WayWeb取引コミュニケーショ
ンシステム構築」、「IT保守ヘルプデスク強化」などがありますね。
　　　　 (注) 2WayWeb取引コミュニケーションシステム：インターネットによる
納期確認、商品紹介、見積り等が双方向で出来るシステム
　中川氏：「契約社員のITスキル育成」は研修出席カバー率で良いのかなと思いま
すが、
　上野氏：それじゃ、効果が見えませんよ。出席率を上げればどんな効果が上がる
かを設定しないと指標として有効ではないですか。たとえば、スキル
育成したときの状態である目的を考えると導入生産性や納期遵守率など
が良いのではないでしょうか。
　山田氏：そうだよな。効果の見えない指標を設けても管理していて嫌になり、
本人のモラルも上がらないからな。
　 上野さん、「2WayWeb取引コミュニケーションシステム構築」、「IT保守
ヘルプデスク強化」の管理指標はどう考える。
　上野氏：そうですね。「2WayWeb取引コミュニケーションシステム構築」の施策は
現在大手の得意先と1社と一部の機能を実施している状況です。この仕組
みはお客様に喜ばれていますし、弊社のお客にすべて広がるようにする
とお客様の満足度は向上しますよね。
　　　　 とすれば、このシステムを利用したいというお客様の参加がポイントで
すから「当サービス顧客参加率」としたらいかがでしょうか。
　中川氏：私にも意見を言わせてくださいよ。施策「IT保守ヘルプデスク強化」の
管理指標はお客様とSLA（Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｍａｎａｇｅｍ
ｅｎｔ）契約を結んでますね。だから、この「ＳＬＡの遵守率」として
はいかがですか。後は営業的ですが、どれだけＩＴ購入のお客様に保守
契約を結んでいただけるかの「年間契約顧客率」でしょう。
　山田氏：オッ、意外と論理的な意見！
　中川氏：意外とは何と言うことを・・・（ムットする）
　山田氏：ごめん、ごめん
　私　　：皆さん、完璧。　じゃ、学習と成長の視点の施策の指標化を見ていきま
しょう。

第９８回はここで終了します。
今回は顧客の視点と内部業務プロセスの視点での事業施策の経営管理指標化の
論議でした。
次回は、学習と成長の視点の指標化の作成を行います。「経営管理指標の作成　
学習と成長の視点の指標」を取り上げます。

Comments(0)

　今日は、昨日の「顧客の視点」と「内部業務プロセスの視点」施策の指標化に
　続き、「学習と成長の視点の経営管理指標化の検討・討議中です。

　山田氏：続いて、学習と成長の視点の施策は「営業情報共有システムの強化」、
　　　　　「技術情報共有システム構築」、「先端インフラ技術スキルの育成」が
　　　　　あるな。
　中川氏：「営業情報共有システムの強化」、「技術情報共有システム構築」は
　　　　　営業と、技術の違いはありますが、共に情報共有ですね。情報共有には
　　　　　まず、情報登録が必要ですから管理指標は登録件数としたらいかがで
　　　　　しょう。
　上野氏：それもあるけど、目的から考えるとちょっと管理指標として、それだけ
　　　　　では弱いですね。
　　　　　営業情報共有の目的は提案書の精度向上や提案書作成の生産性向上です
　　　　　し、技術情報共有はシステム導入の精度向上や生産性向上と言うことに
　　　　　なると思います。
　中川氏：なるほど、そうすると営業では「提案成約率」や「提案書作成生産性」
　　　　　などになるかな。
　上野氏：そうだと思います。同様に、技術の方は「導入納期遵守率」や「導入作
　　　　　業生産性」となると思います。
　中川氏：それで良いのじゃないかな。ところで、もう一つの施策「先端インフラ
　　　　　技術スキルの育成」は教育・育成だが、内部業務プロセスの視点にも
　　　　　「契約社員のＩＴスキル育成]で教育・育成があったな。何で、同じ
　　　　　教育・育成なのに視点が違っているの？
　私　　：ここの議論とはズレますが、良い点に気付かれてますね。学習と成長の
　　　　　視点の施策は上位の内部業務プロセスの視点の施策の下位施策ですから
　　　　　社員の育成のための施策になっています。同じ教育・育成でも顧客や
　　　　　取引先に対する施策は内部業務プロセスの視点の施策に含まれることに
　　　　　なります。
　中川氏：分かりました。とすると経営管理指標もそういう観点で設定するわけで
　　　　　すね。
　上野氏：上位整合性が必要なわけですね。ここの学習と成長に視点の「先端イン
　　　　　フラ技術スキルの育成」は上位施策の「IT事業サイクル体制強化（営
　　　　　業）」の下位施策ですから、営業に関係する指標と言うことになります
　　　　　ね。
　私　　：その通りです。
　中川氏：「先端インフラ技術スキルの育成」の施策がうまく行った状態では営業
　　　　　員は先端インフラ技術を駆使して提案書を作成しているでしょうから、
　　　　　その技術を盛り込んだ提案書が多く出ると思われます。管理指標は費用
　　　　　対効果を反映しなければいけませんから、・・・
　山田氏：営業員が先端インフラ技術を盛り込んだ提案書の受注比率として「新技
　　　　　術提案書受注率」なんかではどうだろう。
　中川氏：良いですね。それにしましょう。

　第９９回はここで終了します。
　今回は「学習と成長の視点」施策の経営管理指標化の論議でした。
　次回は、新規事業であるERP事業の管理指標策定を「経営管理指標の作成　ERP
　事業の指標」として取り上げます。

Comments(0)

　今日は、昨日の「学習と成長の視点」施策の指標化に続き、新規事業である「
　ERP事業」の経営管理指標化の検討・討議中です。

　山田氏：ＥＲＰ事業はここの事業部では新規事業ですね。現行事業と比較して、
　　　　　管理指標の作成で留意する点は何かあるかな。
　上野氏：指標化の原則は同じでしょうが、新規事業の施策は売上向上と実績作り
　　　　　に焦点を当てていますから指標化も実績作りに焦点を当てたものにすべ
　　　　　きではないでしょうか。
　中川氏：その通りだな。その点から見ていくと、財務の視点は“売上高”で
　　　　　ＯＫ、顧客の視点の施策は「ＥＲＰ契約顧客の満足度向上」、「納期
　　　　　遵守」、「システム保守サービスの徹底」の３つですね。
　上野氏：「ＥＲＰ契約顧客の満足度向上」はその目的から“顧客契約数”とし
　　　　　ましょう。　「納期遵守」は“納期遵守率”でしょうし、「システム
　　　　　保守サービスの徹底」は導入後のＥＲＰトラブルに対するサービスです
　　　　　から、お客様の安心や信頼を高めることが目的ですね。
　山田氏：とすると、お客様がサービスを受けた方が安心という想いの広がりを
　　　　　測定するために“システム保守サービス加入率”ではどうだろうか。
　中川氏：コンサルタントも頷いていますので、良いと思いますね。それで、内部
　　　　　業務プロセスの視点の施策の「コンピュータメーカとのＥＲＰ協業体制
　　　　　の整備」はどうしよう。　“受注数”かな。
　上野氏：管理指標の“受注数”は顧客の視点で良さそうですね。ここは下位施策
　　　　　でコンピュータメーカ協業が出ていますのでその意味を入れて“ＥＲＰ
　　　　　協業提案比率”などいかがでしょう。
　私　　：なかなか良いですね。新規事業なので、受注の前の協業提案に重点が
　　　　　置かれているのがよく見えますね。
　山田氏：ずいぶん指標化もこなれてきたね。学習と成長の視点の施策の中で２つ
　　　　　の施策「ＥＲＰコンサルタントの育成」と「モニタリング指導スキル
　　　　　育成」を取り上げてみよう。
　　　　　中川さん、「ＥＲＰコンサルタントの育成」の指標はどうしましょう。
　中川氏：ずいぶん難しい施策を言ってきましたね。営業の目からするとＳＥさん
　　　　　にしろ、コンサルタントにしろ、システム導入がスムーズに問題なく
　　　　　導入でき、お客様に感謝されるスキルを付けていただきたいですよ。
　　　　　教育ではそういうプロジェクトの実践経験のある要員が増えることです
　　　　　から管理指標は「ＰＭコンサル要員数」としましょう。
　山田氏：ふーむ。施策目的にあっているし、良いと思うな。中川さん、頭良く
　　　　　なったね。はっはっは・・・
　上野氏：もう一つの施策「モニタリング指導スキル育成」の管理指標を考えて
　　　　　みましょう。
　　　　　ＥＲＰシステムは全社的システムが多いから投資対効果が求められる
　　　　　ことが多いところから出た施策でしたね。
　　　　　そうすると、経営目標やシステム化目標に対する「成果のモニタリン
　　　　　グ」や「成熟度のモニタリング」は必須になりますね。お客様に投資
　　　　　対効果を可視化し納得できるモニタリングとして受け入れていただく
　　　　　ことが必要です。管理指標は「モニタリング実施比率」で良さそうです
　　　　　ね。
　私　　：よく出来ました。どうやら、現行事業、新規事業の施策の経営管理指標
　　　　　化が出来ましたね。
　山田氏：先日、横浜国大の吉川教授の講義を聞いていましたら、業績評価指標と
　　　　　言われてましたが、個々での経営管理指標と同じですね
　私　　：ＢＳＣでは業績評価指標と表現されています。御社で分かり易い方を
　　　　　使ってください。

　第１００回はここで終了します。
　今回は新規事業の「ERP事業部」施策の経営管理指標化の論議でした。
　次回は、策定したビジネスモデルの投資対効果を「事業計画の作成　投資対
　効果」として取り上げます。

Comments(0)

　事業施策、管理指標も定義できましたが、事業企画書（または経営戦略企画書）
　には投資効果による分析が必要です。今日は、投資効果の考え方を議論していま
　す。
　
　中川氏：投資対効果と言うのは、“使った分に対してどれだけ儲けたか”と言う
　　　　　ことですよね。だから、1億円の設備を買って、1億円以上の利益を上げ
　　　　　れば投資対効果は良好と言うことになりますよね。
　山田氏：何か基本的なことが分かってないのでは？
　中川氏：えっ！！　　何が・・・・・・
　上野氏：中川さんの言ったことはＢ／Ｓ（貸借対照表）とＰ／Ｌ（損益計算書）
　　　　　がごちゃごちゃ。
　中川氏：どういうこと？
　上野氏：だって、1億円の設備を買うことは費用じゃなくて、現金が設備という
　　　　　資産に変わっただけで、Ｐ／Ｌにはまったく関係が無いので利益は減ら
　　　　　ないのですよ。
　　　　　投資対効果を見る場合はキャッシュの出入りか収益の増減で判断しない
　　　　　と統一が取れないですよ。
　中川氏：さっぱり分からない。
　山田氏：設備を買うのに1億円という現金を使ったということは測定指標を同じに
　　　　　すると1億円以上の現金が入ってきて投資対効果が高いというべきでしょ
　　　　　う。これは現金、すなわちキャッシュによる投資対効果測定法なの
　　　　　です。
　中川氏：なるほど。
　上野氏：収益で見る場合は、購入した設備が減価償却される費用分を何年の利益
　　　　　向上で吸収できるかを見れば同一指標になるわけです。
　中川氏：減価償却って何よ？
　上野氏：メルマガの基礎編であったでしょう。1億円の設備を買っても、年月が
　　　　　経つと価値が下がるので、その分の価値を減額することを税法上認めら
　　　　　れている費用です。
　中川氏：思い出した！　パソコンを10万円で買って、1年たつと8万円でしか買っ
　　　　　てくれない価値とすると、2万円が減価償却費と言うことね。
　山田氏：その通り。日本では取得価格の１０％が残存簿価なので、1億円だと
　　　　　1千万円が残存簿価。すなわち、9千万円が減価償却費と言う費用の対象
　　　　　になるのだ。
　　　　　収益の観点でみるとこの減価償却費をどれだけ早く利益で回収できるか
　　　　　と言う観点に立てば同一指標として測定できるわけだ。Ｐ／Ｌの視点
　　　　　だな。
　中川氏：２つも、3つも測定法が無くても良いですよ。どっちを使えば良いのか
　　　　　な？
　上野氏：どっちも必要ですよ。利益と言うのはいずれ現金として回収できるもの
　　　　　ですが、変化の激しい現在のような環境では投資の判定はキャッシュ
　　　　　中心の判断でしょうが、事業の収支は収益判断になっていますよね。
　山田氏：そうだな。投資はキャッシュの出入りのキャッシュフロー。ただ経営は
　　　　　収益で見るから利益と言うことだから、事業判断は収益での判断となる
　　　　　な。

　第１０１回はここで終了します。
　今回は「事業計画の作成　投資対効果」として投資効果の考え方の論議でした。
　次回は、事業の投資対効果を損益判断で捉える「投資対効果　損益分岐点分析」
　を取り上げます。

Comments(0)

　今日は事業の投資効果を損益分析で見る手法の議論をしていました。

　山田氏：事業計画はP/Lの視点で収益を捉えるのが基本だから、投資対効果も、
まず損益で分析するのが良いですね。
　　　　　　(注)P/L：Pｒofit＆Loss（損益計算書）
　中川氏：ちょっと整理させてください。今までの話からすると、投資対効果は
“投資により発生する費用を何時までに売上で回収できるか”、と“投資
金額を何時までに現金で回収できるか”の2つの判断視点があるという
ことですね。
　山田氏：その通りです。投資に対する発生費用と売上の分析手法としては、投資
を固定費と変動費で見る損益分岐点分析（B.E.P：Break　Even　Point）
がありますよ。
　中川氏：変動費は売上高に比例する費用と習いましたね。とすると売上高は投資
による売上高の増加分と捉えれば良いと思うのですが、これが投資対
効果とどう関係するのですか？
　上野氏：今回の投資はコンピュータ等の設備、事務所の借用、要員の増強です
から、投資の費用は設備の減価償却費、事務所の家賃、要員の人件費が
投資の主な費用となります。
　中川氏：これらの費用はみんな年度で固定の費用になるから、固定費だな。　
そうか！投資は固定の増加ってこと！！
　山田氏：そういうことですね。良く出来ました。投資効果を損益分析でみると
いうことは、一定期間での固定費の累積を売上増の累積で如何に多く
回収できるかを判断基準とするんだよ。
　上野氏：つまり、一定期間を3期分とすると、固定費の増分がこれからの1期、
2期、3期目でそれぞれ500万円、300万円、200万円としたとき、累積の
費用は1000万円になりますね。これに対し、3期までの売上増の累積が
1200万円の事業と1500万円の事業があった場合、1500万円の事業の方が
投資対効果が優れていると判断するということですね。
　山田氏：その通りですよ。
　中川氏：上野さんに数字を挙げてもらってはじめて分かった。私、観念的な議論
は苦手。
　私　　：損益分析による投資対効果分析はこれで良いでしょう。事業計画として
は必要な分析ですね。しかし、現在はDCF法による投資対効果分析が主流
になってきていますね。
　山田氏：トップからも指示がありましたよ。個々の投資に対する投資対効果の
判定にはこのDCF法による算定法が義務付けられました。
　　　　　（注）DCF：Discount　Cash　Flow（現在価値法）

第１０２回はここで終了します。
今回は「投資対効果　損益分岐点分析」として損益分析による投資効果の手法の
論議でした。
次回は、事業の投資対効果をキャッシュフロー判断で捉える「投資対効果　DCF
法」を取り上げます。

Comments(0)

　投資効果の算定法の続きでDCF法に対する議論が進んでいます。
　上野氏：この投資対効果算定の考え方は使ったお金（現金）をより早く回収でき
る方が高い投資効果とする判定法でしたね。
　中川氏：損益分岐点分析による方法と同違うのですか？同じに見えるのですが？
　上野氏：利益といっても、倒産等があると売掛金を回収できなくなり、損失に
なりますね。利益はまだ現金化されていない架空の資金なのです。
家計簿をご存知ですか。現金の出入りを見ていきますね。投資も現金が
出て行くのですから、“購入して支払ったお金を何時、どれだけ回収で
きるか”の観点に置いた方が精度が高くなることがお分かりでしょう。
　中川氏：投資のときの回収利益には何か妙な架空の資金が含まれているという
こと？
　上野氏：逆ですね。中川さんはちょっと減価償却費の性質を忘れていませんか。
　　　　　投資は固定の増加というのは昨日の討議でした。その中の人件費や
事務所の家賃などは経費として毎月現金支払いが発生しますので損益が
一致します。しかし、減価償却費は設備などの購入時に現金を払います
が、損益には反映しません。
購入後、年度ごとに一定額の減価償却費文の価値が減少します。この
費用は経費に反映させますが、現金は一切出て行きません。
したがって、利益と現金が一致しなくなります。
私　　：つまり、利益の観点で見ると、減価償却費分が利益から差し引かれて
いますので現金はその分少なく表現されることになります。
山田氏：例を挙げてみよう。初期設備投資５００万円、減価償却費１００万円/年
を計上、利益が３００万円とすると、減価償却費は支払うお金ではない
ので、利益から差し引いた１００面円を戻して、現金では４００万円
得られたとする見方ですね。
中川氏：と言うことは、キャッシュフローで投資対効果を考えるときは、初期
設備投資５００万円を利益＋減価償却費の累積が何年で回収できるか
の判定になるのかな？
私　　：その通りです。正確には利益は税引き後利益を使います。
中川氏：了解。ところで、DCF法のDiscountは値引きと言う意味ですよね。
また、日本語訳は「現在価値法」といいますね。この手法による判定
は、今までの議論と何か違いがあるのでしょうか？
　私　　：投資対効果の考え方の違いと言うより、キャッシュの価値の考え方の
違いですね。山田さんいかがですか。
　山田氏：その件は、明日やろう！　皆さん今日はここで終わって、　一杯行き
ましょう！
　
第１０３回はここで終了します。
今回は「投資対効果　DCF法その１」としてキャッシュフローによる投資効果の
手法の論議でした。
次回は、DCF方の続きでキャッシュの価値を「投資対効果　DCF法その２」で捉え
ます。

Comments(0)

　一杯やっても中川氏DCF法の議論での質問を覚えていて、山田氏に再度質問をして
　います。偉いですね。

　中川氏：山田さん、昨日の議論とDCF法の違いは“キャッシュの価値の違い”
　　　　　って、どういうことですか？
　山田氏：それは、同じ100万円でも現在に100万円と1年後の100万円は価値が違う
　　　　　ということだよ。
　　　　　誰だって、来年100万円もらうより、現在100万円もらう方を選ぶでしょ
　　　　　う。何故かと言うと、利殖等によって増やすことが出来るからです。
　　　　　利子は安いけど、銀行に預けて何もしなくても利子が増えるように。
　上野氏：たとえば、利益率１０％の事業を持っていたとしましょう。この事業に
　　　　　100万円を使うと来年は110万円になります。とすれば、来年の110万円は
　　　　　現在の100万円の価値とする見方です。将来の価値を現在の価値に置き換
　　　　　えることから現在価値法と言われています。DCFのDiscountは現在の価値
　　　　　への値下げ逆算になることから付けられたものでしょう。日本語訳の方
　　　　　が良く意味を伝えていると思います。
　中川氏：復習してみると、来年の110万円の現在価値は利益率を10％とした時は
　　　　　110万円を１．１で除した値から100万円の価値とするのか！　
　　　　　とすると、2年先の100万円は（１＋０．１）２で除した91万円ぐらいに
　　　　　なるということになるの？
　山田氏：その通りだね。同様に3年後は100万円を（１＋０．１）３　で除して83
　　　　　万円ぐらいになるということ。
　中川氏：上野さん、昨日の議論と今日の話のDCF法を例を入れて説明してくれませ
　　　　　ん。私は、ちょっとごちゃごちゃ。
　上野氏：分かりました。例として、投資期間3年、初期投資１００万円、１期、
　　　　　２期、３期がそれぞれ税引き後利益-１８万円、１３万円、３７万円、
　　　　　減価償却費が定額法で３０万円、３０万円、３０万円としましょう。
　　　　　現在の事業の利益率は１０％とします。
　　　　　それぞれの期のキャッシュフローは減価償却費を加えると、１２万円、
　　　　　４３万円、６７万円です。そうすると、３年間の収支をキャッシュフロ
　　　　　ーで見ると、－１００万円＋１２万円+４３万円＋６７万円＝２２万円の
　　　　　キャッシュ増になり投資価値があることになります。
　　　　　これをDCF法に直すと、各年度のキャッシュフローを１．１、１．１２、
　　　　　１．１３で除していくので、中川さんちょっと電卓貸してください。
　　　　　えーと、概ね１１万円、３６万円、５０万円ですから、DCF法でのキャッ
　　　　　シュはー１００万円＋１１万円＋３６万円＋５０万円＝-３万円で赤字に
　　　　　なってしまいます。投資価値は無いということになりますね。
　中川氏：なるほど、DCF法はかなり厳しいな。
　私　　：ただ、現在のようにスピードの速い環境化ではこのDCF法が主流になって
　　　　　いますね。

　第１０４回はここで終了します。
　今回は「投資対効果　DCF法その２」としてDCFの手法の論議でした。
　次回は、事業定義が出来ましたので、IT戦略課題を捉え、情報化戦略の検討を
　「IT戦略策定　IT化ステップ」のテーマで捉えます。

Comments(0)

　今日、伺いましたら大騒ぎをしていました。というのは、山田氏グループが全社
の情報システム立案を任され、引き続きIT化戦略プロジェクトを担当することに
なったからです。

　山田氏：大変なことになったな！社長から、“情報に強い会社を作れ”と言われ
ている。
中川氏：社長が言うのですから、経営判断が期待通りに把握できる情報システム
と言うことですよね。
　山田氏：そんなところでしょう。
　上野氏：それでしたら、IT戦略策定の標準プロセスに沿ってやっていったらどう
でしょうか。
　中川氏:えーと、標準プロセスはITCプロセスの改訂版で見ると、「１．フェーズ
の立ち上げ」これはもうプロジェクトメンバーは決まったから良いです
ね。次からは企業内の原稿IT環境を調査・分析する「２．IT領域内部環境
分析」、業界やIT技術動向の環境を調査・分析する「３．IT領域外部環境
分析」、ビジネスモデルに沿ったビジネスプロセスモデルを策定する
「４．目標ビジネスプロセスモデルの策定」、現状とのギャップ分析から
対策をつくり、IT化ベースラインを策定する「５．IT戦略策定」、次フェ
ーズへの申し送り事項としての方針策定である「IT戦略展開」のプロセス
で構成されていますね。
　山田氏：良いじゃないか。そのプロセスを順番に進めていってみよう。上野さん
リードしてくれる。
　上野氏：了解しました。ただ、コンサルタントの井上さん、ご支援お願いしま
す。
　私　　：当然です。　出来る限りのことをさせてください。
　上野氏：では、IT領域内部環境分析からやっていきましょう。
　　　　　この分析は「現行業務プロセス分析」、「現行IT環境分析」、「内部制
約条件確認」で構成され、現行環境分析が主体になります。
　中川氏：要は、現状分析で「現行業務プロセス分析」と言うのは、現状の業務処
理手順がどう処理されているかを調べるということですね。
ただ、この調査は意外と調査が大変ですよ。と言うのは、調査する人が
業務機能を良く知っていないと無理ですから。
　上野氏：そんなことないですよ！　中川さん、忘れていませんか。DMMとDFDを
使えば、業務の意味の分かっている人であれば、1,2年の人でも出来ます
よ。
　　　　（注）DMM：Diamond　Mandara　Matrix　　DFD：Data 　Flow　Diagram
　山田氏：そうか、そうでしたね。じゃ、中川さんと上野さんで全社調査お願いで
きますか。上野さん、3事業所をどのくらいで出来ますか？
　上野氏：午後半日で、各事業部2回で、合計すると6回ですね。
　山田氏：すごい。中川さんは上野さんほど強くないので教育していただけます
か？
　中川氏：DFDも“業務は情報の変換だ”位のキーメッセージは覚えているけど、
具体的にどうやるか分からないのでよろしく。
　上野氏：じゃ、DFDを使った現状業務プロセス調査の方法のガイドを作って説明
しましょう。明日、中川さん、空いてますか？
　中川氏：助かる。午前中１０：００から2時間空いてるけど、それで良いかな？
　上野氏：OKです。じゃ、明日の準備に入ります。

　上野さん、１、2年でも分かるガイドとはどんなガイドを作るのでしょうか

第１０５回はここで終了します。
今回は「IT戦略策定－ITCプロセス」として、IT戦略手順を取り上げました。
　次回は、素人でも出来る現状業務プロセス調査の方法を「IT戦略策定　現行業務
　プロセス調査」のテーマで捉えます。

Comments(0)

今日は「DFDを使った現状業務調査ガイド教育」の日です。上野さんがインストラ
クターで、私がアドバイザー、対象は中川さんですが、山田事業部長も出席され
ています。

中川氏：さて、どんな調査方法をとれば良いのかな？上野さんよろしくお願い
します。
上野氏：分かりました。それでは早速DMMとDFDを用いた調査ガイドを説明させて
いただきます。 今回、EA（Enterprise　Archtecture）で採用されてい
ることもあり、DMM（Diamond Mandara　Matrix）を採用しています。
このDMM手法は初めてなので、これは井上さん（ITコンサルタント）に
解説してもらいましょう。
私　　：皆さんが勉強されたメルマガには出ていませんので、簡単に解説しまし
ょう。上野さんから紹介ありましたように、EAでは既に採用されてい
ます。URLで見てみましょう。⇒　
http://www.kantei.go.jp/jp/singi/it2/cio/dai6/6siryou3-2-3.pdf
　　　　 DMMの構造は縦３、横３の９つのブロックで構成され、中心に調査対象
業務を置き、中心業務を構成するサブ業務を周りの８つのブロックに配置
します。
たとえば、中心ブロックに「販売業務」を配置したDMMは回りのブロック
に「受注業務」「発注業務」「在庫管理業務」「入庫検収業務」「出荷・
売上業務」「請求・入金業務」といったサブ業務が配置できます。
さらに、この中のサブ業務「発注業務」をDMMの中心ブロックに置いて、
周りのサブサブ業務は「発注依頼受付」「発注先選定」「発注書発行」
などの業務が配置すると業務をより詳細化が出来ることになります。
このようにして、調査対象となる業務の範囲を規定するのと業務の詳細
レベルを階層付けするのに使用します。
上野氏：DFDの記述レベルも階層化されていましたが、この階層はDMMの階層レベ
ルと一致させるということになりますか？
私　　：その通りです。通常、現状業務調査では対象業務を2階層の機能レベルの
64個の業務機能に展開してDFDへ連携します。
上野氏：DFDは“業務は情報の変換と捉える”ところに特徴がありました。DFDの
調査ではこれを利用します。データフローである「業務への入力情報」と
「業務からの出力情報」、そして、データストアとしての「参照するファ
イル情報」のみを聞いて記述してください。
中川氏：なぜ、業務処理機能を聞いてはいけないのですか？
上野氏：業務処理機能は調査員の経験の差が大きく出ます。従来の調査方法の
失敗です。情報システムは業務処理機能を変えるわけではありません。
情報の処理方法を改善していくわけですから、情報システムのための調査
では業務機能は情報の変換と捉えて情報ののみに焦点を当てることで、
客観的で精度の高い調査が可能になります。
　　　　したがって、調査順序は最初に、ユーザー部門ヒアリングで、対象業務を
2階層の機能レベルにしたDMMを作成してください。　次にその業務機能の
DFDを記述していただけますか。
　中川氏：DFDでの調査方法は分かったけど、業務上の問題はどうヒアリングする
の？
　上野氏：ありがとうございます。言い忘れてました。　データフローとデータ
ストア情報の媒体（紙、PCデータ、ホストデータなど）と業務処理の手作
業/IT化処理の区別をヒアリングしていただけますか
　中川氏：IT化できていない部分とどんな情報媒体で業務を遂行しているかを調査
するということですね。
　上野氏:その通りです。
　・・・・・・・・・DFDによる調査が開始されました。

第１０６回はここで終了します。
今回は「IT戦略策定－現行業務プロセス調査」として、現行業務プロセス調査
手順を取り上げました。
次回は、IT環境の現状と動向の捉え方として、TRMを参照し、「IT戦略策定　IT動
向調査」のテーマで捉えます。

Comments(0)

今日はベンチマークとしてのビジネスプロセスモデルをどこにするかを検討する
日でしたが、提携メーカーに打合せに言っていた山田事業部長が困った顔でプロ
ジェクトルームに入ってきました。
山田氏：困ったな。メーカーからサプライチェーンシステムの構築をするから、
手伝って欲しいと協力を依頼された。
中川氏：一体何を手伝えば良いのですか？
山田氏：弊社のノードフロー分析をやって欲しいと言っている。
中川氏：ノードフローって何ですか？
山田氏：ノードとはサプライチェーンの中で物流拠点、在庫拠点となる施設や
置き場等を言い、ノードフローとはノードに対する入りと出の物の流れ
を言うらしい。
メーカーとしては、今回のシステムの目標を納期4日、在庫回転日数を
3日に設定している。そのために流通工程にある弊社のノードフローの
サイクルを押えたいということらしい。
上野氏：サプライチェーンは物理的なものの流れですから、まず、顧客に手渡
すまでの流通工程にある工場、販売店、のデリバリー隘路をつかみたい
と言うことだと思いますね。
中川氏：井上さん、隘路って何ですか？
私　　：流通工程において商品が停滞し、流通機能を低下させるノードのある
経路を言います。
例を上げて説明しましょう。サプライチェーンには仕入先、工場、販売
店、顧客の経路がありました。メーカーが販社や顧客から1万台／日の
注文を受けて、工場で組み立てるとしましょう。1万台／日の組み立てて
販社の倉庫に入庫しても、商品倉庫の出庫能力が8000台／日とすると
2000台／日の在庫が倉庫に滞留します。この場合、8000台／日の
供給が限界になります。これが隘路です。具体的には各販社の処理能力
は異なるのが通常ですので、供給したい市場に対し、その能力を有して
いない隘路が数多く存在します。
上野氏：つまり、市場／顧客ニーズを見越した適切な供給のできるノードフロー
能力を有していないと有効なサプライチェーンは構築できないと言う
ことですよ。
私　　：その通りですね。ノードフロー分析依頼もそこに根ざしていると思い
ます。ノードフローの良し悪しは倉庫機能だけでなく、現行の業務プロ
セスやその機能の良し悪しも大きく関係してきます。
上野氏：既に調べた現行業務プロセスのDFDが生きてきますね。
山田氏：弊社の販売物流システムはこのサプライチェーンの中で、業務機能を
捉えていかないと効率の悪いシステムになってくるわけだ。
中川氏：それでは、ノードフローの調査シートを作って調査しましょう。ノード
フローの毎日の入出庫量とノードの業務機能を調査項目とすればよい
ですね。
山田氏：そうです。お願いします。

第１０８回はここで終了します。
今回は「IT外部環境分析－サプライチェーン分析」として、サプライチェーンを
分析するための用件を討議しました。
次回は、「目標ビジネスプロセスモデル策定」を取り上げます。

Comments(0)

　今日は目標ビジネスプロセスモデルの検討日です。山田氏が口火を切ります。
　山田氏：あるべき姿である目標ビジネスプロセスモデルを作成するのだが、作成
　　　　　するための要件を整理しておきたいのだが
　中川氏：経営戦略を策定したときに、情報化テーマとプロジェクトの概算予算が
　　　　　決まっていますね。現行業務プロセスの分析を行いましたので、その
　　　　　ときの課題を改善したプロセスを作成すればよいのではないですか？
　山田氏：それは現状課題改善プロセスとしては良いのですが、上野さんはどう思
　　　　　いますか？
　上野氏：あるべき姿のビジネスプロセスですから、中川さんのおっしゃるのも
　　　　　含めて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戦略策定-ギャップ分析」を取り上げます。

Comments(0)

今日は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 戦略企画書」を取り上げます。

Comments(0)

今日は構築する情報システムのライフサイクルを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戦略企画書」を取り上げます。

Comments(0)

山田氏：さて、来週の経営会議に向けて、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戦略策定プロジェクトは終了です。

Comments(0)

電子政府の業務・システム最適化計画のプロジェクトに参加している
　中で、EAが難しいという意見をよく聞きました。小職も実際の成果物を作る中で
　かなり苦労しましたし、現在もしています。出版物も多く見受けますが、
　“帯に短し、襷に長し”の感があり、そして解説が難しい。

　自分なりにもう少し、わかり易く解説できないものかとの疑問がありました。
　昨年、私のコースの受講生の方からEAの解説をやってくれませんかと要望が
　あり、トライしてみようと思いました。
　今日がEA解説の第1回です。

　日本では、EAはｅ－Ｊａｐａｎ施策の１つである電子政府の「業務・システム最適化
　計画策定指針」に反映され設計が進められており、今年からシステム構築の段階に
　入っていくことになります。
　ｅ－Ｊａｐａｎ施策にはソフトエンジニアリングの研究強化が謳われています。

　日本の政府の試みとしては初めてです。日本でソフトウエアエンジニアリングは大学
　にも学科が少なく、各ITメーカが独自の研究を進めているにすぎませんでした。
　政府の施策としては電子政府プロジェクトでの現在の取組がこの研究と実践に相当す
　ると思います。ガイドラインも公表され、プロジェクトがこのガイドラインに沿って
　進められています。
　さて、これから数十回にわたって発信しますEA解説はこの電子政府プロジェクト
　を中心に、日本のソフトウエアエンジニアリングとしての紹介を目的に進めたいと
　思います。

　そのテーマをご紹介します。
　（１）EAの全体概要
　　電子政府システム構築・維持の考え方/EA出現の背景/電子政府プロジェクトの目的
　　と役割/全体機能体系/BAとその機能/DAとその機能/AAとその機能/TAとその機能/
　　リファレンスモデル
　（２）業務・システム最適化計画策定プロセス
　　全体プロセス概要/現状体系設計プロセス/見直し方針プロセス/将来体系設計
　　プロセス
　（３）業務・システム最適化計画策定プロセスでのメソドロジー
　　・現状分析：DMM/DFD/情報分析（抽象化）/WFA/EEM1/情報モデル
　　・見直し方針：見直し目標・ビジョン/SWOT分析/内部管理業務見直し方針
　　・あるべき業務プロセス/EEM1/DAM/あるべきWFA/ EEM2/ERD/ 情報システム機能構成
　　・移行計画：WFA/ERD/情報システム構成
　以上のテーマです。

　　・「EAの全体概要」ではEA全体を鳥瞰してみようと思います。EAは個々の議論に入る
　　前に全体像をしっかり持っていないとまったく分かりません。その点を押えたいと
　　思います。
　　・「業務・システム最適化計画策定プロセス」では業務・システム最適化計画策定指針
　（ガイドライン）に沿って設計プロセスと設計機能捉えて行きます。
　　・「業務・システム最適化計画策定プロセスでのメソドロジー」では111回までで取り上
　　げたものも多々ありますが、電子政府構築のための使用法には違った
　　発想を取り入れて活用していますので、その観点に焦点を当てようと思います。
　
　第１１２回はここで終了します。
　今回は「EA目次解説」として、今後のテーマを紹介しました。
　次回は「電子政府システム設計スキーム」をとりあげます。

Comments(0)

　最初に、電子政府の業務システムの構築と維持の構造から、EAの考え方を捉えてみま
　しょう。
　この電子政府プロジェクトが発足するとき、業務を最適化して効率的に稼動させる
　ことが目的の1つにありましたが、それ以上に業務システム開発とその運用維持を最短
　に最小費用で達成することを目的としてあげられていました。
　今までは経産省、総理府等１８ある各府省の情報システムは個別に構築されていま
　した。また、業務の設計はITメーカー任せで専門家がいない状態でしたから、開発・
　運用改善などはメーカーの言いなりの提案価格で実施せざるを得ない状態だったし、
　予算が無ければIT化は停滞するしかありませんでした。この状態を解消して効率的
　な業務システムを策定するためには、政府自身で業務要件書を作成しITメーカーにRFP
　の提出を求め、システムを構築するスキルが必要になります。皆さん方も販売システ
　ム構築を手がけるときに、同じ業態であれば以前構築したシステムの流用やパッケー
　ジを考えるでしょう。この考え方をそのまま流用することで電子政府システム構築を
　効率的にしようと考えました。言うは易くですが、そのためには誰でも理解できる
　標準的な設計コンセプト/設計プロセス/設計手法/記述様式/記述手法/コンポネント
　（開発部品）等の標準モデルが必要です。また、ITの専門家がいませんのでその構築
　支援を指導してくれる人材の採用が必要となります。この人材が各府省に民間企業
　から採用されたCIO補佐官です。
　日本の電子政府システム構築の標準モデルとなったのはザックマンモデルを具現化
　し、設計モデルとしていた米国連邦政府のFEA（Federal　Enterprise　
　Architecture）モデルです。
　米国連邦政府のFEAの基本的プロセスは踏襲しましたが、設計プロセスや手法等は日本
　の特性に合わせて改善を加え、ITアソシエイト協議会中間報告で「エンタープライズ
　アーキテクチャ」注１（2002年12月）発表され、2003年12月に設計ガイドとしての
　「EA策定ガイドライン」注２が策定され、2005年2月2日に「業務・システム最適化
　計画策定指針」（ガイドライン）注３の最新版が公開されました。
　参照URL：（注1）　http://www.meti.go.jp/feedback/downloadfiles/i21227mj.pdf
　　　(注2)　http://www.meti.go.jp/policy/it_policy/ea/data/report/index2.html
　　　(注3) http://www.e-gov.go.jp/doc/20050202doc.pdf

　電子政府システムの構築手順は既存の府省システムをEAフレームで設計し、この府省
　モデルを参照モデルとし、新府省業務に適用して構築のスピード化、標準化を図る
　ことになりました。そのために、政府の業務を分析注４され18府省で共通システム化
　できそうな21個の共通業務システムと各府省で独自に構築しなければならない51個の
　個別業務システムがあることが分かりました。参照モデル作りとして、共通業務シス
　テムから「物品調達業務」、「人事給与業務」、「共済業務」等の数個の業務を最初
　のプロジェクトとして、2003年に発足しました。
　　参照URL：（注４）　http://www.e-gov.go.jp/doc/sentei.html

　第１１３回はここで終了します。
　今回は「電子政府システム構築・維持スキーム」として、電子政府の構築背景と考え
　方を紹介しました。
　次回は「EA出現の背景」をとりあげます。

Comments(0)