How to Choose a Terminal Operating System
Director of Port Solutions and port and terminal operations specialist Richard Willis outlines the key steps in choosing a Terminal Operating System (TOS) in this latest insight:
This is a short introduction to the key steps recommended in selecting a TOS for a cargo terminal operation – a long-term strategic decision for any operator.
Firstly, how NOT to choose a TOS – please DON’T –
- Rush into an ‘executive decision’
- Buy the most expensive and hope for the best result
- Choose from the sales presentation
- Underestimate the cost and risks
Doing a poor job of selecting and defining a TOS project can cause significant operational and cost risks – this is mission-critical…
Some may suggest selecting a TOS is like buying a car – where most of these ‘don’ts’ can work out ok – but the basic understanding of how a car should function is well understood by buyers and, thus, supplied by vendors as a foundation, onto which various specialities are added.
This is not so when buying enterprise-level software - ask a terminal operator to describe a TOS and there are many common themes, but rarely the same answer. Every port, terminal, rail operator or dry-port has vital differences, which may be small or large, and TOS vendors build and sell products to fit parts of this rainbow spectrum.
The task of selecting the best-value, most effective product and long-term partner for your operation needs the application of a thorough method, not just gut instinct.
The same key steps for exploring and understanding the best option apply to all projects, but the effort and detail required for a large automated or multi-cargo terminal is many times greater than choosing a stockyard system for an empty container depot. This approach can be tailored to fit.
Form the Vision – What and Why
What do you want to achieve? Envisage how the end-result might look – not yet a definition, but a general target.
Why are you considering this? Cost efficiency, improved customer service, increase traffic capacity, regulatory demands, expansion, modernisation…. Where is the pain you wish to soothe?
How would this system fit with your business? IT strategy, business division interaction, ownership.
This forms the foundation of the Business Case for the project, to which further costs and refinement can be added once known later in the process.
Document the Requirements
Start with a high-level view on what the software will need to cover, adding as much specific detail as possible. This might be difficult as you may not yet have an understanding of what a TOS can do – with software and hardware automation almost anything is possible (given enough time and money) – but refining the requirements during the process is typical as learning improves from exposure to the vendors’ products.
Business Process Mapping (BPM) is a great way to document and understand more widely how your operation works presently. This helps identification of vital processes to be preserved in the TOS (often Customs or customer-related), and where efficiencies could be made. The output from this exercise is very useful for TOS vendors to quickly understand your needs too, particularly if any customisation might be needed.
Think as broadly as possible and assume nothing during the requirements documentation exercise – remember to include that your car must have four wheels – and each wheel shall be circular…
There are functional requirements – what the TOS must be able to do – like automated yard planning for various criteria, process EDI output in real-time, or automate AGVs
There are also the equally important strategic / non-functional requirements – what the TOS and its supplier must ‘be’ – server platform, supplier experience/stability, support response time, networking, delivery timescale etc.
Pay special attention to areas you know are particular to your operation that may not be common elsewhere – typically, Customs or regulatory needs, EDI formats, Management & Customer Reporting – or where multiple cargo-types interact (stuffing/stripping, or processing/PDC)
[How to define requirements for a TOS will be a later post – it’s a big topic]
The requirements will eventually form a reasonably long document or table, which is the primary means of communicating the client needs to the suppliers. Remember, that the vendor reads the requirements whilst thinking how their product can fit this need, even sometimes in the most minimal manner, so try to be clear and precise in creating these requirements to avoid ambiguity or vagueness later.
Having scripted the requirements in detail, do be prepared to modify them during the selection process – you are buying a product that has set procedures and functions built up from many years’ experience of delivering similar projects – so do take advantage of the vendor experience and adjust the details of your requirements or process to fit what is offered by your preferred supplier.
Explore the Marketplace
Using the requirements, spend a few hours searching for suitable suppliers online, or ask trusted partners and colleagues.
Gather any suppliers that may be able to deliver in the broad area of your requirements functionally and strategically. Pay attention to existing customers/reference sites that may be similar to your needs – a useful guide to stability and versatility. But, don’t discount some newer suppliers, or even a bespoke software house if your needs are really different.
Do download brochures and spend a little time forming a view on which suppliers to add to your contact list, or even visit a tradeshow to get a good handle on the supplier offering. Generally, try to choose at least five options at this stage to give a span of results.
If the results of the exploration provide a confident short-list of suppliers, then you can move directly to a Request for Proposal (RFP). However, an interim step can be to send out a Request for Information (RFI), providing only a short outline of the requirements to invite a broad range of suppliers to respond with their ideas for solutions, leading to a shorter list for the RFP.
Turn the Vision and Requirements documents into a Request for Proposal (RFP) document to share with your chosen list of suppliers. Include as much detail as possible to enable the vendor to respond accurately, if necessary requesting a Non-Disclosure Agreement to be signed beforehand. This process needs a timeline and may need to be a formal tendering arrangement (as some geographies and corporate rules may dictate) or more informally managed to your own needs.
Analyse Supplier Options
Once responses are received, form a scoring method to compare the various suppliers’ capacity to deliver functional and strategic requirements. Be sure that your vital requirements are more highly weighted.
At this stage, outline pricing should have been provided, which allows the cost-element to be added to the Business Case, leading to a Return on Investment (ROI) and Total Cost of Ownership (TCO) view and a general decision around whether the project has potential to go ahead and be cost effective into the future Don’t forget the internal costs of project/change delivery.
From this analysis, some suppliers can usually be eliminated – leading to a short-list (maybe 3 or 4 suppliers)
Feel the Products
The vendor responses to the written requirements document leads onto a formal scope of works, but a true picture and assessment of the TOS product functions requires a detailed demonstration and interaction with the supplier. This is a vital stage to explore the requirements in more detail and get an (important) instinctive feeling for the TOS and for the vendor’s staff.
This demonstration should be based around a series of scenarios taken from your requirements to illustrate that the product can fulfil the needs and understand the ‘user experience’ (a vital factor in change management later on). Again, a scoring and analysis method is recommended, to allow less-emotional comparisons of the options. Do take this opportunity to get to know the supplier’s strategy and future plans (including a product roadmap) as this is a long-term partnership, so the ideal vendor will be broadly aligned with your own business strategies.
A particular advantage of this demonstration meeting is to test out any special requirements or changes that you might require, discussion any system customisations that may be needed and gauging the vendor capability in doing so. If possible, especially aim to meet with technical and implementation staff who will be delivering your project, not just the sales guy, to make a judgement of capability and confidence in them.
From this exercise, you shall be able to trim further the short-list to 1 or 2 options. A refinement of the requirements scope and proposal/price may be relevant at this stage, particularly to cover definition of any customisation work needed, to get to a final document for contracting.
Choose a TOS!
Arriving at this stage, you should have a clear view of –
A vision for the project – including a workable Business Case
Detailed Requirements Scope - foundation for vendor contract
Assessment of supplier options – leading to a carefully considered choice
So, you can make a confident choice for a TOS and move to contracting with your preferred option.
The effort in this approach is reasonably straightforward and logical, but time and detailed diligence is key, with value being added by acquiring external specialist expertise.
Along the way, you will have gained a view and understanding of TOS functions and the expected impact on your business processes and staff that will occur during the implementation….more on those new challenges in the next chapter…..
Richard Willis is Director at Port Solutions Ltd, an independent consultancy firm specialising in the selection and deployment of technology and efficiency in the ports and terminals sector.