PPM BluePrint

<CLIENT> SAP PPM Blueprint Document
Date: 02 November 2012
Commercial-in-Confidence
Version:
Status: Draft
Address and Tel No.

<Client>
Building 6
Beckett Way
Dublin
Table of Contents
1. Introduction.......................................................................................7
2. Overview – Project and Portfolio Management................................8
2.1 Services Commercial Lifecycle..............................................................................................8
2.1.1 OPPORTUNITY IDENTIFIED 11
2.1.2 OPPORTUNITY QUALIFIED 11
2.1.3 HIGH LEVEL ROM 11
2.1.4 DETAILED ESTIMATE 19
2.1.5 FINAL CONTRACT 21
2.2 OPERATIONAL PLAN......................................................................................................... 21
2.2.1 PROJECT CLOSURE 23
2.2.2 PROJECT BONUS 24
2.3 Engineering Core Business Lifecycle...................................................................................24
2.3.1 OPPORTUNITY IDENTIFIED (Product Management - Analysis) 25
2.3.2 OPPORTUNITY QUALIFIED (Product Management - Cost) 25
2.3.3 HIGH LEVEL ROM (Product Management - Design & WP Definition) 25
2.3.4 DETAILED ESTIMATE (Product Management – Ready for Implementation) 30
2.3.5 FINAL CONTRACT (Product Management – Ready for Implementation) 30
2.3.6 OPERATIONAL PLAN (Product Management - Operational Plan) 30
2.3.7 PROJECT CLOSURE (Product Management - Closure) 31
2.3.8 PROJECT BONUS (Not Applicable) 32
3. Commercial Lifecycle Structures....................................................32

3.1 Services Fixed Price............................................................................................................ 32
3.2 Services Time and Materials................................................................................................ 33
3.3 AT&T.................................................................................................................................... 33
3.4 Engineering Core................................................................................................................. 34
3.5 Engineering Assist............................................................................................................... 36
3.6 CPSE................................................................................................................................... 36
3.7 Overhead Projects............................................................................................................... 37
3.8 Project Templates................................................................................................................ 37
3.9 Check Lists.......................................................................................................................... 38
3.10 Questionnaires..................................................................................................................... 38
4. Value Flow......................................................................................39
4.1 Integration............................................................................................................................ 39
4.2 Landscape - Interfaces........................................................................................................ 40
4.3 Profit Centre, Cost Centre and Project.................................................................................41
5. Resource Planning Process...........................................................42

5.1 Roles and Role Types as the Starting point for Resourcing.................................................42
16/10/2019 Commercial in Confidence Page 2 of 163

5.2 Resource search from within a Project................................................................................43
5.3 Resource and Staffing Views............................................................................................... 45
5.3.1 Project-Related View of Staffing 45
5.3.2 Resource–Related View of Staffing 46
5.4 Resource Project with Resource from other Resource Pool................................................47
5.5 Loan a Resource.................................................................................................................. 50
5.6 Resource vacancy and Dummy resources as indicators for Recruitment............................53
5.7 Longer absence from work.................................................................................................. 53
5.8 Emergency Resource Project.............................................................................................. 53
5.9 Inactive Ressources............................................................................................................. 54
6. Timesheet Confirmation Process....................................................54

6.1 Time Registration and Approval........................................................................................... 54
6.2 Timesheet Development...................................................................................................... 57
7. Business Planning..........................................................................60
7.1 Currencies and Exchange Rates......................................................................................... 60
7.1.1 Currencies in the Financials 60
7.1.2 Use of Currency and Exchange Rates in Controlling 63
7.1.3 Currencies in PPM 64
7.2 Cash Flow............................................................................................................................ 67
7.3 Invoice Process.................................................................................................................... 68
7.3.1 Invoice Process – Milestones 68
Invoice Process – Time and Materials 74
7.3.2 Invoice Process – Expenses 75
7.3.3 Non Billable Portfolio Item Types 75
7.4 Health Indicators.................................................................................................................. 77
8. Change Requests and Reforecast..................................................78

1.1 Reforecast Costs and Revenues......................................................................................... 78
9.1 Large Change Request........................................................................................................ 78
9.2 Small Change Request........................................................................................................ 79
9.3 Project Re-baseline.............................................................................................................. 79
8.1 PPM Version Snapshots...................................................................................................... 79
8.2 CO Version.......................................................................................................................... 81
9. Month-end Process........................................................................82
9.1 Work in Progress................................................................................................................. 82
10. HR PPM Integration........................................................................86

10.1 Role Type and HR Integration.............................................................................................. 86
10.2 HR Employee to PPM Business Partner Mapping...............................................................91
11. Reporting........................................................................................94

11.1 Overview.............................................................................................................................. 94
11.2 WIP Report NAR WIP_Feb12.xlsx.......................................................................................97
11.3 Support et al detail Timesheet Cost Feb.xlsx – User Analysis.............................................98
11.4 Support et al detail Timesheet Cost Feb.xlsx - Project Analysis...........................................99
11.5 NAR Profitability and Cost Detail_Feb12.xlsx - NAR Billable Cost USD..............................99
11.6 NAR Profitability and Cost Detail_Feb12.xlsx - NAR Non Billable Cost USD......................99
11.7 YTD Services Regional Profitability Summary_Jan12.pdf - Consolidated.........................100
11.8 YTD Services Regional Profitability Summary_Jan12.pdf – Region Business Unit...........100
11.9 YTD Services Regional Profitability Summary_Jan12.pdf – Transfer Summary................100
11.10 1.6 YTD Services Regional Profitability Summary_Jan12.pdf – Travel report Euro...........100
11.11 Gaps Report APAC EMEA 2012-03-22.xlsm - EMEA 70% Mar.........................................102
11.12 120329 - Resources-Status-Combined.pdf........................................................................104
11.13 120118h-GPO-v1.0.xlsm.................................................................................................... 111
11.14 CALA Forecasted Project Profitability_Feb12.pdf..............................................................112
11.14.1 Forecasted Gross Margin % on Bucket and Portfolio Item 113
11.15 CPSES Monthly Billability Analysis _Feb12.xlsx - Bill Type Summary...............................117
11.16 Departmental Cost Summary_support_Feb 2012.xlsx – Environmental Engineering........117
11.17 Departmental Cost Summary_support_Feb 2012.xlsx – Headcount..................................117
11.18 Departmental Cost Summary_support_Feb 2012.xlsx – Costed Time Summary...............118
11.19 Departmental Cost Summary_support_Feb 2012.xlsx – Support Activity Summary..........118
11.20 Engineering Monthly Billability Analysis _Feb12.xlsx - Bill Type Summary........................119
11.21 Engineering Monthly Billability Analysis _Feb12.xlsx - Bill Type by Dept...........................119
11.22 Engineering Monthly Billability Analysis _Feb12.xlsx - Overhead Hrs................................119
11.23 Engineering Monthly Billability Analysis _Feb12.xlsx - Eng Hrs.........................................119
11.24 Engineering Monthly Billability Analysis _Feb12.xlsx - Non Eng Hrs..................................119
11.25 Engineering Monthly Billability Analysis _Feb12.xlsx – Total Hours by User......................120
11.26 Engineering Monthly Billability Analysis _Feb12.xlsx - Overhead by User.........................120
11.27 Invoices Forecast Report................................................................................................... 120
11.28 Services Regional Profitability and Cost Detail_Feb12.xlsx...............................................121
12. Base Configuration settings..........................................................121

12.1 Object Types for Object Links (System Integration to SAP ECC)......................................121
12.2 Time Units.......................................................................................................................... 122
12.3 Areas................................................................................................................................. 123
12.4 Project Types..................................................................................................................... 124
12.5 Role Types......................................................................................................................... 124
12.6 Priorities............................................................................................................................. 125
12.7 Project Reasons................................................................................................................. 126
12.8 Roles.................................................................................................................................. 126
12.8.1 Role Functions 127

12.9 Status Networks................................................................................................................. 127
12.10 <Client> Portfolio Structures.............................................................................................. 129
12.11 Financial Categories.......................................................................................................... 131
12.12 Financial Views.................................................................................................................. 131
12.13 Portfolio Types................................................................................................................... 133
12.14 Linkage of Portfolio Type to Financial category..................................................................133
12.15 Linkage of Portfolio Type to Financial category..................................................................134
12.16 Portfolio Category.............................................................................................................. 135
12.17 Dashboard Configuration................................................................................................... 135
12.17.1 Staffing Status 136
12.17.2 Schedule Status or Percentage of Completion 136
12.17.3 Budget Status 136
13. Authorizations...............................................................................137
13.1 General Authorisation........................................................................................................ 138
13.2 PPM Composite Role Mapping to <Client> Personnel.......................................................139
13.3 Portfolio and Project-Specific Authorisation.......................................................................141
13.4 Portal Authorisation............................................................................................................ 143
14. Workflow and dashboards............................................................144

15. Data Migration..............................................................................148
16. Bespoke Developments................................................................153
17. Terms and Definitions...................................................................154
18. SAP Terminology and Integration.................................................161

Document Control
Version Issue Date Authors Comments

0.1 31 August 2012 David J Frederick Initial Draft
0.2 10 September 2012 David J Frederick Finished Draft
0.3 05 October 2012 Peter S Rosolski Draft in progress
0.4 02 November 2012 Peter S Rosolski Draft in progress of process driven BP
Daragh O’Gorman
14 16 November 2012 Draft
Udo Stadelmann
Daragh O’Gorman
15 20 November 2012 Draft
Udo Stadelmann
Daragh O’Gorman Draft following feedback from previous
17 30 November 2012
Udo Stadelmann version.
Draft Signoff Sheet
Signature Date
TBD
Signature Date
TBD
Signature Date

1. INTRODUCTION
This document is the blueprint for the PPM area within the <Client> Everest project. This document
can be read in conjunction with the HR blueprint for the same project to provide a complete picture of
the SAP solution for the Human Resource and Project departments.
The document is divided into sections that can be viewed quickly in the table of contents. The first two
chapters provide an overview of the Services and Engineering project lifecycles. The subsequent
sections outline the smaller processes that are tributaries of the main lifecycle. After the sub-
processes are explained the integration between HR and PPM is discussed. The data migration,
reporting chapter and the authorisation chapter come at the end. In section 12 the main configuration
elements are discussed. There is a glossary and terminology section at the back that the reader can
use as a reference.
The solution described in this document is providing processes for the projects (engineering and
services) parts of the business. The solution is built on the SAP platform. The following table outlines
the modules deployed in the solution with a short description of their use.
Module Description of Role in the Solution
PPM Project Management The PPM Portfolio functionality provides a hierarchy
data structure in which projects are placed. The
Portfolio Management
revenues (wip and billed) and the costs of the
Resource Management projects roll up to portfolios so that top managers
and middle managers can view the project
performance under their responsibility.
The PPM Project functionality provides the
processes to build a project, estimate planned
costs, and assign roles and resources.
The PPM Resource Management functionality
provides processes to manage the resources in the
business and ensure that productivity is optimised
by assigning these resources to suitable projects.
PS Project System The PS module provides enhanced financial
reporting functionality and provides the basis for
future expansion of the solution, if <Client> decides
to move the ledger functionality away from
BusinessOne to the SAP ERP product.
HR Human Resources The HR provides the means to define the resources
in the business for use on projects. It defines these
people in terms of skill capability, location and cost.
ESS Employee Self Service The ESS functionality is required to enable easy
timesheet submission over the internet.
FI Finance The FI module is required as a basis for the
financial accounting that needs to take place to
manage the costs and revenues in the project.
CO Controlling The FI module is required as a basis for the
management accounting that needs to take place
to manage the costs and revenues in the project.
BusinessOne Business One Ledger and This system is currently running the accounting
Accounting System ledgers for <Client>. An interface to this system is
required to gather the revenue and non-labour costs
for projects.
BW Business Warehouse The BW system provides a Data Warehouse for the
data in the solution. Reports are built to enable

offline information to the users.
ABAP Programming Language of There are some developments and enhancements
SAP required in the solution. The ABAP module is
required to program these bespoke developments.
The section ‘Value Flow’ provides a more technical explanation of the interaction of these modules in
terms of financial flows.
2. OVERVIEW – PROJECT AND PORTFOLIO MANAGEMENT
2.1 Services Commercial Lifecycle

The following diagram outlines the lifecycle of the typical services project in <Client>. There are some
deviations from this lifecycle for some business units e.g. AT&T, Engineering. The sections
subsequent to this section will outline some of the differences to the typical process flow. The primary
reason for detailing one particular project is that it gives the reader a good overview of all aspects of
the solution in one process before the differences can be understood.
The first diagram provides the overview of the lifecycle.
Figure 1 <Client> Commercial Lifecycle Overview

The above diagram outlines the lifecycle in services. The table below lists the sub-processes
mentioned in the diagram. It also maps the sub-process to the section in the document that describes
more about the sub-process. There are many of the sub-processes that are small and sufficiently
described in the lifecycle overview chapter.
Phase Process Section
Opportunity Identified Portfolio Structuring Required Configuration Settings
Planning Pre-Sales Overview – Project and Portfolio Management, Service
Commercial Lifecycle
Opportunity Qualified Bid Questionnaires Overview – Project and Portfolio Management, Service
Commercial Lifecycle – Opportunity Qualified
High Level ROM Estimation Tool Overview – Project and Portfolio Management, Service
Rate Card
Forecast RevRes Overview – Project and Portfolio Management, Service
Initial Revenues & Costs
May not have Role
Planning

Indicative Margin

Update/Create Blended
Rate
Detailed Estimate Proposal Doc Overview – Project and Portfolio Management, Service
Project Code Request Overview – Project and Portfolio Management, Service
Time Registration Timesheet Confirmation Process
SOW Template Overview – Project and Portfolio Management, Service
Project Risk Overview – Project and Portfolio Management, Service
Item 61
Refined Forecast in Rev Reforecast Costs and Revenues
Res
Role Definition HR PPM Integration
Revenues & Costs Value Flow
People Assignment Resource Planning Process
Indicative Margin Overview – Project and Portfolio Management, Service
Billing Milestones Invoice Process

Final Contract Management Approval of Services Commercial Lifecycle
Project P & L
PCR Form Services Commercial Lifecycle
Committed Forecast Services Commercial Lifecycle
People assigned Resource Planning Process
Revenue confirmed Services Commercial Lifecycle
Cost confirmed Services Commercial Lifecycle
Margin Confirmed Services Commercial Lifecycle
Billing Milestones Invoice process
confirmed
Loan Resource Resource Planning Process
Emergency Resource Resource Planning Process
+/- headcount Reporting
Operational Plan Weekly Forecast Reforecast Costs and Revenues
adjustments (RevRes)
Demand adjusted Reforecast Costs and Revenues
People Assignments Reforecast Costs and Revenues
altered
Revenue Increases (i.e. Change Requests and Reforecast
Change Request)
Time Line changes Reforecast Costs and Revenues
P & L Re-baseline Project Re-baseline
Approval
Invoicing Invoice Process
Trigger Sheet
Invoicing Fixed Term. Invoice Process
Expenses
WIP & RevRes Month-end Process- Work in Progress
WIP Report
WIP & RevRes Reporting
Below Margin
WIP & RevRes WIP Report NAR WIP_Feb12.xlsx
Cash Flow
WIP & RevRes Final Contract
Risk Step 61
Reporting Reporting
Month End Profitability
Reporting Reporting
Month End Profitability

Reporting Reporting
Supply/Demand Capacity
Reporting Reporting
Project Governance and
Escalation
Project Closure Project closed in Rev Project Closure
Res.
Project closed in Journyx Project Closure
Project closed in SAP B1 Project Closure
Checklist Project Closure
Project Code Closure Project Closure
Final P & L Project Closure
Project Bonus Bonus Calculation Project Bonus
The below paragraphs will explain the process depicted in the diagram above. A subsection is created
for each part or stage in the lifecycle.
2.1.1 OPPORTUNITY IDENTIFIED

1. An opportunity is identified by the Sales Department. This is logged, tracked and monitored in
Sales Force and the Sales Department systems. It is not managed in SAP at this point.
2. It is the intention of the design that the Sales Department personnel will log their time to a
special “core project” time-code for a Business Unit or a Customer. This time-code (Overhead
project) is not the project code that is the main subject of the process in this section but it is
mentioned for completeness and clarity.
2.1.2 OPPORTUNITY QUALIFIED

From a system point of view there is no difference between the above parts and this stage.
2.1.3 HIGH LEVEL ROM

1. The primary difference between this part and the last parts is that this part must have a PPM
Project and Portfolio associated with it.
2. The Bid Questionnaire Excel spreadsheet is filled out by the Sales Person and stored on
Sharepoint. It is hyperlinked from the SAP Project so that it can be quickly accessed from
SAP by a user.

Figure 2 the spreadsheet hyperlinked to the Project
3. The PPM Project will be normally created from a Template. The Template project is a pre-cast
project with likely roles, tasks, phases, resources and indeed hours. The main use of
templates is to speed up the Project creation process and provide a consistent structure to
projects. It also removes the risk of someone forgetting to add a particular piece of data to a
project e.g. the 4 SAP phases. The user can override the defaulted data in the operational
project after a project template has been used (copied).
Figure 3 Create Project from Portfolio: the template used is logged within the Project for
reference.
4. It is important to note that the operational Project will not be updated automatically if the
used template is altered after the project is created. This is a copy function and not a
referenced function.
5. The typical project structure is for a services project is illustrated below.

The symbols beside the nodes in the Project structure depict the type of node. The below table will
indicate the use of the particular node type.
Symbol Use
Phase Task used to collect Labour costs
SAP Phase to enable the use of decision

points to drive approvals
SAP Project. The non-labour costs are
inserted at this point. The labour costs are
rolled up to this point from the lower level
nodes.
Figure 4 Project Structure showing the four phases
Figure 5 Project Structure showing Phase Tasks to enable costing at phase task level
6. The four SAP Phases are shown above. The phases are required primarily to drive the stage
gate approval process. After the first phase an Approval procedure takes place for the Project
estimation. After that approval a detailed project planning is to be done. At its end there will be
asked for another approval (CEO approval) to report the results of project planning including
staffing. This will be the baseline for the project execution.
These four Phases will be defaulted in from the template.

7. There are seven SAP Tasks which will sit under the SAP Phase Execute Project. These SAP
tasks are called colloquially within the project Phase-Tasks because they represent <Client>
Project Phases for a Services Project as defined within the <Client> methodology. The Phase-
Tasks are listed in the table below. These will be defaulted in from the template.
<Client> Project Phase

Solution Requirements
Solution Design
Configuration
System Test
System Integration Test
Customer Acceptance
Production Deployment
Special: Project Management
Special: 3rd Party
8. The last two items in the list above represent Phase-Tasks that overlap with the other Phase-
Tasks and allow the Project Manager to book their time at any point in the project.
Figure 6 Project Structure with phases, tasks, milestones and special tasks
9. The structure of the project is very important as it defines two main aspects of the system: the
cost granularity and the Timesheet Work List contents. The structure and granularity also
determines the amount of work required of Programme Managers to assign people to
projects. The Timesheet Worklist contents are the line items that appear as possible entries in
the CATS (Central Application Timesheet) screen for timesheets. Our typical design ensures
that there are seven phase-tasks. The Labour - costs per phase task can be calculated. The
program managers will need to assign the project team members to each and every Phase-

Task. The project team members will see each and every Phase-Task to which they are
assigned. The status of the Phase-Task controls whether it appears on the Timesheet. For
example, the Phase-Task when closed will not appear on the Timesheet Work List, so if the
Programme Manager closes the Phase-Task after it is complete, (s)he will reduce the amount
of redundant entries on the timesheet screen and prevent time from getting booked to the
complete phase. The same can be said for Phase-Tasks that are not released yet.
10. The symbols beside the nodes in the Project structure depict the type of node. The below
table will indicate the use of the particular node type.
Symbol Use
Phase Task used to collect Labour costs
SAP Phase to enable the use of decision

points to drive approvals
SAP Project. The non-labour costs are
inserted at this point. The labour costs are
rolled up to this point from the lower level
nodes.
11. The following table outlines the Phase-Task status. This status list will allow the project
manager to control whether labour costs can be booked to the particular Phase-Task.
Phase-Task Status
Created
Released
Closed
12. There is currently an <Client> estimation tool in MS Excel that is used to size many <Client>
projects. The users can continue to use this offline if they wish. This MS Excel can be
hyperlinked to the PPM Project for information purposes. However, the PPM project itself can
be used to estimate the cost of projects as it has access to blended labour cost rates on drop
down lists.
13. The user will define data for the customer engagement in two places: the PPM Project and
the Portfolio Item. These are on different screens but the user can navigate from Project to
Portfolio Item easily because of the 1:1 relationship between the two objects. The PPM
Project will contain the hours and roles and the labour costs of the project.
14. The PPM Portfolio Item will contain all revenues and all non-labour costs. The labour costs
from the PPM Project will be rolled up to the Portfolio item and will be visible there. But the
user cannot edit the labour costs at Portfolio item level. The user is forced to enter Hours,
Roles based on Role Types and Resources to define the labour cost in detail at Project level.
This is important as the Role provides the business with the skill capacity requirements as the
basic information for the staffing process leading to resources on roles and tasks.
15. The portfolio item has a status network that indicates where within the HIGH LEVEL ROM
part of the lifecycle the portfolio item is. The status that the Portfolio Item traverses is
illustrated below.
16. The status of the progress of the Portfolio Item is represented by a number of SAP fields.
There will be a User Status on the Portfolio Item that will store the status. In addition to this,
there will be a Portfolio Item Win Probability field. There will be two distinct fields to store this
information. The below table seeks to align the Win probability with the appropriate status,
however, other combinations are also technically possible e.g. 10% win probability but
Complete.
Portfolio Status Win Probability

1. Created 10% Projected
25% RFx
40% Proposal
2. Released 50% Release Agreed
3. Transferred 50% Release Agreed
70% Statement of Work
90% Statement of Work
4. Complete 100% Completed
5. 100% Fully Invoiced
6. Closed 100% Closed
7. 100% Dead Cancelled
8. Closed and
Bonused
17. The user can calculate the labour costs based on the Role Type or Resource. The Role Type
method requires that the person to perform the role is unknown. When the resource method is
chosen the person is known.
18. The Role Type is a drop down list with a blended rate configured behind it. The Role Types
and their structure will be defined by <Client>. The formula used to calculate the blended
rates is described in a later section. There will be a custom built search screen in the design
to aid the search for the correct Role Type amongst the around 100 Role Types.
19. When the Resource is placed into a Role, the Role Type Rate is ignored by the system and
instead the Cost Rate on the Business Partner is used. In our design the Rate on the
Business Partner is the blended rate indeed the same blended rate as the person’s Role
Type. But technically they are different fields. The Blended Rate Calculation program will keep
these consistent and equal. This program is described in more detail in a later section as part
of the enhancements to the system.
20. The user will add additional data on the Project level including additional tasks and
relationships between them if required.
21. The user will enter the non-labour planned costs and the planned revenues in the Financial
View of the Portfolio Item. These must be filled out according to the following SAP Cost
Category and Revenue Categories to aid the particular way that the Profit and Margin and
WIP are calculated. The formulae for these require that we separate, for example, hardware
costs. The Categories are as follows.
Figure 7 Portfolio Cost and Revenue Categories

22. The cost categories above will align to the accounts and cost/revenue elements defined in the
associated ERP system.

23. The financial revenues and costs can be forecasted per month. The user can forecast up till
the end of the project in one view. Totals for the year and for the project will be displayed in
the Financial View.
24. In order to see the current calculated profit or margin% the user will press a button that will
generate a report that calculates the margin% for labour based on the <Client> formula that
does not include hardware etc. For completeness the formula is written below.
Margin =
[(Deployment Services & Customisation)+(Global Production Ops)+(Support and Maintenance)
-
(Consultancy Costs + Travel + Other Costs + Travel Recharge)]
/
[(Deployment Services & Customisation)+(Global Production Ops)+(Support and Maintenance)]
The accumulated margin ITD and YTD will be presented on the financial view screen.
Figure 8 <Client> Services Margin Calculation

25. The revenue and costs of the project are rolled up to the portfolio bucket (a bucket is a folder
within the portfolio in which projects are placed) and further up the portfolio hierarchy. This
provides an interactive view to the portfolio managers on the performance of the portfolio and
projects under their responsibility.
Note: The Roll Up of Planned values to the Bucket Level will take place when the project/Portfolio
Item is released.
26. The margin% will be calculated at portfolio item level based on the total of all costs and
revenues of that portfolio item per cost category.

27. When the user is happy with the margin% achieved for the project (s)he will then send the
project for approval by creating an approval decision point on the Portfolio item level.
28. This will invoke a notification that will be sent to Global Operations so they can process this
Project and make this project released. A released project can receive labour costs.
2.1.4 DETAILED ESTIMATE

29. The global operations administrator will receive the Notification request to action the new
Project. The primary tasks of this part in the process are that the PS Project and WBS
structure will be created and the BusinessOne project code will be assigned to the Project.
Because of Character Restriction in Business One, the Project Code in PPM and SAP-PS must follow
the Code, set up in Business One. The Project Code Field in PPM will be locked down after a project
in PS is created.

30. The global operations person will create the BusinessOne Project Code in BusinessOne and
then type this Project Code into the SAP PPM Project as the PPM Project Number. This will
create the link from BusinessOne to SAP PPM via SAP Project system as part of the ERP
system.
It will enable BusinessOne ledger entries to be posted to the PPM Portfolio item Financial
view via the actual cost and revenue elements (without labour costs) on the Top WBS
element in the PS project when the PS project is created.
31. The status of the Portfolio is changed to indicate that the project has entered the detailed
planning phase to reach approval for the execution phase.
32. The Portfolio Item Type is altered to ensure that the capacity and financial information is rolled
up at this point.
33. The status of the project is changed which creates the PS Project definition and associated
WBS elements automatically via the multi-level automatic Accounting integration between
PPM Project Management and Project system. The WBS structure will be taken from the
Project in Project system and the System behaviour will be based on a Project Profile in the
SAP PS Project system connected to the PPM Project type through replication. The Top
WBS-Element of the PS Project in SAP ECC will be the same Number as the Project Number
in PPM and Business One.
34. In PPM the same Project number will be used for the ROM, the estimate and the project. This
number will appear on the CATS timesheet system. It will be the one number that uniquely
defines the project.
35. At this point in time the system will have the planned revenues and costs on Portfolio item
level and also the invoice milestones in the structure of the PPM Project representing the date
when the customer will be sent an invoice.(See also Chapter Business – Planning – Invoice
Process).
36. There is more likely to be greater detail added to the plan at this stage. This would include
more Tasks, Roles and the Roles to be staffed with <Client> resources (employees and
contractors). The processes by which the business would identify available people in other
Business Units are detailed in section Resource management.
37. The Cost and Revenue planning of the Project will be updated on the Portfolio Item
depending on the negotiation with the customer. The labour costs will be rolled up once again
from the project and the other line items (cost and revenue elements) will be adjusted
manually. This will change the margin% on the different revenue elements. The Manager
most likely will have sent a proposal or contract or an SOW at this point.

38. When the Customer and the <Client> project manager have come to a commercial
agreement the Project is ready to be base-lined and approved. This is the next part of the
commercial lifecycle and is approved by the CEO.
2.1.5 FINAL CONTRACT

39. The Project Manager decides to send the final margin and profit commitment to the relevant
Business Unit Manager and the CEO. This is the stage gate where approval is asked for to
start the Project execution phase.
40. The Project Manager will create the approval and assign the members of the approval board.
Figure 10 Approval dashboard
41. Global Operations will be part of that approval workflow and will baseline the project after the
approval has been granted by CEO and Business Unit Manager. This will freeze the project
Revenue and Cost and Margin forecasts as a planned baseline. The baseline will be taken
using CO version functionality of the financial Views
42. The approval request created by the project manager will invoke a notification to be sent to
the Business Unit manager and the Chief Executive Officer. The request for approval will
appear in the approval dashboard in their PPM Project Management WorkCentre.
43. The status of the project changes will be documented by snapshot versions to be displayed in
a project version report within PPM. So, the project manager can keep versions of the Project
and his/her estimates. It is also possible to see the CO versions that contain the financial
versions including the baselined revenue and costs.
2.2 OPERATIONAL PLAN
The user will enter the non-labour planned costs and the planned revenues in the Financial View of
the Portfolio Item. This is multi year and possible to enter data from start date to end date of a project
spanning many years.
44. When the Project becomes operational the project is moved to the operational plan stage.
The Win Probability is 50% or greater and the System Status is set as Release and
Transferred.
45. Actual Costs continue to flow from CATS and Business One Financial Bookings (See also
Chapter Value Flow – Integration). The Actual Revenues flow from BusinessOne also.
46. The Actual labour costs from CATS use a bespoke piece of code to override the standard
functionality and use a unit cost calculated on the basis of the salary paid to the individual.
47. The actual overtime time is logged as with any other hours. The overtime is identified in the
WIP calculation and not included so that overtime does not exaggerate the WIP results.
48. Through the course of the operational project the timesheets are approved by the project
manager via a workflow. The submitter submits the timesheet. An email is sent to the project
manager. The project manager selects the items that can be approved and presses the

‘Approved’ button. The items to be rejected are selected in a similar way and a ‘Reject’ button
is pressed to reject these entries.
49. As the Actual costs and revenues flow into the system there is foreign currency exchange rate
conversion happening. (See Chapter Business Planning – Currencies and Exchange
Rates).
50. The project manager can update his plan and his resource mix on a project and update the
forecasted revenue and costs (non - Labour Costs) and Portfolio Item at any time.
51. There is a control point each two weeks where the Project manager is requested to make
sure that the forecasted values are up-to-date. The project manager updates the same
financial view as illustrated below.
Note: Labour Costs will come from the project

52. The forecasts are updated every two weeks by the project manager. The baseline plan versus
forecast can be reported against as each of the revenue and costs exist on a separate CO
version. Indeed as the costs and revenue are categorised the baseline to forecast deviation
can be reported against at category level.
53. The two-week check points also serve as a way for the Project Manager to update the invoice
milestone payments to inform the business on the cash flow position and the revenue
achievement profile.
Figure 12 Cashflow calculation on the Project based on Revenue and Cost
Cash Flow can be seen on a financial View
54. The invoice process is described in more detail in the section Business Planning – Invoice
Process. The main points about this process are that the Milestones and the Revenue
forecast determine the invoices that need to be issued. The status network on the milestone
indicates clearly to the business that (a) the milestone has been achieved and (b) the revenue
can be invoiced.

55. The WIP calculation is described in section Month-end Process – Work in Progress. This
calculation is a bespoke development that will predict the WIP based on the currently
forecasted hours and the current balance of hours expended to-date and the total billed
revenue at completion. The intention is that this will run automatically every weekend on all
projects. It is also possible for a Project Manager to re-calculate this WIP at any time during
the week to perhaps see the effect of a reforecast of hours, for example.
56. The Risks on the project can be logged and viewed in a SAP Project Checklist.
Figure 13 Risks and Issues can be logged on a SAP Checklist

57. Any extra people or resources that the project manager might need on the project, is covered
in the section 4. The resources that might roll off the project can be signalled by the end date
on the Role on the project. This field provides a good way of the business monitoring the
precise date the resource will need a new project in order to maximise productivity.
2.2.1 PROJECT CLOSURE

58. The project closure part of the lifecycle is initiated by the Project Manager.
59. All the revenue milestones are achieved and invoices issued.
60. The Status of the Project and portfolio is changed to “Complete” to indicate that the project
has been completed from a delivery perspective. It might be the case that the Project
Manager and the business might keep the Item open for some time after as perhaps some
extra Costs might flow from BusinessOne.
61. The Status of the Project and Portfolio is changed to “Request to Close” when the Project
Manager is satisfied that no more costs or revenue are going to flow. It is OK for the project
manager to close the project when there are still outstanding Accounts Receivable invoices
unpaid. In other words the PPM project and portfolio is not concerned with the payment of
invoices, it is only concerned with the issue of invoices. This is because the technical
Interface will have already made sure that all actual Revenues, booked in BusinessOne are
transferred to PPM via the SAP ECC Financials (see also section Business Planning – Value
Flow and chapter Business Planning Invoice Process).
62. The Stage Gate functionality will be used in the closure process in the same manner in which
the approval and release project process. This is to say that the project manager will set up
an SAP approval and decision point and invite the necessary people required to instigate the
steps required to close the project.
63. The administrator will receive a notification email informing of the request to close after the
approval has been granted by Business Unit Manager.
64. The administrator closes the BusinessOne project code.
65. The administrator closes the PPM Project and portfolio. The final snapshot of the Actuals is
taken to preserve the actual margin achieved.
66. The final report is run to calculate the Margin and Profit achieved. This is checked by the
administrator before it is used in the bonus calculation.
67. The administrator checks that there are no outstanding unapproved CATS entries.

68. The administrator changes the Portfolio Item Status to “Closed".
2.2.2 PROJECT BONUS

69. The next part of the lifecycle is the calculation of the bonus. This is an accounting task and is
performed off system with the Bonus Calc Form.
70. The system will not produce a Profit and Loss account with exchange rate fluctuations
ignored. The system will produce the Profit and Loss account with the exchange rate
fluctuations included.
71. When the accounting department and the payroll department have finished with this part of
the process they set the status to “Closed and Bonused”. This is the final point in the process.
72. The Revenue and Costs for a project in the Closed status is still seen in the portfolio. The
portfolio manager will still be able to see the performance of this project in the context of the
performance of the portfolio.
2.3 Engineering Core Business Lifecycle
The following diagram outlines the lifecycle of the typical engineering project in <Client>.
Figure 14 <Client> Product Management Backlog Lifecycle
The diagram aligns to the services process outlined in the section above and so we can streamline
the engineering and services processes within <Client>. The table below maps the engineering phase
to the services lifecycle phases.
Engineering Services
Analysis Opportunity Identified

Cost Opportunity qualified
Design and WP Definition High level ROM
Ready for Implementation Detailed Estimate
and
Final Contract
Operational Plan
Project Closure
<Not Applicable> Project Bonus
The below paragraphs will explain the Engineering process depicted in the diagrams above.
2.3.1 OPPORTUNITY IDENTIFIED (Product Management - Analysis)

1. An opportunity is identified by the Sales Department or Product Management. It is not
managed in SAP at this point.
2. It is the intention of the design that the Product Management personnel will log their time to a
special “core project” time-code. This time-code (Overhead project) is not the project code
that is the main subject of the process in this section but it is mentioned for completeness and
clarity.
2.3.2 OPPORTUNITY QUALIFIED (Product Management - Cost)

There is no difference between this part and the previous part of the process.
2.3.3 HIGH LEVEL ROM (Product Management - Design & WP Definition)

3. The PPM Project is normally created from a Template. The Template project is a pre-cast
project with likely roles, tasks, phases, resources and indeed hours. The main use of
templates is to speed up the Project creation process and provide a consistent structure to
projects. It also removes the risk of someone forgetting to add a particular piece of data to a
project e.g. the 4 SAP phases. The user can override the defaulted data in the project after a
template has been used.

Figure 15 Create Project from Portfolio: the template used is logged within the Project for
reference.
4. It is important to note that the Project will not be updated automatically if the template is
altered after the project is created. This is a copy function and not a referenced function.
5. The typical project structure is for an Engineering project is illustrated below.
Figure 16 Project Structure showing the four phases to drive the approval
Figure 17 Project Structure showing work packages to allow cost reporting at work package
level
6. The four SAP Phases are shown above. The phases are required primarily to drive the stage
gate approval process. After the first phase, a Head of Engineering Approval takes place for
the Project estimation. The engineering core process does not require a CEO approval like
the services project.
These four Phases will be defaulted in from the template.
7. The phase-tasks present in the services project are not used in the engineering process
structure. This means that time and cost is recorded against the Work Package and not the
phase of the work package.
8. The following table outlines the possible engineering Task status. These statuses will allow
the project manager to control whether labour costs can be booked to the particular work
package. A person cannot submit time against a Closed work package. Additional status are
present in the Engineering project task to enable the project manager to record the phase of
the Work Package. This is a small difference to the Services status.
Phase-Task Status
Created
Released Backlog

Released Design
Released Implementation
Released Verification
Closed
These Engineering status are illustrated in the picture below.
They will be selectable from the popup box created after pressing the Status Management button.
9. The engineering project will not have revenues associated with it. So, revenues will not be
filled in on the PPM portfolio item. Forecasted labour costs will be automatically filled out
based on the Project resourcing data.
10. The PPM Portfolio Item can contain non-labour costs. The labour costs from the PPM Project
will be rolled up to the Portfolio item and will be visible there. But the user cannot edit the
labour costs at Portfolio item level. The user is forced to enter Hours, Roles based on Role
Types and Resources to define the labour cost in detail at Project level. This is important as
the Role provides the business with the skill capacity requirements as the basic information
for the staffing process leading to resources on roles and tasks.
11. The portfolio item has a status network that indicates where within the HIGH LEVEL ROM
part of the lifecycle the portfolio item is.
12. The status of the progress of the Portfolio Item is represented by a number of SAP fields.
There will be a User Status on the Portfolio Item that will store the Status. In addition to this,
there will be a field to store win probability.
13. The user can calculate the labour costs based on the Role Type or Resource. The Role Type
method requires that the person to perform the role is unknown. When the resource method is
chosen the person is known.
14. The Role Type is a drop down list with a blended rate configured behind it. The Role Types
and their structure will be defined by <Client>. The formula used to calculate the blended
rates is described in a separate Functional Specification. There will be a custom built search
screen in the design to aid the search for the correct Role Type amongst the approximately
100 Role Types.

15. The Engineering resources will be associated with the Engineering Organisation Units and
can be searched in this manner.
16. When the Resource is placed into a Role, the Role Type specific Cost Rate is ignored by the
system and instead the Cost Rate on the Business Partner is used. (E.g. the Role Type is
defined with a Rate Rate 1, wich is calculated with 100,-- Euro per hour. The assigned
Business Partner is defined with Rate 2, which is calculated with 120,-- Euro per hour.
Planned Labour Costs will be determined by using the Business Partner Rate).
17. It is not possible in the standard SAP system to assign a feature team as a team to a Work
Package. The Project Manager will be required to assign the team members one at a time. It
is possible for the PPM system to group the resources into feature teams using PPM Team
functionality.
18. It will be possible to represent the Feature Teams as HR Organisation Units in PPM. This will
be different to the HR Organisation Units in ERP that will link resources to Line Managers.
The below screen shots show the Organisation Unit of Feature teams and the resulting
screen enabling the search by Organisation Unit.

19. The cost categories used to define the costs for the engineering project will align to the
accounts and cost/revenue elements defined in the associated ERP system.
20. The financial costs can be forecasted per month. The user can forecast up till the end of the
project in one view. Totals for the year and for the project will be displayed in the Financial
View on Portfolio Item Level.
21. The costs of the project are rolled up to the engineering product portfolio bucket (a bucket is a
folder within the portfolio in which projects are placed) and further up the portfolio hierarchy to
the engineering business unit. This provides an interactive view to the portfolio managers on
the performance of the portfolio and projects under their responsibility.
22. When the user is happy with the costs achieved for the project (s)he will then send the project
for approval by releasing an approval decision point on the Portfolio item level.

23. This will invoke a notification that will be sent to Global Operations so they can process this
Project and make this project released. A released project can receive labour costs via CATS
Time Registration.
2.3.4 DETAILED ESTIMATE (Product Management – Ready for Implementation)

24. The global operations administrator will receive the Notification request to action the new
Project. The primary tasks of this part in the process are that the PS Project and WBS
structure will be created and the BusinessOne project code will be assigned to the Project.
25. The global operations person will create the BusinessOne code in BusinessOne and then
type this into the SAP PPM Project as the PPM Project Number. This will create the link from
BusinessOne to SAP PPM via SAP Project system as part of the ERP system. It will enable
BusinessOne ledger entries to be posted to the PPM Portfolio item Financial view via the
actual cost and revenue elements (without labour costs) on the Top WBS element in the PS
project when the PS project is created.
26. The Portfolio Item Type is altered to ensure that the capacity and financial information is rolled
up at this point.
27. The status of the project is changed to “Released and Transferred” which creates the PS
Project definition and associated WBS elements automatically via the automatic Accounting
integration between PPM Project Management and Project system. The WBS structure will be
the same as in the PPM - Project system and the System behaviour will be based on a
Project Profile in the PS - Project system connected to the PPM Project type through
replication. The created TOP WBS Element in SAP ECC Project System will be used as
Costing Object during Financial Bookings, coming via the Interface from BusinessOne.
28. The same Project number will be used for the ROM, the estimate and the project. This
number will appear on the CATS timesheet system. It will be the one number that uniquely
defines the project.
29. At this point in time the system will have the planned costs on Portfolio item level. (Manually
Planned Costs (and revenues) for Non Labour costs and Labour costs, rolled up from the
project tasks.
2.3.5 FINAL CONTRACT (Product Management – Ready for Implementation)
30. Global Operations will baseline the project. This will freeze the project Cost and plan. The
baseline will be taken using CO version functionality.
31. The status of the project changes will be documented by snapshot versions to be displayed in
a project version report within PPM. So, the project manager can keep versions of the Project
and his/her estimates. It is also possible to see the CO versions that contain the financial
versions including the baselined costs.
2.3.6 OPERATIONAL PLAN (Product Management - Operational Plan)

32. When the Project becomes operational the project is moved to the operational plan stage.
33. Actual Costs continue to flow from CATS (Labour Costs) and BusinessOne (Financial
Bookings, transferred to SAP ECC and PPM).
34. The Actual labour costs from CATS use a bespoke piece of code to override the standard
functionality and use a unit cost calculated on the basis of the salary paid to the individual.

The System will not use the Planned Rate (coming from the Business Partner Rate) for actual
Bookings. Instead of this a person specific calculated actual rate will be used to calculate and
transfer person specific Labour Costs to the project.
35. The actual overtime time is logged as with any other hours. Accounting WIP is not relevant for
Engineering Projects.
36. Through the course of the operational project the timesheets are approved by the project
manager via a workflow. The submitter submits the timesheet. A workflow and MS Outlook
email is sent to the project manager. The project manager selects the items that can be
approved and presses the ‘Approved’ button. The items to be rejected are selected in a
similar way and a ‘Reject’ button is pressed to reject these entries.
37. As the Actual costs and revenues flow into the system via the BusinessOne Interface to the
SAP ECC Financial and Controlling Table there is foreign currency exchange rate conversion
happening. The foreign currency treatment is outlined in section Business Planning –
Currencies and Exchange Rates.
38. The project manager can update his plan and his resource mix and update the forecasted
costs in the project at any time.
39. There is a control point each two weeks where the Project manager is requested to make
sure that the forecasted values are up-to-date. The project manager updates the same
financial view with the forecasted costs.
40. The forecasts are updated every two weeks by the project manager. The baseline plan versus
forecast can be reported against as each of the revenue and costs exist on a separate CO
version. Indeed as the costs and revenue are categorised the baseline to forecast deviation
can be reported against at category level.
41. The Risks on the project can be logged and viewed in a SAP Project Checklist.
Figure 18 Risks and Issues can be logged on a SAP Checklist

42. Any extra people or resources that the project manager might need on the project, is covered
in the section on resourcing. The resources that might roll off the project can be signalled by
the end date on the Role on the project. This field provides a good way of the business
monitoring the precise date the resource will need a new project in order to maximise
productivity.
2.3.7 PROJECT CLOSURE (Product Management - Closure)

43. The project closure part of the lifecycle is initiated by the Project Manager.
44. The Status of the Project and portfolio is changed “Complete” to indicate that the project has
been completed from a delivery perspective. It might be the case that the Project Manager
and the business might keep the Item open for some time after as perhaps some extra Costs
might flow from BusinessOne.
45. The Status of the Project and Portfolio is changed to “Request to Close” in the decision point
when the Project Manager is satisfied that no more costs are going to flow.

46. The Stage Gate functionality will be used in the closure process in the same manner in which
the approval and release project process. This is to say that the project manager will set up
an SAP approval and decision point and invite the necessary people required to instigate the
steps required to close the project.
47. The administrator will receive a notification email informing of the request to close.
48. The administrator closes the BusinessOne project code.
49. The administrator closes the PPM Project and portfolio. The final snapshot of the Actuals is
taken to preserve the actual costs expended.
50. The administrator checks that there are no outstanding unapproved CATS entries.
51. The administrator changes the Status to “Closed".
2.3.8 PROJECT BONUS (Not Applicable)

52. This part of the process is irrelevant to the engineering business.
3. COMMERCIAL LIFECYCLE STRUCTURES
3.1 Services Fixed Price
The above section described the Project process including the estimation process for Services Fixed
Price projects at <Client>. This is the main focus of the Everest PPM project at <Client>. The
subsections below outline the other Project Types. The main difference is the structure of the project
master data itself. The process and the steps are very similar to the Fixed Price project explained
above.
It is worth noting that the user can view these structures or any template or project structures in Gantt
Chart view by choosing the Graphic option.
Figure 19 Gantt chart view of a template or a project

3.2 Services Time and Materials
For Time and Material projects the Cost/Revenue rate in PPM project management could be used to
calculate the costs and the revenues based on blended rates for roles and the revenue rate agreed
with the customer. The SAP standard Revenue rate can only be used if the same Price per Hour is
the same for each member of the blended role type. The solution appreciates that this is not likely but
this functionality is included for completeness.
Time and Material Projects will have their own Project type and Item type. The cost estimation will be
based on the amount of hours planned in the PPM project. Planned revenues are estimated in the
same way as the Fixed Price Project Type.
The Services Time and Materials project Type operates in the same way as the Fixed Price Project
Type. The extra Project Type is only used for information purposes and to enable easy reporting.
3.3 AT&T
The structure of an AT&T project is different (seven main/phase tasks). This will be reflected in the
structure of the templates for AT&T.
The structure of the AT&T project is illustrated below. This structure can be used at AT&T if they want
to cost labour costs at phase level: it will however mean that they will need to assign people at each
phase-task. It was agreed in the workshops that it is unlikely that AT&T will use this structure as a
more simple structure is typically required in AT&T. The paragraphs after the illustration will outline this
more simple approach.
Figure 20 AT&T detailed project phase structure
The main difference in AT&T consists of the "very short term" assignments of resources to a project.
This will be reflected also in the templates. They will contain not only roles but also resources
assigned to the roles.
Our recommendation is to assign the resources to the tasks with a start and an end date of each
assignment. This is different from the existing process at AT&T and may cause some additional report
for a more formalized planning of resources and will lead to an improved tracking of resources.

The below project structure illustrates the more simple AT&T structure where resources are assigned
to one task representing the entire executable project. This structure is more suitable when there are
many resources working on many projects and they alternate the project they work on a daily basis. In
this scenario we assign the people for the duration of the project so that they can book time.
Figure 21 AT&T Structure where people are assigned to the Phase Task called Execution and
Estimation
The advantage of the above simplified structure is that people only need to be assigned to one phase-
task which is a reduction in administration time.
The disadvantage is that labour costs are collected at a project level and not at a project phase level.
It should be noted that capacity planning requirements can only be driven if the requirements are
typed into the project. If the resources are merely assigned with either no workload or full work load
on several projects then the capacity management will not be accurate.
It is important to note that the same SAP phases are contained in the AT&T project to drive the
identical approval process as the services Project Types. The description of the approvals for
Release, Approval and Closure in the sections above are identical for the AT&T project.
It should be noted that the Journyx-type functionality where people are assigned to groups of projects
that is described in section 2 can also be used to reduce the administration overhead further. This is
non-standard SAP functionality and will be built using ABAP to alter the available project codes in the
timesheet entry screen.
3.4 Engineering Core

Engineering Core consists of the development of new products and the development of new releases
for existing products. A new release is represented by a PPM project. This project consists of work
packages as tasks and the members of the feature teams as resources assigned to roles.
The Work Packages in an Engineering Core project fall into two categories: the scheduled ones and
the backlog. SAP will reflect these two groups.
The scheduled tasks (with relationships between each other) and staffed tasks are the prioritized
ones. This is very viewable on the Gantt chart. These Work Packages are listed under the Phase:
Execution and Estimation.
It will be also possible use the sort field of the Task to prioritise the work-package within the “release”
or PPM Project. This enables a ranking of all work packages in the project.

Figure 22 Sort field used to indicate the priority rank of the work package
The other tasks that are not scheduled (Work Packages) are "the Backlog list" of that project.
These are not yet planned and scheduled but are ready to be moved in the plan easily if the
project manager has the capacity to increase the scope of the project.
The below illustrates the structure of the Engineering Core projects. The reader will note that the
same four-phase structure is used to drive the approval process.
Figure 23 Engineering Core Project Structure
When the project is finished a new project will most likely start to develop the next release of e.g. the
Policy Manager. This project will be created based on the existing "old release development" project.
The unfinished Work Packages can be copied into the new release project.
This decreases the amount of work in project planning and makes sure nothing will be forgotten from
the Backlog list and that all the feature team members are on board.
The phase structure of an Engineering project will be the same as in Services because of the stage

gates to ask the internal customer (Product Manager e.g.) for approval of the prioritization and the
planned effort of that project.
A Portfolio Bucket will be created for each Product and it will contain items for all the projects related
to that product i.e. all releases for that product. In the Financial view the costs per month and the year
and the grand total will be displayed. It is possible to calculate the profitability by adding the license
revenues.
3.5 Engineering Assist

Engineering Assist supports Sales Activities and will be tracked in an Overhead project for Sales. This
is the scenario where the sales department have requested the use of an engineering resource on a
project for which the sales department have responsibility.
There is a scenario where a part of the <Client> business e.g. Services will request that a piece of
work is carried out by Engineering Assist. In this case the Project is created under the Engineering
Portfolio Bucket. The project manager in this instance is an Engineering Business Unit member.
Engineering Assist projects are structured and managed in the same way as any other Engineering
Core project. There is one task for the Work Package. The SAP phases are included to enable the
approvals. There is unlikely to be a backlog in the Engineering Assist project but it is possible.
The below illustrates the Engineering Assist project.
Figure 24 Engineering Assist structure

In the similar way to the rest of the Engineering projects the resources are allocated to the Work
Package. Cost analysis is possible at the project level and Work Package Level but not the project
phase level.
3.6 CPSES
CPSES is the Service business unit to support customers using <Client>s products and having a
maintenance contract.
SAPs original intention of PPM is not to replace applications for Service management like SAP CS
(Customer Service). So PPM is not a ticket management system to track tickets, their effort and to
group tickets by category.
But it is reasonable to create projects per year and per maintenance contract and assign resources to
the projects. Via CATS the support resources can create their time bookings to the maintenance
contract.
This will allow the business to monitor the profitability for each maintenance contract.

The below structure illustrates the project for the CPSE. The people will be allocated to the one task in
the project to reduce the administration for the project.
Figure 25 CPSE Project Structure will be created for year calendar year
3.7 Overhead Projects
For a proper tracking of resource utilization all resources have to enter their actual hours to CATS
(Cross Application Timesheet).
All the resources will be assigned to the appropriate overhead projects in their business unit. So the
overhead project tasks will be part of their "default” task list in CATS to select for time confirmation
entries.
Overhead consists of Sales activity projects, Business development, Management support, Vacation,
Sick leave.
These overhead projects will be created for each business unit to be part of resource reporting.
If a resource is for a longer period of time not available, he or she may become the status "inactive"
and thus will not to be taken into account for planning and headcount measures.
It is anticipated that the overhead projects are not capacity managed as the resources are typically
quite constant on these projects. However, the Programme Managers who are 50% billable onto
projects can be blocked booked to Overhead Projects for the remainder 50% thus making them only
available for the 50%. This is the mechanism by which we can make Programme Managers available
for billable work.
Note: it is possible to change the block booking for the programme managers so that their time is 50%
for some months and 30% for others.
3.8 Project Templates

The above subsections explain the possible structure of the projects in the solution. In order to quickly
create these structures we will deploy templates that the user can copy.
This section outlines the templates that we envision at this point. These templates can be created by
Global Operations easily in the future.
The following Project Templates will be created. Further Templates can/will be defined during
Configuration Phase.
Initial Engineering Project Initial CPSES Project Templates Initial Other Project
Templates Templates
ENGINEERING_CORE CPSES_TIMEMATERIALS OTHER

ENGINEERING_ASSIST CPSS_FIXEDPRICE
Initial Services Project

Templates
SERVICES_SOLUTION
SERVICES_CAPACITY_EXPANSION
SERVICES_SUSTAINED_TEAM
SERVICES_SOLUTIONCAPACITY
SERVICES_CHANGE_REQUEST
SERVICES_SUPPORT_OPERATIONS
3.9 Check Lists

The PPM solution provides the functionality to create Check Lists populated with Check List Items.
The screen shot below illustrates how these can be constructed and associated with the project task
phase.
These Lists and List Items are easily edited and created by <Client> without configuration or
transports.
3.10 Questionnaires
The <Client> projects have quality reviews at the end of each <Client> Phase (SAP Phase Task).
These are Microsoft Excel based question and answers that form a checklist that the <Client>
programme manager must fill out in order to prove that the phase was successfully completed.
These quality checks do not stop the subsequent phases (phase task) from proceeding.

Within the SAP system solution these questionnaires will continue to be stored on MS Excel
spreadsheets and they will be hyperlinked to the project. The file will be held on the Sharepoint
document management system.
4. VALUE FLOW
4.1 Integration
The following Chapter outlines the system landscape, the integration between the systems and value
flow within the Landscape.
The diagram below depicts the value flow of revenues and costs in the solution. The table after the
diagram outlines the flows as illustrated in the below diagram.

Figure 26 Value flows between the systems in the solution
4.2 Landscape - Interfaces
1 System
Business One Business One is the leading system for all financial bookings to projects
SAP ECC SAP ECC will be the system for delivering actual Labour Costs from Time
Registration, Primary Costs and Revenues to PPM, booked to a Project
PPM PPM will be the leading System for Portfolio and Project Management
BW BW will be the Reporting Interface, using Data out of Business One, SAP ECC and
PPM
2 Value Flow
1 Financial Bookings to Projects in Business One will be transferred to Financials in
SAP ECC.
2 Financial Line Items will transferred to a CO-Line Item Table
3 Time Registration Data via CATS Interface will be stored in the CATS DATABASE
TABLE
4 Time Registration Data in the CATS DATABASE TABLE will be transferred to the
CO Line Item Table
5 Actual Data from Financial Bookings (COSTS and REVENUES) and Data from
Timer Registration (ACTUAL LABOUR COSTS) will be transferred to the Financial
Data Table in PPM
6 REVENUES and PRIMARY COSTS (expenses not Labour Costs) will be planned
on the Portfolio Item Level via a Financial View and stored in the PPM Financial
Data Table.

7 Planned Labour Costs on Project Task Level will be stored in the PPM Financial
Data Table.
8 Planned Data for Primary Costs and Revenues and Planned Labour Costs will be
visualized on the Financial View. Primary Costs and Revenues but no Planned
Labour Costs can be changed via the PPM Financial View
9 Actual Data for Primary Costs and Revenues and Labour Costs will be visualized
on the Financial View.
10 Data will be extracted out of PPM and used in BW for Reporting/Analyzing
11 Data will be extracted out of SAP ECC and used in BW for Reporting/Analyzing
12 Data will be extracted out of Business One and used in BW for Reporting/Analyzing
3 Object Links
A WBS Elements are the Accounting Objects for Primary and Secondary Costs,
reflecting Projects and Tasks from PPM
B WBS – Elements will be used as Accounting Objects during Time Registration in

the Background for storing in the CO Line Item table. The End User will see the
tasks, known from PPM during Time Registration
C The Business Partner, coming from HR – Personal Master Data will be known in
PPM and SAP ECC.
In PPM the Business Partner will be used as a resource that can be assigned to
specific tasks via Assignment to specific Roles.
The Business Partner will be known during Time Registration in SAP ECC – CATS
Time Registration.
D A Project in PPM will be assigned to a Portfolio Item.
E A Project in PPM will be assigned to a Project in SAP ECC- Project System(PS)
4.3 Profit Centre, Cost Centre and Project

Within SAP ECC every project will be assigned to an SAP Profit Centre. Thus, every CO line item will
be reflected as a statistical booking on the Profit Centre.
Within the Project header a responsible Cost Centre will be assigned. A combination of the PS master
data and the CO/profit centre line item bookings within BW will allow a Profit and Loss statement at
Profit Centre level for each Profit Centre.
The Profit Centre structure mirrors the Cost Centre hierarchy at node level.

5. RESOURCE PLANNING PROCESS
The above sections have shown how the system represents an <Client> project in SAP. The process
or steps that the people take in the lifecycle are also outlined. The following chapters will provide more
detailed information into the sub-processes that are tributaries of this main lifecycle process.
This section, ‘Resource Planning Process’ will outline the processes surrounding how the business
will search and resource a project. The section will outline how people are grouped into Resource
pools and managed by a Resource Manager. The loaning and the borrowing of resources are also
explained. The first subsection describes how the Role Type is used in resourcing.
5.1 Roles and Role Types as the Starting point for Resourcing
When resourcing a project the project manager or resource manager will consider cost level and skill
level. These attributes have been encapsulated into the Role Type field on the Role in a Project.
In a project there are roles to define the "skill type" and the typical costs for a first estimation of labour
costs in that project. Roles are based on Role types. Role types are part of the Configuration. A Role
type is connected with a rate at least for costing. In Time and Material projects also for the calculation
of revenues.
<Client> has a set of typical Role Types separated for each area because of massive differences in
the cost rate. Our recommendation is to have a 1:1 relationship between the role as part of a Project
Template and the connected Role Type. It is a goal for the Template Manager to ensure that only
Roles will be used in the Templates fitting to the Role Types. It is possible to add new roles in a
project after the template was copied. The roles to be used in a project should be under control of the
Template Manager at within Global Operations.
With a Role a basic expectation about the skill set is implied by the Role Type field. This could be
enhanced with Qualification Requirements added to the role. When it comes to staffing the role in a
project, the Qualification Requirements will be compared with the skill set of the resources to help find
the most suitable resources for the role in the project.
Figure 27 the PPM Role on a project can store the required qualifications for the role in
addition to the Role Type field value.
After reading this subsection the reader understands that the Role in a Project stores the Role Type
and the Qualifications required to perform the role. This information is used to staff the project and is

also used in reports to identify the kind of skill shortages and skill over-supplies that the business is
experiencing.
5.2 Resource search from within a Project

This section will show how the <Client> Programme Manager can search for a Resource.
With the Advanced Search there are four different search options for resources available to the
Programme Manager:
- General
- Organizational structure
- Qualifications
- Availability
Each of these tabs provides different search criteria.
Figure 28 The manager searches for resources filtering by duration start dates, area-location,
and previous experience with the Role Type and customer
The Resource Search screen tab entitled "General" provides Start and Finish date filter criteria. It also
has filter criteria for Area, Location, prior working experience for the same customer and on that role
type.

Resource search screen "Organizational Structure" delivers a filter for search on the Cost Centre of a
resource. Organizational Structure is in PPM not necessarily connected to the Cost Centre in the ERP
system but as part of our design the Organizational Units are the Cost Centres of <Client>.
Note: it will be possible to search within the Engineering staff by using the Cost Centre or
Organisation Unit field.
The qualifications catalogue will be set up in the HR Master record. The possible qualifications values
have been defined by the HR department. The project manager can search for Resources based on
the skills or qualifications.
It is also important to note that the Resource’s assigned Role Type that defines the blend will be
searchable from within this screen.

The availability in terms of duration dates and work hours capacity can be also searched for in the
screen above.
It is very important to note that the results of a filter can be filtered further using the post filter buttons:
Filter and Sort .
5.3 Resource and Staffing Views

There are two basic ways to manage and view the staffing:
Project-Related
Resource-Related
The next two subsections will outline these two ways of looking at resourcing and staffing.
5.3.1 Project-Related View of Staffing
Staffing of roles on project tasks is part of the project planning (PPM Project Management). A
resource assigned to a role will be assigned to a task. Therefore a start date, an end date and the
amount of hours required is specified.
All the existing entries of a resource on the project tasks with an amount of hours or days (workload)
will be part of the Resource dashboard in Resource Management.
In Resource Management there are two dashboards available:
1. One shows the results of the staffing process on project tasks (Staffing view). This is a project-
centric view of assignments.
2. The other shows the assignments for the resources. This is a resource-centric view of assignments.
Authorizations will control the organizational level of the resources displayed in resource view e.g.
based on a bucket and its resources. The other trigger is the assignment as a responsible resource
manager to a resource, a resource team or a resource pool. All of the above are required in our
solution.

All the projects accessible controlled by authorizations will be visible. Their demand is summed up on
top. Below the total demand the remaining demand (not staffed yet) is shown.
Each project will be split by its roles and their demand.
Indicators will show if the demand is fully (green), partially (yellow) or not staffed (red).
Figure 29 A project-centric view of assignments of people to tasks
5.3.2 Resource–Related View of Staffing
All the existing entries of a resource on the project tasks with an amount of hours or days (workload)
will be part of the Resource dashboard in Resource Management.
The Resource management will be mainly "distributed" at <Client>. That means the main
responsibility and workload in resourcing lays at the program manager to staff his or her projects and
to utilize the resources being part of his or her team.
It is also to be supported by PPM Resource Management that Global Operations will be able to see
the utilization of all resources and to work out staffing issues.
For this also required centralized approach it is necessary to deliver the utilization and the project
staffing as part of the PPM application and also in a report.

Figure 30 Resource-centric views of assignments
5.4 Resource Project with Resource from other Resource Pool

The Program Managers at <Client> act as Project Managers and as Resource Managers for his/her
pool of resources. When it comes to Staffing on a project the Program Manager assigns the resources
of his/her resource pool to his/her project with Hard-booking in one step. For resources under the
control of other <Client> Resource managers or as part of another Business unit the Staffing will be
done as Soft-booking. To make this work the role types will be marked as to be staffed from resource
managers with workflow in Configuration. The soft booking will be changed to a hard booking by the
resource manager of the resource who was soft booked.
The data structure used to store the <Client> Resource Manager will be defined in the PPM
Organisation Structure (not the ERP one). We will have two separate Organisation Structures one will
record the <Client> Line Manager of an individual and also a different Organisation Structure to store
the <Client> Resource Manager of an individual. The screen shot below illustrates this point.
Note: in SAP parlance the <Client> Resource Manager referred to above is not the same as the SAP
Resource Manager. The <Client> resource manager is the SAP Line Manager in PPM. This is a
technical note.

Figure 31 PPM Organisation Structure will enable the system determine who hard books a soft
booked resource
For resources under the control of other <Client> Resource managers or as part of another Business
unit the Staffing will be done as Soft-booking. To make this work the role types will be marked as to be
staffed from resource managers with workflow in Configuration.
When a Soft-booking is done a workflow will be created to inform the responsible <Client> resource
manager of the resource via mail to grant his approval to the booking (Hard-booking) or to reject the
staffing of the resource. The email can be deleted by the <Client> Resource Manager and still be
seen in a Workflow inbox or worklist by the <Client> Resource Manager. When the Resource
Manager actions this workflow they have the option to reject or approve the booking. Upon accepting
the booking the soft booking indicator is removed and the booking becomes a hard booked
assignment.
Soft-booking could be also useful when the final contract is not signed yet and resource staffing
considerations are to be made. It is possible to set up this indicator in the details screen even when
from Authorizations perspective Hard-booking is allowed.
The Soft-booking indicator will be removed from the Resource Manager in the Resource Management
Work Centre in one of the two views described in the following chapters or to be done via a work item
in his work item list.
For the usage of both types in Staffing (Soft- and Hard-booking) it is useful to define Business rules
when Soft-booking has to be preferred even when from authorizations Hard-booking is allowed.
When a project manager wishes to use a resource that is not part of their assignees in their resource
pool then the following process will be undertaken.
1. The Project Manager creates a PPM Project and associates a Task and a Role with this
Project.
2. The Project Manager searches for a suitable resource within the Project Plan view. She finds
a suitable resource but the resource is outside her group. The resource is available at the
time the Project Manager needs the resource.
3. She assigns this person as a Soft booking. This is shown in the below screen shot as a tick in
the column entitled ‘Soft-Bktd’.

4. There is a PPM workflow that sends an email to the resource pool manager that the Resource
belongs to. It is also envisioned that the Global Operations Resource managers and Business
Unit Managers will be Managers of their subordinate resource pools thus they will also
receive workflows of impending cross-pool resourcing. The notifications will appear in the
dashboard of the respective Business Unit Manager and Global Operations Resource
Managers. The process would be to make a phone call to follow up on a soft-booking request.
5. The resource manager has the ability to confirm this booking and turn this soft booking into a
hard booking by clicking on the Approve button on the workflow item.
6. In the event that the resource manager of the resource is not happy to give this resource to
the Project manager the soft booking can be rejected. The project manager receives this
rejection notice. This resource issue is escalated (off-system) to a superior manager to
resolve at this point. This resolution is addressed outside of the system.
Note: the soft booking flag is visible in reports to enable the user to see whether bookings are hard or
soft. SAP uses the field ‘Booking Type’ to distinguish Soft from Hard bookings.
The differences between hard and soft booking are listed in the below table.
Soft 1. The icon beside the resource
in the Resource tab of the project
is different.
2. The soft booked field in the
staffing tab of the Details is set to
True.
3. Reports will show the hours as
Booking Type 1. So, reports can
be generated to display soft
bookings. The readers of these
reports can choose to include
these in resource requirements or

not.
4. Soft bookings are not considered
as fulfilled resource requirements
at the PPM View of capacity
requirements.
Hard 1. The icon is instead of the soft
booking item above.
2. The soft booked field in the
staffing tab of the Details is set to
FALSE.
3. Reports will show the hours as
Booking TYPE 2. So, reports can
be generated to display HARD
bookings. The readers of these
reports can choose to include
these in resource requirements or
not.
4. HARD bookings are considered as
fulfilled resource requirements at
the PPM View of capacity
requirements.
5.5 Loan a Resource

The loan a resource process is used when a person is transferred from one resource pool to another
but more importantly it is a loan that goes across different Business Units. The loan is usually for c.
three months. The person who is loaned is still retained legally in the original cost centre. Salary and
other such legal processes are driven with respect to the original costs centre.
The loan process will be managed using the Area and Location fields on the Resource (Business
Partner) screen. The Area will indicate the ‘Loaned to’ Business Unit. The possible values for the Area
and Location combination will map directly to the Cost Centres that represent the Business Units in
the <Client> design.
The Area Location fields are time-sliced thus the start and end date for a temporary loan can be
specified. The SAP reports and filtering mechanisms will consider the time-slice to correctly
understand the current pool that the resource belongs to.
In a Loan scenario the Cost Centre will not change as the HR employee remains legally a part of the
original loaning Business Unit. The cost centre of the HR master is also time-sliced. So, in effect at
any point in time the system knows the cost centre and the Area and Location of a resource.
The process for loaning a resource is as follows.

1. The process is a demand driven process: a loan will only take place if there is a role for the
person undergoing the loan. So, there is a project that has a role for which there is a scarcity
in the associated Business Unit. There is an available resource in a different Business Unit.
2. In a similar manner to the soft booking process above the resource is soft booked and the
resource manager considers the booking.
3. In the case of the loan scenario in order to easily signal to the Global Operations team a field
will be flagged to denote in the Role that the particular staffing is a “loan resource”. We intend
to use a standard field “Location” for this.

4. It is possible to add notes no the staffing tab to explain the details of the loan.
5. The resource manager may off-system consult with their Business Unit Manager to gain
approval for the loan. Sometimes the Business Unit manager might veto this move.
6. Once the resource manager is happy to proceed with the cross-business unit loan the
resource can be hard booked.
7. Periodically the Global Operations team will run a report to ensure that all Loaned resources
are correctly setup in the system. The report will use the Area field to determine this. The
report is illustrated below.
Resource Task HR Cost Human Resource Date Start Date Finish Name Run Date
Staff Centre Resources Pool Entered in
Area Area Description Selection

Screen
23481 EMEA 100023 NAR Eric Veere 01-Oct- 01-Oct- Enri-K 03-Oct-
Direct 2012 2013 Salazar 2012
Reports
12348 EMEA 100023 CALA Eric Veere 01-Oct- 01-Oct- Nora 03-Oct-
Direct 2012 2014 Buckley 2012
Reports
8. The resource is moved from the loaning resource pool to the new receiving resource pool.
This is performed by Global Operations. The person now is on the resource radar of the
receiving resource pool manager. The new resource pool manager has responsibility for the
utilisation or billability of the Loaned resource.
9. The Location and Area is altered on the Resource so that the loan Business Unit is shown for
the period of time the loan is agreed.
10. There will be a BW report that uses this time sliced data to determine the head count in the
Business Unit and include and exclude loan resources as necessary. For the duration of the
loan period.
The report might look similar to the below.
Location Area Resource Count Loaned In Loaned Out

EMEA EMEA 120 2 4
APAC APAC 200 1 30

Note this report can also include details of the individuals and who they are loaned to as it is a BW
report.
11. At the end of the loan period the resource is moved back to the original resource pool. His
time-sliced Location information is also checked to ensure that the accurate location data is
reflecting the correct business unit.
12. The report below (which is illustrated above also) will also be used to signal that the loan
return is scheduled to automatically occur. The resource pool will need to be updated on this
basis. This report will be automatically run each day to proactively inform Global Operations
of the loan return pending event. It will be a manual off system process to confirm that the
system is correct and the loan will be returned as planned.
Resource Task HR Human Resource Date Start Date Finish Name Run Date
Staff Cost Resources Pool Entered in
Area Centre Area Description Selection
Screen
23481 EMEA 100023 NAR Eric Veere 01-Oct- 01-Oct- Enri-K 03-Oct-
Direct 2012 2013 Salazar 2012
Reports
12348 EMEA 100023 CALA Eric Veere 01-Oct- 01-Oct- Nora 03-Oct-
Direct 2012 2014 Buckley 2012
Reports
Note: The project in which the loaned resource works will receive the costs of the resource for work
carried out. The costs of the holidays are costed against the Project that sits in the loaning business
unit. The resource will book his costs to these projects during the loaning period.
5.6 Resource vacancy and Dummy resources as indicators for Recruitment

Normally resources will come via interface from HR as Business partners.
For urgent demand in projects with a shortage of this particular skill set it will be useful to create
Dummy Business partners/resources to level and indicate the demand for recruitment and the
potential utilization of a resource with that skill set.
5.7 Longer absence from work

Resources absent for a longer period in time may be set to inactive not to be taken into account for
head counting and resource levelling.
5.8 Emergency Resource Project

There is a scenario in <Client> where a resource is required to work on a project immediately in an
unplanned fashion.
It is possible in this scenario that the person will not be a planned resource and the PPM project has
not been updated to enable this person to book their time in CATS.
Every effort will be made to update the project with the resource or person. The timesheet will be
entered as soon as the assignment has been made by the project manager.

5.9 Inactive Resources
A resource will not set to inactive by the system if a resource has not been used for a specific period
of time. The inactive Status will/can be set by HR.
6. TIMESHEET CONFIRMATION PROCESS
6.1 Time Registration and Approval

The timesheet confirmation will be done via CATS (Cross Application Timesheet). CATS will be part of
the ESS (Employee Self service) at <Client>. Additionally CATS will be represented as a WEB
transaction rendered in Internet Explorer or Firefox.
Figure 32 Internet-based timesheet in SAP
A CATS user will get all the Tasks (s)he is assigned to in the data entry screen. CATS will collect these
tasks using a background program from the PPM database. Therefore it is necessary to have
employees and contractors as resources in our system assigned to tasks in projects.

The screen above shows the possible Worklist on a CATS Data Entry View where the CATS user will
get a list of all his/her projects by Project ID, Project description, Project Subobject (Task).
This screen is taken from the CAT2 transaction as part of the ERP system. The CATS screen in the
ESS or in a browser window will look similar.
The user gets this screen with his/her worklist based on the existing assignments for the period
(week) to be reported.
The structure of the worklist will contain at least an identifier for the project and for the task
(subobject). Possible are Project number, Project description, Task number and Task description.
The user selects a row by highlighting in the worklist and copies it in the Data Entry Area below the
Worklist.
As long as the Program Manager does not close the task, a resource can enter extra hours than
planned to the task. During Aproval Process it can be decided to accept or to reject this bookings.
After creating actual hours for each day in the week displayed on the screen the CATS user takes the
next entry from the work list to edit the actual hours.
It is possible to setup CATS differently for other Business areas for smaller portions of work e.g. in
Service (CPSES). It could setup for daily confirmations.
Service people could use CATS with a different setup. Time confirmation on Maintenance contract
projects could be done according to a list of projects (= customers) and tasks (= reasons for "tickets).
That would work without pre-populating the Worklist in CATS via a huge amount of assignments on
tasks in maintenance contract projects.
After all the confirmations for a week are done the CATS user releases the hours for the next step.
The next step will be the approval or rejection of time either by the line manager determined by the
organizational structure or by the program manager in the role of the project manager.

The standard system CATS allows one approver per confirmation done in the system in the standard
workflow. Project Managers will receive one workflow notification for all of the outstanding approvals
required; this is to ensure that the inbox is not overloaded. For resources working on two projects, two
separate approvals will be sought by the system from the two different project managers.
The illustration below outlines a screen that is similar to the screen that the Project Manager will see
while approving timesheets. Note the ESS version of this screen might be slightly different.
Figure 33 Timesheet approval screen
If the user does not want to look at the emails they can instead simply log into the system and view
the screen above.
Vacation, public holiday and sick leave are not overtime hours. vacation time is pre-approved in hr
and not post-approved. Public holiday is neither pre nor post approved. this is to cut down on
unneccesary approvals.
Sick leave is neither pre nor post approved. The sick leave is managed at three levels in the HR
module: certified, uncertified and unpaid.
We will use another activity type for overtime. CATS time registration overtime records will use this
activity type. this overtime can be selected and reported upon. The overtime hours will be used in HR
for paying overtime in KL using a report.
The confirmations of work are in the CATS database. After approval they will be delivered by another
background program to the tasks and project they belong to.
The hours will be visible as actual work and as actual costs in the PPM Project Management project.
The costs will be transferred via the account integration to the appropriate WBS element in SAP
Project system.

Figure 34 The Project in PPM can show the hours and the actual costs on the Accounting View
Actual costs for labour based on the confirmed hours will be also visible as the result of the rollup to
the Portfolio item representing the Financials of that project.
This subsection has outlined the standard way that the SAP timesheet will work based on the specific
assignments of the timesheet submitters to the PPM Project. There is a drawback to this standard
functionality in that it forces a project assignment to be in place before the person can enter a
timesheet. To overcome this restriction we will create a bespoke development. This bespoke
development is explained in the next subsection.
6.2 Timesheet Development

The SAP timesheet tool called CATS tool will allow the employees and contractors to fill in timesheets
on a web-based application within the Employee Self Service (ESS) portal.
<Client> Requirements
1. The tool should allow a user to book a timesheet to a project phase-task so that costs of a
project phase-task can be captured.
2. The standard system only allows a user to book a timesheet to a particular project task, if he
is assigned to the task of a project.
3. There are accounts in <Client> like AT&T where there are large groups of people involved on
a large number of projects & tasks at the same time. The timesheet screen will have an easy-
to-use search mechanism for a user to find the correct project/task. This will be a bespoke
development.
4. The solution should support timesheet recording even if the resource is not assigned to a
project. To control this sort of timesheet processing a new grouping mechanism will be built.
This design will be based on the Journyx data structure where users are grouped, projects
are grouped and the link between the two groups is maintained. This defines a set of projects

for a person that is defined outside of the standard PPM Project. The subsequent paragraphs
in this section will explain more about this new bespoke functionality.
Proposed Solution Design

The CATS time recording application will pre-populate the work-list for an employee based on his/her
standard assignment to various projects/tasks. The work-list will provide easy filter options for the
employee to find a project using various criteria.
The following screen displays possible Project & tasks combination in a CATS worklist. The user will
click on the filter button which will trigger a new screen for selection.
The user will enter the filter criteria and press “Filter” button to drill down to a particular Project Task
entry.
For instances where employees do not have projects assigned to them in the PPM Project like Shared
Services, a new “Group Worklist” button will be introduced on the CATS screen which will populate
the work-list based on User Group & Project Group assignment strategy similar to current timesheet
solution Journyx. This strategy will have to be maintained separately by Global Operations.
When the user presses this “Group Work-list” button, a new window will appear for the user to find
and select the relevant worklist item or Project Task.

With the above approach the system would fetch only those items which satisfy the given criteria and
thus give good performance.
Access would be given to authorized users who will maintain User Groups & Sub Groups
assignments in a separate screen.
The link between Users, Project, Tasks and linking groups can be viewed in the illustration below. This
data structure is very similar to the Journyx functionality. The users are grouped into user groups. The
projects are grouped into project groups. The two types of groups are linked to together so that in
effect there is a one-to-many link between the user and the projects. This will provide the ‘Group
Worklist’ functionality an alternative set of project tasks to display to the CATS timesheet user. This
functionality will meet the need to link people to projects indirectly that is quicker to maintain than the
standard PPM staffing functionality.
Figure 35 Data structure used to link people directly to projects without using the standard
staffing functionality
Note: the JIRA workflow system will be used to formalise the creation, edit and delete of Timesheet
Groups. The Global Operations team will control and manage these lists and edits to this list will only
take place on the basis of a JIRA workflow from the Programme Manager.
It is a requirement that two exception reports will be run to manage the timesheet process:
a. The exception report that highlights timesheets not submitted;
b. The exception report that highlights timesheet not approved.
A reminder email will be sent when timesheets have not been approved within 2 weeks of submission.
An reminder email will be sent when timesheets have not been sent within 3 working days of the end
of the particular working week.

Engineering Assist projects can be set up as projects under the Engineering portfolio.
It will be possible for non-support people to book time against support codes.
7. BUSINESS PLANNING
7.1 Currencies and Exchange Rates
The following currencies will be used. This list can be extended in the future if <Client> enter into
markets in different currency regions. Typically these additional currencies are added by the AMS
service provider.
Currency ID Currency Name

EUR EURO (Default)
USD American Dollar
BRL Brazilian Real
MYR Malaysia Ringgit
GBP UK GBP
ZAR South Africa Rand
AUD Australia Dollar
CAN Canadian Dollar
JPY Japanese Yen
SGD Singapore Dollars
7.1.1 Currencies in the Financials

In the BusinessOne system <Client> posts in different currencies. Using the bespoke FI Interface to
SAP ECC, the SAP ECC will also be able to book in different currencies. Our solution will book the
posting in ECC in the same currency as the original currency in Business One.
The currencies, which will be allowed in the SAP ECC system and the Exchange Rates will be defined
in Customizing. The Exchange Rates will be kept up-to-date with a standard upload transaction to
update the rates.
7.1.1.1 Company Code Currencies

In Financial Accounting, a company code currency will be defined for each company code (See
Blueprint FI/CO/PS)
We will define parallel currencies for each company code. These settings also affect Controlling. (see
Chapter Controlling)
The SAP ECC system requires these definitions to check whether an entered currency is allowed and
to translate the currencies during posting.
7.1.1.2 Currency Code Table

A currency table within the SAP ECC System will have entries for all currencies which occur in
<Client>s business transactions.

7.1.1.3 Posting Documents in Foreign Currency in FI
When a document is posted in SAP ECC in a foreign currency, the SAP ECC system stores the
amount in both local currency and foreign currency in each line item. The system checks whether the
currency key has been defined in the currency code table and is therefore permitted.
Therefore the following specifications will be made in SAP ECC system:
• Currency key for each currency
• Number of decimal places
• Local currency per company code
• Exchange rate between local and foreign currency
7.1.1.4 BusinessOne – SAP ECC Financials Interface Requirements – Currency Key,

Exchange Rate
SAP ECC will not use a different posting date and the currency key in the document header to
automatically convert the currencies during ECC posting. We will force the ECC system to post the
same values in ECC on the same posting date like it is done in BusinessOne. This makes sure, that
no different Exchange Rate will be used, if the Exchange Rate Table in SAP ECC does not contain the
same Rates as in Business One.
Using the Interface the amount will be entered in each line item in both local and foreign currency, so
that no Currency conversion will be done. The amounts and the currencies will be the same as
delivered from business one per line Item.
7.1.1.5 Use of different Exchange Rates and Exchange Rate Types

The previous section was focused on the BusinessOne interface. This section will take care of the
requirements regarding to the CO postings triggered by planning activities and actuals coming
time registration.
Exchange rate types will enable the system to record different exchange rates valid on the same date
for different purposes.

In Standard the SAP ECC system uses exchange rate type M (= average exchange rate) for postings.
After establishing a basic currency for the exchange rate type, <Client> only needs to specify the
translation ratios in relation to the basic currency
The exchange rates have to be maintained at regular intervals according to <Client> internal
exchange policy requirements. We envision that this will occur on a monthly basis.

7.1.2 Use of Currency and Exchange Rates in Controlling
The types of currencies in the following subsections will be valid in Controlling.
7.1.2.1 Controlling area currency

The system uses this currency for cost accounting.
This currency will be defined in the controlling area 1000 (<CLIENT>) as EUR.
7.1.2.2 Object currency

A WBS - element may use a separate currency specified in its master data. When PPM creates a
WBS Element in CO, the SAP system defaults the currency of the company code to which the WBS
element is assigned as the object currency. The system allows the user to specify a different currency
for a WBS-element only if the controlling area currency is the same as the company code currency. It
will be checked during the Realisation if this restriction can be overcome. There will be an object
currency for the sender (Cost Centre) as well as one for the receiver.
7.1.2.3 Transaction currency

Documents in Controlling are posted in the transaction currency. The transaction currency can differ
from the controlling area currency and the object currency. The system automatically converts the
values to the controlling area currency at the exchange rate specified.
7.1.2.4 Exchange Rate Type M and currency storage in CO line Item Table
The system will always translate actual data with the average rate (exchange rate type M).
All three currencies are saved in the totals records and the line items level. This enables <Client> to
use the different currencies in the information system.
This is possible because it will be specified that all currencies will be updated for the controlling area
1000 (<Client>)
Example:
The transaction currency is USD, the controlling area currency is EUR, and the object currency is
SFR (Swiss francs). The system converts the amounts as follows:
1.) From transaction currency to controlling area currency (USD  EUR)
2.) From controlling area currency to object currency (EUR  SFR)
7.1.2.5 Additional currencies

The following additional currencies will also appear as controlling area currencies in Controlling
because cross-company code cost controlling will be usable.
7.1.2.5.1 Local Currency

Company code currency (country currency) used for local ledgers in external accounting.
7.1.2.5.2 Group Currency

Group Currency will be specified as a parallel currency (additional local currency) for a company
code.
7.1.2.5.3 Hard Currency

The Hard Currency will be specified as a secondary currency for countries with high inflation if
needed. It will be specified as a parallel currency (additional local currency) for a company code.
7.1.2.5.4 Global Company Currency

Currency used in a corporate group. In the CO application component companies can be created to
represent divisions, regions, or product groups. This will not be configured for <Client>.
7.1.3 Currencies in PPM

The following section will outline the currency and exchange rates used within the PPM module.

7.1.3.1 Portfolio Item Currency
A particular currency will be defined at the portfolio Item Level.

The screen shot below illustrates this in the Portfolio item.
Figure 36 Portfolio Item Currency
7.1.3.2 Currencies on Bucket Level
A different currency can be used in the financial view at the portfolio Bucket Level. This allows the
EMEA region to perform projects based in a non-EUR currency, for example in South African Rands
or US Dollar. The portfolio bucket will be in EUR and the Item will be in SAR (South African Rands).
Costs and Revenues can be visualized in different currencies on Bucket Level.
Figure 2 Bucket Currency

7.1.3.3 Currencies on the Financial View
Planned Costs and Revenues on the financial view of the portfolio item can be shown in different
currencies.
Figure 3 Portfolio Item Financial View in different currency
Within the PPM project there are a number of objects that can be denominated in different currencies.
The following objects can be defined in different currencies:
1. Rate on the Role Type
2. Planned Rate on the Resource
3. Actual Rate on the Resource
The following paragraphs will outline these objects and explain how the exchange rate will be treated.
7.1.3.4 Currency on the Role Type

The Role Type Rate will be the blended labour rate for planning purposes. The Rate currency on a
Role Type will be the same currency as used for the Company Code to which the Role Type belongs.
7.1.3.5 Currency of the Planned Rate on the Resource

The currency of the planned rate of the specific resource can differ from the currency of the actual
rate used for actual costs.
In our design the planned rate of the resource will be denominated in the currency of the legal entity
(Company Code) to which that person belongs.

7.1.3.6 Currency for the Actual Rate on the Resource
Our design will denominate the Actual Rate of the resource in the same currency of the Salary of the
individual as defined in SAP HR.
During time registration the system will convert the salary based rate to the currency of the project.
In fact the underlying CO table will contain the values of the CO line items in all currencies as
explained in the section above in section 3.2.
This enables the user to see the BW and PPM reports in different currencies as are defined on the
CO document.
7.1.3.7 Special Requirements
One requirement collected in our workshops is the fixed rate for a project from registration to closure.
This is not possible as part of the PPM transaction system. PPM reflects exchange rates maintained
in SAP Transaction OB08 in all its scenarios.
So, for example, a Portfolio item could be denominated in USD whilst the bucket where the item is
located is in EUR. For the rollup on Bucket level the exchange rate will be taken into account. This is
necessary to reflect properly the floating of exchange rates for P&L and Cash flow considerations.
Each Bucket may have its own currency and also each Portfolio item. The currency defined in Bucket
creation will be the one used over the life of a Bucket.
To meet this requirement the financial view of the Portfolio item could be downloaded to EXCEL and
the exchange rate from the Project initiation could be used to calculate a P&L without any effects of
the floating in the currency exchange rates for a proper bonus calculation.
7.2 Cash Flow
Cash flow is to be monitored on Project level in two ways:

ITD – Initiation to Date
YTD – Year to Date
ITD is the period of time over the lifecycle from a registered project until today (ITD). This will be done
based on the Financial view on Portfolio item level. There are all the cost elements and revenue
elements time sliced by month.
The other cash flow figure is from the beginning of the year until today (YTD). This could be done also
as part of the Financial view on Item level as the summarization of all actual cost and revenue
elements as the total figure of the year.
With the rollup from the lowest bucket level to the Top level (<Client>) it is possible to see the
expected development of Cash flow by projects as the summarization of cost and revenue elements
in all areas of the business in a timely manner.
The financial View will look similar to the following example. (Note: The System is currently not
configured. The following screenshot is just an example)

7.3 Invoice Process
7.3.1 Invoice Process – Milestones

The invoice process described in this section outlines how <Client> will manage the generation of
invoices for service projects.
The design of the Invoicing Process as described as follows is the most practical one in the technical
environment and supports the administrative Invoice Processing.
The following section focuses on the invoicing process for Fixed Price contracts. The sections
subsequent to this section outline the Time & Materials and Expenses invoices.
The scenario outlined is a Fixed Price contract with 2 milestones. This project is illustrated by the
screen shot below. The reader can see two milestones in the project schedule prefixed by the word
“invoice:”.

1. The projects portfolio item is setup in PPM with revenue figures, planned (forecasted) in the
financial view on Portfolio Item Level. For each of the milestones there is a forecasted
revenue total in the column for the relevant month.
2. In those months that the project manager forecasts the revenue, invoices will be issued for
the milestones.

3. The project is setup in PPM with Milestones in the project plan to represent the Milestone
Dates on which the Project Manager will seek approval from the <Client> Customer that the
invoice can be issued. The text that is to appear on the invoice will be typed into the
Milestone. There is no hard link between the numerical value in the Revenue number and the
Milestone node in the plan. There will be a reconciliation report to reconcile the milestones to
the revenue amount on the financial view.
4. In the event that the milestone moves due to a re-plan, the Project Manager will update and
adjust the month, in which the revenue figure is positioned AND also the milestone date.
At any point in time the Finance team will be able to run a report (pull Report), on the BW
Database, to list the invoice-able milestones, the planned Revenues and actual Revenues for
all projects and milestones due for a particular period (e.g. current running month). The report
can be run at any time by the Project Manager, Programme Manager or the financial team
also.
The report will be published to one finance team member automatically. The Username to
which the report is sent is adjustable without configuration. The period over which the auto
report gathers data is adjustable by the system administrator. The frequency at which the
report is sent is adjustable by the system administrator. All of these adjustments can be made
by a system administrator without the need for programming or a configuration transport.
If Planned Revenues for a specific milestone are invoiced, the milestone will reflect this by a
special Status (Invoiced).
Project PLANNE Project Milestone Milestone Text Date Milestone Actual

D Manage Status Revenue
Revenue r
[EUR]
TUC01123 100,000 Enri-K 102323 30% down 13-Jun-2012
Salazar payment for
system design
TUC00012 50,000 Joe 234812 10% Hardware 28-Jun-2012 Complete
Smith installation
TUC01111 234,000 Peter 234785 Final payment 24-Jun-2012
O’Toole for telco
analytics
system
123412 Initial payment 12-Jun-2012
for telco
analytics
system
TUC0123 10,000 John 234944 Final Payment 12-Jun-2012 Complete 10,000

Doe for System
Partridge
5. The report will prompt the accounting department to seek the status of the invoice-able
milestones from the relevant Project Manager. This can be performed by email to seek
clarification.
6. The Project Manager who has an invoice payment forecasted to be in the current month but is
currently showing as not Complete (or not yet invoiced), can seek confirmation from the
customer that the invoice can be transferred.
7. When the customer agrees that the invoice can be sent, the status of the milestone will be
changed to a specific status that informs that the invoice can be created.
8. The Invoice Creator creates the invoice in the SAP BusinessOne system.
9. The BusinessOne to SAP ERP interface runs and transfers / posts the financial revenue line
items in SAP ECC Financials and the SAP PS-WBS element will be used as accounting
object (receiver for the revenue) associated with the project in PPM.
10. The receipt of the actual revenue amount into the PPM system will be visualized in the
Portfolio Item Financial View and is the signal that the actual invoice has been successfully
issued to the customer. The Project Manager can read this data to understand this.
11. The invoice is mailed to the customer. If this is created, interfaced but not sent the revenue
will still appear in the PPM actuals. Technically the process will be driven by status
management.
Note: the customer and the Sold To fields on the PPM Project will store the customer for each of the
projects.
7.3.1.1 Customer Payment Terms

The Customer Payment Terms will be stored as Information on The Business Partner, which
represents the Customer.

The Information will be taken from Business One. Customer Master Data and updated.on a regular
basis.
This Master Data will also be available in BW, so that this Information can be shown in several
Reports, if needed.
7.3.1.2 Number of Milestones per month
The design allows to have more than one Invoice Milestones within a month.
Each Milestone represents one Invoice.
7.3.1.3 Milestone Status

Each Invoice Milestone can have a specific Status.
Statuses will be “Open” (No clearance to invoice”) “Invoiceable” (Signal by the PM to Finance that the
invoice is ready to go, and Invoiced (Where finance record the invoice number against the milestone).
7.3.1.4 Milestone Number in Business One

There will be a field in Business One Invoice, wich represents the Milestone in PPM (Text, 20 CHAR).
This Text can also be printed on the Invoice, generated in Business One.
7.3.1.5 Filtering of invoiceable Milestones

There will be a report, which filters all invoiceable Milestones. Therefore the Status will be the
selection criteria.
The Manager can change the Status, the Revenue Amount or the date for billing for each Milestone.
7.3.1.6 Document Link

Detailed Information e.g. Invoice Line Item specific texts will be stored in a document, which is linked
to the milestone via a hyperlink.
It will also be possible to link this Documents to the Portfolio Item.

7.3.1.7 Reports
There will be 2 Exception Reports to support the Invoicing Process. The first report will contain actual
Data with the following fields:
 Project Number,
 Milestone Number,
 Company Code,
 Invoice Number,
 Invoice Type,
 Total Amount,
 Currency,
 Invoice Date.
The second report will contain Planned Data with the following fields:
 Project Number,
 Milestone Number,
 Invoice Type,
 Planned Revenue,
 Planned Invoicing Date,
 Planned Amount on Portfolio Item.

Invoice Process – Time and Materials
The Time & Materials (T&M) process follows the same process as the Fixed Price Milestone above.
In this scenario there will be a milestone for each and every month contained in the project. This way
the same report above will prompt the accounting department to consider T&M projects for invoice
creation.
As in the scenario above the planned revenue figures will represent the best estimate of the future
revenues at this point.
The Sell Price for each resource will be specified on a spreadsheet that can be hyperlinked to the
project.
The project manager will manually calculate the invoice total based on the actual hours logged in
PPM and the sell rates in the spreadsheet above.
The project manager will set the final value before the Status of the Milestone is moved to “invoicable”

7.3.2 Invoice Process – Expenses
There are some projects in <Client> that invoice expenses at cost to the customer. These differ from
the Fixed Price and T&M invoice processes.
The Expenses Invoice process is similar to the above processes however, different reports are used.
1. The PPM Project contains a Milestone for each month in which the project manager predicts
an invoice expense will occur. The expected revenue from expenses is included in the
forecasted revenue. The bespoke code to calculate the <Client> Revenue and WIP will
include this. It is important to note that in a month where there is an expense and a labour-
based invoice due, the PPM project will contain two Milestones one for the expense invoice
and one for the expenses.
2. There will be a report run which lists for the project manager the actual expenses items that
have been posted in BusinessOne. This report is illustrated below.
Project Type CO Doc Number FI Doc Number Comment Total
FI Document
TUC001 Expense 237481239401234 123483294819 Bruno Suares - -300
Hotel
Expense 237481239401234 123483294819 Bruno Suares - -200
Meals
Revenue 34123049 2193049 Bruno Suares - 300
Hotel
TUC003 Expense 237481239401234 123483294819 Peter Pan -100
Conference
TUC004 Expense 237481239401234 123483294819 Peter Pan Flight -500
Cost
1. The project manager can use this report to determine which expenses should be invoiced.
2. It is recognised that in some cases not all expenses will be invoiced.
3. The above report will be sufficient for the Project Manager to provide the information to the
accounting department to enable them to issue an invoice.
4. Within the underlying SAP ECC System technically the booked Expenses (inserted as
primary bookings in FI or from CATS Time Registration) are stored as Actual costs in CO –
Line Items, identified by specific cost elements. The difference to the process to handle
Revenues as agreed fixed price is that a specific financial category, for Actuals will be used,
different from the financial category of the agreed planned fixed invoice amount. So in
summary, a different report is needed for expenses than the T&M/Fixed report because the
underlying data representing invoice-able expenses is different to the data representing
planned revenue. One is actual costs: the other planned costs (expense-type).
5. The milestone on the PPM Project is also used in this case to definitively specify that an
invoice should be sent.
7.3.3 Non Billable Portfolio Item Types
The following Item Types will not have any Revenues and thus will not be billable.

Non-Billable Services Non-Billable Engineering Non-Billable CPSES
Portfolio Item Types Portfolio Item Types Portfolio Item Types
Overhead (Absence, Pre- Overhead Overhead

Sales)
Core Activities Core Products Core Activities
Engineering Core
Engineering Assist
Core Activities
Financial Views are assigned to Portfolio Item Types. Non Billable Portfolio Item Types will have no
assignment of Revenue Categories.

7.4 Health Indicators
There is some functionality available to provide budget, schedule and staffing status for Portfolio
Items in the Portfolio Buckets that the Business Unit managers will view. The below screen illustrates
this functionality.
The indicators and the columns are defined in the table below.
Indicator Description
Budget The budget status is based on the ratio of total actual cost to total planned
cost. This data is transferred to SAP Portfolio and Project Management
through the SAP FI/CO interfacing process and is displayed on the Project
Details screen.
The total actual cost is the sum of all actual costs posted in SAP FI/CO on
the portfolio item cost collectors over the complete posting period of the
associated PS project element.
If costs are within 90% to 100% of planned the indicator is GREEN.
If costs are within 80% to 90% of planned the indicator is YELLOW.
If costs are less 80% of planned the indicator is RED.
Schedule The schedule status is based on the ratio of completed tasks to date to all
tasks to be completed to date. Each task is weighted by the number of
planned hours it takes to complete and the percentage completion of the
task.
If costs are within 90% to 100% of planned the indicator is GREEN.
If costs are within 80% to 90% of planned the indicator is YELLOW.
If costs are less 80% of planned the indicator is RED.
Staffing The staffing status is determined by calculating the difference between total
demand (for all roles) and total assignment (assignments for all roles) for
this item with a given assignment unit within the following 12 months.
The formula is as follows:
Assignment = 0 status: red
0 < Assignment < Demand status: yellow
Assignment = Demand status: green
Assignment > Demand status: yellow

8. CHANGE REQUESTS AND REFORECAST
8.1 Reforecast Costs and Revenues

The following section will outline the process undertaken each week to update the forecasted
revenues and costs for each services project.
1 On a regular basis the project manager of the project will update the projects revenue forecast
figures for each month. This is important so that the business or portfolio understands the
expected invoiced revenue. Note: the updates to the Portfolio Item financial views will be
reflected in BW after the BW extraction has taken place. The extractions will take place each
night.
Figure 37 The forecasted non-labour and revenues are updated on the financial view
2 The project manager will review the capacity requirements for each of the resources. The
resources that are assigned to tasks can book time to these tasks. The hours related to these
assignments will block the resources from getting seen as available to other Project Managers.
3 If there are new Resources, Tasks, Role/Role Types required on the Project, these are updated
at this point by the Project Manager.
4 The milestones that represent the bill payments are moved if required.
5 After the project is saved any alterations to the Business Partner blended rate will be reflected in
the project.
6 After these updates have been saved, the data for the Global Operations Department is
available, to consider who is available, over booked or rolling off a project soon.
7 The BW updates can be triggered by a planned technical job or started manual on demand. In
the event that a BW report is required immediately a request can be made to the system
administrator to start the extraction to BW.
8 After the project has been saved the data related to forecasted invoices in available to the
accounting department.
9 The project manager can take a version snap shot each week so that the progressive elaboration
of the project can be stored and analysed.
The important point about the process in this section is that the project manager does not need
approval to make these changes. The next subsection will outline how the change to the project is
carried out where an approval is required.
8.2 Large Change Request

The following process is used in the case where a customer requests that <Client> perform an
additional piece of scope. There is a change to overall contract value.

Every time a large Change Request comes in this type of Change Request will trigger the creation of
a new Project, which will follow the same lifecycle as every other project.
For a large Change Request the change request will receive a new Project Code for timesheet
purposes and also for accounting and tracking purposes. It is also important to note that the approval
for the large Change Request undergoes the same approval protocol as the normal lifecycle approval
described in section 1.
The original project and the associated change request will be united together for reporting purposes
using the SAP PPM Programme field and object. This programme data structure will allow reports to
be built that calculate revenue and margin and costs at programme level i.e. the combination of the
original contract and change request.
8.3 Small Change Request

Small change requests will be managed in a similar way to the re-forecast process where the project
manager simply increases the revenue and cost forecast for the PPM Project.
In this process the business has delegated the authority to the project manager to allow them to
approve the new work or the change request. The Project Manager is trusted to know when the
change request is so large that it should follow the Large Change Request process as outlined above.
8.4 Project Re-baseline

This section covers the scenario where the project needs to be reapproved with a new agreed
baseline. The Change Request process is not suitable here as the Project Manager simply alters the
cost profile associated with the project as a result of this event.
The status network will allow the project to enter from an operational stage to an estimate phase and
seek approval. The same workflows will be invoked to gain approval from Business Unit and CEO.
The ‘CO Version 0’ will contain the project valid baseline. When the project manager is to create a
new baseline for the project, the version 0 will be copied to a new version e.g. version 3 and the
version 0 will continue as the valid project baseline. Using CO versions in this way ensures that we
can store the old and new baselines.
The PS project exists so a CO version can be taken as a new baseline. In addition the portfolio and
project has a snap shot taken before and after the re-baseline.
The project continues with the historical actuals posted but it has a different forecasted profile in terms
of revenue and cost. Most importantly the baseline used for bonus purposes has been changed and
stored so that performance can be measured against the new baseline.
8.5 PPM Version Snapshots

There is version control available on the PPM Project. The <Client> process demands that a snapshot
will be taken at the following critical times:
Upon release of the project to the Detailed Estimate phase
Upon release of the project after a Change Request
It is also possible that the Project Manager will store a PPM Project version every two weeks.
This section of the document will outline how a snapshot or a version of a Project can be taken. It will
also outline how a comparison can be performed on the Operation project and its older snapshot.
1. The user goes to the Project Versions tab within the PPM Project.

2. The user presses the Create Version button and then the Create Snapshot option.
3. SNP00001 or equivalent version number is chosen.
4. OK button is pressed.
5. A new snapshot is stored of the data in the PPM Project.
6. The Project Versions tab now shows the version that was created.
7. The user might like to compare this older version with the operational next.
8. The user goes to the Versions area of SAP.

9. The user presses the Compare button.
10. The user specifies the project to compare and presses the Compare button.
8.6 CO Version
CO Versions will be used for planning, forecasting and booking actuals of financial Data.
The original Plan (Baseline) will be frozen. Using CO Version on the financial View will alow to
compare Baseline, Forecast and Actual Figures on Portfolio Item and Bucket Level.

The project will be able to follow the below process to seek a reapproval of a rebaseline.
1. The Programme Manager sets the user Status ‘Request for Re-baseline’.
2. The workflow is sent to the CEO and Business Unit Manager for approval.
3. The email is sent to them to remind them of this pending approval.
4. The approval is logged in a dashboard or screen for the CEO and Business Unit manager.
5. When both the CEO and Business Unit managers approve the workflow.
6. The workflow will go to the Gloabla Operations team who will action the re-baseline by
copying a new baseline CO version. The old baseline is also retained.
7. The project proceeds with the new recently approved baseline.
9. MONTH-END PROCESS
9.1 Work in Progress
The business needs the ability to calculate the (WIP) Work in Progress for each PPM Project. The
WIP is used to report to the board of directors and revenue commissioners a fairer reflection of the

(WIP) revenue of the company to date. In addition the solution must be able to calculate the predicted
WIP at months in the future based on the forecasted hours.
In order to deliver functionality that meets this requirement our design has included a new bespoke
transaction or screen to calculate WIP (predicted and current). The following paragraphs outline the
algorithm that this new screen will use to calculate this WIP total.
The recognised revenue or WIP revenue is very different to PPM Project revenue stored in the
systems financial views. The PPM system will store the actual true billed revenues and the planned
true billed revenues in the financial views of PPM Portfolio Management. It will store the WIP revenue
in the financial views. The system will need to calculate the WIP revenue in a bespoke program based
on the following algorithm outlined in this section.
The WIP revenue calculation is based on hours worked to date on the project in <Client>. So, the
actual hours expended as a percentage of total hours expected at completion is the factor used to
determine the proportion of revenue recognised i.e. the WIP revenue. There is also an adjustment for
a Business Unit.
The above calculation is very similar to Earned Value (EV), but is NOT the same. The standard SAP
system calculates EV based on Actual Costs to Date, hence, an ABAP development is required to
calculate recognised WIP revenue based on hours and other factors.
To illustrate the algorithm the following worked example is used.
1. The table below outlines a project with total revenue of 6,000 EUR broken into three
milestones of 1000, 2000 and 3000. This is represented on the second row.
2. In this example, we are at the end of the month March.
3. There are actual hours for every month to-date. There are forecasted or planned hours from
April to June.
WBS Jan Feb Mar Apr May Jun Total
TUC001 Revenue 1000 2000 3000 6000
Hours 50 50 20 25 50 50 245
Planned
Hours 20 50 30
Actual
4. The formula used to calculate WIP revenue at the end of March is illustrated as follows. The
spreadsheet below has the columns indicating the formula used.

5. The formula must calculate the percentage of the total revenue figure at completion that
contributes to the WIP revenue. The percentage of completion is based on the actual hours
to-date and the most up-to-date forecasted hours to complete. This is seen in cell H8. The
pure WIP is the amount over and above the billed amount (Cell H20). The Pure WIP is
multiplied by a regional factor (Cell H22). The WIP per financials is the pure WIP minus the
provision (Cell H24). This is added to the total billed to date to give the recognised revenue
(Cell H28). It is this figure that the report must show and store.
6. The above has explained the WIP for the current month. It is also required that this
development calculates the predicted WIP for each month in the future. So, the future
predicted WIP at each month April and May and June in the future can be calculated. The
equivalent algorithm should be used.
7. For completeness the following calculation is defined for the May month. This is the predicted
WIP for May.

8. The calculation for the forecasted WIP is identical to the current WIP except the cutoff date is
different. The forecasted hours are assumed to be actual hours from the original cutoff date
and the end date of the month for which WIP is forecasted.
It is intended that WIP is run on all projects automatically each weekend. Thus, the latest version of
the WIP for each project will be available after the weekly timesheets have been posted.
Users can run this program manually and calculate WIP for one project or a selection of projects
because there is a selection screen on the front of the WIP program report.
All intermediate results and final results for every project and every week of the relevant project will be
stored in the z-table. This will enable easy reporting on the results. It will also provide a means to
audit and debug the algorithm.
There will be a transaction with filter and sort capability to report and view the results.
The below table illustrates the intermediate results and final results after the WIP has been run. The
user will be able to filter and sort on each of these fields.

It is also a requirement that the user can lock WIP calculations for all months to a certain point in time
e.g. Quarter End. This is particularly important where cost re-forecasts can cause a reduction of
previously calculated WIP figures for months in the past. This is to be avoided as it in effect reduces
previously calculated WIP revenue positions communicated to shareholders and revenue
commissioners. When locks are placed on these months the algorithm will only calculate the WIP of
months after the locked months.
The calculated WIP will be used e.g. in the financial view for Margin Calculation
The above table and all its entries are available for reporting in the system. The user can query these
entries based on the fields outlined in the algorithm above.
Note: it is important that the system is able to archive WIP calculations. So in the event the users can
see what was calculated at various points in time. The ability to restore from an archived version is
also important.
10. HR PPM INTEGRATION
10.1 Role Type and HR Integration

The following section will explain how the HR Career Framework integrates with the PPM (Portfolio
and Project Management) module. The vision for the system is that the project cost planning, project
role planning and career planning are aligned.
The following table will explain definitions of some of the data objects. After this table we will be
explain the relationship between these objects.
Data Object Module Definition
Project PPM An SAP Project is a set of interrelated tasks and subtasks that define a
goal.
This is created in the PPM system to represent an agreed engagement
with a customer. Costs and team members are associated with the
project in order that the project can fulfil its objective.
It is typically represented in the RevRes system and has a Journyx
Timesheet code e.g. TUC00647
Task PPM An SAP Task is created inside a Project. There can be many tasks

created inside the Project.
For example, “Install Database” might be a small task inside a larger
project “Policy Manager Implementation”.
Role PPM A SAP PPM Role defines a position in the project
or
a Qualification/Skill combination that is required to perform a task or
collection tasks.
We associate or link Roles to Tasks in the Project.
The Role is a free-text format.
Role Type PPM A Role Type specifies information about the Role. It is a defined set of
values that cannot be altered by the User.
The Role Type determines the Cost per Hour of the Role.
The Role Type determines the careerpath level of seniority and skill that
is required.
When the links between Role, Role Type and Task have been made the
cost of the costs can be determined for planning purposes.
Resource PPM A PPM Resource is equivalent to an Employee in the HR module.
We link a resource to a Role and thereby assign an Employee to a
Project and more importantly to a Task on the Project.
Employee HR A HR Employee is equivalent to a Resource in the PPM module. These
two data objects are synchronised by the SAP system so we can refer to
them as representing the same thing in real life.
Although independent contractors are not legal employees of <Client>,
they are set up as SAP Employees in the SAP system.
The Personnel records representing Contractors are set up with a flag to
denote that they are contractors and not legal employees.
Business PPM Internal and external Ressources (and also customer) will be set up as
Partner and Business Partners. The Business Partner contains a field with the HR
HR / Personal Number for employees. Within the HR Minimaster information
SAP about the Home Cost Center of the employee is strored. The Business
ECC Partner Data will contain the individual actual blended rate.
The Business Partner, coming from HR – Personal Master Data will be

known in PPM and SAP ECC.
In PPM the Business Partner will be used as a resource that can be
assigned to specific tasks via Assignment to specific Roles.
The Business Partner will be known during Time Registration in SAP
ECC – CATS Time Registration.
Job Families HR A high level grouping of jobs within the company such as technical,
administrative, or programme management. SAP has a concept of a job
family that maps to the same concept within the <Client> Career
Framework. The exact Job Families that are loaded into SAP will be
supplied by the <Client> Career framework exercise.
Job HR Jobs are general classifications of individuals within <Client> based on
the nature of the role that the individual performs, their market rate, level
within the organisation, and their alignment within the <Client> Career
Framework.
Discipline HR Skills and qualifications are associated with an Employee to record the

abilities that this person has.
These can help search for and find suitable people for Roles in a
Project.
There is one special Qualification which is called Role Type. This field
value indicates the following for an employee: the blended fully loaded
cost of the employee, the 'Job', ‘Discipline’ and 'Organisation Unit'
(location), and Employee Group (Employee / Contractor).
Discipline <Client> This is a term used in <Client> and is incorporated into the Job and Role
Type codes. For example, a job of ‘Advanced Engineer’, can have a
discipline of ‘Tester’.
The structure below outlines the relationships between the objects. A project has tasks; the tasks are
associated with Roles. The Roles are defined by the <Client> Role Types that are defined by HR and
align to the HR career framework. The role is staffed by a PPM resource which is a HR Employee
(Employee or Contractor). Every HR Employee is given a Role Type in the Qualifications screen of the
HR record.

It is important to note that the SAP system as standard does not enforce integration between Role
Type and Job and Employee. For example, it is possible to define a Role Type as Programme
Manager and Job as Accountant. We would like integration so we will enter equivalent data in the
PPM Role Type and the HR Job tables so that in effect we have an aligned the PPM Role Type and
the HR Job.
The Role Type is a field value that needs to indicate the following:
Job
Discipline
Location

Employee Group (i.e. Contractor or Employee)
The Role Type field values will thus be structured with the following nomenclature.
The second row denotes the number of characters that we will use for each code part.
Job Discipline Location Employee or Contractor

Advanced Engineer Tester Malaysia Employee
2 characters 1 character 2 characters 1 character

‘AE’ ‘T’ ‘MY’ ‘E’
This nomenclature is required because the Role Type determines the hourly rate that is used for
project planning purposes. The code parts above are the criteria that best allow the business to group
people according to salary and skill type.
So every 6 months the accounting department will recalculate the blended rates by using the following
formula.
TotalOfSal ariesForAllPeopleInRoleType
BlendedHourlyRate  Re gionOverheadFactor 
TotalOfAll HoursWorkedIn Pr eviousSixMonthsByPeopleInRoleType
The method of generation and storage of the personal actual blended rate will be explained in a
separate document (Functional Specification).
The following process can be envisioned that shows the alignment of data fields in PPM and HR.
1. A project is created with a task that requires one day of an Advanced Engineer in the testing
discipline. The project is executed in Washington, USA.
2. The project manager of the project would like to cost this project. She translates her role
requirement into the code structure AETWAE.
3. She creates the PPM Role in her project calling it the “Java Front End Mobile Phone Tester”.
She specifies the Role Type AETWAE against this role. This indicates specifically the type of
person that she is looking to perform the role on her project in terms of cost and skill.
4. She searches for a Resource to perform this Role. But there is none available. She decides to
search for a contractor instead and searches for a AETWAC. There is none available either.
The Role Type on the Role is still AETWAE.
5. She fails to find any employee or contractor with the Role Type equivalent of AET in any place
in <Client>.
6. She is not happy to neither increase the level of the Role Type nor accept an inferior level for
the Role in this example in her project. In short, she wants a AETWAE.
7. The request for hire and the approval associated with this remains the same.
8. The business decides to hire an Employee for this Project Role.
9. The HR department creates a Position against the Job “Advanced Engineer Tester ”. This is
equivalent to the “AET” part in the Role Type.
10. A person is hired and set up as an Employee in the system. The Employee Type is
“Employee” not “Contractor”. The Qualification AETWAE is set against Role Type in the
Employee Record.

11. Upon saving the record the system checks that a sensible Role Type is specified against the
Employee’s Job. If for example a Project Manager Role Type is specified against a Job of
Accountant then the system will issue a warning. This is a bespoke error message.
12. Every six months the Average Hourly Blended Rate is calculated based on all of the
Advanced Engineers in the testing discipline employed in Washington, USA. This rate is
automatically assigned to the Resource representing the new employee.
13. In the case of our newly hired Employee in this example, the blended rate is set up by the
Global Operations by looking at the equivalent rate for another AETWAE. This is because we
cannot wait for the blending program to run.
14. The project manager performs the search for a AETWAE again and finds the newly hired
person. She assigns this person to the Project Role. The project is costed accordingly. The
Resource blended rate overrides the Role Type rate.
Note:
The purpose of the above process is to explain how the Role Type and Job are used in the
identification of a capacity demand and the fulfilment of this through hiring an employee.
There is a step omitted related to the creation of the Resource in PPM to represent the soon-to-be
hired Employee. This ‘dummy’ Resource can be planned on the project and will appear in the BW
reports related to Capacity Supply.
It is important that the ‘dummy’ Resource is deleted after the Employee has been hired on the system
otherwise the system will double count the capacity supply in terms of head count.
Note:
There is a piece of bespoke code required to enable the Project Manager upon creation of the Project
Role to easily find the correct Role Type to use. The list is likely to be close to 100 entries so might be
difficult to find.
We envision a design that has a button next to the Role Type field on the main screen.
Upon pressing this button the User receives a popup box with the ability to filter.
There are drop downs on each of the filter criteria that enable the user to reduce the list to a smaller
list.
The user will be able to use wild cards in this search and thus by entering Role Type equal to *WA*
the system will return all records with the letters WA contained in the Role Type field value.

The results screen also contains the Cost/unit value to help the Project Manager choose an
appropriate Role Type that suits the cost objectives of the project.
The user selects the value required then presses OK.
The system places the value chosen into the Role Type field on the main screen.
Note: the above section shows how the SAP standard field can be used to represent the skill-location
blend rate as a Role Type. It can be used to track the role and discipline requirements for projects by
those interested in capacity planning. It should be noted that this field can be decomposed into its
constituent elements in BW to enable users to report over elements of all Role Types e.g. reports can
be written to collect data on all Contractors globally.
10.2 HR Employee to PPM Business Partner Mapping

The following is a list of the fields that are synchronised between the ERP HR Employee master and
the PPM business partner.
In some cases we will not be using the field in the list below in HR and thus the data will not be
synchronised across.

In addition the Organisational Structure and the Qualifications mappings are synchronised from HR to
PPM.
The reader can read the section on resource searching to understand the fields that can be used to
search in the PPM Project during the staffing process.
The business partner fields are also augmented by the PPM Resource fields. These resource fields
are illustrated below.

11. REPORTING
11.1 Overview
This section will outline the reports that are required in the solution. The approach in this section has
been to analyse the major reports currently in use at <Client> and ensure that the data structures are
in place in the SAP solution to enable an equivalent report to be written in SAP.
The section will start with a table listing the major reports. The subsequent sub-sections analyse each
of these reports and point out where the equivalent data will come from in the SAP solution. There are
some reports highlighted as out of scope and not required in the workshops. These have been
included with the comment “not required” for completeness. There are many reports that are similar.
For example, there might be a NAR and an EMEA report of the same variety. In this case we have
analysed one and simply made a comment that the second report is an equivalent report using the
same data structure.
Financial Reporting will be based on Baseline, Forcasted und Actual Data. This Data will be used in
different Financial Views like Margin Reporting or Cash Flow Reporting on Bucket Level and the
Portfolio Item Level.

Regarding to adHoc Reporting or flexible Analyzes the Functionality on the Portfolio Item Level is
restricted to Filter functionality.
Therefore for interactive flexible Reporting, more complex Reports will be defined in BW.
There are many standard reports available in the PPM module that might be sufficient as delivered
out of the box. However, we have taken a conservative approach to this and assumed that the major
reports will need to be built in the BW system.
The table below lists the major reports analysed. The table also indicates the team who will build the
report. It is noted that the IBM BW team will provide the dataset for the <Client> BW report writer.
Report Category Team Report Comment
Creator
WIP Report NAR zABAP Report ABAP Gautam Maiti
WIP_Feb12.xlsx built in SAP
Support et al detail Timesheet BW report BW Rachael IBM will support and
Cost Feb.xlsx – User Analysis Flynn/Eoghan supply the dataset.
Donnolly
Support et al detail Timesheet BW report BW Rachael IBM will support and
Cost Feb.xlsx - Project Flynn/Eoghan supply the dataset.
Analysis Donnolly
NAR Profitability and Cost BW report BW Rachael IBM will support and
Detail_Feb12.xlsx - NAR Flynn/Eoghan supply the dataset.
Billable Cost USD Donnolly
NAR Profitability and Cost BW report BW Rachael IBM will support and
Detail_Feb12.xlsx - NAR Non Flynn/Eoghan supply the dataset.
Billable Cost USD Donnolly
YTD Services Regional <Not <Not
Profitability Required> Required>
Summary_Jan12.pdf -
Consolidated
Summary_Jan12.pdf –
Region Business Unit
Summary_Jan12.pdf –
Transfer Summary
YTD Services Regional BW report BW Rachael IBM will support and
Profitability Flynn/Eoghan supply the dataset.
Summary_Jan12.pdf – Travel Donnolly
report Euro

Gaps Report APAC EMEA BW report BW Rachael IBM will support and
2012-03-22.xlsm - EMEA 70% also Flynn supply the dataset.
Mar similar
Standard
Reports
120329 - Resources-Status- BW report BW Rachael IBM will support and
Combined.pdf Flynn/Eoghan supply the dataset.
Donnolly
120118h-GPO-v1.0.xlsm <Not <Not
Required> Required>
CALA Forecasted Project BW report BW Rachael IBM will support and
Profitability_Feb12.pdf Flynn/Eoghan supply the dataset.
Donnolly
CPSES Monthly Billability BW report BW Rachael IBM will support and
Analysis _Feb12.xlsx - Bill Flynn/Eoghan supply the dataset.
Type Summary Donnolly
Departmental Cost <BusinessOne <BusinessOne
Summary_support_Feb Report> Report>
2012.xlsx – Environmental
Engineering
Departmental Cost BW report BW Rachael IBM will support and
Summary_support_Feb Flynn/Eoghan supply the dataset.
2012.xlsx – Headcount Donnolly
2012.xlsx – Costed Time Donnolly
Summary
2012.xlsx – Support Activity Donnolly
Summary
Engineering Monthly Billability BW report BW Rachael IBM will support and
Type Summary Donnolly
Type by Dept. Donnolly
Analysis _Feb12.xlsx - Flynn/Eoghan supply the dataset.
Overhead Hrs Donnolly
Analysis _Feb12.xlsx - Eng Flynn/Eoghan supply the dataset.
Hrs Donnolly
Analysis _Feb12.xlsx - Non Flynn/Eoghan supply the dataset.
Eng Hrs Donnolly
Analysis _Feb12.xlsx – Total Flynn/Eoghan supply the dataset.
Hours by User Donnolly
Analysis _Feb12.xlsx - Flynn/Eoghan supply the dataset.
Overhead by User Donnolly
Invoices Forecast Report BW report BW Rachael IBM will support and
Flynn/Eoghan supply the dataset.
Donnolly
Services Regional Profitability BW report BW Rachael IBM will support and
and Cost Detail_Feb12.xlsx Flynn/Eoghan supply the dataset.
Donnolly

11.2 WIP Report NAR WIP_Feb12.xlsx
This reporting represents a billing forecast.
The table below will indicate the SAP data fields where the data fields above will be found. The
<Client> report shows 3 rows for each project these are depicted below in columns 2, 3 and 4.
The comment in the intersection denotes where the data will come from in SAP.
<Client> Report Field 1 Revenue 2 Actual Jyex 3 RR
Source
Customer Project.Customer
Number
Project Project.Name
Code Project.Number
Team Project.Responsible
Role
This is assumed to be
the <Client> programme
manager of the <Client>
programme in question.
Status Project.User Status
Tot 11
Feb 12: Inv The forecasted invoice
billing per month.
The SAP report will use The SAP report will The SAP report will
the WIP calculation show all actual hours show the forecasted
algorithm as specified in entered in CATS for hours for each of the
another chapter to all months to date. months after the
calculate the WIP based current month.
on hour expended.
The 15% safety factor is
defined in a z-table per
Business Unit.

Note:
The WIP calculation always discounts the overtime. The report will always discount the timesheet
hour of one person over the 8 hour defined in the unit of measure table.
There will be a z-table to indicate the contingency factor by which the WIP is adjusted during the WIP
calculation.
It is a business rule that the Project Managers will not forecast overtime in the projected hours in
PPM. The primary reason for this is to show a capacity demand that can be related to head count
more easily and the WIP calculation will require this also.
The selection screen will include a selection criterion that determines the date, from which the report
uses forecasted figures and not actual figures. There will need to be a program that combines the
actual and forecasted hours based on the date specified above.
11.3 Support et al detail Timesheet Cost Feb.xlsx – User Analysis

The following report is a report showing costs based on the hours posted in the Project Types for
Overhead and Core Business by person.

The costs above will be gathered from the CO table that contain the posting from the timesheet CATS
submission.
11.4 Support et al detail Timesheet Cost Feb.xlsx - Project Analysis

The following report is a report showing costs based on the hours posted in the Project Types for
Overhead and Core Business by person.
The costs above will be gathered from the CO table that contain the posting from the timesheet CATS
submission.
11.5 NAR Profitability and Cost Detail_Feb12.xlsx - NAR Billable Cost USD
This is very similar to the above reports for the support projects but split out for NAR.
11.6 NAR Profitability and Cost Detail_Feb12.xlsx - NAR Non Billable Cost USD
This is very similar to the above reports for the support projects but split out for NAR.
The <Client> task will be analogous to the new field in the timesheet that categorizes the time.

11.7 YTD Services Regional Profitability Summary_Jan12.pdf - Consolidated
<Not Required>
11.8 YTD Services Regional Profitability Summary_Jan12.pdf – Region

Business Unit
<Not Required>
This report will not be produced by the SAP system. It will be produced off-line.
Some information required to perform this off-line report will be sourced from the SAP BW system.
11.9 YTD Services Regional Profitability Summary_Jan12.pdf – Transfer

Summary
<Not Required>
11.10 1.6 YTD Services Regional Profitability Summary_Jan12.pdf – Travel

report Euro
Only invoices are shown in this report.

The following table outlines where the data will be sourced for this report.
Field Description
Region This will be obtained from the portfolio bucket to which the project is
linked.
Project Code The Project.Number represents this element in SAP.
Source The description of the finance document in the BusinessOne system.
This is the vendor account or the customer account.
Travel and other Expenses This is the actual expenses euro value imported to SAP ERP from B1.
Travel Recharge This is the actual revenue euro value imported to SAP ERP from B1

representing invoices raised for expenses.
Grand Total The summation of the above fields to give a column that can be
totalled.
Note: the USD equivalent report can only be produced for the companies that post in USD. The APAC
company Kualar Lumpar posts in Ringgits and EURO not USD.
By using exchange Rates, Object and Transaction Currencies during financial bookings all reports can
be shown in different Currencies.
The below costs are not booked in PPM. They are best obtained from the BusinessOne system. This
is not in scoope.

11.11Gaps Report APAC EMEA 2012-03-22.xlsm - EMEA 70% Mar
This presentation is broken into three different reports.
There is one presentation created for each regional Business Unit. This blueprint will explain one
regional business unit only.
The table below will outline the fields used from SAP for this report.
Field Description
Client Name Project.AdditionalData.Customer
Project Name Project.BasicData.Name
Role Project.Resources.General.RoleType
Team Project.Structure.BasicData.ResponsibleRole
This is the project/programme manager and resource manager.
Region The portfolio bucket to which the Project belongs.
Unidentified Resources This will be the capacity demand in hours for the role.
We can change the unit of measure also and make it appear in FTE
months.
Comment Project.AdditionalData.Area
Project.AdditionalData.Location
Status Project.Status
Probability Project.Probability(Severity)
Month The Role Start and Finish Date of the Role will be filtered based on the
filter criteria.
Date Start
Date Finish

The red status definitively shows that the role has not been staffed with an SAP resource.
The warning sign shows tasks that have not been sufficiently assigned to a resource. So, there is
additional capacity to be found for the task.
The Role Type of the Role can also be attained for this report as each Role will have a Role Type
assigned.
There are some standard reports available to see overbooked and under booked resources. The
resource managers and the project managers will be also able to see this in the status icons.
The Availability column is calculated from the Billability% z-field on the HR master.

The Projects field contains the projects that the person is staffed to.
The above reports are graphical representations of the count or totals in the other reports.
11.12 120329 - Resources-Status-Combined.pdf

This file is a presentation that is made up of reports. The reports will be explained in this section. The
text information about context cannot be stored and reported in SAP.
The reports are produced for each regional business unit. This document will analyse one of these
regions.

The above graph can be produced with the following dataset and equivalent SAP field values.
The monthly difference can be produced when the presentation is created.
PPM Project Project Number PPM Project Role Role Type Count of Roles
Customer Business
Partner
Sri Lanka Telecom TUC1111 000001023 KLSE1TC 2
Sri Lanka Telecom TUC1111 000001024 KLSE1TE
Axis TUC3333 000002222 KLSE1TE 3
Axis TUC2222 000002223 KLSE1TE
Axis TUC2222 000002224 KLSE1TE
The above screen shot is a snap shot of the previous months report and also the snap shot run for the
current month.
The below table will outline the fields that are used to construct the above reports.
Field Apr-2012

Weighted Probability This not within scope as this is the numbers
adjusted statistically
Probability >= 80% This is the total demand in terms of hours divided
by conversion figures in the PPM configuration to
denote FTE months.
There might be some projects planned in Days so
the conversion must be able to cater for this.
The probability of 80% related to a group of User
Status on the PPM project. Each status is
analogous to a status and the >=80% relates to a
group of them.
The severity field will be used to record the
percentage probability for the project.
Probability >= 70% Similar to above
Resources on Loan to A resource on loan is identified as having an Area
other Regions Location combination different to his cost centre
equivalent.
This data is time-sliced as with all HR data.
If the resource in allocated to two Area-Locations
in the one month. The hours can be split
according to the proportion of the days to 30
days.
Resources on Loan to This is equivalent to the above field.
other Businesses
Total PS headcount This is the total of the Business Partners in the
particular Business Unit that is being measured
e.g. EMEA, APAC.
The Business Partners will be assigned an Area
Location that is time-sliced and this will need to
be reflected in the month columns in the report.
If a resource is switching Area Location during the
month in question the report can adjust the
headcount by the fraction of that month spent in
each Area Location combination.
There will be some Business Partner records that
will have been deactivated. This will need to be
taken into account as a deactivated Business
Partner is not counted in the head count. The
Business Partner active field will be time-sliced
also.
Extra Business partners will be created with a
separate Business Partner Type to represent
employees that have not yet joined the company
are expected to join.
Available Billable The Billability% field on the HR master will
headcount determine this field.

For those persons that are partially billable they
will be considered billable in this report.
Resources on Loan These are identified as Business Partners that
from Other regions have a different Area Location as EMEA but a
Cost Centre that is not EMEA.
There might need to be a z-table to map the Area
Location to the associated Cost Centre.
Resources on Loan The above data can break down the data to
from Other Business where the resource originated from so this
information is available: business Unit or Region
or Business.
It should be noted that this data is time sliced
also. So future Cost Centres and Area-Locations
field values can change over time.
Excess/Shortfall The values of supply and demand are subtracted
to give a balance headcount figure.
It will be possible to include the dummy Business Partners that represent future to-be hired resources.
The reader will notice that the Win Probability% is a property of this dataset and will be represented
by a separate field to the Status field. This will enable BW report writers to write reports that can filter
and sort based on the Win Probability%. So, for example, a User can see demand for all projects with
Win Probability 10%, 20% 30% only. This will be selectable for the user of the report. It should be also
noted that the PPM view of capacity will not be able to distinguish between Win Probability%: it will roll
up all project demand above 50%.
The dataset used in this report can be used to explore and understand resource requirements at
lower Win Probabilities. The win probability will be used for Engineering also. However, it is highly
likely that they will use 0% and 100% only.
<The above report is not required from SAP PPM>

The above report shows projects that have a status between SOW and baselined but which have an
actual posted against them.
The fields can be found with the below mapping.
<Client> Field SAP Field
Customer Project.AdditionalData.Customer
This is a Business Partner.
Code Project.Number
The number will be an integer in the SAP system
when it is at this stage in the sales process.
PID <not relevant>
Region The portfolio bucket to which the project belongs.
Team Project.ProjectManager
Flag
Probability As above Project.Status
Currency Currency used will be EUR in the case of portfolio
items.
Revenue Revenue for the months forecasted in PPM.
This will be in EUR
The expected invoicing report is similar to the one described in the invoice fixed price project process.
The other fields required for this report are contained in the report above.
The permanent v contractor headcount report can be produced with data on the Business Partners
split between Employee and Contractor in the Employee Type field in the equivalent HR record.

Billability% v Count of Business Partner
This report is best achieved by analysing the total number of hours recorded in the month split across
the Project Types. The Project Types denote whether the project is billable or not.
The hours can be adjusted to change the unit of measure to be FTE months.
The above report can be achieved by showing total hours split across the Project Types and the
Portfolio Buckets.

The above report can be achieved by breaking down the total hours per month by the Activity field that
captures the <Client> Task in the SAP system. This custom field is explained in the section entitled
“Timesheet Process”.
The above report can be achieved by sorting the Overhead Projects by total hours booked by
individuals.
The fields are mapped as illustrated in the following table.
<Client> Legacy Field SAP Field
User Cost Centre Business Partner Cost Centre
User SAP Username posting the booking
Project Type Overhead Projects
Task The bespoke field capturing the <Client> Journyx
Task
Project Sub Project Project.Number
Month The month of the timesheet entry.

The above report is similar to the last report but it breaks down the hours into the month of the year to
date.
The above report is a Project that has a status SOW and has a Project Code with integers only i.e.
<A.
The roles with assignees associated with these project can be found in the PPM cubes.
The fields have been described in the reports earlier in this chapter.
The rest of the reports in the pack are primarily status reports on the Projects in PPM.
11.13 120118h-GPO-v1.0.xlsm
This is the ResRev file and as such is more a database than a report.

11.14 CALA Forecasted Project Profitability_Feb12.pdf
This is a variance report between the baselined project and the current gross margin position.
Legacy <Client> System SAP Field
Customer Porject.Customer
Code Porject.Numer
Region Portfolio to which the project belongs
PM Proejct.PersonResponsible
Currency The currency of the project will be the currency of
the company code into which the costs and
revenues are booked.
Ex This is not required as SAP will post in EUR and
the company code currency as stored on the date
of the post in the Exchange Rate table.
PCR Revenue The total revenue amount entered into portfolio
item.
This is adjusted to not include the revenue
elements that do not make up the <Client>
revenue number.
PCR Cost The total cost amount entered into portfolio item.
This is adjusted to not include the cost elements
that do not make up the <Client> cost number for
margin calculation purposes.
PCR GM The subtraction of the above to figures.
PCR GM% The percentage of GM over the revenue in the
baseline.
Revenue The forecasted revenue but adjusted for <Client>
revenue consideration.
This is adjusted to not include the revenue
elements that do not make up the <Client>
revenue number.
Cost The forecasted total costs at completion but not
including those (e.g. HW, SW) <Client> cost
elements that are not included in the cost
calculation.
This is adjusted to not include the cost elements
that do not make up the <Client> cost number for

margin calculation purposes.
GM The subtraction of the above to figures.
GM% The percentage of GM over the revenue in the
baseline.
11.14.1 Forecasted Gross Margin % on Bucket and Portfolio Item

The most important requirement from a Program Manager perspective is to have a clearly visible
Forecasted Gross Margin % for each Portfolio Item on the Main Screen.
The Margin and the underlaying Figures will be presented on the Portfolio Item via Financial Views.
This is currently not final configured.
The Functional Specification will precise the calculation. A Data Model is set up in Excel which
represents the Financial Views, that will be set up in PPM
It will be possible to report/compare Baseline, Operational Forcasted and Actual Data on Portfolio
Item Level and BW. Therefore different Versions (CO-Versions) will be defined and used in PPM
The financial revenues and costs can be forecasted per month. There is a need for cut off control on
this report for actual. There will be a cut off date functionality in the WIP report. The calculated WIP
Figures will be shown and used within the PPM financial view.
Costs
Revenues

Margin

Underlying Data
Note: Not every Cost Category will be relevant for the Margin Calculation
The following screenshots show the financial View on Bucket and Portfolio Item Level

11.15 CPSES Monthly Billability Analysis _Feb12.xlsx - Bill Type Summary
This report is almost identical to the report described in Support et al detail Timesheet Cost Feb.xlsx –
User Analysis above.
11.16 Departmental Cost Summary_support_Feb 2012.xlsx – Environmental

Engineering
<This is a BusinessOne report>
11.17 Departmental Cost Summary_support_Feb 2012.xlsx – Headcount

• The head count is the count of discrete timesheet submitters in the month. (Not currently the case
for Employees)
The date is broken out by employee type contractor or employee based on the HR master.
The projects are grouped in the white rows above.
The employees are broken out according to region across the top. This is analogous to the HR cost
centre to which they are assigned.
The head count is the count of discrete timesheet submitters in the month.
11.18 Departmental Cost Summary_support_Feb 2012.xlsx – Costed Time

Summary
This is the timesheet hours costed across the months and the projects and project tasks.
The Project Type will drive the categorisation of these line items.
User Activity = Project Type

Cost Centre to which the person belongs.
11.19 Departmental Cost Summary_support_Feb 2012.xlsx – Support Activity

Summary
This is the timesheet hours costed across the months and the projects and project tasks.
User Department = Project Code

The User Activity field in the report is the Project Name in PPM. There will be some breakdown
according to the ‘<Client> Journyx Task’ from the timesheet.

11.20 Engineering Monthly Billability Analysis _Feb12.xlsx - Bill Type
Summary
The report above is a combination of PPM Project and Timesheet z-field that was “<Client> journyx
Task field”. This data is broken out by the Area-Location also.
11.21 Engineering Monthly Billability Analysis _Feb12.xlsx - Bill Type by Dept.

11.22 Engineering Monthly Billability Analysis _Feb12.xlsx - Overhead Hrs

11.23 Engineering Monthly Billability Analysis _Feb12.xlsx - Eng Hrs

11.24 Engineering Monthly Billability Analysis _Feb12.xlsx - Non Eng Hrs


11.25 Engineering Monthly Billability Analysis _Feb12.xlsx – Total Hours by
User
The engineering department people are identified by the Cost Centre.
Legacy System Field SAP Field
Employee Type The HR master contains the Employee Type.
Department The Cost Centre to which the Employee belongs.
User HR Name and Surname
Jan The hours have been broken out by month based
on the timesheet week.
Feb
11.26 Engineering Monthly Billability Analysis _Feb12.xlsx - Overhead by User

11.27 Invoices Forecast Report

This report is explained in section the fixed price invoice process.
Project Revenue Project Milestone Milestone Text Date Milestone Actual
[EUR] Manage Status Revenue
r
TUC0112 100,000 Enri-K 102323 30% down 13-Jun-2012
3 Salazar payment for
system design
TUC000 50,000 Joe 234812 10% Hardware 28-Jun-2012 Complete
12 Smith installation
TUC0111 234,000 Peter 234785 Final payment 24-Jun-2012
1 O’Toole for telco
analytics
system
123412 Initial payment 12-Jun-2012
for telco
analytics
system
TUC012 10,000 John 234944 Final Payment 12-Jun-2012 Complete 10,000
3 Doe for System
Partridge

11.28 Services Regional Profitability and Cost Detail_Feb12.xlsx
The “(A)WIP” and “(C)Total Revenue” field is not required.

Non-labour expenses will be required in this report.
Non Billable Time is the people who have the cost centre for the business unit for which we are
running the report.
The row “Consolidation Translation” is not required.
The row “Uncosted Payroll” is not required.
The row “Contractor estimate vs. time logged” is not required.
The field “Transfer Variance due to timesheet revisions after transfer report and FX” is not required.
12. BASE CONFIGURATION SETTINGS
The following section does not contain every necessary Configuration Settings. It just contains some
basic settings. One of the main focuses is the Financial and Controlling Integration Settings for the
Financial View on Portfolio Line Item.
12.1 Object Types for Object Links (System Integration to SAP ECC)
The object types for which object links will be created in a project will be activated
Object links will be made to Objects in SAP ECC PS-System.

12.2 Time Units
The time units for use in Project Management will be defined
Because of use Accounting Integration, the time units that are defined here will exist in the ERP system
and be defined in the same way.
The following Settings will be used.
Time Unit Description
D Days
H Hours
MON Months
The time unit H (hours) will make sure that resource Planning and Time Registration will use the same
Time Unit.
A default time unit will be specify for each project type. The default will be H - Hours.
The Standard working day definition in terms of Hours per day will be 8 hours per day for each Location

<Client> will be able to distribute total demand for roles and staffing for a role over different periods.
<Client> will be able to enter Full-Time Equivalent (FTE) as the unit of the total demand. In this case the
system uses the hours per day information to convert the Full-Time Equivalent unit into concrete demand.
Staffing also contains information about the availability of the business partner. The system also uses the
hours per day information to calculate the availability values.
The SAP unit of work MON (Month) is defined as (30) thirty 24-hour days.
The SAP unit of work DAY (Day) is defined as 1 24-hour day.
We will define two new Units of Measure: FTE Month and FTE Day. This configuration will allow
<Client> to plan the projects by Months in the same way as in the legacy system.
Note the ability to define work in units of hours will be still possible.
Description
FTE Month This will be defined as seventeen (20.25) 8-
hour days.
This is adjusted for holidays.
FTE Day This will be defined as 8 hours.
If there is a region in the world that would like to deviate from the above standard <Client> work units
of measure then a smaller denomination will need to be used in planning e.g. Hours.
All work units of measure can be converted into ISO hours and thus regardless of the unit of measure
specified the reports can be adjusted to the same units of measure, typically these would be hours.
12.3 Areas
The following Areas will be defined.
These are required to drive the loaning process.
They will mirror the cost centre structure of the Business Units used by the HR solution to assign people.
Area Description
APAC Asia Pacific
ATT AT&T

CALA Central and Latin America
EMEA Europe Middle East Africa
ENG Engineering
NAR North America Region
CPSES
OPS Operations
The locations defined underneath these areas will be defined as US State or Nation.
12.4 Project Types

The Project Types are primarily used for informational reporting purposes.
Type Text
Revenue Bearing
Z00000001 Services Fixed Price
Z00000002 Services Recurring Revenue
Z00000003 Support Project
Cost Bearing
Z00000004 Engineering Assist
Z00000014 Engineering Core
Z00000005 Core Activity Project
Z00000006 Overhead Project
12.5 Role Types

The definition of Role Types used in PPM will follow the Naming Convention determined by the HR
department as part of the <Client> Career Strategy.
The following is an example Role Type used in the solution for an employee from Malaysia who is a
Tester and has achieved the level of Advanced Engineer.
‘AE’ ‘T’ ‘MY’ ‘E’

2 digits 1 digit 2 digits 1 digit
This Logic will be followed when setting up the rest of the Role Types in SAP Project – Resource
Management Settings. See the following Example which is not complete.
Role Type Job Discipline Location Employee or Description
Contractor
PMPGEE PM P (project GE (Georgia) E (Employee) NAR Georgia

Manager) ProjectMgr Employee
SETBRE SE T (Tester) BR (Brazil) E (Employee) CALA Brazil Tester
Employee
SETGEE SE T (Tester) GE (Georgia) E (Employee) NAR Georgia Tester
Employee
SEDWAC SE D (Developer) WA C (Contractor) NAR Washington
(Washington) Developer Contractor.
SEDREE SE D (Developer) RE (Reston) E (Employee) NAR Developer

Reston Employee
SEDWAE SE D (Developer) WA E (Employee) NAR Washington
(Washington) Developer Employee
SETWAC SE T (Tester) WA C (Contractor) NAR Washington
(Washington) Developer Contractor
SETGEE SE T (Tester) GE (Georgia) C (Contractor) NAR Georgia Tester
Contractor
SETIEE SE T (Tester) IE (Ireland) E (Employee) EMEA Ireland Tester
Employee
SETGEC SE T (Tester) GE (Georgia) C (Contractor) NAR Georgia Tester
Contractor
SETWAE SE T (Tester) WA C (Contractor) NAR Washington
(Washington) Tester Contractor
SETGEE SE T (Tester) GE (Georgia) E (Employee) NAR Georgia Tester
Employee
Our design assigns a Person to one and only one Role Type (blend). Our design does not allow a
person to be assigned to more than one Role Type.
To each Role Type an hourly Cost - Rate will be assigned
12.6 Priorities
Priorities will be defined, that can be assigned in the projects and portfolio elements.

12.7 Project Reasons
12.8 Roles
The role describes the function exercised by a resource in a project. It contains information about the
qualifications the resource must have and when and how long the resource will be available for.

12.8.1 Role Functions
Role Functions will be defined for grouping roles.
A role function will be assigned to each role.
Example:
Role Function Description
PM Project Manager
SE Software Engineer
DB Database Administrator
TE Tester
ENG-ARCH Architecture
ENG-DEV Development
ENG-LOHIKA Lohika
ENG-PMO PMO
ENG-SS Shared Services
ENG-TEST Test
12.9 Status Networks

The status of the progress of the Portfolio Item is represented by a number of SAP fields. There will
be a User Status on the Portfolio Item that will store the status. In addition to this, there will be a
Portfolio Item Win Probability field. There will be two distinct fields to store this information. The below
table seeks to align the Win probability with the appropriate status, however, other combinations are
also technically possible e.g. 10% win probability but Complete.
The Status and the Win probability will be on the same screen on the Portfolio Item.
Portfolio Status User Status (Commercial Win Probability
Status)
9. Created ROM Projected 10%
ROM RFx 25%
ROM Proposal 40%
10. Released Release Agreed 50%
11. Transferred Release Agreed 50%
Statement of Work 70%
Statement of Work 90%
12. Complete Completed 100%
13. Fully Invoiced 100%
14. Closed Closed 100%
15. Dead Cancelled 100%
16. Closed and
Bonused

Status Services Item User
Progress Type Probability [%] Status Comment
Opportunity
1 qualified Estimation not yet done
High Level estimation done
2 High Level ROM Below 50% on Project level
Detailed Estimation with
resources staffed on Task
3 Detailed Estimate Higher 50% level in a project
4 Final Contract Project execution will start

12.10 <Client> Portfolio Structures
Settings in PPM Portfolio Management will support the following Portfolio Structures
Top Portfolio Enterprise Portfolio Portfolio Structure

<Client> Services APAC
CALA
EMEA
NAR
AT&T
Ops-Adm
Engineering Assist Engineering Assist
Engineering Core Policy Management
Evolved Charging
All other products
CPSES Environment Engineering
Global Support
GPO
IT Systems
Production Engineering
Production Readiness
Other Overhead
Finance
Global Ops
HR
Marketing
Sales
The following screenshots do not contain the final Configuration Settings. They just should give an
idea, how the system will look like on the Portfolio Management Level.

12.11 Financial Categories
A financial category is a monetary grouping such as costs or revenue.
Each financial category will be linked to a number of financial groups. A financial group is a subordinate
grouping of a financial category
12.12 Financial Views
A financial or capacity view is the combination of financial category and financial group that defines the
process for the portfolio item (item), the item of initiative, the initiative, and the bucket. Settings will just
been made for Level Portfolio Item.

The financial and capacity planning data for a portfolio item will be controlled by a process for view types,
which determines how financial information must be filled. The following view type processes will be used:
 Manual
All the categories and groups in this process contain manual entries. This view type process will be
available for portfolio items.
 Integration
All the views for the categories and groups for this view type process are read-only. This view type
process will be available for portfolio items.
The Financial View will be mapped to Cost Elements, coming from SAP ECC in the CO Line Item.

12.13 Portfolio Types
12.14 Linkage of Portfolio Type to Financial category

12.15 Linkage of Portfolio Type to Financial category
Financial views will be used on Bucket an Portfolio Item Level e.g. for a Margin Reporting

12.16 Portfolio Category
We will use the Portfolio Category field to store whether the revenue is recurring or one-off.
This is an important field for accounting information.
The possible values that can be chosen from tis field are listed in the table below.
Portfolio Category
Recurring
One-Off
Engineering
Miscellaneous
12.17 Dashboard Configuration

The solution will contain the following status indicators for the portfolio item:
Budget Status

Schedule Status
Staffing Status
The following paragraphs will outline how these indicators are defined.
12.17.1 Staffing Status

The staffing status for an item is determined depending on the values for total demand (for all roles)
and total assignment (for all roles) with a given Project for the next 12 months of the project.
The logic for the staffing icon is as follows:
Assignment Icon Definition
Assignment = 0 Red Critical Under-Staffed
0 < Assignment < Demand Yellow Under-Staffed
Assignment = Demand Green Properly Staffed
Assignment > Demand Yellow or Red Over-Staffed
12.17.2 Schedule Status or Percentage of Completion

The schedule status for an item is based on the ratio of completed phase-tasks to-date to all phase-
tasks that are planned to be completed to-date. Each task is weighted by the number of planned
hours it takes to complete and the percentage completion of the task.
The table below shows the determination for schedule status.
Ratio Completed Icon Definition
0% - 49% Red Critical Behind Schedule
50% - 89% Yellow Behind Schedule
90% + Green On Schedule
12.17.3 Budget Status

The budget status is based on the ratio of total actual cost to total planned cost. This data is
transferred to SAP Portfolio and Project Management through the SAP FI/CO interfacing process and
is displayed on the Project Details screen. The total actual cost is the sum of all actual costs posted in
SAP FI/CO on the portfolio item cost collectors over the complete posting period of the associated PS
project element.
The budget icons in the Item dashboard are calculated on budget cost and actual cost in the following
way. You can adjust the ratio ranges defining the status in Customizing.
Criteria Budget Ratio Calculation Icons Definition
Budget ratio =
For total planned cost > (total actual cost - budget cost ) Red Critical Under Budget
total actual cost / Yellow Under Budget
total actual cost * 100
Budget ratio =
Green On Budget
For total planned cost (total actual cost - budget cost )
Yellow Over Budget
<= total actual cost /
Red Critical Over Budget
budget cost * 100

The following screen shot illustrates these indicators.
Figure 38 the portfolio item reflects the red amber green indicator status of schedule, budget
and staffing status of the project
13. AUTHORIZATIONS
Warning: SAP uses the word ‘Role’ within the PPM Project to describe a member of the project team.
It also uses this word to describe Authorisation that can be granted to a Username so that system
security can be managed. In this chapter the word Authorisation will be placed in front of the word
Role in order to distinguish this from the PPM Project Role.
The following chapter will outline how the SAP PPM solution will permit or restrict people from using
the system and parts of the system.
The Authorisation in the PPM module is slightly different to the more traditional approach in other
modules. Namely, (a) there is some access granted by adding Usernames to the Project itself and (b)
there is some access granted via portal ESS and MSS authorisation.
This is important to note for readers familiar with traditional SAP authorisation as the three methods
(a) and (b) above and the traditional method will work together to provide the correct level of access to
each Username in <Client>. For example, if a user is granted access to project HCPT0001 by the
project manager of this project but has not been granted access to project information in general by
the System Administrator then the person will not be able to access the HCPT0001 project. Both are
required.
To summarise the above, the authorisation functionality in PPM can be split into three distinct parts
within the <Client> design:
1. General Authorisation: Authorisation is granted centrally to functionality e.g. the ability to
edit any PPM Project.
2. Portfolio and Project-Specific Authorisation: Authorisation is granted to portfolio or project
data at PPM Project Level by the Project Manager or Administrator e.g. Access to a particular
PPM project is granted by the creator of the project a Project Manager.
3. Portal Authorisation: The portal roles determine the menu options that users can see on the
screen.
The following subsections will outline the three distinct parts to the authorisation design.

13.1 General Authorisation
When we refer to General Authorisation, we refer to traditional authorisation that is used in other
modules e.g. FI CO MM.
This Authorisation will be managed centrally by the System Administration function in AMS.
This Authorisation is managed using SAP Authorisation Composite Roles and SAP Authorisation
Roles. These objects contain the authorisation that is then granted to a Username.
An Authorisation Role is simply a group of authorisations that are granted as a unit to a User. The
reader can visualise these as a bunch of keys.
An Authorisation Composite Role is a collection of (above) Authorisation Roles. The reader can
visualise a composite role is as a biscuit tin with several bunches of keys inside.
The diagram below shows how a Username or User is assigned to many (Single) Roles or (Comp.)
Composite Roles. It also shows how Composite Roles are constructed from Single Roles.
Figure 39 Authorisation Structures: Objects, Roles, Composite Roles, and Usernames
The system screen below shows how the Username has been assigned to a number of Authorisation
Roles and Authorisation Composite Roles. This is the screen that the Administrator will use.
The Role Type column indicates if the Role is Single or Composite.
The symbol denotes a Single Role.
The symbol denotes a Composite Role.
Figure 40 Username assigned to Roles and Composite Roles

The next few paragraphs in this section will outline the General Authorisation design for the <Client>
solution. The solution will be explained by outlining the Authorisation Composite Roles that will be
created with a brief explanation of each and how it relates to the <Client> End-Users. The reader can
imagine how each and every end user will be assigned one or many of the Composite Roles to enable
them to perform their job. The mapping of Usernames to Composite Roles is a Realisation task that
can be carried out in the next phase of the project.
13.2 PPM Composite Role Mapping to <Client> Personnel
The below table will outline the Composite Roles that will be built for <Client> as part of the project.
<Client> will have the ability to assign Usernames to these Composite Roles. A user will receive one
Username to enter the system.
In order to remain as close to SAP standard as possible, we have mapped the <Client>-specific
Composite Roles to SAP standard Roles and Composite Roles in the last right hand column.
Note: The end user training courses can be built around the Composite Roles listed in the table below
because the Composite Roles represent a distinct unit of functionality that can be given to a person.
PPM Standard PPM Standard Role Comments Inherits PPM Standard Role
Composite Role Description Authorisation
(functions)
Z_PPM_ADMINISTR <Client> PPM The Global Operations business unit will Every role listed in this table.
ATOR Administrator have c. 5 specific people who will be
SAP_CPR_TEMPLATE_RESPONSI
trained in the administration of the
BLE
system.
SAP_XRPM_ADMINISTRATOR
They will form a part of the AMS or
support organisation for the system. So, SAP_CPR_PROJECT_ADMINISTR
they will require access to almost all ATOR
project data and projects, PS and PPM
SAP_CPR_TEMPLATE_ADMINISTR
and BW.
ATOR
The people with access to this
Authorisation Role will not have access
to the HR data as this is sensitive. They
will only have access to the HR Data
that is deemed Global Operations-
specific e.g. Default Activity Type, Area,
Location. The PPM administrator will
have access to all non-HR sensitive End
User transactions.
This role will be a composite of all other
Composite Roles listed in this table.
These people will also have the
responsibility for the PPM Project
templates.
It is noted that some Global Operations
people (e.g. Merrill) will also be given
access to the HR data of Contractors. In
order to achieve this, the HR
Authorisation Role
Z_HR_Administration_Contractors will
also be given to this person.
Z_PPM_PORTFOLIO <Client> PPM This composite role will be assigned to SAP_XRPM_USER

_MANAGER Portfolio Manager people in the business, who are SAP_RPM_PROJECTREVIEWER
responsible for portfolios but not
projects.
Typically these will be Regional Vice
Presidents, Business Unit Managers,
and Executives.
They will be able to view the portfolio
data at this level in Portfolio
Management.
They will be able to run reports in BW to
receive information on the finances of
the portfolios and projects.
Z_PPM_PROGRAMM <Client> PPM This will be the main user in the PPM SAP_CPR_BCV_USER
E_MANAGER Programme module. This role will be assigned to all
SAP_CPR_BCV_USER_COMP
Manager <Client> Programme Managers, who
need to create, edit or display data in a SAP_CPR_RESOURCE_MANAGE
PPM project. R
Provision might be made to give access SAP_CPR_USER
to Programme Manager delegates so
SAP_RPM_BCV_USER
that alternative people can edit the
system when the Programme Manager SAP_RPM_BCV_USER_COMP
is on leave.
SAP_RPM_PROJECTMANAGER
The people with
Z_PPM_PROGRAMME_MANAGER will SAP_RPM_RESOURCEMANAGER
not be able to create or edit templates. SAP_XRPM_USER
They will be able to copy templates for
use in PPM projects.
The SAP system typically refers to the SAP_TIME_MGR_XX_ESS_WDA_1
managers of projects as Project
Managers. In <Client> we use the term
Programme Manager. The Composite
Role has been named with the word
Programme but it maps to the SAP
Standard Role ‘Project Manager’.
Z_PPM_EXECUTIVE This role will be given to Usernames SAP_RPM_PROJECTAPPROVER
who can approve a Workflow related to
SAP_RPM_PROJECTREVIEWER
the Approval of a Project.
Z_PPM_RESOURCE <Client> PPM There is the case that there might be a SAP_CPR_BCV_USER
_MANAGER Resource Manager person who is assigned resource
SAP_CPR_BCV_USER_COMP
management monitoring tasks at
Business Unit and Portfolio level. They SAP_CPR_RESOURCE_MANAGE
might not have Programme R
Management access. This Composite
SAP_RPM_RESOURCEMANAGER
Role
(Z_PPM_RESOURCE_MANAGER) can SAP_XRPM_USER
be used for this purpose in resource
management.
Z_PS_ACCOUNTING <Client> PPM The accounting department will have SAP_RPM_PROJECTREVIEWER
Accounting some system administration tasks. This
Department User role will be used for these people.
These Usernames will be able to set
exchange rates, open, close periods.
They will be able to view financial

information on the projects.
They will be able to run the bespoke
programme to create to calculate
blended rates for the Resources and the
Role Types.
Z_TIMESHEET_SUB <Client> Project This role will enable someone to enter a
MITTER Team Members timesheet into ESS.
Notes:
1. Project Team Members are only required to submit timesheets on the system. We will not
create an Authorisation Composite Role for Project Team Members. The reason is that there
will not be enough licences for each team member and there is no need for team members to
see the PPM resident project plan: they only enter timesheets.
2. The main reason for isolating the Executive and Approver from the other Composite Roles is
to reduce the numbers of transactions that they are trained in while providing the transaction
that they require to participate in the processes.
13.3 Portfolio and Project-Specific Authorisation

The above section outlined the general authorisation that is granted at a global level to each
Username in the system. This section will explain the additional authorisation that is granted via the
Project itself. The user will require both authorisations before access to the Project data can be
achieved.
Access in PPM is controllable at the Item and Project level by a screen similar to below. It is
modifiable by administrator (owner) of the object (Project or Portfolio Item) e.g. the Project Manager.
Access can be granted, limited, or denied in this screen.
The screen shot below displays an example of how each Username is assigned rights on a Project by
the Project Manager.
By default the creator of the Project will be granted Administration access to ensure that a Project is
only ever saved with someone able to re-access the data.
The table below illustrates how this will be setup for each Project in <Client>. However, it should be
noted that the Project Manager will have the authority to grant more access to data to other people if
(s)he deems fit.
To enable the reader to visualise the <Client> role in the company the first column will contain the
name of the group of people that might have this access. An example Username is also placed in the
second column to help visualise. The columns from Admin to inherited from provide an indication of
the degree of access (read of write) and the aspects that the project data that the person has access
to.
<Client> Composite Role Example None Admin Write Read Evaluate Accounting Res.Mg Staff Cand. Inherited
Username mt Mngr Mgr From
Z_PPM_PROJECT_MANAGER Enri-K Salazar Yes Yes Yes Yes Yes Yes
The project manager of the project.

Z_PPM_PROJECT_MANAGER Nora Buckley Yes Yes Yes Yes Yes Yes
The deputy project manager when the

project manager is on leave.
Z_PS_ACCOUNTING Eoghan Yes Yes Yes

Donnolly
The accounting department team
member or members. Typically they
will need access to see the project for
invoicing purposes.
Z_PPM_RESOURCE_MANAGER Mrs. Resource Yes Yes Yes Yes Yes

Manager
The resourcing is primarily performed
by the Project Manager who is given a
pool of resources to deliver projects for
a particular customer. However, in this
example, we have decided to create a
new resource manager who can assign
resources at a regional level.
Z_PPM_EXECUTIVE Niall Norton Yes Yes Yes
This executive signs off the final P&L

as the project enters the ‘Final
Contract’ part in the <Client> process.
Z_PPM_PORTFOLIO_MANAGER Eric Veere Yes
This is the Business Unit manager or

Regional Vice President who can see
the figures from this project in a
portfolio view.
Z_PPM_ADMINISTRATOR Rachael Flynn Yes Yes Yes Yes Yes Yes
The administration team will be

defaulted onto every project via a
template as they will need access to
the data in case of questions. It is
important that they can see all data as
they will need to answer perhaps
questions on the behaviour of the
system.
The screen shot below displays how each Username is assigned rights on a Portfolio Item.
The table below illustrates how this will be configured at <Client>. This would be typical for a Portfolio
Item.
Role Example None Admin Write Read Person Inherited
Name Responsible from
Programme Enri-K Yes Yes
Manager Salazar
Global Rachael Yes
Operations Flynn
Administration
Business Unit Eric Veere Yes
Manager
CEO Niall Yes
Norton

If <Client> have a query concerning the system and need IBM AMS (support) team to investigate the
behaviour, they will raise an AMS ticket or issue. It is most likely that the IBM team will require access
to the data in order to diagnose the problem. This access can be granted by the
Z_PPM_ADMINISTRATOR (e.g. Rachel Flynn) at this point. There are other options e.g. that an IBM
generic Username is attached to every single Project. These details can be documented and agreed
as part of the post go-live support strategy and AMS procedures.
It should be also noted that the PPM project has the ability to define a group of people and then grant
access to this group directly and thus indirectly to the people in the group.
13.4 Portal Authorisation

There is a third aspect of the authorisation that needs to be correctly in place before the person can
successfully perform transactions within PPM, for example, enter a timesheet. This authorisation is
portal authorisation which governs how the screens are displayed for each person.
In the SAP PPM Portal, the following “Portal Roles” control what each user can access via tabs.
Recommend assigning all Portal Roles to all whom have any access to PPM. Read / write authority
can be attributed to control further using other authorisation devices i.e. the composite roles in the
table above.
In SAP PPM each role (see left column) is also configured using this table. We recommend keeping
the configuration here the same as standard. See the table below the screen shot for <Client> related
information on how these are mapped to the <Client> organisation.
How
Views when accessing cProjects ROLE applied in
<Client>
SAP_CPR_DECISION_MAKER Regional Z_PPM_PORTFOLIO_MANAGER
Vice
President,
“C” Level ,
Executive
SAP_CPR_INTERESTED FIN, HR, Z_PS_ACCOUNTING
Read-only
SAP_CPR_PROJECT_LEAD Program Z_PPM_PROJECT_MANAGER

Manager,
My project
only
access
SAP_CPR_RESOURCE_MANAGER Program Z_PPM_RESOURCE_MANAGER
Manager,
Global
Ops
SAP_CPR_TEMPLATE_RESPONSIBLE Global SAP_CPR_TEMPLATE_ADMINISTRATOR
Ops Admin
As a design principle we will not use these portal mechanisms to control authorisation. We will use the
other mechanisms.
14. WORKFLOW AND DASHBOARDS
The SAP workflows that are part of the system are listed in the table below.
Soft Hard Booking Workflow
Timesheet Approval
Project Release
Project P&L Approval
Project Closure
Holiday Approval
There is a requirement that dashboards are required to accompany any emailed workflow as this is
how <Client> typically operates. There are dashboards (screens or reports) that accompany each of
the above workflows related to the PPM solution. The SAP workflow system has a Workplace
dashboard (transaction) that collects and groups all workflow items according to their type (e.g. Soft-
hard booking, Project Closure). People who are responsible for Soft-hard booking and Project
Closures can delete or ignore all emails sent to their MS Outlook but access the Workplace
transaction and view all of these items in this screen. The screen shot below illustrates how this
screen can be used to action these items after ignoring or deleting the emails.

Figure 41 Even if the workflow emails are deleted the manager can access his workplace and
action Workflows from this screen.
The following paragraph will explain how the project release, approval and closure emails will operate
using decision points, phases and status. This will be a more detailed description than is written in the
section 1 above.
The example used in this case is the closure of the project.
1. The following data structure is needed to support the process.
Figure 42 The data structure of a project, item and decision point

There is a bucket with a Portfolio Item. There is one project associated with the portfolio item. The
portfolio item has two decision points that have been linked to the two phases in the associated
project. The decision points work together with the phases. The tasks are linked to the phase in
this illustration above.
2. The project manager decides that the project is finished and the closure workflow is to be
initiated.

3. The project manager goes into the approval screen within the phase of the project and checks
that the decision makers are correct. These will be defaulted from the template. The screen
below shows how the project manager checks the decision makers. IN our process there will
be two approvers the CEO and the Business Unit manager, who both approve before the
project can be Closed. The below screen shot shows one decision maker not the two.
4. The decision point is released within the Portfolio Item object next. The screen below
illustrates how this is carried out.

5. The approval is generated and is sent to the Approval Dashboard of the approver. An email is
not sent in this case.
6. The approver logs into the Approvals Dashboard and sees the pending approval.
7. The approver clicks on the approval to view the approval required.

8. The Approver presses the Grant Approval Button. This is not illustrated in the screen above.
After pressing the Grant Approval button the fields (Decision Maker, Password) illustrated
above are shown.
9. The approver re-enters their password into the password field and presses OK. This grants
the approval.
10. The same process as detailed here is carried out for the CEO who also approves the same
decision.
11. When both CEO and Business Unit manager have approved the closure, the Phase closes
and no more time can be booked to the Project.
12. The subsequent phase ‘Project Closure and Bonus’ is released.
13. A workflow is sent to the Global Operations and sits in the Workplace inbox to inform them
that the actions required to close the project should be undertaken. For example, the
BusinessOne codes can be closed down as the last and final phase has started.
15. DATA MIGRATION
The following section will outline the data migration solution that will be deployed to support a go-live
in the PPM module.

The data migration volumes and approach can be refined in realisation but this section will outline the
approach based on workshops in the blueprint phase.
The data migration approach is influenced by when the cutover would take place. The assumption for
this section is that the cutover will take place in 2013 Q1 or Q2.
There are some standard tools supplied by SAP to import the PPM data. The team will endeavour to
use these standard tools where possible.
There are some systems in the <Client> business that can be used as source systems for the data,
however, it was agreed that cutover should consist of data re-creation as this will be faster and will
serve as an ideal practice on the system for Programme Managers prior to go-live.
The following table will outline the Data Objects that we intend to load into the system as part of the
Data Migration exercise. The comment column in the table provides a narrative on the proposed
approach and reasoning.
Data Object Mod Import Load Type Comment Volume
ule
InfoType 0024 - HR IBM HR Program Auto There are over 1000 1000
Qualifications employees and contractors
so it is best that we use an
automatic import program.
The data will be gathered
from the spreadsheets
compiled by HR on the
disciplines and jobs
attributed to every person in
the company.
InfoType 0315 - HR IBM HR Program Auto The timesheet default value 1000
Timesheet Defaults is the same for every person.
There are 1000 people so an
automatic upload is
appropriate.
InfoType 0105 - HR IBM HR Program Auto There are 1000 records to 1000
Communication for import so an automatic
ESS program is appropriate.
The source of this data will
be the SAP Usernames, MS
domain names for each
person and the Employee
numbers.
Project Authorisation PPM SAP Standard Manual The permissions deployed to 75
- PS and PPM people in the system will be a
manual data entry exercise.
Project Templates and PPM Global Ops Manual There is no equivalent legacy 10
Checklist Templates system with template data.
Furthermore the templates
will be built in a way that
drives very SAP processes. It
is best that these are typed
into the system.

Portfolio Items PPM Program Manual There are a low number of 260
Managers Projects and it is best that
these are typed into the
system.
Planned Revenue PPM Program Manual The forecasted revenue will 1000
Managers be typed in by the
appropriate programme
manager.
Planned Costs PPM Program Manual The forecasted cost will be 1000
Managers typed in by the appropriate
programme manager.
Role Types with PPM Global Ops Configurati This data is configuration so it 800
Blended Rates - on can be created once and
Possibly Manual due transported up the systems.
to dependency on
historic timesheets There is a program built to
calculate these rates but this
algorithm would require the
old timesheets so it is not
possible to use this program
to generate the rate values.
It is best to type these in as

these calculations have been
already calculated in legacy
systems.
The list of Role Types will be

about 200. This is small
enough to type into the
system.
One-Task Projects and PPM Program Automatic There are a large number of 1000
Project Roles Managers Projects and it is best that
these are imported into the
system.
Projects with Phases, PPM Program Manual There are a low number of 260
Tasks and Checklist Managers Projects and it is best that
Items these are typed into the
system.
General Ledger FICO SAP Standard Manual There are only 10 of these so 10
Accounts they will be typed into the
system.
General Ledger FICO SAP Standard Manual There are only 10 of these so 10
Accounts Balance they will be typed into the
system.
Exchange Rates FI Finance Automatic There is an automatic upload 50
program to enable the
upload of exchange rates.
Background Jobs BC BASIS Manual These will be typed into the 50
system by the basis
administrator.

Business One - FICO Interface Interface There will be an interface in 10000
Expenses and (RFBIBL01) place to upload this data.
revenues
When we cut over the system
the initial time this interface
runs it will supply all revenue
and non-labour costs.
Journyx Timesheet PPM ABAP Auto The previous timesheets after 1000
Group to Project Load the 01-Jan-2023 and prior to
go-live will be loaded.
It is possible to load every

single timesheet entry or else
summarise these old
timesheets and post only the
summaries.
Regardless of the level of

detail loaded there will be
more than 1000 entries so an
automatic import is advised.
Resources to Task PPM Program Manual There is a bespoke program 1000
Assignment Managers that will enable assignment
quickly based on the Journyx
data structure. This could be
used to quickly ensure that
people can enter timesheets
on the first day of go-live.
The correct capacity demand

and cost profile will need to
be input so that WIP and
capacity management will
function correctly.
As part of the two-weekly

update of the project that
programme manager will
update the assignment and
the forecasted hours for each
of these people.
Resource Allocation - PPM Interface Interface There is an interface that 1000
Start Interface supplies the ERP CATS
timesheet system with the
data from PPM.
Timesheets - CATS HR ABAP Auto The data object represents 120000
inception to start of the timesheets from the start
year Values of the project to the start of
the year.
These values might be

required to correctly
compute the actual cost of
the labour costs.
Further analysis is required in

this object as it might be
sufficient to enter the EUR
balance for these actual costs
at go-live. This is because the
legacy hourly rates would
change historically and it
might be difficult to source
this data.
Business Partner - PPM Interface Interface This interface when started 1000
Start Interface will synchronise the HR
Employee Master with the
Business Partner and PPM
Resource.
Business Partner - PPM Global Ops Manual 50
Un-hired A manually created Business
Partner represents a soon-to-
be hired HR employee. It is
possible at go-live that a few
new hires will need to be
created.
Usernames - All Users BC Global Ops Auto There will be over 1000 1000
usernames required in the
system.
These will be automatically
imported.
The source of this data will
be the MS domain names in
<Client> and the HR masters.
Business Partner - FICO Accounting Manual There is a field in the HR 50
vendors Employee master to indicate
the contractor’s agency.
This is used for information
purposes.
This field is available as part

of the HR go-live One and so
can be updated manually if
this data is required.
This data is not required for

any of the PPM processes as
the PPM is not used to pay
the contractors.
Business Partner – FICO Accounting Manual There will be a few entries 138
Customers required to represent the
Sold To Sold To and Customers in the
system. These are few and
will be entered manually.

Figure 43 Data Objects migration approach
The above table has outlined the data migration approach for each of the objects above. During
Realisation further analysis will be required to perform a field-to-field mapping between the new
system and the legacy systems. This level of detail is not required for a Blueprint document.
16. BESPOKE DEVELOPMENTS
The following table outlines the bespoke developments that are required.
Object Change Category Title Reference
ID Request
ID
ENH001 2 CATS Overwrite the activity type rate with the salary 2.2.9 Planning
based hourly rate stored in Infotype 315 upon Rate
timesheet submission. The hourly rate would Structure
be calculated based on employee salary and
stored in an Infotype 315 of the Employee in a
separate development. ( Ref
ENH002 7 CATS Enhance the CATS timesheet tool to 5.2 Timesheet
automatically book time and cost to an Developments
overhead project when absence is booked by
an employee.
ENH003 9 CATS In order to allow timesheet booking by 5.2 Timesheet
employees not allocated to a project, enhance Developments
the CATS timesheet tool to include "Group
Work-list" functionality.
REP002 9 CATS Build "Group Work-list" maintenance 5.2 Timesheet
application which would be used by Developments
administrators to create and delete
assignments of employees.
ENH004 9 CATS Add Filter functionality to CATS work-list screen 5.2 Timesheet
for easy search of Items. Developments
ENH007 14 CATS Add "Task Code" field to the CATS timesheet 5.2 Timesheet
item which would help in reporting, in a similar Developments
manner to Journyx.
These will be a list of valid values defined
centrally.
ENH009 CATS Custom development to add Approval 5.2 Timesheet
functionality to CATS timesheet using Developments
workflows. The Project Manager would be
required to approve the timesheet to book costs
to a project.
REP001 5 A bespoke program to calculate the hourly rate 2.2.9 Planning
of employees based on salary and update Rate
Infotype 315 with the calculated rate. This rate Structure
would be used while booking timesheet costs to

the project.
ENH010 10 Ensure HR Job consistent with Role Type using
enhancement.
ENH005 11 Customize "Role Type" filter/search in the 9.1 PPM HR
"Create Role" screen to allow easy search of Integration
role types. This should enable search of Role
Type based on Rate type, Rate etc…
ENH006 12 PPM Add various custom fields to Portfolio Item 4.2
ITEM including margin, margin %. Requirements,
The bespoke development will calculate: Section 1
- Margin (based on the <Client>

margin formula)
- Margin % (based on the
<Client> margin% formula)
The bespoke development will calculate these
statistics over the following periods:
- Initiation to Date (ITD)
- Year to Date (YTD)
- At Completion (AC)
ENH008 6, 17 WIP Predicted WIP calculation for each month Section WIP Calculation
between now and the end of the project for
each project.
The revenue elements and cost elements will
need to be forecasted by month in order to
calculate the WIP correctly as this algorithm
requires the month on which the billed revenue
is registered and associated costs.
INT004 B1 INTF Interface between SAP Business One and ECC Section Value
to transfer projects costs & revenues to PPM Flow
INT001 PPM - CATS ALE Integration (Business Partner Section Value

) Flow
INT002 PPM - CATS ALE Integration (Qualifications). Section Value

Flow
INT003 PPM - CATS Accounting Integration Section Value
Flow
ENH011 BADI to override default Project Profile
ENH012 - - An upload program to mass upload the Project T5.2 Timesheet
Groups, Task Codes and users into the new Developments
journyx functionality in SAP.
ENH013 - - WIP calculation archiving functionality and Section WIP Calculation
restore functionality of this archive
ENH014 - - Billability% field on the resource is needed for Resources-Status-
the report “Resources-Status-Combined.pdf” Combined.pdf

17. TERMS AND DEFINITIONS
The following are standard definition that may help understand specific object, process, data
groupings, controls, and general terminology used in this document and other material related to SAP
PPM and other applications.
PPM Portfolio Management is SAP’s Project and Portfolio Management application and contains
PORTFOLIO BUCKETS (structure to store and present Portfolio Items) and PORTFOLIO ITEMS
PPM Project Management is SAP’s Collaboration Projects application which contains PROJECTS
with Phases, Tasks, Activities, Roles and Resources
PS – is SAP’s Project Systems application which is part of FI/CO, and contains PS PROJECTS but is
integrated with PPM Project Management Projects and PPM Portfolio Management Portfolio Items
Portfolio Item – Refers to the header and administrative level of a project. Portfolio Items are visible
in the system from a Portfolio Dashboard (each as one line item). The Portfolio Dashboard provides a
view where the health status of the project in terms of staffing, scheduling and budgeting by traffic
lights is visualized. There is a one-to-one relationship between Project and Portfolio Item.
Project – Refers to project structure level supporting phases, activities, roles, resources, and
accounting interface (think: MS-Project Project)
PS Project – Refers to Cost Collector by project used by FI/CO and PPM and contains WBS
Elements by Project
Item/Project ID – the external identifier that definitively defines one and only one project using this
alpha numeric field. May be automatically generated or entered manually. PPM required that Item,
Project, and PS Project are identical.
Portfolio Bucket – Refers to a strategic (and usually operational as well) collection of portfolio items
(and associated project definitions) that usually represents a planning, managing, and monitoring level
in the enterprise portfolio
We have aligned these to the reporting structure in <Client>. The Business Unit managers have a
portfolio bucket under their responsibility.
Portfolio Bucket Rollup – Refers to the capability of SAP PPM to send costs, (WIP and billed)
revenue, and capacity demand up through the Portfolio Hierarchy aggregating totals of like objects
together.
The solution will rollup project and portfolio item costs and revenue when the item status is released.
The rolled up values will be seen on the portfolio buckets.
Decision Point – Refers to what is essential a project phase and supports tracking execution of that
phase and its phase completion and phase approval
Stage-Gate – Refers to a project phases within SAP PPM/Projects that are tied/linked to decision
points (PPM/Portfolios) and represent the point at which approval, review, and/or authorization are
required to continue work or proceed to the next set of tasks
Reviews – an object within PPM that supports routine and adhoc review of specific projects and
initiatives regardless of Portfolio Bucket and independent of decision points as well (usually periodic
or a project/item on the “watch list”).
Dashboards – Are used throughout SAP PPM to show status and information each object displayed.
This includes health indicators, cost/revenue, headcount, start/end dates and all for both planned and
actuals. It is customizable by individual, can be filtered, sorted, and saved. It provides “clickable”
access to the data it reflects (e.g. projects, decision points, buckets).
Status Network – Project, Item, Decision Points, Stage-Gates, and other objects have statuses which
can be used to trigger workflows, decision tree logic, links between objects, approvals, and other
actions/behaviours.

Initiative – [Out of Scope] an object within PPM that function as a portfolio item and then can accept
projects assigned to that initiative to provide an association between projects associated with that
initiative (purpose)
Category/Sub-Category – used to filter projects and reporting analytics to group projects by purpose,
characteristics, ownership, or responsibility.
Technology Type – like Category / Sub-Category, Technology type is an assignment to a grouping of
projects related to the tools or skills required with the best IT example being UNIX, ABAP, DB2, MS
Server.
Item/Project Type – involves defining a set of controls, defaults, and characteristics of Items and/or
Projects to support both flexibility across a project portfolio and be able to specify business rules and
rigor to each item/project definition (i.e. short term project, support, long term, SAP)
Templates – supports the capability to predefine items and projects with default data, phases, role
assignments, durations, etc. for defining new items and/or projects.
Financial Planning – functionality in SAP PPM that provides time phased representation of data that
has been entered in RPM manually, rolled up from lower level portfolio buckets and from individual
projects, or brought back from R/3 FI/CO and displayed (FI/CO is single source of truth) for managing
projects.
Financial View – are the individual “types” of costs that tracked in each project and aggregated up
through the portfolio structure. Typically financial views are Actual Costs, Planned Costs, Forecast
Costs, and Estimated Costs. They can be defined to be entered manually or to reflect cost data in
FI/CO application.
Financial Group – within each Financial View there can be a higher level grouping of costs which
might be Capital, O&M (expense) or grouping of costs by Labour, Material, Travel or grouping of
expense by internal, external.
Financial Cost Categories – within each Financial Group, the use of Cost Categories depending
upon financial needs might typically be Internal Labour, External Labour, Hardware, Software, Travel,
and Misc. This depends upon how financial information is defined and the capability to maintain that
information.
PPM Financial Reporting Cockpit – real-time functionality that is used evaluate and plan projects
within portfolios based on data within PPM or returned from the FI/CO system using various charts
and tables.
PPM Financial Governance – is the process of distributing target dollars (or allocation of funds)
down through a portfolio bucket structure to help establish a goal for both “funded” projects/items and
“non funded” projects/items. Once distributed, planned and target totals from each level roll up to
monitor compliance and/or trends within the governance model.
PPM Financial Data Transfer – is the mechanism for the collection of financial data from FI/CO (PS
WBS) objects and displaying them in predefined PPM Financial planning categories and views. This
data can also be rolled up through the portfolio structure and used in PPM Reports and Analytics plus
used for metric reporting and alerts.
PPM Financial Data Roll-up – mechanism that aggregates financial data from one level of a portfolio
structure and/or projects and displays at each level up through the structure.
Project Role – applies to a specific project and describes the skills, duties, expectations of a yet
unassigned resource to a task or tasks in the project. It does not necessarily reflect the kind of
resource “role type” designated to fill that project role.
Role Type – designates further how a “project role” can be filled with a specific talent, expertise that
can be associated eventually to a resource or multiple resources to fulfil the project role on a specific
project. It should be noted that this table entry holds planning rates for both a cost and expected
revenue as assigned to that role. This can be made sensitive to a date range, type of resource
(employee vs. contractor), AND High-Medium-Low rate schedule. Organization can be configured to
drive a specific planning rate within a “role type”.
Demand – is the term applied to the level of effort by “project role” in regards to a project, phase or
task as expressed in hours, days, weeks, or months to be associated with a “role type”.

Allocated – is the term applied to the number of hours, days, weeks, or months of an actual
resource being “assigned” (allocated) to that project role. This may be a generic “resource to be
named later”. That usually indicates a commitment to hire/acquire a specific resource for to fulfil the
“project role” assignment.
Business Partner – is the SAP Application (transaction BP) that is populated with information from
the HR system and is treated as a mini master and can have optional data structures (e.g. Skills
catalogue, availability information) associated with it.
Reports and Analytics – is an application that is tied to a package such as SAP PPM and provides
ready to use reports (“standard”) and provides the ability to modify and save new versions (uses BEX
engine). Security/access is built into design streamlining reporting.
Item/Project Versioning – basic functionality that allows a version to be copied, changes made, and
released to replace current version. Used to apply change requests or make adjustment to a project
and its forecast/planned data. Used for more than just minor adjustments to resourcing and tasking.
Item/Project Simulation – basic functionality that allows usually more than one project (usually a
portfolio) to be pulled into a multi-project plan and making changes to the simulation model such as
delaying projects, shifting demand to match resource availability, re-prioritization.
Item/Project Baseline – basic functionality that recognizes the desirability to capture a copy of a
project as it is released for execution or approved for execution. There are additional functionality that
exists for comparisons to baseline as project are changed (minor) or versioned. Re-baselining is
usually a process of creating a version, getting full approvals and capturing the baseline for
comparison to the new project.
Calendar (Factory Calendar) – is defined in SAP ERP modules to specify a calendar for each
Area/Location (or down to the factory level) to provide a schedule for each country or controlling entity
and can specify a complete work days (and shifts) reference showing all defined holidays in reference
work project planning. Projects can build their own calendar to match a customers work schedule for
that location.
CATS – SAP’s “Cross Application Time Sheet” application that can receive a project member’s
authorized “work-list” items to charge against and returns both hours and activity information to
charge the appropriate project WBS Cost Element and task.
SAP GUI – is the “classic” version of SAP which is a transaction base suite of hundreds of
transactions, most designed as “CRUD” (create, read, update, display) transactions.
SAP NetWeaver Portal – is radically different as it is a web based technology with many SAP
functions built into the engine itself. (e.g. Universal Work-List). SAP Enterprise Portal is another layer
of functionality/capability. Security is not SAP Classic and a browser is required.
Customization – is the term applied to adding or changing functionality. Most common is adding user
defined fields, modifying built in “User Exits”, changing formulas. All changes are subject to the impact
of new releases an service packs (“do-overs”). Plus customization can impact performance, data
accuracy, and support (caution).
Configuration – is the term applied to setting table entries and master data up in such a way that the
application behaves as required to meet requirements (within application design constraints).
ABAP – is SAP’s programming language required for applying custom changes.
Portal Page – Refers to a group of iViews (screens) running under a portal. Each page is usually
attached and navigated via Portal Tabs, Application Tabs, Action Buttons, or a navigation panel.
iView – is a more technical term for what is commonly called a “web page” or “screen”.
Tab – is a common term used for a navigation element for selecting web pages and iView/screens.
Navigation – PPM has a web interface and provides side panels and top panels with buttons that
open up or transfer to another “web page”.
The following paragraphs provide some explanation of the SAP data structures and the master data
design for the solution.

The diagram below conceptually outlines how an <Client> SAP Portfolio is constructed with Portfolio
Buckets and Portfolio Items. There are many-to-one links between items and buckets. The entire
hierarchy is made up of a series of buckets. There is a one-to-one relationship between the Portfolio
Item and the PPM Project. The Project is made up of phases which really govern when the project is
released, approved and closed. There is one phase that contains the SAP Tasks. The decision points
link the phases to the Portfolio Item for a technical reason.
Figure 44 Conceptual view of the relationship between buckets, items and Projects, Decision
Points, Phases and Tasks
The following screens illustrate the relationships outlined above.
Figure 45 the portfolio is made up of a hierarchy of portfolio buckets

Figure 46 each portfolio bucket is made up of a list of portfolio items
Figure 47 There is a link between the Portfolio Item and the PPM Project. In our design this is a
one-to-one link. The user can access this Project from the Menu option highlighted.

Figure 48 the link between Phase and Decision point is a technical one and shown on the
Portfolio Item.
Figure 49 There is a one-to-many link between the project and the phases. There is also a one-
to-many between the tasks and the phases. The link back to the portfolio item is also shown in
the Project
The financial and capacity values are rolled up the hierarchy based on the Status. The Released
status will cause the roll-up. The Released status is analogous to the 50% in the RevRes. When the
project is ‘Closed’ the roll up will stop as the portfolio will only contain currently live projects.
This will enable Business Unit mangers e.g. Eric Verre can see his figures up to the EMEA level, and
be able to see cost/revenue for overall EMEA.

18. SAP TERMINOLOGY AND INTEGRATION
The SAP PPM Blueprint will be configured in conjunction with the SAP HCM blueprint. The following
table includes the definitions required to understand the main entities within the SAP HR module.
SAP Term Explanation

Company Code This is a standalone legal entity. The official definition is: Smallest organizational
unit of external accounting for which a complete, self-contained set of accounts
can be created. This includes the entry of all transactions that must be posted
and the creation of all items for legal individual financial statements, such as the
balance sheet and the profit and loss statement.
Personnel Area The Personnel Area is a subset of the company code used to group personnel in
a meaningful way. The official definition is: The personnel area is an
organizational unit that represents a specific area of the enterprise and is
organized according to aspects of personnel, time management and payroll.
Personnel Sub Area This is a further subdivision of the Personnel Area. Within <Client>, we have
mapped this to the departmental structure. The personnel area is an
organizational unit that represents a specific area of the enterprise and is
organized according to aspects of personnel, time management and payroll.
Employee Group This is the primary subdivision of personnel and allows the system to distinguish
between the various types of employee and the various types of contractor.
Employee Sub-Group The employee subgroup is used to group personnel by their pay frequency –
Daily / Weekly / Monthly / etc.
Personnel Number Each employee and contractor will be represented by a unique personnel number
within SAP. When Personnel are integrated into the PPM (Projects) module of
SAP, they are referred to as a 'Business Partners' or 'Resource'.
Organisation Units Describes an <Client>'s distinct Business Units such as geographical regions,
countries, departments and sub-departments.
Job Families A high level grouping of jobs within the company such as technical,
administrative, or programme management. SAP has a concept of a job family
that maps to the same concept within the <Client> Career Framework. The exact
Job Families that are loaded into SAP will be supplied by the <Client> Career
framework exercise.
Jobs Jobs are general classifications of individuals within <Client> based on the nature
of the role that the individual performs, their market rate, level within the
organisation, and their alignment within the <Client> Career Framework.
Discipline A Discipline is an attribute of a job such as ‘Tester’. SAP does not have this
concept in the standard system but IBM will extend the attributes of a job to
include ‘Discipline’.
Positions A position is a specific occurrence of a Job, occupied by one individual, and can
be vacant. As such, each job will have multiple positions, and each position can
have one person assigned at any given time.
Infotype An infotype is a screen within SAP HR that holds data related to an individual.
Similar or related data-points are grouped into infotypes. For example: an
individuals name, date of birth, marital status, PPS Number, Gender, Nationality,
etc. are all located on the Personal Data infotype.

Wage Type Wage Types are pay elements related to an individual. These can be payments
suns as salary and bonus; or deductions such as pension contributions.
Absence Type Absence Types are used to differentiate between the different reasons why an
individual may be absent from work.
Absence Quota Some absences have a quota which is an allowed number of hours or days that
can e taken in a specific period. Within <Client>, the quota concept ha been
applied to Vacation and Sick Leave for most jurisdictions. Quotas can be granted
at the start of a vacation year (such as annual leave in Ireland); or can be
accrued /earned (as with vacation in US).
Activity Type An activity type is the entity that holds the planned (blended rate) for an
individual. The cost planning functionality of the financial modules will determine a
set of blended rates appropriate for <Client> project planning and assign them to
individuals via their HR record. The Activity Type will be aligned to the 'Job' and
'Organisation Unit' assignment of the individual.
The following is an example Activity Type for an employee from Malaysia who is a
Tester and has achieved the level of Advanced Engineer.
‘AE’ ‘T’ ‘MY’ ‘E’

Qualifications The Qualifications catalogue used record qualifications / competencies / skills /
Catalogue etc. against an individual. Qualifications are typically grouped in a meaningful
manner to facilitate separation from a data management point of view. For
example: some qualifications will be managed within the HR function and other
qualifications will be self-managed by the individual.
The third usage for the qualifications catalogue is to facilitate integration between
the SAP HR module and the PPM module. As the qualifications catalogue
associated with an individual is copied to PPM, <Client> will create a special
qualification (called ‘Role Type’) that enables intelligent search functions when
looking for project resource. The ‘Role Type’ qualification will be derived based on
the 'Job', ‘Discipline’ and 'Organisation Unit' (location), and Employee Group
(Employee / Contractor) assignment of the individual.
The following is an example Role Type Qualification for an employee from
Malaysia who is a Tester and has achieved the level of Advanced Engineer.
‘AE’ ‘T’ ‘MY’ ‘E’

PPM Role Type A PPM Role type is used to describe the type of resource required to perform a
project task. This role type is essentially an unnamed generic resource used for
planning purposes until a suitable living resource can be identified and assigned
to the project task. Within <Client>’s usage of SAP ERP and PPM, we will align
the PPM Role Type to the HR Role Type Qualification and default Activity Type.
As such the PPM Role type will have a blended rate derived for all the personnel
allocated to the same Activity Type and Role Type Qualification.
The following is an example Role Type that represents employees from Malaysia
who are Testers and have achieved the level of Advanced Engineer.

‘AE’ ‘T’ ‘MY’ ‘E’
CO Controlling
This is a module that performs management accounting processes in the SAP
system.
Profit Centre Organisation Unit object for which a Profit and Loss statement can be made.

PPM BluePrint

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PPM BluePrint

Caricato da

Copyright:

Formati disponibili

<CLIENT> SAP PPM Blueprint Document

Date: 02 November 2012

Address and Tel No.

3. Commercial Lifecycle Structures....................................................32

5. Resource Planning Process...........................................................42

16/10/2019 Commercial in Confidence Page 2 of 163

6. Timesheet Confirmation Process....................................................54

8. Change Requests and Reforecast..................................................78

10. HR PPM Integration........................................................................86

16/10/2019 Commercial in Confidence Page 3 of 163

12. Base Configuration settings..........................................................121

16/10/2019 Commercial in Confidence Page 4 of 163

14. Workflow and dashboards............................................................144

16/10/2019 Commercial in Confidence Page 5 of 163

Version Issue Date Authors Comments

Draft Signoff Sheet

16/10/2019 Commercial in Confidence Page 6 of 163

16/10/2019 Commercial in Confidence Page 7 of 163

2. OVERVIEW – PROJECT AND PORTFOLIO MANAGEMENT

2.1 Services Commercial Lifecycle

Figure 1 <Client> Commercial Lifecycle Overview

16/10/2019 Commercial in Confidence Page 8 of 163

Forecast RevRes Overview – Project and Portfolio Management, Service

Forecast RevRes Overview – Project and Portfolio Management, Service

16/10/2019 Commercial in Confidence Page 9 of 163

16/10/2019 Commercial in Confidence Page 10 of 163

2.1.1 OPPORTUNITY IDENTIFIED

2.1.2 OPPORTUNITY QUALIFIED

2.1.3 HIGH LEVEL ROM

16/10/2019 Commercial in Confidence Page 11 of 163

16/10/2019 Commercial in Confidence Page 12 of 163

SAP Phase to enable the use of decision

Figure 4 Project Structure showing the four phases

16/10/2019 Commercial in Confidence Page 13 of 163

<Client> Project Phase

16/10/2019 Commercial in Confidence Page 14 of 163

SAP Phase to enable the use of decision

16/10/2019 Commercial in Confidence Page 15 of 163

Figure 7 Portfolio Cost and Revenue Categories

16/10/2019 Commercial in Confidence Page 16 of 163

Figure 8 <Client> Services Margin Calculation

16/10/2019 Commercial in Confidence Page 17 of 163

16/10/2019 Commercial in Confidence Page 18 of 163

2.1.4 DETAILED ESTIMATE

16/10/2019 Commercial in Confidence Page 19 of 163

Figure 9 Portfolio Cost and Revenue Categories

16/10/2019 Commercial in Confidence Page 20 of 163

2.1.5 FINAL CONTRACT

Figure 10 Approval dashboard

2.2 OPERATIONAL PLAN

16/10/2019 Commercial in Confidence Page 21 of 163

Note: Labour Costs will come from the project

Figure 12 Cashflow calculation on the Project based on Revenue and Cost

Cash Flow can be seen on a financial View

16/10/2019 Commercial in Confidence Page 22 of 163

Figure 13 Risks and Issues can be logged on a SAP Checklist

2.2.1 PROJECT CLOSURE

16/10/2019 Commercial in Confidence Page 23 of 163

2.2.2 PROJECT BONUS

2.3 Engineering Core Business Lifecycle

Figure 14 <Client> Product Management Backlog Lifecycle

16/10/2019 Commercial in Confidence Page 24 of 163

2.3.1 OPPORTUNITY IDENTIFIED (Product Management - Analysis)