How I automate processes

Greetings, traveller! - World of Warcraft MMORPG

People often ask me how to start automatization of business-processes at their respective companies. There is no real one algorythm to it since every case is different and requires thorough analysis, but there are basic guidelines that I use. Today I would like to share those guidelines.

First things first, define business processes that need to be automated (from hereon I will refer to automation as a process of providing software solution to meet specific needs of end users). Try to describe each process as it is before automation, the way it is run and how people work in those processes. Make a graph, an workflow of all the processes that need study. Make sure you have entire image and nothing is left unnoticed.

Second, define documents. Most of the time, particularly in my country, documents are the record of some action or event that has happened in a business process. Whether you are requiring some information from other department or just notifying others of some actions you made or going to make, you make a document.

So you need to study the documents lifecycle and find out - at which point of your business-process graph do these documents appear. It is also important to understand that some documents (i.e. deals with clients) appear in one process, but to complete them, they go through several business processes. So, often, documents are created in one process, and finished at some other process. Look at a document as a set of fields in a table, a key-value table, with some static text and some dynamic parts. What you need to know at this stage is to find out and clearify, at which point do these fields get filled out. Here is an example of what I mean. Let's say I work at the bank as a manager and I'm preparing a loan deal for our client. First, client fills out his part of information on the loan agreement document. Then, our legal department fill out some other parts of this document. In the end, Head of our bank signs the document. So, in this simple example, document went through three different stages, and in those three stages, several parts of the document were filled out. You need to identify those fields in every document and mark them on your business-process graph.

Fourth step is to identify algorythm of how you can automate those business-processes. In other words, you need to find the balance between which parts of business processes will be carried out by software applications, and which parts you will leave as is. The reason for this step is that you don't want to grow your software into a big monster beforehand, try to start from automating the core of the processes, and you can add the details and small parts later. You want to provide a software solution of some sort that gets most of the main job done, and you can polish it later, when you have time and have some results to work with. If you start with a huge area to automate you have a risk of either not meeting the time requirements, losing the big image in the process of work and get distracted on details, or simply grow everybody tired of your work. Whereas, if you start from simple but important things, you can show early results, do early testing and find mistakes that you may have made during previous steps, and also, you can then extend the deadlines or make a version 2 of your software. Your clients, end users, once they can see some of your work, it will be easier for them to decide whether to give you the time you need, or to leave the software as is. In my experience clients have always grown natural interest in my work and wanted me to keep going with growing the software bigger and grabbing a much wider range of processes to automate.

Step five is starting the development. You have the image of what needs to be automated. You have every event and action marked as a set of documents on your roadmap of processes. You have the idea of how the first version of the software needs to be done. Now its time to start developing. Make sure that if you have a group of developers - everybody understands the point of development of his part. They all need to know the bigger picture so they can use tools for development that suit best for your needs, and also at the same time leaves your software out of junk extra functions that noone will use, or repeating fuctions within different areas of development. Avoid duplicating work.

Next step is testing. Lots of testing. After almost every important part of software (most of the time it is once you finish every business process in the chain in your map) do the testing. Make a group of sophisticated adequate users who will be doing the testing. Do not ask every employee at the company to test the software. You will get distracted by their reviews. Make a focus group of testers who understand the point of software, who knows business processes and the tasks that need to be autmated. Work with this group. Make sure that your application runs as it should to meet their needs. Try to find out mistakes (not bugs) that were made in business-processes. Your application must copy the business process workflow.

Once you've finished development of version one, do the presentation. Release first version for testing to every employee whose processes are involved. Start working on next version or next project. Make sure that you provide software support. Tech support. Phone support. 24/7. People will call you and ask you questions. They will start with stupid ones. Then they will learn and start asking questions answers to which are not so obvious. And in the end, they will stop asking questions and start asking for next versions where they will specify which functions they would like to see in the next version. That means you have finished your project (at least version 1) well done.

p.s.: if you find some typos please leave a comment or contact me via LinkedIn.