Before and After Case Studies

Before-and-after case studies are one of the best ways to understand the real value of IoT in manufacturing.

But they must be built honestly.

A weak case study says, “We installed IoT and productivity improved.” That is not enough. A strong case study shows the condition before implementation, the specific problem, the first-phase scope, the data captured, the operational changes made, and the measurable results after adoption.

Manufacturers should be careful not to invent dramatic claims. The most useful case studies are grounded in real operating metrics: downtime, reporting time, production visibility, energy use, quality loss, maintenance response, inventory accuracy, and delivery performance.

This article explains how to structure before-and-after IoT case studies in a way that is useful for management, sales, internal teams, and future improvement.

Why Before-and-After Matters

IoT is easier to justify when the improvement is visible.

Before implementation, many factory problems are described vaguely:

• Machines stop too often.
• Reports are delayed.
• Supervisors are overloaded.
• Energy cost is high.
• Quality issues repeat.
• Planning is inaccurate.
• Inventory is confusing.

After implementation, the factory should be able to describe the problem more clearly:

• Which machines stopped most often
• Which downtime reasons repeated
• How much reporting time reduced
• Which energy losses were identified
• Which quality patterns became visible
• Which planning assumptions changed
• Which workflows improved

The value of IoT is not only that numbers improve. It is that the factory finally understands where improvement is possible.

Start With a Baseline

Every case study should begin with a baseline.

The baseline is the “before” picture. It should capture how the factory worked before IoT.

Useful baseline metrics include:

• Average machine downtime per shift
• Percentage of unknown downtime
• Manual reporting time
• Production output against plan
• Energy consumption
• Rejection or rework rate
• Maintenance response time
• Shift handover quality
• Inventory mismatch frequency
• Dispatch delays

If baseline data is weak, document that too. “Downtime reasons were not recorded consistently” is itself an important before-state insight.

Define the First-Phase Scope

A case study should clearly explain what was included in the first phase.

For example:

• 5 critical machines monitored
• Machine status and downtime captured
• Operator downtime reason entry added
• Supervisor dashboard created
• Energy meters added to bottleneck area
• Production count linked with shift reports
• Management summary dashboard introduced

This prevents the case study from sounding vague. Readers can understand what was actually implemented.

Show the Operational Change

IoT does not create results only by collecting data. Results come from using the data.

A strong case study explains what changed in daily work.

For example:

• Supervisors began reviewing downtime during the shift
• Maintenance received alerts for repeated stoppages
• Operators selected standard downtime reasons
• Management reviewed plan-versus-actual daily
• Energy reports were reviewed weekly
• Quality team checked rejection trends by machine
• Planning adjusted cycle-time assumptions

This helps people understand that IoT is not a magic box. It supports better management routines.

Compare Before and After Metrics

The “after” section should compare meaningful metrics.

Examples include:

• Unknown downtime reduced
• Manual reporting time reduced
• Long stoppage response improved
• Plan-versus-actual visibility improved
• Energy waste identified
• Rejection reasons became clearer
• Maintenance priorities improved
• Shift handover became more structured

When exact numbers are available, use them. When exact numbers are not available, explain the qualitative improvement clearly and avoid exaggeration.

Example Case Study Structure

A practical case study can follow this format:

1. Factory context
2. Business problem
3. Before-state challenges
4. First-phase IoT scope
5. Data captured
6. Workflow changes
7. After-state results
8. Lessons learned
9. Next-phase roadmap

This structure keeps the story credible.

Example: Downtime Visibility Case Study

Before IoT, a factory may know that output is low, but not know why. Operators may write downtime in registers, supervisors may summarize it later, and management may only see broad categories.

After IoT, machine stoppages can be captured closer to real time. Operators can enter reason codes. Supervisors can see which machines are stopped and why. Management can review top losses by machine, shift, and reason.

The case study should show:

• Before: downtime was recorded late and reasons were unclear
• Implementation: machine status and reason codes were added
• After: top downtime causes became visible
• Action: maintenance and planning focused on recurring losses
• Result: better response and more structured improvement

This is credible because it explains the path from visibility to action.

Example: Reporting Time Case Study

Before IoT, a supervisor may spend significant time collecting operator entries, checking registers, preparing Excel reports, and answering management calls.

After IoT, production count, machine status, downtime, and shift summaries may be available in dashboards.

The case study should show:

• Before: manual reporting consumed daily supervisor time
• Implementation: production and downtime data captured digitally
• After: reporting became faster and more consistent
• Action: supervisors used time for issue resolution instead of data collection
• Result: better shift control and fewer reporting disputes

This type of case study is especially useful for small manufacturers.

Example: Energy Waste Case Study

Before IoT, the factory may only see total monthly energy cost.

After connecting energy meters, the factory can see energy use by machine, line, shift, or utility.

The case study should show:

• Before: energy cost was known only at bill level
• Implementation: meters connected to dashboards
• After: idle consumption and abnormal usage became visible
• Action: operating discipline and maintenance improved
• Result: clearer energy control and sustainability tracking

This is useful because energy savings can often be measured directly.

Lessons Learned Section

Every case study should include lessons learned.

Possible lessons include:

• Start with fewer machines but deeper data
• Reason codes need refinement after go-live
• Operator training is critical
• Dashboards should be role-specific
• Data validation must happen early
• Maintenance ownership is needed
• Management review cadence creates results
• Integration with production and inventory improves value

Lessons make the case study more authentic and useful.

Where AICAN Optiwise Fits

AICAN Optiwise helps manufacturers create stronger before-and-after stories because it connects operational visibility with production, inventory, purchase, finance, reporting, and management workflows.

A case study becomes more meaningful when machine data is connected to business outcomes: better production control, clearer material movement, improved reporting, reduced downtime confusion, and stronger management visibility.

AICAN focuses on practical digitization that can be measured through real factory improvement. You can learn more on the About AICAN page.

FAQ

Should I use exact numbers in an IoT case study?

Use exact numbers when they are available and verified. Avoid invented or exaggerated claims. Credibility matters more than dramatic storytelling.

What metrics should a case study track?

Track downtime, production output, reporting time, energy consumption, rejection, rework, maintenance response, inventory accuracy, and delivery impact where relevant.

Can a case study be useful without exact ROI numbers?

Yes, if it clearly explains the before-state, operational change, and after-state improvement. But financial ROI should be added when reliable data is available.

How long should a case study period be?

It depends on the process, but many factories need at least a few weeks or months of post-implementation data to identify meaningful trends.

How does AICAN Optiwise support case study tracking?

AICAN Optiwise connects manufacturing workflows and reporting, making it easier to track improvements across production, inventory, purchase, finance, and operations.

What should I avoid in case studies?

Avoid fake metrics, vague claims, cherry-picked data, and statements that ignore process changes. A good case study shows how improvement happened.

Founder’s Note

The best case studies are honest.

At AICAN, we believe manufacturers do not need exaggerated success stories. They need practical proof that a system helped the factory see better, decide faster, and improve with discipline.

A before-and-after story should respect the work behind improvement.

Final Thought

Before-and-after IoT case studies should show the real journey: baseline pain, focused implementation, workflow change, measurable improvement, and lessons learned.

With AICAN Optiwise, manufacturers can connect operational data with business workflows, making their improvement stories clearer, more credible, and more useful for future decisions.