SAP PS

PS structures projects using work breakdown structures (WBS) and networks/activities, plans dates, costs and resources, budgets and controls spend, and settles project costs to their financial targets. It brings project execution into the integrated ERP so project costs and revenues are tracked accurately.

• Work Breakdown Structure (WBS): the project structure.
• Networks & Activities: scheduling and execution.
• Planning & Budgeting: costs, dates, resources.
• Settlement: moving project costs to their targets.

PS models a project twice, and understanding why is most of the module.

The work breakdown structure is the hierarchy of what the project consists of, broken into WBS elements. It is the cost and budget structure: money is budgeted against a WBS element, costs are collected there, and reporting rolls up the tree. It answers what the project is made of and what each part costs.

Networks and activities are the schedule. An activity is a piece of work with a duration, relationships to other activities, and resources. The network is what produces dates, critical path and capacity requirements. It answers when things happen and in what order.

The two are linked: activities are assigned to WBS elements, so scheduled work rolls its cost into the cost structure.

Not every project needs both. A project used purely to collect cost, such as a capital investment, often has a WBS and no network. A project driven by scheduling has both. Building the network for a project nobody schedules is effort with no consumer.

Transactions: CJ20N is the project builder, where both structures are maintained, CJ01 and CN21 create them separately, CJ30 maintains budget and CN41 is the information system.

An hour, and it demonstrates why PS sits between finance and logistics.

1. Create a project with CJ20N, with two or three WBS elements.
2. Set a budget against the top element with CJ30 and release it.
3. Add an activity, and against it a component to be procured. Releasing the network creates a purchase requisition automatically.
4. Convert the requisition to a purchase order and receive it. The cost lands on the WBS element the activity belongs to.
5. Book time against the activity, or post a journal directly to the WBS element.
6. Run the project information system and read actual against budget. If availability control is on, a posting that would exceed the budget is refused or warned.
7. Settle the project. Costs move to their destination: an asset under construction, a cost centre, or profitability analysis.

Step seven is where projects most often go wrong. Costs collected and never settled sit on the project indefinitely and never reach the accounts they belong to.

PS integrates with CO (project costs), MM (procurement for projects), PP (production for make-to-order), SD (billing project deliverables) and HR (resources). It is central to industries running large capital or engineering projects.

PS is unusual in being an account assignment object as much as a module. A purchase order, a goods issue, a time confirmation and a journal can all be assigned to a WBS element, which is why PS appears in materials management, in production and in finance rather than standing alone. Where a business does engineer-to-order manufacturing, the project and the production order work together, with the project carrying the commercial view.

• How deep the WBS goes. Deep structures give precise cost visibility and multiply the elements somebody maintains. The right depth is the level at which the business actually makes decisions about money.
• Networks or not. Only where scheduling genuinely matters, because the network is the more demanding half to maintain.
• Budget and availability control. Whether exceeding a budget warns or blocks. A block is a real control and it will stop a purchase order at an inconvenient moment, which is the point.
• Where costs settle. To an asset for capital projects, to profitability analysis for customer projects, to a cost centre for internal ones. Deciding late means costs sitting unsettled.

Learn PS through its core processes, its master data and configuration, and its integration with the rest of the SAP landscape. Hands-on practice cements it.

PS serves several quite different purposes, and the configuration follows from which one.

Capital investment projects build an asset. Costs are collected on the project and settled to an asset under construction, which becomes a fixed asset when complete. The finance requirement is capitalisation, and the structure is usually a WBS with no network.

Customer projects deliver something billable. The project carries revenue as well as cost, results analysis calculates work in progress, and settlement goes to profitability analysis. This is the most demanding configuration because it touches revenue recognition.

Internal projects collect cost for an initiative with no asset and no customer: a system implementation, a reorganisation. Settlement is to a cost centre.

Engineer to order combines the project with production, where a WBS element carries the production orders for a bespoke product and stock is assigned to the project rather than being general.

Asking which of these a client means is the first question, because the same module produces four different builds.

The question every project asks is how far along it is, and PS answers it in a way worth understanding because it drives revenue on customer projects.

Progress analysis calculates percentage of completion, using methods that range from the honest to the arbitrary: measured against milestones, against cost incurred versus planned, or estimated by the project manager.

Results analysis takes that percentage and calculates what should be recognised. On a customer project, revenue is recognised as work is performed rather than when it is billed, so the difference between billing and progress becomes work in progress or deferred revenue on the balance sheet.

That calculation runs at period end and posts to finance, which is why results analysis configuration is agreed with the finance team and often with the auditors rather than decided in the project.

The dependency worth naming: results analysis is only as good as the progress measure behind it, and a percentage estimated optimistically recognises revenue that has not been earned. That is the specific reason cost-based percentage of completion is common: it uses a number nobody can flatter.

• Learning features, not the end-to-end process.
• Ignoring integration with finance and neighbouring areas.
• Skipping master data/configuration the process depends on.

• Projects never technically completed or settled. The most common finding in a PS review, and it distorts both the project reporting and the receiving accounts.
• Using PS where an internal order would do. A single cost collector with no structure and no schedule does not need a project.
• Budgets set once and never revised. See plant maintenance and production planning for the neighbouring modules that assign to projects.

• Availability control switched on without agreeing who can raise a budget. A blocked purchase order at month end needs somebody with authority available.

Building a structure is straightforward, and configuring budgeting, availability control and settlement so a project's costs reach the right accounts is the part you do in the course.

The check worth running on any project system is how many projects are technically complete and unsettled. It is the most common finding, and it means cost is sitting on projects instead of in the accounts it belongs to.