• Business Process Procedure Template

Structure is the key to effective documentation of your Policies and procedures As humans we all love structure so it’s important to create your documents in a structured way. Structured content educates your readers to expect certain things in certain areas thereby making your policies and procedures easy to navigate, read and ultimately understand. Think about how a cooking recipe is structured. It has an outcome. It has a list of ingredients you’ll need.

Last Modified: 7/9/2013 1/25 Business Process Procedure Purpose Use this procedure to modify relevant information within the LAUSD's Supplier Self-Service.

It tells you what tools-utensils you will need. Time – how long you will need to allow for this. The step by step process you need to follow. It might have some tips. It might also have some traps to avoid So why not use a similar approach when creating your own organisations policies and procedures. See below for a sugested layout that you might wish to use.

Download this sample policy and procedure template and many others available on our site. See the “Download now” button to the right Policy – eg: Our organisation will serve and focus on the following customer segments This policy will apply eg: whenever we decide to undertake any marketing or develop new business in any way. Keep in mind that a policy is basically a decision made at an executive level e.g. Board or owner of business. eg: Businesses needing regular interstate large freight services eg: These businesses will be targeted in newspaper, internet and email marketing. The only exceptions to this are eg: when the business is a multi national which has special pricing rules that make it unprofitable. eg: Businesses needing refrigerated transport systems eg: These businesses will be targeted in newspaper, internet and email marketing.

The only exceptions to this are eg: when the business is moving small quantities making it unprofitable. eg: add more eg: more info. The only exceptions to this are eg: your exceptions to this rule Procedure.

Everyone talks about documenting processes, but there seems to be little real guidance on the topic. Since a key step in the process management journey is the documentation of current processes and any exceptions to those processes, this article explores how to create a template for your process documentation guide. A template makes the process of documenting your processes repeatable. Repeatable is the word to remember here - primary aspects of a process documentation guide should be easily duplicated and reused to create additional guides after the first process has been documented. This repeatability feature makes it less painful to create your documentation as you move through all the processes in an organization. It also provides readers with a common format to follow as they research or review processes within your organization.

While the actual format will differ between organizations, the elements discussed in this article are usually included. How documentation fits into process management Documentation of current processes and exceptions is typically gathered during the overall process management phase, but the discovery phase also provides you with a great deal of information that can be included in a simple template for a process documentation guide. You document your processes to ensure that everyone understands them and knows who to contact when there is a problem or a change is needed. Without clear documentation, a process can quickly fall into disarray - picture ten chefs working in a single-oven kitchen and you'll get the idea of how quickly disagreements and confusion can arise. With clear documentation, a process can continue as designed, and changes can be made in a timely, straightforward manner that allows the organization to keep running effectively even when major transformations occur.

Of course, the organization needs to respect the process documentation guide before such smooth sailing can occur. That means every process must have its own documentation - you can't have a process documentation guide for one process but not the six other processes related to it, for example. If you take that approach, users of the process will be confused and simply ignore the guides that are available.

A better approach - especially if you are undertaking the creation of these guides for your entire organization - is to start with either a new process or one that is currently under revision. If you don't have either of those, start with a specific department or a major process rather than trying to tackle the entire organization at once or worse, tackling random processes in the organization. What's involved in creating a process documentation guide?

The purpose of your guide is to communicate the process management guidelines to support a specific process. The document essentially serves as the source of guidelines to be followed worldwide. The guide can be used by a wide range of audiences - business units, partners, customer service, regional process leaders, or anyone who is involved in the specific process outlined in the guide. Your guide can certainly include more information than what is outlined here. Always keep your organization's needs and interests in mind when you create a process documentation guide. Take a look at the basic tasks involved in creating your process documentation guide:.

Create a scope statement. Craft an applicability matrix. Explain the product or service lines impacted.

Include the roles involved in the process. Document process management system procedures. Establish an exception management process. Include a decision matrix Each of these will be a section within your guide, which you can create in Microsoft® Office Word or another word processing program. I recommend using a program that automatically generates a table of contents for you based on the use of heading styles. Also, it's important to assign a clear numbering system within your document. For instance, the scope statement might be 1.0 while items included with that statement are 1.1, 1.2, 1.3, and so on.

The applicability matrix might be 2.0 with subsequent numbering. A numbering system accomplishes two goals in that it makes:. Information easy for readers to find.

Tracking changes to the guide an uncomplicated process If you make a change to section 1.3, you can easily note that a revision was made to section 1.3 on a particular date and explain what the change included. Without a numbering system, you will find yourself taking a lot of time to describe the correct section.

Create a scope statement The first thing you need to include in your guide is a scope statement. Scope statements should be clear, yet as all-encompassing as possible.

For example, if you have 48 sales processes, there is not necessarily a need to create 48 process documentation guides. Presumably, most, if not all, the sales processes will fall into just a few categories such as manage leads and opportunities, design solution steps, deliver the solutions, and deliver the services.

All of these can be included in one process documentation guide. That single guide, then, would have a scope statement such as 'This guide will cover the following processes:' with bullets listing the processes the guide covers. It's entirely appropriate and helpful to include a description with each bullet. For example, 'Manage leads and opportunities' would be accompanied by 'This refers to the framework for capturing or generating the customer's desire to buy as well as capturing the customer's business needs.' If you need to explain a bullet in greater detail, do it in a supplementary paragraph. The goal is to be sure that as readers begin reviewing the guide they understand what it covers.

Craft an applicability matrix Applicability matrices allow readers to see the scope included in the guide and to see at a glance who is responsible for the processes. It's helpful to place this information toward the front of the guide because it gives readers the ability to quickly see who handles certain pieces of the process and what those pieces are. While you can certainly list this information in a text format, the matrix makes the information easier to understand and to change. You won't be able to complete the matrix until you have identified all the process roles and responsibilities (both are explained later in this article). Placing the matrix near the beginning of your guide is for your reader's convenience. When you use an applicability matrix, remember that the point is to provide quick identification of processes, roles, and responsibilities. The exact information in an applicability matrix may differ depending upon your organization, but it usually includes the:.

Business unit. Customer facing unit. Geographic area impacted. Overall process involved (for example, deliver the solutions). High-level steps involved in the solution. People responsible for the process.

Description of how the process fits with the people As shown in, the matrix makes these seven areas easy to identify. Business unit, customer facing unit, and geographic area impacted are on the left; overall process and high-level steps are across the top; the people involved are on the right; and in the middle is the applicability of a given process to the people, units, and geographic area involved. Applicability matrix. As you review the matrix, you can easily see that some processes apply to some areas but not others and that the responsibility for execution of a process does not always lie with an area impacted by the process.

You can also see the names of the people with the primary responsibility for the area (which is defined by the roles you assign). This is a very simple matrix. Some have multiple subprocesses included. Create your matrix according to what makes the most sense for your organizational processes. Note: Specific people are listed in this matrix example to make it easier for readers to determine who to contact. You might prefer to simply list the roles that are impacted instead. Explain the product line or services impacted The next item to include in your guide is the impacted product lines.

Because when people think about processes, they often think in terms of what the process impacts. For most businesses, this is a product line.

If your business has no products but offers services instead, add the impacted services. If you have both, add both. This particular section may be very short. Its purpose is to give readers a clear understanding of which product lines and services are included in the processes the guide covers.

An example might be 'This guide includes the following product lines:' with a bulleted list for easy reading. Include the roles involved in the process If you have a process, then you have people responsible for ensuring the process flows properly and effectively. Each of those people should have a clear role that is explained within your guide. This particular section can be quite illuminating as you work through it. Don't be surprised if you uncover areas in the process that no one claims responsibility for. Every company has different roles assigned to a process, but it's important to think in broad terms initially. Start with the person responsible for deploying the process at its most base level and work your way up through anyone else who approves all or part of the process from design to approval to implementation.

Here's what I mean. Your sales processes are used in three countries: the U.S., Canada, and Mexico. The people involved in the process range from worldwide leaders who approve the process at the highest levels to country execution teams who actually implement the process. In between are people on executive, steering, or deployment committees and teams who review and approve the finances and deployment decisions.

So, your guide reflects each of these process roles with brief explanations to show where and how all of these roles fit together. Perhaps you have a worldwide process design leader who is in charge of developing and managing the business process design, documentation, and communication of all sales processes in all three countries. This person works in conjunction with worldwide business unit leaders who are responsible for the actual implementation of the process in all three countries. In turn, the worldwide business leaders must work with country business unit process leaders who take responsibility for ensuring the process is properly implemented in each country. The roles continue down to the deployment team that handles the actual hardware and software changes required. As you can see, the roles can vary depending upon the piece of the process involved, as well as the location of the process. As you work to develop the roles and responsibilities (if they are not already established), it's important to clearly state the authority a particular role holds, too.

For instance, a country execution team role might have clear authority to implement the new hardware and software but not the authority to make changes to any piece of the process. In your guide, clearly state that distinction. When the roles are reviewed, it should be easy to determine who holds final approvals for changes or exceptions, who is in charge of deployment, who handles financing, and so on. Remember, process roles are not tied to a particular person at your company.

Instead, a person fills a role. This is a key point. If a process role becomes confused with a particular person and that person leaves the company or moves to another job within the company, the process can fail because the person's role was never clearly understood. If a process role is clearly defined, then it doesn't matter who is in that role - anyone can be designated to fill it. Don't be shy about roles - include as many as you need to capture your particular process. At the same time, be sure role responsibilities do not overlap.

If you have a country leader and a business unit leader in that country who have the same responsibilities, who has the final say? Defining roles is a task that may take some time to be sure you identify any problems before they occur. Document process management system procedures Process management systems are simply the reporting methods that show who is reporting to who - and when - about the process. You can read more about this concept in '.' In your guide, you'll want to document the actual management system that has been created for your process. For some, this may be a simple paragraph, for others it may mean the inclusion of a chart or graphic to show how the management system works. Including this in your guide helps readers recognize all the people who have a stake in the process.

Establish an exception management process The next section of your guide deals with process management system procedures. These vary according to the organization involved but should always include how variations and changes to a process will be handled. Called an exception process, this sort of documentation is critical to ensuring that processes don't morph into unrecognizable procedures from country to country as changes are made to processes. At the same time, it's important to recognize that different countries or regions will have different requirements - some legal, some consumer oriented, some language related.

To address those differences, your process management system procedures need to include concise instructions showing who can initiate a request for process change, who can approve a request, and who will implement a request if it's approved. For example, your exceptions policy might say 'Exceptions to the worldwide process may be requested by using the Exception Change Request form outlined in section 3.6 of this document. Exceptions are typically granted for targeted audiences that require unique implementation guidelines for successful execution of the process. Exceptions require the approval of all affected business unit leaders and the worldwide process design leader.' The Exception Change Request form, then, would be a form included in your guide (usually in the appendix) that asks for details about the requester, the reason for the exception, where the exception applies, the funding implications, and implementation requirements.

It's helpful to designate the role of exception process facilitator in your guide, but this item can also be handled by any other role that you feel is appropriate. It's helpful to your readers to include a graphic showing how the exception change process flows. Remember, this guide is supposed to provide quick and easy reference for a wide variety of people. Including graphic representations alongside your text is always appreciated by readers. Include a decision matrix The final piece that should be included in any process documentation guide is a decision matrix. This differs substantially from the applicability matrix mentioned earlier in this article. Applicability matrices allow readers to see the scope and who covers the processes at a glance, while decision matrices show readers exactly who can actually make decisions and the types of decisions that can be made for the process.

For a decision matrix to work effectively, you must already have your roles established. Then, from those roles you should be able to determine who has the ability to approve a decision, who must review a proposed decision, who can endorse a proposed or final decision, and who must be consulted with before the decision is finalized. You also need to determine the types of decisions that are involved in the process. You might want to create a single decision matrix that can address any type of decision in any type of process or you may want to create a new one for each process. That's up to you. The types of decisions that might be included in your matrix could be worldwide process design, for instance.

Aside from the worldwide process design leader, who else should be involved in decisions about the overall process design? Should an executive approve any proposed changes? Or does the executive simply endorse the changes recommended by the worldwide process design leader while the business unit leaders are required to approve or deny any proposed changes? More details about the decision matrix, including an example, are available in '.' Summary Keep in mind that all the tasks mentioned here are simply the foundation for your process documentation guide template. You can certainly add more information to your guide if necessary. Do whatever works for your organization.

As long as each guide contains the sections covered in this article, you have a good base for your documentation that you can easily add to as time goes. The concept of repeatability should be kept at the forefront of your documentation. The sections outlined here are easily repeated in any new guide with minor changes to the text, allowing you to create new guides as needed with minimal time requirements.

Business Process Procedure Template

It's the rare person who enjoys documenting processes, so make it easy on yourself by using these or other repeatable elements.