1. FirstEnergy’s Service Catalog Journey Presented To: Vivit Service Manager User Group Presented By: Kristi Bledsoe Presented On: October 6, 2011

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. Typical FE Approval Scenario Application A Approval Group 1 Huey Dewey Louie Approval Group 2 Donald Daisy Approval Group 3 Donald Daffy Application B Application C

11. 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

13. 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

14. 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

15. 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

18. 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

19. 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

20. 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

21. 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

22. Appendix

23. 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 CONNECTOR

24. FE Data Stored in svcCatalog interface.info