Business Process Automation – a contextual evaluation Part 1 of 2
It should come as no surprise to anyone that documented data volumes are growing. On the one hand you have the growing global population; on the other hand you have the increased volumes of consumption, production and just transaction volumes in general. Assuming that this increasing transactional volume leads to economies of scale, lower costs and higher profitability, everything looks to be on track for success. This would probably all be true if your SAP system was sized appropriately and your business processes optimized for the kinds of data volumes that you are now seeing.
I am reminded of this, particular in the world of mobile devices, the recent shakeup in the tablet computing market is exciting for computer execs but the demand is a relatively paler cousin when compared with the voracious market for mobile phones. Handsets are, for the most part, coming down in price relative to features and the volume of units being shipped is growing exponentially. Are the logistics systems really coping with this increased volume of transactions?
It is not inconceivable that anyone caught walking around with a mobile that isn’t a smart phone will be lumped in with those who still use fountain pens and wear a trilbey. Perhaps stylish, perhaps a personal statement, but nevertheless a little old fashioned. For manufacturers of the components, brand owners, wholesale distributors, mobile phone carriers and retailers the transactional volumes will continue to grow incredibly.
In the last decadealone we went from the first Mobile phone that doubled up as a MP3 player (The Samsung Uproar) to the Apple iPhone 4 which is currently being touted as a replacementfor Alarm Clocks, GPS, Digital camera, Personal planner, Landline phone, MP3 Player, Video Camera, Newspaper, Radio etc. And while you may think this isn’t really an issue, consider what the backorder status looked like on the latest iPAD , had it been readily available at all stores in all quantities desired, the quarterly volumes in terms of sale may have looked just a little different.
You could argue that the transaction volumes are simply shifting from one area to another but that is not strictly true, people are not simply replacing these other technologies and methods, in some instances they are becoming adopters of those other technologies or facets of daily life as completely new initiates. In the world of SAP the growing volume of transactions has serious repercussions for system and data management. HANA for example has been laid out as an opportunity to do rapid analysis on very large volumes of data , the most recent example being 3.2Bn rows of Microsoft Xbox Kinect Data by Nic Smith however somewhere along the line, that data had to get into SAP. The atrting point is often manual entry or perhaps integration.
From a purely traditional perspective the approach in the past was, hands on keyboards, data processing it manually. This approach is still largely out there, the model may have changed slightly with syndication of the data entry process to mechanisms like web sales order entry screens or one click shopping carts or even point of sale units like the increase in electronic vending machines like those of Zoom and Sephora. These methods are all semi automated or fully automated.
Web portal data entry is great if you have one or two transactions
Sales data and time are recorded electronically, the credit card purchase event settled, and then perhaps the replenishment request automatically sent to the ERP or WMS system. The process is likely very automated and very streamlined. It is only one part of the entire process though and behind the scenes it is most likely that there are still a large number of events that are still being undertaken or scheduled as a result of manual data entry activities. Returns for examples, are they manual or electronic and if they electronic, why a restocking fee? The idea of a smart refrigerator that would automatically generate a shopping list for you based on your stocking level settings was bandied about years ago and failed, it’s a great product management failure story. That was of course before the internet became as ubiquitous as it is now and yet if someone were to suggest it today we would likely be unfazed or unsurprised by the suggestion, it might even work!
It seems a little strange that despite this progress, we aren’t filled with disbelief when we discover that consultants’ timesheets need to be entered field by field into an electronic payroll system or that repeating orders for things like corporate purchases need to be entered from scratch for every order.Role based web-centric data entry is great if you have the onesy-twosey transactions but a pain in the rear-end if you have to do dozens at a time.
The reasons might be multi-various for this apparent acceptance of the status quo. More often than not, I see it coming from the inability of business to either articulate the level of cost and frustration with the current approach or alternately a lack of financial commitment on the part of the business and IT to address the challenge of making people work more efficiently and optimizing the business process.
Intuitive task automation
Task automation increases opportunities for making people more accountable and responsible especially when the automation is done in such a way that it makes intuitive sense to users. A method for example, that allows a user to see their mistakes as they occur as opposed to one that only tells you about the errors at the end is far more intelligently designed. This was one of the great advantages of OLTP when compared with batch processing. Yes, corrections were still effected on bad data but the difference came with you seeing it sooner and being able to correct it sooner. Well designed screens and forms mean better efficiency and reduction in errors, the ability to use electronic forms and interactive screens, in particular, also means that you can reduce the level of rework. With good design you can facilitate such simple functions as cloning and reuse. From a bean counting perspective, these all bring savings, savings in materials, time and labour and ultimately support the ability to generate reports and analysis sooner and more accurately.
So if we agree that automation brings all these wonderful rewards, how do we decide what we should automate?
At first glance, anything that has a repeatable pattern is a candidate for automation, just as for testing automation. By default that potentially means, anything you do with an SAP transaction. The transaction itself is of course automation, most likely of an old manual paper based process, however even within the inner workings of an SAP transaction there are opportunities to automate further. Your criteria for candidates need to be defined and here are some suggestions. This list is not an exhaustive one, but it is a good starting point.
Pervasive use of the transaction.
Is this something that is used by a large number of employees/people? You could say for example that an SAP transaction like PA30 is not for the faint hearted regular employee, that it is usually only used by HCM generalists and specialists, which would all be true. The underlying process however may be something that employees themselves would use if they knew that they could, or if you could trust them to use it correctly; especially if you wanted them to enter and maintain their own data such as addresses or dependents or emergency contact! So relative pervasiveness of the transaction or its underlying business process may be a criterion.
Complexity of the process
Some transaction screens can be awfully complex. Some may have hundreds of fields in a vanilla installation and yet not all of them may be relevant to your business. If you have a relatively high staff turnover or you have staff who are not particularly well educated or experienced with working with your ERP why would you make their lives more complex and the risk of them entering bad data even higher by exposing them to dozens more fields than they need to use? A complex transaction process that can be simplified and reduced to just the bare essentials to achieve their work objectives may be the way to go, and again, this may ultimately be considered an automation of an existing transaction or underlying process.
If you already have the data staged in some transitional source, does it make sense to reenter it manually into another system simply because you cannot manipulate it easily in the system of record. Data often finds its way into downstream and upstream data repositories such as data marts or Excel where users manipulate it to achieve a variety of operational goals. When the data needs to be updated in ERP; if there are no automated data loading mechanisms, users have to reenter the data manually, thereby introducing the risks of transcription errors. Incomplete data or simply failing to enter the data because the up or downstream repository becomes the source of truth is usually a sign that you should be automating.
A classic example here is what i call lazy MRP that works on minimum inventory stocking levels (safety stock) in the ERP but which uses a demand or forecast plan managed out of the data mart, a separate planning tool or even Excel. The minimum inventory levels doesn’t represent the real plan and using safety stock for replenishment can lead to costly inefficiencies and dead stock (think of those mobile phones). Data that is already pre-staged in other electronic forms is a very obvious candidate for automated integration into your target system.
Month end missed deadlines seem to be less of an issue these days but they’re still a potential problem area for the sales organization, for time and expense reporting and a variety of other activities that perhaps involve personally impacting time boxes. Your ability to enter your bill pay transactions into your online banking system is one example where your ability to get the data scheduled in advance of the due settlement date, avoids you being liable for late fees or penalties. These challenges also exist for businesses that want to get early settlement discounts or who need to carefully perform cash management transactions in order to maximize earnings and minimize costs. If your data needs to be moved from source to target in minutes as opposed to hours or days through manual entry then it is likely a good candidate for automation. A good example here might be taken on advanced shipping notices and making these updates in your inventory system as they arrive rather than waiting for the goods to physically arrive.
Volume of transactions
I discussed this in the beginning, data volumes are increasing. In the past the volumes were often dealt with by aggregating data entries but the new order of things, requires more transparency in record keeping and an increased flexibility around being able to see very granular data in real or near real time. Business doesn’t tend to wait for the end of the month for wrapping up the transactions for the month but instead deals with them as they occur because by the time the month end rolls around, there is too much to do in a small window of time. If you’re processing volumes of more than dozens of the same or similar data on a daily basis then this transaction or process is likely a candidate for automation.
Next time I will talk about the approaches to consider, manual integration vs. automated integration and consider what the advantages and disadvantages are, to both approaches.