Process Improvement – An Example

This is a simplified real-life example of a process improvement that I recently made – from start to finish. It illustrates how I took a previously poor process, and came up with, and delivered, a creative and robust solution.

1. Understand the scope of the issue

The first step was to understand the problem.

The Helpdesk for finance systems had a process in place that was intended to control any incidents. These were problems that users of the finance systems encountered while they were using any the systems. These issues the needed to tracked through to resolution. This was important because any problems with finance systems, if left unresolved, could lead to errors and mis-statements in the financial reporting. As such, this process was the subject of a monthly SOX control sign off.

The process was cumbersome and took up a lot of operational and managerial time each month. All individual user incidents were being recorded on a number of systems, leading to duplication and confusion. At the end of each month, these multiple systems were attempted to be reconciled into a monthly report which was subject to management sign off. But given the cumbersome nature of the records, that sign-off was itself cumbersome and took up a lot of managerial time.

2. Map the As-Is Process

The next step was to understand and document the current process.

I sat with the Helpdesk staff and mapped the process as shown in Figure 1. It is at a fairly summarised level, so that I could easily visualise it.

Figure 1 – The As-Is process for recording an Incident

  • Users facing problems with the finance systems raised calls with the Helpdesk.
  • If the Helpdesk decided that that the user’s problem was a real issue with the system, they would raise a call on an IT Incident Management System,
  • and also manually added them to on an access-based Call Log,
  • and also manually listed them on an Incidents spreadsheet.
  • IT then investigated and resolved the incident, and communicated this back to the Helpdesk.
  • The Helpdesk advised the user the issue was fixed,
  • And updated the Call Log and the Incidents spreadsheet.

Figure 2 shows the month end SOX process for ensuring all incidents have been properly managed.

Figure 2 – The As-Is month end process for reporting on Incidents

  • At the end of each month the Helpdesk staff attempted to reconcile the number of opened and closed incidents across the three systems – the IT Incident Management System, the Helpdesk’s own Call Log, and the Incident spreadsheet.
  • Users were then contacted to validate whether the incidents had actually been resolved or not.
  • The current status of all incidents was compiled into a report for management to sign-off as a SOX control.

3. Understand the outputs/reports/requirements

So, the required output was the need to show that all incidents had been properly followed up to resolution. This would be evidenced by the monthly SOX Control, monitored by the Risk Team.

4. Understand the source data/inputs

The data being used to produce the monthly SOX control report was being taken from the manual incident spreadsheet. There was a convoluted attempt to reconcile to the records in the Call Log and to the IT Incident Management System.

Analysing historical records of prior incidents, I found numerous examples of inconsistencies between all three though. Clearly the process of needing to keep manual records was not fit for purpose, and a better, more robust solution would be needed.

An alternative could have been to use records from the Call Log EUC for monthly reporting. But the call logging itself also relied on manual update to a large extent, and the access database EUC would need to be amended to capture all the necessary data.

So how about the IT Incident Management System? I saw that, in attempting to reconcile the records, the team were using a basic report drawn from that system. The IT Incident Management System was designed to do what it says – manage and control IT Incidents. Maybe using the data in this system would allow me to design a better process …

5. Design an improved solution

Could I remove the need to keep manual records on the Incident spreadsheet, and extract the data instead from the IT Incident Management System?

I had managed to gain read access to the system, so I started investigating its reporting capacity. There was not a great deal of SME support for the system in the business for me to call on, but I worked out how to write the code to extract and filter the data relating to open and closed incidents for the Finance Systems Helpdesk team. This data would be a lot more robust and reliable than any manually kept records, as it came from an automatically controlled management system.

I was therefore able to design a process whereby the manual Incident spreadsheet was scrapped, and I wrote a template piece of code to allow the relevant data to be extracted monthly from the IT Incident Management System and fed directly into monthly SOX reporting. Figure 3 shows the effect of this simplification. Figure 4 shows my more detailed design map for the monthly SOX control reporting to make use of the extracted data.

Figure 3 – The To-Be month end process for reporting on Incidents

Figure 4 – The To-Be monthly reporting model

6. Design good controls

As I have said, extracting the data direct from the IT Incident Management system meant that the data was now subject to the controls already inbuilt within that system.

Code would be needed each month to specify which records to extract, based on relevant dates, whether incidents were open or closed, and who was manning the Helpdesk. Writing a VBA macro to automate this code would remove the risk of the wrong records being extracted.

Additionally, if the monthly reporting process included a report of the filters and criteria used to extract the data, this would give comfort that the correct data was being extracted.

Writing VBA macros to automate reconciliation with prior month’s reporting, and to actually produce the month end report, ready for sign off, would again reduce room for errors.

7. Mock-up the solution

Once I had designed my solution and made sure it was appropriately controlled, I could start to quickly mock-up how the solution would work.

I worked out the code syntax for extracting the right data from the IT Incident Management system, and tested that it would return all the data needed.

I designed the reporting spreadsheet. I used good design principles to make sure it was efficient and effective. It would have all the user input on one sheet, with the output and control reports on separate sheets. User instructions, process map, and troubleshooting guide would be included.

Finally, a quick simplified partial build of the Excel VBA macros was useful to give a demonstration to others of the benefits the automation would bring.

8. Get Buy in for the improved solution

I now needed to sell my solution to the owners of the process, and also to the Risk team, as custodians of the SOX control.

I wrote a small PowerPoint presentation detailing 1. the problems with the current manual record keeping, and 2. how and why my solution would solve these.

Only once I had received their formal approval, could I commit the time needed to build the solution.

9. Build the solution

Once I had their sign-off for the solution, I carried on and built the solution as planned. The time effort was in writing the excel VBA code and then testing it.

10. Deliver the solution – documented and supported.

Once I had a robust fully tested process, and the users had signed off that they were happy with it, it was delivered successfully into live.

This process improvement had the effect of delivering far more effectiveness to this vital SOX Control. It also saved in excess of three working days team effort each month and at least one day of senior management’s time signing off and supporting the control.

So that’s it. Some of the thoughts behind how I took a broken process and made it good.