Have a written process flow
Before you can have something automated, you will need to have something to automate! You can usually get this from the operations manuals of your different departments. This would usually be the basis of how your workflow will be automated. If you do not have an operations manual written down, take time to do it. If you do have an operations manual, make sure it is updated to reflect the current processes. This will save you a lot of headaches in the long run.
Nothing is perfect
Before you plan out that foolproof, 100 percent, all encompassing system that thinks for itself, think again. Like reality, nothing is perfect. This applies to technology as well. A lot of projects get delayed because the users or manager refuse to use it until it is perfect, or there is “one more thing to add”. That is like building a house and refusing to live in it until it is absolutely set up with absolutely no cracks in the floor, leaks in the roof, no ants inside, etc! Most of the time, automating 80 percent of the workflow gives enough benefits to improve overall productivity. The remaining 20 percent is just for garnishing.
Computers can’t think
As much as we want all our workload to be done with just a press of a button, it can not be done yet. Technology is best for speeding up things and avoiding repetitive tasks. It is a tool to make your work faster so you can do other things; it will not think for you. If some systems do appear to think, it is because it has been fed a lot of information to properly make its decision, and this information comes from, guess who, you! The more you want it to be automated, the more you have to think, before the programming starts.
Plan for the whole system, but develop and implement separately
Some companies attempt to automate their workflow using the “Big Bang” approach — this means automating everything and trying to implement at a single target date. Unless you are a really, really large corporation with a lot of resources, or your whole workflow is really, really simple, this does not work most of the time. Also, most companies will not be able to afford the downtime of migrating to a new system simultaneously. A more practical approach would be to “divide and conquer” the project into phases based on either areas of functionality or by department involved. This will let you focus more on the success of each phase and will provide minimal disruption to the existing workflow.
Return to Resources
home | resources | services | contact us