直線ホメオスコープ
シンプルなコンパレータ
これは、今日のエキスパートシステムの機械的基礎と呼ばれるものです。 IBMが病院に人工知能を広めているというニュースを覚えていますか？ それで、S。N.コルサコフは少なくとも150年前に似たようなことを始めました。 彼のアイデアは非常にシンプルでした。現場の医師にデバイスを配布する必要があり、医師は経験を積み重ねることができ、一般的な間違いを犯さず、一般的に標準で治療できます。 比較器は鑑別診断の手段として機能し、より単純なホメオスコープはオートマトンとして機能し、医師は症状を入力して出口で病気を受け取りました。
つまり、言い換えると、コルサコフは医療知識のリポジトリとルール管理システムを作成しようとしました。 同じ病気が国の隅々で等しく効果的かつ正確に治療されるとは思っていなかったからです。
一般に、1800年代からそれほど遠くない
現代のビジネスプロセスは、多くの点で、このような機械装置の動作に似ています。 たとえば、銀行でルールが機能する場合があります：クライアントが3年以上サービスを使用しており（1つのレバーを動かした）、アカウントの金額が300万ルーブル（2番目に動いた）である場合、VIPクライアントと見なされるべきです（システムは結論付けられています） ビジネスルールの別の例は、契約額が300,000ドルを超える場合、財務ディレクターとの調整が必要です。
今、あなたが大規模な銀行または保険会社を経営していると想像してください。 ローカルの決定を非常にランダムに行うことに問題があります。 農村部の医師は同じ問題を抱える患者に対して100の独自のカスタムアプローチを使用するため、各部門はほぼ月の満ち欠けごとにローンまたはリスク評価の付与に関する決定を下します。 もちろん、最初の考えは、ヒューリスティックまたは線形比較に基づいた明確なルールを導入することです。
したがって、 BRMSシステムが使用されるのは 、これらのルールの実装のためです。 美しさは、これらがExcelタブレットではなく、支店のコマーシャルディレクターの意見ではなく、同僚のアドバイスではなく、特定のメカニズムであるということです。 会社のビジネスルールは、使いやすい方法で単一のリポジトリに保持されます。 企業システムは、BRMSからルールの計算を呼び出し、結果を取得します。
同時に、ビジネスユーザーはITなしでルールを変更します。これらのルールは、コーディングしなくても非常に迅速に変更できます。 すべてのシステムは常に単一バージョンのルールを使用します。 ルールへの強制的なコンプライアンスの制御があります。
なぜこれが重要なのですか？ たとえば、私は、独自のカスタム開発のみが自動化に使用される大規模な小売ネットワークを1つ知っています。 これを行うには、200人以上の開発者が座っている地域開発オフィスがあります。 ビジネスは急速に成長しており、経営陣は柔軟性を重要な競争上の利点の1つと考えています。 したがって、必要に応じて、ビジネスプロセスやビジネスルールの何かを変更します。たとえ小さなものであっても、コードに座ってすぐに書き直します。 変更の複雑さが増しており、締め切りは常に厳しいため、松葉杖はしばしば積み上げられます。 もちろん、このようなシステムは非常に不安定です。 さらに、かつて書かれたコードを再利用するには、ほとんど考古学者でなければなりません。 あなたは恐怖で逃げたプロジェクトのこの状況をよく知っていると思います。
そのような実装は、ビジネスの所有者にも問題をもたらします-彼は特定の人々、特定のソリューションに執着するようになり、その結果、ますます多くのお金を払い始めます。 エントロピーは成長しています。
一方、これについて事前に考え、有能なアーキテクチャの構築を開始した大企業は、このような問題を回避できます。 特に、「正しい」アーキテクチャの要素の1つはBRMSです。
これは次のように機能します。ルールを設定するためのユーザーインターフェイスがあり、ルールストア自体があり、ビジネスルールを実行するためのエンジンがあります。 たとえば、サイトが割引のサイズの計算を要求したり、1Cが特定のパラメーターのアカウントチェックを要求したりする場合があります。 BRMSシステムは、受信データをリポジトリに保存されているルールに「フィード」し、結果を生成します。 ちなみに、これにより、たとえば、異なる場所で同じ故障のために平日に修理された車を追跡するなど、分析的なことを行うことができます（自動車サービスのスペアパーツの不正の頻繁な例）。
例
可能な実装の1つは、IBM ILOG JRules（現在のIBM WODM）です。 たとえば、その上に、国内に400の支店を持つ大規模な保険会社のBRMSシステムを作成しました。 そこでは、義務的なモーターサードパーティの賠償責任保険と船体保険の一連のルールを考慮し、手数料を計算し、ルールをすばやく変更し、料金の説明がシステム内の計算と正確に一致することを確認し、顧客が自分でルールを変更できるようにすることが重要でした。
最初の状況は次のとおりでした。関税計算アルゴリズムは、情報システムのコードとExcelの計算機に配線されていました。 関税を変更するために、標準のITサイクル「目標設定-開発-テスト-展開」が使用されました。 変更のサイクルには数週間かかりました。 実装後の結果は、数日間の関税変更率であり、引受会社は規則を変更し、ITはプロセスにのみ付随します。 ルールの単一のソース（従業員とシステム用）があります。これにより、すべてのシステムで計算の完全な透明性と正確さがあります。
実装中、主な作業はアナリスト、エンジニア、マネージャーによって行われました。 彼らはルールを計算するために200以上のパラメータを収集し、数万の基本ルールを受け取りました。 出力では、システムによる1つの決定の時間は1秒未満で、30,000の計算が3分未満で実行されます。
システムの美しさは、その柔軟性と、ほとんどすべての設定の可能性です。 ルールは、「エージェントの一定期間の売上が1,000,000ルーブルを超える場合、手数料を20％に設定する」など、単純な人間の言葉で設定されます。
もちろん、ILOGに加えて、他のベンダーのソリューション（Oracle Automation Policyなど）があり、さらに最も有名なのはJBoss Droolsであるオープンソースプラットフォームもあります。
ITの観点からこれはどういう意味ですか？
少なくとも：
- ビジネスルールを実装するための日常的なコーディングが少なくなります。 それらは宣言的に定義できます。
- コードが小さくなると、保守が容易になります。
- システムの統合により多くの努力が費やされる必要があり、開発者のより高い資格が必要です。
北米とヨーロッパの大企業を見ると、ビジネス全体の自動化と、高価なIT専門家の効率を向上させるツールの使用の両方でさらに進んでいることがわかります。 特に、多くの開発者は、BRMSなどのより柔軟なテクノロジーの使用に向けて、維持が困難な大量の開発コードを放棄するための次のステップをすでに取っています。
これはユーザーの観点からどういう意味ですか？
ITの独立。 たとえば、関税を変更するために開発者をノックする必要はありません。 これは、企業内の意思決定の採用と実装の速度が急激に高まっていることを意味します。
もう1つの重要な点は、部門間の関係が改善していることです。以前は「同じ場所で1桁を変更する必要がある」と「すべてを再構築してテストする必要がある」という古典的な誤解があった場合、ユーザーはITが言い訳をすることを考えないためしないでください。
BRMSシステムは他に何ができますか？
彼女はイベント処理の方法を知っています。 つまり、指定されたビジネスルールによって処理される数十万および数百万のイベントのストリームを自分自身に通すことです。 これは、パターンを識別するのに役立ちます。 私がすでに引用したカーサービス担当者の不正行為の検索の例。 別の例は、例えば、特定の兆候のある携帯電話事業者の加入者によるトラフィック消費の減少を伴う特定のアラートなどの市場動向の検索です。 たとえば、モスクワのレストランと2時間後の中国のATMで、2回の引き出しの事実を判断するなどの不正検出があります。
このような各ルールを手動でプログラミングすることは難しくありませんが、何百ものルールがある場合、すべての場合にハンドラーをコーディングするのではなく、すべてを構成できるシステムを作成することは論理的です。 ちなみに、開発者は多くの場合、システムに宣言的にロジックを設定するためのさまざまなフレームワークやその他のメカニズムを実装することでこれを行います。 本質的に、これはBRMSです。
実装中にどんな驚きが明らかになりますか？
私の実践では、文書化されていないルールが多数発見されています。 それらは、BRMSで説明する必要があります。 会社の経営陣のほぼすべての実装で、見ていない場所でどのようなルールが使用されているかが驚きになることは、はるかに楽しいことです。 会社の最初のプログラマーによって15分で書かれたバグのある先史時代の仮設作業が、重要なものを計算するためのモジュールの基礎になり、マッシュルームなどのあらゆる種類の統合で成長します。 会社の多数の契約および内部開発者にとっての別の驚き-それらへの依存度はすぐに低下します。 モジュールがどのように機能するかを理解する唯一の人である「ハンガー」はもはや必要ありません-すべてが単一のシステムで記述されます。
一般的な問題は、一般に、計算から足が伸びる場所を見つけることです。 たとえば、特定の式があることがあります。 公式は、5年間会社にいなかった財務部長によって書かれました。 係数はどこから来るのでしょうか？誰も知りません;それらは定数として使用されます。 彼らは理解し始め、部門のビジネスプロセスを比較します。たとえば、何かを節約できることがわかります。 彼らは係数の計算方法を理解していたからです。
どこで使用できますか？
BRMSを使用する場合、おそらく2つの主な指標があります。多数のルールの存在と、定期的な変更の必要性です。 たとえば、平均的な保険会社は約2,000のビジネスルールを使用しています。 もちろん、すべてのビジネスルールに自動化が必要なわけではありません。 たとえば、「300,000ルーブル以上の契約は、商業ディレクターによって承認される必要があります」-これは、BRMSを介して直接制御を要求するルールです。 そして、「領土への入り口は、人工呼吸器の中だけにあります」-むしろ、その場での警備員の行動について。 分析、均一性、制御、および情報システムの厳格な遵守を必要とするものはすべて、BRMSに提出する必要があります。
産業について話すと、BRMSは、情報システムが積極的に使用されているあらゆる産業での使用に実際に適しています。
会社がBRMSに熟しているかどうかを理解する方法は？
まず、BRMSアプローチの実装がどれほど難しいかを評価してみてください。 1つのポイントがあり、人が少ない場合、ビジネスルールは単純であり、ルール違反のエラーはそれほど重大ではないため、新しいシステムを導入しなくても安くなります。 会社が大規模で、誤った決定の価格が高く、ITソリューションの変化が遅い場合、さらに状況をより細かく制御したい場合は、BRMSを選択できます。 そのようなソフトウェアのライセンスは高価であることに注意してください-金額は数万ドルです（ただし、オープンソースのソリューションもあります）。
これを実際にこのように実行するには、株主への報告ではなく、ビジネスの効率を高めるためだけにシステムを実装する準備ができているマネージャーが必要です。
PSコメントで尋ねたくない質問がある場合は、 Iomehin @ croc.ruに書いてください 。