The requirements for managing
software products as part of the Software Asset Management (SAM) lifecycle can be defined into a number
of complex and intertwined issues. The approach and the timing of the required actions to address these
issues will depend on dependencies on other actions being completed or commenced; thereby some actions
need to be executed in a pre-defined order, whilst other actions should run in parallel with others.
Some issues or parts of issues may well be managed or decided upon by other areas within your
organisation, if this occurs there is extra emphasis on your communication and coordination skills in
keeping all of the lifecycle categories aligned.
Software should be procured
based on a business requirement. Often in IT we have people aligned to technologies and their
consideration of available software products is limited to a vendor or a small subset of vendors. The
reason for this is that due to the highly specialised nature of IT, people learn a particular technology
platform and a range of similar technologies and in the majority remain with these technologies. At
times some people can forget who they are employed by, this is noticeable when they undertake
actions on behalf of vendors, which they should not be doing. The vendors also seek out the people
aligned to their technologies, to push forward the vendors argument on why their product should be
purchased over another vendors product. As a Software Asset Management professional you should have no
such alignment to any vendor, your role is to be totally independent and to represent your organisation
to the best of your ability.
Architects, application and
infrastructure solution designers should be seeking advice on the software licensing costs, over
the software lifecycle. Virtualisation solutions have become one of the major issues facing software
licensing in cost and compliance management. Too often architects, application and infrastructure
solution designers seem to be in total denial of the costs of software in a virtualised environment.
They continue to have the simplistic view that it’s cheaper because less hardware is required, without
considering the software cost. Hardware in itself has very low margins and is these days assigned as a
commodity item. The flow-on cost reductions in computer rooms floor space, utility costs and operations
that is usually attributed to virtualisation, could also be achieved if architects, application and
infrastructure solution designers, co-hosted systems rather than run them independently.
Unless the IT department in
your organisation is a highly well tuned machine where the architects, application and
infrastructure solution designers do seek the guidance of the costs of software licensing over the
software lifecycle, you will have to be pro-active to implement the necessary policies, processes and
procedures for Software Asset Management.
You should undertake a scan of
your IT Department and understand what are the processes and procedures that already exist for the
architects, application and infrastructure solution designers, your purpose should be to imbed software
licensing as one of the key decision items in their considerations. The use of policy will always corral
the people that do not want to involve software licensing in the decision making
process.
In imbedding software
licensing requirements into policy, process and procedures, your role is to provide information that
includes the costs, the terms and conditions of the licence and the possible licensing models for
the various options under consideration. One of the main goals of a software asset management team
should be to continually attempt to achieve product standardisation. Any reduction in; complexity,
the number of licensing models, the number of vendors and variations in the terms and conditions
will improve the Software Asset Management capability in your organisation.
Software that is required for
projects should have funds identified in the project. Good project managers will have
these software costs included in the projects budget. Unfortunately there are many bad project
managers that would not have done this and the most dangerous ones of all, are the project managers that
have not provided the full costs of the projects, in order to gain business signoff at project
initiation stage. Usually when software funding hasn't been budgeted for, there is an attempt by some
project managers to shift the issue to you. The ownership of these funding issues remain with the
project manager, they do not belong to software asset management team.
The software asset management
team role of providing costs, licensing models and the terms and conditions for the various options
under consideration, also includes the responsibility that the software asset management
team actually have the capability to undertake this advisory role. It is extremely important
that your team does not fail at this point; otherwise the whole Software Asset Management program could
be placed at risk through non-performance. If your team is not at this level of capability then you
should be considering how can the skills, knowledge and experience be acquired
quickly. Usually a short term and long term approach is undertaken. In the short term external
people who have the required skills, knowledge and experience are bought into the organisation to
quickly provide the required capability. The longer term approach is to use these external people
to provide knowledge transfer to the existing organisation staff over a period of time. This will enable
the organisations staff to be self-sufficient and to provide the required capability to the
organisation.
When the architecture has been
determined but the solution design is reliant on industry proposals, this is an advantageous position to
be in. With vendors competing against each other, the use of market tenders can place your organisation
in a good negotiation position. Whether these market approaches are very broad or limited to just a few
vendors, your bargaining power on the terms and conditions, and the cost of licences is
greatly enhanced.
One of the conditions for
purchase that you place on the vendor is the responsibility that the vendor provides the products
identification signatures for your software asset management tool and/or the management processes and
procedures that their software requires to ensure effective compliance management. These management
processes and procedures cannot be burdensome on your software asset management team and if they appear
they would be, then different arrangements should be negotiated. You do not want to expose your
organisation to a high risk, if the software cannot be managed that ensures compliance to the licensing
terms and conditions.
Usually software licensing is
purchased with maintenance and support costs each year, which usually ranges from 18% to 24% of the
licence purchase cost. This payment entitles your organisation to version upgrades and support for the
software product. The issue your software asset management team will need to manage throughout the
software lifecycle is the licensing requirements for the version upgrades. The yearly cost of
maintenance and support should have been identified in the budget, therefore this should be a straight
forwarded payment process. The terms and conditions of the EULA, which can change
between software versions, needs to be closely managed. Prior to implementing a version upgrade, a
review of the EULA that applies to the new software version being implemented needs to be undertaken.
The whole process of review and follow-on actions from the review can take quite some time to complete,
as you will find that you are either negotiating with the vendor on changes to the EULA or a change in
the management approach of the software. In order to give your software asset management team the time
it needs to undertake its various roles, you will need to be well aware of the work plan for the
infrastructure and application teams to identify software version upgrade plans. For software licensing
that was purchased without maintenance and support, this introduces additional management
responsibilities for your software asset management team, as they now need to manage multiple versions
of software, that usually means multiple versions of software EULA’s. If you have software without
maintenance and support, then your organisation does not have the rights to upgrade that software
to a later version to the original purchased version.
There are many changes to a
software product during its lifecycle. Most products will be affected by a vendors decision to
rename a software product, bundling a software product with other software products,
breaking the software products into parts and creating new software products and retiring the software
product. All of these changes need to be managed by your software asset management team. The key issues
that need to be managed are software licence entitlements, terms and conditions, software packaging and
record keeping.
At a minimum your
organisations software licence entitlements should allow you to continue to use the software in its
renamed state. Whether the vendor bundled the software with other software or broke it down to a
range of new products is immaterial. Access to the software to continue to use the capability that it
was originally purchased for, is a right you should not give up. Prior to purchasing the software,
you should have negotiated the right to access the software capability even if its been re-bundled or
broken down into several new software products. If this wasn't previously negotiated, you can still
negotiate with the vendor after you have bought the software, its just more difficult to do so. The
vendor will make an argument that this is not possible, the new features go well beyond what you paid
for and other similar statements, however it’s not your problem that the vendor has undertaken these
actions with the software products you have software licensing entitlement to. The issue remains with
the vendor.
Another issue that arises from
the preceding paragraph is changes to the EULA terms and conditions. Unless your organisation is
upgrading the software version, you do not have to accept a new EULA from the software vendor. Stand
your ground as outlined in the previous paragraph. The new EULA's terms and conditions is the vendors
issue. Compliance is also affected by the changes to the vendors software product. This issue should be
raised with the vendor on how they are going to ensure that you remain compliant with the new software
changes. This could lead to renegotiation on the vendor providing access to the full software bundle in
order to access the existing licensed capability or in the vendor having to supply the software
product that your organisation has entitlement, in an unbundled state.
When changes have been made
with software products, this usually means that the distribution of the software has changed,
particularly with software products that are now bundled with other software products. If your
negotiations with the vendor have not resulted in you having entitlement with the full bundle of
products, then this may cause a compliance risk. The risk is if the new software bundle is installed for
the purposes of using the existing software, the IT staff start to use the rest of the bundled
software capability, that your organisation is not licensed for.
Record keeping of all the
changes is an extremely important action to undertake. All correspondence with the vendor, including
meeting notes should be captured and stored on your organisations record management system. These
records will become quite valuable if there is ever a future disagreement between the vendor and your
organisation on software entitlements and the associated terms and conditions. Changes to the software
products discussed above need to be mapped within your software asset management tool or your software
entitlements register to ensure the day to day management of this software can continue and there is a
full line of sight of the software since it was first purchased and implemented into your IT
environment.
Service management is an
important control mechanism for the deployment of software to the approved solution design. A mature
service management function in the IT Operations will make the life of the software asset management
team just that little bit easier. Most organisations based their service management capability on the
ITIL framework. Whilst this framework is only part of the overall requirement for a successful Software
Asset Management program, none-the-less it is an important part of Software Asset
Management.
Software received from a
vendor should go through a standard process of being checked for malicious code, accepted into
inventory, assigned to an owner, the software asset management tool configured and all the
accompanied paperwork filed, where it can be retrieved at a latter date. The use of the corporate record
management system is important, so that the required reocrds can be found by other authorised people
in your organisation. Some records potentially could be required for more than 10 years. During
such a long time period it is quite likely that the person who managed the software receipt from the
vendor has left the organisation, moved to another role or would not be able to recall by memory any
necessary details of the software receipt process. A robust, standardised and repeatable process on
software receipting will address these shortfalls over an extended
period.
It is quite common that
a software library is available to store and catalog the software. Usually software is downloaded from
the vendors web site, however some vendors will still supply software on DVD media. Due to cyber
security precautions, software should be checked and tested for malicious code. If the software is
found to contain malicious code, the contract with the vendor
should include liability clauses against the vendor, to address this
situation.
As the software is being
deployed into the environment, the software asset management tool should be used to verify the
deployment. If the licence model cannot be monitored by the software asset management tool, then
processes need to be implemented to make up for this capability shortfall. Either the software asset
management tool or the new procedures and/or a combination of both are required to manage
the software whilst it is installed in the environment.
All software has a finite
useful life and it will need to be removed from the environment when it is no longer contributing to
achieving the organisations outcomes. There may be a requirement to write down the software from the
financial books. The contract or licence agreement will need to be analysed to determine if any special
conditions exist when the software is no longer required. All records that have been acquired during the
life of the software need to be centralised and filed for possible use in
the future.
The requirements for managing
software products as part of the Software Asset Management lifecycle are quite complex, ever changing
and need to be undertaken over many years, whilst ever the software is installed in your IT environment.
This article has touched on some of the issues that need consideration and what actions need to be
undertaken. The requirements for effectively managing the complexity and the depth of issues that these
actions will encounter, are not addressed here. The information that addresses these types of
requirements will be included in the topic specific articles and in-depth insights
articles.
(IE Printing: - There are known IE printing problems that affect certain printer brands
and printer types; Chrome and Firefox have no reported issues.)
