How ERP Customization Mining determines candidate score and potential

  • Release version: Xanadu
  • Updated August 1, 2024
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of How ERP Customization Mining determines candidate score and potential

    ERP Customization Mining (ERP-CM) generates a score to rank legacy ERP candidates for replatforming onto the ServiceNow AI Platform. Each candidate is assessed based on its ERP module, which defines the remote and extraction tables used. Remote tables pull data via scripts from external sources, while extraction tables gather large datasets through scheduled queries and transform tables for processing within ServiceNow AI Platform.

    Show full answer Show less

    Before scoring, administrators must configure the ERP system connection in ERP Data Hub to enable data access for scoring and evaluation.

    How Candidate Potential Scores Are Determined

    ERP-CM evaluates how well a candidate’s tables and fields align with supported ERP models in ServiceNow. Scores reflect the ease of replatforming:

    • High potential: Candidate tables closely match remote and extraction tables in ERP models, requiring minimal changes.
    • Low potential: Candidate tables have limited matches to ERP Data Hub models, indicating more customization is needed.

    Key Metrics Used to Calculate Scores

    The scoring algorithm incorporates several important factors:

    • ERP Models: Counts how many ERP models the candidate’s tables draw from.
    • Similar Candidates: Number of candidates with similarity scores above a configurable threshold, considering both table and model similarities. This threshold and logical conditions can be adjusted via system properties.
    • Supported Table Score: Ratio of custom app tables supported by any ERP model compared to total custom app tables, excluding standard technical or ServiceNow tables.
    • Supported Table Usage: Proportion of supported tables actually used by the custom app.
    • Unsupported Model Penalty: Penalty based on unsupported operations on ERP model tables, normalized via a sigmoid function to range between 0.0 and 1.0.
    • Unsupported Table Extensions: Counts custom app tables that are recommended as extensions to models.
    • Model Inaccuracy: Number of supported tables not used by the custom app, also normalized using a sigmoid function.

    Practical Implications for ServiceNow Customers

    This scoring mechanism helps ServiceNow customers identify which legacy ERP applications are best suited for migration onto the ServiceNow AI Platform with minimal effort. By understanding the candidate’s potential score and underlying metrics, customers can prioritize replatforming efforts, anticipate customization needs, and better plan integration strategies based on the alignment between their current ERP customizations and supported models.

    ERP Customization Mining (ERP-CM) generates a score to rank the potential for replatforming legacy ERP (Enterprise Resource Planning) candidates onto the ServiceNow AI Platform.

    Every candidate has an ERP module specified in the candidate details in ERP-CM. The ERP module is used to evaluate the potential score of the candidate for replatforming, as well as the remote tables and extraction tables the model contains.
    • Remote tables get their records from running an associated script against an external data source.
    • Extraction tables retrieve large amounts of data using a scheduled query, and use transform tables to process data for use on the ServiceNow AI Platform.
    Note:

    Admins must first configure the connection to the ERP system in ERP Data Hub. For more information, see Working with ERP systems in ERP Data Hub.

    High and low scores for candidate potential

    ERP-CM evaluates candidates based on how well their tables and fields are supported by the ServiceNow AI Platform.
    • A high potential indicates that ERP-CM can immediately use remote tables and extraction tables that match the ERP model for the application candidate without making additional changes.
    • A low potential indicates that the application candidate matches few of the remote tables and extraction tables in the ERP models in ERP Data Hub.

    How scores are calculated

    The candidate potential score is calculated using the following metrics:
    • ERP models: The number of ERP models that the candidate uses remote tables and extraction tables from.
    • Similar candidates: The number of candidates with a similarity score above the threshold, which accounts for both table-based similarity and model-based similarity.

      The threshold can be adjusted in the System Properties [sys_properties] table, and the default OR condition can be changed to AND.

    • Supported table score: The ratio of the number of custom app tables that are supported by any ERP model relative to the number of custom app tables.
      Note:
      Tables from either the Technical or ServiceNow table clusters are ignored from these computations.
    • Supported table usage: The ratio of tables supported by the relevant ERP models that are used by the custom app.
    • Unsupported model penalty: A penalty for the number of unsupported operations on tables in ERP models. The number of unsupported operations is passed through a sigmoid function, so it ranges from 0.0 and 1.0.
    • Unsupported table extensions: The number of custom app tables that are also suggested as model extensions.
    • Model inaccuracy: The number of tables supported by relevant ERP models that aren’t used by custom apps, and are passed through a sigmoid function.