title: Backward Compatible Management Systems: Linking Process Networks to Formal Hierarchy date: 1995-03-15 author: Peter A.J. Bootsma contributors: organization: Quality Research copyright: see General RPM Licence (RP0104EN) file: RP0121EN.TXT source: QRBBS (+31-50-3133713) keywords: RPM abstract: Paper to be presented at the 39th EOQ annual conference. Networks of processes are a popular reaction to increasing complexity. In this paper it is argued that such networks need explicit links with hierarchy. A concept (`recursive process management') and a management tool (`process definition') are discussed. status: final version changes: comment: WP5 versions and illustrations can be downloaded. See =FFhttp://www.icce.rug.nl/qr/qrhome.html for details +------------------beginning of file------------------------+ paper to be presented at the EOQ congress, June 1995, Lausanne Backward Compatible Management Systems: Linking Process Networks to Formal Hierarchy Peter Bootsma, Quality Research, The Netherlands Summary: Networks of process teams may be a popular reaction to increasing complexity, but they cannot replace hierarchy. Network and hierarchy don't match very well either: responsibilities for cross departmental processes are often unclear. This paper is about an attempt to compatibility and a TQM infrastructure at the same time. The concept used is 'Recursive Process Management', a set of four generic management tools for process teams. These tools create common ground for specific concepts as QFD or ISO 9000 certification. The first tool, 'Process Definition', is a kind of founding charter. Teams use this to describe their purpose, team composition and their links to hierarchy. The tool fits management processes, primary and support processes and enables differentiation in autonomy levels. Peter A.J. Bootsma MBA, Quality Research, Zuiderpark 8, NL-9724 AE Groningen, The Netherlands, phone +31- 50-3134598, fax +31-50-3131411, bbs +31-50-3133713, e-mail p.bootsma@icce.rug.nl www http://www.icce.rug.nl/qr/qrhome.html 1 Introduction The real challenge for modern organizations is not quality. Neither is it customers, lean production, process redesign, environment or employee satisfaction. Taken separately, all of these issues can be addressed using existing management methods. The real challenge, however, is doing it all at the same time. The challenge is increasing complexity. More aspects to manage, more options to choose from, and increased need for integrated solutions. In this context, this paper discusses: - how unity of command limits the amount of complexity we can handle; - why networks do better but still can't beat hierarchy; - how a low level concept can integrate network and hierarchy; - how this works out in practice. The concept presented here is called `Recursive Process Management' or RPM for short. RPM was developed in 1992 and has been applied in 9 profit and non profit organizations of between 90 and 2000 employees. It is now the subject of cooperative development by a group of researchers, consultants and organizations, mainly in the North of the Netherlands. This paper briefly explains the concept, one of its four tools and its implementation in a 150 employee non profit organization, the Groningen Public Library. 2 Unity of command as a barrier to managing complexity The simplest way to manage complexity is not to manage. Just rely on common sense and let people adjust their behaviour. Unfortunately, only few organizations can be managed this way, most need more coordination. Next to nothing is managing just one thing and ignoring the rest. Typically, this thing is the primary process. The recipe is: chop it up in pieces like planning, R&D, manufacturing and sales, and assign managers and people accordingly. This creates a simple hierarchy. The basic rule is `unity of command': ambiguous orders are avoided by having only one superior for every employee. Trouble begins when aspects of management can't be isolated in one department because everyone is involved. For instance finance, personnel and environment. The traditional trick is to set up staff departments with direct lines to other departments. But unity of command can not be compromised and staff departments, therefore, have dotted lines and no authority. They merely prepare and execute top management decisions. Hierarchies can manage even more complexity with help of matrixes. While staff people could only draw attention to their subject, project managers can even claim resources to get the job done. They won't, however, get the real long term commitment that people reserve for their home department. The rule still is unity and not duality of command. Another way to handle complexity is unit management. Instead of being completely integrated, the company has autonomous units that serve their own market and have their own support functions. Ties with headquarters may be financial only. The concept of unit management is widely used, even though economies of scale may be compromised. Complexity reduction, however, is limited by the amount of shared functions, such as strategic planning, public relations, marketing, finance, R&D, environmental policy, etc. This is about as far we can get with unity of command. Beyond this point, more dotted lines and cross functional management is likely to increase unproductive tensions and departmental conflicts. Beyond this barrier, therefore, we find a completely different concept for organizations: networks of self managing teams instead of hierarchies of departments. Unity is gone. These teams all face ambiguous requirements to their processes, but they deal with it directly instead of asking one manager for orders. Their basic rule therefore becomes `multitude of stakeholders', rather than `unity of command'. 3 Differences between hierarchy and network The emerge of networks is evident. According to ISO 9000, for instance, an `organization' is `a network of processes' that should be identified, organized and managed. The implications of organizing networks are less clear. For instance: how should responsibilities be distributed in a network? To find answers, it may be helpful to explore some fundamental differences between hierarchy and network. From a systems point of view, both hierarchies and networks are just groups of elements connected by relations. But there is a difference. Hierarchies have few (formal) relations, all in one dominant direction, while networks have many relations in all directions. This mathematical difference has large implications. For instance, it explains why elephants don't dance. That's not a matter of size, weight or muscles; elephants outrun most of us. Neither is it brain volume; elephants have more. There is a major difference, however, in the connections between brain cells. Humans have far more dendrites and synapses. The result is a high connectivity neural network, which is the key to performing complex tasks, such as dancing. Unlike elephants, large organizations can improve their effectiveness by increasing internal connectivity: for instance by tearing down walls between departments. But it's not as simple as that. Adding lines in all directions, means running into the unity of command barrier. Instead of increasing effectiveness it might increase inertia and management overhead, threatening efficiency and flexibility. Connectivity, therefore, is not just a scalar difference between hierarchy and network but rather separates them as different and incompatible paradigms. A logical and even popular thought at this point is to give up hierarchy and build organizations as networks only. Will this work? We might, for the sake of argument, take another biological example: a school of fish. A school is not coordinated through hierarchy but through the voluntary responses of each fish to external signals and their neighbours' movements. As a result, the school has eyes in all directions. It responds as one intelligent body to approaching dangers such as sharks. As long as the school sticks together, few sharks can surprise it. Wouldn't that be nice for a modern organization: internal coherence, external responsiveness, and all without the burden of central control. There is one major drawback, however. The school is responsive because each individual recognizes a shark as dangerous. Sharks are in their genes. The trouble is, trawlers and fishing nets are not. And without hierarchy, even with the net in sight, there is no way to decide between moving right or left. Developing razor sharp teeth might help, but not on short notice. So, surprising a network organization can be quite simple: invent something they never thought of and don't give them time to learn. Of course, human network organizations will learn faster than schools of herring. But the drawback remains the same: recognizing the unknown and agreeing on collective action may simply take too long. Therefore, it wouldn't surprise if a network organization in trouble reinvents hierarchy to improve responsiveness. This get us to the central proposition: if managing complexity requires more than hierarchy and managing innovation requires more than network, then there might be a hybrid option: having hierarchy and network simultaneously. Not a bit of both but an integration of uncompromised concepts. For hierarchy, this means: no distinction between line and staff, no matrixes, large span of responsibility and flat structures. On the network side this means all employees take part in interconnected teams, and teams do all the work. To realize this, relations between hierarchy and network must be redesigned, the objective is compatibility. 4 A low level concept to integrate hierarchy and network Recursive Process Management is intended link network to hierarchy, but as a low level concept only. It helps structuring the network, taking business processes as building blocks. In a technical metaphor, RPM is designed to be for an organization what DOS is for a computer: it facilitates processes and provides standards for interfacing. It does, however, not offer advanced front end functionality. 4.1 implementation: first top down, then bottom up RPM consists by now of four generic management tools for process teams, as illustrated in Figure 1. To understand how it works, we'll follow its implementation. After setting project objectives, implementing RPM starts with a top management task: top-down defining processes and assigning these to process teams. This typically ranges from strategic planning to facility management and includes all existing departments, units, groups, committees, etc. For instance, the Groningen Public Library installed 32 teams for a total of 150 employees. From this point, things work bottom up. First, teams are asked to put together a Process Definition, as illustrated in Figure 2. The Process Definition has three elements: - A description of the product flow, as the 'reason of being' of the team. The strategic team of our library, for instance, names `annual plans' as one element of their product flow. Branch teams name `replacements in library collections' or `answers to customer inquiries'; - A description of the team composition and subprocesses (if any) that are represented by their team coordinator; - An 'authorization table' which denotes management responsibilities regarding the process. 4.2 authorization table contains links to hierarchy The authorization table holds the connection with formal hierarchy, as illustrated in Figure 1. The actual link is established by answering four questions, starting with: - Who owns the process? Unlike other approaches, within RPM ownership implies absolute hierarchical responsibility for the process, for the team and for all managers involved. In other words, unity of command as usual. Therefore, in a departmental team the process owner will often be the head of department. For a cross departmental team, however, the process owner is one or more levels up, often involving top management. A process owner is responsible for process performance. A process owners role, however, may be restricted to ensuring consensus and if necessary repairing it. That's not a full time job since many people try, for good reasons, to avoid top management interventions. Next come three questions about the amount of responsibility delegated to the team. The assumption is that the team always makes operational decisions themselves. Policy matters, however, usually involve outsiders. Three policy aspects are distinguished: - Who decides about process design (how) - Who decides about team composition (who) - Who decides about output planning (what) With regard to each of these aspects, the team may be autonomous in preparing the decisions, for instance by writing a procedure, a job profile or an annual plan. The question, however, is who decides about these proposals: the process owner, other people outside the team, or the team itself, as illustrated in figure 1. The answer may depend on the competence of the team, the risks involved, necessary alignment with other teams, etc. Then, what's left for the team coordinator in case he or she does not decide about process, team or planning? Basically the task is communication: organizing regular team meetings, negotiating with stakeholders, documenting the process, putting together team plans and reports, initiating and managing improvement actions. The job of coordinating a team is challenging because power does not come from hierarchy but from information and initiative. For instance: the team coordinator can formulate a proposal for an authorization table, thus asking for a certain amount of autonomy from the process owner. Anyone competent team member can do the job, a formal position is not required. Essentially, this means that, apart from the team, there are two key persons for each process: the process owner, hierarchically responsible for process performance, and the team coordinator, non hierarchically responsible for communication. And possibly some people in between with delegated decision powers. The number of intermediate decision makers is a matter of choice. The Process Definition helps visualizing this number but does not prescribe few or many. Visualizing, on the other hand, is a powerful instrument in limiting the number of indirectly involved people. The relevance of this specific role model with owners, intermediates and coordinators is that it serves to analyze and design almost any type of delegation between classical military hierarchy and, say, empowered cluster organizations. On the other hand, as many low level concepts, the model does not prescribe what choice to make. It may help to differentiate between discipline and improvisation in neighbouring teams, but may also help to line them up. It may be used to increase empowerment but also to decrease it again when empowerment ever gets out of date. The role model itself, as the rest of RPM, is therefore not a management style. It just helps developing an appropriate one. 4.3 adding other tools At this stage of implementing RPM, teams are ready with their Process Definition. They negotiate this document with all involved and finally with the process owner. Typically, it is printed in the organization manual to underline the formal status of the process and its team. The team is now linked to hierarchy and can continue with other management tasks such as formulating objectives, developing their quality assurance and improvement management. The corresponding tools (figure 3) are not discussed here. The `operating system' nature implies generic tools rather than advanced front end concepts. Inevitably, these generic tools will cover only the most basic of management tasks. But similar to using a word processor on top of DOS, teams may use SPC, FMEA, QFD, procedures, instructions, etc. on top of RPM. This means, by the way, that designing and implementing specific front end tools may be easier. This idea of an 'organizational operating system', separated from specific management tools and designed to enable other tasks, is hardly new. In fact, planning and control practices, management by objectives and policy deployment carry similar characteristics. In this field, RPM, is intended to get one step further into compact and generic management tools for process teams. 5 Benefits and complications of low level concepts Any concept for `networks of processes' will claim benefits such as: - Increased ability to manage complexity, caused by shorter communication lines and `multitude of stakeholders'. - Productivity, as long as empowered process teams are the building blocks of the network. In addition to this, Recursive Process Management adds: - Responsiveness, because of the explicit links with hierarchy; - Efficiency. The restriction to generic low level management tools results in: 1 A training scheme which is basically the same for all functions and all levels. Teams may therefore learn more from each other and rely less on consultants; 2 Cutting out time consuming discussions about whether or not to include process A or B. Instead, lack of exceptions advances cultural integration; the tools become part of 'the way we do things around here'. This decreases the costs of training and consultancy during implementation and thereafter; 3 Shared focus on efficiency. Efficiency itself is a generic theme that concerns all teams and can therefore be directly integrated in low level tools. For instance by declaring efficiency a success factor for all teams and inviting all teams to define their own efficiency indicators, like cost per product or budget overrun (Quality Definition, not described here). - Customized autonomy. The 'how', 'who' and 'what' responsibilities may each belong to the process owner, to people outside the team or to the team itself. This enables a wide variety in levels of autonomy. For instance, a team decides on process design but needs approval for output planning. The flexibility of the tool enables an organization to choose a degree of autonomy per team and to plan autonomy increase in small steps. Of course, network concepts -including RPM- have costs too: - Different mindset required. New frames of reference cannot be introduced overnight, not even with dedicated management tools. Training needs to include learning by doing and special care must be given to communication, reward systems, auditing and even EDP. - Process documentation needs explicit attention. Not unlike ISO 9000, this asks for 1) making all teams responsible for their own paperwork and 2) teaching teams to estimate documentation efforts and match this with available time (Assurance Plan, not discussed here). 6 Implementations Implementations so far show that teams appreciate the new tools for their non-prescriptive nature. Also, the generic design of the tools, has helped sustaining momentum in discussions about methods. It is still a bit early, however, to draw final conclusions about cultural integration of the tools. Also, efficiency effects are hard to quantify. In several implementation projects so far, top management teams used the tools for their own process of strategic planning. One of the success factors they arrive at in writing their 'quality definition' is 'communication'. This expresses that strategic planning lacks quality when the organization is not informed and involved properly. To measure this, employees were asked for their `marks' for policy communication. Publishing the average result is usually confronting at first, but shows top management's commitment to quality in a way that can be imitated. Another outcome we have seen so far is that top managers, once they `own' several processes, tend to push the 'how-who-what' roles down the line and even into the teams. They do this to clear their desk, of course, but also because they always retain final responsibility, they don't lose control. RPM is still in an early stage of development and needs more implementations to stabilize. An important step so far has been the development of the authorization model itself. This part received its current form November '93 and needed only minor changes through subsequent implementations. A still existing question is explaining the abstract notion of networks, although significant progress has been made with a management game developed at the Groningen Public Library. The latest issue we're working on are quick references for the RPM-tools and extensions for planning and reporting in process networks. Apart from the concept there is the issue of copyright. At first, the idea was to discourage unauthorised duplication of ideas and materials as usual. But this doesn't really work for tools that are designed for proliferation. Among other reasons, this has led to the decision to drop all restrictions to copying RPM tools and materials, similar to the practices described in the GNU General Public License for software distribution. This means the concept itself is freely available to everyone at costs of providing information only. This rule applies to anyone working with RPM. It is intended to make RPM a collective concept rather than a proprietary product, to involve managers, consultants and organizational scientists and to arrive at better results through exchange and cooperation. And, last but not least, to create more personal value in networking, or more 'dynamic quality' for those who read Pirsig. 7 Conclusions To conclude with, the presented concept may seem quite obvious and the tools rather basic: no advanced statistics, no elaborate maps or charts, no hi tech planning techniques. Just a few forms that go into the organization manual. Reading this paper may be as exiting as reading the DOS manual of your PC. But somehow, that's what it should be: all operating systems are about reliable basic functions so we can spend our time on the real work. As long as it works we may forget it's even there, just like unity of command has been considered a law of nature. When the concept reaches the end of its life cycle, however, it's not just worth spending time on, renewal becomes a prerequisite for further growth. On the other hand, we should not get carried away with low level concepts, it's rather a matter of fixing the engine to get back on the road. Connecting process networks to hierarchies is not yet proven technology. A lot more work has to be done to realise its potential for managing internal and external complexity. But, as a final question: is this TQM or not? On one hand it is, after all, it is about quality and management in all parts of an organization. On the other hand, it is about low level concepts, it only gets you halfway. It helps building an infrastructure for TQM but does intentionally not provide the finishing touch in order to retain its generic character. It will contribute, however, to modern organizations, where network and hierarchy support each other more explicitly. Not as a compromise but in synergy, building on simplified hierarchy and fully developed networks, enabling us to achieve both stakeholder satisfaction and strategic responsiveness. 8 References Bootsma, P.A.J., Recursive Process Management: improved TQM through fractal design of management tools, EOQ congress proceedings, 1994 (bbs +31-50-133713, file RP0102EN.WP5) Davidow, W.H., and M.S. Malone, The virtual Corporation, HarperCollins, 1992 Free Software Foundation, GNU General Public License, Free Software Foundation, 1994 Likert, R., New patterns of management, McGraw-Hill, 1961. Quin Mills, D., Rebirth of the corporation, Harvard Business School, 1991 Morgan, G., Images of organization, Sage, 1986. Peters, T., Liberation management, MacMillan, 1992. Pirsig, R., Lila, an inquiry into morals, Bantam, 1991. Vogt, G., Das virtuelle Unternehmen, Der Organisator, 1994 Warnecke, H.J., The Fractal Company, Springer-Verlag, 1993 Biography Peter A.J. Bootsma (1959) holds a masters degree in business administration (Glasgow University, 1991) and a bachelors degree in mechanical engineering (Zwolle, 1984). He has worked for the HBO-raad (Dutch council for higher professional education), Philips Norrk=F6pings Industrier (now Whirlpool) in Sweden, Philips Domestic Appliances and Personal Care in Groningen, and N.V. Nederlandse Gasunie, also in Groningen. Main issues have been logistics, project management and quality management. He founded Quality Research in 1992 and developed the Recursive Process Management concept. Besides research and consulting, he teaches quality management at the Leeuwarden Business School and is chairman of the Kwaliteitskring Noord-Nederland (North Netherlands Quality Association, over 400 member companies).