2014年9月19日（金）にVCPC（バリューチェーンプロセス協議会）において、「企業連携におけるビジネスルールの重要性と留意点」の発表をいたしましたので、その概略を解説いたします。
本日のテーマです。
前半はビジネスルールとビジネスプロセスの関係を解説します。
後半は発表テーマである
企業連携におけるビジネスルールの重要性と留意点の解説です。
まず、前半から解説します。
パート1： ビジネスルールとビジネスプロセスの関係
SCOR（サプライチェーン業務参照モデル）などは左のようにビジネスプロセスを階層構造として明確にしています。
一方、ビジネスルールは特に階層という概念が薄いものです。しかし、上から、企業ミッション、ビジネスゴール、ビジネス戦術、ビジネスポリシー、ビジネスルールと言う具合に、階層を考えることも可能です。
今回の研究の結果では、SCORなどのプロセス階層構造と同様にビジネスルールも階層構造を持つことが可能で、かつ階層化することが重要な意味を持つことを提案しています。
[画像のクリックで拡大表示]
本WGの結論ですが、3段階あります。
1.はビジネス戦略とビジネスルールをつなぐためのポリシー憲章です。
次のスライドをご覧ください。
[画像のクリックで拡大表示]
ビジネス戦術とビジネスポリシーを作成する方法の例です。極めて単純な例です。5つの質問により、ビジネス目標（ゴール）、ビジネス戦術、リスク、ポリシーを導きます。
質問1：「ビジネス目標（ゴール）を達成するために最適なビジネス戦術は何か？」
質問2：「そのビジネス戦術を具体化するため使用できる追加のビジネス戦術、またはビジネスポリシーは何か？」
質問3：「ビジネス戦術またはビジネスポリシーの成功を妨げるビジネスリスクは何か？」
質問4：「そのビジネスリスクは受容可能か？」
質問5：「受容できないビジネスリスクに対する最善の防御策となるビジネス戦術、またはビジネスポリシーは何か？」
[画像のクリックで拡大表示]
簡単な例として、ピザ屋さんを取り上げてみましょう。このピザ屋さんのビジネス目標（ゴール）は「顧客に満足してもらい続けること」です。そのためのビジネス戦術は「顧客の自宅や会社にピザを宅配する」ことになります。それを実現するためのポリシー（ルールの親分的なもの）はピザを1時間以内に届けることですが、ルール的な表現で「ピザを1時間以内に届けなければならない」となります。その実現を妨げるリスクとして、「交通渋滞」があります。リスクに対する防御策として、「ドライバーに道路状況のわかるGPSを渡す」があります。
このようにして、縦方向に戦略をダイアグラム的に書いたものをポリシー憲章と言います。
（「ITエンジニアのためのビジネスアナリシス」（日経BP社）より抜粋）
上記ポリシー憲章により、上位の企業ミッション、ビジネスゴール、ビジネス戦略がビジネスポリシーとつながりました。このビジネスポリシーから様々なビジネスルールを導き出していくのですが、ルール側のやり方として、いくつかの方法があります。
- FACTモデルからビジネスルールの作成
- ビジネスプロセスからビジネスルールの作成
- マイルストーンからビジネスルールの作成、など
詳細は参考文献を参照ください。
[画像のクリックで拡大表示]
一方、プロセスの階層化モデルのSCORでは、Enableプロセスのレベル3にビジネスルールに関するプロセスが多くあります。
[画像のクリックで拡大表示]
その内容を詳しく調べてみると、左の図のように、名称はビジネスルールと称していますが、その内容はルールではなく、ほとんどポリシーに該当するものです。
- ビジネスポリシー：ビジネス目標を支える指令であるが、アクションを伴わない
- ビジネスルール：アクション可能でありテストもでき、組織のコントロール下でビジネスポリシーを支える具体的な指令
（BABOK®ガイド V2 日本語版より）
上記はまだ仮説の段階です。続いて実証作業の解説に移ります。
適応事例において、プロセスの階層化とルールの対応関係の実証
実証活動の対象とした今野製作所様です。VCPCプロセスを適用したビジネスを展開し、その著しい効果を発表されています（ここでは割愛）。
この事例でのレベル3プロセスにおける改善項目です。
課題の2つの根本原因
- 14:設計部品表の整備という課題の共通認識がない
- 15: 設計プロセスのルール、アウトプットが未確立
に対する解決策として、以下があげられます。
- 顧客要求の確認シートの受領・確認
- イージー/カスタム設計の判断（ポリシー）
- 製品設計の受領とレビュー（ポリシー）
- 生産設計情報の確認（ポリシー）
- 製品設計、生産設計からのアウトプット（ポリシー）
[画像のクリックで拡大表示]
それを、上記のポリシー憲章的に表現したのが左図です。
ビジネス戦術： 特注設計品の業務プロセスを見直しイージーオーダー化
課題の根本原因はリスクに相当します、その解決策をみるとほとんどルールの基となるポリシーになっていることがわかります。
もう一つのビジネス戦術（ベテランから若手への技術移転）も同様なことがお分かりになるでしょう。
このようにしてみると、この適用事例（今野製作所様）における、ビジネス改革においても、ビジネスプロセスとビジネスルールがすべての階層で対応していることが実証されました。
事例としては多くありませんが、具体的なビジネス応用において、階層化プロセスとルールの階層化が対応できることが実証できたことになります。
[画像のクリックで拡大表示]
ビジネスプロセスの階層とビジネスルールの階層はポリシーをレベル3にセットすることにより、すべての階層で対応付けが可能となりました。
[画像のクリックで拡大表示]
パート2： 企業連携におけるビジネスルールの重要性と留意点
K製作所における板金事業を似た事業を遂行している3社と連携で、ビジネスサイズ、適用分野、顧客層を広めようという試みです。
この連携体におけるITカイゼン・情報連携を東京都中小企業振興公社助成事業として開始するものです。
それに先駆け、業務プロセスとビジネスルールの整理に、上記階層化したビジネスプロセスとビジネスルールを応用した部分の発表です。
連携体におけるレベル2の業務機能です（今野社長の発表資料より）。
このレベル2の業務機能の課題一覧から解決策の中に多くのビジネスルールに関する物が多くあります（次の図を参照）。
[画像のクリックで拡大表示]
企業連携時におけるレベル2分析・設計シートです。
課題一覧から、解決策に関連するビジネスルールを抽出します。
約25個のビジネスルールを作成する必要がありました。そこで、当ワーキンググループで手分けして、連携時に必要となるビジネスルールの作成に着手しました。
[画像のクリックで拡大表示]
作成したビジネスルールの例です。このビジネスルールは欠陥情報を定義するルールで、欠陥情報を収集・受領するプロセスに影響を与えるビジネスルールです。
欠陥情報を収集・受領する際に、欠陥情報を受領する担当者が欠陥の重大さを定義するルールです。
- A）：致命的（火が出る、けがをする）
- B）：重大（使用できない）
- C）：中度（使用が困難）
- D）： 軽度（不便だが使える、またはワークアラウンドがある）
[画像のクリックで拡大表示]
このビジネスに特化したルールではありません。一般の電子機器を想定した欠陥の重要度のレベルから流用したものです。例えば、板金商品において、「火が出る」は考えにくいことです。溶接が外れてステンレスのとがった部分でけがをするなどが該当するかもしれません。WGのメンバーはビジネスアナリストとして、ルールの抽出はできますが、実業務（この場合は板金ビジネス）を行っているわけではありませんので、最終的にルール作成に責任を持つわけにはいきません。そのため、この程度のガイドラインにとどめざるを得ませんでした。それでも約25個の連携時のビジネスルール（またはそのガイドライン）を作成しました。
最後に企業連携におけるビジネスルールに関する課題を提起しています。
企業連携に特有の課題です。
一企業なら暗黙ルールで済むものが企業連携ではルールとして明示化する必要があります。
特に、「自社内の当たり前のこと」が通じません。そのためには用語の統一が必要になります。すなわち「用語集」を一企業内で作成する以上に充実したものを作成しなくてはなりません。同じ用語でもA社で使われている意味とB社で使われている意味が異なることもあります。例えば保険会社では「クレーム」は「事故処理」と言う意味で使われますが、ある保険の代理店では「苦情」を意味していました（実例です）。用語集の重要性が増すわけです。その結果作成するのに、よりコストがかかります。
[画像のクリックで拡大表示]
次に、ルールのメタモデルにならざるを得ない点があります。具体例の一つが上記の欠陥情報の定義の例です。ビジネスアナリストとしてルールの手続き的なこと（作成方法、考え方を示す程度）にならざるを得ませんでした。具体的な方法は当事者が自分たちの都合に合わせて決めてもらいます。欠陥情報の重要度はA,B,C,Dの4レベルが必ず必要と言うわけでもありません。板金ビジネスの金額、リスクの程度に応じて、レベルAは不要かもしれません。ビジネスの当事者が決めることです。
つづいて、プロセスそのものがしっかり構造化されていないケースです。しかし、ポリシー/ルールは必要なのです。例に挙げたのが、商品企画のポリシー/ルールです。
- 市場性の確認
- 実現可能性
- 参入障壁
- 競争優位性
- Visionとの関係性
例えば、ポリシー「市場性の確認」には下位のルールとして「顧客ニーズが明確になっていること」や「ターゲット市場の仮説が存在し、その確認方法の調査結果が明らかになっている」必要があります。
[画像のクリックで拡大表示]
しかし、特段しっかりしたプロセスが規定されているわけではありません。順番もこだわりません。しかし少なくとも上記5つのポイントを押さえておかなければ商品企画がうまくいくとは思えません。このように、緩やかな手順で、さまざまなやり方があるプロセス（のようなもの）のことをケースマネジメントという言い方をします。その定義もまだ開発途上のようですが。このケースマネジメント的な問題の場合、ルールが暗黙知的なことが多く
- プロセス（不明確） X ルール（暗黙知）
となりますから、企業連携の場合、合意形成に時間が必要になり、さらにコスト増になりがちです。
その他としては、以下のようなものも課題として残ります。
- うまくいかない場合のルール
- その場合の損失の配分方法をどうするのか？
いろいろ課題が多い企業連携です。課題を解決するためにも、トップレベルの合意が極めて重要になります。また下記のような会議体（各種機関）で充分な議論を尽くすことも必要になります。
- ステコミ（最終決定）
- 品質管理委員会
- 瑕疵責任委員会
- PMのアサイン
ステコミにおける意思決定と合意方法を事前にきめておくことも必要です。考慮点としては、出資比率、専門能力、影響力、責任能力、組織文化などがあります。