The wires broke this morning with news that an SAP partner had sold a significant add-on deal to SAP of $360,000 to a leading global food manufacturer. Of particular interest is probably the fact that the rationale for the investment was that the company aimed to centralize accounts payable operations and standardize invoice processing within its SAP Enterprise Resource Planning (ERP) System.
It recognized that automating its invoice processing seamlessly within SAP it can reduce invoice processing cycle times and improve visibility and control over invoices.
This is not an unusual story by any means, it is afterall one of the principal reasons that companies choose ERP soltuions. ERP inherently standardized and streamlines a wide swathe of business operations when implemented correctly and appropriately but of course there are many ancilliary activities and tasks that form a part of core processes but which are not easily or properly accommodated in the ERP implementation.
This is particularly true if the company implementing the system is moving from a smaller or legacy system that had many manual supporting activities, or where it has no meaningful systems at all. The levels of complexity that may have been built over the years, into a custom legacy system should never be underestimated and it should be acknowledged that highly customized systems can actually bring very rich user experiences and very sophisticated functionality to business functions.
Pursuant to many conversations with SAP customers at a number of conferences and through events like the Winshuttle User Group conference I have come up with a pair of descriptors of how different levels of automation have different impacts on operations depending on organizational maturity. Consider that 'automation' doesn't mean the same thing to everyone and so it is important to also describe some of the different kinds of automation that a given organization can implement.
How IT sees automation
From an IT perspective automation is often thought of in the context of batch jobs and scheduling and of course this is quite a reasonable thought given that It isn't typically responsible or accountable for the maintenance of automated business processes.
For IT, jobs like spools, cheque runs, backorder rescheduling, delta jobs between ERP and BW are all very clearly understood for what they are; methods to minmize the level of manual effort required to perform some piece of work. In the case of spools, printers would need to be free and available and data would be spooled off to tape or paper rather than manually transcribed from system screens. Printing is a very basic automation that comes with standard formats and layouts. Cheque runs basically are the same. The alternative to a cheque run would be to write the cheque out by hand - a painful, laborious and burdensome activity. Backorder rescheduling would require going into every order and adjusting the delivery date at the line level. Delta jobs between ERP and BW cannot be reasonably done any way other than programatically so its purpose is quite clearly understood. If you want to do analytics in BW then the delta synch jobs needs to run and run completely and correctly.
Often, all of these basic automations, along with backing up the system are well understood and deployed and merely need appropriate care and feeding.
Business sees automation differently
Business problems with handling the flow of paper, getting approvals for decisions, avoiding transcribing data or copying and pasting it from one application to another is not as well appreciated. In a past life I pushed the envelope for the Data Processing department of a small financial institution by setting up PC's to replace dumb terminals for access to the green screens of the back end financial record keeping system and one of the key benefits that flowed from that move was the ability to handle electronic documents as well as deal with the regular paper based forms and submissions that came in for processing. In this way, information that arrived in electronic spreadsheets could be pushed into the system using some rudimentary technologies that accelerated the data processing. This, when compared with the approach used beforehand, represented a significant step up in operational excellence as a result of automation.
Up until that time, this had not been an issue principally because most business partners continued to make submissions by printed paper and not electronically. However, some partners didnt want to generated reams of paper printouts and spend additional funds on mailing their submissions and preferred to submit them electronically. By accepting electronic submissions, we could contract the period close activities and reduce the workload on the operators. Additionally, by supporting electronic returns we could handle additional processing volumes. In this instance the influencing factor was pressure from business partners but now we see additional pressures coming from factors like financial reporting standards, the way our internal partners and employees want to interract with the back office and a need and desire from auditors and regulators to have evidence that an uncontaminated business process is in effect to finalize and report on business transactions.
At a most fundamental level, data that finds itself in an electronic format like Microsoft Excel is not really considered automation, however the way that data becomes SAP data or becomes part if a report or a decision making process is considered either automated or manual. Loading data from Excel to SAP directly, without key stroke entr y beyond starting the process and ending the process is a clear example of this. In some organizations this would be done with tools like CATT/eCATT scripts or LSMW scripts and then later with tools like Winshuttle and then if the scenario was frequnt enough with enough volume and with agreement between all the participants, by way of automation mechanisms like EDI or custom ABAP programs to load the data via IDOCs or something similar.
Moving up the chain of complexity in terms of the way the automations are deployed and maintained is a natural evolution. Moving to a higher level of complexity doesn't mean that the preceding method is no longer relevant, it simply means that the requirements may have outgrown the capability of the method or tool. Routing an excel spreadsheet around the organization via email and gathering email approvals for example, is a rudimentary automation and one that is improved with the use of an approval workflow. The decision to switch from email approval to workflow approval is furthermore, probably driven out of either a need to understand who is holding up the process on a regular basis or perhaps because it is an audit requirement. The final step of loading the data may still involve a manual intervention at the load stage but of course it could be improved if it is done with no further manual intervention after the final approval, in order to preserve the audit trail.
OCR is more than just scanning and recognizing text and numbers
The implementation of document scanning and Optical Character Recognition is often considered at the high end of automation but in reality OCR itself isn't automation unless there is added intelligence in the process. OCR implementations need to bring process aligned capabilities like process form filling, workflow approval and tight integration as an integral part of the solution. In the past this would have been largely achieved through a mish mash of technologies and a raft of different user experiences for operators, reviewers, approvers and decision makers but this is not something that all organizations can easily cope with. Small AP departments, for example, may not be able to afford the capital or the manpower.
Organizations that move to a BPO or shared services operation on the other hand, cannot properly function without this level of automation for at least some processes - the reason principally being that the pape doesn't need to be shipped half way around the world to where the review, allocation and decision making takes place. In most instances a good electronic copy of the documents, appropriately rendered and replicated in the system of record achieves a good enough end result. To make the leap to a big spend on OCR with workflow and integration, the business has to recognize the value or necessity in making such a move as this organization did as described above. The ROI needs to come not just from acclerated processing but also from hard core savings and business benefits such as standardization and transparency.
Organizations that adopt automation to augment business processes are typically more mature, have been running systems for some time and are looking for creative ways to buy more time back so that business operations departments can become more agile, innovative and responsive to a changing environment.
Early adoption of automation in less mature organizations that aren't regulated or heavily cost focused can result in a phenomenon which I refer to as landing up in the 'deadwood forest' - a dark and unhappy place where systems and processes are an over-kill and more robust than necessary. This over implementation of automation leaves people treating systems as black boxes, not fully understanding the processes and complaining an awful lot about things when they dont work properly.
If automation is not introduced at an appropriate time then the business lands in an area that i refer to as 'death valley' - notice death appears in both the forest and the valley.... In the death valley, essentially processes don't keep up with the business requirements and the transaction volumes - people are over worked, frustrated and the quality of the output of the process is degraded. When automation is ignored in such circumstancesthen then the only way to become agile innovative and responsive is to grow the size of teams and in this day and age that is less likely given the general desire to spend less on growing the workforce and spend more on process improvement through intelligent organizational design and methods.
