Software Asset Management
(SAM) is complex to manage, as there are so many elements that make up a successful SAM program. The
elements that contribute to SAM include: contract management and negotiation, audit and compliance,
software licensing models, financial, inventory control, discovered data, deployment, solution design
and many more. This article will only lightly touch on contract management, contract negotiation, audit
and compliance, software licensing models and financial management. The in-depth requirements for these
elements are available in the topic specific and in-depth insights.
A commercial relationship with
vendors is entered into either through a Deed or Contract. An Agreement is usually a pre-condition to
entering into a contract, where an agreement is where both parties have a similar view on issues;
therefore an agreement can be seen as a precondition to entering into a contract. This then can be
extrapolated to establish that all contracts are agreements, as agreements form part of the reason
into establishing a contract. Deeds and contracts do have some differences, they being: In a Deed no
consideration needs to be provided, where in a contract consideration must be provided. There are
different statutory limitation periods for deeds and contracts in the States and Territories
jurisdiction. Deeds range from 12 to 15 years, whilst for contracts the period is 6 years. However both
of these time periods can be extended or reduced by agreement between both parties when forming a deed
or contract. For simplicity for this article, contract will be used to cover both a deed and contract,
the legal differences should be considered when entering into a formal commercial relationship with a
vendor.
The commercial relationship
with vendors begins with contract negotiation and then contract management. A contract can be quite
complex spanning many hundreds of pages that can also include provisions to raise new contracts under
the terms and conditions agreed to under the initial contract, also known as a head agreement. Your
organisations relationship should be built on this foundation, and on your organisations terms. Vendors
will always want to deal with your organisations on their terms and conditions, this is the first part
of the relationship you must change. These vendor terms and conditions are written solely for the
vendors benefit and these should never be accepted for a number of reasons. Generally, when people
review a vendors terms and conditions, the starting position has been established by the vendor. This is
a bad position to start from and you should never start from this position. Your organisation has got
what the vendor needs, money. The power in the relationship at this point in time is with your
organisation, as no money has been given to the vendor, you should start from your organisations terms
and conditions, not the vendors.
Another consideration is that
your organisation would have many contracts with multiple vendors. Managing contracts that have a
lot of variation and requirements is inefficient and generally leads to poor outcomes for your
organisation. The aim should be to have standardisation in the management of the many different
contracts your organisation has with numerous vendors. This will enable you to manage the contracts
better and therefore meet your accountabilities and responsibilities in contract
management.
Organisations have a lot of
software within their environment, some larger organisations have thousands and thousands of
different types of software and software versions. It is quite common that no formal contract has been
entered into with the software vendor, or so it would seem. In fact every software title and version has
a legally binding contract attached to it, often called an End User License Agreement (EULA) or
variations to that name, depending on the software vendor. These contracts are being agreed to by your
organisation when the software is installed, and they are being done so based solely on the vendors
terms and conditions, which should be a significant area of concern for your
organisation.
Consideration on how you
manage this situation should be a high priority, with consideration on whether it is feasible to enter
into a formal contract and ensure the order of precedence applies between the contract and the EULA.
Obviously, a contract brings with it an administration overhead, so the balance needs to be found
between a contract and a EULA, and the management needs of both. Where EULA’s exist, legal review of
these should be considered as they are a risk exposure point for your organisation.
Audit and compliance is an
in-house activity that is run by your organisation, not left to when a vendor requests an audit. The
regular scheduling of audits and follow-up compliance activities will provide a discipline and structure
to your organisations use of software. As software continues to consume a large amount of the IT budget,
any organisation can obtain financial benefits in managing their software assets proactively. This
activity does require a lot of planning and engagement with a number of key infrastructure and
application teams.
The approach to how auditing
will be undertaken will differ in different organisations. Firstly, some organisations will have
Software Asset Management technology implemented that will be able to provide an initial view of what
software is installed in the IT environment. Secondly, other organisations will have other
technology that they will try to adapt for Software Asset Management (which is not a good idea, when you
have to start using that information and applying it to all the various licensing models). Thirdly,
there will be other organisations that have no IT software asset management and will be relying on
manual recording, such as spreadsheets. Obviously the organisations with software asset management
technology have a good start on the others but it is only a start. It is quite probable that in a
decentralised environment, which managed by a wide range of teams, that a combination of the above
approaches is used for a variety of reasons. These reasons could include: the cost versus benefit for a
Software Asset Management technology installation is not viable, the Software Asset Management
technology is incompatible for a particular environment (ie. does not meet the security requirements),
that the support team do not want that Software Asset Management technology in their environment
and various other reasons. A vendor seeing that an
auditing program is established in your organisation is less likely to audit , preferring
to audit an organisation that has no audit program.
The complexity with software
licensing models is magnified when your organisation has a lot of software and a lot of different
vendors. These models range from simple user models through to capacity models that also have various
options depending on how the software is deployed and the architecture that the software has been
deployed on.
It is quite common that the
teams who have a directed influence on what software is approved for purchase, have no idea on
software licensing. These teams usually have the role in determining the architecture of the IT
environment, the solution design of a application and the infrastructure that supports that application.
It is the software asset management teams role to advise these teams on the impact their decisions have
on the management, costs and the compliance requirements of the software
selected.
It is important that these
teams are educated on these issues. This activity requires a lot of engagement and to ensure that it is
correctly structured and is enduring, a communications plan should be developed. Developing the
communications plan will assist you in identifying the key stakeholders, what are the communications
channels available to be used and what are the key messages you need to provide. Examples of
communication channels available could be team meetings, presentations, change advisory boards,
architecture boards, solution design boards, internal IT magazine and the list goes
on.
The careful analysis of each
software licence is required to ensure compliance to the terms and conditions. This is a specialised
skill that draws on knowledge in legal, IT technical, contract management and requires attention to
detail, ability to contextualise and to systematically work through the flow on effects to other licence
models that the technology is reliant on. One test you can always place on a vendor is to ask them how
would they manage their proposed licence model, a number of them have no idea and they cannot provide
you with a specific answer. This is because a number of licensing models do not have a straight forward
approach to being managed, however the vendor is always quick to point out that a licence model should
be managed.
As previously discussed,
EULA’s are a risk exposure to your organisation and there is a great need to have specialist skills in
reviewing the various licence models. Turning a blind eye to this will eventually catch up with your
organisation and the financial and reputation issues that this will bring could be immense. The
management of the EULA’s can be approached by a variety of methods. Prevention is better than cure, so
the obvious initial starting point is prior to purchasing any software, whether this is through a
contract or an ad-hoc procurement purchase. Negotiating the licence model to your organisations
operating model and capability is a fundamental requirement.
The desired state would be to
have the licensing metric at its most simplistic form and not convoluted with a number of metrics that
just make the licensing model too complex to manage. As previously discussed, vendors are interested
before they get the money, they have little to no interest after they have the money. Implementing the
audit and compliance activities as previously discussed will keep the IT environment in check of
deployments and enable near time remediation of unintended deployments as quickly as possible. Standard
service management processes such as release management and change management should be utilised to
ensure that only authorised licenced software is deployed, noting this means you need to be part of the
approval authority for release management and change management.
As with all effective planning
approaches, planning starts from the top and ripples down, often called the “Top Down” approach. This
type of planning enables effective reporting right through the organisation, often called the “Clear
Line of Sight” reporting. Planning should always be undertaken with a clear knowledge on how will the
activities of the plan be reported on, when will they be reported on and what are the key measures the
report will be relying on.
A communications plan should
be a mandatory requirement for your Software Asset Management program. The framework and the details of
the communications plan will vary between different organisations. These differences are
influenced by the following factors; the organisation structure and how centralised or
decentralised is your IT environment and the scope you have determined for your Software Asset
Management program. In a small centralised organisation the communications plan could be a relatively
small piece of work, where is a large decentralised organisation this would be a considerable large
piece of work involving many people, requiring significant amount of resources to establish and to
maintain as an enduring function.
Financial management of
software is one of the key aspects in the management of software. Talk dollars in any IT organisation
and you will have attention, utilise this attention to support your Software Asset Management program.
The authorisation of who is allowed to commit funds for a software purchase will dictate on how
controlled your organisations purchasing of software is. Try and get this control limited to a number of
key trusted positions and personnel. Having this included as a key reporting item will enable you to
keep the visibility of the continual expenditure on software forefront in the Executive’s
mind.
The control of software
expenditure has a direct flow on effect to how successful the organisation is, in its endeavour to
ensure that its software expenditure is value for money. This can be achieved through software
standardisation, effectively managing software licensing terms and conditions, the ability to reuse any
unused software, subscription and support arrangements and finally the overall total spend on software
from the IT budget. Importantly when considering the overall total spend on software from the IT budget
that is what is visible through the balance sheets. Any software deployment that is not authorised is a
commitment to the budget, this liability would largely gone undetected without an audit and
compliance process in place. The preference would have been your organisations audit and compliance
program, not the vendors audit and compliance program.
Financial management is one of
the key foundations to a successful Software Asset Management program. The preceding paragraphs
discussed some of the elements, only to a limited depth, that are required to enable your organisation
to manage a successful Software Asset Management program. The complexity of Software Asset Management is
clearly one of the fundamental issues that affect an organisations ability to manage its software assets
but to ignore this requirement places the organisation at great financial and reputation risk in the
future.
(IE Printing: - There are known IE printing problems that affect certain printer brands
and printer types; Chrome and Firefox have no reported issues.)
