FirstEnergy’s Service Catalog Journey

Presented To: Vivit Service Manager User Group

Presented By: Kristi Bledsoe

Presented On: October 6, 2011

Agenda

Company intro Our original plan and how it evolved Initial challenges Approval design issues and solution Timeline Our approach, success stories, and

lessons learned

FirstEnergy Corp. Largest US investor-owned electric utility with 6 million

customers and a service territory stretching from western Ohio border to NJ coast and south to WV, Maryland, and Virginia

Company History FirstEnergy Corp. was created with the merger of Ohio Edison and

Centerior Energy in 1997 Merged with GPU in 2001 Merged with Allegheny Energy in February of 2011

Approximately 17,000 employees Company includes both regulated and non-regulated

(competitive) sides of the business

Our Environment Service Manager 7.02

1 Windows application server and 2 load-balanced, web servers Oracle database running on HP-UX Unix server Used primarily by IT (except the Service Catalog) Web client for most users, Thick client for “critical” users

Modules Help Desk (call, incident) Configuration Management Change (used for Change and Request Management) Service Catalog

Service Manager support staff 3 technical, 1 part-time team lead No assistance from outside contractors in recent years

Not OOB and Not “an ITIL shop” Have a long-standing tradition of conforming tools to business

processes instead of business processes to tools Service Manager heavily tailored

Our Original Plan Wanted to bring more consistency to our Request

Management processes (but still use the Change module) Planned to utilize the workflow functionality in the Change

module Started with shared folder access requests Wanted to build the basic structure and then reuse the same logic in

future workflows Planned to work on application security access requests next

Service Catalog slated for a little further down the road Started having trouble with workflows

Bugs Clients not willing to accept OOB functionality Because of security issues, had to develop custom solution for

approver access Turned out to be more customized and less “reusable” than we had

hoped

Let’s Try Service Catalog Proposed using Service Catalog for application security

access requests instead of workflows in change module Needed to make do with limited resources

Only available resource was lacking technical knowledge of tailoring and change module

Didn’t want to interfere with workflow work currently underway by working in the same module

No available resources for training/mentoring so why not work on something that no one knew anything about

Anticipated Benefits Use Service Catalog approval engine to allow non-IT people to

perform approvals Document approvals Allow greater development flexibility than the workflows Reduce ambiguity in requests by having clients select exactly what

they want Route requests to the correct assignment group Ability to gather pertinent information from clients up front

Initial Challenges Learning Curve

Lack of technical knowledge and no internal resources available to help (Had to teach myself tailoring through ITRC forums)

Very little documentation available on Service Catalog

Customizations required right out of the gate Did not work OOB in our highly tailored environment Need to reference employees by personnel number not

name Require the PC of each Requested For

Struggled with approval design

FE Approval Requirement Challenges Non-IT users cannot be given access to Service

Manager except through the Catalog Have to protect regulated data from non-regulated people Cannot move the approval logic to the fulfillment module

Many approval requirements are regulatory requirements where the asset owner must approve, rather than an employee’s manager Clients cannot specify their own approver Have to get approvals for each item that requires

approvals—not just one approver for the whole cart Typically define multiple approvers so there is

always someone to act as a backup Approvers often defined on application CIs

OOB Service Catalog Approvals *Applies to SM 7.02* All approvals have to be done at the CART level—

even if approvals are defined on the items No approval designation capability Not really designed for use with approval groups

Geared more toward approvers being individual operators

All must approve or One must approve Complicated approvals should be handled in the

fulfillment module Can have approval groups but group must be defined on

the approver’s service profile (Service profiles are typically assigned to large categories of users)

If one approver denies, the whole request is denied

Typical FE Approval Scenario

Application A

Approval Group 1

HueyDeweyLouie

Approval Group 2DonaldDaisy

Approval Group 3

DonaldDaffy

Application B

Application C

Approvals – Round 1

Utilized approval groups specified in service profiles

Needed each operator to have their own service profile so approval groups could be assigned to individual operators

Created an approval role that would: Look up the approvers on the associated CI (The CI

was stored in the interface.info field of each catalog item.)

Dynamically create approval groups and update the approvers’ service profiles with the approval groups

Approvals – Round 2 Demo-ed to Service Desk Coordinator and a few others

Thought it was unclear to approvers why they were being asked to approve

Would prefer item-based approvals rather than cart level approvals but were willing to accept

Denial behavior was deemed unacceptable “Disabled” the ability to deny requests and added

instructions for removing items from the cart as an alternative to denying

Had completed work on major functionality and started to prepare to move to QA

Fatal blow – When operator accounts and service profiles were created for all users in the company, the number of service profiles caused some operations to crash

Approvals – Round 3 Decided to develop our own “approval engine” and have

item-based approvals, including “line-item” denials (deny one item without canceling the whole request)

When someone adds an item to their cart, the approvals for that item are calculated, and approval records are created in a custom item approval table Created a trigger on the svcCartItem table that calls javascript

When a request is submitted, it has a cart-level approval requirement that is conditional on all item-level approvals being completed Added a field to the interactions (incidents table) to indicate

whether there are items still pending approval

Approvals – Round 3 (cont.) Had to modify the Catalog security to allow approvers to

see the requests pending their approval Use stored query to retrieve requests pending approval instead of

Approval Inbox Added “Approve” and “Deny” buttons to the “View/Edit

Cart” screen that perform our custom approval logic Created display options that call javascript

Cart-level approval is re-evaluated after each item approval/denial and “removed” when no more items are pending approval

Denied items are automagically removed from the cart prior to the cart being submitted for fulfillment, but item approval records are retained for record-keeping

Timeline Started in March-April 2010 Demo that resulted in mixed reaction – August 2010 Round 2 for approvals and making additional adjustments

based on demo feedback – September 2010 Fatal blow for approval design – October 2010 “Derailed” by work on regulatory requirements and the

merger (and also short one team member) – October 2010 through March 2011

Developed new item-based approval design in “spare time” and had basic functionality fleshed out by March 2011

Started getting some additional development assistance – April 2011

QA Testing – May 2011 Item Creation – May 2011 Production Go-Live – June 2, 2011

Our Approach See if it works first

Spent most of our time getting the module to work the way we wanted it to

Focused on item creation after everything was functional and tested Start small and grow

Did not try to identify all services provided by IT Started with a handful of use cases for design purposes Rolled out to small sets of users first Currently working on items that will allow us to “advertise” the

Catalog to an enterprise-wide audience Use the Catalog as a front-end interface to our existing

back-end fulfillment process Using Change module for fulfillment

Catalog category structure was determined by development team to avoid lengthy process of political bickering

Success Stories Application access requests for “CReWS” (key work

management system in the “wires” area of our business) Previous process involved clients e-mailing a spreadsheet form to an

approver who then e-mailed it to the Service Desk who then created a change request for the IT group to grant access

Form incorporated into the catalog item Approvals handled in Service Catalog IT no longer has to verify approval Approvals documented for Sarbanes-Oxley evidence Service Desk no longer involved in the process

Merger opportunity Allegheny Energy had a catalog-like system for requesting PCs, PC

accessories, and desktop software that was going to be lost with the termination of an out-sourcing contract

Quick turn-around on item creation allowed us to use the Service Catalog to fill that gap

Lessons Learned Make sure the Catalog approval design will work with your

business requirements Much of Service Catalog is RAD-controlled so you might

not be able to tailor things you would expect to be able to tailor

All hail the power of Javascript! Thank you Forum contributors! Item creation is a fairly quick process if the item will fit the

existing structure (i.e. approval roles, connectors) What you might initially think of as a single item may need

to be broken up into multiple items Needs to be intuitive (Ask someone outside of IT. IT

people underestimate the average client.) Communication plan is critical for roll-out

Appendix

Service Catalog Under the Hood

If you are not OOB, you will need to make sure you have a way to populate your required fields for incidents and your fulfillment table (cm3r in this example).

Much of Service Catalog is RAD-controlled, so you may not be able to leverage format controls.

Item 1

Item 2

Item 3

svcCatalog

svcCart

svcCartItem

Interaction(incidents)

Change Change

CONNECTOR

FE Data Stored in svcCatalog interface.info