Template Identifier Group IT Project Scope Document ...

Group IT Project Scope Statement

Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020

Review Date April 2023

Controlled Disclosure

Page 1 of 27 File name: TXSAE01 - Group IT Project Scope Statement.docx

When downloaded from the document management system, this document is uncontrolled and the responsibility rests with the user to ensure it is in line with the authorised version on the system.

No part of this document may be reproduced without the expressed consent of the copyright holder, Eskom Holdings SOC Limited, Reg No 2002/015527/30.

1 PROJECT DETAILS

Project No.’s ID DEM-02971-Y4L9 WBS C.TXSAE01 N.TXSAE01

Project Name Cross Border Energy Trading Solution

GIT Customer Area Tx

Portfolio Manager Demand

Carlos Betencourt

Project Manager Delivery Busisiwe Nkangana

Programme / Project Manager

Johann Knoetze

Project Sponsor Rosemary Gamede

PLCM Phase Execution Phase

2 ABBREVIATIONS

Abbreviation Description

ACE Analytics Centre of Excellence Department

ARIS Architecture of Integrated Information Systems

SADC Southern African Developing Community

SAPP CC Southern African Power Pool Co-ordination Centre

NCC National Control Centre

NERSA National Energy Regulation of South Africa

IDM Integrated Demand Management

BRM Business Relationship Management


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






Abbreviation Description

BRS Business Requirements Specification

CR Change Request

DR Disaster Recovery

DFD Data Flow Diagram

GIT Group Information Technology Division, also referred to as Group IT

ITSO Information Technology Service Operations

ICT Information Technology

IT International Trader

KPA Key Performance Area

KPI Key Performance Indicator

PCM Process Control Manual

SIS Strategic Intent Statement

SLA Service Level Agreement

UI User Interface

SAPP Southern African Power Pool

ETS Energy Trading System

Tx MDMS Transmission Meter Data Management System

TEMSE Transmission Energy Management System Evolution

SOA Service Oriented Architecture

CC&B Customer Care and Billing

TWh Terra Watt per Hour

MWh Mega Watt per Hour

MS Microsoft

MTP Market Trading Platform


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






3 GLOSSARY OF TERMS / DEFINITIONS

Term Definition

Analytics Refers to the business intelligence capability.

Business Continuity

Business continuity encompasses planning and preparation to ensure that an organization can continue to operate in case of serious incidents or disasters and is able to recover to an operational state within a reasonably short period.

Business Intelligence

The term Business Intelligence (BI) refers to technologies, applications and practices for the collection, integration, analysis, and presentation of business information. The purpose of Business Intelligence is to support better business decision making. It can also be described as a broad set of data analysis applications, including ad hoc analysis and querying, enterprise reporting, online analytical processing (OLAP), mobile BI, real-time BI, operational BI, cloud and software as a service BI, open source BI, collaborative BI and location intelligence.

Business Requirements Specification

Business requirements specification is the eliciting, analysing and documenting of business requirements early in the development cycle to guide the design of the solution.

Business Rule A business rule is a rule that defines or constrains some aspect of business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behaviour of the business.

Business rules describe the operations, definitions and constraints that apply to an organization. Business rules can apply to people, processes, corporate behaviour and computing systems in an organization, and are put in place to help the organization achieve its goals.

Change Request

A change request is when an enhancement is made to an existing system that meets specific criteria.

Disaster Recovery / Disaster Recovery Plan

A disaster recovery plan (DRP) is a documented process or set of procedures to recover and protect a business ICT infrastructure in the event of a disaster. Such a plan, ordinarily documented in written form, specifies procedures an organization is to follow in the event of a disaster. It is "a comprehensive statement of consistent actions to be taken before, during and after a disaster".

External Agents

Sends information to and receive information from analysis area of study/focus area.

Innovation Innovation generally refers to changing processes or creating more effective processes, products and ideas. For businesses, this could mean implementing new ideas, creating dynamic products or improving your existing services. Predominantly focuses on digitisation type projects.

Process Set of activities that describe how an activity is executed.

Project A project consists of a concrete and organized effort motivated by a perceived opportunity when facing a problem, a need, a desire or a source of. It seeks the realization of a unique and innovative deliverable, such as a product, a service, a process, or in some cases, a scientific research. Each project has a beginning


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






Term Definition

and an end, and as such is considered a closed dynamic system. It is developed along the 4 Ps of project management: Plan, Processes, People, and Power. It is bound by the triple constraints that are calendar, costs and norms of quality, each of which can be determined and measured objectively along the project lifecycle. Each project produces some level of formal documentation, the deliverable(s), of course, and some impacts, which can be positive and/or negative.

Software License Purchase

A software license is a legal instrument (usually by way of contract law, with or without printed material) governing the use or redistribution of software. All software is copyright protected, in source code as also object code form. The only exception is software in the public domain. A typical software license grants the licensee, typically an end-user, permission to use one or more copies of software in ways where such a use would otherwise potentially constitute copyright infringement of the software owner's exclusive rights under copyright law.

System An organized, purposeful structure that consists of interrelated and interdependent elements (components, entities, factors, members, parts etc.). These elements continually influence one another (directly or indirectly) to maintain their activity and the existence of the system, in order to achieve the goal of the system

Wheeling Wheeling entails transmitting a contractual amount of power for specified time periods through the system of an operating member who is neither the seller nor the buyer of this power.

4 PROJECT SCOPE STATEMENT OVERVIEW

The project scope statement is the definition of the project – what needs to be accomplished. Define Scope is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the project, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope. It also enables the project team to perform more detailed planning, guides the project team’s work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries. The degree and level of detail to which the project scope statement defines what work will be performed and what work is excluded can determine how well the project management team can control the overall project scope. Managing the project scope, in turn, can determine how well the project management team can plan, manage, and control the execution of the project.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






5 SOLUTION BACKGROUND AND CONTEXT

The International Trader under Eskom Transmission is responsible for executing the Energy Africa Strategy, which was approved by the Eskom Board in April 2014. International Trader’s mandate includes pursuit of development and execution of business opportunities on the African continent. The intent is to increase exports through cross border energy trading, strengthening transmission system, accessing strategic resources (primary energy, power stations etc.), pursuing additional, more diversified revenue streams and supporting regional development. The business is using Energy Trading System (ETS) for Energy Trading. The “Energy Trading

System” provides international (cross border) energy trading operations, the capability to do the

following activities:

• To facilitate the scheduling and confirmation of numerous bilateral contracts and Southern

African Power Pool (SAPP) markets schedules.

• Enables the settling energy related elements of multiple financial contracts being transported

concurrently over cross-border transmission networks.

• Enables Financial Settlements, Billing and Invoicing of complex contracts, uniquely designed

around the specific constraints and requirements of parties entering into the bilateral agreement.

• Enables system integration with Meter Data Management System (MDMS), Transmission

Energy Management System Evolution (TEMSE), Pool Operations Web Interface (POWI) or

THEMIS (data management system used in Transmission for power exchange) and Customer

Care and Billing (CC&B)

• Reporting

6 OBJECTIVES

6.1 Business objectives

6.1.1 Measurable critical success criteria of the business requirement

• To implement the Cross-Border Energy Trading Solution through the Group IT PMO with the approved methodology.

• To complete the project within the approved budget.

• To complete the project within the approved timelines.

• Ensure the project meets the approved business objectives.

• To ensure continuous integration with all stakeholders for the project i.e Group IT and Transmission.

• Ensure project governance is always adhered to.

• To align and assist in the achievement of the Eskom Business Plan.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






6.1.2 Business benefits/value of the solution

6.1.2.1 Quantifiable Benefits

• Eliminate manual capturing

• Automation of system update and schedules

• Elimination of double work

6.1.2.2 Non-Quantifiable Benefits

• Accurate reporting

• Efficient business process

• Accurate Energy & Financial settlements/calculations & Billing

• Elimination of potential disruption of current business process

• Maintenance of current customer service levels

6.1.3 Financial benefit

No financial evaluation was conducted as there was nothing to compare to at this pre-planning phase. This is an initiative to ensure continuation of Business critical operations.

7 PROJECT REQUIREMENTS

7.1 Functional Requirements:

Functionality grouping

BRS Number

Functionality Business Rule No and Description Priority / phasing

Energy Schedule

BRS 1 Ability to manage energy schedules

Energy scheduling and submission of energy schedules

High

BRS 1.1 Ability to schedule energy trades

SAPP Market trades are scheduled together with Bilateral trades on the energy trading system

High

BRS 1.2 Ability to send the energy trading schedules to National Control Centre (NCC)

All the schedules are submitted to the National Control Centre-(NCC) for real time monitoring and control of power flows

High

BRS 1.3 Ability to schedule energy trading transaction.

The requesting trading partner submits final bilateral and wheeling schedules or requests to Trading Operations for

High


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020







BRS Number


scheduling the transactions of the energy flows.

BRS 1.4 Ability to submit final energy trading schedules

The final schedules are submitted to the National Control Centre-(NCC) and to the requestor for real time monitoring and control of the power flows

High

Financial Settlement Design

BRS 2 Ability to manage financial settlements design

Design and Calculate Financial Settlements High

BRS 2.1 Ability to design financial settlement bill

The bill layout is designed and shared with the trading partner for their approval before commencing to the finalisation of the user requirements.

High

BRS 2.2 Ability to submit financial settlement change control request

The change request form has to be approved to affect the system changes where applicable. Reference is made to the Service Level Agreement (SLA) because a limited number of changes are allowed every year per SLA.

High

BRS 2.3 Ability to provide financial settlement source data configuration

Information is provided to the Billing System Provider specifically outlining the applicable tariffs, rates etc. in terms of each PSA.

High

BRS 2.4 Ability to approve the User Requirements Specification

Once the bill layout finalised, the user requirement specifications as provided by the system service provider are approved.

High

BRS 2.5 Ability to test prototype energy settlement bill

Once the bill layout finalised, the user requirement specifications as provided by the system service provider are tested.

High

BRS 2.6 Ability to approve prototype energy settlement bill

Once the bill prototype functionality is correct then the prototype bill will be signed off for the actual bill to be designed on the system.

High

Energy Settlement Design

BRS 3 Ability to manage energy settlements design

Design and Calculate Energy Settlements High

BRS 3.1 Ability to design energy settlement bill

The bill layout is designed and shared with the trading partner for their approval before

High


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020







BRS Number


commencing to the finalisation of the user requirements.

BRS 3.2 Ability to submit energy settlement change control request

The change request form has to be approved to affect the system changes where applicable. Reference is made to the Service Level Agreement (SLA) because a limited number of changes are allowed every year per SLA

High

BRS 3.3 Ability to provide energy settlement source data configuration

Information is provided to the Billing System Provider specifically outlining the meters to be read. The information will also include sources of certain data required to calculate the bill such as relevant schedule forms and columns.

High

BRS 3.4 Ability to approve the User Requirements Specification

Once data sources have been identified, forms designed and bill layout finalised, the user requirement specifications as provided by the system service provider are approved.

High

BRS 3.5 Ability to test prototype energy settlement bill

Once data sources have been identified, forms designed and bill layout finalised, the user requirement specifications as provided by the system service provider are tested.

High

BRS 3.6 Ability to approve prototype energy settlement bill

Once the bill prototype functionality is correct then the prototype bill will be signed off for the actual bill to be designed on the system.

High

Billing BRS 4 Ability to manage billing

Energy Billing and Verification High

BRS 4.1 Ability to generate or run the bill

High

BRS 4.2 Ability to send instruction to run energy trading bill

An instruction is sent to Group Customer Services (GCS) Billing Department to run the bill

High

BRS 4.3 Ability to verify energy settlements

The energy portion of the bill is verified after the bill has been run to ensure that the energy volumes tie up with reconciled volumes.

High


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020







BRS Number


BRS 4.4 Ability to resolve energy settlements discrepancy

Should there be a discrepancy between the energy volumes on the bill and the reconciled schedules, the discrepancy need be resolved and the bill e re-run.

High

BRS 4.5 Ability to verify financial settlements

The financial settlement portion of the bill is verified after the energy trading bill has been run to ensure that the energy tariffs and energy rates are correct

High

BRS 4.6 Ability to resolve financial settlements discrepancy

Should there be a discrepancy between the bill and the reconciled schedules, applicable energy rates and energy tariffs, the discrepancy need be resolved and the bill re-run.

High

BRS 4.7 Ability to verify financial constants

The trading partner’s account balance brought forward, payments and due date are verified after the bill has been run for accuracy.

High

BRS 4.8 Ability to resolve financial constants discrepancy

Should there be a discrepancy between the bill and the actual information/constants, the discrepancy needs to be resolved and the bill re-run.

High

BRS 4.9 Ability to rerun the bill for prior month adjustments

Should there be a need for correction of prior month/s bills, an instruction will be issued to the relevant billing area to rerun the bill/s

High

BRS 4.10

Ability to dispatch energy trading bill

The bill is dispatched to the trading partner.

High

BRS 4.11

Ability to get notification immediately when the bill is dispatched

High

Reporting BRS 5 Ability to run/draw ad-hoc reports

Medium

BRS 5.1 Ability to draw/run incremental losses report

High

BRS 5.2 Ability to run/draw international trader report

The report is verified to ensure that imbalanced energy has been reconciled and allocated properly and correctly.

High


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020







BRS Number


BRS 5.3 Ability to run/draw Eskom management report

High

BRS 5.4 Ability to run/draw Shareholders report

High

BRS 5.5 Ability to run/draw utility transaction report

High

Integration BRS 6 Ability to combine data residing in different sources and providing users with a unified view of data

Adhere to Integration Centre of Excellence’s integration rules

High

BRS 6.1 Capability to integrate with Tx MDMS


High

BRS 6.2 Capability to integrate with THEMIS/POWI or the TEMSE Historian

Adhere to Integration Centre of Excellence’s integration rules High

BRS 6.3 Capability to integrate with SAPP MTP


High

BRS 6.4 Capability to integrate with Financial/Billing System(s)

Adhere to Integration Centre of Excellence’s integration rules High

Audit Trail

BRS 7 Ability to trace end user access & rights

Logical access & user rights control High

BRS 7.1 End User Audit Trail The business must be able to trace end user activities

High

BRS 7.2 Data/Information Audit Trail

The business must be able to trace the historical data prior and after data updates (Billing data freeze)

High

BRS 7.3 System Configuration Audit Trail

Change control High


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






7.1.1 Data flow diagram OR Context diagram

Figure 1: As-Is


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






Figure 2: To-Be


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






7.1.2 Information/data requirements

The following table depicts the data mapping between ETS and other systems in scope. This information can be an input to system integration initiative

IDR Number Data Data Source Data Destination

Frequency of data exchange

Is Data Available

IDR 1.1 Metering Data

Tx MDMS ETS daily Yes

IDR 1.2 System Status Data

THEMIS/POWI (TEMSE)

ETS daily Yes

IDR 1.3 Energy Schedules Data

ETS THEMIS/POWI (TEMSE)

daily Yes

IDR 1.4 SAPP Market DAM and IDM Trades

SAPP MTP ETS daily Yes

7.1.3 Intellectual Property

All the requirements and related data are the intellectual property of Eskom.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






7.1.4 Reporting Requirements

High level reporting requirements

REPORT NAME FREQUENCY

PURPOSE DATA (Fields) STAKEHOLDERS

Int. Trader

System Operator

Daily Actual & Schedule Operations Report

Daily

The purpose of this report is to compared actuals vs schedules

Schedules(kWh), Energy(kWh), 30 mins interval

x

Daily Export Import data Report

Daily

The purpose is to monitor imports & exports

Energy Imported/ Exported(kWh)

x

International Trader Forecast

Weekly & Monthly

Forecasts energy sales, energy purchases, energy wheeling, revenue, and costs

Energy Sales(MWh), Revenue (Rands) Energy Purchases(MWh) Energy Cost (Rands) Energy Wheeled(MWh) Wheeling Revenue(Rands) Wheeling Cost (Rands)

X

ETS User Access Rights Report

Monthly

User Access control

User ID, Username.Name, Surname, date of creation, last login, status

x

5.International Wheeling

Monthly Summary for International Wheeling transactions

Energy Wheeled(MWh) Wheeling Revenue(Rands)

x


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






7.1.5 Non-functional requirements

User interface requirements No specific user interface requirements other than that it must be user friendly and not complexed to use. It must be similar to current system or even improvement on it. All new systems will have to be evaluated by super users of current system on this functionality

7.1.6 System Integration requirements

The Energy Trading System needs to integrate with the following applications/systems:

• Tx MDMS – Meter Data Management System

• Financial Systems ▪ CC&B – Customer Care & Billing System ▪ SAP – SAP Financial System

• THEMIS/POWI (TEMSE) - Transmission Energy Management System Evolution

• SAPP MTP – Southern African Power Pool Market Trading Platform

• Dispatch Mechanism – Power Station and Tie Line Dispatching System

7.1.7 Access requirements

Accessibility must be based on user identification and the ability must be in place to define the access rights of a user or of a group of users.

7.2 Project Requirements:

IMPORTANT: Project must be completed as a turnkey solution within 14 Months. This includes

Design, Set up of Hardware, Build of solution, Integration, Testing, Training, Go-live and

Stabilisation. 12 Months rollout and 2 Months stabilisation. The vendor must provide all

necessary resources to complete all activities of the project on time and budget.

NOTE: Should any component of the proposed solution be cloud based, the data MUST be

hosted inside the borders of South Africa. It would require additional approval from several

committees based on the data classification, security requirements and legal requirements.

Vendor must always adhere to COVID-19 regulations and accommodate a work from home

policy should it still be applicable during the project. Eskom uses Microsoft Teams and outlook

as main communication mediums.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






7.2.1 Initiation/Planning

Vendor must provide project management and project administrative services in line with the Eskom

Project Office guidelines. Refer to 240-85200946 Group IT Project Assurance Report for all relevant

Project Documentation required by the project.

• Vendor must set up and maintain the Eskom Cross Border Energy Trading Project

Teams/SharePoint site for document records keeping and collaboration

• The vendor must set up, populate, and maintain a Cross Border Energy Trading knowledge

base containing all Cross-Border Energy Trading documents including the project

documentation on SharePoint and Hyperwave.

• Vendor must create and maintain the detailed project schedule in Microsoft Project.

• The vendor must coordinate and control all activities on the project between Eskom and the

various vendors with assistance from the Eskom project manager.

The project Manager must throughout the life of the project:

• Plan, execute and manage the solution realisation process and deliverables

• Oversee the management of the projects in the programme during implementation with the

assistance of the Project Managers/Leads

• Report the project finances.

• Produce all project management documents as agreed with PMO based on the processes

and methodologies in the Project Office

• Ensure that the project complies to all the PMBOK Knowledge Areas and Controlling

Processes

• Provide operational and tactical leadership to the project team

• Establish, manage, and conduct interactions between project and the Eskom Business

• Optimal utilisation implementation partner project team members

• Auditable project documentation

• Communication and Change Management

• Stakeholder Management


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






7.2.2 Analysis and Design

Hardware

IMPORTANT: Eskom will use the detailed hardware design as input to provision the necessary

hardware for the project.

The vendor must provide Eskom with the minimum hardware requirements within one month

of project commencement. This will allow Eskom to request the necessary hardware timeously.

The vendor must perform a full technical assessment on the entire Cross Border Energy Trading

landscape (including integration points) and design a hardware solution. This must include an

infrastructure refresh strategy.

Required environments must be confirmed with Enterprise Architecture and various Cross Border

Energy Trading support teams.

These environments include but are not limited to:

• Production Application

• System Integrated Testing / Quality Assurance environment (This environment must be set

up to be used by the project and Cross Border Energy Trading support post upgrade project)

• Disaster Recovery

The designed solution must take into consideration best practice and alignment to Eskom’s hardware

strategy.

Software (Application)

IMPORTANT: Eskom will use the detailed software design to ensure the solution meets the

requirements and fits into the environment. Eskom Architecture approval is required prior to

implementation.

Should any component of the proposed solution be cloud based, it would require additional approval

from several committees based on the data classification, security requirements and legal

requirements.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






Architecture Vendor must provide a Solution Architect to compile the physical architecture design for the entire

the Cross-Border Energy Trading system landscape. The Architectural Governance processes must

be followed for all approvals prior to execution and deployment.

The solution architect to:

• Document the physical architecture design of the solution within the architecture project

template (206-1313).

• Engage relevant architects (especially security) regarding architecture patterns and standards

to be included in the design

• Engage with relevant support functions regarding the various aspects to be included in the

design

• Present the physical architecture design and pre-transfer at relevant architecture governance

committees

• Ensure that the implementation of the solution adheres to the approved physical

design

The solution architect must have;

• Working Knowledge and experience of TOGAF framework, TOGAF9 certification will serve as

an advantage.

• Working Knowledge and experience of UML.

• Working knowledge of cloud computing will be an advantage.

Integration Vendor must provide Systems Analysts/Architect to verify the current list all Cross Border Energy

Trading Interfaces with Cross Border Energy Trading System functional leads and update the list if

required.

Vendor must provide technical resources to build and implement all required interfaces.

Integration into these systems will be critical for the success of the Cross Border Energy Trading.

Integration scope and deliverables is listed below:

• Analyse, design, develop, test and deploy integration solutions.

• The solution should be able to integrate to THEMIS/POWI, TEMSE/ SAPP MTP, and any other

systems that Eskom may need to integrate to. Refer to the logical design for systems that must

integrate to the solution:

• Cross Border Energy Trading System should be able to integrate with all other applications as

mentioned in the logical design.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






• External interfaces to integrate using Oracle Fusion 12c and IBM WebSphere (Data Power), thus

the vendor should be well skilled to work with the mentioned technologies.

• The Integration Centre of Excellence (ICOE) governance process must be followed for all

approvals. Kindly reference “SOA Workgroup artefacts”.

• All diagrams and processes are to be captured in the Eskom Enterprise Architect (EA). Cross

Border Energy Trading System should be able to integrate with all specified applications as

mentioned in the logical design, conforming to the “End system integration design requirements”.

• All CIM message artefacts (including Mapping Document) to be placed in the Eskom defined CIM

SVN.

• All code to be placed in Eskom defined Code SVN repository

• All artefacts to be placed in the Eskom share point. • The following are the integration and Testing activities and artefacts to be produced and

presented at the committee for approval and sign off: o Business Test case. o Integration specification document.

o Mapping Document.

o CIM message artefacts including WSDL’s and XSD’s.

o Code and unit testing review.

o Deployment Guide.

o SIT testing review of results in ALM.

o SIT test case sign-off.

o Performance testing review of results in ALM (if performance testing is required).

o Performance testing sign-off.

o Pre-transfer documents for go-live approval.

• Provide a message modeller to complete the following: • Analysis of message requirements

• Model or update integration message which follow a Common information model

• Create payloads and envelopes

• Generate XSD, message model and model dictionary


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






Data Migration Vendor must provide a Data Analyst to Review, Analyse and Document the current Energy Trading

System’s data.

Vendor must in advance notify Eskom of any data that requires clean-up with a strategy to guide

business with the clean-up.

Vendor will be responsible for the entire data migration and ensure backups are in place.

Vendor must present a Zero Data loss strategy to Eskom.

Vendor must align and implement archiving according to Eskom’s archiving strategy.

The system must have 7 years of active data and the rest migrated to the archiving solution.

7.2.3 Execution

IMPORTANT: Final product will be Cross Border Energy Trading Application as agreed to in

the contract.

The newly designed and created Cross Border Energy Trading Systems Integrated

Environment must be set up to cater for all integration points connecting to all relevant

testing environments. This environment will be used for Use Case testing, Functional Testing,

Integration testing, Automated testing.

Vendor must ensure the timeous creation and set up of environments to not cause any delays on the

project deliverables.

Vendor must set up all required environments this includes all project environments, automated

testing platform and testing environments and all newly identified environments as per the hardware

design specification, test strategy and cut over strategy. Important is the newly created Cross Border

Energy Trading Systems Integrated Environment. Vendor must take care to ensure this environment

is fully functional and covers all integration paths.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






7.2.4 Testing

IMPORTANT: All test cases must be captured and tracked in HP ALM. This includes all unit

test cases created and tested by the vendor to set up Cross Border Energy Trading System.

The vendor must provide a test manager with and dedicated testers to the project, independent of

the development team. The vendor must plan, guide, and coordinate the entire testing effort based

on Eskom’s testing guidelines and standards. The vendor must provide Eskom with a minimum of 3

months lead time to arrange venues and business resources to assist with functional and user

acceptance testing.

Minimum Required Test types:

• Unit Testing

• Functional and Integrated Testing

• User Acceptance Testing

• Performance Testing

All test cycles must be managed using HP ALM. All defects must be recorded and tracked using HP

ALM. Testing progress reports and sign-off will be done via HP ALM. All testing shall be in

accordance and approved by the Eskom’s testing standards, processes and procedures.

Vendor must provide testing resources as per functional areas below: Cross Border Energy Trading Interfaces

All integration points must be documented as end to end use cases from source to destination

system and loaded in HP ALM to ensure thorough end to end testing.

The Integration Centre of Excellence (ICOE) governance process must be followed for all approvals.

Test Analyst/Test Manager must ensure alignment between source, integration, and destination

resources as resources could be over utilised and require advance notice to test.

Cross Border Energy Trading Test Cases

Test Analysts must verify the current list of Cross Border Energy Trading functional requirements

(refer to section 3.1 Functional Requirements) with Cross Border Energy Trading functional leads

and Eskom’s Testing Centre of Excellence. Test Analysts to update the list if required based on the

additional system functional requirements.

Test Analysts must Review, Analyse and Document the verified list of Cross Border Energy Trading

Test Cases in HP ALM, according to the Eskom HP ALM Standard for capturing test cases (Refer to


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






Eskom TCOE standards).Vendor must set up the different test cycles with relevant test cases in HP

ALM.

Cross Border Energy Trading Automated Test Cases (if applicable)

Vendor must use the automated testing platform during the project and in future projects. The

technology used must be in line with the Eskom approved standards.

Automated testing tool to be used is: Unified Functional Tester (UFT) formerly known as Quick Test

Professional (QTP).

Automated testing framework: Business Process Testing.

Vendor must identify all test cases that qualify for automated testing and create these test cases to

speed up the testing effort.

7.2.5 Deployment/Cutover

Vendor must design a Go-Live strategy and cutover plan as follows:

• Vendor must put together an Eskom governance list and closely track all required approvals

with the relevant Eskom leads to ensure there are no delays. Committees sit from weekly to

Bi-Monthly thus is timing important.

• Vendor must ensure the cutover change is logged with all the supporting governance and test

results.

• Vendor must arrange Go-Live mock cutover simulation sessions to ensure alignment between

all parties and Eskom integrated environments. The plan must be agreed to by all parties and

have committed resources for all activities.

• Plan must contain detail of all applications impacted and the shutdown and start-up strategy

for all impacted applications and interfaces.

• No data loss

• Weekend cutover with maximum downtime of 48 hours starting the Friday evening 20:00

ending Sunday 20:00.

• All Integration points must be tested post go-live to ensure connectivity and throughput.

• Test critical list of test cases to ensure application is functioning correctly.

Vendor must arrange all approvals in line with Eskom process and be aware of lead-times for the

various committees.

Vendor must produce a change management and communication plan, including a business impact

assessment and response plan.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






Vendor must produce a training management plan. This includes the training approach and the

verification, updating of all training material. This must include the training of Eskom Support staff.

7.2.6 Post go-live support

Vendor must provide full onsite support with active monitoring of all systems for 2 months post go-

live to resolve any issues. Project duration 12 month’s + 2 months post go-live stabilisation. Vendor

must create and maintain a quality and stability register of the solutions deployed into production.

Vendor must document, track and resolve all post go-live issues or latent defects.

Vendor must deploy upgraded solution to other identified environments.

Vendor must assist with project closeout documentation.

7.2.7 Training/Transfer of skills

Vendor must ensure close alignment with all resources throughout the duration of the project for the purpose of training and skills transfer, where applicable based on Eskom support strategies and partners.

• Training and skill transfer is required for the Eskom development, Database, Application

Technical Support and end user who need to be developed and skilled within a short period,

to be able to continue with on-going changes and updates of the Cross Border Energy

Trading System in support of on-going business requirements and changes

• Develop training material and support material. Train Eskom development, Database,

Application Technical Support and end user and ensure sufficient knowledge transfer

• Skill and knowledge transfer will be included as part of deliverable sign-off.


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






7.3 Support & Maintenance Requirements:

• Support & Maintenance for a period of 5 years, excluding the post go-live stabilisation period

• Solution must be upgraded regularly to ensure the system stays current with a minimum

compliance of N-1 (This means one version older than the latest software version)

• The vendor must support the solution 24/7/365 for systems errors and recover

• The vendor must also provide helpdesk support for users 12 hours per day, 7 days per week

as per the agreed Service Level Agreement Key Performance Indicators with reporting

• Example but not limited to are queries, errors, trouble shooting, investigations and

configurations

• The vendor must ensure compliance to all Eskom’s required changes impacting the solution,

excluding customisation of the vendor product. Example of such changes but not limited to

integration, security, or configuration changes

• Vendor must implement system monitoring and provide performance reporting

• The vendor must ensure Disaster Recovery testing once a year

• Business customised reports

• The vendor must assist with audit queries related to system administration/support

• Software Technical Issues logged with the vendor must be addressed as follows:

o A response to the logged technical ticket within 24 hours

o Software defect resolution within 72 hours

o Minor software enhancements where agreed with Licensor to be delivered between

one to two weeks

8 PROJECT ASSUMPTIONS

• Commercial process will not exceed 3 Months

• In the tender to market the project will find a fit for purpose product, on the first tender

• The project will implement a vanilla solution without any unsupported customisation

• The estimated project cost is 60% level of confidence, costs are based on estimates received from the market through an RFI process.

• The support cost is estimated on the current support costs

• Group IT dedicated internal resources will be available for this project

• All interfacing systems will have resources available for integration build according to existing approved architecture patterns

• Project will be able re-use the existing integration patterns and paths

• Business resources (or an SME) will be made available to participate in the project, to ensure business alignment, rapid configuration and decision making

• Current ETS vendor will support the project with requested technical information that may be required

• Group IT will provide the budget for the 5 years maintenance and support required


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






9 PROJECT DEPENDENCIES

• Internal and external systems availability for interfacing

• Dedicated internal technical Group IT resources from the various systems and supporting departments.

• Successful RFP process and vendor contracting within projected project timelines

• Project Budget Approval, including 5 years maintenance and support

• Co-operation from current ETS vendor

10 PROJECT CONSTRAINTS

• Availability of Business and Group IT resources

• Systems availability for integration

• Data availability for push/pull activities (Integration Systems)

• Procurement process turnaround time

• No current ETS resources available to assist project


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






11 PROJECT ORGANISATION

12 PROJECT GOVERNANCE

This project will follow the project governance as defined in the Group IT PLCM


Template Identifier

240-43921804 Rev 6

Document Identifier

240-85195240 Rev 3

Authorisation Date

24 April 2020






13 DOCUMENT ACKNOWLEDGEMENT

By signing this document, the people listed record their agreement on the contents of this document.

Programme / Project Manager: Name: Johann Knoetze

Signature: ____________________________________

Date: ____________________________________

Project Delivery Portfolio Manager:

Name: Busisiwe Nkangana

Signature: ____________________________________

Date: ____________________________________

Business Owner: Name: Tshepo Moeti

Signature: ____________________________________

Date: ____________________________________

DOCUMENT APPROVAL

Project Sponsor: Name: Rosemary Gamede

Signature: ____________________________________

Date: ____________________________________

20/05/2021

20/05/2021

20/05/2021

21 May 2021

Template Identifier Group IT Project Scope Document ...

Documents