We must determine needed processes, and the quality manual must identify the interaction between them. I have had an interesting encounter with an auditor and we are not on the same page as to what a process is.
My company makes a product, and also provides a service (maintenance, repair, or modification to similar products). I have defined only TWO processes in the company, documented as flow charts with inputs and output. The first for quotes, orders, scheduling, work, shipping, etc (what our business does). The second for management reviews, audits, and so on (how our business stays healthy). Each of these two 'processes' or flow charts makes reference to procedures, which typically break at department lines.
The auditor insists that we have not identified our processes, his definition is more specific than the overall flowchart, but not as specific as a single procedure. For instance, one process he defined is "product build" which includes design, purchasing, and manufacture, and another process is quotes & orders.
I cannot imagine why engineering functions would be grouped with manufacturing, but documenting an order is not grouped with anything. If a customer places an order, thats the beginning of a process which cannot end until order fullfillment. It takes many sub-processes to complete, and each sub-process has its own sub-proccesses.... so how do you define the 'scope' of a "process"?
How many employees? How complicated is the product? How big are the risks? We cannot analyze your system on the Cove.
But here goes, beyond certification how well does your
system work?
Does it deliver continual improvement? Does it add value faster (in converting needs into cash)? Does it prevent loss sooner (with data-driven preventive action)?
In your two processes do you have the criteria and methods needed to ensure your process-based management system fulfills customer needs, company objectives and other requirements?
Yes, a small company making/delivering and simple product needs a small and simple system and could be designed around the company's core process and its support processes along the lines you describe.
Normally, processes are determined by analyzing your system. Starting at about 30,000ft with the core processes which runs from customer needs to cash in the bank for each type of product. This analysis determines the key processes in the core process and their sequence and interaction.
Then you have to determine the key processes that sustain and improve the core process. These are known as support processes and may include:
- Managing risk (good and bad)
- Recruiting and learning (for competence)
- Controlling documents (that are subject to revision control)
- Filing and archiving
- Monitoring processes (for control and improvement)
- Investing in continual improvement*
* could include removing root causes of problems
List the key processes you have determined and assign each process to its subject matter expert. By analyzing/designing each of these key processes (at say 10,000ft to 1,000ft - competence fills the gap) you can document them sufficient for effective planning, operation and control by capturing the criteria and methods used to fulfill the objectives of each process.
You would be linking your process documents to work instructions (from the control of activities in a process) and to forms (to collect data for analysis to become reports that can be used to prevent future problems).
BTW, your auditor is out-of-date, instead of
identifying processes we are now required to
determine them (as you say). This suggests some system analysis (from needs to cash) instead of just making a list of processes.
Hope this helps,
John
It's just a same old - took the main chunks of each Standard, and said 'we do this stuff' and here's all the right ISO-speak buzzwords and phrases and here's all our cross-references. Process approach? Ha! 
