Building applications that really support the daily work

FEATURE – Technology should help people in their work, and it is with this in mind that the general manager of this car preparation center decided to learn to develop Apps.

Words: Morné Fourie, General Manager, Halfway Production Centre – Johannesburg, South Africa.

They say that perhaps the biggest part of a lean transformation is the opportunity it affords to develop the capabilities of people. I might just be a living example of this, considering that I am a mechanic by trade who is now building apps to support our daily work and experimentation at the Halfway Production Centre.

HPC won’t be new to Planet Lean readers (back in December 2017, we shared our story here), but for those who don’t know us, here’s who we are in a nutshell. We receive vehicles from the Toyota factory, we inspect them and store them in our stock yard (with capacity for 150 vehicles), and prepare them for delivery to the customer for two Halfway car dealerships in Johannesburg (Fourways and Honeydew).

Preparing vehicles purchased by the customer means installing accessories like tow bars or nudge bars. We work on a takt time of 30 minutes. We have 11 stations that are manned by 11 fitters and one team leader. Their sequence is set in a one-way flow, with each station pulling the next vehicle in line when ready.

When we receive a requisition form from our dealers requesting a vehicle to be prepared, we generate a work order and invoice for each vehicle that is delivered. We have a visual “Washing Line” that is split into equal slots for each dealership: the paperwork is placed in a Kanban where it is planned and launched into the workshop. It is then checked for accuracy before the vehicle is marked as complete – quality is in the bay, not at the end of the line. Once complete, vehicles are delivered to the dealerships by means of a truck (we deliver around 300 a month).

Thanks to lean thinking, we have been able to turn around the organization in just over two years, with the objective to achieve 100% complete and accurate vehicle preparation for customer delivery in a known reliable time. We have done this by:

Focus on quality first, then speed, then cost.
Have in-line quality, with no quality control at the end of the line.
Monitor using metrics that matters. We keep targets relevant by looking for the gaps between actual and standard.
Spend time to understand problems and develop countermeasures.

WHAT DOES ADMIN HAVE TO DO WITH IT?

We stabilized the processes at HPC and achieved reliable levels of quality and speed. From the time the vehicle is launched into the process, we are now able to finish preparing it in 311 minutes. Over 90% of the vehicles requested are delivered the same day or the next day. This is a process that took up to five days (maybe) before we introduced flow. Once we created stability, we started to ask ourselves what would come next. It quickly became clear that to get to the next stage of our transformation and deliver vehicles faster to our customers, we’d have to improve the flow of information as much as we had the physical flow.

A pain point for us has always been the process of receiving a batch of 10 vehicles from the ferry agent daily and taking them into our stock so that we could work on them. The administrative tasks of identifying the vehicle and loading it onto the Dealer Management System, then inspecting it for damage and moving it to the storage yard, took a staggering 320 minutes to complete. The inspection and reporting of damages was the main cause of this long lead-time (it’s an important activity that ensures the ferry agent takes responsibility for any damage on cars we receive from the manufacturer).

There were three main problems with this process:

The ferry agent rule is to get damage reports in by 12 PM. As we receive an average of 10 vehicles at a time and we have from 8 AM to 12 PM to report any damages, we needed to process each vehicle in 24 minutes if we want to do them one by one. We tried to check all vehicles in that time, so that any damages found could be reported and all faults repaired right away (without the risk of the claims being rejected). However, with a total process time of 33 minutes per vehicle, it was impossible for us to process more than seven vehicles by 12. We compromised one-by-one flow by batching the checks and reporting, which was only 21 minutes per vehicle on all vehicles first so we can check them all by midday. The system we were using forced us to do so. And then we carried out the remaining processes afterwards, which meant the first vehicle became available to the workshop only 320 minutes after it started.
Reporting damages was an inconvenient and time-consuming process that went through a lot of systems to report a problem with the car. It added a lot of extra work: because we were using a desktop-based system, the worker had to use his personal device, then walk back to his desk, plug in the device, download the picture of damage, resize it (it was typically too big to attach to an email), and email it. You can imagine how, when there are five or six damages to report on a vehicle, the work tended to pile up, with obvious consequences on the quality of the work itself. A delay on one vehicle would also create a domino effect on other vehicles.
Many walks to the same vehicle to go from our stock yard to the office and back.

We realized that the systems we were using were inhibiting our information flow and considerably slowing down the physical work.

Our first thought was to approach the provider of our dealer management system to ask them to develop a gateway to push data automatically to our stocking function so that we wouldn’t have to type it all in. For nine lines of code, they quoted us R50 000 (around €3,000) and a three-month lead-time. Not what we had in mind at all.

We approached a second IT provider we use, which supports our used car sales operations. Their functionality included a stock count system that incorporated bar code scanning and replaced our previous handwritten process. They are a different generation of software house and much more responsive to requests for additional functionality. They were very enthusiastic and started working on the solution right away. They gave us a prototype in five days, but we found a number of problems with it: checks were not organized by model and the specs were incorrect. We reported these issues, and they reworked the product. Four days later they gave us a new version. This was better and matched our sequence, but the data was presented in one long string.

We tried to use the function anyway, but after the second vehicle we realized that the checks were hard to follow: every time you looked up at the vehicle to inspect it, it was near impossible to find where you were on the long string and had to scroll up and down a lot. There was no way for us to record damages when we found them. We went back to the supplier, but they told us they were busy with a big project now and would only be able to help us in a month’s time. This is not a typical IT environment: with a shared resource, getting a place on the priority list is often a challenge.

We had tried two routes: one was prohibitively expensive and very slow, the other was willing but committed to work that had higher priority than our work once it wasn’t completed in the first window they had available to help us.

KNACKING ON HEAVEN’S DOOR

It had become clear to us that off-the-shelf solutions wouldn’t give us what we required, and that we would have to do it ourselves. However, becoming a programmer would take me two years before I could start and would not be scalable beyond myself.

That’s when we heard of Knack, a program that allows you to build apps without knowing how to code. It uses a simple interface with drag & drop and different choices of templates to assist you to build the product you exactly need.

Knack was introduced to us by digital expert Mike Moore, who supported me as I took my first steps into app-building. His idea of “ditching the spread sheet” seemed to be the solution to our problems. So, I got a free-trial on the program, watched a few tutorials and looked at some examples of use.

Knowing exactly what our problem was, I immediately started to develop an app that would support the check-in process (when we receive cars from Toyota South Africa). Through tutorials and Skype calls with Mike, I was able to build an app with minimal capability that reflected the reality of HPC. We gave it a try when it was nearly ready, and it worked quite well. There were some issues with it, of course, but this first attempt showed us that with some more understanding and practice with Knack, we could use the program to build apps that supported the way we needed and wanted to work.

I attended a Knack three-day boot camp presented by Mike Moore to understand how to really use the program and to learn a few tricks. It was a tiny investment, and it was completely worth it: after the boot camp, I built the second version of the app with the intent to use it as soon as possible. This version was a lot better and all the kinks were ironed out. In designing it, I involved the people doing the work much more than before. We played around with the app quite a lot, to really understand how to build it in a way that would truly support their work as it happened in the workshop.

It didn’t take me long to realize how powerful Knack is: after learning to use the program and experimenting with the work, I was able to build a digital system that could do what we needed in just three days. Thanks to Knack, we no longer had to complete all steps manually, transfer files from devices to PC, and so on. We invested in a tablet, which Knack automatically connects to our PC. The effects on the process were immediate, and the results came quickly, too.

We knew that if we wanted to get all 10 vehicles completed (loaded on the Dealer Management System, inspection done and faults reported) one by one to make them available for the workshop right away without the claim being rejected, we would need to do all 10 in 240min (from 8 AM to 12 PM). With Knack, we were able to build an app that not only assisted in making the loading of the information on the dealer management system simpler, faster and complete, but also made information available for use in a mobile form at the vehicle inspection. This meant that the information didn’t have to be copied over and over again between processes, but was one process. Knack allowed us to report the damages linked to a particular vehicle at the time they are found, without having to move the information over to another device or perform any rework on the information. We reduced the information step from 12 minutes down to 5 minutes, and the damage inspection and reporting step down from 21 minutes to 4 minutes. Therefore, the process time per vehicle went from 33 minutes to 9. Now we could process almost 27 by 12, should we ever need to, and without the claim being rejected.

Before we knew it, we could reshape the work in the best way, extending the use of flow to our admin functions. Avoiding batching is in our culture and, by taking away the stumbling block of the damages checks, Knack has enabled information to flow smoothly at HPC.

Kaizen was already done on the physical side, but now we can also do it on the information flow. Within a week or two from starting to use the app, we experienced a kaizen “snowball effect”: being able to tackle damages so fast meant that we began to change the whole value stream – we went past the reporting problem and into a wider view of the process. Knack helped us to evolve in our lean journey. The app has grown to incorporate other functions that were time intensive and now spans most to the functions relating to the scheduling, tracking and parts stocking and replenishment. We have certainly made a lot of headway in ditching the spread sheets.

As I see it, when talking about improvement the majority of lean folks refer to production. But what about admin? It seems to me that this function is often neglected. At HPC, we certainly neglected it. I couldn’t tell how much rework we had in administrative processes, but now I can – and with that comes the opportunity to improve it. People doing the work can now become team leaders and managers, because on-boarding new hires has become much easier and requires less time. Now we can move people around, expand our business, adapt to changes faster. Using technology to speed up the flow of information has opened a new world that we had been avoiding: admin is the next frontier for improvement at HPC. I have even started to go on admin gemba walks!

TECH FOR THE PEOPLE

It’s incredible to think that I have been able to design this app without any coding experience. The best part about it is how quickly we can adapt its features, whenever we find a better way to use them in our work. I can add, change and move functions and features in minutes (sometimes in seconds), using the feedback I receive from the people who use the app: it’s happened a few times that a few minutes after using it, a worker came to me asking to move a button somewhere else on the page to speed up or simplify the usage. It’s real-time on-the-spot kaizen, which encourages people to suggest ideas.

Because we build the system forour people, rather than forcing them to work within that system, we haven’t experienced resistance in getting this new technology-based approach off the ground. We don’t automate things that people are doing, but use IT to support their work and remove the waste that gets in their way.

Our people have immediately seen that the app would make their work easier and more meaningful, removing distractions and stressful steps. There won’t be any waiting, there won’t be annoying phone calls, there won’t be any walking back and forth between the office and the stock yard. Combined, our changes resulted in 18 workdays worth of time saved per month, every month!

There is no reason why people should be afraid of technology and automation, so long as these are tools at their disposal and help them to make the work easier. Technology remains a tool, and without understanding the problem you have and the situation around you, a tool is pretty much useless. It’s the same when you are trying to fix a car: if you don’t know where the problem is, all the right tools won’t be able to fix it. In Knack, we found the solution that could fix the problem we learned we had. If there is one thing that our lean journey to date has taught us (we are still new to this, having only done it for two and a half years) is that it’s not about the solution, but about the problem. If you don’t own the problem, you won’t sustain the solution.

THE AUTHOR