background shadow

Case Study – Financial Power Uses APM To Improve Network Ops Quality

A large Eastern financial company's Network Operations department had a quality problem. Staff members prided themselves on responding quickly and doing projects quickly, but frequently the work was done so quickly that it was not done correctly and had to be redone yet again.

While technicians could be trained on how management wanted a certain type of project performed, management had no idea if the projects were actually being done that way. They did not know how long each person took to do each task, so they had no way of knowing whether training would help. In addition, communication and good reporting were lacking. The QA Manager, for example, learned about a project that needed reworking three days after it had initially been completed.

Several years ago, Network Operations had developed a well-thought-out project management system using BMC's Remedy Action Request System (ARS). The project management system tracked important asset data and moved from person to person with changes of status. The system, however, lacked the flexibility needed to add or remove tasks from the defined process for a specific project type. Dates were not tracked, and work time was not tracked. There was no approval process of the plan for each project, and more communication was needed. Weekly, high-level project information was sent to a secretary who put the information into Microsoft Project , but this did not provide the necessary detail and was not current. Projects were not categorized by type, so management could not get metrics on how long a certain type of task took, nor how long a certain type of task took for each person. No "actual vs. planned cost" information was available.

Management had been working on a Six Sigma quality improvement program for some time. When they saw ActionProgram Manager, they quickly realized that it could be the basis of this program. With it, they could implement their Six Sigma program faster than with any other alternative. Another major advantage was the company's familiarity with the AR System. Technicians (i.e., users) were familiar with the AR System client, so this large learning curve had already been completed. AR administrators could customize the application. Management's investment in licenses and their AR environment could be leveraged, and APM could be added to the existing AR environment quickly.

While implementing APM, management required several customizations. One linked APM tasks to the asset data. The idea was "from one form in one sitting, a technician could enter his or her time against a task, status the task, and update the asset information." Fields were added to the APM:Projects form so that projects could be categorized correctly. Labels were changed to be consistent with the company's terminology, reducing the learning curve and implementation time.

Management also defined templates for each type of project, communicating to the technicians how the project should be worked. The plan for a particular project could be customized as necessary during the planning phase. A feature was added so that a project could be divided into segments. Templates could be defined for each segment and then connected together to form a project. An approval task was defined as the last task in each segment, so as the project was being worked, one part had to be approved by the right person before the technician could proceed to the next segment.

If you'd like to discuss these issues or if you have similar questions, please call Stan Feinstein at 310-230-1722.