ＳＣＭパッケージソフト 開発勉強日記です。
SCM / MRP / 物流等々情報を集めていきます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
ビジネスプロセスの標準規格
今日のビジネスプロセス標準規格
たいていの企業のたいていの社員は、仕事の標準規格について気に掛けることがない。彼らの仕事は、それをどのように遂行するかに関する共通の理解と合意を得た多くの約束事と協定に基づき、極めて単純化されたものである。彼らは、その事実に思いをはせることなく、単に仕事をこなしているにすぎない。
- PR -
車の運転では、道路の右側を走ることと左側を走ることの間に、何の違いもない。しかし、特定地域内では、そのいずれを選択するかについて、すべての人間の合意が欠かせない。同様例で別の観点からいえば、ネジ頭の形状数を限定し、2セットのドライバーでほとんどの場合に対応できることで、われわれ全員が恩恵を被っているのである。
筆者（ポール・ハーモン）は、ほかのアドバイザリ・Webページ※1で、ジェフリー・ムーアの技術導入ライフサイクルモデルについて論じたことがある（図1）。
※1 訳注：本稿を含め、筆者が月次発信するBPM論考シリーズ
簡潔にいえば、イノベーターの範疇（はんちゅう）に属する企業は大学や研究機関から直接新しい技術を採用し、それを大きな競争力の源泉となる突破口として活かそうとする。その技術を役立てる方法を見いだすために、膨大なリソースを積極的に投じている。早期導入者は少し遅れて技術を採用し、競合企業より先に用途を開発することで競争優位に立とうとする。
早期多数派に位置する企業は、新技術を導入する前に、その技術の有効性が明らかになるまで待つ。それにより、新技術の実験と未成熟なツールとの格闘に必要なコスト高の努力を回避する。さらに注目されるのは、彼らが標準規格が整うまで待とうとすることだ。別のいい方をすれば、少なくとも技術領域における標準規格開発は、技術ライフサイクルの早期導入者フェイズの期間中にベンダと先行的ユーザーによって遂行される活動なのである。
図1 ジェフリー・ムーアの技術導入ライフサイクル
標準規格開発への取り組みに関心を持つ企業は、そう多くない。たいていの企業は、技術の普及体制が整うころには標準規格も完成しているはず、と見込んでいるのだ。数年内に有効な標準規格が作成できなかったために、キャズム※2に落ち込み消え去る技術もある。
※2 編注：リリースできなかったとすれば、死の谷というべきかもしれない
標準規格について考えるときに念頭に置かなければならないもう1つの事柄は、デファクト・スタンダードとデジュアリ・スタンダードの違いである。デジュアリ（公的な）・スタンダードは、標準規格機関や業界コンソーシアムによって設定される。片や公式的取り決めを求めないコミュニティによって定められるのが、デファクト（実際上の）・スタンダードだ。
例えばMicrosoft Windowsは、90％以上のPCユーザーが依存するマイクロソフトのOSである。それはOSのデファクト・スタンダードであり、PC用ソフトウェアを売ろうとするベンダであれば、それを支持せざるを得ないであろう。
複雑で急速に進展する環境下では、デファクト・スタンダードの方が、デジュアリ・スタンダードよりも重要である場合が多い。デジュアリ・スタンダードの決定には、通常、より長い時間がかかるからだ。別のいい方をすれば、有力なベンダが一般の標準規格に従えない場合に裁定を下すのは市場であり、結局はデジュアリ・スタンダードとなるベンダが勝利を収めるのである。
これらの考察を念頭に置き、今日のビジネスプロセスに関する標準規格について少し述べたい。この論述の整理の仕方として、標準規格を利用する立場に応じ、それらを3つの大きな枠組みに分類してゆくことになろう。
まず、エンタープライズレベル標準規格は、ビジネスマネージャが、事業活動を分析し体系化するために使用する。
プロセスレベル標準規格は、ビジネスマネージャとビジネスプロセス担当者が、ビジネスプロセス変革プロジェクトの実施に臨む際に使用する。ビジネス・プロジェクトの実施には多様な立場の個人が携わるため、この領域の取りまとめが最も難しい。ある場合には、ビジネスマネージャがビジネス改革プロジェクトの実施に当たる。一方、ITビジネス・アナリストその他のIT関係者がプロセス自動化プロジェクトを遂行するといった実態がある。
実施レベル標準規格は、プロセスにかかわる問題のソリューション開発担当者によって使用される技術を特定対象とするものだ。この領域の標準規格の大半は、ソフトウェア開発の方法あるいはソフトウェア・ツールのインターフェイスの方法を定めたIT標準規格である。既存の、あるいは現在開発途上にあるビジネスプロセス標準規格のすべてを包含するのはほとんど不可能なことだが、大局的見地からの概観は持ちたい。
いうまでもなく、筆者はこの論述の構成と標準規格の分類を筆者自身の経験に照らして行った。これらの標準規格を、筆者と異なる様式で整理される方もおられるに違いない。また、筆者の考えで分類した標準規格の中には、ほかの範疇に位置付けてもよいものもあるだろう。いずれにせよ、概観を簡潔に提示することが必要なのだ。
エンタープライズレベル・ビジネスプロセス標準規格
エンタープライズレベル・ビジネスプロセス標準規格は、ビジネス・パフォーマンスの概要把握、評価、およびマネジメントの体系化を支援するツールとして、エグゼクティブとシニア・ビジネスマネージャに使用される。さらに、エグゼクティブ・コミッティ傘下にBPMグループを設置し、同標準規格をマネージャのパフォーマンス評価とプロセス介入優先順位設定のツールとして用いている企業もある。
恐らく、エンタープライズレベルで最も広く用いられているビジネスプロセス標準規格は、キャプランとノートンのバランスト・スコアカード（BSC）による経営評価アプローチであろう。これは事実上のデファクト・スタンダードであり、多様な様式で用いられていると思われる。しかし、多様ではあっても、キャプランとノートンのアプローチの改変版の間には十分な共通項が見られる。もしバランスト・スコアカードを用いているかと問われた場合、たいていの企業は直ちに「イエス」か「ノー」の回答ができるはずだ。
エンタープライズレベルにおいて、最も注目されるビジネスプロセス標準規格が、サプライチェーン・カウンシルのSCORフレームワークと方法論である。SCORは、複数企業にまたがるサプライチェーン・プロセスを構築し評価するためのツールとして、サプライチェーン・マネージャたちによって開発された。バリューチェーン全体の定義、ベンチマーキング、および評価を行うための標準規格として、急速に普及している。その増幅版では、SCOR+とSCOR/DCOR/CCOR（サプライチェーン・モデル、デザインチェーン・モデル、カスタマーチェーン・モデルに対応）の、いずれかの名称が使用されるようになった。
今後数年間には、プロセスセントリック・アプローチを導入するシニア・エグゼクティブが増加する。これに伴い、SCOR+の重要度も増すに違いない。
VCORは、SCOR+と非常に類似点が多いが、もう1つの異なるアプローチだ。eTOMは、テレコム業界向けに特別に作成されたフレームワークである（今後は、ほかの業界でも、同様のフレームワークが作成される可能性が大きい）。
エンタープライズレベルで時々用いられる、もう1つの標準規格が、ソフトウェアエンジニアリング・インスティチュート（SEI）のケイパビリティ成熟度統合モデル（CMMI）である。CMMIをITプロセスのパフォーマンス評価に用いているケースが圧倒的に多く、この場合には、CMMIをプロセスレベル標準規格と位置付けるのが妥当であろう。しかし、一部の企業では、すべてのビジネスプロセスを評価し全体組織の動向を見極めるために用いられている。この場合には、エンタープライズレベルのツールとして機能していると見てよい。
さまざまな米国政府機関の支柱になっているのが、連邦エンタープライズアーキテクチャ・フレームワーク（FEAF）だ。FEAFは、ある意味ではエンタープライズ・ツールであり、いくつかの機関がその位置付けで用いている。しかし、ITアーキテクチャ構築のアプローチとして用いられることがほとんどで、この場合には、ザックマンのようなIT実行標準規格の範疇に含められるであろう。
図2に、筆者が想定する主要なビジネスプロセス標準規格の位置付けを示しておく。
プロセスレベルは、全体がプロセスのリデザイン／実施プロジェクトの集積である。このレベルの標準規格は、具体的なプロセスの改革に当たるマネージャ、従業員、ビジネスアナリスト、およびヒューマンパフォーマンス・アナリストを支援する。
これまでに、プロセスレベルで最も広く用いられてきた標準規格は、シックスシグマであった。企業や標準規格機関ごとに多様に定義されてきた、もう1つのデファクト・スタンダードでもある。しかし、たいていのシックスシグマ改変版の間には、容易に認識できる、ファミリとしての類似性がある。シックスシグマは、汎用的プロセス改善手法（DMAIC）と、プロセス改善チームがプロセスの改善に適用できる多彩なツールを備えているのだ。
リーンはプロセスフローの無駄の除去に重点化した別個の手法であり、一般的に、シックスシグマ・チームが取り込むべきツールの1つだと考えられている。従って、恐らく、この標準規格は「シックスシグマ／リーン」と称されるべきなのだろう。
いずれにせよ、多くの大手企業が膨大な数の従業員に対してシックスシグマ教育を行い、シックスシグマ／リーン・アプローチにのっとった数多くの改善プロジェクトを定期的に実施しているのである。
シックスシグマとほぼ同等に普及しているのが、ISO 9000だ（この標準規格は9000番台に関し、多くのバリエーションを持つが、一般的にはこの呼称で通っている）。突き詰めれば、ISO 9000は国際標準規格機構が定めたビジネスプロセス定義の仕様である。ヨーロッパの多くの大手企業と政府が、ISO 9000を用いてプロセスを定義することを企業に義務付けている。
残念なことに、この標準規格は、いまや「チェックリスト」項目でしかなくなってしまった。ISO 9000の文書を手早く作成し、それを棚さらしにしている企業がほとんどだ。今日のビジネスプロセス業務に合わせてISO 9000の意義を高めようとする動きはある。しかし、現状では、企業におけるプロセスの実際的運用に対するISO文書のインパクトは、ほとんど見られない。
米国では、たいていの企業がサーベンス・オクスリー法（SOX法）に対応するための文書作成に取り組んできた。重要な財務上の意思決定に結び付くプロセスを追跡できる体制が整っていることを示すよう、企業に義務付けた米国内法である。ISO 9000と同じく、サーベンス・オクスリー法は、社内プロセスの把握を大きく前進させる機会を企業に与える。しかし、やはり、あまりにも短時間内に処理されてきたのがサーベンス・オクスリーの実態だ。やがて棚の上でISO 9000関連文書のそばで眠る貯蔵品になってしまう可能性が極めて大きい。
最近、OMGがルールの標準規格（および、それに関連するビジネスモチベーション・モデル）を公開した。元はビジネスルールズ・コミュニティ（BRC）で開発されたものだが、企業で用いる語彙、方針、ビジネスルールを定義するための標準規格を定めている。この領域では金融機関の取り組みが非常に活発であり、この標準が、やがて金融機関におけるオントロジーとビジネスルールを確立するためのてことして活かされるであろう。
特定の業界あるいは領域に特化した、いくつかのビジネス・フレームワークは、プロセスチームが既存ビジネスプロセスのデザインと評価を行うのに役立つ。ITIL（ITサポート・プロセスの標準規格）とCoBiT（ITマネジメント・プロセスの標準規格）は、その好例だ。双方に対し、ITプロセスの全社的標準化を望む企業からの関心が高まっている。
この数年、ビジネスプロセス・モデラーが多種多様なワークフロー表記法を用いてきた。その代表例が、IDEF0とラムラー・ブレーシュである。普及度の高いプロセスモデリング・ツールのほとんどが、これらの2つの表記法を支持し、その自社版を提供している。
しかし、いまのところ、ビジネスマンの大多数がよりどころとするデファクト・スタンダードはない。フロー図によるビジネスプロセスの文書化と、遂行すべきタスクを記述した図の読み方に関する社員教育を行っている企業が多いという考察に至れば、標準的ビジネスプロセス表記法に有用性を見いだすことになるだろう。
現時点で最も推奨できるのが、BPMI/OMGのビジネスプロセスマネジメント表記法（BPMN）だ。大手プロセスモデリング・ベンダが結成したチームにより開発されたという点、および、コア・バージョンでビジネスマンが必要とする基本的表記法を提供している点で評価できる。半面、ビジネスプロセス実行言語（BPEL）を作成する機能まで持たせたために、明らかにビジネスマンには必要のない、あるいは理解できない多くの表記法が含まれている点はいただけない。
さらに、現在はBPMNがOMGの管理下に置かれていることから、BPMNをUMLアクティビティティ図に組み込むための作業が求められることになるだろう。それどころか、素朴なフォームを見る限りでは、BPMN/UMLアクティビティ図をラムラー・ブレーシュの図と区別することはほとんど困難で、ビジネスマンに、そのいずれかを選択すればよいと受け取られかねない。しかし、通常はもっと複雑な図で説明されることから、その2つが、いち早くビジネスマンになじみ深いものになっているのだ。こうして、ビジネスモデリングに複数の標準規格が存在することになったが、そのどちらがデファクト・スタンダードになるかは、まだ定かでない。
実施レベルのビジネスプロセス標準規格
ビジネスチームによるプロセスのリデザインが完了すると、その実施に向けた準備に、さまざまの部門が巻き込まれることになる。人事部門は、新しい業務記述書の作成、および人材の新規採用や既存人材の確保を依頼されるであろう。IT部門には、ソフトウェア開発の依頼が行く。資産管理部門は、プラントの再配置、新しいトラックの購入、物流センターの新設などを頼まれるかもしれない。
現時点では、ビジネスプロセス実施標準規格のほとんどが、IT標準規格である。それらは、2つのうちいずれかの目的の下に設定されたものだ。1つは、ITプロフェッショナルが行うビジネス要件の収集とソフトウェア・アプリケーションのデザインや手直しを支援すること。もう1つは、企業におけるプロセス情報の共通データフォーマットでの保存やソフトウェアツール間のモデル転移を、確実に可能にすることだ。
OASISのプロセス実行言語であるBPELは、最も大きな注目を集めてきた。BPELはBPMスイートと密接に連結している。しかし、幅広くとらえれば、実際にBPELを用いて開発されたBPMSアプリケーションはごくわずかであり、BPELに完全依存したアプリケーションは見当たらない。BPELの現バージョンには高度なBPMS開発を支援するには限界があり、BPELを用いるベンダは、いずれもほかのコードでそれを補完しているのだ。BPEL標準規格の進展とともに、この状況は変化するであろう。しかし、現時点におけるBPELは、まだ開発途上段階でしかない。
BPELと密接に関連するのが、ワークフロー管理連盟（WfMC）のXPDLやWorkflow Management Facilityといった標準規格である。これらの標準規格は、ワークフローシステムを支援するために開発された。最終的にはBPEL、あるいはそれに類する言語と統合し、BPMSアプリケーションの支援ツールにまでの拡充が必要になることが見込まれる。数年後には、その動きが見え始めるであろう。
OMGのUMLは、明らかにソフトウェア開発者のための表記法システムとして開発されたものだ。MDAとTOGAFはともに、BPMSにより作成されるSOAアプリケーションの構築に用いられる。また、OMGのプロダクションルール仕様が、ゆくゆくは推論ベースのシステムにビジネスルールを格納する方法の標準規格になるであろう。推論ベースのシステムは、金融機関におけるビジネスルール・システムの管理に、ますます多く用いられるようになってきた。
ザックマンのエンタープライズアーキテクチャ（EA）は、企業のIT資産目録の作成を主要業務とするエンタープライズ・アーキテクトのためのデファクト・スタンダードである。しかし、それをビジネスプロセス・アーキテクチャ標準規格と混同し、ビジネスマネジメント・ツールとして用いようとすれば、際限のない困難を引き起こす。
最後に言及するIDSシェアーの表記法かつツールであるARISは、ERPアプリケーションのダイアグラム作成のためのデファクト表記法である。SAPが図表作成に用いているのに加え、オラクルもこれを採用した。ERPフォームにおけるARISは、ソフトウェア開発者にしか理解できない表記法であり、ビジネスマネージャ用にはほかの表記法が必要なことに注意を促している。それでも、ERPベースのプロセス実装に取り組むIT開発者に広く用いられている。ただ1ついえるのは、新たに導入したERPアプリケーションのARISダイアグラムを自社のCEOに見せてはいけない、ということだ。
標準規格の今後
ここまで、プロセスマネージャと開発者に用いられている多くの標準規格のうち、ほんの一握りだけについて考察してきた。その多様性には目を見張らされる。標準規格開発の鍵を握るのは、どの部門がそれを使い、それがあることにより、どのようなアクティビティが促進されるのかの理解である。ビジネスマンにソフトウェア指向標準規格の1つを用いるよう仕向けるようなITは、通常、プロジェクトを不成功に導く。同様に、ビジネスマンが独り善がりで作成したプロセスモデルをITに押し付ける場合、それは明確さに欠けた要件と解釈されるのが普通だ。
企業がBPMSツールの活用とBPMSアプリケーションの作成の方法を追求することから、これらの問題は複雑化の一途をたどることになるだろう。
筆者が最も有望視するのは、SCOR+、VCOR、およびeTOMと称する表記法である。そして、ハイレベル・バリューチェーン表記法が企業におけるエンタープライズプロセス・アーキテクチャの創出を可能にする、という考え方に期待を持つ。このアーキテクチャが実現すれば、シニアマネージャたちが行うプロセス把握、パフォーマンス・モニタリング、およびプロセス改善課題優先度評価の容易さが増すであろう。
同時に、OMGのMDAアーキテクチャは、各標準規格の特定ユーザーグループに対する価値特性を維持しながらも、異なるレベルの標準規格相互の効果的なインターフェイスを可能にする方法を設定する能力を秘めていると思われる。
冒頭に記したように、たいていのビジネスプロセスマネージャには、標準規格に対する関心がない。しかし、時が進むにつれ、共通の約束事の使用に合意することから誰もが潤うようになるだろう。
うまくいけば、現在、標準規格に取り組んでいる大手企業とベンダが、柔軟なアーキテクチャル・システムの内部に共通の約束事を設ける道を見いだしてくれそうだ。それこそが、ビジネスプロセス業務に従事する個別部門のすべてにおいて、相互に連絡を取りながら、最も効果的と確認された方法で業務を完遂することを可能にするのである。
では、また。
ポール・ハーモン
今日のビジネスプロセス標準規格
たいていの企業のたいていの社員は、仕事の標準規格について気に掛けることがない。彼らの仕事は、それをどのように遂行するかに関する共通の理解と合意を得た多くの約束事と協定に基づき、極めて単純化されたものである。彼らは、その事実に思いをはせることなく、単に仕事をこなしているにすぎない。
- PR -
車の運転では、道路の右側を走ることと左側を走ることの間に、何の違いもない。しかし、特定地域内では、そのいずれを選択するかについて、すべての人間の合意が欠かせない。同様例で別の観点からいえば、ネジ頭の形状数を限定し、2セットのドライバーでほとんどの場合に対応できることで、われわれ全員が恩恵を被っているのである。
筆者（ポール・ハーモン）は、ほかのアドバイザリ・Webページ※1で、ジェフリー・ムーアの技術導入ライフサイクルモデルについて論じたことがある（図1）。
※1 訳注：本稿を含め、筆者が月次発信するBPM論考シリーズ
簡潔にいえば、イノベーターの範疇（はんちゅう）に属する企業は大学や研究機関から直接新しい技術を採用し、それを大きな競争力の源泉となる突破口として活かそうとする。その技術を役立てる方法を見いだすために、膨大なリソースを積極的に投じている。早期導入者は少し遅れて技術を採用し、競合企業より先に用途を開発することで競争優位に立とうとする。
早期多数派に位置する企業は、新技術を導入する前に、その技術の有効性が明らかになるまで待つ。それにより、新技術の実験と未成熟なツールとの格闘に必要なコスト高の努力を回避する。さらに注目されるのは、彼らが標準規格が整うまで待とうとすることだ。別のいい方をすれば、少なくとも技術領域における標準規格開発は、技術ライフサイクルの早期導入者フェイズの期間中にベンダと先行的ユーザーによって遂行される活動なのである。
図1 ジェフリー・ムーアの技術導入ライフサイクル
標準規格開発への取り組みに関心を持つ企業は、そう多くない。たいていの企業は、技術の普及体制が整うころには標準規格も完成しているはず、と見込んでいるのだ。数年内に有効な標準規格が作成できなかったために、キャズム※2に落ち込み消え去る技術もある。
※2 編注：リリースできなかったとすれば、死の谷というべきかもしれない
標準規格について考えるときに念頭に置かなければならないもう1つの事柄は、デファクト・スタンダードとデジュアリ・スタンダードの違いである。デジュアリ（公的な）・スタンダードは、標準規格機関や業界コンソーシアムによって設定される。片や公式的取り決めを求めないコミュニティによって定められるのが、デファクト（実際上の）・スタンダードだ。
例えばMicrosoft Windowsは、90％以上のPCユーザーが依存するマイクロソフトのOSである。それはOSのデファクト・スタンダードであり、PC用ソフトウェアを売ろうとするベンダであれば、それを支持せざるを得ないであろう。
複雑で急速に進展する環境下では、デファクト・スタンダードの方が、デジュアリ・スタンダードよりも重要である場合が多い。デジュアリ・スタンダードの決定には、通常、より長い時間がかかるからだ。別のいい方をすれば、有力なベンダが一般の標準規格に従えない場合に裁定を下すのは市場であり、結局はデジュアリ・スタンダードとなるベンダが勝利を収めるのである。
これらの考察を念頭に置き、今日のビジネスプロセスに関する標準規格について少し述べたい。この論述の整理の仕方として、標準規格を利用する立場に応じ、それらを3つの大きな枠組みに分類してゆくことになろう。
まず、エンタープライズレベル標準規格は、ビジネスマネージャが、事業活動を分析し体系化するために使用する。
プロセスレベル標準規格は、ビジネスマネージャとビジネスプロセス担当者が、ビジネスプロセス変革プロジェクトの実施に臨む際に使用する。ビジネス・プロジェクトの実施には多様な立場の個人が携わるため、この領域の取りまとめが最も難しい。ある場合には、ビジネスマネージャがビジネス改革プロジェクトの実施に当たる。一方、ITビジネス・アナリストその他のIT関係者がプロセス自動化プロジェクトを遂行するといった実態がある。
実施レベル標準規格は、プロセスにかかわる問題のソリューション開発担当者によって使用される技術を特定対象とするものだ。この領域の標準規格の大半は、ソフトウェア開発の方法あるいはソフトウェア・ツールのインターフェイスの方法を定めたIT標準規格である。既存の、あるいは現在開発途上にあるビジネスプロセス標準規格のすべてを包含するのはほとんど不可能なことだが、大局的見地からの概観は持ちたい。
いうまでもなく、筆者はこの論述の構成と標準規格の分類を筆者自身の経験に照らして行った。これらの標準規格を、筆者と異なる様式で整理される方もおられるに違いない。また、筆者の考えで分類した標準規格の中には、ほかの範疇に位置付けてもよいものもあるだろう。いずれにせよ、概観を簡潔に提示することが必要なのだ。
エンタープライズレベル・ビジネスプロセス標準規格
エンタープライズレベル・ビジネスプロセス標準規格は、ビジネス・パフォーマンスの概要把握、評価、およびマネジメントの体系化を支援するツールとして、エグゼクティブとシニア・ビジネスマネージャに使用される。さらに、エグゼクティブ・コミッティ傘下にBPMグループを設置し、同標準規格をマネージャのパフォーマンス評価とプロセス介入優先順位設定のツールとして用いている企業もある。
恐らく、エンタープライズレベルで最も広く用いられているビジネスプロセス標準規格は、キャプランとノートンのバランスト・スコアカード（BSC）による経営評価アプローチであろう。これは事実上のデファクト・スタンダードであり、多様な様式で用いられていると思われる。しかし、多様ではあっても、キャプランとノートンのアプローチの改変版の間には十分な共通項が見られる。もしバランスト・スコアカードを用いているかと問われた場合、たいていの企業は直ちに「イエス」か「ノー」の回答ができるはずだ。
エンタープライズレベルにおいて、最も注目されるビジネスプロセス標準規格が、サプライチェーン・カウンシルのSCORフレームワークと方法論である。SCORは、複数企業にまたがるサプライチェーン・プロセスを構築し評価するためのツールとして、サプライチェーン・マネージャたちによって開発された。バリューチェーン全体の定義、ベンチマーキング、および評価を行うための標準規格として、急速に普及している。その増幅版では、SCOR+とSCOR/DCOR/CCOR（サプライチェーン・モデル、デザインチェーン・モデル、カスタマーチェーン・モデルに対応）の、いずれかの名称が使用されるようになった。
今後数年間には、プロセスセントリック・アプローチを導入するシニア・エグゼクティブが増加する。これに伴い、SCOR+の重要度も増すに違いない。
VCORは、SCOR+と非常に類似点が多いが、もう1つの異なるアプローチだ。eTOMは、テレコム業界向けに特別に作成されたフレームワークである（今後は、ほかの業界でも、同様のフレームワークが作成される可能性が大きい）。
エンタープライズレベルで時々用いられる、もう1つの標準規格が、ソフトウェアエンジニアリング・インスティチュート（SEI）のケイパビリティ成熟度統合モデル（CMMI）である。CMMIをITプロセスのパフォーマンス評価に用いているケースが圧倒的に多く、この場合には、CMMIをプロセスレベル標準規格と位置付けるのが妥当であろう。しかし、一部の企業では、すべてのビジネスプロセスを評価し全体組織の動向を見極めるために用いられている。この場合には、エンタープライズレベルのツールとして機能していると見てよい。
さまざまな米国政府機関の支柱になっているのが、連邦エンタープライズアーキテクチャ・フレームワーク（FEAF）だ。FEAFは、ある意味ではエンタープライズ・ツールであり、いくつかの機関がその位置付けで用いている。しかし、ITアーキテクチャ構築のアプローチとして用いられることがほとんどで、この場合には、ザックマンのようなIT実行標準規格の範疇に含められるであろう。
図2に、筆者が想定する主要なビジネスプロセス標準規格の位置付けを示しておく。
プロセスレベルは、全体がプロセスのリデザイン／実施プロジェクトの集積である。このレベルの標準規格は、具体的なプロセスの改革に当たるマネージャ、従業員、ビジネスアナリスト、およびヒューマンパフォーマンス・アナリストを支援する。
これまでに、プロセスレベルで最も広く用いられてきた標準規格は、シックスシグマであった。企業や標準規格機関ごとに多様に定義されてきた、もう1つのデファクト・スタンダードでもある。しかし、たいていのシックスシグマ改変版の間には、容易に認識できる、ファミリとしての類似性がある。シックスシグマは、汎用的プロセス改善手法（DMAIC）と、プロセス改善チームがプロセスの改善に適用できる多彩なツールを備えているのだ。
リーンはプロセスフローの無駄の除去に重点化した別個の手法であり、一般的に、シックスシグマ・チームが取り込むべきツールの1つだと考えられている。従って、恐らく、この標準規格は「シックスシグマ／リーン」と称されるべきなのだろう。
いずれにせよ、多くの大手企業が膨大な数の従業員に対してシックスシグマ教育を行い、シックスシグマ／リーン・アプローチにのっとった数多くの改善プロジェクトを定期的に実施しているのである。
シックスシグマとほぼ同等に普及しているのが、ISO 9000だ（この標準規格は9000番台に関し、多くのバリエーションを持つが、一般的にはこの呼称で通っている）。突き詰めれば、ISO 9000は国際標準規格機構が定めたビジネスプロセス定義の仕様である。ヨーロッパの多くの大手企業と政府が、ISO 9000を用いてプロセスを定義することを企業に義務付けている。
残念なことに、この標準規格は、いまや「チェックリスト」項目でしかなくなってしまった。ISO 9000の文書を手早く作成し、それを棚さらしにしている企業がほとんどだ。今日のビジネスプロセス業務に合わせてISO 9000の意義を高めようとする動きはある。しかし、現状では、企業におけるプロセスの実際的運用に対するISO文書のインパクトは、ほとんど見られない。
米国では、たいていの企業がサーベンス・オクスリー法（SOX法）に対応するための文書作成に取り組んできた。重要な財務上の意思決定に結び付くプロセスを追跡できる体制が整っていることを示すよう、企業に義務付けた米国内法である。ISO 9000と同じく、サーベンス・オクスリー法は、社内プロセスの把握を大きく前進させる機会を企業に与える。しかし、やはり、あまりにも短時間内に処理されてきたのがサーベンス・オクスリーの実態だ。やがて棚の上でISO 9000関連文書のそばで眠る貯蔵品になってしまう可能性が極めて大きい。
最近、OMGがルールの標準規格（および、それに関連するビジネスモチベーション・モデル）を公開した。元はビジネスルールズ・コミュニティ（BRC）で開発されたものだが、企業で用いる語彙、方針、ビジネスルールを定義するための標準規格を定めている。この領域では金融機関の取り組みが非常に活発であり、この標準が、やがて金融機関におけるオントロジーとビジネスルールを確立するためのてことして活かされるであろう。
特定の業界あるいは領域に特化した、いくつかのビジネス・フレームワークは、プロセスチームが既存ビジネスプロセスのデザインと評価を行うのに役立つ。ITIL（ITサポート・プロセスの標準規格）とCoBiT（ITマネジメント・プロセスの標準規格）は、その好例だ。双方に対し、ITプロセスの全社的標準化を望む企業からの関心が高まっている。
この数年、ビジネスプロセス・モデラーが多種多様なワークフロー表記法を用いてきた。その代表例が、IDEF0とラムラー・ブレーシュである。普及度の高いプロセスモデリング・ツールのほとんどが、これらの2つの表記法を支持し、その自社版を提供している。
しかし、いまのところ、ビジネスマンの大多数がよりどころとするデファクト・スタンダードはない。フロー図によるビジネスプロセスの文書化と、遂行すべきタスクを記述した図の読み方に関する社員教育を行っている企業が多いという考察に至れば、標準的ビジネスプロセス表記法に有用性を見いだすことになるだろう。
現時点で最も推奨できるのが、BPMI/OMGのビジネスプロセスマネジメント表記法（BPMN）だ。大手プロセスモデリング・ベンダが結成したチームにより開発されたという点、および、コア・バージョンでビジネスマンが必要とする基本的表記法を提供している点で評価できる。半面、ビジネスプロセス実行言語（BPEL）を作成する機能まで持たせたために、明らかにビジネスマンには必要のない、あるいは理解できない多くの表記法が含まれている点はいただけない。
さらに、現在はBPMNがOMGの管理下に置かれていることから、BPMNをUMLアクティビティティ図に組み込むための作業が求められることになるだろう。それどころか、素朴なフォームを見る限りでは、BPMN/UMLアクティビティ図をラムラー・ブレーシュの図と区別することはほとんど困難で、ビジネスマンに、そのいずれかを選択すればよいと受け取られかねない。しかし、通常はもっと複雑な図で説明されることから、その2つが、いち早くビジネスマンになじみ深いものになっているのだ。こうして、ビジネスモデリングに複数の標準規格が存在することになったが、そのどちらがデファクト・スタンダードになるかは、まだ定かでない。
実施レベルのビジネスプロセス標準規格
ビジネスチームによるプロセスのリデザインが完了すると、その実施に向けた準備に、さまざまの部門が巻き込まれることになる。人事部門は、新しい業務記述書の作成、および人材の新規採用や既存人材の確保を依頼されるであろう。IT部門には、ソフトウェア開発の依頼が行く。資産管理部門は、プラントの再配置、新しいトラックの購入、物流センターの新設などを頼まれるかもしれない。
現時点では、ビジネスプロセス実施標準規格のほとんどが、IT標準規格である。それらは、2つのうちいずれかの目的の下に設定されたものだ。1つは、ITプロフェッショナルが行うビジネス要件の収集とソフトウェア・アプリケーションのデザインや手直しを支援すること。もう1つは、企業におけるプロセス情報の共通データフォーマットでの保存やソフトウェアツール間のモデル転移を、確実に可能にすることだ。
OASISのプロセス実行言語であるBPELは、最も大きな注目を集めてきた。BPELはBPMスイートと密接に連結している。しかし、幅広くとらえれば、実際にBPELを用いて開発されたBPMSアプリケーションはごくわずかであり、BPELに完全依存したアプリケーションは見当たらない。BPELの現バージョンには高度なBPMS開発を支援するには限界があり、BPELを用いるベンダは、いずれもほかのコードでそれを補完しているのだ。BPEL標準規格の進展とともに、この状況は変化するであろう。しかし、現時点におけるBPELは、まだ開発途上段階でしかない。
BPELと密接に関連するのが、ワークフロー管理連盟（WfMC）のXPDLやWorkflow Management Facilityといった標準規格である。これらの標準規格は、ワークフローシステムを支援するために開発された。最終的にはBPEL、あるいはそれに類する言語と統合し、BPMSアプリケーションの支援ツールにまでの拡充が必要になることが見込まれる。数年後には、その動きが見え始めるであろう。
OMGのUMLは、明らかにソフトウェア開発者のための表記法システムとして開発されたものだ。MDAとTOGAFはともに、BPMSにより作成されるSOAアプリケーションの構築に用いられる。また、OMGのプロダクションルール仕様が、ゆくゆくは推論ベースのシステムにビジネスルールを格納する方法の標準規格になるであろう。推論ベースのシステムは、金融機関におけるビジネスルール・システムの管理に、ますます多く用いられるようになってきた。
ザックマンのエンタープライズアーキテクチャ（EA）は、企業のIT資産目録の作成を主要業務とするエンタープライズ・アーキテクトのためのデファクト・スタンダードである。しかし、それをビジネスプロセス・アーキテクチャ標準規格と混同し、ビジネスマネジメント・ツールとして用いようとすれば、際限のない困難を引き起こす。
最後に言及するIDSシェアーの表記法かつツールであるARISは、ERPアプリケーションのダイアグラム作成のためのデファクト表記法である。SAPが図表作成に用いているのに加え、オラクルもこれを採用した。ERPフォームにおけるARISは、ソフトウェア開発者にしか理解できない表記法であり、ビジネスマネージャ用にはほかの表記法が必要なことに注意を促している。それでも、ERPベースのプロセス実装に取り組むIT開発者に広く用いられている。ただ1ついえるのは、新たに導入したERPアプリケーションのARISダイアグラムを自社のCEOに見せてはいけない、ということだ。
標準規格の今後
ここまで、プロセスマネージャと開発者に用いられている多くの標準規格のうち、ほんの一握りだけについて考察してきた。その多様性には目を見張らされる。標準規格開発の鍵を握るのは、どの部門がそれを使い、それがあることにより、どのようなアクティビティが促進されるのかの理解である。ビジネスマンにソフトウェア指向標準規格の1つを用いるよう仕向けるようなITは、通常、プロジェクトを不成功に導く。同様に、ビジネスマンが独り善がりで作成したプロセスモデルをITに押し付ける場合、それは明確さに欠けた要件と解釈されるのが普通だ。
企業がBPMSツールの活用とBPMSアプリケーションの作成の方法を追求することから、これらの問題は複雑化の一途をたどることになるだろう。
筆者が最も有望視するのは、SCOR+、VCOR、およびeTOMと称する表記法である。そして、ハイレベル・バリューチェーン表記法が企業におけるエンタープライズプロセス・アーキテクチャの創出を可能にする、という考え方に期待を持つ。このアーキテクチャが実現すれば、シニアマネージャたちが行うプロセス把握、パフォーマンス・モニタリング、およびプロセス改善課題優先度評価の容易さが増すであろう。
同時に、OMGのMDAアーキテクチャは、各標準規格の特定ユーザーグループに対する価値特性を維持しながらも、異なるレベルの標準規格相互の効果的なインターフェイスを可能にする方法を設定する能力を秘めていると思われる。
冒頭に記したように、たいていのビジネスプロセスマネージャには、標準規格に対する関心がない。しかし、時が進むにつれ、共通の約束事の使用に合意することから誰もが潤うようになるだろう。
うまくいけば、現在、標準規格に取り組んでいる大手企業とベンダが、柔軟なアーキテクチャル・システムの内部に共通の約束事を設ける道を見いだしてくれそうだ。それこそが、ビジネスプロセス業務に従事する個別部門のすべてにおいて、相互に連絡を取りながら、最も効果的と確認された方法で業務を完遂することを可能にするのである。
では、また。
ポール・ハーモン
PR
