In the capital accounting arena that we specialize in, there are two options that we consider for the cost capture piece of the process. Those two options being an Internal Order or a Project (WBS/Network).
Why these two? Well, the big reason has to do with their fundamental purpose and the many similarities that they share. Let mes quickly cover what those similarities are and then reveal what SAP’s plans are for them going forward.
Comparing Orders and Projects
Before I get into the order vs. project debate, I have to back up and talk about a cost center. After all, since I’m covering these major cost objects I can’t possibly ignore the cost center. There’s a key characteristic of cost objects that I use to differentiate between these cost objects.
A cost center is a semi-organizational unit, assigned to a hierarchy and generally represents a permanent entity such as a department, facility, or office location. In theory, if an organization never changes than the cost centers and the hierarchy won’t either. Even though cost centers are so prominent, they actually don’t have much functionality so they aren’t good at handling complex requirements or advanced posting logic. They’re just… cost centers.
In comparison, both an internal order and a project are temporary in nature. They are job- or task-specific and almost always have a defined start and end date… not that everyone actually maintains those dates on them in SAP… but the underlying business purpose that drives the object is almost always finite. Eventually the order or project is deemed to be complete, is closed out, and all costs settled to the final receiver.
It’s not just the time validity definition that makes them similar. In fact, the amount of functional overlap between the two is extensive. In some cases it’s identical.
Here are some examples. Most prominently, the settlement configuration supports both orders (of many types) and projects. It’s all handled at the same place, just configured differently based on the types of cost being settled.
Status Management is another important area that orders and projects support whereas cost centers don’t. Same as before, it’s configured at the same place regardless of which object you’re working with.
Planning and budgeting is also handled in the same manner. It’s here where we start to see some differences but they’re minor and reflect the inherent differences of the two cost objects. Both of these plan profiles are also stored on the same table (TBP1C).
Budgeting is handled the same way too (same table too!).
There are other examples related to cost classification, cost control, and integration to fixed assets.
On the end-user side, the similarities continue in month end processing, reporting and plan/budget data entry. KO88 and CJ88 are nearly identical in execution.
Entering in plan/budget values are also largely the same.
I won’t go into the reporting other than to mention that CJI3 and KOB1 are probably the two most frequently executed reports for both objects. If you have used one, you should be immediately familiar with the other because they’re so similar.
The point of all of this is that there is a lot of overlap between these two modules and the total functionality far exceeds what you can do on a cost center. That’s why we push them as the ‘go to’ for capital cost capture.
What Are The Differences?
So, while these two cost objects have a lot in common, what makes them different? How do you determine to use one over the other?
The differences between orders and projects basically comes down to one prominent feature… that being that a project has a hierarchy of underlying WBS elements and networks whereas an order is a singular object.
And guess what? Accountants. Love. Hierarchies! They love cost center and profit center hierarchies, reporting roll-up hierarchies, product line hierarchies, and yes, they even love WBS hierarchies. It is this feature that helps make the project the most diverse and flexible master data object in all of SAP. It provides a huge benefit in project reporting as well as master data classification. When you look at a project from a logistical or project planning perspective, the hierarchy allows for additional functionality such as start-finish relationships. The hierarchy provides the biggest benefit to the project and is therefore, one of the most important characteristics to evaluate when choosing between it and the order.
Simple vs. Complex
It is the hierarchy that oftentimes scares off customers because they immediately view it as more complex. Complexity is a key factor in choosing between the two (certainly for other software applications too) and it shows up in several areas other than the ones mentioned above. Since PS has more functionality than orders, that means there is more to configure, more integration points to work out, more features to review, and more decisions to make. Yes, projects can certainly be more complex than internal orders.
Well, guess what SAP has been super focused on for the past 5 years? Simplification!
I think a lot of people are confused by what SAP means when they hear the word ‘simplification’. I’ve blogged about this previously (What’s so Simple about SAP Software (Part 1)?) but the quick overview is that SAP is trying to simplify it’s ERP product in a few different ways. One of those is by breaking S/4HANA into separate On-Premise (OP) and Cloud versions. The intent is that the cloud version is significantly more scaled back. There is less functionality delivered in the cloud and less possibility to configure it. For instance, when S/4HANA Cloud was first released, there were significant limitations in the Investment Management (IM) integration points between a project and a fixed asset. In fact, there isn’t an investment management solution within S/4HANA Cloud whereas the OP version has retained it. That makes S/4HANA Cloud a complete non-option for a lot of our customers… currently.
The Principle of One
Another way SAP is simplifying the ERP solution is with a concept that they call the “principle of one”.
Reference (SAP.com): SAP S/4HANA: 10 Questions Answered
To no one’s surprise, as the ERP product evolved from R/2 to R/3 to ECC and now S/4HANA, the amount of functionality that SAP has included has also increased. There were also certain changes in technology where SAP decided to branch off from a current area/approach and go in another direction. Here are some examples:
- Report Painter and Report Writer. Why have both when they’re 90% similar?
- For capital planning we have the previously mentioned Investment Management module but also a completely separate (and licensed) product called PPM. They accomplish almost the same thing. Customers can be successful using either one of them but they have to first choose correctly.
- In the ABAP technical area, there are so many ways to make enhancements it would take a whole blog series to explain them. User exits (old vs new ones), menu exits (deprecated), field exits (deprecated), BADI (old and new), enhancement spots, and on and on. It’s changed again in both S/4HANA Cloud and will be changing in S/4HANA OP.
- There are multiple transaction codes that point to the same program. When will SAP get rid of all of the ….N transaction codes?
- Previously SAP had an approach to put everything into ERP (circa R/3). Anytime a new topic area emerged, they would add a module. Now they’re starting to pull some of them out and ‘shrink the core’ to it’s most essential components. Hybris billing and customer management is an example.
To say that there is more confusion in the product because of these choices… a lot of which appear to be (and are!) highly similar… makes it much harder on all parties. SAP has to support and patch multiple items, and both consulting and customers have to choose which to use.
SAP’s principle of one intends to provide only a single solution going forward. If there are two options or solutions for an area, they are deprecating one and only using the other going forward. If there is a business problem to be solved, there should be one and only one solution. Which brings us to the main topic… what to do about projects and orders if they’re so similar yet have only one significant difference?
Next Blog: Simplification of Internal Orders Leads to… Simple Projects? (Part 2)
