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





Modules





Help Desk (call, incident)
Configuration Management
Change (used for Change and Request Management)
Service Catalog
Service Manager support staff



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
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
 Have to get approvals
their own approver
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
Approval Group 1
Application A
Application B
Huey
Dewey
Louie
Approval Group 2
Donald
Daisy
Approval Group 3
Application C
Donald
Daffy
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


Added “Approve” and “Deny” buttons to the “View/Edit
Cart” screen that perform our custom approval logic



Use stored query to retrieve requests pending approval instead of
Approval Inbox
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



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


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
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
svcCatalog
Item 1
svcCartItem
Item 2
Interaction
(incidents)
Item 3
svcCart
CONNECTOR


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 RADcontrolled, so you may not be able
to leverage format controls.
Change
Change
FE Data Stored in svcCatalog interface.info