Another success story - Keeping the core clean

SAP is telling us SAP consultants to 'keep the core clean'. This means in short: don't change the SAP system in ways that will make it harder to maintain (think: upgrade/convert to the HANA platform/move to the cloud). Whilst promoting this mantra, SAP is steering its customers towards side-by-side builds in the cloud, using its middleware platform for integration.  Here is a story where we did keep the core clean without introducing external development platforms and middleware.

Our customer was running operations in 400+ locations. Each location was run by a subcontractor. The contractor was paid based on the number of transactions going through the till. Historically, most locations were actually operated by salaried employees. Hence the situation we encountered was one where an HR system had been modified over and over again to enable it to pay employees as well as contractors. The most obvious challenge was VAT, which is a completely alien concept in the world of HR. The HR system had gotten so 'dirty' that the cost of operating it had spiraled out of control and worst of all, it took 40 hours to calculate the payroll. This meant that there was no time to correct mistakes in the current month's run and all mistakes had to be carried to the next month to be corrected. This situation led to mistakes upon mistakes upon mistakes.

We looked to replace the HR system with a solution to calculate the pay in a cloud platform but realized the ongoing license cost would be considerable and the build would be out of our hands and hence very costly too. Additionally, we would need to send sensitive data into the cloud.

Our customer was already running the Netweaver platform. We decided to maximize its value. Our approach was to bring all transactions from the sites (1M+) into a central table every night via file upload. We then built some summarization logic into a second much smaller table, summarizing the transactions by type and location. This job takes about 12 minutes. A second job calculates the pay for each subcontractor based on the summarized transactions. The result is available in 15 minutes!(compared to 40 hours previously). The resulting figures are then passed to standard vendor invoices.

So in the end we built an ABAP solution in Netweaver that does exactly what's required and because it is bespoke, it was running with optimal performance. The solution sits on top of MM and FI and does not modify the core of SAP. In terms of upgrading or converting to HANA, this poses zero problem.

An SAP success story on keeping the core clean

 I often read that people question the concept of keeping the core clean with the argument that SAP does not cater for all variations of possible business processes.

Of course the argument is very valid. SAP does not cater for every possible business process variant. How could it? In my career I have encountered this issue many times and in a few cases I was lucky enough to be part of a strong team that overcame the issue without ‘dirtying the core’ of the SAP system (we didn’t call it that at the time). This blog is about one of those times.

I’ll call the customer H. H holds stock of very precious materials in consignment for its 200+ customers. These 200 customers trade their stock among each other without the stock actually physically moving. H charges its customers for looking after their stock and also for each trade they do. It is extremely important that H can tell at any point in time who owns each stock item. H’s customers can deliver more stock to H’s warehouse or they can collect stock from the warehouse. They announce these transports well ahead of time so they can be planned meticulously. H spends a fair bit of time reorganising the stock in the warehouse to optimise the operations. It has to be noted that moving a stock item is quite hard and the storage space is very valuable. It happens regularly that stock changes owner whilst being moved around in the warehouse at the same time. But for H it is absolutely key that at all times all stock items are accounted for in terms of owner and location.

We realised early on that we had a problem tying customers to stock in the way we needed. Standard SAP assumes that you are the owner of your stock, and rightfully so.

We decided that the best way was to use the following standard components:

- The SD and FI modules for customers, pricing and customer billing

- Project systems to tie the stock items to projects and enable us to move stock between customers (effectively between projects)

- MM, WM and Inventory management to keep track of stock location and stock items

The only thing we had to do non-standard was tie a customer to each project. And so the only user exit we implemented was to prevent users going into the PS module and interfering with the link between the project and its customer.

All user screens are bespoke and do only and exactly what H wants including a ton of validations and controls. Building screens and lists in SAP is not hard. ABAP was designed for that. The end users do not see a single SAP term, everything they see is in their domain language. They don’t know the system is using projects, that’s completely hidden.

The trades are stored in a bespoke ABAP table as nothing in standard SAP comes close to holding the information we were dealing with. An ALV list report with a few buttons were enough to manage the trades. 

Other than that, we developed zero enhancements, users exits, etc. It was heaven. All code is in the right place and squeaky clean. This system has now been moved to the HANA platform with zero hassle, because we kept the core clean.

There were some other things about this project that made it such a success.

At the beginning of the project we received specifications that were incomplete and confusing, as the customer with no knowledge of SAP’s capabilities and little to no IT project experience was desperately trying to define the solution in every minute detail…as instructed by top management. I’m glad to say, we managed to gently refocus the customer on telling us about their business and processes and stop worrying about the solution. Using weekly incremental demos we built the entire solution faster than anticipated. The bespoke screens proved to H that we were listening to them and had understood their needs. Trust grew between us and H and that is without a shadow of a doubt the number one ingredient for a successful IT implementation. The collaboration was fantastic. Worries about budgets and timelines slowly moved to the background.

Yes, we developed a fair amount of bespoke code. Many people fear this. I believe it was around week 5 that we were told that all stock was moved using pallets. The customer had failed to mention that as it was ‘obvious’ to them. The word pallet did not appear anywhere in the spec. Luckily because the ABAP code was organised around properly structured classes representing real business objects, we had little trouble inserting the concept of a pallet into what we had built so far.

In all the time that this solution has been in operation, there have only been a handful of helpdesk tickets for it, mostly on cosmetic things. Because the solution runs inside the existing SAP Netweaver/HANA server we saved a ton of time and money by not having to install/procure additional kit and build integrations. Perhaps this was an side-by-side solution built inside?

When your customer wants you to implement workflow…

 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.