REALME REPLATFORMING AGENCY ENGAGEMENT PACK - SERVICE MANAGEMENT COMPONENT - REALME FOR DEVELOPERS AND ...
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
RealMe® Replatforming
Agency Engagement Pack
Service Management Component
Version 1.0 (FINAL)
March 2021
Agency Engagement Pack
Revision History
Version Date Description of changes
0.1 21 April 2020 Initial draft
0.2 1 May 2020 Initial feedback incorporated
0.3 25 May 2020 Further Feedback from UNIFY and
DIA
0.4 25 September 2020 Final Draft with updated timelines
0.5 18 December 2020 Updated timeline
1.0 23 March 2021 Final with updated timeline and
support structure
Service Management Page 2 of 18Agency Engagement Pack
Table of Contents
1 BACKGROUND ............................................................................................................. 4
2 PURPOSE .................................................................................................................... 5
3 OVERVIEW.................................................................................................................. 6
4 SERVICE TRANSITION ..................................................................................................... 7
4.1 Service Validation and Testing ............................................................................................ 7
4.2 Change Management .......................................................................................................... 8
4.3 Planning and Support .......................................................................................................... 8
5 SERVICE OPERATION ................................................................................................... 10
5.1 Support and Contact Details ............................................................................................. 10
5.2 Support Contact Information and Escalation Details........................................................ 11
5.2.1 DIA Internal Escalation Process................................................................................. 11
5.3 Service Level Agreement................................................................................................... 12
5.4 Incident Management....................................................................................................... 12
5.4.1 Incident Priority......................................................................................................... 12
5.4.2 Incident Escalation Procedures ................................................................................. 13
5.5 Agency Notifications ......................................................................................................... 13
5.6 Change Management ........................................................................................................ 14
Release Management ................................................................................................................. 14
5.7 Reporting........................................................................................................................... 15
5.8 Financial ............................................................................................................................ 15
5.9 Knowledge Management .................................................................................................. 15
6 ENVIRONMENTS ......................................................................................................... 16
6.1 Message Testing Site (MTS) .............................................................................................. 16
6.2 Integration Test Environment (ITE) ................................................................................... 16
6.3 Production......................................................................................................................... 16
7 APPENDIX ONE – INCIDENT MANAGEMENT PROCESS FLOW ................................................... 17
7.1 DIA RealMe Service Desk Process Flow ............................................................................ 17
7.2 UNIFY Managed Services Process Flow............................................................................. 18
Service Management Page 3 of 18Agency Engagement Pack 1 Background The authentication and identity verification service RealMe® was launched in 2013. RealMe is a secure and privacy protected way for New Zealanders to access online services, prove their identity and assert personal information online. RealMe provides two key services, the login service and the identity verification, or assertion, service. The login service is an authentication service that allows a returning customer to reuse their login across multiple services. RealMe login currently provides access to 131 services from 40 organisations. Up to 2.5 million logins occur monthly and approximately 60-80% of logins are used to access more than one service. The RealMe Assertion service provides a person with an online identity, allowing them to prove (with their consent) that they are who they say they are online. The pieces of information belonging to a person are called attributes. Attributes are currently provided by the Department of Internal Affairs Identity Verification Service (verified identity – name, date of birth, place of birth and gender) and the New Zealand Post Address Verification Service (residential address). Providing the verification services separately ensures that a person’s attributes are not stored within RealMe itself. The RealMe Assertion service currently provides identity services to 17 public and private sector clients. There is over 820,000 verified identities and the service undertakes over 30,000 successful identity transactions per month. The current RealMe platform is hosted ‘on premise’ and requires significant three-yearly capital investment to upgrade expiring platform components. After consideration of the ongoing costs required to maintain the current platform, the government and DIA’s strategic direction to consider ‘cloud first’ technology options and the potential benefits of a cloud-based platform in terms of faster development, improved security and reduced costs, DIA made a decision to move the RealMe service to an offshore, cloud based platform. DIA selected Microsoft Azure Active Directory B2C as the new platform. DIA has an existing enterprise cloud services agreement with Microsoft, which includes its use of the Azure platform. This agreement incorporates the standard Online Services Terms (which includes a separate Data Protection Addendum) that apply to DIA’s use of Azure. In late 2019 DIA underwent an RFP process to procure an implementation partner, and in December 2019 engaged Unify Solutions NZ Ltd (UNIFY) to carry out this transition, as well as provide ongoing service support. The goal is to have RealMe moved to the new platform early in the second quarter of 2021. Service Management Page 4 of 18
Agency Engagement Pack
2 Purpose
The purpose of the Agency Engagement Pack is to provide agencies with a good understanding of
the purpose, objective, approach, timelines, process and mechanism for integrating applications to
the new RealMe® platform.
The intended audience for this pack includes agency business owners, business analysts, developers
and vendor representatives.
This is the final of three artefacts which, together, form the Agency Engagement Pack:
Artefact Contents
Agency Readiness Pack • Solution Overview
• Roles and Responsibilities
• Pre-requisites
• Engagement Plan (high level)
Agency Onboarding Pack • Engagement Plan (revised)
• Configuration Items
• Integration and User Acceptance Testing
• Rollout across Higher Environments
Service Management Pack (this • Service Transition
document) • Service Operation
The Agency Engagement Pack and related documentation including a list of Frequently Asked
Questions is available on the RealMe Login and Assertion replatforming page of the RealMe
Developer's website.
If you have any questions regarding any aspect of the Replatforming of RealMe please contact
integrations@realme.govt.nz.
Service Management Page 5 of 18Agency Engagement Pack
3 Overview
This document details the processes which will be in place to support agencies who have
applications integrated with the existing RealMe® service. It covers details of the support that will
be provided to agencies prior to, during and after the transition to the replatformed RealMe service
and the service operation following that transition.
This document does not attempt to detail process or procedures relating to the following:
• RealMe Service User processes. These processes will remain unchanged, i.e. customers can
seek support from RealMe self-service, the RealMe Help page or contact the RealMe Help
Desk via email or phone.
• Integration support for existing applications. This process will remain unchanged, agencies
can contact RealMe Level 2 Support via phone or email. If an agency service is unavailable
or significantly impacted due to a RealMe Production issue, a phone call should be made.
• Integration support for new applications. This process remains the same:
o Message Testing Site (MTS): Full integration documentation is available on the
RealMe MTS page or contact integrations@realme.govt.nz.
o ITE / Production: Log an ITE Vendor Access Application from ITE Integration or
Information Request page or contact integrations@realme.govt.nz.
• Renewal of SAML Signing certificates. The process for replacing an expiring Service Provider
(SP) certificate or Identity Provider (IdP) certificate will remain unchanged from an agency
perspective, that is:
o SP certificate expiry: log a Simple Configuration Request from the RealMe
Developer’s website.
o IDP certificate expiry: DIA will provide advance communication and documentation
when the IdP certificates are next due to expire.
• Address Verification Service (AVS) and Identity Verification Service (IVS) as these services are
unchanged by the replatforming of RealMe.
• Training Material for the Help Desk Web Application as these details will be captured as a
separate document.
• RSA Token Administration as this process will remain unchanged.
• Detailed Incident Management, Change Management and Release Management processes
for RealMe. These processes will be detailed in DIA’s Service Support Design Package (SSDP)
and UNIFY’s Service Management Plan for DIA.
Service Management Page 6 of 18Agency Engagement Pack
4 Service Transition
This section provides information about the transition of the RealMe® Login and Assertion services
to the replatformed RealMe. This includes a high-level overview of the validation and testing that
will be performed, the change management process that will be followed and the support that will
be available prior to, during and after the transition to the replatformed RealMe.
4.1 Service Validation and Testing
The replatformed RealMe will be subject to rigorous testing at each stage of the development
lifecycle. Testing will cover all aspects of the replatformed solution including the login and assertion
services, the replatformed Help Desk web application, Service User experience/self-service and data
migration.
There are eight environments each of which supports different phases of the validation and testing
required for the replatformed RealMe as below:
Environment Validation / Test Responsible
Development Unit Testing UNIFY Development Team
Data Migration Testing UNIFY Development Team
System Test Smoke Testing UNIFY Test Team
System Testing UNIFY Test Team
System Integration Testing UNIFY Test Team
Data Migration Testing UNIFY Test Team
User Acceptance Testing Smoke Testing UNIFY Test Team
(UAT) Build Verification Testing UNIFY Test Team
User Acceptance Testing DIA Test Team
Penetration Testing Third Party Vendor
Data Migration Testing UNIFY Test Team
Early Integration Testing (EIT) Temporary Environment for early Agencies
Integration Testing by Complex Agencies1
Message Testing Site (MTS) Smoke Testing UNIFY Test Team
Build Verification Testing UNIFY Test Team
Agency Integration Testing (optional) Agencies
Integration Test Environment Smoke Testing UNIFY Test Team
(ITE) Build Verification Testing UNIFY Test Team
Penetration Testing Third party vendor
Load Testing UNIFY Test Team
Data Migration Testing UNIFY Test Team
Agency Integration Testing Agencies
Pre Production (PP) Smoke Testing UNIFY Test Team
Build Verification Testing UNIFY Test Team
Production (Prod) Post Implementation Verification UNIFY, DIA and Agencies
1
Complex agencies are deemed to be those who have services which use the Assert then Login flow and/or
run their own RealMe Help Desk. This environment will not be available post go-live.
Service Management Page 7 of 18Agency Engagement Pack
4.2 Change Management
The replatforming of RealMe is subject to a robust change management process to support a
seamless Production transition. DIA will continue to notify agencies regarding the schedule of
change and ensure that they are fully informed regarding their role throughout the lifecycle of the
project.
There are a series of key milestones which must be met prior to the deployment of the replatformed
RealMe Solution to each environment. The sequence of key milestones are as follows:
Milestone Required for
Investment Governance Committee consider / approve Change ITE, PP, Prod
Request
Approve UAT Test Handover Certificate ITE, PP, Prod
Approve ITE Test Handover Certificate PP, Prod
Obtain DIA Technical Advisory Board approval ITE, PP, Prod
Obtain DIA Change Advisory Board approval ITE, PP, Prod
All agency applications are successfully integrated in ITE Prod
Production go-live confirmation Prod
In addition, there are several go / no-go decision points which are incorporated into the go-live
process. For further information regarding these decision points, please refer to the Agency
Onboarding Pack available on the RealMe Login and Assertion replatforming page of the RealMe
Developer's website.
4.3 Planning and Support
The DIA and UNIFY teams will support agencies throughout the replatforming process. The
following table outlines the support that will be in place to assist agencies with replatforming
RealMe in each environment.
Environment Description Support Window Support
EIT Integration testing in EIT is 9 Nov 2020 to 20 Jan Email integrations@realme.govt.nz
expected to be performed by 2021 Briefings with agencies will be
agencies with complex carried out prior to the release of
integrations. EIT.
MTS Integration testing in MTS is Mid January 2021 (tbc) Email integrations@realme.govt.nz
optional and at the discretion of
each agency.
ITE Integration testing in ITE is 26 Jan to 26 Mar 2021 Email integrations@realme.govt.nz
mandatory and must be Drop-in workshops will also be run
completed by each agency prior by DIA / UNIFY during the
to Production go live. integration period.
Production Integration to Production must 11 Apr 2021 Email integrations@realme.govt.nz
be carried out by each agency Phone support to be provided by
during the specified window. DIA / UNIFY during the go-live
period.
For a detailed timeline of the steps required to replatform in each RealMe environment, please refer
to the Agency Onboarding Pack available on the RealMe Login and Assertion replatforming page of
the RealMe Developer's website.
Additional support will be available to assist agencies with their integrations to each environment.
This will include a four-week period of heightened support post Production go-live.
Service Management Page 8 of 18Agency Engagement Pack Further information regarding the specific support for agency integrations to MTS (optional), EIT (complex agencies), ITE and Production will be made available prior to the integration support window for each environment. Service Management Page 9 of 18
Agency Engagement Pack
5 Service Operation
This section covers the support that will be available to service users and agencies post the RealMe®
replatforming.
For further information regarding specific details for your agency, please refer to your RealMe
General Terms and Conditions and Key Terms. If you are unable to locate these key documents,
please contact business@realme.govt.nz and request a copy.
5.1 Support and Contact Details
The RealMe Help Desk provides a single point of contact for agencies and Service Users seeking
assistance with the RealMe service. The RealMe Help Desk provides the following support:
Support Group Support Level Scope of Support
DIA RealMe Help Desk Level 1 • Provide Service Users with assistance via phone and email in
use of the RealMe services, such as:
o resetting passwords;
o sending usernames;
o changing contact details within RealMe;
o discussing transactions with users;
o Assist with accessing agency services.
• Call logging and first level triage and troubleshooting.
• Escalations to Level 2 support.
Agency Service Desks Level 1 • Available where the agency has elected in the Key Terms to
provide First Level Support2.
• First point of contact for agency application support,
including RealMe user support.
• Escalations to Level 2 support.
DIA RealMe Administration Level 1 • First point of contact for support with existing application
integrations.
• Incident support for known issues.
• RSA Token Administration.
• Invoicing and reporting.
• Escalations to Level 2 support.
DIA RealMe Level 1 • First point of contact for support with new application
Business/Integration Team integrations and queries from the Developer’s website.
DIA RealMe Support Level 1 • First point of contact for agency Service desks if they have
queries related to process and procedure.
DIA RealMe Service Desk Level 2 • First point of contact for high priority service issues /
(GLSFIX) outages.
• Escalations from DIA and Agency RealMe Service Desks and
DIA RealMe Administration.
• Support for the Identify Verification Service (IVS).
• Route Address Verification Service (AVS) issues to AVS
Support.
• Second level support for the Identify Verification Service
(IVS).
• Escalations to UNIFY RealMe Support.
2
Where an agency wishes to provide its own First Level Support, it will be required to enter into an additional
Schedule regarding the provision of such support.
Service Management Page 10 of 18Agency Engagement Pack
Support Group Support Level Scope of Support
UNIFY RealMe Support Level 2/3 • Receive and record incidents from DIA RealMe
Administration, DIA RealMe Business/Integration team and
DIA RealMe Service Desk.
• Receive requests from the RealMe Developer’s website
including:
o certificate renewal;
o integration configuration changes/technical support;
o new client integrations.
• Support for RSA Token Administration.
• Liaise with Microsoft to facilitate incident resolution.
• Create and maintain a support knowledge base.
• Provide after-hours support for critical incidents (P1/P2
only).
DIA Azure Support Level 3 • Escalations from UNIFY RealMe Support for DIA related MS
Azure issues.
• 24 x 7 currently performed by Datacom.
Microsoft Level 3 • Escalations from UNIFY RealMe Support for MS Azure
related issues.
• 24 x 7 coverage under DIA’s support subscription.
5.2 Support Contact Information and Escalation Details
The following table provides the contact details for each of the Support Groups along with an
escalation contact should an incident/support request not be actioned in the appropriate timeframe
or manner.
Support Group Contact Coverage Escalation Contact
Hours
DIA RealMe Help NZ 0800 664 774 24/7 DIA RealMe Administration
Desk INT +64 4 462 0674 RealMe Level 2 Support
For e-mail support (during business
hours): help@realme.govt.nz
DIA RealMe RMAdmin@realme.govt.nz Business DIA RealMe Business/Integration
Administration Hours Team
DIA RealMe Service Desk
DIA RealMe integrations@realme.govt.nz Business DIA RealMe Service Desk
Business/Integration business@realme.govt.nz Hours
Team
DIA RealMe Service 0800 457 349 or 24/7 DIA Service Delivery Manager
Desk for e-mail support (during business After
hours): RealMe@datacom.co.nz hours
P1/2 only
5.2.1 DIA Internal Escalation Process
DIA will use the following internal escalation matrix should an incident/support request not be
actioned in the appropriate timeframe or manner.
Escalation Level UNIFY DIA
Level 1 Service Delivery Manager (SDM) Service Delivery Manager (SDM)
Level 2 Managed Services Lead Unified Services Manager
Level 3 Account Manager Service Performance & Integration Manager
Level 4 General Manager – Cloud Services GM TSS/CIO
Service Management Page 11 of 18Agency Engagement Pack
5.3 Service Level Agreement
The Service Levels detailed below relate to Production RealMe System, not the RealMe Data used in
the provision of RealMe Services.
Service attribute Key Performance Indicator (KPI) Target Service Level
Performance RealMe System response time for user 85% of transactions occur within 6 seconds
transactions
Availability Availability of the RealMe System Availability ≥ 99.9%, excluding scheduled
outages3
Security Serious security intrusion events (the Zero intrusion events
number of intrusions events within
measurement period that results in loss of
service, unauthorised access, corruption or
loss of data)
5.4 Incident Management
If an agency becomes aware of an incident as described in the following sections, they must notify
the RealMe Service Desk (Level 2 support) immediately. The RealMe Service Desk will manage
resolution of the Incident in accordance with the incident priority set out below. For further
information regarding the Incident Management process flows please refer to Appendix One –
Incident Management Process Flow on page 18 of this document.
5.4.1 Incident Priority
DIA are responsible, with the support of their vendors, for responding to and resolving Incidents.
Incident response will be in accordance with the timeframes defined in the table below, depending
on the priority level of the Incident, once these are notified to the RealMe Help Desk.
RealMe Login Service and Assertion Service incident resolution timeframes apply around the clock
(24/7). Other RealMe Service incident resolution times apply during Business Hours only.
Priority Priority Definition Target Restoration
1 • Daily business operations cannot take place. Major components of the
Service (or Services) are not functioning as specified.
• An outage resulting in an interruption to a business-critical service or
services. • 4 hours, including 15
• Will affect an entire agency business unit or multiple personnel across min response time
multiple agencies or multiple Service Users.
• Any security issue which is likely to put daily business operations of the
agency at risk.
2 • Daily business operations for the agency are substantially slowed or
reduced.
• An outage resulting in an interruption to an agency Service.
• Multiple Service Users will usually be affected.
8 hours, including 15
• An individual in the agency’s organisation with an urgent problem likely
min response time
to have a substantial negative impact on their business.
•
• Management escalation - urgent attention requested. Might otherwise
be classified as a P3.
• Any security issue which has the potential to put daily business
operations of the agency at risk.
3
Microsoft currently guarantees at least 99.9% availability of the Azure platform.
Service Management Page 12 of 18Agency Engagement Pack
Priority Priority Definition Target Restoration
3 • Minor interruption to a Service.
2 days, including 30
• An individual Service User is affected.
min response time
• Likely to have a significant impact on the agency’s ability to do their job,
•
but unlikely to affect overall business operations.
4 • Very minor interruption to a Service.
• An individual Service User is affected. • 4 days, including 60
• Likely to have a minimal impact on the agency personnel’s ability to do min response time
their job and highly unlikely to affect overall business operations.
5.4.2 Incident Escalation Procedures
The table below defines the circumstances, order and timeframes in which major RealMe Incidents
are to be notified, reported and escalated by the RealMe Help Desk and other parties, to the
agencies.
Priority Incident Management Process Timing / Event Trigger By Whom
Event
•
Notification (alert) Immediate
•
Incident confirmation and Within 60 minutes of incident
impact being logged
• Hourly from incident
1 Progress Update • RealMe Service Manager
confirmation and impact
• Within 3 hours of incident being
Escalation (if required)
logged
• restoration time
Target 4 hours
•
Notification (alert) Immediate
•
Incident confirmation and Within 90 minutes of incident
impact being logged
• 2 Hourly from incident
2 Progress Update • RealMe Service Manager
confirmation and impact
• Within 6 hours of incident being
Escalation (if required)
logged
• restoration time
Target 8 hours
5.5 Agency Notifications
The DIA RealMe Administration team are responsible for notifying agencies of scheduled or
unscheduled outages. Depending on the issue, the DIA will provide outage notifications to the
appropriate stakeholders and/or affected parties.
In order to ensure an up to date list of contacts is maintained, the DIA maintain a list of:
• agency services and configuration details; and
• associated contacts.
Service Management Page 13 of 18Agency Engagement Pack
5.6 Change Management
DIA will from time to time make scheduled changes to the RealMe System. Scheduled changes to
the RealMe System include changes that:
• will not impact agencies (DIA will still notify agencies);
• are considered by DIA to require consultation with all agencies; and
• changes that impact on agencies, and which are considered by DIA to require the consent of all
agencies (such consent not to be unreasonably withheld).
As far as possible, scheduled changes will be carried out in a change window. Dates and times of
change windows will be published in a change calendar on the RealMe Developer's Website.
DIA will schedule maintenance and repairs to minimise disruption to the agencies. DIA will
endeavour to provide the agencies at least five Business Days’ notice of scheduled maintenance or
repairs where this is likely to affect the RealMe Services.
The Microsoft Azure components of the replatformed RealMe solution are cloud based and
therefore managed and maintained by Microsoft. This means that these components are updated
seamlessly behind the scenes. All changes go through a robust DevOps build and release
management process prior to release to Production. For further information regarding this process
refer to the next section.
Release Management
Microsoft and UNIFY both practice DevOps to manage the System Development Lifecycle (SDLC) of
the replatformed RealMe across the MTS, ITE and Production environments. This includes Project
Management, Source Code Management, Build and Release Management. The Build and Release
process goes through a series of discrete steps and, if any part of the process fails, the change is
rolled back and triaged. At a high level the process is as follows:
• create and submit configuration / code change;
• multiple levels of peer review are carried out;
• the build process commences and, once successfully completed, the change is deployed to a
staging environment;
• automated/synthetic tests including regression, integration and functional testing are
performed;
• a full change management and approval process is followed; and
• the change is deployed to Production.
UNIFY have refined this approach through their UNIFYRapid™ framework. This is a rapid deployment
framework based on the continuous integration and continuous development principles of DevOps
and follows a Test-Driven Development approach. It facilitates faster delivery, continuous
integration, continuous delivery and release, minimises defects, monitors solution delivery and is a
reliable and repeatable process with a focus on compliance, security and continuous improvement.
Service Management Page 14 of 18Agency Engagement Pack
5.7 Reporting
If required, a RealMe Monthly Report will be made available to agencies within 10 Business Days of
the end of the month to which it relates, by a method agreed by the parties. The content of the
Monthly Report will be agreed with the requesting agency.
Existing reporting agreements with agencies will remain unchanged after the replatforming of
RealMe.
5.8 Financial
The charging model will not differ from the existing RealMe model. Depending on the services
which your agency utilises this may include the following:
• calls to the RealMe Help Desk – this may be per call or tiered depending on your agency’s
support agreement;
• local and/or international SMS for multi-factor authentication;
• number of Identity Assertions provided (first time and returning customers);
• number of Address Assertions provided; and
• RSA Tokens:
o one off cost for a new token and/or;
o monthly maintenance per token.
The DIA invoices participating agencies for costs associated with supporting the ongoing operations
of the RealMe Login service each month in arrears and the RealMe Assertion service each quarter in
arrears. In some cases, where the DIA considers the volume of Service consumed by the agency is
low, DIA may invoice quarterly in arrears.
5.9 Knowledge Management
DIA are responsible for maintaining the RealMe developer’s website and documentation for
agencies. This information will be updated on an as required basis to coincide with scheduled
changes to the RealMe service.
Service Management Page 15 of 18Agency Engagement Pack 6 Environments Post go-live, there will be three RealMe® environments available for agency integration which are detailed in the sections below. 6.1 Message Testing Site (MTS) The primary aim of MTS is to provide developers and integrators with the ability to test application integration and exception handling. Agencies can download all the information required to integrate with MTS from the Try it out now link on the RealMe Developer’s website. Agencies must prove their integration in the MTS environment before they can proceed to ITE. For a full list of prerequisites for integration with ITE, refer to Core steps for Technical Integration on the RealMe Developer's website. Maintained by the UNIFY Solutions team, this is a sandbox environment for agencies to test their SAML integrations and is not considered a ‘Production’ environment. For support and assistance in this environment, please email integrations@realme.govt.nz. 6.2 Integration Test Environment (ITE) Provides a stable pre-production testing environment for agencies to integrate their applications to. Agencies will be set up with a formal integration project using the Developers website online integration tool, and can apply to integrate with ITE by completing the ITE Integration Request form from their project board on the RealMe Developer’s website. ITE is where the bulk of agency integration / development occurs and agencies can have multiple instances, e.g. UAT and Pre- Production, to test and build service components. A successful integration to ITE is required before they can proceed to Production. For a full list of prerequisites for integration with Production, refer to Core steps for Technical Integration on the RealMe Developer's website. Maintained by the UNIFY Solutions team, this is considered a ‘Production’ environment and is locked down under security and change management processes. For support and assistance in this environment, please email integrations@realme.govt.nz. 6.3 Production This is a Public facing environment for agency applications. Maintained by the UNIFY Solutions team, the Production environment is locked down under security and change management processes. For support and assistance in this environment, please refer to the Support and Contact Details section on page 11 of this document. Service Management Page 16 of 18
Agency Engagement Pack 7 Appendix One – Incident Management Process Flow 7.1 DIA RealMe Service Desk Process Flow The flow below commences when the Agency initiates contact with the DIA RealMe® Service Desk. Service Management Page 17 of 18
Agency Engagement Pack 7.2 UNIFY Managed Services Process Flow The flow below commences when the DIA RealMe Service Desk assigns the incident to UNIFY RealMe Support. Service Management Page 18 of 18
You can also read
