The Project System module of SAP (PS) is specifically designed to provide comprehensive and fully integrated project management functionality for SAP customers. When it was originally designed and developed its core functionality was borrowed from and shared with the PP and CO modules.
So most of the PS objects (WBS elements, networks, activities, activity elements) are cost objects similar to cost centers in CO, while networks have scheduling and resource management capabilities that are very similar to PP. Whenever you need flexibility and frequent user interaction for resource loaded scheduling activities, you still feel the remnants of an architecture and user interface that was originally designed for the more static context of PP.
Shortcomings include user-friendliness since SAP did not manage to satisfactorily put the end user in control to easily manipulate the data. In that respect, SAP's unsurpassed enterprise functionality often is perceived as an issue by end-users. Also, and somewhat ironically, PS and PP are not seamlessly integrated. This means that costs or dates do not roll up or cannot be pushed down between PS &PP.
What is SAP PS? Projects are generally part of the internal processes of a company. To be able to control all tasks in project execution, you need an organizational form that is specific to the project and which is shared by all departments involved. Before you can carry out a project in its entirety, the project goals must be precisely described and the project activities to be carried out must be structured. A clear, unambiguous project structure is the basis for successful project planning, monitoring, and control.
The high degree of integration between the Project System (PS) and other R/3 application components means that you can plan, execute, and account for projects as part of your normal commercial procedures. This means the Project System has constant access to data in all the departments involved in the project.
The R/3 PS guarantees close and constant monitoring of all aspects of your project including both technical and commercial aspects of the project.
Project Functionality of SAP-PM (Plant Maintenance)
The SAP Plant Maintenance module (PM) is designed to handle the management and execution of integrated maintenance processes. Such processes include preventative, routine and turnaround maintenance, all fully integrated with purchasing, MRP, controlling and financial accounting performed in SAP. The main objects used in PM are work orders, a series of which (often grouped by revisions) are what typically is thought of as a "project". Such maintenance projects are planned by describing the estimated work effort per "operation" (activity) and work center performing that work effort. By linking operations inside work orders or across them a generic project schedule is created.
Unfortunately SAP-PM has only limited scheduling capabilities. Therefore effective enterprise project scheduling for maintenance purposes requires either the use of the SAP PS module, the integration with external scheduling tools like Primavera or MS Project, or for less complex projects the use of external tools like GWOS (for more information about these tools please search this web site).
The basic master records used by Plant Maintenance are:
- Maintenance Notifications;
- Maintenance Orders;
- Functional Locations;
- Equipments;
- Materials; and
- Work Centers (Resources).
Functional Locations and Equipments contain fields that allow grouping by units, locations, or plant locations.
Project Functionality of SAP-CO (Controlling)
There are several important touchpoints between SAP projects and the SAP Controlling module (CO). All SAP cost planning and budgeting (in SAP terminology: budget = approved cost plan) functions are handled using standard CO functionality. Objects relevant to project management in SAP are cost objects. This means that planned, committed and actual costs can be charged to them like to a cost center or an internal order in CO. Among these cost objects are WBS elements, networks, activities, activity elements, maintenance orders, operations and suboperations.
Costs may be planned on many levels and in many ways, starting as investment management (IM) level or WBS structure level cost planning, through primary cost element planning, and going on to purchase requisitions, planned allocations, planned hourly use of resources with associated standard cost rates, and many more.
Actual costs may be charged to SAP project objects in many ways, typically through goods or service receipts, accounts payable invoices, general ledger (GL) postings, cost allocations or settlements. The SAP system will automatically perform the relevant controlling postings in the background so that CO plan-actual or plan-commitment-actual reports can be run in PS or PM.
Standard costing using standard cost rates associated with work centers (resources) are defined in SAP CO, either internally calculated or manually assigned. This then means that cost center-based controlling transactions have a direct impact on project costing. The moment you say "costs" in SAP, you say "CO" automatically, even when dealing with projects in PS or PM.
Project Functionality of SAP-PP (Production Planning)
Production planning and project management in SAP have many touchpoints. They intersect particularly in a make-to-order environment involving sales-driven projects. In principle there are a lot of similarities between the production planning module (PP) of SAP and the Project System (PS) or even Plant Maintenance (PM). Production orders are very similar to networks or maintenance orders/work orders.
The main difference is that PP deals with ongoing operational aspects while PS and PM deal with projects. Projects are defined as a series of activities with a start and finish date in order to complete clearly specified deliverables at a high quality standard. From that perspective the main conceptual difference to PP is the limitation in time. PP, PS and PM all define a series of tasks, link them through relationships with each other, assign work centers to them to define where and by whom the tasks are supposed to be completed, and then schedule and cost these tasks out.
Even the tools used in SAP are very similar or often the same (like work centers, definition of relationships, resource leveling). This should not be surprising as particularly the PS module, and also to some degree PM, has been built by combining PP and controlling (CO) functionality. It does indeed seem that one reason why project management in SAP often is perceived as not user-friendly is due to that fact. Many of the "logistics" functions of the dynamically changing PS and PM modules are rooted in the much more static PP module. The result is great functional power but often clumsy screens and transactions.
The assignment of internally produced materials (components) to projects in PS or PM reflects another area where these modules intersect. In that case PP provides input to PS or PM, and the timing of this input is synchronized through scheduling and MRP (materials requirements planning) transactions.
There are a number of limitations in the way PP on the one side and PS and PM on the other side interact. At least in the standard SAP R/3 system costs and dates are not naturally rolling up or synchronizing between these modules.
Project Functionality of SAP-SD (Sales & Distribution)
What does Sales and Distribution (SD) functionality have to do with the management of enterprise projects? It does for more companies than may seem obvious at a first glance. For contractors using their own SAP system to manage and deliver capital investment projects the SD module is where the billable deliverables of their projects are defined. The same is true for everybody who uses the SAP project system (PS) to manage the make-to-order production of complex products, whether they are powerplants, aircraft parts, or the concrete bridges.
SAP has functionality that allows to tie reference (template) project structures to product codes so that at the time of sales order creation the setup of a project structure can automatically be triggered. This does then link SD and PS seamlessly, at least on a high level. As the project progresses, milestone billing set up in SAP-PS can then trigger payments in SD, which again results in revenue postings in the SAP financial accounting module (FI). There are a number of other reasons where SD can interact with projects managedf in SAP. Mostly, however, it does so only when you take a comprehensive look at the overall process, trying to ensure full integration. Not doing so may lead to inconsistencies between what sales people or customer relationship personnel sees in SD and the actual status of the delivery of products. One may just consider a situation where SD data from a suppliers' system needs to be tied into a project master schedule managed by a general contractor. To overcome the latter it is helpful to mirror and match purchase orders and sales orders between supplier and customer, also in line with the way the general project is managed.
Project Functionality of SAP-IM (Investment Management)
The potential significance of SAP's Investment Management module (IM) is too often overlooked when considering the management of complex enterprise projects. Nevertheless it should in most cases be considered when designing scalable project management solution that center around SAP.
SAP IM is a tool designed to enable program management in SAP. Program management as defined by SAP in that context means the process of defining a hierarchy on top of many projects with the purpose of planning and controlling costs, including project appropriation management and budget authorizations. Its strongest integration points, besides PS, are with the SAP Controlling (CO) and Asset Management (AM) modules.
While IM was originally developed for the budgeting and high-level management of capital investment initiatives, its functionality has been extended to allow its use for similar functions. It simply is a tool that can perform such functions on top of any kind of PS projects.
Preferred Project Management Tool is...
SAP Project System (PS)
Primavera Enterprise/P3e
Microsoft Project
SAP with Primavera
Difference between SAP PS and PM?
The SAP world makes an important distinction between "PS" and "PM". The acronym "PM" is a source of frequent confusion. For many project management professionals it simply stands for "Project Management", while in the SAP community it is the abbreviation for the "Plant Maintenance" module of SAP.
The SAP PM module was not designed as a project management module. It still contains a lot of components very similar to the SAP PS module, which is the project management module called "Project System". SAP define their modules by function more so than by the process they cover.
The Process Building Blocks for Projects with SAP
Forget about technology and do not pay attention to modules: The key process blocks of Enterprise Projects deal with functional aspects! To set up an effective project management system, these functional aspects need to be clearly defined. If multiple tools are used, responsibilities per functional aspect and project management layer need to be assigned to one tool only, for each layer of the enterprise project (enterprise, project, and contractor).
Key process blocks or functions are:
1. Structures (WBS in SAP-PS)
2. Schedule (Network) 3. Cost Plan (Budgeting)
4. Resources (Work Centers)
5. Actuals / T&E
6. Progress / Completion
