22 Processes and No Shared Way of Working
The organisation is a collaborative R&D initiative bringing together government, industry, and research institutions to advance mining innovation in South Africa. Its administrative function supports multiple programmes, each with its own governance, reporting, and compliance requirements.
Over time, the way work got done had drifted. Files lived in inboxes, personal drives, and shared folders with no agreed logic. Ownership of key processes was unclear, which meant approvals stalled and decisions waited while people worked out who was responsible. The same KPI names appeared across programmes, but the definitions behind them varied. Reports were assembled manually from summary spreadsheets, introducing errors and version conflicts with every cycle.
The people were skilled and committed. But the administrative infrastructure they were working within had never been designed for the complexity the organisation had become. They were compensating for a system that did not exist.
Process Maps Were Not Going to Fix This
Process mapping is a natural starting point for this kind of challenge, and it is valuable: it makes the invisible visible. But we have seen in organisation after organisation that process maps alone do not create change. They create clarity. Clarity is necessary, but it is not sufficient.
The gap here was not understanding. It was infrastructure. There was nothing connecting process intent to daily execution: no shared digital environment, no standard routines, no data model linking what people did each day to what the organisation needed to measure and report. The real work was not mapping the processes. It was closing the loop between the map and the reality.
From Mapping to Structures to Routines to Data
We catalogued 22 core admin processes and prioritised them by impact, complexity, and frequency. For the highest-priority workflows, we mapped inputs, outputs, handovers, and responsibilities, surfacing duplication and bottlenecks that had been invisible because nobody had laid out the full picture in one place.
Then we went beyond the map. We built a standardized and agreed
SharePoint architecture within the existing Microsoft 365 environment, giving every document a clear home with consistent naming and role-based access. We embedded standard work procedures for reporting and governance, formalised an annual reporting calendar, and established coordination routines between programme managers. Training was practical and hands-on, backed by weekly updates and one-on-one conversations to support people through the transition.
The final layer was a data model aligned to processes and reporting requirements, capturing transactional-level data: programme objectives, project milestones, budget allocations, and actual expenditure. This replaced the summary spreadsheets entirely and made automated, auditable reporting possible for the first time.
A Team That Works with the System, Not Around It
The shift was visible before the engagement formally closed. Teams moved from personal storage to shared spaces. Decision-making shifted to a consensus-based model that improved accountability and mutual respect. Staff who had been uncertain about the new structures began actively maintaining them without prompting.
Most importantly, the organisation built a shared language for metrics. KPI definitions were aligned across programmes, which meant that when people sat in a reporting meeting, they were finally talking about the same things.
The Map Is Not the Territory. The System Is.
If the structures, routines, and data systems that surround a process do not support it, the map becomes decoration. People will find their own way of getting things done, and those workarounds will quietly become the real process: undocumented, inconsistent, and invisible to anyone trying to improve things.
Closing the loop means going beyond the map. It means building the environment where information lives, the routines that turn process steps into daily habits, and the data architecture that connects what people do to what the organisation needs to know. That is the difference between an organisation that has documented its processes and one that actually runs on them.
