Digitalization of waste collection: a theoretical study of feral systems

A study of how a large industrial manufacturer can digitalise its waste-collection processes without paving over the workarounds its own people have already built. The argument is that the messy spreadsheets and shadow tools that grow up around enterprise platforms (Feral Information Systems, in the literature) are not a discipline problem to be stamped out, but a free first prototype of the real product.

Context

The article was written as the EU was tightening waste-collection and reporting obligations for industrial sites, and as Industry 4.0 / 5.0 rhetoric pushed every manufacturer to "go digital" without a clear sense of what that meant on the shop floor. The study draws on observations at an unnamed industrial manufacturer (referred to as the study case company, or SCC), where the facility-management department was tracking waste in an Excel dashboard with no integration to SAP, no compliance layer, and no analytics. The literature it draws on (Vogelsang on Industry 4.0 barriers, Mahmood on requirements engineering, Lammers on feral systems) converges on the same finding: the obstacle to digitalisation is rarely the technology.

What the paper argues

Successful digitalisation of an operational process like waste collection rests on three disciplines working together: requirements engineering, compliance management, and the deliberate use of feral systems as prototypes. Most large organisations get the technology choice roughly right and then fail on the human side: missing skills, fixed mindsets, weak strategy from upper management. The article reframes the existing spreadsheet, the thing IT departments usually try to suppress, as the cheapest, fastest iteration of the future module. The path forward is to capture proper requirements as user stories, harden the prototype against recognised standards (UML for design, SOLID for code, IEEE-830 for requirements specs, IEEE-829 for testing), and only then promote it into the SAP-connected operational backbone. The conclusion is that punishing feral systems destroys evidence of real user needs and pushes the same workarounds further underground; channelling them is faster, cheaper, and produces a better ERP integration at the end.

Key takeaways

• Treat feral systems as prototypes, not violations: the spreadsheet someone built last Tuesday is a free first iteration of the product you're about to scope.
• Lead with requirements engineering. User stories and early stakeholder mapping prevent the agility gap that produces shadow tools in the first place.
• Recognise that the dominant barriers to digitalisation are human (skills, mindset, strategy), not technical.
• Use standards as the bridge from prototype to platform. UML, SOLID, IEEE-829 and IEEE-830 are how a hidden Excel sheet earns the right to talk to SAP.
• Build continuous re-evaluation into the operating model: anything shipped today becomes legacy faster than the planning cycle assumes.

My contribution

This was a Group 22 deliverable on the Management of Technology course; the article was authored jointly with Andreas Monrad Pedersen, Daniel Alexander Robert Silsbee, Jacob Hansen Rubæk, and Frederik Freltoft Thoudal.

Reading the full version

This is a co-authored study (Group 22). The full text is available on request: contact me.