Some of the most powerful performance improvement approaches I have seen, and been involved in, are where front line team members are involved in identifying problems, designing solutions and then putting those solutions in place. Approaches like WorkOutTM, Kaizen and Problem Solving Team Building (PSTB) embody the philosophy that the best ideas on how to improve how work gets done will come from those actually doing the work.
As well as providing quantifiable improvements in performance, these approaches have the added benefit that they make front line team members feel more engaged with their organisation; they feel listened to, they feel they can affect their working lives and, when making improvements happen, they naturally feel a sense of achievement. This is why such performance improvement approaches are often the cornerstone of cultural change programmes because of the transformative effect they can have on people.
However, these types of front line performance improvement approaches tend to avoid any kind of solution that requires making changes to core business systems. Typical front line teams gathered to address a problem are unlikely to have the knowledge to suggest how core business systems (like an SAP) could be used as part of the solution. Those that do have any experience with these systems are likely to counsel against even thinking about suggesting changes because of the perceived difficulty and timescale required in getting changes made.
The problems with treating core business systems as a kind of untouchable black box are twofold:
This proposed solution certainly represented a big improvement over the process currently being used. However, it would have been possible to change the standard task list in SAP to reflect the current needs and also avoid the need for a separate spreadsheet, a type of working practice that introduces data control risks: version control, back-up, data security. It would also allow the system to be used to gather actual data on tasks complete for each job, allowing organisation wide analysis and reporting on maintenance activities.
Where the core business systems are bought into the ongoing performance improvement equation and not treated as unmovable constraint that has to be navigated around, I have seen organisations make dramatic improvements in the efficiency of their processes. The system starts to pay off its considerable investment and a virtuous circle is established whereby frontline teams help keep a system fit for purpose and in return free up time to work on further performance improvement activity.
As well as providing quantifiable improvements in performance, these approaches have the added benefit that they make front line team members feel more engaged with their organisation; they feel listened to, they feel they can affect their working lives and, when making improvements happen, they naturally feel a sense of achievement. This is why such performance improvement approaches are often the cornerstone of cultural change programmes because of the transformative effect they can have on people.
However, these types of front line performance improvement approaches tend to avoid any kind of solution that requires making changes to core business systems. Typical front line teams gathered to address a problem are unlikely to have the knowledge to suggest how core business systems (like an SAP) could be used as part of the solution. Those that do have any experience with these systems are likely to counsel against even thinking about suggesting changes because of the perceived difficulty and timescale required in getting changes made.
The problems with treating core business systems as a kind of untouchable black box are twofold:
- First is the obvious one that the organisation misses out on potentially useful changes to business systems
- Second is that performance improvement solutions can undermine the design intents of core business systems if they lead to separate lists, spreadsheets and databases being introduced to working practices. If information is maintained "off-system" that could and should be held on core systems then the often considerable investment made in business systems is undermined.
This can be illustrated with the following real life example from an equipment maintenance process. When creating a new job code for regular maintenance of a pump, the system, SAP in this case, had a pre-defined set of maintenance tasks for this particular type of pump. This task list was created when the system was first implemented. However, over time, various changes made the standard system generated task list insufficient. Health and safety requirements required far more detail on the site preparation and isolation tasks. The manufacturer had changed some of the standard maintenance tasks based on their experience of their product in use over hundreds of sites, adding some new steps and removing some of the old tasks. This meant that each time a job for maintaining this pump type was created, the maintenance supervisor had to manually add these additional tasks to the system printed job tasks list.
At a Kaizen event for this facility the maintenance team spotted this inefficiency and proposed a solution. A spreadsheet would be created with all the standard jobs that could be updated and maintained by the team. So when new maintenance jobs are created, a code would be created on SAP for capturing material costs and labor hours but the task list would come from the team's spreadsheet.
This proposed solution certainly represented a big improvement over the process currently being used. However, it would have been possible to change the standard task list in SAP to reflect the current needs and also avoid the need for a separate spreadsheet, a type of working practice that introduces data control risks: version control, back-up, data security. It would also allow the system to be used to gather actual data on tasks complete for each job, allowing organisation wide analysis and reporting on maintenance activities.
You can see that when looking at improving a team's performance treating the business systems as a an untouchable black box can inadvertently make the overall organisation less efficient. How do organisations avoid this way of thinking?
First step is to identify and train a cadre of front line leaders such that they understand how the core business system works. The level of knowledge they need to aspire to is on a par with a typical system implementation consultant. It is key that the people selected are from the business and that they are trained in the systems, not system experts brought in to learn about the business. The role will require trust of the front line teams, something much easier to achieve if they have the same background. This cadre of experts can be called upon by frontline teams when carrying out performance improvement activities to provide their views, suggesting where the system could help or the practicality of any proposed changes that would impact the systems. For this cadre of experts to be effective, however, they need to be given space in their regular duties schedule to take part in this kind of activity.
Second is that the management of the core business systems needs to plan for ongoing changes driven by the frontline performance improvement activities. This plan would utilize the cadre of frontline system experts as a means to filter such changes, as a sounding board in the design step and to participate in and co-ordinate system and user testing. So as well as managing the introduction of software updates from vendors, IT departments will need to manage the introduction of user driven configuration changes coming from performance improvement activities.
First step is to identify and train a cadre of front line leaders such that they understand how the core business system works. The level of knowledge they need to aspire to is on a par with a typical system implementation consultant. It is key that the people selected are from the business and that they are trained in the systems, not system experts brought in to learn about the business. The role will require trust of the front line teams, something much easier to achieve if they have the same background. This cadre of experts can be called upon by frontline teams when carrying out performance improvement activities to provide their views, suggesting where the system could help or the practicality of any proposed changes that would impact the systems. For this cadre of experts to be effective, however, they need to be given space in their regular duties schedule to take part in this kind of activity.
Second is that the management of the core business systems needs to plan for ongoing changes driven by the frontline performance improvement activities. This plan would utilize the cadre of frontline system experts as a means to filter such changes, as a sounding board in the design step and to participate in and co-ordinate system and user testing. So as well as managing the introduction of software updates from vendors, IT departments will need to manage the introduction of user driven configuration changes coming from performance improvement activities.
Where the core business systems are bought into the ongoing performance improvement equation and not treated as unmovable constraint that has to be navigated around, I have seen organisations make dramatic improvements in the efficiency of their processes. The system starts to pay off its considerable investment and a virtuous circle is established whereby frontline teams help keep a system fit for purpose and in return free up time to work on further performance improvement activity.
Comments
Post a Comment