Recently, everybody seems to be talking about; “process improvement,” “process design,“ “process maturity, “ and so on. But what IS a process? The term has a similar depth and ambiguity as to the idea of an “object.” The ISO 9000:2000 standard defines a process as “a set of interrelated or interacting activities which transform inputs into outputs.” For an IT specialist, it still appears unclear: what is “interrelation” and how do activities “interact?” Why would one deal with “processes” at all? Does that concern our project?
It sounds like we should handle this issue with caution. Many attempts to standardize software project processes ended up in massive folders in locked cabinets – and many of us indeed have bad memories of that. The term “process” alone frequently induces the fear of everybody soon being annoyed with excessive (and useless) formalities, complicated workflow definitions, and generally annoying and wasteful overhead.
A computer scientist may feel tempted to think of processes like UML activity diagrams with object flows. In this context, the world consists of algorithms and data structures; they just need to be modeled: algorithms as activities, results, and inputs as data. However, it doesn’t answer the question about the general purpose of the „process.”
We prefer viewing processes pragmatically. As process consultants, we work with processes in the context of commercial organizations. Thus, processes may be considered to be parts of the value-added chain. It seems only logical since business enterprises have commercial goals.
From this point of view, processes would be just chains of value-adding activities on the way to creating a positive cash flow for the organization as a whole. At each stage, the aim is to „improve” the entire value-added chain. Besides, we should be careful when using certain words: the term „chain“ suggests that a process resembles a deterministic-linear sequence. However, from our experience, we can tell that this is not always the case because decisions, parallelisms, and other characteristics lead to bypasses and shortcuts.
Thus, a helpful definition seems to follow: a process is a directed graph consisting of activities, transitions, and work objects. The activities must work with tools and resources to produce new or more valuable results. A goal of a process is to create a product that can be sold at a profit.
Let’s start a conversation on LinkedIn or X.com (formerly Twitter).
The concept of “project” is a Holy Grail of organizational change that heralds The New. Projects inherently come with risk and uncertainty. In the corporate world, risk aversion is an instinct that foregoes venturing into uncharted territories of product innovation. Taking project risks too lightly may lead to unintended consequences for the project or the entire company. Read…
At first sight, the task appears easy: capture the business processes, visualize them in an easy-to-understand form, and use them as a basis for quality or efficiency improvement projects. This goal may seem trivial to Read…
Is it possible to be agile in a complex, real-time, embedded environment? How does it jive with the heavily regulated, ISO 15504/CMMI, product safety-oriented processes increasingly demanded by the OEMs? In my presentation at the embedded world conference in February 2012, I have argued that the difference between ‘agile’ and ‘rational, controlled’ project organizations is in fact an age-old misunderstanding in terms. Read…
Be the first to comment