The next shiny software upgrade will make it all better – right?

The developed world is gloriously full of sparkly new things to tempt us.  On balance, that’s probably a good thing as we need consumer demand to keep our factories, shops and service businesses open and, in turn, keep us all in work and able to buy the sparkly new things.  I think you need to take care though.

A few weeks ago I was driving up the M5 motorway from one customer in Somerset to another in Lancashire.  I stopped off in the midlands to get something to eat and (somehow!) found myself outside the dealer of my favourite motorcycle manufacturer checking out the latest models.

One had active suspension with automatic anti-dive and a stability control system that detected how far over the bike was leaning and adjusted the braking accordingly.  Amazing stuff.  After a few minutes, a friendly chap in an orange polo shirt came out and asked me what I was currently riding.  When I told him, he was quick to inform me that the newer model had more advanced fuel management and a bigger petrol tank and that I’d be able to go about 20% further between fills.  For motorcycle touring, this is a fairly persuasive point!

As I stood there wondering whether to blow a big chunk of disposable income on being able to ride 20% further and have less, umm, ‘dive’ I got to wondering about all of the other technology we buy and specifically the Enterprise Resource Planning products that my company works with.

Our customers are under constant pressure, much of it self-inflicted I have to say, to upgrade to the latest versions and exploit the latest new features.  Of course, some of these new features can deliver enormous business benefit if used appropriately but the same is also true of the many unused features that reside in the older versions of software our customers already have.

In my working life, I would estimate that around 75% of my customers tell me that they’ve invested in complex and highly capable software but they aren’t really using it to its full potential.  The studies we do of their business processes generally bear this out.  These are often the same people and businesses who pressure themselves to upgrade.  After all, if you’re only using 5% of ERP 1.0 then it makes perfect sense to upgrade to the ‘20% more functional’ ERP 2.0 and only use 4% of that, right?!

I’m not saying for a second that we shouldn’t ever change our motorcycles or ERP applications.  Things like supportability, regulatory factors and those new features that really are perfect for your needs all play a part.  But I’d argue that the decision to upgrade shouldn’t be close to being your first recourse.

For less than the cost of an upgrade, you could retrain whole sections of your staff, carry out a process overhaul and identify those most in need of your attention. You could even add on some sparkly complimentary products to manage specialist tasks and deliver some change. Just think how happy the board would be at the savings!

Back at the motorcycle dealer, I eventually wandered off, driven by the distraction of hunger and a slight feeling of melancholy.  That night, after a bit of hotel-room internet searching I discovered an auxiliary fuel tank system for my bike that will increase its range by 25% and cost an awful lot less than a new bike.  It even came with a fun afternoon in the garage pretending to be a proper mechanic while I fitted it.

I’m going to use the money I saved to actually go to some exciting places on my bike.  There’s only so much time you can spend on the M5…



Andy Bell


Andy started Vanilla, along with Jason in 2009 . Despite being something of an ERP ‘geek’ he is passionate about not complicating things and delivering what the client needs.

Andy likes to split his time between working with his customers on projects, running the business and supporting Abigail with new business development.

If you need Andy’s assistance,  click here to contact him today

Elaine’s story: Exceeding user expectations

In 1993 I worked for a well-known shipping company and was stationed in Singapore, implementing an IT Business System across South East Asia.  The Internet had arrived, but was not yet reliable and businesses spurned it in favour of dedicated point-to-point leased lines for data transfer.

These were the very early days of EDI, and the Port of Singapore Authority (PSA) was in the forefront of developing standards for the exchange of electronic messages with customers and ship operators. They could see that efficient data handling was crucial to their mission to become the biggest transhipment port on the planet. However, the major ports were all in keen competition and each one was intent on designing their own systems. As a result a right royal mess of disparate interfaces and standards prevailed, and so for smaller operators, and those who were unwilling or unable to develop compatible systems, a portal to the PSA was available into which, as a last resort, container numbers and other relevant data could either be manually typed, or files in a special format could be uploaded.

Our largest ships of that time on what we called the Far East Trade routinely called at Port Klang in Malaysia to exchange cargo before the main call in Singapore.  Strict deadlines for the submission of cargo manifests were enforced by the PSA, but the short transit time from Port Klang to Singapore – around 24 hours – meant that some dispensation had to be given since the data were not available until just before the ship sailed. But the pressure to get the data submitted was enormous.

I met Elaine during a routine visit to Port Klang whilst becoming familiar with my patch. Part of Elaine’s role was to ensure that an accurate container loading list was sent to the Port of Singapore Authority (PSA) before the deadline set by them, based on the ship’s arrival time in Singapore. If the transmission was late then the ship could be delayed, and that meant big trouble. There would inevitably be a knock-on effect on the schedule, and the ship’s schedule was sacrosanct.

I was chatting to Elaine about her job whilst at the same time wondering why she looked so exhausted. It turned out that for every ship that called in Port Klang, she was single-handedly reconciling a printed list of several hundred container numbers sorted by location number from the local Port Authority, with another list provided from the ship operator, but sorted by destination, before entering them into the PSA portal. This took her several tedious hours of checking lists and crossing out matching items for each ship and, as the ships normally departed late at night, this kept Elaine up until the early hours of the morning two or three times a week – a fairly gruelling schedule.

I asked Elaine if electronic versions of the printed lists were available from the relevant parties. She wasn’t sure but when I got back to Singapore I made some enquiries and it turned out that they were easy to obtain, she had just needed to ask.  I asked them to provide some file samples, which duly arrived.

Now remember that these were the good old days: no coding standards, change control committees or mandatory software development processes to speak of.  Whilst the “real” software developers were building huge and unwieldy applications on IBM main-frames or AS/400 boxes, bright and IT-savvy employees with either a burning desire to improve their lot, or possibly with too much time on their hands, took it upon themselves to fill the gaps left by monolithic corporate IT systems with their own little home-grown PC spreadsheet and database applications.

For my own enlightenment I had just bought a version of Microsoft QuickC, a self-contained development tool which ran under MS-DOS (look it up!), had no inbuilt database connectivity or networking capability, and was generally extremely limited in functionality. But it did allow the deployment of code in standalone executable binary files, and in common with most computer languages was pretty good at reading and writing data files and sorting data. For this task, that was all I needed to be able to do.

I would blush at the code now, but I knocked up a QuickC application over a weekend that took the two lists, sorted and merged them and output a file that could be directly uploaded to the PSA through the portal. On my file samples it was able to do this in under ten seconds.

I took the opportunity of another trip to Malaysia to see Elaine and show her the software. She didn’t get it at first. We test ran the program a couple of times whilst I went through the steps. Then she went very quiet and I saw a tear rolling down her cheek. She got it now alright. Those late nights were now a thing of the past.

Now, I would love to be able to say that my career in software development has been filled with many moments like this.  It hasn’t. Users have become more sophisticated and more demanding and rightly so. But occasionally we are able to pull something off which greatly exceeds their expectations, and that is immensely satisfying.

Which is why I love working as a software developer for Vanilla Solutions.

JohnDuffy_squareJohn Duffy

Senior Technical Consultant

John joined the Vanilla staff in 2015, having worked with us as a freelance developer for several years previously.  John’s passion is turning a customer’s specification into a working software application and his skills with PL/SQL and .NET reliably produce results that exceed customer expectations.

If you need John’s assistance,  click here to contact us today