Skip to main content
Business operating model

Explore the Connected Business

Spud Software helps a business understand, organize, connect, and continuously improve its operations. This page is the operating model: how the customer promise, the work, the material, and the cost stay together. The map, the seven stories, and the weekly review use bracket BR-14 on job 1842. They are not a SpudERP screen, and they are not a claim that every relationship is already deployed.

Illustrative model

Operating landscape

Map controls

All lenses. Six modeled links stay on the map. Point to a neighborhood to see only its links.

An example path highlights one chain. A scenario narrates a chain on this same map and keeps your place if you explore.

Follow one chain on this map: a quote through to margin, or a machine breakdown through to the schedule and the customer promise.

Neighborhoods

Six cross-department flows are labeled. The arrow is direction. The dash pattern matches the legend. Select a neighborhood to emphasize its handoffs.

  • Information
  • Work
  • Resources
  • Financial consequence

The arrow is direction. The dash pattern matches the name, so the category is not color alone. A missing link is a gap in the record, not another department. These lines are not a claim of a live integration.

How to use this landscape

Select a neighborhood. Its handoffs stay on the map, and the others dim without closing.

Open a handoff for the decision it supports, and for what changes if the record is missing or stale.

The figures use bracket BR-14 on job 1842 for a catalog customer. They are not a real company and not a SpudERP screen. A business can put one link in place at a time. This is the relationship the records need. It is not a claim that every link is already configured, and it is not a weekend cutover.

Operating notes

What has to stay in agreement

These are the facts that have to agree if a promise is going to be kept, and if the company is going to know what that work cost. This is the business. It is not a list of software modules.

  • Demand. The quote, the order, the change, and the date that was actually promised.
  • Work. The job, the routing steps, and the status the floor is reporting now.
  • Materials. What is on hand, what is on order, and what the job still needs before it can move.
  • Capacity. People, skills, machines, and the hours those resources can still give this week.
  • Movement. Receipts, issues to a job, shipments, and returns. Quantity has to survive each handoff.
  • Cost. Labor, material, outside processing, and the overhead that belongs to that job.
  • Quality. Holds, scrap, rework, and the reason a quantity or a date changed.
  • The weekly questions. What is late, what is short, what changed since the prior week, and what it cost.

What breaks when those facts live apart

The same work is often described in email, a spreadsheet, a traveler, and a shipping note. Each copy can be locally reasonable and still be wrong for the next decision. People are usually reconciling in good faith. The break is that no single record is responsible for the quantity, the date, or the status the next person will act on.

  • Quantities diverge. The order, the traveler, and the shipper show different quantities for the same work.
  • Purchasing and the floor disagree. A shortage report triggers a buy while the material is already at the machine, or the reverse.
  • Status depends on the department. Production calls the job complete. Cost is still open because the hours never landed on that record.
  • Dates live in inboxes. The date the customer was given is in email. The schedule still shows the previous one.
  • The meeting waits on a rebuild. Someone exports, pastes, and reconciles before anyone can see the prior week.
  • A decision never reaches the record. The change is agreed in the room, and the floor keeps working from the previous instruction.

How one record carries the request, the resources, and the cost

A request becomes a record. Resources are assigned to that record. Cost follows the resources. Status changes once. Where a current system still holds one of these facts, that system can remain until the shared record is fit to take the handoff. This is not a statement that SpudERP already performs every step.

  1. The request is written once. Who asked, what they asked for, the quantity, and the date that was accepted.
  2. Other work points at that record. A change is made on the record. A side spreadsheet is not a second source of the promise.
  3. Resources are assigned to it. Material, a routing step, a person, a machine, or an outside process.
  4. Time and money follow the resource. Cost comes from the work that was recorded, not from a file assembled after the shipment.
  5. One status change is the status. Planning, purchasing, the floor, shipping, and the weekly review are looking at that same change.
Weekly management review

Are we on track?

These figures use bracket BR-14 on job 1842 for a catalog customer, for the week of October 20-24, 2026. The meeting is Monday, October 27, 2026. They are not a real company, not a live operational result, and not a SpudERP screen. This is the meeting the records can support. It is not a claim that SpudERP already runs this review.

  • More about this figureSales & Marketing owns that customer commitment. No revised date is written on the award. The blank is not an on-time result.
  • More about this figure40.0 scheduled hours, minus 4.0 hours downtime, minus 4.0 hours of absence that did not overlap the downtime.

A forecast is not an actual, and it does not guarantee the week.

How a forecast is made

A forecast starts from historical throughput, labor and equipment availability, open orders, shifts, lead times, and assumptions written on the capacity calendar. It describes a week that has not been reported. A forecast is not an actual. This page does not treat a forecast as an AI result, and it does not guarantee the week. A forecast cell says No forecast when this record has none. Estimate, unknown, and stale stay marked. A missing figure is not stored as zero.

  • Actual
  • Target
  • Forecast
  • Estimate
  • Unknown
  • Stale

Department

All departments. 9 metrics in the KPI summary. Open an exception, a decision, or a metric for the calculation, the source event, the record, and the owner.

Named owners stay on their own decisions: Quality lead, Inventory lead, Buyer, Maintenance lead. A department packet can cite the line. It does not take the decision.

Exceptions and risks

Decisions needed

Owned action items

KPI summary

Each figure stays labeled Actual, Target, Forecast, Estimate, Unknown, or Stale. No forecast means this record has none. No actual means the actual was not recorded. Neither is written as zero. Open a row for the calculation.

KPI summary. Modeled figures for job 1842, not live company results.
MetricActualTargetForecastEstimate, unknown, stale
Actual26.0 good hours
Target40.0 good hours
Forecast30.0 good hours
None
Actual34 pieces shipped
Target40 pieces by October 24
No forecast
UnknownRevised promise date
StaleCustomer message, October 17
Actual$7,426 margin to date
TargetHold the $8,400 estimate
No forecast
Estimate$8,400 estimated margin
StalePlate standard dated October 1
Actual6.0 rework hours
Target0.0 rework hours
No forecastNone
Actual2 unresolved RFIs
Target0 unresolved at the meeting
No forecast
Unknown1 RFI has no owner
Actual2 actions older than 14 days
Target0 actions older than 14 days
No forecast
UnknownThe 18-day action has no owner
Actual4.0 hours down
Target0.0 planned downtime hours
Forecast0.0 hours down
None
Actual$12,400 past terms
Target$0 past terms
No forecast
StaleCollection note from October 20
Actual88.9 percent
Target85 percent of available hours
Forecast36.0 available hours
UnknownIndirect hours
Ten agenda categories

The meeting still has every category. One category is open at a time. The lines are assembled from the metrics, the requests, and the actions. They are not typed in again. A weekly review leaves with one of these kinds of decisions: Expedite or resequence a job because the record says the date will be missed. Buy, move, or stop material because the shortage is on the job, not in a separate list. Accept a date change and tell the customer from the same record the floor will use. Treat a cost variance as a process problem: hours, scrap, or a price that was never on the job.

Choose a category to read its lines.

Responsibility register

The roster can use different department names. These four responsibilities stay named either way. A host packet can cite the line. The host does not take the decision.

  • Quality. Owner: Quality lead. Named on the Operations packet because the hold stops the job. The disposition stays with the Quality lead. Operations reports the hours and does not close the hold.
  • Inventory. Owner: Inventory lead. Named on the Operations packet because the job cannot run without the plate. The on-hand balance stays with the Inventory lead. A stored zero is not an empty bin until Inventory says so.
  • Supply chain. Owner: Buyer. Named on the Operations packet because the lead time sits inside the forecast. The purchase order and the lead time stay with the Buyer. That lead time is an assumption, not an Operations actual.
  • Maintenance. Owner: Maintenance lead. Owned on the Facilities/Assets packet. The Operations packet cites the lost hours. The repair and the downtime stay with the Maintenance lead. Operations does not own the asset.
How a figure is allowed into the meeting
  • Mapping. Each metric names the records it is allowed to cite. Throughput cites labor reports, the capacity calendar, and the maintenance request. It does not cite a spreadsheet prepared for the meeting.
  • Reconciliation. Job 1842 awarded 40, shipped 34, and still has 6 on hold. Those three quantities stay visible together. The invoice is held to 34. A single blended number would hide the exception.
  • Validation. A missing labor report, a missing owner, or a missing revised date stays unknown. The meeting does not store unknown as zero. A stored zero for plate PL-7 failed that test: the shelf held 12.
  • Corrections. A decision writes the change onto the record it cites. The revised promise belongs on the award. The disposition belongs on the hold. A note that lives only in the meeting is not a correction.
  • ActualTaken from a recorded event inside the date range.
  • TargetThe goal set for that range. A target is not evidence the goal happened.
  • ForecastA projection for time that has not been reported. It is not an actual and it is not a guarantee.
  • EstimateA quote or a standard used before the actual exists. It stays an estimate after the actual posts.
  • UnknownThe fact was not recorded. Unknown is not zero.
  • StaleThe record is older than this meeting, or a later record still cites a value that was replaced.

The guided story Weekly review follow-through walks one exception on the landscape. A plant that still rebuilds this packet before the meeting can start with that. When you want to walk through your own plant, discuss your operations. That conversation does not require replacing what you run today.

SpudERP and the partnership

How Spud helps

Spud Software helps a business understand, organize, connect, and continuously improve its operations. SpudERP is the technology a shared record can move into after the people who use it will trust the fields. The partnership decides the sequence.

  • Discovery

    Name the records people already trust, and the ones they export and recheck before they will use the number.

  • Cleanup and governance

    Clean the fields a decision needs: item, quantity, date, status, and cost. Say who can change the record, and how a correction is written down.

  • Phased connection

    Connect the next process only after that record survives a weekly review. A plant can keep an integration it already runs. This is not a cutover weekend.

  • Continuous improvement

    The rest stays on a roadmap. SpudERP is the technology a shared record can move into. This page does not treat those capabilities as already switched on.

Adopt one record at a time

The sequence is one process, then the next. It is not an overnight replacement.

The five steps
  1. Name the records people already trust. And name the ones they export and recheck before they will use the number.
  2. Choose one process to share a record. Usually the promise to the customer, the job status, or the material the job needs.
  3. Clean the fields a decision needs. Item, quantity, date, status, and cost. A field the weekly review will not use can wait.
  4. Connect the next process after the review holds. If the record survived the meeting, the next handoff can use it. If it did not, correct that record first.
  5. Keep the rest on a roadmap. The end state is one set of records. The path there is sequenced. It is not a cutover weekend.

Data integrity

Integrity is whether the next record can trust the previous one. It is not another department.

Source, clean, connect, and govern
  1. Source. Where the fact is captured: the order, the floor report, the receipt, the time entry.
  2. Clean. The fields that have to be fit to use before anyone relies on them.
  3. Connect. The next process allowed to treat that record as its source.
  4. Govern. Who can change the record, and how a correction is written down.

Unknown is not zero. A stale date is not the current promise. An assumption in a quote or a forecast is not an actual. A difference nobody dispositions is not a tie-out. Those comparisons are walked on the landscape.

What the shared record carries

The desired operating model keeps a customer or supplier message, a request for information, a status update, an invoice, and the reply with the record they concern. An internal request, such as a key fob or a facility light, follows the same sequence: receive, route, claim, act, verify, and close. The action can carry a checklist. Hours and cost can be recorded to a job or to a cost center. This is how the records should work together. It is not a statement that SpudERP already covers every step.

Work is a work order opened from the award. Hours and cost can land on that job or on a cost center. Finite capacity and throughput say what the cell can still give this week. Finance can trace the shipment, the cost, and the ledger entry to the same job. The weekly review is assembled from those records. It is not a deck rebuilt the night before, and it is not a live SpudERP screen.

Not everything changes overnight. A plant can keep an integration it already runs while the fields a decision needs are cleaned and governed. The next process is connected only after that record survives a weekly review.

The Platform page describes SpudERP capabilities. The How It Works page describes discovery, a first slice of work, and a roadmap. When you want to walk through your own plant, discuss your operations. That conversation does not require replacing what you run today.

Discuss your operations

If you want to walk through how requests, work, materials, and cost move in your plant, start with that. There is no requirement to replace what you run today.

Contact Spud Software

9478 South Saginaw Street
Grand Blanc, Michigan 48439
810-695-0001