Our solution design was developed by employees from different companies, which, in turn, had a variety of pallet exchange processes in place. These processes ranged from a ‘letterbox’ solution to the customised expansion of the company’s ERP, including inventory management.
This post reveals how we still managed to come up with a solution that was accepted by the group.
Faster horses!
The term ‘requirements engineering’ describes the art of finding out what someone really wants. That’s hardly rocket science now, is it? Why don’t we just ask the question? Good idea! However, it’s worth thinking back to Henry Ford’s witty line: “If I’d have asked the people what they wanted, they would have said faster horses.” In the same vein, back in 2007, no one was asking Steve Jobs for a portable telephone that could be used to listen to music and surf the net.
In other words, it’s still a challenge to get out of people what they really want. And this is even more important when we are dealing with new technologies that people haven’t even heard of. Development approaches such as design thinking and BXT (see https://digital.pwc.com/en/bxt.html#/) are useful for addressing these issues. These are based on the assumption that the best solutions are developed by involving different disciplines and by adopting a people-centric approach. Of course, not people in general, but specifically those who will be involved with using the solution at a later date.
Roles in a pallet exchange system
Working with a shared process model is recommended for determining roles in the context of a consortium. Our pallet management system was, therefore, split into 5 sub-processes and served as a basis for reaching a global understanding of who is involved in the exchange process and how these roles should be described. Definition of these roles, e.g. ‘Lorry Loader’ or ‘Outgoing Goods Office’, forms the foundation for subsequent steps. Requirements are defined for each role in the form of user stories, as well as acceptance criteria – as we described in a previous blog post:
<link innovation blockchain-blog wer-macht-eigentlich-was>
www.gs1-germany.de/innovation/blockchain-blog/wer-macht-eigentlich-was/
Crossing over to the blockchain world
The documented user stories highlight the requirements of the existing roles with regard to existing processes. Before these can be transferred to the blockchain world, they need to be ‘converted’. In other words, the fact that the Loader requires a signed pallet note from the Lorry Driver at the end of the process will be converted into the requirement that a data set describing the exchange is recorded in the blockchain instead. If the Outgoing Goods Office wants to know what type of pallet has been exchanged, it will need a GRAI (global returnable asset identifier), which GS1 has defined as the industry standard.
We work through the entire list of requirements in this way. The process involves pallet experts, blockchain specialists, standardisation specialists and UX designers and results in the rough initial outline of a solution.
We realise that we need two ways of accessing our blockchain. Firstly, a mobile application that drivers and warehouse employees can carry around with them and a desktop application to support administrative processes in the office. A target process emerges, which only involves four roles: a driver, a logistician, a document administrator and an authoriser.
Prototypes with an increasing level of detail
First of all, we start by describing the required functions for each role so that these can be integrated into the initial draft of the screens. Our approach enables us to develop and test prototypes with an increasing level of detail. Firstly, we outline rough functions and procedures on paper and on a whiteboard, then use PowerPoint to portray the screens with their most important fields, the standards used and application logic. Finally, we use a screen mock-up programme to provide all fields with selection criteria, system interaction and system messages.
According to the level of detail, the prototypes are tested by going through the different process steps and comparing the solution to the user stories and acceptance criteria. The number of people who are asked to look at the design increases as tests continue. Finally, we obtain the go-ahead from all project members during an online meeting, before forwarding the solution to the programmers and waiting – with much excitement – to see it implemented.
PwC
Comments
No Comments