プロセス・マネージャーの構築プロセス:アーキテクチャーとデザイン・パターン

プロセス・マネージャーは、人材、情報、技術を統合するプロセス・フローを導入し、管理するアプリケーションです。プロセス・マネージャーによって、お客様は組織の生産性を高めるとともに、ガバナンスと準拠要件を満たすことができます。本稿では、ワークフロー・ベースのアプリケーションと対比してプロセス・マネージャーを構築するための設計上の課題について説明します。ここ数年のプロセス・マネージャーの構築で得られた教訓から導き出された業界のベスト・プラクティス・プロセス、利用シナリオ分析、アーキテクチャーとデザイン・パターンの利用を含む方法論を示します。このアプローチと設計方法論は IT に対応したサービス管理ドメインのために記述されたものですが、その全体的設計原理はほとんどのプロセス管理ドメインにとって興味深いものであると思われます。

長年にわたり、企業と組織は、プロセスを、人や組織のエンティティーのコレクションによって行われる作業を調整して順序付ける方法として導入してきました。当初、このようなプロセスはすべて手動で行われていましたが、時間の経過とともに、 ツールを使用してプロセスのコンポーネントが自動化されるようになりました。スループットと効率が重要な考慮事項となっているドメインでは、これらのプロセスの分析や最適化について多くの研究が行われました。¹ このような研究の一般的な例として、オンライン・ストア用のオーダー管理プロセス² または金融機関の融資の組成プロセス³ があります。

各企業は、独自の方法で編成した独自のビジネス・サービスを提供するため、カスタム・ビジネス・プロセスを初めから定義し、それらのプロセスを導入し自動化するためのカスタム・アプリケーションを構築する傾向がありました。これらのアプリケーションは、プロセス・ベースのアプリケーションとして知られています。プロセス・ベースのアプリケーションの中には、ワークフロー技術 (たとえば、Web Services Business Process Execution Language [WS-BPEL ⁴]) を使用して構築され、WebSphere* Process Server ⁵ などの製品によって提供されるワークフロー・エンジンを使用して実行されるアプリケーションがあります。ワークフロー技術を使用して構築されたプロセス・ベースのアプリケーションのサブセットを、ワークフロー・ベースのアプリケーションと呼びます。ワークフロー・ベースのアプリケーションの構築方法 ⁶ (モデル化 ⁷、構築、デプロイメント、および監視 ⁸ を含む) について書かれた文献は、膨大な数に及びます。

近年、ほとんどの業界 (小売、金融、医療、および製造)は、基本的なビジネス・サービスを顧客やエンド・ユーザーに提供する上で、情報技術 (IT) に依存するようになっています。基礎をなす IT インフラストラクチャーの複雑さが増すにつれて、IT に対応するビジネス・サービスの構築、デプロイメント、運用において各サービス管理組織部門 (サーバー・チーム、ネットワーク・チーム、ストレージ・チーム、アプリケーション・チームなど) が行っている作業を効果的かつ効率的に調整することがますます重要となっています。適切なプロセスと調整がない場合、ビジネス・サービスをサポートしている IT インフラストラクチャーに誤った変更が行われると、高い代償が伴うサービスの停止が発生してしまう可能性があります。ビジネス・プロセスに似たアプローチを使用してこの問題に取り組むために、企業はサービス管理プロセスの一部を自動化するために、カスタム・サービス管理プロセスを定義し、カスタム・サービス管理アプリケーション (自社内の変更管理アプリケーションなど) を構築する傾向にあります。このようなカスタム・プロセスとカスタム・アプリケーションを構築して維持していくには大きな費用がかかります。

この傾向は徐々に変わりつつあります。コストや運用上の圧力の増加によって、内部のニーズに対応するために「市販の」ツールを使用してプロセスを導入する方法を研究するようになっています。近年、内部のサービス管理プロセスを改善して標準化するために、IT Infrastructure Library** (ITIL**)^9,10、Control Objectives for Information and Related Technology (COBIT**)¹¹、および enhanced Telecom Operations Map (eTOM**)¹² のような業界のベスト・プラクティスを理解して活用することへの関心が高まりつつあります。また、特定の法的要件への準拠を求める最近の法令 ¹³ も、プロセス・ベースのアプリケーションの使用への関心が高まる要因の 1 つとなっています。これは、プロセス・ベースのアプリケーションを使用することによって、適切な準拠管理が行われていることを示すことができるからです。

このため、企業は、サービス管理プロセスを迅速に導入するために、プロセス・ベースのアプリケーションを構築しているベンダーに目を向けるようになっています。Hewlett-Packard Development Company、L. P.¹⁴ および BMC Software, Inc¹⁵ などのいくつかのベンダーは、サービス管理のためのプロセス・ベースのアプリケーションを提供しています。数百にも及ぶサービス管理ソリューションの実装から得た経験を生かして、IBM サービス・マネジメント戦略 ¹⁶ は、この概念をさらに発展させてプロセス・マネージャー (または PM) として知られている一連のプロセス管理製品を提供しています。プロセス・マネージャーは、1 つの特定のベンダーが一般的なクラスのプロセス管理アプリケーションを具体化したものです。

プロセス・マネージャーの概念

プロセス・マネージャー (PM) は、お客様が自身で初めから構築するよりも速くプロセスを統合して自動化できるように、柔軟で「すぐに使用可能な」ベスト・プラクティス・プロセスの導入を可能にするアプリケーションです。参考文献 ¹⁷ は、IBM サービス・マネジメントの全体的なアーキテクチャーの状況を示すとともに、PM がIBM サービス・マネジメント・アーキテクチャーの他のコンポーネントとどのように関係しているかを解説しています。

IBM サービス・マネジメント・アーキテクチャー内の PM では、実行可能なプロセス・フロー (ワークフロー技術を使用する) を使用することで、そのプロセス内のアクティビティーとタスクが順に実行され、そのプロセス内の正しい時点で正しい情報が適切なユーザーに提供されます。プロセスのタスクが手作業のタスク (自動化された支援を伴うものも含む) である場合、PM はユーザーがそのタスクを実行し、そのプロセスのステップを完了できるように、ユーザー・インターフェースを提供します。さまざまなソースから情報が集約されて、プロセスのタスクを迅速に完了するのに役立つ背景情報がユーザーに提供されます。ツール統合モジュールは、環境に対して処理を行うために (ソフトウェア配布タスクを実行するためなど)、適切な外部ツールとやり取りし、分析対象の情報を抽出して表示するために使用されます。PM は、構成管理データベース (CMDB) 内の構成アイテム (CI) に関する情報を活用し、許可された変更が行われた後に CMDB 内にある情報を更新します。

ここ数年にわたり、IBM Tivoli Release Process Manager¹⁸ や IBM Tivoli Storage Process Manager¹⁹ などのいくつかの PM が IBM によって構築されて出荷されています。

関連する研究

プロセス・ベースのアプリケーションとプロセス管理アプリケーションは、人事管理、サプライ・チェーン・マネジメント²⁰、カスタマー・リレーションシップ・マネジメント²¹ などのドメイン用に構築されています。また、このようなアプリケーションはとりわけ、一般的な要求管理、ルーティング、および承認に主な焦点を置いたインシデント管理、問題管理、および変更管理^14,15 などの IT 管理のドメインにも存在します。

プロセス管理アプリケーションは、さまざまな業界の WS-BPEL エンジン ²² や IBM WebSphere Process Server などのカスタムのワークフロー･ベースのアプリケーションやワークフロー・ベースのランタイムとは異なります。 カスタム・ワークフロー・ベースのアプリケーションは、導入されている特定のプロセスに焦点を置いて、その特定のケースの導入を最適化することができます。その対極にあるワークフロー・ランタイムは、多くの異なるプロセスのテンプレートを実行できるようにするとともに、ロギング、例外処理、エスカレーション管理などのインフラストラクチャー・サービスを提供しますが、それぞれのプロセスの意味構造を理解してはいません。

ところが、カスタム・プロセス・ベースのアプリケーションは、特定のプロセスや特定の顧客のために構築されることが多く、PM は複数の顧客に対して簡単に適用できる必要があります。また、PM は複雑で多様な IT 環境に対応しなければならず、それによって、1 つのプロセス・ドメイン内でさまざまな要求に対して実行される詳細なタスクのシーケンスもかなり柔軟に変更可能であることが求められます。IT 環境でのプロセスの自動化は、多数の技術やツールを PM に統合しなければならないことから、独自の別の課題もあります。この課題に取り組むために、PM は適応可能で、柔軟で、モジュール式で、拡張可能であるだけでなく、各PM がプロセス・フローの一群を効果的にサポートすると同時に、準拠要件と、サービス管理組織 (サーバー・チーム、ネットワーク・チーム、ストレージ･チーム、アプリケーション・チームなど) をサポートするために必要なローカルの自主性のニーズとのバランスをとることができなければなりません。したがって、PM は、特定のプロセス・ドメインの意味構造を理解するとともに、実行時の状況に基づいてフロー・テンプレートやフローの変化の管理などのプロセス管理機能を実行する必要があります。

PM を構築するプロセスにおいて、我々は、重要な機能能力を提供するデザイン・パターンを確認しました。これらの能力には、ベスト・プラクティスの活用、IT 環境におけるプロセス管理の課題への適応、PM 全体にわたる共通性、統合、動作の一貫性の提供などが含まれます。本稿では、PM を構築してお客様の環境にデプロイした経験から得た教訓と、その経験から導き出されたアーキテクチャーやデザイン・パターンについて説明します。

上に戻る

組織は、プロセスを管理するためには、そのプロセスを理解し、文書化することから始める必要があります。組織は、現行のプロセスのセット (現状のままのビュー) に的を絞ることも、望ましいプロセスのセット (将来のビュー) に的を絞ることもできます。したがって、多くの場合、最初のステップは、プロセスの文書を保持するための何らかの形式の文書リポジトリーを使用して、組織のプロセスを把握し、標準形式で編集して文書化することとなります。 IBM では、お客様がそのプロセスを把握し、文書化するのに役立つ Rational* Method Composer ²³ や WebSphere Business Modeler ⁷ などのツールを提供しています。 WebSphere Business Modeler は、プロセス・コンサルタントやビジネス・アナリストがお客様のビジネス・プロセスを調べて最適化するために使用できるモデル化機能、シミュレーション機能、および分析機能も提供します。

既知のベスト・プラクティスから始める

望ましいプロセスのセット (将来のビュー) を決定する場合、初めからスタートして関連するサービス管理プロセスをモデル化し分析することも、公開されているベスト・プラクティスを利用することもできます。IT 対応のサービス管理ドメインでは、業界の一連のベスト・プラクティスが ITIL Library ⁹ という形式で文書化されています。同様のベスト・プラクティスとして、電気通信業界については eTOM ¹² で表されたものがあり、ガバナンス、コンプライアンス、プロセスの改善については、ISO20000 ²⁴、COBIT ¹¹、Capability Maturity Model Integration (CMMI) ²⁵ で表されたものがあります。IBM は、これらの外部に公開されたベスト・プラクティスの徹底的な調査を完了し、そのベスト・プラクティス間の差異を調整し、役割、成果物、入力、出力を識別し、これらを Process Reference Model for IT (PRM-IT) と呼ばれるリファレンス・モデルに文書化しました。

PRM-IT のコンテンツは IBM Tivoli* Unified Process (ITUP ²⁶) と呼ばれるツールで使用することができ、そのコンテンツは IBM Tivoli Unified Process Composer (ITUPC) と呼ばれるツール (図 1 の左側) で作成することができます。

たとえば、ITUP や ITUPC は、変更管理の最上位レベルのアクティビティー (たとえば、変更の受け入れおや分類、変更の評価、変更の承認とスケジューリング) を記述します。これらの各最上位レベルのアクティビティーは、さらに、変更マネージャー、変更アナリスト、変更実装者、変更プロセスの所有者などの役割が明確にされた各ユーザーによって実行されるタスク・レベルのワークフローに分解されます。ITUP は、入出力、主要な成果物、タスクまたはアクティビティーの実行に必要なツールについても記述します。

拡大図

お客様がエンドツーエンドの目標を達成できるようにするために、さまざまなプロセスとツールをどのように連携させるかを示すシナリオが記述されます。たとえば、インシデントがサービス・デスクで記録されて分析され、その問題の診断が行われ、そのソリューションを作成するための変更要求がオープンされ、ソリューションが開発され、最後に、適切なシステム管理ツールによってソリューションが配布されます。

プロセス・コンサルタントは、このような IT に対応したサービス管理プロセスを初めから定義するのではなく、ITUP 内の豊富なコンテンツによって、文書により十分に立証されたベスト・プラクティスのプロセスから開始して、そのプロセスを特定の顧客のニーズに適応させることができます。

プロセス・マネージャーの役割

組織は、ベスト・プラクティス・プロセスを理解し、選択したら、次にそのプロセスを実行する最適な方法を決定しなければなりません。プロセスを自動化する必要がある組織では、多くの場合、ワークフロー・ベースのアプリケーションを初めから構築するには、開発者を雇わなければなりません。このためには、組織は、図 1 の上半分に示されているように、これらのプロセスのモデル化から、シミュレーション、開発、デプロイ、および実行までの全開発サイクルを実施する必要があります。これは、多くの場合、ワークフロー・ベースのアプリケーションを構築するために WebSphere Business Modeler ⁷ や WebSphere Integration Developer ²⁷ などの高度な開発ツールが必要となり、費用のかかる計画となります。

これの代わりとなるのが、特定のプロセスの実装とともに重要なプロセス・フロー管理機能および自動化機能を提供する、事前に構築されたプロセス管理製品 (すなわち、PM) を使用する方法です。このような製品は、費用のかかる開発サイクルを経ずに、IT 運用マネージャーが、必要に応じて PM のGUI (グラフィカル・ユーザー・インターフェース) によってプロセス・フローを直接再構成できるものでなければなりません。再構成されたプロセスは、社内および法的要件に準拠するために、社内のガイドラインとの整合性を保ち続ける必要があります。

PM がインストールされて構成されると、IT 運用スタッフが日々の業務でプロセス・タスクを実行するためにいつでも使用できる状態になります。PM は、タスクを正しいユーザーにルーティングし、そのプロセスに参加している各ユーザーに割り当てられたタスクの進捗状況を追跡し続ける責任を負っています。多くの場合、図 1 の右半分に示すようにプロセス実行メトリックスは、PM そのものにより、また WebSphere Business Monitor などの外部ツールにより、分析およびレポートのために収集されます。これらのメトリックスの分析は、プロセスのボトルネックを理解するために使用され、組織の効率を高めるためにプロセスの再設計に使用することができます。

拡大図

ベスト・プラクティスの実装フローへの変換から得られた初期の結果

最初の波 の PM の構築で、我々は、製品を出荷する前に設計段階まで戻って手直しを行う原因となった、いくつかの教訓を得ました。この点に関わるいくつかの課題を中心に図 2 に示しています。

我々の初期の試行錯誤の結果は、ベスト・プラクティス・プロセスを固定化されたワークフローに文字どおり成文化したものでした。我々は ITIL および PRM-IT のベスト・プラクティスを反映したワークフロー・ベースのアプリケーションを構築することから始めました (他の多くのベンダーの作業と同様)。しかし、お客様は組織のベスト・プラクティスについてそれぞれ独自の考えを持っているため、固定化されたワークフローをアプリケーションに実装することは現実的ではありませんでした。ワークフローを特定のお客様の環境で使用できるようにするためには、修正が必要でした。これは、汎用的 PM 製品を構築するための一連の要件を示すもので、特定の顧客の問題を解決するためのカスタム・ワークフロー・ベースのアプリケーションを構築する際にはほとんど遭遇することのないものです。

また、我々は、組織によって文書化されたハイレベルの参照プロセスと、IT スタッフによって実施される日々のアクティビティーやタスクの間の「ズレ」を発見しました。このようなズレが生じたのは、参照プロセスが日々行われている作業を抽象化したものであり、文書化の観点からは容認できても、組織が詳細なレベルでプロセスを導入し自動化するのを支援する市販用の製品を構築するのに適していなかったからです。

我々はこのズレを理解するために、IT スタッフの日々の作業の分析に時間を費やしました。IBM Global Services (IGS) が運営しているホスティング・センターの詳細な運用プロセスを評価するとともに、いくつかの大規模なお客様の詳細な運用プロセスを評価しました。ある場合においては、ホスティング・センターに新しいサーバーを供給するために IGS が 122 ものプロセス・ステップを経なければならないことがわかりました。これには、さまざまなチーム間での責任の委譲がかなり伴いました。IBM のある大規模なお客様の場合、新しいサーバーを供給するために最大で 43 日間もかかることがありました。責任の所在は、21 のチーム間を移り、これらのチーム間では数回にわたって責任の委譲が行われることがよくありました。たとえば、変更の影響を評価する場合、最終的な評価を完了させるためには、サーバー・チーム、ストレージ・チーム、ネットワーク・チーム、さらに、その他のチームから詳細な評価を収集する必要があります。同様に、デプロイメントのためのワークフローには、サーバーのハードウェア・チーム、サーバーの運用システム・チーム、ネットワーキング・チーム、ミドルウェア・チーム、アプリケーション・チームによって実施されるプロセス・ステップが含まれます。

一連の分析活動で、我々はこの情報と利用可能な成文化されたベスト・プラクティスを比較しました。これらの分析活動の 1 つには、変更管理のためのいくつかの詳細なワークフロー、つまり、変更の評価アクティビティーのワークフローと、変更の承認とスケジューリングのアクティビティーのワークフローが含まれていました。図 3 に、これら 2 つのアクティビティーのための参照プロセス・ワークフローと、その差異、必要とされる改良のレベル、再利用可能なレベルを示します。

拡大図

(A) 変更の評価のフローと (B) 変更の承認とスケジューリングのフロー

これらの参照ワークフローの精査において、変更の評価の場合、参照ワークフローは抽象化のハイレベルであり、日々の業務を反映させるために洗練しなければならないということです。たとえば、処理される特定の種類の変更要求のために、技術の影響評価アクティビティーとビジネスの影響評価アクティビティーをさらに洗練して固有の詳細ワークフローにする必要がある場合です。対照的に、変更の承認やスケジューリングのワークフローをレビューする場合は、我々が予測するあらゆる種類の変更要求に対してすべてのタスクを同じ方法で実行できるほどに、ほとんどのタスクが十分な一般性を備えていることがわかります。

我々の初期のプロトタイピングと分析は、PM が以下のような主要な要件に対応する必要があるという結論をもたらしました。

• プロセスの改良 — 参照プロセスを、ワークフローに変換する前に、組織の日々の作業を表す詳細なレベルにまで改良する必要があります。
• 要求に基づく差異 — 我々は、処理される個々の要求のタイプ、場合によっては、個々の要求の属性に基づいて、必要とされるタスクおよび人が異なることに気付きました。ITIL は大きな変更、小さな変更、または緊急の変更として特徴付けられた変更のためのプロセス・フローの違いを取り込むことができましたが、我々は、この分類は必要ではあっても十分ではないことに気付きました。したがって、要求の分類と区分が必要であり、要求ごとに異なる詳細運用プロセス・フロー (運用手順書フローまたは運用プロセス・バリアントとも呼ばれる) を使用できます。
• 要求固有の自動化タスク — 我々は、処理される要求のタイプによって、プロセス・フローで使用される個々の自動化タスクが異なることに気付きました。たとえば、追加のストレージの変更要求はストレージ管理アプリケーションと統合され、オペレーティング・システムのパッチの変更要求はパッチ・デプロイメント・アプリケーションと統合されます。
• プロセス・フローのモジュール性および再利用 — 我々は、さまざまなアクティビティーのためにプロセス・フローをモジュール化し、さまざまな要求タイプのさまざまなプロセス・フローで再利用できるようにアクティビティー・レベルのフローを構築する必要があることに気付きました。
• フローの構成可能性 — IT 管理にはドメインごとの特殊化が付き物です。ローカルの運用マネージャーや技術主導者が、個々の特定の要求タイプのニーズに基づいて、プロセス・フローを再構成し、変更できるようにすることが必要です。たとえば、新しいオペレーティング・システムをデプロイするためのプロセス・フローは、複雑なアプリケーションをアップグレードするためのプロセス・フローとは異なります。
• 構成可能性とコンプライアンスのバランスを取る — PM は、プロセス・フローが変更される場合でも、Sarbanes-Oxley Act への準拠を報告できなければなりません。このようなコンプライアンス・シナリオをサポートするために、企業のプロセス所有者は、そのプロセスの特定の部分を「ロックダウン」したり、特定の承認に必要なものとしてフラグを立てたりできなければなりません。
• 役割のファミリー — 我々は、参照プロセスでの役割の定義が実質的に役割のファミリーを表していることに気付きました。たとえば、変更マネージャーの役割は、複数の組織に散在する多数の人によって果たされます。ビジネス上の理由で、我々は、変更マネージャーの役割が事業単位で分けられることに気付きました。たとえば、クレジット管理事業部門の変更マネージャーと、ブランチ・バンキング事業部門の変更マネージャーは別々に分けられました。他のケースでは、我々は、技術的な能力に基づく役割の分離に気付きました。たとえば、ネットワークの変更マネージャー、ストレージの変更マネージャー、アプリケーションの変更マネージャーがそれぞれ分離されました。

前述の分析から生じた特定の要件のほかに、多数のお客様の取り組みから生じた要件がいくつかありました。また、新たに登場してきたサービス・カタログを提供するためのオートノミック・コンピューティングや開発中の製品などの新しい技術やイニシアチブも、PM に対する追加要件の主要な発生源となりました。

段階的な自動化のサポートが必要とされました。PM はさまざまなレベルで運用管理製品と統合することができます。深い機能レベルの統合は、最も高度なタイプの統合であり、実現までに最も費用のかかる統合です。すべての製品との深いレベルでの機能の統合を即座に達成することは不可能であるため、段階的な自動化をサポートするアプローチを見つけ出す必要があります。

自動化された機能が存在する場合でも、それが絶対に確実なものとはなりません。可視性の異なる多数の要因が自動化されたアクションに影響する可能性があります。したがって、特に複雑な環境においては、ユーザーは、必ずしも完全な自動化を信頼するとは限らず、最初は自動化の支援によってタスクを実行する方法が必要となります。その後、ユーザーは、システムが信頼を得るのに応じて、徐々にそのシステムに責任を委譲して、人の介在なしにタスクを実行するようにすることができます。

お客様は、サービス・カタログを通じて最終的な顧客 (および内部ユーザー) にサービスを提供し始める際には、既存の運用プロセスを使用して、そのカタログからのさまざまな要求を実行することを期待します。このようにして、サービス要求フローは、特定のサービスを遂行するために常に複数の PM をトラバースする必要があります。したがって、アーキテクチャーおよび設計がサービス・カタログとのシームレスな統合をサポートすることが必要でした。

前述の要件は、PM のアーキテクチャーおよびデザイン・パターンの開発のための主な動機となりました。

上に戻る

我々は、顧客要件および技術要件に対応するために、PM の詳細なアーキテクチャーを作成しました。このセクションでは、そのアーキテクチャーの簡単な概要を示します。以降のセクションでは、新しいドメイン (たとえば、リリース管理) 用の PM を構築するために、このアーキテクチャーをどのように適用できるかについて説明します。

拡大図

PM を構築するには、組織で扱われる要求のタイプと、各要求をサポートするために実行する必要がある特定のタスクおよびアクティビティーのシーケンスについて理解する必要があります。十分に構造化されたプロセスの実装環境では、その詳細なシーケンスは、参照プロセスと同じ最上位の構造に従い、その特定の要求タイプをサポートするための参照アクティビティーおよびタスクの改良を表します。これは、フローのモジュール性および再利用を可能にするための鍵となる設計原理です。

我々はプロセス・フローのバリアントという言葉を使用して、さまざまな要求タイプのタスクおよびプロセス・フローの変形を表しています。最上位のプロセスは、さまざまなタイプの要求のために実行される日々のタスクを反映する多数の詳細運用プロセスのバリアントを持つ可能性があります。これらのフローのバリアントは、PM ではフロー・テンプレートとして表現されます。

図 4 は、PM フロー・テンプレートを構成するためのアプローチを示しています。要求は別々のグループやタイプに分類され、タイプ・レベルの違いが重要となる特定のアクティビティーの場合は、そのアクティビティーを実行するための複数のフロー・テンプレートがあります。たとえば、変更要求を評価するための特定の個々のタスクは変更のタイプによって異なるため、変更評価アクティビティーには 3 つのフロー・テンプレート (B, C, D) があります。ソフトウェアのアップグレード要求には、CMDB 内のアプリケーションの関係を分析して、ビジネス全体への影響を判断するタスクが必要となります。ストレージ要求には、ツールの支援により (ストレージ管理ツールの支援によって行われる) 未使用のファイルを解析するタスクが必要になります。ツールで支援されたタスクは、固有のグラフィカル・ユーザー・インターフェースを備えたカスタム・タスク・タイプによって実装することも、サポートしているアプリケーションへのコンテキストでの起動として実装することもできます。このプロセスの後半の、変更の実装アクティビティーの場合にも 3 つのフロー・テンプレート (F、G、H) があります。各フロー・テンプレートには、統合モジュールを介してシステム管理ツールとインターフェースをとる自動化されたタスクが含まれています。各フロー・テンプレート内の自動化されたタスクは、その要求タイプ特有のものです。たとえば、ストレージのプロビジョニング・タスクは TotalStorage* Productivity Center などのストレージ管理ツールによって処理されますが、アプリケーションのアップグレード・タスクは Tivoli Provisioning Manager などのソフトウェア・プロビジョニング・ツールによって処理されます。この図は、一般的なフローが十分である場合 (たとえば、変更の承認およびスケジューリングのための参照プロセス・フローの我々の分析に基づいて)、フロー・テンプレートのその部分 (特に、そのアクティビティー・フロー・テンプレート) をすべての要求タイプに再利用できるはずであることを示しています。

したがって、エンドツーエンド・プロセス・フロー・テンプレートは、一般的なアクティビティー・フロー・テンプレートと特定の要求タイプに固有のアクティビティー・フロー・テンプレートを含む、個別のアクティビティー・フロー・テンプレートの変形になります。

プロセス・フローの自動化を検討する場合には、参照プロセスを改良して詳細な運用プロセスにすることがいっそう必要になります。我々は、問題に対してトップダウン型のアプローチを行う場合、手作業で行うべき主要なアクティビティーとタスクを識別するために、最初はそのプロセスを完全な手作業のプロセスとして定義します。したがって、一部のアクティビティーやタスクを完全に指定せずに、その意味構造を大まかに定義することが認められます。自動化を検討する場合は、自動化の対象となるタスクの詳細な属性と意味構造を完全に指定することが必要になります。完全に指定されていない場合、そのような試みはうまくいかないか、予期せぬ副次作用をもたらす可能性があります。

プロセスの自動化においては、考慮すべき 2 つの主要な局面があります。1 つはプロセス自身の関数呼び出しを作成することで、もう 1 つはデータにその呼び出しを行わせることです。機能面では、IBM サービス・マネジメントのアーキテクチャー ¹⁶ は、統合モジュールの構成体を使用して、さまざまなシステム管理製品を使用することでインフラストラクチャー・リソースに対するアクションを実行します。プロセス層から統合モジュールへのインターフェースを論理管理操作 (LMO) と呼びます。

統合モジュールへの関数呼び出しには、構成アイテム (CI) への参照が含まれています。構成アイテムは、サーバー、ネットワーク、ストレージ、ソフトウェア、論理的ビジネス・アプリケーションなどの広範囲のリソースを含む管理対象となるインフラストラクチャー内のすべてのものを表す ITIL 定義の用語です。CI に関する情報は CMDB に保管されています。このような情報の一部 (「発見された CI」) は、リソース用のディスカバリー・アダプターまたは Tivoli Provisioning Manager などの他の管理ツールに接続するアダプターを使用することによって、その環境から発見することができます。この場合、一連のリソースに関して発見された情報は、管理ツールから直接インポートすることができます。

PM は、本質的に拡張可能である必要があります。自動化のための特定のシナリオやユース・ケースしか扱えない PM を構築するのは実用的ではありません。大幅な改訂を必要とせずに、追加のシナリオを扱えるように PM を拡張できる必要があります。ストレージのようなリソースは、変更だけのために管理する必要があるのではなく、モニタリング、インシデントの処理、問題の識別、および修正措置を必要とします。したがって、この観点から、それぞれの PM に対する拡張では、ストレージのようなリソースをサポートする必要があります。新しいリソース・タイプは、新しい要求タイプのセット、新しい CI のセット、ディスカバリー・アダプター、タスク・タイプ、フロー・テンプレート、および統合モジュールを作成することによって、このアーキテクチャーで扱うことができます。

上に戻る

このセクションでは、シナリオの分析から始めて、PM を構築するための全体的な方法論について説明します。

ビジネス・シナリオとユース・ケースの分析

たとえば、リリース管理などの新しいプロセス分野のための PM を構築するプロセスについて説明します。ITIL や ITUP で記述されているように、ベスト・プラクティスの観点からリリース管理を捉えることができます。リリース管理における主要なアクティビティーには、リリースの計画、リリースの設計および構築、リリースの承認、リリースの展開の計画、リリースのための連絡、準備、およびトレーニング、リリースの配布およびインストールがあります。

拡大図

たとえば、組織によって管理されるリリースの種類など、このプロセスが適用される、組織、インフラストラクチャー、およびツール関連の状況を考慮する必要があります。ハードウェアのリリースなのか、ソフトウェアのリリースなのか、それとも両方のリリースなのかを考える必要があります。ソフトウェアのリリースの場合、新規のアプリケーションのデプロイメントであるのか、既存のアプリケーションのためのパッチであるのか、または既存のアプリケーションのアップグレードであるのかを考える必要があります。組織が取り組んでいる異なる種類のリリースから、要求の分類 (要求グループおよび要求タイプ) を作成するために使用される情報が得られます。

ここでは、新規のアプリケーションをデプロイしようとしている組織の特定のケースを中心に取り上げることにします。新規のアプリケーションのデプロイメントのための運用シナリオを理解する必要があります。これらのアプリケーションは社内で開発されたものなのでしょうか、あるいはサード・パーティーのベンダーから取得したものなのでしょうか。このアプリケーションをどのようにパッケージ化してデプロイしますか。この組織は、どの配布ツールを使用することを計画しているのでしょうか。どれだけのサイトにこのアプリケーションをデプロイする必要がありますか。このプロセスに関わりを持つ各担当者の役割はどのようなものですか。どのようなタスクを実行する必要がありますか。

リリース管理の問題を図 5 に示します。アプリケーションをアップグレードするための変更要求によって、構成管理システム (たとえば、Rational ClearQuest* や Rational ClearCase* によって提供される構成管理システム) でソフトウェア変更要求が作成されます。社内でのアプリケーション開発が完了すると、そのアプリケーションが運用チームに引き渡され、そこでリリース・パッケージャーがそのアプリケーションのバイナリーを取得し、デプロイメント構成を決定し、デプロイメント・パッケージを作成します。これらのパッケージはテスト環境で検証された後に、複数のサイトで本稼働状態に置かれます。デプロイメントが完了すると、そのアプリケーションの新規のバージョンを反映するために、CMDB が更新されます。

このシナリオをサポートするためには、リリース・プロセス・マネージャーは、アプリケーション・デプロイメント要求のタイプのカテゴリー化をサポートし、特定のユーザーの役割およびアクセス権限のセットを指定できるようにし、詳細なフロー・テンプレートの形式で実行する必要があるタスクのシーケンスを把握し、最上位のリリース管理プロセスの枠内でフロー・テンプレートを構成する必要があります。 このシナリオでは、実行すべき特定のタスクはこのプロセスのアクティビティーの枠内にあります。

また、PM は、特定のソフトウェア・パッケージおよびターゲットを CI として指定できるようにするとともに、確定版ソフトウェアの保管庫 (DSL) の構造をサポートし、Tivoli Provisioning Manager または Tivoli Configuration Managerのようなデプロイメント・ツールへの統合をサポートしなければなりません。プロセス・フロー内の各ステップとやり取りするために、またユーザーが適切なツールによってプロセスの適切な時点でタスクを実行できるようにするためにユーザー・インターフェースを提供しなければなりません。また、複数のサイトにわたるデプロイメント計画を作成する能力もサポートしなければなりません。このようなデプロイメント計画では、サイト、配布単位、担当者、ツール・インスタンス、およびスケジュール枠を示す必要があります。

シナリオおよびユース・ケースの分析は、要求タイプ、プロセス成果物 (DSL、展開計画、配布単位など)、CI のタイプ (ソフトウェア、サーバー、ネットワークなど)、プロセス・フロー、ユーザーの役割、および特定のシナリオをサポートする PM の一部として組み込む必要のある特定の種類のユーザー・インターフェースを決定するのに役立ちます。シナリオが異なる場合、たとえば、サーバー、ネットワーク、およびストレージが関わるリリースを扱う場合は、PM の統合に使用する特定のツールも異なり、フローも異なり、特定のタスクのユーザー・インターフェースも異なります。したがって、正しい PM のコンポーネントのセットを構築するために、詳細なシナリオ分析とユース・ケースが使用されます。これらの要素の組み合わせが、エンドツーエンドのプロセス管理および自動化のサポートを CMDB の統合により実現するための豊富な機能と能力を PM に与えます。

プロセスの成果物、CI、関係

シナリオの分析が完了すると、PM にどのようなプロセスの成果物、CI、関係を構築する必要があるかが、かなり明確になるはずです。詳細設計の次のレベルでは、これらのプロセスの成果物および関係と CMDB に必要とされる CI を表します。ITIL 形式の CMDB では、許可された CI と発見された CI の両方の表現を認める必要があります。この 2 つの比較は、構成監査が実行されるときに、行うことができます。

各 PM には、作成して、管理する必要があるそれぞれのプロセスの成果物があります。プロセスの成果物 (リリース管理のための) の例として、リリース要求、リリースの詳細、リリースの承認、マスター・リリース・カレンダー、配布の詳細などがあります。

また、PM はプロセスの成果物と CI の関係を作成し、維持する必要もあります。たとえば、RFC (要求変更) が特定の CI (たとえば、サーバー x) に対してオープンされる場合は、データベース内に RFC オブジェクトを作成する必要があり、RFC オブジェクトとターゲット・サーバー x 間の関係を表す関係オブジェクトを作成する必要があります。

これらのオブジェクトに組み込まれている情報を PM で使用することによって、特定のサーバーに対してオープンされた RFC のセットに関する情報を表示したり、特定のサーバーに対して行われた変更の履歴を表示したりすることができます。

PM には、プロセスの成果物間の関係を作成し、維持する責任もあります。たとえば、特定のアプリケーションに関わる未解決のインシデントに対応するために RFC を作成することができます。この場合、インシデント・オブジェクトと RFC オブジェクト間の関係を表す関係が作成され、維持されなければなりません。

要求管理

主要なプロセスの成果物と関係が設計されると、次のステップではプロセス・フローを開始する要求を設計することになります。すべての PM は、何らかの要求を扱います。これは、PM が組織によって実施される作業を表し、管理しているからです。プロセスの分野によっては、要求タイプの数が多くなることがあります。この多数の要求タイプを扱うためには、分類階層を作成してタイプの異なる要求を分類するのが有効です。たとえば、変更管理では、要求をサーバー、ネットワーク、ストレージ、アプリケーションなどのリソースの能力に基づいてグループ化することができます。

アプリケーション・グループ内には、変更要求のタイプがさらにある可能性があります。たとえば、新規のアプリケーションのデプロイメント (単一のマシン構成のための単純な J2EE** アプリケーションまたは複数のマシン構成のための複雑な J2EE アプリケーション、ネイティブ Microsoft Windows** アプリケーション、またはネイティブ Unix** アプリケーションなど)、既存のアプリケーションのアップグレード、ミドルウェアのデプロイメント (ハードウェア前提条件の有無に関わらず)、アプリケーションのコンテンツのデプロイメント (HTML [ハイパーテキスト・マークアップ言語]、Word のテンプレート、Excel** ファイルなど)、またはパッチのデプロイメント (オペレーティング・システムのパッチ、ミドルウェアのパッチ、またはアプリケーションのパッチ) などが挙げられます。

要求の分類をレビューしたときに、我々は、要求のタイプによってデータのニーズも異なるということに気付きました。たとえば、新規のアプリケーションをデプロイするために要求側から収集する必要がある情報は、アプリケーションをアップグレードするために収集する情報とは異なります。したがって、各要求タイプには、要求固有の一意の属性セット (すべての要求タイプについて収集される実行依頼者の名前や日付などの一般属性の域を越えた) が関連付けられている可能性があります。

サービス・カタログをデプロイしているお客様の場合、PM 内の特定の要求タイプがサービス・カタログ内の特定のサービス・タイプと対応している必要があり、そのエンドツーエンドのサービス・フローをサポートするためにプロセス・ドメイン内で行われるべき作業の一部を表す必要があります。参考文献 ²⁸ には、サービス・フローとプロセス・フローがどのように関係しているかについての背景情報と説明があります。

実装によって、要求管理が、すべてのプロセス・マネージャーを対象とする単一の (共通の) 要求管理アプリケーションによって処理される場合と、各プロセス分野を対象とするカスタム要求管理アプリケーションによって処理される場合があります。どの実装パスが選択されるかは、要求タイプの指定がどの程度高度であるかと異なるプロセス管理アプリケーションによって提供される拡張属性によって決まります。

プロセス内の作業の表現と管理

要求が指定されると、PM の設計の次のステップではその要求とそれを遂行する特定の方法を関連付けることになります。最初に、ワークフローを実行することによって、目的が達成されるケースを考えることにします。IBM Process Manager は、プロセス・フロー・テンプレートの概念をサポートしています。これらのテンプレートは、特定の要求の目的を達成するために実行する必要があるアクティビティーとタスクのシーケンスを指定します。

フロー・テンプレートのコレクションを使用すると、要求タイプとフロー・テンプレートのマッチング自体が高度な作業になる可能性があります。共通の(デフォルトの) デザイン・パターンは、各要求タイプをデフォルトのプロセス・フロー・テンプレートに関連付けます。高度なケースでは、入ってくる要求の属性に作用するルールのセットに基づいてフロー・テンプレートが自動的に選択できます。この要求の分類は、属性の 1 つにすぎないかもしれません。その他の考慮事項として、要求の緊急度、要求者のタイプ、その要求者が所属する組織、または要求によって影響を受ける CI などがあります。

オートノミック・コンピューティング・シナリオをサポートするためには、各フロー・テンプレートが完全な手作業によるフローから完全に自動化されたフローまでの異なるレベルの自動化を提供するなど、要求タイプごとに複数のテンプレートが定義される可能性があります。単純で標準的な変更のための変更管理プロセス・フローは、完全に自動化されたフローの一例です。このような変更は、事前に許可済みとみなされ、自動的に処理できます。このような場合、そのフローは変更管理プロセスの主要なすべてのアクティビティーを表し、その各ステップは自動的に実行され、記録されます。

プロセスをワークフローの形式で表すことは、表現の 1 つの形式にすぎません。多くの場合、アクティビティー・レベルのプロセスをハイレベルで表すことはできますが、詳細なタスク・レベルのワークフローを事前に成文化することはできないことがあります。たとえば、インシデントが診断される場合、アクティビティー内のタスクの正確なフローが事前にはわかっていることはほとんどなく、インシデント・アナリストが行うインシデントの診断業務に基づいて動的に判断する必要があります。それぞれの分野の専門家であるインシデント・アナリストのチームは、初期の段階の調査結果に基づいてそのチームの別のメンバーに仕事を回すことが必要となる場合があります。そのような場合、すべてのタスクとそのシーケンスを指定する正式な詳細ワークフローを事前に指定することはできないため、ほかの作業割り当て形態や表現がより適切となる場合があります。最上位のインシデント管理プロセスのためのタスクのシーケンスが随時的な方法で決定されるシナリオを、アドホック・フローと呼びます。

ほかの場合では、実行すべき特定のタスクのセットを事前に知ることはできても、完全なワークフローを表すほどの十分な情報を得ることはできないこともあります。このような場合、そのプロセスをタスクの作業構成明細 (WBS) の形式で表すことができます。あるタスクのもう １ つのタスクに対する依存関係が分かっている場合は、デフォルトのタスク・シーケンスを推測することができます (それによって、デフォルトのワークフローが推測されます)。詳細情報がある場合、プロセスの所有者または特定の要求の所有者は WBS 内の情報を増強して条件分岐を追加し、特定のタスクのシーケンスを決定することができます。

プロセスのもう 1 つの表現形式に、フロー・モデルではなく、成果物中心の状態モデルという表現形式があります。状態モデル形式のプロセスの表現は、タスクのシーケンスが主に 1 次プロセスの成果物の状態や遷移によって決定されるため、より直感的になる場合があります。たとえば、変更管理は、1 次プロセスの成果物、すなわち変更要求 (RFC) の状態遷移の形式で表すことができます。

状態モデルは、状態間の遷移を決定するアクションのシーケンス (アクティビティーおよびタスク) ではなく、状態に重点を置いた代替表現です。状態モデルの表現は、「ループバック」をより巧みに処理することができます。たとえば、RFC が拒否された場合は、その RFC を送り返して再分類するか、または再評価することができます。これらの選択肢は、2 つの異なる状態遷移として表すことができます。

PM の設計者は、そのドメインに最も適した特定の表現形式を見極める必要があります。たとえば、リリース管理にはフロー・ベースのモデルが最も適している可能性があり、インシデント管理の場合は、最上位にはフロー･ベースのモデルを使用し、詳細レベルにはアドホック・モデルを使用する組み合わせによって、より適切に処理される可能性があります。変更管理は、成果物中心の状態モデルによって、より適切に処理される可能性があり、資産管理は資産の維持に関連する作業を表す WBS によって、より適切に処理される可能性があります。

汎用タスク・タイプとカスタム・タスク・タイプ

プロセス・マネージャーを構築するために、プロセス・マネージャーの設計者は、ユーザーがタスクを実行するのを支援するユーザー・インターフェースおよびビジネス・ロジックを作成するための最適なアプローチを決定する必要があります。この業界においてプロセス管理アプリケーションを構築するための共通のアプローチは、プロセス管理アプリケーションをフォーム・ベースのアプリケーションとして構築する方法です。そのようなアプリケーションでは、主要なオブジェクトがデータベース形式で表され、そのオブジェクトに関連付けられているビューがフォームのメタフォーを使用して作成されます。プロセス・アプリケーションのユーザーは、属性を表示、変更、入力することによってフォームとやり取りします。これらすべてのケースについて、ユーザーはそのオブジェクトによって提供され、フォーム形式で表示される特定の属性のセットに限定され (または焦点が絞られ) ます。これは、たとえば、特定の変更要求に関して異なるユーザーからの情報の収集、評価、承認などの、特定のプロセスの成果物を管理するタスクを扱う場合にうまく機能する傾向があります。このような場合、プロセス・フロー内のタスクは基本的に、変更要求の承認などのさまざまなアクションをフォームで実行するようにユーザーに指示するタスクです。

このアプローチを使用すると、汎用タスク・シーケンスのセットでプロセス・フローを比較的簡単に構成することができます。この場合、タスクの名前はプロセス内のステップに対応し、そのタスクのユーザー・インターフェースは汎用フォーム・ユーザー・インターフェースです。我々は、このようなタスクを汎用タスクと呼んでいます。

汎用の作業管理タスク自体のそれぞれのタスクに拡張属性を持たせることができるため、このような方法で汎用タスクのよくあるさまざまなパターンが可能になります。汎用タスクのほかに、PM でより複雑なシナリオをサポートするためには、タスク固有の独自の GUIを備えたカスタム・タスク・タイプを提供するとともに、ツールとの対話に基づいてデータを動的に表示することも必要となります。たとえば、ユーザーはプロセスのステップの一環としてツールとの対話が必要となる場合があります。この種の対話は、フォーム技術を使用して成文化することが困難です。より動的なユーザー・インターフェース、つまり、ツールとの対話の結果を表示することができるとともに、ツールから返される情報をユーザーが選択または変更することができるようにして、より状況に応じたプロセスのステップ固有のツールとの対話を行うことができるユーザー・インターフェースが必要となります。そのようなタスクは、専用のユーザー・インターフェースと専用のビジネス・ロジックが組み込まれるため、カスタム・タスクと呼ばれます。

このように、プロセス管理タスクは、特に、システム管理ツールと統合する適切な方法を決定する際に、さまざまなレベルの高度化と自動化をサポートできます。それは、完全な手作業のタスクから完全に自動化されたタスクにまで及びます。完全な手作業のプロセスは、汎用タスクを組み合わせて使用するだけで、実現できます。自動化支援機能を備えているか、あるいは完全に自動化されたタスクについては、カスタム・タスクの必要性が高まっています。

以下に、タスクの実行のために自動化を支援するいくつかの方法を示します。

• ツール・リンケージ・タスク — タスクの実行に使用可能なツールへのリンク (たとえば、URL [uniform resource locator]) を保持している手作業のタスク。ここでのユーザーに対する支援は、ユーザーがツールを自ら探さなくても済むということです。代わりに、具体的なツールとそのツールのホーム・ページがユーザーに示されます。
• コンテキストで起動タスク — 現行タスクからのコンテキスト情報を使用してターゲットURL やリモート管理ツールの特定のターゲット・ロケーションが判断される、支援されたタスク実装。たとえば、CMDB トポロジー・ビュー内で CI をブラウズしているときに、このタスク・タイプによって、ユーザーは別のツール (Tivoli Monitoring など) を起動して、プロセス管理タスクで取り組まれている特定の CI の現行のモニタリングの詳細を取得することができます。
• 手作業の、ツールによってサポートされる自動化タスク — プロセス・フロー内の担当者によって実行される手作業のタスクの一種。このタスクでは、担当者がそのプロセス管理タスクで提供されている GUI によって外部のツールとやり取りします。一例として、タスク固有の GUI を持つ IBM Tivoli Release Process Manager では、ユーザーは Tivoli Provisioning Manager 製品のソフトウェア・デポをブラウズして DSL にインポートするパッケージのセットを選択することができます。この例では、プロセス・タスク実装が統合モジュールにより TPM ツールとインターフェースをとり、TPM ツールを照会し、照会の結果をそのプロセス・タスクで提供されている GUI で表示します。
• 完全に自動化されたタスク — プロセス・フローの一環として完全に自動化された方法で実行されるタスク。たとえば、プロセス内のタスクの １ つは、ターゲット・マシンにソフトウェアを配布するためのタスクです。プロセス・フローのこのステップは、プロセスの初期の段階で収集されたデータに基づいて、ツールによって完全に自動化された方法で行うことができます。

したがって、PM の設計者は、分析された特定のエンドツーエンド・プロセスの自動化シナリオをサポートするために開発する必要がある汎用タスクとカスタム・タスクの特定のセットを決定する必要があります。また、PM の実装では、単一のタスクの複数の実装 (たとえば、手作業による実装、支援された実装、または完全に自動化された実装) もサポートできます。オートノミック・コンピューティング・シナリオでは、個々のユーザーが求める信頼度や快適度のレベルに基づいて、タスクを、自動制御に委ねるメカニズムがユーザーに提供されます。これは、更新を自動的に探し出し、ダウンロードし、自動的に適用するように構成することも、単に更新を探し出し、ダウンロードするが、適用しないように構成することも、ユーザーに更新を通知する以外の処理を行わないように設定することもできる、Windows Update 機能と似ています。同様に、複数のタスクの実装をサポートする PM は、プロセス・フロー内の特定のステップに使用される特定のタスクの実装をユーザーに選択できるようにすることができます。

自動化されたタスク・タイプをサポートするには、ツール統合モジュールを作成する必要があります。この統合モジュールは、汎用タスクの抽象化およびデータをプロセス・レベルでマッピングし (たとえば、ソフトウェアの CI をターゲット CI に配布し)、それを特定のツールによってサポートされている特定の API (アプリケーション・プログラミング・インターフェース) 呼び出しに変換して、その論理演算を実行します。

PM の設計者は、サポートされるカスタム・タスク・タイプの自動化のレベルを決定し、プロセス・ユーザーがやり取りする必要がある各ツールのための統合モジュールを作成する必要があります。

上に戻る

このセッションでは、プロセス・マネージャーに関連したその他の課題、すなわち、Web Services に基づく他のプロセス・マネージャーとの統合と、運用メトリックスと KPI (主要業績評価指標) のリアルタイム表示でのプロセス・マネージャーの使用について説明します。

Web Services による外部統合

PM は、他の PM との対話のほかに、外部のアプリケーションとも対話する必要があります。そのような対話をサポートするために、各 PM は外部システムが PM の機能を呼び出せるようにする Web Service のインターフェースを提供する必要があります。たとえば、Change PM は ChangeManagement ポート・タイプで WSDL (Web Services Description Language) インターフェースを提供し、CreateRFC、QueryRFCStatus、CancelRFC、ModifyRFC などのオペレーションをサポートしています。具体的な WSDL インターフェースは各 PM に固有なもので、特定のプロセス・ドメインの意味構造によって制御されます。

ダッシュボードとレポート

組織が PM を実装する第一の理由は、組織の生産性を高めることにあります。PM は、運用メトリックスと KPI に関するすべての関連情報をユーザーに提供することによって、この要件に対応する必要があります。運用メトリックスには、進行中の変更要求 (RFC) の数、未解決のインシデントの数、インシデントの重大度、インシデントまたは RFC の処理のエンドツーエンドのサイクル時間、プロセス・フローの中で一番時間のかかるタスクなどがあります。

拡大図

この情報は、リアルタイムの「ダッシュボード」またはレポートの形式でユーザーに表示する必要があります。図 6 では、PM にログインしたユーザー用のダッシュボード・ビューの例を示しています。PM は、各ユーザーが担う異なる役割に基づいてそのユーザーが 1 つ以上のダッシュボードを作成できるようにする必要があります。たとえば、図 6 では、ユーザーがサービス・レベル管理者、購買マネージャー、サービス・デスク・マネージャーの役割を担っています。ダッシュボードによって、ユーザーはプロセス・フローの特定の時点で実行するその特定の役割に基づいて適切な情報を集約して表示することができます。

ダッシュボード・ビューを使用してリアルタイムで表示できる情報もありますが、詳細な分析はプロセス・マネージャーのレポート・コンポーネントによってサポートされています。

各 PM は、多数の実行メトリックスを収集します。たとえば、すべてのタスクは実行中にモニターされ、タスクの存続時間、経過時間、保留中のタスクの数などのメトリックはプロセス管理アプリケーションによって保持されます (プロセス・マネージャーが実行される実行時プラットフォームからの情報を使用して)。これらすべてのメトリックは、最終的には、データ・マイニングや主要業績評価指標の分析のために使用できます。組織はこれらのレポートを使用することによって、現行プロセスの問題箇所やボトルネックを理解し、組織の有効性や効率性を高めるためにプロセスの改善に取り組むことができます。

上に戻る

PM を構築するプロセスは、特定のドメインにおけるベスト・プラクティスを理解し、シナリオを分析して構築する適切なビジネス・オブジェクト、要求タイプ、プロセス・フローを決定し、PM のアプリケーションを構成するさまざまなコンポーネントを構築するための演習を経験することから始まります。 本稿では、ここ数年にわたる PM の構築で得た多くの教訓について説明しています。また、新規の汎用プロセス管理アプリケーションを構築する際に PM の設計者が精通していなければならないアーキテクチャーとデザイン・パターンについても説明しています。ここに示している例は IT 管理のドメインから得たものですが、このアーキテクチャー・パターンと設計原理はプロセス管理の他のドメインにも適用できます。

上に戻る

PM を構築する戦略の定義と実施において長年にわたりインスピレーションとフィードバックを提供していただいたチームのメンバーの皆様に感謝申し上げます。特に、Vijay Aggarwal、Arnaud Mathieu、Dave Lindquist、Hari Madduri、Bala Rajaraman、Kyle Harding、Dave Calvert、Anthony Honaker、Praveen Hirsave、John Long、Mike Orr、Alan Lee、Ranjit Nayak、Adam Holey、Jeff Dean、Rob Goodling をはじめとする IBM サービス・マネジメント部門の多くの皆様にお礼申し上げます。本稿で説明されているいくつかの概念は、著者とHari Madduri および Himanshu Desai が共同研究を行った ITIL Rapid Deployment Extensions (IRDE) プロジェクトと呼ばれる社内のプロジェクトに基づくものです。

*IBM Corporation の米国およびその他の国における商標または登録商標です。

**United Kingdom Office of Government Commerce、Information Systems Audit and Control Association、Telemanagement Forum Corporation、 Sun Microsystems, Inc.、Microsoft Corporation、または The Open Group の米国およびその他の国における商標または登録商標です。

上に戻る

1. H. Smith、P. Fingar 共著、「Business Process Management: The Third Wave」、Meghan-Kiffer Press, Tampa, FL (2002 年)
2. F. R. Ricker、R. Kalakota 共著、「Order Fulfillment: The Hidden Key to e-Commerce Success」、Supply Chain Management Review 3, No. 3, 60–70 (1999 年秋)
3. C. M. Hess、C. F. Kemerer 共著、「Computerized Loan Origination Systems: An Industry Case Study of the Electronic Markets Hypothesis」、MIS Quarterly 18, No. 3, 251–275 (1994 年 9 月)
4. 「Web Services Business Process Execution Language Version 2.0」、Committee Draft, OASIS (2006 年 5 月)
5. 「WebSphere Process Server」、IBM Corporation
6. F. Leymann、D. Roller 共著、「Workflow-Based Applications」、IBM Systems Journal 36, No. 1, 102–123 (1997 年)
7. 「WebSphere Business Modeler Advanced」、IBM Corporation
8. 「WebSphere Business Monitor」、IBM Corporation
9. 「IT Infrastructure Library (ITIL)」、Office of Government Commerce
10. itSMF International
11. 「COBIT, Information Systems Audit and Control Association (ISACA)」
12. 「Enhanced Telecom Operations (eTOM) Overview」、TeleManagement Forum
13. 「The Sarbanes-Oxley Act of 2002 (House Resolution 3763)」、United States Congress (2002 年 7 月 30 日)
14. 「HP Open View Service Center Overview and Features」、Hewlett-Packard Development Company
15. BMC Software, Inc.
16. 「IBM Service Management」、IBM Corporation
17. D. Lindquist、H. Madduri、C. J. Paul、B. Rajaraman 共著、「IBM サービス・マネジメント・アーキテクチャー」、IBM Systems Journal 46, No. 3, 423–440 (2007 年、本号)
18. 「IBM Tivoli Release Process Manager」、IBM Corporation
19. 「IBM Tivoli Storage Process Manager」、IBM Corporation
20. 「SAP United States, Enterprise Applications/Business Software Systems」
21. 「Siebel Customer Relationship Management Applications」
22. 「List of BPEL Engines」、Wikipedia
23. 「Rational Method Composer」、IBM Corporation
24. 「Information Technology—Service Management—Part 1: Specification」、国際標準化機構 (ISO) (2005 年)
25. 「CMMI」、Carnegie Mellon University, Software Engineering Institute (2007 年)
26. 「IBM Tivoli Unified Process」、IBM Corporation
27. 「WebSphere Integration Developer」、IBM Corporation
28. A. Ganek、K. Kloeckner 共著、「IBM サービス・マネジメントの概要」、IBM Systems Journal 46, No. 3, 375–385 (2007 年、本号)

2007 年 3 月 26 日に発表許可
2007 年 7 月 3 日にオンライン公開

Chakalamattam Jos (C. J.) Paul
IBM Software Group, Tivoli, 11501 Burnet Road, IBM Tivoli Software, Austin, TX 78758。Paul 博士は、IBM Tivoli の Process Managers のリード・アーキテクトであり、IBM サービス・マネジメント・ポートフォリオの一部である Process Managers のファミリーのアーキテクチャーと設計を指揮しています。重点分野には、プロセス自動化、システム管理、サービス・マネジメント、コンプライアンス、およびガバナンスなどがあります。現職の前は、IBM のオンデマンド自動化戦略とアーキテクチャー、オートノミック・コンピューティング・イニシアチブ、Tivoli のコア・テクノロジー、および WorkSpace on Demand 製品ラインを手がけていました。IBM Autonomic and Tivoli Architecture Board、IEEE、および ACM のメンバーであり、十数件を超える特許を取得しています。Paul 博士は 1993 年に IBM に入社し、当初はマイクロカーネル・オペレーティング・システムに取り組みました。ペンシルベニア州ピッツバーグのカーネギーメロン大学でコンピューター工学の博士号を取得し、チェンナイの Indian Institute of Technology でテクノロジー学士の学位を取得しています。

目次へ戻る

上に戻る