In a previous blog, we told you about the introduction of Android scanning to our product suite and emphasised why it was now being released and the importance of timing things correctly at Clydebuilt Business Solutions. With that in mind, we are actively looking to progress our software range, and one of the stages in that development is involving you, the customer, our partner in everything that we do.
As our valued client, we are always trying to provide you with the best possible service and products. We already collect feedback on an ongoing basis about everything that we do, but we are about to start our largest ever single undertaking in this respect.
Over the coming weeks and months, we will be contacting all customers, and this is the very first step on that journey. Following on from this, the management team are looking to visit customer sites in order to speak with you on a one-to-one basis and receive any views you may have on our software products and services.
As part of this process, and in advance of those visits, we will be contacting you by email, and by good old-fashioned regular mail, in order to deliver an easily-completed little survey that will allow you to give us some written ratings and opinions. And when we say “easily-completed”, it really is a short form that can be finished in just 5 minutes, depending on how much you have to say.
We thank you in advance for your help with this. We appreciate the time you take to provide us with feedback and suggestions, and we will be actively using it to improve the services we provide you.
So, remember, keep an eye on your email and your letterbox, we’ll be in touch very soon.
Now that we have looked closely at the Pros and Cons of each option, it would appear that the perceived costs, along with specific business functionality, are likely to be the key factors in deciding to go with a bespoke development.
In reality, however, the costs very quickly mount up, resulting in a far larger investment than originally thought. A previous example we gave illustrated a low-end cost of a single developer, and this would obviously increase if more people are employed to complete the project in a timely fashion.
We highlighted the scenario of working to a specific business brief that ultimately leads your company down a dead-end. The worst-case scenario may be that business objectives and working practices change before the bespoke development is even complete, or as it is completed; where would that leave the business?
The truth of the matter is that a software company offers off-the-shelf packages for a reason. The product rarely becomes defunct, as the life-blood of the software house is the production of new technologies, and internally they will invest in research and development to ensure that their product(s) remains useful for clients.
A good software vendor will thoroughly analyse your current practice, and make modifications to their existing package where applicable, giving you a solution that truly fits in with your business. Added to this is the safety in the knowledge that the software system has the flexibility to adapt as your business does; again, these developments are standard for the software provider and will cause minimum trouble for you and your staff.
Of course there should be an emphasis that you must choose your vendor well, but with the right software company providing your solution you should be able to rest easy that you will ultimately get a successful result.
The first major plus point with buying an “oven-ready” package is simply the fact that it is tried and tested; you know that it works, there will be support provisions in place, and you won’t have to worry about being the first to try it out.
There is no need to “reinvent the wheel” when it comes to these things, there are already specialised software systems that have already been designed to cater for the problems that you are looking to address.
Before you purchase, as with the first point, it is already in place elsewhere so you will be able to go and view the system in operation in a similar working environment.
The provider of the package, the software house, will very probably bring considerable experience with them that you can then rely on
You can’t take forever to put systems in place, and the implementation time will be shorter when buying off-the-shelf, measured in weeks rather than months, or even years.
In terms of what you require and what you will get, it is possible that the package could be bloated with unnecessary features (although could they be necessary in future?), yet may fall short in some critical areas.
There is a risk of the vendor being slow to react to market trends or reluctant to adapt the software to your particular needs.
If you have other systems in place there may be potential integration issues with the new software.
Support and Maintenance costs can be expensive (although you will also have to support and maintain when developing in-house).
Finally, when purchasing from an external provider you are putting a lot of faith in that one company. Some may say that this is a case of putting all your eggs in one basket, while others may tell you to just make sure they are deserving of that confidence you are showing in them.
While these are definitely examples of problems you may experience with some off-the-shelf systems, we should say we don’t believe they can be associated with our own products. We may well be biased, but our years of experience in the industry have ensured that we do tend to know what our customers are looking for.
In the previous blog we discussed the development of Warehouse and Transport Management Systems, and started to make comparisons between developing in-house or buying off-the-shelf. Following on from that we can now look at the pros and cons of keeping your development work internal.
As mentioned previously, there can sometimes be the view that an IT department is an expensive fixed cost, and that by keeping development within the company this will give the IT team “something to do”. Depending on the company, there may indeed be an element of truth to this idea.
The development costs are perceived as being cheaper, as there should be less money being drawn out of the company account.
One major plus point for many is that they will have “total control” and not be influenced by a software house, or other third parties.
Where development is of strategic importance, having “full” control may be vital.
The client can define and should get exactly what they require.
The software should be built to fit in with existing in-house systems.
The interface should be familiar, although that is not our general experience.
Spending valuable money on developing a system from scratch is almost like “reinventing the wheel”.
Clearly defining the project and specifications is an involving task. Both operational and technical staff will need to be involved, using up valuable hours – this is not only an IT department job!
Tight deadlines and time constraints could mean that time is not on your side.
How “right first time” do you need it to be? The reality is that complex projects can take twice as long and end up costing several times more than the original budget!
Your IT team might not have the specific skill set required for certain areas of the development.
If you bring in outside specialists, they might not have relevant warehouse experience or, in the worst case, be working to their own agenda.
Debugging issues can be prolonged.
Developers can turn into an in-house technocracy with whom managers may find it difficult to argue.
The programmers are not likely to have learned lessons from others’ mistakes or benefit from others’ good ideas.
The system may have little inherent flexibility and scalability.
The process can drive a company further down a unique, or dead-end, development branch and into dependency on a particular developer, or development team.
Modular upgrades are unlikely to be available.
There is an over-reliance on one department to produce the goods.
Finally, a major question that you have to ask about in-house development will be “is it actually cheaper?”. Let’s assume there is a £40,000 yearly cost for employing a single developer, so you will pay £200,000 over, say, a five-year product life. For that same £200,000, assuming 20% per annum support and licence charges, you could buy and maintain a £66,000 software package. And this does not include the opportunity costs of delaying implementation of a solution whilst design, programming, testing and debugging takes place.
The pros and cons of any software system obviously have to be weighed up before any installation takes place, but here we have laid out those related to an in-house development, and in the next blog we’ll go over those belonging to an off-the-shelf purchase to allow for a full comparison to take place.
Naturally, as a software development company that operates solely within the logistics market, we believe that in the majority of cases the most common sense and logical action is to purchase Warehouse and Transport Management Systems “off the shelf”.
You may well think “they would say that, wouldn’t they”, but if you do read on, we believe you will find the following discussion to be well balanced in its views, and justify why we believe that to be the best decision in the vast majority of cases.
A company will usually develop in-house where the issue to be addressed is trivial or where their requirements are viewed internally as complex, or perhaps unusual – a “we do things differently” mentality. Alternatively, maybe the IT department is seen as a fixed, or “sunk”, cost to the business and using them to develop a new software solution may be a “cheaper” option.
If we ignore the former and move on to the possibility of the complex and unusual, the realisation of software projects range from the totally in-house development through to the totally off-the-shelf purchase.
With a product developed completely internally, the requirement is defined, analysed, programmed, maintained and developed using the company’s own resources. In contrast, with an off-the-shelf commercial offering, you will buy and effectively have to work with the package as it comes out of the box. In reality you are least likely to find total solutions for logistics software in either of those extreme positions.
In many cases there will be a large degree of external involvement in achieving the eventual outcome. External consultants, system analysts, programmers and project managers might be used to deliver a ground-up in-house product, while no sophisticated commercial product is likely to be useable without some configuration and tailoring to meet a customer’s specific needs. This is often in close co-operation with internal IT staff, and it should also involve working with the relevant operational staff. These are elements of best practice that we always follow at Clydebuilt Business Solutions.
More realistically, the comparisons are the perceived benefits of Bespoke Software versus those of a Tailored Commercial Package. The crux of the matter comes down to the hope that the core of the chosen pre-packaged product(s) will be tried and tested, more robust and providing a stable basis on which local workflow procedures and processes may be built. This means that even if the given methods and mechanisms that augment the core are initially less than required, the system can function, probably very successfully, whilst additional changes are made. It is the combination of this strong, stable and very capable core, with the flexibility to tailor and add functions and procedures quickly, that characterise the modern commercial logistic software package, such as those that we provideat CBS. By comparison, in-house developments can rarely afford to build in additional capabilities that are not immediately required and, of course, some additional capabilities may not even be thought of.
Further developing the in-house system with new, even minor changes, can be slow and costly to deliver.
The commercial product on the other hand is likely to be the result of a variety of users in different environments all bringing their needs and requirements to the product design table. There may well be generations of design involved, making it possible that future requirements, currently unknown or vaguely known, are already catered for or easily added. With an external package you may also be entitled to any upgrades and improvements that are made to the product along the line, with negligible or no extra cost.
None of the above touches on the problems of being locked-in to external consultants that can follow a bespoke program or the difficulty of supporting and amending a system when the original programmers have gone and the level of documentation is often inadequate for others to take on the development without a huge time commitment.
There are pros and cons to both sides of course, with regards to where your software products are coming from, and these will be discussed in further detail in the next blog.