Skip to Content

In previous blogs I mentioned that the majority of customer systems show significant potential for stabilizing and improving the existing business processes (Protect your SAP ERP investment & improve your core business processes). I also highlighted inTraditional Business KPI approach vs Business Process Monitoring that the bottom-up approach with Business Process Monitoring and Business Process Analytics complements the typical business KPI reporting activities from customers, which are top-down approaches. Now if you look at the problems highlighted with the BPMon key figures it is not always business critical problems. Actually you can typically cluster the problems into two areas – systematic problems and real exceptions. The systematic problems are often representing inefficiencies on how you operate your business processes and hence they are often not directly impacting your business processes, but they can at least indirectly impact your porcesses as already outlined in the blog Protect your SAP ERP investment & improve your core business processes. The real exceptions on the other hand have typically a direct impact on your business processes, e.g. you are delivering late or you get your money late. Hence these exception are impacting your company goals like customer satisfaction or revenue targets and thus your effectiveness is hampered. In the remainder of this blog I want to take one concrete example of a Business Process Monitoring key figure (Overdue Sales Orders, i.e. sales orders with open/not delivered schedule lines where the respective planned GI date lies already in the past) and explain the difference between systematic problems and real exception in more detail. As a conclusion you should better understand how you can improve the efficiency and/or the effectiveness of your business processes accordingly.

Possible systematic problems leading to inefficiencies

Systematic

The following bullet points show typical systematic problems that we see in customer systems when we analyze the output results of the key figure for overdue sales orders

  • One root cause is often related to bad Master Data quality, i.e. there are still inactive sales organizations or document types in the system and as nobody works on the corresponding documents any longer they remain in the system as backlog documents.
  • Another root cause is often related to “wrong” customizing, e.g. a typical configuration mismatch between item category (no delivery expected) and schedule line category (delivery expected). At the end the system expects a delivery to be created due to the schedule line category configuration although no delivery is expected from a business perspective. As the business does not expect a delivery the corresponding sales order remains open from an SAP system perspective.
  • Especially in industries where large quantities (volume wise) are sold (e.g. concrete, cement, sugar beet, chalk) it often happens that not the full quantity is delivered, so that always a small fraction remains open (e.g. 28,5 tons or 29,3 tons are delivered instead of the ordered 30 tons). Business-wise this might be okay and the remaining quantity might be delivered the next time but from an SAP system perspective the remaining quantity is still expected to be delivered. In this case the remaining quantity needs to be rejected respectively which might require additional end user training.
  • Another root cause might be related to a functional error that got transported into the productive environment so that certain sales orders could not be processed in the past (until the error was resolved) and the documents remained open in the system.

All these root causes are usually not business critical but represent inefficiencies that should be avoided. Old and not delivered sales orders remain in the so-called delivery due index table VEPVG and hence can have a negative impact on the performance of your delivery due list runs. All open sales orders can of course not be archived and hence the performance of several sales transactions and ABAP reports might decrease unnecessarily over time. Some BW extractors only extract those data where the document is fully processed. So open sales orders might not show up in your business reporting. At the same time inactive sales organizations should most likely not show up in your business reporting. So as long as this data is not removed from the respective backend system, additional and unnecessary rework might be required on BW side in order to “clean-up” the BW reporting. Depending on the root cause, the material/plant combination in the respective open sales order might still be considered as open requirement, i.e. supposed issuing element in your ATP checks or in your MRP run, hence leading to wrong ATP decisions and inaccurate supply chain planning.

Possible real exceptions leading to ineffectiveness

Exceptions

Once the systematic errors are eliminated it is much easier to gain transparency over the real (business) exceptions which might cause real delayed customer deliveries. This can then result in decreasing customer satisfaction and delayed or even lost revenue. As this might directly deteriorate your company’s business goals, these exceptions should be avoided or at least resolved as fast as possible which would lead to an improved business process effectiveness.

Taking the same key figure example as before we often see the following different root causes:

  • The maintained Master Data in the system could lead to committed delivery dates (proposed by the system) which can never be met from a business perspective. Hence the customer has to wait for the goods longer than what was committed/promised to him.
  • Some end users are perhaps not properly trained and hence forget to provide all necessary information in a sales order that is required for further processing in subsequent process stages (keyword: incompletion log). Depending on the configured incompletion procedure the delivery processing might be blocked due to the missing field(s) in the corresponding sales order
  • Some sales orders might be created/replicated automatically via IDoc and/or background job. So if technical errors occur during the IDoc or job processing this might delay the overall sales process
  • Last but not least there might be real business exceptions which are causing a delayed sales order delivery. Perhaps the requested material is out of stock or there are real delays in the picking process within the warehouse or delays during the physical transportation occur as a truck or ship broke down.

You see how diverse the identified problems can be that you find with just one single key figure. If you want to learn what other key figures are available you can follow the previous blogs listed below, especially those with “New ky figures” in the title.

Further reading

You can find all necessary information about Business Process Analytics in this document.

Frequently Asked Questions about Business Process Monitoring and Business Process Analytics are answered under http://wiki.sdn.sap.com/wiki/display/SM/FAQ+Business+Process+Monitoring andhttp://wiki.sdn.sap.com/wiki/display/SM/FAQ+Business+Process+Analytics respectively.

The following blogs (in chronological order) provide further details about Business Process Monitoring functionalities within the SAP Solution Manager.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Dionisio Bustillo Galvez
    First at all, thanks for your great contribution Volker

    We are currently auditing a SAP system with a lot of inactive (not to say useless) data in our production environment (doc. types, account groups, companies, tax codes, etc). As you pointed out we believe this is error prone.

    We are in a huge deployment with many teams working in our development system, and we are not sure how to proceed.

    If we delete master data from development and transport it to production, consultant won’t be able to use some data as template in the future.

    Should we open the productive client and delete all templates and inactive master data directly?

    Is there any SAP recommendation for this matter? We are stating with this and I’ll appreciate any advice.
    Thanks so much.
    Dionisio

    (0) 
    1. Volker von Gloeden Post author
      Hi Dionisio,

      Thank you for the good question. Unfortunately I cannot provide a general Best Practice advise in this area.
      In the cases that we mainly encounter it is most important for the customers to first close all related open business documents before deactivating some master data. After closing the documents they are archiving the documents accordingly. Only if the documents are properly closed (and possibly removed from the system) then the customers are deactivating the corresponding master data. Typically the data is deleted in dev and then transported. Direct changes to the productive client are avoided whenever possible.

      Best Regards
      Volker

      (0) 

Leave a Reply