Complementarity of project and process management
ARBEITSPAPIERE DER NORDAKADEMIE ISSN 1860-0360 Nr. 2018-02 Project and process management are usually mixed together. In fact, on the one hand, they complement each other, on the other, they differ fundamentally and their intersection is small. Therefore, it is important to overcome the prevailing paradigm of process management and to broaden the view of the entire company organization. To this end, the present article takes up cognitive science findings that justify a distinction between tasks and problems. From this, two generic procedural models are derived, one for the completion of tasks and the other for the solution of prob-lems. Finally, these two models are related to each other in a meta-model.
1 Process management as a paradigm
Since Hammer and Champy (1993/2003) recommended a radical reorganization of companies towards business processes in the early 1990s and promised a dramatic improvement in key performance indicators such as costs, quality, service and lead-time, process management has established itself worldwide. Knuppertz and Feddern (2011, V) even associate this with an al-most epochal development; according to Wagner and Patzak (2007/2015, VII), leading compa-nies without process management are no longer imaginable and Nanz (2012, 210) claims that business process management is an integral part of the everyday work of most companies and organizations. The latter can at least be justified in so far as the probably most widespread standard worldwide, DIN EN ISO 9001:2015, requires a process organization for quality man-agement from all companies certified according to it (Ahrens 2016a).
At the same time, however, increasing importance is being attached to project organization. For example, a HAYS study (Rump et al. 2010, 4) comes to the conclusion that the procedural organization with formalized processes are increasingly proving to be an obstacle in view of current and expected developments in the economy. Much greater agility would necessitate project-based organizational structures.
Such comparisons of process management on the one hand and project management on the other suggest that one can easily be replaced by the other, i.e. that in principle both organiza-tional forms are suitable for carrying out all kinds of tasks or problems and only differ in their respective advantages and disadvantages. In addition, proponents of process management simply equalize differences between the two organizational forms by interpreting projects as processes. For example, Cooper describes his widely known product development process model as the Stage-Gate Process (2002/2010, 146), Jakoby explains that every project is a spe-cial problem-solving process (2010/2015, 1), and according to Burghard, the process also char-acterizes the actual procedure in the project (1988/2013, 19).
Given its dominance, thinking in processes can be described as a paradigm (Kuhn 1962/2001). An associated benefit is the exploitation of the full potential of this approach (Hoyningen-Huene 2010, 283), as the number of professionals who agree that it is truly an outstanding solution is large and, as a result, participate in research and application. A major drawback, however, is that not a task or problem determines the solution, but, conversely, that the solution that fits the paradigm is applied to all tasks or problems that appear to fit even in the paradig-matic pattern (ibid.). According to Kuhn, science does not view itself as a method-led search for the objectively best solution, as Descartes and Bacon propagated it above all (ibid.). Instead, science is essentially determined by history and, above all, the success of good marketing: Once a solution has been established, only problems are looked for that can be solved (apparently) in a nearly similar way.
Against this background, now the difficulty lies in the fact that the blending of the terms project and process corresponds to the prevailing paradigm, while the following explanations leave this paradigm in order to outline which potentials can be unlocked beyond the mainstream. The challenges that await the reader familiar with the prevailing paradigm, however, will be illus-trated by the use of technical terms. These are defined somewhat differently in the following, with the emphasis on both "somewhat" and "different". "Somewhat" means that what is to be understood by a process, for example, does not change fundamentally. In fact, the term only is narrower and its application is largely1 limited to routine activities. This sounds easier than it is. It would be really easy to introduce completely new terms and to completely abandon terms that are of central importance in the prevailing paradigm. A slightly different use of terms, in which the differences, quickly classified as insignificant, have a great effect, on the other hand, causes much greater communication problems.
Kuhn has described this as semantic incommensurability (Hoyningen-Huene 1990, 97 ff.). This term comes from geometry and describes the ratio of the lengths of two distances, which are incommensurable if they cannot be expressed as integer multiples of a common measured dis-tance. For example, the radius and circumference of a circle are incommensurable because they are linked by the irrational number π. Transferred to the terms of two different paradigms re-spectively the terms of one paradigm and those outside of it means that there is no common basis. Above all, the mentioned shift of the meaning of terms can remain superficially unno-ticed, although it contains central statements (Hoyningen-Huene 2010, 287). Against this back-ground, the following section will focus on the use of key terms such as task, problem, process, phase, consistency, etc.
2 Distinction between tasks and problems
The procedures accord-ing to which people com-plete tasks and solve problems are not inven-tions, but discoveries. Cognitive scientists such as Dewey (1910/ 1997) or Dörner (1976/ 1979) have derived these from the observation of intui-tive actions. The models that were developed from this are merely ra-tionalizations of the more or less pronounced intuitive competence of every human being to cope with everyday matters. Procedure models that deviate from these lead to application problems due to their counterintuitiveness.
The systematization of observations takes its starting point from behavior (Figure 1), which becomes action through an orientation towards a target (Funke 2003, 18). A target in turn de-scribes the difference between an existing situation and a desired one. Cognitive scientists call this difference a barrier. If the means for overcoming this barrier are known and available, they speak of tasks, if the means are unknown or not available, they are problems (Dörner 1976/1979, 19; Duncker 1935/1974, 1; Funke 2003, 25; Lüer/Spada 1990, 256).
Figure 2 illustrates the relationship be-tween problems and tasks. First, each non-trivial barrier poses a problem when it is first overcome. The aim is either to solve this problem finally or to transform it into a task that can then be performed repeatedly and routinely. This connection leads to the insight that problem solving and task accomplishment serve different purposes: Routine activities should bring about a flow equilibrium (homeostasis), problem solving a change (genesis).
For example, customer orders from a catalog are to be followed by regular punctual deliveries of all ordered items. To differentiate between tasks and problems, it is irrelevant that parameters such as article, price and delivery date differ from order to order within the given scope (e.g., quantity discounts). What matters is that orders are expected regularly, that each order triggers the same activities and that everything necessary to cope with them is known and available. Any deviation is an error and can lead to a customer not being satisfied. Simplifying one can state: Deviations are malfunctions.
In contrast, the development of a product, for example, is only required once per product. To differentiate between tasks and problems, it is irrelevant that certain phases, such as the identi-fication of requirements or the design, are repeated for each development project. What matters is that at the beginning it is not yet known how the product will look at the end and that it is not trivial to get there. If nothing new were to emerge in the course of development, the product would not have any unique selling points and would therefore be difficult to sell. For this, it has to be different from other products, especially from previous ones. Simplifying one can state: Deviations are necessary.
2.1 Continuity versus discontinuity
One reason for interruptions in the workflow are checks of intermediate results. The number and duration of such checks increase with increasing uncertainty (Patzak/Rattay 1995/2014, 19). In the course of routine activities, they can be limited due to sufficient safety and integrated into the workflow to such an extent that they do not significantly impair quasi-continuous pro-cessing. Up to this point, one can speak of a consistency of value-adding processing, as aimed at by process management. For example, the application of the Poka-Yoke principle, error avoidance or recognition through technical measures, possibly supplemented by a worker self-test, can very largely minimize the testing effort in many areas of industrial series and mass production. This fulfils a prerequisite for flow production, which in turn can be regarded as a prime example of a process in the sense intended here. Simplifying one can state: Interruptions can be avoided.
When it comes to solving problems, the uncertainty is naturally much greater than when it comes to completing tasks. Therefore, most audits do not only cover interim results, but also, for example, involve questions as far-reaching as whether it makes sense to continue the project at all. Furthermore, the examinations often first have to be developed themselves as well as the necessary methods and tools. After all, many more stakeholders are involved in such audits than in routine audits. As a rule, audits therefore inevitably lead to significant interruptions in the course of projects, which can even lead to the project being terminated. Simplifying one can state: Interruptions are obligatory.
2.2 Degree of automation
In view of frequent repetitions of the same or at least similar activities over a long period of time, investments in measures to identify, design, implement and maintain rules for the han-dling of business processes up to automation, for example with the aid of workflow manage-ment systems or business process management systems, pay off (Brocke/Rosemann 2010/2015). Proponents of process management such as Gaitanides (1983/2012, 7) are critical of the "information-technical Taylorism" associated with it, but cannot help admitting that the benefits cannot be ruled out in practical individual cases. Kieser (1992/2006, 99) confirms that such management doctrines, which he characterizes as simple, are indeed widespread today.
Problems, on the other hand, oppose the automation of their solution because they usually differ too much from each other, so that at best the corresponding measures pay for themselves in partial areas. Although computer programs have long been offered to support project manage-ment, their consistent use usually falls short of promises or expectations.
Ultimately, there is only a small inter-section between pro-ject and process man-agement, in which processes are also possible and mean-ingful in projects (Figure 3). In pro-jects, for example, in-voices have to be paid, which is similar in most companies, and several work processes such as checking for factual correctness by a specialist department, checking for arith-metical correctness by the accounting department, release by a superior department, posting, payment instruction and archiving, which are usually carried out on a division of labor basis. Moreover, the processing of vacation requests or the completion of business trips also belong to this category of procedures, which are not fundamentally differently steered in projects than in the context of the routine organization. In such cases, projects can often even fall back on already existing processes of routine organization. Whether such processes then still have to be called project processes, however, appears questionable.
The fact that the paradigmatic pressure to ultimately have to identify everything as a process, which even seems to be only rudimentary suitable for this, can also clearly overshoot the goal is shown, for example, by DIN Standard 69901-2:2009-01 on project management, when it describes the holding of a final meeting as a process (ibid., 48). Time does pass during such a meeting, and there is no doubt that various things have to be done with the presentation, dis-cussion and documentation of findings up to and including the publication of lessons learned. However, it is doubtful whether this really means what the proponents of the process organiza-tion originally imagined.
2.3 Sequence versus circularity
Due to the aim of designing processes consist-ently, these are usually modeled as successive activities. An equally simple and widespread type of notation is the arrow form (Gaitanides (1983/2012, 168). Figure 4 shows that the se-quence of activities is reduced to the particularly simple case of a linear sequence. A popular concretization of this notation can be found in Porter's model of the value chain (2000, 66).
The Swim Lane representation is also widely used, in which the process steps are assigned to the "swimming lanes" and organizational units displayed line-by-line (Gaitanides 1983/ 2012, 172) in order to include the organizational structure in addition to the process organization. Although the process in this notation traverses the organizational units, this, too, generally rep-resents a largely linear process flow.
Pure linearity is abandoned in more differentiated process models such as the event-driven process chains (EPC) (Allweyer 2005, 133 ff.), the Business Process Model and Notification (BPMN) (Freund/Rücker 2010/2014, 22 ff.) or the ibo follow-up plan (Fischermanns 2006/ 2013, 17 ff.). In partic-ular, they provide branches (OR sequences) and par-allelizations (AND sequences). However, the domi-nance of the sequence of activities remains. Although the authors also mention the possibility of loops (Freund/Rücker 2010/ 2014, 76 ff., 171) and re-bounds (Allweyer 2005, 134), Fischermanns (2006/2013, 241 ff.) as well as Freund und Rücker (2010/2014, 134 f.) expressly declare that the First Pass Yield (FPY: percentage of events that are cor-rect at the first pass and do not require rework) should be maximized. Loops or jumps should remain the ex-ception in processes.
The situation is completely different in projects. Thus the procedure model of the system’s engineering for problem solving (Haberfellner et al. 1976/2015, 72) is explicitly understood as a cycle according to Figure 5 (Ahrens 2014, 84). What should be an exception in process management becomes the rule here. This can be explained by the much greater uncertainty involved in solving problems compared to completing tasks. The necessity to include the unforeseen and to return to previous phases of problem solving or even to cancel the project (the latter is not shown in Figure 5) is unavoidable when solving problems that have not yet been solved. The hermeneutic circle (Ast 1808), which also provides for a cyclical procedure in order to enable a successive approach to the solution of a problem, forms the basis of epistemological theory.
2.4 Consistent approach versus consistent results
The diametrical nature of project and process also becomes clear when one considers what their respective regularity is. Tasks should always lead to structurally identical results, requests for quotations and finally to orders, holiday and travel applications for approvals or rejections, the assembly of gearboxes to functional gearboxes and so on. Here the regularity thus refers to the results. The required procedures, on the other hand, are always specific: the process of assem-bling a gearbox is fundamentally different from the preparation of an offer. Simplifying it can be stated: the results of processes are always largely the same, but the procedure is always different.
In the case of projects, the situation is exactly the other way round. While the results of two problem solutions differ significantly (otherwise they would be repetitions), the procedure for solving them is always approximately the same (Haberfellner et al. 1976/2015). The micro-cycle is always the problem-solving cycle as shown in Figure 5 (regardless of whether it is described in this way or in another way or whether it was specified with regard to certain areas of application). Furthermore, the macro-logic follows the life cycle of a product from planning through implementation and operation to disposal, and in addition, there is a whole series of design principles such as a procedure from rough to detailed. Altogether the systematics for the completion of projects is of course too complex to be explained here, nonetheless the aspects mentioned should be sufficient to make it clear that one can simplified say : with projects the procedures are always to a large extent the same, the results are however always different.
3 Complementarity of project and process
|Condition of interest||Genesis||Homeostasis|
|Degree of automation||low||high|
|Sequence of procedures||always (structurally) the same||always different|
|Results||always different||always (structurally) the same|
This can be confirmed by a system-theoretical view, which, thanks to its ideology-free system-atics, enables the extension of a paradigmatically limited field of vision (Ahrens 2017a, 10 ff).
- In the 1940s, Wiener (1948/1961) founded cybernetics, the system-theoretical sub-discipline dealing with homeostatic processes. This initially purely technical approach was sub-sequently adapted by very different scientific disciplines, including business administration. Beer (1972/1981) designed his well-known Viable Systems Model (VSM) on this basis at the beginning of the 1950s. This model inspired, among other things, the St. Gallen Man-agement Model (Ulrich 1968/2001) and Malik's management cybernetics (1984/2015, 24), which are still widely known and recognized today.
- At about the same time as cybernetics was being developed with regard to homeostatic processes, Systems Engineering (SE), which provides a process model as well as methods and techniques for the design (genesis) of complex systems, was created in large organiza-tions such as Bell Laboratories (Ropohl 1978/2009, 74; INCOSE 1994/2015, 12) and the National Aeronautics and Space Administration (NASA). Closely linked to this is project management (Haberfellner et al. 1976/2015, 31).
On the one hand, project and process have a common basis in systems theory; on the other hand, the two sub-disciplines cannot be brought together, nor reduced to one another. This also demonstrates the complementarity of the two organizational forms.
4 Potentials off the beaten track
If one leaves the comfort zone, which is undoubtedly offered by swimming in the mass of pro-ponents of process management, new potential opens up. These will certainly not trigger a rev-olution, as it has been proclaimed so often in other places (e.g. Womack/Jones/Ross 1991/1994; Braungart/McDonough 2008/2011; Bauernhansl et al. 2014), without having occurred subse-quently (Ahrens 2012, 30 f.). However, even small advances can offer a decisive competitive advantage, so that it is also worthwhile to look for new paths off the beaten track.
In the following, two aspects will be addressed: on the one hand, the control of processes and, on the other hand, the far-reaching, possibly too far-reaching simplification of reality associated with the process model.
4.1 Control versus regulation
Proponents of process management explain in unison that processes must be controlled (All-weyer 2005, 9; Fischermanns 2006/2013, 483; Freund/Rücker 2010/2014, 7; Gaitanides 1983/ 2012, 204; Knuppertz/Feddern 2011, 8; Nanz 2012, 210). Even Wagner and Patzak 2007/2015), who initially refer to the systems theory and thus inevitably identify regulation as the funda-mental model (ibid., 27), speak of a control of processes (ibid., 175 ff.).
According to cybernetic understanding, however, a control system represents an open chain of action. This means that the actual result of a process is not continuously checked to see whether it corresponds to the intended result. Deviations are therefore not always detected in time, in their entirety or even not at all. However, this type of control corresponds to the widespread understanding of processes, according to which processes are thought to be largely linear and, if possible, always forward-looking. In everyday life, this would correspond to a room heating system without a thermostat, so that if temperature fluctuations occur, for example by opening a window or changing sunlight, the persons present must themselves pay attention to the level of the temperature (measuring element) and ensure the desired room temperature (control path) by manually actuating the heating valve (actuator).
The fact that this type of temperature control is no longer common today can be seen as clear evidence that controlling business processes is just as outdated. Just as thermostatic valves have long been used almost exclusively in heated rooms to regulate room temperature automatically, business processes must and can also be regulated. To this end, the control system must be expanded by adding a measur-ing element and a control ele-ment to form a control loop as shown in Figure 6 (Ahrens 2016a). The measuring element then continuously returns the actual results, possibly influ-enced by faults, to a reference junction, where they are com-pared by the control element to a specification, the so-called Figure 6: Model of the control loop (regulation) reference variable, so as to counteract any differences found between the nominal and actual values in the next run by suitable measures. Only in this way can homeostasis be reliably maintained. Actually, the knowledge about this has been known for a long time and is, for example, an integral part of the REFA methodology (REFA 1991, 39 ff.), but with the advent of the process paradigm, it seems to have been lost.
Regulations can be found everywhere, in machines (Zacher/Reuter 1972/2014) as well as in organisms (Maturana 1982, 35) and organizations (Mirow 2005, 39 ff.; Wagner/Patzak 2007/2015, 27; Willke 1982/2006, 132 ff.). This generalizability is important because the model used here would allow objections such as those of Gaitanides (1983/2012, 2 f.) to be too mech-anistic for application to organizations. However, it would go too far here to link this technical model with a sociological model. That such a link is not only necessary, but also possible, can be shown, for example, on the basis of the AGIL scheme of Parsons (Ahrens 2016b, 3 ff.).
4.2 Process management versus network management
Corsten and Gössinger (2001/2008), referring to numerous sources, explain that relationships between individuals and organizations usually take the form of networks. This is confirmed by an unbiased view of reality. For example, the Supply Chain Management cited by the two au-thors shows that business relationships are not only linear and independent, but often have nu-merous cross-references: Suppliers can be customers or competitors at the same time; they can supply each other and so on. The metaphor of the chain, on the other hand, suggests supply relationships that are lined up linearly without cross-references, similar to process thinking which is based on the metaphor of flow (Klaas 2002, 43), for example the flow of a liquid through a pipeline.
Processes merely represent a special case of networks and thus abstract very largely from real-ity. Abstraction as such is by no means to be evaluated negatively. On the contrary: from a constructivist point of view, every human perception is an abstraction, it is the assignment of meaning to neuronal processes that are in themselves meaningless, it is construction and inter-pretation (Roth 1986, 170). Without abstraction, it would simply be impossible to cope with the complexity of reality (Luhmann 1984/1996, 70 ff.; Stachowiak 1973). However, with Einstein's well-known proposition that everything should be made as simple as possible - but not simpler - it can be argued that the reduction of networks to largely linear processes is too far-reaching an abstraction. If one follows this assessment, one will have to further develop theories, meth-ods and tools with the help of which networks can be mastered better than before.
Some sources already mention the need for network management, such as Corsten and Gössin-ger (2001/2008). How much, however, the paradigm of process thinking can filter the view of reality, can be shown by the quality standard DIN EN ISO 9001:2015-11. On the one hand, the standard constantly emphasizes the necessity of process orientation in the sense explained above. On the other hand, however, it also goes beyond this by demanding in Chapter 4.4.1 that, in addition to processes, their interactions be designed and controlled. If, however, pro-cesses and their interactions are combined, a network is created. However, to consistently de-scribe this as such would contradict the paradigm. Now this is a standard that has to document the state of the art. It emerges from compromises between different stakeholder groups and contains no more than the lowest common denominator. On the other hand, science and practice should seek ways to overcome the state of the art, i.e. paradigms, in order to gain a competitive edge.
5 Relationship between project and process
Figure 7 now shows how the two process models for problem solving and routine task comple-tion are related. The so-called product life cycle serves as a connecting bracket, whereby the term product generally refers to everything that is produced by human beings. Every product is created with the idea for it and with the intention to realize this idea. Then the product must first be created, which requires a problem solution, which is to be brought about after the prob-lem solution cycle (Figure 5). With the transition into the use of the product, a change of the procedure model takes place to the control loop (Figure 6), because now it applies to maintain-ing the use over a long period. A product is to be sold e.g. as long as possible, in order to compensate the investment costs and to gain if possible beyond that a profit. However, the service life of a product cannot usually be maintained indefinitely. This leads either to the prod-uct having to be withdrawn from the market or to a new or further development, whereby the product life cycle can close to a circle. With regard to the corresponding procedural models, this means that the control loop can finally be converted back into a problem-solving cycle.
The circular character of the product life cycle has been taken up by the so-called PDCA cycle (also known as the Deming2 cycle) accord-ing to Figure 8. However, this model is often misunder-stood (Ahrens 2016c). The letters of the abbreviation mean Plan - Do - Check - Act and designate four phases. The first three roughly outline the procedure for solving a problem, while the fourth phase describes the application of problem solving, i.e. the completion of tasks. Thus, the PDCA cycle corresponds to the product life cycle and thus represents a meta-model to which the partial models of the problem solving cycle and the control loop can be assigned.
The PDCA cycle is often used to describe the continuous improvement3 (kaizen) that has es-tablished itself with the advent of the Toyota Production System (Liker 2009), also known as Lean Production. Here, however, this will be demonstrated using Figure 9 on the basis of the two partial models: Problems can also arise in the course of carrying out tasks. These problems must then be solved by working through the problem-solving cycle in parallel with ongoing routine operations. The solutions found in this way must then be incorporated into the running operation. Here, too, however, a clear distinction must be made between the two types of action: while the ongoing operation must con-tinue to be maintained on the basis of control loops, problem solutions must be developed in parallel after the prob-lem-solving cycle.
The art of continuous improvement is in this respect to incorporate changes to the control loop that are required as a result of problem solving into the running operation, because this brings with it a destabilization that is the core task of each regulation to absorb. Con-trol loops are resistant to change. This is why change management is such a major challenge (Lauer 2010/2014).
6 What to do
Finally, what needs to be done will be outlined for three fields of action: Research, teaching and practice. Practice is the starting point, because concrete problems arise here, for the solution of which the potential of the process paradigm seems to have been largely exhausted. Although the previous successes of process management should not be underestimated at all, an increase in organizational productivity, quality and innovative ability that goes beyond what has been achieved to date is now obviously reaching its limits.
Fischermanns and Völpel (2006, 289), for example, observed 15 years after the widespread introduction of process management that although companies are always quick to come up with solutions, they also model them well, often without achieving the hoped-for effects. 20 years after its introduction, almost two thirds of all companies surveyed in a study by Minonne (2011) stated that there had been little more than a general awareness of process management and that at most individual aspects of this approach had been addressed. Only one third of the companies stated that they had already introduced certain process management methods, and only about 7% of the companies surveyed showed consistent implementation of process management. At the same time, Knuppertz and Feddern (2011, 4 f.) observed very concrete problems when try-ing to implement process management effectively:
- Many companies, for example, would take upcoming certifications of quality management systems as an opportunity to describe the processes required by DIN EN ISO 9001 and even assign initial process responsibilities, but these would initially be limited to the provision of process documentation. After successful certification, the documents would then quickly be placed back into the filing cabinet only to be retrieved again for the next certification and then in an outdated form.
- Furthermore, impulses for process modelling would also occasionally emanate from IT departments, for example, when new IT systems had to be introduced, which often went hand in hand with the necessity to adapt working methods to the standards specified by these systems. Even in such cases, however, the discussion of processes is rather of a short-term nature.
- After all, companies would optimize processes that have proven critical, for example due to quality problems or efficiency deficits. Although powerful methods such as Six Sigma can be used to achieve improvements, the processes are often left to their own devices after the optimization projects have been completed, so that progress is not sustainable.
It will be attributable to the focusing effect of the paradigm that such observations do not lead to the conclusion that something could be wrong with the solution approach, but that the blame for the inadequately perceived implementation lies with the users: Optimization teams would not sufficiently deal with the underlying causes of process weaknesses and would not take the resistance of those affected seriously enough in implementation (Fischermanns/Völpel 2006, 289) or would simply not be sufficiently informed (Minonne et al. 2012). In fact, it requires a liberation from the paradigmatic constraints of exclusive process thinking and a solution-neu-tral, problem-induced approach in order to come up with the idea that expanding approaches such as those of regulation and network thinking can possibly continue and that, in particular, a diversity of methods is required in order to do justice to the diversity of problems.
Research must provide the basis for this. The transfer of engineering control to business organ-ization concepts has so far not gone beyond isolated approaches (e.g. REFA 1991, 45; Peter-mann 1995; Pawellek 2007, 114 ff.). The situation is similar with the development of methods and tools for controlling networks (e.g. Corsten/Gössinger 2001/2008).
Finally, it is also possible and necessary in teaching to go beyond the status quo. To this end, for example, the previous thematic boundaries, which have often evolved historically, can be rearranged. Thus, it is still part of the self-explanation of logistics today that it is a cross-cutting topic that overlaps with many other topics. The historical origin of the transfer of this field of activity to industry, which in the last millennia has been mainly dominated by the military, is explained in particular by the change from seller's to buyer's markets in view of a transition from pent-up demand as a result of the Second World War to replacement demand against the background of largely saturated markets at the beginning of the 1970s (Merkel/Heymans 2003, 4 ff.).
This ad-hoc adaptation of military logistics by industry was, from a pragmatic point of view, undoubtedly helpful at first to counter the sudden sales problems that arose with additional services such as shorter delivery times. However, there is no discernible reason to stick to such a solution for all eternity, especially if it entails disadvantages such as overlapping with other topics as in the case of logistics. Avoiding such disadvantages requires a lot of coordination between the teachers and does not even lead to success in view of the constitutionally anchored freedom of teaching at colleges and universities. In addition, it will soon become apparent that a systematic approach to specific topics opens up interesting perspectives.
For example, thematic areas could also be identified by the distinction between creative and managerial fields of activity, which has become the focus of attention here. This would bring the required methods and tools into focus, which seems quite attractive with regard to the in-tended teaching of methodological competence (problem-solving competence).
If, for example, everything that is necessary for the design of systems is grouped together in a thematic block, it can be seen that certain problems, the solution of which has hitherto been taught in different subjects, are not as different as the allocation in different subjects suggests. This includes the optimal arrangement of locations: in logistics, this is treated as location plan-ning, for example to determine warehouse locations; in factory planning, it is about the arrange-ment of machines and plants; in ergonomics, it is about the arrangement of tools and materials in a person's workspace. Looking at these problems from a systematic perspective, it can be seen that the differences relate primarily to the dimensions: while logistics is calculated in kil-ometers, factory planning is about the order of meters and ergonomics about the order of cen-timeters. Apart from that, however, the problems to be solved are relatively similar. Further-more, this also applies to other problems such as route planning (logistics), material flow opti-mization (factory planning) and the motion sequences of human limbs (ergonomics).
Each historically evolved subject area has so far produced its own methods and tools: for ex-ample, the Warehouse Location Problem (WLP) (Kuehn/Hamburger 1963) for the optimization of locations in logistics, in factory planning arrangement procedures such as that of Schmigalla (1968) and in ergonomics there are ergonomic methods from the repertoire of REFA (1991) and MTM (Bokranz/Landau 2006/2012). Systematizing these will also be a task for research.
As useful as paradigms may be in exploiting the potential of the solutions they encompass, they stand in the way of innovation. In view of the process orientation that has prevailed for almost three decades now, it therefore seems high time to take a look beyond this paradigmatic plate.
Such a view can lead to the insight that one does not have to do everything differently, but can do some things better. This includes a clearer separation between tasks and problems as well as consequently a clearer separation of the methods and tools required for their respective solution, which are in a complementary relationship to each other. This also includes the expansion of controls into regulations and an expansion of process thinking into thinking in networks. Prac-tice, research and teaching are equally affected by this.
Ahrens, V. 2012: Inflation industrieller Revolutionen. PRODUCTIVITY Management 17 (2012) No. 5, pp. 30-31.
Ahrens, V. 2014: Abschlussarbeiten richtig gliedern in Naturwissenschaften, Technik und Wirtschaft. v/d|f-Hochschulverlag, Zürich (UTB, Stuttgart).
Ahrens, V. 2016a: Prozessorientiertes Qualitätsmanagement nach DIN EN ISO 9001:2015. Arbeitspapiere der NORDAKADEMIE, No. 2016-02. Elmshorn.
Ahrens, V. 2016b: Systemisches Controlling. In: SEM|RADAR – Zeitschrift für Systemdenken und Entscheidungsfindung im Management. 15. Jg., H. 1, S. 3-28.
Ahrens, V. 2016c: Interpretation des PDCA-Zyklus nach DIN EN ISO 9001:2015 als Meta-Vorgehensmodell. Arbeitspapiere der NORDAKADEMIE, No. 2016-01. Elmshorn.
Ahrens, V. 2017a: Systemtheorie – Wissenschaftliche Grundlage des Wirtschaftsingenieurwesens. technologie & management, 01/2017, S. 10-18.
Ahrens, V. 2017b: Zur Komplementarität von Projekt und Prozess. In: SEM|RADAR – Zeitschrift für Systemdenken und Entscheidungsfindung im Management. 16, Vol. 1, pp. 3-32.
Allweyer, 2005: Geschäftsprozessmanagement – Strategie, Entwurf, Implementierung, Controlling. W3L Verlag, Herdecke/Bochum. Ast, F. 1808: Grundlinien der Grammatik, Hermeneutik und Kritik. Landshut.
Bauernhansl, T./ten Hompel, M./Vogel-Heuser, B. (ed.) 2014: Industrie 4.0 in Produktion, Automatisierung und Logistik – Anwendung, Technologien, Migration. Springer Vieweg Verlag, Wiesbaden.
Becker, J./Probandt, W./Vering, O. 2012: Grundsätze ordnungsgemäßer Modellierung – Konzeption und Praxisbeispiel für ein effizientes Prozessmanagement. Springer Gabler Ver-lag, Berlin/Heidelberg.
Beer, S. 1972: Brain of the Firm. John Wiley & Sons, Chichester. 2nd ed. 1981.
Bokranz, R./Landau, K. 2006: Handbuch Industrial Engineering – Produktivitätsmanagement mit MTM. Verlag Schäffer Poeschel, Stuttgart. 2nd ed. 2012.
Braungart, M./McDonough, W. (ed.) 2008: Die nächste industrielle Revolution – Die Cradle to Cradle-Community. Europäische Verlagsanstalt, 3rd ed. 2011.
Brocke, J. v./Rosemann, M. 2010: Handbook on Business Process Management 1 – Introduction, Methods, and Information Systems. Springer Verlag, Berlin/Heidelberg. 2nd ed. 2015.
Burghardt, M. 1988: Einführung in Projektmanagement – Definition, Planung, Kontrolle, Abschluss. Publics Publishing, Erlangen. 6th ed. 2013.
Cooper, R. G. 2002: Top oder Flop in der Produktentwicklung. Wiley-VCH Verlag, Weinheim. 2nd ed. 2010.
Corsten, H./Gössinger, R. 2001: Einführung in das Supply Chain Management. Oldenbourg Verlag, München/Wien. 2nd ed. 2008.
Dewey, J. 1910: How we think. Dover Publications, Mineola (NY) 1997.
Dörner, D. 1976: Problemlösen als Informationsverarbeitung. Verlag W. Kohlhammer, Stuttgart et al. 2nd ed. 1979.
Duncker, K. 1935: Zur Psychologie des produktiven Denkens. Springer Verlag, Berlin et al. 3rd ed. 1974.
Gaitanides, M. 1983: Prozessorganisation – Entwicklung, Ansätze und Programme des Managements von Geschäftsprozessen. Verlag Franz Vahlen, München. 3rd ed. 2012.
Geirhos, M. 2011: IT-Projektmanagement – Was wirklich funktioniert – und was nicht. Rheinwerk Verlag, Bonn. 2nd ed. 2017.
Fischermanns, G. 2006: Praxishandbuch Prozessmanagement. Schmidt Verlag, Wettenberg. 11th ed. 2013.
Fischermanns, G./Völkl, M. 2006: Der Reifegrad des Prozessmanagements. ZFO – Zeitschrift für Führung und Organisation, 5/2006, 75, pp. 284-290.
Freund, J./Rücker, B. 2010: Praxishandbuch BPMN 2.0. Hanser Verlag, München. 4th ed. 2014.
Funke, J. 2003: Problemlösendes Denken. Kohlhammer Verlag, Stuttgart.
Haberfellner, R./Weck, O. d./Fricke, E./Vössner, S. (ed.) 1976: Systems Engineering – Grundlagen und Anwendung. orell füssli Verlag, Zürich. 13th ed. 2015.
Hammer, M./Champy, J. 1993: Business Reengineering – Die Radikalkur für das Unternehmen. Campus Verlag, Frankfurt a. M./New York. 7th ed. 2003.
Hoyningen-Huene, P. 1990: Inkommensurabilität bei Kuhn und Theorievergleich. In: Agazzi, E. (ed.): Die Vergleichbarkeit wissenschaftlicher Theorien. Universitätsverlag Freiburg. pp. 97-108.
Hoyningen-Huene, P. 2010: Paradigma. In: Bermes, C./Dierse, U. (ed.): Schlüsselbegriffe der Philosophiegeschichte des 20. Jahrhunderts. Felix Meiner Verlag, Hamburg. pp. 279-291.
INCOSE: Walden, D. D./Roedler, G. J./Forsberg, K. J./Hamelin, R. D./Shortell, T. M. 1994: Systems Engineering Handbook – A Guide for System Life Cycle Processes and Activi-ties. Wiley, Hoboken. 4th ed. 2015.
Jakoby, W. 2010: Projektmanagement für Ingenieure – Ein praxisnahes Lehrbuch für den systematischen Projekterfolg. Springer Vieweg Verlag, Wiesbaden. 3rd ed. 2015.
Jochem, R./Landgraf, K. 2010: Die Prozessorganisation. In: Jochem, R./Mertins, K./Knothe, T. (ed.): Prozessmanagement – Strategien, Methoden, Umsetzung. Symposion Verlag, Düs-seldorf. pp. 55-75.
Kieser, A. 1992: Managementlehre und Taylorismus. In: Kieser, A./Ebers, M. (ed.): Organisationstheorien. Kohlhammer Verlag, Stuttgart. 6th ed. 2006. pp. 93-132.
Klaas, T. 2002: Logistik-Organisation – Ein konfigurationstheoretischer Ansatz zur logistikorientierten Organisationsgestaltung. Deutscher Universitäts-Verlag, Wiesbaden.
Knuppertz, T./Feddern, U. 2011: Prozessorientierte Unternehmensführung – Prozessmanagement ganzheitlich einführen und verankern, Schäffer-Poeschel-Verlag, Stuttgart.
Kuehn, A. A./Hamburger, M. J. 1963: A heuristic program for locating warehouses. Management Science, Vol. 9, pp. 643-666.
Kuhn, T. S. 1962: Die Struktur wissenschaftlicher Revolutionen. Suhrkamp Verlag, Frankfurt am Main. 24th ed. 2001.
Lauer, T. 2010: Change-Management – Grundlagen und Erfolgsfaktoren. Springer Gabler Verlag, Berlin/Heidelberg. 2nd ed. 2014.
Liker, J. K. 2009: Der Toyota Weg – 14 Managementprinzipien des weltweit erfolgreichsten Automobilkonzerns. 6th ed. FinanzBuch Verlag, München.
Luhmann, N. 1984: Soziale Systeme – Grundriß einer allgemeinen Theorie. Suhrkamp-Verlag, Frankfurt a. M. 6th ed. 1996.
Lüer, G./Spada, H. 1990: Denken und Problemlösen. In: Spada, G. (Ed.): Lehrbuch Allgemeine Psychologie. Hans Huber Verlag, Bern. pp. 189-280.
Malik, F. 1984: Strategie des Managements komplexer Systeme. Haupt-Verlag, Bern. 11th ed. 2015.
Maturana, U. 1982: Erkennen – Die Organisation und Verkörperung von Wirklichkeit. Vieweg-Verlag, Braunschweig/Wiesbaden.
Merkel, H./Heymans, J. 2003: Logistik als Koordinationsaufgabe in unternehmensübergreifenden Versorgungsketten. In: Merkel, H., Bjelicic, B.: Logistik und Verkehrswirtschaft im Wandel. Vahlen Verlag, München. pp. 3-19.
Minonne, C./Colicchio, C./Litzke, M./Keller, T. 2011: Business Process Management 2011 – Status quo und Zukunft: Eine empirische Studie im deutschsprachigen Europa, v/d|f-Hochschulverlag, Zürich.
Minonne, C. 2012: Gibt es eine Alternative zum Prozessmanagement? In: Wissensmanagement 3/2012, pp. 32-33.
Mirow, M. 2005: Wie praktisch ist eine gute Theorie? Thesen zur Umsetzung systemischen Denkens in der Gestaltung von Führungsstrukturen. In: Krieg, W./Galler, K./Stadelmann, P. (ed.): Richtiges und gutes Management – vom System zur Praxis. Festschrift für Fre-dmund Malik. Haupt Verlag, Bern u. a.
Nanz, G. 2012: Prozess-Alignment, in: ZFO – Zeitschrift Führung und Organisation 03/2012 81, pp. 210-212.
Patzak, G./Rattay, G. 1995: Projektmanagement – Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen. Linde Verlag, Wien. 6th ed. 2014.
Pawellek, G. 2007: Produktionslogistik – Planung, Steuerung, Controlling, Hanser-Verlag, München.
Petermann, D. 1995: Modellbasierte Produktionsregelung. Fortschritt-Berichte VDI 20, Vol. 193, VDI-Verlag, Düsseldorf.
RFFA 1991: Methodenlehre der Betriebsorganisation – Planung und Steuerung, Part 1. Hanser-Verlag, München.
Ropohl 1978: Allgemeine Technologie – Eine Systemtheorie der Technik. Universitätsverlag Karlsruhe. 3rd ed. 2009.
Rump, J./Schabel, F./Alich, D./Groh, S. 2010: Betriebliche Projektwirtschaft – Eine Vermes-sung. Eine empirische Studie des Instituts für Beschäftigung und Employability (IBE) im Auftrag von HAYS. Mannheim.
Roth, G. 1986: Selbstorganisation – Selbsterhaltung – Selbstreferentialität: Prinzipien der Organisation der Lebewesen und ihre Folgen für die Beziehung zwischen Organismus und Umwelt. In: Dress, A./Hendrichs, H./Küppers, G. (ed.): Selbstorganisation – Die Entste-hung von Ordnung in Natur und Gesellschaft. Piper Verlag, München/Zürich.
Sell, R./Schimweg, R. 1988: Probleme lösen – In komplexen Zusammenhängen denken. Springer Verlag, Berlin/Heidelberg/New York. 6th ed. 2002.
Schmigalla, H. 1968: Methoden zur optimalen Maschinenanordnung. VEB Verlag Technik, Berlin.
Stachowiak, H. 1973: Allgemeine Modelltheorie. Wien et al.
Ulrich, H. 1968: Die Unternehmung als produktives soziales System. Haupt-Verlag, Bern u. a. 2nd ed. 2001.
Wagner, K. W./Patzak, G. 2007: Performance Excellence – Der Praxisleitfaden zum effektiven Prozessmanagement, Carl Hanser Verlag, München. 2nd ed. 2015.
Wiener, N. 1948: Cybernetics or Control and Communication in the Animal and the Machine. Cambridge, MH. MIT-Press. 2nd ed. 1961.
Willke, H. 1982: Systemtheorie I – Grundlagen. Lucius & Lucius-Verlag (UTB), Stuttgart. 7th ed. 2006.
Womack, J. P./Jones, D. T./ Ross, D. 1991: Die zweite Revolution in der Automobilindustrie – Konsequenzen aus der weltweiten Studie des Massachusetts Institute of Technology. 8th ed. 1994.
Zacher, S./Reuter, M. 1972: Regelungstechnik für Ingenieure – Analyse, Simulation und Entwurf von Regelkreisen. Springer Vieweg, Wiesbaden. 14th ed. 2014.