これまでの IT 部門は、リソース固有の組織または機能固有の組織へと成長してきました。歴史的に見れば、このリソース指向の組織構造は、新しいタイプの IT リソースがコンピューター環境に導入されるたびに新しいサポート・チームが結成されてきたことの結果でした。このようなチームは、特定のリソースを管理するためにそれぞれ程度の差はあれ独立に活動し、彼らが開発したプロセスと彼らが調達したツールはそのリソースに特化されたものになりました。これらの特化されたプロセスとツールは、組織の重点がリソース指向の管理からサービス指向の管理へとシフトしたときに足かせになる可能性があります。
この IT 内部の昔ながらの組織構造が原因で、リソース指向からサービス指向への移行において、IT 機能のすべての側面で課題が噴出する可能性があります。概して、ITSM を実装するための課題は、プロセス、人、テクノロジー、およびデータの 4 つの広範な領域に及びます。
プロセス
ITSM 戦略の実装を成功させる鍵は、IT サービスを顧客に提供するための品質プロセスの実装にあります。それらのプロセスの正確な開発と実装が、プロジェクト全体の成功に不可欠です。
ほとんどの IT 組織にとって、組織間で共通の管理プロセスの実装がおそらく ITSM プロジェクトの最も困難な側面になります3。IT スタッフの視点からは、ITSM が登場しても、新しいまたは変更された責任と業績測定基準が導入されただけでは、組織が劇的に変わったようには見えないかもしれません。新しい IT 製品とテクノロジーの導入や古い製品とテクノロジーの段階的廃止は頻繁に行われるため、必要な ITSM 技術インフラストラクチャーの実装は「通常業務」として処理されます。しかし、組織全体に及ぶ日常業務プロセスの実装は、多くの IT スタッフにとって新しい経験である可能性があります。
これまで、IT 組織は、サポート対象のテクノロジーの進化に応じて発展してきました。新しいテクノロジーが導入されるたびに、そのサポートのために新しい組織が設置されます。ビジネスで特定のテクノロジーの使用が増加するにつれて、それをサポートする IT 組織の割合が増加しました。このようなリソース指向の組織が成長するにつれ、組織のリソースをサポートするための独自のプロセスが開発されました4。
IT 組織全体で共通のプロセスを開発し実装するには、以下の手順が必要です。
- プロセスオーナーシップの確立
- プロセス範囲の定義
- プロセス設計に対する合意
- プロセス測定基準の開発
- プロセスをサポートするための技術インフラストラクチャーの設計
- プロセス実装の優先順位の決定
- プロセス実装と関連インフラストラクチャーの計画と実行
ベスト・プラクティスでは、プロセスごとに 1 人の権限のあるオーナーを決定することが求められます。この人物は、プロセス目標の特定、プロセス設計の監督、適切な測定基準の決定、および最終的なプロセスの実装、運用、改善に対して責任を負います。組織をまたがったプロセスの所有を成功させるために必要な知識、スキル、および経歴を持った適切なスタッフの特定に苦労する可能性があります。
プロセスオーナーとして指名された人物は、責任のあるプロセスの範囲を遂行する必要があります。この範囲には、プロセスの制御または影響の下にあるハードウェア、ソフトウェア、人などのすべてのリソースが含まれます。提供されるサービスの内容やプロセスによっては、この範囲が、事業部門やサービスを IT に提供するベンダーにまで拡大される場合もあります。正確なプロセスの範囲定義が重要であり、影響を受けるすべてのグループがプロセス設計と実装計画のレビューに参加する必要があります。
ITSM に必要なプロセス実装の優先順位付けについては、業界内で意見が分かれています。次のような意見があります。
アスベストの管理とは何か
- 最大のビジネス・メリットが得られるプロセスまたはプロセスのグループから始める。
- 継続的支援を確保するために IT のユーザーに対してなるべく早く投資が還元できるプロセスから始める。
- 最初に構成管理と変更管理を実装する。これは、その他の管理が構成管理に依存しており、構成管理と変更管理が密接に関係しているためである。
- 最初にインシデント管理を機能させる。これは、インシデント管理が IT エンド・ユーザー・コミュニティーとの主なインターフェースとなるからである。
- すべてのプロセスを並行して実装する。これは、プロセスが真に独立しているためである。
さまざまなコンサルタント、アナリスト、および著述家が、ありとあらゆる意見を主張しています。いまだ「ベスト・プラクティス」が出現していない以上、特定の ITSM プロジェクトに関与しているマネージャーがプロジェクトの優先方式を決定する必要があります。優先順位付けは、経営管理チームにレビューして同意を得てから、プロジェクトのライフ・サイクルを通して維持する必要があります。
実稼働環境でのプロセス実装の成功は、基本的なプロジェクト管理スキルにかかっています。参加者にそれぞれの役割、プロセス・フロー、および製品の使用方法を教育するためには、詳細な計画が必要です。加えて、事前に実装された管理製品に対する人的インターフェースと技術的インターフェースを特定して確立する必要があります。
プロセスを複数のサイトに実装する必要がある場合は、計画の策定がより複雑になります。大規模なプロジェクトと同様に、実装を困難にする不十分な計� �は、初期運用前にプロジェクトを台無しにします。ITSM とその関連プロセスの実装は会社全体に影響を及ぼす可能性があるため、実装計画は新しい ITSM 運用モデルの受け入れに不可欠です。
人
ITSM 戦略の実装における最も困難な課題の 1 つが、IT 組織やスタッフに対する ITSM の影響です。その結果は、組織の役割や責任におけるシフトから、各 IT スタッフの日常活動における変化にまで及びます。このような人を中心とした変化の特定、計画、および実装には時間がかかります。ITSM を実装したマネージャーは、組織とスタッフ配置に関する課題の解決に作業の 70 ～ 80% が消費されたと報告しています5。
ITSM 戦略に着手したら、組織に必要な変更の真の範囲を理解することが不可欠です。ITSM 戦略の実装は、当然、IT スタッフに影響を与えますが、他にも影響を受ける組織や従業員がいます。これには、今は顧客になっている IT の事業部門ユーザー、現在は IT サポートの一部を提供しているだけの事業部門・スタッフ、製品サポート・サービスを提供するベンダー、支援スタッフであるコンサルタント、および会社との関係が IT に大きく依存しているビジネス・パートナーが含まれます。新しい ITSM 戦略の影響を、実装前に、これらの各利害関係者とレビューして評価する必要があります。
ほとんどの IT 組織にとって、ITSM が要求する変化の範囲は、トップレベルの経営コミットメントを必要とします。そもそも、大部分の IT 組織が階層構造になっています。すべての報告ラインが、最高情報責任者 (CIO) または同等の役職につながっています。戦略として何を勧められても、階層組織では、「上司にとって重要なことが自分にとって重要なことである」という考え方が推奨されます。そのため、ITSM 戦略の実装を成功させるためには、すべての管理レベルからのプロジェクトに対する誠実で明示的なコミットメントが必要です。ITSM プロジェクトの開始時点から、経営幹部や中間管理職がプロジェクトに対する知識と継続的なコミットメントを示す必要があります。日常のプロジェクト管理は委託される場合がありますが、IT スタッフは ITSM に対するコミットメントがトップダウンからのものであり、「それが自分の上司にとって重要なことである」と認識する必要があります。
なぜ経済学者は好むように見えるん
経営幹部が ITSM 戦略に対してコミットしたら、一部の組織的特徴を検証する必要があります。伝統的に、IT 組織は、サポート対象のテクノロジーを中心に形成されていました。ネットワーク・グループやワークステーション・グループのように分けられていました。ITSM を使用すれば、重点が、サービスの提供とサポートという新しい次元にシフトします。サービスをサポートするためにスタッフの全部または一部を再編成するかどうか、サービスのサポートを強化するために現在の構造の運用手順と測定基準を調整するかどうかを決定する必要があります。図 1 は、ITSM の導入によって引き起こされる代表的な組織の変化を示しています。図 1A はリソース指向の IT 組織を示しているのに対して、図 1B はサービス指向の IT 組織を示しています。リソース指向の部門やテクノロジー指向の部門が存続しますが、専任の部門を通して特定の事業部門の IT ニーズの解決に同様の重点が置かれることに注意してください。
図 1. リソース指向の組織の例 (A) とサービス指向の組織の例
拡大図
組織構造の変化に加えて、IT スタッフのパフォーマンスを評価するための測定基準も変える必要があります。リソース指向の組織では、スタッフの評価基準が IT サービスを受け取る顧客の能力に直結していない可能性があります。たとえば、メインフレームの可用性がどんなに優れているとしても、ネットワークが使用可能になっていなければ、顧客は IT サービスを受けることができません。
ITSM 戦略の登場によって、組織の測定基準は、顧客に対するサービス提供の成功を反映したものにする必要があります。
組織内部での新しい戦略の実装における課題の多くは、変化を嫌う人間本来の性向に起因しています6。プレッシャーが大きい環境での組織の変更の実施は、影響を受けるスタッフに歓迎されない可能性があります。そのため、提案されたすべての変更は、徹底的に検証し、特定されたメリットと課題の影響を受けるすべての関係者にレビューし、最も混乱を生じない方法で注意深く実装する必要があります。変更が必要な理由と変更を実装することの重要なメリットに関する戦略全体を理解している IT スタッフは ITSM 実装戦略を支援する傾向が高くなります。
テクノロジー
ITSM ソリューションに必要なテクノロジーは、主に、(1) 構成管理データベース (CMDB)、(2) プロセス・レベルの自動化、および (3) タスク・レベルの自動化の 3 つのコンポーネントで構成されます7。
CMDB
ITIL ベスト・プラクティスでは、信頼できるデータ・ソースとして機能する CMDB の使用が強く推奨されています8。CMDB は、構成アイテム (CI) と呼ばれる管理対象のエンティティーとそれらの関係に関するデータのリポジトリーです9。
ITSM の初期の実装者は、CMDB がまだ市販されていなかったために、独自の CMDB の開発に着手しました。ネットワーク管理ツール・データベースなどの既存の製品データベースをベースに作成されたものもあれば、標準的なデータベース・テクノロジーと製品を使用して開発されたものもありました。特定の製品データベースに関連付けられた初期の CMDB の多くは、ITSM ソリューションに導入した場合にさまざまな種類のリソースをサポートする能力に限界があることがわかっています。今日では、システム管理製品のほとんどすべてのベンダーが CMDB 製品を販売しています。
CMDB を選択する場合に考慮すべきいくつかの側面があります。これには、情報の範囲と奥行きの両方におけるスケーラビリティー、データ現行性、およびデータ保全性が含まれます。現在のテクノロジーに基づけば、大企業が IT 環境内のすべての CI に関する情報の保存を単一のデータベースに依存するのは通常は実用的ではありません。今日の巨大化および高度に複雑化した IT 環境では、このようなデータベースはすぐにスケーラビリティーの限界に達してしまいます。そのため、理想的な CMDB ソリューションでは、一部の CI データ情報 (変更管理に関連付けられたデータなど) を物理的に常駐させ、残りのデータをオンデマンドでアクセス可能なリモート・リポジトリーに保存します。素早くアクセスするためにローカルに保存されたデータとリモートに保存されたデータの間の物理的な分割は、ユーザーから見えないようにすべきです。エンド・ユーザーは、単一のインターフェースを通してすべてのデータにアクセスできる必要があります。
ボルチモア·ガス＆エレクトリックのためメールアドレスです
プロセスの自動化
プロセスの自動化を支援するための製品が数多く市販されています。これらの製品の機能は、プロセス固有のサポート付き製品から、カスタマイズが可能な汎用のワークフロー・エンジンにまで及びます。多くの大企業が、サービス・デスク製品として知られるようになった製品に投資してきました。これらの製品は、問題管理またはインシデント管理用の自動化エンジンとして考案され、変更管理と構成管理を取り込み、今では、さまざまなプロセスをサポートするものがあります。
ITIL とベスト・プラクティス・プロセス・フレームワークの登場によって、サービス指向アーキテクチャー (SOA) などの新しいテクノロジーに基づく製品が導入されています10。これらの製品は、新しい ITIL 指向の市場をターゲットにし、ITIL プロセスの「すぐに使える」(既製)サポートと必要に応じてプロセス・フローをカスタマイズ可能な能力を売りにしています。SOA ベースのツールのメリットは、広範なアプリケーション環境に自然に適合できることです11。場合によっては、同じアプリケーション環境でビジネス・アプリケーションと管理アプリケーションの両方をサポートすることができます。この環境の共有は、長い目で見れば、ソリューションのサポートとその結果としてのビジネス・アプリケーションと管理アプリケーションの統合に有利に働く可能性があります。
このような製品は市場に登場したばかりであり、注意深く検証する必要があります。使用される製品またはテクノロジーに関係なく、ITSM プロセスの自動化インフラストラクチャーには、以下の特性の一部または全部を含める必要があります。
- タスク・レベルでのプロセス・カスタマイズのサポート
- 役割と責任の定義のサポート
- 単一の CMDB または複数の CMDB へのインターフェース
- リソース固有または機能固有の管理ツールのサポート
- ユーザー数などの環境の規模に対するスケーラビリティー
- プロセス品質の向上を実現するためのステータスと業績測定基準の豊富なセット
- 高い可用性と順応性
- 複数レベルのデータおよびアクセス・セキュリティー・メカニズム
タスクの自動化
新しい ITSM プロセスが明確に定義されたら、インストール済みのツール・セットの評価に着手してプロセス・サポートの現在の機能と望ましい機能を判断する必要があります。現行のインフラストラクチャーによっては、プロセス・フロー内の特定のタスクの実行を支援可能なツールが含まれている場合があります。たとえば、変更管理を支援するためのソフトウェア配布ツール、インシデント管理を支援するための監視ツール、キャパシティー管理またはサービス・レベル管理を支援するためのパフォーマンス追跡ツールなどがあります。
プラットフォーム固有であっても、同様の機能を実行する複数のツールが存在する場合があります。たとえば、専門家のチームが特定のプラットフォーム (UNIX**、Linux**、Microsoft Windows** など) を専門に担当している場合は、グループごとにプラットフォーム固有のツールを使用してオペレーティング・システムのロードやソフトウェアの配布を実施している可能性が最も高くなります。明確に定義された変更管理プロセスとリリース管理プロセスが導入されれば、すべてのプラットフォームをサポート可能な単一の製品を使用する方が効率的です。これによって、統合が容易になる (たとえば、3 つの統合点が 1 つになる) だけでなく、CMDB と同期しなければならない外部データ・ソースが削減されます。
プラットフォーム固有のサポート・グループが、プラットフォーム固有のツールから、より汎用的なクロスプラットフォーム・ツールに変えることに反対の場合は混乱が生じる可能性があります。ただし、特定のツールを維持すべきか、より汎用的なクロスプラットフォーム・ツールに投資すべきかの判断は、ビジネス・ニーズに委ねる必要があります。
データ
CMDB の実装では、以下のような複数の要素を考慮する必要があります。
- CI データの粒度レベルの決定
- 複数のデータ・ソースから送られてくる情報のリコンシリエーション
- どのデータをローカルに保存し、どのデータにデータベース・フェデレーションを通してリモートでアクセスするかの決定
- どのデータを積極的に発見し、どのデータを既存のデータ・ストアからインポートするかの決定
CI の特定
CMDB データ・モデルは、すべての CI とそれらの関係を記述するために必要な情報のサポートに十分な柔軟性を備えている必要があります。これには、「コンピューター・システム」や「ビジネス・アプリケーション」などの CI のタイプと、「インストールされている」や「依存している」などの CI 間の関係の両方が含まれます。CI データの細分度は、ビジネス・ニーズによって異なります。ITIL では、ビジネス要件とサービス要件を満たす最高レベルで CI を記述することが推奨されています。ただし、結果として要求される可能性のある最低レベルの CI の理解と、選択された CMDB がそのレベルをサポート可能なことの保証にも配慮する必要があります8。
たとえば、IT サービスが、最初は、「データベース・サーバー Y はコンピューター・システム Z 上にインストールされている」のような情報だけを必要としていたのに、プロセス定義が成熟して IT サービスの理解が進むにつれて、「ビジネス・サービス W はコンピューター・システム Z 上にインストールされたデータベース・サーバー Y に依存しているアプリケーション X で構成されている」のようなより詳細な情報が必要になります。
リコンシリエーション (整合化)
CI 関連データの多くは、既存の運用管理データ・ストア内で使用できますが、複数のデータベース・サーバーに複製することもできます。特定の CI に関するデータによって CI を識別する方法がいくつかあります。たとえば、資産管理ツールではホスト名でコンピューター・システムを識別するのに対して、ネットワーク管理製品ではインターネット・プロトコル (IP) アドレスで同じ物理資産を識別できます。CI データの単一の信頼できるデータ・ソースを提供するには、さまざまな CI 関連データ項目を整合化して、単一の標準化されたフォーマットにマージする必要があります。これは、CMDB を生成するために必要なことです。Distributed Management Task Force (DMTF) Common Information Model (CIM) が、標準的なモデリング・フォーマットの基礎を提供します12。
このフォーマットへのデータの正規化と整合化では、選択された CMDB によって提供される任意の発見メカニズムまたはインポート・メカニズムで、豊富なルールのセットをインポートの一部として呼び出すことができるようにする必要があります。これによって、CMDB 内に CI の一意のインスタンスが 1 つしか存在せず、結合されたデータ・ソースからの属性が最も正確なデータを反映するように優先順位が付けられることが保証されます。
フェデレーション(連合化)
CMDB データを正規化および整合化するための方式が決定したら、どのデータを CMDB に保存し、どのデータを複数のデータ・ストアからフェデレートするかを検討します。データ・フェデレーションは、データを複数のソースから読み出してそれらをあたかも単一のデータ・ソースから読み出したかのように提示する機能です13。
一般的に、まれにしか変化しない CI 属性は CMDB にインポートしてローカルに保存する対象になります。たとえば、「コンピューター・システムというCIの「モデル番号」、「シリアル番号」、「オーナー」などの属性の場合は、ローカルに保存する必要があります。この種の情報は、発見されるか、既存のデータから生成されるかのどちらかであり、CMDB にインポートする対象になります。
より変化の激しいデータの場合は、データベース・フェデレーションがより適切なアプローチになります。データベース・フェデレーションは、現行性と正確性が重要なデータの場合も推奨されています。
ユーザーが多数存在する場合は、データをローカルに保存してフェデレーション・オーバーヘッドを最小限に抑える必要があります。変更管理の制御下にあるデータのように厳密に管理されるデータは、ローカルに保存する必要があります。変更管理の制御下にないデータのような補足的なデータは、フェデレートすることができます。
CMDB のデータの設定
CMDB へのデータの設定は、ITSM の実装に関与するタスクの中でも難しい部類に入るため、ITIL では、できるだけ CMDB の初期ロードを自動化するように推奨しています8。この目的のために、(1) 既存のソースからの収集、(2) 自動発見、および (3) 手動入力の 3 つの CI データの収集方法があります。
ほとんどの企業は、既存のツールを使ってシステム管理情報から生成されたデータ・ストアを利用しています。多くの場合、このデータ・ストアには、環境に関する正確なデータが含まれており、CMDB へのデータの設定に使用することができます。例として、デスクトップ情報が保存されている資産や在庫のデータベースが挙げられます。この場合は、既存のデータ・ストアから自動的にデータを抽出し、その情報を使って CMDB にデータを設定するのが理想的です。オープン・アーキテクチャーの CMDB を使用すれば、データを抽出して XML などの標準形式にフォーマットしてから、CMDB にロードすることができます。
自動発見を実行できない場合は、外部データ・ソースからのデータ抽出も推奨されています。これは、一部の物理デバイスがネットワークからアクセスできないとか、一部の物理デバイスにセキュリティー制限がかけられているなどの理由で、発見ツールそのものが制限される結果である可能性があります。
ビジネス・アプリケーションとサービスの場合は、顧客がサービスを構成するコンポーネントや関係を完全に理解していない場合が多く、自動発見ツールを使用しなければならない可能性があります。このツールは、エージェント・ベースとエージェント・レスのどちらにもすることができます。エージェント関連の誤動作が問題にならない点で、エージェント・レス・テクノロジーの方が� �確です。どんな場合でも、自動発見でオープン・スタンダードを使用して、その処理を実行するための最低限のセキュリティーを備えることが重要になります。
どのデータを発見して、どのデータを既存のデータ・ソースからインポートするかを決定するための単一のアプローチは今のところ存在しません。したがって、CMDB を生成して維持するための実用的なアプローチは、自動発見、既存の信頼できるソースからのデータのインポート、および最低限の手動入力の組み合わせになります。
0 件のコメント:
コメントを投稿