开启保险业的未来：专家框架-核心系统转型-Guidewire

2为什么真正的伙伴关系是成功实施系统转保险公司将从人工智能中获得多少收益，以及能够领先于竞争对手的程度，在很大程度上统的影响。许多保险公司仍然依赖过时的核心应用，这限制了他们部署与客户为他们提供繁荣发展的基础。随着人工智能和其他技术的发展继续改变行业，我们期待在多保险公司发现他们的核心系统已接近寿命终结，由于过时的技术堆栈导统对于保持竞争力至关重要。过时的系统会增加成本和低效率，而现代平台则统。这些过时的系统可能会阻碍创新、增加成本，并造成竞争优势。通过投资现要采用全面的方法，该方法考虑了商业战略、技术、数据和人员。如上所述，问功能现在被AI技术如GenAI所取代，保险保险单生命周期方面仍然至关重要，包括承保、政策发行、批改、续保、账单和索赔处理。它确保符合监管 ,处理复杂的计算，管理大量数据，并与其他企业系统集成。然而，快速发展的AI技术可以整合并补充核心系统 ,以提升保险公司的整体效率、客户体验和运营能力。我们还应关注行a所作的未来预测，他设想SaaS模式将被AI代理所颠覆，这些代理将取代传统的用户界面和静态业务逻辑，通过直接控制多个后端系统来简化流程编排。这表明，在未来，包括核心系统在内的保险应用程序生态系统可能AI代理操作，可能通过直接与数据的交互进行。虽然这个愿景非常有趣，但它与当前本文深入探讨了对保险行业过去15年的专业全面分析，在这一和现代化核心系统的历程。转型的驱动力在于迫切需要更加以客户为中心，让客户和合作伙伴；通过创新的新产品来满足客户需求；通过自动化和简化来提高运营效率此外，该转型减轻了实施现代解耦微服务和API驱动架构所寻求的遗留和安全性风险，使这项核心系统的改造努力，常被比作心脏手术，可能复杂、昂贵，对保险公司而言极具挑战成转型的人将获得在他们的运营、增长和盈利能力方面的重大飞跃，这不仅包括更好的客户在整个这段时间里，这些核心系统转型项目取得了不同程度的成功，其中许多项目面临积累的、深度嵌入和硬连接的遗留系统，这些系统已经发展变化，不再适合提供现代保险公司的所要不仅进行大量的技术改造，还需要与业务操作和新兴的客户需求进行仔细的协调。这种复杂性通完成时间的延长和成本超支，调整后的期望和范围缩小，减少了这些项目原本打算带来的利益。现了潜在的陷阱。一些项目不得不进行完全的重置，需要重新启动或调整努力方向，这进一步增加了担。在某些不幸的情况下，项目被完全放弃，代表了巨大的沉没成本和保险公司错失的机会。相比当这些举措失败时，市场往往将责任归咎于平台供应现成功转型的众多组件之一。本文提出一个框架，该框架提供了一个端到端的考虑方式，从商了实现特定转型所必需的各个关键组成部分，例如目标企业架构、产品策略、流程优化、核心此类转型的能力。该框架还侧重于如何为特定组织选择合适的核心系统（不是所有情况都适用统一的解决方案）总之，本文旨在对这些挑战进行详细审查，提供洞见、指导以及成功框架对于从业者来说，明确一系列驱动因素以证明进行核心系统更换项目的必要性应该相领域可能是最常见的：•敏捷性与满足现代商业需求以保持竞争力：遗留系统通常是单体应用程序，往往在紧密耦合、非AP构中存在冗余和多个点解决方案。它们通常缺乏模块化，并使用过时的技术以及稀少的以及捕捉关键数据变得困难。关键功能，如人工智能、数据分析、欺诈检测以及与其他用户计算（EUC）解决方案来弥补。这些系统严重依赖于少数对几十年前设计和构建这些系统有企业记忆的个人。此外，恢复程序可能复杂，可能会造成重大加密等基本控制措施，以及强大的日志和审计功能。它们也容易受到数据完整性户端）、依赖过时技术和有限的自我服务能力而受到困扰。这些问题阻碍了生产力，并意度。通常，这些系统缺乏直观且易于使用的配置器，这些配置器集成到平台的端到端），整合到一个统一或更少的平台（s）中，组织可以降低总体总拥有成本（TCO），并在云采用和基础设施优化方清单继续。这些挑战共同强调了需要对核心系统景观进行战略审查，以及涉及现代化或完当然，在所有这些考虑因素中，评估对客户的积极影为什么保险公司缓慢地接受这些驱动因素并动员计划通过实施更支持其这并非一个简单的决定。这样的转型既复杂又繁琐。它会对业务产生颠覆性影响，因为它通跨越多年时间，并且从历史上看，它通常成本高昂，回报率不确定（我们稍后讨论商业案例决定使公司长期承诺于一个技术解决方案，通常为15年以上，以此外，高管们的声誉取决于这些可能具有高风险的转型是否成功交付，许多保险行业人士都变革管理方面，许多保险公司都存在对变革的抵制，员工习惯了现有的系统和流程。转型引因此，尽管投身此类企业无疑是极有益于组织的来规划结果和途径，包括内部和外部方面，并进行全面尽职调查以选择合适的平台供应商和SI合作伙伴，同时需要的地方实施点解决方案。其他人考虑将他们的旧系统仅作为记录系统保留，并在其上方组织专业需求的定制方案。在许多市场领先的健康保险公司中都有这种方法的例子。许多保略一致，量化了财务收益，评估了风险，计算了投资回报率，应对了竞争优势，确保了可取代保险核心系统的强大业务案例，保险公司应关注成本节约和潜在收入增加。该案例应改善客户体验、推动产品创新和提高运营效率。然而，保险公司也必须考虑涉及到的复杂性、风险和成本，现代化转型，但由于其复杂性和成本，这一转变具有挑战性，需要有一个能够平衡有形和业案例。该机构建议保险公司将现代化不仅仅视为技术升级，而应将其视为保障其业务未。有力论据，而是更多地认识到现代化对组织及其未来至关重要。挑战在于长期的投资回收可确定性。然而，可以估计包括一次性实施成本和未来的运营成本（与现有的运营成本相人们可能会考虑使用每条业务线（LOB）的毛保费（GWP）预测作为衡量标准，或者更好的是使用（PBT），这可以捕捉到费用和损失比率。然而，准确地将这些利益归因于新平台或核心系统，而不是其他举措，如更优化的定价模型、营销活动、运营流程效率和生产力改进、新产品、组织变革、合并与收购、合作伙伴和渠道表现或一般市场条件，这要困难得多。我：我在多个任务中所采用的一种简化方法涉及专注于五年商业计划，该计划由的，因为这些PBT目标如果没有新核心系统可能会更具挑战性或不太可能实现。业务案例应该包括核心系统现金流分析，包括详细的单一成本和持续成本，包括退役节约，结合五年及以上的归属收益，可以得出净现值(9鉴于这是一项长期投资，我建议将计算延长至10年期限，对五年商业计划之外的增长率进行假设，并可能将PBT此外，重要的是，不要忽视那些应纳入考虑的无形利益，以支持商业案例。作者已经开发了一以及由数据和洞察力支持的人工智能。所有这些的推动者是ITB/E核心系统，例如，SAP、PAS、理赔每当核心系统转型的议题出现时，讨论通常立即聚焦于选择政策与索赔管理供应键领域，从而实现更成功和可持续的实施，以实现效益。此框架涵盖的范围远远超出了仅仅供应商选择的范畴，如图表所示。本文不可能详细展开这个框架的所有要素，它将仅关注核心系统选择和实施。法可用于产品合理化、流程优化、ERP和其他API集成、数据迁移、变革成熟度等，这些可能成为进一步出版的在实施过程中，当出现困难或延误时，将责任归咎于核心系统供应商的情况相当普遍，一种共识。然而，核心系统只是框架中的一个组件，并且依赖于其他组件的解决，以实现转型成功的核心系统转型的起点，一旦转型案例已被提出以支持业务战略，就是要明确界定则，以及关键成功因素。关注企业架构，对现状及其局限性有良好理解，并定义目标状态，这义目标状态架构可能需要经过多次迭代，因为在转型过程中，可能需要由最初就应建立的设计权。别出令人满意的组件、需要修复的组件、需要淘汰或逐步淘汰的组件，以及最重要的是，目前距。基于公司优先级的这项客观评估对于理解新核心系统所需功能范围，与其他系统相比，以接下来，评估业务状况，包括：。探索可能有助于包含在范围内的任何创新，这些创新将影响未来状态流程，例如引入生解决这些问题需要付出大量努力，但这是确保新核心系统不仅仅延续现有低效率问现企业设定的愿景和目标的基本步骤。相反，它应该是一种全面的企业与技术相结合的方法在选拔过程开始时，明智的做法是意识到并考虑关键市场趋势、供应商行为、实施保险公司政策管理和索赔平台供应商正迅速发展，既有传统公司也有新加入的企保险市场的需求。主要趋势包括：台是云原生的，而另一些则是云就绪的，但无论使用何种标签，只有少数真正提供SaaS解决方案。尽管迁移到云端是一个日益增长的趋势，但大多数部署仍然是本地化的，在英国，云部署的临界量尚未达到多组织受到供应商的鼓励，在考虑升级时抓住机会迁移到云端。可以说，这种从本地化到云端高级分析与大数据：工具帮助保险公司分析大量数据以•用户友好的界面：供应商正在优先考虑设计直观和用户友好的界面和门户，以确保保险公司和保单持有•安全和合规：对强大的安全功能以及符合行业规范的核心系统选择因组织特定的多种因素而异，这些因素需要根据实际情况进行调整以实现最佳1.根据最初定义的目标架构，确定转型的范围，不为了确定替换传统核心系统的最佳行动方案，通从当前遗留的核心系统迁移到新的现代化核心系统，然后淘汰—仅对新业务实施全新的核心系统，同时在现有产品运营中继尽管后者由于消除了产品和数据迁移的需求（这本身是复杂的）而简化了实施过程和新系统的复杂性，并在停用之前需要长时间维护旧系统，导致成本重复（更不用说定义与组织相关的战略参数，这些参数可指导新核心系统的选择。此参数列表需要个别定 ,以有效指导选择过程。以下是一个典型的参数列表作为示例：声称他们可以在单一平台上覆盖所有保险业务领域（LOB）。另一种选择是专注于财产与意外险（P&C）线或功能方面的需求。这种务实的方法与选择顶级（镀金）解决方案形成对比，后者保险技术供应商的一些未经证明或不成熟的解决方案。同样，风险偏好可能决定了组织愿保交付，例如，使用经过验证的方法和具有深入了解解决方案的成熟系统集成合作伙伴， ,而不是承担一些风险，以期以较低的成本交付更创新和定制化的解决方案。在选择一个在特定地理区域内没有本地经验（或已建立的国家级层）的供应商时，也存在重要的风险。有许多例子，新案，为组织在未来保障对新技术实施的投入提供了有吸引力的选择。然而，由于缺乏足够验其稳定性和可靠性，这些平台中的一些可能尚未证明其稳定性和可靠性，并且可能缺乏种最佳实践。因此，平台功能与组织要求的紧密匹配是一种优势，并能消除权衡的该组织在最小化定制与接受一定程度的定制以确保基本功能与组织业务定制可能有必要，但它可能导致更高的成本、增加的复杂性和更困难的升级。另一势表明，向具有API启用功能的云原生平台转移，平台能够在管理和非侵入方式下通过低/无代码能力增强、甚至是在本地。重要的是要注意，许多平台，即使是市用（OOTB）功能的平台供应商，例如政策、索赔、账单、客户沟通、评级和承保等级、现有的企业级客户沟通和文档管理系统、再保险能力、欺诈、CRM等。可能还有其他因素需要考虑，除了上述列表之外。这些因素将,以指导选择。这些参数的发展需要由业务和IT部门共同承担，因为这种转型是业务转型，不应被视为IT转型。一个实体需要考虑的最后一个方面是它们是否属于一通用部署保持一致。重要的是，他们需要明确自己决策的理据和运营影响，无论他们选择独立系统试点和变更管理规划对于降低风险至关重要，同时关注长期成功确保系在一个典型的选择过程中，起点是建立一个相关的供应商长名单，然后利用前一部分讨以下是一个此类地图的示例，如图4所示。水平轴将已建立供应丰富性、解决方案稳定性、创新、现代架构、成本和风险之间的权衡。已建立供应商提供功能丰富的成熟平台，应商在图中的位置可以通过颜色编码进一步明确，以表明特定特征，例如支持所有业务线（LOBs）、原生云状态、公司规模、减少或有限的部署、地理重点（例如英国、美国或EMEA）、翻新的遗留系统等。框的大小也可基于组织一致同意的战略参数选择标准，可以缩小目标供应商的范围至短名单。以下两个示例说明了这一过程：的所有升级时，还可能带来更简单、成本更低的实施优势。这可能有助于克服一些预算限制，在回答该问题之前，讨论供应商面临的问题至关重要，这些问题可能导致某些行为，进供应商勤奋地工作，以交付他们认为最能满足市场需求、具有独特视角的保险平台。构建这 ,以及数百人年的努力来开发支持保险业所需复杂功能的丰富能力。然而，可以公平地说，大多数供应商在他们的产品提供方面存在缺口。他们通 ,或者通过提供定制化解决方案，或者通过从其产品组合中排除它们（依赖合作伙伴）来管理这些缺口。此外 关键点在于，选择过程必须确保平台在功能性和非功能性要求方面差距的透明度，以及特定些问题，无论是通过即插即用功能、配置还是定制（编码）。实现这种透明度需要保险公司明确少在开始过程之前要达到较高层次。一些保险公司可能缺乏内部技能来完成这项练习，并在选择第三方，采用他们所说的敏捷方法来界定要求。虽然敏捷非常适合详细要求的阐述，但将其作为在我看来，对于组织中的关键实践者来说，他们每天都要与遗留系统打交道，密切参与本功能至关重要。这可能包括以下元素：利用一个全面且集成的产品配置器，带有预配置的产品多货币支持，复杂的索赔管理，包括技术会计和诉讼预留，共同保险能力（领先或跟随再保约和FAC广泛的OOTBAPI，佣金，折扣（包括覆盖退款等等。一些其产品功能的冗长电子表格列表，因为这让他们在回应中几乎没有操作空间或细微差别（考虑到他们的回应在RF在与核心系统供应商相比与系统集成商（SI）合作伙伴签订合同时，标准流程涉及发布信息征求（RFI）随后发布提案征求（RFP），这仍然是首选路线，并且可能非常有益。组织需要决定最适合其需求、成熟度和风险概况的方法。该方法还可以与供应商进行测试，以评估他们的认可。一个选择是采用单一RFI/RFP流程，用于供应商及其首选的系统集成商（SI）合作伙伴之间的联盟。这种方法可能降低交付风险，因为供应商与在其平台上经验丰富的SI合作伙伴合作，确保交付的明确责任(“ 型有多种变体。为了确定适合特定组织的正确模型，需要对利弊进行彻底分析。下表总结了主。定供应商平台能力的有价值工具，从规格说明过索赔、销售、IT、首席信息安全官、财务、风险投资、合规、数据保护官、法律等）进行评估至关重要价值验证），涉及多个典型的预定义用例或挑战，这些用例或挑战集中在RFP技术评估中确定的OOTB（即开箱即用）不确定区域或弱点，并测试各种功能，从而增强对供应商平台能力的信心。重要的是运 ,根据需要举行研讨会、一般和特定演示、问答环节、所需的POC用例、现场审查和证是必不可少的，可以成为一个有价值的工具，帮助保险公司增强信心并评估特定供应商平台我将补充说，在过程中值得认真考虑的其他两个领域应该是数据迁移的方法（大史数据、产品、索赔、存档等）以及集成（在POC中测试的OOTBAPI）。本文的范围不在于对这些非常重要的领域进行任何详细的讨论以给予它们应有的公正，然而，一般建议采用分阶段的方法来进行间遇到的挑战以及他们在日常运营中获得的支持。在可能的情况下，现场访问是首选。在特定评估团队成员通常来自组织中的不同部门，他们对应该选择哪个平台有不要视角。最便宜的选项未必是最佳选择。再次强调，对成本各组成部分的详细分析，将其分供应商是否在为交易做准备。例如，固定价格合同可能存在某些限制并导致特定的行为，而时间与材料20 ,决定数据迁移方法，建立实施计划，并适当动员项目。发现阶段使团队能够紧密合作，及早解决任何技术、运营或治理问题，并为组织提供