One of the bugbears that I have encountered during my professional career is the ability for managers to accept a lousy solution. They even coined a specific term for it: technical debt.

Let me explain how this works. The business users want a new feature in the system. Let us say for the sake of argument that it is the automation of specific tasks when saving a sales order. In the beginning, the requirements are straightforward and seem like a small development. The proposed solution is extending an existing user exit when saving the sales order, triggering a specific program as a batch job to perform the various automated tasks.

From the start the scope was limited, only focusing on creating a production order and a stock transfer order when the production plant differs from the delivering plant.

Luckily the transformation of a sales order item into a production order already has a dedicated custom transaction, so the new program to automate this step was to execute this transaction, when applicable.

So far, so good.

That project started over one year ago, and it was still not deployed. So what happened?

First of all, the requirements change all the time. It is a moving target. Every time you believe you covered all possible business processes, a new one surface and impact the existing code.

Secondly, the choice to use job scheduling backfired. As you only have limited slots to run batch jobs (for example 15 batch jobs can run at the same time), during busy hours, there are not enough slots to create the production order as soon as possible. Quickly a queue builds up in the system, triggering a delay.

Furthermore, when also a stock transfer was required, the timing to generate this purchase order is essential. The requirement is only to create this procurement document when the production order exists. This dependency is vital because you want to calculate the correct lead time to arrive at the delivering plant. Creating the purchase order too early triggers unreliable delivery dates in the sales order.

Finally, things can change. After creating the production order, capacity planning can force a change in the estimated finish date of production. Whereas initially, the development of this entire solution focuses on the “blue sky” scenarios, the nitty-gritty business cases for changing dates until production is released triggers delays in acceptance testing of the whole solution.

As time passes, and both business users and IT support team lose the momentum to create a reliable and robust and flexible solution, the IT manager approved the imperfect current for deployment into the production system. In the meanwhile, new insights emerge for a better approach, and a new project starts to make improvements.

The deployment of a flawed solution happens all the time at every company. The incentive to deploy a superior resolution does not always get delivered. As time goes by, and the business users learn how to deal with imperfections, the need for a better solution becomes less critical. The day-to-day struggles take over and fixing the incomplete deployed solution consume the IT team resources. Before you realise what is happening, handling defects triggered by a lousy solution counteracts the ability to build a superior solution.

Now, how can the Business Rule Framework avoid the deployment of faulty custom solutions?

One observation is that the IT team underestimated the overall business requirement, not asking upfront all the potential scenarios in scope for acceptance testing. It would have highlighted the various day-to-day struggles to acknowledge to the client when the ordered goods will arrive at their warehouse. The interaction between the sales, manufacturing and procurement departments will then become more evident when there are capacity constraints when planning production.

You deal with a continually changing environment, where the sales order, production order and purchase order have to change. As soon as you realise this, then trying to capture shifting dates due to specific events within the ABAP code will become messy and potentially impossible to control. It is much better to deal with the necessary flexibility with BRF+ functions. Let the ABAP code outsource the decision making and only manage to supply of data and handling of the returned result.

Simulation is one of the powerful tools of the Business Rule Framework. You can build a prototype and discuss all possible acceptance test scripts with the business users before a single line of code is written. You might conclude that you change the estimation for the effort required to deploy a fully workable solution.

Decision making via BRF+ has as an advantage that it can execute its functionality when ABAP code is accessed. When you realise that job scheduling is not the preferred method to perform a task, then you can easily switch to trigger an event with workflow tasks instead. The decision making remains identical, just the technical approach to execute the functionality differs.

Embracing the Business Rule Framework will save you time and will prevent the likelihood of deploying technical debt.

And if a wrong solution exists in your SAP system, BRF+ is the perfect tool to implement a superior alternative much faster than the traditional development strategies that got the technical debt deployed in the first place.