I’m definitely not the 1st one to point this out. Sometimes you have to tell your customer ‘no’ and you have to tell them in the right way. The right way is to focus on the business need and ignore all else. Remember this when you get told to implement workflow.
Companies don’t like to spend their money (on the wrong things) and any purchase will often be preceded by an approval process. But this is not what the consultant is told. The consultant is told: please implement a workflow for PO approval.
What are the business needs here? Well firstly expenditure must be controlled and no employee should be able to willy-nilly spend company money. There is a need for a process. For example: the employee will raise a purchase requisition, this will be converted into a purchase order by another employee and the purchase order will be approved (or rejected) by one or more other employees. A decent IT system can then handle the rest in the background: send the order to the supplier, inform the warehouse manager about the inbound goods, etc…
A second business need is a consequence of the first one: the approval process must be as efficient as possible. Well in fact, this is a requirement for all business processes.
Now it so happens that managers find approving PO’s a pain in the backside that they would rather get rid of, especially because they cannot control when the approval requests will come in and they are sometimes urgent. They even get them whilst on holiday! What a nuisance.
In my experience, a solid PO approval process starts like this.
1. No PO should be auto approved even if the system cannot derive an approver. SAP is guilty as charged. That issue has to be dealt with as a priority. A report should list all approvers and the scope of their approval. It should also show the gaps: situations where the system cannot find an approver for whatever reason.
2. There is a way to centrally monitor all unapproved POs, who the next approver is and how long the delay is in the approval process. Also, this report should be able to list approved POs, with delays and what/who caused the delays. Building this is not a task for the faint-hearted.
3. Once those 2 elements are in place and owned by the central procurement team, one could consider implementing workflow. Workflow isn’t all that sexy by the way. It simply means that the approver receives a notification, usually by email.
But managers hate email. They get so much of it. They are thought in management seminars not to respond to email or do it infrequently, so their teams do not grow to expect quick answers any time of day or night. So then the IT department comes along and gives employees a mechanism to bombard managers with email that must not be ignored. Oh my.
But things get worse: in standard solutions offered by SAP, the manager does not see the full PO but only some summarised data. So to perform an approval, they need to click on a link that opens another app. What if the manager is sitting in an aeroplane or some other place without a decent internet connection? The nuisance just got a lot bigger!
My recommendation is to start with the two monitoring reports mentioned above. Admin staff can use those to help the manager approve efficiently during their private meetings, maybe once or twice a week. In that case, there is no need to build anything else. But if you are going to bombard your managers with email, make sure the email gives full sight of the PO including who else already approved it. Ensure they do not need to open other apps or technology to respond. It should be a simple email response with one click on a button. That email can sit in their outbox until they are back online and is sent automatically without further ado.
No comments:
Post a Comment