Posted by admin on May 7, 2010 under Enterprise Architecture, Process Improvement | 
A couple of weeks ago, I posted a comment (http://ow.ly/1Ifgm) on an article published by McKinsey about a failed Enterprise Architecture (EA) initiative. I wanted to follow up on this topic because of EAs increasing popularity and importance in organizations.
What is EA? Quite simply, it is a holistic view of the components of an organization, and their relationships to one another. This, of course, implies alignment and connectivity throughout the organization which is one of the reasons EA is becoming so popular. Documenting an organizations enterprise architecture highlights any disconnects in an organization. Further, the potential impacts of strategic decisions are readily apparent when viewed in the context of the organizations architecture.
While EA is a powerful and useful tool, organizations must enter into EA initiatives with “eyes wide open”. If you have ever tried documenting a current business process, you can appreciate the complexity of documenting a high level architecture across an entire organization. This exercise is not for the faint of heart! However, the insight it provides is well worth pursuing. With a few “ground rules”, an organization can be successful in implementing EA.
I have just released an article commenting on on the McKinsey case study, and a few success factors in undertaking an EA initiative. I’d be interested in your perspective on this subject.
Posted by admin on April 19, 2010 under Enterprise Architecture |
McKinsey recently released a new whitepaper on why business needs should drive IT architecture (http://ow.ly/1yUHu). It seems to me we, in the industry, have been talking about this subject for a long time. Why is there even still a need for any discussion?
This article is chock full of tips for the CIO trying to implement EA - it even contains a checklist to “revolutionize architecture management”. I question, however, whether EA efforts can and should be initiated by the IT organization. Do we understand enough about what EA should be accomplishing to be the driver for these types of initiatives?
I’ll share my thoughts in my May article so check back here on May 7, or subscribe here so you don’t miss it. In the meantime, let me know your thoughts…
Posted by admin on April 1, 2010 under Leadership, Process Improvement |
For several months now, we have been talking about moving forward with our strategic plans, and implementing the right technology for the job. We have talked about why technology projects fail, pointing out that organizations tend to get the “cart before the horse” by selecting technology without necessarily considering how it will impact the business processes it is designed to support. There is an additional element that needs to be considered when enabling change through the implementation of technology…
Often, organizations are reengineering processes and implementing new automated systems to address business process challenges, whether automating manual processes or enhancing existing software applications. Unfortunately, organizations tend to make one very large mistake during these efforts – they make change management decisions in the context of a single silo – solely within their own departmental boundaries.
It is a rare team, indeed, which considers how to improve operations across a full business process. For example, a customer service organization might consider how they can more quickly respond to and address customer calls. They might implement call center software or other technology that allows customer service representatives to answer calls within X number of rings, and enter a sales order within X number of keystrokes.
However, has any thought been given to the “upstream” or “downstream” processes, and the impacts on those process “handoffs”? It is likely that our customer service organization is thinking only in terms of its own organizational silo, and how those “internal” processes are being performed.
Granted, those metrics and operational functions are critical to the organization. However, what about the downstream process of order fulfillment, for example? When considering the technology or business process change, are you considering how to more effectively provide the inputs needed to fulfill that customer order?
What about product development processes which (should) rely on customer feedback in order to develop products customers will purchase? How are these processes impacted by the changes made in the customer service department? Is there an opportunity to improve the information being collected in the customer service department so it can be provided to the product development team?
I think you would agree that all departments play a key role in the operational capabilities of an organization. Each must work together in a synchronized manner in order for the organization to be most effective. If one of those processes gets out of whack, the “wobbles” are felt throughout the rest of the organization.
When considering making improvements to your functional area, consider the following:
- Identify the specific information, documents or other inputs you are receiving into your departmental business processes. Can they be provided in a more useful manner or format? Are they being provided often enough? Too often? Is there anything missing from the input that causes rework, delay or additional effort in order to execute your own business processes?
- Evaluate the outputs of your business process – the product(s) you provide for the “downstream” process. Are you providing the input in the right format? Often enough? Too often? How could you make your work product better so it can better be utilized by the recipient (whether internal or external)?
By considering the inputs and outputs from your own business processes, you are improving operations not only in your corner of the world, but potentially in other areas as well. Further, you are demonstrating to others how to affect the best kind of change – change that allows the entire organization to work more effectively and efficiently.
Posted by admin on February 6, 2010 under Process Improvement, Technology |
There is a lot of literature about the reasons for the abysmal success rate of technology implementation projects. We blame the project management skills, the end users (if you can imagine), management’s lack of support and/or interest and so forth.
While all these may contribute to the demise of a project, the real reason these projects fail is that they do not address the underlying business problem being solved. The first step in any technology project needs to be the careful, systematic definition and assessment of the business problem. If you cannot articulate the business problem you are addressing, you have no business even starting a project! For more, see our latest article.
