The hidden risks of digitization
If you touch a hot stove as a child, you make a mistake and feel its effects immediately – you learn quickly, sustainably and don’t make this mistake a second time. It is different if we make mistakes with our retirement provision, for example. Because the consequences are not immediately felt, it is difficult for us to learn from these mistakes.
Unknown unknowns: Things we don’t even know we don’t know. Unknown unknowns are particularly problematic when assessing the right course of action.
Donald Rumsfeld, who was US Secretary of Defense during the 3rd Gulf War in 2002, coined the term “unknown unknowns” in this context. So with the things that we don’t even know that we don’t know. These “unknown unknowns”, according to Rumsfeld at the time, are particularly problematic when assessing the right course of action in dealing with Iraq – and as a result a model for risk assessment has developed from the “unknown unknowns”.
UNKNOWN UNKNOWNS CREATE LOOSE-LOOSE SITUATIONS DURING DIGITALIZATION
The mechanisms of action described above also play a decisive role in the planning and implementation of digitization projects: Anyone who wants to start such a project does not know what they do not know in various dimensions – and has no opportunity to learn directly from their mistakes because a relevant part of the possible negative effects only manifests itself after a considerable time lag.
Interesting: Experienced digitization service providers like us are often perceived as too expensive in tenders because they want to make financial provisions for one or more unknown unknowns, the existence of which some of those involved may not yet recognize or deny at this point. They may also be perceived as slow because the time and effort needed to iron out unknown unknwowns is included in the planning. But we do it because we know and take into account various long-term effects. So we may be punished for our competence and experience, from which we know very well about the real existence of unknown unknowns and just don’t say “everything is very easy and done quickly”. But that’s what many want to hear, or they tend to hire someone who promises exactly that. Incidentally, this pattern is also used for major projects such as airports or train stations.
We have seen it a few times now that someone who initially decided against us for exactly the reasons described above, comes to us after two years remorsefully and is annoyed that he didn’t “listen to us” at the time. . This is a nice confirmation for us – but ultimately only brings losers compared to a more forward-looking and more trusting approach. We didn’t win the big project, the customer lost a lot of time. Lose-lose situation – that’s not something you like to say, is it? Pity!
WHERE DO THESE AMAZING UNKNOWN UNKNOWNS ACTUALLY RESIDE?
Anyone who has bravely persevered up to this point in their search for a supposed mythical creature should be rewarded with a few clues as to where unknown unknowns have already been encountered several times and are sighted again and again.
Unknown unknowns system architecture
- Fast, short-term improvised, individual special solution in the shop software causes problems with updates
- Too much customization in the monolithic shop system
- Naively used plugins of low quality
Unknown unknowns Setup
- Poor product data (unknown data model, lack of consistency)
- Interface requirements unclear or underestimated
- (Recognized too late) individualization requirements for standard software
- Unexpected loss of speed in communication with third-party service providers
Unknown unknowns expansion
- Setup rework consumes all available resources
- Challenges in day-to-day business hinder focused expansion
- No impulses, dull, reactionary processing of given topics by service providers
Unknown unknowns daily business
- Support only feels responsible for self-caused problems (“no customer perspective”)
- Support not sufficiently qualified, only accepts reports
- Support cannot solve many technical problems itself
There is a lot of talk right now about MACH, a software architecture that is microservice-based, API-first, cloud-native and headless – but for historical reasons there are hardly any consistent implementations. The e-commerce agency Shopmacher presents sport2000.de, one of the first major cases in the field.
The vendor market for commerce solutions is on the move. Experts see a move toward composable commerce and cloud-based solutions. What should a future-proof commerce system look like? Manuel Ludvigsen-Diekmann, CTO of SHOPMACHER, joins two other commerce experts to talk about the most important ShopTech requirements for 2023.