Kierowanie wymagań do ekspertów: właściwe przypisanie przyspiesza przetarg

Wprowadzenie

Specyfikacja wymagań dla pojazdu szynowego zawiera od setek do tysięcy pojedynczych wymagań. Napęd, hamulce, ochrona przeciwpożarowa, klimatyzacja, informacja pasażerska, dostępność, utrzymanie, każda dziedzina ma własne normy, obowiązki dowodowe i język specjalistyczny. Żaden pojedynczy inżynier nie jest w stanie ocenić tego wszystkiego. Dlatego kierownik oferty rozdziela wymagania między ekspertów z różnych działów i specjalizacji. Ten proces nazywa się routingiem ekspertów.

To, co brzmi prosto, w rzeczywistości jest jednym z największych wąskich gardeł przygotowywania ofert. Już w 2014 r. kierownik producenta systemów hamulcowych powiedział firmie CONTACT Software, że liczba wymagań wymagających komentarza wzrosła w poprzednich dziesięciu latach co najmniej dziesięciokrotnie. W tym samym okresie objętość dokumentów przetargowych wzrosła z płyty CD do DVD. Od tego czasu objętość nadal rosła, podobnie jak liczba zaangażowanych ekspertów.

Liczby są podobne w różnych branżach: według raportu Loopio 2025 RFP Response Trends (ponad 1 500 firm ze wszystkich branż) 48% zespołów ofertowych wskazuje współpracę z ekspertami jako największe wyzwanie, i to już piąty rok z rzędu. W branży kolejowej, gdzie zazwyczaj równolegle pracuje od 10 do 30 zespołów podsystemowych, faktyczne obciążenie koordynacyjne jest prawdopodobnie jeszcze większe.

Dlaczego routing ekspertów ma znaczenie

Jakość oferty bezpośrednio zależy od tego, czy każde wymaganie ocenia właściwy ekspert. Inżynier ochrony przeciwpożarowej może kompetentnie sklasyfikować wymaganie dotyczące EN 45545 , ale nie wymaganie dotyczące kompatybilności z ETCS. Z kolei specjalista od sygnalizacji nie może wypowiadać się o wytrzymałości konstrukcji według EN 12663. INCOSE Requirements Working Group definiuje alokację wymagań, czyli przypisanie wymagań do odpowiedzialnych elementów systemu i osób, jako jedno z podstawowych działań zarządzania wymaganiami, równorzędne z identyfikowalnością i weryfikacją.

Błędy w routingu mają bezpośrednie konsekwencje:

• Błędna klasyfikacja: Osoba niebędąca ekspertem klasyfikuje wymaganie jako "OK", choć w rzeczywistości można je spełnić tylko warunkowo (OKB). W projekcie prowadzi to do Change Request.
• Opóźnienia: Wymaganie trafia do niewłaściwego działu, zostaje przekazane dalej i ponownie czeka w kolejce. Tracone są dni. Według Loopio 33% zespołów uważa, że szybsze odpowiedzi ekspertów byłyby najważniejszym sposobem na wygrywanie większej liczby przetargów.
• Podwójna praca: Bez jasno określonej odpowiedzialności dwa działy opracowują to samo wymaganie niezależnie, być może z sprzecznymi wynikami.
• Luki: Wymaganie nie zostaje przypisane żadnemu ekspertowi i pozostaje nieopracowane. W najgorszym przypadku odpowiedzi brakuje w specyfikacji wykonawczej.

Źródło: CONTACT Software: Bummelzug zum Anforderungsmanagement

Struktura LH i EN 15380: jak organizuje się specyfikacje wymagań

W branży kolejowej specyfikacje wymagań są zazwyczaj dzielone na sekcje tematyczne, obejmujące różne podsystemy i branże. Powszechnie stosowany podział wykorzystuje tak zwane kategorie LH (LH1 do LH8), które wytyczne VDB dotyczące zarządzania wymaganiami opisują jako pomoc w strukturyzacji.

Równolegle seria norm EN 15380 definiuje znormalizowany system klasyfikacji pojazdów szynowych. Część 2 (Product Groups) dzieli pojazd na nazwane grupy produktów, część 4 (Function Groups) przypisuje funkcje, takie jak napęd, hamulce czy sterowanie drzwiami, a część 5 (System Breakdown Structure) definiuje hierarchiczny podział na systemy główne i podsystemy. EN 15380 ma znaczenie dla routingu ekspertów, ponieważ dostarcza stabilnej, niezależnej od producenta taksonomii: jeśli każde wymaganie jest przypisane do podsystemu EN 15380, decyzję o routingu można zautomatyzować lub przynajmniej ustandaryzować.

Typowa liczba wymagań w kategorii LH (wartości względne, zależne od projektu i zamawiającego).

Podział LH stanowi naturalną podstawę routingu ekspertów: wymagania LH3 trafiają do działu napędów, LH6 do działu wyposażenia wnętrz, a LH7 do działu IT. Przypisanie rzadko jednak jest tak jednoznaczne, jak sugeruje struktura.

Workflow routingu w praktyce

Niezależnie od tego, czy firma pracuje w Excelu, systemie ALM czy na wyspecjalizowanej platformie, proces routingu ma podobny przebieg:

RACI i macierze kompetencji: systematyzacja routingu

W przypadku dużych specyfikacji nie wystarczy doraźne przypisywanie wymagań. Firmy, które usystematyzowały ten proces, korzystają z dwóch narzędzi:

Macierz RACI dla routingu: Dla każdej kategorii LH (lub każdego podsystemu EN 15380) ustala się, kto jest Responsible, Accountable, Consulted i Informed. Inżynier napędu jest na przykład Responsible za wymagania LH3, a Consulted przy wymaganiach LH4 ze stykiem do napędu. Macierz RACI zapobiega utracie wymagań przekrojowych podczas przypisywania, ponieważ rola konsultacyjna (Consulted) jest wyraźnie udokumentowana.

Macierz kompetencji dla projektu: Tabela przypisań dokumentująca dla każdego dostępnego eksperta, jakie normy, podsystemy i technologie może objąć. Jeśli specyfikacja po raz pierwszy zawiera wymagania dotyczące napędów wodorowych, macierz kompetencji od razu pokazuje, czy know-how jest dostępne wewnątrz firmy, czy trzeba je pozyskać z zewnątrz. Większość firm buduje macierz kompetencji na podstawie wcześniejszych projektów i aktualizuje ją dla poszczególnych projektów.

Gdzie powstają straty wynikające z tarć

Na papierze ten workflow wygląda prosto. Rzeczywistość jest inna.

1. Problem dystrybucji

W przypadku specyfikacji z 1 500 wymaganiami samo wstępne przypisanie może zająć kilka dni roboczych, jeśli jest wykonywane ręcznie. Kierownik oferty musi przeczytać i zrozumieć każde wymaganie, a następnie przekazać je właściwemu ekspertowi. W przypadku wymagań przekrojowych decyzja nie jest trywialna, zwłaszcza gdy kierownik oferty nie zna równie dobrze każdej specjalizacji. Według Loopio aż 57% zespołów w branży technologicznej zgłasza trudności z koordynacją ekspertów, co jest najwyższą wartością spośród wszystkich branż.

2. Dostępność ekspertów

Eksperci w branży kolejowej nie są dedykowanymi pracownikami ofertowymi. Równolegle pracują przy bieżących projektach, zadaniach rozwojowych i innych przetargach. Jeżeli ekspert ochrony przeciwpożarowej przez dwa tygodnie jest zaangażowany w projekt dopuszczeniowy, jego wymagania stoją w miejscu, niezależnie od systemu routingu stosowanego przez firmę. Według własnej strony dla dostawców Alstom koordynuje około 19 000 dostawców w 77 krajach. Każdy z tych dostawców ma własne ograniczenia przepustowości, które wpływają na czas odpowiedzi OEM.

3. Brak przejrzystości stanu opracowania

W przepływach pracy opartych na dokumentach (Excel, Word przesyłany e-mailem) kierownik oferty nie ma podglądu w czasie rzeczywistym, które wymagania zostały już opracowane, które są nadal otwarte i gdzie powstają wąskie gardła. Zapytania o status przez e-mail lub na spotkaniach zabierają czas i często dają niedokładne wyniki. Według Loopio 39% zespołów ma trudności ze znalezieniem aktualnych, precyzyjnych odpowiedzi na pytania techniczne. W branży kolejowej, gdzie wymagania często odwołują się do źródeł normatywnych zmieniających się między rewizjami, problem jest szczególnie wyraźny.

4. Problemy ze spójnością

Gdy 20 ekspertów niezależnie opracowuje wymagania, mogą pojawić się sprzeczności: dział A klasyfikuje interfejs jako "OK", a dział B odpowiadające mu wymaganie jako "OKB". Takie niespójności często wychodzą na jaw dopiero na późnym etapie konsolidacji, gdy czasu na korekty jest mało. Standard EuroSpec dotyczący zarządzania wymaganiami rozwiązuje ten problem poprzez sześć obszarów podstawowych (cechy wymagań, składnia, atrybuty, identyfikowalność, walidacja/weryfikacja, wymiana danych), ale przestrzeganie tych standardów wymaga, aby wszyscy zaangażowani eksperci pracowali w tym samym systemie.

Modele organizacyjne routingu

To, jak firmy organizują routing ekspertów, zależy od ich wielkości, struktury organizacyjnej i stopnia wsparcia narzędziowego. W praktyce powszechne są trzy modele:

Większość firm stosuje model hybrydowy: kierownik oferty wykonuje zgrubny podział na poziomie podsystemów (na podstawie kategorii LH lub przypisania EN 15380), a osoby odpowiedzialne za podsystemy rozdzielają wymagania szczegółowo w swoim obszarze. Wymagania przekrojowe są identyfikowane przez kierownika oferty i przypisywane wielokrotnie. W dużych przetargach konsorcjalnych, takich jak kontrakt na 15 mld EUR dla berlińskiej kolei S-Bahn (DB, Siemens, Stadler), wymagania są dodatkowo dzielone między partnerów konsorcjum, co dodaje kolejną warstwę routingu.

Identyfikowalność: czego wymagają EN 50126 i ISO 22163

Routing ekspertów jest również wymaganiem regulacyjnym. CENELEC EN 50126 definiuje cykl życia RAMS (Reliability, Availability, Maintainability, Safety) i wymaga w ramach modelu V pełnej identyfikowalności. Każde wymaganie musi dać się przypisać do działania weryfikacyjnego, osoby odpowiedzialnej i dowodu. Specyfikacja i alokacja wymagań systemowych jest odrębną fazą cyklu życia modelu V, z określonymi rolami na każdą fazę. Kto ocenił które wymaganie, należy do dowodu bezpieczeństwa, a nie jest opcją.

ISO 22163:2023 (IRIS Rev. 04) w swoich rozdziałach dotyczących projektowania i rozwoju wymaga identyfikowalności od wymagań klienta aż do dowodu projektowego. IRIS wykracza poza ISO 9001 i uzupełnia specyficzne dla kolei wymagania dotyczące zarządzania projektami, First Article Inspection (FAI), dowodów RAMS i kosztów cyklu życia. Norma obowiązuje w całym łańcuchu dostaw: od firmy rozwojowej, przez producenta i dostawcę, po zakład utrzymania. W kontekście oferty oznacza to, że przypisanie wymagań ekspertom i ich oceny muszą być dokumentowane w sposób możliwy do prześledzenia, nie tylko dla własnego zespołu projektowego, lecz także dla zewnętrznych audytorów i jednostki certyfikującej IRIS.

Narzędzia do routingu ekspertów

Zakres narzędzi sięga od tabel Excela po systemy ALM. To, czego używa firma, określa, jak dobrze routing, śledzenie statusu i identyfikowalność działają na co dzień.

Excel z kolumnami przypisania

Najprostsze podejście: każdy wiersz wymagania otrzymuje kolumnę "Odpowiedzialny", w której wpisuje się nazwisko eksperta. Widoki filtrowane dla każdego eksperta umożliwiają podstawowy podział pracy. Wady: brak powiadomień, brak śledzenia statusu, brak pracy równoległej (słynne pytanie "Kto ma aktualną wersję?"). Artykuł CONTACT Software opisywał w 2014 r., że nawet Deutsche Bahn dopiero "niedawno" wdrożyła bazodanowy system zarządzania wymaganiami.

IBM DOORS / DOORS Next

Wiodący na rynku system zarządzania wymaganiami w branży kolejowej i lotniczej. DOORS oferuje przypisania oparte na regułach, identyfikowalność i analizę wpływu zmian. Konkretny przykład: Rail Projects Victoria (Melbourne) wybrało DOORS Next jako rozwiązanie SaaS dla Metro Tunnel Project o wartości 11 mld AUD. System stworzył centralne, współdzielone środowisko, w którym wymaganiami można było zarządzać w czasie rzeczywistym z udziałem wielu interesariuszy wewnętrznych i zewnętrznych. Szczególnie istotne dla routingu było to, że integracja Hazard Logs i rejestrów interfejsów zapewniała prawidłowe przypisanie kontroli i wymagań właściwym stronom. RPV wykorzystuje obecnie zdobyte doświadczenie również w kolejnych projektach, w tym Regional Rail Revival i Melbourne Airport Rail.

Siemens Polarion

Polarion jest alternatywą Siemens o takim samym zakresie funkcji. Hitachi Rail zintegrował Polarion ze swoimi workflow projektowymi, aby zastąpić Excel i Word jako nośniki wymagań. Od 2025 r. Polarion oferuje również funkcje wspierane przez AI do automatycznego wyodrębniania wymagań z dokumentów przetargowych. AI analizuje obiekty wymagań według domeny i, na podstawie rozpoznanych domen oraz odpowiedzialności, przypisuje je właściwym działom. Według Siemens pozwala to ograniczyć pracę ręczną nawet o 70%.

Wyspecjalizowane platformy

Obok dużych systemów ALM coraz częściej pojawiają się wyspecjalizowane platformy koncentrujące się na procesie ofertowym. Tendric stawia na routing oparty na regułach, z niższym progiem wejścia niż DOORS czy Polarion, ale z ukierunkowanym wsparciem routingu, klasyfikacji i eksportu specyfikacji wykonawczej. Dane międzybranżowe pokazują, że zespoły z uporządkowaną biblioteką treści osiągają 66% ponownego wykorzystania i niemal dwukrotnie częściej uzyskują wysokie wskaźniki wygranych. Wyspecjalizowane platformy działają tam, gdzie Excel przestaje się skalować, a pełny system ALM byłby zbyt rozbudowany.

Czy AI może zautomatyzować routing?

Automatyczne przypisywanie wymagań ekspertom jest naturalnym zastosowaniem systemów opartych na AI. Idea jest prosta: jeśli system uczy się na tysiącach historycznie przypisanych wymagań, jakie sformułowania i tematy należą do danego działu specjalistycznego, może zaproponować wstępne przypisanie dla nowych specyfikacji.

Dla wymagań, które można jasno przypisać, działa to dobrze: wymaganie zawierające "EN 45545" lub "klasę ochrony przeciwpożarowej" zostanie wiarygodnie skierowane do zespołu ochrony przeciwpożarowej. Nowoczesne systemy, takie jak Polarion z warstwą AI idą dalej: rozumieją semantykę wymagań (a nie tylko dopasowanie słów kluczowych), porównują nowe wymagania z istniejącymi i automatycznie rozpoznają zmiany między rewizjami. W przypadku wymagań przekrojowych lub nowych sformułowań (np. napęd wodorowy, FRMCS jako następca GSM-R) trafność wyraźnie spada.

Według Loopio 68% zespołów ofertowych we wszystkich branżach korzysta już z generatywnej AI, co oznacza podwojenie w porównaniu z 34% w 2023 r. 70% osób korzystających z AI robi to co najmniej raz w tygodniu. W branży kolejowej ta zmiana dopiero się zaczyna, ale pierwsze zintegrowane rozwiązania (Polarion AI, DRIM, Tendric) pokazują kierunek rozwoju.

Przykład: Melbourne Metro Tunnel Project

Melbourne Metro Tunnel Project to jeden z największych projektów infrastrukturalnych w Australii: nowy podziemny korytarz kolejowy dla ponad 500 000 dodatkowych pasażerów tygodniowo, o wartości 11 mld AUD. Rail Projects Victoria (RPV) stanęło przed zadaniem koordynacji tysięcy wymagań w wielu pakietach prac i między setkami zaangażowanych inżynierów z różnych organizacji.

RPV wybrało IBM Engineering Requirements Management DOORS Next jako rozwiązanie SaaS. Rezultat: centralne środowisko współpracy wspierane bezpieczeństwem jako "single source of truth", w którym wymaganiami można było zarządzać w czasie rzeczywistym i selektywnie udostępniać je każdej organizacji, zgodnie z jej obszarami funkcjonalnymi w projekcie. Integracja Hazard Logs i rejestrów interfejsów zapewniła prawidłowe przypisanie wymagań właściwym stronom.

Na podstawie tych doświadczeń RPV opracowuje obecnie ustandaryzowany framework zarządzania wymaganiami, który ma zostać przeniesiony na kolejne projekty (Regional Rail Revival, Melbourne Airport Rail).

Podsumowanie

Routing ekspertów jest niewidocznym wąskim gardłem przygotowywania ofert w branży kolejowej. Wyzwanie nie polega wyłącznie na technologii, lecz na połączeniu wolumenu (setki do tysięcy wymagań), złożoności (dziesiątki specjalizacji, normy od TSI przez CENELEC po ISO 22163) i presji czasu (terminy złożenia ofert wynoszące kilka tygodni).

Dobry system routingu, oparty na tabelach lub wspierany narzędziami, musi zapewniać cztery rzeczy: szybki wstępny podział na podstawie stabilnej taksonomii (kategorie LH, EN 15380), przejrzyste śledzenie statusu w czasie rzeczywistym, dokumentację umożliwiającą identyfikowalność EN 50126 oraz równoważenie obciążenia wszystkich zaangażowanych ekspertów.

IBM DOORS i Siemens Polarion obsługują segment enterprise, wyspecjalizowane platformy, takie jak Tendric segment średnich firm, a rozwiązania wspierane przez AI początkową alokację. Ważniejsza od wyboru narzędzia jest jednak stojąca za nim dyscyplina: macierze RACI, przypisania kompetencji i konsekwentne śledzenie. Największym ryzykiem nie jest bowiem niewłaściwe narzędzie, lecz wymagania nieprzypisane żadnemu ekspertowi lub takie, których stanu opracowania nikt nie zna.