TABLE OF CONTENTS

• What is ACE:AI?
  • Data Transmission
    • In-house Applications
• Main Functions
  • 1. Application Normalisation 
  • 2. Application Categorisation and Description
  • 3. Application Vendor & Name Translation
  • 4. Application Accept/Reject/Rationalise
  • 5. Operating System End of Life Reports

What is ACE:AI?

ACE:AI - Asset Confidence Engine: Artifical Intelligence

ACE:AI aims to reduce the amount of time and effort required in managing applications. It's typical for 1000s of applications to be present in ManagementStudio, due to the vast number of applications in use in the enterprise, and the numerous versions detected (this assumes an Inventory Connector such as the MECM/SCCM Connector is in use).

Prior to ACE:AI , it took an application specialist many days to review the discovered applications in ManagementStudio's "pending" area, then make decisions about which are legitimate business applications, which versions of these should be rationalised, and which applications were non-business (out-of-scope). This was especially challenging where there was limited knowledge of applications.

ACE:AI attempts to vastly reduce the amount of time and effort involved in this process, and also reduces the skill-level required. ACE:AI collects information about what application decisions (accept or reject) were made by other customers. These are stored in the cloud. When a customer is processing their application estate, ACE:AI makes suggestions about each application based on the previous customer decisions. If 18 out of 20 customers (90%) previously accepted an application, ACE:AI will suggest that the next customer accepts that same application with a confidence rate of 90%. The same principal is applied where an application has been rejected.

The new customer's decisions are recorded in the cloud, ensuring that the system is constantly improving.

In addition, where ACE:AI finds multiple versions of an application, it will suggest that those versions are rationalised, according to the version threshold settings defined in the Admin area.

The end result is that a large number of applications can be easily quickly and rationalised, which provides a concise and accurate understanding of the organisations current application requirements. This is a powerful starting point in understanding the requirements for a transformation project, or BAU process involving applications.

Data Transmission

In-house Applications

During the onboarding process, each customer's application list undergoes manual review, and rules are established to exclude in-house applications using exclusion filters. These applications are NOT added to the global application catalogue in the ACE:AI database, and are NOT transmitted to the OpenAI API. For instance, with the fictional customer MyCorp, applications with the vendor 'MyCorp' (in-house developed applicaions) are excluded.

Main Functions

1. Application Normalisation 

Many vendors are inconsistent when naming and versioning their software titles. Application normalisation is the process of removing all those inconsistencies to present a clean, easy to manage set of names and versions.

The ACE:AI engine provides a way to automatically (or manually) normalise the application estate using a pre-defined ruleset.

Example:

• The software vendor Adobe uses different ways of branding its products such as "Adobe", "Adobe Corp.", "Adobe Inc."
• The ACE:AI engine recommends changing all these to "Adobe" and can optionally

Usage Instructions

2. Application Categorisation and Description

The ACE:AI engine can lookup categories and descriptions for recognised applications using the ChatGPT API. These can be applied manually or automatically on a schedule. Note that within the ACE:AI settings the categorisation options are part of the Normalisation section.

Usage Instructions

3. Application Vendor & Name Translation

The ACE:AI engine leverages the OpenAI API for accurate application vendor and name translation. This is performed automatically where vendors/names using non-alphanumeric charaters are detected.

4. Application Accept/Reject/Rationalise

The ACE:AI engine takes decisions made by existing customers about applications. It then builds a confidence rating of these decisions, and suggests that other customers make those same decisions. This can be a manual or automated process.

In-scope application Example:

• 100 customers choose to mark Bloomberg as a valid business application
• A customer installs a new instance of ManagementStudio in an organisation where Bloomberg is in use
• The ACE:AI engine recommends that Bloomberg is "Accepted" as an "in-scope" application and can optionally auto-accept this application
• As different versions of Bloomberg are discovered, they can be auto-rationalised to the "Accepted" version

Out-of-scope application Example:

• 95 customers choose to mark Spotify as a non-business application
• A customer installs a new instance of ManagementStudio in an organisation where Spotify is in use
• The ACE:AI engine recommends that Spotify is "Rejected" as an "out-of-scope" application and can optionally auto-reject this application

Rationalisaton Example:

• As different versions of existing appliactions are discovered, they can be auto-rationalised to the "Accepted" version

Usage Instructions

5. Operating System End of Life Reports

The feature generates reports on Operating System end-of-life support dates using the ManagementStudio Algorithm. These are available in the built-in Device report ACE - OS End of Life Report. The end-of-life dates can be manually added to a Device Datamining Report by ticking Add OS End of Life Days in the Device Reporting Tier.