2. Agenda
• Background and high level team information
• Change management within EVO
• How the project affects change management
• SOX
• A challenge !
• Questions
4. EVO – the story so far
• Vision to have all majority owned Vodafone companies running the same
set of Finance, Supply Chain and HR processes on a global ERP platform.
• 2 brand new companies set up
– Vodafone Procurement Company (VPC) in Luxembourg
– Vodafone Operations Company Hungary (VOCH) in Budapest
• First telecommunications company rolled onto EVO was VF Hungary in
September 2008, since when
– VF Germany in April 2009
– VF Portugal in September 2009
– VF Netherlands and ARCOR in April 2010
– VF Spain and VF Group Service Limited in September 2010
• VF Tiger also launched on a separate SAP instance to support VF India
• A terminals (handsets) solution – called 3TM – was rolled out to VF
Netherlands in July 2010.
5. EVO – the future
• Release 6
– UK, Ireland and Egypt
– Further builds on VF Group and ARCOR (German fixed line business)
– New functionality (CATS, Network Inventory, SRM Catalogues)
– BI re-design
• Release 7
– Italy, Greece and Turkey
• To be scheduled
– Romania, Czech Republic, Malta, Albania, South Africa, Qatar, Australia, New
Zealand.
• Other future work
– Roll-out of 3TM to other EVO OpCos
– Retro-fitting of OpCo specific functionality to all OpCos
– Convergence project with Tiger
6. High Level View on Global ERP Support & Operations
.
Global ERP Support
and Operations
Petra Heine-Brach
EVO
Service Transition
Christian Markus
EVO
Service Operations
Barry Dewey
Retained
Operations
Jürgen Kimmer
Supplier
Management
Thomas Schecke
Change
Management
Andrew Mayer
Achim Vierneisel
Operating Model
Alignment
Team Assistants
•Supplier Manager
• BAU Release
Scheduler
• Configuration
Manager
• Operational
Demand Manager
• Functional Lead
Operational
Design
• Operational
Design SMEs
• Operations Tools
Owner
• Functional Lead
Release &
Deployment
• Data Centre
Liaison Manager
• Service Transition
Project Managers
• Project
Environments
Manager
• E2E Service Level
Mgmt Lead
• Service Level
Manager
• Quality Assurance
& Processes Lead
• Problem Mgmt
Process Manager
• Support &
Operations
Process Manager
• Service Ops
Tools
Improvement
Specialist
• Support
Enablement Lead
• Support Group
Enablement Mgr.
• 12 VISPL Change
Analysts
• 2 independent change
analysts
• Change Manager
• 3 Transport
Coordinators
7. • Safe delivery of changes through to production ensuring:
–Minimal disruption of services
–Minimal back-out activities
–Economic utilization of resources involved in the change
• SOX Compliance of the Change Process within the scope of Vodafone
GITC obligations
• Provide risk assessment of changes into key decision taking forums
• Ensuring the most efficient flow of change through the system given the
regulatory framework
• Schedule all BAU releases
• Schedule and run freeze periods
• Ownership of
–Change management
–Transport management
–Configuration management
–Change Advisory Board
Accountabilities of Change Management
KPIs
Workstream: Change Management
Principal Manager: Andrew Mayer
Personal Details / Interesting facts
• Budget compliance
• Cost per change
• Change success rate
• Change throughput
• SOX Compliance
• Career
–Joined Vodafone UK in December 1998
–Joined EVO February 2006
• Personal
–Born in Wales and supports Cardiff City FC
–Has represented Vodafone at cricket and badminton
–Plays real tennis, the 16th
Century forerunner to modern tennis, played indoors
with elements of both lawn tennis and squash.
–Looking forward to England beating Australia in The Ashes!
9. Role of Change Management Within EVO
• ITIL – “Delivery of changes to the IT infrastructure in order to minimise the
number and impact of related incidents”
• Extra challenges for EVO
– Focus on SOX compliance
– EVO grows into the flagship finance system, subject to ever more rigorous audit.
– Key part of the audit is change management, with a high onus on Vodafone to prove that
all change made to the system is
– Driven by a genuine business justification – incident or business initiative.
– Assessed for risk, and all risks identified mitigated.
– Tested to a standard commensurate with the complexity of the change.
– Approved by the appropriate level of business before it is applied to the live system.
– Complex technical landscape coupled with aggressive project targets.
– Accenture assess that EVO is the most complex SAP project they have been involved in,
taking into account the number of separate systems, the volume of interfaces and data and
the fast track approach to rolling in OpCos
– Change freezes
– Business as usual/bug fix changes are restricted for virtually half the year
10. Checklist Reviews
• The first step for a change is to review the checklist. Please take time to do
this and push back to the development team in all cases where the
information is inconsistent, sketchy or plain wrong. You will be backed up
in case of escalation.
• Areas to concentrate on (not exhaustive)
– The reason for the change is a filled in; the description of a change is done in “as
much detail as possible”. The 2 fields should not be the same.
– That for any CBM change - or one that has come through new demand - that
placing “n” in updating of functional and technical specification is challenged.
– That test plans are adequate and relevant.
– That all mandatory fields are filled in
• Key is to review the checklist thoroughly and with common sense (for
example spelling errors are not a reason to bounce it).
• From this review the category of the change should be defined
11. Categories of Change
• Normal changes
– Medium to high risk necessitating approval from the full Change Advisory Board
– High level of focus from the change team to look for and mitigate associated risk
– Likely to be in testing for many days or weeks
• Minor Changes
– Low risk requiring approval only from change team + transport coordinators
– Low level of focus from the change team
– Likely to be in testing for 1 or 2 days
• Emergency Changes
– Backed by a severity 1 or 2 incident (or unable to wait for the next CAB)
– Highest risk changes to process requiring the most attention from change team
• “Fast Track” Changes
– Pre-agreed to need no justification , and moved through at same pace as
emergency transport
– Currently storage locations are the only example.
12. Normal Change
• All changes that go via the Change Advisory Board (CAB) are normal
changes.
• Changes are normally collected via the pre-CAB meeting based upon
business prioritisation.
• All changes presented must
– Be SOX Compliant
– Have transports released by the developer
• All approved changes are transported to pre-production following the
meeting
– Change team must update the change status
– Inform the nominated tester
13. Minor Change
• Self-certified by the developer by setting the risk level on Remedy to 5
• UAM team are the main users of this
– An additional transaction given to a role is a minor change
– Removal of a transaction from a role is not
• For all changes then the key is that there is no requirement for any VF
involvement before the FIA step
– If the business will do the testing themselves then it is not minor
– If the Centre of Excellence (COE) or any other central person have to review a
change (because it is CBM, or affects all OpCos) then is not minor.
– If the FIA agrees to Z test approach then it is not minor
– Etc
14. Emergency Change
• Defined as a change that cannot wait until the next sitting of the CAB
• Usually supported by a severity 1 or 2 incident
– Exceptions would be a “fast track” or where the proposer can set a compelling
business reason why a lower category incident must be placed live before the
next CAB sits.
• A new demand should never be an emergency change
– This ensures that all affected (COE, IBM etc) have a chance to review in a full
CAB.
– On exception this can be approved by myself or nominated deputy.
• All compliance must be in place (as per a CAB)
• E-mail is sent to the ECAB authorities, along with enough detail to allow
them to make a decision
– Supporting reason for emergency
– CRQ details and checklist
15. Solve Incident
• The solve incident process is designed to cope with high severity incidents
occurring outside normal business hours.
• IBM – as the major incident manager – can raise a CRQ and based upon
purely ECAB approval and the final import approval put a change live.
• All other controls can be collected the following working day and entered
into the CRQ by the change team.
16. Fast Track
• We have agreed one “fast track” process with all parties; other may be
accepted into the same process in the future.
• This is for changes that happen often (more than once a week on average)
and are important to the smooth running of a business.
• The one accepted change is to set up new storage locations, and IBM will
always mark the CRQ with the words “Fast Track”.
• In such cases then they should be treated as emergencies
– Immediately SOX them up without waiting for pre-CAB approval, or being told
they are an emergency change.
– Apply for ECAB in the usual manner stating that this is a fast track storage
location change.
– Pass into testing; keep track of the testing as it should be short in duration.
– Pass onto the correct FIA
– Master data shop creation; Ann Katrin Schlueter / Frank Maas
18. New Demand
• New demand is a process that delivers a design change to EVO.
• The main drivers for new demand are
– EVO process improvements (e.g. HR Roadmap)
– Individual OpCo initiatives (e.g. VPC program)
– Legislative changes (e.g. IFRS in Portugal)
– Technical improvements (e.g. interface monitoring)
• New demand is tracked through the Project Portfolio Management (PPM)
tool.
– This has a gated process based upon design approval; funding approval; vendor
selection; impact assessment etc.
• New demand may go live as part of a major Release (e.g. some 20 new
demands will go live alongside Release 6 in April); or with their own
release slot.
• Associated change management often needs an embedded change
analyst into the project, especially where there is a complicated release
strategy or a new vendor.
19. Key Behaviours
• The work info should tell the story of the CRQ
– The latest entry should be accurate
– VIP customers will contact me and ask re specific CRQs and it is very poor for the
team’s image if the information I give is not up to date or correct
• The status of the CRQ must reflect the latest position
– Reports will show what status the change is in
– SLAs and KPIs will be driven by the status of a change
– When a change can be completed this must be done promptly
• Every CRQ should have an entry every 2 days
– If there is a known exception then place the CRQ into pending and place a clear
message as to why (and for how long) in the work info
• Tune into the CAB cycle
– Make sure all changes picked at pre-CAB or otherwise chosen are CAB ready
(SOX compliant, transports released etc).
– Ensure that all testers are informed to start testing as soon as the transports hit
pre-production (A* systems).