ERP Business Analyst in Germany

Why German requirements belong on paper before the tender

In many owner-led German manufacturers the most important process knowledge sits with a handful of long-serving employees. The production planner knows which machine can run which variant, the head of purchasing knows which supplier needs a call rather than an order, and the bookkeeper knows exactly which postings the Steuerberater will query. When an ERP project begins, implementers ask for this knowledge in their own vocabulary and often receive incomplete answers.

My role is to collect it first, on your side. I run remote process mapping sessions by department, follow real orders through the business and record the exceptions: rush jobs, partial deliveries, customer-supplied material, credit notes after a complaint. Then I turn the maps into a numbered requirements list, similar in purpose to the Lastenheft many German buyers already know, with a priority and an acceptance criterion on every line.

For German subsidiaries of foreign groups the problem looks different. The parent often sends a global template, and the local team has to show where German practice needs something extra. I separate group mandates from local needs so both sides can see which gaps are real. The method behind this work is described on my requirements gathering page.

Expressing GoBD and DATEV expectations as requirements

Bookkeeping principles in Germany, usually referred to as GoBD, are often treated as something the vendor will take care of. In practice they need to appear in the specification as concrete statements, otherwise nobody tests them. I write lines such as: posted documents cannot be changed without a reversal; every change to master data is logged with user and time; each incoming receipt is stored with its booking; and data can be made available for an audit in a usable form. Your tax advisor reviews these lines, because interpreting the rules is their job, not mine.

The handoff to a DATEV-based advisor deserves its own short chapter. I ask the advisor what they want to receive, whether that is periodic posting batches, receipt images or only balances, and which standard chart of accounts the company follows, for example SKR03 or SKR04. That becomes a requirement every platform must meet natively, through an add-on or through an interface.

Incoming structured e-invoices are captured the same way. I note which formats your suppliers already send, how invoices should reach approval and how the original file is kept. Which obligations apply when is confirmed by your advisor. The comparison of how each platform answers these lines continues on the Odoo in Germany and Dynamics 365 in Germany pages.

Mapping variant production, EU trade and service processes

The processes I map most carefully in German projects are the ones that generate cost and margin. For manufacturers that usually means variant products: how a customer specification becomes a bill of materials, how routings change with options, how capacity is checked before a delivery date is promised and how actual hours and scrap flow back into costing. A requirement such as "configure variants" says nothing useful; a requirement that lists the option rules, the pricing logic and the costing method gives an implementer something to answer.

Trade within the EU adds data requirements that are easy to forget during demos. I list the fields needed on customer, supplier and article records for EU sales reporting and trade statistics, such as VAT identification numbers, commodity codes and country of origin, and I note which reports your advisor currently prepares from them. Where you also sell service contracts or spare parts, I map those flows separately, because their billing logic rarely matches production orders.

Each map ends with a list of problems and the requirement lines that address them. The result feeds straight into a fit-gap analysis, and it helps management decide which processes to standardize before the new system arrives rather than after.

Works council and stakeholder consultation in the specification

In companies with a works council, the question of what an ERP records about employees often comes up late and delays the rollout. Time recording on production orders, user activity logs, approval histories and performance reports can all be relevant. I do not advise on co-determination; that belongs to your HR lead and legal counsel. What I can do is make the facts available early.

During analysis I build a role and data catalog: each user role, the screens and reports it uses, the personal data it can see, what the system logs automatically and the business reason for each log. I also note where the shortlisted platforms allow logging or reporting to be restricted. HR and management can use this material to prepare their own consultation, and any agreements that result go back into the specification as requirements the implementer has to respect.

Other stakeholders need the same attention. Group IT may set rules for identity, hosting and integration; the data protection officer will want to know which personal data enters the ERP and CRM; the payroll provider needs a clear boundary. I record each of these voices in the document so the final scope reflects all of them. The broader setting for German projects is on my ERP consultant in Germany page.

English documents, German terminology and sign-off

The engagement runs in English, and the specification, process maps, fit-gap matrix and test scenarios are written in English. For many German subsidiaries and export-led firms that suits the audience, since management already reports to owners or a parent abroad in English. It does leave one task that has to sit with your team: German terms.

I keep a glossary inside the document that pairs each English term with the German expression your staff actually use, such as the names of document types, account groups or production statuses. A bilingual key user reviews that glossary and any German-language artifact, such as print layouts or field labels, before they reach the implementer. If the implementer needs the specification in German for their own team, translation is arranged by you or by them, and the English version stays the reference for scoring.

Sign-off happens in writing. Each department head confirms their chapter, management confirms the priorities and your advisor confirms the finance lines. After that, changes go through a short request log so the scope stays visible. Remote sessions run in the Central European morning, which falls inside my working day in India. To see how this connects with platform choice, read the BRD consulting page or visit the Germany hub.