Business automation best practices

Hi, I’m Sandy Kemsley of column2.com. I’m here for the Trisotech blog with the fifth in a series on best practices in business automation application development.

In the first episode I talked about the automation imperative that is driving all organizations to automate. There’s a lot of new technology that lets us automate things that were never possible before and you need to be considering it or risk losing your competitive edge. In the second episode I examined best practices in strategic vision, including making business automation a strategic direction and picking the right processes to automate that will have the maximum impact. Then in the last two episodes, I looked at Best Practices in the design of business automation, covering metrics understanding your processes and understanding what to automate and what not to automate. Now, you can go back and review those earlier episodes if you haven’t watched them already.

In this video, I’m continuing on with best practices in the design of business automation by talking about the worst practices, in other words, some common anti-patterns that we see in business automation design.

Before you ever get your business automation project rolled out, there are some red flags that you can see during the requirements and design phase. And even in an Agile development environment where you’re doing this in more of an iterative fashion these design flaws can have far-reaching effects.

types of anti-patterns

Now, there are a couple of different types of anti-patterns that we see in process automation design.

1 First there are those that originate at the interface between the business people and the business analyst. And the most common one that I see, is designing and building what the business asks for rather than what they need. Now, I know the business is supposed to be a fully fledged participant in the design process, but in reality business people spend most of their time running the business and don’t necessarily have the time to learn what the technology is capable of or how to improve their processes using that technology. They’re not analysts they’re business specialists. Now, a business analyst, on the other hand, has three jobs:

• They have to be able to analyze the current and future state of the business.
• They need to know enough about the technology to understand how to use it to make transformative changes in business processes. So improvements, but also ways in which you can totally transform the business processes.
• They have to know how to sell those ideas to the business because it could be that the business hadn’t thought about doing things that way and need a little bit of encouragement to be able to see this possible future.

Now, if the business analyst doesn’t understand the capabilities of the technologies involved that’s another problem. But the more common situation is that the business analyst is instructed to just do what the business wants. Now, you know what the business doesn’t want? A failed project that doesn’t improve their business and it’s the Analyst job then to push back to the root of the business requirements and help map that into the automation of the processes in the best possible way using the technology at hand.

Now with a fully Agile development cycle, which by the way almost never happens, you can theoretically iterate your way from what they said they wanted to what they need. But there’s a lot more to it than just the technical ability to quickly modify automated processes and applications. All of this requires an equal collaboration between the subject matter experts from the business and the business analysts. If the business side is too strong, then the analyst is just a scribe but that documents the business requests. If the analyst is in charge, then likely some critical parts of the business process that they don’t fully understand will be overlooked. Balance of power is important.

Now, the problem of implementing what the business asks for often manifests as a system that paves the cow paths of the old processes and procedures. The new system does exactly what the manual processes do, without considering how the technology could have improved or automated them. A lot of money is wasted to have tasks pushed around amongst the business people a little bit faster. Now, although you don’t want to just throw away all the old knowledge and start with a completely Green Field, you do need to validate that the things that the business says are important, are in fact necessary and sufficient for the current operating standard procedures.

2 The second type of any pattern that I see in process automation design happens when we start to loop in the technical designers. Many complex process automation systems require more of a developer in this role than the business analyst so they might not be as close to the business requirements. And what this happens, we can end up with a misalignment between frequently changing business conditions and the implementation technology.

To understand this, you need to think about the technical characteristics of the system that you’re using for process automation. Typically business process automation systems — or BPMS — are stateful. They maintain state for each process instance as long as it lives.

Included in that state is usually a snapshot of the process model at the time that the instance was created. Changing and redeploying a new process model only changes the model for instances that are created after that point in time, not the ones that are already in process. There are ways in some systems to convert existing instances but, it can be a bit of a hack and it’s not something you want to be doing every day in your production system.

Now decision management systems, on the other hand, are typically stateless. You call them at a point in time, you pass them some data, they make a decision and they return the results. So, if you make a change to a business decision, the most current decision will be invoked at the time that it’s called, if that’s the one you want unless there’s a reason you want to call the old one.

You can change decisions as often as you want and they will take effect immediately, and in fact a lot of organizations put some of the decision tables directly in the control of the business so that they can change parameters on the fly like what percentage of things go to QA at any particular time of the day, based on volumes of inbound transactions that you might have.

A necessary part of the early design requirements is understanding what parts of the business process are changeable and what parts tend to be more fixed and unlikely to change very much. Then make sure that you’ve designed appropriately to allow for flexibility while still maintaining clean designs that are understandable to the business. Whatever’s done on the drawing board, whatever this is, you can be sure it will not be right the first time around and that’s okay.

So, just as military wisdom tells us that no battle plan survives first contact with the enemy, I’ve seen many times over that no system design survives first contact with the end users. The key is to recognize the anti-patterns of bad design practices early, and use that to create flexible automations that you can correct iteratively as you go along.

That’s all for today. Next time I’ll wrap up the series with an episode on best practices in implementation methodologies for business automation.

You can find more of my writing and videos on the Trisotech blog or on my own blog at column2.com. See you next time.