How internal software audits help streamline compliance and reduce costs
As enterprise technology becomes increasingly defined by its software-based infrastructure, the need for a robust software asset management (SAM) solution is greater than ever. Many smaller organisations still rely on manual processes, such as spreadsheets, for managing their software portfolios and licenses. Some don’t even have a clearly defined process at all. This can lead to wasted licenses, increased risk of compliance failures, and greater security risks due to poor software lifecycle management.
An internal software audit gathers key information about a company’s software environment to address the aforementioned challenges. It’s a documented process that must be deployed at scale to manage software installations and licenses across constantly expanding and ever-more complex infrastructures spanning today’s decentralised IT environments. In other words, it’s about bringing information together across branches, facilities, and departments, including ones around the country and beyond.
Internal software audits broadly address two key goals – to reduce the number of inactive or expired licenses and to enforce your corporate software policies. But these goals are virtually impossible to achieve at scale if you’re relying on manual processes. An automated software asset management solution provides a single, centralised interface for monitoring application usage and license deployment and maintaining complete visibility over the environment.
Here are the top reasons why you need internal software audits:
#1. Build your software inventory
Before you can understand your software licensing status and take steps to optimise the wider IT environment, you need to have a clear picture of what you have and where it’s installed. A complete software inventory provides the foundation you need to simplify maintenance and uphold compliance, as well as strategically patch holes in your infrastructure and optimise your budget. Given the complexities of today’s enterprise software environments, and the fact they typically incorporate a wide range of desktop applications, cloud-based services, and mobile apps, it’s rarely possible to do this manually. To reduce the risk of human error and optimise efficiency, you’ll need a software asset management platform which automates the collection of licensing and installation data across your entire environment. Your SAM solution should also be able to import purchase data and compare it alongside installed software.
#2. Monitor application usage
Collecting software usage data will provide a baseline for how you define normal software use throughout the enterprise. It’s a good idea to start collecting and monitoring application usage as soon as you’ve populated your software inventory. Many enterprises have unused licenses which can be freed up to reduce costs. One study by CSO Insights even found that 60% of businesses have unused licenses, meaning they’re wasting money on so-called ‘shelfware’ which they never use. With integrated tracking and metering tools, you can easily expose such licenses and reallocate or terminate them as necessary.
#3. Optimise license deployment
Before you can optimise license deployment, you’ll need a complete overview of the licenses your company currently owns. This is often the most difficult step after building your software inventory, so having an automated solution will help immeasurably. The best place to start is by looking at your purchase records – something an automated internal software audit should be able to do. By centralising this documentation, you can import it into your software asset management platform for reconciliation against installed licenses and usage volume. Then, you can adjust license counts as necessary. For example, if you have 200 licenses for your CRM software, but you’re only using 150, you may be able to renegotiate a better deal with your CRM vendor. Similarly, if you’re using 200 copies of your software, but you’re licensed to use only 100, then half of your copies won’t be legal, in which case you’ll need to address the problem as soon as possible to prevent potential sanctions.
#4. Enforce software policies
To uphold information security and ensure compliance with licensing regulations, you need a policy that thoroughly documents the process for requesting, deploying, and managing every software asset in your organisation. But a policy by itself is nothing more than a piece of paper. You need a way to communicate and enforce them across every business operation. These policies govern the procedures for installing and using software throughout its lifecycle. They should also make clear the standards which software has to meet before it can be deployed. This includes creating a list of approved vendors, determining who’s responsible for acquiring and maintaining new software and negotiating pricing, and deciding which powers individual branches, departments, and employees have concerning the process. An automated solution aligns with these policies to proactively identify any potential breaches, as well as establish and enforce an enterprise-wide deployment and onboarding process. It also lets you manage ongoing license compliance by automating renewals and running periodic inventories.
We at SnowMirror are great fans of Microsoft PowerBI, and we wanted to share with you some dos and don’ts and best practices when connecting ServiceNow with PowerBI. PowerBI has grown massively in popularity recently, and it’s easy to see why. It provides a great deal of flexibility and functionality for non-developers, and makes it easy to turn data into visually compelling reports. When PowerBI is combined with the data from your ServiceNow instance, great things can happen. Here are some of our tips.
Don’t: Work directly with your ServiceNow PRODuction data
There are many reasons why you shouldn’t work on a live production, or PROD, instance. Some of these are obvious, such as the risk of accidentally deleting or changing your data, but there are also performance bottlenecks to consider.
ServiceNow recommends that no development work whatsoever be done on the production instance. They recommend to perform all development in a sub-PRODuction instance and thoroughly test everything that’s affected before deploying to PRODuction. This includes even small changes, such as adding a field to a form, or activating a plugin, updating an access control list (ACL) rule, tweaking a client script or developing reports.
Do: Replicate your ServiceNow data before working with it in PowerBI
ServiceNow recommends to “Always have a back-out plan, which includes backing up all records that will be affected by the change.” One such backup tool is SnowMirror, which is a smart replication tool for ServiceNow. SnowMirror makes a copy of your production ServiceNow data to your own database, either on-premises or on the cloud of your choice, which makes it possible to connect ServiceNow to PowerBI effectively and safely. The benefit is that you can easily blend the replicated data with other data sources or modify the data’s structure for easier reporting, secure in the knowledge that the production data is unchanged.
Don’t: Affect ServiceNow performance by running PowerBI queries on live production data
Connecting PowerBI to ServiceNow production instances directly may significantly affect performance. For bigger ServiceNow instances with a lot of data, this approach won’t work at all because it will take ages to download the data for your report.
The best practice is to create a dedicated reporting database containing a copy of the data, either an on-premise database or one in Azure. Once you have this database replicated, you can connect PowerBI to it. You won’t be impacting ServiceNow and the reports will be much faster.
Do: Know when to replicate with display values and when to keep tables
For simple reports, it’s best to set SnowMirror to replicate with display values (Reference Fields = Both). SnowMirror will then replicate the display values to your target database. However, it’s worth noting that doing so means only the display value will be displayed.
For more complex reports, we recommend keeping the tables from ServiceNow as they are, and doing joins between the tables once you have them replicated. This gives you more flexibility in the long run.
For further reference, check out this blog post we published titled “Introduction to display values.”
Do: Have a clear idea of the information you’re trying to convey
This post on the Microsoft PowerBI blog has several useful tips for designing a great PowerBI dashboard, and in previous posts on the SnowMirror blog, we’ve talked in detail about what makes a good data visualisation great, as well as how to identify opportunities hidden in ServiceNow data. We’ve also written about the important differences between operational and strategic reporting. What ties these all together is the importance of having a clear idea of the information you’re trying to convey. A sense of prioritization, simplicity and context are all best practices for your PowerBI reports.
If you’d like to talk with us about how SnowMirror can help your business get the most out of ServiceNow, get in touch here.