Organisations characterise also on the use and abuse of Processes. While some tend to prefer quick (and sometimes dirty) execution, others put a strong accent on the tools and coding of rigorous procedures...
In my working career I made experience of both, finding out the reasonable balance is very hard to be achieved. Of course when you are under pressure for example in a field test, thinking about having a process for changing settings that involves more than simply a couple of clicks, cannot work. On the other hand, in a long term R&D, you should avoid making fundamental decisions without a significant consultation.
Is there an optimum valid for all the cases? I am of the opinion that optimum can only be driven by common sense and self criticism: re-assessing the effectiveness of a process and of its approach should be a cyclic exercise. If it is detected it is quick, but it is causing too many failures, some more intelligent checks shall be applied. In the opposite direction, if a process is slowing down critical executions, the risk of mistakes must be mitigated perhaps with more frequent but less time consuming analysis of specific relevant parameters...
Coming then from the opposite directions, the tendency I would see is to avoid falling in love with what has been implemented. It is rather worth to have a process able to monitor the other processes where the result is simply: OK or NOT OK.
From there the medicine can be drops of creativity, pills of rigour and a constant use of common sense...
Nessun commento:
Posta un commento