As well as requirements gathering, a critical aspect of work BEFORE starting work on a new system is to understand the underlying business processes that people do on a daily basis, whether or not they are done in systems or on paper.
A timely reminder of this came yesterday, over lunch with a friend who owns a recruitment company. A key member of staff is soon leaving his organisation after many years and, when he took time to understand what she did, he discovered that a lot of her activity was re-keying information others had already input into another system and then manually processing paperwork with checklists to ensure she didn't miss anything.
He will now be able to automate most of her work with software that he already has, or new software that is very cheap to license, and will not need to replace her with a new member of staff, saving time and money, reducing errors and improving both candidate and client experience - WOW!
In an African Telecoms giant, it was possible to instantly remove $10m of unnecessary cost and waste from their operations through business process improvement, without impacting any of their systems! They had always worked in a particular way and this hadn't changed in years, by re-thinking this huge savings were made, costs were removed and obsolete equipment that was sitting on their shelves was quickly identified and sold off.
As previously mentioned in Requirements gathering, done properly, it is crucial to think in terms of People, Processes and Systems because it is the People who do interact with eachother and with the systems and if you don't consider the whole environment, then you will miss aspects. Moreover, if you simply ask people how they do things, then key aspects may get missed because they do these things very often and their familiarity means they no longer think in detail about precisely what they do.
It is also important not to assume that everyone does it the same way. In a large UK Telecoms company different teams doing essentially the same jobs operated differently, despite the fact that they all sat in the same room and had, at different times, worked in most of the other teams. Amazingly, one of the teams doing more complex operations had evolved a far more efficient process than the ones doing simpler versions of the same basic functions (possibly because they had to simplify it in order to cope), but this had not been shared with others! By capturing their processes in great detail, it was then possible to further improve them and to roll this way of working out to the other teams, making their jobs even faster and more efficient, with less potential for errors and improved customer satisfaction! This process improvement was done before the new IT system was implemented, which meant that the Change Management activity was almost seamless at cut-over.
In "Effective Communications at the start of a project" the concept of engaging staff in a dialogue to identify ways of improving systems and processes was covered in some detail and when it comes to business process, this is critical because the people who do it every day are also the ones who can often tell you how to do it more efficiently. This engagement process needs, however, to be facilitated because quite often solving a minor issue in one area causes further issues elsewhere that will not be obvious until the end-to-end process is analysed. Furthermore, simply asking the staff is often just scratching the surface because they are too close to it and can't think in fresh ways about how to simplify what they do and make things more efficient, as in the African Telco example above.
It is critical, therefore, to ensure that you consider processes not simply as a series of serial or parallel tasks but also in terms of:
It may be necessary to map the process as a flow and as "swim-lanes" and to have sub-processes to capture other aspects that happen elsewhere as part of the overall process. For instance, if the warehouse needs to ship a router to a client as part of supplying a new broadband circuit, then what is the process at the warehouse once they receive the order from the CRM system? Does somebody actually type out the address label from the details on their screen and stick it on the box, or is that label sent directly from the CRM system?
Once the end-to-end processes are understood in detail, these can be validated against the findings of the requirements gathering exercise and also analysed to find aspects that can be automated, done more efficiently, or completely removed to make things simpler, faster, cheaper and potentially improve employee and customer satisfaction.
As an example, I have recently received three deliveries in one day from Amazon.co.uk and also, on another occasion, received 4 items in 4 different boxes - I ordered four camping chairs and they each came in their own huge box, when all four would have fitted into one box! Now multiply these little irritations that I suffered by a business the size of theirs and imagine the potential savings from process improvement and consolidation!!
Again, impatience can have a huge impact on the quality and thoroughness of this activity and it is easy to see the potential consequences of not doing it properly, either in terms of completely missing a critical area or of missing out on a massive opportunity to improve how your company does business. Potentially, you could significantly diminish the benefits of a new system if the processes aren't correctly reflected in the new system and associated working practices.
The next article will be on Effective Communications during a Project.
A timely reminder of this came yesterday, over lunch with a friend who owns a recruitment company. A key member of staff is soon leaving his organisation after many years and, when he took time to understand what she did, he discovered that a lot of her activity was re-keying information others had already input into another system and then manually processing paperwork with checklists to ensure she didn't miss anything.
He will now be able to automate most of her work with software that he already has, or new software that is very cheap to license, and will not need to replace her with a new member of staff, saving time and money, reducing errors and improving both candidate and client experience - WOW!
In an African Telecoms giant, it was possible to instantly remove $10m of unnecessary cost and waste from their operations through business process improvement, without impacting any of their systems! They had always worked in a particular way and this hadn't changed in years, by re-thinking this huge savings were made, costs were removed and obsolete equipment that was sitting on their shelves was quickly identified and sold off.
As previously mentioned in Requirements gathering, done properly, it is crucial to think in terms of People, Processes and Systems because it is the People who do interact with eachother and with the systems and if you don't consider the whole environment, then you will miss aspects. Moreover, if you simply ask people how they do things, then key aspects may get missed because they do these things very often and their familiarity means they no longer think in detail about precisely what they do.
It is also important not to assume that everyone does it the same way. In a large UK Telecoms company different teams doing essentially the same jobs operated differently, despite the fact that they all sat in the same room and had, at different times, worked in most of the other teams. Amazingly, one of the teams doing more complex operations had evolved a far more efficient process than the ones doing simpler versions of the same basic functions (possibly because they had to simplify it in order to cope), but this had not been shared with others! By capturing their processes in great detail, it was then possible to further improve them and to roll this way of working out to the other teams, making their jobs even faster and more efficient, with less potential for errors and improved customer satisfaction! This process improvement was done before the new IT system was implemented, which meant that the Change Management activity was almost seamless at cut-over.
In "Effective Communications at the start of a project" the concept of engaging staff in a dialogue to identify ways of improving systems and processes was covered in some detail and when it comes to business process, this is critical because the people who do it every day are also the ones who can often tell you how to do it more efficiently. This engagement process needs, however, to be facilitated because quite often solving a minor issue in one area causes further issues elsewhere that will not be obvious until the end-to-end process is analysed. Furthermore, simply asking the staff is often just scratching the surface because they are too close to it and can't think in fresh ways about how to simplify what they do and make things more efficient, as in the African Telco example above.
It is critical, therefore, to ensure that you consider processes not simply as a series of serial or parallel tasks but also in terms of:
- Who does it (which machine, system, person, team or department)
- How they do it (is it manual or system based, is it automated),
- When they do it (what is the trigger event, is it a serial task or one of a number of parallel tasks),
- Why they do it (is it necessary)
- What they actually do
- What checks are there (that it has happened to time, quality, etc.) Who checks?
- What Escalations/Dependencies/Pre-requisites - if it doesn't happen or hasn't happened what are the impacts?
It may be necessary to map the process as a flow and as "swim-lanes" and to have sub-processes to capture other aspects that happen elsewhere as part of the overall process. For instance, if the warehouse needs to ship a router to a client as part of supplying a new broadband circuit, then what is the process at the warehouse once they receive the order from the CRM system? Does somebody actually type out the address label from the details on their screen and stick it on the box, or is that label sent directly from the CRM system?
Once the end-to-end processes are understood in detail, these can be validated against the findings of the requirements gathering exercise and also analysed to find aspects that can be automated, done more efficiently, or completely removed to make things simpler, faster, cheaper and potentially improve employee and customer satisfaction.
As an example, I have recently received three deliveries in one day from Amazon.co.uk and also, on another occasion, received 4 items in 4 different boxes - I ordered four camping chairs and they each came in their own huge box, when all four would have fitted into one box! Now multiply these little irritations that I suffered by a business the size of theirs and imagine the potential savings from process improvement and consolidation!!
Again, impatience can have a huge impact on the quality and thoroughness of this activity and it is easy to see the potential consequences of not doing it properly, either in terms of completely missing a critical area or of missing out on a massive opportunity to improve how your company does business. Potentially, you could significantly diminish the benefits of a new system if the processes aren't correctly reflected in the new system and associated working practices.
The next article will be on Effective Communications during a Project.
RSS Feed