Today’s digital journeys demand CX and UX experiences that are consistent, rich with intuitive features and above all provide an easy and engaging customer experience (CX). This is true from the coolest ‘app of the year contender’ through to digital government services (digitised Covid-19 vaccine status and QR code use highlighted this recently).
When developing a new product, process efficiency (beyond the process that is being defined which is inherent to the product) is generally of little concern. Take a step into the future where a business is ready to create additional digital products, extend the ecosystem, not to mention governance, internationalisation, and audit requirements, while maintaining consistent and engaging CX, then it may be time to think of process optimisation. There are of course tools that will integrate your platforms, manage workflow, pass data around (low-code, no-code) making it easy to keep out of Technology hands and therefore reduce costs, so processes can be orchestrated across platforms. Great! Now we can effectively link everything, does that mean our process problems are fixed? Maybe. Loosely coupled, modular and distributed service design (on the product architecture side of things) all help to get close to an architecture that will scale, remain sensible and logical to maintain, however will the accompanying set of processes / journeys that traverse multiple products (out-of-the-box and custom) form a manageable architecture and maintain a seamless, quality CX? Maybe not. For larger enterprises, this is where Business Process Management (BPM) can assist, and for a select few, this may provide the answer, however if worrying about processes is on the periphery for most Small and Medium Enterprises (SMEs), then BPM is way over the horizon, both in terms of relatability and perceived ROI.
Optimization is king, long live the king
At some point in time, however, many SMEs will want to look at process optimization. If led by platforms and vendors, this may often translate directly to automation as a fix-all. However, while there are a myriad of tools and platforms that can provide automation, if the actual process logic is not considered then this can just help us do bad things more quickly and maybe with more exposure (to data and business logic). In coding we’ve generally moved from working with large procedural languages with routines comprising hundreds of lines of code, to object oriented and later, micro services approaches to modularize, simplify and better execute. With processes however, we often still look end to end and perhaps don’t see the need to modularize. We know we have some problems but fail to see how to fix them. For example, an onboarding web form may have (as we perceive) way too many questions and take to long for customers to complete. Often a form like this has been built up from prototype, has had multiple layers of additional information applied to it and has ended up effectively a monolith. If we skip process modularization and jump to automation, our answer might be to automate some of the easier bits of information during capture, allow some default information to be assumed and then put through to back-of-house processing to be fixed up later. On the surface we have optimized the process – the customer can onboard, say, 25% more quickly. Great! But if we approach this problem from a process modularization point of view then we can understand that the monolithic form is a bit like an archaeological dig, different layers represent growth of the product, “accidental” architecture that develops over time with the addition of new data requirements, etc. If we analyze in this way, the “onboarding” form captures not only customer onboarding information, but also specific product or feature options for intended use as well as, perhaps, banking, and other company or statutory information. So in terms of modules, we have customer information, product / feature and statutory / financial information being captured. The onboarding process in this example can be modularized into a set of processes that while they can flow in an end-to-end way may also be looked at (and importantly executed) individually. A new customer may create basic onboarding details, save, log off and come back later. They may need to wait to obtain certain financial information but proceed to capture some company details. Modular processes can support this while an unoptimized monolithic process will struggle.
If you think of the typical portal applications for different products and services we use every day, regardless of the backend platform, these kinds of journey variants are what we expect. With just a bit of process optimisation thinking, those same automation platforms and tools can now be used to orchestrate our optimised processes and to inject automation where it makes sense.
Leave a comment