Hypercare - Managing the risks around the unexpected

What is Hypercare
Hypercare is the period immediately following a system Go Live where an elevated level of support is available
to ensure the seamless adoption of a new system.

It's the time-limited, enhanced level of governance and resourcing to ensure appropriate levels of support are
provided during system stabilization, issues are addressed quickly, and knowledge transfer is occurring to the
Service Delivery Organization.

In simple terms
 Starts with Go-live
 Limited time period (warranty period)
 System runs on Auto Pilot
 Support available 24*7 and 7 days a week for all technical issues
 SME’s take full ownership during Hypercare
Definition
Hypercare in application support can be considered as the phase after application is live in production. The
main purpose of the Hypercare period is to closely monitor the application to respond/resolve any type of
functional, Technical and Security issues for smooth functioning of the implemented application. The thumb
rule is that when hypercare support ends, the system is declared as stable and it is in safe hands of AMS team
who should be in full capacity to support and resolve issues.

Some of the areas to focus on during hypercare

 Confirm business-as-usual is working
 Manage Defects
 Customer (end user) support
 Data integrity
 Availability and performance of the system
 Roll off vendor support (knowledge base)
 Some team members should focus on next phase rollouts by addressing “lessons learned” while designing
and supporting
Risks and issues often faced during hypercare
 Issue Prioritization
 Response time for support can be delayed
 Resource constraints (internal vs. vendor)
 Lack of training (e.g., materials, reference guides, in-person)
 Lack of knowledgeable subject matter experts
 Emergency access needs can result in excessive privileged access
Risk Factors – People, Process and Technology
People:
 Lack of executive level support/awareness to post go-live criticality
 Lack of dedicated business process and technical professionals
 Lack of enough involvement from the business process owners in the hypercare phase
 Lack of necessary ERP expertise on the implementation team (including management and readiness partner)
 Insufficient training for end users
 Importance of change management is underestimated or done ineffectively
 Lack of effective knowledge management
 Insufficient governance strategy around segregation of duties, master data, and reporting
Process:

 Lack of a formalized project office responsible and accountable for inventorying, prioritizing, and
monitoring the various competing problems that arise
Technology: E.g.- SAP Security Module:

 SAP security is not addressed proactively to design a strategy that balances costs associated with controls
and maintenance
 Risk associated with SAP default functionality is not addressed (SAP*, SAP_ALL, SAP_NEW, RSPARAM
vulnerabilities)
 Lack of negative security testing to identify unintended combinations of access granted
 Interfaces are not tested thoroughly
 Reports are not readily available to support the various processes
Hypercare Readiness Scorecard for Golive – Sample
Criteria Phase 1 Phase 2, Notes and Actions needed for 100%
etc.,
Processes Control integration, training
Tools Application monitoring
Reports Defect Report, EAM Report (Enterprise Asset
Management)
Roles & Training team, support team, audit, etc.
responsibilities
Staffing Plans Global 24 hour “war room” support for week 1
Coverage Continue weekly update
Plans
Infrastructure Preparation of technical equipment for locations,
mobile devices
Training Dry run complete?
Soft spots Mitigation plans developed and conveyed to user and
hypercare teams?
Critical Conversion of SIT/UAT critical tickets to hypercare
Workarounds tickets
Workaround plans conveyed to user and hypercare
teams

Note: Include this item in final go-live approval decision

Example Reports: Number of Critical Defects

Duration
 Based upon the project and criticality of the application, usually 45 – 60 Days
When does the hypercare period end?
 Do not just pick an arbitrary period (e.g., 45 Days)
 Do monitor the following:
o Number of critical defects and/or workarounds
o Number of changes to application roles
o Count of Firefighter usages
o Frequency of IT performing business transactions
 Do communicate with both internal and external auditors regarding the plan and timing for short-term
hypercare controls and the longer-term new control framework
 Let’s Talk in Practical Scenario
Triggers/Scenarios for Hypercare support
 Implementation – Standard (or) Custom Application
 Upgrade - Standard (or) Custom Application
Types of issues in Hypercare
 User Issues
o Password settings
o user administration
 Technical Issues
o Backup
o Recovery
 Change Management Issues
o Change approvals
o Testing
Types of support in Hypercare
1. Technical support
2. On-site training
3. Handling issues and queries
4. Escalation plan
5. Ensuring smooth handover

Technical Support: An important objective of hypercare support, this includes resolving technical queries of the
end user working on the application and any bugs and fixes. This allows the application to stabilize and work
efficiently in the new IT environment among other systems. This also takes care of the data integration taking
place with various other existing systems.

On-site training: This is another aspect of hypercare support which includes on-site availability of the support
team. This is implemented so that end user queries can be resolved on the spot without wasting any time. This
also includes on the floor training for the end users which helps them get a complete understanding of the
application which considerably reduces the number of queries hitting the support desk during on- going
support. On-site training also facilitates the end user to get completely familiar with the application. This makes
it easy to use thus satisfying the primary purpose of the application.

Handling configuration issues and queries: Handling of configuration issues and related queries are also
managed under hypercare period. This includes configuration of fields, adding drop down values, modifying
field names, changing locations of the fields etc. These are some of the tasks managed during hypercare for
smooth functioning of the application related processes. This helps make the application more user friendly
with minimum possible resolution time.

Ensuring smooth handover: This is the final activity that comes under hypercare support. This includes various
handover activities like documentation, confirmation from the end users on various processes configured in the
application. This also, includes handover of the application’s administrator rights to the support team.
Confirmation on resolution of major issues are reported during this phase.
Hypercare Approach

High level Schematic Incident/Ticket – Flow/Escalation (Sample)

2a User 1

2b

Super User 3

Support Desk 4

5a
7
IT Ops 2nd line
Team

5b

Project Delivery
Product Owner 7
Team

6
 1 – User identifies a “bug” or “error” in the application.
2a – User locates their Super User by looking up the list of SU’s and contact them (if it is out
urgent). The super user analyses the “bug” or “error”.
2b – If the issue is urgent, the user will contact the SD directly (Portal/Email/Phone).
3 – Super user contacts the SD on behalf of the User to request a ticket to be raised for
Application Support to repair the “bug” or “Error” (Break – fix ticket).
4 – The SD runs through its script, logs the incident and ensures that they capture all relevant
Description information and assign the break-fix to the relevant Service. Management ticket queue.
Problem Type “Application”.
5a – The ticket gets routed to IT Ops 2nd line.
5b – If IT Ops 2nd Line team cannot resolve incident, ticket is escalated to the project team.
6 – Project Delivery Team may consult Project Owner on the chosen solution.
7 – Project may suggest that the change process is initiated.
During this process the Product Owner and Super Users will play a role in implementing the
change and testing/training the end user as required.

IT Support Project
Key Business Roles
Roles Delivery Roles

Stakeholders/Key players: Roles and Responsibilities

 Implementation resources work closely with customer to track and resolve any production issues during
this period.
 Any high priority issues should either be resolved or have a plan for resolution before transitioning
customer to support and Customer Success Manager (CSM).
 It is also imperative to help customer measure adoption metrics during this phase to ensure that value is
being achieved from the start.

Roles
Post Go-Live Support Lead
Service Delivery Manager
IT Delivery Manager
Responsibilities
 Accountable for PGLS Deliverable
 Manage the plan and resource ramp-up and ramp-down
 Consolidated view of PGLS status
 Escalation point for the business and stakeholders
 Single source of communication for all PGLS activities
 Central co-ordination point for PGLS to ensure alignment across all
parties (Business, Deployment team, SD etc.,)
 Management of risks and issues throughout PGLS phase
 Reports PGLS status
 Review and recommends functional readiness to exit PGLS into BAU
 Link between IT Delivery, Service Delivery and Business
 Ensure alignment between IT Delivery, Service Delivery and
Business Priorities/ focus
 Supports the resolution issues
 Provides inputs/guidance to the business
 Understanding of logged incidents and trends
 Reports PGLS status for functional area (Consolidate IS and Business
review)
 Report on readiness to exit PGLS in to BAU
 Represents IT Delivery Organization
 Accountable for managing resolution of incidents during the
warranty period
 Resolution of defects carried forward into BAU
 Provide support to service delivery organization of open incidents
 Business Change Lead
Super Users
 Represent Business
 Communication link into the business
 Escalation point for business function and super users
 Understand and communicate core business issues and priorities
 Monitor risks, implement mitigation and plan contingency
 Ensure adoption of new solution within business
 Ensure decommissioning of the workloads
 Measure and Report KPI’s, Assessment exit readiness to BAU
 Measure ad report KPI’s, Assesses exit readiness to BAU
 Represent end-user
 Firstline business support (On-floor support)
 Participate in issues identification, resolution and communication of
resolution (Bi-directional)
 Support end user in raising the incidents

(OR)

Key steps that contribute to a successful Hypercare

1. Set up a War Room – a centralized support base of operations
2. Identify and place Project Change Champions in key areas that are most impacted by change
3. Readily accessible training content
4. Allocated dedicated project members to the customer with technical expertise of the upgraded system
Key elements to consider
 End-user support in System adoption
 Technical support in Incident and issue resolution
 Escalation Management
How it works
Hypercare clients are provided a designated single point of contact (Dedicated Portal/Email/Number) for all
support requests called a Client Advocate. The client advocate delivers several benefits to hyper care clients,
including:

1. Single Point of Contact for the client

2. Related application solution expertise
3. Existing knowledge of client landscape and requirements
4. Access point to all respective resources
5. Ongoing client champion and project manager for ticket resolution

Entry Criteria
 Follows Operational Readiness Confirmation & Go-live

Operations Factors (examples given below – tailor for your project)

 Responsibility remains with Project Delivery Team
 Incidents are all raised by the end user, super user or process focal point via the Service Desk to the project
delivery team
 All incidents are tracked in Service Management Tool
 All incidents are investigated and resolved by project delivery team
 Change Management is followed for all changes
 Project team execute changes to source code and central configuration
 IT Ops attend weekly incident meetings
 Project delivery team is responsible for all support activities, including any processing or maintenance
tasks.

Exit Criteria

What if business is super demanding and does not want to agree on exit?
Ensure you agree on Exit criteria well in advance. Preferably before UAT and moment they start noticing issues.
Ensure you have Business owners defining KPIs for business processes and listing key Business activities, that
need to happen with Project support. If those activities (with "first-run" date) will run smooth, there will be no
reason not to agree on exit. We call it "Business criticality calendar".
e.g. of such activities in Finance could be

 First payment run from new system

 Start of posting of incoming invoices
 First processing of bank account statements
 FI Reconciliation - Assets

References:
https://www.theshelbygroup.com/post-implementation-support-part-2-silence-bliss/

https://systemsplusgroup.blogspot.com/2014/07/hypercare-support.html

https://www.snp-poland.com/en/better-business/case-studies/hypercare-support-after-sap-upgrade/

https://www.plantvision.se/hypercare/

https://opsasto.blog/2017/09/the-service-cutover-plan/

https://www.linkedin.com/pulse/went-live-now-what-part-1-ausra-gustainiene/

https://www.acronotics.com/bot-maintenance

https://success.coupa.com/Implement/Overview/04_Deploy/4.4_Establish_Hypercare_Plan

http://wpc.0b0c.edgecastcdn.net/000B0C/Presentations/GRC2016_Marrs_Hypercarehowtohandlesecurity.pdf

https://www.gartner.com/en/documents/3178218/how-to-plan-your-erp-project-s-go-live-hypercare-and-sta

https://prezi.com/3dhep-u49p2x/hypercare-model-kudu-wave-1/

https://slideplayer.com/slide/14254660/