Leah English – VP Sales & Business Development
OneShield Program Consulting Group. What is it, and how is it going to differ from the typical technology implementation and support services that a OneShield client might expect?
At OneShield, we have recognized that carriers invest a lot of time and energy into their vendor selection process. But once they acquire the technology they don’t always have a plan for how they’re going to optimize that investment and roll out the functionality as a part of the implementation.
OneShield’s Program Consulting Group ensures that there is a consultative approach throughout the client lifecycle. From the very beginning in the sales cycle, continued in the project kickoff, throughout the entire implementation and in any post-production services that OneShield might provide.
Applying OneShield’s implementation methodology in conjunction with [the] consultative approach not only ensures consistency in the client lifecycle, but it also ensures that the best practices from all our client implementations and really all of our collective experience at OneShield is leveraged for any new clients or existing clients.
Again, we recognize that an insurer might only go through a system transformation once or twice in their career, but collectively at OneShield we’ve done this hundreds of times. We really want to make sure that best practices are implemented for all our clients.
With the combination of best practices and OneShield Enterprise flexible platform… we’re protect our clients from implementing a new legacy system, which we see happen very often in the industry.
So, it sounds like this will significantly enhance the OneShield client customer experience. Can you give us some specific examples of how you set your clients up for success in the implementation?
OneShield Enterprise provides a process automation platform with a design tool and that’s how we build solutions via configuration. There’s an abundance of artifacts on our core platform and base functionality which encompasses the object model, workflows, UI, rules… that is really a solid starting point for our implementation.
What we are trying to accomplish across sales, implementation and services is to ensure that we are creating a common framework for the initial release of the implementation. We begin to talk with customers about during the sales cycle. It’s understanding how they can build either interfaces, integrations or functionality that they can leverage across multiple phases or multiple releases of the technology.
It is really important that our customers are prepared for long term use of the technology and they’re able to manage the platform post-production. That’s really something that we promote in our efforts to help insurers minimize their total cost of ownership for the platform.
All our clients, at some level, are self-sufficient on our platform and this is a result of this principle. During the initial release, when Oneshield is involved in the implementation, we’re ensuring that there’s this common framework that they can leverage in subsequent releases as they add new products, they enter new jurisdictions… They have this common framework to build upon for continued success.
I understand there’s something very special about the define phase in OneShield’s consultative process. Can you tell us how it will help ensure an optimal use of technology investment dollars?
The OneShield define phase is critical to the overall success of insurers’ transformation. The define phase is that first 30 to 60 days of project kickoff… and that 30-60 days is dependent on what kind of scope that is involved in the client transformation.
During this define phase the client organization and the OneShield organization are aligning on: What are the overall program goals? What are the strategic tenets?… what’s guiding the program and defining success for the program, and how the implementation team and the client team can approach the overall project with a “one team” mindset.
During the define phase we’re gathering data and scoping what’s included in overall roadmap. And, we’re also determining the sequencing of products and functionality for the roadmap, and what’s a high-level estimate for the total program. The deliverables from this define phase are key in having a successful blueprinting phase, construction phase and UAT phase. it’s essential to making sure that the project is kicked off in the most effective manner and that those deliverables are leveraged throughout the program.
Let’s discuss the three different categories of deliverables from the define phase. The first category is making sure that there is strategic alignment… Artifacts like your program charter, your governance model, and your overall program’s strategic tenets [Leah says “tenents,” but means tenets).
The second deliverable is a total scope analysis. This is making sure that all elements of scope are considered, and that there is a high-level solution design associated with that scope.
The last deliverable is a high-level plan for the rollout of the technology, and the high-level estimate for the roadmap.
The scope discovery exercise decreases the contingency from the estimate given in the sales cycle. And the estimate is even further refined post the blueprinting phase.
I understand there are three key roles or functions within the consulting group. Can you tell us how each one affects the consultation process?
Sure the program consulting team leads the initial define phase and consults throughout the program. The 3 key roles are business sponsor, business architect and solution architect.
The role of the business sponsor for the implementation is to ensure that there’s alignment to the strategic tenets and the guiding principles throughout the program. That person is the client advocate within OneShield, and providing input and guidance to any program level decisions that a client would make.
For the business architect, it is making sure that… they’re similar to a B.A. but they have a ton of insurance experience. They’re conducting discovery across the entire program and understanding high-level requirements to make sure that they can guide any large scope decisions that might have a budget or a timeline implication.
And, then the solution architect is the technical counterpart to that business architect. They are understanding that high-level design to making sure that that design is feasible and fits within the total program, and ensures that the common framework that we talked about earlier is being established in the early phases of the program, and allowing the client to be successful and optimize that technology spend.