Platforma do Automatyzacji Projektowania

Severn Trent wymaga komercyjnej, gotowej platformy SaaS, która jest w stanie zautomatyzować wstępne projektowanie infrastruktury uzdatniania wody i ścieków. Obecne podejście do projektowania na wczesnym etapie wymaga ręcznych obliczeń i analizy różnych zbiorów danych, a następnie produkcji dokumentów do przeglądów projektowych i zarządzania, co prowadzi do nieefektywnych sposobów pracy i znacznej ilości poprawek projektowych. Wymagamy rozwiązania projektowego, które wprowadzi automatyzację do tego kompleksowego procesu, pomagając naszym zespołom projektowym szybko tworzyć i oceniać opcje projektowe, przyspieszając cały proces projektowania. Platforma musi łączyć wszystkie poniższe możliwości w jednym rozwiązaniu (nie dostarczane jako oddzielne, rozłączone moduły): 1. Głębokość dziedzinowa i wbudowana wiedza inżynierska: Te wymagania zapewniają, że rozwiązanie jest prawdziwą platformą inżynierską – nie niestandardowym narzędziem ani pośrednikiem usług. Standardy inżynierskie, heurystyki i zasady projektowania muszą być jawnie zakodowane w samej platformie, a nie wywnioskowane z dokumentów, nauczone z przykładów lub pozostawione do oceny użytkownika. 2. Natywne wsparcie dla obiektów uzdatniania wody i ścieków: Platforma musi natywnie obsługiwać infrastrukturę uzdatniania wody i ścieków. Obejmuje to układy procesowe, sekwencjonowanie procesów jednostkowych, wymiarowanie sprzętu oraz ograniczenia wynikające z przepisów lub norm, bez konieczności niestandardowego modelowania lub skryptowania. 3. Zachowanie oparte na standardach i deterministyczne: Zachowanie projektowe musi być zgodne z jasnymi standardami i schematami inżynierskimi, dając spójne, wyjaśnialne wyniki, które nie różnią się między kolejnymi uruchomieniami w zależności od podpowiedzi, sformułowań użytkownika lub wnioskowania probabilistycznego. 4. Zarządzanie, audytowalność i długoterminowe użytkowanie Te wymagania odróżniają trwały system rejestrów od narzędzi punktowych lub rozwiązań jednorazowych: Audytowalna historia projektowa Platforma musi utrzymywać trwałą, możliwą do przeglądu historię danych wejściowych projektu, założeń, zmian i wyników, odpowiednią do przeglądu regulacyjnego, planowania kapitałowego oraz audytów finansowych lub technicznych. Separacja logiki projektowej od wyników Logika inżynierska musi być niezależna od formatów wyjściowych, co pozwala na ponowne wykorzystanie tej samej logiki projektowej w różnych projektach, typach zasobów i narzędziach niższego poziomu bez ponownego tworzenia lub przeprojektowywania. Sprawdzone przyjęcie przez właścicieli-operatorów Rozwiązanie musi być zaprojektowane do użytku przez właścicieli zasobów lub przedsiębiorstwa użyteczności publicznej – nie tylko przez konsultantów lub wykonawców – w celu wspierania planowania wewnętrznego, oceny opcji i podejmowania decyzji. 3. Czas do uzyskania wartości i natychmiastowa użyteczność Rozwiązania oparte na usługach lub niestandardowe zostały uznane za nieodpowiednie, preferowane są istniejące: Gotowość do pracy od pierwszego dnia bez niestandardowego rozwoju Platforma musi być natychmiast użyteczna po subskrypcji przez personel właściciela lub przedsiębiorstwa użyteczności publicznej, bez dostosowywania przez dostawcę, niestandardowego rozwoju lub długoterminowych projektów wdrożeniowych. Godziny do projektu, a nie tygodnie do prototypu System musi generować kompletne projekty wstępne w ciągu godzin lub dni, a nie tygodni, dla nowych projektów bez dodatkowego nakładu pracy na konfigurację. Powtarzalne użytkowanie bez zależności od dostawcy Użytkownicy końcowi muszą być w stanie samodzielnie realizować nowe projekty i iteracje, bez polegania na dostawcy w zakresie realizacji i/lub poprawy użyteczności. 4. Wyniki projektowe i wymagania dotyczące danych Te wymagania koncentrują się na tym, co system produkuje, a nie na tym, jak może być marketingowany: Dane inżynierskie o jakości projektowej, ustrukturyzowane Platforma musi generować czytelne dla maszyn, ustrukturyzowane dane inżynierskie reprezentujące jednostki procesowe, logikę wymiarowania sprzętu i zależności – wraz ze standardowymi wynikami, takimi jak PDF i BIM – odpowiednie dla systemów modelowania, kosztorysowania i autoryzacji niższego poziomu. Identyfikowalne założenia i udokumentowana logika Każdy projekt musi zawierać jasne, możliwe do sprawdzenia założenia i zasady (np. kryteria projektowe, zastosowane standardy, ograniczenia), poparte dokumentacją techniczną w ramach platformy, wystarczającą do wewnętrznej walidacji i przeglądu regulacyjnego. Projekty wieloopcyjne, bezpośrednio porównywalne System musi generować wiele kompletnych wstępnych opcji projektowych, używając spójnej struktury, która umożliwia bezpośrednie porównanie kosztów, zasięgu, wydajności i ryzyka. Platforma musi być sprawdzonym, komercyjnie dostępnym produktem – nie w fazie wczesnego rozwoju ani oczekującym na pierwsze wdrożenie – i powinna wykazać się udanymi wynikami z innymi brytyjskimi przedsiębiorstwami wodociągowymi, a zwłaszcza z innymi WASC. Severn Trent posiada już krytyczne oprogramowanie, które zostało sprawdzone i wdrożone, dlatego będą rozważane tylko produkty oferujące taką samą funkcjonalność dzisiaj; nie będzie możliwości rozwoju etapowego. Musi również bezproblemowo integrować się z kluczowymi systemami użyteczności publicznej tam, gdzie jest to wymagane (np. Wspólne Środowisko Danych).