Mazda’s e-Port system is revitalising compound system management. Malcolm Wheatley looks at how, from a modest investment, the manufacturer has achieved real-time visibility and boosted labour productivity with predictive scheduling.
Visit one of the American ports through which Mazda imports vehicles from Japan and you’ll Vlikely see a slick new port compound management system in operation. Developed internally by Mazda’s North American Operations organisation, after a process of exhaustively benchmarking comparable systems in use within the industry, the system–dubbed ‘ePort’– has impressed Madza executives with its enhanced usability and functionality.
They reckon a modest investment in software code and new hardware has enabled the business to leapfrog an entire generation of port and compound management systems, delivering both industry-leading best practice as well as filling critical gaps in its supply chain management processes. Vehicle movements, for instance, are now logged and updated as they happen, using Motorola handheld scanners running a mobile web browser. Relayed from the vehicle movement point to the port operator’s server by a cellular wireless network, the movements are then instantly transmitted to Mazda’s Irvine, California headquarters data centre via a high-performance private network employing Multi-protocol Label Switching (MPLS) telecommunications technology. They are then accessible to Mazda’s commercial and logistics systems, providing unprecedented real-time visibility into port-based operations.
The system, says Mazda, is a major advance compared to previous systems. For instance, the training and deployment costs are reduced through a simple browser-based interface. And the use of mobile technology, located at the point of movement, boosts labour productivity and cuts sharply the interval between a vehicle being moved and the system being aware of that movement. Welcome though such improvements are, they are essentially fringe benefits. The system’s real worth comes in its ability to accurately provide answers to questions that, until recently, could only be roughly estimated or guessed at.
When will a vehicle be ready to leave the port, for instance? And having left, when will it reach the dealer? The answers are now available not only to Mazda’s port employees, contractors and dealers more quickly, but are also available at a higher level of accuracy and granularity than before.
“We’ve talked to others, and we think that what we’ve got here is class-leading in terms of its ability to schedule vehicles through our port operations,” says Scott Mize, Mazda North American Operations’s national transportation manager. “And the jewel in the crown is the scheduling part of the system. It doesn’t just schedule the vehicle through the various operations that take place at the port, but also provides us with a predictive capability, too. Combine that with a thirdparty predictive tool that we use for the port-to-dealer journey and the result is that we can predict, with a high degree of accuracy, when a vehicle will reach its intended dealer.”
Rescheduling the past
The story begins back in 2009, explains Mize. Historically, Mazda had relied on an elderly 1980s-era port management system, which ran in batch mode on an antiquated IBM OS/2 system–a platform long since superseded by modern operating environments.
And while the port management system itself was adequate when first developed, its relevance after the millennium had come into question and it had mostly been abandoned by 2006. Instead, Mazda decided to rely on port vehicle-handling contractors’ systems.
But while they offered newer and more capable technology, Mize relates, relying on contractors’ systems wasn’t without its drawbacks. They were all different for a start, meaning that economies of standardisation were lacking, even though the core operations in question were identical. What’s more, interfacing was made more complex by the number of different platforms on which these replacement systems ran–some ran on OS/2 again, but others used AS/400 and Microsoft Windows platforms.
Instead of the desired ‘one version of the truth’, there were as many versions of the truth as there were systems–with few pointers as to which perspectives were correct. And so, explains Jim DiMarzio, Mazda North American Operations chief information officer, a decision was made to look for an alternative approach.
A small working party was set up with a threefold mission: identify the features that Mazda might be looking for in an ideal system; look at the kinds of systems that other OEMs were using; and survey the computer software market to see what third-party packages might be available. But in the process of travelling around the country and talking to other carmakers and importers, says DiMarzio, several things quickly became clear.
One was that the calibre of vehicle scheduling within port management systems was an area of weakness–not just in Mazda’s approach to port handling and dealer promising but in those of other manufacturers too.
“Scheduling is really the most important piece of the puzzle, but it hadn’t really been addressed before,” says Mize. “Historically, average lead times have been used to estimate key dates and we at Mazda were no different. So we’ve never really been able to predict the date of leaving the port with any accuracy or, for that matter, the date of arrival at the dealer. And to achieve that capability, we needed to actually schedule, rather than just apply average lead times.”
Another frequently encountered weakness appeared to be the granularity of the data points used in the scheduling and vehicle-tracking process. “We only saw one manufacturer that claimed a scheduling capability that was anything near to what we wanted and even then not to the number of vehicle data points that we felt we needed,” adds DiMarzio. “We wanted to collect data on vehicle movements at 15 data points–while most manufacturers were collecting at just three points: vehicle arrival at port, dispatch, and quality control.” Similarly, the systems that Mazda observed seem to provide inadequate detail for frequency of update and the associated granularity of time within the data point recordings.“What we saw were manufacturers collecting data at ‘date stamp’ granularity, whereas we wanted ‘time stamp’ granularity,” says Mize. “We wanted to know the actual time that an operation had been completed–not just the date.”
Finally, says DiMarzio, talking to other manufacturers quickly revealed that none of them were using a third-party package for port handling.“Even Oracle lacked a complete automotive solution,” he explains. “While it had parts of what we were looking for, it didn’t have everything–although we understand that its capability has evolved since then.”
Success over speed
The only way forward seemed to be to develop a new system in-house, says DiMarzio; one that would leverage the very latest cloud software technology. Getting the go-ahead to start work was straightforward. “We didn’t need to go to Japan for approval or funding; the expense was manageable internally,” says DiMarzio. “Using a combination of offshore and onshore programming resources, the cost of software development was pretty low and costs about the same as the investment in handheld terminals, server capacity and data storage.”
Written largely in the open source programming language Java and relying on ‘off-the-shelf ’ reusable components where possible, the ‘front end’ of the system is entirely Java, while what DiMarzio calls “the heavy lifting”–namely scheduling–is done in batch mode, using stored procedures. But it is, he stresses, “batch on demand, not overnight batch runs”. But the formal scope of the ePort system, as the name suggests, is the port compound and the operations carried out within it. Once a vehicle has left the port, technology from tracking specialist ICL Systems takes over.
To predict the arrival date to the dealer, ePort pulls in known transit times between location pairs from ICL’s extensive database of actual journeys. This time is then added to the calculated scheduled date of a vehicle leaving the port to produce an estimated date to the dealer–a date that is more accurate than the rough estimates that preceded it. The system is currently in operation at two of Mazda’s four entry ports: Jacksonville, Florida, operated by contractor Amports; and–as of early August–the Tacoma, Washington terminal operated by the Auto Warehousing Company. While implementation went flawlessly, the power of the new system still caught executives by surprise. “One of the first data collection points is the arrival of a vehicle from a boat,” says Mize, “and when the first boat arrived we began seeing vehicles appear on the system as they were being unloaded: we were watching them leaving the boat and could see them appear on the system in real time, not two days later as we were accustomed to. Even though we were expecting it, it was still a powerful surprise.”
Mazda’s plan is to add one new port each quarter until all four ports have migrated onto the new system. The emphasis is on a successful migration, rather than a fast migration. “We want the contractors to be completely aware of everything that they will need to do: they are having to migrate from their system to our system,” DiMarzio explains. Throughout the design and development process, Mazda has worked hard to keep contractors ‘in the loop’, including them in reviews and demonstrating new pieces of functionality as they became available.
“We also have a policy of involving facility managers in the launch of the previous facility to switch to the system, so that they can understand how the launch is going to work,” notes Mize. “So far, it’s been very smooth. We’ve had no complaints as to the operation of the system at all; from the handheld scanners to the desktop systems, it’s all worked well. A lot of the contractors were very worried, particularly about the handheld dimension but, in fact, the feeling seems to be that they work faster than their previous technology, not slower.” Long term, the system offers contractors several strategic benefits, Mize adds. “We’re taking a burden off contractors. They’re smaller than we are and mainly regionally-based and the move to our system makes the technology they’re using more maintainable and easier to improve.”
The move to a single system also offers benefits in terms of standardisation and contractor management. “Before, different contractors used to measure supposedly identical data points in subtly different ways,” Mize says. “Now it’s standardised, so we can really see how individual contractors are performing.” Providing further insight into contractor performance is a nine-point ‘dashboard’, highlighting such measures as vehicle inventory, dwell time, vehicles ‘on hold’, scheduled parts required and so on. And within 2011 this dashboard will also be available on executives’ iPhones, complementing the existing ability to send ‘alerts’ to them in this way. With the project in roll-out mode, the benefits it provides have become clear although, as DiMarzio points out, a formal return-on-investment calculation isn’t on the cards. “The justification was really all about improving business processes,” he explains. “We were not the system of record, which was causing problems as the data wasn’t being held here. There was no standardisation or scheduling and the slow speed of response was causing problems. Everything said do it–so we did.”
And the results speak for themselves, stresses Mize. “We’ve delivered on the standardisation and scheduling agendas, which was a big thing. And we’re the system of record. And we’ve got real-time visibility, plus dashboards. And we’re giving our customers and dealers a more reliable and consistent estimated time of arrival. What’s not to like about all that?”
