Recently, I was honoured to be invited to the SAP® AppHaus Pretoria launch in South Africa. I listened to the presentations with interest but I couldn’t shake off a certain amount of scepticism. This may have been the general apprehension I tend to feel when large multinationals inform me of a new ‘game-changing’ approach to something, which seems to manifest itself more frequently as I get older.
The old way
I remember projects in the early 2000s where the technology’s capabilities were the starting point for the design. IT systems were hosted internally and were designed almost deliberately to prevent integration with other technologies. The vendor wanted everything to be done in their ERP system, and was expanding the scope of their technology as part of an ‘arms race’. Even when integration was clearly required, like Electronic Data Interchange (EDI) to enable distinct organisations to trade, this was not easy to achieve. Turning standard data messaging formats into IDocs that SAP could process required a separate EDI subsystem middleware. So, when embarking on a new design for a business process, the last thing you wanted to do was ask the user what they wanted.
Years of experience had taught us gnarly IT professionals that engaging the business early in the design would lead to a scope that would turn out to be either technically unfeasible; or worse, it would be possible, but only by increasing project costs massively and ripping out systems or technology already understood and backed up by the skills and knowledge of the IT department’s existing staff.
So the early phases of the project focused on what could be technically possible, given the IT estate that was already heavily invested in, and/or known to be the favoured vendor of the incumbent IT director.
UAT (‘U will Accept it’ Training)
With this approach to process design, it was always inevitable that the User Acceptance Testing (UAT) would be a battle. I sat on both sides of that table within a very small time window quite early in my career. The systems’ users had many gripes with the legacy systems or manual processes. They were aware that a lot of time (and, therefore, money) had been spent on the project. Those who hadn’t been involved in UAT before would have very high hopes that their pain was going to be taken away by project ‘silver bullet’. Those who had played this game before were on the lookout for the real ‘showstopper’ that might need to be highlighted before more of their precious cynicism was wasted on this venture by overpaid consultants with no business experience, and they could get back to their actual work.
The major point here is that the important design decisions were long since gone by the time of UAT. Almost all the stakeholders had a vested interest in UAT being successful, and the clock was invariably ticking for everyone. Often the improvements of underlying technology meant the new system was marginally better than the old one, but it still had to overcome the inevitable human resistance to change. So the ‘go live’ perception would require many to hold their nose and swallow hard, so they could move on to the next project.
My niggling doubt about Design Thinking
So far, so good. I could absolutely see why Design Thinking made sense. But my immediate thought turned to one thing:
I couldn’t get past the yesteryear mindset of IT departments. End users were not to be trusted, or perhaps I should say even included in important systems’ decisions. IT knows best. Limitations of systems’ integration must be considered before anyone can possibly openly discuss what a user would like to happen.
The inflexion point
A leopard cannot change its spots (subject to some incredibly ethically questionable stem cell work) but a grumpy old man can switch his position after a little time and reflection.
Back in the northern hemisphere, I was talking to another parent while my youngest played lacrosse. In a discussion about his IT challenges while working in the public sector, I stumbled on to explain that application programming interfaces (APIs) meant modern systems could integrate seamlessly with each other. The best example I could think of to explain this was the personal banking apps. Twenty years ago, a credit card statement would come in the post and a cheque would be posted back to pay it. Now your credit card app can open your banking app and, once you’ve authenticated the two, can instantaneously swap information and complete the payment. There is some ‘technical debt’ out there with old internally-hosted systems that were deliberately built like sealed units but, for the most part, the systems organisations are running on have APIs for most of the actions required.
The banking app is just the tip of the iceberg. The siloed old ERP systems from around the turn of the millennium are still there in many cases, but they have had their barriers to integration forced down by the need to accept that they didn’t win the arms race on all fronts and had to integrate seamlessly. Yes, SAP CRM improved immeasurably from its early versions but many organisations still switched to a ‘best of breed’ for the industry or a ‘born in the cloud’ solution that, by very definition, has to be able to interface with the ERP systems.
Throw into the mix the march of mobile in the last 20 years. How could the ERP vendor have imagined keeping up with all the dumb-terminals (if you’re under 30, look that up, and you’ll be astounded!), scanners, tablets and phones that would need to be able to submit and receive information from operatives in the warehouse or sales teams out on the road, or ‒ of course ‒ employees absolutely anywhere? Each one has multiple operating systems and versions to support.
The point here is that most actions you might want to carry out in an ERP system can be done from outside, via an API or other interface. Where they can’t, that’s just the next gap the vendor needs to plug or a middleware needs to be employed to enable. In the case of SAP, this is exactly where BTP comes in, allowing an almost infinite number of ways to interact and extend the core ERP functionality in a platform with instant access to the outside world, machine learning and AI.
Let’s listen to the user
With this realisation, it all falls together quite quickly. The users have the best understanding of what actually goes on in the process we’re trying to improve. The people using the system are knowledgeable and likely have a skill set in demand in our current world. We need to put two things at the top of our priorities in how we design or redesign a process:
-
We really don’t want to hand over something which is going to be frustrating and contribute to job dissatisfaction and potentially lead to someone quitting.
-
We want to ensure the best use of this person's time. We need them to be able to execute the activity as quickly and smoothly as possible so we can make best use of their valuable time.
We must start design from the assumption that anything is technically possible (within reason, of course) and work backwards from the process being perfect for the person who will have to live with it long after the project is over.
Design Thinking? Tell me more…
Design Thinking is a problem-solving methodology that places the user at the centre of the process. It is a human-centred approach that involves understanding the needs and perspectives of users, generating ideas and solutions, prototyping and testing those solutions, and iterating based on feedback. The goal is to create innovative and effective solutions to complex problems.
It is a creative and iterative process that encourages collaboration, experimentation, and risk-taking. It often involves working in multidisciplinary teams to leverage different perspectives and expertise.
The process typically involves five stages: empathise, define, ideate, prototype and test. Empathy involves understanding the user's needs and perspectives, while defining identifies the problem to be solved. Ideation involves generating a wide range of ideas, while prototyping creates tangible representations of those ideas. Testing seeks feedback from users to refine and improve the solutions. The stages are not always sequential; they can be run in parallel or be repeated as part of the iteration.
The purpose of the SAP AppHaus network is to provide the space and guidance to carry all this out. Read more in this blog by SAP's Andreas Hauser.
Sign me up
After this screeching U-turn, I am actually now very keen to experience an AppHaus project for myself. So, if you’re one of our clients and you are planning a project requiring my skills, then please get in touch. Or if you’re an AppHaus partner looking for someone with my skill set for a project, please reach out.
Learn more about EPI-USE Apphaus Pretoria – the first AppHaus in Africa.
Leave a Comment: