|
RUPの拡張: エンタープライズ・ビジネスモデリング作業分野 |
 |
このホワイトペーパーの題材は、Scott W. Ambler、John Nalbone、Michael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。 |
ビジネスモデリングは RUP の一部として組み込まれています。現在の RUP のビジネスモデリング作業分野では、プロジェクトの適切な対象範囲を明らかにし、システムが業務の中にどう組み込まれて業務をサポートするかを示すことで、特定のプロジェクトに関する組織のビジネス構造とプロセスを捉える視点を提供します。これはプロジェクトにとってはきわめて重要なことですが、企業全体にとってはそれだけでは十分とは言えません。エンタープライズ・ビジネスモデリング作業分野に含まれる作業は、RUPのビジネスモデリング作業分野と同じですが、エンタープライズレベルのものだという点が異なります。公平を期すると、RUP 製品でもエンタープライズレベルでのモデリングの必要性は述べられていますが、RUP にはシステムをまたがった問題を適切に記述するメカニズムが含まれていないため、この概念が十分に効果を発揮しているとは言えませんし、プロジェクト間で情報を共有する方法が明示されているわけでもありません。
IT 組織が成功するためにエンタープライズ・ビジネスモデリングが重要なのには、いくつかの理由があります。
エンタープライズ・ビジネスモデルの開発は、業務全体を広く見ることから始まります。これは、業務全体をモデリングするということではありません。たとえば組織の経理の部分は安定しているので無視するというようなことも可能ですが、1つのプロジェクトの範囲にとどまらないモデルを作成しなければなりません。全体をカバーした浅く広いモデルを利害関係者と一緒に作成することで、業務の基本を捕らえることが目標です。あまり詳細にする必要はありませんが、広く捕らえる必要はあります。どの部分が重要かを明らかにして優先順位を付け、個々のプロジェクトチームのビジネスモデリング作業で詳細に調査できるようにします。エンタープライズ・ビジネスモデルには、ビジネスの概要を正確に高いレベルで定義し、時間が経っても比較的安定している情報を含めなければなりません。たとえば銀行の場合、個人顧客向けの取引を処理しなければならないというニーズは何百年も前からありますが、その処理を行う方法は時と共に劇的に変わっています。高いレベルのニーズは安定していますが、詳細は非常に流動的です。エンタープライズ・ビジネスモデリングの作業では、幅広い問題について調査する必要があり、その結果として、エンタープライズビジネスモデルは実際に次のような小さな成果物の集合から構成されることになります。
エンタープライズビジネスモデリング作業分野のワークフローを図1に示しました。この作業分野を成功させるためにもっとも重要な要因は、エンタープライズ利害関係者との関係です。この利害関係者には、上級IT管理者や上級事業幹部、仕入先、顧客、ドメインの専門家 ( 通常は上級ビジネスアナリスト ) などが含まれます。アジャイルモデリングでは、利害関係者の積極的な参加というプラクティスを奨励しています。利害関係者はタイミングよく判断を下したり情報を提供できるようにするだけでなく、モデリング作業にも積極的に参加しなければなりません。これは、誰もが身につけやすく使いやすい包括的なツールや技法を使っている場合には可能です。包括的なツールには、紙や、ホワイトボード、ワードプロセッサなどがあります。包括的な技法には、本質ユースケースの他、データモデリングやプロセスモデリング用の一般的なモデリング表記法を単純化・簡略化したものなどが考えられます。
図1. エンタープライズ・ビジネスモデリング作業分野のワークフロー
エンタープライズ・ビジネスモデリングで重要なのは、ビジネス戦略全体の定義です。というのも、この戦略をもとにビジネスモデリングの作業を進めることになるからです。エンタープライズ利害関係者と緊密に協力してエンタープライズ・ビジネス戦略を作成してください。この戦略は、業務 ( business ) から引き出し、業務に受け入れられるものでなければなりません。IT だけの戦略ではないのです。
エンタープライズ・ビジネスモデラーは、エンタープライズ利害関係者と緊密に協力して、全社的な目的、達成目標、構想を定義します。これを行う方法としては、ジョイントアプリケーション開発 (JAD) ミーティングのような議事進行型のモデリングセッションや、もっと非公式なアジャイルモデリングセッション、1 対 1 の面談を個別に行う方法などがあります。目的や達成目標は一般に、「今四半期に 2% (達成目標)以上、銀行の法人顧客数を増やす(目的)」といった短期的なもので、たいていは定期的に見直されます。「管理資産ベースで北米最大の個人・法人向け銀行になる」といった構想は、一般的に長期的なものであり、時間が経ってもあまり変わりません。全体的な構想を持つことは重要です。どこに向かっているかが分からなければ、そこにたどり着くことはできないからです。
ビジネスプロセスのモデリングは、この作業分野にいくつか含まれるモデリング作業の1つです。このワークフローの詳細を図2に示しています。ビジネスプロセスモデリングの作業は、Zachman フレームワーク (ZF) の「作業 (How) 」の列を扱うもので、全社的なミッションやビジョンを反映しなければなりません。ビジネスプロセスモデルには次の内容を記述します。
図2. 「ビジネスプロセスをモデリングする」ワークフローの詳細
私たちの経験では、よくできたエンタープライズ・ビジネスプロセスモデルは、完全にとは言わないまでも大部分が論理的なレベルのものです。というのも、企業がやり遂げようとしていることの基本部分は時間が経ってもあまり変わらないのに対し、行う事柄の物理的な面はかなり頻繁に変わるためです。また、エンタープライズモデル ( ビジネスモデルとアーキテクチャモデルの両方 ) は、きわめて高いレベルで作成しなければなりません。詳細部分も大切ではありますが、個々のプロジェクトチームに任せた方がよいでしょう。ビジネスルールやビジネスプロセスの細部を(おそらくビジネスプロセス実行言語 ( BPEL ) やオブジェクト制約言語 ( OCL ) を使って)文書化しているとしたら、このレベルにおいては明らかに詳細化しすぎです。
プロセスの自動化の対象範囲を洗い出すことは、エンタープライズ・ビジネスモデリングの大きな要素です。というのも、これによって IT 作業が組織全体のどの部分に位置するかが分かるからです。IT は、それ自体が目的ではなく、業務を効果的に行うための手段だと捕らえなければなりません。業務という文脈で自動化を考えると、技術それ自体を目的に実装することがなくなります。処理の中には完全に自動化されるものも完全に人手で行うものもありますが、ほとんどはその中間です。「プロセスの自動化」という言葉を使うと、手作業で十分な場合、さらには手作業の方が適した場合にまで、ITによる解決策に傾いてしまいがちだと、私たちは考えています。そのため、ここでは「プロセス実装」という言葉を使うことにしました。その他に、この議論の中で、プロジェクトに関する新しい考えが見つかります。この情報は、まったく非公式のプロジェクト提案という形で ( ホワイトボードに書いた数行の文のような簡単なものの場合もあります )、ポートフォリオ管理の計画立案作業に渡されます。
ビジネスプロセスをどうすれば実装できるかを見つけ出すことはある種の技術です。そうでなければ、世界中の書店チェーンが、インターネットによって提供されたチャンスに気付き、自分たちの Amazon.com を作ったはずです。さらに、実装戦略の決定も非常に困難です。その目的は、何を自動化して何を手作業で行うか(手作業のプロセスを改善する方法を探す方がよいこともあります)、そして、さまざまなサブプロセス間でどのような種類のビジネスプロセスの相互作用が必要かを明らかにすることです。
エンタープライズ・ビジネスモデリングの重要な要素の1つに、大雑把なドメイン/概念モデルの作成があります。ここでは組織にとって重要な主要ビジネスエンティティとその関係を表わします。このモデルはあまり詳細に作成する必要はありませんが、情報管理グループのエンタープライズ・データモデリング作業や、プロジェクトチームの要求やビジネスのモデリング作業にとって、貴重な情報となります。どちらの場合も、エンタープライズドメインモデルをもとに、より詳細なモデリング作業を行うことができます。プロジェクトチームが毎回ドメインモデルを新たに作り直す必要はないのです。それと並行して、エンタープライズ業務用語集も作成します。ここでは組織で使われている一般的な用語を定義します。このエンタープライズ業務用語集は貴重な情報源であり、すべてのプロジェクトチームで共有するべきものです。「顧客」のような一般的な業務用語を何度もプロジェクトチームごとに定義するのはばかげています。間違った仮定や不適切なデータにつながりかねないからです。そうではなく、各チームは共通のものとして認められたエンタープライズ・ビジネス用語集を参照し、自分たちの作業に固有の用語だけを定義するべきです。
組織構造こそがビジネスプロセスの実装を可能にするものであり、組織を成功させたいならこの2つを同調させなければなりません。組織モデリングとは組織図を作成することだと考えている人がほとんどですが、組織図は上級管理者の報告系統を示すものです。それも重要な情報ではありますが、出発点でしかありません。本当の組織モデルでは、組織の単位 ( チーム、グループ、部など ) と、主な職位、役職者、それらの人や組織単位が満たす役割と責務、それらすべての間の関係 ( 報告系統と制御フローの両方を含む可能性もあります ) について記述します。
単にエンタープライズビジネスモデルを作成してプロジェクトチームに手渡すだけでは不十分です。十中八九、プロジェクトチームはそのモデルをそのまま無視するでしょう。私たちはこれまでいくつかの組織で開発プロジェクトに携わってきましたが、エンタープライズビジネスモデルが存在することは何度もあったにも関わらず、チームは決してそれを利用しようとは思っていませんでした ( 存在を知っている場合でも同じです ) 。エンタープライズビジネスモデリングを成功させるには、その作業について開発チームに伝え、チームがエンタープライズ・ビジネスモデルを利用できるよう積極的に支援する必要があります。
エンタープライズ・ビジネスモデリング担当者が、プロセスモデリングスキルについてビジネスアナリストを、あるいは一般的な分析やモデリングスキルについてすべての開発者を指導したり教育したりするのは、ごく普通のことです。また、開発チームに(多くはビジネスアナリストの役割で)積極的に加わることも珍しくありません。彼らはその他に、エンタープライズビジネスモデリング用の適切なモデリング指針や標準 ( ガイダンス ) の作成や保守も行います。このガイダンスは、BPMN や UML 2 といった標準のモデリング表記法を抜粋しただけの簡単なものもあれば、モデリング指針の場合もあります。モデリングガイダンスのレビュープロセスには、エンタープライズ利害関係者も加わる必要があります。というのも、エンタープライズビジネスモデルの重要な読者には彼らも含まれるからです。さらにその手引きには、利害関係者が積極的にモデリングに参加できるよう、彼らが理解できるモデルを作成する方法も記述しなければなりません。
 |
本ページの原文（改訂されている可能性があるのでご注意ください）: www.enterpriseunifiedprocess.com/essays/enterpriseBusinessModeling.html Copyright 2004-2007 Scott W. Ambler
|