My first job, while still at university, was to help a company move its customer relations database from an Access creation to an industry standard CRM. That was back in 2000, and ‘home brew’ low-code options have been around far longer. They all have the same back story, led by someone who knew a particular application well who also wanted their process to fit just perfectly.
Things change…
It works, and it often works well. But then time goes by, and processes change and people change. Things adapt, a little, but then more steps are added, more manual processing, more time spent. Without a further champion, what was originally slick and innovative can become a burden, dotted with security flaws and bound together by goodwill and a reluctance to change.
Microsoft Access, Excel and other low-code, home-brew solutions have a place to take and process data in a meaningful way. Quick, short processes, often unique to an area or industry, can be reflected in an exacting way. Without thought though, that freshly-commissioned software soon starts to struggle with changes, upgrades in key components and amendments to the workflow. It can soon become a link in a lengthening chain.
Software straightjackets
But the alternatives can be expensive, bloated software solutions that concentrate on a process, but bend users to that process, providing a set, structural straitjacket. Once commissioned and running, change and upgrades are painful (at best) or will require additional expensive work via new contracts (at worst).
The same issues that dog home-brew and low-code custom solutions remain. That big software changeover, the team training, the rollout – launched perfectly, managed successfully and too expensive to repeat again in the near future. But as processes change and the software doesn’t, work-arounds and Excel spreadsheets proliferate. The original efficiencies can be driven out of a process if there isn’t an option to change it quickly, cheaply and by yourself.
Consider APIs
What’s the solution? Well, there are two options. The first option, when looking at creating low-code, home-brew and customised options, think of the future and consider the flexibility you might need based on past experience or emerging trends. Look for mainstream compatibility, such as using APIs to connect with powerful third-party software (e.g. Microsoft Power BI).
Be aware that the straitjacket of a perfectly-fitting piece of software may eventually strangle users. The ability to change values and tweak processes can be built into software, taking hard-coded elements and giving end-users more choice. However, it takes time and thought, so don’t just hand over a brief of how you do things now; instead, hand over a brief of how you want to change and grow as well.
Customisation included
The second option is to choose software that has more options for self-customisation. This avoids the reliance of wholesale version upgrades every few years to keep up with general policy and technology changes. It also avoids commissioning custom consultancy to make changes, which, because of their cost, are often bunched together into a larger package. These then rely on lengthy programming and UAT cycles. Keeping customisation options within reach of your main end-users means that ever-increasing improvements can be made based on smaller points of feedback for the lifetime of the software – evolving, changing and growing with your team.
The key to both options is the flexibility of customisation; the ability to tweak, change and adapt on the fly without significant intervention, budgetary sign-off and lengthy lead-in times. The more power given to your ‘power users’, the more future-proof the software can become and the more efficient your teams can be.
Daniel Hayman is a director of Huume.
