Optimizing a Modern P&C Insurance Core Cloud Implementation

Thank you for joining us today for the Digital Insurance web seminar, optimizing a modern PNC Insurance Core Cloud implementation. As as we all know, P and C insurance system integrators play a crucial role in helping insurers understand and plan for digital transformation. They bring expertise in technology, industry best practices, and change management to help guide insurers through the very complex process of modernizing their operations. Today, we’ll get perspectives from two of these industry veterans as we understand how insurers can leverage best practices as they go about both planning for and then executing successful cloud projects. My name is Chris Bennett, and I’m the chief of strategy for the insurance business at Origami Risk. And I’ve been deeply involved with risk and insurance technology projects during my twenty five year executive career. Today, I’ll be joined by Bill Freitag. Bill is the founder of WikiFree and has over thirty years of senior executive and consultant experience across financial services, p and c, l and a, and even group insurance. After founding, growing, and selling multiple businesses, he now puts his expertise to work for exceptional start ups and InsurTech firms through the power of connection. With Wikifried, mister Frytech focuses his consulting, technical knowledge and insurance industry expertise on identifying and partnering with dynamic high momentum startups and insurance industry leaders for networks that empower truly disruptive and innovative insurance solutions. I’ll also be joined today by Brian Blair. Brian is a Managing Director at and has been working in insurance technology for over thirty years. He spent over twenty years of that career working in various technical and executive leadership positions for global specialty and P and C insurers prior to joining in twenty thirteen. As a leader in insurance technology practice, he is focused on strategic integrations, services, advising clients and enterprise software implementations. A little about myself. Over the course of, you know, more than nine hundred cloud implementations with Origami, we’ve seen and experienced, you know, multiple, you know, challenges, and we’ve seen system integrators as vital partners in the process. Perhaps the two of you could provide a little more insight from your perspective and the unique value your firms bring to the table, including the types of organizations you specialize in working with? Bill, we’ll start with you. Well, WickedFry is focused in on working with all insurance rated entities, And, we enjoy the insurance experience, and what we do is, like, we pride ourselves on our knowledge of the insurance business and knowing how to make our clients successful. It’s very important as you know to pick a partner that’s gonna help you implement in the cloud. And implementing in the cloud with somebody who knows and partners with you in insurance makes you successful. And we’ve had multiple successes partnering with Origami, and we enjoy that all the way along the way. Thanks for that, Bill. Brian, your perspective? Sure. Well, there’s really three areas where leveraging a strategic integrator adds value for our clients. The first is effective solution design The second is reduced implementation risk, cost, and time. And the third is resource scalability. So let’s start with solution design. Having completed more than a hundred enterprise software implementations, including policy, claims, billing, and digital transformations, we can advise our clients how to implement proven industry best practices for handling all sorts of insurance processing transactions. By starting with an optimized solution design that incorporates industry best practices as the as part of the initial implementation, we enable our clients to expedite realization of their ROI objectives while creating a positive user experience at the time of system launch. As far as risk, cost, and time savings, you know, another benefit of having completed over a hundred implementations is having developed a very deep bench of of resources who who have significant experience completing enterprise software implementations in p and c, life, and specialty insurance. You know? And that experience enables effective scoping, estimation, planning, and execution of an implementation in a manner that avoids mistakes and the associated cost and time overruns that can go along with those mistakes. And really, lastly is scale. Computing enterprise software implementations requires a significant number of resources. And the most most organizations just don’t have the appropriate number of resources with the right skills to complete their implementation. By leveraging a partner with significant experience in doing so, you’re you’re likely to avoid, one, having to hire all these resources yourself and then figuring out what to do with them when you get done because you’re not gonna need all of that large number of resources when you complete your implementation. You know, an experienced partner can help you avoid, again, costly mistakes that that will add risk and and time and and additional cost to your implementation by leveraging the the their collective experience. And then when those resources go away, you know, more or less just doing knowledge transfer to their to your own internal resources. Excellent. Thank you, Brian. So now let’s let’s dive into our discussion by by actually focusing on digital transformation. And, Bill, I’ll start with a question for you. How should insurers think about their operating model and the contribution that model has to their digital transformation success? Well, WikiFry, we have what we call our insurance business oriented operating model, and it really helps our clients think through what are all the different components needed to run an insurance company. So for example, we focus in on distribution first, who are your insured, how are you going to get your product to market, and then what are all of the different operating entities that you need to have involved? Like, you know, so you’re gonna need a policy admin system. You’re gonna need a claim system. You’re gonna need a billing system. You’re gonna need financials. We help our clients think through all of those things through this well thought out framework to help people be successful. And we found that through this, the most important part of digital transformation is focusing in on the insured and how you’re gonna distribute and and move your product to market with them. This is where we found that, like, it makes a big difference as to what the customer experience is and what the customer journey is as you begin to walk through that. And we found that this is, like, our way to, like, help our clients think through things. We have one client who is a start up workers’ comp company. They bought a shell company. They are a bunch of brokers. Love brokers. So I don’t want it to seem like de minimis on that. But, you know, brokers do not understand the insurance industry. So we help them walk through and think through all the different items that they need to think through to make them a successful operating entity. And today, I can tell you today, we were able to successfully launch them in about four months to in a workers’ comp product with Origami, and we were they’re successfully writing business today, and they’re still building out their framework for being a successful operating entity based upon the iBOOM, our insurance business oriented operating model that we help them think through things. And they help them think through things like do we need to be an MGA? Do we need to have an insurance company? All those things we found out what was right for them, and that’s how we made them successful. Excellent. Thank you. Thank you very much. Brian, question for you. Was kind of a, you know, similar similar, slightly different take. Change management, in particular, is an important consideration during digital transformation. What advice do you have when it comes to managing the process of change as a part of digital transformation? Sure. Thanks, Chris. The the best advice I can offer when considering change management as part of any implementation is to clearly identify your business objectives prior to planning your implementation and include any required change management activities required to realize those business objectives as part of the implementation plan. Software implementation can create changes for your organization in several ways. One, changing the way that you interact with your customers or business partners. Certainly, digital enablement of customer interactions or using fully automated integrations to communicate with your business partners are common triggers of change management activities as part of any implementation. And another common change management activity as part of your implementation is adjustments to your organizational model that are required to enable either new or amended business processes using the new system. Adding a roofing or changing various positions in your organization structure typically must be completed prior to the launch of your system to allow time for training of the impacted resources and to operationalize your new business processes. By way of example, let let let’s consider a, you know, a very common implementation objective, improving the efficiency of your integrations or of your interactions rather with your business partners by implementing fully automated integrations with those partners. Switching to fully automated integrations almost always creates change management activities. You know, a a very common operational efficiency improvement is enabled as part of, say, claims software implementations where where you’ll automate your integrations with either glass repair vendors or rental car companies. Without partner integrations, insurance carriers or TPAs typically interact with their glass or rental car vendors via the telephone. They’ll call on the phone, and they’ll either authorize rentals or they’ll authorize glass repairs on behalf of their insureds. Billing and payment are also, you know, typically handled on a claim by claim basis where, you know, the bill comes in, a check is cut by the claim examiner to to to pay the pay the invoice and the expenses allocated to the claim. That’s the typical model. Increasing operational efficiency means building an integration, a live integration, to avoid those phone discussions between your claim examiner and those vendors. In order to enable that, the first change management activity is the contracts between the insurer and these vendors typically have to be amended to enable electronic interactions via that new integration. And the business processes currently used by the claim handlers to engage with the glass and rental providers will change. The claim examiners will require training to prepare them to use the new system to authorize rentals or authorize glass repairs. And some customers may require notification as well regarding, say, new claims processes if for glass claims, they’re gonna be calling a different number now because you’re likely gonna have your claim reported directly to the glass vendor as opposed to your claims department. You know, your finance and AP processes may have to change as well. You know, when billing is fully automated, you’re likely to get one bulk bill at the end of the month where you’re gonna have a single ACH transaction to pay for all the rentals or all the glass repairs in a single month. You know, instead of cutting checks to those vendors on a claim by claim basis, you’re likely just going to have a single ACH transaction paying for all the glass or rental repairs in a given month. And the AP resources may have a change in their job role whereby they just spot check a monthly bulk bill invoice to make sure that there aren’t any errors there before paying. Again, all of that all that retraining and those process changes are gonna require a change management plan as part of your implementation plan to make sure that’s all completed in time for the system launch when those new processes go live. This is another area where leveraging a strategic integrator can be helpful to mitigate the risk of this change management as part of your implementation. We leverage an experienced change management team that operates as part of our insurance technology practice that has deep experience helping clients not only to plan the change management activities, identify them and plan them, but also execute them as part of the implementation program. Okay. And and, you know, kind of a follow-up question. What strategies do you use to help employees adapt to some of these changes that are brought on by digital transformation? But then also, how do you address potential resistance to change? Like, really, the the the best way to to deal with both of those conditions is stakeholder engagement. You know, the the the resources who will be impacted by these process changes are very frequently engaged in the design process for these new integrations or or these changes to the business process. That that can include everything from including them in in workshop sessions during the the engagement planning. There’s stakeholder surveys are frequently done by our change management team collecting information from these different stakeholders and and, you know, warning what they what they feel they need to make their jobs easier and and to streamline processes. And and it’s through that stakeholder engagement where you get buy in from that that community. They feel they’re part of the of designing the solution, and they’re much more likely to embrace the solution once implemented. All right. Thank you, Brian. Let’s shift gears a little bit and focus a little more on technology. When we think about cloud based solutions and consider cloud based solutions and technologies, when you recommend those technologies to P and C insurers, why are you typically recommending one platform over another? And more specifically, I guess, and Bill, I’ll start with you, what criteria do you use to evaluate cloud technology on behalf of your clients and why? Well, the table stakes obviously is they need to be have a SOC attestation, which means that they’re, you know, certified by their auditors to to know that you can rely on them. And after that, then we really dig into what does the security look like, when you’re moving data back and forth between your cloud providers and your own organization, how secure is that? We look at scalability. How quickly can you scale up? Because with a number of like we’re seeing a lot of new progress in the E and S market and that’s a market where you get you dip in, you dip out of and they want to be able to scale up and scale down. And I think knowing that your cloud provider can do that is very, very important. We’re also looking at you know, accessibility, you know, where can I access the data? Where can I access the the, application? You know, the cloud provides all of those things. And certainly, when we’re in this remote hybrid workforce, you know, people wanna be able to access things wherever they are, and they wanna be productive, and they wanna be successful. And so we’re looking at all those things as we look at cloud providers, applications in the cloud. Right? Because a lot of people are working either in the AWS market or they’re operating in the Azure market. We don’t see one as better than the other. They’re both equally successful. But what we want to do is see scalability, security. We want to see either make sure that confidentiality protection of data is there. Those are all the different things that we look at when we’re helping advise our clients. Alright. Thank you. And and and, Brian, how do you assess, like, the compatibility of an existing system when you are are in an environment with an insurer with the proposed digital solutions? And what should insurers consider in this regard? Sure. I’ll echo, you know, many of the Bill’s comments related to, you know, cloud space or with AWS or Azure or what have you. Not necessarily one better than the other, and and the and what you need to consider really doesn’t change depending on the on the platform you’re on. But, you know, you know, typically, just to in order to assess interoperability or compatibility of your existing systems in a modern digital platform, really, the first thing you need to evaluate is how these systems will communicate. Any system you select that will need it will need to integrate with other systems to enable accurate and reliable sharing and processing of information across those systems. And if your existing systems aren’t designed to enable effective reliable integrations, you’re gonna need to complete some refactoring of your legacy systems. That refactoring typically involves implementing common standards like JSON or REST or SOAP or XML for exchanging data between systems. You can also leverage middleware to manage communications between your legacy systems and your new digital system. If you need to refactor your existing systems to enable compatibility, the with your digital platform, the best approach is to basically implement a wear of abstraction that will separate your your various legacy systems into components, and that will that will limit the number of dependencies between the systems as well and ease your maintenance burden going forward. It’s also very, very critical to evaluate your organization’s security standards and whether or not the digital platform either meets or exceeds your current standards. It can be difficult to refactor existing or new platforms to satisfy required security standards, to protect your data both at rest as well as in transit, to implement, you know, multifactor authentication. So evaluating the the security protocols leveraged by your your platform when you’re making your selection is is is very important to confirming compatibility. Okay. Thank you. So flipping around a little bit, you guys bring a lot of experience in the in in particular arena. Any insight into why some cloud implementations fail and what from both a technology perspective, but also change management or or even other reasons may have contributed? Well, I don’t I don’t think that cloud makes a difference. I think technology projects, regardless whether in the cloud or not in the cloud, the focus needs to be on people, and I think Brian was talking about change management. So getting people aligned, getting people understand the objective, getting people to let down their barriers are all critical success factors for any implementation. And and in I’d I’d love to say that CloudWood is gonna solve everything, but it does not solve the people problem. And the people problem is almost always the number one objective that you need to focus on. And, Brian, any thoughts? Yeah. I I agree with Bill. You know, it’s a and, you know, cloud really doesn’t matter. You know, enterprise software implementations or implementations can be on prem, it can be on the cloud, but the the issues are the same. You know, in my experience, implementations fail for, you know, only three reasons. Lack of effective planning or scoping or estimating or or resource scheduling. Lack of there are required organizational sponsor or leadership support or resource support just to support the implementation or an ineffective implementation governance model that doesn’t enable you to effectively control scope. In thirty two years of implementing software, I’ve never experienced an implementation that failed due to technology. Software configuration, scalability, and bandwidth can be adjusted to meet your clients’ needs so long as the solution is properly vetted prior to the implementation in the planning phase. Know, minimal adjustment to your client. Thirty two years, Brian. It’s only thirty two thirty two. I’m showing my gray hair here. But successful software implementations are are while they’re dependent on selecting the right technical platform, they’re much more dependent on selecting the right team to complete your implementation. I agree with Bill. It’s all about the people. Great insights, guys. Thank you. Alright. Let’s let’s switch topics again and and talk a little more, you know, about ROI and and the financial impacts of these projects. You know, I’m sure for you guys as it is for us, it’s common for insurers who are looking to modernize operations to ask for help in quantifying a return on investment. And we know there isn’t really a one size fits all answer. But for each of you, bringing your experience to bear, how do you typically respond? And do you have any particular guidance on how insurers should approach this question? Bill, we’ll start with you. Well, my favorite story is a story I had one client in, it it was an executive committee. And they go, how do we do I go, how do you do ROI? And they go, we well, ROI is only for the projects we wanna kill. They’re not for the projects we want to go forward with. So with that in mind, okay, there is strong ROI. I found the strongest ones are around business growth and, you know, premium, increases in premium. We were working with one client right now where they, they wanted to take all of their different underwriting platforms, meaning the risk bearing entities, and be able to let all their underwriters write on all of them instead of just one of them. And so we’ve been able to helpfully successfully make them so they can all their underwriters can use, like, an admitted platform, a Lloyd’s platform, and an E and S platform so that wherever they’re quoting and however they wanna write the business, they can come up with the most competitive strategy. So that is a strong business driver. When you look at, premium increases, revenue increases, those are the strongest ones. Of course, there’s ones where you’re going to look for customer service, that’d be more in the claims arena, but certainly those are strong drivers as well. But if you do not have a strong driver, then then my suggestion is that you that you don’t do the project because you need to have strong momentum, strong driver. I as we’re talking about people and aligning success, that’s what’s important. Yes. That that makes a lot of sense. And and what what projected costs, you know, when you think about, like, upfront expenses, even ongoing operational costs, should be considered and budgeted for as as a part of this process? I would always say that, you know, we one, you need to scope out the project. I think Brian’s been really good about talking about, you know, scope definitions, scope control. You need to understand that for the the the upfront cost. But I would say is when you get into if you’re in the in one side of the pond, you call it business as usual. If you’re on this side of the pond, you call it production support. But I think you also need to say what what are we gonna need to do and how can we realistically plan our business? So if, let’s, for example, say, delegated underwriting authority, you know, how many new agreements, how many new underwriting teams am I gonna bring on this year? That’s gonna drive how much cost there’s gonna be. And so steady state is different for every organization. There’s some that go through change, and then they get their steady state stays linear. There’s some that go to steady state, and that’s they they really did the project to begin with for exponential growth. And I think you need to carefully plan either scenario or someplace in between because that’s where you’re gonna find out, I need to have the resources I need to be able to be successful and be realistic about that. Great great points. And and, you know, if if we think about these transformations, you’re not doing them for today, you’re doing them for the future. Right? It’s the future revenue, the future gains that that you can get. Brian, kind of a follow-up to to that question. Thinking it that from that perspective, right, the digital transformation really is a forward looking play. How do you help ensure that digital solutions are scalable to accommodate future growth? What are the things that you think about and you advise your clients to think about? Sure. I I for for me, the best way to future proof your solution is to map out your growth strategy and your business planning assumptions to identify your growth and scalability requirements. Essentially, you need to know where you’re headed so you can plan for scaling your operating and organizational models as well as your technical platform as needed to enable that plan growth. You also need to select a platform with an established credible product roadmap for evolving the platform with a commitment to that roadmap that’s demonstrated by a history of significant and sustained platform investment. You know, essentially everything your platform partner does to support your future needs as part of their product roadmap is one less thing you’ll need to worry about. And and choosing a cloud native, you know, multi tenant SaaS partner can help ensure that your your platform will evolve in a way that limits the future effort and investment required from you as that platform evolves. You know, as far as evaluating the the the the technical scalability requirements of a modern digital platform, there’s really two primary factors that drive scalability. The first is software design and IT infrastructure, and the second is the scalability of the platform processes and technical resources needed to operationalize performance and scaling management. When considering hardware design and IT infrastructure, look for a solution that enables both vertical and horizontal scaling. Horizontal scaling, you know, usually just means adding more nodes. Vertical scaling usually means adding CPU or memory to existing nodes. You really need both. You need to be able to scale horizontally because vertical scaling is really limited by hardware. And when it comes to scalability, cloud is really the way to go. For most clients, cloud will provide almost infinite scalability for a properly designed system. And and highly scalable cloud solutions commonly leverage technologies like Kubernetes or ECS for software deployment management activities, you know, load balancers, elastic storage, data lakes. These are all common components of highly scalable systems. You know, if you can find a SaaS provider that utilizes an effective continuous integration or continuous delivery pipeline to manage their software delivery platform, odds are they’re a a pretty good candidate for you, and they’ll they’ll offer you a scalable platform. Thank you. Now I know we’ve we’ve worked together on a few projects, and and I know, you know, I’m thinking of one in particular, but but it might be good to share an example, you know, for a client that had to that knew they had forward looking growth plans even as they were beginning their technology journey. So I’m I’m thinking specifically of Harvard. Any learnings you can share there? Well, I think they more or less did what it is that we talked about. They they know where they are now. Their current you know, it was a claims implementation. Their current claims volume, you know, they know what their future acquisitions look like and and their their, you know, premium growth model, which, you know, claims will generally follow fairly linear line with that. They’re built now to handle their current claims volume when considering their organizational model as well. The way we design the solution, they don’t want to have to scale up their staff in a straight line with their business as it grows. So basically, they’ve designed enough efficiency into the model whereby they when their claims volume doubles, they’re not gonna have to double their claims staff. They’ll be able to grow within an organizational model that is practical for them and their and their physical footprint. And that’s that’s exactly what you need to do as part of your your your scalability model is understand your business objectives. In that case, it was growing your growing the volume of your business without growing the volume of your staff in a straight line with that, and then designing a technical solution with enough efficiency to enable that. Thank you. Good good insights. Alright. Let’s talk a little bit about projects themselves, some pitfalls and best practices for for implementing cloud solutions, which is really the big challenge, you know, for for a lot of insurers. So, you know, let’s get into some more specifics about projects, and and really thinking about the project management angle and running a good project. You know, Brian, you know, from your perspective, what is a reasonable timeline for a digital transformation project? And how do you advise senior leaders on how to both set and then manage expectations internally around that project? Sure. Sure. Well, as far as advising senior leaders, in terms of managing expectations, there are three key items that are critical to communicate, which is a clear scope, a clear vision, and a clear schedule for the project. You know, because it really, no two clients are alike. There’s no simple answer in terms of a reasonable time frame to complete a digital transformation project. You know, execution velocity can vary significantly across organizations. So you need to evaluate the organization during the inception or planning phase to establish a practical timeline based on the unique characteristics and business mix of that organization. In the most general terms, digital transformation projects can be completed in ten to eighteen months, depending on the client and depending on the scope of the implementation. That’s why the most critical phase of an implementation is the inception phase where basically scope, effort, cost and the implementation timelines are determined. An effective inception phase is typically completed in eight to twelve weeks For a single component such as claims or policy, probably another nine to twelve months may be required to complete the implementation depending on the number of products, number of integrations and other components to be implemented along with that component. For a full suite, multiple lines of business, policy billing and claims, typically fourteen to twenty four months end to end. And again, we typically advise senior leaders to manage expectations by planning conservatively and allowing for twenty percent time and cost contingency in their plans, and to commit only to what they’re confident they can deliver and make sure they understand what’s expected of them during the implementation. All stakeholders understand what’s expected of them during the implementation and what they’re likely to experience at system launch. There’s very few implementations that go live without at least a single fast follow release to resolve at least some unexpected issues from the implementation. So again, you just have to manage expectations accordingly. Okay. I know you mentioned you mentioned inception phase, which which makes me think, you know, kind of about milestones and phases in a project. How do you typically think about breaking down a project into manageable milestones and deliverables, And why? You know, what what drives that that breakdown? So the so EYE leverages a hybrid agile methodology that breaks down implementations into five phases, pre inception, inception, build, stabilization, and deployment. Milestones are established within the build and stabilization phases that are specific to the scope of the scope and governance requirements of that implementation. So in the pre inception phase, it’s more or less an inception mobilization phase. Really, what we’re doing there is we’re gathering technical and business documentation required to plan the inception phase, develop the content that you’re to review in workshops and then schedule the workshops with all the required attendees. Then during the inception phase, our goal is to understand the requirements well enough to establish scoping details sufficient to accurately estimate cost and time and resource required to complete the implementation, the remaining phases of the project, implementation stabilization. Work products from the inception phase typically include an implementation plan that describes dependencies between the tasks on on things like vendor integrations and and vendors to engage with us to do those implementations as well as client activity dependencies as well, you know, doing work to support integrations, doing work to support security setup, or building accepting fees to downstream systems so they can test downstream processes. And and a a functional requirements inventory and an integration inventory are also very common products from the inception phase as well as a governance model. We also frequently complete detailed requirements for the first build iteration that enables the build phase to begin immediately after inception. And the number of build iterations will be planned during the inception phase based on the the scope and and timing complexity of of the implementation. And so, you know, we’ll just as we move on to the build phase, we’ll iterate through one one through x of those build iterations depending on how many are planned, also frequently called sprints. In order to build the scope components of the requirements needed to complete the following build iteration as well, You’ll gather those requirements while you’re building in one iteration, you’re gathering the requirements for the next build iteration. And so it’s more n minus one basically is is where you’re gathering the requirements of the build. We also include what’s called early business testing during the build iterations, which is really a means of evaluating solution design as approved and the requirements while introducing the system to the resources that will frequently complete the UAT phase. And early business testing is particularly effective at identifying what we refer to as requirements defects, which is the user will look at the system and say, I know that’s what I asked for, but now that I see it, here’s what I know I need. You know, typically, those things are uncovered in UAT unless you do early business testing and you engage your user acceptance testers, testing the functional components while they’re built during the build iterations. And it’s it’s much better to to to catch those issues then when you have more time to react. When you’re catching them in UAT, the it’s much harder to solve the solve the problems under time pressure. And then, you know, during the stabilization phase, you know, we complete system and integration testing, which basically includes testing of all integrations as well as feeds to the downstream systems as part of end to end transactions. And then the the the SIT phase is followed by user acceptance testing, the the last part of stabilization prior to production deployment. And, again, I’ll just repeat it, that the most important phase of any implementation is the inception phase because an effective inception will enable you to to accurately estimate and plan your implementation with all the dependencies to make sure all your milestones are achievable. Yeah. Thank thank you. And and we know planning is super important. I I would ask one follow-up question because we all know that no matter how well we plan, unexpected issues, changes, they happen. Right? During during almost every project, something something won’t go according to plan. How do you typically think about managing the project communication, keeping stakeholders informed, and more importantly, keeping the project moving forward when you have those those sort of unexpected occurrences that that you weren’t, you know, weren’t originally accounted for. Yeah. That’s a great question, Chris. And and, you know, as I mentioned, you know, one one of the the the work products of of an inception phase is your governance model. And and an effective governance model will typically include a project communication plan, which basically establishes who are the recipients of communications, what what will be the content of those communications, and how frequently will they receive those communications throughout the program, and who’s going to communicate. So that communications plan is typically how you keep everybody in the loop. The the most important part, in my opinion, of project governance is is change management or scope management. And and and the way that’s typically described in in in the governance model is you will define a decision authority matrix that allows you to identify specific groups or levels within the organization and the guardrails around the types of decisions they’re able to make. And those guardrails can be measured by, you know, time to complete the change or cost to complete the change or what have you. But but what’s critical in your decision authority matrix is that it describes a change management process in a way that’s going to allow you to maintain decision velocity at an appropriate rate that isn’t going to retard the schedule of your program too significantly. So, you know, typical typical change management decision matrixes look something like the the SMEs that are working as part of the Sprint, you know, to perform functional testing on developed software and whatnot. You know, we’ll typically load a Sprint at about eighty percent effort, leaving twenty percent of the effort in that Sprint or or burn down of the Sprint to allow the the the SMEs engaged with the in that that build sprint to make decisions about where things appear on the screen and colors and that sort of thing. You know, you really don’t wanna bother your senior leaders with with those decisions because they don’t have a big enough cost or time impact to to cause a change in your schedule or the cost of your program. If you wanna add an entirely new integration or if you do an acquisition during a build phase and and you need to, you know, incorporate yet another system as part of your implementation, you’ll have a different line in your decision matrix that involves executive management that can, you know, approve changes like, you know, adding new integrations or, you know, add this much time to the program, add this many dollars to the program. And by only elevating those decisions up to the executive level, you know, you can again maintain an effective decision velocity and effectively control scope as well. Great. Great. Great points, Brian. Thank you. I wanted to shift gears just a little bit as we think about, you know, best practices when we’re when we’re implementing cloud solutions. You know, one of the the big concerns for a lot of organizations when they’re when they’re, you know, either moving to the cloud or going through any real really any digital transformation is around data security and compliance, Bill. So I wanted to dig in with you a little bit. How do you think about ensuring that customer data will be securely handled and compliant with industry regulations in in this type of transformation project? Well, we start with, looking at data in transit and data at rest. And in transit, we wanna make sure it’s encrypted. We wanna make sure that our end nodes are minimal. We wanna make sure that those nodes are secure. And when we look at data at rest, we still wanna see it encrypted. And those are some of the best practices today, although not followed by everyone. It’s not that hard to implement, and it’s it and it is fairly significant, for securing the data. Well, then we go to the next level, which is we look at masking of data or deanatizing the data. So we’re looking at, like, how do we take it so that you cannot identify who that data is associated with? And so I think some of these things are likely like, a little bit more cerebral, but, like, you look through it. But, like, one of the simplest things that people do not think about that they should think about is, so I have my production data. My production data is very, very secure. I go and then I use that in my user acceptance test environment or some test environment. And then I may not have the same level of standards. Well, we recommend that you do have the same level of standards. We also recommend that when you’re using data within a test environment that you you you you anonymize the data because there’s no reason for that to to have, like, the full authority and rights of a production data. What you wanna do is you wanna make sure that that data is useful for your testing, but it doesn’t need to be the full production data. So you can enhance privacy enhancements by anonymizing that data as well. And so those are some of the techniques that we use and we suggest to our clients in order them to have them be in the most secure environment. And it’s really kinda interesting because we do work with a lot of cyber companies, and, you know, that’s where, you know, we we’ve learned from them and they’ve learned from us. And, I think it’s it’s one of the best things about the insurance industry. There’s just a ton of collaboration. But your your cyber friends out there, will help you with, you know, with some of the best practices as well because that’s part of their industry and that’s you always lean on your insurers because they have some great content rich expertise. Thank you. And and and, Bill, you know, as we’ve talked about kind of the the full life cycle of the project, Brian kind of laid out all the different phases that go into successful project. You know, at the end of the day, there there there is a time when that project is moving into into the live environment and into production. Right? And we’ve talked about change management upfront. But but, specifically, you know, in your role as system integrator, how do you go about helping with, you know, post implementation support, training type issues, and address any of ish those issues that may come up? Because at the end of the day, a successful project doesn’t stop when we get deployed. Right? It continues on and making sure that customers are successful using that system and that their customers are successful. So how do you think about that? Well, I I really like the concept that Brian talked about in terms of early business, testing, because we believe that getting the people who are gonna be using the system involved with testing earlier is better. It not only helps you test the system and find out if you have requirement defects, I think as Brian pointed out, but it also helps them learn how the system works. So we love to have the the business community involved with the testing so they learn and understand how to use it. The other pieces, though, is that there is a velocity of the business. I think I talked about that before. There’s some that, like, you’re gonna still be in a steady state environment, but many people take on these transformation projects because they’re looking to grow their business. And so as they’re looking to grow their business, you need to know and understand what are the drivers and the dynamics behind how do I plan for that. So I think I talked about it before. If you’re in a delegated underwriting authority environment, if you’re gonna bring on a lot more MGAs or, you know, very common in today’s practices today is people are buying underwriting teams or they’re buying books of business, you need to be able to plan for that velocity to be able to support it. Okay? Because most people think steady state is steady state, and I think steady state is somewhat a misnomer because a lot of people have growth plans. And so you need to factor in what’s it gonna take for me to grow and what are the different components of that growth. If it’s a new underwriting team, what does it take to bring on an underwriting team? If it’s a new program, what does it take me to bring on that program? If it’s a new line of business, what does it take me to accelerate that? What does it take me to support that, Right? Because steady state is really not any business is not in steady state. People are looking to grow. People are looking to expand, and you need to figure out what those dynamics are, and that can build your support budget in your so you can be successful. Fantastic points, Brian. That’s that’s certainly something that we see. It is is there is no static end state. It’s it’s, you know, constant growth with the business, so fantastic points. I I wanted to come back to something you said on the question before, right, which is, you know, you you guys have had a lot of success and and started to really work with a lot of folks out there that are in the cyberspace, which is why, you know, you you’ve come across a lot of data security issues. I know that that, you know, we’ve had the good fortune of working with with both partners, WikiFry and And and it’s not every project that you get two system integrators that come together on a mutual client and work as smoothly as as as this team has. You know, on the on the Triumph cyber implementation, we were fortunate enough to work with with both of your organizations. I think it’s really a great case study in in what can happen when, you know, good processes, you know, people, and technology all come together. I know we went live in in four months, which is incredibly fast to to bring a system up. What would the two of you say about projects like this? And then any helpful takeaways from that engagement? Well, I mean, the good news, Chris, I don’t know if you’re aware that they’re going to ask us to do another one. They want to bring up another line of business. I don’t know we’re at liberty to talk about it too much, but I’ve always said that the reward for good work is more work. So Brian, thank you for your successful partnership. Chris, thank you for yours. But what it came down to is we focused in on first of all, Josh is an incredible business leader. He set out a clear vision. He set a clear vision, and we knew what the vision was, and we knew what our roles were, and we all performed our roles, and we all got together to focus in on success. So I think, you know, one is clear goal, clear leadership. I think Brian’s talked about it a number of times already. There was clear scope. There were clear objectives, and we were able to satisfy those. And, we look forward to the next one as well. Yeah. I I agree, Bill. The you know, certainly, the leadership team at Triumph is is just fantastic. And and that was one of the the key success factors. They they made a lot of decisions the right way to enable them to to to go from start up phase, you know, in, what, October to, you know, get going live in in four months. You know, the the first of which was pragmatic planning, evaluating their current limitations, you know, what they could operationalize as an organization upfront, and making sure they engaged resources to help them to bridge those gaps. Bill brought a lot of the business planning and structural just the administration of standing up a new operation, and they handled that beautifully. That coupled with selecting the right platform. You know, the the platform, you know, being a SaaS platform enabled very rapid implementation where you’re not worried about, you know, setting up a configuration of billing. You’re just you’re configuring the system to meet your needs. And then selecting the right partner that could scale sufficiently to enable very rapid implementation. You know, that that planning and that engaging the appropriate resources were were critical to to just getting the basic building blocks in place. And then the leadership engaging, you know, to to to Bill’s point, Josh, having a very clear vision around scope and time and the business problem they were trying to solve. But then it wasn’t just words. Those words were backed up with action. This team was actively engaged every day with with with the full team, basically, you know, getting the build out done and and operationalizing the platform. And it was that kind of leadership backing up the vision was was really that’s it. Those are all the all the ingredients you need for a successful rapid implementation. Yeah. And and and I think it really was a a fantastic success story. And I think it it was the coming together of, you know, the process, the experience, the rigor that the two of you bring, you know, to a project like that with with the technology offering, the single instance multitenant SaaS, you know, that Origami provides that allowed us to move quickly to be, you know, both in configuration of the system but in continued evolution as we worked with with the client to to deliver a meaningful solution in a minimal amount of time. It really was about, you know, driving speed to value. And then as we think forward looking, it’s about scalability. Right? It’s about growing into that next program and then the next program and the next program. It’s about being future ready. It’s a it’s a platform that’s designed to, you know, to continue to evolve rapidly. Right? Leveraging that that configuration, that configurability of the platform, that low code, you know, sort of way to to implement new programs and changes. And I I I thought the application of that in this particular project really came down to to the people both on the client side and the partner side helping to drive that project, which was fantastic. And, for us at Origami, the focus is always and ever on how do we continue to make our clients successful, to prioritize their trust, their success and to constantly be thinking about innovation and continuing to drive speed to value. Because to the point that you guys have made throughout this presentation, there is no static state. These are projects that are investments, and they’re investments so that the insurer’s business, the MGA’s business can continue to grow and and to be ready to take advantage of new opportunities. And you want those future projects to be just as painless, as well run, as short in time and duration getting up and running as the initial project. So looking forward to continued growth both with Tram and then with other clients where we’re working together. I wanted to give a a special thank you to both of you, Bill Bill Freitag from WikiFry, Brian Blair from for taking the time today to discuss this this important topic for our industry. And I just wanted to give each of you maybe a a a quick minute. Any final words of advice, words of wisdom for insurers out there as they look to, you know, to their future, their near or midterm future at a digital transformation project? Sure. I guess in closing, you know, I’m gonna assume that some of the attendees in this webinar are seeking to understand the formula for completing a successful implementation. You know, and by attending this webinar, that they probably gleaned a lot of helpful information to do just that. You know? But that being said, you need to keep in mind, even the best platforms can be difficult to implement. Again, it’s not necessarily always about the technology. It’s really about the people. You know, if it was easy to to to, you know, do one of these implementations, somebody would just write a book describing all the steps of cookbook, and and everyone would buy it and then go off and do their thing. You know, being honest in the assessing the capabilities of your organization. And if you have a stable of seasoned professionals that have significant experience completing these types of implementations, then by all means, embark on that implementation independently. If if you don’t, you know, certainly, you know, you won’t regret selecting a partner that you’re comfortable with that that can help you to be successful to to help bridge the gap for those skills in your organization and and help you get these things done. It’s it’s it’s there’s no shame in reaching out for help. These things are difficult, and, and it’s a key to success, based on my experience. Thank you, Brian. Bill? I would say that, you know, I think we’ve already said it, but making sure you have a clear objective, making sure you have a clear vision, making sure you have the right team, whether that team’s with partners or internal. You need to make sure you have the right skills and capabilities. But at the end of the day, there’s no no organization is an island. So knowing and understanding the ecosystem that you’re developing and knowing how to partner with that ecosystem is gonna bring you success. And having the right ecosystem, having aligned cultures, having aligned values are what’s really, really important to making any of these things successful. Technology might be the easiest piece of all of it. It’s the people part, the process part, the, you know, getting along part. Those are all really super important. And, course, you need great technology. But great technology is out there because we know that. So those would be my closing thoughts. Thank you. Thank you to you both. Thank you to the audience taking time today. If you’d like to learn more about how Origami Risk works with system integrators like Wikifry and to deliver speed to value for core P and C insurers and MGAs, I invite you to download our free guide at origamerisk dot com slash implementationguide. You can also learn more about Origamerisk and our single instance multi tenant cloud solution at origamirisk dot com slash insurance. Thank you everyone for joining us today and goodbye.