NederlandsAfter reading my previous blog in this series, for the observant reader the conclusion will be that managing software compliance requires a combination of SAM-tooling and processes, and not only the processes that are supported directly by the tooling. I introduced my favorite SAM process model and the SAM Core processes. In this subsequent blog, I’ll give an impression of the organizational units involved in SAM processes.
Processes and Organization
Software Asset Management is a concern for the whole organization. The greater part is involved passively. They need to be informed about relevant SAM policies, and must act accordingly. Only a number of employees are actively engaged in SAM processes. Depending on the organization’s maturity level some of them may have dedicated SAM roles, whether or not in a SAM organizational unit. Related processes and units, e.g. IT, Procurement and Finance are also involved in SAM processes. It is not possible to design ‘the standard organization model’, according to which SAM roles and responsibilities must be assigned.
[Figure 1 – SAM Process Model] [Figure 2 – Sample Organization Model ]
Figure 2 shows a simplified organization model that I will use below to discuss some aspects that must be considered when implementing SAM processes in the organization.
Accountability and mandate
Software Asset Management requires a substantial investment, to realize a much bigger profit by cost savings and risk reduction. The amounts of money that we are talking about justify attention and commitment at Board level.
In fact, the CEO is accountable for the organization’s compliance. Probably he will delegate the accountability for software compliance to someone in the organization. Let’s call him the ‘SAM Executive Sponsor’. This person must be willing to spend money in SAM and must be able to make decisions, for example in case of escalations. Ideally, the SAM Executive Sponsor will be at Board level, e.g. the CFO. At this level, it is possible to provide strategic guidance to projects and processes.
The second role, which must have at least the mandate of the senior management, is the SAM Process Owner (PO). He is responsible for designing the SAM processes and tool selection, and implementing and monitoring the processes. This could be an employee at enterprise staff level, e.g. in the ‘Compliance Office’ (see Figure 2).
Besides these two roles there is the SAM Manager. He is the one who operationally manages the SAM processes.
Until recently, however, and for many organizations even still, the management of software is not a priority. Software is considered to be an IT issue and as long as unexpected excessive costs do not trigger the CFO, no initiatives will be taken at senior management level. Consequently, in most organizations SAM roles can be found in the IT department, mostly the SAM PO and the SAM Manager even combined in one person. Because SAM processes depend on processes outside IT (Finance, HR, etc.) this person might lack mandate to have them adapt their processes.
Central vs. decentralized
Since compliance, and consequently audits by vendors, is a corporate issue, the main SAM processes must be centralized. If operational activities must be executed decentralized care must be taken to tune the processes and manage the data.
ISO 19770-1 distinguishes between a central and local Process Owner. In our opinion local POs are always subject to corporate coordination.
Related organizational units
When implementing Software Asset Management, it is important to determine your stakeholders. Especially stakeholders in other organizational units than the one you’re running your SAM implementation project from. Stakeholders will have the most influence on control over your SAM project because it is their action or inaction that determines the success or failure. So, it’s crucial to enlist their support or determine the risk when they treat the SAM project as a threat to their KPIs making them oppose to the project.
The IT department is the most important stakeholder for the SAM Team, probably the team is even part of IT. Many IT employees are dealing with applications in all stages of their lifecycle, thus being involved in SAM processes, which are closely related to the ITIL processes. The SAM Team receives data about the status and usage of software. At the other hand the SAM Team is involved in decisions about purchasing, designing and deploying software.
In Figure 2 I pictured the RSCQ roles (Risk, Security, Compliance and Quality) together as an organizational unit. However, in reality these roles will be positioned differently. Sometimes they operate at corporate level but it’s also possible at departmental level (and thus only for a part of the organization).
Whilst aiming for mitigating organizational risks, compliance to organizational security or QA standards, all these processes also relate strongly to being compliant to license agreements and – therefore – interact directly to SAM policies and the SAM organization.
Finance is the unit that’s keeping track of all financial transactions within the organization. Non-compliance of software licensing translates in lost Dollars/Euros in terms of fines, buying lacking licenses and loss of revenue and market share due to negative publicity. While the SAM project initially needs financial funding, the project will lead to a return of investment which can be significant higher than the losses.
In a large organization, you may encounter different currencies and different (national) tax systems.
Charging of software costs, if applicable, e.g. to business units or regions, will be processed by the Finance department, based upon data from the SAM Team.
For your SAM project, you may have to deal with the Chief Financial Officer directly as one of the key stakeholders.
Procurement is the unit that needs to ensure that the purchasing processes for company-approved purchases are done in an orderly fashion and that purchases are made at the most favourable price. Their support and cooperation are required for reconciliation of purchase orders and invoices with software licenses to determine the extent of non-compliance.
In organizations that have a dedicated contract management function the SAM organization must be designed to work closely with contract managers since software agreements are contracts themselves. Processes for software acquisition can benefit from the knowledge and experience of skilled contract managers, primarily in the negotiation of terms and conditions. Be aware that in large geographically spread organizations the content of contracts for – apparently – the same software may differ. Also, processes for software acquisition may differ due to cultural aspects.
The potential for software license non-compliancy and the need for ongoing legal review of software agreements and maintenance contracts lead to significant need for services from the Legal department of the organization. Almost every time that negotiations about contractual terms and conditions are going on the legal department will be involved.
The Human Resources Department (HR), provides information about employees, e.g. numbers and new and departing employees.
Key for the success of the SAM organization is that policies regarding software compliancy are acknowledged and adhered to by all employees. This is also a key goal for the HR Department. They must ensure that all employees are properly educated in these organizational policies with the associated responsibility for addressing employee counselling when policy violations occur. Any remedies for policy violations (sanctions!), especially if it involves a permanent record in personnel files or even termination of the work contract between the organization and the employee, must be coordinated with HR.
Conclusion
There is no standard recipe for positioning a SAM Team in an organization. It is obvious, however, that the SAM Team interfaces with many organizational units, including their processes. These interfaces are two-way. They provide data but also benefit from the information and expertise of the SAM Team. The SAM project will have to schedule activities explicitly to involve all related units.
Hans van der Zanden
Co-founder and CFO of In2SAM BV, The Netherlands
Process guru for 25 years
Expert added to ISO Workgroup 21, co-editor of additions to ISO 19770