Multi-product tenders: how to manage multiple variants and product lines in one project

Introduction

In March 2024, Siemens Mobility delivered the 137th and final ICE 4 to Deutsche Bahn. Behind that number lies a detail that is decisive for bid managers: the 137 trains comprise three different variants—37 seven-car, 50 twelve-car, and 50 thirteen-car XXL trains—with a total of 1,500 coaches and around 105,000 seats. One procurement, three vehicle configurations, an investment volume of six billion euros.

Such multi-product procurements are not an exception in the European rail industry. The UNIFE World Rail Market Study 2024 puts the global rolling-stock segment at EUR 63.3 billion, within a total market volume of EUR 201.8 billion. Western Europe is driving growth at 7.3%, primarily through the renewal of electric fleets. Transport operators and infrastructure managers are increasingly bundling their needs into framework agreements covering multiple vehicle types and variants.

For the manufacturer, this means that a single specification contains requirements that sometimes apply to every offered product, sometimes only to specific variants, and sometimes must be answered at company level. This article walks through the structural complexity of such tenders, using real procurement programmes, the regulatory framework, and tools that make the process manageable.

Multi-product procurements: market and practice

A multi-product tender (also known as a package tender or framework tender) covers the procurement of several different vehicle types or series within one procurement procedure. In rolling-stock manufacturing, there are two typical configurations:

• Different vehicle types: An infrastructure manager procures tamping machines, ballast profiling machines, and stabilisers at the same time—three fundamentally different machines with different technical specifications.
• Variants of one vehicle series: A transport operator orders multiple units in different lengths, with different propulsion systems, or for different route categories (main line vs. branch line).

Real procurement programmes

A look at current and completed framework agreements:

• DB ICE 4 (Siemens): 137 trains in three variants (7-car, 12-car, 13-car XXL), EUR 6 billion. The largest procurement programme in DB history. Each variant has different seating capacities, coach counts, and configurations, but shares the same platform.
• DB ICE 3neo (Siemens): A total of 90 high-speed trains in three order tranches (30 + 43 + 17 trains) over several years, with a total volume of around EUR 3.1 billion.
• ÖBB Mireo (Siemens): Framework agreement for up to 540 electric regional trains worth more than EUR 5 billion. The first call-off covers 70 Mireos in three variants: 11 three-car units (73 m) and 28 four-car units (106 m) for regional services, plus 31 four-car units for long-distance services on Alpine routes.
• ÖBB KISS (Stadler): Framework agreement for up to 186 double-decker trains worth up to EUR 3 billion. The same KISS platform supplies both four-car Cityjet regional trains and six-car Railjet long-distance trains.
• Stadler FLIRT: More than 2,750 units ordered in 24 countries. The FLIRT family includes 2- to 6-car configurations and electric, diesel-electric, and battery variants.
• SBB FLIRT (Stadler): Framework agreement for up to 510 FLIRT units for SBB, Thurbo, and RegionAlps—the largest rolling-stock order in Swiss railway history. First call-off: 286 trains for around CHF 2 billion. The FLIRT family includes 2- to 6-car configurations and electric, diesel-electric, hydrogen, and battery variants, with more than 2,750 units ordered in 24 countries.
• SNCF TGV M / Avelia Horizon (Alstom): Framework agreement for a total of 160 modular high-speed trains (115 SNCF + 30 Eurostar + 15 follow-up order), with a total volume of more than EUR 3.5 billion. The “M” stands for “modulaire”: configurable seating and interior layouts per variant.
• DB Cargo Vectron Dual Mode (Siemens): Framework agreement for up to 400 locomotives worth more than EUR 1 billion. The Vectron platform is approved in 20 European countries, with variants for AC, DC, multi-system (MS), and dual-mode operation. The multi-system variant supports four different power systems (25 kV AC, 15 kV AC, 3 kV DC, 1.5 kV DC).

Vehicle authorisation: types, variants, and versions

Anyone offering several vehicle variants quickly encounters the European authorisation regime. The European Union Agency for Railways (ERA) has been the central authorising body since 2019 for vehicles used in several Member States. The Implementing Regulation (EU) 2018/545 defines three levels:

In concrete terms, each type variant needs its own evidence of conformity with the applicable Technical Specifications for Interoperability (TSIs). Since 2019, the ERA has authorised more than 80,000 vehicles, with 83% of approvals concerning cross-border operations. In a multi-product tender, the bid manager must demonstrate separately for every variant which TSI requirements are met and which are not.

Product structure under EN 15380

Without a consistent product structure, every multi-product tender descends into chaos. The European standard EN 15380 (Railway applications: designation system for railway vehicles) defines a standardised product-tree structure in four parts:

• Part 1: General principles of the designation system
• Part 2: Product groups (for example, multiple units, locomotives, passenger coaches)
• Part 3: Product characteristics (technical attributes such as gauge, maximum speed, and propulsion type)
• Part 4: Function groups (the hierarchical breakdown into subsystems such as running gear, propulsion, braking, and power supply)

Part 4 is especially relevant to bid processing: its function groups provide the structure used to assign subsystem and department requirements. When the customer organises its requirements along the EN 15380 structure, partial specifications can be exported for each function group—for example, all bogie requirements for a supplier or all braking requirements for the specialist department.

The three levels of requirement assignment

Requirements in a multi-product tender can be divided into three levels. Anyone who does not apply this distinction consistently produces flawed exports:

Why duplicate rather than link?

The decision to duplicate shared requirements for each product rather than model them as one requirement with multiple answers is deliberate and arises from practice. The VDB requirements-management guide describes the need to assign each requirement unambiguously to responsibilities and evidence. Where answers differ by product, duplication is the only way to preserve that clarity.

Three products, three different engines, three different answers. Each also needs its own evidence documents, owners, and comment threads. One requirement line with a single compliance status is not enough. The same pattern occurs on the Vectron platform: a power-supply requirement has a different answer for the AC variant (5,600 kW, 15 kV / 25 kV) than for the DC variant (5,200 kW, 3 kV / 1.5 kV) and the multi-system variant (6,400 kW, all four power systems).

Typical assignment by specification category

In practice, assignment to the right level often follows the specification-category structure. Not all categories are equally product-specific:

Share of product-specific requirements per specification category (qualitative assessment). LH3 and LH4 are predominantly company-wide requirements; LH7 is almost exclusively product-specific.

This distribution has a direct impact on requirement volume: in a tender with 800 requirements and three products, the ~5% company-wide LH4 requirements are answered once (~40 requirements), while the ~95% product-specific LH7 requirements must be processed three times (~2,280 product-requirement combinations in LH7 alone). The total volume therefore quickly rises to 1,500 to 2,000 effective responses.

Standards compliance across multiple products

Each product has its own certification status. The same standard can be fulfilled for product A and not fulfilled for product B.

ISO 22163:2023 (IRIS Rev. 04) requires complete traceability from customer requirements to design evidence in its design and development clauses (Section 8.3). At the same time, Section 8.1.4 requires structured configuration management with defined baselines. The IRIS Guideline 8 (Configuration & Change Management) specifies three configuration baselines:

• As Designed: The approved design of all configuration items. It must be documented separately for each product because different variants have different designs.
• As Built: The actual build state. In multi-product orders, series status and production dates diverge between variants.
• As Maintained: The maintenance state over the lifecycle. Every variant develops independently.

With several products, this means every standards requirement must be assessed and evidenced separately for each product, and every configuration baseline must be managed independently for every variant.

Partial specifications by product and subsystem

In multi-product tenders, partial specifications must be exportable for every product and subsystem. The customer typically expects an overall functional specification, but internally subsystem-specific extracts must be passed on to specialist departments and suppliers.

Typical partial specifications in a multi-product tender for track-construction machines:

• Bogie partial specification: all running-gear requirements across all products, with product-specific answers
• Brake partial specification: braking requirements per product (different braking performance)
• Electrical partial specification: power supply, lighting, and control per product
• Hydraulics partial specification: only for products with hydraulic units
• Propulsion partial specification: engine, transmission, and exhaust aftertreatment per product

The combination of multi-product and multi-expert work creates a matrix: for every requirement, it must be clear which product it concerns and which 1–5 experts are responsible. With three products and an average of two experts per requirement, 500 shared requirements create an assignment matrix of 3,000 entries. This is barely manageable manually.

Typical challenges

1. Excel reaches its limits

In spreadsheet-based work, product assignment is often handled through additional columns: one answer column per product. With three products, row width triples, clarity declines, and maintaining cross-references between product columns becomes error-prone. The CONTACT Software Blog described the limits of spreadsheet-based requirements processing at increasing volumes as early as 2014. Multi-product scenarios intensify the problem. Specifically, an Excel file with 800 requirements and three products has 2,400+ answer cells spread across dozens of columns, with manual consolidation required for every revision.

2. Consistency checking across product boundaries

When product A classifies a requirement as “OK” and product B classifies the same requirement as “NOK”, the bid manager must check whether that is correct or an error. With hundreds of shared requirements, this cross-check is barely feasible manually, especially when different experts work on the products and enter responses at different times.

3. Configuration management across variants

ISO 22163:2023 merged the former Sections 8.1.4 (configuration management) and 8.1.5 (change management) into a combined Section 8.1.4, “Configuration management and change control”. The standard requires configuration baselines to be established at least for “as designed”, “as built”, and “as maintained”. In multi-product orders, this means every variant has its own configuration baseline, and changes to one variant must not be transferred to others in an uncontrolled way. A new software release for the tamping machine does not automatically affect the stabiliser, even if both are based on the same control platform.

4. Export complexity

The customer may expect various formats: an overall functional specification with all products, separate specification sections per product, and partial specifications per subsystem. Each export must apply the right filtering: only requirements for product A, only the LH7 category, only the “propulsion” subsystem group. With three products and eight specification categories, that creates up to 24 export combinations, before subsystem filters are added.

Tools and data exchange

In practice, the tool spectrum ranges from enhanced Excel structures to database-based systems:

IBM DOORS Next was used on the Melbourne Metro Tunnel Project (AUD 13.4 billion) to coordinate thousands of requirements across four work packages and hundreds of engineers. According to Acmena, it was one of the first rail projects with centralised requirements management across all contractors and suppliers, including information partitioning: separate workspaces for different contractors alongside a project-wide integration view.

Siemens Polarion also offers requirements management with end-to-end traceability. For multi-product scenarios, Polarion’s multi-product branching is relevant: specification documents can be branched to manage commonalities between products while tracking product-specific requirements. Since 2025, Polarion has also used AI to automatically extract and cluster requirements from incoming tender documents (PDF, MS Office). This saves substantial manual effort with large multi-product specifications.

How AI helps with multi-product tenders

AI can help at several points in multi-product tenders, although the degree of automation varies greatly by task. Platforms such as Tendric address this scenario specifically through product-by-product requirements management and automated consistency checking:

• Automatic scope detection: Identify whether a requirement is product-specific, shared, or company-wide based on keywords, standards references, and specification category. Requirements with unambiguous standards references (for example, “EN 45545” or “Stage V”) can be assigned reliably to the right scope; with ambiguous wording, the hit rate decreases.
• Product-specific classification: Compare every requirement against the relevant product data sheet and associated manufacturer specification, with a separate assessment for each product. Quality depends directly on the availability of product-wise separated SSOT documents.
• Consistency checking: Detect conflicting classifications across product boundaries, such as when a shared interface parameter is assessed as OK for one product and NOK for another. This can be automated well because it is a structured data comparison.
• Automatic partial-specification generation: Filter and export by product and subsystem, including the right standards links and evidence documents.

Conclusion

Multi-product tenders are the rule, not the exception, in the European rail industry. DB procures 137 ICE 4 trains in three variants and 400 Vectron locomotives, ÖBB orders up to 540 Mireos, SBB 510 FLIRTs, and SNCF 160 modular TGV Ms. The sector procures in packages, framework agreements, and platform families. For bid managers, this multiplies the work: more requirements, more standards evidence, more experts, and more exports.

The decisive factor is clear separation into the three levels of requirement assignment: product-specific, shared/duplicated, and company-wide. Every requirement must be assigned unambiguously to a product (or to company level), with its own classification, evidence, and expert responsibility. Tools such as Tendric, which enforce this structure rather than leave it as an optional discipline for the user, reduce errors and enable scalable partial- specification exports.

There is also the regulatory side: ERA type authorisation with variants versus versions, TSI conformity evidence per variant, and ISO 22163 configuration baselines per product. Multi-product tenders are not purely a matter of organisation; they require regulatory expertise and tools that reflect it in day-to-day work.