Australian Software Asset Management Association

Rule

 

 

Software Asset Management Complexity To Manage

       

        ASAMA

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.)