Navis has adopted a new strategy as part of the Zebra Technology Enterprise Solutions group
Over 200 ports are using Navis software and its sale last year to Zebra Technologies raised more interest and affected more container terminals than any other sale or merger involving a supplier to date.
Navis CEO John Dillon said the sale process kicked off after the company received an unsolicited
offer and its private capital investors recommended appointing investment bankers to advise on a sale. Navis drew interest from “some” of the large terminal operators, but Dillon acknowledged that majority ownership by one would have eventually driven the others away.
At one stage a consortium, with the big terminal operators taking a minority stake, was mooted. Other suitors included major IT industry players, an industrial manufacturing company in the container crane business (most likely Kalmar or Konecranes) and a major US aerospace and defence contractor.
Dillon said the prospect of the latter “horrified some overseas customers” worried Navis would become a bureaucratic government department.
In the event, Navis clients seem largely pleased with its new owner. Dillon described Zebra as a “pretty benign” public company, and Navis is a big enough part of its business to allay fears it might be lost in a business focused elsewhere.
Strategic move
For Zebra Technologies, the Navis acquisition is a key part of its strategy to transition from a printer manufacturer to a wider business that helps customers indentify, track and manage assets along the supply chain.
Navis is now part of Zebra’s new Enterprise Solutions Business Group, which Dillon heads as general manager. Zebra clearly plans to grow the enterprise group’s technology suite, which was formed with Navis, WhereNet and Proveo. Most recently, Zebra has added Multi Spectral Solutions Inc, a specialist in ultra wideband (UWB) technology for communications and tracking, to the group.
Prior to joining the Zebra fold, one of Navis’s strategies was to leverage its core competence in synchronised planning and real time planning control software into applications outside marine terminals. The SmartTurn application that (successfully) brought lowcost planning to distribution centres through the software as a service model was not part of the sale and is now run as a standalone company, headed by Jim Burleigh.
Under Zebra, Navis is focused on bringing in and integrating related technologies to go broader and deeper into asset tracking and management in its core marine terminal business.
Zebra’s vision for Navis is to leverage its dominant role in the marine TOS business to bring other group solutions into the maritime market. For example, Proveo has a vehicle-mounted unit, developed for the airport market, that feeds GPS and other sensor information to a processing
application over a wireless link. This could compete with systems from Sattel and Now Solutions
and be integrated with Where- Net’s RTLS offering. The UWB technology from Multi Spectral Solutions could also be used at ports to track and manage some asset types.
Better integrated
Navis is well placed to expand as a systems integrator, a role Dillon said ports have been forced to take on “working with 10 to 20 small companies to piece together a solution.” At the technology level,
the TOS is the core application most other systems have to integrate with and Navis has the central role in managing that process. Prior to the acquisition, Navis had already leveraged this position to take on the role of prime contractor to the Georgia Ports Authority (GPA) for its ATAMS project.
Zebra has the intent, and a large war chest, to grow by acquisition and Dillon made it clear that gate systems are one area on the radar screen. Noting that this is an area where terminals currently have to work with a “band of rag tag small companies” sometimes “operating out of garages” to get
a solution,” Dillon said he now had the ability to make “appropriate acquisitions” and start to consolidate. This does not mean Navis will become a “soup to nuts” style vendor dong everything itself, but more of a prime contractor with a larger in-house offering, including a new gate kiosk.
This is a departure from Navis’s origins as a hardware-agnostic software developer, but Dillon argues there is a vacuum in systems integration and Navis is being asked “to take a bigger piece as the projects are at risk.” He cited the example of the Euromax project where the initial consortium
failed and Navis was asked to take over everything including programming the traffic lights. As a US$20M company, Dillon said Navis was really too small to take on this role, but he told customers
the goal was to build a stronger organisation with the strength to manage large projects.
This may be well received by some terminal operators, but others might be concerned that technology selection will be governed by commercial considerations rather than best practice under an open standards environment. In the RTLS market, for example, there are other ways ports can use RFID to achieve a RTLS without the expensive reader coverage WhereNet requires.
Dillon responded that Navis needs, and will continue to be open to, other technology partners but the industry wants a major player that can vet technology and have the financial strength to stand behind it. Moving in to fill that role, on balance, provides more advantages and enables Navis to go from being a supplier to a partner, he added.
Going to N4
In the core TOS market, the key development for Navis is the SPARCS N4 application, which will eventually replace the original SPARCS product. SPARCS is now 20 years old and its architecture is problematic for both Navis and its customers.
Dillon said Navis initially developed a vessel planning system to assist terminals, but at some point
that software became the mission critical core application without Navis really being prepared for it.
As a business, Navis was too focused on developing new features and not enough on the overall architecture of its products.
Six years ago, Navis got the message from customers that the product needed to be significantly
better. Navis was the market leader but “we weren’t ready to be a world class supplier,” said Dillon. In developing SPARCS N4, as well as more recent versions of SPARCS, Navis has invested considerably in the software development process itself to address this issue.
SPARCS N4 employs a Java “Rich-Thin Internet Client” technology that can be delivered over the Internet, allowing a range of deployment options, including multi-facility and hosted systems. As a J2EE application, SPARCS N4 is no longer tied to Oracle forms. It can run on virtually any database, but Navis supports three specific options: Oracle; SQL server; and the open source MySQL.
| Ready to automate | ||
Navis is expecting the number To serve this market, Navis has Version 1.0 includes a crane |
road trucks and automated APMT is using SPARCS 3.7 Navis is also working with a |
|
One of the single biggest advantages of SPARCS N4 is its configurability. Most “off-the-shelf ” TOS systems require customisation and a limitation of SPARCS was that most changes had to be hard coded, resulting in the now familiar story of every Navis customer having a different version of the software.
SPARCS N4 avoids this through highly configurable business rules that can be changed/selected by the user. Robert Inchausti, senior director of product management, said with over 200 installations, Navis could identify the 80-90% of operations where terminals can use the same software logic and business processes. However, terminals need configurable options around gate processes, Customs, holds and EDI options in particular and SPARCS N4 has extensive options.
Many terminals will, however, want something extra to out-of-the-box functionality and Navis caters for this with standard APIs for the Groovy dynamic scripting language. Using in-house resources, a contractor or Navis Services, SPARCS N4 users can do “last mile” customisation outside the core application.
Migration path
Getting its existing client base to migrate to SPARCS N4 will be a significant challenge. There is no fixed deadline and Navis is not stopping work on the SPARCS 3.x versions. Indeed, version 3.7 has just been launched - the first SPARCS release built in Microsoft Visual C++. Tom Baker, director
of product management for SPARCS, said it will continue to “be important for the next 5-10 years” and Navis will continue to improve features as well as quality, stability and performance.
For some terminals, the trigger to migrate to SPARCS N4 will be a major operational change, such as automation or implementing yard gantry cranes. Others will find there will eventually come a point where the costs and benefits of the N4 version outweigh staying with what they have. Navis’s approach is to leave the decision to terminals themselves.
SPARCS N4 now has most, but not all of the functionality of the SPARCS 3.x versions. SPARCS N4 1.4 was comparable to SPARCS 3.5 and the new 1.5 version has further developments, including
full rail management capabilities, more EDI support and APIs for gate and appointment systems.
Inchausti said greenfield terminals are typically choosing SPARCS N4 and version 1.6 is coming later this year with further improvements, including support for the new equipment control application, which will replace the current radio server application.
While supporting general cargo is still a major functionality gap, director for SPARCS N4 Services, Andy Clason, said full parity with SPARCS and Express would be completed in 9-12 months.
Navis’s advice to clients is that deciding when to migrate requires analysis of four key areas: functional gap; the current level of CFx (customer funded extensions); costs and benefits; and the customer’s tolerance for risk.
Bigger issue
The functionality gap is closing, but the bigger issue for existing Navis users is that many (if not most) have configured SPARCS with CFx, which are hardcoded changes. Inchausti said many of
these will not be configurable options in SPARCS N4 and, therefore, customers have to address whether they should adapt their processes or use the new customisation tools to develop the functionality or interface they require “outside” the core SPARCS N4 application.
Clason makes the case that the whole enterprise software industry is starting to realise that successful IT projects are tightly focused and, where necessary, adapt procedures to fit available software. Designing software to support manual or poorly automated systems might be possible, but probably does not make business sense.
For highly customised sites, migrating to SPARCS N4 will be more difficult than a “normal” software upgrade as business processes may have to be re-engineered, or new customisation completed,
and the greater the complexity, the higher the risk of business disruption.
The message from Navis is that terminals have to balance that “risk” against the rewards the new SPARCS N4 architecture can deliver. Navis will work with clients to develop risk mitigation plans to help them manage the transition to SPARCS N4 and is calling for lead customers who will get benefits from being early adapters, including greater input on design, direct engineering team support and special pricing.
Market response
At the time of writing, there were five terminals running live with SPARCS N4 of which one, Lyttelton in New Zealand (the first implementation), was an upgrade from SPARCS. Another 11 sites are in various stages of testing and implementation.
One of the biggest successes of SPARCS N4 to date is that it forms a key part of the strategy of DPW, which has 29 out of 44 terminals using SPARCS. SPARCS N4 is running at DPW’s key automated terminal, Antwerp Gateway, and DPW is understood to have abandoned its attempt to develop a global TOS it inherited from P&O Ports..
Other notable successes for SPARCS N4 include a new contract to replace the in-house software at Maher Terminals in New Jersey. This is one of the larger straddle terminals in the world and the contract is understood to be one of Navis’s biggest by value for a single terminal.
In South Africa, Transnet Port Terminals has made SPARCS N4 the “foundation” of its strategy to bring port and rail together into a multimodal transport corridor. Transnet’s national IT operations manger, Mark Wootton, said this requires “a common integrated IT system between the ports and the landside to provide visibility in the supply chain.” This includes a centralised berth planning system that supports a hub and spoke system.
SPARCS N4 will support multiple complexes and the rail and port facilities within each. Transnet expects SPARCS N4 to deliver visibility across its operations and allow centralised planning at a low deployment cost. Major benefits include single source data entry and billing, which in turn supports the transition to single multimodal contracts and a single unified invoice.
Transnet plans to install SPARCS N4 in six marine terminals by October 2009, which is a significant blow to Cosmos, which currently has software in five of them. The sites will be integrated by EDI until the roll-out is complete and the network functions as one integrated system.
Elsewhere, a multi-user rail terminal application is being developed in SPARCS N4 for P&O Trans Australia, a joint venture between DPW and the KFM consortium, to run its five rail terminals across Australia.
Developing SPARCS N4 has been a significant investment for Navis, but it continues to develop other new applications and modules in both the N4 and 3.x versions of SPARCS. It recently announced Live View, a visibility tool that lets the user see all the equipment and containers on the terminal in real time.
Other new developments include a billing application (separate to Express), new versions of SPARCS Monitor and SPARCS Analytics and an online training initiative.
