Helmut
This also makes much more sense to me. It sounds as though you don't like the "transformation" definition either - or at least you don't try to justify it. It is interesting that your choice for the "input" is different from what I have seen others define as the input, ie the "customer need" or the "customer order".
I think subscribe to a "transformation" definition, though maybe we have different connotations of that word. A simpler definition is "A core process takes "something," and does something to it, and the resulting output has more value than before.
The coffee example takes coffee beans and water, and makes a tasty beverage which sells for $1.00. The next operation make take that nice basic beverage and add a bunch of extra silly ingredients, resulting (output) in a highly over developed designer beverage, and sell it to the customer for $4.50. If the customer has extra specifications, they have a more expensive product, but it meets their perceived needs.
When we discuss "core" or "Customer Oriented" processes, this relationship between inputs and outputs should be pretty clear and obvious. The rest of the details fall into the various Tools categories you mentioned.
However, when we discuss "non-core" or "Supporting" processes, like Training, Calibration, etc., the input/output conversation can be less clear. When working with a team of folks, I add another question to clarify the output concept.
For Training, the discussion would be as follows. OK, Training is an internal support process. In other words, Training is a service (product) provided b the HR Dept. OK, what is the result we expect to get? What is the product of that activity? What is the output? The answer is usually "trained, competent, people with proficient skills." OK, then
"trained, competent, people with proficient skills" is the
output of that Training process. Then it stands to reason the
input was
"UN-trained, NOT-competent, people with certain undeveloped skills."
I find groups of managers and regular folks have a much easier time developing it when this approach is clear.
I like the idea of "tools" ("resources"?), and of treating them as "things you need to have available for the process to work". Staff would also belong in this category (a product of the Recruitment and Training processes?).
Yes, but bear in mind, these tools probably were the result of an earlier process (Training, Purchasing, Process Designing, etc.)
But the bottom line is that I believe that all this would be unnecessary if we used a more intuitive definition, such as "a sequence of activities triggered by an event and designed to achieve an objective. It uses resources and is subject to influences." The "product" is the achieved objective. This works for a higher level process and also scales down to the individual task level. So the receipt of a customer order triggers the order processing process, and a New Customer form arriving in someone's Intray triggers the task to set up a new customer on the computer.
You may add and modify the "official" definition all you want internally. A good teacher always adds insight to the material, and tailors it to the needs of the student. But, don't lose the link to the original definition, because I don't think it is so far off. It just can be phrased better.
In the examples I sited above, the customer order "trigger" would be the
input to the Sales/Contract Review/CSR Process (whatever the heck we are calling it nowadays). The
output would be the processed order information on the form or ERP database. This information and order is the product we pay the Sales people for. And the effectiveness (cl 4.1.c) is judged by whether the information is complete and accurate, and in my opinion, whether they get enough of these transactions. Then, the next process - Engineering/
APQP - takes this information and fashions a product and process to meet these needs/requirements.
It is very easy to "map" this just scribbling a half dozen circles on the whiteboard. The class sees the concept, then they begin to develop each one. All the rest of the activities tend to fall into the "Support Process" categories.
Focussing on objectives is one of the key concepts which the ISO definition misses, and is vital for seeing how the business processes help to achieve the overall business strategy.
No, not at all. in my view, ISO is very focused on effective results from each process. In other words, effective outputs from each process, which then become effective inputs for the next INTERNAL customer - the next process in the chain. The failure is that everyone steps right over 4.1.c and jumps right to 4.1.e. They measure "stuff (4.1.e)," when they haven't even defined and documented what "stuff" is important (4.1.c).
Imagine inspecting a part to a blueprint that does not define what the acceptance criteria shall be. Well, why do we evaluate (inspect) processes to criteria that has not been defined (4.1.c).
And we wouldn't need to debate what is an input, what is or isn't "transformed"...
I think my approach reduces much of this to a comfortable discussion.
Going back to the original theme of this thread - the way the processes interact is to do with how you make the required resources available, and how you manage the factors that can influence a process (such as compliance with external standards). I have never seen the point on drawing a picture to say that "we sell something then we make it then we check it then we deliver it then we invoice it" - everyone knows that!
