Many Points of FailureBy Trever Scott | Posted 2011-06-16 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
Dole Fresh Fruit chose an infrastructure that provides management with worldwide, real-time access to production and sales information on a common platform.
Many Points of Failure
Things were very different in the past, when U.S. personnel used the term “Dole Hole” to describe the fact that containers disappeared from view when they left on a voyage from Latin America. The containers would only reappear later on a voyage manifest that came off a fax machine. This fax was then entered into the U.S. port system by hand. This architecture had many points of failure. The main complaint voiced by the business users in the logistics organization was the lack of systems stability.
The current Dole application environment consists of JD Edwards’ World product for accounting functions—with the exception of sales, revenue and inventory control, which are performed on JDE’s One World product. Port operations are handled by Tideworks Mainsail and Spinnaker software. Container fleet, compliance and vessel operations functions are assigned to TranShip, a multimodal application from Trans-i Technologies. The transport layer (systems integration) for the architecture is provided by GIS from Sterling Systems.
In the past, we used and supported systems that were different from one country to another. Now there is a worldwide system, which has a very complicated infrastructure with multiple real-time and batched interfaces that operate 24 hours a day. The three main system functions are ERP, transportation/yard management and traceability/equipment tracking
Issues with the hardware and support of these applications and interfaces negatively affected the business, so we needed a better way to monitor the health of the systems. As part of our search, we had multiple conversations with Compuware about its Application Performance Management (APM) solution to determine how it could help resolve our problems. One of the reasons we chose Compuware is because it was willing to participate in a joint venture with us. We each agreed to supply consulting teams that would work together on-site for six months. During the project, the teams met every day, which helped them understand the root causes of our instability problems.
We wanted an intercompany solution, so we distributed the expertise of the Compuware team across our supply chain. We had a Compuware consultant who was fluent in both Spanish and English. That was essential because our offshore infrastructure team, which supports the local data center and some of our infrastructure and telecommunications, is housed in Costa Rica. The offshore team was involved in daily phone calls and video conferences, but we believed it was important for the Compuware consultant to visit the facility. We scheduled one week of activities for the consultant in Costa Rica, where he worked with some of the local infrastructure technicians.
That worked out so well that we extended the trip to four weeks. It helped bridge the gap between the technical infrastructure and our application architectures. If we hadn’t done that, it would have taken much longer to resolve our problems.