SAP S/4HANA Cloud, public edition provides you with so called enterprise projects and professional services projects. In this blog we like to give an overview about what they have in common and some main differences from a functional point of view, based on the 2308 release.
Professional services projects can be used to manage your projects for project-based services. It is part of our professional services automation (PSA) solution and can not only be used in professional services companies, but also companies which have a professional services like business in one of their business units. The main functional focus of the solution is around cost & revenue planning, managing of required resources, collecting activities & expenses, corresponding revenue recognition & work in progress and billing to customers. The main design principle is to provide a higher degree of automation based on the basic principles for this kind of business. There are two types of professional services projects:
Enterprise projects can be used to manage different kind of projects in different industries. The main design principle is to provide a more flexible solution which can be used for a variety of scenarios. In a most simple scenario, an enterprise project has no project structure at all and simple acts as a cost collector, similar to an internal order in SAP S/4HANA On-premise or private cloud edition. Compared to professional services projects, an additional functional focus is to manage physical materials for projects, for example by help of project specific stock or an integration to production planning. Enterprise projects can have one of the following profiles:
Both, enterprise projects as well as professional services projects, provide an integration to core business processes in SAP S/4HANA Cloud, such as time recording, purchasing and financial accounting.
Enterprise projects and professional service projects come with separate sets of business roles and best practice processes.
In order to start to have a look at professional services projects, you could consider using this:
To get yourself familiar with enterprise projects, you could have a look at the following:
Enterprise and professional services projects can be structured by help of a so called work breakdown structure (WBS). It is up to you how to use a WBS element, it could represent for example a piece of the project scope, a certain package of work or the engagement of a certain organizational unit or service line of your company. A WBS element should not represent a single task. Among other things, WBS elements can be used to plan and collect costs and revenues. You can control what kind of actions are allowed for a WBS element by help of so called blocked functions (but there are different ones for enterprise projects and professional services projects).
In professional services customer projects, you can have two levels of WBS elements. The elements on the first level are used to manage revenues, are the anchor for the billing process and are called billing elements. Once a professional services customer project has a certain stage, one project always relates to one sales order and one billing element always to one sales order item. This relationship and its consistency is managed by the system. The WBS elements on the second level are called work packages and are the main objects for planning, managing resources and collecting actual costs. In addition, you can use so called work items in professional services projects. In difference to work packages, work items are not cost objects, meaning you cannot book actual costs on a work item itself, but you can use them to structure the efforts within a work package during planning and monitoring.
Possible project structure of a professional services customers projects
Along the basic design principle of enterprise projects, to provide a more flexible solution that can be used in different scenarios, you have more options to setup and manage the work breakdown structure. The WBS of an enterprise project could have more than two levels and the processing status of every WBS element can be managed individually. So for example one part of a project could be already in execution whereas another part is still in planning. Billing elements could be positioned at every level (but not two billing elements below each other) and could be linked with no or more than one sales order item, even from different sales orders. In difference to professional services projects, you need to setup and manage these relationships manually. In a smallest scenario, an enterprise project consists of the project header only and so can be used for internal order like use cases known from SAP S/4HANA On-Premise. Since the project header itself is a special form of a WBS element, it can already be used to plan and collect costs and revenues. Besides WBS elements, you can assign milestones to the project header to structure your project.
Possible project structure of an enterprise project
Another difference to SAP S/4HANA On-Premise is that there are no networks of activities for projects. One use case for network activities with SAP S/4HANA Cloud On-Premise are the integration with external and internal procurement, for which you can use so called project demands in SAP S/4HANA Cloud public edition.
Further reading:
In SAP S/4HANA Cloud, public edition you can use so called project demands to describe what is needed to execute a WBS element (or work package). One project demand represents one certain need at a certain time, for example a project team member, a service or a physical material. You can use project demands starting from an early planning stage, when some details are not yet known. At a more mature stage of your planning, you can trigger for example a request for staffing or an external procurement. During project execution, project demands are the basis to prefill time recording and material consumption and for monitoring actual delivery. A project demand always belongs to a WBS element (or work package) and it is not a cost object on its own.
Because the scenarios which are supported by enterprise projects and professional services projects are different, there are also different demand types for each. Demand types available for professional services projects:
Since enterprise projects can also be used to support scenarios which require the management of physical materials for projects, for example for engineer-to-order projects, it supports so called sales order or project stock. These are special stock segments which can be used to manage physical materials that shall only be consumed for the project or related sales order itself, but not for any other activity. To be more precise, every WBS element of an enterprise project with profile “Investment project” or “Project with revenue” has an own stock segment. If sales order or project stock is used for a certain internal or external procurement process, depends on the settings of the physical material to be managed. The following demand types are available for enterprise projects:
It is also possible to manage some of the mentioned processes without project demands in a more manual way. For example you can create a purchase order manually and account assign it to a WBS element (or work package) (account assignment category P) or the stock segment of a WBS element (account assignment category Q)
Depending on the type of resources, there are different ways to book the actual usage or consumption. Internal / external worker can use their timesheet, for external services you can create a service entry sheet, for physical materials you can maintain a goods issue. For some of these transactions approval process can be defined and all of these transactions lead to actuals cost postings on the WBS element (or work package).
Further readings:
As mentioned above, the key element to plan and collect costs and revenues are WBS elements (in it’s different forms as work package, billing element, enterprise project header). A WBS element can be used as account assignment object in many different business processes and so can lead to commitment or actual postings on the WBS element itself. For this aspect, WBS elements of enterprise projects and work packages of professional services projects behave very similar. Because of the different underlying design principle and supported scenarios, there are differences between enterprise project and professional services projects with regards to how costs and revenue are planned and actual costs can be further processed.
The table below tries to give a first overview how costs can be managed:
Professional services projects | Enterprise projects | |
Planned costs | calculated by the system automatically based on project demands | need to be uploaded, e.g. based on XLS |
Forecasted costs (estimate at completion) |
calculated by the system based on forecast for remaining efforts | – |
Plan and control cost budget | – |
– original budgets can be defined manually like planned costs on WBS element level – so called budgets documents can be used to manage budget transfers (between WBS elements) or describe budget returns / supplements – before every actual cost posting on a WBS element, the system can check if enough budget is available for the WBS element itself (or one of the parent WBS elements) and throw a warning or error message depending on the configuration |
Integration with asset management | – | for projects with profile “Investment project”, the system can generate one or multiple assets under construction for each WBS element and settle the collected costs to a fixed asset at the end |
Settlement of costs | – no settlement for customer projects – costs of internal projects need to be settled to e.g. other WBS elements, G/L accounts or costs center |
– different project profiles provide different capabilities – for projects with profile “Investment Project”, it is possible to pass down settlement rules to child WBS elements |
Calculation of overhead costs | – | – Actual overhead costs can be calculated during period end closing |
Cost reporting | Reporting can be based on work items in addition | Reporting can include assigned maintenance and production orders in addition |
It is important to mention that professional services projects and enterprise projects use different planning categories for planned costs, revenues and budgets. Along the underlying design principles, the planning categories for professional services projects are fixed and mainly managed by the solution:
Although planned costs and revenues are maintained manually for enterprise projects, for certain capabilities you should consider the following planning categories:
Both, professional services projects as well as enterprise projects, are integrated with event-based revenue recognition in SAP S/4HANA Cloud, public edition. The variations how revenues can be managed with professional services projects and enterprise projects are mainly based on the differences mentioned so far and the different processes for billing (which will be explained in the next chapter):
Further readings:
For professional services projects of type customer projects, as well as for enterprise projects with profile “project with revenue”, billing plays a key role. Since both solutions are designed to support slightly different business scenarios as mentioned at the beginning, they are integrated with different best practice processes for billing.
The main scenario for professional service projects is to support the delivery of project-based services, which is typically very human resource centric and often requires are fine granular billing of the efforts and expenses spent. Therefore, the related best practice process “Project Billing – Project-Based Services” (https://me.sap.com/processnavigator/SolS/EARL_SolS-013/2308/SolP/4E9?region=US):
The billing process for professional service projects start with an object called project billing request, based on which a billing document request and subsequently an invoice can be generated.
Enterprise projects with profile “Project with revenues” are often used for engineer-to-order like scenarios. So billing can be needed after the delivery of a physical material, which is described in best practice process https://me.sap.com/processnavigator/SolS/EARL_SolS-013/2308/SolP/4I9?region=US. The described scenario uses a fixed price billing method and an optional down payment. In case a milestone-based billing is needed, the billing plan of the sales order items connected to billing WBS elements could be used. A connection with the milestones of an enterprise project is not supported. Time & expense-based billing, including a flexible determination of the product to be billed, is not supported for enterprise projects. The project billing request, which was mentioned above and provides e.g. additional monitoring capabilities, is not available for enterprise projects. Billing for enterprise projects could start with a billing document itself.
Further readings:
With this blog post we tried to give an overview for the main differences between enterprise projects and professional services projects in SAP S/4HANA Cloud, public edition. Feel free to add comments or ask questions.