Desktop programs support operational efficiency with SAP

[clinton_jones2]

I was recently discussing some past challenges experienced in the Sales Returns processing area with CRM where business users at a remote warehouse location were tasked with initiating the returns process when a customer returned something they had purchased using a returns label that accompanied goods they had previously bought.

Simplifying the input mode

Whilst we didn't delve too much into the specifics of the process I recalled that the issue was really only discovered when the finance group received a lot of disputed credit card transactions which were attributable to customers tired of waiting for the credit to be passed to their credit card following the return. When we dug deeper with the logistics group it turned out that the reason returns were not being processed in a timely manner was because users were having a difficult time entering the returns in the custom UI established for them. The reason a custom UI had been developed was to simplify the overall process for the logistics users, over a relatively slow bandwidth WAN with sub-par workstations, the users had found latency intolerable and more importantly couldn't always understand the error messages that they were receiving whilst trying to process the return.

When a full analysis was undertaken of all the components that made up the solution as well as logic of the processing activities, it became clear that the solution was being applied in an environment for which it had not been adequately planned.

Reverse Logistics - the last thought in peoples' minds

Any supply chain expert irrespective of the system used to support the process, will tell you that  reverse logistics is one of the biggest headaches for most businesses. Whether it be reconciling milk crates, packing pallets, exchanging faulty or warranty items or processing a full reversal of a sales transaction, many businesses spend significant resources on accommodating the special needs of reversing the process.  The overall process is in fact so difficult in some cases that certain business models actually don't support reverse logistics at all; in fact their policy is to simply replace the warranty, broken, lost or damaged item or refund the transaction rather than have to deal with restocking. Getting inventory out the door to fulfill orders seems to be a much easer process than getting inventory back in and completing the reversal or correction of the transaction. It has been estimated that reverse logistics costs account for anything between 10 and 15% of the US economy alone and unfortunately this process is still largely undeveloped  and so there aren't well established systems that can measure business costs in this area well.  Some project costs as high as 5% of the overall logistics cost for business. In a low margin wholesale distribution scenario that can decide whether you make a profit or a loss. Logistics analysts Rogers and Tibben-Lembke, in their book Going Backwards, Reverse Logistics Trends and Practices estimated the cost to be as much as $35 billion in 1997 and more recently has seen the establishment of the Reverse Logistics Trend Industry Association.

Overwhelmed by a sea of boxes

Returning to my story, it transpired that the users at the warehouse felt so defeated by the system that they had decided to 'hide' the problem in a cage at the back of the warehouse. Every day when the returns came in, they would scan the barcode on the pakcing slip, scan the material barcode and store this information in an electronic spreadsheet. The spreadsheet would then be placed on a shared folder on the network and a data processor would attempt to process the returns for the day.  Each return would take approxamately two minutes to process despite the fact that the operator had the order number and the return was almost always a full return, not a partial return.

Over a period of 4 months they had accummulated 6,000 items in the cage that could not be processed or which they thought could not be processed. The issue was now at business boiling point. Aside from the credits issue, the materials were sitting idle in a cage and the cage was now bursting at the seams with boxes of materials that no one knew what to do with.

Solving the software problem seemed difficult, the customization had been done specifically to avoid this type of scenario and wasn't effectively doing its job. We looked at the options for tackling the problem and the most obvious one seemed to be some way of processing the backlog closer to the system, somewhere at a LAN rather than a WAN level. We would solve the software problem but in the mean time we had a more pressing problem, a sea of boxes and no where to put the hundreds more that were being added weekly.

Automation tools to the rescue

We had been using CATT scripts for some time to do 'fixes' to data or to do mass changes of various sorts but as any experienced user of CATT will tell you, working with CATT is far from easy for complex scenarios and more importantly CATT was was developed to help with automated testing not for the purpose that some people repurposed it, namely 'fixing' data. Our support partners evaluated developing CATT scripts for our problem but it seemed impossible to handle all the potential errors that orders would throw our way without spending many days debugging the messages so we looked further afield. We had been exprimenting with a third party testing tool that required minimal development effort but more importantly which easily used input from an electronic spreadsheet and would return positive results or errors in a nicely formatted and structured way. Aft6er several iterative attempts to get the tool to work we eventually settled on a multi pass routine that would cover 90-95% of all scenarios and the remaining 5 - 10% would require manual intervention to get them to work. In a matter of a week we were caught up with our returns processing and all that remained now was a few hundred items that needed the human touch to address them

The prevailing problem remained though, namely that out of every 300 or so returns received per day, a significant percentage would not be able to be processed at the source. The tool we had used to process more than 5,000 records was not a business tool and required the skills of a technically experienced resource, someone knowledgeable about the tool and about SAP. THe months that would follow would continue to be a trying on the patience of all those involved and until the application was fixed we would have to engage an expensive technical resource to support the business on a daily basis to complete what seemed to be a relatively straightforward business activity.

You can never do enough testing

Look back it is easy to see that several measures could have helped to alleviate the situation. We could have engaged in more exhaustive in field prototyping and user acceptance testing of the application. You can never do enough testing and you will always encounter problems after go-live. A proper assessment of the operational environment, operating systems, workstation power, browser versions etc would have revealed a gap here. Training of users was sorely lacking, we could have done with a better operational cheat sheet and nurturing of these new users into go live. Network monitoring was suboptimal, and though products like the the BMC performance agent together with the SAP Solution Manager would have helped us better understand the user context. Finally, the absence of adequate Root Cause Analysis tools on our java elements of our SAP landscape and relative inexperience with these components meant that at a server level at least, we were operationally blind. These facts aside, we didn't have a suitable tool to do mass load of any kind of data and though there were products in the market place, no one thought to evaluate anything that users in the business could use, because we were so busy in the weeds trying to resolve the specifics of the problem.

Mass load tools in the hands of business users

Mass load and business user seem to be word pairs that don't go together yet in reality mass change and IT personnel seems equally wrong. The reality though, is that business, not IT, is constantly maintaining, updating, changing and creating massive amounts of data every day. Some of these mass change and create activities are supported by mechanisms like EDI and custom development and connections to the SAP system but a great many come from users in the business network with their fingers on keyboards.  Today, business often requires such fluid transformation of data that business users can hardly keep up with all the information that needs to be created and maintained. The absence of this data can sometimes impact business severely just as in the example cited above.

The good news is that business users can be saved from this unsatisfactory situation without the need to create complex ABAP programs or develop custom BAPI's  or leverage BADI's to upload and download data from their SAP systems and more importantly, these desktop based solutions can be easily developed, adopted and executed in minutes. There will always be a home for the custom development and there will always be a place for manual data entry however there is a sweet spot between the two that is best addressed by desktop integration tools. Yes, you could use testing tools to fill this gap, there is no doubt that CATT and some third party tools go some way to addressing this however they are generally cumbersome to work with, inflexible to remanipulate or clone and repurpose and more importantly, they are testing tools designed with technology testers in mind, not business end users.

If your business continues to be plagued with operational data entry issues that quite simply come down to insufficient hands on keyboards, insufficient hours in the day and the laborious transcription of data from electronic spreadsheets into screens on your SAP system of record, then consider desktop integration tools that can be used and supported in the business by the business and require no more experience than a basic understanding of electronic spreadsheets and the specifics of SAP transactions.