In Part 1, we defined process as a “series of actions or steps taken to achieve a particular end…” (Oxford, n.d.) Processes govern what is done and when it is done, and connects roles and responsibilities to turn an input into an output. Processes are normally grouped by their purpose. The main processes areas include:
Procurement to Pay: The process of buying something (the input) to making the payment to the vendor (the output). In larger organisations this is sometimes divided into Procurement to Purchase and Purchase to Pay.
Sales to Cash: The process of selling a product (the input) to delivering the goods or services (the output). In larger organisations this is sometimes divided into Sales to Order and Order to Cash.
Record to Report: The process of entering a transaction (the input) into the ledger to prepare a set of accounts (the output). Examples include customer accounts, management accounts, and statutory (financial) accounts
How do processes work?
A process ensures that all inputs to the organisation have a destination, and that the input is managed by the right people or system and is converted into a useable output. All process, therefore, must have a start and end. Processes answer the following questions:
Where do I start? – Process must be triggered by an event. Events could be a request for information from a perspective customer, signing of an expenditure contract, or the requirement to submit an audited financial statement.
When do I act? – A good process advises staff when they are required to take action. For example: A sales order may only be raised in the system based after a contract is signed with a customer.
What do I do next? – Once the task is complete, what is done next? Does the transaction need to be approved by someone with appropriate authority? (See part 2!) Does the customer need to approve the order?
Process maps
Processes can be mapped setting out roles and responsibilities, when decisions are taken, and documentation. Process maps are comprised of symbols which are internationally recognized.
Each map shows where a process begins – its trigger, process steps, and where the process ends. The following example map shows a simple transaction at a supermarket. The map shows as the first step a customer placing items on the belt, thus signifying the beginning of the process. It then continues to explain what the cashier and customer must do to finalise the transaction and how the system assists.
Process maps can be linked together via process steps. For example: the map can include links to differing payment methods. A step can also be added to explain what happens in an exceptional circumstance. For example: Who will approve a price change due to a difference between the price in the system and a published sale price?
Relationship between process and policy
A process map explains how a situation will be handled; however, the governing policy explain when that process is most appropriate and who will be responsible for managing it. For example: The process map can explain that when a customer wants a price reduction, the manager must approve; however, the map does not explain under what circumstances the price will be lowered. Only a policy can set that out. Authority delegated to a member of staff to approve certain levels of discount and require higher level approvals for larger discounts.