BPMS Improvement

Project: SRM Improvement

Good day! This is the first of many blog entries about past projects I have been involved with. These entries will be my take on building a portfolio of work. They will be following the STAR structure. This project is concerning an improvement of the Service Request Management (SRM) (Service Catalog) System.

Synopsis

Situation

We started migrating ITSM Application Suites from a customized version of Remedy ARS to a customized version of Remedy 7.6. I was working on the third full ITO (IT Outsourcing) project utilizing Remedy 7.6. At this point in time, the Transition Operations Procedure Project – which I will discuss in a later blog – had not kicked off yet. This means we were still executing projects based on the much older Remedy ARS way.

Within Remedy ARS, requests were simplistic, meaning no dynamic workflow, and needed to be duplicated per account. For example, if the Content Filtering group had five standard requests and they supported 30 customers, they would have 150 separate requests. So, if you had to make one minuscule change to the ‘whitelist add’ request, you would have to do this 30 times. This resulted in thousands of request forms. A lot of times those 30 updates did not occur, so not all requests were the same per account.

Our thought process (or at least what I think it should be) as an IT Outsourcer, is to utilize leverage teams (one team supporting multiple customers) and utilize proven standards and processes that support that business. We are the “experts”. This is how the customer saves money while at the same time increasing IT service delivery.

Working with one of the tool admins, I discovered that Remedy 7.6 had a “Global” account which could be utilized like a parent account and activate certain items for certain customers. I pitched an idea to the necessary stakeholders: “If we build out and enforce standard workflows, we can reduce transition manpower by at least two FTEs (full-time employees) and save three to six months on that task.” The pitch was approved, and I chartered and led a team to do just that.

Task

We worked with 37 service delivery towers such as Information Security, Data Center, Back-up, Storage, Network, and so forth, for this project. The task was to understand the thousands of request workflows in Remedy ARS and which ones were the most up to date and could be standardized. Once we had the standards in place, the next step was to consolidate workflows based on Remedy 7.6 dynamic workflow functionality.

Action

Through this exercise, we came up with a total of 579 request workflows. Once we had that list, we then looked at what could be consolidated. As an example, we had a lot of requests across the majority of the towers that were ‘create’, ‘modify’, and ‘delete’. These were three requests that had very similar end-user questions and very similar back-end workflows. So, we started consolidation with these types of requests first. We kept track and created mappings for consolidation per tower. This way we could answer the question: “This is the request I used in ARS; which one do I use for 7.6?” These new, dynamic workflows were created in the ‘Global’ account, allowing any entitled customer to utilize them. Basically, during a transition project, we could flip a proverbial switch and activate all the requests needed in less than a day.

Results

Once those workflows were created, I created process and procedures for Transitions to implement within the customers’ environment. I also put in place an approval process for Operations to update these workflows. We started off with thousands of requests. After standards were identified, there were 579 workflows that we were working with. We were able to consolidate down to 248 workflows. From standards to consolidation, we reduced the number of workflows by 43%! Moving forward, duplication across accounts was removed. Reporting capabilities improved and leveraged teams could see across all accounts.

Unfortunately, we did have to move the end date out a few times due to the project being a revolving door for resources. In comparison to active customer transition projects, this project was a lower priority. To combat this, the project schedule would shift to accommodate services that were being implemented on those customer projects. Doing this also gave us an opportunity to utilize the resources working on that customer project to assist with the service workflows they needed for their customer.

I enjoyed this project; it made a huge impact on our transition and migration projects. I worked with a great team that gave it their all the entire time. We learned so much about this tool’s capabilities, and because of that, it was a huge benefit for the customer projects moving forward.

 

 

 

Thank you for your time,

Volume 7 Issue 7 (30) 
Original Post: 08/27/2016 
Updated: 08/27/2016
Posted in Project Portfolio and tagged , , , , , , , , , , , .

My mission is to lead strategically by SHEPARD-ING: guide and motivate teams in best practice adoption, positive change, and continual improvement through authentic servant leadership, creativity, and mentorship.

Digital Service Management Leader & Practice Owner passionate about Continual Improvement | MBA, IT Management | ITIL 4 Managing Professional | PMP