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.

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.

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.

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.

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.

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.

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.

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.

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.).

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.

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 improvement