Ethanol Unloading
at Loadshark software
In this project, I worked on the development of a module in logistics management software to manage the unloading of ethanol truckloads at Braskem's plants.
The case is divided into 4 parts: starting scenario, method, prototypes and results.
Summary
Stated problem
Difficulty in scheduling and rescheduling unloadings brought in by third-party trucks by Braskem's planning team.
Objective
Creation of a module in the Loadshark software that manages schedules and that can also be accessed by carriers and unloading operations staff.
My part in this project
Understand and analyze the roles of those involved in the unloading schedules and propose an MVP flow to solve the planning team's pain points.
Solution
The research methodology used was: desk research, in-depth interviews followed by weekly touchpoints with the planning team.
For the construction of the prototypes: construction of the blueprint involving all three teams that would use the product, ideation process and Moscow method to define priorities in the MVP, design of the user flow, touch points with the development team and prototyping based on Loadshark's design system. The prototype design was based on 2 main screens accessible by the 3 teams with specific interactions for each.
Client and project
Ethanol Unloading project, for the Loadshark venture, part of Braskem.
Results
A 90% reduction in the number of emails exchanged, a view into the horizon of scheduling windows, reduction in overtime paid to carriers and R$57,000.00 in savings in the first month of the module's operati
Starting scenario
I was working on a venture that aimed to provide road transport logistics solutions to a large company using web-accessible software.
The project presented here began when the department responsible for the storage and unloading of chemical loads, specifically ethanol, reported difficulties in organizing these receipts, a process that turned out to be more costly than expected.
Three groups are involved in the unloading process:
Planning
Third-party carriers
Outsourced operational
The stages of the receiving process should have been as follows:
The planning team defines the quota for the month (in liters) and divides it among a number of carriers;
Carriers inform the plant team of all truck arrival dates for unloading;
Planning team organizes the reception schedule with dates and times for the entire month;
Carriers send trucks to collect ethanol and deliver it to plants;
Based on the planning schedule, the operations team waits to receive the trucks at the plants
Planning tracks all deliveries and receives additional information from the operational team.
However, the stages rarely occurred without unforeseen events that affected all involved groups and data collection. The planning team's initial report of pain was: critical scheduling errors, slow operations, difficulty in managing carrier performance, frequent overtime payments due to delays, lack of control in rescheduling windows.
Method
Study and initial interviews
The first step was to understand the process, the people involved in it, and their actions; to this end, I began a desk research using material provided by the groups and material from outside the companyh (employee handbooks, market insight reports, research material collected by the marketing teams) to understand the specifics of the process and how the company's competitors solved similar challenge.
Based on this material, I followed up with a series of in-depth interviews with participants from the three groups (chosen to ensure the greatest plurality of hierarchies and responsabilities between the groupas), with the goal of understanding:
What was everyone's routine on the days when unloading-related tasks took place?;
How much time and energy were spent on these tasks? How did the participants feel about it?;
What tools were used to complete the tasks (e-mail, phone, spreadsheets, custom systems, etc
How the communication between the participants and between the groups worked, when required;
What information was relevant for each of them to successfully complete their tasks.
Based on a basic storytelling interview structure, the format followed 5 stages: introduction, technical information, contextualization of the interviewee, icebreaker, situational questions designed to encourage the interviewee to tell a story, and finally, specific questions.
The interviews were conducted in pairs (one moderator and one note-taker), with a total of eight people interviewed individually. At the end of each interview, the moderator and note taker discussed and documented the key findings and pain points presented.
Interview guide and insights wall
The information collected allowed us to create a blueprint of all the users' journeys, summarizing each person's actions and responsibilities at each stage of the process, and the consequence of each action at the next stage.
Blueprint
Ideation
MOSCOW and userflow
Constant contact with the three groups meant that answers to questions that arose during the design process could be quickly obtained and reviewed with everyone involved.
This was followed by the ideation process for the scheduling solution. In this stage, the entire UX team and development team were involved, since there were features developed for the modules that could be reused here with certain adjustments, and in addition, understanding the architecture of the system is fundamental to building it. Throughout the process, all groups were available for questions and confirmations.
Based on the possible solutions presented, I used the MOSCOW method to prioritize the solutions to build the MVP (Minimum Viable Product).
Ideation dynamics and MOSCOW
Based on this definition, the user flow of the three groups (shown below separated by color) could be constructed as follows:
User flow
Prototypes
Design System e system features
During the reseadefinition of the unloading module, the Loadshark software's Design System was still under construction. Up to that point, it had the basic information for building the components (such as colors, fonts, buttons, and header), but it still lacked a clear definition of more complex components, their features and usage rules, as seen below.
Loadshark software's Design System
Nevertheless, the Design System was essential for building the prototypes. By involving the Product Owner (PO) and development team in some of the ideation dynamics, prioritization and definition of flows and features, it was possible to overcome the shortcomings of the underconstruction DS.
Prototyping
To build the prototypes, three main flows were defined: Planner, Carrier and Operational.
Carriers were able to select a scheduling block and fill out the form with all the necessary documents. If necessary, this data could have been edited on the screens immediately (for example, if the driver making the delivery was replaced during the trip). As exemplified in the screens below:
Schedules carrier view
Form carrier view
The operations team monitored the daily schedule via the Scheduling screen and consulted relevant reception information via the Forms screen (both pre-filled by the carriers). A small panel with key figures had been added to this view. As exemplified in the screens below:
Schedules operational view
Form operational view
The planning team monitored real-time data and changes throughout the process. A small panel with key figures had also been added to this view.
Schedules planning view
Form planning view
Starting from this common point between the three groups, it was possible to define the responsive flows for each user and make the necessary adjustments during the usability tests and, in a second step, to make improvements based on the accumulation of data from the actual use of the tool.
Workflow
The solution chosen was establishing two central information screens: the first with all the documents needed to carry out the process, and the second with the scheduling cards for each day (containing information such as location and time). Both screens could be accessed by all groups, but with customized views and actions for each.
Results
The implementation of the new module had brought several benefits to the planning team:
Reduction in the number of e-mails by 90%;
Easy scheduling and rescheduling of loads;
Reduction in overtime paid to carriers by the scheduling company;
Better schedule management with downloadable reports;
Horizon view for scheduling available reception windows;
In the first month of using the module, the planning department saved R$ 57,000.00. This figure was expected to increase in the following months.