Recently I described the role of the Business Architect in developing a formal Organizational Change Management program. As a result, I had an interesting conversation with a CIO. This CIO had a good understanding of and appreciation for business architecture. However, he did not believe that convincing “the business” to invest in business architecture would be an easy sell; what the business asked for was a formal Organizational Change Management program.The question this CIO posed was this: Can Organizational Change Management drive support for Business Architecture and help get an Enterprise Business Architecture Practice funded and off the ground?
A different perspective
This changes the perspective. In this case, I am not working “from” a familiar definition for Business Architecture. Rather, I am working “towards” that familiar definition; essentially starting from nothing.This new perspective, however, does not change the definition of Business Architecture, that provided by the OMG Business Architecture Working Group (www.bawg.omg.org). I still have the same aspects of Business Architecture to consider: organization, business processes, business information, capabilities and governance structures. The difference is this time I am populating them, not leveraging them. Nor does this perspective change the five components that I believe make up a complete Organizational Change Management program: impact mitigation, communication, incentives, support, and training. It only changes my approach.
Impact Mitigation
When starting from scratch, and leveraging the Organizational Change Management program to populate business architecture, I still start with the organizational to identify the various parts of the business affected by the change. However, in this case it is not to craft meaningful communication, though that will come. It is more of a first step in understanding management’s vision and what management believes is the impact to the business.Having gained management’s perspective of the impact, it is up to the Business Architect to determine which business processes are affected and ascertain the practitioner’s view of the impact; that is, the view from the people actually executing the various business processes. The Business Architect documents the as-is and to-be business processes by working with the managers and staff of each business unit identified by upper management as being impacted by the change. This allows the Business Architect to consider the end-to-end business processes, those that span business functions and organizational boundaries, and develop a sense for the impact of change on the enterprise, not just on single business units. This first step in utilizing Organizational Change Management to populate business architecture gives us two things. First, it gives us a glimpse of the organization and possibly the governance structure within the organization. Second, it gives us a set of business processes that take into account the people, processes, and technology required to deliver value to the customer. Keep in mind, however, that the artifacts at this point are not complete. The organization/governance structure will have been defined in terms of the change that is currently being managed. The same holds true for the business processes; these are only the processes affected by the change at hand. The business still has a long way to go in their business architecture maturity.
Communication
The efforts involved in conducting the impact assessment give the Business Architect a good idea of how well upper management has communicated the vision to the management team and how well the management team disseminated the vision to front-line staff. So while the Business Architect may now work with upper management to develop or hone their communication plan, the communication program itself does not contribute that much to business architecture. Or does it?When considering business processes we may be tempted to think of only the core business processes; those that deliver value to or otherwise interact direct with the customer. However, we must also consider support processes such as HR and IT processes, and so must the communication program. Having populated the business architecture with people, process and technology artifacts during impact analysis, the Business Architect is now well positioned to take the vision to HR and work with HR on the people side of the organization (e.g., roles, responsibilities, skills, job descriptions) thus improving the organizational model. The Business Architect can work with executive management to better understand and document their governance structure. And the Business Architect can let IT know how the change impacts the application and information architecture that supports the business. Finally, the communication program makes a less tangible contribution to business architecture – the relationships between core business processes and support processes and, therefore, relationships between the various business units and support organizations.
Incentives
The incentive program works both ways. The Business Architect works with executive management to understand the enterprise’s tolerance for incentives and then works with HR to develop the incentive program, which becomes part of the organization model. The Business Architect also works with executive management to align the tactical aspects of change with strategic objectives, assign a strategic value to the change, and quantify the value that successful change promises. The strategic value of change not only contributes to defining an appropriate incentives program but also leads to measures and KPIs that further contribute to the governance structure and its maturity.
Support
The support structure is a temporary structure designed to last only long enough to get the business to a certain level of comfort with the change, or capability maturity. Of course, the support structure relies on measures and KPIs to determine that level of comfort and to determine where support services are needed at any give time. Those affected by the change depend on the support structure to help them through the change. Executive management, on the other hand, depends on the support structure to feed those measures and KPIs into the governance cycle and will use that information to further mature the governance structure.
Training
Training gives the business the opportunity to refocus and retool the organization. By cataloging what has been learned and to what levels of proficiency, an effective training program allows the organization to change as the business changes, adjust incentive programs where and when appropriate, staff and decommission support structures as necessary, and proactively mitigate the impact of change.
Conclusion
If this approach to business architecture seems backwards and convoluted, it is. It is not a perfect world out there so we can not assume that we will have business architecture to leverage when developing an Organizational Change Management program. All too often business architecture must fly under the radar until such time as it can make a contribution of its own. Once upper management sees the value that business architecture brings to the enterprise, buy-in will increase, funding will be granted, and eventually we will see Enterprise Business Architecture as a strategic imperative. Until such time, however, we may have to work with what we are given and populate the business architecture as we go.
