When you are in the middle of a project go-live, providing first-line hyper care support, within the chaos surrounding you, requirements for BRF+ complex decision making will emerge.
Many clients are not aware of the Business Rule Framework, therefore not considering this tool to prevent chaos mainly because the focus is on “going live” as fast as possible, often bypassing proper user acceptance testing and cut-over testing. Especially interfacing will be difficult to test as it requires assistance from the third parties connecting their test environments to yours. The more external systems and different types of interfaces, the more likely all pray that “all will be fine” in a production environment. The level of panic will only emerge when customer orders cannot be registered, and you need to hire temporary staff to process them manually. Also, manual activities in the system will be required when communication to and from the distribution centres are triggering loads of errors.
The faults when processing interfaces can have root causes in many, sometimes unexpected, areas. Here a list of potential reasons why interfaces cannot be processed successfully:
- Missing system configuration
- Incomplete master data
- Incorrect mapping rules
- Misaligned transactional data between sending and receiving system
When moving stock from A to B, then you need to configure the system these locations are set-up to store the inventory. You might initially point to missing master data, but also system configuration requires attention. Absent customising probably emerges when you want to execute intercompany billing transactions. These are easy to fix, but requires immediate action and testing in quality assurance environment before deploying into the production system. This delay might prevent solving the blocked transactions before month-end closing. So you can avoid this obstruction by analysing sales orders, purchase orders and production orders and predict the required system configuration to allow flawless completion of the end-to-end business process. You can use BRF+ to design an early warning system to enhance missing settings before the stoppage in processing the intercompany billing will occur. This usage of BRF+ will only add value within a rapidly expanding business.
Almost all SAP ERP system will struggle with incomplete master data, so the power of the Business Rule Framework comes into its own. Preventive master data checks based on transactional data is easy to implement. You can run overnight batch jobs to analyse the recorded transactions in the system and check if potential issues could occur soon. Think of missing packing material for an end product, allowing creating the sales order and delivery but blocking post goods issue and customer billing. Also, you can expect problems with batches when you perform a stock transfer when no batch master data exists for the receiving distribution centre, preventing goods receipt.
Unnecessary complex mapping rules within interfaces can occur when doing mergers and acquisitions. No SAP system is the same, because you can easily extend the standard with custom-built solutions. When you buy a division within a large organisation, you also inherit complex decision making within the legacy SAP system. This complex decision making will be within the mapping of the interfaces. When you do not allow sufficient time to analyse the existing legacy mapping rules, then you can get some surprises. These issues are especially challenging to interpret because the decision making within those mapping rules is not related to your SAP system configuration. Integrating BRF+ within the interface mapping rules can add value, allowing you to be flexible to re-evaluate the inherited mapping rules. In time you can construct the BRF+ functions in such a way that the old mapping rules become obsolete.
A common issue is the misalignment of stock data between the ordering system and the stock storage systems. It is not always that clean-cut to assume that the stock storage system will have the most reliable data, even though you expect that data to be accurate and complete. You also struggle with an always moving target, as stock movements happen throughout the day, especially on a 24/7 operating warehouse. You can take snapshots of stock between two systems and then validate the stock levels, assuming that all goods receipt interfaces are processed successfully. Keep a close eye on those products for which less stock is available for sales in the ordering system, as that is the most likely reason for goods issue interfaces to fail. The Business Rule Framework is an ideal tool to analyse the snapshots of stock levels from both systems. You can quickly react to new insights when interpreting the available data. You can also identify products in high demand and isolate them to fix potential stock differences, avoiding interface failures.
The robust simulation capabilities within the Business Rule Framework, and the ability to collect data directly from the SAP database, allows you to build programs very quickly to test the complex decision making. You do not need a lot of resources from developers to create prototypes. You can quickly transform these prototypes in stable definitive deliverables you can deploy into the production system.