Microsoft Gets Business Intelligence

Normally, I would not use a public forum like this blog to endorse vendors and products, so when it happens, I do so with a fair amount of deliberation and forethought. Such is the case with my opinions about Microsoft and the evolution of their Business Intelligence and Data Warehousing strategy. In short, they get it. I think it's important to share these thoughts at a time when health care is turning the corner of interest on BI, and complexity and total cost of ownership for BI still tends to be a barrier to entry. Taken in its entirety, realizing that no vendor offers a perfect solution yet, Microsoft's BI/DW product stack and execution on vision offer the best overall value currently available to health care-- and other industries, too, for that matter.

My data warehousing background is rooted in the military and national intelligence communities, which were IBM and Oracle centric. The data warehouse that my team built at Intermountain Healthcare was (is) Oracle-based. Oracle and IBM have been good to my career. My first exposure to Microsoft-centric BI came at Intel in the mid-1990s when SQL Server and Windows were still on wobbly legs. We built a BI solution at Intel to help analyze the various trade-offs between logistics product options and chip fabrication defects and throughput for the Rio Rancho production facility in New Mexico. It was a whopping 300Gbytes in size. Long story short, the "New Mexico Data Repository" was a huge success and was eventually deployed to something like 35 of Intel's sites. My colleague Rob Carpenter deserves the credit for implementing the strategy and design that I started.

The point is, I've watched closely for a number of years as Microsoft has evolved SQL Server into what is now the equivalent of Microsoft Office for Business Intelligence-- i.e., a very rich stack of products that integrate very well to deliver a complete BI solution, from the database to the desktop and web. One of the most impressive aspects of this evolution was Microsoft's willingness to completely reengineer SQL Server's foundation at least once-- arguably twice-- during this period. They caught much-deserved criticism for these overhauls and the lack of backwards compatibility with SQL Server, but it was their willingness to take the heat in the short term, while the product was young and the install base was small, in return for long-term success that is particularly noteworthy. Part of their "willingness" to reengineer SQL Server was no doubt related to cutting commercial ties to Sybase, but nonetheless, whatever their motive, the outcome was strategically invaluable. Other RDBMS vendors have not done the same and they suffer from legacy baggage as a consequence.

Despite their very impressive vision and steady execution around SQL Server and BI, Microsoft could polish their strategy even more with the addition of two more tools in their BI product stack: (1) An integrated customer/person/patient identification tool-- that's a BI problem that plagues numerous industries, especially health care; and (2) A metadata repository and browser, which is a must-have for every BI/DW system, anywhere.

If Microsoft were smart ;) they would offer Windows on the desktop and the Office Suite for free and relinquish to their eventual commoditization-- in return for the value of the desktop's integration with a company's data. That's where the future value and differentiators for Microsoft reside. It's in the data, not the desktop.

Again, my motives in sharing these comments are to facilitate a faster rate of BI adoption and success in health care. Those who know me, know that I purposely keep vendor relationships at arm's length and wouldn't accept anything closer if it were offered. Microsoft can tell you that I've given them plenty of headaches and criticisms on other issues lately, so this blog isn't about a love fest. It's about getting to a data-driven health care environment in the U.S., the sooner the better.

Not the First to Question Six Sigma

Thanks goes to several colleagues for their comments and in particular for pointing out that I was not the first to question the value of Six Sigma, including a person and thinker who I greatly respect, Tom Davenport. Among his many excellent and insightful publications, he wrote "Competing on Analytics", a book that should be required reading for every executive and manager in healthcare.

http://www.businessweek.com/magazine/content/07_24/b4038409.htm

One of my former students asked me if she should discontinue her plans to seek Six Sigma training and I answered no. There's still value in understanding the concepts and theories underlying Six Sigma and in certain restricted corners of a business, Six Sigma could be the best tool for addressing process improvement. But I retain the opinion that there are few, if any, of those corners in healthcare and it is a methodology which, if broadly applied in any business, will squeeze agility and innovation to death.

Six Sigma = Sick Sigma

As healthcare organizations rush towards process improvement, many are adopting or have adopted Six Sigma as their quality improvement process du jour. While at first this choice sounds great and makes for eye-grabbing headlines, the reality is, Six Sigma will soon squeeze every drop of agility out of these same organizations. It’s only a matter of when, not if. Also, many of these same healthcare organizations have mistakenly labeled Six Sigma and Lean as synonyms. Nothing could be further from accuracy. Six Sigma matured in Motorola as a means for eliminating defects in product manufacturing and is highly driven by statistical data analysis and process control. Lean grew up in Toyota, as a front line cultural tool for eliminating waste. In addition to this fundamental difference in motive—i.e. defects vs. waste-- they use drastically different tools and methodologies. Six Sigma is complicated and dogmatic about measurement. Lean is inherently simple and dogmatic about culture.

Six Sigma is appropriate if your organization:

• Is in a low volatility industry. Stated otherwise, the business state of the market is relatively stable; innovation is less important than consistent delivery on the status quo; competition is minimal; and consumer demand for better products and/or lower prices is low.
• Can focus on quality at the expense of schedule and production volumes, in the delivery of its products and services.
• Produces products and services in an environment which is readily measurable, i.e., the variables in the equation of “Quality” for those products and services can be quantified with reasonable accuracy and consistency

Healthcare, I would argue, is not an industry which fits any of these criteria. Nay, few if any industries or markets fit these criteria today.

There are many reasons for Motorola’s fall from grace, but it is more than simple coincidence that Six Sigma was once its crown jewel. I had the great opportunity to work with Motorola as a customer of their products while I was in the Air Force in the 1980s. During that period, innovation and agility were less important across all industries than they are today. At that time, TQM, CQI, and ISO were focusing on quality, repeatability, and execution. Motorola was relatively innovative, but they were better known for highly reliable, cost effective products, and their execution on commitments. At about this same time frame, Motorola started to embrace the notion of Six Sigma for eliminating virtually all defects in their products. As an Air Force information systems officer, reliability of my equipment was paramount, so I was clearly impressed by and supportive of Motorola’s intentions.

Fast forward to the mid-1990’s when I was a small-time consultant to Motorola on their Iridium project. Ignoring the flaws in Iridium’s business model, such as the failure to account for the loss of telecommunications tax revenue in countries which benefited from land-line communications and eventually cell phone towers, the Iridium project gave me a thin-slice insight into a larger problem at Motorola—the Six Sigma process was squeezing agility, and subsequently innovation, to death. Fast forward once again to today and we see a Motorola that has, in fact, been squeezed to death. The agility and innovation of their competitors are like pythons, slowly crushing the culture of this once great company, and has Motorola crying for a buy-out. Other early champions and adopters of Six Sigma are showing the same fate—Allied Signal, Honeywell, Jaguar, Sun Microsystems, et al. I would argue that GE, Motorola’s Six Sigma protégé, is floating the same river.

I recently visited the “official” Six Sigma web site and found it proudly proclaiming “1,176 slides” available for DMAIC training for only $99. I didn’t know if I should laugh or shake my head in sad appall. Any process improvement methodology which allows for that degree of largesse, needs to recursively turn its own processes back on itself. In stark contrast, I’ve seen the tenets of the Toyota Production System and Lean process improvement taught to a group of nurses with no manufacturing background in as few as 20 slides in the morning, and those same nurses applying Lean to their own departments later in the afternoon.

Don’t make healthcare worse by rushing to the popular cliff of Six Sigma…. Unless, of course, you’ve equated it to Lean and then I would encourage you to normalize your vocabulary to standards. :-)

Microsoft Amalga Pricing and Licensing

Several readers asked to comment about the pricing structure and Total Cost of Ownership (TCO) for Amalga (aka, Azyxxi). I am still in pricing negotiations with Microsoft and of course need to respect the confidentiality of those discussions, so can't go into any detail, but will offer a few general thoughts, all of which I have shared with Microsoft.

Utility vs. Legacy Pricing Models: Unfortunately, I believe Microsoft is missing an opportunity to establish itself as a forward thinking leader in a new vertical, with a new product-- a prime greenfield opportunity for innovation-- by offering a traditional, legacy licensing model for Amalga. I have been encouraging them to offer a utility, pay-as-you-consume model which, I believe, would ensure more, not fewer customers. The licensing model they are offering now is very typical of transaction systems-- i.e., big up-front fees with smaller multi-year commitments. However, Amalga is more akin to a business intelligence tool than a transaction processing system, therefore, predicting the total adoption rate is very, very difficult for Amalga. The scope and adoption rate for transaction systems, like a PACS, EHR, or ERP system, are relatively easy to predict-- count the number of users and divide by the length of the implementation plan. The implementation timeline for transaction systems is usually driven by very clear organizational goals, i.e., "At least 90% of our employed physicians will be using our EHR within three years." For BI tools, counting "users" is very tricky and full of uncertainty and organizational cultures are much less likely to establish corporate goals around the adoption of a BI tool, so committing to a multi-year adoption rate in a high-dollar contract is risky business. Amalga and BI tools are perfect candidates for utility, Software-as-a-Service licensing.

Licensing Costs vs. Solution Costs: Though I see signs of awareness and change, Microsoft is still selling software licenses vs. total solutions. CIOs are left trying calculate the true Total Cost of Ownership-- comprised of hardware, software, implementation services, and support services. In my negotiations with Microsoft, offering a total solution cost for Amalga has not come naturally for them, but we are making progress.

Build vs. Buy: We are building an Enterprise Data Warehouse (EDW) at Northwestern and making great progress (keep my fingers crossed). Since the project started 18 months ago, we've spent only $1.4M on everything-- hardware, software, and labor-- and we've been generating useful analytics and other unique services from the EDW for at least 6 months. Recently, and into the foreseeable future, we will be focusing on developing the tools to easily interact with the content of the EDW. These tools, I believe, will soon rival and potentially surpass much of the functionality of Amalga. In my discussions with Microsoft, our strategy is to plug the Amalga application layer into our existing EDW data content layer-- but my EDW development team is making such great progress, building lean applications over the top of the EDW, I'm beginning to see less and less of a role for Amalga. At this pace, our total EDW "Build" costs will be much lower than the software licensing fees alone for Amalga. That said, Amalga still offers a much richer user interface than anything we will develop in the near future, but that rich user interface is less valuable for Northwestern where we already have a large amount of data integrated in our EHRs-- Amalga's strengths are best revealed in organizations with many disparate clinical diagnostic systems and no EHR.

People are Buying: Yesterday, Microsoft shared the names of several new and significant customers for Amalga, all of which will soon be announced publicly. Despite my reservations about the licensing model and total cost of ownership, other CIOs seem less concerned, and at the end of the day for Microsoft, paying customers definitely trump Dale Sanders' Quixotic opinions. ;-)

The CIO's Role in Healthcare Economic Reform

First, I want to recommend a book--Nudge-- for everyone in health care, especially CIOs. There are several elegant themes in the book, but one of the most pertinent is: If you simply expose people to data about their behavior and within a relevant context, you can often times "nudge" them towards a desired new state of behavior, without the need for a complicated, onerous, process improvement campaign... which usually nudges people away, not towards, the desired behavior. For example, the authors write about a campaign in California in which a utility company exposed data to consumers about their energy consumption as compared to other consumers in their neighborhood, including the lowest energy consumer in the neighborhood. Over time, the entire neighborhood reduced its energy consumption, including the lowest consumer, thereby establishing a new and constantly improving benchmark. Awesome. There are ample opportunities for us to leverage our data in health care to nudge better behavior, even if we can't completely overhaul the entire system.

Second, let's assume a few things for the sake of discussion:

1. Economics and Quality: Health care quality of care in the U.S. will not change significantly unless the economic model of health care changes to one which financially rewards physicians and hospitals for patient health vs. patient volume.
2. CIO Influence: Health care CIOs don't alone have the influence to radically change the economic model of health care.
3. Costs are Verboten: Health care is the only service-based business in the U.S. in which the service is provided without any discussion of the scope of costs during the course of the business transaction between the service provider and the consumer. In other words, neither the physician nor the patient have a clue about the true costs of care to the overall system of health care. In fact, discussions of costs prior to treatment are avoided like the plague.

I wrote an article for last Winter's edition of the HIMSS Journal which outlines the things which we can do as CIOs to help nudge the economic model of health care towards something more sensible. If you can afford it, do the right thing and pay for a subscription and download it from HIMSS. It's available here:  Winter 2008 JHIM.  If you don't have access to HIMSS archives, there's an interview here: Sanders' interview, CIO role in healthcare economic reform.

More on SOA in Healthcare

A reader commented: "In a future post, could you consider reflecting upon your reasoning for a "buy and develop" approach, the principles you use to govern this, and how you keep the vendor software/services/APIs and your own in-sync? Also, do you see this as a fundamental shift for all health care organizations, or only the largest?"

Differentiating Through "Buy and Develop": Although the key differentiators between organizations will always boil down to people and culture, it's fairly clear that information technology in the hands of great cultures can change the world. The effective use of IT is clearly an opportunity for all companies to differentiate themselves. Health care is nearly a green field IT environment in this regard, but if you imagine a future world in which we all deploy the same commercial-off-the-shelf (COTS) products, e.g., Epic, in more or less the same fashion, there is very little room to allow for the differentiating power of IT to blossom. Instead, the COTS investment becomes a utilitarian asset, not a discriminating advantage. The customers must do something "differentiating" with these COTS products, and vendors must allow for that by offering an open, standards-based SOA API in such a manner which allows Northwestern to differentiate itself from Loyola and Loyola from the University of Chicago, etc.

Balancing Development and COTS: Health care leaders such as Intermountain, Duke, Vanderbilt, Indiana Regenstrief, Partners, Columbia Presbyterian, et al saw the differentiating power of IT many years ago, and only in the past eight years or so have we seen COTS products which were capable of competing with the home grown systems of these leaders. Obviously, we can't and shouldn't all build our own version of HELP or TMR, but we also can't fall to the other extreme of buying a vanilla COTS product and expect doing so to differentiate us for very long as "leaders." A "buy and maintain" strategy around COTS products will not be enough to differentiate health care organizations of the future.

SOA Caution: The principles for governing and building SOA extensions to COTS products is worthy of a day-long discussion. Suffice to say for this blog that you must exercise caution in design so that your services don't dip too deeply with hooks into the proprietary dependencies of the COTS' product layers, thus creating problems for future upgrades, compatibility, and configuration management. Think of the "Services" in SOA as circles who interact at their tangents, but do not overlap.

Small Organizations: Differentiation between leaders and followers doesn't recognize boundaries around organizational size. Even if you are a small health care organization, yet you strive to be a leader within your realm, buying and maintaining COTS products will probably not be enough to achieve leadership-- unless, of course, the simple act of investing in a COTS product is enough to differentiate you, while your competitors are still wading in paper or constrained by minimalist legacy systems. I see ample of that scenario unfolding in the territory of private physician offices.

Repackaging Data: In addition to the differentiating power of SOA extensions, health care organizations of the future will distinguish themselves through the creative and powerful use of data-- i.e., in the traditional sense of reporting, analytics, and metrics-based decision making, and also through the secondary use of their data to support new perspectives on real-time workflow processes. They will extract their production systems' data, repackage it, mash it with other data, and present it back to the front line workflow, but not as a report or a metric-- but as a new perspective on transaction data.

CIO 2.0: Hiring and Retaining Great People

My colleagues at CHIME are sponsoring a series of lectures and education sessions to explore the changing responsibilities of the CIO in healthcare. One of those areas of change involves the way we recruit and retain great IT professionals in an increasingly competitive hiring market.

CIO’s in healthcare must start seeing ourselves in a competitive hiring market which extends beyond the boundaries of healthcare. Right now, and for the foreseeable future, the best IT talent is generally not attracted to healthcare. I am enormously grateful to say that we are a small exception to that trend at NMFF-- we’ve managed to put together a team of IT professionals which has the potential to be among the best I’ve ever worked with in any industry. So, my present team excepted, the best IT talent in the world is currently attracted to the pure eBusiness companies like Amazon and Google, and the gaming industry. If we want to be the best, we have to compete with the best.

Here are a few thoughts about competing for this IT talent, now and in the future, all of which I learned working for my Dad, bucking endless fields of 80-lb alfalfa hay bales at 7,000 feet elevation in the thin air and hot sun of southwest Colorado. Talk about a tight labor market. Try hiring and retaining people for that environment. :)

He paid well: My Dad paid more than the farmer down the road; Not much more, but enough to attract a slightly better worker. Healthcare IT leaders always surrender to the notion that “We’ll never be able to pay as much as [fill in the blank with another industry].” But, as long as we accept that notion and manage our budgets and staff in that fashion, such will always be the truth. Younger generation IT professionals are motivated more by money than their more altruistic forefathers. In short: You get what you pay for, and today, nobody works for charity. Money matters when you want talented employees.

He provided lunch: Not a big deal—it didn’t cost Dad much money—but it was an important perception of value to those of us who worked for him. It also kept us physically energized and prepared for the afternoon’s work. Also, he recognized that serving a healthy lunch on-site was a much more efficient use of time. CIO’s need to “provide lunch” for their staff in whatever form, either symbolically or tangibly. Judy Falkner at Epic gets this. Steve Jobs at Apple gets this.

He made us laugh: Dad was constantly joking around, poking good humored fun at each one of us. Laughing under those conditions is not naturally easy—bucking hay can be brutally uncomfortable—but he knew that the best way to distract us from the discomfort was to tickle the funny bone. CIOs in healthcare need to lighten up a bit, take themselves less seriously, and cultivate a cultural sense of humor that aligns with the new generation of IT professionals. CIOs of the future need to contribute to the Laugh Metric.

He paid a productivity bonus: We were paid hourly, but we benefited if we finished early. Rewarding productivity is essential to the future skilled worker, and healthcare is the worst industry I’ve ever been around for failing to recognize and pass the financial benefits of productivity down to the lowest levels of the organization. And, those bonuses need to be paid immediately after the good deed. Basic Skinner psychology there. It’s a very frustrating part of my career in the business, actually, and I believe one of the reasons that healthcare is still so terribly inefficient—the front line workers are not a part of the financial incentive program to achieve greater efficiency. Toyota gets it.

He bought the beer: When the hay was “in the barn”, Dad would always let us celebrate by having a beer—a single beer each-- even though we were all under legal age. Terribly politically incorrect, wasn’t it? Too bad we’ve bleached that sense of harmless fun from our society. At that time in America, nothing was more “cool” than having a beer in that setting with your Dad and/or boss—it was a coming of age….a redneck bar mitzvah… a ritual of healthy masculinity. CIOs in healthcare need to find a similar way to bind themselves socially to their teams. Again, the modern IT workforce expects it. Friday Beer Days are notorious at Google.

Here are some other important lessons I learned over the years and try to practice which I think help attract and retain great IT professionals:

Proactive salary management: None of my employees should ever have to ask for a pay raise. I should pay them well, proactively, and expect them to perform accordingly. I’ve missed my responsibilities as a leader if someone on my staff feels like they are underpaid to the point that they have to ask for a pay raise.

Transparent salary management: Similar to the above, I manage salaries as if they were not the secret we make them out to be. That is, if salaries were ever accidentally spilled on the table and everyone could see them, I would want people to react by rubbing their chin and saying, “Hmmm… Interesting…but these salaries look very fair. I’m o.k. with it.” Unfortunately, American corporate culture being what it is, we can’t be entirely transparent with salaries, but we can act and lead as if we could. And, BTW, I subscribe to an official salary survey every year from Computer Economics, and make that survey available to all members of IS. At least we can be transparent in that regard.

Hire your future boss: I hire people that I want to work for, just in case I blow my role as CIO and have to apply for a job with them. Seriously, I always hire direct reports who I could follow and trust as my leader and manager.

Develop people to leave: I try to develop the skills and self-esteem in my people so that they are marketable—so marketable that they could say “Screw you, Sanders. You’re a kook. I’m outta here. ”, and they could find a great job elsewhere, tomorrow. If you give people that sense of empowerment over their own fate, ironically, they’ll never leave.

Hire balanced overachievers: Create a culture of “40-hour-a-week overachievers.” Hire people who are so capable and efficient, that they can accomplish as much in 40 hours as the inefficient but self-glorified and one-dimensional workaholics who work 60 hours per week. Encourage your culture to be balanced, well-rounded human beings—the kind who are happy, creative, and team-oriented. The modern IT professional expects flexible work hours and a balanced life, even though IT is as much a hobby to them as it is a profession. They might work all night to solve a problem or test a creative idea, but they want to make that choice on their own, not be forced into it.