The mandate is clear: "We need a new ERP system." Perhaps support for your current system is ending. Perhaps your processes have become so convoluted that nobody can make sense of them anymore. Or you're a growing company starting with a proper ERP for the first time. The goal is clear—but how do you get from a blank page to a tender that actually delivers what you need?

Over recent years, I've guided various mid-market companies through agile procurement processes—not specifically for ERP systems, but the principles are transferable. A recurring pattern emerged: the classic approach—months of requirements specification, then tender, then hope—only works marginally for complex IT projects. The world has moved on, but many procurement processes haven't.

Of course, a company with 150 employees doesn't need Agile Release Trains or PI Planning events with 100 participants. But the thinking models and methods that SAFe describes in Lean Portfolio Management are surprisingly useful even for smaller organisations—particularly when it comes to structuring a major initiative like an ERP tender in a way that enables an agile contract.

📌 The Dilemma: Knowing Enough to Tender—Without Knowing Everything

Here lies the fundamental problem you face as an IT leader: for a serious tender, you need enough substance for vendors to provide costings. At the same time, you don't yet know what your processes should look like in two years—and frankly, your business units don't know either. The classic 200-page requirements specification suggests a precision that doesn't exist in reality.

The good news: there's a middle way. One that gives you enough structure for a solid tender whilst maintaining the flexibility you'll need during implementation. This path leads through what the Scaled Agile Framework calls Lean Portfolio Management—adapted to the realities of an ERP project.

🎯 Phase 1: Strategic Anchoring

Before you write down a single requirement, you need to understand why your company needs a new ERP in the first place. This sounds obvious but is surprisingly often skipped. The consequence: requirement lists that collect technical wishes but lack a common thread.

Begin with what SAFe calls Strategic Themes—the three to five overarching objectives driving your ERP investment. SAFe recommends formulating these themes in OKR format (Objectives and Key Results). This has a practical reason: OKRs force you not only to name the goal but also to define measurable results by which you can recognise progress.

In practice, such Strategic Themes look like this: the Objective "Faster order processing" becomes concrete through Key Results like "Reduce cycle time from order receipt to delivery by 30%" or "Reduce manual data entry by 50%". This structure helps you enormously later—both for prioritising requirements and for measuring success after go-live.

Alternatively—or complementarily—you can work with Capabilities at this level. Capabilities describe what abilities the company must develop to achieve its strategic goals. For an ERP project, this might mean: "Capability for real-time transparency across all inventory" or "Capability for automated compliance documentation". The advantage: Capabilities are formulated solution-neutral and leave vendors room for how they implement this capability technically. In practice, I often find a combination of both approaches works best—OKRs for measurable goals, Capabilities for necessary abilities.

For documenting and ongoing tracking of your Strategic Themes, we've developed a free OKR tool specifically tailored to the needs of mid-market project teams. It doesn't replace comprehensive strategy software, but for ERP requirements gathering purposes it's perfectly adequate.

Why is this important? Because later, when a vendor explains why Feature X is absolutely essential, you can check: does this contribute to our Strategic Themes? If not, it's nice-to-have, not must-have.

For this phase, you need two to three workshops with executive management and department heads. No more. The temptation is great to dive into details already—resist it.

🛠️ Phase 2: Process Landscape and/or Value Streams

Now it gets more concrete, but not too concrete yet. In this phase, you create an overview of your core processes—not as detailed flow diagrams, but as end-to-end processes at a high altitude. Here, two worlds collide that you should know about.

The traditional process landscape is an established method in business process management and a fixed component of the ISO 9001 standard. It structures the organisation into management, core, and support processes and shows their interactions. Many mid-market companies in the DACH region already have such a process landscape—often from ISO certification or earlier quality management projects. It's documentation-oriented and rather static.

SAFe thinks differently: there, you work with Value Streams—the flow of value from trigger to delivery to the customer. SAFe distinguishes between Operational Value Streams (how you create value for customers) and Development Value Streams (how you develop software/solutions). The focus is on flow, on the continuous flow of value, not on static process boxes.

The pragmatic bridge: in reality, you can use both. If your company already has a process landscape, that's a good starting point. Use it to identify the relevant end-to-end Value Streams. Typically, four to six of these value streams crystallise: Order-to-Cash (from customer order to payment receipt), Procure-to-Pay (from need to supplier invoice), Record-to-Report (from posting to annual accounts), and depending on industry, Hire-to-Retire, Plan-to-Produce, or similar.

Let's be honest: your goal isn't to implement SAFe. Your goal is a good tender. For that, you use proven methods from the framework—but you don't force yourself into a complete transformation.

🔧 The Concrete Approach When Working with a Process Landscape

If your company already has a process landscape from ISO certification or earlier quality management projects, that's your best starting point. You don't need to reinvent the wheel.

Step 1: Identify in your existing process landscape the four to six core processes that your ERP system must support. Focus on the processes actually affected by the new ERP—not all processes from your landscape are relevant.

Step 2: Document for each of these core processes on maximum one page:

• 🔹 The current state (roughly sketched, no details)
• 🔹 The main pain points (concretely named)
• 🔹 Where media breaks occur
• 🔹 Where information or material waits unnecessarily long
• 🔹 Which manual interventions should be avoided

Step 3: Appoint a Process Owner from the business unit for each core process. This person should:

• 🔹 Understand the process end-to-end
• 🔹 Have decision-making authority across multiple departments
• 🔹 Be willing to invest time regularly for the project

The Process Owner is later your contact person for all questions about this process—both during requirements gathering and in implementation. This isn't the person who knows the process in most detail (that's often a clerk), but the person who can make decisions.

🔧 The Concrete Approach for Value Streams

If you opt for the Value Stream approach (or if your company doesn't have an existing process landscape), the approach is similarly structured but with a different focus:

Step 1: Identify the three to five most important Operational Value Streams in your company. These are the end-to-end value streams relevant to your customers. For a manufacturing company, this might be: "From customer enquiry to delivered product", "From material requirement to availability", "From idea to product portfolio".

Step 2: Document for each Value Stream on maximum one page:

• 🔹 Trigger: What starts the Value Stream?
• 🔹 Value: What is the expected outcome for the customer?
• 🔹 Delays: Where do material, information, or work wait unnecessarily long?
• 🔹 Bottlenecks: Where is flow constrained?
• 🔹 Waste: Which activities create no value?

SAFe offers Value Stream Mapping for this analysis—a method to visualise the current state and identify optimisation potential. You don't need to do this in full depth, but thinking in delays and bottlenecks helps you enormously to formulate the right requirements.

Step 3: Appoint a Value Stream Owner—the person responsible for the end-to-end performance of this value stream. This is often harder than it sounds because Value Streams typically cross multiple departments. But that's exactly why the role is so important: it forces you to think beyond silo boundaries.

In practice, it often comes down to the same people—your department heads will be both Process Owners and Value Stream Owners. The difference lies in the thinking pattern: with processes, you think in activities and responsibilities. With Value Streams, you think in flow and value creation.

🔄 Phase 3: From Processes to Epics

Now it gets concrete—but differently than you might be used to. In this phase, you condense your process or Value Stream analysis into so-called Epics. An Epic in the SAFe context is a larger initiative that delivers significant value and typically spans multiple sprints.

For an ERP project, an Epic might be: "Automated order processing without manual data entry" or "Real-time transparency across all inventory with automatic reorder proposals". Not too small (that would be a User Story), not too large (that would be an entire programme).

SAFe suggests creating a Lean Business Case for each Epic—a compact description (two to three pages) that answers the following questions:

• 🔹 Problem: What concrete problem does this Epic solve?
• 🔹 Solution Hypothesis: What solution do we propose?
• 🔹 Benefits: What measurable benefit do we expect?
• 🔹 Cost of Delay: What does it cost us if we don't implement this?
• 🔹 Success Criteria: How do we recognise that it works?

Sounds elaborate? It isn't. For most Epics, half a page suffices. The crucial thing is: you force yourself to think in business value, not technical features. "We need an interface to SAP" is not an Epic. "Automatic synchronisation of customer master data between CRM and ERP to avoid duplicates" is an Epic.

Typically, ten to twenty such Epics crystallise for a mid-market ERP project. Not a hundred. If you have more, you're too detailed. The details come later—in the fit-to-standard workshops with the selected vendor.

For each Epic, you assign a provisional priority based on the WSJF model (Weighted Shortest Job First): Business Value, Time Criticality, Risk Reduction, and Effort. You don't need to calculate this scientifically—a rough assessment on a scale of 1 to 5 is perfectly adequate.

The result of this phase is your Epic Portfolio—the prioritised list of initiatives that your new ERP should enable. This is the core of your tender.

🚧 Brownfield vs. Greenfield: An Important Junction

Before you proceed, you must make a fundamental decision that will determine your further path: are you migrating an existing system or starting on a greenfield site?

With a migration (brownfield), you have a huge advantage: you know what works. Your requirements gathering focuses on the deltas—what should be different? Where are the gaps? The effort for gathering is significantly less, but the technical complexities of data migration are added.

With a new implementation (greenfield), you have the chance to rethink processes. This is simultaneously curse and blessing. The temptation is great to rebuild every special request from the last 20 years. Resist. Use the opportunity to radically question: do we really need this process like this?

In both cases: explicitly document which Epics map standard processes (FIT) and which require deviations (GAP). This distinction will be crucial later for vendors' costing.

📋 The Tender Documents

Now comes the part that probably interests you most: what do tender documents look like that are suitable for an agile contract?

The classic approach—detailed requirements specification, fixed price, done—leads to a dead end for ERP projects. Either the vendor calculates so much risk buffer that you pay significantly too much. Or they calculate tightly and finance themselves later through change requests. Neither is in your interest.

The alternative approach I recommend consists of four documents:

The first document is the project vision with Strategic Themes. Two to three pages describing why you're doing this project and how you measure success. This document is read by the vendor's managing director—not the sales representative.

The second document is your process landscape or Value Stream. Your documented end-to-end processes (Order-to-Cash, Procure-to-Pay, etc.)—each with the concrete problems that need to be solved. If you already have a process landscape from ISO certification, continue working with it and supplement it with the identified delays and bottlenecks. That's perfectly adequate.

The third document is the Epic Portfolio with Lean Business Cases. This is the core of your tender. For each Epic: problem description, expected benefit, success criteria, dependencies, provisional priority. No detailed target processes, no screen mask descriptions.

The fourth document describes the framework conditions and rules of engagement. Here you define how you want to work together: what roles do you expect from the vendor? How often should deployment occur? How do you handle changes? Who has what decision-making authority?

Explicitly not part of the tender is a 200-page requirements specification with target processes. You develop these details together with the selected vendor in so-called fit-to-standard workshops during implementation.

⚙️ The Contract Model

Here it gets legal—and here many agile ERP projects fail before they've really begun. Contract law doesn't recognise "agile contracts". You must decide: works contract (you pay for a result) or service contract (you pay for time and effort). The legal classification remains complex—the Frankfurt Higher Regional Court left the classification open in 2017 and tended towards a mixed-type contract.

In practice, a hybrid model known as "Agile Fixed Price" has proven effective. The basic idea: you define an overall framework (budget and rough scope) and agree that the details are worked out iteratively in sprints. Each sprint has a fixed budget and delivers an agreed increment. After each sprint, you both have the option to adjust or terminate the contract.

Two mechanisms are crucial here. The first is called "Change for Free": within the overall budget, you can swap requirements as long as the effort is comparable. You no longer want Feature A, but instead Feature B? No problem, as long as the estimated effort is similar.

The second mechanism is called "Money for Nothing": if after Sprint 10 you realise you've already received enough value delivered, you can terminate the project early. The vendor keeps part of the saved budget, you keep the rest.

Have these contracts reviewed by an IT lawyer who understands agile projects. This costs a few thousand dollars and potentially saves you hundreds of thousands in disputes.

⚠️ The Reality: What This Roadmap Doesn't Cover

It doesn't replace the political work. ERP projects rarely fail due to technology—they fail due to people who can't agree or who don't want the project. If your sales director sabotages the project, the best requirements gathering won't help you.

It doesn't guarantee success in vendor selection. Even with perfect tender documents, you can choose the wrong vendor. The chemistry must be right, industry experience must fit, key personnel must be available.

It doesn't make the project shorter or cheaper. Agile methods aren't a magic bullet. They make projects more transparent and adaptable—but not automatically faster or cheaper. However, a McKinsey study on agile ERP implementations shows measurable benefits: approximately 10% lower project costs and 20% higher programme value—when the prerequisites are met.

👥 For Whom Is This Approach Suitable—And For Whom Not?

This approach works well for mid-market companies with 50 to 500 employees who are willing to engage in a collaborative relationship with the vendor. It works well when you have decision-makers who can invest time regularly for the project.

It works less well if your organisation is heavily regulated and mandatory detailed upfront documentation is required. It works less well if your procurement department insists on classic fixed-price tenders and shows no flexibility. And it doesn't work if your management wants to delegate the project to IT and doesn't want to be involved themselves.

📚 Further Resources

If you want to delve deeper, I recommend the following sources:

On the topic of SAFe and ERP, SAP together with Scaled Agile published an official SAP Activate + SAFe Playbook in October 2024, which standardises the methodological integration of both frameworks. For public sector clients, the Agile Public Administration Forum offers a template for agile software contracts with EVB-IT combination.

On legal contract design, there are now well-founded BITKOM practical guides for balanced IT contracts. The standard work on the Agile Fixed Price is "Der agile Festpreis" by Opelt, Gloger, Pfarl and Mittermayr (Hanser Verlag, 4th edition 2023).