Skip to main content

SAP Fiori · Offline Mobile · Plant Floor

Food and Agriculture SAP Cloud Platform SAP ECC SAP Fiori

How a global meat-snack manufacturer proved offline Fiori on the plant floor before committing to a full rollout

A Global Meat-Snack Manufacturer Delivered 2019

A Design Brainstorming session followed by four weeks of focused development delivered a working offline-capable Fiori app on Android, proving that plant-floor transactions could queue locally and post to SAP when connectivity returned, without losing data or stopping the line.

By the numbers

  • 4 weeks

    From brainstorming to working offline prototype

  • 0

    Data loss in queue-and-sync testing

  • 3 core capabilities

    Connectivity, transactions, and barcode scanning validated

Before

Unreliable connectivity, no offline path

  • Plant-floor workers could not process SAP transactions when the network connection dropped.
  • No validated architecture for offline queuing and automatic sync on reconnect.
  • No confirmed path from Android to the Windows 10 devices used across the plant floor.

After

Proven offline architecture, ready for rollout planning

  • A working Android app demonstrating Goods Receipt in both offline and online modes.
  • Queue-and-sync architecture validated: transactions post automatically when connectivity returns.
  • GS1 barcode scanning confirmed on Android, with a clear migration path to Windows 10 devices.

Why this matters

Prove it before you build it: a short, focused Design Brainstorm followed by four weeks of development gave a global food manufacturer the technical validation it needed before committing to a full plant-floor rollout.

The challenge

The company is the world's largest meat-snack manufacturer, running plants across multiple countries. On the plant floor, SAP connectivity was unreliable. When the network dropped, workers had no way to process Goods Issues, Goods Receipts, or Production Confirmations, and that meant either waiting for the connection to come back or finding manual workarounds that introduced errors.

The company wanted to know whether an offline-first mobile app on Android could handle those transactions reliably: queue them on the device when SAP was unreachable, then post automatically once connectivity returned. Before investing in a full rollout, it needed proof that the technical architecture worked.

What we did

Mindset ran a two-phase engagement. The first phase was one to two days of on-site Design Brainstorming, during which a senior UX architect and a UX architect worked with the plant team to understand exact workflows, prioritize transactions, and define what the proof of concept needed to demonstrate.

The second phase was a Sprint 0 to onboard the team, followed by roughly four weeks of development across two sprints. The team built a custom Hybrid Offline Goods Receipt application for Android, demonstrating three core capabilities the company had defined: clean transitions between offline and online modes with performance validated against the SAP Cloud Platform solution; the ability to queue transactions locally when the device lost connectivity and queue in the cloud platform when the connection to SAP ECC was severed, then post automatically once the connection was restored; and GS1 barcode scanning running on Android as the basis for a later migration to Windows 10 devices. Error handling in both offline and online modes was part of the build.

The outcomes

The engagement delivered a working proof of concept on Android, confirming connectivity between the mobile device and SAP Cloud Platform and demonstrating that the queue-and-sync architecture held up under the failure conditions the plant actually experienced.

The engagement was scoped as a proof of concept toward a broader plant-floor rollout covering additional transaction types and device types. The POC gave the company a tested technical foundation and a clear picture of what a production rollout would require before committing development resources to it.

If we built this today

Concept · not delivered scope

The plant floor keeps moving offline.

This is a forward-looking concept, not the scope we delivered on this engagement. It is the build we would reach for now, grounded in SAP that ships today.

When SAP connectivity dropped on the meat-snack plant floor, workers had no way to post a Goods Issue, so this case proved an offline-first app could queue movements locally and sync them once the network came back.

The data product

Cloud ERP Intelligence

Grounds the agent in real production and inventory semantics from across plants, so a reconnect reconciliation reads movements the same way every site does and the agent isn't guessing what a queued transaction meant. It's a curated app over governed S/4HANA data, not a raw export.

Intelligent Application on SAP Business Data Cloud

The Joule agent

Production Order Healer

Reads queued goods movements, open process orders, and on-hand stock the moment a device reconnects, then reconciles the offline-posted Goods Issues and Receipts against SAP and flags anything that won't clear so the line never silently loses a transaction. It proposes the posting and the fix for each exception, and a person approves.

SAP S/4HANA Inventory Management, SAP S/4HANA Production Planning, SAP Digital Manufacturing · PROPOSE · Unposted plant-floor transactions and reconciliation time after a connectivity drop

The Fiori app

Manage Stock / Post Goods Movement (Joule-embedded)

The standard S/4HANA goods-movement apps now carry Joule in the launchpad, so a floor lead can ask why a queued Goods Issue failed to post and get the open process order, batch, and storage-location context without leaving the screen. SAP Digital Manufacturing handles the AI-assisted shop-floor side.

Embedded in the Fiori launchpad.

We'd mine the real goods-movement and confirmation flow in SAP Signavio first, map the ECC-to-S/4HANA gap in SAP LeanIX, and lean on MIND accelerators to carry the offline queue-and-sync pattern from that old PoC into a modern build.

The Joule Agent Factory Process intelligence

What we built

  • Scope and priorities defined before development started

    Design Brainstorming session

    One to two days on-site with a senior UX architect and a UX architect to map plant-floor workflows, prioritize transactions, and define the exact scope for the proof of concept.

  • Working offline Goods Receipt on Android

    Hybrid Offline Goods Receipt application

    A custom Android app that handles Goods Receipt transactions in both online and offline modes, built from the brainstorming outputs over four weeks across two sprints.

  • No data loss, no manual workarounds when connectivity dropped

    Queue-and-sync architecture

    Transactions queued on the device when SAP connectivity was lost, queued on the SAP Cloud Platform when ECC was unreachable, and posted automatically once the connection returned.

  • Validated on Android as the path to broader device support

    GS1 barcode scanning

    Barcode scanning on Android as the basis for migration to Windows 10 devices in a later rollout phase.

  • Both failure paths covered and tested

    Error handling (online and offline modes)

    Explicit error handling for both the device-to-cloud and cloud-to-ECC failure paths, so plant staff knew exactly what happened when a transaction could not be processed.