Procurement
Heat Map Engine.

Every Friday began the same way.

Buyers exported multiple SAP reports, ME2N, MB52, and ZMINVENTORY, before manually copying and pasting the information into a large Excel workbook.

The workbook had evolved over years of operational changes. It contained twenty-four worksheets, many of which no longer contributed to the final output. Logic had accumulated organically, creating duplicated calculations, hidden dependencies, and significant manual effort.

After refreshing formulas, manually updating quarterly demand inputs, supplier forecasts, and consumption data, buyers reviewed thousands of SKUs to determine whether inventory should be expedited, postponed, replenished, or ignored.

Although the organization possessed extensive operational data, there was no engineered process capable of transforming that information into consistent, explainable purchasing decisions.

The bottleneck was never information. It was attention.

The Procurement Heat Map Engine separates responsibilities into four independent layers. Each layer performs one function exceptionally well, allowing the system to remain modular, transparent, and easily maintained by future engineers.

Data ingestion begins with scheduled SAP exports and quarterly planning inputs. PowerShell orchestrates extraction, validation, cleansing, logging, and transformation. The calculation layer applies deterministic business rules built directly into a structured Excel engine. Outputs are then published to Power BI dashboards and automated buyer reports.

This separation allows every recommendation to be traced back to its original business rule while preserving full auditability.

The architecture deliberately avoids unnecessary technical complexity.

PowerShell performs scheduled execution, SAP extraction, file management, validation, logging, and process orchestration. Excel remains the calculation engine because it already contains years of trusted procurement knowledge and deterministic business rules. Rather than replacing Excel, the system restructures and validates it as production infrastructure.

Power BI serves as the visualization layer, providing executives and buyers with role-specific dashboards, exception queues, and daily recommendations. Every technology choice prioritizes maintainability, transparency, and organizational adoption over novelty.

# Procurement Heat Map Engine — nightly orchestrator
$run = [DateTime]::UtcNow.ToString("yyyyMMdd_HHmm")
$log = "\\fileshare\heatmap\logs\$run.log"

Write-Log "Pull SAP extracts"      | Invoke-SapExtract -Reports ME2N,MB52,ZMINVENTORY
Write-Log "Validate & cleanse"     | Test-ExtractIntegrity -StopOnError
Write-Log "Run calculation engine" | Invoke-ExcelEngine -Workbook "engine.xlsm"
Write-Log "Apply business rules"   | Invoke-RuleEngine   -Rules "rules.json"
Write-Log "Publish Power BI"       | Publish-PowerBIDataset -Workspace "Procurement"
Write-Log "Notify planners"        | Send-DailyDigest -Top 25

Recommendations are generated through deterministic business rules rather than opaque statistical models.

Inventory health is evaluated using reorder point status, safety stock utilization, lead time, supplier reliability, inventory under inspection, demand stability, and lifecycle classification. The engine converts operational conditions into recommended actions.

Because every recommendation originates from explicit business logic, planners understand exactly why each action is proposed.

The dashboard presents inventory exceptions rather than overwhelming users with every material.

Executive users receive strategic KPIs, inventory trends, supplier exposure, and purchasing performance. Buyers receive ranked recommendations, interactive heat maps, and drill-through capability into every business rule supporting each recommendation.

This design dramatically reduces cognitive load while improving decision speed and consistency.

The deployment transformed procurement from a manually coordinated weekly exercise into a standardized decision support system. Measured improvements include over 80 percent reduction in manual processing, a twenty-four worksheet architecture simplified into a structured pipeline, daily automated execution, standardized business rules across buyers, improved auditability, higher data quality, reduced cognitive load, faster identification of inventory risks, and improved consistency across purchasing decisions.

The greatest improvement, however, was organizational confidence. Every recommendation became transparent, repeatable, and explainable.

The next generation of the Procurement Heat Map Engine expands deterministic decision rules with explainable artificial intelligence.

Future capabilities include predictive inventory risk, supplier disruption forecasting, learning from planner overrides, natural language explanations of recommendations, scenario simulation, and digital twins of inventory networks.

Artificial intelligence should enhance transparency rather than replace it. Human expertise remains the final decision-maker.

The objective is leverage, not autonomy.

What follows is a working notebook rather than a product narrative. It records five versions of the same problem — converting fragmented procurement data into defensible purchasing decisions — and marks precisely where shipped production functionality ends and experimental work begins.

V1 through V4 are what procurement uses. V5 is what I am testing next, and it is labeled that way everywhere it appears.

No agent computes the recommendation. The deterministic rules engine does. Agents read the same typed inputs, produce scoped findings, argue with each other under a mandatory challenge step, and hand a reconciled package to a human. Each agent has a narrow remit so that a wrong finding is attributable rather than diffuse.

• Executive portfolioTwelve synthetic SKUs ranked by urgency, filterable by action, site, criticality, and supplier; selecting a row loads it for review.
• Editable operational inputsOn-hand, open PO, weekly demand, volatility, lead time, supplier OTD, unit cost, safety stock, inspection stock, lifecycle, and criticality all drive the math.
• Six-stage review, ~18 secondsIntake and validation, parallel signal scan, challenge and debate, scenario simulation, synthesis, human review.
• Visible reasoningShared evidence, deterministic rules firing, a consensus/disagreement meter, and explicit unknowns and data warnings.
• Calibrated confidence bandA band rather than a point score, with the reasons and assumptions that produced it.
• Counterfactual labAdjust demand, lead time, OTD, and cost to see before/after recommendation, coverage, risk, and cash effects.
• Full trace + memoEvery stage event is inspectable, and the decision exports as a JSON memo carrying its synthetic-data disclaimer.

The prototype is currently unevaluated. The following is the plan that would make its claims falsifiable, stated before any results exist.

Questions and metrics

Ablations

Limitations and governance

• —The public prototype runs entirely on synthetic data. No supplier, price, or consumption figure in it is real.
• —No empirical performance claim is made for V5. The shipped results reported earlier on this page belong to V1–V4 only.
• —The current public prototype makes no external AI calls; all reasoning is typed deterministic logic executed in the browser.
• —No autonomous purchase order placement. The system proposes; a human disposes.
• —Human authority is structural, not advisory — approve, override, and request-evidence are the only terminal states.
• —Production deployment would require role-based access control and segregation of duties between recommendation and approval.
• —Any ERP write-back would be gated, reversible, and logged, never issued directly by an agent.
• —Language-model agents introduce prompt- and data-injection exposure; untrusted supplier text must be treated as data, never instruction.
• —Supplier pricing and performance data is commercially sensitive and would require tenancy isolation and retention limits.
• —Rules, models, and source extracts must be versioned so any historical decision can be reconstructed exactly.
• —Audit logging must be durable and external to the application.
• —Overrides are signals for rule review, not ground truth. They must never silently retrain a model.