In this article, Stephen Jackett discusses his thoughts on this topic!
Technology is a passion of mine as it has improved so many facets of everyday life, making things easier, faster, and more fun. This is also the case for putting together compelling business reasons for customers to spend money with you. For example, we can automate various calculations that can show the benefits of adopting a solution into a business in many ways – spreadsheets, in-house built software and also vendor supplied solutions.
All can be very effective so does it really matter which method we use to do it?
I would argue in these days of data privacy, protection, compliance (and big fines!) and not to mention the importance of a company’s brand and reputation, it does matter – a lot! I also quite often see companies selling solutions that improve efficiency, arguing you no longer need to use spreadsheets for various tasks, only to see them using a spreadsheet to put the business case together to help justify the solution that removes spreadsheets - it does make me chuckle!
The catalyst for putting my thoughts down on paper is the recent trend of many organisations that employ extensive supplier on-boarding processes. These on-boarding processes ensure that the suppliers can “comply with the strict requirements around Data Security and Process Compliance".
As a business we have invested heavily (and continue to do so), in the security of our platform and the robustness of our internal processes so that we can comply with these requirements. These requirements are often overlooked when businesses use spreadsheets or in-house systems for something so business critical as producing financial justifications for their customers. This is not only putting their company’s reputation at risk but more importantly their customers data, as well as potentially violating their own company’s data security and compliance policies.
In house developed systems (including spreadsheets) quite often lack the security, accuracy, transparency, and data compliance requirements that are demanded by the organisation.
This is something that is overlooked during the development and use of these types of systems. Indeed, some vendor systems I have seen can also fall foul of these requirements. An example of this are systems that allow users to fundamentally change the workings of a system to produce a result. For example, self-authored calculations in a business case means the end product given to a customer may lack the necessary quality and accuracy checks needed. Not only does this present a consistency problem across the organisation, but allowing end users to publish operational code to a live platform could present a serious security flaw. This type of functionality can also lead to unstructured data structures that have little or no use when attempting to leverage it in the future for ongoing analysis or use.
In summary, the requirement to articulate the value of a solution is not going away for sophisticated sales. The methods to do this are varied and all carry their own risks. Often an external vendor’s solution can be seen as an unnecessary expense, but when compared to the internal expense of development and the associated risks it is often far less expensive.