Meridian: from department files to owned actions.

Meridian runs four plants and four warehouses on department workbooks: production by shift, purchasing trackers, stock counts and a standard cost sheet. Each department kept its own version of the numbers, so the weekly meeting began by reconciling them instead of acting on them.

We didn’t ask anyone to give up their files. SAS loads them as they are, and the project is laid out in five stages, each a folder of programs with a flow beside every program.

The 19 files became 23 raw tables, 12 cleaned tables and 23 gold tables ready for decisions. Forty cleaning rules fixed 28,098 rows: money typed as text, dates in three formats, shift codes written several ways. Each rule writes a line to the data quality log.

Every program has a flow, so SAS Lineage can draw the path from any table back to the program that built it and forward to the reports that read it.

A planner’s question is simple: which product, at which warehouse, will drop below its reorder point in the next four weeks? Model Studio trained seven candidates on the same features (stock against reorder point, stock in transit, recent shipments, supplier lateness and season), with later weeks held back for testing.

Forest ranked best on the held-back weeks and was registered in Model Manager as the champion. Gradient boosting is retrained in code every week as the challenger, so a slipping champion shows up in the numbers.

A score is not an action yet. The decision Meridian_next_best_action runs the champion model, then two rule sets. “Choose action” (6 rules) decides whether a stock position needs a reorder, a purchase order needs expediting, a product needs a margin review or a line needs checking. “Priority, owner and review” (14 rules) sets priority by money at stake, picks the owner, sets the deadline and decides when a second person checks.

The decision is published to the SAS Micro Analytic Service, so anything that can make a web request can ask it what to do.

A scheduled job runs every Monday at 06:00. It reads back what people decided and resolved in Lantern, builds this week’s candidate actions, sends each one through the published decision, drafts the messages, measures last week’s outcomes and pushes the results to Lantern.

The batch job calls the same published decision as everything else, so an action in a report and an action on screen can’t disagree. If the decision service can’t be reached, the job stops and keeps last week’s actions rather than publishing an empty list.

Lantern gives each action one owner and shows why SAS raised it: the rule that fired, the champion’s probability for stock positions, and the rule set that chose its priority, owner and deadline. The owner does the work (calls the supplier, checks the line, places the order), records what was done and resolves it.

What people see follows their role. A buyer sees purchase orders, a shift lead sees their own line, and the database enforces it row by row.

Each week the job checks resolved actions against what happened next: did the stock run out, did the purchase order arrive on time, did the defect rate come back down. The results are pushed to Lantern beside the action.

The models are judged the same way. Champion, challenger and a plain stock-level ranking are scored on the same 1,100 held-back rows, 138 of which ran out within four weeks.