Part I and part II.
In the last part, I wrote that this part would be about processes and strategy. However, let me make a small change and first address the modeling of an organization, based on the process approach, before relating processes to strategy.
4. Modelling an organization – mapping processes
ISO 9001:2015 clause 4.4.1 states that an:
Organization shall determine the processes needed for a quality management system.
How can that be done?
We need to develop a model of how the organization works having as its building blocks what we call processes.
4.1 What is a model?
“A model is an external and explicit representation of part of reality, as seen by people who want to use the model to understand, to change, to manage and control that part of reality”
Michael Pidd in “Tools for thinking - Modeling in Management Science”
Remember, we don't draw a model to answer ISO 9001:2015 requirements, and please auditors. We draw them because we want to understand, to change, to manage, and control our organization's present and future.
Models are always a simplification and an approximate representation of some aspects of reality, models reduce complexity, simplify the original or the future to be built, to reduce the noise produced by reality, and thus highlight, distinguish the critical factors, for the object of study concerned. The model does not show all the attributes of the original, it only illustrates those attributes that are relevant, or suitable for the observer/creator/user of the model to manipulate. Models do not need to be accurate to be useful, models are simplifications, and their usefulness lies precisely in that approach.
The task of the observer/creator/user of the model is to collect the visions, the perceptions, even if ill-defined and implicit of reality, and to shape them in a sufficiently well-defined way to be understood and discussed by other people. A model is a representation of reality.
With Deming I learned:
All models are wrong, some are useful!
The reality is composed of a set of objects that constitute a system, at a conceptual level we design a model capable of illustrating the system, the reality. Armed with the model as a work unit, we can perform simulations to perceive reality and influence it, the simulation uses the model to perceive and anticipate the dynamics and behavior of the system.
4.2 Modeling an organization as a set of processes
To build a model of an organization, it is necessary to have a clear definition of its purpose, now an organization exists only because there are customers, they are its raison d'être!
An organization, the organization object of our study, is an entity, it is a system, which transforms, that converts “potential customers with needs” into “customers served”.
4.2.1 Step 1 - Identify the different types of customers
Customers are not all the same, it is possible to identify and isolate different types of customers, this activity is important because different types of customers may require, different processes and may mobilize different actors, may involve different inputs and different outputs.
4.2.2 Step 2 - List the inputs and outputs of the model
Distinguish the different states of the customers and identify all interactions (inputs and outputs) between the organization and its customers! How do we get in contact with potential customers? How do we collect information to develop new products and services? How do we receive orders or requests for proposals? How do we deliver our products and services?
4.2.3 Step 3 – Determine the core, the heart of the model
Let us track the route, from inputs into outputs. Let us zoom in on the organization. Let us open the black box!
For the purposes of this blogpost, we select a certain type of customers and then start to dive inside the organization (for someone implementing a quality management system for certification, this could be a management system scope option)
I gather a set of people that know the organization, each from a different perspective and give them sticky notes and markers. Then, I post two sticky notes that represent the responsible for major input in the system and the receiver of the major output of the system.
I ask; what actions, what activities do you do when going from one extreme into the other? People use sticky notes to write things that they remember. I set a rule: one sticky note must have one verb and one noun like “Receive Request For Proposal”, like “Write Proposal”, like “Budget Proposal”, like “Present proposal”, like “Negotiate proposal”.
After that kind of brainstorming one can start to aggregate sticky notes that belong to a flow of activities. For example, I can replace these 5 sticky notes above by saying that they belong to the same process called “Win order”. Repeating the technique for other sticky notes we develop the central sequence of processes.
When designing the road from the inputs into the outputs, do not dive into to much detail!
Let us look at a high level of abstraction and consider 3 to 6 entities (each entity represents a process, a set of activities) And let's number the processes sequentially!
We can do a mental exercise: "If we were riding an order, what would we see from the reception to its delivery?" Do not register departments or functions, but state changes, the main tasks! ”
4.2.4 Step 4 – Name each process
Designate each entity (each process)! Start with a verb that illustrates the transformation that takes place inside! Avoid references to departments, to avoid confusion remember:
- processes are not departments,
- the organization chart is not a process map,
- the vertical and horizontal views of an organization are very different.
I like to designate a process by relating its name to the main output of that process.
While certain processes seem to be clearly determined, based on a physical flow (production, logistics, distribution, transport) or a flow of information (design/development, closing accounts, invoicing, payment), certain activities of an administrative nature seem difficult to integrate into a “process” view.
There may then be a strong temptation to group them by function analogy and to baptize these groupings as “human resource process” (in which recruitment, training, communication, payment of wages, contract management will be mixed) work, social dialogue, without the slightest logical link or the tangible outputs that characterize such a process appearing), “accounting and financial process”, etc. Performing more or less arbitrary functional groupings is of no interest from the point of view of process management, because it will be difficult to draw interesting conclusions as to the coordination and chaining modes.
In the next part, we will continue with the modeling of the public works company as a basis for modeling an organization.
Sem comentários:
Enviar um comentário