Disclaimer slide is not to be removed. Requirement per DST Legal Department.
Pacific Life is a financial service company. We are not a technology company. Our goal is not to create new technology. Our
Road is curvy. See all the ruts in the picture. I’m sure its filled with pot holes and bumps. Everyone can easily recognize that it is bad and needs to be improved. No brainer to go fix it.
So we pave it. Drive is quicker. Same path is paved, no ruts, experience is fantastic. Productivity improvements. Yipeee.
We are on the path to success. Everyone is more productive. Now instead of taking 5 hours to drive the road it only takes 4. But did we take full advantage?
Innovation is not just redoing what was already done with a slight improvement. Innovation is change. It is looking at the whole solution for a new way of running your business.
If we had straighten the road, we could have driven the distance in 2 hours.
Too often in IT, we do the minor improvement rather than really fixing the problem. This could be a result of budget or time. And sometimes, you won’t have the luxury of straightening the road.
We don’t ask the hard questions. We don’t ask the why questions?
How many of you have rewritten reports that no one uses?
How many of you have had to ask why we still do a task?
To get the best success out of the solution, you need to ask why?
We recently spent some time going through this process.
There are four key concepts to determine innovation.
We will be looking at each of the 4 and talking about how Pacific Life went through the process and the things we learned.
The first challenge is to find the problem. It sounds silly because sometimes it obvious. Other times, it is not.
Roadblock are the things that are preventing you from succeeding from the challenge.
Analyze is identifying solutions to the road blocks.
Prototyping is proving the solution has the desired effect.
I think this one of the most important steps of any innovation project. The biggest challenge is often trying to figure out what you are going to solve. Sometimes, its easy. Sometimes, its hard. But you have to identify the problem before starting on the solution. Otherwise, you might solve a different problem. And it might not be the one you are trying to solve.
So to identify the problem, you take data from a wide variety of sources. It might be a customer survey, feedback from a single customer, identifying trends, presentations from trade groups or conferences. These are the things that provide the spark to help identify the problem.
The problem can be stated in a variety of ways. They can be presented a challenge to a business condition. An opportunity for your business to expand market share. An idea of doing something different or more efficient. Or might be a new strategic direction for the company like entering a new market
For us, it was looking at a new way to expand into a different segment of Life Insurance. We used a variety of sources from tends in data, to trade groups publications, and some customer surveys. The Prime project was born from it. The problem was to encourage Financial advisors who do not sell Life Insurance to begin selling Life Insurance. To make it easy for them. And push us into a new market.
Roadblocks are the hurdles that must be solved before identifying solutions. For Pacific Life, we identified the road blocks for the Prime initiative.
It revolved around improving the overall experience that a Financial Advisor goes through. If we delivered a better process. Maybe they would be more likely to submit Life Insurance.
No one wants to talk about what will happen when they die. And no one thinks they will die.
Life insurance products can be really complicated. They are many different types. Every companys’ policies are slightly different.
Everything is on paper. And how many of you hate paper?
The application process is really wrong.
Have to talk about intimate details of your health
Tablets/phones are the way people interact. I don’t usually carry a laptop unless I’m presenting. They are bulky and heavy and such a pain.
Life Insurance is being sold by people who don’t sell it today because it is a pain.
Growth!!
Wanted to expand into new markets. We wanted more transactional business over the complex business that has been our sweet spot. We needed to make our products easier for people to understand. Not only easier for the insured but also easier for the financial advisor. We wanted to have products that a financial advisor who never sold life insurance would be comfortable using our application. And we wanted to make the processing of the life insurance to be much quicker and with better insight into the process. As a result, we rebuilt our entire workflow system to take advantage of automated underwriting and best practices in workflow with statuses integrated back into the portal. The site needed to support people doing business anywhere whether they are in their office using a computer or out at lunch using their tablet with the experience flowing between the two. We wanted the site to be something compelling for the users. It needed to catch their eyes and be the right platform for them to use. And after all that, we need to leverage this back into our existing business to drive the same benefits.
Each phase of
The enterprise revolves around BPM. It is at the center of the solution because it is tracking and managing everything. BPM is processing data from systems and providing updates to taking data from systems and pushing data to systems. If you have solution that doesn’t bypass workflow. You need to be rethinking the solution. Even if it is exception management.
For the Prime Initiative to be successful, we focused on 6 key areas for BPM. These things may not seem that necessary, but these things are the basis for the growing success of BPM at Pacific Life.
One of the key concepts that we like to talk about when designing BPM is to keep the user in their Primary App. This reduces the amount of application switching. We find users spend a significant amount of time switching to another system, logging in, and performing a search to find the work. If it is a task that happens over and over, the time spent is significant with no value.
As a result, we look at 3 key ways to do this.
API—bring the data into the app and save the data back out via an API. Our favorite is using REST
Deep Links—Cheesiest way. A new window pops up and the user is taken to the window to make the changes in the native app. Quickest and most efficient to implement
iFrame—Embed a ui directly into the app. The user does not realize where they are using another app.
Another key concept that we talk about is Formalizing Exceptions.
On my first workflow project, we were really concerned about covering all the exceptions in design. We were very careful to make sure that we found them all. And guess what, we were wrong on both sides. Some of the exceptions that we designed for never happened. And there were a lot of exceptions that we did not expect.
So the lesson here is allow the flow to be flexible for exceptions when going live. After some runtime, start formalizing exceptions that are most common and have the biggest hit to efficiency.
Another benefit of this approach is you also solve for the happy path. When an exception occurs, the goal is to get it back as quickly as possible on the happy path. More paths = greater complexity=greater maintenance=greater testing.
Process synchronization is one of the places that yielded the most efficiency.
The whole goal of workflow is to get the right work at the right time to the right person. If you have no way to signal between processes to make sure something is done before moving to the next step, then someone has to be watching and checking in on the progress on a regular basis.
It takes a lot of time to do this. And worse yet, a human can make a mistake and miss a change in status.
One of the major changes we made in the Prime Initiative is the concept of creating business events. In the past, these events were always detected by scanning for changes in the database. Really hard to move the location and worse yet, you have IT identifying when one of these events occurs. Not the business telling you. As a result, we let the business define these events in the workflow. The event are put into a queue where different systems can subscribe to them.
We have subscribers that update our portal. We have subscribers that generate an email. We see this as a standard way to publish events for other systems to consume and is one of the key ways we integrate with systems outside of BPM.
One of the goals that we have is to build common tools to solve some of our most common problems.
They are tools like
Searching image archives
Creating and editng revisable documents like Word and Excel.
Auto attaching documents
Creating other transactions as a result of a status
But all teams leverage these common services. And when we add a new one, we try to get all business areas to leverage it.
Why solve everything twice? Why re-invent the process?
At Pacific Life, we have a cookbook on how to implement solutions in BPM. We create consistencies between process flows and we speed up the design time. The cookbook has ways to organize work, ways to implement integrations, and ways to build process flows.
The best part is that teams who build reports know how to look at the data.
Prime spent a lot of time doing the four phases of innovation. During the period, we worked with a lot of partners to help shape the solution. But at the end of the day, BPM made all the innovation possible. We developed these 6 best practices into design methodology. We partnered with the operational leadership to help them understand that not only was this an investment for Prime. But theses practices were the future foundation of work and all teams using a BPM would benefit.
This made them buy into the long term vision. We are now bringing the last business units onto the common platform. Each one is smoother and with each one, we add to the overall BPM solution. Those additions benefit all the teams that are already on the platform.