Part of why I love IT is finding patterns and creating new ones. Patterns by themselves are interesting, but when you’re able to automate a pattern that’s when you start to really deliver value to a business. The result of that work is what I call process, and it might range from a batch file to a multi step SQL Agent job to a full fledged workflow spread across many machines and employees.

The goal of process isn’t to reduce the number of employees by taking work away from. That can happen in some cases, but most of the time the goal is to let employees do work that requires a human and let machines do the work that can be described in code. Automating has benefits beyond just saving time for employees, it’s a way of making it repeatable – something that often has a lot more value than the time saved.

Not all processes require code. Most do in our world, but there are plenty of times when a process is still required.Take annual reviews, or a homeowners association election for example. Both can benefit from a written series of steps so that everyone understands how it should be done and how to do it.

I suspect you appreciate the power of identifying and solidifying patterns. So where does the pain arise? It’s got a few flavors:

• Processes are rarely documented well. Businesses grow to rely on them and months or years later when something goes wrong it becomes archaeology to figure out why and how to fix them.
• Builders of the processes either focus too heavily on edge cases, or not at all. Focus too much on exceptions and you take a 3 step job and turn it into an application. Focus too little on exceptions and you get a process that breaks easily and usually gets patches and re-patched every time it fails.
• Every person has a different technique for automation. I just worked on one that involved an external hard drive, a Mac, two packages, multiple views, and a generated batch file that required manual edits. It works, and works well enough, it’s just not the way I would have done it!

Another part of the pain comes from dealing with changes or unplanned for exception past the initial build. When is ok to change the pattern? To decide that a pattern is more pain than productivity? How do you get consensus? How do you test the changes in a time effective manner?

In the next post I’ll talk about some details around building and documenting (or not) processes.