Hamburg by CONTAX G2
----------------------------------------------
前回は クリティークの観点を単なる進捗確認だけではなく、ビジネス目標とIT達成成果との差をチェックする事もやりましょうと書きました。
今回はここをもうちょっと掘り下げてみたいと思います。
この一連のコラムの中で、企業目標をIT部門の目標にブレイクダウンしておきましょうと言うことは述べておりました。
例えば、
・経営目標:経費節減→IT目標:IT資源の削減
といった具合にです。
実際には「IT資源の削減」だけでは目的が大きすぎますから、これを例えば 「パソコン、サーバ台数見直し」というような業務目標にまで落とし込むわけです。
さらに担当者の作業ベースに分解すると、「サーバーの統廃合」「パソコン環境の見直し」と2つの作業になると思われます。
そして、評価する場合、サーバ統合でどれだけコストが浮いたか、パソコンの方ではどうか、等を勘案して 上位目標の達成度合いを積み上げ評価することになります。
何かプログラムを作る場合では、
・経営目標:経費節減
→IT目標:リアルタイムで在庫把握できるシステムの整備
→IT業務目標:在庫モニタリングシステムの新規構築
→IT作業目標:拠点間サーバの同期プログラムの開発
というようにブレイクダウンされます。
ここでもし、「拠点間サーバの同期プログラムの開発」がリアルタイムではなく技術的な理由でバッチベースに変更されてしまうと当初の目標に対してどういった影響が現れるかを評価しておくことが大切、というのが前回の主張でした。
さらにもう1つ、アプリケーション開発の場合、「経営目標」と「IT目標」の間に、「ビジネス目標」を入れる必要があります。
「経費節減」→「システム構築」と一足飛びになっていますが、実施には経費削減のために行うべき「日常業務活動」の観点が入っているはずです。
”システム構築”は当に”道具”の整備であって、「日常業務活動」すなわち”在庫量のモニタリングと適正化活動”の一部である事を認識しておく事が重要です。
つまり、経営者の立場からは、「在庫量のモニタリングと適正化活動」が軌道に載ったかどうかが重要視されることになります。
IT部門の視点では「リアルタイムで在庫把握できるシステムの整備」が出来たかどうか、もしくはITで実現できなかった事を別の”仕掛け”で代替できたかが評価されるべきことになります。
こうしておかないと、「拠点間サーバの同期プログラムの開発」が出来なかったので、「在庫低減できませんでした」という非常に間の抜けた説明をしなくてはなりません。
当然、経営者も「プログラム開発が出来なかったから経費が減らなかった」という非常に間違った認識を持つことになります。
アプリケーションの是否を評価するときは、必ず「業務活動」の視点で行う事を徹底させてください。道具の出来不出来がビジネスの正否を左右するのは事実です。しかしビジネスの正否を評価する場合には、道具が「ビジネス戦術」の付帯物である以上、当該の「ビジネス行動」全体で成果を判定しなければ本末転倒になります。「道具の出来」は懸案事項の1つとして取り扱うのが望ましいと思うのです。
-ende-
最近のコメント