Telematics reduces fraud and improves road safety

Young drivers are more likely to be involved in car accidents, but being able to tailor a policy to an individual’s driving is better than assuming that all drivers are the same. Low mileage drivers will benefit from Usage-Based Insurance (UBI). It adds fairness by having different premiums for someone who only drives 1000 miles per year to those driving more than 20,000 miles per year. Drivers who have recently passed their driving test and are taking out their first policy will be considered high risk.  With vehicle telematics insurance, premiums will be lower at the outset or within the first few months, after insurers have given drivers a chance to prove themselves. Telematics based insurance premiums are beneficial for drivers who travel within the speed limit and an indicator of those who don’t.

This publication (Effective Telematics) provides insight into how telematics data can be leveraged and combined with other sources of data to profile drivers to calculate insurance premiums. This approach would also identify where drivers reduce speed when they see a roadside speed camera and increase speed once they have driven past it; a behaviour I have often observed even with drivers travelling at the speed limit. Telematics promotes consistent driving and steers away from erratic driving; pun intended!

Inadequate Software Asset Management (SAM) during mergers and acquisitions

Buying a company or merging to create a new company, without understanding the current software licensing position, can become costly. Financial and legal due diligence is standard practice in mergers and acquisitions, but IT implications are seldom given the same required attention. Software Asset Management (SAM) is one example of where inadequate IT due diligence is likely to result in increased exposure to financial and compliance risk; unplanned and unnecessary IT costs can significantly impact on the overall economic viability of the deal. IT due diligence will eventually become a standard part of the mergers and acquisitions process.

With significant changes taking place including new job roles, redundancies, new computer systems and business processes, the addition of new geographical locations and new legal jurisdictions, this is likely a time when compliance is low. Therefore it is not surprising that announcements of mergers and acquisitions are an impetus for software licence audits by vendors.

Key questions to ask include:

  • What is the current position with software licensing across both companies?
  • What is the software licence shortfall value of the target company?
  • Has the software licence shortfall cost been factored into the sale price of the business?
  • How mature are SAM processes in both companies?
  • What will the software licence position look like after two companies have merged?
  • How much will it cost to purchase new licences?
  • Who owns the software licences?
  • Can the software licences be reallocated to a new organisation?
  • Can existing software be used within the newly acquired company?
  • What opportunities are available to renegotiate licences?

Important points to remember are:

  • Proactive dialogue with software vendors during the merger or acquisition process will result in increased bargaining power and strengthen supplier relationships
  • Reactive dialogue in response to a software vendor licence audit puts the licensee in a relatively weak position

Mergers and Acquisitions: The case for early IT involvement is now available following research to improve post-acquisition integration and assess the financial impact of mergers.

Improving software buying decisions

Vendor software solutions usually have configurable settings to work in a particular environment; what we don’t expect is to end up paying for significant adaptations to make the software work. Without understanding the required level of configuration or customisation, costs for the new solution can quickly skyrocket. Investigate the solution more thoroughly before making a buying decision. Using the system ‘out of the box’ should be a viable option.

Here are some examples, but these will vary depending on the type of system:

  • Identify and Access Management – does the solution have a built-in option to integrate with Active Directory or other directory services? Given the level of Active Directory usage throughout the world, this should be the case for this genre of software. Configuring the system to know which domain to look at is expected. However, it would be a disappointment to purchase the solution and then need to pay extra for the development of an integration module.
  • Support packages used to fix products – selling a solution combined with a support package is one thing; however, offering consultancy services to make the software work properly is often a fact of life in the IT sector. The consultancy services could quickly become more expensive than a “built in-house” solution.
  • Existing integration modules – what systems does the solution already integrate with as standard out of the box?
  • How much, if any, bespoke software development is required? – the solution should be functional out of the box. If there are special requirements that no other organisation has, then the software may need tailoring.

If the product needs modifications, you should thoroughly consider if it is the right choice and investigate other options.

Stakeholder Engagement with SAM and HAM

One of the problems with data-driven solutions occurs when different groups of people have different sets of data, and all carry out their work duties on the assumption that the data they are using is complete, is a reliable and dependable version of the truth.

Organisations often evolve into this state when different teams self-manage their areas, their hardware and their software in isolation. Although attempts may have been made on occasion to collate the data and provide a more accurate holistic view, without processes to maintain such data, it inevitably becomes out of data very quickly. Where such an aggregation of data is undertaken upon the initiative of an individual team or team member rather than driven by senior-level strategic direction, data from some areas may be missing.

If you allocated time and resources to building or buying a new solution:

  • It should become the single source of truth for hardware and software within the business. If other teams need a subset of the data, it should come from this source and not independently compiled.
  • Where multiple teams manage hardware and software, the new HAM/SAM delivery project should have buy-in from all relevant departments to ensure that the system becomes the master solution. Without this, the new solution will quickly become another “one of many” solution.
  • Understand any specific requirements that individual teams may have for data on hardware and software. If the new solution doesn’t meet the needs of all stakeholders, they are likely to continue compiling their data independently. Reports should not be generated using separate data sources but should come from a consistent data source.

Consider the following actions:

  • Make sure all the stakeholders are involved in the process or have an awareness of the new project
  • Keep stakeholders up to date on the project and any decisions made
  • Identify all existing inventories or processes currently being used by teams throughout the business and identify any specific requirements at a local level

It is your SAM/HAM data

Regardless of which SAM or HAM solution you selected, it will need your data for the system to work. More than that, the data is the essential part, and it doesn’t matter how much money you spend on building or buying and delivering a system, without your data, it will not work, and it will not provide any meaningful service to the business.

I have taken over failing projects where businesses have already purchased a solution, but it is not yet operational. Often, nobody involved in the project understood:

  • What data already existed
  • The location of the data
  • Who could provide the data and how

Also, very little information was available as to how the system would function in the target environment. The non-technical buyer believed and expected that spending the money and installing the software would solve the problem. Data and many other factors are essential and need consideration long before a buying decision. The availability of data will depend on the size, the age and the maturity of the business.

With mergers and acquisitions, different solutions exist already, and that the data fragmented across various systems with no holistic view of hardware or software. Due to the inaccuracy of data over time, compiling data from multiple sources will allow an accurate picture to emerge. The following are some examples of where be locate data:

  • Active Directory – details of all computer accounts in the domain along with the date and time stamps showing when assets last accessed the network. The same principle will apply to other directory services.
  • DHCP allocation – the logs will contain details of every piece of hardware with an allocated IP address. This data will also indicate how recently each piece of equipment accessed the network.
  • Purchasing records – details of hardware and software purchases will be available, however, not necessarily available in a convenient machine-readable format.
  • Anti-virus – details of assets with anti-virus software installed and details of the most recent virus definitions updates
  • Support Teams – individual support teams should have information on what hardware assets fall within the scope of services they offer
  • Laptop allocation records – details of laptops purchased, their location, and who is responsible for them

The list of data sources will differ for every organisation and in some cases may include manually maintained spreadsheets with details of computers. From an accurate or partially accurate list of hardware assets, inexpensive utilities can identify software installations and usage.

Commercially available software such as Microsoft Access and Microsoft SQL Server, with free of charge versions, are available and suitable for data analysis at this level. These software packages can answer many questions about hardware and software from this raw data already available. Consider the following actions:

  • Get access to the data
  • Perform some analysis
  • Find out what the data says

I have observed the following in numerous cases:

  • Expensive solutions remain undelivered for excessive periods due to insufficient skills to deliver and operate the service
  • Many data sources within businesses often remain unknown, or known but not understood, analysed or utilised

It is not always necessary at this stage to decide to buy a commercial product or build an in-house asset management system. Getting the data and performing an analysis can often provide actionable intelligence to mitigate sources of risk and increase overall compliance.