Od specyfikacji wymagań do specyfikacji systemu
Od zgodności z TSI i dowodów CENELEC po koordynację dostawców: pięć faz pracy ze specyfikacją wymagań, ReqIF w praktyce, typowe wąskie gardła i obszary, w których cyfryzacja robi największą różnicę.
Wprowadzenie
Każdy, kto składa ofertę w europejskim przemyśle kolejowym, musi przekształcić specyfikację wymagań w specyfikację realizacyjną. Brzmi to jak praca nad dokumentami. W praktyce dziesiątki ekspertów dziedzinowych koordynują przy tym tysiące pojedynczych wymagań z setkami odwołań do norm, a wiele firm nadal robi to w Excelu i Wordzie.
Sam europejski rynek taboru kolejowego jest wart, według badania UNIFE World Rail Market Study 2024 63,3 mld EUR, przy rocznym wzroście 7,3% w Europie Zachodniej. Według badania Parlamentu Europejskiego (2023) czterech największych europejskich producentów posiada ponad 70% udziału w rynku. Kto chce konkurować na tym rynku, musi szybko, kompletnie i zgodnie z normami odpowiadać na specyfikacje wymagań. Tematem tego artykułu jest proces prowadzący do tego celu.
Poniżej: dlaczego przemysł kolejowy jest szczególnie wymagający, pięć faz procesu, gdzie zazwyczaj pojawiają się problemy oraz co mogą zmienić narzędzia cyfrowe.
Czym jest specyfikacja wymagań?
Specyfikacja wymagań (po angielsku: requirements specification lub tender specification) opisuje wszystkie wymagania, jakie zamawiający stawia dostarczanemu systemowi. W przemyśle kolejowym tworzy ją zamawiający, czyli przedsiębiorstwo transportowe lub zarządca infrastruktury, a następnie wysyła ją do potencjalnych dostawców.
W zależności od zakresu projektu specyfikacja wymagań zawiera od setek do kilku tysięcy pojedynczych wymagań. W przemyśle kolejowym struktura często opiera się na kategoriach LH (LH1 do LH8), które obejmują różne podsystemy: konstrukcję pojazdu, technikę napędową, układy hamulcowe, wyposażenie wnętrza, informację pasażerską i inne.
Każde wymaganie zwykle zawiera jednoznaczny identyfikator, właściwy tekst wymagania, odniesienia do norm (TSI, DIN EN, ISO) oraz stopień wiążący (musi, powinno, może). Przewodnik VDB dotyczący zarządzania wymaganiami zaleca elektroniczną wymianę w formacie ReqIF (Requirements Interchange Format), aby uniknąć ręcznego porównywania wersji dokumentów.
Nie należy też lekceważyć ram czasowych: według badania Parlamentu Europejskiego w Niemczech od zaproszenia do udziału w postępowaniu do produkcji seryjnej mija zwykle od 7 do 8 lat, a od podpisania umowy co najmniej 6 lat. Faza specyfikacji realizacyjnej znajduje się na początku tego łańcucha i decyduje o tym, czy dostawca w ogóle znajdzie się na krótkiej liście.
Dlaczego przemysł kolejowy jest szczególnie wymagający
Specyfikacje wymagań występują w każdej branży. Przemysł kolejowy wyróżnia połączenie głębokości regulacyjnej, różnorodności norm oraz szerokości łańcucha dostaw.
Złożoność TSI
Pojazd szynowy musi jednocześnie spełniać kilka technicznych specyfikacji interoperacyjności (TSI) UE. ERA definiuje 11 różnych TSI. Dla pojazdów co najmniej trzy są bezpośrednio istotne: LOC&PAS (lokomotywy i wagony pasażerskie), Noise (emisje hałasu) oraz PRM (dostępność). W zależności od typu pojazdu dochodzą CCS (sterowanie ruchem kolejowym), SRT (bezpieczeństwo w tunelach kolejowych) i kolejne.
Każda TSI jest rozporządzeniem UE, a tym samym prawem obowiązującym bezpośrednio. Tam, gdzie TSI pozostawiają kwestie otwarte, dodatkowo obowiązują krajowe przepisy techniczne (NNTR). W projektach transgranicznych oferenci muszą jednocześnie spełniać TSI oraz NNTR kilku państw. Zgodność sprawdza jednostka notyfikowana (NoBo) oraz jednostka wyznaczona (DeBo).
CENELEC EN 5012x: RAMS, oprogramowanie, Safety Case
Oprócz TSI rynek wymaga wykazania bezpieczeństwa funkcjonalnego zgodnie z normami CENELEC. Trzy kluczowe standardy to:
- EN 50126 definiuje cykl życia RAMS (Reliability, Availability, Maintainability, Safety) w 12 fazach. Oferenci muszą dostarczyć dla swojego systemu cele RAMS, analizy ryzyka (FMEA, FTA) oraz Safety Case.
- EN 50716 od października 2023 r. łączy w jednym standardzie wcześniejsze EN 50128 (technika sygnalizacyjna) oraz EN 50657 (oprogramowanie pojazdów). Nowość: wyraźne regulacje dotyczące rozwoju iteracyjnego, komponentów AI/ML i cyberbezpieczeństwa.
- EN 50129 definiuje strukturę Safety Case oraz dowody bezpieczeństwa sprzętu. Przed dopuszczeniem do eksploatacji w UE obowiązkowa jest ocena przez niezależnego asesora bezpieczeństwa (ISA).
Wszystkie te dowody trafiają do specyfikacji realizacyjnej. Oferent, którego dokumentacja RAMS zawiera luki, otrzyma niższą ocenę niezależnie od tego, jak dobry technicznie jest jego pojazd.
Łańcuch dostaw zwielokrotnia złożoność
Żaden OEM nie buduje pojazdu szynowego samodzielnie. Według własnej strony dla dostawców Alstom współpracuje z ponad 21 000 dostawców w 83 krajach. Zakupy stanowią 60% rocznych przychodów. Każdy z tych dostawców otrzymuje częściową specyfikację wymagań dotyczącą jego zakresu i musi odpowiedzieć własną specyfikacją realizacyjną. Producent systemu hamulcowego otrzymuje wymagania dotyczące hamulców, dostawca HVAC wymagania klimatyczne, a producent siedzeń wymagania dotyczące wyposażenia wnętrza.
Oznacza to, że OEM musi nie tylko przygotować własną specyfikację realizacyjną, ale też konsekwentnie przekazać wymagania dostawcom podsystemów i skonsolidować ich odpowiedzi. Jeżeli producent hamulców oceni wymaganie jako OKB, a OEM zgłosi klientowi OK, powstaje niespójność, która zostanie zauważona podczas kontroli.
Kontrakt o wartości 15 mld EUR dla berlińskiej S-Bahn otrzymało konsorcjum DB, Siemens i Stadler. 1 400 nowych wagonów, przetarg trwa od 2020 r., rozstrzygnięcie nastąpiło dopiero w 2025 r. Alstom zaskarżył postępowanie. Takie struktury konsorcjalne pokazują, jak wiele stron może uczestniczyć w opracowywaniu wymagań.
5 faz opracowania
Proces można podzielić na pięć faz. W praktyce nakładają się one na siebie i różnią się zależnie od firmy, lecz podstawowy wzorzec jest podobny u większości oferentów.
Specyfikacja wymagań jest importowana i dzielona na poszczególne wymagania. Ekstrahowane są struktura, identyfikatory i odwołania do norm. Przy rewizjach trzeba zidentyfikować zmiany względem poprzedniej wersji. Najlepiej, gdy wymiana odbywa się w formacie ReqIF, obsługiwanym przez narzędzia takie jak IBM DOORS, Siemens Polarion i Eclipse RMF.
Każde wymaganie jest oceniane: OK (w pełni możliwe do spełnienia), OKB (możliwe do spełnienia pod warunkami), NOK (niemożliwe do spełnienia), OKM (możliwe do spełnienia po modyfikacji) lub R (pytanie do zamawiającego). OKB jest często najtrudniejszym przypadkiem, ponieważ warunek musi być sformułowany precyzyjnie, mierzalnie i w sposób akceptowalny dla klienta.
Wymagania są przydzielane właściwym działom specjalistycznym: technika napędowa, układy hamulcowe, elektryka, RAMS, wyposażenie wnętrza. W zależności od zakresu projektu uczestniczy od 10 do 30 zespołów podsystemowych. Błędne przydzielenia kosztują czas i powodują luki.
Eksperci dziedzinowi formułują zgodne z normami odpowiedzi z odniesieniami do dowodów. Dokumentowane są warunki, propozycje alternatywne i pytania. Każda odpowiedź musi móc wskazać dokumenty źródłowe: raporty z badań, dokumenty dopuszczeniowe, karty katalogowe producenta, dowody RAMS.
Pojedyncze odpowiedzi są łączone w specyfikację realizacyjną i eksportowane jako kompletny dokument oraz jako częściowe specyfikacje wymagań dla każdego podsystemu, w formacie wymaganym przez klienta, z pełną identyfikowalnością od wymagania do dowodu.
ReqIF w praktyce
Requirements Interchange Format (ReqIF) to otwarty standard OMG (obecnie wersja 1.2) umożliwiający bezstratną wymianę danych o wymaganiach między różnymi narzędziami. Pierwotnie opracowany w 2004 r. przez Herstellerinitiative Software (HIS) niemieckiego przemysłu motoryzacyjnego, ReqIF jest utrzymywany przez OMG od 2011 r.
Teoretycznie ReqIF rozwiązuje problem wymiany wymagań między zamawiającym a oferentem. W praktyce występują udokumentowane problemy z interoperacyjnością: podczas importu ReqIF z Polarion do IBM DOORS wszystkie obiekty są oznaczane jako zablokowane. Starsze wersje DOORS implementowały RIF 1.0, podczas gdy Polarion używał RIF 1.1a, co prowadziło do cichych błędów importu . Rozszerzenia specyficzne dla dostawców, brak filtrowania atrybutów oraz niezgodności wersji nadal są problemem.
W 2020 r. wskaźnik wykorzystania szacowano na 30%. W przemyśle kolejowym jest on niższy niż w motoryzacji. W artykule CONTACT Software z 2014 r. stwierdzono, że większość producentów nadal nie potrafiła dostarczać swoich specyfikacji w prawidłowym formacie. Od tego czasu sytuacja się poprawiła, ale wielu mniejszych dostawców nadal wymienia wymagania za pomocą Excela.
Typowe wyzwania
Opracowanie specyfikacji wymagań w dużych projektach kolejowych trwa od tygodni do miesięcy. Problemy, które się przy tym pojawiają, zna każda branża z rozbudowanymi przetargami. W przemyśle kolejowym są one bardziej wyraźne, ponieważ wolumeny wymagań, liczba zaangażowanych zespołów oraz głębokość regulacyjna są większe.
Liczba wymagań, które trzeba komentować podczas opracowywania specyfikacji wymagań, wzrosła co najmniej dziesięciokrotnie w ciągu ostatnich dziesięciu lat.
– Menedżer producenta systemów hamulcowych, blog CONTACT Software (2014)Źródło: CONTACT Software, Powolny pociąg do zarządzania wymaganiami
Ten sam artykuł wymienia dalsze przyczyny: krajowe standardy różnych państw są ze sobą sprzeczne, międzynarodowi interesariusze różnie interpretują normy, a wielokrotne przetargi tego samego zamawiającego prowadzą do odmiennych specyfikacji między partiami. Do tego dochodzi fakt, że dokumenty wymagań rozrosły się z płyty CD do DVD wyłącznie po to, by pomieścić zakres pojedynczego przetargu.
Obraz ten potwierdzają dane międzybranżowe. Raport Loopio 2025 RFP Response Trends Report (ponad 1 500 zespołów ofertowych, wszystkie branże) pokazuje: 48% zespołów zgłasza trudności we współpracy z ekspertami dziedzinowymi, a 39% ma problemy ze znalezieniem na czas dokładnych odpowiedzi na pytania techniczne. Dla przemysłu kolejowego nie ma porównywalnego badania, ale ze względu na większą liczbę zaangażowanych zespołów podsystemowych faktyczny odsetek powinien być wyższy.
Jakość specyfikacji jako wąskie gardło
Problem często zaczyna się już od samej specyfikacji wymagań. Prover Technology identyfikuje trzy główne problemy specyfikacji w fazie przetargowej: są niekompletne, niespójne i błędne. Błędy niewykryte na tym etapie przenikają cały cykl życia projektu i z każdą fazą stają się droższe do naprawienia.
Co musi zawierać specyfikacja realizacyjna
Specyfikacja realizacyjna (Compliance Document lub Technical Offer) jest oficjalną odpowiedzią na specyfikację wymagań. Dokumentuje dla każdego pojedynczego wymagania, czy i jak dostawca je spełnia. Profesjonalna specyfikacja realizacyjna zawiera:
- Pełne pokrycie wymagań: każde wymaganie specyfikacji wymagań jest uwzględnione, żadne nie zostaje pominięte
- Klasyfikację z uzasadnieniem: OK, OKB, NOK, OKM lub R z konkretnym wyjaśnieniem (więcej w szczegółowym omówieniu klasyfikacji)
- Odniesienia do dowodów: wskazanie dokumentów źródłowych, takich jak raporty z badań, dokumenty dopuszczeniowe, dowody RAMS lub karty katalogowe producenta
- Zgodność z normami: przypisanie do odpowiednich standardów (TSI, DIN EN, ISO, CENELEC EN 50126/50716/50129)
- Warunki i propozycje alternatywne: jasne sformułowanie w przypadku OKB i OKM
- Częściowe specyfikacje wymagań: podział według podsystemów do wewnętrznego dalszego przetwarzania i przekazania dostawcom
Standard EuroSpec dotyczący zarządzania wymaganiami definiuje ponadto sześć obszarów kluczowych: cechy wymagań, składnię, atrybuty, identyfikowalność, walidację/weryfikację oraz wymianę danych. Ta struktura stanowi dobre wskazanie dla zapewnienia jakości specyfikacji realizacyjnych.
Różnica między dobrymi i słabymi specyfikacjami realizacyjnymi
Jakość specyfikacji realizacyjnej często decyduje o przyznaniu zamówienia lub wykluczeniu. W regulowanych postępowaniach zakupowych, na przykład w ESA lub w prawie zamówień publicznych, rozbieżności między deklaracjami zgodności a faktyczną ofertą mogą prowadzić do znacznego obniżenia oceny lub wykluczenia. Priorytety UNIFE na lata 2024–2029 zalecają stosowanie zasady MEAT (Most Economically Advantageous Tenders) z kosztami cyklu życia. W praktyce oznacza to, że zamawiający ocenia na podstawie macierzy zgodności, a luki lub niespójności są karane.
Jak cyfryzacja i AI zmieniają proces
Cyfryzacja przebiega w dwóch krokach. Najpierw następuje przejście z Excela i Worda na systemy oparte na bazach danych. Następnie, na tej podstawie, wdrażane jest wsparcie AI.
Krok 1: systemy oparte na bazach danych
Ugruntowane narzędzia w sektorze kolejowym to IBM DOORS (od dziesięcioleci de facto standard w branżach regulowanych), Siemens Polarion (z natywną obsługą ReqIF) oraz Reqtify firmy Dassault Systèmes (nakładka do identyfikowalności z ponad 100 interfejsami). Wiele przedsiębiorstw kolejowych już wykonało ten krok lub właśnie jest w trakcie.
Konkretny przykład: Rail Projects Victoria (Melbourne) wybrało DOORS Next jako rozwiązanie SaaS dla projektu Metro Tunnel Project, aby centralnie zarządzać wymaganiami wśród wielu uczestników projektu. Deutsche Bahn wdrożyła system zarządzania wymaganiami oparty na bazie danych dopiero około 2012/2013 r., co dokumentuje artykuł CONTACT Software.
Krok 2: wsparcie AI
Według raportu Loopio 2025 RFP Response Trends Report 68% zespołów ofertowych we wszystkich branżach wykorzystuje już generatywną AI — dwa razy więcej niż 34% w 2023 r. W przemyśle kolejowym ta zmiana w dużej mierze dopiero nastąpi.
Zakres automatyzacji zależy od fazy:
Rejestracja wymagań: automatyczne analizowanie, strukturyzowanie i wykrywanie różnic między rewizjami. Przewodnik VDB zaleca do tego format ReqIF, który umożliwia automatyczne oznaczanie zmian.
Klasyfikacja: porównywanie wymagań z dokumentami wewnętrznymi, normami i wcześniejszymi odpowiedziami projektowymi. Tu tkwi największy potencjał, ale jakość zależy całkowicie od wewnętrznej bazy wiedzy, a ostateczna decyzja pozostaje po stronie eksperta.
Kierowanie do ekspertów: automatyczny przydział na podstawie tematyki, kategorii LH oraz odwołania do normy. Platformy takie jak Tendric stosują tu routing oparty na regułach, aby ograniczać błędne przydzielenia.
Odpowiedź: generowanie propozycji odpowiedzi na podstawie bazy wiedzy. Według Bidara wskaźnik ponownego wykorzystania treści między branżami wynosi 66%, co jest potencjałem, którego wiele firm nie wykorzystuje z powodu braku przeszukiwalnej bazy wiedzy.
Eksport: zautomatyzowane formatowanie i generowanie częściowych specyfikacji wymagań dla każdego podsystemu i dostawcy.
Od października 2023 r. EN 50716 zastępuje wcześniejsze EN 50128 i EN 50657. Nowy standard po raz pierwszy dopuszcza rozwój iteracyjny (Agile/Scrum), zawiera regulacje dotyczące komponentów AI/ML i wymaga integracji cyberbezpieczeństwa zgodnie z CENELEC TS 50701. Dla menedżerów ofert oznacza to, że odwołania do norm w starych szablonach specyfikacji realizacyjnych muszą zostać zaktualizowane.
Rynek oprogramowania do zarządzania przetargami wzrośnie, według Verified Market Reports do 3,5 mld USD do 2033 r. (CAGR 9,8%). W sektorze kolejowym rozpowszechnione są ugruntowane narzędzia, takie jak IBM DOORS i Siemens Polarion, lecz wyspecjalizowane rozwiązania obejmujące całą drogę od specyfikacji wymagań do specyfikacji realizacyjnej, takie jak Tendric, nadal należą do rzadkości.
Wnioski i kolejne kroki
Im większa specyfikacja wymagań, tym bardziej opłaca się uporządkowany proces. Przy setkach lub tysiącach wymagań, 11 TSI, dowodach CENELEC oraz łańcuchu dostaw z dziesiątkami dostawców podsystemów różnica między pracą opartą na dokumentach a pracą wspieraną przez bazę danych staje się czynnikiem decydującym.
Poziom dojrzałości można z grubsza podzielić na cztery etapy:
- Excel i Word (oparte na dokumentach, bez identyfikowalności)
- System oparty na bazie danych (DOORS, Polarion) z centralnym zarządzaniem wymaganiami
- Zintegrowana platforma z wymianą ReqIF, kierowaniem do ekspertów i eksportem częściowych specyfikacji wymagań
- Klasyfikacja wspierana przez AI i generowanie odpowiedzi na podstawie wewnętrznej bazy wiedzy
Kto dziś nadal znajduje się na etapie 1, nie powinien próbować przeskoczyć od razu do etapu 4. Najbardziej oczywistym pierwszym krokiem jest centralny system, w którym wymagania, klasyfikacje, odwołania do źródeł i odpowiedzi są ze sobą powiązane i identyfikowalne. Narzędzia takie jak Tendric dokładnie odwzorowują tę strukturę. Bez takich uporządkowanych danych wsparcie AI nie ma podstaw.
- Specyfika przemysłu kolejowego: kilka TSI, dowody CENELEC EN 5012x i krajowe przepisy (NNTR) dla każdego projektu
- Proces obejmuje 5 faz, od rejestracji po eksport, które w praktyce często przebiegają równolegle
- OEM-y, takie jak Alstom, koordynują ponad 21 000 dostawców, z których każdy musi odpowiedzieć na własną częściową specyfikację wymagań
- ReqIF teoretycznie rozwiązuje wymianę, ale występują udokumentowane problemy z interoperacyjnością między narzędziami
- EN 50716 od października 2023 r. zastępuje wcześniejsze EN 50128/50657 i wprowadza regulacje dotyczące AI/ML oraz cyberbezpieczeństwa
- Postęp dojrzałości: Excel → baza danych → zintegrowana platforma → wsparcie AI
Das tendric-Team entwickelt KI-gestützte Werkzeuge für die Ausschreibungsbearbeitung in der Industrie. Wir schreiben über Best Practices, Branchentrends und die Zukunft des Angebotsmanagements.