- Because ERP offers mediocre functionality, it distracts from better functionality outside of ERP.
- Learn why this leads to so much waste on ERP projects.
ERP sets up mediocre functionality at companies, and interferes with buying better software that could provide a great deal of value to the business. I will use several examples in this chapter to explain this prevalent feature of ERP software. ERP implementations result in generic functionality being installed. Then, after the ERP system is installed, other applications that provide better functionality are frequently and selectively used to replace ERP. These superior applications must often coexist with portions of the ERP functionality that are still active.
The Problem with ERP and Intercompany Transfer
An intercompany transfer is when a company buys product from “itself.” While companies make a big deal about being global (and many certainly operate globally), when it comes to fi nance, a company must actually be incorporated in every country in which it operates, and must report to the tax authorities based upon its activities within a country. Thus, when a product (or service—but as this is planning we concern ourselves with products) is sent/sold between two different companies—say an automotive component from Toyota Japan to Toyota U.S.—an accounting transaction must be generated to record that the product has been transferred. This transaction, which is dated and has a transfer price, moves the product from Toyota Japan’s “books” to Toyota U.S.’s “books.” If you search for the term “intercompany transfer” in Google or on Amazon, you will fi nd that most publications on the topic of intercompany transfer are on the topic of intercompany transfer pricing. While accounting transactions are not particularly “relevant” for supply chain movements, they do have to be accounted for so that the supply network design can support the type of activities required on the accounting side. Supply chain planning systems and ERP systems generally have a standard workflow for dealing with intercompany movements, and this will work for simple intercompany transfers. However, as soon as the intercompany transfer becomes even slightly more complex, ERP systems most often require expensive customization. Furthermore, because of the rigid design of ERP systems, this customization will consume many analytical and development hours.
Intercompany Transfer Alternatives
There are two basic ways of handling intercompany transfers: a billing stock transfer order and a standard stock transfer order. A standard stock transfer order (STO) is used between locations that are part of one company code. With a standard STO, no billing document is necessary because the STO is an internal movement. A billing STO combines the document used for internal company movements with the invoicing aspect of a purchase order. This is shown in the following graphic.
A normal stock transfer, transfers goods between two internal locations without any billing.
A billing STO simply performs the same movement, and then performs the intercompany transfer in the ERP system. This is shown in the graphic below:
Intercompany transfer is covered by standard ERP system functionality. It combines an internal movement with billing, hence the “billing-STO.” Billing STOs work for straightforward intercompany transfers. The billing STO is the most straightforward way of transitioning ownership between two companies within one global company. However, it does not even come close to meeting all of the requirements of an intercompany transfer. For instance, some companies have multiple locations that interact with one another during an intercompany movement; while the billing relationship is between two locations, the goods are moving between different locations. Entities other than the receiving location can be involved in invoicing the sending location.
In fact, there can be four or five locations (or possibly more, although I have never seen more than five location interactions). The standard billing STO will not meet the requirement because the billing is not applied to the location that is sending the product. This is a complexity that is missed by those who propose the non-billing STO for every intercompany transfer situation. (I know as I used to be one of those who proposed the non-billing STO for a company that had a more complex need than I fi rst understood.)
Matching Purchase Order/Sales Order for Asymmetrical Intercompany Transfers
To understand this nonstandard approach to intercompany transfer, we will begin by reviewing the standard purchasing goods transfer.
Standard purchasing transfers goods from an external location to an internal location with billing. However, intercompany transfer combines features of both the internal stock transfers and purchasing.
When the interaction between the locations is complex, and there are more than two locations, customization is required. Here the stock transfer goes between locations B and A, but the invoices go between locations A and C.
A custom program is required to take a stock transport requisition (STR), which in this case is created in the external supply chain planning system, and convert it into several documents, such as the Sales Order and Purchase Order pair between locations A and C, and the STO between locations C and B.
Thus, while an STR is created in APO, once it is sent to ERP, that same transaction becomes a purchase order and sales order (which cancel each other out as they are for the same item or items and same quantities. The sales order and purchase order are simply two transactions moving within a company, or should I say two different companies—a company buying and selling to itself but situated in different countries). Let’s review how the two different approaches work.
- Standard Intercompany Transfer: When product flows from an intercompany location A to location B and the invoice flows from location B to location A, a billing STO is the standard and most direct way of managing the relationship between the locations. The external supply chain planning system is unaware that the STO is billing or not billing. Billing is managed completely in the ERP system as external supply chain planning systems do not deal with money. This approach is relatively easy to confi gure.
- Asymmetrical Intercompany Transfer: When more than two locations are involved in the stock transfer relationship, the billing STO is not the way to set up this relationship, as it will place the invoice on the wrong location. In this case an STR is still created within the external supply chain planning system between the sending and receiving locations. However, once this STR is sent to the ERP system, the STR must be converted to matching purchase orders and sales orders. These items will move between additional locations beyond the two that are involved in the stock transfer. A company involved in broad-scale international stock movements will sometimes have different intercompany transfer models. Some of these models mean the creation of a paired purchase order and sales order from a stock transport requisition/order created in the external supply chain planning system. Other movements may require no sales order, and in this case the STO is simply converted into a purchase order.
Controlling Transfer of Ownership in ICO Movement
In most cases, the transfer of ownership will occur when the product is receipted into the receiving location. Although this is the standard workflow for most ERP systems, it does not meet the requirements of all companies. Some companies want the ownership transfer to occur after the product has left the sending location but before it arrives at the destination location. I have found this to be true particularly of transfers with very long lead times, such as ocean carriage.
The graphic on the following page shows the standard transfer of ownership versus the custom alternative.
The first alternative is preferable as it is in line with how many external supply chain planning systems and the ERP system operate. However, for different reasons, some companies prefer the second alternative. Because the transfer cannot be performed while the product is in-transit, an intermediate location—which is not an actual physical location but is a virtual location—is sometimes set up in order to perform the transfer.
The Core Problem of Limited Dimension Transactions
The issue that companies face when attempting to manage complex requirements of this type is that the ERP system is too limited and too infl exible to be adjusted. Instead of prescribing a limited set of functionality, ERP systems could have been designed quite differently. We use the terminology of STO, non-billing STO, and billing STO. All of this terminology really just describes transactions that behave differently in a dimension where the transaction impacts the ERP system, as shown in the graphic below:
A transaction is nothing more than a container that initiates a series of related transactions— which change the state of the ERP database in prescribed ways. Rather than prescribing a limited number of ways that a transaction can behave in a particular dimension, one can open up the options, and this can be accomplished with far less complexity and without the confusing terminology. It is unclear why so many ERP systems took such a prescriptive approach when developing the software in the first place. Perhaps they lacked the development sophistication to make flexible systems and wanted to reduce the costs of development. Creating a system of more limited behavior within the dimensions of a transaction saved development effort and money in the short term, but is ultimately a poor trade-off. The software must be customized per client location, resulting in a great deal of redundant customization (because the same customization, or at least very similar customizations, must be performed in a decentralized fashion at implementing companies). In case the point is elusive, this is exactly what has happened with ERP systems. An alternate development approach is to decompose the transaction to its behavior per dimension, provide an initial set of common dimension combinations, and allow the transaction to be easily extended. This can happen by simply copying over a pre-existing transaction variant and making a single change to a dimension behavior (or to multiple dimension behaviors), resulting in a new transaction variant. An example of this is shown below:
The total library of the transactions categories and variants within those categories constitutes the total of the functionality within any ERP system.
What I have described above would be the perfect scenario, but ERP systems were not designed this way. And because of their transactional inflexibility, the tight integration of their modules means that they restrict the ability of companies to fully leverage the functionalities in applications that are connected to ERP systems. Thus a company with an ERP system will receive less value from any other application that they implement (unless the application is extremely simple) than a company that does not have an ERP system. This is one of the major reasons why most ERP systems are either a dead end—or simply a starter kit setting a company for much more expense and work down the road.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
The Real Story on ERP
How This Book is Structured
This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.
ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.
Break the Bank for ERP?
Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.
By reading this book you will:
- Examine the high failure rates of ERP implementations.
- Demystify the convincing arguments ERP vendors use to sell ERP.
- See how ERP vendors take control of client accounts with ERP.
- Understand why single-instance ERP is not typically feasible.
- Calculate the total cost of ownership and return on investment for your ERP implementation.
- Understand the alternatives to ERP.
- Chapter 1: Introduction to ERP Software
- Chapter 2: The History of ERP
- Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
- Chapter 4: The Best Practice Logic for ERP
- Chapter 5: The Integration Benefits Logic for ERP
- Chapter 6: Analyzing The Logic Used to Sell ERP
- Chapter 7: The High TCO and Low ROI of ERP
- Chapter 8: ERP and the Problem with Institutional Decision Making
- Chapter 9: How ERP Creates Redundant Systems
- Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
- Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
- Chapter 12: Conclusion