User talk:Andygalloway

• Help & FAQ
• Manual (to create a wiki)
• Community portal
• Editing help
• Language support
• <translate> Sandbox</translate>

Welcome to Wikimedia Incubator!

At the right there are some important links, and here are some tips and info:

• If you haven't created a user page yet, please create one with for example Babel templates on it.
• You can select your interface language in your preferences.
• If you make articles, templates or categories, don't forget to add a prefix!
• If your knowledge of English is good, you can help with translating pages to other languages you know, so more people can understand it!
• If you want to translate the interface, please go to Translatewiki.net and follow the instructions.

If you have any questions, feel free to ask them on Incubator:Community Portal.

-- Welcoming Bot 09:48, 13 August 2015 (UTC)

6PE Methodology

The 6PE Methodology was created by Andrew Galloway of External Quality Management Ltd in 2000 in response to the changing need of the Quality Management Systems standard ISO9001. The 6PE Methodology is a simple methodology because it has only a few rules, but it is incredibly powerful in developing process based management systems.

The 6PE is a proprietary methodology for the development, implementation and ongoing improvement of Management Systems. Among other things, a management system is comprised of a number of processes and its effectiveness is dictated by the effectiveness and the interrelationship of those individual processes. The 6PE model is based on our understanding that processes have 6 component elements. When processes are developed with consideration for all 6 of these process elements:

• they will quickly and easily demonstrate compliance with the management standard (i.e. ISO 9001, ISO 14001, ISO 27001, OHS&S 18001, ISO 22000, ISP 22301, SoX S404, TSA CoPs) or any specific technical standard or legal or regulatory requirement that controls part or all of the process;
• they deliver the required management controls without stifling creativity or being too restrictive;
• they give precise control within the process (and therefore within the organization) at predefined points;
• they allow for effective monitoring and measurement, not only of the product or service, but of the effectiveness of the processes themselves;
• they can be used to control and manage change within the organization ensuring that a new process or an entire system being implemented will work correctly and be fully compliant as soon as it goes “live” and;
• they are an aid to process redevelopment ensuring that the processes are aligned with the achievement of organizational goals and objectives.

The 6PE Model

The 6PE model is powerful and flexible. It enables the requirements of any management standard or any organizational strategy to be developed into a management system for that specific organization. This in turn instals the necessary controls to ensure that all activity is directed towards and streamlined with the organization’s goals, whilst achieving all necessary compliance with regulations and management standards as a matter of course.

The Rules

Introduction

A process is a discreet area of business. A good example is the Sales Process. It has a direct input from the business objectives, there will be methods in place to monitor sales and (like all activities) it requires some specific resources. The process starts with the trigger of the prospective customer calling the salesperson, followed by a series of steps leading to the output of sending a quotation to the prospective customer. If the business area does not have all six of these process elements, it is not a process. It is probably a procedure or it may be a supporting system to the main process.

Business and Quality Objectives These should be clearly identified and should be in line with corporate goals. Every corporate goal should be reflected somewhere within the Business and Quality Objectives of the Process Maps and some will be represented more than once. For example, the Business Objective “To grow the company organically and by acquisition” would appear as a Process Objective in the Sales Process (“To increase the company customer base through organic growth”) and in the Business Development Process (“To identify and acquire suitable businesses to enable the company to grow into new geographical areas” and “To up-sell newly acquired services to existing customers and existing services to newly acquired customers”).

It is normal to associate the clause of the standard or other reference document to the business and quality objectives. This makes auditing the process much easier. It also helps when the process is being reviewed, particularly if that review was triggered by a change in the legislation or other reference document.

Methods of Monitoring and Acceptance Criteria can be identified in the process as a process step i.e. “Sample 10% of the batch against Quality Specification 1234” The next step would normally then be a question i.e. “Did the sample pass?” with different routes to follow if the answer is “Yes” from if the answer is “No”.

MoM can also identify the acceptance criteria i.e. “Test the batch. Any that pass the “xyz” test schedule are marked “Pentium 4 Compatible”. Those that do not pass “xyz” but do pass the “stu” test schedule are marked “Celeron compatible”. The remainder are scrapped in accordance with procedure 12 - Scrappage and waste.” This can be represented by a series of process steps to follow or a branching structure with questions and different routes to follow based on the answers. (In this case, I would opt for the series of process steps because you do actually go through all of the steps and the process itself does not branch.)

It is normal to associate the clause of the standard or other reference document to the Method of Monitoring and Acceptance Criteria. This makes auditing the process much easier. It also helps when the process is being reviewed, particularly if that review was triggered by a change in the legislation or other reference document..

Resources are clearly identified within a process map. Without resources, there would be no way of implementing the process steps or applying the monitoring criteria. It helps to know what processes have been utilized in the past when the process is being reviewed for increased efficiency (streamlining), re-engineering or cost-cutting purposes.

Inputs are also known as trigger events. They are things that do not naturally follow on from one of the previous process steps. For example if there were a process step called “Print the invoice” and one called “Post the invoice” in one company they may well be connected by an arrow which means every time you print the invoices the next task is to post the invoices.

In another company, they may print all the invoices in one go and at a later stage, they post the invoices. In this case, the process step called “Print the invoices” may be followed by a task of “Put invoices in postal tray” with an output of “Invoices in postal tray”. The posting of the invoices would then need to be triggered by something else later in that process or in a completely different process.

Inputs to a Process Step may come from the Inputs column or from the previous step in the process flow. The process below shows two options to trigger the step to put postal tray items into envelopes and frank them. Both are inputs i.e. trigger events to the next process step.

Process Flow The process flow is made up of a series of process steps and decisions. Skill in identifying the process flow will lead to improved effectiveness of the process. Each step in the Process Flow must be either:

• Self-evident (a process step of “Put the invoices in the envelopes” may well be self-evident. However, if there are different types of invoices and different types of envelopes, you can either expand the process flow to show more detailed self-evident process steps or keep the process simple and have process step supported by something else);
• Supported by something else (a check list, a form, training, a training course, a procedure, a manufacture’s handbook, a sub-process, a computer generated report, etc.)

It is a good idea before declaring a Process Map to be completed, that you address each process step and ask of each one “Is this self-evident or supported?” If self-evident, read the wording critically to ensure it is self-evident and there is no room for error. If it is supported, check the support system to ensure that it is robust and that the supporting system can in fact provide the support that is required for the process to run smoothly and without deviation.

In some instances, you can add the resources to the process step or at least identify who carries out that task. Be careful with this, as it can get very burdensome. I would suggest doing this only where it is critical who does what. You could just as easily alter the process step wording to identify the member of staff such as “The Administrator prints the invoices”.

The outputs from a process step are useful if you are re-engineering a process. As you re-arrange the blocks of the page or on the screen, you would identify a weakness in the process if an output went missing, particularly if it was an output relied upon in a later process or something being sent to the customer. You can also identify redundant or additional resources as well as supporting systems. This is so robust a system that you would normally expect a re-engineered process to work correctly on the first attempt.

Try to keep the Process Steps in a single column down the middle of the page. This makes applying inputs and identifying outputs much easier. A sub-process should also contain its own objectives, methods of monitoring, resources, inputs, process flow and outputs and all of these rules apply just as equally to a sub-process as they do to a “main” process.

Outputs are commensurate with the business objectives. Each item considered to be a quality or business objective should be clearly identifiable as an output from that process. In the above example, one of the objectives of this process may be to ensure all invoices are raised and posted to customers by the end of the trading day. Normally, but not always, the overriding business objective of the whole process would be the output in the bottom right of the process map, all minor outputs having been identified earlier.

Every series of process steps should lead to an output; otherwise, what is the point in carrying out those steps.

For the greatest flexibility, keep the number of outputs to a minimum i.e. one output at the end of each series of process steps. Only state an output in a process map when it is essential to the achievement of the objectives. For example, if you require a customer’s signature at any point to demonstrate legal compliance, state it as an output from a suitable process step (“Get the customer to sign the worksheet”) with an output of “Work Sheet signed by Customer”. If you would like to get the customer’s signature as proof of delivery, but it doesn’t matter if you don’t, use the same process step of “Get the customer to sign the worksheet” and add the words “, if applicable” and do not specify the output.

If you have too many outputs in one Process Map, the whole process becomes unworkable and will probably fail i.e. unplanned inconsistencies and failure to achieve objectives will become the norm rather than the exception.

The whole process map should look like:

A Typical Process Map

--Andygalloway (talk) 12:51, 7 September 2017 (UTC)