Vendor Support 2

Process

As this process document does not contain procedural information, the intended and target audience and applicability is specific to directors, managers and leaders across ITD and EDConnect.

The Vendor Support Process document has been created to provide a framework to support and underpin the Service Management elements of Vendor Support. It is not intended to be a procedural document and subsequently will be supported by the Vendor Support Procedure.

Vendor Support, within NSW Department of Education, broadly leverages and contributes to multiple processes within the ITIL Service Management Framework. This includes:

Service Design
  • Supplier Management - To ensure that contracts with suppliers support the needs of the business, and that suppliers meet their contractual commitments.
Service Transition
  • Service Asset and Configuration Management – To maintain information about Configuration Items required to deliver an IT service, including their relationships.
Service Operations
  • Incident Management - To manage the lifecycle of vendor incidents. The primary objective of Incident Management is to return the IT service to users as quickly as possible.
  • Request Fulfilment - To fulfil Service Requests, which in most cases are minor (standard) Changes (e.g. requests to change a password) or requests for information.
  • Problem Management - To manage the lifecycle of all Problems. The primary objectives of Problem Management are to prevent Incidents from happening, and to minimize the impact of incidents that cannot be prevented. Proactive Problem Management analyses Incident Records, and uses data collected by other IT Service Management processes to identify trends or significant Problems.
  • Knowledge Management - To gather, analyse, store and share knowledge and information within an organization. The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge.
Continual Service Improvement
  • To use methods from quality management in order to learn from past successes and failures. The Continual Service Improvement process aims to continually improve the effectiveness and efficiency of IT processes and services, in line with the concept of continual improvement adopted in ISO 20000.

3.1. Purpose

The Vendor Support Process document guides, provides and underpins clear and comprehensive frameworks for facilitating process in alignment with established service management process and procedures.

The purpose of Vendor Support is to facilitate and assist the organisation to provide customers with a consistent, high quality and timely vendor support service and to provide a channel for escalation management, provide and request information, and to ensure overall vendor performance in line with Information Technology Directorate (ITD) managed contracts.

3.2. Scope

The Vendor Support Process leverages and contributes to multiple processes within the ITIL Service Management Framework in alignment with established Service Management Office process and procedures. Vendor Support is framed within the supporting process or procedural document and operates within the bounds of Information Technology Directorate managed contracts in partnership with vendors and support groups across the organisation.

The Vendor Support Process applies to the operations of vendor support in alignment with the other Service Management processes in relation to a product or service delivered to customers by the Service Management organisation.

4.1. Single Process

Vendor support, as a process, is comprised and expressed as an amalgam of processes to serve a service management function. A single vendor support process will be used to guide, manage, support, and underpin vendor support within the organisation and is based on industry best practises.

The vendor support process is detailed and framed in the supporting process, procedural, work instruction and guideline documents.

4.2. Process Alignment

The vendor support process will directly relate to, support and underpin all service management processes within the service management organisation. The alignment of these polices is detailed and framed in the supporting process, procedural, work instruction and guideline documents.

Communications with the customer and vendor support community in relation to process and procedures is the responsibility of the individual accessing the vendor support content. This process is detailed and framed in the supporting process, procedural, work instruction and guideline documents.

Reporting will cover service, products, customer, business unit, support teams and support individuals. These reports will be used to ensure that the services delivered to customers perform within the instruction of the vendor support process and procedure.

The purpose of the governance is to ensure that process and procedures are implemented and adhered to. Governance includes defining accountability, roles and responsibilities, adherence and automation, measuring and reporting, and taking actions to resolve any identified issues.

The governance group will also assess the results of internal quality reviews and continual service improvement plans.

7.1. Governance Group

Members of the Governance Group are:

  • Director, Service Management
  • Director, Service Delivery
  •  Director, Service Support
  • Director, Service Operations
  • Director, Field Operations
  • Vendor Operations Lead

7.2. Stakeholders

  • Information Technology Directorate leadership team;
  • IT Customer Experience and Service Delivery;
  • Commercial and Resources;
  • Vendors engaged via ITD managed contracts.

Procedure

The vendor support procedure is owned by the director, service delivery and managed by the vendor operations lead.

Vendor support is the process used for the end-to-end warranty management of consumer hardware across the NSW Department of Education in line with Information Technology Directorate (ITD) managed contracts. The goal of an effective vendor support procedure is to ensure the day-to-day performance of vendors meets contractual arrangements and the expectations of customers and support groups.

The responsibility for establishment and maintenance of standards, processes and procedures resides with the Vendor Operations Lead.

1.1. Purpose

The Vendor Support Procedure document describes the processes which must be followed to ensure:

  • lifecycle management of vendor support;
  • correct application of warranty entitlement;
  • toolset operation;
  • handling of customer and support group escalations;
  • accurate and meaningful advice is provided to customers; 
  • and department requirements within ITD managed contracts are satisfied.

Vendor support facilitates the end-to-end management of a defined sub-set of warranty entitled hardware across the department, purchased under an ITD managed contract. It is important that customers and support groups recognise and understand the scope of the Vendor Support procedure.

The sections below describe hardware which is in-scope or out-of-scope for vendor support.

2.1. In Scope

Warranty entitled desktop, laptop and tablet technologies purchased by or supplied to schools and non-school offices under the standard devices offerings including:

  • Acer - desktop and laptop.
  • Apple - desktop and laptop (excludes tablet and mobile).
  • Dell - desktop, laptop and tablet.
  • HP Inc - desktop, laptop and tablet.
  • Lenovo - desktop, laptop and tablet.

Warranty entitled server and network technologies purchased by or supplied to schools and non-school offices under an ITD managed contract or standard offering including:

  • Dell - server, UPS and storage.
  • Hewlett Packard Enterprise - network switch.

2.2. Out of Scope

  • Non-warranty or out-of-warranty desktop, laptop and tablet technologies purchased by or supplied to schools and corporate offices under the standard devices offerings.
  • Non-warranty, out-of warranty or non-maintenance server and network technologies purchased by or supplied to schools and corporate office under an ITD managed contract.
  • Technologies procured outside of standard devices offerings or ITD managed contract including where exemption has been granted. This also includes technologies procured under other NSW Government contracts.
  • Technologies procured under department Procurement Directorate managed contracts. For example: printers including multi-function devices and photocopiers, smartboards and audio/visual equipment.

Issues concerning or relating to supply, purchase, return and disposal of technology procured under standard devices offerings or ITD managed contract, and department Procurement Directorate managed contracts.

Vendor support has evolved significantly since its inception within the department. The driver of all significant change has been to enhance the end-to-end lifecycle and customer experience of Vendor Support as a result of:

  • changed contractual arrangements with vendors;
  • enhancements within the ITSM toolset;
  • establishment of Service Management processes; and
  • shift-left and organisational restructure initiatives.

At the time process establishment, there were approximately 22 variations of the Vendor Support process across the department ICT support organisations. The Vendor Support Procedure document defines the single, contemporary work practices of all support groups.

3.1. Overview and RACI

  • R - Responsible: Those who do the work to achieve the task.
  • A - Accountable: Those who have ownership of the task.
  • C - Consulted: Those who are called upon to contribute information.
  • I - Informed: Those who are provided update(s).

Overview and RACI table (DOCX 14.24KB)

Vendor support procedure overview flowchart (DOCX 101.42KB)

For the purposes of a consistent and holistic approach to Service Management across the organisation, Vendor Support aligns to the following established service management processes:

  • Incident Management
  • Request Fulfilment
  • Problem Management
  • Knowledge Management

Additionally, Vendor Support contributes to building organisational maturity for the following Service Management processes:

  • Supplier Management
  • Service Request Management
  • Service Asset and Configuration Management
  • Continual Service Improvement

Vendor Support leverages the Remedy Information Technology Service Management (ITSM) platform to align with Service Management process and as an integration mechanism with vendors. Remedy drives the day-to-day operations of Vendor Support by maintaining the relationships of customers, sites, support groups, vendors, configuration items, incidents, problems and knowledge.

5.1. Remedy Integration

Integration with vendors is based on an SMTP transactional relationship between Remedy and vendor systems. Based on the analyst or support team input into Remedy, a SMPT transaction (message) is created and sent to the vendor to trigger a sibling incident (Vendor Ticket) in the vendor system. The Vendor Ticket is then managed end-to-end until the sibling incident is closed, sending a resolution to Remedy.

Remedy is only able to send 1 message to the vendor system to initiate the creation of a Vendor Ticket. No other event in Remedy such as updating the work detail or reassigning the incident to another support group will trigger a message to the vendor system.

There are 4 key messages from the vendor system to Remedy:

  • ACK – an ACK (acknowledgement) message from the vendor system identifies that the message from Remedy has been received by the correct vendor with all mandatory fields populated.
  • NACK – a NACK (not acknowledged) message from the vendor identifies that the message from Remedy has been received by the wrong vendor or not all mandatory fields or information has been included.
  • UPDATE – a UPDATE message from the vendor adds an entry to Work Detail of the associated Remedy incident.
  • RESOLVE – a RESOLVE message from the vendor resolves the associated Remedy incident and provides comments in the Resolution field.

It has been identified by customers, support groups and vendors that the current integration will not continue to meet the maturing needs of the organisation, and work is currently underway to implement an API to enable a more highly sophisticated transactional relationship between Remedy and Vendor systems.

5.2. Remedy Assigned Groups

All incidents assigned to vendor must be assigned to the SD Vendor Support queue. This is to ensure that incidents are correctly assigned, and to monitor and manage service delivery with the vendor. The SD Vendor Escalation queue is for the use of the Vendor Operations Lead for the purposes of escalation management and problem management.

The quality of a vendor incident is imperative to ensure contractual arrangements for Service Level 1 is satisfied and the incident is acknowledged (ACK) by the vendor. The assigning analyst or support team is responsible for providing complete and accurate information for the vendor to ACK the incident and undertake repair to restore the technology fault.

Incidents which do not contain quality information will:

  • be not acknowledged (NACK) by the vendor (rejected);
  • cause delay for the vendor to resolve the customers fault; and
  • request a repair which will not resolve the customers fault;

6.1. Data Sources

Remedy uses a number of data sources to construct and send an SMTP transaction to a vendor. When a Vendor Group is selected, the current information stored within these data sources will be sent to the vendor to request a warranty service. The vendor will use this information to assess the validity of the request and determine the action required to repair the fault.

Note: Updates to these fields after the Vendor Group is selected is not sent to the vendor. If corrections or additional information must be shared with the vendor, please contact the Vendor Operations Lead.

The following incident data is provided to the vendor for their assessment and use:

  • Customer Remedy profile (includes name, address and contact information)
  • CI related to the incident (includes serial number, manufacturer and model information)
  • Incident fields (Incident ID*+, Question/Symptom*, Notes, Priority)

Analysts and support teams should ensure that appropriate information is stored in these fields.

6.2. Quality Requirements

Within the context of the Vendor Procedure, all vendors are engaged with the department under a 'no screen' arrangement. This means that the department must satisfy all Service Level 1 prior to engaging the vendor for warranty service. Fundamentally, this requires analysts and support teams to clearly identify a failed hardware component (eg. RAM, HDD, optical drive etc.) for replacement or provide sufficient diagnostic and fault isolation information for the vendor to make an informed determination. Analysts and support teams should prompt and support customers to perform basic troubleshooting to develop this information to be clear and succinct without department jargon.

The following examples have been prepared to demonstrate best practice: (note screen grabs in following examples are replaced by text.)

Example 1:

Fault isolation.

Incident – Notes

Customer reported that monitor will not power on.

-          Customer has confirmed that cable is installed in a known working power outlet

-          Customer has tested monitor will not work with another desktop

-          Customer has tested monitor with alternative power and display cables

-          Customer has confirmed that there is no physical damage to the monitor

Please investigate under warranty

[OK] [Cancel] 

 

Example 2:

Observation and diagnostic information.

Incident – Notes

User is experiencing issues with booting laptop. When he pushes the power button, the laptop makes a series of beeping noises and does not display anything on screen. He says he can hear fan noise until the beeps stop and then the laptop turns off.

The Beeps are :two short, one long, one short.

[OK] [Cancel]

 

Example 3:

Diagnostic information and requesting replacement of specific failed component.

Incident – Notes

Desktop is unable to complete network rebuild. Rebuild process experiences an error message during install and the desktop restarts and displays message “No operating system found”.

Customer performed HDD check in BIOS which reported ‘critical failure’. Can you please replace HDD.

[OK] [Cancel]

 

The following examples have been prepared to demonstrate common issues:

Example 1:

Information in the work detail is not available to the vendor. Issue was investigated which identified a switch fault however this information was not updated to the Notes field before selecting the Vendor Group.

Incident – Notes

Wireless access points in D block won’t turn on. Customers says it was like this since school retuned from the weekend. All other blocks appear to be fine.

[OK] [Cancel]

 

Example 2:

Information contains department specific process and insufficient information to identify a specific failed hardware component.

Incident – Notes

Cannot perform F12 Rebuild on laptop

[OK] [Cancel]

 

Example 3.

Information describes faults with two separate devices. These will need to be separated into unique incidents and assigned to the appropriate Vendor Group.

Incident – Notes

I have a problem with two of my computers.

The laptop in my classroom is making load grinding sound form the HDD when turned on and is running really slow. Can you please replace the HDD.

The desktop in the staff room has an error message when it turns on: ‘Fan Error 002’.

[OK] [Cancel]

Entitlement is consistent across all vendors operating under an ITD managed contract. However, each vendor may have a unique delivery mode or terminology in order to deliver the service within their global support model. The following provides analysts and support teams with the common entitlement breakdown and associated terminology.

  • Dead on Arrival (DOA). DOA is a provision within the Warranty Entitlement period to replace a device if it is found to be damaged or does not work during unboxing, or a hardware component fails within the first 3 weeks (21 days) of normal use. Vendors may also offer a repair service during this time if it represents a more agile service to the customer. Note: It is at the customer’s discretion whether to replace or repair.
  • Warranty Entitlement. Warranty entitlement is coverage for component failure throughout the duration of the warranty period. The duration of warranty entitlement may vary depending on the type of device purchased under ITD managed contract. For example:
    • Tablet/Chromebook – 2 year
    • Base model and non-touch notebooks – 2 year
    • All other notebooks – 4 year
    • Desktops and servers – 4 year
    • Switches - Limited lifetime warranty
  • Onsite or Return to Base (RTB) Entitlement. Onsite entitlement describes whether any repairs undertaken by the vendor will be performed at the location of the customer. RTB entitlement describes whether any repairs undertaken by the vendor will require the device to be sent by the customer to a depot for repair.
  • Lemon Rule. Lemon Rule describes a device which has received 3 completed repairs during the warranty period and experiences any further component failure. The customer will be entitled to replacement of the equivalent standard devices or repair at the customers discretion. Note: Replacements inherit the warranty entitlement of the faulty device.
  • Customer Replaceable Unit (CRU). CRU entitlement describes whether repair or replacement of components can be undertaken by the customer without vendor certification.
  • Whole Unit Replacement (WUR). WUR entitlement describes that any component failure on the device will result in the device being replaced and the faulty unit collected by the vendor.
  • Non-Warranty. Non-warranty describes component failure on a device which is not covered under the warranty agreement. This may include physical damage, environmental damage etc.
  • Out of Warranty. Out of Warranty describes component failure on a device outside the warranty period.

Escalations to the vendor are managed by Vendor Support at the request of customers or support groups, and proactively through service level monitoring and reporting. Escalations may be made to a vendor for a variety of reasons including:

  • Call to action for progressing repairs or maintenance;
  • Request for information or clarification;
  • Providing missing or supplementary information;
  • Cancelling an incident; and
  • Customer complaint.

Escalations from customers must be referred to the Vendor Operations Lead for investigation. Analysts and support teams should collect and include the following information to include with the escalation:

  • Incident number;
  • Customer details;
  • Details of any related incident history including previous repairs or services;
  • Details of any related correspondence between the vendor and the customer; and
  • Details of any previous escalations.

Analysts and support teams should also make a copy of the escalation within the incident work detail for audit purposes. As the escalation progresses, updates will be added to the incident work detail for Analysts and support teams to track progress and provide updates to the customer (where required).

Vendor Support is continuously reviewing, updating and creating knowledge articles to assist support teams. Articles which identify the Owner Group as SD Vendor Escalation and are in a published state should be treated as an authoritative source of information. Guides and support materials contained within articles should be accessed from the article when required and not downloaded locally to ensure ongoing accuracy and relevance.

Vendor Support reporting is an important function of managing customer experience and vendor performance. All current reports are generated for the purposes of mandatory reporting cycles, proactive incident management, trend analysis, and process compliance. Availability of these reports is restricted under department and vendor commercial-in-confidence.

  • ACK - Acknowledgement message from vendor to accept an incident
  • Action plan suspended - Vendor has been unable to contact customer to schedule repair
  • API - Application programming interface
  • RTB - Return to base
  • Call deferred - Vendor has been advised by customer to attend site at another nominated time
  • Call on hold - Vendor is shipping parts to local repairer
  • CID - Customer induced damage
  • Connote - Consignment note
  • Contacting client - Vendor is attempting to contact customer
  • CRU - Customer replaceable unit
  • DOA - Dead on arrival
  • MWD - Missing, wrong, damaged
  • NACK - Not Acknowledged message from vendor to reject an incident
  • ONSITE - Technician has attended site
  • OOW - Out of warranty
  • POD - Proof of delivery
  • Resources being scheduled - Vendor is attempting to contact customer to arrange onsite repair
  • Return of machine via courier - Vendor has shipped device to customer
  • SMTP - Simple mail transfer protocol
  • VTN - Vendor Ticket Number created as a reference for the sibling vendor incident
  • Verifying client entitlement - Vendor is validating what entitlement(s) are applicable to the device and repair
  • Working the request - Vendor is contacting local repairer
  • WUR - Whole unit replacement
Return to top of page Back to top