Understand the Outcomes, then Focus on the Inputs

July 13, 2009

 

The recent and ongoing debate on Healthcare highlights a problem that is prevalent throughout organizations, governments, and society in general.  The problem is with the thinking process, or should I say, lack of a thinking process, and an almost myopic and emotional focus on addressing only the outcomes of a process.

In Healthcare, we are constantly told that the “system” is broken, it doesn’t meet the needs of patients, and there are too many people who can’t afford healthcare.  People not being able to afford healthcare is a problem, so, as some are presenting, the solution is to provide those people with health insurance (the mechanism which they receive it doesn’t matter), then we will have solved the problem of people not being able to afford healthcare.  But what does this solution really solve?  What is being done to drive the costs of healthcare down?  What is being done to improve the quality of the delivery of healthcare to better meet the needs of the patient?  What is being done to fix the broken “system”? And it is broken.

The issue is the solution proposed does not address the reasons as to why people can’t afford healthcare.  Lack of insurance may be one of the reasons, but it’s certainly not the only reason, just maybe the easiest reason to address to a frustrated public that wants to see “results.”  The problem is that to truly address the reasons healthcare is unaffordable means we need to dive into the system and determine what is driving costs from the moment a patient enters a physician office (or earlier) until they settle their bill (which may be covered by insurance).  If the output is unaffordable care, we need to focus on the inputs that are driving these outputs.  Healthcare is a very complex model, with physicians, providers, insurers, pharmaceutical companies, and medical device suppliers all functioning as independent groups (often times, required by law to do so).  To fix the outcome of our current system, we need to focus on the inputs these entities provide and the interrelations that exist.

Years ago in manufacturing, when an organization had quality problems, the solution was to simply put more quality inspectors in to monitor the product.  Well as anyone who’s been involved in manufacturing knows, “you can’t inspect quality into a product.”  Organizations that tried this quickly found it was unaffordable and not sustainable – they had to go fix the inputs of the process to truly improve and sustain quality.  The logic has nearly universal application, whether it’s manufacturing, healthcare, technology, etc. : to fix the outcome, focus on (control) the input.

The outcomes of a process are very important, and measure how effective the process is performing, but if one wants to improve the process, it is the inputs that must be addressed.

Let me know your thoughts!

Glenn Whtifield

Advertisements

Two Tales of Customer Service

June 29, 2009

 

In the past couple of weeks I have had the distinct pleasure of driving nearly 3,000 miles through 8 states in the U.S.A. using two different cars.  When one puts that many miles on vehicles in a week, something is bound to go wrong – and it did.

First Experience – how to satisfy your customer

While making our way home from South Dakota for a soccer tournament, at around 9:00 pm, our 2007 Ford Freestyle decided it did not want to accelerate properly.  Fortunately for us, we were outside St. Louis, MO and happened to see a Ford dealership (Pundmann Ford) by I-70.  Unfortunately for us, they were getting ready to close and could not look at the car until the morning.  Since the on-site rental car shop was closed, they graciously offered us a ride to a nearby hotel.  In the morning around 8:00 am, they called and informed me of good news and bad news: Good news – they found the problem and it would be covered by the extended warranty I purchased; Bad news – they did not have the part and it would not be in until the next morning, but he could set me up with a rental (covered by warranty).  So, the Family and I decided to make plans to “see” St. Louis.  About an hour later, they call back to inform me they’d been looking for the part at dealerships in the area and found one – I’d probably be on the road by late that afternoon, and they would call back with a status.  An hour and a half after that call, they call and tell me the car is ready, and they’ll be sending a driver to get us.  By 11:00 am, we are on the way home.  Outstanding service – they communicated with me throughout, and went out of their way to make sure we were taken care of.  Whether they treat all customers this way, I’m not sure, but the team at Pundmann Ford sure satisfied our expectations.

Second Experience – how not to satisfy your customer

When I returned from our South Dakota adventure, I needed to drive to Nashville, TN for some client meetings.  No problems there, but when I returned home, my 2001 Ford Focus decided it wanted to overheat.  Since there is a Pep Boys one mile from my house, and since they have worked on the car before, I took it there about 2:30 pm on Thursday.  I told them I’d be around the corner at another store, and they said they would call with what they found out in about 45 minutes.  About 75 minutes later, I returned to check the status, and the service person said, “Oh yeah, they want to do an engine diagnostic test.” Having worked in the industry, I knew this was necessary, but also realize it is a complete RIP OFF what you pay for this. All they do is hook up a computer, press a few buttons, read and interpret a few codes, and that can help them diagnose the problem.  Anyway, turns out it’s a water pump and thermostat.  I tell them to go ahead and ask when the car will be ready.  The service rep tells me around 3:00 pm Friday.

At 4:00 pm Friday, having heard NOTHING, I call to check the status.  After the service rep comes back on the phone to double check my name (I guess he can’t find my car), I am informed they are working on it and it should be ready by 5:30 pm or so.  At 7:00 pm, again, having heard NOTHING, I call to check the status.  I am now informed that the technician is 90% done, but they need another part from the dealer – seems the thermostat housing that used to be one part number is now 2 part numbers, and the second part number won’t be in until 8:30 am Saturday morning.  I am told my car should be ready by 10:30 am.  I express my EXTREME disappointment on why it takes 27 hours for them to realize this is 2 parts, and how I had to call twice to find out what was going on.  It is the 21st Century, and one would think that a parts supply store like Pep Boys would know what parts and part numbers it takes to repair a vehicle.  Why it took 27 hours to discover this befuddles me.

So on Saturday, I can’t get to the store until 1:00 pm (well after the 10:30 am promise time), and I suppose that’s a good thing because the car is still not ready.  Again, no call – NOTHING.  The Service Advisor eventually tells me it will be another 30 minutes – after he walked the shop looking for my car.  When I check again, the car is ready, but it takes another 15 minutes for them to figure out the bill (big one too!!).  The Service Advisor politely mumbles, “sorry about your wait today.”  TODAY?!?!?  He obviously has no idea how many times I had to check on my car.  At that moment, Pep Boys had a chance to make things right, but it came and went.  I paid my bill, took my car and drove home.  I think I’ll give Pep Boys another chance to make good.  A sign on the wall in the shop says they have a 100% service guarantee – we’ll see how they define “service.”

The Difference

The difference between the two situations is simple – Communication.  In the first, although disappointed at first that the part would not be available until the next day, the Pundmann Ford folks communicated openly and honestly with me about the status of the vehicle.  They then were able to over achieve their commitment.  If I lived in the area, that’s where I would go for service.

In the second experience, there was silence.  I had no idea what was going on with the vehicle, and had to personally check on the status each time and was given 4 times that the car would be ready  – only to be told I would have to wait longer each time. Had Pep Boys decided to pick up the phone and inform me of the status, the delay would have probably been more bearable, and understandable.  However, it appears someone is asleep at the wheel at Pep Boys.

So, when dealing with customers the key is to communicate – the news may not always be good, but most customers will understand if you are open and honest about their situation. 

Let me know your thoughts!

 

Follow-Up: In the past several weeks, I have been contacted by Pep Boys Customer Service, first through Twitter (@pepboysauto).  We have worked together to resolve my issues and I have spoken to the Service Manager of the store who acknowledged he has an issue with status communications and is working with his team to improve.


What IT Can Learn From Manufacturing

May 26, 2009

 Background

A long time ago, or at least what seems like a long time ago, in the U.S., Manufacturing was King. For companies whose primary product was manufactured, manufacturing, along with finance, dominated discussions.  There was little concern for quality, cost, or customer service.  The customers would get what they got (and like it), and any additional costs incurred would simply be passed along in the price of the product.  Life was good!

Slowly, however, things started to change.  As other countries began to emerge from the post-WW II economies, they began to develop their own infrastructure, and were actively seeking techniques to improve quality and productivity.

Meanwhile, back in the U.S., it was business as usual, and many felt these pesky little countries were no match for the mighty U.S. industrial base.  Quality experts like Deming and Juran, seeing the error in this line of thinking, pleaded their ideas to senior management before it was too late.  They were cast aside.

So they went to Japan, whose leaders were hungry for ways to improve quality and increase productivity.  They were able to implement these techniques through diligent work with much success.  Eventually, they began to take a foothold in the U.S. and their products became very successful.

Savvy U.S. manufacturers looked at what was going on and began to change their thinking and their organizations.  The traditional organization’s operations, with its command and control structure, siloed departments, mass-production mentality with its associated lack of flexibility, had to change.  Some organizations made the transformation while others did not, and are no longer in business.

Because of the “sudden” insurgence of foreign competition (not really, but few were paying attention to notice), managers took drastic steps to remain competitive – like outsourcing either entire manufacturing operations, or parts of operations.  Sometimes this worked, sometimes due to supply chain and other issues, it was less than successful. 

Next, and for those whose products and structure precluded them from outsourcing, came implementation of Lean manufacturing / Toyota Production System (TPS) concepts, along with several reorganizing by product or service.  This transformation continues to this day.

IT Comparison

So, what does this have to do with IT?  Well, when you look at IT in enterprise organizations, a lot.

One of many ways to look at it is to ask, “In an enterprise, what is the purpose of IT?  What does IT really do?”  In its simplest form, IT processes data to become usable information so it can be utilized in decisions to help the business.  In this way, IT is much like a factory that processes data and turns it into information.

Of course, the way it processes data varies greatly.  Sometimes it functions simply as a conduit, as in email.  A supplier (user) types a note on an application and presses SEND.  At that point, IT takes the email and processes it to a customer (also a user) who opens the email and makes a business decision based on the information it contained (act on it, do nothing, delete, etc.).  Sometimes IT is a storage facility that stores and inventories products (files) for later use by customers.  A supplier (user) sends a product (file) to IT for storage (server).  When a customer (user) needs the file, they order it from IT (click to open), and IT delivers the product to the customer.  Other times, IT functions as a true manufacturer and creates product.  A supplier has a need to solve a business problem and there is an IT product (application) that can help.  The supplier presents the build specs and IT produces the application either by building it with its own resources (development) or by outsourcing production to a specialist (purchase software).  IT then delivers it to the customer for use, and provides customer service (help desk) as well.

Now, there are a lot of things going on behind the scenes in the IT Factory to deliver these products and services, and the way IT Factories go about delivering these vary by organization.  As was the case in manufacturing during the mass-production hey-days, where factories were aligned by departments (Stamping, Machining, Finishing, Assembly, Shipping, etc.), many IT Factories are aligned by function (Hardware, Software, Network, Storage, Server, Support, etc.).  In the traditional IT Factory, every application has its own server, storage, and support group all within and aligned by each of the functional areas.  Changes and new requests must pass through each of the functional areas before moving to the next, with the occasional concurrent processes.  Since the organization was probably already structured in a hierarchical way, it only made sense for IT to follow this structure.

But things are changing, and changing quickly.  If the rate of change in manufacturing was linear, in IT it is exponential (see figure 1).

Mfg IT Change Rate

However, in a slight difference from manufacturing, the change IT enterprises are experiencing is not necessarily driven by outside competition, but by the technology itself.

Applications have gone from being developed in-house (highly specialized ones still will need this), to being purchased off the shelf and installed on the companies servers, to being available as a service (SaaS).  Storage and Networks (along with Applications) that used to require separate physical machines have gone from 1:1 to 1:many with the implementation of virtualization technologies and the advent of the cloud.  Mini-factories (desktops) that are supported by maintenance personnel (desktop support) who had to be dispatched remotely to solve customer (user) problems or make changes can now be fixed remotely with desktop virtualization technologies.

In essence, IT as we have known it in the enterprise is slowly becoming obsolete unless it develops new approaches and skills to support the business.  It’s not a question of whether the current work that is being performed will still be needed, it’s a matter of scope and scale.  There will still be a need for networking, hardware, storage, etc. personnel, just not as many (in the enterprise).

This leaves two choices for IT leaders.  They can either support these new technologies, figuring out how to best utilize them in their organization, or resist them and continue to maintain the status quo.  The problem with resisting them is they will eventually catch you and your organization.

IT Reaction

IT needs to use these transformative technologies to fundamentally change the way it does business, much in the same way that manufacturing embraces Lean and cellular manufacturing concepts and techniques.  IT needs to transform from a provider of technology to a provider of service that utilizes technology.  It needs to become the de facto expert at applying technology to improve the business and business processes, ensuring all the while its actions are aligned with the overall corporate strategy.

Time is of the essence.  Organizations need to review the technology available and determine not only how that technology will enable them to improve operating costs, but also how it will help them improve the service they provide to the business.  The opportunity is ripe for IT to take a true leadership role in helping change and improve the business.  History has shown us where the consequences for inaction lead.

 Mfg IT Then and Now

 

Let me know your thoughts!

Glenn Whitfield


Creating a Necessary Dependence – An IT Business Alignment Whitepaper

May 6, 2009

 

Over the past several months, I have written several posts about the issues facing IT Business Alignment, a need to create a dependence between IT and the Business, and an emphasis on taking a process centric approach to the issue.

I decided to consolidate that into a white paper, which is now available. 

It’s not sponsored by a large software or hardware company, but does present an approach offered by my company (New Age Technologies) to help an organization move toward IT Business Alignment by focusing on a process to be improved, then understanding how it’s infrastructure and technology can help that process.

Please feel free to leave any comments about the paper at this post, or you can email me at the address on the paper.

I hope you enjoy!

Whitepaper:  Creating a Necessary Dependence: A Process Centric Framework for IT Business Alignment

 

Thanks!

 

Glenn Whitfield


Want IT Business Alignment? Change Your Approach and Create a Dependence

April 14, 2009

 

What’s wrong with your approach to IT Business Alignment is your approach to IT Business Alignment. For over 30 years, organizations have been wrestling with the IT Business Alignment issue, and according to the annual Society of Information Management survey it remains a top issue today. 

Why is this so difficult to get our arms around?  I’ve written previously about how defining IT Business Alignment has been an ongoing issue, and how our organizational structures make it very challenging (here).  We have spent so much time struggling to figure out the right approach that perhaps we have lost our way.

Part of this struggle is due to the definition itself.  ITIL v3 defines Business/IT Alignment as:

An approach to the delivery of IT Services that tries to align the Activities of the IT Service provider with the needs of the Business.

The problem with this definition is it defines Business/IT Alignment as an approach. Other definitions call it an “ongoing process” (Wikipedia).  While there may be a process to achieve it, Business/IT Alignment is not an approach or process, it is an outcome.

It is the outcome of many different approaches and processes which will vary by organization and will involve varying levels of technology.  Defining it as an outcome:

IT Business Alignment is the delivery of IT Services that does align the IT activities to the needs of the business.

Now looking at it as an outcome, how do you know when you’ve achieved it?  Well, it’s just like in the movie Goldfinger, when James Bond is asked, “What do you know about gold 007?”  His response was, “I know it when I see it.”  IT Business Alignment is like this in many ways because there is no “one size fits all” solution; each organization is unique, and alignment will look different in each.  This is what makes it so challenging.  An attempt by Company B to replicate the alignment results at Company A will likely be disappointing, because Company B is different than Company A.

However, to achieve this outcome, there must be some fundamental pieces in place in order to drive the approaches to meet the outcome of IT Business Alignment.  Fundamentally, IT and Business must be dependent on each other for success, and this dependence must be mutually recognized and acted upon.

Creating this dependence starts with creating a relationship and establishing common metrics.  Many will say this already exists in their organization.  Before you do, ask if the actions back it up?  Remember, not only does the dependence need to be recognized, but it must be acted upon.

 One way to act is to take the initiative to engage with the business in helping improve their operation.  This is where taking a process based focus to the operation can provide real benefit.  Using techniques like Business Process Management, or the one we’ve developed like the IT2x FrameworkSM, can help IT and Business create the necessary dependence and become aligned.

Once aligned, continue to move IT and the business closer.  Whether you call this Synchronization, Convergence, or Fusion, doesn’t matter.  What does matter is the continuous process of moving toward these goals. 

Change your approach to IT Business Alignment.  Stop treating it as an approach, and start looking at it as an outcome.  Then act toward achieving this outcome, by creating a dependence on each other through relationships, common metrics, and a process centric approach to improving operations. 

Let me know your thoughts!

 

Glenn Whitfield

 

 

 

 


Preparing for Virtualization

March 25, 2009

 

In the last couple of weeks, I have been asked to participate in several meetings with our virtualization specialists to help a client with a few issues.  Now, I know very little about the technical aspects of virtualization, but I do know a few things about processes and organizations.  So, when they asked me my thoughts on one of the issues (application deployment), my first thought was to find out how they performed that function with a physical server.  We then mapped out their process.  Next we mapped how it should be done in a virtual environment.  And lastly, we mapped how they were actually doing it in the virtual environment.

Comparing the way they did it with a physical server to the way they were doing it with a virtual machine, we quickly discovered nothing had changed.  They were trying to do things the same way.

IT organizations constantly complain that when they put in new technology, the business users never achieve the full benefit of the technology because they refuse to change the way they do things (and IT then gets blamed for the technology underachieving expectations).  But who to blame when the ‘business’ user is IT?  It will either be the consultant who helped them put it in, or the technology itself.  Excuses like, “we tried virtualization and it just didn’t work here” or “virtualization is just not for us” start to be voiced, and, viola, the technology once again failed to meet expectations.

Why did the virtualization project fail? Because we focused on the wrong things; we focused on the technology and ignored the process and people. 

We must learn to focus on the process, engaging the people, while preparing for the technology. (see more here and here)

Virtualization is a tool.  It is a technology that, to get the full benefit, requires the IT organization to change the way they do certain things.  If you don’t change the way you do things, you won’t ever get the benefit of the tool.  Intuitively, everyone knows this.  But how many are doing something about it?

If you are heading into a virtualization project or expanding on work you’ve already started, it is imperative you review your processes for how you do things currently in the ‘physical’ world, and how you’ll do things in the future in the ‘virtual’ world.  Not doing so will limit your potential.

Let me know your thoughts!

 

Glenn Whitfield


Metrics – They’re only good if you use them

March 12, 2009

 

Peter Drucker’s famous quote, “What gets measured gets managed” has been a mantra for process improvement folks (like me) for years.  How can you possibly know you have made an impact unless you can measure it with some metric?  Organizations spend lots of time and effort to determine and gather these metrics (which is why my preferred method when approaching a process improvement activity is to try to use metrics that are already being tracked to measure impact).  We can debate whether or not the metrics selected appropriately measure the process we are analyzing, and the differences between correlation and cause and effect, but I digress.  The assumption we’ll go with is that we have selected the proper metric.

Great!  Now we have a metric.  We measure it.  We track it.  We put it on pretty graphs.  But do we ever use it?  We can collect mountains of data faster than ever before, but unless we use it, why bother?  Data can only become information if it is used.   But let’s take this a step further.  The data must be used to become information, and it must be shared with others.  Too often, a department collects data, then, in their mind, make decisions with it (turned it into information for them), but they do not share it with others impacted by the process or the decisions.  This creates huge waste in organizations.

Here’s an example:

A couple of weeks ago, at a client meeting, the following story was shared.  The client, a director at a large organization, was in a meeting with several other directors and they were discussing the organizations change management process.  The manager over this process made the statement, “Changes take too long to get implemented, we need to fix this.”  So, our director left the meeting concerned about the changes her group was putting through, and determined to fix it.  After spending several hours talking with her team, she was struggling to see how her group was delaying the process.  She then went to the manager of the change management process to get more information.  The response was, “Oh, you’re changes aren’t the problem, they usually only take 15 minutes or so, it’s another department.”  Our director left, first relieved, then frustrated.  She had just wasted 4 – 5 hours trying to fix a problem that wasn’t a problem – pure waste.  The rationale she was ultimately given was, “We didn’t want to single anyone out in the meeting.”

Sure, the manager could have shared the data in very vindictive and accusatory way, attempting to completely embarrass and humiliate the director of the area that was causing the problem; seen it done – very nasty.  OR, the manager could have presented the data in a way that would encourage an ad hoc brainstorming session to help identify and improve the problem; seen it done – very nice.  But to choose not to present it to the group, then wonder why the problem doesn’t improve – mindboggling.  Who wants to bet the director of the area that is the issue has no idea they are the issue?

Yes, metrics are important (the right metrics, of course).  Just make sure if you are going to take the time to collect them, you use them and share them in a way so your organization can improve. 

Let me know your thoughts!

 

Glenn Whitfield