Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

March 15 2012

Left and right and wrong

Sometimes I find a picture or a blog post that leaps off the screen at me and says "your readers must see this as it applies to health IT."

Normal Modes, a solid UX company based in Houston, sends me fairly good UX tips on a regular business. The last one featured this photo (used with permission):

Parking log picture from Normal Modes

Normal Modes points out, very clearly, that points of confusion like this are bad for users. They regard their job, as UX experts, to eliminate this kind of experience for users. Their analysis about how to do this is right on.

I have seen this kind of error in EHR systems and PHR systems on countless occasions. From an engineering perspective, it is really useful to take a moment and consider how something like this happens. First, you have two different "levels" of operation here. One is concerned with how traffic flows in the parking lot. The other is concerned with directions in the parking lot. For whatever reasons, these two "parking lot features" were implemented separately by people who had access to two different sets of resources. It stands to reason that the people who had access to white paint and stencils to make the sign on the right were the same people using stencils to mark the parking spots. It stands to reason that the people who had access to the professional sign-making system were somewhat removed from the people actually designing the parking lot.

In short, what you are seeing here is the artifact of a political and process disconnect. In health IT, there are constant political disconnects that cause similar issues. The EHR vendor is one political group, the insurance companies another, and the government is so large that it actually has multiple groups with different agendas. (HHS alone has so many sub groups that it's very difficult to completely follow what is happening.)

As enthusiastic as I am about the potential for meaningful use incentives, I think there will be lots of artifacts like this in EHRs that do not make much sense because the EHR vendor was pulled in a new direction by these incentives.

I have said in almost every talk about health IT I have ever given that the problems in health IT are political and not technical. I think it is my most tweeted quote. But sometimes a picture is worth a thousand words.

Meaningful Use and Beyond: A Guide for IT Staff in Health Care — Meaningful Use underlies a major federal incentives program for medical offices and hospitals that pays doctors and clinicians to move to electronic health records (EHR). This book is a rosetta stone for the IT implementer who wants to help organizations harness EHR systems.

Related:

March 29 2011

Process management blurs the line between IT and business

Business process management (BPM) and more specifically business process optimization (BPO) is about fully understanding existing business processes and then applying agreed-upon improved approaches to support market goals. Rather than exploring BPO from the viewpoint of the business, here I'll briefly explore some of the motivations and benefits from an IT perspective.

Almost every business change has a technology impact

There are very few IT systems today that exist in isolation within an organization. Systems interact because they often require data from each other and they are interdependent in terms of sequential steps in a business and technology process. As a result, a change in one system invariably has a downstream impact on one or more other systems or processes. Often, the consequences of these changes are poorly understood by both IT and business stakeholders. Put another way: in interdependent complex systems and processes, there is seldom the notion of a small change.

Once both IT and business stakeholders recognize this, there is an opportunity to turn it into a highly positive outcome.

IT must be perpetual teachers and learners

As is the case in achieving many of the objectives of an IT strategy, it begins with communications. Every contact between IT and the business is an opportunity to teach and to learn. This is a reciprocal interaction. When I hear or read a sentence that begins, "Could you make a small change for me…" I know we're already starting from a bad place. Unless the requester fully understands the internal complexity of all the interdependent systems and the potential impacts (which is rare), it's presumptuous for him or her to estimate the scale of the change. Conversely, any IT person who minimizes the impact of a change without fully understanding the potential impact does a disservice in setting expectations that may not be met.

For IT requests, it's best and safe to assume that a change will have impact, but the scale of that change will not be known until reasonable diligence is performed. That's a much better starting point.

Let's now assume that the change is not inconsequential. Two opportunities present themselves.

IT is an important business facilitator

First, stakeholders that are impacted by the change should be brought together to discuss the impact. I'm always surprised how these meetings reveal gaps in everyone's understanding of business processes between departments. To me, this is where IT can shine as the connective tissue within an organization. More than ever, technology forces organizations to better understand and agree on processes — and that's often well before the subject of supporting technology is even relevant to the conversation.

Use this opportunity to surface the entire process and for everyone to understand the impacts of any change. Improvements to the process very often emerge. IT has suddenly motivated business process optimization.

There is no such thing as too much process documentation

Second, assuming no documentation exists, this is the right time to map the process. If you're like many organizations, your IT systems grew organically with little emphasis placed on business process design. My guess is that comprehensive, high-quality, current process documentation is uncommon. It's never too late to start. If you have business stakeholders in a room discussing and agreeing on the current and future process, this is the time to document it. There is a burgeoning market for tools and support to help enable and simplify this work.

Ultimately, documented processes make it easier to build the right software and to make changes with less overhead activities in the future.

The essential roles of business analyst and solutions architect

It's this emphasis and attendant benefits of understanding and documenting business processes that supports the expanded roles of both the business analyst and solutions architect. These two roles, and having the right amount of capacity for your organization's demand, will be essential to succeeding with your IT strategy and in growing the business. In many organizations, the business analyst for this work may or may not be in IT, thus further blurring the lines between where IT starts and ends and where business responsibilities start and end.

Perhaps it's possible that in the not too distant future we'll look at IT as part of the business and not as a separate entity in the manner it is today. It just might be the increased emphasis on business process management that acts as the catalyst.



Related:


October 25 2010

Can predictability and IT innovation coexist?

Organizations that succeed in consistently converting ideas into value, and then profiting from them -- the art and science of innovation -- are often those that have balanced rigid process with agility. The reconciliation of predictability and innovation is at the heart of many IT transformations, even if it isn't an overtly focused intent. In other words, leadership wants more value from IT and more contribution to the bottom line, but they want it without compromising the core business functions that technology supports.

Typically, IT transformations try to achieve two things:

  1. Improve existing services by increasing quality and capacity while finding ways to radically reduce cost.
  2. Spend less time managing and maintaining back-office systems and redirect resources and capacity in order to enable new business opportunities.

To address item 1 usually requires the implementation of optimal processes, and to support item 2 necessitates innovation. Unfortunately, in the effort to ensure the compliance of processes, an organization can stifle, or in the worst case, create high entry barriers to innovation.

As an example of rigorous process, IT project governance often requires a level of analysis and support that just isn't available to risky new ideas. Since the absence of concrete evidence can be a showstopper for many decision-makers, ideators are deterred from proposing their ideas in the first place. After all, who would want to expend energy and enthusiasm championing an idea when there is a very good chance it won't even be entertained?

An IT organization can overtly follow a path that is predictable (read: rigidly process driven) as it may be right for its profile. Think about financial organizations like banks and insurance companies, or the constraints of regulation in healthcare industries. These types of organizations lend themselves to a sharper focus on process.

Then there are businesses that make innovation their modus operandi. I think about technology-based start-ups and industries where complacency means certain obsolescence. For example: miss a beat in the fast moving mobile phone domain and you're toast.

Lastly, there are a large percentage of businesses that want to be both predictable and innovative. Most importantly: they don't want one aspect to trump the other.

Today, every IT leader needs to consider this dichotomy for the business domain in which their business competes: whether to run an IT organization that is equal parts predictable and innovative. Strategies that can reconcile these two agendas have positive observable and measurable results. At the same time, organizations that don't reconcile these aspects often see lower levels of IT innovation. I'd bet that we each know the category in which our own organizations belong.

In O'Reilly IT, ensuring that we achieve the right degree of process while charting an innovative course is an important part of our transformation journey. As I've written before, it begins with winning over your IT staff and your internal customers. Then it's about clearly defining the limits of process within your organization. What will the culture permit?

When process overrides its benefits, it couldn't be clearer: your business stakeholders will reject it and it will fail. So tread slowly. Look for those organizational signals. Examples will include decreasing participation in process-based meetings; non-responded emails; and missed deadlines. Above all, when you begin to find the right balance, loudly communicate the benefits of the process. It needs to resonate with the participants. When it does, you know you're headed in the right direction.

If you're unsure whether your IT organization reconciles predictability with IT innovation, test it. One of the simplest ways to do this is to ask. You might be surprised at what you hear.



Related:


Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl