OGC Gateway 4 Readiness for Service

1
OGC Gateway 4 Readiness for Service

• Planning Day, 21st July 2008

2
ERDF Background

• The European Regeneration Development Fund is one
  of the EC Structural Instruments
• ERDF budgets are fixed every 6 years, the current
  one is for 2007-2013
• BERR lead on all Structural Programmes in the UK
• Communities Local Governments European Policy
  Team (EPP) manage ERDF in England
• EPP do not administer projects, as this is
  devolved to the 9 English Regions
• Historically ERDF has been administered by the
  regional Government Offices (GOs), but the
  2007-13 programmes they will be managed by the
  RDAs
• All ERDF operations in member states are defined
  in Operational Programmes (OPs)that have
  strategic objectives and measures
• Each Operational Programme must comply with EC
  Regulations issued by DG Regio
• There is risk of significant financial correction
  if the Regulations are not complied with or the
  key N2 performance measure is not met, reulting
  in loss of investment in the regions

3
High Level ERDF Process
4
ERDF 2007-2013 Learning from the Past
x
x
x
x
Dispersed information Discrepancies dispersed
information across the process organisations
Standards No standards to maximise the value
delivered by ERDF MI resulting in poor
consistency of monitoring and reporting between
regions.

• Duplication
• Myriad of systems across the regions, increasing
  information input and adding to inconsistencies
  between data sources.

Bureaucracy Off line, paper based systems
resulting in inaccuracies and limiting access to
timely data
x
x
x
x

• Regional variations
• regional process, organisation structures and
  terminology leading to MI inconsistencies

Integration No integration between participants
systems across the process

• Risks
• Lack of reliable consistent MI, coupled with
  inconsistent monitoring increasing risk of
  de-commitment

Performance monitoring Monitoring based on
actuals instead of pro-active management
5
ERDF Core Processes Management Information
Consistent Management Information Processes
Processes result in MI to effectively manage the
programmes
6
Efficiencies across the Programme
9 regions

• Unified Process MI Systems can help to deliver
• Efficiency across the process
• Efficiencies between organisations
• Consistent data collection
• Better performance management
• Reduced risk of de commitment

Consistent MI across Regional Operational
Programmes
7
ERDF 2007-2013 Principles of the Gershon
Efficiency Review
Standardisation
Transactional support services replicated
processes could be made more efficient by a
combination of simplification, standardisation
and sharing to deliver economies of scale
Self Service
Processes should designed to exploit self-service
Avoid Duplication
Significant duplication exists across
organisations resulting in inefficiencies to both
the private and public sectors
Transformation
Transactional services direct to the public have
the potential for complete transformation through
ICT
Access
Explore the opportunities to simplify access for
the public and achieve major efficiencies by
accelerating the usage of modern technology.
Culture
There needs to be a significant culture change to
realise the benefits of ICT through an active
process of managing the shift of key customer
groups to ICT channels
8
ERDF 2000-2006 Business Improvement Programme

• Scott Wilson study in 2002 identified process and
  administration weaknesses across the regions
• The study identified potential under-spend and
  risk of de-commitment
• The TESA Project was initiated to
• Define a consistent process across ERDF
• Introduce web based technology to adopt the
  efficiency principles of the Gershon review and
  e-government
• Allow GO staff to be freed up from bureaucratic
  paper based processes to focus on more higher
  value monitoring tasks
• Enforce compliance with the process and EC
  regulations through in built controls
• Standardise the underlying dataset across the
  regions for better MI
• TESA is now live across all regions, with approx
  3,000 users
• It was delivered late in the 2000-06 Programmes,
  but a strategic decision made to re-use it in
  future Programmes and reap further benefit from
  this investment

9
ERDF 2007-13 Business Context
Autonomy need to recognise RDA autonomy coupled
with the need to comply with a strict regulatory
framework controlled by EC Compliance while RDAs
are allowed to deliver the Programmes in line
with their regional strategy, there is no scope
for variation in compliance with the
regulations Consistency the argument for
consistency is compelling, as unless it is
evident that appropriate controls are in place
across all OPs, there is significant risk of
financial penalty. Efficiencies a centralised
approach to system delivery and use is cheaper,
and more effective than a duplicity of systems
replicating each other Standards a suite of
standards is required to ensure compliance and
consistency that must be adhered to.
10
The Case for Consistency

• The argument for consistency in approach is
  compelling
• The legislative and EC regulatory requirements
  impose certain standards and procedures that must
  be complied with.
• The regulations empower the Commission to impose
  financial penalties on member states in cases
  where irregular expenditure arises because of
  breaches of regulations or deficiencies in
  control systems.
• Unless it is evident that appropriate controls
  are in place, across all Operational Programmes
  there is significant risk of financial penalty.
• A centralised approach to system delivery is
  cheaper and more efficient that a duplicity of
  systems replicating each other.
• In a devolved framework, it is common to impose
  technical and operational standards.
• Consistency can help establish and reinforce CLGs
  position with the EC, and thereby improve
  long-term performance across the 2007-13
  programme.
• Consistency in process and systems could itself
  add significant value to the stakeholder
  community.
• Financial management controls are expected to
  avoid all threat of financial loss, which implies
  both very tight and consistent control.
• Consistency of data collection and validation
  will help demonstrate compliance.

11
ERDF 2007-2013 Challenges

• To achieve a vision of joined up ERDF processing,
  we must overcome the triple challenges depicted
  in the 'pillars' of

getting RDAs, Stakeholders and CLG to appreciate
in a timely way the Information and Process and
interactions required, the options available and
the actions to be taken
ensuring RDAs, Stakeholders and CLG have access
to the required and relevant information for
participation in ERDF administration in the
Information Age
building new working relationships between CLG ,
RDAs, and Stakeholders to manage the programmes
and develop trust between each other
Understanding
Access
Trust
12
ERDF 2007-13 Governance Framework

• What we are putting in place is
• Statutory Instruments establishing the RDAs as
  Article 59 Intermediary Bodies
• An ERDF User Manual as the core statement of
  Management Control for the English Operational
  Programmes
• Within CLG the roles of Managing Authority (EPP),
  Certifying Authority (FSSD), and Audit Authority
  (IAS)
• An MI Systems Operational Framework, comprising
• a set of system requirements and specifications
  whose validity is generally accepted across all
  the stakeholders now chapter 9 of the User
  Manual
• a centralised Management and Control Information
  System (MCIS) that meets these requirements and
  specifications
• mechanisms which enable regional managers to
  acquire/develop systems economically to meet the
  same standards (should the centralised system not
  prove to be viable)
• enforced compliance with these requirements and
  specifications

13
Product Breakdown Structure
14
What is MCIS?

• The Management Control Information System will
  be the electronic system for administering the
  ERDF 2007-13 Programmes
• It meets the EC regulation that all information
  on ERDF Operations to be held in electronic
  computerised format
• It supports the regulatory requirement for an
  audit trail from EC declarations to the
  beneficiary
• It is being developed from the TESA system which
  is live in all the 2000-2006 programmes.
• There will two virtual versions of MCIS
• Core, which will be used by RDAs, MA CA to
  submit aggregate data for re-imbursement of
  expenditure
• Full, which builds upon the core system to allow
  an RDA to use MCIS to administer all the projects
  within their Operational Programme

15
MI Systems Operational Fraamework
16
Core Vs Full MCIS
17
MCIS Functionality

• Full Core System Users
• NWDA
• EEDA
• LDA
• SEEDA
• ONE

• Core Only System Users
• SWDA
• EMDA
• YF
• AWM

• CLG MA
• CLG CA

18
MCIS Benefits

• It will deliver the following benefits to all
  RDAs CLG
• Consistent data model for submission of aggregate
  interim claims
• Accessible via the internet
• Real time status of claim, inc audit trail to
  trace amounts claimed to the commission through
  the IB and Beneficiary
• Facilitates efficient exchange of data between
  the RDA, MA, CA EC
• Additionally, for the users of the Full System
  MCIS will deliver the following benefits
• Ensures process consistency across all projects
• Forces compliance with the regulations
• Reduced cost of development through a shared
  service approach
• Accessible to participants, for claim submission
  and MI
• Allows RDA staff to focus on higher value tasks
  (i.e. reduced key entry tasks)
• Ensures ERDF payments reconciles with local
  finance system
• Clear visibility of N2 achievement

19
'Core' Requirements Functionality

• Maintain Programme Details, aligned with SFC07
• Creation of Aggregated Claim, inc claim
  calculation, irregularities
• Submission Approval of Aggregated Claim
• MI for Regulatory Reports
• EC Declarations
• Euro Conversion
• System features
• Accessed via the Internet, real time data
• On line validation, workflow
• Government Gateway user authentication
• Security approved
• Compliant to Govt IT Standards
• Event logging audit trail

20
'Full' System Requirements Functionality

• Support all the ERDF Lifecycle Business Processes
• Project set up gt claims gt monitoring gt aggregated
  claims
• Project Set Up
• On line Project Applications?
• Electronic Funding Agreements, baseline project
  details
• Claims
• Claim Schedule creation, per priority axis
• Claim processing, including outputs, actuals
  forecasts
• Grant calculation, inc Revenue Generation
  projects?
• Breakdown of expenditure
• Key dates
• Monitoring, inc Article 13 checks, Irregularities
  clawbacks
• Automated Aggregated claim (from project data)
• Management Information

21
Project Governance
22
Project Organisation
23
Acceptance Roll Out Criteria

• Functional Testing
• Non Functional Testing, especially performance
• Security Accreditation, ISO 27001
• Security Testing
• End to End User Testing, Full Core System
• Gateway 4 review, prior to full roll out
• Post Go Live Development Plans
• Implementation Plans for remaining offices

24
Test Acceptance Strategy
25
Unit Integration Testing

• Unit Testing
• Performed by MCIS developers during development
  phase
• Objective - to prove that each basic unit of the
  system functions correctly in isolation
• Integration Testing
• Performed by MCIS developers during development
  phase
• Objective - to prove the integration between Unit
  tested components
• Consists of both manual and automated testing

26
System Testing

• Undertaken by MCIS project team
• Consists of both Functional and Non-Functional
  testing
• Objective - to test the complete system against
  the functional specification
• Based on the simulation of business cycles i.e.
• Prepare aggregate claim and evidence
• Submit aggregated claim and evidence
• Approve aggregated claim
• Certify aggregated claim
• Authorise/Reject aggregated claim
• Process payment via SAP
• Performed in a dedicated System Test environment

27
Functional System testing

• To test all the business requirements as defined
  in the baseline documentation, which includes
• Functional Specification
• XML validation rules
• Operational Framework document
• Government Gateway Specification
• SAP Interface Specification
• Site map
• State transition diagrams
• User Journeys
• Roles document

28
Non-Functional System test

• Objective - to prove the operational performance
  of the system and compliance with required
  standards, and includes
• System security, including penetration testing
• Performance testing
• Accessibility
• Operational tests (backups, restores)
• Virus protection when loading files
• Browser testing

29
User Acceptance Testing

• Joint responsibility of Managing Authority,
  Certifying Authority and RDAs
• Objective is to test the complete system to
  ensure it meets the business requirements
• Based on the simulation of business cycles ie
• Prepare aggregate claim and evidence
• Submit aggregated claim and evidence
• Approve aggregated claim
• Certify aggregated claim
• Authorise aggregated claim
• Process payment via SAP
• Performed by
• early adopter RDA (i.e. Yorkshire Forward) but
  there may be input from other interested RDAs
• Certifying Authority
• Managing Authority
• MCIS Project Team
• Performed in a dedicated User Acceptance Test
  environment

30
Model Office Business Simulation Testing

• Performed by all RDAs as part of their MCIS
  implementation
• May be run in parallel with User Acceptance phase
  of testing
• Objective is to prove the readiness of the
  complete process (i.e. people, process and
  technology) for operating ERDF
• Successful completion of this phase is a
  pre-requisite for the decision to go live with
  MCIS within each RDA
• This phase will be managed by the RDA Local
  working Group, with support from an
  Implementation Co-ordinator from the MCIS Project
  Team
• RDAs can use the business scenarios used as part
  of System and User Acceptance Testing, but they
  should also be writing extra scenarios to test
  their own MI System

31
Security Accreditation

• MCIS are working towards the latest HMG security
  standard and approach
• First stage is completion of IS1 Security Risk
  Assessment, to demonstrate that that the risks
  are properly managed and Information Assurance is
  put in place to address
• Confidentiality
• Integrity
• Availability
• MCIS Security Policy will also cover
• An assessment of the business impact of any loss,
  e.g. financial loss to public sector or
  reputational damage
• An assessment of the key threats to the system
• An assessment of the vulnerabilities against
  appropriate baseline security standards, i.e.
  compliance with ISO/IEC 27002

32
Security Accreditation MCIS Scope
33
Progress to date
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
June
July
Aug
Initiation
Requirements
Development
18/5 1st MI Meeting
30/5 Issue of 1st MI Spec
7/12 Update Data Dictionary
13/6 2nd MI Meeting, spec feedback
12/12 Launch Project website
15/6 2nd updated spec
26/6 3rd updated spec, inc spreadsheet
12/12 MIS Meeting, finalise System Requirements
17/7 MIS Group, TESA demo, System Functionality
11/01 Finalise MI Operational Framework
7/8 Updated MI Spreadsheet
25/04 1st demo of Release 1
21/8 RDA mtg System Options
25/7 Sign off Release 1
31/8 System Options paper
24 /9 Implementation strategy
11/10 MIS Meeting, issue of Data Dictionary,
System development approach
26/10 RDA Update full Development Plan
published
06/11 Implementation Blueprint
26/11requirements standards doc issued
30/11Updated data Dictionary
30/11 Development team resources in Place
34
Release 1 Delivery Plan
35
High Level Plan
36
Implementation Approach
37
Implementation Timeline - core
38
Support Framework
39
Support Levels