Diversity Versus Replication of Organizational Processes and Information
I recently had the pleasure of joining a discussion among organizational development professionals. During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geographically around the world, should the organizational structure of each unit be similar?
The illustration that the questioner used: organization structure (org charts). Should the org charts look alike?
As examples, he mentioned two business units of his own company, one that was fairly “steep” with a Managing director having two direct reports, both Vice Presidents, and each of them having a small number of VPs under them. The alternative was a different unit of the same company where the Managing director had something like 16 functional managers reporting directly to him or her.
Unit one looked something like this:
Unit two looked something like this:
The questioner illustrated his example by pointing out in the “steep” structure (unit one), the director of Human Resources was somewhere down at level four. In the “shallow” structure (unit two), the director of Human Resources reports directly to the managing director.
So here’s the problem he faced: the company had a hard time moving a qualified director of Human Resources from unit two to unit one, because he would be “dropping” to four levels below the managing director, and that meant less control, less access, and less effectiveness. On the other hand, the executive in unit two, who had a large number of direct reports, frequently complained about being overworked.
Should we force each of the units to have the same hierarchy?
Think about it. The company had many structures, and they were different from one another, making it difficult for a person doing work in one of those structures to translate their work, their processes, and their efforts from one to another. This limited mobility of workers and cross-pollination of skills. It limited information integration and consistency. It limited process reuse. It meant that quality of the output could be quite variable, even though each of these different units produce the same (highly complex) product!
Before I go on… what do you think? Should the company have the same structure in every one of their geographically diverse operations?
Would you change you mind if I told you that some of those business units were two orders of magnitude larger and more profitable than others?
Which is better: diversity or consistency (replication)?
The first observation I’d like to make about this “problem” is that it is a problem by choice, and not by accident. The organization is NOT a franchise model. This is a large organization that has grown over the past 100 years to be a very successful company. Most of the life of the company preceded the information technology revolution… before computers and teleconferencing and instant communication. Each of the business units had no choice but to operate independently. Corporate management, early on, chose to allow each of the business units to structure itself as needed based on local conditions, people, culture, regulations, and resources. In the terms of Jeanne Ross (author of “Enterprise Architecture As Strategy”), the organization was not a replication model. It was a diversification model.
That said, each of these business units provided essentially the same product in each of a half-dozen different locations around the world.
Only someone who had read Jeanne’s book would recognize that the underlying question in the room was simple. The person posing the question saw a great many advantages to having a “replication operating model,” and didn’t see an advantage to having a “diversification operating model.” He was seeking input on whether he was the only person who could see the advantage to making a switch. (of course, he was not the CEO, so it was a fictional exercise, but a useful one nonetheless).
Switching from a Diversification Model to a Replication Model
There are many problems with making a switch from a diversification model to a replication model.
- It is fairly complex to do. An “ideal” model must be created for all of the business units to follow. Since none of the current business units is likely to have that “ideal” model implemented, you’d first have to create an “ideal” model and then implement it in one place to get feedback on how it actually works (if it does). That takes time. Once you’ve made changes in one place, rolling it out means moving people, recreating processes, and restructuring information and accountability across each of those units. It’s essentially the same a tearing down a company and starting over. Only each of those business units will have to keep operating while it is going on, and will have to show profit at the end of the year.
- Loss of business unit innovation. Companies making that kind of switch usually screw up at the “ideal model” stage because creating the “ideal” model rarely involves the right conversations with every one of the business units involved. As a result, innovations that are working well in one area can be lost because those innovations were not copied to the “ideal” model, even if they would have been useful to everyone. Importantly, innovations that were about to be implemented in any one unit, but had not been, are completely discarded. Evolution of the business units themselves can be thrown backward by years. Also, by the very fact that there is now “replication by policy,” it becomes very difficult for any further innovation to occur because it has to occur once and then be replicated everyone else, regardless of whether that innovation has the same ROI in each business unit. (Hint: it nearly never does).
- Loss of local adaptations. There is a notion that “the person closest to the work knows best how to do it.” In the case illustrated above, the two business units being compared were in different parts of the world, with different business cultures and business expectations. The PEOPLE in these organizations have a specific idea of the way that business operates. They have relationships, cultural expectations, and accountabilities neatly arranged to suit those local conditions. Your “ideal” structure will come from you, and you live in a business culture. We all do. Therefore, you have assumptions about what will and will not work. If you impose your structure on a group of people, be prepared to re-educate every single person in every single business unit on the “one right way” to do business… and then you’d better hope that the “ideal” you have created will be more effective in a local environment than the one that was previously there. (Hint: it probably won’t be).
A better way
As I have explained in my previous discussions of “Minimum Sufficient Business Integration,” I believe that many modern organizations can benefit from taking the time to find the minimum set of capabilities needed across business units to meet key corporate goals. After that minimum set is understood, the rest of the choices can (and probably should) be left up to the people closest to their customers and suppliers. At best, a “reference model” can be widely shared that represents your idea of what an “ideal” structure would look like… but without enforcement from above.
Of course, it can take a little thought to understand what is the “minimum” level of commonality that should be imposed. It should be very carefully considered because, and this is important, for there to be value in this concept, that level of commonality will be strictly imposed. No exceptions. On the other hand, every little thing included in that “common set” will be VERY expensive to roll out consistently across a wide array of business units, so the absolute minimum set should be included.
Conclusion
My recommendation for this situation is to remain in a diversification model, but to consider moving a little closer to process and information consistency through minimum sufficient business integration (MSBI). This means having consistency for those areas that absolutely positively must have consistency, and then to allow diversity (and innovation) to grow atop that minimum set.
In that case, the org charts would probably remain different from one another… and rightly so.
Happy architecting!
P.S.: I also want to point out that the notion of minimum sufficient integration takes place at the level of business capabilities. Not business processes. Not information elements. Not business functions. Capabilities. So if your business architecture methods don’t use capabilities (or if you don’t know what capabilities are), you cannot use this methodology. This post is not going to teach you what a business capability is, but I’ve blogged about them dozens of times, as have hundreds of other folks including the Business Architecture Guild and the Business Architecture Society. Start there.
Technorati Tags: business architecture,enterprise architecture,organizational development,integration