Better Data

Reference

SCM workspace (apps/scm)

Edit this page

SCM workspace (apps/scm)

apps/scm is the Next.js workspace where tenant organizations run Commerce Chain Optimization (CCO): inventory, planning, procurement, fulfillment, demand intelligence, orders, returns, gateway/registry operator flows, and billing. It is the primary hosted surface for the @betterdata/scm-* and @betterdata/dcm-* module families described in SCM packages and DCM packages.

Despite the repo folder name scm, the same application hosts both SCM (supply-side operations) and DCM (demand-side, channel, and customer-order flows). The split is a domain boundary and module ID prefix (scm.* vs dcm.*), not two separate web apps.

SCM vs DCM — what lives where

| | SCM (Supply Chain Management) | DCM (Demand Chain Management) | | --- | --- | --- | | Focus | Supply and execution — what you hold, move, make, buy, and receive | Demand and promise — what customers and channels ask for, how orders and returns flow | | Typical questions | Where is stock? What should we reorder? Did we receive it? Ship it? | What is demand telling us? Which orders need allocation or intervention? How do returns close? | | Module ID prefix | scm.* (e.g. scm.inventory, scm.procurement, scm.execution) | dcm.* (e.g. dcm.demand, dcm.orders, dcm.returns) | | OSS packages | @betterdata/scm-inventory, scm-procurement, scm-execution, scm-catalog, … | @betterdata/dcm-demand, dcm-orders, dcm-returns, dcm-channels, … | | Example governed loops | scm.procurement, scm.fulfillment, scm.replenishment, scm.quality | dcm.demand, dcm.order, dcm.returns |

In one sentence: SCM tightens physical and purchase-to-deliver operations; DCM tightens signal-to-cash loops on the demand side (forecast → order → return). Both participate in the same loop model and the same CCO navigation model (Sense → Decide → Approve → Execute → Improve; Govern for trust, access, and audit) in apps/scm.

How this appears in the product UI

  • Service module cards on /welcome (e.g. Inventory & Operations, Commerce Gateway) group capabilities for onboarding; tier-2 rows like Procurement and Fulfillment are SCM operating domains under that card — not separate top-level “SCM vs DCM” tabs.
  • DCM surfaces are woven through the same workspace: for example forecasting, demand signals, orders, and returns routes align with DCM packages and dcm.* loop families.
  • Internal probes enumerate routed modules such as scm.inventory, scm.catalog, scm.procurement, scm.execution, dcm.demand, dcm.orders, and dcm.returns — reflecting one app routing both families.

Usage-based pricing (hosted)

Better Data’s hosted commercial model is usage-based around loop outcomes, not seat count. The canonical overview lives under How pricing works:

  • Loop completion — billable completions are counted when a loop instance reaches an eligible terminal state (e.g. procurement or return closed, order completed or cancelled per policy).
  • Committed volume — plans include a monthly committed loop completion allowance; overage is billed per your contract when you exceed that commitment.
  • Where to see usage — in apps/scm, open Settings → Billing to view commitment, current-period completion counts, utilization, and threshold / overage indicators.

Enterprise customers negotiate custom commitments, annual terms, and volume tiers; contact hello@betterdata.co for packaging aligned to your modules and regions.

Hosted Loop Engine describes outcome-based positioning for the loop runtime; apps/scm billing surfaces the same completion-based lens in product settings. For list-price style tiers on the public site, see your commercial docs and How pricing works.

Monorepo location

| Item | Path | | --- | --- | | SCM workspace app | apps/scm/ (bd-forge-main) | | CCO-style navigation config | apps/scm/app/(authenticated)/components/sidebar/navigation-cco.ts | | Welcome module grid (Inventory & Operations groups) | apps/scm/lib/welcome-modules-config.ts, apps/scm/lib/welcome-core-modules-config.ts |