Automation runs on software. But first things first: what is the difference between a business process and a technical process?
‘We mainly distinguish between functional and technical processes, though we prefer not to call the technical side “processes” at all, to avoid confusion. The easiest way to explain it is to look at what someone without a technical background does and does not understand. If it is language they can follow, you are talking about functional processes — a block diagram describing a flow, for instance. A technical process describes what happens inside one of those blocks, such as updating systems or handling email actions. We often try to “hide” those technical processes from the client. Users are not interested in that level of detail at all; when they reach a certain step, an email simply has to go out. Everything that has to happen to make that work is less relevant to them.’
Most people and companies indeed care little about exactly how software works. Is that also why they sometimes end up trapped in standard click-and-go systems?
‘As a company you can do one of two things: adapt your business to the software, or adapt the software to your business. The first is cheaper. You buy an off-the-shelf product and change the way you work. Companies usually choose that route without entirely realising it. The philosophy behind that kind of software is to lure you in with something cheap. Usually it covers about 75%. And certainly at the start you do not see the pitfalls; it works perfectly well.
But at the level of detail they often fall short; sometimes functionality is simply missing. And when something does need changing, it is usually very expensive. Sometimes it is not possible at all. That makes it far harder to distinguish yourself from your competitors. Of course this all depends on whether the core of your operation depends on software.’
Do you have advice for companies, organisations or departments unsure about their choice of software package?
‘By then it is usually too late. You are having doubts, or you have concluded you made the wrong choice. Chances are you have already invested time and money, even when it is a monthly subscription you could cancel easily. The real solution, and the real gain, is in the preparation.’
The real solution, and the real gain, is in the preparation
The choice is huge. Why does it matter so much to prepare the decision about a software package properly? And what causes the lack of preparation?
‘Companies often start small, do everything by hand and eventually automate certain things. In practice you see that pattern far more often than companies with an automation strategy built into how they run the business. But it all depends on the line of work: for a baker such a strategy is of secondary importance, while a company with a cloud-based product really cannot do without one. Even at cloud-based companies, though, you often see that they have not thought it through. If you have to adapt, scale and automate software when it becomes unavoidable, the business still has to keep running the old way in the meantime. Switching to the new way also costs time and money, and is often frustrating for the team.
At that point a company is enormously dependent on the software. And that dependency is exactly what you want to avoid. In recent years you see it more and more with consumers who can no longer use a product they bought after the company goes under — think of what happened with VanMoof. You see it regularly in the games industry too: when a game developer collapses, a game can no longer be played because the servers are gone. The same problem will arise with electronic doorbell manufacturers. As far as I know two brands store the recorded video locally; with the others it is uploaded to the cloud. If circumstances mean they can no longer pay the server bills, everything goes dark.’
We are sometimes too dependent on software. So who or what do I need to make a good choice?
‘Many people and organisations are seduced by the interface, which these days often looks fantastic. The beautifully produced demo videos tend to show only the functionality that works well; the weak spots naturally do not feature.
What you need is someone who is functionally strong at mapping out exactly what a software package has to do. What does the company need? Not on the technical side, but in terms of the number of users, the importance of specific tasks and the time currently being lost. If a particular task has to be done by one person once a month, it is not a problem — you can choose to keep doing it by hand. But if a whole team spends 40 hours a week on it, the right choice can pay back your investment remarkably fast.
At CodeCast we focus mainly on automating tasks that quickly deliver a strong return. Sometimes that is not possible, or clients do not want it. Then we look at whether we can automate it partly, or streamline the business process better. A four-hour task might then be done in two. If you are genuinely a distinctive company and want to differ from your competitors, you have to choose software or a partner that supports you in that. If you just pick something at random, it can become a painful process.’
You need someone who is functionally strong
How do you avoid the bad aftertaste that automating processes or upgrading software can leave behind?
‘We usually start small and focus on one business case at a time: we are going to automate this specific process “X”, and we know with complete certainty it will save “X” hours a week. As a result we earn the investment back after period “X”. We never automate all processes at once; that has to happen very gradually. A process may not be interesting to automate now, but might well be in two years. Working this way you do not disrupt the business too much, because you are only ever working on the things that genuinely matter. That makes the experience much better for staff, and it really helps with acceptance.’
What does CodeCast do to avoid falling into the software-developer rabbit hole?
‘We often see clients come up with solutions themselves, sometimes having half thought through the technology, but we always try to steer away from that; in the end the question we get is always about a functional problem. Internally we are best placed to decide which technology to use for it. The moment we start building on someone else’s technical solution, it becomes harder to get to the question behind the question.
We once had a request to build an extra report. The client was looking for a better way to find incorrect transactions, but with a fairly simple solution we could recognise those transactions much earlier in the process — and often prevent them altogether. In that case the need for a new reporting system disappeared. If we had not kept asking about the actual problem, we would never have arrived at that solution. The biggest benefit here is that nobody has to read a dull report any more; when a transaction is wrong, a notification simply comes in that can be handled and resolved straight away. That leaves more time for enjoyable, useful work. And creating that kind of job satisfaction is, to my mind, the best result we can achieve.’
