“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.