97話では、UISS/ITSSの利活用に踏み出せない理由を掘り下げてみました。 読まれた方々から多くの同意の声もいただきました。 トップダウン的な理想のアプローチでなくとも、十分に利活用に踏み出せるのです。ユーザー企業・ITサービス企業に係らず、UISSの1構成部品として提供されているファンクションをうまく活用することが、その第一歩になります。
|
|
問題解決型アプローチ |
97話であげた問題点により前に進まない状況の場合、どうすることが考えられるでしょうか? 「現状を知る」というのは大事なことですが、短絡的にスキル診断をしても意味はありません。そうではなくて、せっかくUISSから機能のフルセットが提供されているわけですから、これを使って現状組織の機能的過不足を見極めることが先決です。 ドキュメントやセミナーで繰り返し言われている「経営戦略から入る」というのは、まさしくトップダウン的思考になるので、「トップダウン型アプローチ」と呼びますが、組織機能の検証から入るこの方法は、「問題解決型アプローチ」と呼びます。 機能検証をしてみると、本来持つべき機能が無かったり、実際に必要の無い機能が存在していたりと、現状をかなり可視化することができます。UISSの機能にはスキルがサブセットとして設定されていますから、その機能を実際に実行していくためのスキルセットが明らかになるわけです。
UISSでは「機能役割定義」の名称で組織として必要な機能群とそれぞれのサブセットとしてのスキルセットを提供しています。(図参照) |
|
組織機能検証 |
それでは、実際にどのように進めるのかに入っていきます。 通常それぞれの組織では、実際に遂行されているタスクでの管理がされています。たとえば図のインフラシステム部(右上)では、システム運用のためインフラを受け持っていますが、そのうちのタスクの一つとしてインフラの維持管理があるとします。そのタスクがUISSから提供されているファンクションのどの部分に相当するか検証を進めていくことになります。 UISS提供のファンクション群は網羅的に揃えてありますので、粒度の差はあっても全てのファンクションが存在し、自社のために追加しなくても使えると考えて大丈夫なようになっています。 こうしていくと、タスクごとに主たる機能か従たる機能かも明確になります。 言い換えると、どこまでが責任範囲かを明らかにすることができるということです。 |
|
システム的思考における抽象化 |
システム構築の際には、ほとんどの場合現状分析から入ります。現状がどうなっているか分かっていないと、課題や問題点の理由・根拠が不明確になり、結果的にいいシステムを構築することができない可能性が高いからです。 現状を調査する際には、組織ごとに調査を進めることになります。仕事は組織単位に実施されているからです。言い換えると組織ごとにぶつ切りになった情報からスタートすることになります。 客から注文を受けて商品を出荷し、代金を回収することを考えてみましょう。システムサイドから見ると、客から注文情報が来て、最終的に商品が出荷され、請求して入金があり売り上げを立てるという流れですが、これを組織単位に調べると、次のようになります。 ・営業が客より注文を受け、在庫を調べ引き当てた後に出荷指示書を倉庫に回す。(データインプットする) ・倉庫は出荷指示書に基づき配車手配・在庫情報更新する。在庫量が少ない場合は発注しておく。 ・営業が納品を確認後請求手配をする。 ・経理は請求手配に基づき、請求書を発行する。 入金が確認されれば売り上げに計上する。
このように、組織ごとに細切れの仕事のスタート/エンドが発生しています。つまり、調査はこの単位で行うことになるわけです。これらの情報から組織の枠を取り払い、抽象化(論理化)してファンクションという単位にまとめていくのが、システム構築上流工程の中の機能分析フェーズに当たります。 そしてこの現行ファンクションモデルに、システム要求をぶつけることによって、あるべき姿、To-Beファンクションモデルが出来上がるわけです。
このシステム構築上流工程の考えと同じで、UISSで提供されている機能は、企業におけるTo-Beファンクションを策定するためのテンプレートと考えると、大変分かりやすく捉えることができます。
〜その3に続く |
|
|
|
登録:2011-01-30 15:53:34
|