Digitalisation projects in the Mittelstand rarely fail because of the technology. They fail because of four disciplines that nobody wants to see lumped together: technical documentation, knowledge management, translation, and content engineering. Cut one of them, and you have damaged the other three with it.
Over the past years I have seen many digitalisation projects that were brilliant in the slide-deck phase and quietly fizzled out after 18 months in reality. Management had a new ERP, a new CRM, and a new PIM. The staff had 240 PDF manuals, a knowledge base without a search function, and a translation department that did not know which term stood for what in which system.
The cause rarely lies in the tool. It lies in the structure — more precisely, in the separation of the four disciplines that need one another. Four fields that, in most organisations, sit in four different departments, are assigned to four different budget lines, and have four different executives responsible for them. As long as this separation persists, every digitalisation effort runs in circles.
The four disciplines without which digitalisation does not scale
Technical documentation is more than an appendage to product development. It is the interface at which design, manufacturing, sales, and service become legible. With the Machinery Regulation 2023/1230, binding from 14 January 2027, it additionally becomes a mandatory regulatory deliverable with conformity relevance. Anyone who digitalises here without thinking through the output for market surveillance and the liability case builds in a legal risk that appears in no ERP requirements specification.
Knowledge management is the answer to a question that has been raised in staffing meetings for years: what happens to the knowledge in the head of the colleague who retires next year? A SharePoint site with 4,000 unmaintained files does not meet the definition of knowledge management. It is a graveyard in which answers lie to questions nobody asks any more. Real knowledge management structures knowledge, assigns it to a source, lets it expire in a controlled way, and makes it findable. Without these four functions, every „knowledge hub“ is unusable after 18 months.
Translation management in the Mittelstand rarely means just „get it translated into English and French“. It means: keeping terms consistent across product lines, languages, and markets. Inconsistent terminology adds 20 to 35 % effort to every localisation and produces complaints that nobody traces back to mistranslated maintenance instructions. A maintained translation memory and a central terminology database are regarded in many organisations as a luxury. In truth, they are the foundation on which AI-supported translation can work at all.
Content engineering is the discipline that has the other three’s backs. It ensures that content is modular, tagged with metadata, managed in a CCMS, and deliverable independently of the channel. Without content engineering, each of the other three disciplines remains an island of data. With content engineering, they become a system that can be maintained, searched, and analysed.
Why the separation of the four disciplines is so expensive
In my practice I see four typical symptoms that reveal the disciplines are working uncoupled:
- Three spellings for the same component: in design „maintenance flap“, in the documentation „service flap“, in the spare-parts catalogue „inspection cover“. Service staff search and find nothing, the customer calls, costs arise.
- The translation budget rises 15 to 25 % each year without more content being produced. Cause: the translation memory cannot capture reuse because the source texts vary slightly all the time.
- The knowledge base is „tidied up“ each quarter: nobody maintains it in a structured way, once a year an intern is put on it, and after three months it is back to the same state.
- Onboarding new staff takes 9 to 14 months. Not because the tasks are so complex, but because the knowledge about systems, processes, and exceptions is passed on verbally.
Each of these symptoms can be treated in isolation. But the treatment does not take hold as long as the other three disciplines remain in their own silo.
What holistic digitalisation means in concrete terms
„Holistic“ is a word that appears on every consulting slide and usually means nothing. In concrete terms it means:
One terminology source for all four disciplines. Design, documentation, translation, and service use the same set of terms. Maintained by a terminology owner, not by users. Tools: a termbase such as crossTerm, MultiTerm, or a modern TBX-capable solution. Without this foundation, every further step is burning money.
Modular content as standard. Each piece of information exists exactly once and is pulled by reuse into all outputs: manual, training, help centre, service portal. Tools: a CCMS such as SCHEMA ST4, Acolada cosima, or other COTI/iiRDS-capable systems. Effort to introduce in the Mittelstand: 9 to 18 months, six-figure investment range, payback 2 to 3 years if the foundation is laid cleanly.
A knowledge architecture with clear responsibilities. Every knowledge area has a named owner. Content has an expiry date. Search works on structured metadata, not on full-text gambling. Tool: not necessarily a new tool — often a consistent use of the existing Confluence or SharePoint with a strict governance model is enough.
A translation workflow directly at the CCMS. Translation is not thought of as a downstream provider order but as a module workflow within the same system. Translation-memory connection via XLIFF and iiRDS. With a clean data basis, the effort per language drops by 25 to 40 %.
Order is everything
Anyone who tackles all four disciplines at once fails under complexity. Anyone who tackles them one after another needs years. The order that has held in my projects:
- Inventory of content and terms (4 to 8 weeks). Which content exists, in which systems, with what maintenance, with which set of terms?
- Terminology first (3 to 6 months). The set of terms comes before any tool. Without terminology, tool selection is gambling.
- Modularisation of content (in parallel from month 2). Pilot with one document type and one product line. Start small, scale the findings.
- Tool selection on the basis of the first three steps. CCMS, TMS, and knowledge base are chosen according to the concrete requirements, not according to the vendor demo.
- Introduction in a pilot area, then scaled. Three-month pilot with documented metrics (creation time, review effort, complaint rate).
- Training and governance. Without maintenance owners and clear processes, the best system is a data graveyard after 18 months.
What this means for the budget
Mittelstand companies that walk this order cleanly typically invest in the high six figures over 24 to 36 months. That sounds like a lot until you know the comparison figures: translation costs alone come to 200,000 to 500,000 euros per year in production-heavy organisations. A 25 % reduction refinances the CCMS within the first two years. Plus the complaint and liability costs that do not arise, plus the onboarding times that halve, plus the compliance value for the Machinery Regulation 2027.
Anyone who instead keeps doing „introduce tools, then we’ll see“ pays extra every year and ends up with the same inconsistency — just in a more expensive software stack.
What to consider before you start a project
From recent consulting engagements, three points I bring into every initial consultation:
Who is the one person responsible for content? Not the head of marketing, not IT, not design. One person with a mandate over all four disciplines. Without this responsibility, the project drifts between the silos.
Which data may go into which cloud? Engineering drawings, service data, customer master data: each of these categories has different legal requirements. Before any tool, it has to be clear where this data lands and who has access.
How do you measure success? „More efficiency“ is not a metric. Creation time per document, complaint rate, translation effort per language, onboarding duration: those are the figures that show whether the project holds. Without them, after two years management has nothing in hand but a software invoice.
An inventory as a starting point
Before any CCMS, TMS, or knowledge-management project, a systematic inventory pays off: which content, which set of terms, which owners, which obligations. Schübeler Consulting carries out this inventory with you and delivers a prioritised roadmap for the next 12 to 24 months, tailored to your industry and the regulatory requirements.
Initial consultation: info@schuebeler-consulting.de or via the website.
Johann Jörgen Schübeler, Schübeler Consulting