複雑なビジネスデータモデルとプロセスを、検証を伴う正式な表現にどのようにマッピングしますか?

Aug 22 2020

私はブラジルを拠点とする小さな保険会社で働いていますが、主な問題点の1つは、新しい保険商品の導入です。私は比較的新しい社内プロジェクトマネージャーであり、正直に言うとビジネスにとても慣れていません。全体を改善したいのですが、どこから始めればよいのかまだわかりません。

主な問題は、構造的に非常に異なる複数のもので構成される保険商品の複雑さです。それはすべて利用規約から始まります-基本的には長いテキストです。誰かが製品の価格設定を開発することに基づいて、請求部門は請求を処理する方法を理解し、契約条件の変更を要求する場合があります。財務部門は、この製品の会計処理などを行う方法を理解する必要があります。最後に、ドキュメントテンプレートの作成、ドキュメントの処理、外部サービスプロバイダーへのインターフェイスの把握などによって、これらすべてを実装する必要があります。さまざまなITシステムに実装されており、プロセスフローなどの他のアーティファクトは、人々の頭のどこかに、またはさらに悪いことに、文書化されたままになっています。

定期的に、物事が忘れられたり、ITシステムと互換性のない製品の決定が行われたりします。しかし、最悪の部分は、新製品の作業を開始したり、既存の製品を調整したりするときに、あるべきすべての質問を本当に知っている人がいないことです。尋ねられ、製品開発は、迷路に入って出口を見つけるまで無意識に走り回るなど、すべての部門内で行われていますが、いつかはわかりません。イライラします。私の知る限り、これは保険会社ではかなり一般的なプロセスだと言われています。

少し前にプロジェクト管理を導入して、すべてをより構造化したり、プロセスドキュメントを使用したりしていますが、それでもプロセス全体は、途中で問題を特定するために人々の認知能力に依存しすぎています(「ITシステム」それをサポートしていません」、「これを行う場合は、サービスプロバイダーの契約に付録Cを追加する必要があります」など)。

だから...私は本当に疑問に思います、あなたはそれをどのように扱いますか、どこから始めますか?保険商品のデータモデル全体を、当社の機能のデータモデルと照合する検証とともに文書化する方法を探しています。事前に尋ねる必要のあるすべて/ほとんどの質問を知っているので、部門はデータモデルに簡単に「記入」します。優れた統一されたドキュメントがあり、検証によって機能しないものが指摘されます(たとえば、ITの制限のため、ITシステムを拡張するか、製品の何かを変更します)。

私はデータモデリングツールを調べてきましたが、それらは非常に技術的でデータベース設計用に設計されているようで、部門がどのように「記入」して問題を早期に把握するのか理解できません。

長い間読んで申し訳ありませんが、私の質問が素朴な場合は申し訳ありませんか?どうやってそれにアプローチしますか?

回答

nvogel Aug 22 2020 at 20:39

保険業界での経験を持つデータモデラーにこれを支援してもらうことで、あなたが恩恵を受けることを期待しています。いくつかのユースケースとプロセスモデリングの専門知識も役立ちます。

ただし、データモデルを通じてプロセスの改善やソフトウェアの変更を実現することを期待すべきではないと思います。いくつかの重要な機会/問題点を特定し、それらを優先順位に従って作業できるユーザーストーリーに変えることをお勧めします。ストーリーマッピングは、製品とプロセスのビジョンを構築するための一般的な方法です。そのアプローチは麻痺につながるだけなので、考えられるすべての状況に前もって対応しようとしないでください。最終的には、優先順位を付け、変化するニーズに対応できることがはるかに重要です。適切なチームを配置し、継続的な改善のアプローチを採用する場合、データモデルとプロセスモデルは時間の経過とともに進化するはずです。

Bogdan Aug 23 2020 at 16:28

私は比較的新しい社内プロジェクトマネージャーであり、正直に言うとビジネスにとても慣れていません。全体を改善したいのですが、どこから始めればよいのかまだわかりません。

あなたはビジネスを理解することから始める必要があります。完全に理解していないものや、それがどのように機能するかについてよく知らないものに変更を加えることはできません。そうしないと、失敗の式を作成するだけです。あなたが探しているものは、ビジネスプロセスモデリング(BPM)とビジネスプロセス管理の傘下にあります(残念ながら、まだBPMと略されています-答えの中でBPMに言及するときは、より大きな分野を指します)。あなたは、物事をより構造化するために、しばらく前にプロジェクト管理を導入したと言います。これは、間接的にのみ、物事を管理するのに役立ちます。物事を理解するのに役立つ実際のツールとテクニックは、BPMにあるものです。

ここで本当に明確にしておきたいのは、BPMのツールとテクニックです。アイデア、実践、アプローチなど。本格的なBPMソフトウェアに飛び乗ってワークフローやフォームを作成し、手に入るすべてのものを自動化することはお勧めしません。それはあなたがあなたの質問で指摘した別の問題を引き起こすだけです...

主な問題は、構造的に非常に異なる複数のもので構成される保険商品の複雑さです。

BPMソリューションには限界があります。同じ人が同じ方法で同じ手順を繰り返し実行する場合に最適に機能します。このようなプロセスがある場合は、プロセスに参加する必要のあるすべての人を、適切な検証、作業を進めるためのゲートウェイ、イベントなどを使用して、適切なタイミングで適切な順序で関与させる自動フローを作成できます。保険商品の問題は、それらの多くがユニークであるということです。新製品を作成するためのある種のルーチンといくつかの繰り返しがありますが、違いを自動化することはできません。残念ながら、BPMを使用すると、そうしようとする習慣が強いられます。人々の行動を制約する不適切で厳格なワークフローになってしまいます。基本的に、ツールでは許可されないため、人々は仕事をすることができません。状況の詳細とより大きなコンテキストを確認し、情報に基づいた決定を行う必要がありますが、ワークフローでは事前定義されたオプションのみが許可されますA 、BまたはC。

したがって、本格的な自動BPMワークフローは、1つの問題に対処するのに役立ちますが、別の問題を作成します。ステップが明確に定義された構造が得られますが、その構造が課すものとは異なる何かを追加して、人々にできることとできないことを伝えることができれば、実際に優れた保険商品を作ることができるものを失う可能性があります。プロセス分析、自動化、改善、ワークフローの構築に多くの時間を費やすリスクがありますが、繰り返しとルーチンの自動化では必要な製品を構築できないことに気付くため、投資収益率がマイナスになります。

これは、たとえば、医師がすべての患者に同じワークフローを使用しようとする医療の問題です。問題は、患者の症例がそれぞれ異なるため、使用するツールによってシステムでの患者の症例の作成と文書化の方法が制限されている場合、物事を完全に文書化して診断することができないことです。これに対する対応として新しい分野が登場し、それはアダプティブケースマネジメントと呼ばれています。これは、物事に共通の構造といくつかの共通のステップがあることを認識していますが、ケースが異なる場合はワークフローから抜け出すことができます。これらのソリューションは、BPMよりもさらに複雑です。あなたはこの声明で、あなたの質問でもこの点に到達しました:

しかし、それでもプロセス全体は、途中で問題を特定するために人々の認知能力に過度に依存しています

これは本当です。関係する経験、ドメイン知識、コラボレーション、コミュニケーション、さらには直感、人々ができること、そしてプロセスワークフローで捉えることができないことはたくさんあります

私の知る限り、これは保険会社ではかなり一般的なプロセスだと言われています。

あんまり。人々はそのような働き方に慣れて、それが普通だと思っていると思います。私は、企業が明確に定義されたプロセスとすべてを追跡する方法を持っている状況(保険商品ではなく同様の商品)と、人々がそれを推進している(つまり、混乱)状況を見てきました。あなたは物事の適切なバランスを見つける必要があります。

あなたのための私の解決策は次のようになります:

  • 保険商品の作成プロセスの視覚化を開始します。かんばんに精通している場合は、製品がいつでもある状態、各ステップの責任者、作業内容などを含むかんばんボードを作成できます。何も変更しようとしないでください(私が言ったように) 、最初に何が起こっているのかを理解してから混乱させる必要があります)、何が起こっているのかを文書化するだけです(現状のままの状態、後で将来の状態について考えます)。
  • あなたのボードは、それが形になっているときにあなたの保険商品であるそれを通過するただ一つのアイテムを持っているでしょう。基本的には、ある部門から別の部門に渡されるバトンのようなものです。
  • 毎日(または十分な頻度で)ボードを見て、全体像を理解しようとします。バトンが動かなくなる場所はありますか?一部の部門が不足しているためにバトンを拒否したため、バトンは後退しますか?次はどこへ行くの?誰が物事を承認しますか?俳優は誰ですか?彼らの貢献は何ですか?
  • 別の製品を作成したい場合、同じ手順を使用できますか?すでに作成した製品との類似点は何ですか?違いは何ですか?各アクターはこの製品を他の製品と同じように扱いますか?
  • このプロセスを視覚化し、問題がどこにあるのか、またはチェーンがどこで壊れているのかを把握したら、それらを詳しく調べて修正または改善できます。それからいくつかの自動ワークフローを作成することさえできるかもしれません。実際に行われている作業を自動化できない場合でも、バトンが1つの部門から別の部門に渡される方法を自動化して、何も忘れたり失われたりしないようにすることができる場合があります。

最後に、警告の一言:これには時間がかかります。一晩で変更、改善、修正できるものではありません。ですから、辛抱強く、物事をシンプルに保つようにしてください。