How to Create and Manage Capital Projects in SAP®

Written by: Richard Frykberg

SAP Project Systems is one of the most powerful and deeply integrated modules in SAP. To fully benefit from this functionality, you need to configure your system appropriately and create new projects thoughtfully. Well-structured projects enable efficient downstream processes and analysis. Poorly defined projects waste time and money and increase the risk of project failure.

The best practices for effective project definition in SAP are outlined below, including special considerations when migrating from SAP ERP to S/4HANA.

Project Initiation

What triggers the set-up of new projects, and when in the project lifecycle should this occur?

Timing the creation of capital projects

Timing when you set up a project is important. Is it when the project starts? Or when it’s approved? Or when planning commences? Setting-up your projects in the system too late will limit its usefulness for capital budgeting and forecasting. Setting-up your projects too soon may result in wasted effort and redundant master data if the project doesn’t proceed.

It is generally accepted that the best practice for capital budgeting is to undertake zero-base budgeting. Rather than simply allocate a top-down capital budget bucket to operational areas, it is recommended to base any budget allocations on an approved list of planned initiatives. So if your capital budget is based on identified initiatives, where is the list of items maintained?

For many organizations, the detail of the capital budget is maintained in spreadsheets. This is a poor solution as any reconciliation of actual and forecast expenditure must then be performed outside the system, involving inefficient data extraction and reconciliation.

There are two primary approaches for maintaining the detail of your capital budget inside SAP:

• Implement SAP Investment Management, or
• Early creation of project master data for planning and budgeting purposes.

If you have SAP Investment Management activated, proposed projects can be identified as Appropriation Requests or as granular Investment Program Positions.

The best practice is to maintain a summarized investment program structure that is easy to roll-forward from year to year. Individual projects can be planned as linked Appropriation Requests, and appropriately classified and evaluated. On final business case approval of projects, these Appropriation Requests can be replaced by the Investment Measures (Projects or Internal Orders) that will be utilized for project execution. Budget can then be distributed from the summary investment program positions to these individual orders.

If you have elected not to activate SAP Investment Management functionality, it is recommended to create your project master data at the time of budget request submission. With appropriate automation, the effort of project creation can be nullified, and the ‘wastage’ of unused project codes is more than offset by the value of having all your project budget details in SAP as your single source of truth.

If you create your projects early, it is beneficial to employ user statuses to differentiate budgeted and unbudgeted projects. Changing business conditions invariably results in project substitutions. Where an initially budgeted (and created) project is no longer prioritized to progress, it’s status can be updated accordingly to facilitate ease of reporting.

In the event of project substitutions, in addition to status management, budget must be reallocated from the original to the replacement projects.

Project Systems vs Internal Orders

There are two primary mechanisms for controlling projects as investment measures inside SAP: Projects and Internal Orders. Both are temporary cost-collectors that ultimately ‘settle’ to a Cost Centre (in the case of operational expenditure) or to an Asset (in the case of capital expenditure).

Projects are a better choice for complex projects where project decomposition into work breakdown structures for more granular control over scheduling and costing is required. Internal Orders are easier to set up and administer and are more appropriate for direct purchases or simpler initiatives.

Too often, organizations elect to use only one or the other. They may use Internal Orders for both a new vehicle and a new factory. Or they may use projects for both major plant refurbishment and simple equipment replacement. This causes either unnecessary complexity, or insufficient visibility and control.

The main reason some organizations pick one investment measure type to apply to all cases is operational consistency. Due to the complexity of maintaining master data in the SAP system, and for the simplicity of end-users, reporting and downstream processing, they elect one approach and apply it in all cases.

The best practice is to employ the most suitable technical object for the scenario. Use projects only where required, and internal orders in all other cases. Having the flexibility to use internal orders where appropriate means that less projects will need to be created and will simplify general operation.

Combining the use of both Projects and Internal Orders is greatly facilitated by simplifying the end-user experience. Ideally, most business users should not even need to know what technical object is being used in the back-end system.

The choice of technical object should be derived by the nature of the project. Rather than asking the user to choose between “Project or Internal Order,” the characteristics of the project should be evaluated, and consistent business rules should be applied. For example, if the nature of the project is a low value replacement of a single fixed asset, an internal order will be sufficient for project control.

SAP Investment Management

If you are using SAP Investment Management with Appropriation Requests for evaluation and approval of initiatives, you can make use of standard functionality to create the required investment measures.

Depending on the appropriation request types that have been configured in your system, you may be able to automatically create projects, internal orders, or both.

The benefit of creating projects from Appropriation Requests is that the planned cost of the project can be automatically transferred from the request to the project.

The key disadvantage of the automatically creating projects from appropriation requests is that there is no opportunity to refine the project structure according to the needs of the specific project.

Furthermore, any budget distribution is still required to be manually done using transaction codes (IM52).

Rather than creating Projects from Appropriation Requests using transaction codes within SAP, the best practice is to create the project as required, and then update the appropriation request accordingly. An SAP Fiori user-interface is highly effective for capturing the required project breakdown structure required to set-up a project in SAP according to the needs of the project.

By orchestrating project creation directly, the master data, planning and budgeting can all be handled simultaneously.

SAP Enterprise Project Portfolio Management

SAP Enterprise Project Portfolio Management (ePPM) is the module that helps organizations consistently classify, evaluate, and select items for inclusion in the active project portfolio.

Projects can be automatically created by ePPM when items are approved and progressed through a specified stage gate.

As with Investment Management, there is little opportunity to adjust the structure of projects created via ePPM integration. Projects created via ePPM will often need to be manually restructured to meet unique project execution and analysis requirements.

Whilst the SAPGUI transactions (such CJ20N) can be used to adjust project master data, providing end-users with a Fiori web-application for refining project set-up makes it easier for them, and ensures that projects are optimally structured in accordance with business rules for downstream processing and analysis.

Project Initiation Request Fiori Apps

Project initiation requests come with many names. Some of the frequently used terms to describe the request form that triggers the set-up of a project include Project Initiation Request (PIR), Project Approval Request (PAR), Authorization for Expenditure (AFE), Capital Expenditure Request (CER), Capital Approval Request (CAR), and Capital Project Approval (CPA).

Sometimes multiple request forms are prepared. For example, a Capital Project Approval may be raised initially to trigger the creation of project definition and top-level budget item. Subsequently, individual Capital Expenditure Requests can be raised to set up lower-level WBS elements and initiate procurement processes.

A variety of technologies are applied to support these forms. As these request forms all involve workflow approval, organizations consider their current workflow approval tools.

Whilst SAP workflow on appropriation requests is a technically feasible solution, the traditional SAPGUI interface precluded this as a realistic option. As senior executive engagement approvals are required for high value capital projects, a more familiar and user-friendly approach is normally adopted.

Many organizations used paper forms until relatively recently. However, spurred by Covid, globalization and remote working arrangements, physical forms are no longer a viable solution. For many organizations, the project initiation form is an Excel template. Sometimes these Excel templates are simply routed through the approval chain via email. This is a very manually intensive process, and compliance with delegation of authority polices onerous to enforce.

The most common approach is to make use of the organization’s document management system to facilitate this workflow. For many organizations, this is SharePoint. The major disadvantage of a document-based request and workflow solution is that it is very hard to consolidate and analyze in-progress requests or automate the project set-up on approval.

Best practice for SAP-centric organizations is to make SAP your single source of truth throughout the request and approval lifecycle. This can be achieved by using standard SAP transactions (such as appropriation requests) under-the-hood but surfacing the functionality as user-friendly Fiori apps.

Project Accounting

How does the set-up of your projects impact financial accounting and analysis?

CapEx vs OpEx

Capital projects mainly incur capital expenditure (CapEx). However, many projects also include an element of operational expenditure (OpEx). CapEx is long-term in nature and capitalized into the resultant fixed asset. OpEx, by contrast, is expenditure without a lasting benefit, and in accordance with accounting rules is required to be expensed in the period in which it is incurred.

In SAP, settlement rules determine how the costs accumulated on a project work breakdown structure element (WBS) are settled.

The best practice approach to separately accounting for both CapEx and OpEx on projects is to differentiate these components in the WBS hierarchy. The most effective level to differentiate CapEx and OpEx costs is at level 2 of the WBS hierarchy as illustrated below:

Capital Interest

In many jurisdictions, high value capital projects that are completed over an extended period should accrue the interest expenditure incurred in the funding of these projects.

Within SAP, capitalized interest can be automatically calculated on a monthly basis and added to the cost of project.

In order to trigger this calculation, a capital interest profile needs to be assigned to the relevant WBS elements.

Interest profiles can be automatically defaulted if assigned via the project profile to the project definition. However, distinguishing project profiles based on capital interest requirements can unnecessarily complicate the number of project profiles in operation.

Best practice is to directly derive the need for capital interest calculation in accordance with business rules (such as the value and project duration). When the need for capital interest accrual is identified, the capital interest profile can be automatically assigned to the project on creation.

Planned Depreciation Simulation

Another key accounting consideration is whether planned depreciation is required to be calculated on capital projects in-progress.

Planned depreciation is based on the asset class and capitalization date on a WBS element.

Project initiation requests should specify the target asset classes and capitalization dates so that this information can be used to automate planned depreciation calculations.

Project Classification

What best practices apply to project classification and portfolio analysis?

Project Types

WBS elements are assigned a Project Type. These Project Types are initially derived from the Project Profiles and normally include types such as ‘Capital Investment’ or ‘Customer Project.’

Within SAP these project types have no functional impact but are useful attributes for reporting and analysis.

A common best practice approach is to classify CapEx and OpEx WBS elements using the project type attribute.

Investment Reasons

Capital projects are motivated by a range of investment reasons. The most common is sustenance of existing capital plant and equipment. As the organization’s existing capital base depreciates, ongoing replacement is required to sustain current levels of operation.

Another core investment reason is growth. These investments are expected to deliver a return exceeding current operational capacity and performance.

Environmental, Social and Governance (ESG) projects are increasingly important. Many organizations have set emissions abatement targets, and this often requires significant investment in new technologies and processes.

These investment reasons would likely have very different risk profiles, cashflow profiles and executive sponsorship.

Investment reason is a configurable attribute that should be maintained on project WBS elements for analysis purposes.

Scale

Scale is a standard WBS attribute intended to reflect the relative size of a project. This is a useful attribute to drive workflow processes. However, the investment value can be directly determined, so the use of scale to reflect only value is a bit pointless.

An alternative, but related, use of scale is to reflect complexity. This can then drive workflow and additional business rules.

For example, simple projects may involve repeat purchases of capital plant and equipment from a regular supplier. Complex project many involve many departments, new technology, and rely on an untested vendor.

Simple projects may well be of high value, but nevertheless, progress through an expedited analysis and workflow.

Complex projects, irrespective of value, may require more checks and balances including the need to provide supplementary documents, complete additional checklists, obtain specialist endorsement, and progress through further levels of workflow approval.

Priority

Priority is a standard WBS attribute intended to assist users focus on and expedite the highest priority items first. However, when granted the ability to select a project priority, most sponsors consider their initiatives to be High Priority. So, it is recommended not to use naïve priority ratings such as high, medium, or low.

Priority rankings are, however, essential to portfolio optimization. Given resource and capital constraints, you will always need to decide which projects to prioritize.

Project prioritization should be based on a consistent and transparent scoring methodology. Key considerations that impact the priority score should include:

• Urgency, the inherent risk of NOT executing the project. The greater the imperative to mitigate cost, the higher the priority. Note the cost avoidance can relate to both direct and opportunity cost.
• Benefit, the relative Net Present Value and Internal Rate of Return of a project should directly impact prioritization. Benefit may also be assessed qualitatively. For risk-based sustenance projects, for example, the degree of risk mitigation can influence the relative benefit of initiatives.
• Confidence, or the likelihood of successful execution, is another key dimension to project prioritization. Low-hanging fruit should typically be eaten first.
• Strategic alignment is probably the most important dimension to assess. By explicitly evaluating the degree of alignment between each initiative and the benefiting area’s most important strategic objectives, you will be able to clearly identify the projects that matter most.

For more information on project scoring, please refer to the article: How to Score and Rank Projects to Achieve Strategic Goals Sooner

Project Execution Management

How does the set-up of project data impact effective project delivery?

Planning vs Budgeting

To control project execution effectively and efficiently, you need to plan, budget, and monitor your project expenditures.

Within SAP, planning and budgeting are distinct concepts.

Planning is more flexible, can be done on a monthly basis and can be revised periodically through the use of planning versions. The initial plan, and revised forecasts, are all independent versions that can be used as a yardstick to track your actual expenditure. Management attention can be focused on material variances. By design, plans and forecasts should provide the best estimate of future expenditure, and it is expected that actual results will fluctuate around that estimate.

Budgeting, by contrast, is more formal, and is an annual concept. Expenditure is constrained to the approved and budgeted amount. Budget availability checks are automatically performed when purchase orders are raised. Project budgets can only be adjusted through formal supplements and returns. Budget limits normally include a provision for contingency and are set at a level slightly higher than the most-likely cost estimate.

Given the restrictive nature of budgets, they are normally only allocated or distributed to the top-level nodes of the WBS hierarchy. Plans, on the other hand, can be maintained at lower levels.

This need for effective budgetary and planning control over project execution will impact the way you structure your projects. For example, you can only distribute budget to the top-level node of your project from investment management.

Effective Forecasting

Within the project structure in SAP, certain nodes can be designated as planning-only summarization levels, whilst subordinate nodes are activated for direct account assignment and postings.

Typically, planning and forecasting are updated in the system at these higher levels. To facilitate the effective forecasting of expenditure, it is important to be able to link project resource planning and procurement commitments to these planning elements in the project structure, either directly, or indirectly via lower-level WBS elements or network activities.

CapEx Approval vs Purchase Order Commitments

For many organizations, there is a distinction between capital project approval and purchase order approval.

Capital project approval is typically indicated by the allocation (and withdrawal) of budget on the project. In addition, project and WBS statuses are often set to identify budgeted items. These statuses provide a convenient mechanism for selecting and analyzing projects.

Project commitments result from the placement of purchase orders (PO’s) with vendors. Once the project is budgeted, POs provide a further opportunity for management to approve the actual vendor and product selection.

In SAP, CapEx approval (often based on Appropriation Requests) and PO approval (based on Requisitions or Purchase Orders) are very discrete transactions. This may be very appropriate for complex projects.

However, for direct Capex purchases, this may be time-consuming, inefficient, and frustrating for both requestors and approvers.

Where the required asset, vendor and scheduling are known at the time of raising the Capex request, a single form can be utilized that orchestrates the two SAP transactions. This data collection is optimally achieved with a Fiori app that can then be appropriately approved and automate the downstream SAP transactions.

Vendor Assignment and Engagement

Most capital projects rely on external vendors to provide necessary goods and services. Where multiple vendors are engaged in the delivery of a solution, it is recommended to provide segregated WBS elements or Network Activities to discretely track the planned and actual costs, and delivery schedules, of each supplier.

Change Requests and Supplementary Approvals

Project scope and budget variations are common, and capital projects should be structured in SAP to accommodate these changes.

Budget supplements can be differentiated from original budget. As it is possible that there may be multiple supplements, it is a good idea to activate line items for these budget transactions. This provides drill-down visibility of each supplementary approval.

Planned cost adjustment can be differentiated by version. However, this is complicated when budget versions primarily reflect revised planning forecasts and versions will combine approved scope variations and revised expenditure estimates.

It is common to segregate the project change requests and approved variations into separate WBS elements. This provides the highest degree of analysis capability.

To report variations separately from the original WBS elements, it is common practice to incorporate a change request sequence number in the WBS naming convention.

Project Pools

Pools are often used for capital budgeting. Pools can represent large programs of work, or funding buckets for smaller direct purchases such as vehicles or spare parts.

Pools typically operate slightly differently from regular projects. For example, sub-projects funded by a pool will draw down budget from the pool. Direct postings to pools may be blocked.

If project pools are to be utilized, they will need to be distinguished in the project and WBS master data so that these processing variations can be automatically applied.

Project pools may incorporate a separate numbering convention or apply user fields to identify themselves. Search helps should be provided to facilitate the selection of funding pools when raising related requests.

Related Projects

There are logical relationships between projects. They may be:

• Related for information or report grouping.
• Parents or Children when part of a funding pool.
• Co-dependent, when both projects are required to be completed together.
• Dependent, when once has to be completed before the other; or
• Mutually exclusive when than cannot be executed together.

These dependencies should be identified when setting up the projects in SAP so that business rules can be enforced accordingly.

Document Management

Most projects collect significant supporting documents. SAP provides a robust Document Management System for attaching and classifying these documents, controlling versions, and authorizing user access.

However, there are often project participants (for example subcontractors, and technical staff) who may not have ready access to, or licenses for, SAP. There is thus also often an external document repository, such as SharePoint, that controls project related documents.

It is important when structuring your projects and configuring SAP to consider the optimal storage location of supporting documents in your environment.

If an external document management repository is used, the project ID is often a key reference. To enable project document folders and SharePoint sites to be able to reference a common project ID, it becomes important to generate the project number early in the Front-End Loading process.

If planned projects generate project ID’s early in the planning cycles, it should be expected that some of those projects may not progress to execution stage. Project status management plays a useful role in excluding any rejected initiatives from reports and worklists.

Project Controls

What are the best practices for effective project monitoring and control?

Person Responsible

An important project control is clear and unambiguous assignment of roles and responsibilities, and particularly the project manager.

In SAP, the Person Responsible field is an effective way of identifying the project manager. This field is not reliant on the implementation of SAP personnel master records. Persons responsible for WBS elements can be linked to SAP user ID’s but this is optional. The benefit of establishing this link to an SAP user account is that it enables notifications and workflows to be automatically generated.

SAP also provides an option to identify Applicants. The usage of this field should be consistently applied. The most beneficial use is to record the project Sponsor.

Both responsible persons and applicants are simply defined. As there is no required link to HR Master records or user accounts, they can include external parties.

One key disadvantage of using SAP responsible person and applicant fields is that they are configuration elements. Adding new entries needs to be done in a development system and transported through the landscape. This can delay the timeliness of setting-up new projects managers and sponsors in the system. If these fields are used, it is recommended to adjust the table definitions so that these lists of individuals can be directly maintained in a production environment.

Unfortunately, these records cannot be deactivated when the person leaves the organization. This leads to ever increasing lists that are hard to use. The limited metadata for each person further inhibits ease of selection. Defined by name only, it is not possible to select by location, function, or title. Individuals with the same names are impossible to distinguish.

Whilst these two fields are commonly used, it is highly recommended to use partner functions on the WBS element. Partner functions support a much broader range of involved participants. As opposed to just the applicant (or sponsor) and person responsible, partner functions can include other interest parties including related technical and financial collaborators, endorsers, and approvers.

Partners can be more flexibly defined and include personnel numbers, users, positions, external organizations, or contacts. There is also no practical limit to the number of related parties than be linked to a project to ensure effective communication is maintained.

The available partner functions are defined by the partner determination procedure assigned to the project definition.

Stage Gates and Status Tracking

Capital projects typically follow a process that includes:

• Project initiation at which stage the opportunity is identified and validated.
• Front-end loading during which projects are formally evaluated, optimized, and designed in detail.
• Execution during which the project expenditure is incurred, and assets are commissioned.
• Close-out during which contractual arrangements are finalized and deliverables formalized.
• Investment Review during which the achievement of project objectives is assessed.

Transitioning a project between stages should be supported by forms, checklists, and approvals. This ensures that the allocation of financial and human capital is optimized and helps prevent wastage.

The successful transition of a project through each of these stage gates should be reflected in the project data in SAP. User statuses are typically implemented to support this stage-gate management processes. The required data collection forms, checklists, and workflow to achieve a stage gate transition can be effectively supported using SAP Fiori apps.

Work Breakdown Structure (WBS) Elements

The effective use of WBS elements within the project definition will help control project execution. Naturally, large, and complex projects should not be controlled with a single WBS element as this doesn’t provide the required degree of granularity of analysis of cost and schedule performance.

On the other side, too many WBS elements can also cause difficulties in the appropriate assignment of purchase orders and timesheets. This can waste significant administrative effort reallocating costs between WBS codes.

To provide guidance in the appropriate level of granularity to adopt in structuring capital projects, many organizations make effective use of project templates. Suitable project templates can be defined for the common types of projects an organization undertakes. Templates reinforce best practices, make it easier for end-users, and provide consistency in analysis.

Assets Under Construction

Capital work in progress can be effectively controlled with assets under construction functionality in SAP.

The investment profiles that you configure and assign to WBS elements will determine how assets under construction (AuC) are handled. For larger capital projects it is highly recommended to monitor the accrued work-in-progress costs in individual assets. Your investment profile configuration will allow you to assign a default asset class to the AuC assets that get automatically created. The AuC asset class determines the financial classification of the capital work-in-progress and planned depreciation. Planned depreciation can be based on either budget or planned costs.

For example, if you need to separately report capital work in progress by investment category (e.g., land and buildings vs plant and equipment) separate asset classes and investment profiles should be configured accordingly.

The investment profile configuration also determines the basis for cost settlement to final fixed assets. Normal best practice is to enable both amount and percentage-based cost distribution.

Coding Masks and Object Numbers

SAP makes extensive use of smart numbering. Coding-mask functionality helps users interpret the level and purpose of various WBS elements.

Consistent project structures and thoughtful adoption of coding standards can improve the accuracy and reliability of postings and support effective monitoring and control.

Best practice would caution against excessive reliance on coding masks to classify WBS elements. Important attributes should be explicitly defined in the WBS master data and not rely on numeric coding for conventions.

For example, some organizations embed attributes such as investment reason, priority, asset class, scale, or organizational unit in their project number schemes. The key risk of this approach is that subsequent changes to these attributes can create inconsistencies.

The best practice approach is to keep numbering schemes as simple (and as short) as possible. Embedded attributes in the numbering scheme only where their inclusion would greatly facilitate usability, and not to support subsequent analysis.

For example, it is recommended to incorporate a CapEx/OpEx split in the WBS structure at level 2. At level 3, individual capitalizable components should be identified. Work packages are normally defined at level 4. The format of levels 1 to 3 should be consistent across all projects. However, at level 4, some familiar classifications can be embedded for ease-of-use. For construction of a building, for example, a breakdown by trade may provide a useful guide to the correct WBS selection.

User Fields and Classifications

There are a limited number of standard user fields available on a WBS. These include short text fields, numeric fields, dates, and checkboxes.

Careful up-front planning and design should be conducted to optimize the application of these fields, as they are readily accessible to end-users and are valuable for analysis purposes.

Commonly, these fields are utilized for cross-reference purposes to external project management, workflow, or document management systems.

Additionally, these fields may be used for classification and grouping of projects. For example, all projects related to a particular strategy or program can be identified by a common key here.

One of the checkboxes is often assigned to identify project budgeting pools.

In addition to the standard user fields, SAP incorporates a sophisticated classification system. This provides a very flexible and comprehensive framework for grouping and analysis of projects. However, as project classifications are slightly harder to access and maintain, they are not extensively utilized.

Surfacing projects through a Fiori interface can simplify the usability of the classification system and ensure that important project analysis can be done within the system as opposed to relying on extracts and off-system analysis.

Network Activities for External Purchases and Operations

Whereas WBS elements provide effective cost summarization, network activities in SAP are useful for defining required external goods and services.

External network activities identify the preferred vendor, pricing, quantities, and scheduling information. Network activities provide a direct connection to procurement processes to enable purchase orders to be efficiently raised and tracked through to receipt of goods and services.

Network Activities for Resource Allocation and Scheduling

Similarly, network activities enable the effective allocation of internal activity. Internal activities identify the providing work center and requested activity type.

This demand for internal services can then be reconciled with work center capacity to ensure that realistic timelines can be achieved.

Variations in scheduled dates can be tracked in detail to ensure that delivery timeframes can be reliably monitored.

Project Completion

What happens to project completion and has does this impact project set-up?

Asset Capitalization

All projects should start with the end in mind. For capital projects, the end-result is a productive fixed asset, appropriately valued and classified.

Project capitalization is triggered once a project WBS is technically completed, and a fixed asset record assigned in the settlement rules.

To simplify and expedite asset valuation and capitalization it is beneficial to have summary WBS elements that accumulate the related costs of a target fixed asset. Supporting activities can be reflected as lower-level WBS elements or related Network Activities.

Where an asset will be capitalized in tranches or phases, it often makes sense to create additional WBS elements. Whilst costs can be segregated and settled by period, there is often no simple cut-off. Handling these supplementary costs in separate WBS elements will facilitate clearer status management and simpler settlement rule definition.

Settlement Rules

Where project costs related to multiple assets are summarized in a single WBS element, the settlement rule will specify the allocation of cost to the target fixed assets.

For example, a significant investment may be procured under a single contract. For practical purposes, a single WBS element may be sufficient to control the planning, budgeting, and cost collection. However, if capitalization requires creation and valuation of multiple discrete assets, this can be accommodated in the settlement rules.

Settlement rules can be defined by amount or percentage. Percentage settlement has the benefit of ensuring that all costs are ultimately transferred from the project to the specified fixed assets. If periodic settlements are made from the project to fixed assets by amount, ongoing reconciliations will be required to ensure that all costs are settled on a timely basis.

Project Close-out

Closing-out projects on a timely basis and capitalizing assets in the correct accounting period are important financial controls. It is normally the responsible person who identifies project completion and defines the resulting fixed assets and settlements.

Project close out also involves several other participants including asset accountants, procurement officers, maintenance managers, finance, and departmental sponsors. Asset accountants are required to confirm depreciation classes and useful lives. Procurement officers close out any open commitments. Maintenance managers ensure that serviceable equipment is identified, and maintenance schedules assigned. Financial accountants update project forecasts and return any un-utilized budget. Sponsors confirm asset hand-over and commissioning have occurred.

The project close-out process can be effectively supported with a Fiori app to collect project status updates, asset details, cost splits, and obtain the approval of all participants before automatically orchestrating all the required back-end transactions.

Analytics

How will your project set-up impact project performance analytics?

Investment Program Positions

Senior executives are highly engaged in capital allocation and project approval processes. They require clear and concise reporting of capital expenditure forecasts.

A standard way of defining hierarchical investment management structures and rolling-up capital expenditure accordingly is to make use of Investment Programs within the Investment Management module of SAP. By linking project WBS elements into the investment program structure it is possible to produce meaningful executive reporting at appropriate levels of summarization.

For example, the investment program structure may identify business units as the primary reporting dimension, followed by region and legal entity.

Selection Profiles

Selection Profiles should be used to facilitate efficient and timely project analysis. Defining relevant information cubes based on important analysis dimensions will ensure that end users are able to easily analyze the information contained within SAP in a simplified and reliable way within standard SAP reporting tools.

SAP Analytics Cloud

SAP Analytics Cloud provides a robust platform for detailed project analytics and presentation. In addition to providing advanced charting and analysis of historical data, SAP Analytics Cloud now harnesses Artificial Intelligence (AI) and machine learning to provide predictive analytics.

Manual forecasts produced by project managers are notoriously optimistic. AI infused predictable analytics provides a more objective assessment of likely expenditure trends and outcomes.

Capital projects should be consistently structured and tracked to enable AI machine learning to improve its predictive capabilities.

Spreadsheets and Other End-User Reporting Tools

When SAP ERP was sold in the 90’s, elimination of spreadsheet-based processes was a key value proposition. Thirty years later, spreadsheets remain alive and well.

The key virtues of spreadsheets are their familiarity and flexibility. Spreadsheets empower end-users to meet their unique data preparation and analysis needs.

The goal of leveraging SAP to manage your capital projects more effectively should not be to replace Excel. The goal should be to provide a central and reliable single source of truth. Your implementation should allow end-users to both import and export data from and to spreadsheet formats efficiently. Provided that the source of truth remains SAP, empowering user in this way for unique requirements will ensure the quality and completeness of information within the system.

If you make it hard to upload or extract information from SAP, users will hesitate to maintain it there at all. This leads to islands of data that significantly undermine the reliability and effectiveness of the overall solution.

Productivity Boosts

What mechanisms are there to set up your projects more efficiently and consistently?

Project Templates

Project templates provide an effective and efficient way of driving consistency in project set-up. Consistency of project definitions greatly enhances project execution, control, and analysis.

However, whilst project templates provide a good baseline for project definition, they can be easily changed. This may suit individual project managers but does negatively impact their consistency. To maintain standardization of project set-up, many organizations route project creation to centralized resources. Project structures are defined in spreadsheet templates, and central administrators create the projects on behalf of project managers manually. This is obviously an inefficient and error prone process.

Integration from External Systems

To minimize the inefficiency of manually setting-up projects, but ensure consistency, some organizations rely on external integration.

Robotic process automation is a method of replicating manual project set-up activities. Due to the large number of potential variations in the set-up of projects ranging from small direct asset purchases to turn-around projects with thousands of WBS elements and activities, this is generally not an effective approach.

Outside-in integration of project set-up is feasible due to the availability of a good suite of APIs for project creation and maintenance. Many external systems do not, however, have all the required data elements to set up projects completely, and they rely on hard coding of defaults and business rules in the integration process. Supporting external integration can also be expensive due to the involvement of third-party technologies and reliance on external resources with no SAP experience.

A more successful approach to effective and efficient project set-up is to make use of Fiori Apps. Fiori apps can be tailored to meet user-experience expectations and enforce consistent and standardized project creation. The benefit of adopting SAP technology is that is leverages SAP technical resources. This reduces the risk and cost of miscommunication between technologies or specialist resources.

Project Impacts of your S/4HANA Migration

How will your project set-up vary as you transition to S/4HANA?

Availability Control

One key enhancement in project systems in S/4HANA is the ability to utilize planning versions to enforce availability control. Rather than maintaining budgets and plans in different transactions, at different degree of granularity, the planning and budgeting mechanisms can now be consistent.

For many organizations, this will greatly simplify the planning, budgeting, and forecasting process.

Clean Core

A key objective for many organizations that migrate to S/4HANA is to reduce the amount of customization in their systems so that they can ultimately move to SAP Public Cloud services and eliminate the pain of upgrades in the future.

If you have custom integrations, tables, screens, reports or other enhancements in your SAP ECC system, your planning for S/4HANA should include a review of how to achieve a ‘clean core’.

One example is to move custom project reports from ECC and provide the analysis capabilities in SAP Analytics Cloud on SAP’s Business Technology Platform (BTP).

SAP Fiori

Another key opportunity to address the end-user experience and process standardization objectives is to adopt SAP Fiori as your user-interface technology. The most obvious change with S/4HANA is the transition from the grey SAPGUI client to web-based Fiori Apps.

SAP Fiori Apps are accessible on any browser-enabled device including mobile devices which can be a real benefit to on-site project users. Fiori Apps can be tailored to closely reflect your capital project use-cases.

You don’t have to wait for your S/4HANA upgrade to commence utilizing Fiori for capital project set-up and control. Many organizations deploy Fiori in their ECC environment in advance of their migration. If your ECC support level does not support embedded Fiori apps, you can always deploy Fiori on a Font-End server or run your Fiori apps directly on SAP BTP.

You can build your own Fiori apps for CapEx management or adopt pre-built solutions like IQX CAPEX. IQX CAPEX is a suite of Fiori apps that addresses the complete CapEx process from project initiation, through project creation, forecasting, project completion, and analysis.

IQX CAPEX is built on IQX AppBuilder to allow rapid configuration of the user experience, workflow, and transactional orchestration. IQX AppBuilder is an SAP-certified addon that runs on both ECC and S4/HANA environments.

Transformation Opportunities

If your current project classifications and set-up have become inconsistent and sub-optimal, your S/4HANA migration is a perfect opportunity to revisit your capital project processes.

A transformation of your capital project structures will include updating your configuration settings, refining your project templates and set-up practices, engaging SAP analytics cloud, and delighting participants with intuitive Fiori apps with accelerated workflows and automatic transaction orchestration.

Project Process Optimization Benefits

How can transformation of your project initiation and set-up process provide real business benefits?

Productivity

Setting up projects manually and relying on extracted data for spreadsheet-based analytics is a waste of human capital.

By digitalizing your project initiation forms, workflows and SAP updates, you liberate your users and administrators to focus their attention on the substantive challenges of capital project delivery.

Mitigate Risk of Wasted Expenditure with Better Reporting

A timely, well-structured, consistent, and single source of truth is essential to reliable reporting. This data should include plan, budget, forecast, actual and commitment information at a granular level. In addition to an historical perspective, the data should provide predictive analytics.

With quality information, and by focusing management attention on both past and projected variances, mitigating action can be taken sooner to prevent wasted expenditure.

Achieve Higher Return on Investment (ROI)

Capital project portfolios are constrained by human resource and financial capacity. Selecting the best projects within those constraints is the key project portfolio management challenge.

Optimizing your project portfolio relies on effective project evaluation and prioritization. Multi-dimensional scoring factors in risk, return and strategic alignment will help ensure that the most valuable projects are ranked highly.

Reliable financial analysis metrics and scoring mechanisms will enable executives to make confident and informed project and portfolio approval decisions, which maximize the organization’s return on investment.

Improve Environment, Social and Governance (ESG) compliance

In recent years, community expectations have increased for organizations to meet environmental, social and governance (ESG) objectives.

Environmental drivers are now a major category of capital investment as organizations rush to cut greenhouse gas emissions, preserve natural resources, and reduce waste. This requires a new set of project evaluation and prioritization criteria beyond traditional financial metrics.

As part of a digital transformation, legacy project initiation forms and processes can be enhanced to capture environmental investment reasons, evaluate alternative approaches with new measures, and engage new executive roles.

Probity of Approvals

The investment decisions made by executives are under intense scrutiny by regulators and activist investors. The probity of the executive decision-making process relies on quality data, and evidence of compliance with approval policies.

A key opportunity with the digital transformation of capital project processes is to bring the workflows onto the SAP technology platform. Having all data collection, approval workflow and processing on a single technology stack will help ensure effective process governance.

Strategic Optimization

Capital projects are all future focused. Time and money are invested today to produce long-term benefits for the future.

It is imperative, therefore, that any transformation of the capital project process has long-term strategic outcomes as a primary goal.

Project initiation forms and processes should explicitly seek to align investment proposals to defined strategic outcomes.

Project forecasting should include both project costs and future benefits. Reporting processes should assist executive continuously evaluate their project portfolio. Just because a project has started, doesn’t it mean it shouldn’t be stopped if a better allocation of time and money will produce a more strategically aligned result?

Changing the reporting emphasis from historical budget variance analysis to predicative value realization in line with strategic outcomes will have a profound impact on organizational success.

Leverage Fiori to Create and Manage Capital Projects in SAP®

Projects involve significant investment of time and money. SAP provides rich functionality to support the effective and efficient definition, prioritization, execution, control, analysis, and successful completion of projects. Optimizing your SAP project processes will deliver substantial business benefits.

A key technological capability that should be applied to project set-up and control is SAP Fiori. Whilst the core capabilities of SAP Project Systems have been available for decades, SAP Fiori presents this functionality in a radically improved way.

Traditionally, access to SAP Project Systems’ grey screens was restricted to the few. SAP Fiori, by contrast, enables user-friendly access to all participants. SAP Fiori apps provide simplified and readily accessible web application access everywhere. Project managers can more easily initiative and update their project structures, statuses, and plans. Senior executives are able to approve budgets and outcomes directly within the system using any device.

Leverage SAP Fiori to capture the key data from the people who know. Collaboratively engage technical experts to review and endorse submissions. Quickly obtain approval from executives in accordance with delegation of authority policies. And then systematically automate the set-up of your projects, plans, and budgets in accordance with best practices.

By optimizing your project processes, you will more effectively prioritize the projects that matter most, deliver them more confidently, and maximize your return on investment of your human and financial capital. Focusing on the future, and aligning project portfolios with strategic objectives, will ensure that these goals are achieved sooner, at lowest cost, and least risk.