How to Use Scheduled Routing Analysis Results

Overview

Scheduled Routing Analysis provides a recurring analysis of actual production performance compared with the expected values configured on routings.

Instead of calculating the information only when a user opens the standard Routing Analysis page, Scheduled Routing Analysis stores the calculated results so they can be reviewed later, refreshed automatically, analyzed with Business Central tools, and used with Copilot where supported.

Use Scheduled Routing Analysis to answer questions such as:

• Which routing operations consistently take longer than expected?
• Which operations have the most variable or unpredictable runtimes?
• Are recent process changes making an operation faster or slower?
• Which operations have the greatest estimated cost impact?
• Where is scrap occurring?
• Are actual setup times significantly different from routing setup times?
• If Shop Floor Insight is used, which operators perform an operation most consistently or may require additional investigation?

The results are based primarily on completed production activity and the corresponding production and capacity ledger information.

Configure Scheduled Routing Analysis

Navigate to : Scheduled Routing Analysis Settings

The page controls what will be analyzed each time the scheduled process runs.

The application automatically maintains a default analysis batch, so for normal use you do not need to create or manage batches manually. Current defaults analyze approximately the previous six months and use the previous month as the “recent” period for trend analysis.

Routing No. Filters

Use Routing No. Filters to determine which routings should be analyzed.

Leave the field blank to analyze all routings, or enter a Business Central filter to limit the analysis.

For example:

Requirement	Example
One routing	1000
Several routings	1000|2000|3000
A range	1000..1999

For a customer with many routings, consider limiting the scheduled analysis to the routings that are actively used or that are most important to review on a scheduled basis vs. running the Routing Analysis page directly for ad-hoc/manual routing analysis.

Min. Average Variance

Min. Average Variance removes small runtime differences from the results.

The calculation compares:

Actual mean runtime per base unit
versus
Expected routing runtime per unit

Only operations with an absolute difference equal to or greater than the configured threshold are retained.

The default is:

0.05 hours = 3 minutes per unit

For example, with a value of 0.05, an operation whose actual runtime differs from the expected runtime by only one minute per unit would not normally be included.

Set this value to 0 if you do not want to filter based on runtime difference.

Min. Std. Deviation controls how much runtime variability is required before an operation is included.

Standard deviation measures how much the individual observed runtimes vary from the average.

In practical terms:

• A low standard deviation indicates repeatable, predictable production.
• A high standard deviation indicates that the operation sometimes runs quickly and sometimes slowly.

The default threshold is also 0.05.

This is useful when the goal is to identify unstable processes rather than simply slow processes.

Results Filtering

Use Results Filtering to determine whether operations with no difference between actual and expected runtime should appear.

All Lines includes them.

Only Difference removes operations where the calculated actual difference is zero.

For most exception-oriented reviews, Only Difference reduces unnecessary noise.

Use Include Without Prod. Orders to control whether routing operations should be displayed when there were no finished production orders for that routing in the analysis period.

Exclude is the default and is generally appropriate when the goal is to analyze actual production performance.

Consider Include when the routing structure is relatively stable and you want the result set to also show routings that have not recently been used.

The application specifically recommends excluding these rows when a customer has many frequently changing routings.

Configure the Analysis Date Range

Scheduled Routing Analysis can use either fixed dates or rolling date formulas.

For an ongoing scheduled analysis, date formulas are normally preferable.

Starting Date Formula

The default is:

-6M

This creates an analysis window beginning approximately six months before the Business Central Work Date.

Ending Date Formula

The default is:

0D

This uses the current Work Date as the end of the analysis.

Each time the Job Queue runs, Business Central recalculates the dates from these formulas and updates the actual Starting Date and Ending Date fields on the setup page.

This means a configuration such as:

Starting Date Formula: -6M
Ending Date Formula: 0D

continually gives you a rolling six-month analysis without someone manually updating dates.

Using fixed dates

For a one-time historical review, clear the date formulas and specify Starting Date and Ending Date directly.

For example, a consultant investigating a production issue that occurred during Q2 could specify a fixed Q2 date range and review only the production completed during that period.

Configure Recent Trend Analysis

The Recent Trend Formula divides the overall analysis period into a historical period and a more recent period.

The default is:

-1M

With the standard settings:

• Overall analysis = previous six months
• Recent period = previous one month
• Historical comparison = the earlier portion of the six-month period

The resulting Trend % helps determine whether production performance has recently improved or deteriorated.

For example, suppose a customer changed tooling or production procedures approximately one month ago. Using:

Starting Date Formula: -6M
Ending Date Formula: 0D
Recent Trend Formula: -1M

allows you to compare the last month against the earlier historical performance.

Interpreting Trend %

Negative Trend % = faster / improving

Positive Trend % = slower / worsening

The calculation compares the recent average runtime per unit with the historical average runtime per unit.

A significantly negative value can therefore indicate that a recent process change is working.

A significantly positive value is worth investigating to determine what changed.

Configure Operator Analysis (requires Shop Floor Insight installed and used for recording shop floor data collection)

This section is relevant when the customer uses Shop Floor Insight and records production time with Shop Floor employees and activities.

Without Shop Floor Insight recording the required operator information, the routing-level analysis remains useful, but Operator Insights will not contain meaningful employee-level information.

Min. Operator Samples

Default: 3

This determines how many observations are required before an operator result reaches full statistical confidence.

A result based on one observation should not normally be treated the same as a result based on twenty observations.

Excessive Time %

Default: 10%

An operator whose mean runtime exceeds expected runtime by this percentage can be identified as having excessive runtime.

High Variation Threshold

Default: 0.25

This threshold uses the Coefficient of Variation, which normalizes runtime variability so different operations can be compared more meaningfully.

A higher coefficient means the operator’s runtime is less consistent.

The scheduled analysis uses these settings when generating operator findings, Best Runtime Scores, Struggling Scores, and confidence values.

Schedule the Analysis

From Scheduled Routing Analysis Settings, select:

Job Queue Entries

If the required Job Queue Entry does not already exist, the application creates it automatically.

The generated entry runs the background Scheduled Routing Analysis update process and is created with a description similar to:

Scheduled Routing Analysis : DEFAULT

Importantly, the Job Queue Entry is initially created with a status of On Hold.

The administrator or consultant must therefore finish configuring the schedule.

Configure the Job Queue Entry with the desired recurrence and then set it to Ready.

For many organizations, running the analysis once per night outside normal production hours is a reasonable starting point. The appropriate frequency depends on the amount of production data and how frequently users need refreshed analysis.

The walkthrough also notes that the initial calculation can take some time in an environment with a meaningful amount of production history.

What happens each time it runs

For every routing included in the setup, the scheduled process:

1. Recalculates the rolling dates.
2. Analyzes the applicable production history.
3. Applies the configured variance and filtering thresholds.
4. Replaces the previous scheduled results for that routing.
5. Calculates Operator Insights when Shop Floor Insight data is available.
6. Generates a plain-language Summary for each operation.

The Scheduled Routing Analysis Results page therefore represents the latest calculated snapshot, not a history of every previous scheduled run.

Open Scheduled Routing Analysis Results

Navigate to Scheduled Routing Analysis Results

You can also open the results directly from Scheduled Routing Analysis Settings.

Each row represents a routing operation included in the most recent scheduled analysis.

A good first review is to focus on:

Routing No. → Operation No. → Description → Summary

and then inspect the supporting metrics for operations that stand out.

Understand the Summary

The Summary is designed to provide a quick plain-language interpretation of the row.

Depending on the available data, it can describe:

• Whether the operation is faster or slower than expected.
• The difference between actual and expected hours per unit.
• The total hours gained or lost compared with the expected runtime.
• The best-performing operator for the operation.
• An operator showing signs of excessive time or high variability.

For example, a summary may effectively communicate:

The operation was 18% slower than expected, resulting in 24 additional runtime hours. Operator A has the strongest runtime score, while Operator B shows high variability.

The summary is generated from the underlying calculated values. It is not itself the source of the calculation, so the individual fields can always be reviewed to understand why the summary says what it does.

Understand the Most Important Result Fields

Mean Time (Hrs) per Qty. (Base)

This is one of the most useful measures on the page.

It represents:

Total Actual Run Time ÷ Total Finished Quantity

and answers:

How many actual runtime hours does it take, on average, to produce one base unit?

Compare this directly with the routing’s expected runtime.

Routing Run Time (Hrs) Per Qty.

This is the expected runtime from the routing, converted to hours.

If:

Mean Time = 0.15 hours

and:

Routing Run Time = 0.10 hours

the actual process is taking longer than its configured standard.

Avg. Actual Difference

This is the absolute difference between actual mean runtime and expected routing runtime.

It is useful for identifying operations where the standard and actual performance are substantially different.

% Difference

This expresses the difference as a percentage of the routing runtime.

One important interpretation detail is that Avg. Actual Difference is an absolute value, so % Difference is best used as the size of the discrepancy, not its direction.

To determine whether production is faster or slower, compare Mean Time with Routing Run Time, or read the Summary.

Actual Std. Deviation

This indicates runtime consistency.

An operation may have a perfectly reasonable average runtime but still have a high standard deviation.

For example:

• Order 1: 10 minutes
• Order 2: 11 minutes
• Order 3: 9 minutes

is a predictable operation.

By comparison:

• Order 1: 4 minutes
• Order 2: 25 minutes
• Order 3: 2 minutes

may have a similar average but represents a much less controlled process.

High standard deviation is therefore often worth investigating independently from average performance.

Note: Unlike the ad-hoc Routing Analysis page, the schedule routing analysis results do not allow drilling into how the actual standard deviation is calculated. If you want to double-check or investigate unexpected standard deviation calculations you will need to run the same analysis on the ‘Routing Analysis’ page, not the scheduled routing analysis results.

Actual Lots per Hour vs. Expected Lots per Hour

These fields provide a throughput-oriented view of the same performance.

Use them when users naturally think in terms of:

“How many batches/lots should we complete per hour?”

rather than hours per unit.

The configured Routing Line Lot Size is used to normalize these calculations.

Total Actual Run Time vs. Total Expected Run Time

These values show the cumulative impact.

An operation that is only slightly slow per unit may still represent a major opportunity if thousands of units are produced.

This makes total runtime particularly useful when prioritizing which discrepancy to address first.

Estimated Cost Variance

This estimates the financial effect of runtime variance:

(Actual Hours – Expected Hours) × Unit Cost

A production manager may therefore find that the operation with the largest percentage difference is not necessarily the operation costing the company the most money.

The Estimated Cost Variance helps prioritize by financial impact.

Scrap %

This identifies the percentage of recorded output that was scrapped for the operation.

Use this alongside runtime performance. An operation that appears very fast but generates unusually high scrap should not automatically be considered efficient.

Setup Time

The results also include:

• Routing Setup Time
• Total Actual Setup Time
• Mean Setup Time
• Average Actual Setup Difference

These can help determine whether a routing’s configured setup allowance reflects actual production behavior.

Use Trend % to Measure Process Improvements

Trend analysis is particularly useful after a known change.

For example:

A manufacturer changes a fixture on July 1.

Rather than immediately rewriting the routing standard, the consultant leaves the historical window broad and uses a recent trend window corresponding approximately to the period after the change.

Then review Trend %.

If the operation shows:

Trend % = -18%

recent production is running approximately 18% faster than the earlier historical period.

If it shows:

Trend % = +22%

recent production is running significantly slower.

This provides a straightforward way to validate whether changes to tooling, staffing, work instructions, layout, or processes are actually improving runtime performance. The internal walkthrough specifically demonstrates using a six-month analysis with a one-month recent period for this purpose.

A Practical Review Workflow

For a recurring production review, a useful approach is:

First: Find financially significant problems

Sort or filter by Estimated Cost Variance.

This highlights operations where runtime discrepancies are likely having the greatest financial impact.

Second: Find unstable processes

Review Actual Std. Deviation.

A high standard deviation indicates inconsistent execution even if the average runtime appears acceptable.

Third: Find standards that may no longer reflect reality

Review % Difference, then compare:

Mean Time (Hrs) per Qty.
against
Routing Run Time (Hrs) per Qty.

Consistently large differences may indicate either:

• A production problem, or
• A routing standard that no longer reflects how the operation is actually performed.

The analysis identifies the discrepancy. A user or consultant should determine which explanation applies before changing the routing.

Fourth: Look for recent deterioration or improvement

Review Trend %.

Large positive values deserve investigation.

Large negative values may identify successful improvements that could potentially be replicated elsewhere.

Fifth: Check the amount of supporting data

Review No. of Prod. Order Lines and related quantities.

A dramatic result based on one production order is less persuasive than the same result seen consistently across fifty orders.

Sixth: Investigate the source data

Use the drilldowns and navigation actions described below.

Investigate a Suspicious Result

Scheduled Routing Analysis is intended to point you toward the operations worth investigating.

It also provides several ways to move from the calculated result back to the operational data.

Capacity Ledger Entries

Select an operation and choose:

Capacity Ledger Entries

This opens the production Capacity Ledger Entries for the selected routing and operation.

Use this to investigate:

• Actual posted run time
• Setup time
• Output quantities
• Scrap
• Posting dates
• Individual production activity

One important detail is that this page may display more Capacity Ledger Entries than were actually used in the Scheduled Routing Analysis calculation. For investigation purposes it can also show posted activity associated with production that is not yet finished.

Production Order Lines

The No. of Prod. Order Lines field supports drilldown.

This can be useful for identifying the finished production orders that contributed to the analysis.

The application treats this drilldown as an approximation of the production order lines used by the scheduled calculation rather than retaining an exact lineage list for every result, so minor discrepancies between the drilldown and the calculated sample are possible.

Use Operator Insights

When Shop Floor Insight is installed and production time is associated with Shop Floor employees, select a routing operation and choose:

Operator Insights

The page opens already filtered to the selected routing and operation.

Key fields

Shop Floor Employee No.

Identifies the operator associated with the runtime.

Activity Value

Identifies the Shop Floor Insight activity associated with the work.

This can be particularly useful when Activity Codes are used to identify activities such as rework.

Sample Count

Shows how many runtime observations support the analysis.

More samples generally mean more confidence in the result.

Mean Hours Per Qty.

The operator’s average runtime per base unit.

Lower means faster.

Higher means slower.

Expected Hours Per Qty.

The routing standard used as the baseline.

Mean Delta Percent

Shows the operator’s performance relative to the expected runtime.

Positive = slower than expected

Negative = faster than expected

Std. Deviation

Shows the absolute variability in the operator’s runtime.

Coefficient of Variation

Normalizes variability relative to the operator’s average runtime.

This is useful when comparing consistency across operations with very different normal runtimes.

Best Runtime Score

A deterministic score combining faster-than-expected performance, consistency, and confidence.

A higher value indicates stronger evidence that the operator performs that operation efficiently and consistently.

Struggling Score

A deterministic score combining excessive runtime, variability, and confidence.

A higher value indicates stronger evidence that the operation may warrant investigation for that operator.

Confidence

Ranges from 0 to 1.

The score is based on:

Sample Count ÷ Minimum Operator Samples

capped at 1.

With the default minimum sample count of three:

• 1 sample gives low confidence.
• 2 samples gives partial confidence.
• 3 or more reaches full sample-count confidence.

Finding

Provides a plain-language explanation of why the row was flagged.

Data Quality Flags

Identifies problems such as:

• Missing operator
• Missing activity
• Zero output
• Other data anomalies

These should be reviewed before drawing conclusions from an unusual score.

How to use Operator Insights responsibly

Operator scores are best treated as an investigation tool, not an employee scorecard in isolation.

For example, a high Struggling Score could indicate:

• A training opportunity
• Difficult jobs being disproportionately assigned to one employee
• Rework
• Inconsistent production conditions
• Incorrect time reporting
• Poor source data

Similarly, a high Best Runtime Score can be useful for finding people whose methods may be worth observing and standardizing. For example, the same employee can even surface in different ways depending on the underlying runtime and variability characteristics, reinforcing the need to review the supporting data rather than treating one label as the conclusion.

Use Copilot with Scheduled Results

One of the advantages of Scheduled Routing Analysis is that the result records are stored persistently and can therefore be made available to Business Central’s Copilot capabilities. The original interactive Routing Analysis page primarily uses temporary buffer records, which are not suitable for the same page-grounded analysis.

On supported builds, the Scheduled Routing Analysis Results page includes:

Evaluate selected line with Co-Pilot

This evaluates the current routing operation and can summarize potential bottlenecks, over-performance, or high variability.

For broader page analysis where Business Central’s Copilot capabilities are available, useful questions include:

• “Which routing demonstrates the most variability?”
• “Which operations are taking the most time above their expected runtime?”
• “Which operations have the largest estimated cost variance?”
• “Which operations have become slower recently?”
• “Which operations have improved the most recently?”
• “Which routings have high runtime variability?”
• “Which operations have the highest scrap percentage?”
• “Which routing standards appear furthest from actual performance?”

The internal walkthrough demonstrates the question:

“Which routing on this page demonstrates the most variability?”

with Copilot using the routing data and standard deviation to identify the result.

Copilot should be used to help explore and summarize the data. Important conclusions should still be verified using the calculated fields and source-record drilldowns.

Recommended Starting Configuration

For a customer setting up Scheduled Routing Analysis for the first time, the supplied defaults are a sensible baseline:

Setting	Starting value
Routing No. Filter	Blank / all relevant routings
Starting Date Formula	-6M
Ending Date Formula	0D
Recent Trend Formula	-1M
Min. Average Variance	0.05
Min. Std. Deviation	0.05
Results Filtering	All Lines
Include Without Prod. Orders	Exclude
Min. Operator Samples	3
Excessive Time %	10
High Variation Threshold	0.25

Run this configuration initially and examine the volume and usefulness of the results before making the thresholds more restrictive.

For a high-volume manufacturer with hundreds or thousands of routings, it may be useful to narrow the routing filter or raise the minimum variance thresholds once you understand the customer’s typical runtime behavior.

Common Troubleshooting

No Scheduled Routing Analysis Results appear

Check the Job Queue Entry first.

The automatically created entry starts On Hold. Verify that:

• A recurrence has been configured.
• The status is Ready.
• The Job Queue has executed successfully.
• There are finished production orders in the configured date range.
• Routing filters are not too restrictive.
• Minimum variance thresholds are not filtering everything out.

The dates are not advancing

If rolling dates are desired, verify that Starting Date Formula and Ending Date Formula are populated and that the Job Queue is actually running.

The concrete Starting and Ending Dates are recalculated when the scheduled process executes.

Too many irrelevant results appear

Consider:

• Using Only Difference.
• Increasing Min. Average Variance.
• Increasing Min. Std. Deviation.
• Setting Include Without Prod. Orders to Exclude.
• Narrowing Routing No. Filters.

An operation shows unexpectedly high variability

Check:

• Number of production order lines
• Capacity Ledger Entries
• Posted runtime
• Output quantities
• Runtime units of measure
• Unusual individual production orders
• Changes in machines, tooling, operators, or processes

A high standard deviation often indicates that the average alone is hiding important variation.

% Difference looks high but the operation is actually faster

This can be expected.

The underlying average difference is an absolute difference, so use Mean Time vs. Routing Run Time or the Summary to determine direction.

Operator Insights is empty or not useful

Verify that Shop Floor Insight is installed and that production activity is actually recording the operator and activity information required for the analysis.

The routing-level analysis does not require employee data, but Operator Insights does.

Copilot cannot answer questions about the original Routing Analysis page

Use Scheduled Routing Analysis Results instead.

The scheduled results are persistent records specifically suited to analysis and AI grounding, whereas the original interactive “Routing Analysis” analysis relies on temporary buffer records.

Optional Use with Power Automate or Copilot Studio

For consultant-led integrations, the application also exposes the persisted Scheduled Routing Analysis information through read-only API queries.

The Routing Analysis API uses:

Publisher: insightWorks
API Group: iwxRoutingAnalysis
Version: v1.0
Entity: routingAnalysis / routingAnalyses

Operator results are also exposed through the same API group using:

Entity: operatorTime / operatorTimes

These persistent APIs can be useful when a customer wants to consume routing-performance data in Power Automate, Copilot Studio, reporting, or another external analysis process.

Business Analyst/Consultant Review Checklist

When reviewing Scheduled Routing Analysis with a customer:

1. Confirm the date window represents enough production history.
2. Confirm the Job Queue is scheduled and successfully refreshing the results.
3. Review the highest Estimated Cost Variances.
4. Review operations with high Standard Deviation.
5. Compare Mean Runtime against Routing Runtime.
6. Review recent Trend % for deterioration or improvement.
7. Confirm suspicious results have enough production-order samples.
8. Drill into Capacity Ledger Entries before recommending routing changes.
9. Review setup-time and scrap information where applicable.
10. If Shop Floor Insight is installed, review Operator Insights with emphasis on samples, confidence, findings, and data-quality flags.
11. Use Copilot to help identify patterns, then validate its answer against the underlying calculated fields.
12. Adjust the scheduled thresholds only after establishing what “normal” looks like for that customer’s production environment.

The objective is not simply to find every routing whose actual runtime differs from its configured runtime. The most useful application of Scheduled Routing Analysis is to identify which differences matter, determine whether they reflect a production problem or an outdated standard, and focus improvement efforts where the operational or financial impact is greatest.