Documentation

When a ticket involves a Change Request (e.g., IMACD -Installation, Move, Add, Change, and Delete- of a printer queue), an LRS Managed Services Technician will execute the Change Management process agreed upon during Service Design. The change will be recorded in accordance with the agreed procedures and reflected in the Change Management Database (CMDB) if appropriate. LRS technicians will support testing of the deployed LRS solutions when complementary systems or the underlying infrastructure is changed (e.g., upgrades or patching of operating systems or databases) using agreed test procedures in non-production and production environments.

LRS Managed Services are designed to complement the existing LRS Support Services, not replace them. Rather, they are designed to replace the services normally provided by SMEs within the customer’s IT teams or a third-party service provider. Therefore, incidents referred to the LRS Managed Services technicians will typically require Level 2 Support after being triaged at Level 1 by the customer’s service desk or a third party (e.g. MPS provider). Should Level 3 Support be required, the incident will be referred to LRS Support by the LRS Managed Services Technician.

The process for receiving a support ticket will have been agreed during the Service Design and Onboarding process and will vary from customer to customer. The customer’s service desk may start the process of opening a ticket to be assigned to an LRS Managed Services Technician. LRS technicians may also initiate a ticket on behalf of customer from within LRS’ own service management tool.

Classification of incidents helps to ensure proper categorization and assignment of tickets. Service Level Agreement (SLA) compliance is dependent on ticket priority to define response and resolution rate. Priority decides the due-by date before which the ticket must be resolved. Therefore, it is essential to assign the right priority to the ticket. A priority matrix gathers impact and urgency from users and then decides the ticket priority so that business-critical issues are addressed first.

LRS Managed Services technicians will accept a triaged ticket from the service desk and validate that the incident does relate to LRS solutions. If it does not, then the incident will be re-routed to another SME.

In cases where the incident is related to LRS solutions, an LRS Managed Services Technician will respond within the contracted response time according to severity level. These levels and response times are detailed in Section 5 below.

If the incident is related to external service providers such as Cloud or MPS providers, the ticket will be reassigned to the appropriate vendor.

Where appropriate, the incident may also be escalated to the LRS Support Team who may in turn refer to LRS Development.

An LRS Managed Services Technician will manage the incident through to resolution. Efficient communication about the troubleshooting and resolution process helps users to get back to normalcy. When the LRS Technician receives confirmation that the incident has been resolved whether by email or automatic acceptance or via no response after an agreed period of time, the LRS Technician will close the ticket.

In addition to the Standard SLA service shown in the table below, LRS offers Premium and Premium Plus options.

In addition to responding to user-reported incidents, the LRS Managed Services Team will use its own set of monitoring tools. These include the alerts in LRS’ own software (LRS/AlertX and the VPSX Enterprise® Dashboard), which identify extraordinary events such as a server outage, ports that are unavailable, services that are offline, etc. LRS monitoring tools are designed to report accurately on the health of the solutions based on continuous measurement of key internal performance levels and intelligent reporting of those metrics. The exact range of which events will be monitored will be agreed during Service Design.

This event management feature of LRS Managed Services will be particularly important when LRS is also providing the cloud hosting. In this scenario, LRS will leverage additional tools from the hosting provider to monitor server logs, network device logs and key operating system performance metrics to continuously verify system health and stability. Monitoring of events at this level of granularity provides many advantages. These include early detection of conditions before an event happens, a clear understanding of underlying event root cause, and timely notification that a problem state has returned to normal.

The LRS Problem Management component seeks to uncover the root cause of incidents and then to initiate actions to improve or correct the situation. The purpose of the problem management process is to minimize the adverse impact of incidents that have already occurred and to prevent recurrence of these incidents. Through root cause analysis, problems are categorized, prioritized, and logged so that historical data drives proactive problem management as a practice.

Problem Management activities include:

• Reactive Problem Control – Helps identify problems and investigate their causes in response to one or more incidents. Provides workarounds and permanent solutions as needed.
• Error Control – Enables staff to log and monitor known errors through to resolution.
• Proactive Problem Prevention – Identify and eliminate problems before incidents reoccur and reduce the overall number of incidents.
• Identify trends – Uncover problems by conducting ongoing trend analysis of incident records.
• Providing Information – Helps deliver problem data to other process areas. Problem Management requires accurate and comprehensive recording of incidents by the service desk in order for effective and efficient identification of the cause of the incidents and trends.
• Completion of Major Problem Reviews – Commence once a major problem has been resolved to determine what worked well, what did not work well and changes and/or controls needed to prevent the problem from happening again.

The LRS Managed Services Team will be responsible for installing and testing new fixes, releases, and versions of LRS software according to a process agreed during Service Design. This may involve phased deployment in non-production and production environments. The scheduling of releases and deployments will follow the standard change management and approval processes.

The LRS team will establish maintenance windows in order to perform such maintenance. LRS will recommend anywhere from quarterly to annual maintenance windows during hours not disruptive to critical business processes. The detailed maintenance operations, frequency and duration of downtime will be minimized and scheduled accordingly.

There may be LRS software release and fix levels which the customer must accept in order to comply with SLAs. All LRS software must be maintained to currently supported releases. LRS software must operate only on supported versions of the operating system or related software which may impact the service.

LRS Mission Control is a Cloud-based service available to all LRS licensed customers who use our VPSX® and / or MFPsecure® products. 

Note that an environment need not run in the Cloud. But it can. It can even be a hybrid of both Cloud and on-premise, server-based systems. LRS Mission Control is running as a Cloud-based service, but our output management software components can run anywhere. However, to facilitate communication between LRS components and LRS Mission Control, you must be running release V1R4 or later of the VPSX, MFPsecure, and other associated components.

There are three major functional areas to help you understand and manage your LRS environment.

• Licensing
• Dashboard
• Analytics

LRS Mission Control also enhances customers’ analytic abilities. These analytics are geared toward more real-time server and network load situations in the EOM environment.

Customers using LRS software are already familiar with the LRS Innovate/Audit™ database, which provides cost-based analysis of the output management environment. As part of the service, LRS can run and distribute print usage statistics reports from LRS’ Innovate/Audit software, using Power BI or Excel PowerPivot, and LRS’ ServiceNow platform. Innovate/Audit data can be analyzed using other reporting tools, but as LRS does not use these tools internally, use of such tools is not offered as part of the service. Development of new reports is excluded from the service and would be performed as part of a separate Professional Services agreement.

An LRS Service Delivery Manager (SDM) will oversee the service as well as its adherence to service levels. They will also  organize service level reviews and serve as a central point of contact for both the customer and LRS technicians. The SDM monitors service delivery within terms of the service agreement and is responsible for various activities including:

• Ensuring the LRS Managed Services team's processes and tasks are carried out efficiently and accurately
• Providing regular communications and reporting
• Conducting service level reviews

Service level reviews will be held at regular intervals to examine and discuss performance of the service and  compliance with agreed SLAs. Based on this review, LRS may recommend or require software and/or service improvements. This effort facilitates continued alignment of the Managed Services with new and changing business needs. Newly desired outcomes may be within the scope of the existing service or may involve extending the scope, redesigning an area of service, or offering new services. The latter cases may result in added Transformation and/or Transition services to be executed via the change order process.