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