Spaces:
Build error
Build error
| Project Concert | |
| BPD009 β Project Systems & Time Sheets | |
| Business Process Document | |
| 1.00 Baselined | |
| [Publish Date] | |
| BPD PS& TM | |
| Purpose: The objective of this document is to summarise the validated Concert Programme business processes for Project Systems and Time Sheets including: | |
| β’ Business scope and requirements | |
| β’ Site specific variations | |
| β’ Detailed business activity | |
| β’ High level roles and skills | |
| β’ Integration points | |
| β | |
| Scope: In scope are the key activities of Project Systems and Time Sheets including Project Creation, Project Templates, Budgeting, Project Execution, Cost Allocation, Time Sheet Management and Project Closing. The scope of the Project Systems and Time Sheeting workstream covers: | |
| β’ The Consolidation of activities from Agresso to SAP β this includes all activities of the JM Davy business plus moving the time sheeting for the RD&E business area to SAP | |
| β’ Implementation of Project Systems for the management of R&D activities in line with the move of RD&E business time sheeting moving from Agresso to SAP | |
| β’ Implementation of Project Systems for the management of Formox Plant Designs and move of this business to the use of time sheeting in SAP | |
| β’ Other parts of CT will continue to use Internal Orders/their current processes for managing project type activities such as CAPEX projects. | |
| Summary: | |
| All Project Systems and Time Sheeting processes in the defined business areas (JM Davy, RD&E, Formox Plant Designs) will be done on the Concert SAP system by the roles involved e.g., project manager, customer services etc., with interaction with the other roles e.g., finance, estimating etc. and the Master Data Team. Some processes will continue to take place out of the system using tools currently in place such as KeyedIn, Primavera, Excel. | |
| Document Information | |
| Document Name Project Systems & Time Sheets Business Process Document | |
| Last Saved 06/06/2022 16:07:00 | |
| Printed NAMonday, 06 June 2022 | |
| Author(s) Marco A. Desentis, Carl Scarlett | |
| Business Owner Carl Scarlett | |
| β | |
| Contents | |
| 1. Document Control 8 | |
| 1.1. Authors 8 | |
| 1.2. Change History 8 | |
| 1.3. Approvers 8 | |
| 1.4. Reviewers 9 | |
| 1.5. Distribution Information 10 | |
| 1.6. External References 10 | |
| 1.7. Related Business Process Documents 11 | |
| 1.8. Glossary 11 | |
| 2. Introduction, Purpose and Scope 13 | |
| 2.1. Document Purpose 13 | |
| 2.2. Document Scope 13 | |
| 2.3. Document Architecture 13 | |
| 3. Business Context 14 | |
| 3.1. Concert Programme Vision 14 | |
| 3.2. Design Principles 15 | |
| 4. Design Scope 17 | |
| 4.1. Business Process Framework 17 | |
| 4.2. Organisation Process Hierarchy 18 | |
| 4.3. Concert Deployment Context / Scope 18 | |
| 4.4. Process Area Scope 18 | |
| 4.4.1. Process Areas - In Scope 18 | |
| 4.4.2. Scope Items β In Scope 20 | |
| 4.4.3. Process Areas - Out of Scope 20 | |
| 4.5. Site Related Scope 20 | |
| 5. Detailed Design 24 | |
| 5.1. Level 3 & 4 Business Processes 24 | |
| 5.2. Level 3 Business Area β 08.01.01 Maintain Project Definition & Structures 25 | |
| 5.2.1. Process: 08.01.01.01 Develop Project Policy and Procedure 25 | |
| 5.2.2. Process: 08.01.01.02 Create and Maintain Projects 27 | |
| 5.2.2.1. Level 4 Process Flow and Steps 29 | |
| 5.2.2.2. To-be Changes 32 | |
| 5.2.2.3. Site Specific Changes 33 | |
| 5.2.3. Process: 08.01.01.03 Project Template and Master Data Maintenance 33 | |
| 5.2.3.1. Project Templates 34 | |
| 5.2.3.2. Project Template for Licensing 34 | |
| 5.2.3.3. Project template for Licensing Proposals 38 | |
| 5.2.3.4. Project template for Formox Plant Designs 38 | |
| 5.2.3.5. Project template for R&D KeyedIn Projects 39 | |
| 5.2.3.6. Project Structures for βday-to-day" activities 40 | |
| 5.2.3.7. Level 4 Process Flow and Steps 42 | |
| 5.2.3.8. To-be Changes 44 | |
| 5.2.3.9. Site Specific Changes 44 | |
| 5.3. Level 3 Business Area β 08.01.02 Perform Project Budgeting & Planning 44 | |
| 5.3.1. Process: 08.01.02.01 Perform Budget for Project Spend 53 | |
| 5.3.1.1. Level 4 Process Flow and Steps 54 | |
| 5.3.1.2. To-be Changes 56 | |
| 5.3.1.3. Site Specific Changes 56 | |
| 5.3.2. Process: 08.01.02.02 Perform Project Forecasting 56 | |
| 5.3.2.1. Level 4 Process Flow and Steps 58 | |
| 5.3.2.2. To-be Changes 60 | |
| 5.3.2.3. Site Specific Changes 60 | |
| 5.3.3. Process: 08.01.02.03 Perform Project Amendment (over/under) 60 | |
| 5.3.3.1. Level 4 Process Flow and Steps 62 | |
| 5.3.3.2. To-be Changes 63 | |
| 5.3.3.3. Site Specific Changes 63 | |
| 5.4. Level 3 Business Area β 08.01.03 Capture Project Costs & Timesheets 64 | |
| 5.4.1. Process: 08.01.03.01 Capture Project Related Costs 65 | |
| 5.4.1.1. Level 4 Process Flow and Steps 70 | |
| 5.4.1.2. To-be Changes 71 | |
| 5.4.1.3. Site Specific Changes 72 | |
| 5.4.2. Process: 08.01.03.02 Maintaining HR Mini Master 72 | |
| 5.4.2.1. Level 4 Process Flow and Steps 74 | |
| 5.4.2.2. To-be Changes 76 | |
| 5.4.2.3. Site Specific Changes 76 | |
| 5.4.3. Process: 08.01.03.03 Enter & Approve Time 76 | |
| 5.4.3.1. Level 4 Process Flow and Steps 82 | |
| 5.4.3.2. To-be Changes 85 | |
| 5.4.3.3. Site Specific Changes 85 | |
| 5.4.4. Process: 08.01.03.04 Time Administration 85 | |
| 5.4.4.1. Level 4 Process Flow and Steps 86 | |
| 5.4.4.2. To-be Changes 88 | |
| 5.4.4.3. Site Specific Changes 88 | |
| 5.4.5. Process: 08.01.03.05 Reporting for Time Sheets 89 | |
| 5.4.5.1. Level 4 Process Flow and Steps 93 | |
| 5.4.5.2. To-be Changes 94 | |
| 5.4.5.3. Site Specific Changes 95 | |
| 5.5. Level 3 Business Area - 08.01.04 Capture Project Revenue (Billing) 95 | |
| 5.5.1. Process: 08.01.04.01 Maintain Policy & Procedure for Revenue Recognition 95 | |
| 5.5.1.1. Level 4 Process Flow and Steps 97 | |
| 5.5.1.2. To-be Changes 98 | |
| 5.5.1.3. Site Specific Changes 98 | |
| 5.5.2. Process: 08.01.04.02 Billing for Revenue Projects 98 | |
| 5.5.2.1. Level 4 Process Flow and Steps 101 | |
| 5.5.2.2. To-be Changes 102 | |
| 5.5.2.3. Site Specific Changes 102 | |
| 5.5.3. Process: 08.01.04.05 Account Revenue Recognition 103 | |
| 5.5.3.1. Level 4 Process Flow and Steps 106 | |
| 5.5.3.2. To-be Changes 106 | |
| 5.5.3.3. Site Specific Changes 106 | |
| 5.6. Level 3 Business Area β 08.01.05 Project Monitoring 107 | |
| 5.6.1. Process: 08.01.05.01 Perform Project Reporting 107 | |
| 5.6.1.1. Level 4 Process Flow and Steps 110 | |
| 5.6.1.2. To-be Changes 111 | |
| 5.6.1.3. Site Specific Changes 111 | |
| 5.6.2. Process: 08.01.05.02 Perform Integrations with Project Management Tools 112 | |
| 5.6.2.1. Level 4 Process Flow and Steps 116 | |
| 5.6.2.2. To-be Changes 118 | |
| 5.6.2.3. Site Specific Changes 118 | |
| 5.7. Level 3 Business Area β 08.01.06 Project Month & Year End Close 119 | |
| 5.7.1. Process: 08.01.06.01 Results Analysis 119 | |
| 5.7.1.1. Level 4 Process Flow and Steps 120 | |
| 5.7.1.2. To-be Changes 122 | |
| 5.7.1.3. Site Specific Changes 122 | |
| 5.7.2. Process: 08.01.06.02 Perform Project Settlement 122 | |
| 5.7.2.1. Level 4 Process Flow and Steps 124 | |
| 5.7.2.2. To-be Changes 125 | |
| 5.7.2.3. Site Specific Changes 126 | |
| 5.7.3. Process: 08.01.06.03 Project Closure 126 | |
| 5.7.3.1. Level 4 Process Flow and Steps 127 | |
| 5.7.3.2. To-be Changes 129 | |
| 5.7.3.3. Site Specific Changes 129 | |
| 5.7.4. Process: 08.01.06.04 Project Year End Close 129 | |
| 5.7.4.1. Level 4 Process Flow and Steps 129 | |
| 5.7.4.2. To-be Changes 130 | |
| 5.7.4.3. Site Specific Changes 130 | |
| 5.8. Level 3 Business Area β 08.01.07 Project Reporting 131 | |
| 5.8.1. Process: 08.01.07.01 Project Commitments 132 | |
| 5.8.1.1. Level 4 Process Flow and Steps 133 | |
| 5.8.1.2. To-be Changes 133 | |
| 5.8.1.3. Site Specific Changes 134 | |
| 5.8.2. Process: 08.01.07.02 Project Revenues 134 | |
| 5.8.2.1. Level 4 Process Flow and Steps 134 | |
| 5.8.2.2. To-be Changes 135 | |
| 5.8.2.3. Site Specific Changes 135 | |
| 5.8.3. Process: 08.01.07.03 Project Costs 135 | |
| 5.8.3.1. Level 4 Process Flow and Steps 136 | |
| 5.8.3.2. To-be Changes 136 | |
| 5.8.3.3. Site Specific Changes 137 | |
| 5.8.4. Process: 08.01.07.04 Project Cash Flow 137 | |
| 5.8.4.1. Level 4 Process Flow and Steps 137 | |
| 5.8.4.2. To-be Changes 138 | |
| 5.8.4.3. Site Specific Changes 138 | |
| 5.9. Headline βTo- Beβ design changes 138 | |
| 5.10. Key Design Decisions 138 | |
| 5.11. Policies and Compliance 139 | |
| 5.12. Key Value Drivers 139 | |
| 5.13. Risk and Controls (to be completed by R&C Lead) 140 | |
| 5.14. Roles and Skills 140 | |
| 5.14.1. Business Role Change Summaries 142 | |
| 5.14.1.1. Business Role Finance 143 | |
| 5.14.1.2. Business Role Project Accountant 144 | |
| 5.14.1.3. Business Role Project Controller 145 | |
| 5.14.1.4. Business Role Project Admin 146 | |
| 5.14.1.5. Business Role Project Finance Admin 147 | |
| 5.14.1.6. Business Role Project Financial Controller 149 | |
| 5.14.1.7. Business Role Project Manager 150 | |
| 5.14.1.8. Business Roles Project Engineer/Lead Engineer/Planning Engineer 151 | |
| 5.15. Business, Functional and Non-functional Requirements and solution Design 153 | |
| 5.15.1. Business and Functional Requirements 153 | |
| 5.15.2. Non-functional Requirements 153 | |
| 5.15.3. Design Gaps 153 | |
| 5.16. Data Impact 154 | |
| 6. Risks, Issues, Actions and Dependencies 154 | |
| 6.1.1. Design Risks and Issues (outstanding) 154 | |
| 6.1.2. Design Related Actions 155 | |
| 6.1.3. Process Area Dependencies 155 | |
| 7. Appendix 156 | |
| 7.1. Segmentation 156 | |
| β | |
| 1. Document Control | |
| 1.1. Authors | |
| Author Role | |
| Marco Desentis Workstream Functional Lead | |
| Carl Scarlett Workstream Business Process Expert | |
| 1.2. Change History | |
| This version replaces all previous versions. Please archive any previous versions: | |
| Version Date Created / | |
| Changed Author Comments / Summary of Change | |
| 0.1 29/02/2022 Aninda Roy Initial Template | |
| 0.2 28/03/2022 Carl Scarlet Review of section 1 | |
| 0.3 29/03/2022 Marco Desentis Review | |
| 0.4 18/04/2022 Marco Desentis Review section 5 | |
| 0.5 12/05/2022 Carl Scarlett Version for SME review | |
| 0.5 12/05/2022 Uche Nnene Internal QA Review | |
| 0.96 13/05/2022 PMO In Review | |
| 0.97 19/05/2022 Carl Scarlett Review Updates | |
| 0.98 01/06/2022 Matt Allen Sending for Approval | |
| 1.00 06/06/2022 Matt Allen Marking record of approval and baselining | |
| 1.3. Approvers | |
| This document requires the following approvals: | |
| Name Signature Role Date of Approval Version | |
| Carl Scarlett PS/TM Business Process Expert - JM 06/06/22 1.0 | |
| 1.4. Reviewers | |
| This document requires the following reviewers: | |
| Name Role Date of Issue Version | |
| Marco Desentis PS/TM Functional Lead - EY 13/05/2022 0.96 | |
| Carl Scarlett PS/TM Business Process Expert - JM 13/05/2022 0.96 | |
| Ashley Anderson Projects & Engineering Director 13/05/2022 0.96 | |
| Jason Flynn Financial Accounting Manager 13/05/2022 0.96 | |
| Hooman Toosi Planning Engineer 13/05/2022 0.96 | |
| Alyse Giardini Senior Cost Engineer 13/05/2022 0.96 | |
| Dale Smart Business Support Manager 13/05/2022 0.96 | |
| Enrica Ippoliti Plant Upgrade Project Engineering Manager 13/05/2022 0.96 | |
| Jonas Lindborg Projektchef 13/05/2022 0.96 | |
| Carina Hugosson Financial Controller 13/05/2022 0.96 | |
| Gabriella Bicki Business Controller 13/05/2022 0.96 | |
| Mike Bainbridge R&D Director 13/05/2022 0.96 | |
| Jennifer Williams CT Portfolio Manager 13/05/2022 0.96 | |
| Jo Huby KeyedIn Systems Admin 13/05/2022 0.96 | |
| Mariette Rosqvist Finance Controller 13/05/2022 0.96 | |
| Steve Weaver Project Manager 13/05/2022 0.96 | |
| Afraaz Ayaz Project Accountant 13/05/2022 0.96 | |
| Peter Louwrens Licensing Finance Manager 13/05/2022 0.96 | |
| Ashton Berry Sector NPI Manager 13/05/2022 0.96 | |
| Jerry Springs R&D Director 13/05/2022 0.96 | |
| Ian Triccas Functional and Solution Architect β JM 13/05/2022 0.96 | |
| Uche Nnene Business & Functional Lead - EY 13/05/2022 0.96 | |
| 1.5. Distribution Information | |
| This document has been distributed to: | |
| Name Role Date of Issue Version | |
| Ian Triccas JM Solution Architect 06/06/22 1.0 | |
| Albert Venter <Albert.Venter@Matthey.com> JM Test Manager 06/06/22 1.0 | |
| Kanika Syal <Kanika.Syal@gds.ey.com> EY Test Manager 06/06/22 1.0 | |
| Ashley Winsper <Ashley.Winsper@matthey.com> JM Data Lead 06/06/22 1.0 | |
| Srinivasarao Battini <Srinivasarao.Battini@matthey.com> EY Data Lead 06/06/22 1.0 | |
| Shaylin Moodley <Shaylin.Moodley@uk.ey.com> Risks and Controls Lead 06/06/22 1.0 | |
| 1.6. External References | |
| The following referenced documents have been compiled but do not form a part of this document: | |
| Name Link/ Location | |
| Business Process Master List Link | |
| Master Requirements Traceability Matrix Link | |
| RAID Log Management (Master RAID Consolidated) Link | |
| RICEFW Inventory Link | |
| Change Impact Assessment Link | |
| Risk & Controls Matrix Link | |
| Functional Design Documents TBC | |
| 1.7. Related Business Process Documents | |
| The following Business Process Documents are impacted by this Process (End to End): | |
| Business Process Doc ID/Name Cross functional Business Process Author Relationship Link/Location | |
| BPD003 β RTR Vendor Invoice Management, | |
| Vendor Payment. Ryan OβNeill BPD003 -RTR Project Concert.V01.docx | |
| BPD005 β LES Inventory Management, | |
| Stock Transfers Iantha Kirkup BPD005 LES - Project Concert.docx | |
| BPD008 β PM Refurbishment Process, | |
| PR Against Planned Maintenance David Palhota BPD008_PM -Project Concert.docx | |
| BPD002 β STC Inbound Deliveries, | |
| Outbound Deliveries, | |
| Subcontracting Process. Bob Campbell BPD002 Sales to Cash V01.docx | |
| BPD 004 PTM (PM / QM) Production Planning | |
| Production execution | |
| Quality Management David Palhota TBC | |
| 1.8. Glossary | |
| Acronym/Term Description | |
| AP Accounts Payable | |
| AR Accounts Receivable | |
| ATP Available to Promise | |
| BPD Business Process Documents | |
| BPE Business Process Expert | |
| BPML Business Process Master List | |
| BU Business Unit | |
| CIA Change Impact Assessment | |
| CRA Credit Rating Agency | |
| CRM Customer Relationship Management System | |
| CS Customer Service | |
| CT Catalyst Technologies | |
| DoA Delegation of Authority | |
| E2E End to End | |
| ERP Enterprise Resource Planning (SAP) | |
| FDD Functional Design Documents | |
| LN Lotus Notes | |
| MDG Master Data Governance | |
| PO Purchase Order | |
| RFQ Request for Quote | |
| RICEFW Reports, Interface, Conversion, Enhancements, Forms, Workflow | |
| RTM Master Requirements Traceability Matrix | |
| SME Subject Matter Expert | |
| SO Sales Order | |
| STC Sales to Cash | |
| PS Project System | |
| TM Time management | |
| β | |
| 2. Introduction, Purpose and Scope | |
| 2.1. Document Purpose | |
| This Business Process Documentation has been developed by Project Concert specifically in relation to the delivery of this programme. This document provides a detailed description of the organisation's related business processes and sub processes. The key business drive for this document is to provide a structured schematic that can be used for development and future operational reference. | |
| This document aims to outline the business processes, interfaces, controls, measures, systems, and roles for the business processes covering Project Systems and Time Sheeting. This document covers the scope indicated below. | |
| This document provides the details to support: | |
| β’ Guiding principles to design the future state of the CT business functions and more specifically Project Systems and Time Sheeting with the enablement of SAP technology | |
| β’ Process flow diagrams with associated process narratives | |
| β’ Agreed specific Project Systems and Time Sheeting requirements in the context of what is to be designed for the business functions and configured in SAP | |
| β’ Agreed site specific requirements in the context of what is to be designed for the business functions and configured in SAP | |
| 2.2. Document Scope | |
| This document scope covers the L4 business processes for the Project Systems and Time Sheeting process area in the identified business areas. | |
| 2.3. Document Architecture | |
| A BPD section will exist for each of the process areas that are identified in section 4.5 | |
| The intention of each BPD section is to detail: | |
| β’ The process area scope | |
| β’ A summary of the key changes agreed through the workshops for each process area | |
| β’ The level 3 / 4 process inventory (otherwise abbreviated to L3 / L4) | |
| β’ The design decisions for each component impacting the operating model | |
| β | |
| 3. Business Context | |
| The following sections outline the context for the programme. | |
| 3.1. Concert Programme Vision | |
| The goal of the Concert programme is to enable the delivery of the CONCERT business case, decommission legacy ERPs, Harmonise and Improve SAP processes for Catalyst Technologies (CT) Business Unit. | |
| The Concert Project will deliver value design that supports: | |
| o A strategic standard technology platform supported by SAP ECC 6.0 EHP 7, fit for the future of our business | |
| o A consistent Enterprise and data design (i.e., chart of accounts design), underpinned by robust data controls and governance | |
| o Harmonized and Improved sales, procurement, finance, manufacturing, logistics, maintenance, R&D and Licensing processes and controls | |
| o Harmonized and Improved transparency of reporting within ECC | |
| o A single version of the truth for financial reporting, compliance, and control | |
| o Vastly improved insight into our business drivers, allowing us to make the right decisions earlier | |
| o Business driven change to enable the adoption of consistent and leading SAP practices | |
| At the end of Concert programme, there will be a step change from how the CT business works today. | |
| β | |
| 3.2. Design Principles | |
| The Concert Programme will be based these 15 key Design Principles: | |
| Theme No Design Principal Description | |
| Value Based Design and Build | |
| 1 Concert scope is bounded by the Catalyst Technologies Business unit; it will prioritise scope that achieve the goals of βHarmonisationβ, βImprovementβ and βConsolidationβ prioritised based on value (maximise benefit, maximise ROI and minimise implementation cost) | |
| 2 Scope classified as achieving βHarmonisationβ will adopt the best of what exists today within CT business | |
| 3 Scope classified as achieving βImprovementβ will either adapt from Group / JM Standards / Unify or from Industry reference models / SAP Standard Best Practice | |
| 4 Scope classified as achieving βConsolidationβ will adopt the target SAP design (incl. any integrated applications) | |
| 5 Concert Scope should consider vendor roadmaps and end of life dates to avoid regret spend on obsolete technology. | |
| Business Led Adoption 6 CT BPEs (Business Process Experts) and Subject Matter Experts (SMEs) will own and govern the Concert design | |
| Leverage JM and Global Best Practice Approach 7 Concert design will not compromise health & safety, regulatory compliance, controls, and service continuity | |
| 8 Group / JM standards / Unify processes will be adapted for βImprovementβ scope | |
| 9 Concert design will align with the JM Target Architecture | |
| CT Process Design aligned to Global Framework 10 Concert will establish a new CT Business Process Master List (BPML) that defines the E2E processes and numbering taxonomy for the CT business | |
| 11 CT BPML will cover the full E2E processes down-to Level 1 to Level 3. BPML Level 4 and below will only be defined for prioritised Concert scope items | |
| 12 Levels 1 to 5 of the CT BPML will follow the globally agreed process architecture levels and design standards | |
| 13 Concert design aligned to agreed target operating model and CT organisational changes needed to realise the Concert Business Case | |
| Fit to Standard Approach | |
| 14 Processes designed for cross-site standardisation while minimising site-specific variants / localisations | |
| 15 Concert design will minimise customisation to reduce the cost and complexity of the solution | |
| Table 3 1: Represents the overarching Concert Design Principles | |
| Figure 1 - Represents the overarching Concert Design Principles & Themes | |
| β | |
| 4. Design Scope | |
| 4.1. Business Process Framework | |
| During prepare and high-level design, a future state level 1 and 2 process framework was defined and produced to provide a schematic view of how CT Organisation wished to transform the business to best deliver on the vision. This model gives a complete view of all the processes needed to be able to function as a chemical manufacturing organisation. The scope of the Concert programme is articulated in the diagram below. Selected scope items are agreed and documented within the BPML Baseline document | |
| Other aspects of the process framework out of scope for Concert will be impacted through other initiatives. | |
| β | |
| 4.2. Organisation Process Hierarchy | |
| During Detailed Design the Concert Programme aims to provide Level 4 detail for impacted processes in accordance with business process definitions: | |
| Figure 2 - CT Process Hierarchy | |
| 4.3. Concert Deployment Context / Scope | |
| In order to provide greater detail, the L2 processes are linked to technical solutions across the seven Concert functional areas: RTR, PS/TS, STP, STC, LES, PM and PP/QM. Each area has differing technical solutions but will require business and system integration to function effectively. The deployment approach considers the linkage between Business Capability and Technical Capability and the separation required across the Releases that form the deployment approach for the technical and business deployment. | |
| The deployment plan is being finalized and will be referenced later. | |
| 4.4. Process Area Scope | |
| This BPD refers to the harmonisation, improvement, and consolidation of the Project System & Timesheets process area across the following businesses: | |
| β’ Licensing | |
| β’ Formox Plant Designs | |
| β’ R&D | |
| 4.4.1. Process Areas - In Scope | |
| This BPD refers to the Project Systems and Time Sheeting process area. JM CT have determined that Project Systems and Time Sheeting will only be applied in the following business areas at this stage: | |
| β’ JM Davy β Consolidation from Agresso to SAP | |
| β’ RD&E | |
| β’ Formox Plant Designs | |
| All other business areas will continue to use Internal Orders/existing processes to manage projects and time at this stage. | |
| The Project Systems and Time Sheeting process covers the following areas. | |
| β’ Maintain Project Definition and Structures | |
| β’ Perform Project Budgeting & Planning | |
| β’ Capture Project Costs & Timesheets | |
| β’ Capture Project Revenue (Billing) | |
| β’ Project Monitoring | |
| β’ Project Month & Year End Close | |
| β’ Project Reporting | |
| 4.4.2. Scope Items β In Scope | |
| Scope Item Number Scope Item name | |
| 3.9.3 Revenue Recognition β Davy & Formox | |
| 3.8.1 Perform booking of Time sheets - Licensing | |
| 3.8.2 Perform booking of Time sheets - Formox | |
| 3.8.4 Project Systems (Agresso). | |
| 3.8.5 Project Systems (Formox Plant Designs). | |
| 3.8.6 Project Cost Control Reports | |
| 4.4.3. Process Areas - Out of Scope | |
| The following process areas have been agreed as out of scope for Concert Design for Projects and Timesheets: | |
| β’ CAPEX β the use of Project Systems and related Time Sheeting for CAPEX activities has been excluded from the scope of Concert at this stage. | |
| β’ Technical Services/Field Services β the use of Project Systems and related Time Sheeting for these areas has been excluded from the scope of Concert at this stage. | |
| β’ Other users of Internal Orders on the CT SAP system outside of RD&E and Formox Plant Designs are all excluded from the current Concert scope. | |
| 4.5. Site Related Scope | |
| The implementation of Project Systems and Time Sheeting into the JM CT SAP system will be new for all sites as neither of these elements exist in the current CT SAP system. The different businesses do have similar concepts and systems in place but will all be moving to the new Project Systems and Time Sheeting solution in CT SAP. | |
| Project Systems and Time Sheeting are being implemented across the Licensing, R&D and Formox Plant Design businesses and these have a presence across several CT sites. The following sections outline the different businesses, sites and processes that will be required. | |
| The process βProject System & Timesheetsβ is an end-to-end business operation that involves, the following functions that have been identified and defined for the standard and harmonized project life cycle process to be followed by JM CT. | |
| Project Lifecycle Harmonized and Standardized in SAP for JM CT | |
| The following table describes in high level the functional scope of the seven sub-processes mentioned on the diagram of above. | |
| Process Areas | |
| L3 Process Area L3 Process Description L3 Process Description | |
| 08.01.01 Maintain Project Definition and Structures The functionality will cover all the activities related with the project creation in the system. | |
| The user will have the ability to design the structure of a project according business needs. | |
| 08.01.02 Perform Project Budgeting & Planning The functionality will cover all the activities related with planning costs activities for projects and budgeting. | |
| Planning will be used to create cost estimates in projects and the budgeting will be used to allocate the final amount approved in a project to be spent. | |
| 08.01.03 Capture Project Costs The functionality will cover everything related with the collection of costs from different processes like: | |
| β’ Purchase | |
| β’ Sales | |
| β’ Finances | |
| β’ Time Sheets | |
| 08.01.04 Capture Project Revenue (Billing) The functionality will cover the integration between sales and projects, for the correct allocation of revenues in projects. | |
| 08.01.05 Project Monitoring The functionality will cover the different activities related with the overseen of the evolution of project during their execution. | |
| 08.01.06 Project Month & Year End Close The functionality will cover everything related with the different activities involved on Month & Year end. | |
| 08.01.07 Project Reporting The functionality will cover everything related with the identification, extraction and reporting of information related with projects. | |
| SAP Project System (PS) is a part of SAPβs Project and Portfolio Management solution. Project System helps manage projects throughout the entire project lifecycle, from the creation of a project to the preparation of detailed plans, project execution and completion, according to the harmonized process that has been established for the JM CT business. | |
| Due to its tight integration with SAPβs Finance and Logistics modules, the SAP PS Module can be used especially for large and complex projects such as construction, production, service, investment projects in all industries. | |
| Licensing | |
| Project Systems and Time Sheeting are being implemented for the Licensing business to enable the replacement of the existing Agresso ERP system. | |
| Licensing Sites | |
| Licensing is primarily based in Paddington and Stockton. Paddington is the base for the organisation, including project management and engineering, whilst Stockton is the base for R&D within the Licensing business. | |
| The following L3 processes will be required for the Licensing business: | |
| Process Areas for Licensing | |
| L3 Process Area L3 Process Description | |
| 08.01.01 Maintain Project Definition and Structures | |
| 08.01.02 Perform Project Budgeting & Planning | |
| 08.01.03 Capture Project Costs & Timesheets | |
| 08.01.04 Capture Project Revenue (Billing) | |
| 08.01.05 Project Monitoring | |
| 08.01.06 Project Month & Year End Close | |
| 08.01.07 Project Reporting | |
| R&D | |
| Currently R&D uses Agresso (the Licensing ERP system) to capture time related to R&D activities and Internal Orders in SAP for managing costs. The implementation of Project Systems and Time Sheeting on the CT SAP system will enable R&D projects to be tracked and managed within the system, replacing the Agresso time sheeting capability and enhancing the collection of costs associated with R&D activities. These costs will be able to be shared with KeyedIn. | |
| R&D Sites | |
| R&D activities take place across several the CT sites, including: | |
| β’ Savannah | |
| β’ Stockton | |
| β’ Chilton | |
| β’ Perstorp | |
| β’ Paddington | |
| The following L3 processes will be required for the R&D business: | |
| Process Areas for R&D | |
| L3 Process Area L3 Process Description | |
| 08.01.01 Maintain Project Definition and Structures | |
| 08.01.02 Perform Project Budgeting & Planning | |
| 08.01.03 Capture Project Costs & Timesheets | |
| 08.01.05 Project Monitoring | |
| 08.01.06 Project Month & Year End Close | |
| 08.01.07 Project Reporting | |
| Formox Plant Designs | |
| Currently Formox Plant Designs use Internal Orders for managing projects and carry out time sheeting in SharePoint. The implementation of Project Systems and Time Sheeting will bring this part of the business into line with the Licensing business and the common time sheet solution. | |
| Formox Plant Designs activities take place on the Perstorp site in Sweden. | |
| The following L3 processes will be required for the Formox Plant Designs business: | |
| Process Areas for Formox Plant Designs | |
| L3 Process Area L3 Process Description | |
| 08.01.01 Maintain Project Definition and Structures | |
| 08.01.02 Perform Project Budgeting & Planning | |
| 08.01.03 Capture Project Costs & Timesheets | |
| 08.01.04 Capture Project Revenue (Billing) | |
| 08.01.05 Project Monitoring | |
| 08.01.06 Project Month & Year End Close | |
| 08.01.07 Project Reporting | |
| 5. Detailed Design | |
| 5.1. Level 3 & 4 Business Processes | |
| Level 4 processes have been designed to cover both business and system steps. The level 3 process has been used as a βgolden threadβ throughout the design to bring together all the operating model elements. Each process map will document the activities, controls, roles, decisions, and systems in use, using the symbology shown below: | |
| Figure 3 - Process Map Symbology | |
| 5.2. Level 3 Business Area β 08.01.01 Maintain Project Definition & Structures | |
| 5.2.1. Process: 08.01.01.01 Develop Project Policy and Procedure | |
| To implement Project Systems and Time Sheeting in SAP for JM CT, several key elements required by these systems need to be defined. | |
| The project structure within SAP allows the business to allocate and process all the information related to the execution of a project lifecycle. It enables the business to represent the different parts, phases and activities required to deliver a project. | |
| To simplify the set-up of projects, templates will be developed to enable quick and consistent set-up of projects within SAP. The structures used in these templates will include: | |
| 1. Project definition | |
| 2. WBS elements | |
| 3. Networks and activities | |
| 4. Milestones | |
| Providing templates with these structures will help the business to standardise the approach to the creation, monitoring and execution of projects within CT. Templates will be made available for each area of the business as required. | |
| The templates and project structures will contain the elements required to manage projects within CT. The following table shows which main structures will be used across the different businesses. | |
| Business Project Definition WBS Elements Networks/Activities Milestones | |
| Licensing In scope In scope In scope In scope | |
| Formox In scope In scope Out of scope Out of scope | |
| R&D In scope In scope Out of scope Out of scope | |
| As well as templates and common structures, a project Coding Mask has been developed. This is based on the Unify approach but has been adapted for CT use. | |
| The project code being used by CT is as follows: | |
| Refer to the FDD for full details of the coding structure and masks. | |
| The project number will follow the guidelines below for different project types. This is designed to align with existing numbering in the CT businesses where appropriate. | |
| Licensing (JM Davy) projects will be numbered using a 4-digit number preceded by 00 (XX according to the mask defined). This aligns with the existing 4-digit numbering used in the Licensing business. | |
| Example: Existing project 2543 will be numbered as 002543. The 4-digit number will allow the large number of existing document templates used in Licensing to be retained with limited changes. Studies and Plant Upgrades will also use the same 4-digit numbers preceded by 00 but with a different project type detailed in the text Project Type field in the Root WBS element. | |
| LI - will be the project type code used in the coding structure for all Licensing projects (projects, studies, plant upgrades) - this aligns with the current approach of these all taking consecutive numbers. | |
| Within the project header it is possible to add a text field Project Type - the proposal here is to consider including a different text description to allow differentiation between projects, studies, and plant upgrades | |
| The Project Type text field options will include: | |
| β’ Licensed Technology Project | |
| β’ Plant Upgrade | |
| β’ Study | |
| The Project Type code in the coding will remain LI. | |
| Licensing Proposals will use a 5-digit number preceded by an L and the Project Type code PS. This allows other businesses to use the same Project Type code (PS) and incorporate a different leading letter in the future. At this stage only L will be used for Licensing proposals. There is the option of using the Project Type text field in the Root WBS element if required as per Licensing projects. | |
| Formox Plant Design projects will be numbered using a 3-digit number preceded by 000. This aligns with the existing 3-digit numbering used in the Formox business. Example: Existing project 218 will be numbered as 000218. | |
| R&D projects that are in KeyedIn (NPI & PIM projects) will use a 6-digit number which will align with that used in KeyedIn. Where necessary leading zeros will be added to make project number 6 digits long. Example: Existing project PRJ1985 will be numbered as 001985. For R&D projects in KeyedIn the KeyedIn project number and the programme number will be captured in User Fields at WBS element level, e.g., 0521 (programme number) and PRJ1985 (project number) will be stored in the User Fields for this example project. Any reference to a workstream number will be stored in a User Field in the appropriate WBS element. | |
| Segments: All relevant projects will be tagged with a Segment code. This provides an indication of the market segment that the project is associated with. This combined, where appropriate, with the customer will enable projects to be reported based on market segment. The segments are detailed in Appendix 7.1 | |
| Note: There is no flow diagram for this L4 process because this section defines the approach and structures that will support the creation of new projects. | |
| 5.2.2. Process: 08.01.01.02 Create and Maintain Projects | |
| Create and Maintain Projects Overview | |
| The Create and Maintain Projects process refers to the flow of events required to create and maintain projects and their associated structures within SAP by the different CT businesses. | |
| Projects are being used in CT for the management of activities across the Licensing, R&D and Formox Plant Designs business areas. Projects are not being used for other areas such as CAPEX at this time but will be implemented in the future. | |
| A project will be set up in SAP based on a request from the requestor. The requestor will need to provide sufficient information for the project to be created. This will include: | |
| β’ Project Name | |
| β’ Project Type | |
| β’ Responsible Person | |
| Once a project has been approved, the request will be used to set up the project. Once the project has been set up the requestor will be notified that the project has been created and is now available for use in SAP. | |
| If changes are required to a project, these can be requested or performed directly depending on the rights of the person concerned. Changes can be made to all elements of the project so enabling flexibility required for the different projects undertaken by CT businesses. | |
| If a project is not available immediately then hours/costs can be booked to a proposal and then transferred to the appropriate WBS elements of the project once it is created. A similar process can be used to handle correction of costs if booked to the incorrect project. The off-system processes for these corrections would continue like today but with revisions where references are needed to WBS elements. | |
| Key points: | |
| There are likely to be additional fields required that will be reviewed during the realisation phase, like dates, technology, free field entry texts etc. | |
| Technology may be covered by existing use of Segment/Industry Code for example. | |
| Dates are available in the WBS elements, and these may be appropriate to use for things such as Effective Date. | |
| Networks: | |
| There are 3 main sections to be configured in the Network: | |
| β’ Network | |
| β’ Graphic | |
| β’ Activities | |
| Network - Key configuration parameters (in scope): | |
| Field Description In scope | |
| Network type For Licensing a network type will be set up, and an also a new control key. | |
| The key configuration of this control key will be explained below. In scope | |
| Control Key | |
| One important requirement from the business is the closing of the activities without the need to perform a βnotificationβ on each activity. It will be necessary to create the following new control keys to plan βinternal activitiesβ and βexternal activitiesβ. | |
| Notes: | |
| β’ Planning β The licensing business has decided to perform all the planning (time) outside of the system, so this is not considered in the customisation of this functionality in SAP. | |
| β’ MPR integration β This is not part of the requirements, and this integration will not be customised, the PR and POβs will be created manually by the user. | |
| β’ Validations and Substitutions β So far, there are no validations or substitutions considered to be customised at network level; However, during the realisation this will be confirmed. | |
| β’ User fields β User fields are not considered at network level to be available for the user; However, this will be reviewed during the realisation phase in case there is a need for the use of any of the standard fields. | |
| The configuration for Licensing will be more oriented to cost allocation, instead of planning boards and integration with MRP and production. Anything related with planning and the integration with MRP is not considered in the scope of the customising of project system for CT. | |
| Graphic β (out of the scope) | |
| Graphics and planning boards are not considered in the scope for Licensing. Any planning related with time will be performed outside of SAP or in Primavera. | |
| Activities Key configuration parameters (in scope): | |
| The following parameters will be maintained in the Network Profile: | |
| β’ Network type (parameter) | |
| β’ Activity parameter | |
| In JM CT the Network Type will be used to hold the information for controlling and managing the networks. The configuration required for the Licensing business for networks is very simple, because it will not be necessary for them manage capacities, integration with production (routings) and the integration with MRP. The user will be able to plan activities and general costs only according to the business requirements. | |
| 5.2.2.1. Level 4 Process Flow and Steps | |
| Figure 4 β 08.01.01.02 Create and Maintain Projects | |
| 08.01.01.02 Create and Maintain Projects | |
| L4 Process Step System / Manual Narrative Step Owner SAP T-code | |
| Project creation request Manual Creation and issue of the request form, establishing the requirement to create a project. Requestor/ Project Manager N/A | |
| Approve project creation Manual Before a new project is created it must be approved by the appropriate person. Approver N/A | |
| Template selection SAP For the creation of a new project, the user can select the corresponding βproject templateβ to create the new project. | |
| For JM CT some project templates have been defined to provide a consistent structure for the new project to follow. Project accountant/ Project controller CJ20n | |
| Copy existing operative project SAP For the creation of a new project, the user has the option to create a new project, using as a βtemplateβ an existing operative project. | |
| The operative project is a project that is active or used to be active, that can be used to create a new one. Project accountant/ Project controller CJ20n | |
| Define/Select Project number SAP The system will present the latest number available that can be used by the user to create the new project. | |
| The project number will not be assigned automatically by the system, the user will confirm the number to be used. | |
| The structure of the project code will be established based on the coding already defined in section 5.2.1 of this document. Project accountant/ Project controller CJ20n | |
| Project Creation SAP The CT user will create the project on this transaction, using the project code selected. | |
| For the creation the user will have the option to create a project using a template or an operative project as described above. Project accountant/ Project controller CJ20n | |
| Notification project created Manual Once the user has completed the creation of the project, the requestor will be notified via email. | |
| The requestor will receive the code of the new project. By default, the project will not be released. | |
| When a project has been created the details of the project will be available for the creation of the sales order via the STC process: 02.04.01.04 Create Customer Order with Project and Intercompany Sales Orders via 02.04.01.07. Project accountant/ Project controller N/A | |
| Project change request Manual Creation and issue of the request form, establishing the requirement to modify an existing project. | |
| NOTE: Project Managers may have the ability to make changes to projects themselves and hence the process allows these changes to be made directly. Project Manager N/A | |
| Approve project change Manual Before a change is made to a project it must be approved by the appropriate person. | |
| This process is followed when the Project Manager is not able to make changes directly to projects. Approver N/A | |
| Create/modify project SAP The user will have this transaction available to create or modify projects. | |
| The modifications will be performed according to the request made by the user. Project accountant/ Project controller | |
| Project Manager CJ20n | |
| Create/modify WBS SAP The user will have this transaction available to create or modify WBS elements. | |
| The modifications will be performed according to the request made by the user. Project accountant/ Project controller | |
| Project Manager CJ20n | |
| Create/modify network SAP The user will have this transaction available to create or modify Networks. | |
| The modifications will be performed according to the request made by the user. Project accountant/ Project controller | |
| Project Manager CJ20n | |
| Create/modify/milestone SAP The user will have this transaction available to create or modify milestones | |
| The modifications will be performed according to the request made by the user. Project accountant/ Project controller | |
| Project Manager CJ20n | |
| Notification project modified Manual Once the user has completed the modification of the project, the requestor will be notified via email. | |
| When a project has been modified the details of the project will be available for the creation of the sales order via the STC process: 02.04.01.04 Create Customer Order with Project and Intercompany Sales Orders via 02.04.01.07. Project accountant/ Project controller | |
| Project Manager N/A | |
| The following table provides more information on some of the important fields required during the creation/modification of a project. | |
| Header Fields Description Mandatory / Optional | |
| Project Profile The profiles contain default values and control parameters for processing objects and functions in the Project System. | |
| The Project System includes the following profiles: | |
| β’ Standard network profile | |
| β’ Network profile | |
| β’ Project profile | |
| β’ Plan profile for cost planning in the WBS | |
| β’ Budget profile for budget management | |
| β’ Information system profiles | |
| For JM CT 5 project profiles are defined | |
| Mandatory | |
| Project definition The project definition contains dates and organisational information that are binding for the entire project. | |
| The project definition defines the project mask to be used by the project to build their project code Mandatory | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| STC 02.04.01.04 Create customer order with project As part of the new practices adopted by the different JM CT businesses for projects, it will be necessary create a project number before creating a sales order. | |
| STC 02.04.01.07 Create Sales order for Interco Project This process will allow a company to invoice services to another affiliate, for cases where the company is using resources from an affiliate. | |
| PS&TM 08.01.02.01 Perform Budgeting for project spend Once the project has been created, the next step for the user will be the upload of the plan and initial budget for the project, that will be perform in this process. | |
| TBC TBC External systems There will be an integration with KeyedIn, that will be manual. | |
| The user responsible, will create a project in SAP once have received the request from KeyedIn. | |
| RTR 01.06.02 Expense Management (Concur) There will be an interface between SAP and Concur. This interface will transfer the WBS codes created within projects into Concur, to allow the users to allocate and projects to receive charges (costs) from travel expenses reports. | |
| The design of this interface will be finalised during the realisation phase. | |
| 5.2.2.2. To-be Changes | |
| Project creation and maintenance is a new process in JM CT SAP. The users from the different CT departments will not be able to allocate time to projects, unless the project has been created first. Existing processes for the creation of projects in Agresso or in SAP as Internal Orders will need to be adapted or revised to use SAP PS. | |
| CT Sites Changes Business justification | |
| All Sites Implementation of PS is new to all sites. Processes for creation and maintenance of projects using PS will be new on all sites where this is being used. Existing processes used to create projects in Agresso/SAP will need to be revised to follow the requirements of SAP Project Systems. This includes where Projects are replacing current use of Internal Orders. Implementation of PS for JM CT | |
| All Sites Adoption of project templates for the creation of new projects is a new process. | |
| This will support a standard process across JM CT to manage and administrate projects in the same way. Standardisation of the process to create projects and the use of templates across all JM CT | |
| All business The creation of a project is considered βmaster dataβ; however, it has already been agreed that every business will establish their own responsible person to create new projects in the system as per of business needs and requests. | |
| Every business will have autonomy to create and administrate their own projects. The main target is to provide autonomy to every business to create their own projects, without the intervention from the global master data team. | |
| 5.2.2.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| Agresso sites The creation and modification of projects in SAP PS will require new and adapted processes compared to those currently followed for the creation and modification of projects in Agresso Move from Agresso to SAP PS | |
| Perstorp The creation and modification of projects in SAP PS will require a modified process compared to that used for these activities using Internal Orders currently in this part of the business Consolidation to the use of SAP PS for projects from the use of Internal Orders | |
| Other existing SAP sites The creation and modification of projects in SAP PS will require a modified process compared to that used for these activities using Internal Orders currently in this part of the business. There will be more use of Projects as currently not all R&D projects are given SAP codes, but they will be required going forwards for time sheeting purposes. Consolidation to the use of SAP PS for projects from the use of Internal Orders | |
| 5.2.3. Process: 08.01.01.03 Project Template and Master Data Maintenance | |
| Project Template and Master Data Maintenance Overview | |
| The Project Template and Master Data Maintenance process refers to the flow of activities required to create new templates or make changes to existing templates. | |
| Project Templates will be used to help the business standardise the structure of each project depending on the nature of the business and the project type. | |
| A project template is a preconfigured project, that can be used to setup a new project which SAP PS calls an Operative Project. | |
| A Template is a neutral structure that can be used to standardise WBS structures, Networks, Activities and Milestones. Templates are Master Data structures. Within CT, these will be managed by the CT business teams involved in project creation rather than the Master Data Team. There will be multiple templates to reflect different project scenarios. Project and Network Templates contain a Project or Network Profile, and templates can contain inherent business rules. Templates are not mandatory, but if you have common, complex structures, they help maintain consistency. | |
| Existing Operative Projects and their Networks can be used to create new projects but are prone to inheriting errors present in the structure of the source project. | |
| Milestone Templates (Standard Milestones) can be attached to Standard WBSβs and Standard Networks. Standard Templates do not carry Settlement Rules. | |
| To summarise, a project can be created on three ways: | |
| 1. From a Template - this is a standard project structure that is then copied to create the project. Because you are using a standard template there should be no errors transferred to the new project. | |
| 2. From an existing project - this copies an existing project (Operative Project) to create a new project (it retains the structure but the budgets etc. are not copied) - there is a risk here that errors in the original project will be copied into the new project. | |
| 3. From scratch - clearly this takes time and would not be appropriate in most cases. | |
| For JM CT Project Templates will be developed for the following businesses, as explained below. | |
| β’ JM Davy β Consolidation from Agresso to SAP | |
| β’ RD&E β move of time sheets and projects from Agresso/SAP to a common approach using Project Systems and SAP Time Sheeting | |
| β’ Formox Plant Designs β move of these from use of Internal Orders to Project Systems and introduction of SAP Time Sheeting in place of existing SharePoint based solution | |
| Integration with Concur | |
| Depending on the roll out timing, Concur updates may have to be performed manually at the go-live of PS/TM. | |
| It is intended native integration will be implemented removing this need, but this may be in a later phase. | |
| Integration with Concur and impact on available codes will need to be confirmed during realisation. | |
| Note: | |
| There will be a WBS element where royalties are collected as part of the structure. The accrual of royalties will be performed manually. | |
| 5.2.3.1. Project Templates | |
| The following project templates are being developed to cover project needs for the JM CT business. | |
| 5.2.3.2. Project Template for Licensing | |
| The diagram below shows the template structure for Licensing projects. This structure will be used for all Licensing projects (Licensed Packages, Studies and Plant Upgrades). Other activities such as proposals and day-to-day activities will use the simpler structures described later. | |
| Figure 5 - Licensing Project Structure | |
| The intent of this structure is to enable the Licensing business to continue to manage projects in a similar way to currently in Agresso down to a similar level of detail. In addition, the structure in SAP will enable the planning of manhours within SAP and the production of Cost Reports from SAP. | |
| The project template includes all the elements that make up a single project. For Licensed packages this can include License Fee, Engineering, Equipment Supply and Catalysts. There is also consideration of the need to manage contracts which are owned and managed by a different legal entity to the entity doing the work (e.g., JM Plc (GB30) contracts with JM Davy performing the work and receiving the revenue). It is likely there will be some contracts where changes will be required but the template should provide a good basis for most Licensed packages. The same template will be used for Studies and Plant Upgrades, where not all elements will be used but will be created as part of the template and can then be removed or ignored at a later stage. | |
| WBS Level 2 (Core Activities) | |
| This level includes WBS elements that relate to the different elements of a Licensed package, i.e., License Fee, Engineering, Equipment Supply and Catalysts. There is also a WBS element for JM Plc at this level to handle the cases where JM Plc manages the contracts (including invoicing and receipt of payment). This will enable these to be handled within the project and then the costs/revenue can be transferred to the correct WBS element. | |
| WBS Level 3 (Work Orders) | |
| This level replicates the work orders currently found in Licensing. The total list of work orders has been reduced from those currently in use to a key sub-set agreed with the business. The sections below outline the workorders, the relevant WBS elements provided in the template and the reasoning behind the design. | |
| License Fee | |
| No WBS levels are required below Level 2 for the License Fee as there are no costs associated with this activity. The Level 2 WBS element will be used to handling billing etc. for the License Fee contract. | |
| Engineering Work Orders | |
| The Engineering WBS Level 2 is designed to cover the engineering aspects of the project, excluding those costs, billing etc. related to the supply of equipment by JM to the customer which will be covered under the Equipment Supply WBS Level 2. The Level 3 WBS elements used here are: | |
| Description Agresso Work Order SAP WBS Element | |
| PDP 10 10 | |
| Post PDP 20 20 | |
| Training 40 40 | |
| Meetings 51 51 | |
| Site Services (Reimbursable) 55 55 | |
| Home Office Support 58 58 | |
| If Technical Procurement Support (for customer procurement of equipment) is required, then an additional WBS element in the 20 series can be created to capture these costs. | |
| Work Order 30 is not included here as equipment costs associated with the supply of equipment by JM to the customer are moved to the Equipment Supply WBS Level 2. | |
| Equipment Supply | |
| The Equipment Supply WBS Level 2 is designed to cover the engineering, procurement, billing etc. activities related to the supply of equipment by JM to the customer. This does not include Technical Procurement Support of customer procurement which would be under the Engineering WBS Level 2 β see above. | |
| A minimum of one WBS element would be created at WBS Level 3 for equipment supply as shown in the diagram (e.g., E1). It may be appropriate for some contracts to create multiple WBS Level 3 elements to cover multiple major items of equipment supply. | |
| Catalysts | |
| The Catalysts WBS Level 2 is designed to cover the procurement, billing, supply etc. activities related to the supply of catalysts by JM to the customer as part of the project. Future charges of catalyst would be handled as normal sales. | |
| The use of level 3 WBS elements may be required if there is a need to separate for example JM supply vs. PFR catalysts within the project. A typical WBS Level 3 would be C1. | |
| Note: | |
| Revenue for catalysts will be able to be reported separately to the other project revenues as this is being handled through a separate WBS element. There will also be a separate Sales Order for the catalyst. | |
| WBS Level 4 | |
| This level enables a roll-up of the various functions within the project to a discipline level. This is used in the reporting and management of manhours. The Level 4 WBS and Level 5 WBS elements will be repeated under each of the Level 3 WBS elements under Engineering (Level 2 WBS ENG) and Equipment Supply (Level 2 WBS EQP). | |
| The Level 4 WBS elements are: | |
| Description (Discipline) SAP WBS Level 4 | |
| Engineering 10 | |
| Process 20 | |
| R&D 30 | |
| Projects 40 | |
| Others 60 | |
| Note: | |
| SAP PS has a limitation on the number of characters in the project coding mask (limited to 24). So, the new coding has been established to fit in this structure. The new coding will need to be understood by the different businesses and different users will need training and time to get used to the new structure. | |
| Concert has deliberately chosen codes that broadly align with existing codes in use in the business to help with this transition. | |
| WBS Level 5 | |
| This level enables the split of activities by function and roll-up to the functional level. This aligns with the Cost Reporting and planning activities. Activities will be placed below the Level 5 WBS elements. The information from these Level 5 WBS elements and reporting will also be fed to the planner for updating the forecast manhours and this then provides input to the forecasting of costs and revenue. | |
| The table below shows the mapping of existing codes to the new SAP WBS Level 5 numbering and the roll-up to the Level 4 WBS elements. | |
| Description (Function) Agresso Code SAP WBS Level 5 SAP WBS Level 4 | |
| Engineering Management 100 10 10 | |
| Procurement 103 13 | |
| Vessels & Heat Exchangers inc. Metallurgy 104 14 | |
| Mechanical 105 15 | |
| Electrical / Instrument 106 16 | |
| Piping / Layout 107 17 | |
| Civil / Structural 108 18 | |
| Fired Equipment 109 19 | |
| Process Design 201 21 20 | |
| Systems Engineering 202 22 | |
| Process Detailed Engineering 205 25 | |
| QA 206 26 | |
| R&D 300 30 30 | |
| R&D Commissioning 300 31 | |
| Project Management 400 40 40 | |
| Project Engineering 401 41 | |
| Project Controls (inc. Planning) 402 42 | |
| Secretarial (London) 601 61 60 | |
| Document Control/Office Services 604 64 | |
| Accounts 700 70 | |
| Business Services 900 90 | |
| Unallocated 999 99 | |
| Additional WBS elements can be created as required during the creation and operation of the project. | |
| 5.2.3.3. Project template for Licensing Proposals | |
| The diagram below shows the template structure for Licensing Proposals. The intent here is a separate project is created for each proposal. | |
| Figure 6 - Licensing Proposals Structure | |
| The structure allows for the capture of manhours and costs on proposals. The intent is to use generic discipline activities below the Manhours WBS Level 2 element to enable an understanding of manhours by discipline if required. | |
| 5.2.3.4. Project template for Formox Plant Designs | |
| The diagram below shows the template structure for Formox Plant Design projects. | |
| Note: Other Formox activities will continue to use Internal Orders, only Formox Plant Design projects are moving to using PS/TM. | |
| Figure 7 - Formox Plant Designs Project Structure | |
| The aim of this structure is to align with the current approach within Formox Plant Designs. Existing GLs will be used within the WBS Level 2 elements to capture costs. It is anticipated that this approach will allow the Formox Plant Design business to continue to use their existing planning, forecasting and revenue recognition tools, although some modifications will be required based on the finally developed reports that are available from SAP. | |
| 5.2.3.5. Project template for R&D KeyedIn Projects | |
| The diagram below shows the template structure for R&D projects that are established in KeyedIn. These will typically be NPI or PIM projects and will be created in KeyedIn before being set up in SAP. Other R&D activities will be covered by standard project structures described later for day-to-day activities. | |
| Figure 8 - R&D KeyedIn Projects Structure | |
| In order that the data can be transferred from SAP to KeyedIn for actual manhours and costs, the project template includes User Fields which will be populated at set-up with the matching information from KeyedIn. This includes: | |
| Β· KeyedIn Programme Number | |
| Β· KeyedIn Project Number | |
| Β· KeyedIn Workstream Number | |
| These fields are required to enable the import of the data from SAP into the correct entry in KeyedIn. A field will also be provided to allow a project that is eligible for Tax Credits to be marked as such. | |
| At WBS Level 2, one workstream WBS element will be created by default. This aligns with the current CT use of workstreams in KeyedIn. However, using this structure would enable the use of multiple workstreams at future date which is already used in other parts of JM. | |
| At WBS Level 3, two WBS elements are created, one for manhours and one for costs. At the present time CT does not capture costs on specific R&D KeyedIn projects, but again this structure provides this capability. Initially only time will be captured against specific projects using the appropriate WBS element when employeesβ complete timesheets. | |
| 5.2.3.6. Project Structures for βday-to-day" activities | |
| As CT is implementing time sheeting for the whole of RD&E including Licensing, Formox Plant Design projects and R&D as well as the broader Licensing business, it is necessary to have projects set up to provide places for time to be booked for on-going activities such as customer support, manufacturing support, innovation, and overheads. These projects will be continuous and used simply to collect time/costs as part of time sheeting. | |
| The structure of these projects will be straightforward as there will be no need to segregate by activity or discipline. In some instances, multiple activities may be included in one overarching project, for example: | |
| Customer Support | |
| A single project could be created for Customer Support. Within this project the WBS Level 2 would provide a split by business area, e.g., Refinery Hydrogen, Additives, SNG and GTL, Ammonia & Nitrogen etc. Below this the WBS Level 3 could include various Key Accounts, plus Non-Key Accounts to which hours would be booked. The diagram below shows how this might look. | |
| Figure 9 - Typical Non-project Activity Structure | |
| Further work is required to finalize these project structures and coding's with the business, the aim being to reduce the number of codes in use at present in Agresso and consolidate to common coding across CT where possible. | |
| Notes: | |
| 1. The templates in SAP are considered as βmaster dataβ, however, for the creation of a βproject templateβ or an operative project, each business will have their own responsible person. This person will receive and validate any project/template creation request made by the business, and once confirmed will be responsible to create the project in the system. | |
| It has been established that every CT business will have autonomy to administer, create and improve the structure of their project templates and operative projects. | |
| The responsible person will be also administer, modify and make any changes requested by the business on their project templates. | |
| During the realisation phase, each business will establish the people responsible for the administration of templates and creation of projects. | |
| 2. There will be a need to decide if the costs need to be included in the % completion calculation for revenue recognition and this may require a modification to the Results Analysis key for the specific WBS element. This will be further reviewed during Realisation and Training. | |
| 3. The previous diagrams are generic and are proposed structures. The actual or final structures will be finalised during Realisation phase of the project. | |
| 4. The intent is that each project will also be assigned to a βSegmentβ using a βUser Fieldβ (this has been explained in the FDD) within the project header. This will enable Segment to be defined for each project and hence reporting by segment will be possible. This field will be a key field for reporting purposes. | |
| 5. For procurement on projects, the purchasing process will need to refer to the appropriate WBS element within a project to ensure that the commitments and costs appear on the project in the correct place. Authorisation requirements for purchasing will follow the standard STP processes with no additional elements due to the use of projects. | |
| 5.2.3.7. Level 4 Process Flow and Steps | |
| Figure 10 β 08.01.01.03 Project Template and Master Data Maintenance | |
| 08.01.01.03 Project Template and Master Data Maintenance | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Create/Modify Project Template Manual Requestor needs to create/modify a βTemplateβ and submits a request for approval. | |
| The project template is a predefined structure that contains all the required βstructuresβ to create a project, to manage and control a specific project. | |
| Requestor N/A | |
| Review Request Manual Approver reviews the Template request received from Requestor. If the template request is approved, it will be sent to Master Data team or else will be sent to Requestor with a reason for the rejection. | |
| Approver N/A | |
| Create/Modify Template SAP Master Data team creates/modifies a Template after an approval. Project Accountant/ | |
| Business Controller CJ91/CN02 | |
| Create/Modify Project Definition & WBS SAP Master Data team creates/modifies the Project Definition and WBS Templates by using the transaction codes. Project Accountant/ | |
| Business Controller CJ91/CJ92 | |
| Create/Modify Network & Activities SAP Master Data team creates/modifies the Network and Activity Templates by using the Transaction codes. Project Accountant/ | |
| Business Controller CN01/CN02 | |
| Notification Manual An email notification will be sent to confirm the template has been created/modified. Project Accountant/ | |
| Business Controller N/A | |
| 5.2.3.8. To-be Changes | |
| Project template and master data maintenance for PS is a new process in CT SAP. | |
| CT Sites Changes Business justification | |
| All Sites Implementation of PS is new to all sites. Processes for maintenance of templates and associated master data will be new on all sites where this is being used. Implementation of PS for JM CT | |
| 5.2.3.9. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business justification | |
| None identified | |
| 5.3. Level 3 Business Area β 08.01.02 Perform Project Budgeting & Planning | |
| For JM CT projects planning and budgeting will be available for each project. | |
| β’ Planning β through this functionality in SAP, the users from the different businesses of JM CT will be able to create multiple βversionsβ of cost estimates per project. | |
| o The planning allows the users from the different businesses to plan at: | |
| ο§ Total or annual level | |
| ο§ Cost element level | |
| ο§ Activity level | |
| β’ Budgeting β through this functionality in SAP, the users from the different businesses will be able to limit the amount that can be spent on a project for a specific phase. | |
| o SAP provides an active βavailably controlβ functionality, to allow the user to restrict the amounts that can be spend in a project. | |
| o The budgeting in SAP will operate only at WBS element level. | |
| Note: | |
| These two functions will be available for every business; however, the business can decide to skip the use of planning or budgeting for a specific project. | |
| The recommendation is always to use these two functions to maintain consistency with the process defined and to allow the user to track the history of the budget agreed. | |
| Planning | |
| For Planning purposes in JM CT, the following βcost planning methodsβ have been established and will be available to perform cost planning in a project for each business: | |
| The following table outlines the methods available per business: | |
| Business Level Planning method | |
| Licensing WBS element β’ Total (Overall Planning) | |
| β’ Annual | |
| β’ Cost element (Cost and Revenues) | |
| Activity level β’ Cost element | |
| β’ Activity (man hours) | |
| Formox WBS element β’ Total (Overall Planning) | |
| β’ Annual | |
| β’ Cost element (Cost and Revenues) | |
| R&D WBS element β’ Total (Overall Planning) | |
| β’ Annual | |
| β’ Cost element (Cost and Revenues) | |
| Definitions: | |
| Planning method Description | |
| Total (Overall Planning) With this method, the system will allow the user to allocate an βoverall planning amountβ for the entire duration of the project. | |
| This would be equal to assigning an βoverall amount valueβ for the project, at the highest level of the hierarchy, e.g., WBS-1 in the diagram below. | |
| Annual With this method, the system will allow the user to allocate an βoverall annual amountβ for each year until the project ends. | |
| This would be equal to assigning an βannual amount valueβ for the project at WBS element level. | |
| Cost element level | |
| (Cost and Revenues) With this method, the system will allow the different businesses to plan costs at cost element level (GL account) and at WBS element level. It will be also possible plan at activity level, if required. | |
| For cost planning, there will be created the following planning cost element groups, with the valid range of accounts that can be used by the user to plan costs: | |
| Cost element group Description Business Type | |
| LICE-PLCOST Licensing planning costs Licensing Plan costs | |
| FORM-PLCOST Formox planning costs Formox Plan costs | |
| R&D-PLCOST R&D planning costs R&D Plan costs | |
| LICE-PLREV Licensing planning costs Licensing Revenues | |
| FORM-PLREV Formox planning costs Formox Revenues | |
| R&D-PLREV R&D planning costs R&D Revenues | |
| Currently, is not considered in the scope the planning in a monthly basis. This will be reviewed during the realisation phase. | |
| Activity level With this method, the system will allow the user to plan hours & costs at activity level. | |
| This method will be used, particularly in the Licensing business, to perform the planning of hours on activities. | |
| At the activity level, the user will have available the option to cost activities, assigning the number of units (hours) and the cost associated (activity types in CO). | |
| The JM CT business has currently identified the following set of activities: | |
| Activity type Description Cost element no. Unit | |
| 1000 Normal Hours TBC number (realisation phase) Hours | |
| 1100 Overtime | Mon-Fri TBC number (realisation phase) Hours | |
| 1500 Overtime | Sat-Sun TBC number (realisation phase) Hours | |
| 2000 Overtime | Bank Holiday TBC number (realisation phase) Hours | |
| Planning costs on activities: | |
| CT will not be using salary-based costing of manhours in SAP. This is because salaries are not included in the SAP HR records - salaries are maintained in Workday and for GDPR reasons not transferred to SAP. | |
| Rates will be established for the conversion of hours to costs based on disciplines. This will result in a reduction in the accuracy of the cost conversion as a rate will not match the actual salary cost but this is acceptable to the Finance team. | |
| The current solution is designed to establish as a default, every employee is assigned and needs to be assigned into a specific cost centre in the organization. | |
| This cost centre will work as key pivot to determine their rate. As the diagram shows, the calculation of a rate will be based on the relation between employee (level), cost centre and work centre (discipline). | |
| This is the logic of how the table with the rates will be built in the system and will have to be updated once a year (as a minimum). | |
| Note: | |
| PRB costs will be included in the βcost rateβ, and these costs will be determined outside of the system and will be added into the hourly cost rate within the system. | |
| Planning versions: | |
| JM CT will have available the use of βPlanning versionsβ to produce multiple βsnapshotsβ of the cost situation in a project. | |
| CO planning versions are used to plan costs and revenues in a project. Using CO planning versions, JM CT can define various cost plans for a project, for example, an "optimistic" and a "pessimistic" or even a βforecastβ plan. The user will be able to copy values from one version to another and make manual adjustments in the new version to represent for example a βForecastβ. | |
| For the different JM CT businesses, the following βplan versionsβ will be set up. | |
| Plan versions for Forecast | |
| Plan Version Description | |
| ASS As-sold budget version | |
| CCE Budget approved | |
| M1 Forecast adjustments Jan | |
| M2 Forecast adjustments Feb | |
| M3 Forecast adjustments Mar | |
| M4 Forecast adjustments Apr | |
| M5 Forecast adjustments May | |
| M6 Forecast adjustments Jun | |
| M7 Forecast adjustments Jul | |
| M8 Forecast adjustments Aug | |
| M9 Forecast adjustments Sep | |
| M10 Forecast adjustments Oct | |
| M11 Forecast adjustments Nov | |
| M12 Forecast adjustments Dec | |
| Plan versions for budget adjustments | |
| Plan Version Description | |
| BCE Budget approved | |
| B1 Budget adjustments Jan | |
| B2 Budget adjustments Feb | |
| B3 Budget adjustments Mar | |
| B4 Budget adjustments Apr | |
| B5 Budget adjustments May | |
| B6 Budget adjustments Jun | |
| B7 Budget adjustments Jul | |
| B8 Budget adjustments Aug | |
| B9 Budget adjustments Sep | |
| B10 Budget adjustments Oct | |
| B11 Budget adjustments Nov | |
| B12 Budget adjustments Dec | |
| Through these versions, the user will be able to compare a βbaselineβ version (budget approved) vs previous versions or vs a forecast version to determine and document variances. | |
| Plan versions will be provided to allow monthly versions. Not all versions need to be used and it is anticipated that the frequency of use will vary across a Licensing project. | |
| Formox projects tend to work on a quarterly review and so they will not use all the versions available either. | |
| If in a month (e.g., Jan) there are no changes in the plan and this happen for Feb and March, then the user will continue using this version (Jan), as the official plan until the project requires changes in the plan. | |
| Budgeting | |
| For Budgeting purposes in JM CT, the following βBudgeting methodsβ, will be available to allocate the budget approved in a project. | |
| The following table describes the methods available per business: | |
| Business Level Budgeting method | |
| Licensing WBS element β’ Total | |
| β’ Annual | |
| Formox WBS element β’ Total | |
| β’ Annual | |
| R&D WBS element β’ Total | |
| β’ Annual | |
| Definitions: | |
| Budgeting method Description | |
| Total (overall budget) With this method, the system will allow the user to allocate an βoverall budget amountβ for the duration of the project. | |
| This would be equal to assigning an βoverall amount valueβ for the project, in the highest level of the hierarchy or at WBS element level, e.g., WBS-1 in the diagram below. | |
| Annual With this method, the system will allow the user to allocate an βoverall annual amountβ for each year until the project ends. | |
| This amount is what the system will use to control the budget spent, through the use of availability control on a project. | |
| Note: | |
| It is anticipated that there will be a degree of automation available, the details will be developed during Realisation. As part of this, the user will have available some additional functionality, to allow the upload of the budget and planning automatically at a certain level. | |
| This will be reviewed during the realisation phase. | |
| Availability control in projects: | |
| Availability control (AVAC) compares the current distributed budget (or released amount) with the assigned value (actuals), issuing a warning by email and error messages when budget exceeds that available within the βTolerance Limits Settingsβ. | |
| β’ When a project is being executed, the available funds are used at various places within the Project including when Commitments are created, and actual costs are incurred. | |
| β’ Availability control monitors funds using budget allocation. By entering business transactions that create cost assignments, the system checks whether there is still sufficient budget available for the Project. | |
| β’ Assigned funds can be found in the budgeted WBS element and in the lower-level assignable WBS elements. | |
| β’ To ensure that the available funds are not exhausted at an early stage, the budget can be released in stages, with AVAC activated on the Released Budget Amount. | |
| The tables below detail the tolerance limits within availability control which will be enabled for each business area: | |
| Licensing | |
| Tolerance Limit for Licensing 70% 90% 100% | |
| Actions Warning Warning with an email to the person responsible Warning with an email to the person responsible | |
| Formox | |
| Tolerance Limit for Formox 70% 90% 100% | |
| Actions Warning Warning with an email to the person responsible Warning with an email to the person responsible | |
| R&D | |
| Tolerance Limit for R&D 70% 90% 100% | |
| Actions Warning Warning with an email to the person responsible Warning with an email to the person responsible | |
| Note: | |
| The intent of Availability Control is to provide warnings only - there is no intent to restrict spend on projects in CT at the present time. The use of this feature is optional and exact limits can be adjusted. We will establish the correct settings for each business during the build. | |
| The user will be able to switch on or off this functionality for a specific project or for multiple projects. | |
| Planning Process: | |
| During the project planning and development process, each business is expected to continue using the different tools currently in place to establish costs/budgets. This will enable them to develop the costings/budget during the development and quotation phase using these familiar off system tools. | |
| Once the final version (costing version) has been agreed and approved, the cost engineer will copy and update manually the planning version in SAP. | |
| The above diagram shows how the plan version βXβ with an initial cost estimate made at WBS element, has been copied into the version βYβ but with some amendments made in the plan costs on the WBS elements WBS-142 and WBS-143. | |
| In this case, the user had the option to create a new plan version, using an existing plan as the basis and then make corrections on the new version, to create the new plan version or forecast version. | |
| The different business will have at least one plan version per month for βbudgetingβ and βforecastβ. | |
| 5.3.1. Process: 08.01.02.01 Perform Budget for Project Spend | |
| For the JM CT businesses, the process will start by the manual upload of the final approved budget into the appropriate plan version in SAP. Once this version has been uploaded into the system, the cost engineer can copy this to a working budget version, if required, (e.g., Cost Control Estimate in Licensing) and perform any additional adjustment to create the final version approved. | |
| The approved cost structure (planning version approved) for executing a project is documented by distributing the budget to the WBS elements of the project. This typically occurs during the approval phase before the start of the project execution phase. | |
| Project reporting in SAP PS allows for the evaluation of the budget values together with the planned vs actual costs. | |
| The following budgeting functions from PS will be available for the different JM CT businesses: | |
| 1. Original Budget | |
| 2. Budget Supplement | |
| 3. Budget Transfer | |
| 4. Budget Return | |
| 5. Budget Release | |
| Functionality Description | |
| Original Budget In CT the Original Budget will be maintained during the initial stage of the project when there is a need to allocate funds and have control of expenditure throughout the project life cycle. Ideally, this will be one-time activity and any change to the original budget will be done through budget update functionality as detailed in the Functional Design Document. | |
| Supplements If the funds provided are not sufficient, the system enables the use of budget supplements to increment the budget approved in a project. | |
| Transfers In CT transfer budget functionality will be intended for transfers between WBS within the same project and available for transfer among WBS elements of different projects. | |
| Returns In CT this function will allow us to return unused budget on a WBS element to the top-level WBS element in the project thereby increasing the distributable amount in the project. | |
| Budget Release In CT we will leverage the standard SAP functionality of approving partial or total budget originally allocated to the project. Management in CT may try to optimise the use of funds and hence this additional step of budget release will be defined. This will also be done to ensure the original available budget is not exhausted at an early stage of the project and so we can release the budget in stages. | |
| Through the cost & revenue planning option in SAP, the different businesses from JM CT will be able to produce multiple planning versions at cost element level for project costs and revenues. | |
| The revenues will be assigned and copied into the project from the revenue plan (billing plan) on the sales order assigned to the project. | |
| 5.3.1.1. Level 4 Process Flow and Steps | |
| 08.01.02.01 Perform Budget for Project Spend | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Finalise Estimate/ Budget inc. approvals Manual The final estimate/budget for the project is approved by the business and ready to be uploaded and input into SAP. Cost Engineer N/A | |
| Import Estimate/ Budget into SAP as a plan SAP Manual upload of the finalised cost plan/budget version into SAP PS. | |
| This will be a manual process, where the user will have to type manually in SAP the values planned in the cost estimators or excel. Cost Engineer CJ40 | |
| Copy Plan version to budget plan version SAP Copy the plan version to the budget in a Project. | |
| The user will use this transaction to copy values from one version into another. Cost Engineer CJ9d | |
| Confirm project budget plan version correct in SAP SAP Verifying the Project budget has been correctly input into SAP. | |
| The user will perform a review to verify that the plan budget has been copied correctly. Cost Engineer CJ30 | |
| Copy budget version to Budget for Availability Control SAP Once the budget version has been confirmed, it will be copied into the βbudgeting functionalityβ to allow the system to activate the βavailability controlβ. | |
| The availability control gets activated on the copied budget version Cost Engineer CJ30 | |
| Project Budget released SAP The budget gets released Partially/Fully as per the project requirement. Once the Project budget gets released, the notification will be sent to the Project Manager. Project Manager CJ32 | |
| Release Project/ WBS Elements SAP Once the Project budget is released the Project Manager can release the Project/WBS elements for Project execution. Project Manager CJ20n | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| PS&TM 08.01.01.02 Create & Maintain Projects This process has been described in section 5.2.2. | |
| A budget cannot be estimated for a project unless the project has been created first. | |
| RTR 03.09.04 Maintain activity types This process describes the setup of the activity types for projects. | |
| Through activity types, the user will be able to plan and to allocate costs into a project, especially for timesheet costs. | |
| PS&TM 08.01.02.02 Perform project forecasting The user will be able to create a forecast version from the actual or current version. | |
| PS&TM 08.01.02.03 Perform project amendment (Over/Under) The user will have the option to modify an existing plan or budget version. | |
| STC 02.04.01.05 Create/Modify customer order with project The user will be able to request the modification of revenue plan in a sales order. | |
| Every customer sales order will have to be created with reference to a project (WBS element), to guarantee that the dates established on the billing plan will be inherit correctly into the forecast of the project. | |
| STP 01.04.01.01 Create Purchase Requisition Purchase requisitions will be created with reference to the project structures. | |
| For materials and services, these will be able to be ordered for a project following this process. | |
| The procurement department will have to receive the request and the PR will have to be processed in the system, but without have been triggered automatically by the release of the activity. | |
| TBC TBC Concur integration Concur will be used to allow the users to allocate and projects to receive charges (costs) from travel expenses reports; PS will be able to also transfer the budget to Concur. | |
| This interface will be defined during the realisation phase. | |
| 5.3.1.2. To-be Changes | |
| Project planning and budgeting is a new process in JM CT SAP. The users from the different CT businesses will be able to plan βbudgetβ versions (plan versions) in SAP. The current planning process for the different JM CT businesses will be adapted and planned in SAP. | |
| CT Sites Changes Business justification | |
| All Sites Adoption of project planning versions to update and control budget and planning versions. Standardisation of the process for planning budgets in projects. | |
| All Sites Adoption of the availability control in projects for the administration of the budget online. Implements controls around budgets in projects. | |
| 5.3.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business justification | |
| Agresso Existing processes for budget management will need to be adapted to use plan versions in SAP. Entry of data into CT SAP will be new to people as much of this activity is currently undertaken in Excel. Standardisation and implementation of reporting and tracking of costs/budgets and forecasts in SAP. | |
| Perstorp Existing processes for budget management will need to be adapted to use plan versions for Projects in SAP. Existing processes use plan versions but for Internal Orders Standardisation and implementation of reporting and tracking of costs/budgets and forecasts in SAP. | |
| Other existing SAP sites Budgeting is currently not planned to be used for other project types (R&D etc.). Standardisation and implementation of reporting and tracking of costs/budgets and forecasts in SAP. | |
| 5.3.2. Process: 08.01.02.02 Perform Project Forecasting | |
| Using the cost & revenue planning option in SAP, the different businesses within JM CT will be able to produce multiple planning versions at cost element level for project costs and revenues. | |
| In other words, a planning version that reflects the current situation in a project, can be used as point of start to create a forecast. | |
| As previously described, the user will be able to create a copy of the current plan and then perform adjustments in the new version to create their new forecast for the project. | |
| In summary, the businesses will be able to plan and track costs and revenue on planned versions created as well as produce forecasts for projects. | |
| The information from SAP will flow into the wider financial forecasting processes outside of Project Systems. | |
| Changes to the billing plan will impact the invoicing on a project but not the revenue recognised. Invoices raised to a client will not be considered by the revenue recognition process, established for the different CT businesses. | |
| Project Manager will provide to the cost engineer (in Licensing) with any updates/changes to be made, in a similar fashion to the existing process, i.e., reviewing and marking up a cost report. | |
| 5.3.2.1. Level 4 Process Flow and Steps | |
| 08.01.02.02 Perform Project Forecast | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Send revised forecast details Manual Changes required to the plan will be documented and sent to be updated on the system in the corresponding project. | |
| The changes will be made in excel or other legacy tools and then will be updated into SAP. Project Manager N/A | |
| Copy plan to next version SAP A new planning version will be created by making a copy from the current version into a new one. | |
| There will be available for the user, one plan version per calendar month and one plan version for budgeting purposes. | |
| Each business will decide how often these versions need to be updated. Finance Controller/ Cost Engineer CJ9B | |
| Modify new plan version SAP The new version will be modified in accordance with the changes to the forecast requested by the project manager. Finance Controller/ Cost Engineer CJ40 | |
| Perform changes on cost (primary cost elements) SAP The changes will be performed at cost element level, according to the list of βvalid costsβ that can be planned in a project. Finance Controller/ Cost Engineer CJ40 | |
| Perform changes on revenue (primary cost elements) SAP The changes will be performed at cost element level, according to the list of βvalid revenue elementsβ that can be planned in a project. Finance Controller/ Cost Engineer CJ40 | |
| Notify plan has been updated Manual Confirmation will be sent by email that the plan has been updated. Finance Controller/ Cost Engineer N/A | |
| Updated plan received Manual Notification that the plan has been updated is received. Project Manager N/A | |
| Send details of adjustments Manual The updated plan will be reviewed, and any additional changes required will be sent for updates to be made. Project Manager N/A | |
| Issue updated forecast plan Manual Notification will be issued to confirm the forecast has been updated. Finance Controller/ Cost Engineer N/A | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| PS&TM 08.01.03.01 Capture Project Related Costs The different costs received from the different modules in SAP, will work as point of reference to the user for changes in the forecast. | |
| PS&TM 08.01.04.02 Billing for revenue project Depending on changes performed in the billing plan (dates), the system will amend the revenues at project level and as consequence there will be changes in the forecast. | |
| PSTM 08.01.03.03 Enter and approve time For Timesheets there will be a Fiori interface to allow the users to login and input their timesheets from any browser. This graphic interface will interact in the background with the standard transaction in SAP CATs that will process the times into SAP. | |
| STP 01.04.01.01 Purchase requisition For materials and services, these will be able to be ordered for a project following this process. | |
| The procurement department will have to receive the request and the PR will have to be processed in the system, but without having been triggered automatically by the release of the activity. | |
| PS&TM 08.01.01.02 Create & maintain projects This process allows the user and the different businesses to create a project. | |
| PS&TM 08.01.05.01 Perform Project Reporting Budget/Actual/Commitment/Plan Once the forecast has been updated, the user will have the option to execute several reports to present the information. | |
| This process describes the different reports that will be available for the user. | |
| 5.3.2.2. To-be Changes | |
| Project planning of costs, revenues and the associated forecasting in SAP is a relatively new process in JM CT. Some parts of the organisation have used similar processes before with Internal Orders, but the new processes use these techniques more extensively and with Projects rather than Internal Orders. Through implementing these processes, the JM CT user will be able to generate different plan and budget versions per project and perform the associated forecasting of project revenue and costs. | |
| CT Sites Changes Business justification | |
| All Sites There must be a sales order created and linked into a project, to allow the user to visualise the planned revenues in a project. | |
| Standardisation of the process for planning budgets in projects. | |
| All Sites The move to a more extensive use of plan versions in SAP will be a change for all sites. In addition, the use of these with projects will be new to all sites. Standardisation of the process for planning budgets in projects. | |
| All business The creation of a project is considered as βmaster dataβ; however, it has already been agreed that every business will establish their own responsible person to create new projects in the system as per business needs and requests. | |
| Every business will have autonomy to create and administrate their own projects. The main target is to provide autonomy to every business to create their own projects, without the intervention from the global master data team. | |
| 5.3.2.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business justification | |
| Agresso Existing processes for planning and forecasting will need to be changed to use plan versions in SAP. Entry of data into CT SAP will be new to people as much of this activity is currently undertaken in Excel with some interaction with Agresso. Standardisation and implementation of reporting and tracking of costs/budgets and forecasts in SAP. | |
| Perstorp Existing processes for planning and forecasting will need to be adapted to use plan versions for Projects in SAP. Existing processes use plan versions but for Internal Orders Standardisation and implementation of reporting and tracking of costs/budgets and forecasts in SAP. | |
| Other existing SAP sites Project Forecasting is currently not planned to be used for other project types (R&D etc.). Standardisation and implementation of reporting and tracking of costs/budgets and forecasts in SAP. | |
| 5.3.3. Process: 08.01.02.03 Perform Project Amendment (over/under) | |
| During the execution of a project, it is possible that an additional budget will be required or that budget will be moved within a project. This process allows these changes to be made to the project budget within SAP and ensures that this is reflected in any reporting. Additional controls are in place to ensure that the budget cannot be increased without the appropriate approvals. | |
| Additions to Budget | |
| Any addition (increase) in a project budget will need to be approved before it can be reflected in the project. This is likely to arise from a change in project scope that has been agreed with the customer (change order) or other change that has been agreed to be taken on by the project and hence as this increases the budget approval of the change is needed. | |
| The user will also have the following options to make changes in the budget from a project: | |
| Supplements: | |
| If the funds provided are not sufficient, the system enables the use of budget supplements, which can be used on projects in CT. | |
| There are two types of supplements for projects. | |
| A) In The Project | |
| A Supplement can be made in the project from the top-down, from the higher-level WBS element to the lower level. We can supplement only as much budget on a WBS element, as is contained in the higher level. | |
| B) To The Project | |
| Making a supplement to a project means providing a selected WBS element with the additional external budget. This is independent of the remaining budget on the higher level. The system updates the supplemented budget on the WBS upwards. | |
| Devolutions: | |
| In CT, devolutions are not considered, however the functionality will be available for the user. | |
| Transfers: | |
| In CT transfer budget functionality will be intended for transfers between WBS within the same project and applicable for transfer among WBS elements of different projects. | |
| Returns: | |
| In CT this function will allow us to return unused budget on a WBS element to the top-level WBS element in the project thereby increasing the distributable amount in the project. This can be used when the activities against a WBS element have been over-budgeted. | |
| Budget Reallocation | |
| During the execution of a project, particularly complex licensing projects, it is likely that the project manager may wish to move budget from one element to another within the project. As this does not lead to an increase in the overall project budget this change does not require approval. | |
| 5.3.3.1. Level 4 Process Flow and Steps | |
| 08.01.02.03 Perform Project Amendment (over/under) | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Change to budget identified Manual Project Manager identifies a need for the budget to be changed, raises a request for additional budget or budget transfer within the project Project Manager N/A | |
| Request budget transfer within Project Manual Project Manager requests the transfer of budget within the project. Project Manager N/A | |
| Request for additional budget Manual The Project Manager requests an additional budget. Following approval, the budget will be amended on the project. If it is not approved the Project Manager will be informed and no change made. Project Manager N/A | |
| Cost plan/Budget version to next version SAP Copy the plan or budget version to the next version using T-code CJ9b Cost Engineer/ | |
| Project Accountant CJ9b | |
| Update budget plan/version SAP Update the budget plan version by using T-code CJ40 Cost Engineer/ | |
| Project Accountant CJ40 | |
| Copy budget version for Availability control SAP Copy the planned version for availability control using T-code CJ30 Cost Engineer/ | |
| Project Accountant CJ30 | |
| Budget Release SAP Release the partial/overall budget for the Project execution using T-code CJ32 Cost Engineer/ | |
| Project Accountant CJ32 | |
| Notification for completion of budget change Manual Notification sent to the Project Manager after completion of the budget change Cost Engineer/ | |
| Project Accountant N/A | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| PS&TM 08.01.02.02 Perform Budgeting for project spend Budgeting of projects is a pre-requisite for needing to make amendments to budgets | |
| 5.3.3.2. To-be Changes | |
| Project budget changes are used in existing CT processes, but the use of Project Systems will lead to changes in the current processes and systems being used. | |
| CT Sites Changes Business justification | |
| All sites The existing processes for changes to project budgets will need to be adapted to use the new SAP PS structures and processes. Existing approval routes will be used to manage changes of budget prior to updates being made in SAP Standardisation of the use of SAP PS for managing projects | |
| 5.3.3.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business justification | |
| Agresso Existing processes for changes to project budgets will be adapted to use SAP. Changes in budget allocation within a project will continue to be made by the Project Manager without additional approval. Changes to the overall budget and the associated approvals process will continue off the system prior to entry into SAP Standardisation of the use of SAP PS for managing projects | |
| Perstorp Existing processes for changes to project budgets will be adapted to use SAP Project Systems rather than the existing use of Internal Orders. Standardisation of the use of SAP PS for managing projects | |
| Other existing SAP sites Budgets and hence amendments are currently not planned to be used for other project types (R&D etc.). Standardisation of the use of SAP PS for managing projects | |
| 5.4. Level 3 Business Area β 08.01.03 Capture Project Costs & Timesheets | |
| SAP Project System is closely integrated with other SAP modules like Logistics, Material Management, Sales and Distribution, Plant Maintenance and Production Planning module. | |
| The integration between the SAP Project System with the rest of the application modules will allow JM CT to design, plan, and execute the projects as part of the new process defined for JM CT. | |
| The following diagram shows the points where SAP Project System will integrate with other modules: | |
| The table below describes the different integrations already mapped between PS&TM and other workstreams (SAP modules) for the different JM CT businesses: | |
| Modules Description Licensing Formox R&D | |
| RTR | |
| (Finance and Controlling) Actual costs and postings will come from RTR as: | |
| β’ Overheads | |
| β’ Journals | |
| β’ Payments | |
| β’ Goods/services receipts In scope In scope In scope | |
| STP | |
| (Materials Management) Commitments will come from the creation of: | |
| β’ Purchase requisitions | |
| β’ Purchase orders In scope In scope In scope | |
| STC | |
| (Sales and Distribution) Revenue will be assigned into projects in two ways: | |
| β’ Planned revenues | |
| These will be inherited into the project from the billing plan established on the sales orders. | |
| β’ Actual revenues | |
| These will come from invoices raised to the clients. In scope In scope In scope | |
| Workday | |
| (Human Resources) To manage the processing of timesheets, it will be required to enable the setup a βmaster recordβ for employees. | |
| There will be an interface between Workday and SAP, to transfer basic information about employees to allow them to process their timesheets In scope In scope In scope | |
| TS | |
| (Time sheeting) Timesheets in SAP will be a new functionality, to allow employees in JM CT to process their weekly timesheets in the system. In scope In scope In scope | |
| 5.4.1. Process: 08.01.03.01 Capture Project Related Costs | |
| Organizational structure | |
| In Project Systems every project (via WBS elements) will become a cost collector that will be assigned to specific financial structures. | |
| In general, each time a project receives a posting from finance (cost allocation), the posting will be assigned to the following financial structures as a minimum in accordance with the requirements of the following businesses: | |
| β’ Licensing | |
| β’ Formox | |
| β’ R&D | |
| The following table summarises the main organisational structures that will be required to be used by the different CT businesses. | |
| Business Company code Cost elements Controlling area Profit Centre Plant | |
| Licensing Required Required Required Required Required | |
| Formox Required Required Required Required Required | |
| R&D Required Required Required Required Required | |
| The financial organisational structure establishes the company and P&L where all the charges received by the project will be assigned. | |
| Main PS&TM integrations with STP, STC and RTR. | |
| Integration with procurement (STP) | |
| Purchase Requisition Process Overview: | |
| The purchase requisition process refers to the flow of events that are triggered when any department needs to make a purchase. | |
| A purchase requisition is an internal document in SAP. It is used to give notification to the purchasing department of requirements for materials or services. Purchase requisitions can be created with reference to MRP/Planned order or can be created manually. Once it is created it will be sent for approval based on the approval matrix. | |
| Any PR with reference to a project will have to be created manually by the user or requestor area. The current design does not include the automatic order of materials or services triggered by the releasing of activities in a project. | |
| Purchase requisitions (PR) will be created across all sites in CT to procure direct, indirect, and service materials. Most of the direct purchase requisitions will be triggered by MRP or planned orders at most sites. Use of scheduling agreements for raw materials should be deployed at the same time as MRP use. There should be a logged dependency on each project. | |
| Reference: L4 Process 01.04.01.01 Create Purchase Requisition. | |
| Integration with Sales (STC) | |
| This process is intended to be used wherever the JM CT business activity is managed using SAP projects that include elements of customer invoicing. For example: | |
| β’ Licensing | |
| β’ Formox Plant Designs | |
| SAP supports several approaches to the integration of sales order processing with PS, ranging from the closely coupled approach to a looser, financially focussed integration. An example of close integration would be the so called βEngineer-to-orderβ process. The resulting Quotation reflects the costs and schedule contained within the project. Similarly, it is possible to generate a project from the Quotation itself, using standard project templates; this too results in very close integration between PS and Sales. | |
| The approach documented here reflects a looser, financial integration. The sales order is created using standard sales order transactions, namely VA01. The sales document line item is then account assigned to the project by entering the billing WBS element. This ensures that both planned and actual revenue can be reported and reviewed using standard PS reports, and hence the profitability of the project determined. | |
| Upon completion of a milestone, the project manager or administrator will be releasing the line item and collecting the required documentation to support billing. They will manually contact finance to remove the billing block when milestone documentation is completed. Invoicing will not be completed automatically in system. | |
| Invoices generated against the account assigned sales order line-item post with reference to the billing WBS, which must be released to receive revenue prior to invoice generation. This is a new process for JM CT and is intended to provide much improved management of customer billing with respect to complex engineering project and related activities. | |
| Reference: L4 Process 02.04.01.05 create sales order with project | |
| Integration with Finance (RTR) | |
| The Finance team will be able to allocate costs to projects via: | |
| β’ FI Journals being posted directly to a Project β e.g., FI Journals will be posted to the project via transaction FB50 referring to a WBS element. | |
| β’ Financial Allocations, Interest etc. - Distribution or assessment cycle functionalities will be used to allocate cost from a cost center to projects or WBS elements | |
| β’ Postings will also come from procurement and sales via the use of cost elements. | |
| β’ Financial accounting: WBS elements and Networks codes will act as cost objects in Financial Accounting transactions. | |
| With the standard integration between FI and PS, every WBS element and network will become a cost collector that will be assigned to specific organizational structures. | |
| Tech provisions | |
| β’ Tech Provisions will be handled as a cost under License Fee, but not considered as part of the % complete calculation. The process for accrual of Tech Provisions will be finalized during realization. It may be possible to automate this process, and this will be reviewed during realization. | |
| Overheads | |
| β’ Overheads will be handled separately using distribution cycles, the functionality will be confirmed and validated during the realization phase. | |
| Time sheets & intercompany allocations (TM) | |
| JM CT users will have the option to allocate time to projects that do not belong to the company code that they are assigned to. | |
| An engineer, whose office base is in Sweden (for example), working on a project that is managed by the UK, for timesheet processing purposes will ask the UK project manager for the WBS element or Network/activity number where time should be allocated. | |
| There will be an intercompany process defined and operated by finance, to allocate timesheets coming from different business units. | |
| In this case an employee that belongs to a business unit in Sweden, this employee will be able to allocate time into a project that belongs to a UK business unit. This will be possible because during the definition of the corporate structure, it has been defined that every profit centre can receive postings from different business units. | |
| Representation: | |
| In the previous diagram, the movement A) is reflecting the effect that the system will create, when an employee in Sweden is allocating their time into a project that belongs to the UK; The system automatically will generate the effect (postings) using the intercompany accounts defined B). | |
| With these postings created a user in Sweden will be able to report all the time allocated into projects that belongs to a different business unit and at the end of the month, the business unit will be able to raise an invoice for the services provided to the affiliate. | |
| The process requires: | |
| 1. The setup of the intercompany account postings between business units (currently in the scope of RTR). | |
| 2. The process to clear and review the amounts allocated on each business unit during month-end (part of the scope of reporting in PS&TM). | |
| 3. The process to invoice these amounts to the business unit that has requested the works in the project. | |
| Key point: | |
| It is important to mention that at project can start to receive cost allocations (journals, timesheets etc.), only once the project has been released. | |
| There can be cases where because of the dynamic of the business it will be necessary to release a project (or a WBS element only), without have already updated the CCE budget, planning and forecast. | |
| In terms of the operation of the system, this will be a valid scenario, however, for revenue recognition purposes, the system will not be able to calculate it, unless the different forecast values (forecast revenue and forecast cost) have been updated correctly in the system. | |
| 5.4.1.1. Level 4 Process Flow and Steps | |
| 08.01.03.01 Capture project related costs | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Project released SAP Once the project has been released the project will be able to start to receive charges and movements from different modules. | |
| As described above a project can start to receive movements and postings from the following processes: | |
| β’ STP | |
| β’ STC | |
| β’ RTR Project Manager CJ20N | |
| Project execution review and corrections Manual The review of the execution of the project will become a daily, weekly, and monthly process to be executed by the project manager to review the evolution of the costs in a project. Project Manager CJ20N | |
| Project reporting Manual There will be several reports in SAP that will help and support the project managers in performing their reviews of the evolution of every project. Project Manager CJ20N | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| PS&TM 08.01.02.02 Perform project forecast Level 4 process defined to allocate and create a forecast on a project. | |
| PS&TM 08.01.03.03 Enter and approve timesheets Level 4 process defined to create and post timesheets into a project. | |
| STP 05.02.01.02 IM Goods Receipt Level 4 process is defined to generate the reception of goods and services into a project. | |
| STP 01.04.01.01 Create Purchase Requisition Level 4 process is defined to create a purchase requisition with reference to a project. | |
| RTR 03.01.07.01 Process General Ledger Journals Process defined to allocate multiple costs into a project by finances. | |
| STC 02.06.02.01 Create Customer Invoice Process defined to create client invoices for a project. | |
| PS&TM 08.01.03.04 Time administration Process defined to create and to amend timesheets on project. | |
| STC 02.04.01.05 Create Customer Order with Project Process defined to create sales order with reference to a project. | |
| PS&TM 08.01.02.01 Perform Budgeting for project spend Process defined to establish the initial budget for a project. | |
| PS&TM 08.01.07.01 Project Commitments Process defined to allow the user to execute multiple reports to review commitments in projects. | |
| PS&TM 08.01.07.02 Project Revenues Process defined to allow the user to execute multiple reports to review revenues allocated in projects. | |
| The reports also include the revenue forecasts. | |
| PS&TM 08.01.07.03 Project Costs Process defined to allow the user to know all the costs allocated into a project. | |
| The reports will also provide views to compare actuals vs cost forecasts. | |
| PS&TM 08.01.07.04 Project Cash flow Process defined to allow the user to review all the payments made on invoices (providers) with reference to a project. | |
| PS&TM TBC Cost report (Licensing) The Licensing business will have available a report to create and produce their current βcost report for projectsβ. | |
| 5.4.1.2. To-be Changes | |
| The introduction of Project Systems to CT SAP will bring new processes for the administration of projects. | |
| CT Sites Changes Business justification | |
| All sites There will be several new processes that will be integrated with projects to manage the full life cycle of the project. | |
| Project systems will have and will provide strong integration with the all the rest of workstreams as described above. Standardization of the use of SAP PS for managing projects | |
| 5.4.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business justification | |
| Agresso Existing processes for managing projects in Licensing use Agresso and off-system tools. There will be several changes to processes and systems required as a result of the implementation of SAP Project Systems. Additional training on the new processes will be required. Standardization of the use of SAP PS for managing projects | |
| Perstorp The existing process for managing projects in Formox Plant Designs is based on the current use of Internal Orders. Some of these processes will need to be revised and adapted to use Project Systems. Standardization of the use of SAP PS for managing projects | |
| Other existing SAP sites There will be less impact on R&D and other projects due to their simpler nature and lack of budgeting and planning, however there will still be a need to handle issues such as purchasing within Project Systems. Standardization of the use of SAP PS for managing projects | |
| 5.4.2. Process: 08.01.03.02 Maintaining HR Mini Master | |
| HR Mini Masters will be used by JM CT to access employee profile information for Time Sheeting purposes. An interface with Workday will transfer the information required into SAP related to the master record and details of the employees (as shown in the diagram below). | |
| β’ Workday β Workday is the corporate system selected by JM, to manage all the personal information for all employees. | |
| β’ Middleware β the middleware (SAP PI/PO) will be used to administer the mapping and flow of the information between both systems. | |
| β’ SAP β SAP CATS is the system to be used by CT to allow the employees to process and generate timesheets. | |
| The interface between Workday and SAP HR, will support the transfer of information for the following info types. | |
| β’ 000 (Actions) | |
| β’ 001 (Org-Data) | |
| β’ 002 (Personal data) | |
| β’ 007 (Planned working hours) | |
| β’ 0105 (Communication) | |
| β’ 315 (Timesheet Default) | |
| Note: | |
| IT0007 record from HRMM will provide planned working hours, which will be used as target working hours in CATS Timesheet and will be defaulted for each employee in the Fiori Interface. Users can edit the time as per their actual working hours, and the system will provide a warning message when the hours booked are over or under the target working hours. | |
| IT0007 will also provide details about public holidays, as per the work schedule rule, however public holidays/target hours will only be for display purposes. | |
| Note: | |
| IT0315 record from HRMM will be used to default controlling area and Activity Types for each employee depending on their discipline. These defaults will be available for each employee in their Fiori interface and can be edited if needed. | |
| SAP HR Infotypes are the information units that are used in the SAP Human Resource Management System. SAP HR Infotypes keep the information in structured way that facilitate the use of this data in SAP. | |
| Note: The detail of this integration remains to be confirmed with the Workday team. | |
| The interface will transfer the necessary information into SAP to allow employees to process their timesheets on a weekly basis. | |
| Employee Records: the creation of HR Mini Masters based on the data available in Workday is intended to be automated. The details of this interface are still to be finalised due to limited access to the Workday team at present. | |
| Note: For more information, please refer to the FDD document section 02.05.02.01 | |
| 5.4.2.1. Level 4 Process Flow and Steps | |
| Figure 11 β 08.01.03.02 Maintaining HR Mini Master | |
| 08.01.03.02 Maintaining HR Mini Master | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| 1. Non-SAP Workday File Transfer | |
| Workday is the corporate system used by JM, to manage personal and payroll information for all employees. | |
| Data will be sent from Workday to SAP. This process will be automated, details of which will be confirmed during the build phase. | |
| The file format to be used will be confirmed during the build phase. NA NA | |
| 2. SAP Middleware | |
| Middleware (SAP PI/PO) will be used to manage the mapping and flow of information between the systems. | |
| Once the HRMM configuration is completed, an employeeβs mini master data can be replicated from Workday to SAP via this process. NA NA | |
| 3 SAP File Preparation | |
| The data file will be prepared by the middleware in a format suitable (expected to be XML) for SAP upload. NA NA | |
| 4. SAP Update of SAP Info types | |
| SAP CATS is the system being used by CT to allow the employees to process and generate timesheets. | |
| SAP will receive the data file (XML) from the middleware and update the following Info types: | |
| IT0000, IT0001, IT0002, IT0007, IT0105 and IT0315 NA PA20/PA30 | |
| The following data fields are the key fields identified between Workday and SAP HR required to enable implementation of HR Mini Masters for JM CT: | |
| Field Mandatory / Optional | |
| Personnel number Mandatory | |
| End Date Mandatory | |
| Start Date Mandatory | |
| Action Type Mandatory | |
| Action Reason Mandatory | |
| Company Code Mandatory | |
| Personnel Area Mandatory | |
| Employee Group Mandatory | |
| Employee Subgroup Mandatory | |
| Personnel Subarea Mandatory | |
| Organizational Unit Mandatory | |
| Position Mandatory | |
| Job Mandatory | |
| Last Name Mandatory | |
| First Name Mandatory | |
| Middle Name Mandatory | |
| Personnel ID number Mandatory | |
| Work Schedule Rule Mandatory | |
| Employment Percentage Mandatory | |
| Daily Working Hours Mandatory | |
| Weekly working hours Mandatory | |
| Monthly working hours Mandatory | |
| Weekly workdays Mandatory | |
| End Effective Date Mandatory | |
| Start Effective Date Mandatory | |
| Communication Type Mandatory | |
| Communication ID/Number Mandatory | |
| Controlling Area Not Mandatory | |
| Activity type Not Mandatory | |
| This information will be transferred into SAP and will allow employees to process their timesheets. | |
| For a JM CT employee this process of data transfer will be completely transparent, and they will not have to perform any additional action in SAP. | |
| 5.4.2.2. To-be Changes | |
| The implementation and maintenance of HR Mini Masters are new processes in JM CT SAP. In order to enable CT users to allocate time to projects HR Mini Masters are required. Updating and maintaining the HR Mini Masters is critical to ensure that this information is kept up to date. This will be a new process for all the parts of CT that will be using time sheets. | |
| CT Sites Changes Business Justification | |
| All Sites Implementation of HRMM is new to all sites. Implementation of HRMM for JM CT employees to enable time sheeting in SAP | |
| 5.4.2.3. Site Specific Changes | |
| The implementation of HR Mini Masters for time sheeting will be new to the CT SAP system and hence this process will be new for all parts of CT concerned. No specific site changes are anticipated related to this process. | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.4.3. Process: 08.01.03.03 Enter & Approve Time | |
| An SAP Fiori interface will be developed to enable JM CT employees to prepare and submit their timesheets on a weekly basis. | |
| What is SAP Fiori?. | |
| Fiori is a streamlined application, delivering a role-based user experience that can be personalised across all lines of business, tasks, and devices. It uses tiles to encapsulate standard tasks like viewing sales orders or approving timesheets. | |
| This provides a user-friendly web application for inputting time sheet data. The layout the interface will display, will be based on the entry profile defined for each business (Licensing, R&D and Formox). | |
| The Fiori interface: | |
| β’ Will be used to enter as well as approve the timesheets. | |
| β’ Is web-based, accessed via a browser and a user-friendly GUI. | |
| β’ Makes filling and approving timesheets a simpler experience which can be done from anywhere on any device with appropriate authorisations. | |
| Classic Fiori interface | |
| Time Sheet Approval | |
| Timesheet approval helps to track which employees' timesheets have been checked for accuracy before closing out the pay period | |
| The process will enable line managers to review, approve and reject timesheets for all employees. | |
| Line managers will approve timesheets, in line with the approach currently being used in JM CT. | |
| Line managers will reject timesheets, in line with the approach currently being used in JM CT and the following timesheet rejection reasons will be available. | |
| Code Timesheet Rejection reasons | |
| REJ1 Hours booked to incorrect number | |
| REJ2 Incorrect number of hours booked | |
| REJ3 Incorrect overtime booked | |
| REJ4 Incorrect work centre used | |
| REJ5 Other error in timesheet | |
| For JM CT the following status codes have been defined, to identify the stage for each time sheet during the approval process. | |
| Note: These Status codes can be viewed using SAP standard report CATS_DA. CATS_DA is not available on the standard Fiori interface and so requires SAP access. | |
| Note: Timesheet filling, release, submission, and approval will be done via Fiori interface. | |
| Note: For more details, please refer to FDD section 2.5.2.3. | |
| Status Short description Description in the context of JM CT | |
| 10 In process The record is being processed and is not yet ready for transfer to the target components (Controlling). | |
| 20 Release for approval The record has been released and is ready for approval or rejection by the line manager. | |
| 30 Approved The record has been approved and is ready for transfer to the target components (Controlling), to convert hours to cost. | |
| 40 Approval rejected The record has been rejected by line manager. It cannot be transferred to the target components (Controlling). | |
| 50 Change after approval An approved record has been changed. The original record is assigned this status until the new record has been approved. | |
| 60 Canceled The record was cancelled after approval. | |
| Process: | |
| The creation of projects will be managed within the business and will follow a similar process today. For example, in Licensing it is expected to use an updated version of the CWA. | |
| Once approved, the project can be set up using the templates provided alongside the creation of a Sales Order and necessary customer record. | |
| Once this is done employees will be able to book time to the WBS elements that have been set up, even if budget has not been assigned, provided the WBS element has been opened to allow bookings. | |
| Allocation of Rates per activity (discipline): | |
| The allocation of time into projects will be covered by the uses of SAP βactivity typesβ. Project concert will establish βactivity ratesβ based on an average rate per βdisciplineβ. | |
| Example: (Licensing) | |
| In this case the average rate will be established at discipline level and will be determined by the βWork Centreβ in SAP: | |
| Description (Discipline) SAP WBS Level 4 | |
| Engineering 10 | |
| Process 20 | |
| R&D 30 | |
| Projects 40 | |
| Others 60 | |
| βWork Centresβ will be defined in SAP for the disciplines in the table above and work centre will be an attribute that will be input in the timesheet by the employee. | |
| The following table details the activity types defined for the different CT businesses to allocate time into projects: | |
| Activity type Description | |
| 1000 Normal Hours | |
| 1100 Overtime | Mon-Fri | |
| 1500 Overtime | Sat-Sun | |
| 2000 Overtime | Bank Holiday | |
| This list will be reviewed during the realisation phase, to confirm ifβs necessary add new activity types required by the CT Businesses. | |
| For timesheet purposes, an employee will input in the Fiori app the following data: | |
| 1. Project or projects (WBS element) where he wants to allocate their time. | |
| 2. Activity type that refers to the type of work performed (e.g., 1000 Normal hours). | |
| 3. Work centre, that will determine the βDisciplineβ. | |
| With this combination of values in the fields, the system will be able to calculate the rate for the activity and then establish the cost to be allocated into the project. | |
| Example: | |
| Cost centre Work centre Activity type Unit/Measure Unit Rate per h. | |
| C100 W100 1000 Hr 1 Β£ 45.00 | |
| C200 W100 1000 Hr 1 Β£ 35.00 | |
| C300 F100 1100 Hr 1 Β£ 55.00 | |
| C400 F200 1100 Hr 1 Β£ 65.00 | |
| The previous table shows how the rates will be setup in the system, this table will have to be maintain at least once a year or depending on business requests. | |
| The following example shows how the system will make the conversion of hours to cost: | |
| An employee βJohn Doeβ creates a timesheet with 40hrs for the discipline βW100 design engineeringβ and the activity type 1000 Normal hours. | |
| Employee John Doe | |
| Cost centre C200 | |
| Activity Type 1000 | |
| Work centre W100 | |
| Note: by default, every employee will be assigned into a cost centre, and this will come from Workday. | |
| In this case, the system will perform the following logic: | |
| John Doe is assigned to the Cost Centre C200 (because this is the area within the company where he belongs), so the system will make the following calculation: | |
| 40 Hrs. multiplied by the rate from the table where the Cost Centre is equal to C200, Activity Type 1000 and Work Centre (discipline) W100. | |
| Cost centre Work centre Activity type Unit/Measure Unit Rate per h. | |
| C100 W100 1000 Hr 1 Β£ 45.00 | |
| C200 W100 1000 Hr 1 Β£ 35.00 | |
| C300 F100 1100 Hr 1 Β£ 55.00 | |
| C400 F200 1100 Hr 1 Β£ 65.00 | |
| As a result, the system will allocate into the project the cost of Β£35 GBP X 40 hrs = Β£1,400.00. | |
| The table with the rates per activity and work centre will have to be created per business (Licensing, Formox and R&D) and will be part of the initial setup of the system. | |
| 5.4.3.1. Level 4 Process Flow and Steps | |
| Figure 12 β 08.01.03.03 Enter and Approve Time | |
| 08.01.03.03 Enter & Approve Time | |
| L4 Process Step System / Manual Narrative Step owner SAP | |
| T-Code | |
| Time entry via Fiori application Non-SAP Time Entry via Fiori App | |
| Every JM CT Employee will be provided with SAP Fiori interface URL, with username and password to submit and access weekly timesheets. | |
| During the realization phase of the project the final list of end users that will have access to this functionality will be confirmed. | |
| Delegates can be assigned and allowed to fill in timesheets on behalf of another user. | |
| The Fiori interface will also be used to approve or reject the timesheets. User NA/ URL | |
| Time Entered in CATS released and sent for approval (CATA) SAP Time Entry in CATS | |
| Every entry made by a CT employee in the Fiori interface will redirect to CATS Time sheeting in SAP(CATA) in the background. | |
| Note: Users/Approvers need not know about the SAP interface, as all the timesheet related processes are done via the Fiori interface | |
| Hours will be submitted weekly, saved, released, and sent for approval. | |
| Approvers will receive an email notification that a timesheet is ready for approval. | |
| Approval will be done via the Fiori interface by the line managers User URL | |
| Timesheet Approval/ | |
| Rejection SAP Approval/Rejection | |
| Depending on the timesheet data, the approver can either approve or reject the timesheet. If the timesheet is approved, it will be sent to finance and internally the hours will be converted to costs. | |
| If the timesheet is rejected, the employee/delegate will need to re-enter the timesheet and send it back for approval. Approver NA/URL | |
| Timesheet Transfer to Controlling SAP Transfer to Finance | |
| After the timesheet has been approved, the hours from the timesheet will be moved to Finance/Controlling via an automatic process and converted to cost by using activity rates maintained per activity. Finance CAT7/KP26 | |
| The following fields are required for the time sheet entry, Initial Entry screen | |
| Key Fields Description Mandatory / Optional | |
| Data-entry profile The Data Entry profile is a profile that will be created for each business: R&D, Licensing and Formox. It will define for each business group the customised fields they want to see in their timesheet, also the default fields that need to be shown while filling timesheets. | |
| This enables the businesses to default on some general settings relating to displaying weekdays or workdays only, displaying target hours etc. It can also be used for time settings like the number of weeks to be displayed etc. | |
| This will be configured during the configuration phase. Mandatory | |
| Personal Number Employee number filling in the timesheet Mandatory | |
| Key Date The key date determines the period for which you should enter or display times Mandatory | |
| The following fields are required in timesheet entry | |
| Key Fields Description Mandatory / Optional | |
| Cost Centre Cost center is a field within the organizational unit, that defines the location of cost incurrence. | |
| Cost Centre can be defaulted while filling the timesheets from the HR Mini master. Mandatory | |
| WBS Element A work-breakdown structure element is a way of breaking down a project into smaller components. A work breakdown structure is a key project deliverable that organizes the team's work into manageable sections | |
| The user will have to type manually the WBS (project) where he wants to allocate their time. | |
| The user will have the option to assign time to multiple projects in the same timesheet. Mandatory | |
| Activity Type Activity types describe the activity produced by a cost center and are measured in units of time. | |
| Activity types can be selected from the list of drop downs available and can also be defaulted from HR Mini master. Mandatory | |
| Hours Total number of weekly hours utilized by an employee. Mandatory | |
| Work Centre Allocated work center as per JM disciplines Mandatory | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| RTR 03.09.04 Maintain Activity Types As part of the new Project Systems approach, it will be necessary to setup activity types to manage costs on timesheets. | |
| PS&TM 08.01.01.02 Create & Maintain Projects This level 4 process describes the creation of project in the system. | |
| To allow any user to create their timesheets, it will be necessary to create the project first. | |
| PS&TM 08.01.02.01 Perform Budgeting for Project Spend This process describes how the budget needs to be assigned into the project before it can start to receive any costs. | |
| The user will not be able to complete any timesheet entry unless the project has been released or the budget has been assigned. | |
| RTR 03.09.05 Maintain Activity Rates As part of the new Project Systems approach, it will be necessary to setup rates per activity type to be used to allocate costs into a project. | |
| RTR 08.01.03.02 HR Mini Master This process describes the integration between workday and SAP. | |
| To allow employees from the CT businesses to process their timesheets in SAP, HR-Mini master records must be created in SAP. | |
| It will not be possible for an employee to create timesheets if their SAP HR master record has not been copied from Workday into SAP. | |
| 5.4.3.2. To-be Changes | |
| Entering and approving timesheets on SAP is a new process in JM CT. Fiori interfaces and workflows will be created as required. Timesheet completion is a process that is currently used by many of this group of employees, however the systems, interfaces and processes will change. | |
| CT Sites Changes Business Justification | |
| All Sites Implementation of timesheets and the approval procedure on SAP is new to all sites. With the replacement of Agresso by SAP, time tracking must be retained as this and the conversion to cost is a key part of the business areas concerned. Implementing time sheeting within SAP meets this need. | |
| All Sites Enabling a Fiori interface to allow the JM CT employees to create and submit timesheets. The JM CT business has requested, the enabling of a browser application to allow the different employees from the business to create and process timesheets in a user friendly and flexible way. | |
| 5.4.3.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| Agresso Users | |
| (Paddington, Stockton, Chilton, Savannah, Perstorp) Employees currently completing time sheets in Agresso will be moving to the SAP based time sheeting system. This will require them to be trained on the new system and the processes required to complete and approve timesheets | |
| The group of employees involved will cover Licensing (JM Davy) as well as the wider RD&E teams across multiple sites. Time sheeting is required by these businesses and the replacement of Agresso with SAP requires this change of approach. | |
| Perstorp The Formox Plant Design team already complete timesheets using an existing SharePoint based system. These employees will be moved to using the CT SAP based time sheeting system. Consolidation of the RD&E businesses on to one common time sheeting system and integration with Project Systems in SAP. | |
| 5.4.4. Process: 08.01.03.04 Time Administration | |
| When errors are identified with the time recorded on timesheets, these errors need to be corrected. Modifying incorrect time can be done at different points in the processes. Changes are more easily made prior to approval. After approval changes must be made via the finance team to enable correction of any cost postings as well as the time records. | |
| β’ Users | |
| Users can identify incorrect timesheet data after submission. They can send a request to the approver (Line Managers) for resubmission of the timesheet via email. This can only be done if the timesheet has not been approved by the line manager. Users can also modify the timesheet if the timesheet has been rejected by approver. | |
| β’ Approvers | |
| Approvers can modify the timesheet for user before approval if they are assigned as time administrators or delegates. They can also reject a time sheet and send it back to the user for correction. If an approver identifies an error in the timesheet after approval, an email notification is sent to finance and finance makes the necessary changes to the time sheet record and any financial corrections required. | |
| β’ Finance Team | |
| Once the Finance Team receives an email notification of incorrect timesheet data postings, they can make the adjustment, reverse the postings, and send an email notification to confirm the change has been made. | |
| The identification of errors in timesheet allocations will follow the existing processes within the businesses. Similarly, the existing timesheet amendment process would be followed, and correction information provided to Finance. | |
| Revisions will be required to the existing processes/forms to reflect the revised systems, coding and how the changes need to be applied. | |
| 5.4.4.1. Level 4 Process Flow and Steps | |
| Figure 13 β 08.01.03.04 Time Administration | |
| Time Administrator | |
| The Time Administrator role will be performed by employees in the individual business groups of R&D, Licensing, and Formox. Each business will have at least one time administrator each. | |
| Roles of Time Administrator, | |
| β’ These employees have the task of correctly recording and managing the Time Sheet data of the employees assigned to them. | |
| β’ Time Administrator manages time sheet allocation for all personnel numbers assigned to the user in his or her capacity as a time data administrator. | |
| β’ Time Administrator can also perform as a delegate, they can fill the Time sheet on behalf of the users. | |
| β’ Time Administrator also has the authorisation to approve/reject the timesheet of all the personnel numbers assigned to them. | |
| β’ Time Administrators are assigned in IT0001 for each employee. | |
| 08.01.03.04 Time Administration | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Error in timesheet identified by user after sending SAP/ | |
| Non-SAP Error Identification in Timesheet | |
| An error is identified in a timesheet by user after submitting timesheet, a user can ask the approver to reject the time sheet allowing resubmission via the βEnter and approve timeβ process. | |
| If the error is identified by the approver before approving, the approver can edit the timesheet directly (if assigned as delegate/or time administrator) or reject the timesheet and send it back to user for resubmission. | |
| If an error is identified after approving the timesheet, notification must be sent to the Finance team to enable time sheet correction. User/ | |
| Approver NA | |
| Notification sent to user/line manager/project manager via email Manual The requestor will send the notification that there is an error in a timesheet posting, but the timesheet has already been posted into Finances. | |
| The notification will be sent by email. User/Approver/Project Manager | |
| /Finance NA | |
| User requests rejection of timesheets Manual Based on a previous identification of an error on the processing of a timesheet. | |
| The user can detect the correction and send the indication to the approver to reject the timesheet. User/Approver/Project Manager | |
| /Finance NA | |
| Approver rejects timesheets Fiori The approver (line manager) can reject the timesheet in the system and then send the indication to the end user to re-process their timesheet again. User/Approver/Project Manager | |
| /Finance Fiori | |
| Correction received by line manager Manual Correction Assessment | |
| If correction is not required, no action is needed. | |
| If correction is required, an email notification is sent to the Finance team. Manager NA | |
| Error Identification by Finance SAP Finance | |
| The finance team identifies errors and corrections to be made and then, makes the required timesheet corrections and reverse on postings made. Finance KB15N | |
| Email Notification Non-SAP Notification | |
| Notification of any corrections made by the Finance team are sent to line managers and users via email Finance NA | |
| The following fields are required to correct an incorrect entry, TCODE KB15N, | |
| Key Fields Description Mandatory / Optional | |
| Sender Element In KB15n, the sender cost element can be cost center, WBS element or internal order. If timesheet data is incorrectly posted to CO, it can be reversed by inputting the respective cost collector (Cost Centre/WBS/Network/Internal orders) in KB15n in the Sender field Mandatory | |
| Receiver Element The receiving cost collector is entered in the receiver field and executing the program transfers the amount/hours from sender cost collector to receiver cost collector Mandatory | |
| Date Date on which postings are to be reversed Mandatory | |
| Amount The amount to be reversed from one cost collector to another Mandatory | |
| Secondary-cost element Cost element used for internal cost allocation Mandatory | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| PSTM 08.01.03.03 Enter and Approve Timesheets This is the process where the user will be able to input their timesheets into the corresponding projects. | |
| PSTM 08.01.07.03 Project costs This is the process where users from the different CT businesses, will be able to review the cost assigned into projects. | |
| 5.4.4.2. To-be Changes | |
| Modifying time is a new process in JM CT. Currently βmodify timeβ is done in Agresso but this will be replaced by SAP βmodify timeβ. | |
| CT Sites Changes Business Justification | |
| All Sites Implementation of modify time in SAP is new to all sites. Some sites already have a process for handling changes to timesheets and these processes will need to be revised to align with the new SAP timesheet system. The modify time process flow needs to be set up for JM CT. The replacement of Agresso with SAP requires this change of process to enable time sheets to be corrected. | |
| 5.4.4.3. Site Specific Changes | |
| Modify time for time sheeting will be new to the CT SAP system and hence this process will be new for all parts of CT concerned. | |
| CT Sites Changes Business Justification | |
| Agresso Users | |
| (Paddington, Stockton, Chilton, Savannah, Perstorp) Employees currently completing time sheets in Agresso will be moving to an SAP based time sheeting system, and this will require them to be trained on the new system and processes required to modify time. | |
| The group of employees involved will cover Licensing (JM Davy) as well as the wider RD&E teams across multiple sites. Time sheeting is required by these businesses and the replacement of Agresso with SAP requires this change of approach. | |
| Perstorp The Formox Plant Design team already complete timesheets using an existing SharePoint based system. These employees will move to using the CT SAP based time sheeting system and associated process for making corrections. Consolidation of the RD&E businesses on to one common time sheeting system and integration with Project Systems in SAP. | |
| 5.4.5. Process: 08.01.03.05 Reporting for Time Sheets | |
| For JM CT there will be several standard reports available to analyse and report on timesheets. However, two main reports will cover 95% of the data and reporting requirements. | |
| β’ CATS_DA Report | |
| β’ CJI3 | |
| Note: Above reports are not available in Fiori interface but can be accessed in SAP with the right authorisations. | |
| CATS_DA Report | |
| The CATS_DA report will be used by the business to review information related to timesheets. The system will save all the information related with timesheets. | |
| CATS_DA SAP Standard report | |
| The Standard SAP reports for Time Sheets (CATS_DA) contains all the data that has been recorded using Timesheets. As soon as a user has entered and saved data in the time sheet, the system writes the record in the table. | |
| The CATS_DA reporting output will help to track timesheet data before it is transferred to PS/Controlling. It can help to: | |
| β’ Retrieve information at employee level, e.g., employee number, working hours, approver details, to help track changes in timesheets and dates | |
| β’ Provide details of timesheet status as defined in 5.4.3 | |
| β’ Track delegate information. In the CATS_DA Output, we can view the name and the personal number of who updated the timesheet data (this can be a user or a delegate in place of the user). | |
| β’ Show HR information retained in SAP. | |
| β’ Provide the reason for rejection of timesheet by approver. | |
| β’ Provide data from timesheets from before as well as after the current system date. | |
| β’ Can be used by managers to track employee timesheet status before the last submission date. Multiple employee numbers can be checked at once. | |
| CJI3 (Display Actual Cost Line Items for Projects) report: | |
| CJI3 is a standard SAP report used to display the actual cost incurred by the project. This report is used to review and analyse expenditure line items posted against projects. | |
| The Project Line-Item Report can be run as required to check and analyse project costs within a defined time frame. | |
| In relation to timesheets, this allows the reporting of the costs that have been transferred to the projects based on the time booked on the time sheets. | |
| There will be several benefits from the use of this report, including: | |
| β’ It can be used to validate month end settlements to Cost Centres | |
| β’ CJI3 shows all actual lines item posted to WBS elements/Activities. | |
| For example, Actual Cost incurred at WBS level can be retrieved. | |
| The example below shows the total cost incurred by WBS 1710-2021-0007-02.01 can be reported based on specified dates. | |
| β’ Costs can be tracked by posting dates. | |
| β’ Costs incurred from previous years can be tracked using the posting date selection field, as shown below, | |
| β’ The report provides follow up documents from controlling and provides controlling level information as shown below, | |
| 5.4.5.1. Level 4 Process Flow and Steps | |
| Figure 14 β 08.01.03.05 Reporting for Time Sheets | |
| 08.01.03.05 Reporting for Timesheets | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Report View Non-SAP User wishes to view approved cost or time reports | |
| User can view or export desired report output in multiple formats (excel/text etc.) from SAP. NA | |
| CJI3 | |
| SAP Standard Report SAP CJI3 | |
| User wants to extract actual costs incurred by project during a certain time CJI3 | |
| CATS_DA | |
| SAP Standard Report SAP CATS_DA | |
| User wants to view Timesheet level data before transferring to controlling CATS_DA | |
| The following table shows key SAP Fields from the CATS_DA Report Output. This report can be customised as required during the build phase. | |
| Each CT business can have a different number of fields and time of export for this report, In SAP, R&D, Licensing and Formax will have one variant each with the fields and details as required. | |
| Key field Technical name | |
| Personnel Number PERNR | |
| Date WORKDATE | |
| Sender Cost Centre SKOSTL | |
| Activity Type LSTAR | |
| Activity Number LSTNR | |
| Receiver WBS element RPROJ | |
| Network number RNPLNR | |
| Controlling Area KOKRS | |
| Company Code BUKRS | |
| User Who Created Data Record ERNAM | |
| Date of Last Change LAEDA | |
| Time of Last Change LAETM | |
| Date of Approval APDAT | |
| Processing status STATUS | |
| Reason for rejection REASON | |
| The table below show key SAP Fields from the CJI3 Report Output. This report can be customised as required during the build phase. | |
| Each CT business can have a different number of fields and time of export for this report, In SAP, R&D, Licensing and Formax will have one variant each with the field and details as required. | |
| Key fields Technical name | |
| Document No BELNR | |
| Cost element KSTAR | |
| Value TranCurr WTGBTR | |
| Transaction Currency TWAER | |
| Posting Date BUDAT | |
| WBS Element POSID | |
| Fiscal Year GJAHR | |
| The final report layouts for each report, will be defined and completed during the build phase. | |
| 5.4.5.2. To-be Changes | |
| Time sheet reporting is a new process in JM CT SAP. These reports are readily available as they are SAP Standard reports and will be replacing the current Agresso and SharePoint Timesheet reporting processes and formats. | |
| CT Sites Changes Business Justification | |
| All Sites Implementation of time sheet reporting is new for JM CT, although JM currently uses Agresso, and SharePoint based time sheet reporting. This will be replaced with SAP. | |
| Existing timesheet reporting will need to be replaced with the appropriate reports from SAP. The process for accessing these reports will be new for the users. With the replacement of Agresso by SAP, SAP time reporting must provide all the reporting required by the business. | |
| Implementing time sheeting reporting within SAP meets this need. | |
| 5.4.5.3. Site Specific Changes | |
| Time sheet reporting will be new to the CT SAP system as this will be replacing the existing Agresso and SharePoint processes and hence this process will be new for all parts of CT concerned. | |
| CT Sites Changes Business Justification | |
| Agresso Users | |
| (Paddington, Stockton, Chilton, Savannah, Perstorp) Reporting will change from that provided in Agresso to that available from SAP. Move from Agresso to SAP CATS time sheeting solution using Fiori interface and hence need to provide reporting from SAP. | |
| Perstorp Reporting will change from that provided in the current SharePoint solution to that available from SAP. Move from SharePoint to SAP CATS time sheeting using Fiori Interface solution and hence need to provide reporting from SAP. | |
| 5.5. Level 3 Business Area - 08.01.04 Capture Project Revenue (Billing) | |
| As part of the design established by the Project Concert, revenues will be assigned and allocated into a project by the creation of a sales order. | |
| To process a billing document (invoice) for a client, the project will have a sales order that will be linked to the project, so every invoice raised to the client in the system will automatically assign the revenue to the project. | |
| This process will be used wherever the JM CT business activity is managed through the use of SAP projects that include elements of customer invoicing. | |
| β’ Licensing β Davy | |
| β’ Formox | |
| β’ R&D | |
| The current BPD document contains a description of how PS and Sales will work together to enable customer billing where project work is on behalf of an external customer. | |
| 5.5.1. Process: 08.01.04.01 Maintain Policy & Procedure for Revenue Recognition | |
| Revenue recognition is an accounting principle used to determine when and how the revenue from a project needs to be recognised for accounting purposes. | |
| By using the SAP Result Analysis Functionality (RA), the different businesses will be able to calculate revenue recognition on projects, based on the guidelines established for each business. | |
| For the Licensing and Formox Plant Design businesses CT will adopt the cost-based percentage of completion method to recognise revenue in projects as well as point in time. | |
| The following table defines the scope of businesses and methods that will implement this functionality to automatically calculate revenue recognition in projects: | |
| Business Revenue Recognition Methods Existing / New | |
| Licensing Required Revenue Recognized = Plan revenue x POC | |
| POC = actual costs incurred / Forecast total costs | |
| PIT = Revenue Recognition equal to actual cost (at one specific point of time) In scope | |
| Formox Required Revenue Recognized = Plan revenue x POC | |
| POC = actual costs incurred / Forecast total costs | |
| PIT = Revenue Recognition equal to actual cost (at one specific point of time) In scope | |
| R&D Not applicable Not applicable Out of scope | |
| During the creation of the project the RA Keys will be determined as required for revenue recognition. | |
| PIT β will apply mainly on projects where the cost will be equal to the revenue to be recognised in the corresponding period. E.g., for Licensing projects, Royalties projects, Breakeven projects, where the βpaymentsβ are made by the clients once a year or every six months, PIT will recognise all the cost incurred in a monthly basis as revenue recognised until the payment happen, and then the system will perform the corresponding adjustment. | |
| Important β Every RA is related with only one calculation method; this means will have to be WBS elements to calculate revenue recognition based on POC and WBS elements for PIT. One WBS element cannot have more than one calculation method applied to it. | |
| These are project parameters that will be predefined in the project templates, so it will not be necessary capture and assign these RA keys to the structure, every time that a project is created. | |
| However, it will be one of the pre-checks that will have to be performed by the corresponding project controllers, to ensure that these keys are assigned correctly. | |
| Without the correct assignment of the RA keys to the structure, the system will not be able to automatically create the corresponding calculations to establish the revenue recognition for the project. | |
| The RA key will determine the method to be used by the system (see table above) to calculate revenue recognition. | |
| During the realisation phase of the project additional RA keys will be created if required. | |
| Currently, 3 result analysis keys have been identified as being required. | |
| Result Analysis key Description Existing / New | |
| LI00001 Result analysis key Licensing In scope | |
| FO0001 Result analysis key Formox In scope | |
| RD0001 Result analysis key R&D Out of scope | |
| Note: | |
| During the realisation phase the correct reconciliation process will be determined. This process will help the business to provide additional reporting, to verify the results calculated with the revenue recognition process. | |
| The process will provide a comprehensive model to the user, to review the main inputs taken by the revenue recognition process in SAP, and to verify if the results obtained are correct. The process will also provide a different mechanism to make corrections and adjustments in case this is necessary. | |
| Breakeven projects are part of the scope of this design document, but they will be reviewed in more detail during the realisation phase, to identify the best method to manage and administer the calculation of revenue recognition. | |
| 5.5.1.1. Level 4 Process Flow and Steps | |
| Non applicable for this section. | |
| 5.5.1.2. To-be Changes | |
| Result Analysis is a new process in JM CT SAP. The process will provide a standard and automated process for every CT business to calculate revenue recognition in projects. | |
| The process will be fully automated and integrated with finances, so once the results has been approved and validated, the user will have the option to transfer and post the effect into Finances. | |
| CT Sites Changes Business Justification | |
| All Sites Every CT business will migrate their current calculation process to determine Revenue Recognition into SAP. | |
| The new process will help to automate in SAP the calculations, instead of being performed outside of SAP manually. | |
| There will be new processes and systems required. Use of a standard tool to provide the different CT businesses a standard and automated method to calculate revenue recognition in projects. | |
| 5.5.1.3. Site Specific Changes | |
| Result Analysis is a new process in JM CT SAP and will harmonize the method to calculate RA across all the CT businesses. The process will provide a standard and automated process for every CT business to calculate revenue recognition in projects. | |
| CT Sites Changes Business Justification | |
| Licensing RA will replace the current manual processes used in Licensing for revenue recognition. This will require people to understand the new processes and systems needed. Move from existing manual process to an automated standard tool for revenue recognition. | |
| Formox RA will replace the current development used by Formox to calculate revenue recognition. | |
| Formox is currently using a βtailor madeβ program (ZFXX_SVATOOL) for revenue recognition. Use of a standard tool to provide the different CT businesses, a standard and automated method to calculate revenue recognition in projects. | |
| RA will be able to deliver the results, as required by Formox. | |
| 5.5.2. Process: 08.01.04.02 Billing for Revenue Projects | |
| For Revenue billing, SAP supports several approaches to the integration of sales order processing with PS, ranging from the closely coupled approach to a looser, financially focussed integration. | |
| For the different JM businesses, the process will require a sales order is created using standard sales order transactions (T-code: VA01) in the SD module (STC). The sales document line item is then account assigned to the project by entering the billing WBS element, for example: | |
| This ensures that both planned and actual revenue can be reported and reviewed using standard PS reports, and hence the profitability of the project determined. | |
| Upon completion of a milestone, the project manager or administrator will release the line item and collect the required documentation to support billing. They will manually contact finance to remove the billing block when milestone documentation is completed. Invoicing will not be completed automatically in system. | |
| Invoices will be generated against the account assigned sales order line-item post with reference to the billing WBS, which will be released to receive revenue prior to invoice generation. | |
| Note: | |
| β’ The completion of a milestone in a project implies the creation and sending (including documentation support) of the invoice to the client. This is the moment where the system will allocate the revenue to the project (revenue recognition does not take place at this stage). | |
| β’ The PM can change whenever required the due date in a milestone or in several milestones. Finance can have access to see these milestone dates in the system. | |
| β’ The revenue forecast will be taken by the project from the billing plan established in the Sales order. This revenue forecast will provide good level of visibility to the user, to know βwhenβ the project is expected to release an invoice to the client (this means create the invoice and prepare it to be sent to the client). | |
| β’ If there are changes in the milestones of the projects, because of delays (for example) these changes will have to be reflected manually in the billing plan of the sales order. | |
| During the period end, result analysis will be performed on those WBS elements which are assigned to sales orders, like license agreement, engineering agreement, catalyst agreement etc in the Licensing business. | |
| While doing result analysis on a WBS element the system will consider all sub level WBS elements and Network Activities to calculate the result analysis. Result analysis will consider data like actual cost of work done, forecast total cost (not budget), planned revenue and actual revenue (Milestone billing and down payments). | |
| Below there is a list of some business requirements that have been considered in the current design for the different JM CT businesses: | |
| β’ Support customer billing of activities managed through a project | |
| β’ Support for milestone billing to project | |
| β’ Support for billing of services such as training and engineer site visits | |
| β’ Link planned revenue visibly to the project | |
| β’ Link actual revenue visibly to the project | |
| β’ Need time for non-Davy employees to be input for % completion calculations for revenue recognition | |
| β’ Limit the number of transactions to manage billing associated with intercompany actions | |
| β’ Handle revenue recognition across JM legal entities, especially where % complete is required. | |
| 5.5.2.1. Level 4 Process Flow and Steps | |
| 08.01.04.02 Billing for revenue project | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Revenue milestone reached Manual The project manager will determine based on the progress achieved in their project, if a milestone has been reached as part of the milestones agreed in the contract. Project Manager NA | |
| Confirmation milestone completed SAP If the milestone has been reached, the project manager will change the status of the milestone in SAP to βcompleteβ. | |
| This will provide a clear indication in the system that a milestone has been reached, and will allow any user to know the status Project Manager CJ20n | |
| Prepare invoice support documentation Manual The project manager will put together all the supporting documentation of the milestone achieved. Project Manager NA | |
| Notification project milestone reached Email The project manager will notify the billing clerk that a contract and project milestone has been reached, this will allow the billing clerk to start to process and issue the invoice. Billing clerk NA | |
| Send invoice Manual/ | |
| email The invoice issued will be send to the project manager to add all the support documentation. Project Manager NA | |
| Project manager to request intercompany invoice Manual The project manager will request to the billing clerk the creation of an invoice (sales order created first), but in this case the client will be an affiliate. | |
| Example: When Plc is holding the contract with the end client, but Davy is delivering the work to the client. Billing clerk VA01 | |
| Delivery of the invoice to the client plus documentation Manual The project manager will prepare all support documentation for the work delivered to the client. | |
| The project manager will put together all the documentation plus the invoice to be send to the client. Client Na | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| STC 02.04.01.05 Create customer order with project Process defined to create sales order with reference to a project. | |
| As has been explained before, during the creation of the sales order by this process, the sales order will be created and linked to a project (WBS element). | |
| STC 02.06.02.01 Invoicing This process describes the steps that will be followed by the account clerks to issue and process invoices with reference to a project. | |
| PS&TM 08.01.07.02 Project revenues Process defined to allow the user to execute multiple reports to review revenues allocate in projects. | |
| The reports are also including the revenue forecasts. | |
| PS&TM 08.01.06.01 Revenue recognition / Result analysis This process describes the steps and effects calculated and posted into Finances, as a result of the automatic calculation of revenue recognition in projects. | |
| This process must be part and will be one to the steps of the month end process of the business. | |
| 5.5.2.2. To-be Changes | |
| The issue of an invoice to a client in relation to a project is a new process for the different JM CT Businesses in SAP. The new process will establish the need to create or have a sales order created first to process and issue an invoice to a client. | |
| CT Sites Changes Business Justification | |
| All To issue an invoice to a client, the sales order and the invoice will have to be referenced to a project (WBS elements) Guarantee that all the revenues related with clients, will be assigned to referenced to a project (WBS element). | |
| 5.5.2.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| Licensing Moving from Agresso to SAP will require a change of processes and systems. People will need to be trained on the new systems and requirements of the processes. Consolidation of the Licensing business from Agresso to SAP and introduction of standard processes for handling of invoices on projects. | |
| Formox Formox will move from using Internal Orders to using Projects in SAP and the associated changes to the invoicing process. People will need to be trained in the new processes. Introduction of standard processes for handling of invoices and the use of projects in SAP. | |
| Other SAP sites (R&D) Where applicable sites will need to move to the use of the same processes for handling invoicing customers from projects. People will need to be trained in the new processes. Introduction of standard processes for handling of invoices and the use of projects in SAP. | |
| 5.5.3. Process: 08.01.04.05 Account Revenue Recognition | |
| As described above, RA has a standard integration with Finances in SAP to allow the user to transfer automatically, the amounts calculated into the corresponding Balance Sheet and P&L accounts. | |
| To allow that PS RA automatically calculate the proposal of revenue recognition to be posted into Finances, the system and the calculation method will take the following inputs as elements to perform the calculation. | |
| To calculate and propose accounting adjustment entries as per matching principle, Result Analysis considers data like planned cost, planned revenue, actual cost, actual revenue, method to be used to match cost and revenue, and GL accounts to be posted. Result Analysis does not post any accounting entries. | |
| Revenue relating to the project will coming from SD (sales order billing) to the WBS elements. | |
| During period end, Result Analysis (Transaction KKA2) will be performed on the project to match cost and revenue. It is performed at WBS level and will consider all the sub level WBS elements and Network Activities. | |
| The user will have the option to execute this process in βtestβ as many times they required before transferring the final amounts to Finances. | |
| This will help the user to review case by case (project) to perform any change or amendment in the information. | |
| The calculated results obtained by RA will be saved but will not be posted into Finance, until the project settlement has been executed (08.01.06.02 Perform Project Settlement). | |
| Once the user has confirmed the results, the settlement will create the postings established in the account determination of RA. | |
| Example: | |
| The first posting will reflect the revenues collected by the project. | |
| The revenues will continue be posted into the current accounts, but now using the global chart of accounts defined by JM. | |
| The final number of the GL accounts to be used, will be defined during the realisation phase. | |
| The next posting presents the allocation of costs into project that will come from timesheets and purchases (goods or services with reference to a project). | |
| Example: | |
| Finally, depending on the method used, RA in SAP will generate the following posting at project level, to recognize the revenue calculated. | |
| RA will calculate the effect and will generate a posting per project βDebiting the cumulative revenue accountβ and βCrediting Revenueβ. | |
| This effect will be posted the last day of the period and then, the system will create a reverse movement in the first day of the following period. | |
| This is because, RA will calculate the revenue recognition for a project in a cumulative basis depending on the NEW progress achieved in the month. | |
| The main target is that the different CT businesses must have a βnetting effectβ in their revenue accounts on their balance sheet, as the following diagram presents. | |
| The number of the GL accounts will be defined during the realisation phase of the project. | |
| Note: | |
| β’ Revenue recognition (via Results Analysis) will be set up to calculate revenue based on the relevant WBS elements and types of revenue recognition required by the different businesses. | |
| β’ Invoices will be not part of any of the calculation methods defined for JM CT. | |
| 5.5.3.1. Level 4 Process Flow and Steps | |
| Non applicable for this section | |
| 5.5.3.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All The postings (results) generated by RA, will be posted automatically into the corresponding Balance Sheet and P&L account. | |
| The main change is that all the postings that currently are performed manually by the user, the system will calculate automatically and will automatically transfer the information to Finances. Ensure that all the revenues related with clients, will be referenced to a project (WBS element). | |
| Provide a standard platform to automate the calculation and postings of Revenue Recognition into the Financial reports of every business. | |
| 5.5.3.3. Site Specific Changes | |
| Revenue recognition automation within SAP will be new to some parts of the business and in others the process will change from a custom process to the standard SAP process. | |
| CT Sites Changes Business Justification | |
| Licensing The Licensing business will be migrating from Agresso to SAP and moving from a manual revenue recognition process to an automated one. This will require the use of new systems and processes. Consolidation of the Licensing business from Agresso to SAP and introduction of standard automated processes for revenue recognition. | |
| Formox The Formox business will be moving from a custom revenue recognition process to the SAP standard automated process. This will require the use of a new process. Introduction of standard processes for automated revenue recognition in SAP. | |
| Other SAP sites (R&D) Where applicable sites will need to move to the use of the same processes for handling revenue recognition for projects. People will need to be trained in the new processes. Introduction of standard processes for automated revenue recognition in SAP. | |
| β | |
| 5.6. Level 3 Business Area β 08.01.05 Project Monitoring | |
| The project monitoring processes are how the different CT businesses will be able to review and monitor the project and integrate with other external systems. | |
| For project monitoring purposes, the following integrations between SAP and legacy systems or applications currently used by CT have been identified. | |
| Business Description Type Comments: | |
| Licensing Integration with Primavera SAP standard Report (manual) Outbound only | |
| Licensing/ Formox Integration with Tableau (Segmentation) SAP standard Report (manual) Outbound only | |
| R&D Integration with KeyedIn SAP standard Report (manual) Inbound and outbound | |
| All business Integration Workday/ | |
| HR-Mini-master Interface (automatic) Inbound only | |
| Licensing Finances forecast SAP standard Report Outbound only | |
| Each of these integrations will be explained in more detail in the following sections. | |
| 5.6.1. Process: 08.01.05.01 Perform Project Reporting | |
| Regarding project reporting of costs, two main reports have been identified that are key for every business to present and deliver results. | |
| These reports are: | |
| Business Description Type | |
| Licensing Project cost report SAP standard (to-be configured as a variant) | |
| Formox Integration with Tableau (Segmentation) SAP standard Report (manual) | |
| 1. Licensing cost report | |
| The βcost reportβ is a standard report used by the Licensing business to track the status of a project for a specific period. To fulfil this requirement, a new report will be developed using βreport painterβ in SAP. | |
| Report painter is a standard reporting tool in SAP to create and combine multiple views, extracting and presenting the information from multiple tables. | |
| The following diagram shows the main components of this report and from where the information will be extracted from SAP. | |
| The following image shows the layout of the report that is expected to be built. | |
| The columns in the image above related as follows: | |
| Column Description Description | |
| A Original Budget The original budget will come from a project version created at the start of the project. The original budget will be updated manually into the system by the cost engineer. | |
| B Approved changes Changes approved will come from changes approved on the original budget. This will also be registered in a project version. | |
| C Current budget This field will be a calculated field that will be the result of the sum of fields A and B. | |
| D Commitment This column will present the βcommitmentβ, that is the total of Purchase orders and purchase requisitions created per WBS and activity | |
| This is a new column for this report and for the users of this report. | |
| This is part of the improvements made by the standard integration and process in SAP as it allows the report to show committed spend as well as actual spend to date. | |
| E Spent to date This field (column) will display the total actual cost to date. | |
| F Forecast to go This field will display the estimated forecast established by the project manager. | |
| These values will be stored in a project version. | |
| G Total Forecast This will be a calculated field that will equal the sum of D + E + F | |
| H Budget (over/under) Calculated field | |
| I Changes in forecast Calculated field | |
| J Remarks The notes will be extracted from every WBS from the documentation section. | |
| The details of this report will be reviewed during the realisation phase of the project. | |
| Note: | |
| The intent would be that the updates/changes to the cost reports are done by the Cost Engineer following a similar process to today but using plan versions in SAP. | |
| It will be possible to make comparisons between multiple versions to review the corresponding variances. For example, the user will be able to report e.g., a version for January vs a version from April from the same year or from a different year. | |
| 2. Formox Financial Forecast | |
| The βFinancial forecastβ for the Formox business is a standard report used to know the situation of a project for a specific period. | |
| This report will be created and extracted from the systems using standard cost elements reports. | |
| Currently, the report is created via the monthly download of the information into excel and then is formatted and organized in excel to fulfil the requirement. | |
| β’ This process will continue, however, the user will have to use some different reports in PS (cost elements reporting), to download and format the information in excel. | |
| β’ Some additional cost elements groups will be created for reporting purposes and the range of cost elements for each group will be determined during the build phase of the project. | |
| The details of this report will be reviewed during the realisation phase of the project. | |
| 5.6.1.1. Level 4 Process Flow and Steps | |
| Licensing cost report | |
| Licensing cost report | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Requirement to extract the report Manual Reception of the requirement to generate this report for a specific project. Cost Engineer NA | |
| Execute transaction | |
| ZLCOSTREP SAP With the request already established, the user will have to open this transaction in SAP and then select the project number to execute the report. Cost Engineer ZLCOSTREP | |
| Delivery and review of the data Manual In the same transaction (as above) the user will execute the download process into an excel or create a printout for the end user. | |
| Note: the format will be defined during the realisation phase Cost Engineer N/A | |
| Formox Financial Forecast | |
| Formox Financial Forecast | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Requirement to extract the report Manual Reception of the requirement to generate this report for a specific project. Project administrator/ | |
| Project planner/ Project Manager NA | |
| Execute transaction | |
| ZFFINFOR SAP With the request already established, the user will have to open this transaction in SAP and then select the project number to execute the report. Project administrator/ | |
| Project planner/ Project Manager ZFFINFOR | |
| Delivery and review of the data Manual In the same transaction (as above) the user will execute the download process into an excel or create a printout for the end user. | |
| Note: the format will be defined during the realisation phase Project administrator/ | |
| Project planner/ Project Manager N/A | |
| 5.6.1.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| NA NA NA | |
| 5.6.1.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| Licensing The report will be extracted directly from SAP. | |
| The report will provide a full consolidated view of the commitments, plans, budgets, actuals and forecast per project. | |
| This report will be executed by the Licensing business. | |
| The new report will incorporate the possibility for the user to review the value of the commitments in a project. The business needs to be able to produce this report in a monthly, weekly, or daily basis. | |
| This report provides a consolidated view of the status of a project. | |
| Formox The report will be extracted directly from SAP. | |
| This report will be executed by the Formox business. | |
| The new report will incorporate the possibility for the user to review the value of the commitments in a project. This report provides a consolidated view of the status of a project. | |
| The report will continue providing a view at project and at cost element level. | |
| 5.6.2. Process: 08.01.05.02 Perform Integrations with Project Management Tools | |
| 1. Primavera | |
| Primavera is a project management tool, currently used by the Licensing business to prepare reporting information regarding forecast and availability per project. | |
| For the new design, Licensing will continue using Primavera to prepare the current reports requested by the business; However, there will be a manual interface where the user from Licensing will be able to download the information requested from SAP to an excel file. | |
| There will be a predetermined βlayoutβ in SAP defined in the following report, that the user will use to extract and present the information with the content required. | |
| In the new process the Licensing business will extract the information from SAP PS instead of Agresso, as follows: | |
| Through the use the transaction CJI3, the Concert project team in conjunction with the users, will predefine a data layout that will match with the data requirements from Primavera (this will be finalised during realisation). | |
| Menu Path: | |
| CJI3: Information Systems β Project System β Financials β Line Items β Actual Costs/Revenues | |
| The report will generate the layout with the information required and the user will have the option to export the file into excel to then be uploaded into Primavera. | |
| The initial structure (data fields) of the file that will be uploaded into Primavera, has already been defined in the FDD for PS. | |
| The list of fields already determined will be reviewed and confirmed during the realisation phase of the project. | |
| This interface will be a βmanual interfaceβ, so the end user will have the responsibility to generate this file in SAP, download the file into the net or their own PC and then upload into Primavera. | |
| 2. Integration with Tableau | |
| The integration with Tableau will be similar to the integration with Primavera. The user will prepare the information in SAP and then the file extracted will be uploaded into Tableau using a manual interface. | |
| The user will generate a report in CJI3 with the fields and data required, the file will be downloaded and then uploaded manually in Tableau. | |
| Menu Path: | |
| CJI3: Information Systems β Project System β Financials β Line Items β Actual Costs/Revenues | |
| 3. Integration with KeyedIn | |
| For the integration between SAP and KeyedIn there has been identified two main interfaces that will be performed manually. | |
| A. Project creation | |
| B. Project actuals | |
| A. Project Creation | |
| During project creation, every time a project is created in KeyedIn, a project will also have to be created in SAP via 08.01.01.02 Create & Maintain project structure. | |
| a. Project creation in SAP will be a manual process and the project structure of the project will follow the defined template. | |
| b. The user will populate manually in predefined User Fields, within the project and WBS elements, the key information from KeyedIn. This includes the programme number, project number and workstream number used by KeyedIn to setup the project. This is how the user will be able to identify the project in SAP and in KeyedIn. | |
| B. Project Actuals | |
| SAP will transfer to KeyedIn the hours allocated into a project, plus their equivalent in cost. | |
| a. As part of the standard functionality, SAP is converting the hours allocated in projects by multiplying the units (hours) against the hourly rate established for the activity. | |
| b. The interface will also transfer into KeyedIn other actuals, like invoices, goods receipts of services & materials; The interface will transfer any cost allocated into the project, that has affected the balance. | |
| c. In the same way as for Primavera and Tableau, a layout will be defined in CJI3 that will provide the details required by KeyedIn. | |
| 4. Workday Integration | |
| This integration has been already described in the sections: | |
| β’ 5.4.1 β 08.01.03.01 Capture Project Related Costs | |
| β’ 5.4.2 β 08.01.03.02 Maintaining HR Mini Master | |
| 5. Licensing Financial Forecast | |
| There are several reports and datasets required to be produced and fed into the Licensing Financial Forecasting process. It is anticipated that this information will be available in the standard SAP reports. The reports required and integration with the existing processes will be reviewed during the realisation phase. | |
| For this business requirement most of the information required will extracted using transaction CJI3, the Concert project team in conjunction with the users will predefine several data layouts that will match with the data requirements of the Financial Forecast for Davy (this will be finalised during realisation). | |
| Menu Path: | |
| CJI3: Information Systems β Project System β Financials β Line Items β Actual Costs/Revenues | |
| The report will generate the layout with the information required and the user will have the option to export the file into excel to then be uploaded into final Financial Forecast report in excel. | |
| The list of fields will be reviewed and confirmed during the realisation phase of the project. | |
| This interface will be a βmanual interfaceβ, so the end user will have the responsibility to generate this file in SAP and upload into forecast data base. | |
| 5.6.2.1. Level 4 Process Flow and Steps | |
| Integration with Primavera | |
| Primavera | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| User requires the extraction of data from SAP Manual The user will start with the business need to update and modify the forecast in Primavera. Project administrator/ | |
| Project planner NA | |
| Actual Line items SAP With the request already established, the user will have to open this transaction in SAP and then select the predetermined layout. | |
| The Layout will produce the report with the structure required that will be verified by the user, before download the information. Project administrator/ | |
| Project planner CJI3 | |
| Generate download actual line items SAP In the same transaction the user will execute the download process into an excel file or the format required. | |
| Note: the format will be defined during the realisation phase Project administrator/ | |
| Project planner CJI3 | |
| Generate import into Primavera Primavera With the file with the information downloaded, the user will perform the necessary activities in Primavera to perform the upload. Project administrator/ | |
| Project planner NA | |
| Integration with Tableau | |
| Tableau | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| User requires the extraction of data from SAP Manual The user will start with the business need to update and modify the actuals in Tableau. Project administrator/ | |
| Project planner NA | |
| Actual Line items SAP With the request already established, the user will have to open this transaction in SAP and then select the predetermined layout. | |
| The Layout will produce the report with the structure required that will be verified by the user, before download the information. Project administrator/ | |
| Project planner CJI3 | |
| Generate download actual line items SAP In the same transaction the user will execute the download process into an excel file or the format required. | |
| Note: the format will be defined during the realisation phase Project administrator/ | |
| Project planner CJI3 | |
| Generate import into Tableau Tableau With the file with the information downloaded, the user will perform the necessary activities in Tableau to perform the upload. Project administrator/ | |
| Project planner NA | |
| Integration with KeyedIn | |
| KeyedIn | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| User requires the extraction of data from SAP Manual The user will start with the business need to update and modify the actuals in KeyedIn. Project administrator/ | |
| Project planner NA | |
| Actual Line items SAP With the request already established, the user will have to open this transaction in SAP and then select the predetermined layout. | |
| The Layout will produce a report with the structure required that will be verified by the user, before downloading the information. | |
| The report will consider any cost that has been posted into the project such as, timesheets, vendor invoices, internal costs (overheads), goods receipts of materials and services. Project administrator/ | |
| Project planner CJI3 | |
| Generate download actual line items SAP In the same transaction the user will execute the download process into an excel file or the format required. | |
| Note: the format will be defined during the realisation phase Project administrator/ | |
| Project planner CJI3 | |
| Generate import into KeyedIn KeyedIn With the file with the information downloaded, the user will perform the necessary activities in KeyedIn to perform the upload. Project administrator/ | |
| Project planner NA | |
| 5.6.2.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| NA NA NA | |
| 5.6.2.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| Primavera The process will continue working in the same way that currently is managed; However, the extraction of the information will be performed in SAP and transferred manually into Primavera This interface is part of the scope of the project and is necessary to the Licensing business. | |
| This interface will continue helping the business to prepare consolidated forecast in Primavera. | |
| Tableau The process will continue working in the same way that currently is managed; However, the extraction of the information will be performed in SAP and transferred manually into Tableau. This interface allows the continued collection of time data across the RD&E business (Licensing, Formox Plant Designs and R&D) as is currently performed using data from Agresso. | |
| KeyedIn The integration will continue existing between KeyedIn and SAP, however, the process will be a mix between automatic and manual. | |
| SAP will provide at the end of the period to Keyedin with all the actuals (costs), that are coming from timesheets and other costs. This interface allows projects to capture time and costs associated with R&D projects in KeyedIn and the transfer of this information back to KeyedIn for project management and reporting. | |
| 5.7. Level 3 Business Area β 08.01.06 Project Month & Year End Close | |
| 5.7.1. Process: 08.01.06.01 Results Analysis | |
| Results Analysis (RA) is a functionality in SAP Controlling to evaluate ongoing, unfinished activities, such as service orders, production orders or projects at month-end. | |
| In the JM CT business, a project will be created with the required structure (following the template structures), but the forecast (cost and revenue) will have to be maintained in the corresponding planning versions (this has been explained in more detail in section 5.3 of this document) | |
| During period end, Result Analysis (Transaction KKA2 in SAP) will be performed on the project to match cost and revenue. It is performed at WBS level and considers all the sub level WBS elements and Network Activities. | |
| To calculate and propose accounting adjustment entries as per matching principle, Result Analysis considers various data like planned cost, planned revenue, actual cost, actual revenue, method to be used to match cost and revenue, and GL accounts to be posted. Result Analysis does not post any accounting entries. | |
| Revenue recognition is an accounting principle used to determine when and how revenue is recognized for accounting purposes. By using the result analysis functionality in SAP, the different businesses will be able to calculate revenue recognition on projects, based on the guidelines established for each business. | |
| The table below describes the Result Analysis methods that will be provided in the system for the different JM CT businesses according to their business requirements. | |
| Business Revenue Recognition Methods Existing / New | |
| Licensing Required Revenue Recognized = Plan revenue x POC | |
| POC = actual costs incurred / Forecast total costs | |
| PIT = Revenue Recognition equal to actual cost (at one specific point of time) New | |
| Formox Required Revenue Recognized = Plan revenue x POC | |
| POC = actual costs incurred / Forecast total costs | |
| PIT = Revenue Recognition equal to actual cost (at one specific point of time) New | |
| R&D Optional Revenue Recognized = Plan revenue x POC | |
| POC = actual costs incurred / Forecast total costs | |
| PIT = Revenue Recognition equal to actual cost (at one specific point of time) New | |
| 5.7.1.1. Level 4 Process Flow and Steps | |
| 08.01.06.01 Result Analysis | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Project Creation SAP As it has been commented before, there must be a project created first and a sales order linked to this project. Project Manager Cj20n | |
| Release project/WBS elements SAP The milestones will be released on this transaction, to allow the triggering of the invoicing process. | |
| The release of the WBS will be more for informative purposes. Project Manager CJ20n | |
| Milestone approval SAP The milestone will be approved by the project manager, and this will trigger the invoicing process. Project Manager CJ20n | |
| Revenue recognition | |
| Pre-review Manual The user will start to perform the prechecks to calculate revenue recognition. | |
| The first point is to ensure that all the invoices has been issued. Project administrator NA | |
| Verify settlement rule SAP For new projects that have not been settled before, it will be necessary confirm if the settlement rule has been assigned correctly. | |
| For projects created from a βtemplateβ, the settlement rule will be already predetermined. Project Administrator CJ20n | |
| Verify Result analysis key SAP For new projects that have not been settled before, it will be necessary confirm if the βResult analysis keyβ has been assigned correctly. | |
| For projects created from a βtemplateβ, the result analysis key will be already predetermined. Project Administrator CJ20n | |
| Change cut off period SAP The Project Financial Controller maintains the cut off period for settlement/Result Analysis. | |
| The cut-off period determines the period in which RA will make the calculations. | |
| The period must be aligned to the financial period. Project Finance Administrator KKAO | |
| Result Analysis SAP The Project Financial Controller runs the Result Analysis individually or collectively using the T. codes KKA2/KKAJ respectively Project Finance Administrator KKA2/KKAJ | |
| Review results/RA reports SAP The RA reports will need to be reviewed to confirm they are correct or if corrections will be needed. | |
| The RA analysis process will calculate and prepare the postings, but this will not be released to Finances until the settlement is executed Project Finance Administrator N/A | |
| Perform corrections SAP The corrections are to be performed for the settlement rule and Result Analysis key in CJ20N. | |
| It will be necessary in some cases to make corrections on planned costs and planned revenues Project Finance Administrator CJ20N | |
| Perform corrections to costs/Revenue SAP If the Result Analysis reports are not correct, the corrections are made at the planned costs and Revenues using T. codes CJ40 & CJ42, to run RA. Project Finance Administrator CJ40/CJ42 | |
| Integration with other processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| RTR 03.01.07.02 Perform Period close Result analysis (RA) must be seen as another transaction as part of the financial month end process. | |
| RA will perform the calculations on a project, to calculate the results of revenue to be recognized in a project. | |
| PS&TM 08.01.06.02 Perform project settlement Once RA has made the calculations related with the revenue recognition on projects the Settlement process will transfer all these values into postings that will be reflected in Finance. | |
| PS&TM 08.01.02.01 Perform Budgeting for project spend Process defined to establish the initial budget for a project. | |
| STC 02.04.01.05 Create Customer Order with Project Process defined to create sales order with reference to a project. | |
| STC 02.06.02.01 Create customer invoice Process defined to create client invoices for a project | |
| 5.7.1.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All Sites Through the functionality of RA analysis, the system will automate the calculation of POC and revenue recognition. | |
| Currently, these calculations are made outside of SAP or via a custom process. Simplification and automation of the revenue recognition process for the different JM CT businesses. | |
| 5.7.1.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| Agresso Through the functionality of RA analysis, the system will automate the calculation of POC and revenue recognition. | |
| Currently, these calculations are made outside of SAP using Excel. There will be a change in the process, actions required of the people involved and additional training required. It is possible that the results will be different to that seen before and this will need to be resolved. Simplification and automation of the revenue recognition process for the different JM CT businesses onto a common approach. | |
| Perstorp Formox currently use a custom process for revenue recognition. Moving to the SAP standard approach will make things consistent across the business but will lead to changes for the people involved in the process. There will be changes in the steps, actions and possibly the output. Simplification and automation of the revenue recognition process for the different JM CT business onto a common approach. | |
| Other existing SAP sites Non-revenue projects wonβt have to perform revenue recognition so impact of this change will be minimal on these sites at this stage. Simplification and automation of the revenue recognition process for the different JM CT business onto a common approach. | |
| 5.7.2. Process: 08.01.06.02 Perform Project Settlement | |
| Settlement in SAP is the process, where the costs and revenues allocated (P&L accounts) and collected in a project, will be transferred, or βsettledβ into different receivers. | |
| During the execution of the project settlement, costs and revenues which are collected in projects must be settled to one or more receivers as part of the period end processing and year-end close. | |
| In JM CT the settlement function is used to settle (transfer) values from P&L accounts to Cost Centres or Profit Centres. | |
| Configuration will be required in project systems for all JM CT projects, to allow the businesses to settle values to the different defined receivers. | |
| This configuration will be saved in the βsettlement profileβ and it will be defined only for WBS elements and networks, that have the following βoperative indicatorsβ activated: | |
| 1. Account assignment element | |
| 2. Billing element | |
| This configuration will be predefined in each project template, so the project settlement field will have a predefined settlement profile assigned. | |
| The following table describes the different senders and receivers that will be available for projects and businesses: | |
| Business Sender Receivers | |
| Licensing β’ WBS elements | |
| β’ Networks β’ Cost centres | |
| β’ Profit centres | |
| β’ GL accounts | |
| Formox β’ WBS elements β’ Cost centres | |
| β’ Profit centres | |
| β’ GL accounts | |
| R&D β’ WBS elements β’ Cost centres | |
| β’ Profit centres | |
| β’ GL accounts | |
| 5.7.2.1. Level 4 Process Flow and Steps | |
| Perform Project Settlement | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Verify settlement rule SAP For new projects that have not been settled before, it will be necessary confirm if the settlement rule has been assigned correctly. | |
| For projects created from a βtemplateβ, settlement rule will be already predetermined. Project Administrator CJ20n | |
| Execute settlement in test | |
| (individual) SAP Execution of the settlement individually in test. | |
| The settlement can be executed for one project only or for multiple projects. Project financial controller CJ88 | |
| Review settlement log (errors) SAP Reviewing and confirming there are no errors in the settlement log. | |
| Because the settlement can be executed in test, this will allow the user to perform and review and potential error identified by the system, before performing the settlement in real. Project financial controller CJ88 | |
| Execute settlement in test | |
| (massive) SAP Execution of the settlement massively in test. | |
| The settlement can be executed for one project only or for multiple projects. Project financial controller CJ8G | |
| Review settlement log (errors) SAP Reviewing and confirming there are no errors in the settlement log. | |
| Because the settlement can be executed in test, this will allow the user to perform and review and potential error identified by the system, before performing the settlement in real. Project financial controller CJ8G | |
| Perform corrections settlement rule SAP If there are errors in the settlement rule, this will have to be corrected in the project. Project financial controller CJ20n | |
| Perform corrections cost/revenues SAP The errors can also be in the planning costs and planning revenues. | |
| As part of the analysis performed in the log, the user will have the option to make corrections to these values. Project financial controller CJ40 | |
| Execute settlement β real (individual) SAP With all the corrections in the data made, the user can execute the settlement for a specific project. Project financial controller CJ88 | |
| Execute settlement β real (massive) SAP With all the corrections in the data made, the user can execute the settlement for multiple projects. Project financial controller CJ8G | |
| Integration with other L4 processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| RTR 03.01.07.02 Perform Period close The project settlement must be seen as another transaction as part of the financial month end process. | |
| The project settlement is the process that will transfer the amounts calculated in RA into Finances. | |
| PSTM 08.01.06.01 Result Analysis Once RA have made the calculations related with the revenue recognition on projects the Settlement process will transfer all these values into postings that will be reflected in Finance. | |
| 5.7.2.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All Sites Through the settlement functionality in SAP, the user will have an automated process to perform the settlement on their projects automatically. The results will be allocated to the correct receiver (Cost centre, Profit Centre) during the month end process. | |
| This will guarantee that costs will not be left in the P&L. | |
| 5.7.2.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| Agresso Settlement in SAP will be a different process to that undertaken in Agresso. The process, activities etc. will be different, additional training will be required. Consolidation of CT business onto a common system using standard SAP functionality and Project Systems. | |
| Perstorp Settlement using Projects will be different to that currently done using Internal Orders. Additional training will be required. Consolidation of CT business onto a common system using standard SAP functionality and Project Systems. | |
| Other existing SAP sites Settlement using Project will be different to that currently done using Internal Orders. Additional training will be required as this will be applicable to some non-revenue projects. Consolidation of CT business onto a common system using standard SAP functionality and Project Systems. | |
| 5.7.3. Process: 08.01.06.03 Project Closure | |
| The project closure process in SAP PS, is the process where the business performs the final close on a project. | |
| The project closure process has several stages and activities that will have to be performed and confirmed by the user, before passing to the stage to perform the final close of a project. | |
| The following table describe the steps that every business will have to follow to perform the final close of a project. | |
| No. Activity Description Licensing Formox R&D | |
| 1 Perform final confirmation on each activity Every activity in the project needs to be marked as completed Required Not Req. Not Req. | |
| 2 Any stock in the project needs to be cleared Clear any stock received by the project Required Required Required | |
| 3 Perform any goods/receipt pending Complete any "good/receipts" on goods already bought Required Required Required | |
| 4 Perform and complete any invoice verification Perform the invoice verification process on any invoice pending Required Required Required | |
| 5 Transfer into finances any timesheet open or pending Complete and transfer into Finances any timesheets pending Required Required Required | |
| 6 Cancel any material reservation Cancel any material reservation made by the project. Required Required Not Req. | |
| 7 Confirm there are no items pending to be invoiced to the client. Complete the billing on any invoice pending with the client. Required Required Required | |
| 8 Move the status of the project to TECO Move the status of the project from REL (Release) to TECO (Technical close) Required Required Required | |
| 9 Confirm there are no payments pending Confirm all the payments on invoices allocated in the project have been paid Required Required Required | |
| 10 Confirm there are no overheads pending Confirm the project has received any overheads pending Required Required Required | |
| 11 Execute the revenue recognition process Execute the Result Analysis process to calculate Revenue Recognition. Required Required Required | |
| 12 Execute the project settlement Execute the project settlement process, to achieve Zero value in the WBS. Required Required Required | |
| 13 Cancel any PO missing or open Cancel and delete any PO open Required Required Required | |
| 14 Change the status of the project to CLSD Move the status of the project from TECO (Technical close) to CLSD (Closed). Required Required Required | |
| 5.7.3.1. Level 4 Process Flow and Steps | |
| 08.01.06.03 Perform Project Closure | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Project closing request | |
| Manual | |
| Request to perform the final close in a project sent. | |
| Project Manager | |
| N/A | |
| Change status to TECO | |
| SAP Change of the status in the project from REL (Release) to TECO (Technical close). | |
| Project Administrator | |
| CJ20N | |
| Confirm the status of the pending bills | |
| Manual | |
| Confirm there are no items from the billing plan pending to be invoiced to the client for the project. Project Administrator | |
| N/A | |
| Confirm the status of the pending PO's and PR's. bills | |
| Manual | |
| Confirm there are no items from POβs pending to be received by the project. | |
| Project Administrator | |
| N/A | |
| Posting of the Time sheets | |
| Manual | |
| Confirm there are no timesheets opened pending to be approved. | |
| Project Administrator | |
| N/A | |
| Posting of costs and Over heads | |
| Manual | |
| Confirm all finances costs and overheads have been posted into the project. Project Administrator | |
| N/A | |
| Result Analysis/ | |
| Project Settlement | |
| Manual | |
| Confirm and complete the execution of result analysis. | |
| Project Administrator | |
| N/A | |
| Project Closure | |
| SAP Confirm the project has been finally closed, by changing the status from TECO to CLSD. Project Administrator | |
| CJ20N | |
| Notification | |
| Manual | |
| Project Administrator sends notification to Project Manager confirming closure of the project. | |
| Project Administrator | |
| N/A | |
| Integration with other processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| STP 01.05.01.01 Goods Receive Direct/Indirect Level 4 process defined to generate the reception of goods and services into a project. | |
| STC 02.06.02.01 Create customer invoice Process defined to create client invoices for a project. | |
| RTR 03.01.07.01 Process General Ledger Journals Process defined to allocate multiple costs into a project by finances. | |
| PSTM 08.01.03.03 Enter and Approve time Level 4 process defined to create and post timesheets into a project. | |
| PSTM 08.01.06.01 Result Analysis Once RA has made the calculations related with the revenue recognition on projects the Settlement process will transfer all these values into postings that will be reflected in Finances. | |
| PSTM 08.01.06.02 Perform project settlement The Settlement process will transfer all these values into postings that will be reflected in Finances. | |
| The process will generate in finances the corresponding postings to reflect the revenue to be recognised in a project. | |
| Note: | |
| The business will be able to generate reports (including the cost report) from a project or multiple projects, during and even when the project has been officially closed. | |
| 5.7.3.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All Sites The introduction of Project Systems will introduce the new process for the closure of projects to all sites. Implementation of Project Systems in JM CT SAP | |
| 5.7.3.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| Agresso The process for the closure of projects will be different to that currently undertaken in Agresso. New processes will need to be followed, requiring additional training. Consolidation to Project Systems in JM CT SAP. | |
| Perstorp The process for the closure of projects will be a change to existing processes where projects use Internal Orders. New processes will need to be followed, requiring additional training. Consolidation to Project Systems in JM CT SAP. | |
| Other existing SAP sites The process for the closure of projects will be a change to existing processes where projects use Internal Orders. New processes will need to be followed, requiring additional training. Consolidation to Project Systems in JM CT SAP. | |
| 5.7.4. Process: 08.01.06.04 Project Year End Close | |
| The year-end process in projects will be linked to the year-end process defined by the Finance team. | |
| 5.7.4.1. Level 4 Process Flow and Steps | |
| 08.01.06.04 Perform Project Year End Close | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Budget carry forward | |
| SAP | |
| The budget gets carried forward to next period using T-code CJCO. | |
| The system will transfer the remaining budget from the previous year into the following year. | |
| Project Administrator | |
| CJCO | |
| Commitment carries forward | |
| SAP | |
| Carry forward the commitment using T-code CJCF, as the goods received will happen in the next period. | |
| The system will transfer the remaining items of the commitment (POβs) into the following year. | |
| Project Administrator | |
| CJCF | |
| Integration with other processes | |
| Process integration | |
| WS L4 Process Area L4 Process Description L4 Process integration | |
| RTR 03.01.07.02 Perform Period close The project settlement must be seen as another transaction as part of the financial month end process. | |
| The project settlement will be the process that will transfer the amounts calculated in RA into Finances. | |
| PS&TM 08.01.06.01 Result Analysis Once RA have made the calculations related with the revenue recognition on projects the Settlement process will transfer all these values into postings that will be reflected in Finance. | |
| PS&TM 08.01.06.02 Perform project settlement The Settlement process will transfer all these values into postings that will be reflected in Finance. | |
| The process will generate in Finance the corresponding postings to reflect the revenue to be recognized in a project. | |
| 5.7.4.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All Sites The introduction of Project Systems will introduce a new process for project year end to all sites. Implementation of Project Systems in JM CT SAP | |
| 5.7.4.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| Agresso The process for year-end close of projects will be new following the move from Agresso to SAP. New processes will need to be followed and additional training required. Consolidation on Project Systems in JM CT SAP. | |
| Perstorp The process for year-end close of projects will be a change to existing processes where projects use Internal Orders. New processes will need to be followed, requiring additional training. Consolidation on Project Systems in JM CT SAP. | |
| Other existing SAP Sites The process for year-end close of projects will be a change to existing processes where projects use Internal Orders. New processes will need to be followed, requiring additional training. Consolidation on Project Systems in JM CT SAP. | |
| 5.8. Level 3 Business Area β 08.01.07 Project Reporting | |
| In the SAP system, a Project Information System is used to monitor and control the project master data. It will allow the JM CT users to analyse each project, parts of projects, or multiple projects. | |
| The analysis will include creating different overview reports and advanced level reports with various degrees of detail. These reports meet the metrics required as part of project management data. | |
| Key functions in PS reports | |
| β’ Using the PS Information system, JM CT can run standard reports in the system or can create their own reports to meet specific tasks in the Licensing, Formox and R&D businesses. | |
| β’ These reports can be displayed directly and are available in Project Information system or you can run them as background jobs. | |
| β’ Report analysis includes considering various fields and functions of a project. | |
| Note: | |
| Depending on the authorisation roles for each user in the system, the user will be able to use all these reports or only some. The final authorisation roles will be defined during the realisation phase. | |
| All the reports in SAP can be downloaded into multiple standard formats (Excel, PDF, TXT etc). | |
| All the SAP standard reports enable different views to visualize revenues, costs, budgets and cashflows. The enabling and use of these views will be reviewed during the training phase of the project. | |
| Types of Reports | |
| For JM CT, there will be available the following types of reports in the PS Information System. | |
| β’ Technical Reports | |
| The PS Information System in SAP PS will allow the different users from the JM CT businesses to manage and control a project technically. | |
| This allows the user to select all the objects or specific objects (fields) in the system, like: WBS elements, Networks, PS text, materials etc. to check their status and their use in the project hierarchy. | |
| Via the PS Information System, JM CT users can monitor the data related to current projects as well as data in archive to see historical data and lessons learnt. | |
| β’ Commercial Reports | |
| JM CT users can view various commercial reports related to project progress in the SAP PS system. | |
| β’ The Cost Element Report is used to view cost and revenues summarised by cost element | |
| β’ To monitor full value flow in the project, you can use Cost/Revenue and Payment hierarchy reports. Payment hierarchy reports contain data related to drill down into a project. | |
| β’ To display actual, plan, commitment, and budget values you can use Line-Item Reports. | |
| 5.8.1. Process: 08.01.07.01 Project Commitments | |
| In SAP PS commitment management is part of the cost monitoring process. Commitment items are triggered by purchase requisitions and purchase orders for projects and will be reduced by various business transactions such as goods receipts. | |
| For commitment reporting there will two types of reports available for JM CT: | |
| β’ Hierarchy reports | |
| β’ Line-item reports | |
| Each of these types of reports will analyse the commitments on projects at different levels of detail. | |
| β’ Hierarchy reports run faster than cost element reports and will present the results, based on the structure defined on the project. | |
| β’ Line-item reports are more detailed than cost element reports and hierarchy reports. Line-item reports will enable the user to select individual POs and items from the PO. | |
| The commitments on projects, will be integrated in two ways: | |
| 1. Purchase Requisition: A purchase requisition process refers to the flow of events that are triggered when any department needs to make a purchase. | |
| Purchase requisitions (PR) will be created across all sites in CT to procure direct, indirect, services or goods with reference to a project. | |
| 2. Purchase Order Process: A purchase order process refers to the flow of events that are triggered when the purchaser creates a purchase order with/without reference to purchase requisition. | |
| The purchase order (PO) will be created by CT to procure direct materials, indirect materials and services from suppliers set up in the system for projects. Most of the direct POs will be created by converting approved PRs to purchase orders and these orders will take the project number from the PR. | |
| 5.8.1.1. Level 4 Process Flow and Steps | |
| 08.01.07.01 Project commitments | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Commitments per month SAP With the execution of this report, the business user will be able to know the "commitment" of a project split per month. Project Manager/ | |
| Project Engineer | |
| Project controller S_ALR_87100187 | |
| Commitment line items SAP With the execution of this report, the business user will be able to know the "commitment" from a project per line-item. | |
| The commitment will be presented at PO item level. Project Manager/ | |
| Project Engineer | |
| Project controller CJI5 | |
| Commitment detail | |
| SAP With the execution of this report, the business user will be able to know the "commitment" in a project in detail. | |
| The system will present the commitment split by: | |
| β’ Purchase requisition open | |
| β’ Purchase orders open | |
| β’ Reservations Project Manager/ | |
| Project Engineer | |
| Project controller S_ALR_87013537 | |
| 5.8.1.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All Sites Commitment management will be a new function in projects, that will allow the different users from the JM CT business to know the total commitment and detailed commitment for projects in real time. This will be new to CT with the implementation of Project Systems, requiring new processes and training and understanding of the reporting options available. Realtime integration with the STP process (Source to pay). | |
| This standard integration between purchasing and projects, will provide project managers the ability to visualise the amounts already committed in a project. | |
| 5.8.1.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| All Sites N/A N/A | |
| 5.8.2. Process: 08.01.07.02 Project Revenues | |
| Several standard revenue reports will be available. The reports will provide different breakdowns to present the revenue allocated in a project, such as by WBS element, date month, cost element etc. | |
| All these reports are standard and will be available for the users. | |
| 5.8.2.1. Level 4 Process Flow and Steps | |
| Project Revenues | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Actual Revenue as per structure view SAP With the execution of this report, the business user will be able to know the "Revenue" on a project based around a project structure view. Project Manager / Project Engineer/Project controller S_ALR_87013563 | |
| Plan Revenue detail SAP With the execution of this report, the business user will be able to know the "Revenue" on a project at a line-item level. Project Manager / Project Engineer/Project controller S_ALR_87013564 | |
| 5.8.2.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All Sites Revenue management in SAP Projects is new to the business and will allow the different users from the JM CT business to know the total revenues in detail coming from sales orders in projects in real time. New processes will be applied in SAP and additional training will be required. Realtime integration with the STC process (Sales to cash). | |
| This standard integration between sales and projects will provide, to the project managers, the ability to visualise the revenue amounts forecasted and real. | |
| 5.8.2.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| All Sites N/A N/A | |
| 5.8.3. Process: 08.01.07.03 Project Costs | |
| Project Cost Management is the financial aspect of project management that involves allocating and tracking costs for projects. | |
| Projects of all types receive costs from various sources: | |
| β’ Material costs resulting from consumption recorded for the project. These credit project inventory | |
| β’ Service costs resulting from service confirmations. These credit the cost centres which performed the services. | |
| β’ Other direct costs using supplier invoices, journal entry vouchers, or expense reports | |
| β’ Some project types may also receive overhead costs using overhead distribution or overhead absorption. These credit cost centres | |
| β’ Customer projects are JM CT projects that are managed for customers and are always linked to a sales order. This integrates customer projects into the normal order-to-cash scenario and offers standard functions such as reporting by function of expense, profit analysis, and automatic revenue recognition. | |
| Reports relating to these costs are standard and will be available for users. | |
| 5.8.3.1. Level 4 Process Flow and Steps | |
| Project Costs | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Actual cost as per structure view SAP With the execution of this report, the business user will be able to know the "cost " from a project structural view. | |
| This uses the project structure defined for the project. Project Manager / Project Engineer | |
| Project controller S_ALR_8701351 | |
| Cost line items SAP With the execution of this report, the business user will be able to know the "cost" from a project line item view. | |
| The report will provide in detail all the charges that have been allocated into the project. This will provide full visibility on the origin of the movement to the user. Project Manager / Project Engineer | |
| Project controller CJI3 | |
| Planed cost detail SAP With the execution of this report, the business user will be able to know the "Cost" of a project in detail. Project Manager / Project Engineer | |
| Project controller S_ALR_8701352 | |
| 5.8.3.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All Sites Cost management in SAP Projects is a new process that will allow the different users from JM CT to know in detail the costs allocated into a project. This will require new processes and reporting. Additional training will be required. Realtime integration with the RTR process (Record to report). | |
| This standard integration between Finance and projects, will provide project managers the ability to visualise the amounts already allocated into a project. | |
| 5.8.3.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| All Sites N/A N/A | |
| 5.8.4. Process: 08.01.07.04 Project Cash Flow | |
| Reports will be available that will provide a cash flow view of payments, already made by a project to a vendor or multiple vendors. | |
| The reports will show the information related with the payment made, plus details like the payment method, payments terms, transfer reference, bank etc. | |
| The cash flow forecast is a function that is also included in the scope of the project, this will be managed through the setup of additional cost elements. The user will be able to schedule an estimated cashflow per year and per month, the user also will have to the option to modify and reschedule payments on the project forecast. | |
| All these reports are standard and will be available for users. | |
| 5.8.4.1. Level 4 Process Flow and Steps | |
| Project Cash Flow | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Actual Payments/ | |
| Payments Commitments SAP The user will be able to review the schedule of all the payments to be made and already paid by project. Project Manager / Project Engineer | |
| Project controller CJIA | |
| Payments SAP This report enables the user to view in detail all the payments that have been processed with project invoices. Project Manager / Project Engineer | |
| Project controller S_ALR_87013591 | |
| 5.8.4.2. To-be Changes | |
| CT Sites Changes Business Justification | |
| All Sites Cash flow in SAP Projects is a new process that will allow the different users from JM CT to know the total of payments already made over invoices received with reference to a project. Additional processes and reporting will be used, and training will be required. Consolidation to Project Systems within CT SAP. | |
| 5.8.4.3. Site Specific Changes | |
| CT Sites Changes Business Justification | |
| All Sites N/A N/A | |
| 5.9. Headline βTo- Beβ design changes | |
| The business has requested several changes to the way in which the Project Systems and Time Sheeting processes will be managed and executed in the future: | |
| Change Theme Change Statement | |
| Remove Agresso The consolidation of the businesses currently using Agresso on to the CT SAP system is a key change of the project. | |
| Revenue Recognition In moving from Agresso the implementation of revenue recognition on the system rather than the existing off system process. | |
| Time Sheeting With the removal of Agresso, a replacement solution for time sheeting is required. | |
| Project Systems Moving from Agresso requires the implementation of Project Systems within the CT SAP to enable these businesses to function. | |
| These changes were identified in HLD and do not provide an exhaustive list but were to provide indicative direction for the detailed design. | |
| To help deliver on these change themes, all aspects of the Operating Model wheel were considered through a series of workshops and the following changes have been identified. | |
| 5.10. Key Design Decisions | |
| The business has agreed to the following Key Outstanding Design Decisions as part of the new ways of working as it impacts the Project Systems and Time Sheeting processes to be managed and executed as part of the to-be design: | |
| No BAG Ref Theme Decisions | |
| N/A N/A N/A | |
| Reference link for cross functional key design decision | |
| 5.11. Policies and Compliance | |
| The Project Systems and Time Sheeting workstream must comply with JM Policies set by Group. They can be found on MyJM. Many of the policies dealing with ERP systems are codified in the ICFR, including Segregation of Duties, Proper Approvals, and Access Rights. Sites are also responsible for compliance with local Tax and Governmental Reporting requirements, which are typically supported by data from SAP. | |
| The following key policies have been identified as being impacted by the Concert design | |
| No New/Existing Decisions | |
| 1 Existing JM Accounting Policies to be adhered to | |
| 2 Existing JM Internal Control Framework (ICFR) to be adhered to | |
| 3 Existing JM Master Data polices to be followed | |
| Concert is considering related Controls and Policies in developing the Detailed Design. A complete list of Risk and Controls considered can be found in Risk and Control Matrix. | |
| 5.12. Key Value Drivers | |
| The design has highlighted for L3 processes the key value drivers resulting in the process harmonization and improvement (the why), to meet the business value statements and KPIs as highlighted in the High-level design. | |
| L3 Reference Value Driver Description KPI Reference Name (KPI's) Benefits | |
| CT will establish a common system for reporting of all RD&E initiatives and resources to provide better visibility and understanding of overall R&D costs using PS and Timesheets - enabling better decision making on use of R&D budget and resources Operating Efficiencies Total Cost of Finance Function | |
| CT will move the Licensing business from Agresso to SAP with other parts of CT enabling improved efficiencies of financial management and associated cost savings Cost Reduction Total Cost of Finance Function | |
| CT will establish a standard approach to the management of projects making use of Project Systems and Time Sheets across the business as appropriate. This will enable improved understanding of costs and resources and drive increased efficiency and visibility enabling better decision making and monitoring. Operating Efficiencies Total Cost of Finance Function | |
| β | |
| 5.13. Risk and Controls (to be completed by R&C Lead) | |
| Leveraging SAP Standard functionality can prove to be beneficial when controling and managing risk within workstreams. In the PS workstream the need to implement and thereafter operate a range of controls that are Automated, Semi-Automated or Manual hasnβt been identified. | |
| PS Control Type Summary | |
| Automated Automated β Access Automated β SOD Manual Semi-automated Total | |
| 1 1 - 6 2 10 | |
| PS Control Risk Rating Summary | |
| Critical High Medium Low Total | |
| 2 7 - 1 10 | |
| PS Control Current State Summary | |
| Not Operating Operating Partially Operating Total | |
| 1 8 1 10 | |
| Refer to the Risk and Control Matrix for detailed view of controls that will be applied - Link. | |
| 5.14. Roles and Skills | |
| 1. Analysis is based on only composite roles excluding direct assignment of single roles. | |
| 2. Global roles indicated below are our grouping of existing composite roles across company codes/purchasing organisation/plants for ease of reference. | |
| 3. Please refer to the file PS Business Roles Analysis.xlsb for mapping the existing composite roles to the grouping, as referred in point 2. | |
| Step owner SAP T-Code | |
| Project accountant/ Project controller CJ20N | |
| Project accountant/ Project controller CJ20N | |
| Project accountant/ Project controller CJ20N | |
| Project accountant/ Project controller CJ20N | |
| Project accountant/ Project controller CJ20N | |
| Project Manager CJ20N | |
| Project accountant/ Project controller CJ20N | |
| Project Manager CJ20N | |
| Project accountant/ Project controller CJ20N | |
| Project Manager CJ20N | |
| Project accountant/ Project controller CJ20N | |
| Project Manager CJ20N | |
| Master Data team CJ91 | |
| Master Data team CN02 | |
| Master Data team CJ91 | |
| Master Data team CJ92 | |
| Master Data team CN01 | |
| Master Data team CN02 | |
| Cost Engineer/ Project manager CJ40 | |
| Cost Engineer/ Project manager CJ9D | |
| Cost Engineer/ Project manager CJ30 | |
| Cost Engineer/ Project manager CJ30 | |
| Project Manager CJ32 | |
| Project Manager CJ20N | |
| Finance Controller/ Cost Engineer CJ9B | |
| Finance Controller/ Cost Engineer CJ40 | |
| Finance Controller/ Cost Engineer CJ40 | |
| Finance Controller/ Cost Engineer CJ40 | |
| Cost Engineer/ Project Accountant CJ9B | |
| Cost Engineer/ Project Accountant CJ40 | |
| Cost Engineer/ Project Accountant CJ30 | |
| Cost Engineer/ Project Accountant CJ32 | |
| Finance CAT7 | |
| Finance KP26 | |
| Finance KB15N | |
| Project Manager / Project Engineer/Lead Engineer/Planning Engineer CJI3 | |
| Project Manager / Project Engineer/Lead Engineer/Planning Engineer CATS_DA | |
| Project Administrator CJ20N | |
| Project Administrator CJ20N | |
| Project Finance Administrator KKAO | |
| Project Finance Administrator KKA2 | |
| Project Finance Administrator KKAJ | |
| Project Finance Administrator CJ20N | |
| Project Finance Administrator CJ40 | |
| Project Finance Administrator CJ42 | |
| Project Administrator CJ20N | |
| Project financial controller CJ88 | |
| Project financial controller CJ88 | |
| Project financial controller CJ8G | |
| Project financial controller CJ8G | |
| Project financial controller CJ20N | |
| Project financial controller CJ40 | |
| Project financial controller CJ88 | |
| Project financial controller CJ8G | |
| Project Administrator CJ20N | |
| Project Administrator CJ20N | |
| Project Administrator CJCO | |
| Project Administrator CJCF | |
| Project Manager / Project Engineer/Project controller S_ALR_87100187 | |
| Project Manager / Project Engineer/Project controller CJI5 | |
| Project Manager / Project Engineer/Project controller S_ALR_87013537 | |
| Project Manager / Project Engineer/Project controller S_ALR_87013563 | |
| Project Manager / Project Engineer/Project controller S_ALR_87013564 | |
| Project Manager / Project Engineer/Project controller S_ALR_8701351 | |
| Project Manager / Project Engineer/Project controller CJI3 | |
| Project Manager / Project Engineer/Project controller S_ALR_8701352 | |
| Project Manager / Project Engineer/Project controller CJIA | |
| Project Manager / Project Engineer/Project controller S_ALR_87013591 | |
| 5.14.1. Business Role Change Summaries | |
| Legends Description | |
| Business Role EYβs grouping of different business | |
| EY Global Role EYβs company code and/or site agnostic grouping of existing composite role(s) | |
| Distinct User Unique number of users that currently hold access to the composite role(s) | |
| Comments Brief description of the access the composite role provides | |
| T-Codes (required by Business Role) Tick mark means Composite role provides access | |
| SoD EYβs indicator of whether the existing composite role(s) contain segregation of duties concern | |
| SA EYβs indicator of whether the existing composite role(s) contains sensitive access from a financial reporting perspective | |
| 5.14.1.1. Business Role Finance | |
| a. As per BPD, individuals with business role βFinanceβ require access to 3 specific T-codes: | |
| i. CAT7 | |
| ii. KP26 | |
| iii. KB15N | |
| b. Through analysis of the existing SAP composite roles, we noted that 5 such SAP composite roles were providing access to one of the mentioned T-codes. | |
| c. None of the roles grant access to two T-codes: CAT7 and KB15N. | |
| See summary below: | |
| Business Role EY Global Roles Comments Distinct Users Finance SOD SA | |
| KP26 | |
| Finance Y_FI_CCXX_FINANCE_OPERATIONS This role is implemented for company codes DE35, IN10, SE33, US32, US38 and GB30. 22 οΌ οΌ | |
| Finance Y_FI_CCXX_PRODUCT_COSTING This role is implemented for company codes DE35, IN10, SE33, US32, US38 and GB30. 17 οΌ οΌ | |
| Finance Y_FI_CCXX_BUSINESS_ACCOUNTANT This role is implemented for company code GB30 only. 9 οΌ οΌ οΌ | |
| Finance Y_FI_CCXX_FINANCE_OPS_PARK This role is implemented for company code GB30 only. 2 οΌ οΌ | |
| Finance Y_FI_CCXX_FINANCE_OPS_POST This role is implemented for company code GB30 only. 1 οΌ οΌ | |
| Change(s) Required β | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Finance responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate. | |
| 3. As these are marked as Sensitive Access; ensure that no users outside of those with Finance responsibilities are assigned these SAP roles. | |
| 4. 1/5 composite roles are marked as SoD; ensure that access to conflicting T-Codes is either mitigated or access to conflicting T-code(s) are withdrawn from these SAP roles. | |
| 5. Ensure that none of these SAP roles are intended for business roles that do not have Finance responsibilities. | |
| 6. Add 2/3 missing Finance T-Codes to existing composite role(s) - None of the 5 composite roles provide access to 2 T-Codes (CAT7 and KB15N). | |
| 5.14.1.2. Business Role Project Accountant | |
| As per BPD, individuals with business role βProject Accountantβ require access to 5 specific T-codes: | |
| a. CJ20N | |
| b. CJ9B | |
| c. CJ40 | |
| d. CJ30 | |
| e. CJ32 | |
| Through analysis of the existing SAP composite roles, we noted that 4 such SAP composite roles were providing access to one of the mentioned T-codes. | |
| None of the roles grant access to four T-codes: CJ9B, CJ30 and CJ32 and CJ40. | |
| See summary below: | |
| Business Role EY Global Roles Comments Distinct Users Project Accountant SOD SA | |
| CJ20N | |
| Project accountant Y:EC_GLOBL_OTC_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project accountant Y:EC_GLOBL_PTM_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project accountant Y:EC_GLOBL_PTP_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project accountant Y:EC_GLOBL_RTR_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Change(s) Required β | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Project Accountant responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate. | |
| 3. All composite roles are marked as SoD; ensure that access to conflicting T-Codes is either mitigated or access to conflicting T-code(s) are withdrawn from these SAP roles. | |
| 4. Add 4/5 missing Project Accountant T-Codes to existing composite role(s) - None of the 4 composite roles provide access to 4 T-Codes required. | |
| 5.14.1.3. Business Role Project Controller | |
| As per BPD, individuals with business role βProject Controllerβ require access to 11 specific T-codes: | |
| a. CJ20N | |
| b. S_ALR_87100187 | |
| c. CJI5 | |
| d. S_ALR_87013537 | |
| e. S_ALR_87013563 | |
| f. S_ALR_87013564 | |
| g. S_ALR_8701351 | |
| h. S_ALR_8701352 | |
| i. S_ALR_87013591 | |
| j. CJI3 | |
| k. CJIA | |
| Through analysis of the existing SAP composite roles, we noted that 4 such SAP composite roles provided access to one or more of the mentioned T-codes. | |
| None of the roles grant access to nine T-codes: CJI5, CJIA, and S_ALR_87100187, S_ALR_87013563, S_ALR_87013564, S_ALR_8701351, S_ALR_8701352, S_ALR_87013591and S_ALR_87013537. | |
| See summary below: | |
| Business Role EY Global Roles Comments Distinct Users Project Controller SOD SA | |
| CJ20N CJI3 | |
| Project controller Y:EC_GLOBL_OTC_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ οΌ | |
| Project controller Y:EC_GLOBL_PTM_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ οΌ | |
| Project controller Y:EC_GLOBL_PTP_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ οΌ | |
| Project controller Y:EC_GLOBL_RTR_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ οΌ | |
| Change(s) Required β | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Project Controller responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate. | |
| 3. All composite roles are marked as SoD; ensure that access to conflicting T-Codes is either mitigated or access to conflicting T-code(s) are withdrawn from these SAP roles. | |
| 4. Add 9/11 missing Project Controller T-Codes to existing composite role(s) - None of the 4 composite roles provide access to 9 T-Codes required. | |
| 5.14.1.4. Business Role Project Admin | |
| As per BPD, individuals with business role βProject Adminβ require access to 3 specific T-codes: | |
| a. CJ20N | |
| b. CJCO | |
| c. CJCF | |
| Through analysis of the existing SAP composite roles, we noted that 4 such SAP composite roles were providing access to one of the mentioned T-codes. | |
| None of the roles grant access to 2 T-codes: CJCO and CJCF | |
| See summary below: | |
| Business Role EY Global Roles Comments Distinct Users Project Administrator SOD SA | |
| CJ20N | |
| Project Administrator Y:EC_GLOBL_OTC_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Administrator Y:EC_GLOBL_PTM_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Administrator Y:EC_GLOBL_PTP_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Administrator Y:EC_GLOBL_RTR_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Change(s) Required β | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Project Administrator responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate. | |
| 3. All composite roles are marked as SoD; ensure that access to conflicting T-Codes is either mitigated or access to conflicting T-code(s) are withdrawn from these SAP roles. | |
| 4. Add 2/3 missing Project Administrator T-Codes to existing composite role(s) - None of the 4 composite roles provide access to 2 T-Codes required. | |
| 5.14.1.5. Business Role Project Finance Admin | |
| As per BPD, individuals with business role βProject Finance Adminβ require access to 6 specific T-codes: | |
| a. KKAO | |
| b. KKA2 | |
| c. KKAJ | |
| d. CJ20N | |
| e. CJ40 | |
| f. CJ42 | |
| Through analysis of the existing SAP composite roles, we noted that 4 such SAP composite roles were providing access to one or more of the mentioned T-codes. | |
| None of the roles grant access to four T-codes: KKA2, KKAJ, CJ40 and CJ42 | |
| See summary below: | |
| Business Role EY Global Roles Comments Distinct Users Project Finance Administrator SOD SA | |
| CJ20N KKAO | |
| Project Finance Administrator Y:EC_GLOBL_OTC_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Finance Administrator Y:EC_GLOBL_PTM_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Finance Administrator Y:EC_GLOBL_PTP_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Finance Administrator Y:EC_GLOBL_RTR_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Finance Administrator Y_FI_CCXX_PRODUCT_COSTING This role is implemented for company codes DE35, IN10, SE33, US32, US38 and GB30. 17 οΌ οΌ | |
| Change(s) Required β | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Project Finance Administrator responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate. | |
| 3. 4/5 composite roles are marked as SoD; ensure that access to conflicting T-Codes is either mitigated or access to conflicting T-code(s) are withdrawn from these SAP roles. | |
| 4. Add 4/6 missing Project Finance Administrator T-Codes to existing composite role(s) - None of the 4 composite roles provide access to 4 T-Codes required. | |
| 5.14.1.6. Business Role Project Financial Controller | |
| As per BPD, individuals with business role βProject Financial Controllerβ require access to 4 specific T-codes: | |
| a. CJ20N | |
| b. CJ8G | |
| c. CJ40 | |
| Through analysis of the existing SAP composite roles, we noted that 4 such SAP composite roles were providing access to one or more of the mentioned T-codes. | |
| None of the roles grant access to 2 T-codes: CJ8G and CJ40. | |
| See summary below: | |
| Business Role EY Global Roles Comments Distinct Users Project Financial Controller SOD SA | |
| CJ20N CJ88 | |
| Project financial controller Y:EC_GLOBL_OTC_SUPPORT_DISP 10 οΌ οΌ οΌ οΌ | |
| Project financial controller Y:EC_GLOBL_PTM_SUPPORT_DISP 10 οΌ οΌ οΌ οΌ | |
| Project financial controller Y:EC_GLOBL_PTP_SUPPORT_DISP 10 οΌ οΌ οΌ οΌ | |
| Project financial controller Y:EC_GLOBL_RTR_SUPPORT_DISP 10 οΌ οΌ οΌ οΌ | |
| Change(s) Required β | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Project Financial Controller responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate. | |
| 3. All composite roles are marked as SoD; ensure that access to conflicting T-Codes is either mitigated or access to conflicting T-code(s) are withdrawn from these SAP roles. | |
| 4. Add 2/4 missing Project Financial Controller T-Codes to existing composite role(s) - None of the 4 composite roles provide access to 2 T-Codes required. | |
| 5.14.1.7. Business Role Project Manager | |
| As per BPD, individuals with business role βProject Managerβ require access to 16 specific T-codes: | |
| a. CJ20N | |
| b. S_ALR_87100187 | |
| c. CJI5 | |
| d. S_ALR_87013537 | |
| e. S_ALR_87013563 | |
| f. S_ALR_87013564 | |
| g. S_ALR_8701351 | |
| h. S_ALR_8701352 | |
| i. S_ALR_87013591 | |
| j. CJI3 | |
| k. CJIA | |
| l. CATS_DA | |
| m. CJ30 | |
| n. CJ32 | |
| o. CJ9D | |
| p. CJ40 | |
| Through analysis of the existing SAP composite roles, we noted that 4 such SAP composite roles provided access to one or more of the mentioned T-codes. | |
| None of the roles grant access to 14 T-codes: CJI5, CJIA, and S_ALR_87100187, S_ALR_87013563, S_ALR_87013564, S_ALR_8701351, S_ALR_8701352, S_ALR_87013591and S_ALR_87013537, CJ9D, CATS_DA, CJ30, CJ32 and CJ40. | |
| See summary below: | |
| Business Role EY Global Roles Comments Distinct Users Project Manager SOD SA | |
| CJ20N CJI3 | |
| Project Manager Y:EC_GLOBL_OTC_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ οΌ | |
| Project Manager Y:EC_GLOBL_PTM_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ οΌ | |
| Project Manager Y:EC_GLOBL_PTP_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ οΌ | |
| Project Manager Y:EC_GLOBL_RTR_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ οΌ | |
| Change(s) Required β | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Project Manager responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate. | |
| 3. All composite roles are marked as SoD; ensure that access to conflicting T-Codes is either mitigated or access to conflicting T-code(s) are withdrawn from these SAP roles. | |
| 4. Add 14/16 missing Project Manager T-Codes to existing composite role(s) - None of the 4 composite roles provide access to 14 T-Codes required. | |
| 5.14.1.8. Business Roles Project Engineer/Lead Engineer/Planning Engineer | |
| As per BPD, individuals with business role βProject Engineer/Lead Engineer/Planning Engineerβ require access to 2 specific T-codes: | |
| a. CJI3 | |
| b. CATS_DA | |
| Through analysis of the existing SAP composite roles, we noted that 4 such SAP composite roles were providing access to one of the mentioned T-codes. | |
| None of the roles grant access to 1 T-code: CATS_DA | |
| See summary below | |
| Business Role EY Global Roles Comments Distinct Users Project/Lead/Planning Engineer SOD SA | |
| CJI3 | |
| Project Engineer/Lead Engineer/Planning Engineer Y:EC_GLOBL_OTC_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Engineer/Lead Engineer/Planning Engineer Y:EC_GLOBL_PTM_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Engineer/Lead Engineer/Planning Engineer Y:EC_GLOBL_PTP_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Project Engineer/Lead Engineer/Planning Engineer Y:EC_GLOBL_RTR_SUPPORT_DISP 1. This role is currently implemented for all Company Codes | |
| 2. This is currently a display only role 10 οΌ οΌ οΌ | |
| Change(s) Required β | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Project/Lead/Planning Engineer responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate. | |
| 3. All composite roles are marked as SoD; ensure that access to conflicting T-Codes is either mitigated or access to conflicting T-code(s) are withdrawn from these SAP roles. | |
| 4. Add 1/2 missing Project/Lead/Planning Engineer T-Codes to existing composite role(s) - None of the 4 composite roles provide access to 1 T-Code required. | |
| 5.15. Business, Functional and Non-functional Requirements and solution Design | |
| 5.15.1. Business and Functional Requirements | |
| Refer to the Project Systems and Time Sheets Functional Design Document (FDD) | |
| 5.15.2. Non-functional Requirements | |
| Specify any No-functional Requirements (NFRs) that are identified during the design activities. These will be fed into the NFR section of the RTM after high level design. NFRs include SLAs, user numbers, transaction volumes, archiving, system performance, Business continuity / disaster recovery requirements. | |
| Ref NFR Category NFR Description NFR Type (SLA / Volumes etc.) | |
| 1 None Identified N/A N/A | |
| 5.15.3. Design Gaps | |
| Specify requirement that is not met by SAP Standard and which a design decision is still to be determined through the JM Governance process | |
| Ref Requirement Description GAP Resolution Options Impact (L/M/H) Resolution Date Owner | |
| 1 Workday Integration Interface development H tbc Marco Desentis | |
| 2 Licensing Cost Reports Enhancement to reporting H tbc Marco Desentis | |
| 3 Segment User Field Validation Enhancement to validation M tbc Marco Desentis | |
| 5.16. Data Impact | |
| Name of Data Object Object Type (Standard/Custom) (New/Existing) Name of the (Table) Name of the (Field) Data Requirement | |
| (Mention "No Improvement" if object not in scope for any data improvements) Sites Impacted/Affected Remarks | |
| PSTM_C001 Activity Rates for timesheets COST TBC In scope All | |
| PSTM_C002 1001 β activity types CSSL TBC In scope All | |
| PSTM_C007 1029 β Project hours CAUFV TBC In scope All | |
| PSTM_C003 Project definition / WBS element PROJ | |
| PRPS TBC In scope All | |
| PSTM_C004 1075 β WBS budget RPSCO | |
| BPJA TBC In scope Licensing and Formox sites | |
| PSTM_C005 1077 β WBS plan COEP/ COSP/ COSS TBC In scope Licensing and Formox sites | |
| PSTM-C006 Network / activities RPSCO / CAUFV TBC In scope Licensing Sites | |
| 6. Risks, Issues, Actions and Dependencies | |
| 6.1.1. Design Risks and Issues (outstanding) | |
| Document any risks / Issues impacting on the business process design / solution and ability to deliver the scope within the agreed schedule timeline and budget and deliver on the benefits. | |
| Ref No Risk / Issue Description Impact Status Mitigation Resolution Date | |
| 1 Workday integration High Open JM IT is working on the assembly of the corresponding team, to support project Concert on the definition of the data and technical integration between Workday and SAP TBC | |
| 6.1.2. Design Related Actions | |
| Document any open actions assigned to the design group as part of the business process design / solution that is required to be completed and could impact the realisation phase. | |
| Ref Action Owner Due Date Status Closed / Open | |
| 1 Workday Integration | |
| There still definitions to make for the integration between SAP (HR-Mini master) and Workday. | |
| There still need to be reviewed: | |
| β’ Data model mapping between both systems | |
| β’ Technical integration | |
| β’ Technical connectivity to be used Carl Scarlet / Marco Desentis TBC Open | |
| 6.1.3. Process Area Dependencies | |
| Document any dependencies with other processes that will impact the end to end design of the above solution. | |
| Ref ID Dependency Area Dependency Description Agreed (Y/N) Type | |
| Predecessor / Post step Integration Process Flow Ref | |
| D001 RTR Dunning procedure TBC | |
| D002 RTR Credit Management TBC | |
| D004 RTR Automated credit approval TBC | |
| D004 LES Stock Allocation for sales TBC | |
| β | |
| 7. Appendix | |
| 7.1. Segmentation | |
| The following table details the segmentation structure that will be used to tag projects within CT. This is to enable reporting of time and costs based on market segments. This list will be used to create a table from which the segment can be selected when a project is created. The table will use the column of names that are 20 characters long or less due to limitations with the User Fields in SAP. | |
| URN Category Group Value Chain Segment Group Segment Segment for User Field | |
| (β€ 20 characters) | |
| URN01 Base Business Building Blocks Formaldehyde Formaldehyde - Wood & Chemicals Formaldehyde - W&C | |
| URN02 Base Business Building Blocks Methanol Methanol - Fuel Additives & Chemicals Methanol - F&C | |
| URN03 Base Business Building Blocks Nitrogen Amines Amines | |
| URN04 Base Business Building Blocks Nitrogen Ammonia - Fertilizers & Chemicals Ammonia - Fertil. | |
| URN05 Base Business Building Blocks Nitrogen Nitric Acid Nitric Acid | |
| URN06 Base Business Building Blocks PTA PTA PTA | |
| URN07 Base Business Fuels & Energy FCC Additives FCC Additives Additives | |
| URN08 Base Business Fuels & Energy FCC Additives (ZSM-5) FCC Additives (ZSM-5) Additives (ZSM-5) | |
| URN09 Base Business Fuels & Energy Gas Purification Natural Gas Processing Nat. Gas Processing | |
| URN10 Base Business Fuels & Energy GTL GTL GTL | |
| URN11 Base Business Fuels & Energy Refinery Fuels Refinery Fuels Refinery Fuels | |
| URN12 Base Business Fuels & Energy Refinery Hydrogen Refinery Hydrogen Refinery Hydrogen | |
| URN13 Base Business Fuels & Energy Refinery Purification Refinery Purification Refinery Purif. | |
| URN14 Base Business Fuels & Energy SNG SNG from Coal SNG from Coal | |
| URN15 Base Business Intermediates Acetic Acid Acetic Acid Acetic Acid | |
| URN16 Base Business Intermediates Agchem Paraquat Alternatives Paraquat Altern. | |
| URN17 Base Business Intermediates Alcohols Alcohols - Detergent Alcohols Alcohols - DA | |
| URN18 Base Business Intermediates Alcohols Alcohols - Natural Detergent Alcohols Alcohols - NDA | |
| URN19 Base Business Intermediates Alcohols Alcohols - Oxo-Alcohols Alcohols - Oxo | |
| URN20 Base Business Intermediates Alcohols Alcohols - Polyols Alcohols - Polyols | |
| URN21 Base Business Intermediates Alcohols Alcohols - Tech Polymer Diols Alcohols - Tech Pol | |
| URN22 Base Business Intermediates Edible Oils Edible Oils Edible Oils | |
| URN23 Base Business Intermediates Fluorochemicals Fluorochemicals Fluorochemicals | |
| URN24 Base Business Intermediates Hydrogen Peroxide Hydrogen Peroxide Hydrogen Peroxide | |
| URN25 Base Business Intermediates Olefins Olefins Olefins | |
| URN26 Base Business Intermediates Oleochemicals Oleochemicals Oleochemicals | |
| URN27 Base Business Intermediates Solvents Solvents Solvents | |
| URN28 Base Business Intermediates Sponge Sponge Sponge | |
| URN29 Base Business Intermediates VCM VCM via Ethylene (EDC) VCM via Ethylene | |
| URN30 Base Business Other Copper Zeolite Copper Zeolite (77-1 and CuZe) Copper Zeolite | |
| URN31 Base Business Other Environmental Catalysts Environmental Catalysts Environ. Catalysts | |
| URN32 Emerging Building Blocks CO2 Purification CO2 Purification CO2 Purification | |
| URN33 Emerging Building Blocks MEG MEG MEG | |
| URN34 Emerging Building Blocks SNG SNG for CO2 Transport SNG - CO2 Transport | |
| URN35 Emerging Fuels & Energy Bio-pyrolysis Bio-pyrolysis (Anellotech) Bio-pyrolysis | |
| URN36 Emerging Fuels & Energy Blue Hydrogen Blue Hydrogen (LCH) Blue Hydrogen (LCH) | |
| URN37 Emerging Fuels & Energy Electrolyser Gas Purification Electrolyser Gas Purification Electr. Gas Purif. | |
| URN38 Emerging Fuels & Energy Green Hydrogen Green Hydrogen Purification for Automotive Green H2 Purif. | |
| URN39 Emerging Fuels & Energy Sustainable Fuels non Syngas routes Biodiesel Biodiesel | |
| URN40 Emerging Fuels & Energy Sustainable Fuels non Syngas routes Biorefining (Virent) Biorefining | |
| URN41 Emerging Fuels & Energy Sustainable Fuels Syngas routes FT for SAF FT for SAF | |
| URN42 Emerging Intermediates Ethyl Acetate Ethyl Acetate Ethyl Acetate | |
| URN43 Emerging Intermediates VCM VCM via Acetylene VCM via Acetylene | |
| URN44 Emerging Other Low Carbon Solutions Low Carbon Solutions Low Carbon Solution | |
| URN45 Emerging Other Plastics Recycling Plastics Recycling - Catalytic Pyrolysis & Purification Plastics Recycling | |
| URN46 Emerging Other Ventilation Air Methane Abatement Ventilation Air Methane Abatement (COMET) Methane Abatement | |