What happens when you digitise sh!t processes?

So, I asked myself, why? Why aren’t businesses taking the opportunity to digitize and improve at the same time? The answer I suspect is because many digitizing programmes sit on a hot-bed of over-engineering. Oftentimes this means adopting”strategic” business platforms which require companies to adapt their processes to fit them rather than the other way round. Sometimes, it can mean hiring expensive contractors that don’t understand the business and are more interested in growing their personal digital tool kit than your bottom line. The thought of wiping the slate clean and discovering improved, elegant and modern processes before you even start those lengthy, expensive development cycles must be enough to put most people off. Let’s face it, it’s hard enough to get any project into the IT QUEUE in the first place. Meh.
Of course, there is another way.
You stop digitizing sh!t processes, stop waiting for precious developer resources and stop spending a fortune on bloated business platforms that will simply become tomorrow’s legacy
.”
Justine Caul
in this LinkedIn post.

Hot-bed of over-engineering. Check.
Lengthy development cycles. Check.
Digitizing sh!t processes. Check.
Difficult getting into the IT queue. Check.
Discovering improved, elegant and modern processes before you even start. Uhhhmmm…. have you ever had a “check” on this item on an OSS project?

We spoke yesterday about a migration project that is simply migrating all the old data and processes over to a new platform. To me, that’s missing out on one of the big opportunities of doing a migration. The opportunity to revisit old processes and redesign them for the new one. Or to paraphrase Justine Caul, “discovering improved, elegant and modern processes before you even start.”

Every OSS project that requires processes to be migrated from one platform to another will introduce some level of change to the process (ie the originating platform won’t have the exact same workflow as the new one to perform certain tasks). However in my experience, the integration team has always tried to massage the old processes into the new system rather than revisiting whether the old workflow is still effective. For example, rules and regulations change over time, approvals that used to be mandatory may no longer be relevant, automated system checks that have changed may not be giving the best response, etc.

But I’ve become side-tracked. The real message of this story is Justine Caul’s reference to not digitising sh!t processes. Just because things CAN be done in an OSS, doesn’t mean they SHOULD be done in an OSS. The great thing about OSS is that they’re supremely capable and can be configured to do so many amazing things. But that doesn’t mean they should. If it’s more cost-benefit justifiable to do a once-monthly task manually than doing an OSS integration, then why ask your OSS to do it? As Justine points out, chances are you’ll be sitting in the IT queue for a while anyway.

To put this in another analogy – it’s far cheaper to make changes in the design stage than it is during the construction phase. Consider processes to be the equivalent of the design stage. It’s more effective to streamline the process before handing it over to an IT team to implement. If the digitisation process is rubbish, then the solution will be rubbish too, no matter how good the OSS is.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

2 thoughts on “What happens when you digitise sh!t processes?

  1. Thanks for the props Ryan. Having come from an OSS/BSS background myself – I’ve seen this happen over and over with some companies. Every time there’s a new technology introduced (APIs, middleware /workflow, virtualisation, Cloud, mobile, big data) there’s a tendency to assume that it will transform what was there before. And, although this is often true in the case of “hygiene” factors like speed or security, cases where simply changing the technology provides a better customer experience are few and far between:
    – In the finance world – I can certainly remember the days when online banking was more complicated than telephone and, I remember all too well the race to implement per-second billing in mobile (becuase it was possible) when what customers really wanted was an affordable airtime plan with a fixed monthly cost.
    Low-code may be a quicker way to build solutions – but it’s success is really based on the ability to do it in an iterative customer led way. – Justine

  2. Thanks Justine

    Your initial article certainly resonated, as did your follow-up comment, so it’s no surprise to hear that you’ve already wrestled with the OSS/BSS beast 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *