Best practices in business automation application

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

In the first episode of the series, I talked about the automation imperative that’s driving organizations, 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 talked about best practices in strategic vision, namely making business automation a strategic direction and picking the right processes that will have the maximum impact. Then, in the last three episodes, I looked at best practices in the design of business automation, covering metrics, understanding your process (understanding what to automate and what not to automate) and finishing up with a session on design anti-patterns. So you can go back and review those earlier episodes if you haven’t already watched them. Today, I’m going to be wrapping up the series with some best practices in implementation methodology for business automation.

Best Practices In Implementation Methodology For Business Automation

Now, using an agile approach for implementing software projects isn’t unique to business automation, but they are particularly well suited to each other. Today’s business automation tools are usually model driven and low-code, so that you’re able to at least get a workable prototype up and running without writing much if any code. That doesn’t mean there will be no code, since you may have parts of the system such as integrations or specialized algorithms that require traditional coding techniques.

However, agile techniques combined with model driven low-code tools means that you can quickly get a working version in the hands of a group of business users, and let them beat it up. And that speed from idea to working system enables the first best practice in implementation: get a minimum viable product rolled out into production, as soon as possible, then iterate in place. Now, I’m showing this popular graphic, created by Henrik Nieberg several years ago, illustrating how to think about MVP, and you can follow the link in this QR code to read his excellent article discussing the concepts in detail. You might find it useful if you ever need to explain the concepts of minimum viable product and iterative implementation to others in your organization.

Now, you don’t want to be in the position of taking months to perfect your system, deploy it to the business, and then have them tear to shreds on the first day, so instead, you get it to them much earlier in the development cycle. So, when they tear to shreds as they inevitably will, you haven’t invested so much effort in that first version that you’re resistant to their ideas. Then you iterate until there’s a consensus on how this system should look and behave.

That’s not something that’s going to be possible if you’re stuck in old waterfall methodologies. With waterfall, you’ll be three months just writing requirements documents, plus time to get the business to sign off on them, since you’re forcing them to decide what they want months before they’ll actually see it. Then, another six months or so writing and signing off on design documents then a lengthy implementation cycle, just to roll out a system that is almost guaranteed to not be what the business actually wants or needs. If a project is taking too long and is far over budget, take a look at the implementation methodology and you’ll probably find waterfall.

Now, waterfall methodologies work fine for specific types of implementation, such as technical integrations where you’re writing code that will connect to systems using standard protocols. Where waterfall doesn’t work all that well is whenever there are business people who are going to interact closely with the software in their day-to-day operations. Which is of course A lot of the time. Now, if there was ever a way to convince your organization to adopt agile or agile-like implementation methodologies, you want to show them the power and flexibility of model driven low-code tools in order to do that. So whip up a quick prototype in a couple of days, it doesn’t have to be operational, and show it to people, get some feedback, change it, show them another version later the same week. They’ll get the idea that implementation can be iteratives and also collaborative between business and development. And that is what will maximize the probability of success.

Now, this requires a pretty close connection between your implementation team and your business. It doesn’t mean that you can’t outsource implementation or that your developers can’t be in other locations, but it does mean that they need to work closely with the business as a team, deploy frequent iterations, and then be able to quickly integrate feedback into the implementation cycle. So, if there aren’t daily conversations between someone in the business and someone on the implementation team, you’re probably not connected as closely as you need to be. This also means that the business needs to trust the implementation team when they say that the MVP delivery is part of the process and not a final delivery.

Too many users have been burned by being stuck with version 1.0 of an implementation, while the dev team is shunted off to the next project. That’s how we end up in these lengthy waterfall cycles of requirements and design documents, and in fact, Nieberg suggests using a different term rather than MVP, such as earliest usable product, which implies that this is the earliest of many releases, rather than a final delivery.

Now, the other best practice in business automation implementation that I want to talk about, is being ready and able to pivot. This is not just a matter of changing little things on the user interface so that the business likes it better, or creating a new API to extract data from a legacy system. I’m talking about radical change in direction or functionality once the business sees that first iteration and decides that you need to go down a different path. Sometimes because it’s the business’s first real exposure to the capabilities of the business automation tools, and the flexibility of a low-code approach, they just didn’t even know that some of these things were possible. Then they look at their first iteration, they scratch their heads and then they say: “Hey, couldn’t we completely automate this part of the process?” or “Would changing this allow us to use remote workers for certain human steps?” or “Can machine learning be used to auto-adjudicate these decisions?” or “Can we integrate this functionality into our customer portal for self-service?”. You get the idea.

Now, Nieberg’s article had a great little graphic to illustrate that point. What if you were busy implementing the car by way of skateboard and bicycle as your iterative steps, but figured out they would really be better served by taking a bus? Think of it as radical re-engineering of the business process driven by the business.

Now, business goals usually align with two high-level corporate metrics: net revenue and customer satisfaction. To achieve these, the business is going to be looking for more automation, more accurate and efficient processes, appropriate levels of customer self-service and occasionally a completely different way of serving your customers, or a completely new business model in order to provide services. Now, a smart business analyst who’s well versed in the business and the automation tools should be suggesting that type of different functionality early on, but if not, then when that first version is put in front of the business, be prepared to pivot.

That’s all for today. I’ll be back next time with something completely different, now that we’ve wrapped up this series on best practices in business automation projects.

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.