How Many Processes should be created for each Department?

[BeaBea]

I am creating the entire QMS for our small business to obtain our ISO 9001:2015 Certification.
So far I am structuring the foundation.
We are a small business VAR company that sells IT solutions (the middle man that reviews contracts, finds a supplier, create and RFQ, and sell IT products to the customer) We don't manufacture anything, in fact we don't even touch any products. Everything is done online.
Our business is requiring an ISO certification to obtain specific government contracts....

So I am now in the process of creating processes. (we have procedures... but not ISO standard "turtle diagram" processes)
I am trying to break down company in to 'departments'/ and 'functions'.
We have the Admin/Accounting Department that deals with bills and invoices, we have the Sales department that creates quotes and Purchase Orders, we have the Marketing team that advertises our certifications to acquire government contracts, our IT department that falls in line with NIST and CMMC regulations, and we now have me, the entire QA department.

I understand the ISO requirements (I took an auditor course back in February)
But I am trying not to over complicate each department/function.

For example: Accounting has about 4 main "goals": 1. Activation of a contract, 2. Processing Purchase Orders, 3. Invoicing the Supplier, 4. Billing the Customer

Now my question is:
Do I create 4 separate processes for the accounting team? (the 4 I listed?) and each individual one will have a turtle diagram with the standard requirements; inputs/ outputs, training, procedures/ records, key metrics...
OR
Is that 1 process as a whole for the accounting team? and the 4 "goals" I listed IS actually "the process"?

Please let me know your thoughts. I AM the entire QA department and have no one to bounce ideas off. I'm trying to keep it simple, but obviously meet all requirements.
Thank you for your time!

 

[Ninja]

Howdy Bea, and welcome to the Cove,

Since there is no requirement for # of processes...break them where they make sense for your organization.

Placing a purchase order is far different than paying an invoice...two processes (two documents) typically.
Writing a purchase order, saving it to pdf, emailing it, filing it...these are all sorta part of the same flow...one process (one document) typically.

Do not over-complicate it...but don't oversimplify it either. You could have the whole company on one document if you wanted...or 40,000. Separate it where it makes sense to the flow. Don't be afraid to ask the folks actually doing those jobs how to break things down...make friends, don't "ISO" future enemies.

HTH

 

[BeaBea]

Howdy Bea, and welcome to the Cove,

Since there is no requirement for # of processes...break them where they make sense for your organization.

Placing a purchase order is far different than paying an invoice...two processes (two documents) typically.
Writing a purchase order, saving it to pdf, emailing it, filing it...these are all sorta part of the same flow...one process (one document) typically.

Do not over-complicate it...but don't oversimplify it either. You could have the whole company on one document if you wanted...or 40,000. Separate it where it makes sense to the flow. Don't be afraid to ask the folks actually doing those jobs how to break things down...make friends, don't "ISO" future enemies.

HTH

Thank you SO much! This makes total sense!
It's such a relief to have found this forum.. I need more QA friends in my life :s
I think I get caught up in overthinking things and I convince myself of one way over another, and its nice to hear other perspectives.

Thank you for your input!

 

[John Broomfield]

Bea,

Welcome to the Cove!

Search the Cove for developing a process-based management system. You’ll see that processes are usually cross-functional involving more than one department.

After working with top management to determine your company’s mission you should be able to engage them in determining the key processes comprising the core process that runs from determining customer needs to receiving cash in the bank. At 30,000ft it can crudely be stated as get work, do work, get paid. This usually further engages top management because they thought you wanted to talk about quality!

Then you drop to 10,000ft to determine the key processes that comprise the core process. For example: Marketing and Selling, Designing Services, Delivering Services, Obtaining Payment. Once you have a list of these processes you can ask top management to name the process owner for each process.

Then take some time with the system standard to determine the key processes that support, direct or improve the core process. When you see the requirements for resources, for example, you are thinking recruiting, training, purchasing and maintaing facilities and equipment. Translate the headings into processes.

Ask top management to name the owner of each of the organization’s support processes.

Remember that processes are work not procedures. Procedures are the specified way of doing the work.

You should then be ready to work with each of the process owners to determine the way their process actually works to fulfill its objectives. Ask auditor type questions by showing a genuine interest in their work. If you are not trained as an auditor then I strongly recommend it. My clients preferred to document their procedures lightly using deployment flowcharts which referred to forms to collect data and to instructions where how to instructions already exist.

Ask the process owners to engage their process teams (note that these folk will probably be in different departments) in review of their flowcharted procedure for accuracy and reconcile their comments.

Also remember that a procedures does not need to be documented to be procedure! Strange but true and worth remembering to avoid over documenting your management system.

That’s enough for now.

Good luck and let us know how it goes.

John

 

[BeaBea]

Bea,

Welcome to the Cove!

Search the Cove for developing a process-based management system. You’ll see that processes are usually cross-functional involving more than one department.

After working with top management to determine your company’s mission you should be able to engage them in determining the key processes comprising the core process that runs from determining customer needs to receiving cash in the bank. At 30,000ft it can crudely be stated as get work, do work, get paid. This usually further engages top management because they thought you wanted to talk about quality!

Then you drop to 10,000ft to determine the key processes that comprise the core process. For example: Marketing and Selling, Designing Services, Delivering Services, Obtaining Payment. Once you have a list of these processes you can ask top management to name the process owner for each process.

Then take some time with the system standard to determine the key processes that support, direct or improve the core process. When you see the requirements for resources, for example, you are thinking recruiting, training, purchasing and maintaing facilities and equipment. Translate the headings into processes.

Ask top management to name the owner of each of the organization’s support processes.

Remember that processes are work not procedures. Procedures are the specified way of doing the work.

You should then be ready to work with each of the process owners to determine the way their process actually works to fulfill its objectives. Ask auditor type questions by showing a genuine interest in their work. If you are not trained as an auditor then I strongly recommend it. My clients preferred to document their procedures lightly using deployment flowcharts which referred to forms to collect data and to instructions where how to instructions already exist.

Ask the process owners to engage their process teams (note that these folk will probably be in different departments) in review of their flowcharted procedure for accuracy and reconcile their comments.

Also remember that a procedures does not need to be documented to be procedure! Strange but true and worth remembering to avoid over documenting your management system.

That’s enough for now.

Good luck and let us know how it goes.

John

This is Great information John!! Thank you so much for your input!

 

[Kronos147]

One way to make it simple is just use the 'departments' as the process names (since someone sees it this way anyway). Their 'processes' as you described them could then be identified as sub-processes under the process umbrella.

I like what Ninja had to say, about not overcomplicating it. You can always expand, it's more difficult to consolidate.