Implementing ESS in Remedy - Lampson and Maple

Document Sample
Implementing ESS in Remedy - Lampson and Maple Powered By Docstoc
Enterprise Service Suite (ESS)
          in Remedy
Migration to a Data-driven Service Request
           System Architecture

  Sue Lampson & Jonathan Maple
   Sandia National Laboratories
Why Change?
One Service Request: Promote “United Front”
New Customer Bottleneck
• ~3 months to add new team
• ~2-3 weeks to change notifications or team
High maintenance and administration
ESS Implementation Milestones
Package Selection               September 2004
Package Installation                March 2005
Live with IES Help Desk         November 2006
Live with IT partners                June 2006
New Create Request console         August 2006
“Dashboard” complete            November 2006
Kinetics Selection              December 2006
New Notification Architecture        June 2007
The Dream:
Powerful, Intuitive Application Interface

Single interface directed toward a wide audience

Easy to change

Easy to learn, easy to use: No Training Required!
The Reality:
Powerful, Intuitive Application Interface
The good:
• Code ownership – develop your own interface
• Most support partners loved “as delivered”
The bad:
• Customers varied in use requirements
  – “Heavy”        : CSU/Help Desk, Networks
  – “Lite”         : Support Partners
  – “Ultra-lite”   : Project Mgrs, Occasional Use
• Required a lot of training
The ugly:
• Reporting capability very basic
The Future:
Powerful, Intuitive Application Interface

Create web-based “Ultra-lite” interface
Create interface to hand-held devices
Create a SQL table set outside of Remedy for
  Ad-hoc reporting
Provide on-line modularized classes
The Dream:
Consolidated, Integrated Service Requests

One Size Fits All
• Consolidate multiple applications into one
• Consolidate all service requests into one
The Reality:
Consolidated, Integrated Service Requests
The good:
• Supports unlimited service offerings
• Different interfaces talk to same back-end
• 5 Of 7 applications were consolidated
• Can open other forms through the interface
The bad:
• Some service types require a lot more data
• Could not integrate all our service types
The ugly:
• Network Trouble Ticket (NTT) data
  is filled out and attached manually
The Future:
Consolidated, Integrated Service Requests

Implement Kinetics
• Additional data forms dependent on request
• Specialized ticket close-out surveys

Tap into more of ESS’ capabilities
The Dream:
Real-time Team & Notification Admin

 Retain ability to create specialized
  notifications on a per-team & per-event
 Permit easy-to-configure, non-programmer
The Reality:
Real-time Team & Notification Admin
 The good:
 • Team set-up very easy
 • Functionality, especially ticket close-out,
   easily configured and easy to customize
 The bad:
 • Integration to existing notification capability
 • ESS Message construction not data-driven
 • Back-end not easy to customize
 • Testing intensive
 The ugly:
 • Notification set-up is very complex
The Future:
Real-time Team & Notification Admin

Rewrite notifications to be data-driven

Provide Kinetics forms for customers needing
  a flashier close notice
Lessons Learned & Caveats

Primary customer “owners” for each interface
   must be identified
Illusion of “one size fits all;” we have two
    interface sets and need at least four
Deploy in phases
Lessons Learned & Caveats
ESS can be a resource hog and slow; Every
   second, every edit, every button counts
• We live in a “console” environment
• Delivered package is “button clicking”
• Backend developed in early Remedy
   version; customize to use filter guides
• Heavy users don’t care if its pretty OR
   easy, just make it fast
Lessons Learned & Caveats
Let the system do what its does best
(Become one with the product)
• Think twice before changing a core
• Deviation from product philosophy comes
   at a great cost
• Set up every team with their own
   notifications; ESS is about data-driven
Lessons Learned & Caveats

       There is no Fairy Dust

  Any successful system implementation
              takes hard work
  and the support of everyone involved


Shared By: