What are the biggest mistakes in software procurement in the health care industry, and how can one identify them before it’s too late? -By Joshua Ferdinand
Ever since computers and software became de rigeur for businesses in the late 1970s, organizations have sought to build an edge by purchasing the best software available. Yet the drawbacks of software quickly became apparent: rapidly obsolete programs, programs nobody ends up using, and thousands if not millions of dollars wasted on licenses that aren’t producing any value for the organization.
To mitigate these drawbacks, the discipline of Software Asset Management, sometimes referred to as IT Asset Management, came to be. When investing heavily in the wrong software might be a major liability for an organization, that organization needs to have an expert on hand to know how to choose the right solutions, minimize the risk of things going wrong, and ensure that whatever software the company does adopt, it’s one that will efficiently deliver the desired results. Here, the challenges of modern software asset management will be discussed, with an eye toward avoiding the biggest mistakes in software procurement.
In a 2018 article for the Journal of Health, Education, and Sport, researchers looked at the most significant problems facing organizations in the field of software asset management. Some of the statistics they produced were downright shocking. For instance, they claimed that up to 76% of the business leaders polled in their study did not have any system at all in place for software asset management. Imagine any other area of business in which management just lets purchases proceed with virtually no oversight, and one will get a sense of the magnitude of this problem. Likewise, 45% of companies have no protocols in place to monitor their software licenses, the permissions they grant, and any potential redundancies in the organization’s purchasing habits. Lastly, nearly all of the organizations responding to the study, 96%, admitted that their overall awareness of the discipline of software asset management is virtually nil.
This represents a serious problem at a time when software is transitioning to a cloud-based model wherein organizations will be paying perpetual subscriptions rather than one-time fees to support the software upon which they depend. In order to gain a baseline familiarity in the discipline of software asset management, it might be worth seeking out some of the popular accreditations for one’s organizational leadership, such as Certified Asset Management Professional (CAMP), Certified Mobile Asset Manager (CMAM), Certified Asset Management Security Expert (CAMSE), and more, depending on what expertise one’s organization requires.
Addressing the Biggest Mistakes
In order to get the best results from one’s software asset management, one will need to know what the biggest mistakes tend to be, as those represent some of the biggest opportunities to gain a competitive advantage.
One of the most straightforward and obvious mistakes in software asset management is simply choosing the wrong software for the business’s needs. Just because a software program says it does what one needs, doesn’t necessarily mean that it does it in a way that will work for the company. Thus, beyond just looking at features, what is really needed is a robust way to measure whether or not workers actually use the purchased software system. The best way to do this is by directly measuring usage rates, and making cuts to one’s software procurement for those programs that just aren’t seeing significant use.
Another all too common mistake is not involving the software’s end users in the decision making process. If the value of a piece of software lies largely in how often it will actually get used to make business happen, then it only makes sense that stakeholders – those workers who actually use the software on a daily basis – get some say in what requirements they have for a given piece of software. Also critically important is developing some metric by which one can measure their level of buy-in towards using a particular piece of software. Remember the golden rule here: if employees won’t use the software, it’s useless.
There are other significant problems that can crop up when one is working with a supplier to develop proprietary software for one’s organization. One of the most significant of these is the use of poor quality RFx material. As Victoria Barber writes in 2018, when software suppliers are making inadequate use of requests for proposals, information, quotes, and bids, it makes for an absolute mess of software asset management. It’s important then to find developers who are focused on business outcomes – that is to say, not so much profits and losses, but rather that they have a clear idea what one’s organization is trying to achieve in the long term, and how their software solutions fit into that structure.
The workflow efficiency of suppliers is another very serious factor that must be considered. Even if an organization understands exactly what one wants in a piece of software, it doesn’t matter if they’re only able to deliver it long after one’s deadlines, or for way over one’s allocated budget. These are things that one can tell about proprietary developers beginning at the level of the proof of concept. When a developer delivers a proof of concept for a piece of software, it should be elegantly streamlined, perfectly easy to use, and its various functions should be immediately obvious and beyond question. If a proof of concept is delivered in a disorganized state, this is one of the biggest red flags that a software asset management specialist can face.
Lastly, one of the biggest mistakes organizations make is overspending on duplicate software. This isn’t just a matter of not buying literally the same software that one already owns, but more a matter of having protocols in place to periodically review one’s existing software licenses and functionality spreadsheets in order to make sure that one doesn’t have multiple pieces of software that replicate the function of each other. If this is the case, it’s often a sign of money going out the window on software that employees aren’t using to its full advantage.