Hi, I’m Sandy Kemsley of column2.com. I’m here for the Trisotech blog with a new topic now that we’ve finished my series on best practices in business automation application development. Today, I’m going to talk about future proofing your business with process automation technologies such as BPM.

Now, a little over three years ago, everything was business as usual. Organizations were focused on new competitors, new business models, new regulations, but it wasn’t a particularly disruptive time. Then the pandemic happened, and that was disruptive! So, supply chains, customers, business models, everything changed dramatically in some cases.

Now, that’s not news of course not by now, but it’s become obvious that it’s not enough to have shifted to some new way of doing things in a response to a one-time event. Companies have to become more easily adaptable to frequent disruptions, whether they’re technological, societal or environmental, or they’re just not going to exist anymore. In many cases this means modernizing the very technological infrastructure that supports businesses.

So how is your business going to adopt a change? Both the changes that have already happened and the unknown changes in the future? There’s a lot that falls under the umbrella of modernization, and you need to look at whether you’re doing just enough to survive or if you’re taking advantage of this disruption to thrive and actually outgrow your competition.

I see three ways that companies have been reacting to disruption:

more than
managing your business processes

So I mentioned BPM, but this is about more than just managing your business processes. There’s a wide variety of technologies that come into play here and that really support future proofing of your business: process and decision automation, intelligent analysis with machine learning and AI, content and capture, customer interactions with intelligent chatbots, and Cloud infrastructure for Access anywhere anytime…

So you have to look at how to bring all of those together, and just understanding how all those fit, is like an entire day’s lecture all in one, but you probably have a bunch of those that you’re using already. Let’s look at a few kind of examples of this support/improve/innovate spectrum that I’ve been talking about though and we’re dealing with instruction and then just what it means for future proofing your business. So, supporting your existing business, a matter of just doing what you can to survive, and hoping that either you can keep up or that things will go back to normal. Now basically you’re doing the same business that you always were, but with maybe a bit of new technology to support some new ways of doing things:

• Your employees might be working from home so you needed some new Cloud technology or Network Technology to help with this.
• You probably also need some new management techniques, in order to stay productive and motivated even though your your Workforce is highly distributed geographically.
• You also need to handle changing customer expectations. So you have to have some amount of digital interactions and if you’re dealing with physical goods you might be looking at new ways of handling delivery.
• Your supply chain processes need to become flexible, this is one of the things that we really saw during the pandemic is there were a lot of broken supply chains, so you want to be able to change suppliers or change other channels in the event of disruption.

But let’s just go a little bit beyond surviving disruption that you might do by sort of mandating together something to support your existing model. The next step to is to look at disruption as an opportunity to thrive. So you want to still be in the same business but embrace new technologies and new ways of doing things. So this really pushes further into looking at customer expectations: adding in self-serve options if you don’t already have them, and then coupling that with intelligent automation of processes and decisions. So, once you’ve added intelligence to your business operations to let them be done mostly without human intervention, now a customer can kick off a transaction through self-service and see a complete almost immediately by intelligent automation, same business – better way to do it, more efficient, faster, more accurate, better customer satisfaction.

Now, this is also going to be helped by having proper business metrics that are oriented towards your business goals. With more automation data is going to be captured directly,, regarding how your operation is working, and then that’s going to feed directly into the metrics. Those metrics then you can use to guide knowledge workers so that they know what they should be doing next. Also to understand how customer satisfaction is and how you can improve it.

So this lets you move past your competition, while keeping your previous business focus. So given that there’s two companies, you and your competitors, who are offering the same products or Services if one does only that survival support that I talked about previously and one does more intelligent improvements focused on customer satisfaction, who do you think is going to win?

Now, the third stage of responding to disruption and adapting to change is innovation. You’ll continue to do process and operational improvements through performance monitoring, data-driven analytics, but also move into completely new business models. So maybe you repackage your products or services and then you sell them to completely different markets, so you might move from commercial to Consumer markets or vice versa or you sell into different geography or different industries because now you have more intelligent processes you have this always-on elastic infrastructure. Here again, you’re just moving past your competition by not only improving your business but actually expanding into new markets, taking on new business models that are supported by this technology-based Innovation.

So it’s the right application of technology that lets you do more types of business and more volume without increasing your employee headcount. Without automation and flexible processes you just couldn’t do that, and without data-driven analytics you wouldn’t have any understanding of the impact that such a change would have on your business or whether you should even try it. So you need to have all of that: you need to have the the data that supports the analytics and you need to have the right type of technology that you’re applying to have more intelligent operations business operations, and this was going to allow you to move from just surviving to thriving to innovation.

Now, a lot of change here. The question that all of you need to be asking yourself now is not is this the new normal but really why weren’t we doing things this way before? There’s just a lot of better ways that we could be doing things and we’re now being pushed to take those things on.

That’s all for today. Next month I’m going to be attending the academic BPM conference in the Netherlands, and there’s always some cool new ideas that come up so watch for my reports from over there!

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.

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.