Prototyping a Kanban Plugin for Existing ERP Systems

Kanban is often introduced through cards, columns and work-in-progress limits. In an enterprise, the harder problem is joining that visual flow to the orders, materials, machines and people recorded in the enterprise resource planning system. The board becomes useful when it reflects operational reality while leaving the ERP as the authoritative source for commercial and production data.

A plugin offers a focused way to achieve this connection. Rather than replacing a costly ERP, it can translate selected ERP objects into Kanban cards, track policy-compliant movement and return useful events. This preserves existing investments, shortens the route to a pilot and gives operational teams a practical way to test digital visual planning before wider rollout.

Prototyping a Kanban plugin for existing enterprise resource planning systems therefore demands equal attention to workflow design, data quality and technical integration. The strongest prototype is not a polished board disconnected from daily work. It is a small, measurable slice of the value stream that reveals where information flows, where decisions stall and which integration boundaries deserve further investment.

Why integration matters more than the board

Research published by the Chalmers Electronic Lean Research Team, Celean, gives useful context for this kind of development. The Project Visit site documents work on digital visual planning, Kanban, visual project management, enterprise systems and lean processes, including collaborations with organisations such as Volvo. It points to a practical principle: digital tools should make work more visible without creating a parallel administrative system.

ERP estates are rarely tidy. Production orders may reference purchase requisitions, planned maintenance routines, quality inspections and supplier schedules through different identifiers. Operational teams then reconcile several screens before they can decide which job can start. A plugin can present these relationships through a shared card model, but only if the underlying mappings preserve traceability back to the ERP.

That distinction shapes the prototype’s purpose. A visually attractive board adds little value if users must check the ERP to determine what each card means. The useful test is whether a supervisor can identify a blocked item, its owner, its age and its effect on delivery without leaving the visual workflow. The ERP remains the system of record, while the plugin becomes the interface for managing flow.

Designing around an actual value stream

Good prototyping begins with a narrow flow containing visible delays. A production cell in an automotive supplier, a maintenance crew servicing an asset or a team handling inbound quality inspections may offer suitable candidates. The selected flow needs identifiable start and finish points, recognisable card types and enough recurring work to compare performance before and after introduction.

A credible first release might read production orders from a sandbox ERP environment and create cards only for work meeting agreed criteria. Pull signals, replenishment alerts and ageing thresholds can operate as demonstrations without changing the ERP. Once the team confirms that the workflow matches reality, a small number of controlled write-backs can be introduced, such as recording a card’s completion or requesting material replenishment.

The interface should support both observation and action. Users can filter by supplier, product family, priority or exception state, then open an ERP record for detail. Barcode, QR-code or RFID input can advance a card where scanning is already part of local practice, while drag-and-drop can support supervised keyboard workflows. A card should always show the source record and the timestamp of its latest ERP update.

Mapping ERP records to visual work

Data modelling determines whether the board can remain dependable as the organisation changes. Each card needs a stable internal identifier linked to one or more ERP objects, rather than relying on descriptions that users can rename or overwrite. Card types should distinguish customer orders, internal transfers, maintenance, quality work and supplier replenishment, with configurable policies governing which fields appear and which actions are permitted.

State changes require careful treatment. Moving a card from “ready” to “in progress” may represent a local authorisation, while completion might need to update the ERP and wait for confirmation. Every transition can carry a source, timestamp and user identity. Conflicts, such as a card completed after its order was cancelled, should remain visible as exceptions instead of being silently resolved in the plugin.

The board itself should expose lean policy rather than reproduce every database field. Swimlanes can represent work cells or stages, while work-in-progress limits, ageing colours, due dates and blocked-time indicators make exceptions visible at a glance. Supervisors need filters for exceptions, overdue work and cards awaiting external information. Standard views should remain simple enough for daily use, with detailed diagnostics reserved for process owners investigating data or integration problems.

Meeting enterprise technical constraints

An enterprise plugin must fit the organisation’s security and governance framework without becoming a hidden route into production systems. Role-based permissions should control which cards users can see and which ERP actions they can trigger. Configuration changes, manual overrides and write-backs should be auditable, while sensitive commercial data should remain within approved ERP roles. Where personal information appears, retention and masking should follow the organisation’s existing policies.

Integration should begin with stable interfaces rather than direct database changes. Supported APIs, webhooks and enterprise integration platforms can exchange orders, confirmations and status events, with retries and monitoring handling temporary failures. A read-only prototype creates a safe learning environment, while later write-backs require idempotency so repeated requests cannot create duplicate movements. Offline capability may be necessary on remote or low-connectivity sites, but local actions need clear synchronisation rules to prevent two teams from advancing the same card inconsistently.

The same principle appears in RECAP’s work on live shopping recognition, where software identifies product logos in changing video and turns uncertain visual input into structured information. A Kanban scanner faces a comparable problem: a damaged label, obscured card or changed layout can produce uncertain results. Confidence thresholds, manual confirmation and clear audit records are more trustworthy than forcing every image into a supposedly perfect classification.

Testing assumptions in Australian operations

Australian validation should not be borrowed wholesale from another manufacturing culture. Melbourne’s automotive, engineering and food-production clusters, together with Sydney’s logistics and construction networks, often combine high-volume operations with make-to-order work. A card may represent a customer order, maintenance task, quality hold or supplier replenishment, so the prototype needs configurable card types rather than one universal workflow.

Geography creates different usage conditions in Brisbane and Perth. Mining, utilities and major infrastructure projects may combine urban planning teams with remote sites, fly-in fly-out crews and intermittent connectivity. A Kanban view must remain readable when a transaction reaches the board hours after the ERP event, and teams working across Perth and eastern states need ageing rules that account for time-zone differences. For importers, customs clearance milestones and broker updates can form a separate external queue that should link to, rather than block, internal production work.

The local software market also shapes procurement and integration choices. Australian enterprises commonly operate SAP, Oracle, Microsoft Dynamics or Infor systems, with implementation teams balancing cloud licences, local support and existing internal capability. Australian shop-floor customs generally reward direct communication and visible exceptions, so training can focus on daily problem-solving rather than detailed software administration. Where certified agreements affect work allocation, consultation with the relevant workforce representatives should accompany pilot design.

Measuring outcomes rather than activity

A baseline is needed before the plugin changes the workflow. Measures such as flow time, throughput, blocked duration, schedule adherence, inventory movement and late-order frequency can reveal whether visual planning improves delivery. The number of cards created or active users may help explain adoption, yet these activity figures cannot demonstrate operational benefit on their own. Baseline periods should also capture the variations caused by demand, staffing and production interruptions.

Balanced measures make the evaluation credible. Operational outcomes can be paired with data-quality indicators, such as missing ERP links or duplicate card creation, and with user measures such as time spent resolving exceptions. Interviews with planners, supervisors and shop-floor staff can explain why a metric changed. A shorter queue that merely transfers waiting to an untracked spreadsheet, for example, should not be treated as an improvement.

A controlled pilot provides stronger evidence than a general launch. One cell, product family or maintenance team can use the plugin while a comparable group retains the existing process. Teams should agree in advance which changes constitute success, how long the comparison will run and who can stop an unsafe or unproductive pilot. This makes it possible to refine card policies, ERP mappings and training while the scope remains manageable.

Moving from prototype to adoption

A staged rollout keeps technical learning connected to operational learning. Discovery establishes the value stream, current-state measures and responsible owners. A sandbox prototype then tests information structures and user interactions with representative records. A limited live pilot introduces reliable ERP connections and controlled write-backs, while the final evaluation decides whether to extend the plugin, revise it or stop the work. Each stage needs an explicit evidence threshold rather than a predetermined commitment to scale.

Governance should remain lightweight but visible. A small cross-functional group can review card policies, access rights, exceptions and metric trends, while ERP administrators retain authority over interfaces and master data. Scaling introduces reusable templates for additional value streams, standardised event mappings and onboarding material for new teams. It also increases the importance of version control, since a policy change applied in one plant should not produce inconsistent behaviour elsewhere.

The practical takeaway is to treat the plugin as a bounded organisational learning system: connect one consequential flow, expose its real delays, and expand only where the evidence shows that visual planning improves delivery rather than merely adding another screen.