Intro

While manual matching is very time-consuming for users, intelligent systems can significantly speed up matching decisions by using AI methods, such as machine learning. The system presents one or more strategies for linking similar objects, and indicates the quality of each strategy. Users then only need to approve or reject the suggestions, or adjust them to their needs.

When to Use

Matching is relevant when at least two artifacts can be linked together on the basis of similar characteristics. The process of matching follows a set of rules, which can be adjusted dynamically (“learned”) by the system.  The learned rules can change over time due to user input or other triggers.

Matching can be applied to different content types, including:

The content to be matched strongly influences the type of output and its presentation.

Match Quality

A key aspect of matching is the quality of a match. Objects can be a full match or only a partial match:

• A full match is given when all defined parameters fit.
• In a partial match, only some of the required parameters fit.

The more parameters match, the better the quality of a match.

Matching Types

Based on enterprise use cases, we have defined the following matching types:

Components

Matching involves a group of items that are linked by certain criteria (such as similarity or the type of relationship). This is called a matching group.

Matching Group

The following matching group characteristics are typical for the use cases we observed:

• Group name: A meaningful label for the matching group. For example, this could be the name of the master record in a merging scenario, or the name of the matching criterion.
• Group summary: An optional description of the group contents. The summary can be presented as a text or using key/value parameters.
• Group size: The number of items in the group.
• Quality indicator: Rates the confidence of matching proposal in relation to the defined goal. For example, this could be the similarity of business partner records when merging duplicates, or the percentage covered when matching invoices.
• Finalizing action: An action that can be applied to the whole group, such as approval of a matching proposal.

You can present the set of matching groups to users in different ways (for example, as a list, grid, or even as a graph). Users can then drill down into a specific group and analyze its content and match quality in detail. The presentation of a matching group depends on the use case and can vary from a simple list to a chart (such as a network graph).

Behavior and Interaction

Depending on the matching level and the match quality, the degree of interaction with the matched objects and groups varies. For example, if the matching proposal is not very accurate, then editing the matching group is an essential part of the interaction.

Higher levels of automation already present good enough match proposals, and differ only by strategy. Here, the following main or finalizing actions are possible:

• Approve: The proposal is accepted as it is.
• Reject: The proposal is fully or partially rejected. Partial rejection involves editing the matching group manually and then accepting it. Rejection can lead to a follow-up feedback mechanism (implicit or explicit).
• Merge: Involves merging two or more groups into a “golden” one.
• Split: Involves creating two or more groups out of one. This can be achieved by selecting individual items, which then are used to create new groups.

Responsiveness

The concept itself does not have any limitations with regard to Responsiveness. It makes use of the standard SAP Fiori controls and floorplans and inherits their responsiveness characteristics and guidelines.

Example

The following example shows how the system creates matching proposals for unassigned payments that it was not able to clear against invoices automatically.

Using machine learning algorithms, the systems “works” through the open invoices and makes several matching proposals for open invoices that correlate with the customer payment.

These different proposals can be described as applied strategies, which define the criteria for matching.

Each proposal is a matching group, which contains several invoices for the uncovered payment (one-to-many relationship). It also includes a human-readable explanation of the main parameters that were considered when constructing the matching proposal.

Top Tips

• Display matching groups with a set of characteristics, as described above, and present them to the user as a recommendation for approval.
• Rank matching groups by priority or by confidence level, depending on the use case.
• Always offer the user an explanation to outline why the system generated the suggestion in a certain way. The user needs to understand the suggestion and must be able to edit it to make minor adjustments.
• Every action or decision on a suggestion must be reversible and adjustable. The user must always have the option to match items manually if none of the suggestions are suitable.

Helpful Questions to Ask

• What is the desired result of the matching or merging interaction? Do you want to create a new relationship (such as a cleared document), or a new object (such as a merged contact)?
  Background: Depending on the use case, we differentiate between matching (changing a relationship) and merging (changing an object).
• What are the typical criteria for building matching groups?
  Background: We have observed that users normally work with a set of objects that are grouped by specific criteria (matching group).
• What are the typical operations users perform on matching groups?
  Background: We assume that there are standard operations, such as Add Item to Group / Remove Item from Group, Split Group, Merge Groups.
• What is the finalizing action for solving the issue?
  Background: Depending on the use case, we assume that there is one finalizing action for each matching group (for example, Clear Invoices, Merge Contacts).

Related Links