会社の絶え間ない変化のプロセス-自動化の方法

さて、これがなぜ必要なのかを、1つの大規模な工業所有権の例で説明します。これは、そのように数百万ルーブルが失われる可能性があることに突然気付きました。 さらに、非凡な非識字、混乱と官僚制度の誤りのため。 そして、これらはすべて、グローバルなプロセスのリファクタリングを背景にしています。



したがって、大規模な生産ホールディングでは、多くの企業が1つのグループに統合されています。 2011年と2012年に、彼らは高い利益を示しました。最適化については忘れて、できるだけ早くさらに理解することができます。 「考えるべきことは、あなたは揺さぶる必要がある」-そのような収益率に基づいた最適なビジネス戦略。 2013年、一般的な経済状況により、利益が減少することが明らかになりました。 したがって、多くのリーダーシップが始めた最初のことは、痛みを伴わずに、または単に削除できるものを見つけるために、どこでどのようにお金が使われているかを正確に把握することでした。

私は何をしています

大企業は、3〜4か月ですべてのプロセスを整理し、混乱を打ち破ることができると考えています。 実際には、外の世界では何かが絶えず変化しており、毎日が緊急に実装する必要がある新しい機能から始まります。 そして、その費用を再度支払うか、IT部門に過負荷をかける必要があることがわかりました。



私は多くの奇妙で理解できないものをBRMSシステムに紹介することにコミットしています。 実際、企業内の意思決定ルールのリポジトリであり、そこから他のITシステムがデータを取得します。

持ち株会社の経営陣は、お金の行き先を把握することにしました...

ここで、彼らはワークフローシステムの驚きを待っていました。 厳密な科学用語では、自発的な他家受粉に似ていました。 まあ、またはP2Pネットワーク。 あなたが持ち株会社の従業員であると想像してください。 契約に同意して署名する必要があります。 この手順は多くの決定を提供しますが、その主なものは、制限の決定、権限の枠内での合意に署名する能力、生産の必要性に加えて、どのような文書に応じて、財務ディレクターから弁護士および技術部門の責任者までの十数人との調整です。 ロシア語への翻訳-毎回契約によって異なる20のサブタスクのクエストがあります。 最も面白いのは、誰もこのドキュメントの処理方法を正確に知らないことであり、クエストのすべてのサブタスクは途中で描かれます。 たとえば、技術部分の実装を担当するユニットの責任者は、生産のための原材料を彼に供給する3人の人にあなたを送ることができます-そして、彼らのそれぞれも彼の弁護士と金融業者に。



ヒープに-チェーン内の誰もが数百万ドルの費用がかかる決定に責任を感じ、それを安全にしようとするため、承認が複雑になります。



一般的に、 大企業に馴染みのある地獄。



これは非常に独創的な方法で-コーディネーターのシステムによって解決されました。 どのような紙をどのように、どこで、なぜ運ぶのかを知っている特別に訓練された人々がいました。 1人で約20件の契約を監督できます。 文書管理システムをそのまま構成したのはこれらの人々でした。 この場合も、それぞれが何らかのスキームではなく、自分の経験に依存しています。 そして、2人の異なる人々にとって、同じ文書が異なるルートで会社を旅行する可能性があります。



この時点で、経営者は、この話に加えて、持ち株会社が承認なしに自社間で出荷に同意することがよくあることを発見します（時間がかかり、作業に価値があるため）。 イワノビッチとペトロビッチは指で合意し、ペトロビッチはロードに行き、契約の代わりに-最高の保証。 そのようなケースはそれぞれ、後で見つけるのが非常に難しい原料のワゴンのペアです。



そして、すべての決定点で完全な制御を導入する決定が下されます。



ここに彼を電子文書管理システムにする同僚が現れます。 彼らはドキュメントを扱う特別な人々のもとに来て、それらを会議室に置いて、プロセスがどのように進んでいるかを尋ねます。 彼らは頭をひっかいて、すべてが簡単だと言います。 最初は、「3つの通り」の美しい計画が判明しました。 私たちは文書を取り、それを描画しようとしました-いいえ、すべてが私たちの望む通りではなかったことが判明しました。 このスキームには実際の状況が課され始め、契約の種類ごとに多くのニュアンスが明らかになりました。 スキームは、メトロマップに似始めました。 その結果、A3に巨大なマトリックスが出現し、それによって決定がどのように行われたかをどうにか理解することができました。



この「ネジを締める」プロセスでは、ビジネスプロセスを形式化することは非常に困難な作業になりました。 第一に、スペシャリストから抜け出すのが大変だったことがたくさんありましたが、彼らはそれをやりました。 次に、判明したように、さらに2つの驚きが現れました。 1つ目は、ルールを破ることができる緊急の非常に重要なドキュメントです。 特別な廊下と優先順位のシステムを作成しました。 2つ目は、システムが静的ではないことです。 法律は変化し、会社は構造的に再編成され、マネージャーと標準の要件も修正されず、経験に基づいて新しい瞬間が現れます-一般的に、何かが常に書かれている場所で、ブロックせずにデータベースをコピーしようとするようなものです



その後、数か月の間に、一部の文書が承認手順の例外を必要とすることが明らかになりました。 そして、これらのまれな文書-約60％。



同僚が「変化の永続性」というフレーズを言ったとき、私のチームが現場に現れました。 持続的な変更は、まさにBRMSが最も得意とすることです。

この場合、なぜBRMSが必要なのですか？

BRMSはビジネスルールリポジトリです。 たとえば、あなたが保険会社で、クライアントがあなたのところに来て、アンケートに記入し、さらに彼に関する多くのデータを収集する場合、保険にかかる費用を理解する必要があります。 固定システム（1度または別のERP、CRM、BPM）により、この場合、これを簡単かつ簡単に自動的に計算できます。 問題ありません。 マーケティングが関税を変更することを決定すると、困難が始まります。 2つのタスクがあります。

1. 誰にとっても、IT部門に行き、処理ロジックの変更を依頼する必要があります。
2. どうなるかを事前に推測することは常に可能とは限りません-計算ルールは相互に排他的である可能性があり、エラーにより計算から外れ、係数の1つを0.5％シフトすると利益が急激に低下する可能性があります-これはすべて事前に知られている必要があります

そして、ここにBRMSシステムがあります。 これは、会社のすべてのルールが収集され、システムの残りの部分に重ねられる場所です。 保険会社の場合-BRMSは、誰に、何を、どのように数えるかを知っています。 テレコムの場合-関税が変更された場合に、既知のプロファイルを使用して現在の加入者の利益予測を作成できます。 銀行にとっては、誰にどのような条件で、どのような条件で、誰に融資するのかを正確に知ることができます。 非常に重要なこと-IT部門ではなく、意思決定者が管理します。 それは直接、投資家、マーケティングなどです。



実装は高速で安価ではありません。 しかし、その後、投資家は「そのような場合はこれを行います」と言って、単純なインターフェイス（図の描画に似ています）を介してルールのシステムに移行します。 それ自体。 考えられる結果を確認し、「適用」をクリックします。 その後、会社のすべてのITシステムが新しいルールを選択し、プロセスを変更するだけです。



BRMS以前は、これは新機能のためにIT部門への必須の旅行を意味していました。 ここに簡単なケースがあります：新しい電気通信料金。 IT部門に行き、係数の変更を依頼するのはビジネスです。 ただし、互換性のために古い料金を維持する必要があります。 そして、彼は他の松葉杖との互換性のためにそこにさらに5つの松葉杖を持っています。 信頼性を保証して（ビジネスロジックや技術的な部分に誤りがない場合）、プロセスは考古学的な遠征に似たものになります。 迅速に行われた場合、全員が正しいとみなされる保証はありません。



したがって、BRMSは、非常に迅速に変更を加える必要がある人によって実装されます。 有利な市場での保険、貸出市場の上昇時の銀行、競争のレベルの上昇での小売（小売の場合、変化の速さは生命です）、およびプロセスが変化したときのさまざまな大企業。





BRMSの作業例

私たちは何をしましたか

その結果、電子文書管理システムのアーキテクチャ要素として、かなり珍しい形式でBRMSを展開しました。 2つの非常に重要なタスクが解決されました。契約のルートの計算と制限の設定です。



ルートでの話はこれです。 通常の電子文書管理は、純粋にアーキテクチャ上、ルートを最初に一度考慮してから制御します。 変換ポイントの道路に沿って2-3-5-10ノットを追加できますが、これらのノードの数は、アーキテクチャレベルまたはその近くで決定する必要があります。 私たちの場合、各調整ノードは契約ルートの再計算のポイントになりました：「しかし、ここでは間違って同意されました。署名者の異なるリストが必要です。」 論理的には、チェーンの最初に紙を引っ張ってやり直す必要がありますが、その後、少なくとも数週間はビジネスが失われます。



したがって、ルートは各ポイントでリポジトリのルールを使用して考慮されました。



2番目のポイントは、委任状、予算、期限などの複雑なシステムです。 ここでは、巨大なルールセット（A3の同じマトリックス）に従って、すべてがドキュメントで正常であるかどうか、さらにドラッグできるかどうかなどを確認することが重要でした。 これらすべてをワークフローに組み込みます-3〜4年でシステムを松葉杖のようなフラクタルに終わらせます。 BRMSでも取り出されます。



その瞬間から、すべてがなんとか簡単になりました。 リーダーがシステムの彼の部分を完全に制御できるとき、これは幸福です。 そして、彼の年長のリーダーは、順番に、すべてのドキュメントでまったく同じであったものを見ることができます。 このような透明なレポートが判明しました。



一般的に、誰もが幸せです。 作業はまだ進行中ですが、その終わりが見えます。 ホールディングの経営陣は（彼ら自身のために）コントロールと透明性を受け取り、従業員はタンバリンとシャーマンなしで文書に署名する機会を受け取りました。

保険

BRMSの2番目の注目すべき事例は保険でした。 彼らはオフィスに巨大なXLSファイルを提供しました。そこには、多くの接続されたセルとマクロ、顧客が収集したデータがありました。 その後、これらすべてが考慮され、結果が得られました。 一般に、中小企業にとっての通常の解決策は健全です。中規模企業にとっては大企業のレベルまで成長することができました。 とても大きい。



すべての従業員がこのXLSファイルの内容と方法を完全に理解できるわけではありません。 そして、難しい質問が生じ、ルールの変更が必要になったとき、問題が生じました。



これらすべてのフォーム、マクロ、統計テーブルを巨大なファイルで見たとき、私たちは迷信的な恐怖に陥っていました。 おそらく、ランプで最新のプロセッサレベルi5を見た場合、このようなことになるでしょう。



これらはすべて、文書を部署（各オフィス）にメールまたはFTPで送信することにより更新されました。



一般に、これはクライアントがそのようなプロセスに耐えられなくなったため、IT部門の負担を軽減したいというBRMSを実装する典型的なケースでした。 これらのデータの入力に問題はないことが判明しました。すべての準備が整い、ソートされ、チェックされました。 最新のツールが必要でした。 それはいつもそうでしょう。



現在、関税の変更率は数か月ではなく数日です。 ビジネスユーザーはルールを変更し、ITスペシャリストのみが同行します。 これで、顧客は単一のルールソースを使用できます。 さらに、複雑なスキームの非常に迅速な計算-毎分約10,000件の保険料の計算。

私たちと

CROCには、年間約2,500件のプロジェクト（うち200件以上、100万ドル以上の予算）、2500人の従業員がいます。



私たちは常に最新のものをすべて実装しています。BRMSシステムも例外ではありませんでしたが、本当に必要でした。 主な問題は財政的でした-プロジェクトのコストと収益性を考慮し、what-if分析を行う必要がありました。



以前は、大規模で複雑なプロジェクトのコストは人手と見なされていました。 たとえば、プロジェクトの人件費を計算するためには、約14のパラメーター（役職、部門、関与する従業員の割合など）を考慮する必要がありました。これはわずか数分で完了し、さらに明確かつ詳細にコストを計算できます。 現在、すべてがシステムで行われているため、より多くのパラメーターを考慮して式が複雑になりました-現在約170個あります。販売。 たとえば、従業員の率が突然10％上昇した場合、税率が変更された場合など、財務パフォーマンスがどうなるかを簡単に見つけることができます。 そのままの幸せ。





プロジェクトの人件費を計算する例



営業部長にとって、これは便利なツールである金融プロジェクト計算機にもなりました。 ルールリポジトリのおかげで、彼らは独立して（「投資家の参加なし」）、関与する従業員の数と地位、工数、作業エリアなどのパラメータに応じてプロジェクトコストを計算できます。



BRMSは、現実が変化しているプロジェクトに特に不可欠であることが判明しました。 悲しいかな、状況はTKが1つのことであり、プロジェクトが終了する頃には、中小企業だけでなく、まったく異なる何かを繰り返す必要があります。 また、以前の機能がまだ実装されていないが、新しい反復の要求も既にある場合。 これで、プロジェクトの原価計算の方法論を複雑にすることなく変更および拡張できます。

BRMSシステムは統合プラットフォームに接続されているため、構成されたルールをサービスとして使用し、必要に応じて社内のビジネスプロセスから呼び出すことができます。

合併と買収

BRMSは、多くの場合、合併や買収でヨーロッパとアメリカで使用されます。 たとえば、何かを吸収し、実際には1つの標識の下に2つの構造体になった銀行が1つありました。 「そしてこの部門では、これを行うことはできません。別の部門への道を渡ります。」 異なるスタッフ、異なるルール、異なるABS。 1つのプラットフォームに切り替える計画がない場合（そして、これは一種の洗練された自殺です）、唯一の論理的な出口があります。 これはすべて比較的簡単です（合併と買収で可能な限り）は、BRMSシステムを介して接続されます。

もう一回

BRMS：

• ルールの迅速な変更（つまり、ビジネスにすばやく変更を加えることができます）
• 複雑なビジネスルールの即時再計算とモデリング
• ビジネスルールアルゴリズムの作成履歴全体を保存する
• すべてのシステムに対して常に単一バージョンのルールを使用する
• コンプライアンス監視
• 高性能コンピューティング：1秒あたり数千のルール
• what if分析（what if ...）
• これらはすべてIT部門に行かなくても可能です。 また、統合プラットフォームとの組み合わせで-プロセスおよびアプリケーションからのルールへのアクセス。

そして、これは、tsarの下での最初のコンピューター前自動化システムの例に関するBRMSに関する以前の投稿です。



ご質問がある場合は、コメントにゆっくり返信するか、特に特定のコメントについてはメールでsplaunov@croc.ruに返信します。 唯一のことは、NDAによると、すべてのデータは抽象的な企業のものであるということです。結果のスクリーンショットでさえ、すべての数字と文字を消去しないと表示できません。