Showing posts with label Value Chain. Show all posts
Showing posts with label Value Chain. Show all posts
Saturday, 24 October 2015
Friday, 18 September 2015
Wednesday, 10 June 2015
Monday, 1 June 2015
Building A Customer-Obsessed Operating Model
Empowered customers, armed with ever-increasing digital capability, increasingly expect any information, any service, at their moment of need. We call this the age of the customer. Innovative brands, from Delta to Southwest, T-Mobile to Verizon, Home Depot to Walgreens, and Caterpillar to Rolls Royce, are sharing with Forrester how they are disrupting the way they work to meet their empowered customers’ needs, to become customer-obsessed. Becoming customer-obsessed gives you, the CIO, an unprecedented opportunity: to overcome the nagging frustration of IT gravity that suppresses your and your team’s ability to influence the direction of your business, to build new competitive advantage. But you have to be willing to change the way you work.
You’re in an enviable position and are more essential to your firm’s success than ever. Together with your CMO, you have the best overall knowledge of your customers and the technology know-how to deliver a superior customer experience and drive growth.
We’ve begun to identify how leading firms change their operating models to deliver more value and become truly customer-obsessed. Much of that change falls on the CIO to drive. This research is ongoing, but the actions leaders take to shape their customer-obsessed operating model — focused on customer loyalty, innovation, and most importantly, growth, and fueled by customer insight — are becoming clear:
- Investing in new skills. Software and data are central to how you deliver value. We believe customer-obsessed firms cultivate software engineering, analytics, and customer experience design competencies to meet and exceed customer experience expectations.
- Disrupting processes. Your customers get value-added services and capabilities from other firms they do business with almost daily. We know yearlong, or even quarterly, delivery cycles can’t keep pace. And we believe you have to rethink your processes with your end customers — not just your business stakeholders — in mind. We believe you have to be agile, at scale, and not just within your teams but across the entire organization. That includes marketing, finance, and business units designing, funding, and delivering to your customers’ moments of need.
- Re-engineering systems. Monolithic systems once served a purpose. Today, you have to deliver to your customers’ moments of need. That moment may be digital, but it may also be when they’re on the phone with a customer service representative or talking directly to one of your sales representatives. We know leaders constantly re-engineer their systems to deliver capabilities and micro-services that can be assembled into moments of need defined by customers’ journeys.
- Assembling new teams. Leaders define their organizations to drive greater collaboration around customer needs and growth. These firms abandon functional models in favor of centers of excellence and teams that come together on shared goals and outcomes.
- Modifying governance. From the top down, these leading firms put customer insight at the center of their decision-making and governance. ROI and contributions to EBIDTA still matter, but leaders use new metrics, like our own Customer Experience Index, to drive project investment strategies and measure outcomes. Failure is also tolerated, so long as failure happens quickly.
- Transforming culture. Corporate cultures can no longer be rigid. Leaders embrace purpose-driven, customer-focused cultures. They also value insight-driven decisions, showing low tolerance for decisions based on assumptions that cannot be backed up by data. Leaders drive this culture by changing how people are goaled and measured and supported by more continuous learning for employees to help them become more tolerant of change.
Now is the time to become customer-obsessed and focus your strategy and budgets on the business technology agenda — technologies, systems, and processes to win, serve, and retain customers. Doing so doesn’t just help you deliver better customer experiences, deliver innovative products and services, or accelerate your path to a digital business future. Doing so helps your firm create new competitive advantage — if you’re willing to change.
Stay tuned for more on our research in these key areas of the customer-obsessed operating model. And reach out to me if you have questions or ideas on what we may be missing at kmcnabb@forrester.com.
Friday, 20 March 2015
Saturday, 17 January 2015
The Subject and Discipline of Business Architecture
Business Architecture has become a modern term. It is like a security, everybody has heard about it and has a personal opinion but very few know what it actually means.
This article discusses the phenomena of Business Architecture considering both its subject and discipline. Without knowing the subject of Business Architecture, it is very difficult to justify the scope and extension of the role of a Business Architect, i.e. the discipline. Many Managers and Architects can say – “What’s the problem? By identifying stakeholders and collecting their viewpoints, one could essentially define a Business Architecture”. Unfortunately, this approach is the major fault that leads to many contradicting opinions about this subject.
The proponents of defining Business Architecture via opinions of stakeholders subconsciously change focus from “what it is” to “what can it do for me” and usually refer to the ISO/IEC/IEEE42010 standard 1 addressing viewpoints and views. However, this standard warns that views cannot define a subject but can only describe it. We deal here with a difference between ‘description’ and ‘definition’. One can collect thousands of descriptions and still would not have a definition of the subject because every description or view is subjective, in other words everyone sees what she or he wants to see.
I have noticed that in numerous discussions about Business Architecture at conferences and on the Web , the debate mostly shifts into what Business Architects do or should do, which is a different matter. When we are defining a view on car driving, does it define the car? No, it does not because the process of driving relates to only a few operational controls in the car and their effect on the movement. Additionally, there are special driving rules and regulations that cannot be found by observing a car; just reviewing the outside-in views on a car we cannot find what is under the hood. If we cannot resolve this simple case with a car, then why should we assume that stakeholders know more about Business Architecture via their observations than the Business Architects do?
In this article, I describe a method that has led me to the definition of an Enterprise Business Architecture irrespective of the business domain of the enterprise. As a result, Business Architecture appears simpler than many think and, simultaneously, has more complex relationships with the rest of the business in an enterprise. I will articulate the reasoning for this conclusion and list some outcomes of it.
Business Architecture Definition
Architectural Business Elements of an Enterprise
The two approaches of defining Business Architecture can be used from the business and formalization perspective. The first approach is based on business value. A commonly known business value is a monetary one. Many believe that this value, including the monetary equivalent of goods, is the only one valued by businesses. Monetary abstraction is very simple and convenient for modeling, measuring and managing; however, in a consumer society we cannot eat bank notes, we cannot wear them, we cannot move on them.
When a new enterprise is established, an Enterprise Business Model – the “business face” of the company – is written. It usually comprises the core business functionality that distinguishes this enterprise from others in the market. Business functionality is the only category that links an enterprise to the 'demand and supply’ factors of a consumer society.
Measuring this link in monetary values only is good for a short-term. Monetary values obfuscate the mechanism of the demand satisfaction and in the long run a company can miss the point where this mechanism should be adjusted to the changed demand. If consumer satisfaction decreases, the company might not lose its revenue yet but it may be too late when the revenue starts dropping – the company’s reputation with the customers may be already damaged some time ago. That is, monetary values are good for measuring but this is not the only one criterion for the business effectiveness.
At the same time, business functionality addresses the core business value of any company in a consumer society. If this functionality satisfies the needs of the consumers, they will bring money to the company. That is, the second approach combines monetary and functionality aspects as the criteria for Business Architecture. If Business Architecture is based on business functionality, it is much more likely that the essence of the corporate business and its strategic goals will fit with the changes in the market.
Talking about Business Architecture I assume that it is an architecture, first of all. I have chosen a definition of architecture formulated in the ISO/IEC/IEEE 42010 1 and extended it as the following: an organization of a system/structure embodied in its fundamental self-sufficient cohesive elements, their relationships to each other and to the environment, and shared principles guiding its design and evolution. As one can see, this definition is free from specifics of business or technology.
With this definition, I challenged several significant business elements of an enterprise including those that are the most frequently attributed to Business Architecture by other authors. The elements analyzed were business strategy, capabilities, financial (revenue/profit) targets, functionality, clients and suppliers, people and business processes, governance structure, business information, organizational structure, and structure of responsibility over economic activities.
Out of the above enumeration, only business functionality and business information have appeared to be
- Fundamental – an enterprise cannot exist without them and they are irreplaceable
- Self- sufficient – they are not derived from something else and can exist on their own
- Cohesive – they are consistent and interrelated
- Similarly guided – they share the same guiding principles.
That is, those two elements have architectural attributes. Characterizing other enterprise elements, I can briefly say that:
- Business strategy – is not self- sufficient and may have its own guiding principles different from the principles of other enterprise elements. Business strategy, together with the Enterprise Business Model, constitutes an input and objectives of the Business Architecture. The business strategy is defined and guarded by C-level executives. Business Architecture only contributes into the strategy definition and validates its final version via implementation
- Business capability – is an implementation of a particular business function or a combination of functions. Business capability is one of the primary outcomes from the Business Architecture realization while the architecture itself addresses only the functionality part of capabilities
- Financial targets – comprise a structure, not an architecture, because they are not self- sufficient and may be non-cohesive. In essence, the financial structure of an enterprise is derived from several factors that include business functionality, operational and organizational structures, implementation methodologies and technology, and the state of the market
- Clients and suppliers – are external elements while Business Architecture addresses internal elements of an enterprise; relationships with particular clients and suppliers are inputs in and outcomes from the Business Architecture models. Only types of clients and suppliers are included in architectural models
- People – are not self-sufficient, may be non-cohesive, replaceable and externalized (outsourced). Business Architecture (models) can exist without people while a realization of the Business Architecture cannot; all implementations of architecture are done by people
- Business processes – are a form of implementation of business functionality, more accurately – a form of implementation of business services. That is, business processes cannot be architectural elements while functions/services can
- Governance structure, organization structure, and structure of responsibilities over economic activities – are the major outcomes of Business Architecture implementation; some of them are inputs into Business Architecture as well. If they are out of sync with the Business Architecture decisions and directions, an enterprise has to adjust/modify these implementation elements to avoid troubles in the on-going activities.
Thus, all elements listed above are not architectural while very important to the enterprise. They form an environment where the Business Architecture exists and Business Architects operate. Business Architecture is not everything that is important for the enterprise (not everything in a car is its engine); Business Architecture is a compact entity but impacts everything in the enterprise.
Subject of Business Architecture
The subject of Business Architecture is defined by the answers to the questions WHY, WHAT, WHO, WHERE and WHEN the enterprise conducts its business. That is, Business Architecture elaborates on the Enterprise Business Model and Business Strategic Plans, transforms them into a functional landscape of the business while the rest of the company works on how this functionality is or should be implemented.
Enterprise Business Architecture is the architecture that comprises business functionality and business informational models, positions itself across the business administrative and organizational enterprise structures, and that transforms goals and objectives described in the Business Enterprise Model and refined in the Strategic Business Plans into the functional and informational definition of the corporate business. This definition of Business Architecture is based on the definition of architecture presented earlier.
The idea of functional architecture is not absolutely new; the modeling language ArchiMate refers to “Business Function Architecture”(BFA) though it is not clear enough. This definition does not distinguish between the architecture and its implementation when saying “The BFA describes the context in which processes are executed, and can be an aid to model and visualise the most important objectives of the organization” 2. Also, a business “model of organization …describes business processes, data and information, business objectives, critical success factors, organizational structure, information areas, and relations between these parts2.” In this line of logic, almost everything in the enterprise is a “Business Architecture”.
In contrast, I argue that Business Architecture defines, not describes, only a functional context regardless its implementation while “the most important objectives of the organization” are visualised in the corporate Business Strategic Plan. Moreover, as we discussed already, Business Architecture does not describe “business processes, data and information, business objectives, critical success factors, organizational structure”. All these are the factors of an architecture implementation. Business objectives and critical success factors cannot be a part of an architecture because they are external criteria that the architecture should adhere.
There is M:M ratio between Business Architectures and their implementations. Particular Business Architecture may have several alternative implementations; the opposite is also true. An implementation cannot be used for defining the architecture. An architecture should offer models of functionality, information and operation qualities (such as accessibility, scalability, robustness, security and alike) detailed enough for the implementation. The latter, therefore, starts with the potential solutions in both business and technology domains while treating Business Architecture as a source of requirements.
Business Architecture deals with current and planned functional architectural models. Existing functionality is frequently articulated as business competencies while planned functionality is depicted via business capabilities (i.e. potential abilities to realise certain business function/feature in particular business circumstances). A business competency may include motivational values and current behaviour while a business capability defines what the business could do if specific conditions occur.
A capability is a combination of a business function and its possible (reserved) implementation as shown in Figure 1. Business Architecture defines the combinations of business functions/features for each capability while corporate management defines/reserves implementation details. Nonetheless, business capabilities are just a part of what Business Architects do and what the Business Architecture discipline defines. An enumeration of business functions/features without defined/reserved implementation is valueless. One can define/plan a holiday trip to Seychelles Islands but if all tickets are sold already, the plan is worthless.
Figure 1. Parts of a Business Capability
Described Business Architecture differs from the concept that is utterly based on capabilities, value streams and organization as it is promoted by the Business Architecture Guild (BAG)5. In contrast to BAG, this architecture states that a vision and strategies are inputs into architecture while tactics are implementation means, business capabilities are shared with meanagement and organization is a primary implementing mechanism that does not necessary match the architecture (unfortunately), value streams are results of implementation that also can appear differently from the architectural directions, architectural design projects are separate from the implementation projects, and policies-rules-regulations-metrics-measures are a contribution of architecture into the Governance for others and for itself, i.e. outside of the architecture. Business Architects may be and are involved in all these activities but as a part of the discipline, not as the subject of architecture. That is, BAG is not a new approach and just supports existing practice of mixing architectural models-plans with implementation, i.e. mixing intents with reality. It is well known that depending on business circumstances, value streams and capabilities may or may not materialise, i.e. building the architecture of phantoms is probably not the best way to spend resources.
Moreover, I have found that several BAG principles are contradictive. For example, if “Business architecture’s scope is the scope of the business”, how one can provide for ”Business architecture is reusable” – this totally depends on the “scope of the business”, which may be not reusable at all. Or, if ”Business architecture is not prescriptive”, everyone in an enterprise can do whatever she or he is pleased and Business Architecture simply becomes excessive. The paradigm of Business Architecture presented in this article is prescriptive in a sense it defines the business functionality and an information model that other elements of the enterprise should realise to the best of their abilities.
Every enterprise has its Business Architecture though it may be not formally documented or even perceived. Only business functionality and business informational model jointly form any particular Business Architecture. Other business elements of an enterprise make the architectural solutions happen. These elements influence Business Architecture or are influenced by it but do not construct it.
Consequences of functional Business Architecture
A Business Architecture, which is based on functionality and information, is, in essence, an architecture of services that realize business functionality and provide access to business capabilities. In other words, this Business Architecture leads to the type of a Service-Oriented Enterprise 3, which comprises structures of business services. Such an architecture is capable of linking together the strategic business goals/objectives, revenue, consumer demand and corporate culture4. It also needs certain organisational and operational structures of the company. This architecture transforms an enterprise into a form optimal for the businesses conducted in a highly dynamic external environment.
Service Orientation provides a rapid adoption of changes via business flexibility based on re-composition of business services. Flexibility of business solutions6 cannot be accomplished without the changes in the management and organizational structure of a company demanding them to become flexible as well. A service-oriented nature of Business Architecture appears as the major consolidating factor in an enterprise that is capable to be compliant with social structure, corporate culture, cooperative work of internal business units and external activities in the market.
Business Architecture oriented on services works for enterprises of all types and sizes. Service Orientation delivers the market competitive advantages based on business innovations, business solution integrity, business flexibility and extensibility, and all of these in convergence with the technological scalability, security and manageability.
Business services, which form Business Architecture, are organizational and operational entities that realize certain business functionality via manual and automated means. These entities usually cross from business to IT areas of the company 4. An Information Technology, as one of the forms of implementation of business functionality, plays an important role in optimization of business services. The proper granularity of business services makes their compositions a powerful instrument for addressing the majority of new business tasks and existing problems.
Business services provide the level of abstraction that permits the most comprehensive tactical and strategic business management. They also allow multiple competent and competitive implementations of the Business Architecture. As a result, an effectiveness of cost/value and improvement of Customer Value may be gained via re-arranging the structures of cooperating business services.
A Few Notes about Business Architecture Discipline
A discipline of Business Architecture bridges between business needs and business capabilities as a means of transforming WHAT into HOW. Since Business Architecture is the resource of requirements for defining business organizational, management and operational structures, Business Architecture discipline requires Business Architects to work in two basic dimensions. First, they define business functional models for the current state of the enterprise and plan functional capabilities for the transition to the strategic state. Second, they assist corporate management in developing business transformations via changes in products, services, organizational and operational structures. Both dimensions contribute in reaching the corporate financial targets. A relationship between the subject and discipline of Business Architecture is shown in Figure 2.
Figure 2. The subject and discipline of Business Architecture
Not everything that Business Architects deal with is Business Architecture. That is, an influence of Business Architecture penetrates many enterprise elements via Business Architecture discipline but these elements are not owned or managed by the Architecture. Business Architects consolidate directives from the C-level Executives with the directions of a Business Strategy Plan and Market Analysis, and transform the directives into business functional components – functions, features, services and products.
Business Architects contribute a great deal to business performance, but they do not define performance or revenue, or any other financial indicators – this is the job of management at all corporate levels. Business Architects design solutions that target certain performance or revenue, but I would not call it performance or revenue modeling. Business performance and revenue may be considered as the leading drivers to such Business Architecture’s qualities as scalability, flexibility, and robustness.
Business Architects define what business solutions and/or tasks the business units should take up to be compliant with a Business Strategy Plan and corporate goals and objectives. These decisions affect or should affect business operational structure, business and technology management structure, business deployment, product strategy and related technology delivery, though which unit does what is defined by the related management.
A Business Architecture discipline requires that certain decision making, which is currently an exclusive privilege of management, would be shared with or delegated to Business Architects. This is why Business Architects ought to be in the high business ranks, like Director or higher, because they have to influence business management of senior and mid-levels.
The work of Business Architects aims to the middle-to-long term gains and benefits. Short-term solutions, which may be characterized as “revenue today regardless of the cost tomorrow” or “tomorrow will be new business”, apparently is more costly and much more risky with the potential that “tomorrow” does not happen for such business. While architectural errors should not be withheld, the violation of architectural solutions attributed to short-term thinking during implementation is a much more frequent situation.
Altogether, a discipline of Business Architecture is a description of primary and secondary duties of the role of Business Architect. A separation between the subject and discipline of Business Architecture allows to distinguish between the architectural model level and its implementation throughout an enterprise 4. This also helps to clarify a separation of responsibilities between Business Architects and the corporate management.
Conclusions
This article discusses the definition of the subject and discipline of Business Architecture, its reasoning and options. The key methods applied are the separation between the architecture subject and discipline and the separation between the architecture and its implementation. Business Architects are those who develop the models of the architecture subject and assist the rest of the company in the models implementation.
In contrast with other approaches to the definition of Business Archtiecture, the article identifies that only business functionality and business information may be considered architectural entities and together form the subject of Business Architecture. The discipline of Business Architecture is a description of what the role of Business Architect has to work on as primary and secondary tasks.
Such definition of Business Architecture places business functionality and realizing it business services – the means of access to business capabilities – into the frontline. Business Architecture based on business services appears as the best model for carrying out the business enterprise model and strategic business goals. It's also capable of integrating the strategic business goals/objectives, revenue, consumer demand and corporate culture. This architecture is suitable for companies of any size in any business domain; it transforms a company into a Service-Oriented Enterprise that is optimal for the businesses conducted in a highly dynamic external environment.
Resources
1 “Recommended Practice for Architectural Description for Software-Intensive Systems”. ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.
2 “Pocket Guide: Enterprise Architecture Management”. BiZZdesign Academy, ISBN: 979-90-809722-4-7. 2011
3 Michael Poulin. “Ladder to SOE”. Trobador Publishing, ISBN 978-1848761-629, 2009.
4 Michael Poulin. “Architects Know What Managers Don’t”. BuTechCon, ISBN 978-0-9575199-0-9, 2013.
5 The Business Architecture Guild’s Web Site may be found here but the majority of its content is accessible to the members only.
6 The method of estimating solution flexibility is described in 4
Monday, 12 January 2015
Leading Organizational Redesign with Business Architecture
Reorganization of a business is not easy. Following the usual process of organizational design, you work to identify the current organization, note the gaps and describe a process for getting to the new organization. That sounds easy enough in theory, but implementing the reorganization is not nearly as straight forward. Asking stakeholders what the problems are usually only gets you symptoms. Identifying gaps is difficult because if the organization knew there were gaps, they would have fixed them. Then you have those who abhor change who believe their area of the business works fine – it’s everyone else’s fault.
Getting Started
Starting from a position of knowledge always helps to get started in the right direction. The idea of bringing in a team of consultants to figure out your organization and put it back together is not going to lead you to success. Just the amount of time spent figuring out what everybody is doing would take a relatively long time – you already know that something is not working or the business wouldn’t be reorganizing. That’s where a business architect provides value. Already having the blueprints including capability maps, value streams and organization maps puts you way ahead of the game.
Discovering Organizational Problems
When interviewing members of the leadership team, clients and staff, it’s important to know how they relate to the business – where they fit in the capability and organization maps. If one of the key problems is communications, which, let’s face it how many times is there not a communication problem, what type of communication problem? Is it that leadership doesn’t feel they are getting the information they need? Did leadership clearly set the expectation for what needs to be communicated? Is leadership providing the right kind of communication back to the staff? Does that communication rally the team or alienate them? How does communications affect your clients? I’ve seen all of these problems, even within the same organization. Using a combination of the capability maps and organization maps to discover where the communications are breaking down makes it easy to demonstrate the gaps.
Discovering Organizational Strategies
The next area that is crucial for reorganization is to spend time with the leadership to discover the organization’s strategies – current past and future. Understanding how that strategy was communicated, executed and evolved gives you clues as to what the organization can handle. I’ve used Enterprise Strategy Value maps and a lot of people were surprised to find out that that didn’t understand what the strategies were and what was important to leadership. Large swaths of the organization were working on projects that didn’t line up with the business’s direction. You will notice that I started by identifying gaps, then went to understanding strategy. This may seem backward to some, but becomes enlightening when you discover most gaps have nothing to do with organizational strategy and in fact most staff have no idea what is the strategy.
Discovering Strengths and Weaknesses
Knowing your capabilities is one thing. Knowing which are your core capabilities and the strengths and weaknesses of those capabilities is a whole new world for some organizations. I’ve been a part of quite a few Strength, Weakness, Opportunity and Threat (SWOT) analyses sessions. If they are done like a brain storming session, it will end up as a hodge-podge of ideas. When I run a SWOT, I try to target the items in the Enterprise Strategy Value Map and the Capability Map. It’s a real eye-opener when an organization realizes they don’t have strengths in the strategies they need to pursue and their supporting capabilities are stronger than their core capabilities. It’s not a surprise. As an organization grows, managers fight to protect what’s theirs. If the department they run is no longer needed, that team is out of a job. That fear of working oneself out of a job causes the manager to build an incredibly strong capability even though it provides very little value in advancing the organization’s goals.
Walking the Dog
I like to think of this phase as walking the dog. After everyone thinks the new organization is redesigned, this last step before launching can save an awful lot of headaches. The reorganization team creates a set of use cases that cover the major value streams. Working with each team, they walk their processes from start to finish calling out how materials, tools, product and information is passed among the players. Theoretically, the team should be able to traverse each value stream and define who is responsible, accountable, consulted and informed (RACI) at each stage. Most times someone realizes that a step or person was missed in the process. It’s always better to catch the problems before rolling the plan out. Don’t get me wrong, there will be errors in the plan uncovered as the reorganization becomes real, but with the proper due diligence, the errors should be pretty small.
Communication
The final topic that needs to be addressed is communication. The early stages of the reorganization will need to be with a relatively small set of people. Leaks in communication starts rumors, so be sure everyone on the team understands that and abides by it. As soon as a plan is made however, the communication has to start – communicate early, communicate often. Rumors will swirl. Productivity will drop drastically if people in the organization feel their jobs are threatened. Depending on the personalities involved, I’ve seen things get downright hostile. There will be agitators amongst the ranks. Address them quickly and disarm them. They can wreak havoc within the organization. If you can’t contain them, you may need to remove them. If there are people who will not have a place in the new organization, deal with them right-away and face to face. If you are not going to be keeping someone do it quickly and cleanly, don’t give that person the opportunity to poison the effort – sorry, that’s just the reality of business. You also need to communicate the fact that you had to let someone go to your remaining workforce. If they feel threatened, they may jump ship even though you value them highly. Always put a positive spin about the person you had to cut – this isn’t the time to air dirty laundry. Talk about the accomplishments they have made.
The Roll Out
The day is finally here. The new organization starts today. It’s not like you can just flip a switch and go home one night and the organization looks like it always did and Bam!, the next morning the organization’s all new. Usually, the roll out will occur over a period of days, weeks or months depending on the size of the organization. They key is to have a plan, work to the plan but adjust as necessary. Don’t protract the effort any more than it needs to. That’s how organizations fall back into doing things the same old way because nothing seems to be happening. It has to be driven – no faster than is needed to maintain control, but not so slow that you don’t see the change occur.
Wrapping up the Reorganization
As the reorganization rolls into place, necessary adjustments will need to be made to keep things running smoothly. The last step is to make sure everything is well documented. Are the capability maps up-to-date? Do we have all of our Value Streams corrected and each stage makes sense? Can we tell where communications should be flowing throughout the organization? Have we defined the right metrics for leadership to see the benefits of the new way of doing business?
Finally, the key piece to wrapping up the reorganization is just that, wrap it up. Nobody likes to be in a constant state of flux. That’s why planning and proper leadership before doing are so important. Minor changes will happen afterward, but try to stabilize the organization quickly and efficiently so your people can get back to doing their real work. Emotionally, change breeds a lot of stress and mistrust. The quicker you can lead your organization to stability, the better the emotional state of your team and the sooner your organization becomes the productive entity that the reorganization was meant to create.
Subscribe to:
Posts (Atom)
