The Wellness Wave

August 15, 2011 Leave a comment

The Healthcare landscape in the U.S. is currently undergoing transformation on several fronts. Health Care Reform, informatics, coverage types to name a few. One of the key areas that will create sustainable change in the U.S. healthcare system is the new wave of wellness.

In the U.S., we have been trained out of responsibility for our own health. We care more about what we put into our cars than what we put into our bodies. The system here has supported us to not pay attention to our bodies until and unless something is wrong, which is when health insurance kicks in. It, among other things, has helped create a culture of negligence among the population at large in the U.S.

According to the Center for Disease Control, chronic diseases cost $3 out of every $4 spent on healthcare. 70% of the the causes of chronic diseases are due to behavioral and environmental factors. Corporate Wellness Magazine claims that 50-70% of claims cost are driven by controllable behaviors.

No conclusive evidence exists quite yet, but it is abundantly clear that we can make a big dent in the healthcare expenditures by plaing a preventive role in disease management. Traditional healthcare insurance companies and plans have disease management programs to fight critical diseases such as diabetes, obesity, high blood pressure etc. Only recently are such plans beginning to adopt wellness programs to help members lost weight, stay healthy and away from developing chronic diseases.

If we are to have a serious dent in our national expenditure for healthcare, we need to take a collective look at how we empower ourselves and our co workers take a preventive role in staying healthy. The wellness wave is alive and well and will be among one of the key drivers in helping us train ourselves back into responsibility and ownership for our own health.

Categories: Uncategorized

Economies of scope: A new model of build vs. buy for healthcare payers?

December 10, 2010 Leave a comment

Healthcare payers, unlike other industries, still face the age old question of “do I buy core services such as medical management or utilization management” or “do I build that capability in house?”. Though many firms have proliferated and honed expertise in the various functions such as medical management or utilization management, the concept of economies of scope may be underplayed for payers to remain competitive and agile in today’s fast changing healthcare landscape.

Most of us are familiar with the term economies of scale. In a nutshell, it is when the marginal cost of producing the next unit of output keeps dropping. In other words, the more I produce, the lower the cost of production PER unit.

The term economies of scope doesn’t get used as often as economies of scale, but has hidden potential for Payers. Economies of scope refers to the lowering of the average cost when more than one type of product is being produced. For example, a research and development lab for innovative products will lower it’s cost of innovating each product if it is actually trying to innovate multiple types of products. If it only focuses on one product development, the cost of innovation for that product will be much higher than if it focuses on a diversified set of products to be innovated.

Let’s take the function of medical management for example. In one of my recent clients, we were exploring the possibility of building a gaps in care capability in house. When we looked at gaps in care just by itself, the question naturally emerged “why would we want to build that function when several vendors offer those exact  services at competitive prices?”. Not only so, many vendors have been doing this as a business for some time and have gained significant expertise in conducting gaps in care. It was a bit bold of us to believe we could build something better than what these vendors have built over the years.

However, through much debate we discovered that we were asking too narrow of a question. Our question was only around gaps in care. There are several other medical management related capabilities that a payer will be interested in. The solutions that are offered today often tend to be very specific and thus siloed. In other words, I can purchase a gaps in care service from one vendor that is an end to end solution for gaps in care only. If I wanted to purchase a health coaching service for medical management, I may have to purchase another service from that vendor or yet another vendor. Pretty soon, my portfolio of medical management services has many products and vendors in the mix with no expertise in house. For certain payers, this situation might be fine, but in the given case, we took a different approach.

Looking towards the future business strategy, we came to conclude that we wish to develop multiple capabilities in house, not just capabilities to do gaps in care. Looking at the technology stack, we assessed that several tools in the market place, such as rules engines, master data management tools etc. can be used to create a bedrock of such capabilities. For now, we would only build the gaps in care function, but sometime in the future we could leverage those tools and their inherent features to develop capabilities in other types of services. This would allow several pros as well as cons as shown below.

Pros

Cons

  • One, integrated system instead of siloes.
  • Economies of scope exist in developing multiple capabilities, similar to an R&D lab developing multiple products, lowering the cost of innovating each product.
  • Utilizes in house talent towards innovation rather than keeping the expertise outsourced.
  • Less complexity in managing a portfolio of services.
  • Difficult to be competitive in the short run.
  • Requires investment in terms of time and money.
  • Requires a shift in mentality to become an innovative firm rather than a processing firm which may not be culture appropriate for all payers.

For the given case, leveraging economies of scope was the right decision. Each firm must weigh and balance the pros and cons and their specific conditions to assess what is the right course of action. Along with economies of scale, economies of scope might just be the next concept to leverage for payers in today’s Healthcare landscape.

Categories: Uncategorized

Business Transformation and the S-Curve

April 20, 2010 2 comments

This blog post is a part of a series known as the Target Business Model (TBM) series. To learn more about what TBM is, read Target Business Modeling – A Primer.
 

What is an S-Curve?

The S-curve is used to describe several phenomena, but in the context of technology transformation, an S-curve shows the level of desired performance for a given level of effort for a certain technology.  In other words, a technology S-curve shows performance along a certain dimension as a function of the innovation efforts invested to reap that performance improvement. For example, the S curve below shows the performance of microprocessors as a function of the R&D effort.

 

 

 

 

 

 

 

 

 

 

 

 

 

Background on S-Curves and Transformation

S-curves are a good model to explain the impact of disruptive technologies, technologies that improve products or services in ways the market does not expect. Consider microprocessors for example. Moore’s law says that every 20 months microprocessor speed doubles. This type of technology has brought about unexpected changes in the market in terms of new software, software consulting, business intelligence etc.

In the example above, processor speed is shown as the dimension of performance. It is not always clear what the performance dimensions are for an s-curve in a given industry, especially when the industry itself is going through a transformation. For emerging industries, one must guess what the market accepted performance dimension is. In our example here, we will use processor speed since it is a well accepted performance dimension for the hardware industry.

When a chip manufacturing facility uses a set of equipment, they can continue to tune that factory to keep making better and faster chips. At first, a little effort yields a great deal of return (the bottom part of the S-curve). However, at some point the pattern shifts in the opposite direction and a lot of effort yields only a little improvement in performance (top part of S-curve). At one point, the factory will reach a state where a brand new factory with brand new types of equipments will be needed to continue to get higher performance for a give level of effort. In other words, instead of moving along the given S-curve, the factory would have to “jump” to a new S-curve as shown below. Such a jump can be characterized as a transformational shift since it requires a fundamentally new factory with fundamentally different types of equipment, architecture and technology.

This type of “jumps” are often known as “discontinuous” innovation. Continuous innovations are evolutionary by nature, staying on the same basic technology, simply improving it (movement along the s-curve). In contrast, discontinuous innovations are revolutionary by nature, going to a new technology altogether. This dynamic is shown in the diagram below.

 

 

 

 

 

 

 

 

 

 

 

 

 

Note that in order for the processor factory in this example to continue getting reasonable ROI on their R&D investments, the factory is forced to transform itself to a brand new factory. This is similar to any IT program or project where an older system is reaching its limit (ex. A mainframe based application reaching the top of an S-curve) and needs replacement (ex. Technology modernization of a mainframe system).

S-Curve and TBM

During TBM, large groups of users will tend to move along a given S-curve rather than jump to another S-curve altogether. For example, a healthcare client of ours had been focusing on a problem of quality assurance of inbound insurance premium checks. It was assumed that the performance dimension here was the cycle time and quality inspection level for such checks (number of errors per thousand checks inspected). The users were designing a process that would inspect the checks faster and log better accuracies by using the new technology. The performance dimensions used in this thinking were still cycle time and quality level. This was thinking that is moving along the same S-curve because nothing fundamentally was changing except the usage of a few more software modules to track the same work. However, once we kept digging into why such checks needed inspecting, we unearthed that erroneous checks are allowed to come in from insurance agents and a one time error is allowed for such checks. This policy had actually encouraged such behavior and agents who knew checks were incorrect, sent them in anyways in hopes of “working around the system”. However, this sort of inspection incurred a good deal of expense on the company while providing no real value to the customers. The best solution was to alter the policy and avoid such errors altogether, i.e., change the dimensions of performance to be “value generated to customers”. Doing so would not only cause a process change and policy change, but also the usage of the technology would be different than merely tracking the error, but scanning and storage of the check to allow for higher quality traceability and discourage non-value generating activities in the future. This was an example of small scale transformational change using new technology in a whole new way to achieve the business objective of avoiding unnecessary error checking.

Take Aways

  1. Know  which  S-curve you are on and where on that S-curve you currently reside. Are you trying to move along an S-curve or jump to a new one? If you are implementing a brand new IT system, it is reasonable to move along the S-curve because you might reap a lot of benefit for little effort. However, when working on a legacy system, chances are you are on the top of that S-curve and a lot of effort may only yield little benefit. In such instances, jumping to a new s-curve may be a better option.
  2. Ensure that you agree on the dimensions. When designing new solutions and systems, it is often NOT the case that people are on the same page and in agreement about the performance dimension under question. Cycle time vs. customer quality perception are two examples. It is not surprising that a customer service representative might want to focus on quality perception while an operations person may focus on cycle time. Neither is wrong, but during TBM discussions it is important to identify which dimension is being discussed to ensure a fast and efficient modeling of the future state process.
  3. Is the dimension under discussing the correct one? Dig deeper than usual. In our example above, the performance dimension of cycle time and errors appeared to be the correct dimension, but after some root cause analysis, we discovered that “value generated to customers” was a more appropriate dimension. Such root cause analysis will help you see where you spend a lot of effort for sometimes not so good reasons.

Parallelism: What’s the limit?

April 15, 2010 Leave a comment

This blog post is a part of a series known as the Target Business Model (TBM) series. To learn more about what TBM is, read Target Business Modeling – A Primer.

Week of 3/22/2010

TBM sessions by nature are very involved. They include not only coming to a common agreement about processes, but also involve working out the productive disagreements of various groups coalescing into a common approach to business problems. As a result, time is always a limited resource during the TBM sessions. To work around the time constraints, one may be tempted to break out the TBM team into sub-teams and perform work in parallel. What we have found is that such parallelism of work can work well, but they do have their limits.

One example of parallelism we used during our TBM session was to split up the different lines of business as sub-teams when discussing the current state processes. We had two teams who physically took two parts of the room and drew out their own current state processes as process flow diagrams. We set this up as a fun competition, seeing which team could do a better and faster job in completing their process flow diagrams on the wall. Then, we would allow each sub-team to briefly present their current state process to the entire room, explain nuances and identify process improvement opportunities as they saw it. The opposing team could ask questions or suggest further opportunities as they thought about the process.

Once both teams had completed their current state presentations, we focused as one team on creating the future state process model. Having reviewed the individual current states and talked through some improvement opportunities for each had helped in setting the groundwork for discussing a future model.

It all seemed like parallelism was working in our favor. But quickly after the week was over, we learned that certain members of the smaller business line didn’t feel comfortable enough expressing their views when it came to the future state process. This was due to some fairly complex factors such as fear of job losses in the future state model, supervisor to employee relationships within the TBM team etc. As a result, we created separate sessions with that line of business. With a much smaller team, they seemed to have responded much better. Though we thought we could apply a high degree of parallelism, it turned out that some parts of the session had to be done in series.

Take Aways

  1. Maximize parallelism even if it leads to making mistakes. You will never know exactly what the right amount of parallelism is for your TBM sessions. But your goal should be to maximize the amount of parallelism since you wish to maximize time savings. Even if you learn after a session that parallel processing among teams did not working (like we did), you can always change course and finish off in a series fashion. We found that such series meetings actually went a lot faster than we thought because of the pre-work done.
  2. Pay attention to team dynamics, especially the minority views. Remember, transformative changes are challenging and human nature is to resist change, even when change is rational. Especially the minority views must be kept in check. The TBM facilitator should follow up consistently with all team members, especially the ones in a minority group, to see whether their opinions are being heard. The same topic may be discussed in parallel with one set of teams but may need to be discussed in series with a different set of teams. It all depends on whether the business users are comfortable enough inserting their opinion in the larger team.
  3. Recruit executive help if appropriate. Sometimes it may be appropriate to recruit executive help when it comes to teams not feeling comfortable in sharing their opinions. Often, team members need to hear things in their own ways, from leaders they are familiar with. Since change is difficult, having a familiar leader assure the team of their voices being heard can go a long way.

Start with what’s simple, then build on it

March 31, 2010 Leave a comment

This blog post is a part of a series known as the Target Business Model (TBM) series. To learn more about what TBM is, read Target Business Modeling – A Primer.

Week of 3/15/2010

We had noticed that some days during TBM would be very efficient while others were not. As we started to notice more closely, we found that the first process flow of the day seemed to have set the tone for the rest of the day. So we started to experiment and here’s what we found. Some of us thought that if we start with a complex process first, and we overcome all barriers, then subsequent discussions would become easy. However, we found that starting with a simple process first created momentum in the group and also allowed people to build on some easy concepts which would later be used  to discuss complex ones. To some degree, this is similar to “building the basics” first and then tackling larger, more complex process flows. In subsequent meetings, we always started with simple processes and have consistently generated efficient and effective TBM sessions.

What is the system of record? Data Strategy, Synchronization and Quality Management

March 31, 2010 Leave a comment

This blog post is a part of a series known as the Target Business Model (TBM) series. To learn more about what TBM is, read Target Business Modeling – A Primer.

Week of 3/8/2010

Which system is the system of record for a given piece of business information? This is a question that often gets asked during a TBM session. “System of Record” is also referred to as the “source of truth”. System of record refers to the unique IT system  that is the authoritative data source and responsible for maintaining and housing the data related to a certain business domain. For example, a business may use a Customer Relationship Management (CRM) software to house its contact information. At the same time, that same business might use an email system where much of the customer contacts happen to spill over to. Ultimately, however, if there is a discrepancy between the data in the email system and the info data in the CRM system, common sense would dictate that the CRM system will win out. That is because the CRM system is the “System of Record” for contact information.

Even though this concept sounds quite simple, this can have far reaching implications in terms of the usability and ease of your end solution as well as the cost of systems integration for your solution.

During TBM sessions, the issue of system of records is often raised. This may sound confusing or misplaced  because a system of record strategy is typically a design-time consideration. In some cases, however, the system of record strategy has direct effect on user experience and usability (ease of use) of the solution and may be relevant during the requirements and analysis phase. For example, managing work queues is a common component in any healthcare solution. Work queues are managed via workflow management software (WMS). If an external entity, such as a parent company contains a WMS which cannot be used for internal work by the subsidiary, it is possible to have two separate WMS systems and thus 2 systems of record for work items. This may cause the user difficulty in synchronizing the two work queues. In such a case, systems of records may need to be discussed during TBM and at least a high level agreement reached. In other words, business users might be concerned about their day to day work which is affected by which system stores which data. The technical architects (especially the data architects) are particularly interested in the system of record since it has direct effect on their business intelligence and reporting solutions.

Sometimes there exists a hierarchy of data and all parts of the hierarchy may not reside in the same system of record. In other words, a parent piece of data may reside in one system of record and the related child piece of data may reside in another system of record. For example, a CRM system may hold contact information about a customer. However, when it comes to the orders created by that customer, order information may reside in an Order Management System (OMS). In such a case, the system of record for contact information is the CRM system and system of record for order transactions is the OMS.

Sometimes it is not possible to only have one system of record for a given solution. For example, in a healthcare insurance company, several insurance members may be saved into their respective member management systems according to which market the member belonged to. However, due to security restrictions and cross market member search needs, a “search” system can be created which would house the latest copy of member information from ALL member management systems. Such a search system has to be kept synchronized so any new member that was added to any of the member management systems would also be replicated to the search system. Usually in situations like this, an Enterprise Application Integration (EAI) tool is used to synchronize the data or to synchronize the processes. The EAI acts as a glue and keeps such systems in synchronicity. Usually EAI tools are used for large projects where the system of record does not follow a simple strategy. Otherwise, small programs are written to synchronize the data among various systems via what is known as a “point to point” architecture.

Take Aways

Develop a System of Record strategy during or after the TBM sessions. It is unlikely, but it may be possible to have one created before TBM. If that is the case, you may save a lot of debate and confusion during the TBM process. Either way, create a solid System of Record strategy as it will affect your design decisions, usability and ultimately business adoption and productivity of your solution.

The Importance of Team Dynamics In Facilitating Business Models

March 29, 2010 2 comments

This blog post is a part of a series known as the Target Business Model (TBM) series. To learn more about what TBM is, read Target Business Modeling – A Primer.

Week of 3/15/2010

Team dynamics is a key consideration and factor for facilitators to keep in mind during TBM sessions. According to Bruce Tuckman, teams undergo 4 necessary and inevitable developmental stages (discussed below) . We found that the TBM sessions were no exception.

  1. Forming: This refers to the team simply forming, coming together and understanding one another.
  2. Storming: This refers to a period of high uncertainty and even some frustration and conflict within the team because some key standards may not have necessarily been agreed upon and some team norms or operating agreements are yet to be created.
  3. Norming: This stage refers to the team establishing norms AND following them. This marks the end of the storm as new rules and cultural norms curtail the chaotic experienced from the storming phase.
  4. Performing: This stage refers to the team “hitting its stride” and performing well. Team members start to complement one another’s strengths and compensate for weaknesses.

Our TBM sessions were scheduled to cover different business topics each week. Each week, we had different sets of business end users who were subject matter experts for the respective topics. These business users represented about 30% of the entire team (remember, the TBM team consists of business users, process analysts, technical architects, technical business analysts and facilitators).  Because 30% of our team was being changed each week, we were essentially dealing with entirely new team dynamics each week. As a result, we saw the entire cycle of forming, storming, norming and performing happening each week. In fact, there was a very predictable rhythm to the entire team. Monday morning seemed to be forming, Monday afternoon and Tuesday morning seemed to be storming with a good degree of the stereotypical “chaos”. Wednesday had consistently become the day where the entire team would start performing and catching up on the delays from Monday and Tuesday. Most Wednesdays we would move ahead of the schedule when only Tuesday we were behind. Thursday and Friday continued to serve as the performing stage of the team.

Take Aways

  1. Expect to go through these phases. You cannot avoid the developmental stages of a team, the real victory is to go through them at high velocity and churn through them quickly. Had we taken Monday through Wednesday to go through storming, it would not provide us the time needed to accomplish what we needed to accomplish. Also, none of the phases are “good” or “bad”. They are all necessary for the normal functioning of a team. Had we not had the storming phase, which felt chaotic, we would not have the collaboration during norming and performing stages either. Treat each stage with the respect it deserves while keeping in mind that your goal is to get to the performing stage.
  2. Expect to go through the phases multiple times. Every time there is a significant change in the team members (in our case 30% was significant enough), know that you no longer have the same team but your team is an entirely new team with new team dynamics EVEN if you have the leaders and facilitators be the same. Be able to identify when you have a “new team” and need to allow that team to evolve. Focus on going through these stages again and go through them as quickly as possible.
  3. Inform your business users of the expected stages to help set expectations. Letting the users know what to expect will help them go through these phases with greater ease. The storming phase can be quite challenging for some users and may project an unwanted image of the TBM sessions. If a business user only attends the storming sessions, they may walk away thinking that the sessions are unproductive and full of conflict but may not see those sessions as  being building blocks for subsequent sessions.
  4. Be able to find out key dynamics in the teams that need to be highlighted to achieve the “norming” phase. For example, one week we had a rather quiet team that needed to be drawn out. In that case, we created a norm that before we move on from one topic to another, we need everyone to say something, even if that meant “I agree with this process and it covers all my needs”. Another week, we had a highly vocal group each speaking on top of another and multiple conversations was slowing down the group’s ability to be together. In that case, we created a norm of “one conversation at a time”. Both of these situations are very different norms and were appropriate only for the given group at hand.
  5. Have a balanced blend of nature vs. nurture. To some extent, these phases are natural and cannot be avoided. However, the evolution of these phases can be influenced via leadership and facilitation. Knowing how much to consciously “push” for the acceleration of that evolution vs. “letting it blossom on its own” is truly an art. There is no standard protocol about this balance. This is where the facilitators need to apply their leadership and listening skills to know when to push and when to let things emerge. There is no right way to do this and there is no way to avoid ALL mistakes. Take your mistakes as tell-tale signs and learn from them quickly. This is not the game of who makes the least mistakes, but who course corrects quicker from each of their mistakes and anticipate them going forward.