Process automation trends uncovered, with Forrester

Ursula Cullen00:00

Hello everyone, and welcome to today's webinar. I'm Ursula Cullen from FlowForma, and I'll be hosting Process Automation Trends Uncovered by Forrester's John Bratincevic. Today's webinar is being recorded, your lines are muted, and if you need any help, email info@flowforma.com. If you have questions for our panelists, pop them into the chat box, and after the webinar we'll share a copy of the recording.

Ursula Cullen00:45

I'm delighted to be joined by John Bratincevic, senior analyst at Forrester. John's research focuses on citizen development, low-code development platforms and digital process automation. Paul Stone joins us from FlowForma. He's our product strategist and the go-to product expert from both a business and a technical perspective, working closely with FlowForma clients. There are no slides for this part: I'll interview John and Paul on some of the most topical process automation trends.

Ursula Cullen01:38

The first topic is citizen development. There's a lot of talk about it at the moment. John, is it real, and is it here to stay?

John Bratincevic02:13

It is real and it is here to stay. I sometimes liken where we are to where business was a few decades ago, when the personal computer was just entering the office. Computers were seen as arcane, only a few people had them, and they had to be carefully governed. Now using a computer is ubiquitous. I think what we call citizen development, people who aren't technical specialists making applications and developing software, is going to become as common as the computer. In my view it's the future of work.

John Bratincevic03:02

Think about all the trends in business: everything is software driven, digital means your business is expressed in software, it's constantly changing, and we're automating the heck out of things. That necessitates business people doing software work. If your business is expressed in software, the business people have to own, iterate on and control that software.

John Bratincevic03:33

And it isn't just a theory. We see it happening at modest scale, a few thousand developers at a time in the biggest examples I've seen, and a lot of large firms are working on how to roll it out to hundreds of thousands of business people. The most common question I get on low code at Forrester is how to scale one of these products out so people can start eliminating all the paper, spreadsheets, whiteboards, phone calls and emails that go into running most businesses. In the long term it's an economy-affecting sort of deal.

Paul Stone04:46

I certainly see that reflected in our client base. There are obvious pressures on IT to deliver at the pace the business needs, and organizations are looking to citizen developers as a solution. Citizen developers are more than willing to try it out, often with very good results. Three, four or five years ago it was a really big deal for a business worker to build a solution, but now there's much more aptitude for it, and recent events have spurred people on further.

Paul Stone05:56

It's also being implemented at an organizational level, where companies say citizen development is part of their strategy and put strategic changes in place to change the culture and enable it. It's really exciting.

John Bratincevic06:13

It is very exciting. It's a bigger deal than most topics I deal with.

Ursula Cullen06:27

No code is really driving the citizen development movement, and governance is especially important. John, what are your thoughts on that side of things?

John Bratincevic06:40

Governance is the big, hairy, difficult question most people are working on. It's the point of friction. If you're trying to embed this as a competency in the business, just a white-collar skill, governance has to work differently. If you simply delegate what IT does, the business won't do it: nobody wants to jump from a completely ungoverned way of working to a highly prescribed life cycle with testing expectations. There's a huge gulf between the way IT builds very important systems and the way business people get their work done.

John Bratincevic07:45

So firms are balancing autonomy, letting people build apps with some independence, with pragmatic control: an assessment of risk. You don't want health and safety problems because somebody wrote an app for prescribing drugs, so you think about use cases, training, access, and how people use data sources with sensitive information. In my research I've seen three basic patterns.

John Bratincevic08:29

The first is what I call the privateer model. Within a self-contained unit, like a business unit or a big department, there's a small, business-first team. Process people tend to fill this role. They might be moderately technical, good with Excel or able to build reports, but they're not developers. They become a semi-dedicated team on the platform. Say you're in the mortgage arm of a bank: three or four people use the low-code platform to build the apps that business unit needs.

John Bratincevic09:17

That controls the who. IT prescribes the platform, how to handle integrations and how to maintain users, but otherwise the team reports to the business unit executive and takes care of business. It doesn't have the cultural trappings of IT, but it's effectively local IT and can reprioritize on a dime. I call it the privateer because the executive at the firm I interviewed described that team as a pirate ship. They digitized all these paper processes and increased efficiency, data and visibility.

John Bratincevic10:38

The second approach is what more people think of as citizen development: pure democratization. Anybody in the firm can develop at any time, self-service. Where the first model restricts who, this one restricts what, usually through the way the platform is configured. Maybe integrations are limited or go down a different path, or the platform has inherent scale limits, so you're working on smaller use cases without special approval.

John Bratincevic11:36

A telecom in Asia did this really well. They configured an easy-to-use platform with limited integrations and ran a hackathon to attract early adopters. Over 300 people showed up, and they had remarkable results up front: quite a few substantial apps that saved a lot of money and time, small apps IT never would have gotten to. Those people became early evangelists, they now run regular quarterly training and more hackathons, and the goal is that everybody in the enterprise can build an app.

John Bratincevic12:41

The third is the most complex, but it's probably where enterprises will evolve to, because that's where the biggest returns are: a federated model. The low-code platform is a governed service, with a center of excellence that owns it. The CoE doesn't just set the rules; it develops and co-develops with people, and coaches and trains them.

John Bratincevic13:09

Then, depending on the business unit, the developer's training, the data being used and the criticality of the app, who works on it and how changes. There might be one process for simple departmental apps, another where you need the data owner's approval before deploying, and core modules the CoE builds itself, with collaboration in between. It's multiple processes and teams, and products don't fully automate that kind of governance yet, but it's where technology is going: an unbroken spectrum of technologists from IT to business people working on a shared platform.

Paul Stone14:37

We've been doing citizen development for quite a long time, and over time we've seen all three models. In the early days it was very much the privateer model, and more recently we've landed on federated, with a controlled environment. The returns rise as you go through the three models. The privateer always gets a good return, but with the federated model you get significant returns to the business. It's a bigger investment of time, but the return at the end is fantastic.

Paul Stone15:16

It comes down to how much risk IT wants to take on. They're always going to be there, at the very least managing the infrastructure, but they decide how much to let go and pass to the business process owners. Now there are plenty of real-world examples of people applying one of these three models, so they can make that decision in the context of the returns they'll get.

John Bratincevic15:59

We're right at the point where people are starting to place their big bets. That's where we are in the cycle.

Ursula Cullen16:13

There's probably still a lot of confusion around low code and no code. John, can you simplify the main differences for our audience?

John Bratincevic16:20

There's some history to the term. Low code was coined by Forrester six or seven years ago, when my predecessor noted a new generation of cloud-enabled, highly abstracted development tools where you wrote very little code. The idea was that you can always write some code if you need to, and in the enterprise you often do. Since then the platforms have matured, and you can pretty much write complete apps without any lower-level coding language.

John Bratincevic17:12

Another segment of the market calls itself no code. Most of the time, when a product says it's no code rather than low code, it means it's aimed squarely at the citizen developer: the person who not only can't code but doesn't have an engineer's mind for how software comes together. At Forrester we label the segments by persona, but in the market, low code generally connotes something more technical, aimed at the professional, and no code usually means business people.

Paul Stone18:09

From FlowForma's perspective, we're definitely aimed at business people, so we call ourselves no code and are proud of it. What's a little unusual is the breadth of functionality: you can build really complex applications with no code. We started as a no-code vendor and expanded the application over many years to cater for many business scenarios, and to take coding out of every aspect of the system, with no-code versions of things like integrations. So we target the citizen developer all the way, but cater for complex applications too.

John Bratincevic19:21

Let me ask you, Paul: can you write code somewhere in FlowForma if you want to?

Paul Stone19:28

Yes, you can, little tiny bits. Let me tell you a story. I once wrote a single line of code in a business application I was building with a customer. Their senior engineer, a very clever person, immediately said no, that's not allowed. We don't write code here, give me a different solution. We had to put a new feature on our roadmap to get rid of that line of code, and that's what we've been doing for a very long time. For citizen developers, literally one line of code is a problem, so we keep cutting it down. But you're right, John, there is a get-out clause if you need it.

John Bratincevic20:27

I think there's a strong architectural argument for not writing code. You're putting it on the vendor to provide the tooling. If the platform is powerful enough, going beyond it is largely theoretical, and having less code to own in the long term is better. There's huge value in that.

Ursula Cullen20:58

With new ways of working, a lot of organizations are looking to digitize at scale. I know there's no one answer that fits all, but what are your top tips for doing it well?

John Bratincevic21:18

I don't think people quite grasp what digitizing at scale means. We survey process data every year, and staggering numbers of companies still rely on paper and spreadsheets. The newest number is that 80% of firms have at least a few process dependencies on paper, and 99% still have some depending on spreadsheets passed around by email. That's not digital at all. It tells you companies haven't reflexively turned everything into software. They see technology as a selective investment: buy a big app, or scope a project and build it with engineers.

John Bratincevic22:28

What needs to happen is a cultural shift where the default position is that any policy, process, procedure, piece of data or bit of institutional knowledge gets turned into apps and software. That's very different from the MBA style of thinking, where every technology investment needs a business case. Low code and citizen development are what make the economics of that viable: development is so much faster, easier and cheaper, and you expand the developer pool beyond the engineers in IT.

John Bratincevic23:32

And this isn't trivial stuff. One of my first projects as a developer was at one of the largest firms in the world, where $100 million worth of work was managed on spreadsheets by about 20 people. I turned those spreadsheets into a really nice set of applications. In almost every firm, very important things affecting revenue, customer experience and quality are encoded in workarounds around the big systems. Either the big systems change a lot, or we build a lot of bespoke apps, and I think it'll be bespoke apps. So reflexively turn stuff into software: that's where it starts.

Paul Stone24:59

Absolutely. A couple of people at one client, a business of about 200 people, wanted to digitize their processes. Normally after our onboarding program people get a process or two digitized in about eight weeks and they're very happy. These guys took the bull by the horns: they were working on paper and spreadsheets, and they digitized 42 processes in 10 weeks and successfully went live with them. You can only achieve that with these tools. No IT department could deliver that kind of speed.

Paul Stone26:14

Another client decided at board level that citizen development was the way they would go. They had about 400 processes, put a training program together and trained 60 people. About 30 of those people delivered processes, and they delivered around 120 processes in two months. The tools are in place to let you scale; you need the mindset and the commitment, and if you have that, you can do it.

Ursula Cullen27:19

COVID-19 and customer-obsessed transformation have pushed automation front and center, but it's difficult to choose among process automation tools. What's the difference between DPA and RPA, and when is each best used?

John Bratincevic27:40

Big picture: DPA should be your foundation for process automation work, and RPA should be a service you selectively apply. DPA platforms are for building applications: screens, data, a notated process, an app that runs and that you interact with as a user. RPA is for tasks. It literally recreates what a person does with a keyboard and mouse, the clicks and keystrokes. Think of it as macros on steroids.

John Bratincevic28:45

That's useful in certain cases, for example when you need data out of an old system and there's no way to get it except with a mouse and keyboard. But you should only use it when you must, because it's fragile: if the screen layout changes, it breaks. It's not part of an overall process model. I often say RPA is Henry Ford's faster horse, while DPA is moving from a horse to a car: redefining the work, building it into data models, screens and APIs, which delivers much more substantial long-term value. RPA should always be subservient to DPA.

Paul Stone30:08

We have quite a number of customers who bought into RPA first. They were sold on the hype. RPA isn't a bad thing; it has a limited set of uses, and in the right scenario you get fantastic results. But it doesn't cover processes where people interact to achieve a business goal. Low-code DPA tools cover an awful lot of ground that RPA tools and ERP systems don't.

John Bratincevic31:18

Best practice is that the same team doing the low-code or DPA apps also does the RPA work. Some products even have RPA built in. The point is that one team has the range of tools and can apply the right one in the right context. When you separate those teams, that's when you get problems.

John Bratincevic31:49

Slightly bigger picture, one reason RPA gets over-applied is that we've been trained to buy best-of-breed applications and not customize them, so they don't do exactly what we want. Our solution is to replace the people using them with bots. But those systems were designed for people to interact with them. If your fix is to throw the person out and put a bot in their place, your system architecture is out of whack.

Paul Stone32:43

That's a great point: the same people should configure DPA and RPA, because they're complementary technologies. Don't have two separate teams.

Ursula Cullen33:02

You've both mentioned integrations. Digital organizations now use multiple systems and applications. John, how can integration and process automation tools work hand in hand?

John Bratincevic33:21

There's a class of integration tools called integration platform as a service, but a lot of low-code tools do similar things: a library of connectors, sometimes hundreds, plus tooling to map fields between systems and transform data. More mature DPA products cover the integration platform role to a decent level, so keep that in mind when you buy.

John Bratincevic34:24

The other bit, especially for citizen development, is that IT teams and engineers often worry too much about integration. They won't take a single step until the integration strategy is worked out. There's enormous value in these tools even without any integration at all. Turning all those paper, spreadsheet and email islands in your company into application islands is still about 10 times better than leaving them. Don't wait for the perfect integration rules and infrastructure to start digitizing.

Paul Stone35:28

I'd reiterate that: don't get hung up on integrations. Probably over 90% of our client base don't integrate their DPA platform with their back ends and still achieve enormous value, because they were working on paper and spreadsheets before. When you do integrate, at FlowForma we build integrations so citizen developers can use them, presented in a clear, easy format.

Paul Stone36:29

The other thing John said that's very true is that you don't need perfection the first time. Aim for a draft and refine it over time. You get value much earlier and better adoption, because people use it and see it getting better. That's a far bigger thing than having the system integrate with your SAP database.

John Bratincevic37:14

That's really important. There's an instinct, from decades of coding practice, to optimize before putting your hands on the keyboard: design the process the theoretically optimal way, then pick the technology. When we talk about agile we say MVP and fail fast, but for process people say no, define it all in the abstract first. When the barrier to entry is this low, the reflex should be to start making the process in the digital environment. It's not that you never plan, but we need to get much closer to live development: digitize it, tweak it, continuous improvement.

Paul Stone38:43

And getting it into the hands of the people who use the system, and getting their feedback directly, is so important. The system gets adopted more quickly and more successfully, and adoption is what gets you the return on investment. An imperfect draft out there is much better than waiting longer for perfection and potentially failing.

Ursula Cullen39:29

Paul, you mentioned adoption. John, can you share some tips on fostering a culture of continuous process improvement?

John Bratincevic39:45

It's a whole discipline in itself. We keep saying how wonderful citizen development and low code are, and they really are, but they're hard to introduce if the company's culture doesn't encourage it. If the culture is that you have your job, you don't have the time, encouragement or safety net to do anything else, and nobody wants you to change things, it's very hard to introduce the idea that everyone will run experiments in a digital environment.

John Bratincevic41:06

I know one firm with a wonderful privateer implementation, because the process improvement people did projects as their job. When they tried to democratize further, it fell down: the wider workforce didn't have time to learn, because that wasn't the culture yet. The flip side is that motivated people sometimes create the culture. Someone gets frustrated with the systems, builds something, gets recognized, and others take interest.

John Bratincevic42:18

Having a concrete medium where you can see the process and the data tends to encourage continuous improvement. In lean they say standard work is the foundation of continuous improvement, and when you digitize a process it becomes a visible standard. The natural inclination is to start tweaking it, and you have more time because you've automated it. So it can be a hard battle, but make time for people to improve things, let them experiment and make mistakes, and low code becomes the medium to do that very effectively.

Paul Stone43:28

I totally agree. Occasionally we come across companies with a culture of innovation, where people have targets to innovate and there are processes for submitting and assessing new ideas. That's great news for us; we can introduce a tool straight away. More often, though, it's a case of finding a champion in the business who wants to try a new way of working. They build their solutions themselves, show people the results, those results encourage others to jump on board, and gradually it expands and scales.

John Bratincevic45:06

One fundamental principle of continuous improvement is that the professional problem solvers at a distance shouldn't solve most of the problems; the people involved in the work should. If you have that embedded, this technology fits perfectly. But those environments are rare. Most people are striving.

Ursula Cullen45:33

Thank you both, we covered a lot of great topics. Paul, over to you for a few minutes to tell the audience a little more about FlowForma and some success stories.

Paul Stone46:06

FlowForma is a digital process automation platform that lets you digitize processes very quickly. It's aimed at citizen developers, business users who want to own the development of the solutions they use to run processes digitally. That accelerates digital transformation, because you use business resources rather than depending on IT bottlenecks, internal or external. You standardize processes, improve compliance and reduce costs. Even the most basic digitization of a process, compared with spreadsheets, paper and email trails, brings significant efficiency and a very fast return on investment.

Paul Stone47:21

The first example is the Liverpool School of Tropical Medicine, one of the oldest schools of tropical medicine in the world. They had a small, busy IT department without the capacity to digitize all the processes running on spreadsheets and email chains, so they chose a no-code tool. Training takes a couple of days, and they quickly trained eight people. They started with the finance department, and within a year they had automated over 120 processes, then expanded to general operations, HR and more.

Paul Stone49:12

The second is CVB Tideway, a very large civil construction project in London. They wanted compliance and visibility of their processes and to move away from paper. With so many paper processes, it's hard to know where to start, but there were some Captain Obvious processes with a very visible impact. They chose the project starter form, because so many contractors come and go, and site diaries, which every person on the project does every single day.

Paul Stone50:42

Because digital processes record the time and effort spent on every task, they could measure their savings: over 700 hours. And with all the data stored automatically, they could report on statistics they never could when they ran on paper.

Paul Stone51:14

FlowForma is a three-in-one tool. It merges workflow, the execution of tasks toward a business goal; forms, to collect data; and document management, to generate, pass around and store documents. It runs on Microsoft 365, with data saved in SharePoint and replicable to back-end systems. Our customers span construction, financial services, healthcare, transport and many other sectors, because the tool is designed to solve any process problem you might have.

Ursula Cullen52:49

Thanks, Paul. We have a couple of minutes for questions. One that came in at registration was about external stakeholders: would you recommend organizations allow external users to input directly into business processes?

John Bratincevic53:39

Of course, yes. If the philosophy is to turn everything about the business into software, the way you engage with customers should be too. There are a couple of caveats. One is brand: at a fancy restaurant, do you want to order a $300 bottle of wine on an iPad, or have a sommelier tell you about it? For Amazon, click and done is the brand. So make sure it's consistent with your brand promise.

John Bratincevic54:50

The second is that citizen developers absolutely work on customer-facing things, but when it's the front-and-center experience your customers interact with, especially at a large company, that's often done by professional developers or the CoE. So yes, with caveats.

Paul Stone55:34

I agree, the end-user experience is critical. We have a technology called Engage that lets external people take part in a process step. One company uses FlowForma to create products, and when a product comes from an external supplier, an admin clerk had to key in the supplier's details from a scanned image in an email. FlowForma can present that step directly to the supplier with a secure login. The supplier fills in the form, takes responsibility for getting it right, and the system still validates the information.

Paul Stone57:08

For a customer, it might be capturing information when they open a new account. It doesn't work in every scenario, as John said: sometimes you want the personal touch. But in many scenarios it adds a lot of value.

John Bratincevic57:39

But you should still reflexively digitize.

Ursula Cullen57:47

Another question from the audience: is there a way for citizen developers to test and learn as they build processes? Paul, do you want to take this one first?

Paul Stone58:05

Testing is critical to controlling risk. You're giving citizen developers very powerful tools, so you want them used properly. FlowForma has a health checker that checks a process for errors as it's being built and reports them to the citizen developer, and a visual interface so they can see the end-user experience as they build. Just as important is getting the solution to end users and getting feedback as soon as possible. Your end users effectively become your user acceptance testing: build a draft in a day, get feedback, adjust it the next day.

John Bratincevic59:46

Testing is an interesting question for low code in general and for citizen development. If you're not writing code, the nature of the tests is different. Do you need unit tests in low code? No, though the intent still matters as things get complex, and everybody's still figuring that out. Even professional testers will say the lower the risk, the less testing you need. When you're using a declarative tool and you saw the screen as you built it, do you need to formally test it? In general, the closer you get to business people, testing correlates to the risk and complexity of the thing.

Ursula Cullen60:41

Thank you so much to John and Paul. That hour flew by. If you'd like to learn more about FlowForma, sign up for a free trial or book a demo on our website. If we didn't get to your question, one of our product experts will be in touch. Thanks for joining us.