The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.
– Bill Gates
IT projects are as much about people as anything else. Projects are generally started with a notion of making things better. But what is better? Maybe it’s to do more with less, or do things faster, or do more but with fixed resources. These all point to a desire for efficiency.
To achieve efficiency people need to be removed from the process, business rules need to replace human decisions and input. Capturing, writing, designing, building and testing hundreds of business rules is a big task but can be done, the risk of missing a rule, or a bug appearing once live with a system is not acceptable though. The simpler the process being automated the easier the project will be and the more robust the system will be, and by minimising the human touch points required the more scalable the solution will be.
IT projects need to analyse processes and not simply automate what is already there. This is where I think the quality of the current state analysis is critical, it really sets up the rest of the analysis work.
These are the typical questions I like to ask of my current state analysis. If my analysis does not answer these questions then I go back and get the answers.
- Can we do without the process completely
- What is the impact of not changing the process
- How does it affect processes either before (upstream)or after the process(downstream)
- How can manual intervention be automated
- Is the process covering for problems initiated upstream in a different process or team.
- Is the process something that should be done elsewhere
- Look for duplicate processes elsewhere, in other teams
- Within a process I look for the same thing being touched more than once
- Too many checkpoints or breakpoints that will no longer be required if automated
- I check for hand off points between the system and users, and question why they are there
Once I have found the business areas that would benefit from change I then start to develop and present proposals. When making proposals I consider the potential for resistance. For example I may need to challenge statements like ” but we always do it that way” or I may need to challenge assumptions like ” oh they won’t change” or “they won’t like that”. In these situations I find the best approach is to put together a case beforehand, never start conversations without all the information possible to hand, challenge assumptions with the facts !