Why Automating Everything Might Not Be Your Best Solution
Why Automating Everything Might Not Be Your Best Solution
Low-code/no-code development offers a tantalizing future where almost anybody can create workflow automation to streamline operations for a more efficient, productive workplace. According to TechRepublic, 47% of organizations already use low-code/no-code platforms, with workflow automation being the leading reason. The business world is certainly ready to embrace low-code/no-code development in its everyday operations.
However, as exciting as the possibilities might be, low-code/no-code development can also be overused or poorly implemented; this creates problems in the long term simply for the sake of making things easier in the short term.
Ten years from now, organizations that aren’t careful will likely find themselves with dozens of unnecessary automated processes that run on various unstable platforms and that were built by people who no longer work at the company.
The Problem With Automating First and Asking Questions Later
In the book “Implementing Lean Software Development: From Concept to Cash,” authors Mary Poppendieck and Tom Poppendieck said: “We are not helping our customers if we simply automate a complex or messy process.”
It’s important to remember that even if there’s little coding involved in low-code/no-code workflow automation, the design and management problems will still be similar to full-on software development.
You can’t get away from the fact that complex work processes are complex, and the automation of those processes will mirror that.
Messy Processes Beget Inefficient Automation
The authors went on to say: “Any process that is a candidate for automation should first be clarified and simplified, possibly even removing existing automation. Only then can the process be clearly understood and the leverage points for effective automation identified.”
Consider, for example, that you have a requisition system that requires five different approvals to move forward. So you automate the approval process. You might save employees a few minutes sending emails and filling in spreadsheets, but what if the fundamental inefficiency lies in the approvals themselves? What if you don’t need that many approvals to begin with? Automating unoptimized processes only hardwires inefficiency into the system and makes it more difficult to change later.
Assessing Whether You Should Automate With a Low-Code/No-Code Platform
To make the most out of these platforms, it’s crucial to ask the right questions before jumping straight to automation. It’s the only way to be sure you’re creating a process that will help your business maintain efficiency for years to come. Here are four questions you should ask to figure out whether a low-code/no-code automation solution is right for the job:
1. Do I know enough about workflow and process analysis to be confident in my decisions?
Used effectively, automation can streamline existing processes and free up employees’ time to work on more important things.
Used ineffectively, however, automation could cement wasteful processes into your operations and make them harder to dispose of in the future.
When Toyota developed the lean manufacturing approach, it didn’t immediately start automating everything. Instead, the company invested heavily in continuous process improvement and hyper-optimizing its workflows. Make sure you have the expertise necessary to know whether a process truly needs to exist and is well-optimized before you begin to automate.
2. How critical is a process to our organization?
Software development has a long history of quality analysis and quality assurance processes that are often missing in low-code/no-code development. It’s important to keep in mind that a lack of coding doesn’t mean there will be a lack of errors — the system will only ever do what you tell it to do.
Although the risk is generally much lower on these platforms than for developers, if you’re trying to build something for a business-critical process, it pays to take extra care and time to make sure you can get it right. In these cases, it’s often best to build several small automation systems instead of one big one. That way, you’ll be much less likely to forget about how pieces work as you’re piping data from one part to another.
3. Do I understand the need for longevity?
Typical software development tends to happen with a five- to 10-year outlook in mind, but this long view is often missing from low-code/no-code software. Employees fail to evaluate risks that might turn up in the next year or more and instead focus only on the current task at hand.
But what happens when you think out to six or 12 months in the future? Will you still be in the same position then? If not, how will you hand the project off to someone else? Beyond that, how will things look in five years? Is it likely that the platform you’re using will still be around? Short-term gains tend to overshadow these important long-term considerations in low-code/no-code development.
4. Am I okay with throwing experiments away on the journey to a workable project?
You don’t want to spend a ton of time putting together a big plan for an automation project and then building it all in one go. Instead, it’s smarter to start sooner and then work in smaller batches. These batches can provide you with a powerful learning feedback loop that will help you avoid wasting time developing features no one will use. By working on and delivering smaller segments, you can experiment and iterate to build useful and efficient processes instead of ones that don’t accomplish your goals.
Tools that enable people to automate without a deep understanding of software engineering and design principles are on the rise — which means so is the likelihood of baking inefficiencies and faulty assumptions into workflows.
Before creating something that will only be a burden down the line, evaluate the bigger picture and determine if your processes are ready for automation.
Image Credit: Markus Spiske; Unsplash; Thank you!
The post Why Automating Everything Might Not Be Your Best Solution appeared first on ReadWrite.
(32)
