EHR & The Ghost of Technologies Past

November 30, 2009

“It’s like déjà-vu all over again” Yogi Berra famously once said, and yes, it is. We’ve been here before.  The promise of a new technology the will create so many efficiencies – too many to count.  It will make everyone’s life so much ‘easier’ and allow the organization to make unprecedented gains.

Enterprise Resource Planning (ERP) systems, and the consultants that sold them, promised us the moon.  While a few (and very few) made their mark, most would fall into the ‘failure to launch’ category.  If they did get off the launch pad, they didn’t make it very far.

While everyone generally accepts the definition of insanity as ‘doing the same thing over and over again and expecting a different result,’ organizations and leaders of organizations continue to repeat mistakes from the past despite warnings from many.  They rationalize it to themselves by saying, “our industry is different.”  The only thing to say to that is, “Yes, you’re different – just like everyone else.”

They then make the same mistakes done by those in different industries, but implementing the same concept, and wonder why the new technology failed to meet expectations.

So now, we have Electronic Health Records (EHR) [Electronic Medical Records (EMR)].  We’ve been told that this will help solve some of the issues that create so many problems in healthcare, and improve patient care, efficiencies, eliminate medical errors, etc.  Sounds a lot like the ‘moon,’ and if any industry feels they are ‘different’, it’s healthcare.

But the question is – what are you going to do different?

The traditional approach to implementing new technologies (like EHR) has been to focus on the Technology, glance at the Process, and be blind to the People.  We have traditionally centered everything we do around the new technology, treating it as a panacea; all we need to do is install it, and our problems will be solved.  To this end, we may take a brief look at how the process will be with the new system (rarely ever at how we currently perform it), and typically ignore the people who actually perform the process (we interview and train them, but do we listen to them?).  This approach has produced less than stellar results, with some pundits claiming up to 75% of technology project fail to meet expectations (this approach being only part of the many reasons for failure).

To approach an EHR in this manner would be doing the same thing over and expecting a different result.  A different approach (which I continue preach) would be to focus on the Process, while involving and engaging the People to prepare for the Technology.

By focusing on the process, we can get a true understanding of the way things really get done – how the people actually perform the tasks that move the organization each day.

With the people engaged, involved, and focused on the process, the organization will get a solid understanding of what needs to be improved, and have created the buy-in and ownership of the people who perform it each day to improve the process.

By cleaning up the current process, the organization will be prepared for the new process the EHR will bring and fully understand how to effectively integrate the technology and the process into a new way of operating.

So, are you going to repeat the mistakes others have made in the past when implementing technology, or are you going to try a new approach?

Let me know your thoughts!

Glenn

Note: This is cross-posted here

Advertisements

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


The Communication Divide Continues

April 30, 2009

 

Effective communication is critically important in any relationship, be it with your significant other, or your business partners.  This is ever so important in the IT Business relationship.  After all, if we want to improve alignment, we need to make sure we understand each other.  Despite all the efforts, the issues continue to present themselves.  A couple of examples from the past few weeks:

In a meeting with IT & operations leaders, a business unit VP was discussing how they needed to better understand the ‘workflow’ and be able to improve it.  He asked IT to help.  Since the organization had Microsoft SharePoint deployed, the IT team went back and looked at the ‘Workflow’ engine in SharePoint.  Unfortunately, the ‘workflow’ he was talking about was the process the people were using to complete their tasks.  Same word, different meanings.

A hospital scheduling organization allowed physician offices to fax orders into the system.  The orders were converted to PDF files using “Fax-o-matic” (name changed).  Indexers then labeled the orders into the email system, and linked it to the order in the scheduling system (I know, a mess, but no $$$ to change).  Hospital leadership would constantly hear of issues with the “Fax-o-matic” system.  When they approached IT, IT would say it was working fine.  To IT, “Fax-o-matic” was the creation of the PDF file from the fax.  To Hospital leadership, “Fax-o-matic” was the entire process from faxing the order to linking it to the scheduling system, as well as finding it as necessary.

Much time and effort could have been saved (as well as some nasty meetings in the case of the second example) if both parties had taken the time to understand exactly what the other was saying,  what it meant to them, and explaining what they were going to do.  If the IT group had said what it was going to look at when the meeting ended, the VP would have realized they were not on the same page.

When communicating, it is not only important that you understand what the other person is saying, but that you are sure they understand what you are saying.

Let me know your thoughts!

 

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

 

 

 

 


CIO? No, Leader Wanted

March 5, 2009

 

Change.  That is the overriding theme of today.  So that got me thinking about the relationship between IT and Business, the classic IT and Business Alignment problem, and how “everyone” is always promoting that it must change.  After all, it’s been an issue for like, well, forever.

 

CEOs are always saying they need their IT organizations to understand the business to be aligned, synchronized, converged, or whatever.  They want the CIO to understand the ‘business’.  If this is the case, when looking for a CIO, why do organizations tend to look only at those who have worked exclusively, or primarily in technology?  Sure, the person has to have some level of understanding about technology, but does the CIO really need to know every detail of C#, Visual Basic, or Java?

 

I recently had a conversation with ‘Jack’, a CFO of a Fortune 1000 organization who was sharing a conversation he had with a friend of his, ‘Mark’ – a Fortune 500 CEO.  Mark was having issues getting value and alignment out of his IT organization and was considering outsourcing the group.  Jack told him, “Before you do that, you need to make sure you have the right leader in that position – someone who understands the big picture.”

 

Every organization is different – just ask them.  Maybe it’s time to do something different.  Remember the classic definition of insanity: Keep doing the same thing but expect a different result.  Seems to me that if you truly want to change the way IT functions in the organization, looking outside the technology sandbox for a leader might not be a bad idea.

 

Let me know your thoughts!

 

Glenn Whitfield 


Process Improvement – Been there, done that. Have you Really?

February 23, 2009

 

A couple of weeks ago, I had the opportunity to sit on a panel to discuss IT Alignment with Operational Goals in the Healthcare community.  It was a lively discussion with several great opinions.  What bothered me was the conversation the evening before the event at a dinner for the panelists and sponsors.

At the dinner, I was conversing with a CTO and we were discussing the “stimulus” package.  He was ecstatic over how much money would be heading his way and how this would help him and his budget problems, and how he could help more patients.  I acknowledged helping more patients is great, but maybe he should take a focused look at his processes first to see what he can gain there and to make sure he is not spending money on bad processes.  I said, “As the saying goes, if you have a mess and you automate it, when you’re done all you have is an automated mess.”  He looked at me like I had horns coming out of my head!  He then politely said, “Oh, we’ve already done that.”   Our conversation was interrupted before we could continue.

What worries me is the “we don’t have that problem” attitude.  I have dealt with his organization.  He DOES have that problem.  He just can’t see it. They had done a re-engineering project several years ago, and had some success in several areas.  They thought they were doing process improvement.  They may have done process improvement, but they were a long way from continuous improvement.

There are two important things to remember when starting a process/continuous improvement program:

1)      To get the full impact, it must be a continuous process.  You can never think you are done improving.

2)      Leadership must get “boots on the ground” and see how the processes are being executed.  They must ask questions and get engaged.

There’s a lot more, but without these, you will not get the full, sustained impact of a continuous improvement program.

So how do you know you truly have a continuous improvement program?  – When you stop calling it a “continuous improvement program.”  And then, when someone from outside the organization comments on what a great CI program you have, your response is, “Oh, I hadn’t noticed – that’s just the way we do things here.”

 

Glenn Whitfield