TOC Measurements with SAP Part 2

This is the second part of the first post TOC Measurements with SAP Part 1

Let´s continue with the second measurement OE (Operating Expenses)

OE (Operating Expenses):

The definition says that OE = all the money in the system that is spent in turning the investments into throughput. Again, there are plenty of procedures to get to these numbers. I chose the following approach with G/L accounts. (See Transaction FS10N).

     There are two selection options for accounts in my report. The first one is for accounts for investment(I) and the second one for operating expenses(OE). The reason is these accounts are needed for both measurements. The function module(FM) BAPI_GL_ACC_GETLIST delivers all accounts in the company which are then reduced to our selected accounts. See coding:

The next step is the loop sequence on the table with accounts and each account is evaluated with FM BAPI_GL_ACC_GETPERIODBALANCES. Values are added to columns with OE or I depending on the selection above. See my methods:


This section is about OE but we gain in this approach as a side effect also a part of Investment at the same time and therefore let´s move on Investment(I).


I (Investment):

The definition is that I = all the money the system invests in purchasing items the system intends to sell. In a simple way, it has two parts: Inventory (all materials) and Assets (machines, buildings etc.). Now, after having T and OE in place, we can use previous methods for building value for I. We have already got assets as a side effect by evaluation of OE. Now we have to add inventory in TOC sense and that means for unfinished goods and finished goods only their TVC part (without adding the value of direct labour). For raw materials, its price and quantity for the time period are stored in table MBEWH. In the same table are stored time period, quantity and price for unfinished and finished goods. That price must be replaced through TVC for one piece multiplied by quantity. TVC comes from the same method as in the case for T. See the complete coding:




Having all three parts(T, I, OE) in one table, we can assess NP(NetProfi) and ROI(Return on Investments), or Productivity and Turns as shown at the beginning of this miniseries. It was the goal of our project, an easy way to evaluate the overall performance of a company according to TOC.

  I would appreciate any feedback especially if you use SAP in a combination with the Theory of constraint.

TOC Measurements with SAP Part 1


The topic of this blog is to show you how SAP ( in my case ERP ECC 6.0 ) can be used to get the right data for performance measurements, which are used in TOC ( Theory of Constraint ). These measurements consist of T (Throughput), I (Investment) and OE (Operating Expense). My main goal is to direct you to where and how to obtain data from (out of) SAP. A detailed examination of TOC and it’s TA (Throughput Accounting) is beyond this post. You can find a lot of information on the internet and books related to this subject.

The Goal:

There was a project in our company to improve financial control processes of the whole company and to simplify it. It was decided to take an approach from TOC and its Throughput Accounting (TA) by using its measurements T, I, OE for evaluating the company´s performance. These are the basic values and from these, you can gain e.g. NET PROFIT (T – OE) and RETURN ON INVESTMENT ((T – OE) / I) or PRODUCTIVITY (T/OE) and TURNS (T/I). Unfortunately, there is no standard way in SAP ECC 6.0 to get this data directly. Let me demonstrate a way of how to gain our measurements for a time period of a month:


T = Revenues – TVC (Totally Variable Cost – mostly just raw material)

There are at least two possible ways how to build it. We have to start with sales. Fortunately, there are LIS – Infostructures with revenues in time periods such as S001 and others.

See picture…

In my case, it is the infostructure S660. Now with data (Month, MaterialNumber and Sales) for building our throughput (T) value we have to get the second part of the equation and this is TVC (Totally Variable Costs => in our case raw material) One way is to break down to all these component(raw materials) of the product in BOM ( Bill of Material) with the function module CS_BOM_EXPL_MAT_V2 and then find out their price in the time period (tables MBEWH / MBEW) or another way is to use calculations (tables KEKO + KEPH) for the product in that time period where TVC is available. I created for TVC a cds view.

See code:

Now we have everything needed for our equation for Throughput and we can sum all products sold in a month in one T in a time period. Here are my methods as for an example:

In the next part, we will look at how to build OE and I and how we use them for performance evaluation.

Best Regards


Find the constraint

capacity evaluation in PP

The topic of this blog post is to show you how can SAP PP help you to find the constraint on the shop floor.
If you use ToC (Theory of Constraint) in your plant or you would like to or you are at least aware of ToC and its principles then you know that its keystone is knowing your constraint. How to find a constraint in your production using SAP, that is the topic of my post.

In SAP PP there are standard transactions for capacity evaluation and planning like CM01 and other CMXX transactions using actual data and CM38 for Planning Scenarios. Working with these TAs to get the overall picture about the distribution of capacity loads and overloads across the entire plant is quite challenging. That was the reason I decided to build my own tool which I could customize to my own requirements. From the beginning of my journey, I was trying to use SAP function module CY_FILL_KUBEL. Without having the right documentation, it was hard and almost impossible to get what I wanted. Eventually, I decided to take another approach.
In the coding below you can see my way through with all needed notes. The function of the code is very simple and straightforward. Through parameters you can select capacity IDs and the time area (from, to) you are focusing on. Then it provides the basic tables for each selected ID with available capacity for time period chosen above and with a time grid selected by the parameter p_peart ( Methode get_available => FM ‘CR_CAPACITY_PERIODS’ and ‘CR_CAPACITY_AVAILABLE_PERIODS’ ). You can choose whether to go on with a sum from the table (as in my case) or to use load_tab for details according to your preferences and time grid. The next method provides a sum of all capacity requirements for the capacity ID and time area (expanded by backlog, which is set by the parameter p_back) using the internal table lt_kbeds. The function module ‘CY_AMOUNT_KBED_COMPUTE’ provides the exact amount of the duration for each working step according to settings in work-centre master data. In the last step, the sum of capacity requirements and available capacity are divided to get the percentage of the capacity load.

Here is my coding….

If it is run through all your capacity IDs you can get the ID with the highest load for the time interval which shall be than your constraint you are looking for. With this constraint, according to ToC, you can proceed to 5 focusing steps where SAP can help you too. But this topic is for another blog post. 🙂


SAP and the Thinking Process

Building stronger Current Reality Trees

Part II


In this article, I´m going to continue on the topic started in part one. As mentioned in the previous text, SAP can support you very well in constructing Current Reality Tree. Now we will continue with the next two examples.


to remember, we are talking about the same tree as in part one

Current Reality Tree

Entity nr. 124 says: “We have an unnecessary inventory”. There are many ways to mininge the data from SAP to support this claim. You can gain the sum of the value kept in your inventory and WIP (work in progress). For these purposes, SAP provides its own standard transactions. But there can be another point of view. If one of your problems, whilst you are constructing a current reality tree, is lack of capacity, then it is useful to examine how much capacity ( or time ) is held in your inventory. Of course, there could be other reasons for doing it in this way. This approach is not difficult. The first step is building an interval table with materials and their current inventories. The next step is delivering all needed times for producing these from their working plans. The last step is calculating the desired result.

Here is my coding example:

Entity nr. 124 says: “We are measured according to local optimum” This is, unfortunately, the most common way how companies evaluate their productivity for a plant. From my point of view, the reason is “ it has always been done this way” and it is easy to understand and calculate. But in fact, almost nobody cares, that this approach is flawed. An explanation of my statement is not the aim of this article, but you can find it in The Theory Of Constraint. The old way for the productivity evaluation goes like this, but it can differ from plant to plant: In my example, each worker is assessed in a particular period of time. Its productive times are gathered from the DB-table AFRU and then compared against its attendance.

Here is the ABAP class for this action :

As you can see, there are plenty of ways how to mine data from SAP for supporting facts not only for the use in current reality trees but for other processes which need some facts for decision making. In this two-part article, I have shown options and approaches how you can do it and I hope SAP will help you in your own quests.


SAP and the Thinking Process

Building stronger Current Reality Trees


In this article, I´m going to show you how SAP ( or other ERPs ) can help you in building your own CRT ( Current Reality Tree ) from the thinking process approach. I won`t cover how to build CRT here. It isn´t my aim now, however, there is a lot of information available on the internet. I´ll focus on one particular aspect needed for constructing CRT, on getting data and facts from the SAP to support entities existence.


In my day to day practice, I use the approach from H. William Dettmer as he calls it “The Logical Thinking Process”. For more details see his great book The Logical Thinking Process – A Systems Approach to Complex Problem Solving. There are tools for constructing CRTs called Categories of Legitimate Reservation: Clarity, Entity Existence, Causality Existence, Cause Insufficiency, Additional Cause, Cause-Effect Reversal, Predicted Effect Existence and Tautology. The second of them is the Entity Existence with its three conditions: Completes, Structure and Validity and just the validity is exactly the point where SAP can help you to gather the needed facts. As Dettmer writes on page 38 ”…Validity is normally established by evidence. Logic tree quality is improved dramatically if documented evidence of cause and/or effect can be produced. This helps avoid speculation or invalid assumptions about causality…”. SAP can support you with the needed data.


Let´s go through my example. On the diagram below you can see one particular branch from my CRT inclusive entities notes. I don´t claim it is perfect and can´t be improved, but for the purpose of finding out all root causes is it sufficient.

My Current reality tree:

Current Reality Tree

Round Box Entities
• cause101 – a part of orders are produced too late to due to dates
• 102 – some customers don´t accept later dates
• cause102 – not all requirements are available as needed
• 103 – We start later than needed in some cases
• 104 – there is no way to reduce the production time
• 105 – there aren´t alternatives for those requirements
• – during the production process strikes Murphy
• 107 – there is no way to reduce the production time
• 109 – We don´t have enough capacity at the right time
• 110 – We don´t know exactly all demands beforehand
• – Future is unpredictable
• 112 – We´re not proactive with customers
• 114 [L] – We don´t know exactly all demands beforehand
• 117 – One way to be efficient is to reduce setup time
• 118 – Workers merge orders
• 119 – We move actual orders back
• 120 – We use capacity for not actual orders
• 121 – The sum of needed time is sometimes higher than available
• 124 – we have unnecessary inventory
• 125 – We have a backlog
• 126 – We have some overloaded resources
• 127 – We have not the right buffer (Capacity/time/material)
• 128 – We plan our capacity due to history and forecast
• 129 – we plan our resources conservative
• 130 – All resources must be producing all the time to be efficient
• 131 – Plan in CZ must be > 0.
• 132 – some actual orders are planed over available capacity
• 133 – We don´t have the right planning tool to see overloading
• 134 – We DO have the right planning tool to see overloading
• 135 – We ignore overloading
• 137 – We are scared there will be lack of orders for all resources
• – We have some rules to ignore available capacity
• 139 – we plan our capacity as a sum
• 140 – There are big differences in workloads of resources; 50 %
• – A buffer means an idle resource
• 144 – We don´t want idle resources
• 147 – We all believe in local efficiency
• 148 – There are resources with a lower load than the bottleneck
• – We have not totally balanced production
• 150 – we are measured due to local optimum
• 151 – there are no other rules

Here is the German version…………………….

Round Box Entities
• cause101 – Wir produzieren manche Aufträge später als kundentermmin
• 102 – Manche kunden akzeptieren kein Verzug
• 103 – Wir fangen in machen Fällen später an als benötigt
• 104 – Es gibt keine Möglichkeit für Reduzierung der Fertigungszeit
• 105 – Es gibt keine Alternativen für diese Anforderungen.
• – Während der Produktion erscheint Murphy
• 107 – there is no way to reduce the production time
• 109 – Wir haben nicht genug Kapazität in der richtigen Zeit
• 110 – Wir kennen nicht alle Bedarfe Voraus.
• – Die Zukunft ist unvorhersehbar
• 112 – Wir sind nicht proaktiv mit unseren Kunden
• 114 [L] – We don´t know exactly all demands beforehand
• 117 – Eine Möglichkeit für Efektivnes ist Reduzierung Rüstzeiten
• 118 – Wir fassen Aufträge zusammen
• 119 – Wir schieben aktuelle Aufträge nach hinten
• 120 – Wir nutzen Kapazität für nicht aktuelle Aufträge
• 121 – Die Sume für die benötigte Zeit ist höher als vorhandene
• 124 – Wir haben unnötige Bestände
• 125 – Wir haben Rückstand
• 126 – Wir haben manche überlastete Quellen
• 127 – Wir haben nicht den richtigen Puffer(Kapa/Zeit/Material)
• 128 – Wir planen unseren Kapazitäts-Bedarf nach Vergangenheit
• 129 – Wir planen unsere Quellen konzervativ
• 130 – Alle Resourcen müssen laufen/ Wir wollen Efektivnes
• 131 – Plan in CZ muss sein > 0.
• 132 – Manche aktuelle Auftäge werden überplant über vorhandene Kapazität
• 133 – Wir haben nicht den richtigen Plannungswerkzeug
• 134 – Wir haben den richtigen Plannungswerkzeug
• 135 – Wir ignorieren Überlastungen (kapazitiv no go)
• 137 – Wir haben Angst, daß in Zukunft weniger Aufträge sein werden.
• – Wir haben Regeln für Ignorierung vorhandene Kapazität
• 139 – Wir planen unsere Kapa-Bedarf in Summe
• 140 – Es gibt goße Unterschiede unter verschiedenen Resourcen; 50 %
• – Ein Puffer heißt ungenutzte Kapazität
• 144 – Wir wollen keine ungenutzten Kapazitäten
• 147 – Wir glauben in lokale Efektivität
• 148 – Wir haben Resourcen die nicht voll ausgelastet sind.
• – Wir habe keine komplet ausgewogene Fertigung
• 150 – Wir sind nach lokalen Optimum gemessen = Leistung
• 151 – Wir haben keine andere Regeln
• 401 – Nicht alle Materialen sind vorhanden in Menge und Qualität wie benötigt
• 406 – Wir produzieren mache Teile im Vorlauf
Undesirable Effects
• UDE100 – Liefertreu ist 50%


Let´s follow each entity for supporting facts which can be gained from the SAP in my case.

Nr. UDE100 says: Delivery performance is about 50%. I suppose each company has its focus and priority on that measurement and has a tool to follow it. In another case, you can get those data from SAP using DB tables VBAK, VBEP, VBAP, VBFA, LIKP, LIPS. I won´t go deeper into how you can build an ABAP program to calculate delivery performance. Firstly it should be easy for an experienced developer and secondly, every company can have its own methodology for calculating its delivery performance.

Nr. 118 “Workers merge orders”: As usually in SAP, there are several ways, to support this statement with facts/data. As an example see coding below comparing production orders with planned orders according to the material number.

Here is the ABAP class for this action :

Nr. 126 “We have some overloaded resources” and Nr. 140 “There are big differences in workloads of resources”: Again, there is not only one option for mining data. I chose the following approach with function modules CR_CAPACITY_PERIODS and CR_CAPACITY_AVAILABLE_PERIODS. See method get_data_for_his_db

Here is the ABAP class for this action :