We all like lists, be they the top 10 films or places to visit, or even airports to avoid. But all such lists are pretty personal, and my top three business problems are no exception. I have tried to crack these problems, but have met with variable success. Reflecting on why this is, I think it is because they are what could be considered "second wave" type problems.
Second wave problems are not show-stoppers, likely to delay a go-live date. These class of problems are more likely to only become apparent afterwards, when the system has been running a while, and thoughts turn to improving performance of the business processes. Very often, they are ignored or "worked around" without tackling the root cause, but as with neglecting to service your car, the relentless toll brought by such neglect brings increased risk and decreased performance. As such they are perfect targets for exploitation projects.
Anyway, here is my list:
1. Handling exceptions from an automated process.
Exceptions should only represent a small proportion of a properly designed system, and when they occur, manual procedures will cope. Right? Wrong. In a article I wrote recently (Incoming Invoices at Shared Service Centers), I recount how incoming invoices to a shared service centre required manual intervention in a surprisingly high number of cases. The problem was not in the process, but in variable quality of the incoming data that failed pre-posting validation checks.
To my mind, some form of all encompassing approach to capturing and tracking the exception seems to me the right way forward, but it's hard to imagine this being picked up and used as a universal solution. The closest I see this technique being used is in the incident management component of Solution Manager. Most budgets baulk at the costs of deployment and change management required to introduce such a system, and it is for this reason why it appears on my list.
2. Measuring the immeasurable - reporting what is really going on.
When I started with SAP Business Workflow, I was often asked what the difference between workitems from a workflow process and emails carrying some automated functions, such as can be generated from SAPOffice. The answer I gave compared workflow to the rail network, where the tracks laid represented the workflow process, and trains running on the track represented the relevant business objects, and the stations where the train stopped where the agents who worked on the business object.
Email, however, was like a car. You get in and drive anywhere, along any route, leaving no measurable trace (it was a time before carbon footprints). Workflow was ordered, standardised, better. Email was ad-hoc, immeasurable, and now as we know, it is how business processes are conducted that haven't submitted to traditional approach to process automation, which is to say the majority of business interactions.
One example, perhaps, of this type of process (I originally wrote "a typical example", but that lazy writing style would give the errorneous impression that there are "typical" examples) is handling starter and leavers from a company. I'm imagining that in common with other companies I have worked with, there are many different systems an employee needs to access. Delays in setting this up is a costly inefficiency stretching for many days, unless determined efforts are to made to micro-manage the process.
I've have reservations with the traditional KPI performance measures for such processes. A priori assumptions are necessarily made about what metrics to capture, and the reporting seems to me an exercise in box ticking. More challenging, but surely more useful would be if a wide range of possible "indices" (raw data points) are captured which then can be summarised and sliced'n'diced which may identify hard-to-pin problems. But the problem does not come from "down-stream" data mining, but from "up-stream" capture of the metrics. How would the information be easily captured in such a way that the context is preserved though to analysis?
3. Sharing business processes innovations, and validating designs.
I've recently been assisting a client using barcodes for matching scanned documents with documents entered into SAP. Barcodes are great little things, they bridge the gap between "NCI" (non-coded information - images to you and me) and "OCR" (optical character recognition). Using barcodes allow retrieval of scanned documents, without the overhead of actually knowing what is in the document. Wouldn't it be great if there was such a mechanism available for labelling business processes?
Let me back up there a minute, and explain the proposition. Arguably, most business processes are derived from a finite number of templates or "best practices". However, they generally defy classification because there is so many crucial variations between them. In a sense, to recognize a business process, you have to study it and understand it, much like a picture. This puts a limit on the ability to share innovations and validate existing designs.
There has been a lot existing work already done on classifying processes by purpose. As someone who has written a lot of workflow processes, it appears to me there is very little re-use on the meta-level, where the process flows between user agents and control points defined in the system. That may seem natural enough, given the uniqueness of each client's process, but if finger-prints can be recalled from a database based on key parameters, why can't the similar "touch-points" be extracted from a business scenario?
