In this blog, we’ll explore what happens when you try to relocate a process before anyone has actually written it down, why “we know they’re working, we just don’t know at what” is a genuine sentence a head of procurement once said to me, and how nearshore process documentation turned two brand-new sites into a control tower instead of a black box.
A European IT services and telecommunications group asked PDCA Consulting in to help move part of their procurement operation out to new sites in Hungary and Slovakia. Straightforward enough, on paper: hire people locally, hand them the existing process, let them get on with it. Except there wasn’t an existing process. There was an existing set of habits, distributed across several buildings in Darmstadt and beyond, and nobody had ever written any of it down.
Call it what the contract called it if you like. The honest description is nearshore process documentation, not nearshoring, because the process had to exist on paper before it could exist in Hungary and Slovakia.
A company built on its own history
The client had been through more than one rebrand over the years, and some of the paperwork still in active use hadn’t caught up. Procurement staff were working from forms that still carried an earlier corporate identity’s logo at the top. Nobody had reordered the stock in years. Nobody had thought to. It was a small, slightly absurd detail, and it told the whole story of the process underneath it: inherited, patched, never properly rebuilt.
The work itself was serious. Every new supplier had to clear a set of checks against the client’s requirements: declarations that they didn’t use forced labour, evidence of sustainable sourcing, sight of their incorporation documents, and a fair amount besides. Necessary checks, all of them, and the requirements varied by category, so mobile phones went through one set of hoops, office furniture through another, paper stock through a third.
The trouble was where the checking happened. One authorisation would clear a stage in a Darmstadt building, travel to Munich for the next stage, then back to a different desk in Darmstadt for the stage after that. The head of procurement, nominally responsible for the whole operation, told me plainly that he had people working for him and no real idea what half of them did day to day. Not because they weren’t working. Because there was no way to see the work.
Getting Darmstadt to admit what it actually did
The interviews were the hard part, and not for the reason people expect. Staff weren’t hiding anything. Most of them genuinely believed they already had a process, their process, the one they’d been doing for years, and struggled to see why anyone needed it written down.
Ask someone to describe a routine they’ve performed from memory for a decade and you get a confident, fluent answer that skips half the actual steps, because the missing half is so automatic it doesn’t register as a step at all. Getting the real sequence out of one person meant asking the same question three different ways, then comparing notes with the person one desk over doing the “same” job slightly differently.
Nearshore process documentation comes first, or not at all
That’s the line I kept coming back to, because it’s the entire point of this story. Everyone had assumed the plan was: move the work to Hungary and Slovakia, then work out the control afterwards. I flipped it. You cannot control a nearshore team on a process that only exists as tribal memory scattered across three cities. Skip the documentation and you have simply exported the confusion somewhere cheaper, which is not the same thing as fixing it.
So the first job was archaeology, not automation. Going through what actually happened, step by step, building by building, person by person, made the invisible process visible on paper for the first time. Only once that existed did it make sense to put it into a service desk tool the new Hungarian and Slovakian teams could actually run against, with a combined dashboard so the head of procurement could, for the first time, look at one screen and see how many authorisations were moving, how fast, and where they were stuck.
What fifty new employees actually got handed
By the end, around fifty people across the two nearshore sites, roughly twenty-five per site, were trained on what proper service management meant for this operation, working from a documented, tool-supported process rather than institutional memory. The transfer from Germany was complete. The head of procurement finally had statistics instead of guesswork: turnaround time by process type, volume by month, a genuine basis for continual improvement instead of a shrug.
None of this required new technology. The service desk tool itself was nothing exotic. What changed the outcome was the order of operations: document first, tool second, offshore third. Reverse that order, as plenty of nearshoring programmes do under pressure to show progress fast, and you get a shiny dashboard reporting on a process nobody can actually vouch for, which is arguably worse than no dashboard at all, because it looks like control without being control.
It’s worth being honest about the sequence, because it’s the transferable lesson here, not the specific procurement detail. Every nearshoring or offshoring project that has gone wrong in front of me has made the same mistake: assuming the receiving team can absorb a process the sending team never actually documented in the first place. If your own head office can’t tell you what your process is, sending it three hundred miles away doesn’t create clarity. It just moves the confusion somewhere with a different postcode, with a language and time-zone gap added on top for good measure.
None of this is unique to procurement. ITIL 5 gives this discipline a name: the Continual Improvement Model, the formal loop of measuring, learning, and adjusting that turns a one-off fix into a repeatable capability, and PDCA Consulting’s ITIL coaching and consulting work exists precisely because most organisations discover the gap the way this client did, under pressure, mid-project, with a nearshore site already waiting for instructions. Anyone wanting the formal grounding behind what got built here can find it through the current ITIL certifications pathway.
The old-branded forms are long gone now, I’d imagine. That detail has stuck with me longer than most of the technical work, because it’s such a precise little symbol of what undocumented process actually looks like from the inside. Not chaos, exactly. Just habit stacked on habit, inherited from an earlier version of the same organisation that nobody had quite finished saying goodbye to.
To find out more about PDCA Consulting’s expert consulting services either:
- Book 30-minute conversation directly: here
- Get in touch via the contact form here
- Connect with me on LinkedIn
