RMDS Quality Manual - Section 7 Product Realisation

• Planning of Product Realisation
• Customer Related Processes
• Design and Development Processes
• Purchasing
• Production & Service Provision
• Control of Monitoring and Measuring Devices

7.1 Planning of Product Realisation

Product realisation comprises all the tasks and activities that the RMDS group are required to complete, in order to develop solutions that meet a customer's needs and to realise these solutions. The high level Product Realisation process is outlined in ARIS. The RMDS group have the following product responsibilities:

1. Manage and maintain all aspects of the retail electricity market design documentation on behalf of the Commission for Energy Regulation.
2. Manage the Change Control Process in the Creation of new / amended Market design documents as a result of requests from:
   • CER
   • Industry Participants (i.e. SSA, MRSO, DSO, TSO and authorised Suppliers)
   • ESB Support Centre
   • Modifications Panel
   • Retail Market Design Services
3. Review all new and amended Market Documentation with the relevant stakeholders and adjust design documents to align with decision of the Industry Governance Group
4. Get agreement and sign off from stakeholders to develop or amend the Retail Market Design products
5. Liaise with the software development group on the design, build and testing of RMDS's products
6. Rollout the new / amended RMDS products to all Market Participants.
7. Provide ongoing support to the Market Participants after the release of the new /amended product.

The Resources Supporting the RMDS Realisation Process are:

• The RMDS team
• RMDS budget
• RMDS Business Plan

A full audit trail of how a new / amended product came to exist is recorded in the numerous meeting minutes and support documentation from the following sources:

• Conference Calls
• Design Forums
• External Audits
• IGG actions
• Market issues
• RMDS website and mail Inbox
• Stakeholder meetings
• Supplier Queries

This audit trail can now be automatically tracked within the SharePoint management solution.

The processes in the RMDS Management System document the quality objectives for products, how requirements are captured and recorded and the verification, validation and monitoring steps. The processes also state how the output of these stages are recorded to show our products meet the requirements.

Principal among the processes are the Change Control Process and the Release Planning Process.

The Manager RMDS is responsible for ensuring that a budget and work-plan is prepared for each year and presented to the Commission for Energy Regulation. This defines the resources necessary to provide the agreed services.

7.2 Customer Related Processes

7.2.1 Determination of requirements related to the product

Market requirements are initiated through the Change Control Process. The Change Control process is a formal process used to ensure a product, service or process is only modified in line with the identified necessary change. Requirements can come through many different channels (Government, CER, Market Participants, ISC etc.), and are all logged, managed and tracked by the RMDS Group.

The Change Control Process provides for the accurate capture of customer requirements. This includes implicit requirements and additional requirements arising from good design principles which are captured via knowledge of the existing market design and also via a series of reviews with ISC and customers. Relevant statutory and regulatory requirements are also captured and documented.

7.2.2 Review of requirements related to the product

As part of the process of defining a Market Change Request, requirements are defined, changes to requirements are captured and resolved, and the ability of ESB Networks ISC and the Market Participants to implement the change is established.

The change Control process also provides for the recording of these steps and the validation of the information gathered with the Market Participants via the Industry Governance Group. Where changes emerge, RMDS amend the Change Request and issue a new version. The reasons for the change and the new requirements are documented and recorded.

High level design requirements are captured using the Discussion Request (DR) template. The detailed design is captured using the Market Change Request (MCR) template. In addition the DRR Template (Defect Resolution) captures detail of the defect & proposed solution. These documents are reviewed and signed off by all stakeholders prior to the building of the product.

7.2.3 Customer communication

Other customer related processes are addressed in ARIS.

Communication with our customers is by a number of routes. Regular updates are provided to all Stakeholders through the following means:

• Design Forums
• IGG Meetings
• TAG Meetings
• RMDS website and mail Inbox
• Stakeholder meetings

The content of the communication is recorded through meeting minutes, emails, change control documents (DRs, MCRs) and customer complaints or corrective actions.

7.3 Design and Development Processes

7.3.1 Design and Development Planning

The Change Control process defines the design and development planning process for change request products including the stages, review, verification and validation at each stage and the responsibilities and authorities.

Upon approval of a Market Change Request or group of Market Change Requests for incorporation into the Retail Market Design or Central Market Systems, the Release Planning Process comes into play. The Release Planning Process defines the stages, review verification and validation processes for each stage as well as the responsibilities and authorities at each stage.

The RMDS Design Lead will liaise with the ISC to finalise a delivery date. All customers, including the requesting customer, will be asked to agree to the change or program of changes, via the appropriate Retail Market Forum and this agreement will be recorded in the minutes of the appropriate meeting or conference call.

7.3.2 Design and Development inputs

The Inputs to the Change Control process result in the creation of DRs and MCRs. The RMDS Group can receive inputs from the following sources:

• Originator of the DR - by contacting the Originator of the DR, clarification on the precise nature of the request can be teased out.
• CER - through regular meetings, regulatory requirements are clarified and documented.
• Design Forum - these are weekly meetings where system and process design impacts are identified and discussed.
• Market Participants - Market Participants can give valuable input during conference calls and IGG meetings. Market Participants are also required to carry out their own impact assessments.
• Data Protection Commission and internal legal advice to establish statutory requirements

As part of the process for development of a Discussion Request, these requirements are reviewed for adequacy. Requirements are clarified to eliminate ambiguity, checked for completeness and to ensure the requirements are not in conflict with each other. Only when these criteria are met is a product approved for delivery.

A fast-track priority change is one that is:

• Essential (i.e. industry processes cannot operate acceptably without the change and there are no available work rounds)
• Urgent (i.e. the length of the standard change control process would cause a delay to implementation)

A high priority change is one that is:

• Essential (i.e. industry processes cannot operate acceptably without the change and there are no available work rounds)
• Non-Urgent (i.e. the length of the standard change control process would not cause a delay to implementation)

A low priority change is one that is:

• Non-Essential (i.e. industry processes can operate acceptably without the change)
• Non-Urgent (i.e. the length of the standard change control process would not cause a delay to implementation)

All other changes will be deemed to be Medium Priority.

7.3.3 Design and Development outputs

The Outputs from the Change Control process include:

• Detail about the proposed development
  • Background Information
  • Proposed Change
  • Proposed Solution
• Reason for the Change Request
• Market Design Documents impacted by the request
• The organisations impacted by the design change
• The scope of the Change Request
• Impact Assesments
• Recommendations
• Market Process Changes
• Market Message Changes
• Process flow support text
• Supplementary information
• History of Changes

The proposed changes can be verified against the design inputs i.e. the reason for the change request. Any reference product acceptance criteria will be attached to the change request (e.g. relevant regulatory decisions). Any background business process information required for the effective use of the new or changed feature will also be documented and included in the change request. Adequate information is provided in the change request to allow customers and ISC to develop the necessary changes.

7.3.4 Design and Development Review

Change Control Process

One of the main services provided by the Retail Market Design Service is the provision of change control administration to update and improve the agreed Retail Market Design. As outlined in the process linked above, a customer may raise a Discussion Request to modify the agreed design. The Retail Market Design Lead is responsible for reviewing any such requests with the raising customer to ensure that the requirements are understood, all impacted documents and systems identified and any issues are resolved. Each Market Participant may accept or dispute a request raised by another party and the RMDS team will keep a record of all such responses in Share Point.

As part of this review, the Market Design Lead will liaise with CER to determine if there are any issues from a regulatory perspective resulting from the change requested. The Market Design Lead will also liaise with the ESB Networks IS-U Support Centre to determine if there are any issues with the proposals or to identify if a potential alternative solution exists.

Before a release of Central Market Systems or agreed base-lined documents the RMDS Design Lead will review all changes incorporated into the release with all Market Participants. This will usually be done via the appropriate Retail Market forum, with agreed minutes serving as a record of agreement.

Following the completion of functional specifications within the ISC, the RMDS Design Lead will review the specification with the appropriate ISC resource to ensure that the customer requirements have been met. If necessary, the Design Lead will contact the requesting customer to ensure that the proposed modification meets their requirements. The Design Lead will ensure that actions are agreed and followed up on for any issues identified.

Meetings will be held with the ISC at appropriate intervals in the period leading up to the release of Retail Market Design Documents or changes to Central Market Systems to ensure that delivery of the product is still on time and to budget and that all customer requirements can be met.

7.3.5 Design and development verification

All RMDS products are verified against design inputs prior to delivery. This is provided for in the change control process. The Change Control Process also provides for the review and verification of proposed changes by our customers prior to advancing to the draft market change request stage and the approved market change request stage.

7.3.6 Design and development validation

All RMDS products are validated against customer needs prior to delivery. This is provided for in the change control process. The Change Control Process also provides for the review and validation of proposed changes by our customers prior to advancing to the draft market change request stage and the approved market change request stage.

Another of the services provided by RMDS is release planning. While RMDS does not directly develop and deliver software changes, RMDS administers the industry release planning process that ensures that all changes are validated to ensure they meet the specified customer requirements prior to the software changes being released into the live production environment.

Prior to delivery of a change, or group of changes, the RMDS Design Lead will be responsible for ensuring that the end product meets pre-defined criteria by completing the relevant checklist(s) below:

Cutover Checklist

Message XX release YY template

MPD XX release YY template

Where appropriate, samples of the new or amended document or functionality will be provided to the customer to ensure that it meets their requirements.

The Release Planning process supports the build, testing and roll out phases of the product development lifecycle.

Release Planning Process

Release Planning Process

Where the change is of sufficient magnitude, the approved Assurance Strategy requires inter participant testing (IPT) to be carried out. By this process, market participants verify and validate the change to the market desing and the corresponding changes to their business processes and systems prior to delivery. The release process covers the following:

1. Identifying strategy and tests required
2. Agreeing on the resources to be assigned
3. Ensuring the test environment is available and working
4. Testing the communications infrastructure (excluding message content)
5. Obtaining suitable test data
6. Identify the various test case scenarios
7. Co-ordinating the execution of testing
8. Agreeing on the messages to be sent
9. Reporting on the progress of testing to all Market Participants
10. Getting sign off from key stakeholders and CER to go ahead with the release
11. Creating a cut over plan
12. Communicating the cut over plan to all Market Participants
13. Providing updates and support during the cut over period
14. Being able to roll back due to any unforeseeable circumstance that may arise

7.3.7 Control of Design & Development Changes

Changes to the design and development documentation are controlled by the 'Change Control Process' as outlined above. This process provides for the identification and recording of any changes. Under this process, all changes are reviewed, verified against the design inputs and validated against the customer needs prior to issue. This validation includes the assessment of the impact on the existing market design and on the business processes and systems of our customers.

7.4 Purchasing

7.4.1 Purchasing Process

Within ESB, purchasing processes are centrally managed by Procurement services. The only bought in service that has a major bearing on the quality of the RMDS services is consultancy services for market assurance. This contract is subject to a formal tendering process. This process provides for, the evaluation of suppliers in a systematic way based on documented criteria. Records of evaluation are maintained.

7.4.2 Purchasing Information

The request for purchase documents the services required, the standards to which the services must comply, the qualifications and expertise to be provided by the supplier and the quality management system criteria. The successful tender document captures all of this information in detail.

7.4.3 Verification of purchased product

RMDS has stipulated and carries out a systematic review and approval process on all products produced by external suppliers prior to delivery. Each review is documented. Customer feedback, where appropriate, is sought after assurance events. Once delivered, the products are controlled within the change control process.

Any quality issues are reported to the Supplier's Contract Manager with a request for improvement via the supplier's quality management system.

7.5 Production & Service Provision

7.5.1 Control of production & service provision

RMDS products are produced using checklists giving the required characteristics of the product and documented processes. The processes describe the monitoring, release, delivery and post-delivery activities.

For example, the RMDS market documents are controlled using the 'Market Design Baseline Documents' process. This process identifies the controls that have to be adhered to prior to providing the service. This Process contains two sub-processes:

• Release of new documents
• Revising an existing document

There are also checklists for checking the integrity of:

• Market Processes
• Market Message Content
• Change Requests

Release Checks

Job Aids Our Market Design Documentation is published on our web site using ARIS web publishing tool. The attached are simple Job aids to assist staff when making changes in ARIS or publishing to the web.

Job Aid - ARIS Method Manual

Job Aid - ARIS Quick Start Guide

7.5.2 Validation of processes for production & service provision

All RMDS processes are reviewed at team meetings weekly catch-up meetings and management review meetings. In the case of the change control process, checklists are maintained and updated in the light of any product non-conformances detected. Our customers form part of the change control process and assist in this validation by highlighting any non-conformances or gaps they identify prior to approval of a change request. In the case of other processes, lessons learned meetings are held and customer feedback sought at the conclusion of a run of the process. These inputs are reviewed at subsequent management meetings and corrective or preventive actions initiated to address any opportunities for improvement.

7.5.3 Identification & Traceability

Each product is identified by a unique ID number and version no. throughout its lifecycle. Each product has a status field throughout its lifecycle. All products at all stages in their lifecycle are stored on the RMDS Share Point site where the unique ID, version no. and status can be traced up to the point of delivery (and beyond should further changes be required). After delivery, the status and version information is easily accessible to our customers on the RMDS website. It is also summarised and presented to the IGG at regular intervals.

7.5.4 Customer Property

Occasionally data or intellectual property such as screen shots from proprietary systems or commercially-sensitive customer implementation planning information may be received from customers. To date, this intellectual property has not been incorporated into an RMDS product. This property is identified and stored in one of three places. It can be stored in:

• SharePoint - as a document, issue, or email
• Outlook - where all RMDS email communication is stored
• File Share - where any relevant market document is stored.

Customer intellectual property can not be used or disseminated without the permission of the customer. Should the customer wish that it be destroyed, this wish will be recorded at the point of storage and compliance will be verified back to the customer. While the documents may be stored in three places they can all be retrieved using the SharePoint search engine. Mail messages are archived in the File share. This File Share is indexed weekly by SharePoint software making it possible to search and retrieve any Market Participant document instantaneously.

7.5.5 Preservation of Product

Prior to delivery to participants via e-mail, CD or the RMDS website, all RMDS products will be identified, stored and version controlled on the RMDS Share Point site. All changes to our products are captured and recorded as part of the versioning. Each product must be proof-read, internally approved and agreed with the IGG prior to delivery.

7.6 Control of Monitoring and Measuring Devices

This is not relevant to the work of the RMDS team ( see exclusion in 1.3 ).