Mike Kavaner:

Good morning, afternoon, evening, depending on where you are joining us from here today. So for the next hour, we’re going to talk about our journey, or Co-operators’ journey, to move from our on-premise solution for PolicyCenter and BillingCenter into Guidewire Cloud. If you’re expecting to hear about another topic today, you may be in the wrong session. So my name is Mike Kavaner and I’m the Vice President of Property Casualty and Technology at Co-operators. And I’m joined here today with two of my colleagues, Mike Curchin, the Associate Vice President of Property and Casualty Solution Architecture, and Grant Kelly, who’s the AVP responsible for delivering on our large initiatives for the PNC technology portfolio. And as you would expect, we provide and support the technology solutions to enable Co-operators PNC products.

So let’s get into some of the topics we’re going to cover today. So we’ll start by providing you with an overview of the Co-operators in Guidewire, and then we’ll touch base on the objective of today’s session, followed by a historical view of the Co-operators Guidewire journey. And then we’re going to get into the real meat of today’s session, which is to provide you with the insight we gained during our Guidewire Cloud transition. And now that we’re in the cloud, we’ll quickly review what’s next for us, including some of the new Guidewire features we’re taking advantage of, and then we’ll wrap things up with a Q&A.

So if we can get into an overview of the Co-operators. Co-operators is a leading Canadian cooperative insurer servicing property and casualty life and creditor insurance, as well as offering wealth management services with more than 62 billion assets under administration.

Our PNC book of business is over 4 billion in direct written premium providing home, auto, commercial and farm products. And as an organisation, we are here to provide financial security for Canadians and our communities while being a catalyst for a resilient and sustainable society.

Now, you’ve heard me mention Guidewire a few times so far, and I imagine most people on this call who are listening here today are familiar with Guidewire. But for those of you who are not, Guidewire is a technology company that’s 100% focused on providing property and casualty software solutions, to over more than 540 PNC insurers servicing roughly 20% of the global PNC direct written premium. Their main product is Insurance Suite, which encompasses PolicyCenter, BillingCenter and ClaimCenter of which Co-operators utilises for most of its PNC book of business. In fact, Co-operators was Guidewire’s first Canadian client.

So let’s get into the objective of today. So as an early adopter of transitioning from our version seven on-premise PolicyCenter and BillingCenter solution into Guidewire Cloud Platform, let’s just say we encountered a few bumps along the way. So what’s our objective of today? We want to help you be more successful in your journey to Guidewire Cloud by sharing the key lessons we learned from our experience.

And with that, I’ll hand it over to Mike Curchin.

Mike Curchin:

Looking back a bit over 15 years ago, our technology landscape for policy administration was highly complex. We had more than eight different legacy systems, and as you can imagine, maintenance of this many systems was daunting. Beyond that, the technology behind them made doing even simple changes difficult. With this in mind, we set forth on an ambitious initiative to consolidate and align on a single modern suite of insurance applications, Guidewire, with PolicyCenter, BillingCenter and ClaimCenter that would help us modernise, improve efficiency and enable our business partners. We are able to go live in 2008 with ClaimCenter followed by policy and billing in 2010, and this started a multi-year journey of converting our book into these systems. Shortly after going live, we upgraded to version seven, which at the time was the most recent version of Guidewire software and we were successful. We were able to replace and decommission our legacy technology while empowering our staff with a more modern intuitive system to help use and help foster innovation. We were able to automate many challenging business processes and provide our developers with an up-to-date technical toolbox to meet our business needs.

While we’d made a huge investment to modernise, we started to lag behind. Every few years, Guidewire would release a new version of their software. However, we remained stagnant. Guidewire moved from version seven to eight, eight to nine, and nine to 10. Then with the release of their cloud platform, they actually increased their cadence to multiple times per year, causing us to fall significantly behind Guidewire as well as the rest of the insurance industry. At the time, our modern set of insurance applications had slowly become over 12 years out of date. This put us into sustaining support with Guidewire. And several components within our system started having large technical issues due to the age of the software. We had to put clunky workarounds in to help keep supporting these while others stopped working altogether. Security standards in the industry started becoming more stringent and went beyond what was being able to be supported by the platform. Even integrating with vendors became more difficult as they were using newer technology patterns that weren’t supported by Guidewire seven.

But what stopped us from upgrading? Well, there are many good reasons for this. Upgrades are extremely costly time-consuming programmes that divert attention away from other business initiatives. And during this time, we prioritised our legacy migration journey as well as many significant changes to our business, such as the introduction of our comprehensive water product and our digital national quote and bind programme. But it was starting to become clear that we needed to address our currency issues.

How do we start? Well, we knew that we needed a solution that would move us beyond today and into the future. And at the time, Guidewire was just working on releasing their new cloud-based offering, which was a totally different model than what we were used to with our traditional on prem experience.

In 2018, we started working with Guidewire and developed a plan to see what it could look like for us to be on the cloud with them, and we were able to convince our executives to help us move forward with that plan, starting in 2019. We were actually part of the first dozen to sign up for Guidewire’s cloud, which was the very early days, and we started our upgrade journey. Then COVID happened. We had to take a small pause to the programme and kicked it back up the following year. Now, in order to start a programme of this size, we had to get very strong business buy-in. Our business executives needed to be comfortable prioritising an upgrade over the many complex business initiatives that were being looked at.

And it was starting to become clear that the platform that we had was incurring high technical debt and effort to maintain and keep moving the business changes forward. A new platform would enhance our experience productivity and enable us to deliver faster with increased abilities to connect to integration partners via accelerators. But what we needed was a very strong business case and this needed to be extremely solid. So what we did was we combined multiple different aspects from currency where we would reduce our technical exposures and technical debt, bringing in a modern user interface with enhanced productivity to our end users. We also use this to enable business agility, which would be there to help enhance and build new business features. With the new technology available within a more modern solution, a more modern solution also came with enhanced capabilities that came with the upgrade to help provide our business with new sets of features. The move was also a SaaS-based model, where we were able to actually reduce our on-prem server footprint, reducing our overall maintenance and development costs.

And finally, with the model change, future upgrades were actually embedded as part of the subscription service where Guidewire would perform upgrades for us on an annual basis. This would reduce our overall long-term upgrade cost and prevent us from getting in the same situation ever again. But during our journey, we learned many other things. What we wanted to look at doing was embedding ourselves and having discussions with industry peers. We worked with many different insurers including a Canadian Mutual on a regular basis who were in the same journey that we were at the same time, we’re able to have open discussions, talk about problems that we were both facing and provide each other with advice and ways to help move forward. This is something I highly recommend if you are on a major journey like this.

From an approach standpoint, there are many different ways you can approach upgrades. What we chose to do was a technical upgrade where we would bring our existing configuration and make it work within the new cloud platform. What this did was it helped to reduce our overall effort and risk while limiting the changes seen by our users on day one. It would also set us up for utilising new features after we go live.

And while it was a technical upgrade, we did focus on looking at changes that we could adopt from out of the box where it had filled a gap that we had previously had to develop ourselves. But one major risk with technical upgrades is that you modernise your core but fail to ever utilise the new technology, the new features available to you. And to overcome this, what we’ve done is stood up a team dedicated to improving our system and this team will help make sure that we get the most out of our investment going forward.

In order to do this, what we really needed was the support of our senior executives. We had a lot of different people from VPs and our CEO backing us throughout the journey, and we actually saw that during the project, our COO became one of our largest supporters. This level of involvement was amazing. It helped provide the backing and support we needed to set us up for success. Our executive team is now a huge proponent of upgrades and staying current, and this helps us utilise the system to the best of its ability. For any executives listening, please consider rallying behind your teams to show the support as it’s truly appreciated. Be in this together with them. We also learned that there’s a high value in spending time to do a detailed inception. Spend the time upfront to understand what changes need to happen and build out a detailed plan to build everything together to meet those complex interdependencies, look at all the teams involved and make sure that they’re all planning towards that same goal and build out a structure that will allow you to achieve your objectives.

Grant Kelly:

One of our key learnings as a part of this journey was around programme management. Having a dedicated programme manager was crucial to the success of this programme. We realised this very early on that one person could not run a programme of this scale while working on other projects. Now I know what some of you may be thinking. We have folks who could do more than just a PCBC upgrade, but we tried this approach for a very short time and very quickly realised that was not the case. With the size of our programme of more than 150 people, not including our Guidewire team, our programme manager was key in ensuring we aligned with our business partners, our IT partners, and our vendor partners. The programme manager was crucial with stakeholder management and communications. We had several main areas such as steering committees, partner forum, and as Mike just talked about, most importantly, with our C-level executive engagement and awareness. With long programmes such as this, we wanted to make sure we had consistent support throughout. Our programme manager was key for ensuring both our CIO and COO were kept up to date throughout the entire programme, which then in turn ensured we had their support when required and we did need it on more than a few occasions.

And last but certainly not least, our programme manager was key to ensuring our programme documentation was in order. So when we got audited, we would pass with flying colours, and we did. Not to be outdone, and equally as important, were the partnerships we utilised and had throughout the programme. As mentioned, we had more than 150 people on our programme. Working with both internal and external partnerships was a must ensuring its success. On the internal side, we had many close partners. One specifically on the business side was the policy administration team. They were relatively a new team of the Co-operators who had helped the programme in so many different ways, communicating with a multitude of business teams on the program’s behalf.

Working with the change management team, which is a must, and with people in the field, they were a large part of our go live support and warranty phase. We couldn’t have done it on the business side without their support. And if you have a business team, you can work hand in hand with it, your location, make sure you partner up, you will not regret it.

On the IT side as always, we had a lot of critical partners, IT infrastructure who worked tirelessly on our new circuits and pipelines and access. IT security, who we worked very closely with to ensure our platform met all the required industry security standards and our own. And the IT data warehousing team who was a key partner with the cloud data access capability that everyone will go through eventually working on with Guidewire. On the external side, we had strong delivery partners. First we enlisted Guidewire as a lead delivery partner in the planning and execution of the programme, we relied heavily on their industry knowledge and understanding of the platform to execute our two hop upgrade. When we were planning this programme, the industry knowledge moving to the cloud at that time was still maturing, which is why we felt using Guidewire was one of our best options.

We also had other resource partnerships with our resource vendors to round out our programme team. With the amount of effort required to execute a multi-level upgrade, building out the new infrastructure and the new capabilities, we needed to ensure we had the right support. When all was said and done, we ended up fixing close to a thousand defects running three full dry runs as part of our execution plan, and we had three teams over seven different time zones helping us execute on our 85-hour migration. Partnerships both internally and externally were crucial as a part of the success of this programme. I can’t emphasise enough how important stakeholder communication is. One key learning we had that we’d like to share with everyone is that communication and the setting of expectations regarding the upgrade of this size needs to be done early and often. We engaged our change management team, our corporate communications team as part of the cloud upgrade to help us with this approach.

Utilising tools such as our corporate intranet for company-wide comms, we had consistent updates and FAQs for agents. We had training developed for users to help understand how things were going to change and where. Having constant updates for folks in the field about what’s coming and what’s changing was a must. And trying to make it easy to understand was really the goal. We utilised the analogy of a mobile phone upgrade. Things would be slightly different but better. There would be some discomfort for a short period of time, but it would be worth it. We did all of this and more because no matter how much you communicate, we learned and we knew there will always be some people who will have questions, they will have issues, or who forget what’s going on and need constant communications as a reminder.

Another cool thing we did was having a monthly technical drop-in session. This is where folks from anywhere could come in and ask us anything about what was changing, technical how-tos, changes to screens and anything they needed or wanted to know what the new cloud environment and platform.

We had a multitude of forms on the communication side. So earlier we talked a little bit about steering committees. We had partner forms, which was an extended stakeholder form to ensure all of our executives from all the impacted lines were updated and could ask questions where they wanted to. And again, most importantly, having the support of our CIO and CIO was key. These were some of the communication strategies and avenues we employed, which we saw great value in helping to get us to the finish line.

But as I mentioned earlier, start setting expectations early and often to ensure everyone understands what’s going on, it will pay off in the end.

Mike Curchin:

Testing of projects of this size is paramount. Throughout the journey, we learned a number of different techniques and different things that needed to be tested to ensure we would have the quality ready to go live. Make sure to test policies that have been converted into your system from a legacy system. Often these can be missed in newer test environments as they’re harder to reproduce. Don’t just concentrate on things that are there via new business within the system. Also, test what we call in-flight transactions. So these could be items where you have a policy that’s in renewing status on your old version of the system, and as you upgrade it a few days later, it’s now going to have to be bound. And what you want to look at doing is make sure that that data rolls over properly across terms and that it will be upgraded correctly and that in-flight transaction will successively do what you want it to do.

Finally, what we looked at doing was testing last minute changes. So you really want to hold off on as many of these as possible once you’ve completed your exhaustive sets of system tests, but inevitably, things are going to creep through that need to be solved. These can include last minute business changes, defect fixes, or even late cloud assurance items that Guidewire’s requests me to do. For each one of these items, make sure you fully review that item and understand what needs to be tested. Don’t just assume it will work in the new version. You really want to make sure that those get fully tested with that new version. And performance testing is something that often gets pushed to the end of the programme. I can’t stress the value of performance testing enough. Don’t wait until you’re fully finished development to start looking and building out your scripts.

Build these early. Focus on new patterns, new integrations that are being leveraged within the system. Things like cloud connectivity, things like SSL handshakes and authentication. Really what’s changing with the platform and where are those high risk points? Get those tested early because you don’t want to find out about those once you’re live in production. From an environment management standpoint, solid test environments are the key to good testing. Invest as much time in automation of building out an environment as possible. No matter how many environments you think you need, you’re probably going to need two to three times that. And for these, if you have to build each one of those out as a snow-climbing environment, it’s going to be a lot of effort and a lot of risk. What you want to do is automate as much of that process as possible and further plan, not just for your upgrade project for the number of environments you need, plan for what your BAU will like after you’re live. What projects are going to be kicked off after being live? And, do you have enough environments to support those? Get those in early before you deploy.

One valuable lesson we learned was having a very detailed run book or the steps needed to do a deployment. What we did was we looked at making sure that everything was included within our plan for that go live weekend. Everything was very detailed with who was going to do each step and everything that step included. We didn’t want any guessing to happen during a go live. Also, for this process, make sure you have very clear paths for escalation that people are ready to be there in case something does happen and that you have a plan to get the right people on the phone to move through that, including Guidewire.

You want to make sure that they have their experts on standby ready to support you. What we also needed to make sure was that there was clear communication between steps. We didn’t want someone to say, “Yeah, I’m finished my step,” and it not to actually have been completed. So we had multiple steps in place to ensure that someone didn’t start the next step until that prior step was ready for this, what we used was a code word, something that no one would say in regular conversation as that checkpoint between steps so that we could really ensure, yes, we are ready for that next step to continue.

Another valuable lesson that we learned was having constant communication. This could be hourly or every other hour, to communicate which step we’re currently on, what the overall progress is and how we’re tracking towards our end goal and send this communication out not just to the core team, but everyone who’s interested in that programme, including executives. We saw that they were very eager to check these constantly throughout that weekend. And by automatically sending these out, you’re also insulating your core team from people reaching out to say, “Hey, how’s the upgrade going?” You don’t want them to get distracted. You want them to have that focus and delivering the steps they needed.

Finally, these are very long deployments. Ours, we had a whole long weekend to be able to do that deployment. And when you’re thinking about that many hours, what we need to look at is ensuring that our staff, who are processing this, have the time to not burn out, not to get too tired and be very on point during that entire upgrade process. So what we made sure that we had was shifts set up so that each one, each person involved had a set amount of time that they were being asked to be fully engaged in the upgrade and they would’ve set time away from the upgrade where we wouldn’t have things like sleep schedules. So they were always constantly ready to be there for the upgrade and have full focus. Again, we don’t our staff to be burnt out. You’ll need them the day after you go live to help be there to support your system.

What we also learned was the value of dress rehearsals. Once you have your run book, you really want to make sure that those steps will work and we want to take that and repeat it multiple times. What this will do is uncover kinks, uncover missing steps. Or as you see errors, you might need to recover and find a better way to do this. Again, similar performance testing. You want to find these things out early. You don’t want to find them out in the moment. Practise, practise, practise.

Grant Kelly:

After we went live, we went right into warranty. Do not underestimate how much time you will need for warranty. That is a huge lesson learned for us. As part of the programme, we solicited industry feedback about warranty phases and how much time others had set aside or had used. We’d been told by industry peers, this is not your traditional warranty and to make sure we have a plan for more than the standard 30 days that most companies usually have. Our warranty support team consisted of traditional production support team, the project team, and multiple other business teams. Another learning we had is make sure you have extra hands on deck and ready to handle the increased call volumes and questions. Our support call volumes increased by 500% in the first week and we needed everyone on deck to be able to address them.

What we realised was that we were getting questions related to everything could be training, non-Guidewire related questions, Salesforce questions and general issues. This was because folks knew we had just completed a major upgrade. And as everyone in tech knows, all problems will be related to the most recent change. When we got into our second week of warranty, we realised due to call volumes and increased problems that our 40-day warranty wasn’t going to cut it. And we began planning an extension. With the support of our executive team, we had an additional two months to allow us to stabilise the platform with areas like performance and to address issues.

The additional warranty also allowed us to focus on client experience and stability of the platform. We didn’t want to hand over a project with hundreds of defects to our business partners. So as we got into our first extension, with that in mind, we requested one more so we could have a clean handover. Remember, this is not your traditional warranty. There will be bumps in the road. Making sure you do more than the traditional 30 days will benefit you in the long run.

One of the positive and major benefits that came out of our warranty phasal was an opportunity to go out into the field and visit with our agents and our call centre. Performing site was an eye-opener and a game-changer for us. Seeing how people on the ground were using the upgraded platform helped us get real feedback and data so we could adjust where needed, train where required, and coach folks on the fly. This helped us to address quite a few issues immediately, which in turn then saved our production support teams from even more calls and more tickets.

Just as important, was the fact that we were able to build relationships with key stakeholders in the field, which made them feel heard and that their issues were being addressed. It bought us a lot of street credit. Being in the field helped us to not only solve issues as they arose, also to help people differentiate between Guidewire problems and other platforms. As mentioned, we all know once an IT person is in the field, they’ll get any issue, no matter what application it’s from, it could be like your phone system could be from Salesforce. Having this information enabled us to share that feedback with our corresponding IT partners to have even these issues addressed, which also provided a positive client experience with our business partners.

Our site visits were so successful that we wish we had done them from day one. We’ve now adopted this as an approach for all major projects going forward. And a lesson learned, if anyone thinks about wanting to do these, we would recommend absolutely doing them.

Getting feedback from the people who use the product is an amazing way to improve. If you have the chance to do it, just do it.

Mike Kavaner:

When we reflect back, the cooperative was running really old Guidewire software with significant currency concerns and we were finding it difficult to keep up with our business demand. So where are we now? We’re running current software that we are contractually obligated to update every year and we’re experiencing an increased ability to deliver on business demands when utilising the new Guidewire software capabilities that are out of the box. So where are we going? Our next step is to transition our V9, our version nine on-premise ClaimCenter solution into Guidewire Cloud Platform with a target implementation date of early 2025. And we’ve also started to utilise Advanced Product Designer to successfully implement some of our complex commercial products. In fact, we’re currently innovating with Advanced Product Designer or APD and Cloud APIs by reverse engineering our established products into APD and then generating cloud RESTful APIs to enable quote and bind activities for one of our client self-serve portals. That pretty much wraps us up today for our formal presentation. However now it’s time for us to take some questions that you might have for us, so I’ll open up the floor to the audience.

Ben Telfer:

Thank you very much, Mike. Thank you, Mike. Thank you, Grant. A fantastic presentation. It covered so much in terms of your journey and also way you’re ahead. It’s very appreciate you sharing so much in terms of what’s gone well as well as some learnings. As Mike just said, that we will get to some questions. I do have a number in, but please do submit additional questions. We’ll have time to get to a few of those right now.

Before we do get on that, I just want to touch on something that Mike said around connecting with other mutual insurers, and I know you’ve done that with some peers in Canada, but it’s great that that’s happened already and again, that’s the potential that there can be more of that going on within the ICMIF network. So again, if anybody’s watching this now or watching the recording, please do get in touch and I know the Co-operators would be very keen to share their journey and also hear from other ICMIF members in terms of their experiences with Guidewire and their own transition to the cloud.

So in terms of a question for you based on your presentation, when transitioning from an on-premises solution to Guidewire cloud, many insurers utilise the services of a system integrator. What were your determined factors when making your decision to use or to not use the services of a system integrator?

Mike Kavaner:

So why don’t I take that first question. So when we started on our Guidewire cloud journey and we were going to Guidewire Cloud Platform, as Grant had mentioned in the presentation, there was not a lot of experience within the industry on that front. So really what we wanted was a partner that could help us transition and really knew that Guidewire Cloud Platform. And when we looked around, we felt that Guidewire was really the only company that could help us with that, because we felt that no one would know the platform better than Guidewire itself. The other thing is, we have traditionally not really utilised a lot of the services of the typical systems integrator, so we wanted to continue down that path as well is to, and we had typically use Guidewire to help us with some of our more complex Guidewire solutions, so that’s why we decided to go with Guidewire itself.

Ben Telfer:

Thank you. Mike, did you implement any new business capabilities as part of your cloud upgrade programme?

Mike Kavaner:

So I guess we’ll take that one as well. So Mike Curchin had talked about this during the presentation to some degree, where we decided to do more of a technical upgrade. We had used the terminology for earlier on within our programme and that really was to say we’re taking our existing solution and moving it into the platform in the same way. Wherever we took on a new business capability that required a zero effort for us, we did that. But if anything required any significant or just a little bit of effort, we decided to veer away. Really, we felt that the jump from version seven into the cloud platform was a big enough risk in itself, and so we stayed away from as many business implementation items as possible in order to reduce our risk and our scope to the programme.

Ben Telfer:

Thank you, Mike. You mentioned in the presentation around when the pandemic hit, there was a bit of a pause in terms of implementation. The question that comes that’s come in is a bit surprised with that because obviously there will be conversations when the pandemic hit is that digitalization was accelerated because of COVID. Perhaps you could share a bit about how the pandemic did pause the project and whether there was any positives of that in terms of the project being delayed and then some different implementation as a result of the lockdowns and various other pandemic related factors.

Mike Kavaner:

Our decision to pause the programme at the beginning of the pandemic was really at the very beginning of the pandemic. If you recall back to that time at the very beginning, there was a concern that the economy around the world would collapse, absolutely collapse because everybody, the commerce had stopped in a number of ways and as an organisation we sat back and we said, “Okay, what can we do to preserve our capital as an organisation?” We wanted to make sure that we lasted through a severe economic collapse. And that was our focus initially when we made that decision. So we stopped a number of programmes within our organisation to preserve our capital. Now, what we all know is that commerce picked up on the virtual side, on the e-commerce side. And so we did pause for a few months.

It was actually nine months that we paused. It was actually closer to eight and then we restarted at the beginning of 2021. And now did that help us? Well, initially we were going into Guidewire Cloud Classic, what Guidewire now calls their Guidewire Cloud Classic. That was our initial focus, but with our pause and our restart, Guidewire has stated nobody knew we’ll be going into Guidewire Cloud Classic. We had to go into Guidewire Cloud Platform and we were one of the first to be going in that direction. And I would say it was good in one way because we went on the newest platform with Guidewire, but also it hurt us because there was a lot of new steps, a lot of new techniques, a lot of new operational capabilities that Guidewire was not quite aware of in their journey to Guidewire Cloud Platform. So we learned and we went through a number of bumps along the way as a result of that decision and that change. So it helped us and it hurt us.

Ben Telfer:

Thank you. That’s a great answer. Very interesting to hear. And, reflecting back four years ago, it seems like a lifetime. Thank you for sharing that. A question that you probably have covered already, but I’ll ask it. Sorry. How did you handle the integration of Guidewire Cloud Platform with your exist in IT infrastructure and legacy systems, particularly regarding data migration and system compatibility?

Mike Curchin:

So from a system compatibility standpoint, what we looked at doing was see which items are truly anti-patterns from a cloud. And a few of those, we had to rebuild on newer sets of technology that would meet within Guidewire’s means. So Guidewire worked through us and did a number of workshops to uncover which items wouldn’t be compatible with the platform, and we created backlog items to alleviate those. One thing we also really had to work on was the pipes or the connection between our on-prem infrastructure and in this case AWS. We wanted to make sure that we would have a dedicated solid connection. We actually had to go through, and this is a big plan if you’re not already connected to the cloud, plan for looking at your data centre and understand we had to change network switches and firewalls to be fast enough to get that connection speed and that dedicated pipe to AWS. That was a major initiative and a lot of work. So that’s something to really plan for.

Beyond that, from a data upgrade standpoint, really focus on if you have a large database, how much data can you prune? Do you have old policies, old data within the system that you can get rid of before sending it over for that upgrade weekend? That’ll make the data transition faster and it’ll also make your upgrade deploy at a faster rate.

Ben Telfer:

Great stuff. Thank you. Thank you. Mike, have a couple of questions here. Did you identified any low-hanging fruit in terms of the new out-of-the-box functionality that you could implement?

Mike Curchin:

I think really what we started to utilise right after we went live was the new integration capabilities. What we found, I think I spoke to this earlier, version seven, didn’t have an easy way of calling into REST services where the cloud platform now has cloud APIs and it has native abilities to call into REST services as well as an integration gateway capability. We’ve actually utilised this for several new initiatives after we’ve went live, and it’s made development of these lots simpler, a lot faster to deliver and more standard to out-of-the-box. Previously, we had to have a lot of code to be able to do these sort of things in the legacy tech and it’s really a huge enabler from an integration standpoint.

Ben Telfer:

Thank you, Mike. Grant, did you have anything to add on that? I know you were going to comment.

Grant Kelly:

I was going to mention the same thing and we’re also looking at using APD as well as a new capability that Guidewire has. We’ve run some POCs with that and going into Guidewire marketplace and using their pre-built technology and downloading it, we’ve seen some real big wins with that technology already, just from a speed perspective. If folks have the opportunity to get in there and look at that in the Canadian market, they have some of that pre-built home and auto capabilities already put there. I’d say take a look because we’ve seen, I’ll say an improvement of months from a development perspective just from using that new capability alone.

Ben Telfer:

Thank you, Grant. Time for a couple more questions, I think, what was your rationale for shifting policy and billing only and did this cause any issues?

Mike Curchin:

What we were really looking at, I think there’s a couple different aspects. One being the overall size of the programme. These are very large programmes. At the time, policy and billing. We had on version seven claims, we had actually recently done an upgrade to version nine of Guidewire on-prem. And so we were at a much more recent version. We really had that big technical risk with policy and billing and we wanted to make sure that we would upgrade those together to that cloud, build out that infrastructure, build out all of those patterns, and that would set us up for an easier cloud deployment with ClaimCenter.

From a risk standpoint, it was fairly low in that their policy and billing for us are very intertwined. They originally shared the same database, they have very tight integration because of the way policies interact with that billing system. Claims was a bit more standalone in how it was connecting because it had to work with multiple different systems within our company to support claims across the board beyond just PolicyCenter when it was developed. That kind of decoupling helped with that deployment and we had an integration layer in the middle that makes it easier to repoint policy and billing

Grant Kelly:

Just to layer into that as well. Hindsight’s 20/20, but when you look at it, we’re really happy that ClaimCenter went second because the amount of lessons learned that we were able to utilise from PolicyCenter and Building Centre, and I’ll say right across the board from working with partners from architecture environments. I know Mike talked about that, just the process, the procedure, the data migration. We’ve not to jinx anything, but we’re going through the ClaimCenter programme right now and things are running really smoothly, partially because of all of that and we’re able to utilise everything we learned. It’s a blessing in disguise that we were able to do that second.

Ben Telfer:

Thank you.

Final question. You mentioned around having the backing of the senior executive and the senior team and how valuable that was to push this project forward. The question says that some people may struggle with having such a supportive management team is any advice you can give to how you can really bring them along in their journey and to make the decision and to get their support? Any advice you can give on that?

Mike Kavaner:

I will say trying to go to Guidewire Cloud and getting the business case in place for that was a challenge. We struggled with that. We tried for well over a year. And the business case was really hinged on the fact that each upgrade after that, after the first one we did, after that first hop, would be much easier to do in a much less cost. And that was really the business case for us and how we put it together. And initially I would say that we did not have the focus of our senior executives within the organisation. We had the ear of our CIO, but our COO was less inclined from a technology perspective, felt that we could handle it and so on. But the more that we got into it and the more challenges that we saw, the more interested they became.

I always say do not waste a great crisis. And this is a situation where we had a few crises along the way and we would raise those up and help people understand what challenges we were experiencing and how we needed help. And it’s interesting, our COO said after we were finished the programme, “I learned so much through this journey, and I’m so thankful that I had the opportunity to be so close to this programme.” And what we’re seeing now is she’s asking some really phenomenal questions moving forward from a technology perspective because she learned so much through this journey that it’s really helping us on programmes moving forward. And we feel the support not only in this programme for Guidewire Cloud, but all the programmes we’re moving forward since then.

Ben Telfer:

Thank you Mike. And for sure, that’s very, very helpful. Thank you everybody. Thank you Mike, Mike and Grant, fantastic presentation and thank you for sharing so much more information in the questions. I just want to reiterate the fact that if you are having any sort of issues on the journey or you’d like to share anything, both Mike and his team at Co-operators would be very willing to connect with you. Again, they’ve already shared the value they’ve got with connecting with peers across the Canadian mutual sector, also globally. I know Guidewire is such a leading platform for the P&C industry around the world. Please do get in touch with myself and I’ll be happy to connect you directly with the team of Co-operators and vice versa as well.

Before I leave you, I just quickly want to just share a couple of slides about some webinars. As I mentioned before, this webinar today is part of our digital mutual series. We have a number of case studies on there, each looking at different aspect of digital transformation. Please access those, they’re all available to all with members on demand via the knowledge hub. You can access more than 120 webinars on demand, on a range of different topics. Please check those out and access those again through the knowledge hub.

Just a final thank you to everybody for joining today and again, a final thank you to Mike, Mike and Grant for sharing Co-operators journey. Hope everybody has a good day and seeing you on a future webinar or virtual event very soon.

The above text has been produced by machine transcription from the webinar recording. ICMIF has made every effort to ensure that transcriptions are as accurate as possible, however, in some cases some text may be incomplete or inaccurate due to inaudible passages or transcription errors. Listening to or watching the webinar recording will allow you to hear the full text as delivered during the webinar but this is available in English only. Our transcriptions are provided to enable members to select the language of their choosing using the dropdown menu above.