What is SIOP OS, what do I need to do, and what will I get?
SIOP OS turns operating data into a short list of decisions worth investigating.
You provide ordinary ERP, MRP, inventory, purchasing, supplier, demand, or planning data. SIOP OS translates what you have, checks whether it is trustworthy enough to use, connects related items and sources, and reduces the data into prioritized issues with the records and measurable exposure behind them.
Raw business data
What is happening?
Why does it matter?
What should I investigate?
Question 1
What is this and how do I use it?
Start with one simulated company below. The application walks the same path your own data will follow: translate → identify → validate → analyze → act → report. You can explore without uploading anything.
Question 2
What is expected of me?
Very little. For a simulation: choose a company and explore. For your data: export a sanitized CSV, upload it, and answer only the mapping or item-equivalency questions the software cannot safely resolve itself.
Question 3
How will I know it gave me value?
Do not judge it by the number of charts. Judge it by whether it exposes a meaningful issue, quantifies it, identifies the exact records driving it, and gives you a credible investigation path you did not have before.
Your work in the beta: Choose a simulated company → inspect the top priorities → click into the evidence → compare the report-out. With your own data, add one step: upload the file and confirm uncertain translations. SIOP OS should do the analytical work; you supply business judgment only where context cannot be inferred safely.
Why are there four different simulated companies?
They are not four cosmetic demos. They deliberately hold some analytical concepts constant and change other operating conditions so you can see whether the engine adapts to the business model instead of producing the same generic answer every time.
Electronics
High mix + short lifecycle
Designed to expose: lifecycle/obsolescence, volatile demand, configure-to-order complexity, launch/EOL exposure and supply timing.
Industrial valves
Stock + engineered-to-order
Designed to expose: different fulfillment models inside one manufacturer, runner/repeater/stranger behavior, engineered demand and stocking-policy mismatch.
Parts distributor
Multi-warehouse + multi-source
Designed to expose: network imbalance, defined supplier splits, commodity multi-source buying with no fixed split, pack-size economics and sourcing concentration.
Packaging
Repeat production + stock runners
Designed to expose: stable demand, customer/program relationships, production/replenishment discipline and the difference between planned stock runners and exceptions.
What should look similar
The same basic workflow and page structure.
Data translation and readiness checks before conclusions.
A small number of prioritized issues rather than hundreds of KPIs.
Every priority drills to records, dollars/units/risk and an investigation path.
Reporting derives from the same underlying evidence.
What should intentionally be different
The highest-priority problem.
The data fields that matter most.
The analytical modules that activate.
The meaning of inventory, demand, sourcing and fulfillment signals.
The recommendations and report trends. If every scenario produces the same answer, the tool has failed the test.
What counts as empirically valuable output?
A useful output is not “inventory is high.” It is closer to: these 17 item/source/location combinations create $420K of modeled exposure; these six records create 71% of it; the pattern is consistent with a sourcing-allocation, lifecycle, replenishment, or network imbalance issue; here is the evidence and what to verify next. The number must reconcile to the data and the recommendation must be no stronger than the data allows.
Start with a simulated company
Pick the environment closest to something you understand, then try a very different one. The comparison is part of the training.
How to choosePick the scenario closest to something you already understand first. Then run one that is very different. The comparison is how you verify the engine is interpreting context rather than reusing one generic rule set.
What to compare afterwardCompare Data Translation, Item & Source Identity, Data Readiness, Data Coverage, Today, Workbench and Reporting. Similar structure is good; identical conclusions are not.
After you run a scenario
Start on Today to see the headline value. Then use Workbench to prove the headline reconciles to real records. Finally use Reporting to see whether the same evidence becomes useful in an operating rhythm. Use the other tabs when you want to understand why the tool trusted the data or interpreted the source relationships the way it did.
Self-guided walkthrough
Start Here: What SIOP OS Does, What You Do, and What You Get
What this tutorial doesIt walks through the complete SIOP OS experience—from the problem the tool solves through data translation, item/source identity, readiness, analysis, evidence, reporting, and repeat refresh.
What you need to doNothing. Click Play or use Next. This is the recommended first page for a new user. The tour is self-contained and does not change any data.
Instructor narration readyInstructor narration explains why each page matters instead of reading the screen. Same audio on every computer; no live speech service required.
Step 1
See the customer file
Narrated walkthrough
Buyer + manager output
What needs attention first?
What this page doesTurns the analysis into a short management priority list: what matters, how large it is, and which issue deserves attention first.
What you need to doReview The One Thing, then click a prioritized action. Do not make a business change from the headline alone—open the evidence underneath it.
Choose a scenario.
Prioritized actions - click any action to investigate
The value test
Before accepting the analysis, ask: Can I see exactly which records created this priority? Can I see a measurable magnitude or risk? Does the recommended investigation logically follow from the evidence? If any answer is no, treat the output as incomplete rather than actionable.
Evidence layer
Action Workbench
What this page doesShows the exact records creating the management themes so a buyer, planner, sourcing manager, or operating leader can work the issue.
What you need to doOpen the highest-value records first. Use the evidence and investigation prompt to validate the facts before taking action.
This is the desk-level layer behind the management themes: the exact items, dollars, quantities and evidence that need investigation.
Choose a scenario
Priority
Theme
Item / Context
Evidence
Exposure
Risk Units
No scenario loaded.
Output intelligence
Reporting Rhythm
What this page doesRepackages the same analysis into daily, weekly, monthly SIOP, and executive operating rhythms.
What you need to doChoose the cadence that matches your role. Built-in scenario trends are simulated for training; uploaded customer trends require repeated real snapshots.
Use the same underlying intelligence for daily action, weekly management, monthly SIOP, and executive reporting.
Training note: Historical trend shapes in the four simulated companies are intentionally simulated and different by scenario. Uploaded customer data will not show a trend until multiple real snapshots are available.
Today's highest-value actions
Exposure by theme
Management note
8-week modeled exposure trend
Theme concentration
Weekly scorecard
12-month SIOP trajectory
Value driver mix
Monthly review prompts
Executive value trajectory
Top operating-system priorities
Leadership narrative
Canonical item model
Item & Source Identity
What this page doesSeparates ERP part numbers from functional item families and approved sourcing relationships, including planned supplier splits and commodity multi-source models.
What you need to doReview sourcing families and allocation behavior. Only confirm possible equivalent parts when you know they are truly interchangeable.
ERP part numbers are treated as source identifiers, not automatically as unique functional items. SIOP OS uses stronger cross-references to identify item families and multi-supplier sourcing relationships.
ERP item numbers
--
Canonical item families
--
Multi-source families
--
Source allocation intelligence
Run a scenario or upload data to evaluate sourcing relationships.
Possible equivalent-part relationships
No identity analysis has been run.
Example sourcing relationship
No item family loaded.
Data integrity gate
Data Readiness
What this page doesChecks whether the data is trustworthy enough to analyze: required fields, UOM, currency, dates, duplicates/granularity, and other integrity risks.
What you need to doResolve blockers. Review warnings. Proceed only when the analysis gate says the data is usable for the conclusions you expect.
The tool should validate and translate the dataset before it generates business recommendations.
Readiness score
--
Upload a dataset to evaluate data integrity.
Analysis gate
No dataset loaded.
Translation & normalization
Customer mapping memory
No customer mapping has been confirmed yet.
Adaptive intelligence
Data Coverage & Confidence
What this page doesShows which intelligence modules the available data can support and which conclusions would be weak or impossible.
What you need to doUse Active modules normally, treat Partial modules with caution, and do not expect conclusions from Unavailable modules.
The tool should use the data that exists, identify which analyses are supportable, and explicitly disable conclusions the dataset cannot justify.
Run a scenario or upload a dataset to see available intelligence.
Data-quality findings
No dataset loaded.
What this dataset cannot prove
No dataset loaded.
Recommended data request
Tier 1
Minimum viable
Item/SKU, on-hand, unit cost, and preferably trailing usage. Supports snapshot prioritization and basic cash exposure.
Tier 2
Operational intelligence
Add open supply, supplier, lead time, MOQ, safety stock, plant/warehouse, lifecycle, and 12 months demand. Supports stronger root-cause and purchasing/sourcing analysis.
Tier 3
Full SIOP / IBP intelligence
Add forecast plan, PO/receipt history, requested/promised/actual dates, payment terms, invoice/pay dates, fulfillment model, production orders, customer/program and lifecycle events.
Data translation
How SIOP OS understood this data
What this page doesTranslates the customer's ERP/MRP column names into a common SIOP OS language.
What you need to doFor simulated companies, no action is required. For uploaded data, review only the uncertain important fields and click Confirm & Continue.
SIOP OS translates source-system terminology into a common analytical language before it runs the analysis.
No dataset loaded
Choose a simulated company or upload sanitized data.
Waiting for data
Translation summary
No data has been translated yet.
We need your help with a few fields
Only fields that are uncertain or important enough to confirm appear below. Leave a field as “Not available” if your dataset does not contain it.
How the source fields were interpreted
This simulated dataset has already been mapped. No tester action is required.
Source field
SIOP OS meaning
Confidence
No action required. This simulated dataset has already been translated and validated.
Source preview
A small preview is shown so you can verify that the file looks like the one you intended to load.
Self-guided training
Learn the Tool
What this page doesProvides a short self-guided map of the input, analysis, action, and reporting flow.
What you need to doUse this page when you are unsure what a term or page means. You should not need a separate training course to operate the beta.
A short map of what goes in, what SIOP OS does with it, and where the answers show up. Start here if this is your first time using the tool.
1. The whole process at a glance
1. InputScenario or customer CSV
2. TranslateUnderstand customer field names
3. IdentifyResolve parts, alternates and suppliers
Run a simulated company. Use the Scenario Lab to see what a complete analysis looks like.
Look at Data Translation. See how the customer's field names were converted into common SIOP concepts.
Review Item & Source Identity. See how multiple ERP numbers, alternates and suppliers are grouped.
Check Data Readiness and Data Coverage. Confirm what the data can and cannot support.
Open Today and Workbench. Move from the management issue to exact records and investigation steps.
Open Reporting. See how the same intelligence feeds operating cadence.
Multi-source sourcing: one important distinction
Defined split: If the plan says Supplier A 70% / Supplier B 30%, SIOP OS can compare planned share with observed sourcing and flag material drift.
Commodity multi-source / no fixed split: If several suppliers are approved but no allocation is prescribed, concentration is not called a plan violation. The tool asks whether the concentration is economically and operationally justified.
Single source: The tool does not invent a multi-source expectation where one supplier is intentionally approved.
3. What the top pages mean
Scenario Lab
Training examples and the entry point for Analyze My Data.
Today
The One Thing and the highest-value actions needing attention now.
Workbench
Exact items, suppliers, plants, projects and evidence behind the actions.
Reporting
Daily, weekly, monthly SIOP and executive report-outs.
Item & Source Identity
Canonical item families, approved alternates, multi-source splits and possible equivalents.
Data Readiness
Can the analysis be trusted enough to proceed? Shows integrity blockers and warnings.
Data Coverage
Which intelligence modules are Active, Partial or Unavailable.
Data Translation
How source-system headers were interpreted. Uploaded data asks for help only where uncertain.
How It Works
Methodology and safeguards behind the analysis.
4. Common fields and terms
Item / SKU
The ERP identifier. It may not be the same as the functional item family.
Canonical item family
The functional item grouping that can contain multiple ERP numbers, supplier numbers or approved alternates.
On-hand
Inventory currently recorded as available or in stock.
Open / inbound supply
Purchase orders, planned supply or production already committed but not yet available.
Run rate / actual demand
Observed usage or shipments used to understand recent consumption.
Forecast / demand plan
Expected future demand. When both forecast and actual exist, forecast quality can be evaluated.
Lead time
Time required to replenish. Actual PO-to-receipt history is stronger than a static ERP setting.
MOQ / order multiple
Supplier or production constraint that can force purchases above immediate demand.
Source allocation
Planned share of demand assigned to each approved supplier, such as 70% / 30%.
Observed share
What sourcing behavior actually appears to be occurring based on available purchasing, receipt or consumption data.
Modeled exposure
Estimated decision-support value used to prioritize investigation. It is not automatically realized savings.
Confidence / fidelity
How much the tool can trust the available fields, mappings and data quality for a specific conclusion.
5. Reporting rhythm
Daily Tracker
Question: What changed and what needs action today?
Best for buyers, planners and operating teams.
Weekly Scorecard
Question: Are exposure and repeated exceptions improving?
Best for functional and plant management.
Monthly SIOP
Question: Are demand, inventory, supply and lifecycle decisions converging?
Best for cross-functional SIOP.
Executive View
Question: Where is enterprise value trapped and is the operating system improving?
Best for COO/CFO/CSCO/Leadership.
Beginner rule: You do not need to understand every field. Follow the pages in order and let Data Readiness/Data Coverage tell you what the file can support.
Traceability
How the output is constructed
What this page doesExplains the logic and safeguards behind the beta so you can understand why an item was flagged and what the tool refuses to infer.
What you need to doUse this page when you want to understand the analysis rules or the limits of a recommendation.
1. Operating theme
A theme is not manually assigned to look good. Records qualify based on scenario-specific operating logic: lifecycle, fulfillment model, engineering release, branch balance, pack size, production release, forecast commitment, and other signals.
2. Measurable exposure
Each qualifying record contributes an estimated dollar exposure and/or unit/service risk. The theme total is the sum of those underlying records.
3. Click-through evidence
Every theme opens to show the actual parts, warehouses, programs, customers, inventory, inbound supply, lead time, demand and reason it was flagged.
4. Investigation, not blind automation
The output says what to investigate next. It does not automatically cancel POs, scrap inventory, change service policy or declare causality without business validation.
Product standards used in this beta
Traceable: a theme must reconcile to underlying records and measurable evidence.
Adaptive: richer data unlocks richer analysis; sparse data narrows the conclusion.
Conservative with ambiguity: the tool warns, asks for confirmation, or disables a conclusion instead of inventing precision.
Action-oriented: outputs should tell the user what to investigate next, not merely describe a KPI.
Self-teaching: a first-time user should be able to learn the workflow from the application itself.