In the last article (see “Changing Software – Do we really need to change?”) we considered the question: do we really need to change our software? Maybe it’s holding back our progress, the level of support is not what we expect, or perhaps there is an alternative that might be better suited to where we want our business to go in the future.

Assuming there are some doubts about what we already have is the best for the business, the next stage is to investigate alternatives.

Before starting however, it’s good to be aware of some of the more general potential pitfalls associated with a change in software provider (rather than, at this early stage, technical implementation risks), in order that precautions can be taken to minimise the risk of them happening.

1.  Disruption to operations – it will be necessary to have both an extensive implementation plan and training program defined well in advance, ready to accommodate new ways of working

2.  Existing (inefficient) ways of working continue – for example, if one of the benefits is to come from replacing spreadsheets, then users need to be on board with the changes from the outset – the easy option is for a disenchanted user to continue with what is most familiar

3.  History gets lost or distorted – it is essential that all the valuable information accumulated in the old system is carried across in full, accurately to the new system

When looking at possible replacements for existing software, using the following methodical approach will assist in ensuring the best choice is made from what is currently available.

Next needs to be drafted a Software Requirements Specification, along with an importance ranking to assist when filtering alternatives (essential, good to have etc). This is best done again in conjunction the team using the current software, but this time with just a few, maybe more experienced users.

•     As before, but now in much more detail, the question to ask is what does the software need to do? In other words what functions does it need to have in order to satisfy the needs of all stakeholders (that includes the business as a whole, as well as the users)?

•    Decide on the budget available, again helpful when later filtering out alternatives.

•    Reporting requirements need to be specified: who needs what information, and when?

•    Versatility – what future changes can be foreseen (growth, new markets etc) and therefore what support will be needed at a later stage? In conjunction with this, and because the market as well as the organisation is dynamic, a software provider will not only need to be capable of accommodating such changes but demonstrate a program of continuous development, based on a proven, detailed knowledge of their particular sector and its changing needs. A detailed investigation of the software provider will need to take place in the final stages of selection confirm this ability and to ensure that they will be around for the long-term, as a partner, rather than merely a third party supplier.

•    Technology also needs to be defined, a simple example being whether the solution should be cloud-based or on-premise; Android, iOS or both.

•    User preferences – as the current team will be using the new software, they need to feel comfortable with its replacement, without needing an excessive amount of re-training.

The objective is to first make as extensive a list as possible of the alternatives available along with their important characteristics, including pricing, suitability, etc. Regardless of whether it’s felt inclusion in the list is inappropriate or not, at this stage add everything possible, probably most conveniently managed in Excel – this long list will be shortened at the next stage.

Now take a couple of sweeps to end up with a shortlist of around half a dozen alternatives. The first sweep will be to eliminate those that are most obviously inappropriate, one example could be because a mobile app, regarded as essential, is not available. Do however make a note of the reason for exclusion on the spreadsheet – what is essential now may change over time as we look more closely into what is available. Having eliminated the obvious, now is the time to take that closer look in order to produce a short list of no more than five.

Having whittled down the list of contenders, revisit the list of requirements, the objective being to determine which are satisfied and which are not, and to what level. Demos are an efficient way to discover which requirements are met, and for the team, with as many as possible viewing each demo, to ask questions.

However only by actually using the software – which unfortunately is unavoidably time consuming if done properly – will it be possible to tell whether some particular needs are met or not, primarily ease of use (if the software has been used before by a member of the team, or has been recommended, then valuable time can be saved). For this reason a shortlist of 2 or no more than 3 alternatives would be advised.

A simple vendor evaluation matrix such as the following (populated with one’s own specific requirements) will make it easier to compare alternatives:

As many members of the team as possible should be participate in both the demos and the trials. This will be beneficial in terms of getting numerous viewpoints, not only that, each team member can be delegated the responsibility to test particular features and functions thus ensuring more rigorous testing takes place.

When trialling, it is important to use data from one’s own business, thus ensuring that the software being considered will work with not just simple scenarios. Make sure there is enough time allocated to give the software a thorough test, not only in terms of the length of the trial but also the availability of the team – being able to rely on the results of a trial requires an unavoidable investment of time.

Now having a very good idea of what software is best for your business, find out as much as possible about who it is that is going to be your software partner, which will probably be for at least the next few years. Make enquiries of existing clients how good is the level of support they receive, how good was the installation, has the software proven to be as good as first hoped, in other words, has the software that is your first choice met their expectations?

Armed with this additional information a decision can be made with confidence, leaving only the negotiations, which should include establishing the total cost of ownership, not just the software price, a clear description of services, and payment obligations tied to deliverables.

Knowing that the best choice has been made for the business as whole, including those who need to use the software on a daily basis, after this comes the implementation, a procedure that will be covered in a forthcoming article.

Creating solutions for the global maritime sector, CompassAir develops state of the art messaging and business application software designed to maximise ROI. Our software is used across the sector, including by Sale and Purchase brokers (S&P/SnP), Chartering brokers, Owners, Managers and Operators.

 

Through its shipping and shipbroking clients, ranging from recognised World leaders through to the smallest, most dynamic independent companies, CompassAir has a significant presence in the major maritime centres throughout Europe, the US and Asia.

 

Our flagship solution is designed to simplify collaboration for teams within and across continents, allowing access to group mailboxes at astounding speed using tools that remove the stress from handling thousands of emails a day. It can be cloud based or on premise. To find out more contact solutions@thinkcompass.io. If you are new to shipping, or just want to find out more about this exciting and challenging sector, the CompassAir Shipping Guide might prove to be an interesting read.

 

Contact us for more information or a short demonstration on how CompassAir can benefit your business, and find out how we can help your teams improve collaboration and increase productivity.