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?
No comments:
Post a Comment