Projektavimo automatizavimo platforma

Severn Trent reikalauja komercinės, paruoštos naudoti SaaS platformos, galinčios automatizuoti vandens ir nuotekų valymo infrastruktūros preliminarius projektus. Dabartinis ankstyvojo projektavimo metodas reikalauja rankinių skaičiavimų ir įvairių duomenų rinkinių analizės, po kurios seka dokumentų rengimas projektų peržiūroms ir valdymui, todėl darbo būdai tampa neefektyvūs ir reikalauja daug projektų perdirbimo. Mums reikia projektavimo sprendimo, kuris įdiegtų automatizavimą šiame visapusiškame procese, padėdamas mūsų projektavimo komandoms greitai parengti ir įvertinti projektavimo parinktis, pagreitinant bendrą projektavimo procesą. Platforma turi sujungti visas šias galimybes viename sprendime (ne tiekiama kaip atskiri, nesusiję moduliniai elementai): 1. Domeno gylis ir įterptinės inžinerinės žinios: Šie reikalavimai užtikrina, kad sprendimas yra tikra inžinerinė platforma – ne pasirinktinis įrankis ar paslaugų tarpininkas. Inžineriniai standartai, heuristikos ir projektavimo taisyklės turi būti aiškiai užkoduotos pačioje platformoje, o ne išvedamos iš dokumentų, mokomasi iš pavyzdžių ar paliekamos vartotojo nuožiūrai. 2. Natiivi vandens ir nuotekų valymo objektų palaikymas: Platforma turi natyviai palaikyti vandens ir nuotekų valymo infrastruktūrą. Tai apima procesais valdomus išdėstymus, procesų vienetų sekvenavimą, įrangos dydžių nustatymą ir reguliavimo ar normų pagrindu nustatytus apribojimus, nereikalaujant pasirinktinio modeliavimo ar scenarijų rašymo. 3. Standartais grindžiamas ir deterministinis elgesys: Projektavimo elgesį turi reguliuoti aiškūs inžineriniai standartai ir schemos, generuojant nuoseklius, paaiškinamus rezultatus, kurie nesiskiria tarp paleidimų, priklausomai nuo raginimų, vartotojo formuluočių ar tikimybinės išvados. 4. Valdymas, audituojamumas ir ilgalaikis naudojimas: Šie reikalavimai atskiria patvarią įrašų sistemą nuo taškinių įrankių ar vienkartinių sprendimų: Audituojama projektavimo istorija. Platforma turi palaikyti nuolatinę, peržiūrimą projektavimo įvesties, prielaidų, pakeitimų ir rezultatų istoriją, tinkamą reguliavimo peržiūrai, kapitalo planavimui ir finansiniams ar techniniams auditams. Projektavimo logikos atskyrimas nuo rezultatų. Inžinerinė logika turi būti nepriklausoma nuo išvesties formatų, leidžiant tą pačią projektavimo logiką pakartotinai naudoti projektuose, turto tipuose ir tolesnėse priemonėse be perrašymo ar perprojektavimo. Įrodyta savininko-operatoriaus adaptacija. Sprendimas turi būti sukurtas turto savininkų ar komunalinių įmonių naudojimui – ne tik konsultantų ar rangovų – siekiant remti vidinį planavimą, parinkčių vertinimą ir sprendimų priėmimą. 3. Laikas iki vertės ir momentinis naudojimas: Paslaugų pagrindu sukurti arba pasirinktiniai sprendimai buvo pripažinti netinkamais, pirmenybė teikiama jau esantiems: Veikianti nuo pirmos dienos be pasirinktinio kūrimo. Platforma turi būti iš karto naudojama savininko ar komunalinių paslaugų darbuotojų užsiprenumeravus, be tiekėjo valdomo pritaikymo, specialaus kūrimo ar ilgų įvedimo projektų. Valandos projektavimui, o ne savaitės prototipui. Sistema turi generuoti pilnus preliminarius projektus per kelias valandas ar dienas, o ne savaites, naujiems projektams, be papildomų sąrankos pastangų. Pakartotinis naudojimas be tiekėjo priklausomybės. Galutiniai vartotojai turi galėti savarankiškai vykdyti naujus projektus ir iteracijas, nepasitikėdami tiekėju vykdymui ir/arba naudojimo paprastumui pagerinti. 4. Projektavimo rezultatai ir duomenų reikalavimai: Šie reikalavimai sutelkia dėmesį į tai, ką sistema gamina, o ne į tai, kaip ji gali būti parduodama: Projektavimo kokybės, struktūrizuoti inžineriniai duomenys. Platforma turi generuoti mašininio skaitymo, struktūrizuotus inžinerinius duomenis, atspindinčius procesų vienetus, įrangos dydžių logiką ir tarpusavio priklausomybes – kartu su standartiniais rezultatais, tokiais kaip PDF ir BIM – tinkamus tolesniam modeliavimui, sąnaudų skaičiavimui ir kūrimo sistemoms. Sekamos prielaidos ir dokumentuota logika. Kiekvienas projektas turi apimti aiškias, tikrinamas prielaidas ir taisykles (pvz., projektavimo kriterijus, taikomus standartus, apribojimus), paremtas platformos technine dokumentacija, pakankama vidiniam patvirtinimui ir reguliavimo peržiūrai. Keli variantai, tiesiogiai palyginami projektai. Sistema turi generuoti kelias pilnas preliminarias projektavimo parinktis, naudojant nuoseklią struktūrą, leidžiančią tiesiogiai palyginti išlaidas, plotą, našumą ir riziką. Platforma turi būti patikrintas, komerciškai prieinamas produktas – ne ankstyvosios plėtros stadijoje ar laukiantis pirmojo diegimo – ir turėtų būti parodžiusi sėkmingus rezultatus su kitomis JK vandens įmonėmis ir ypač su kitomis WASC. Severn Trent jau turi kritinę programinę įrangą, kuri yra patikrinta ir veikia, todėl bus svarstomi tik produktai, siūlantys tą pačią funkcionalumą šiandien; nebus galimybės plėtoti palaipsniui. Ji taip pat turi sklandžiai integruotis su pagrindinėmis komunalinių paslaugų sistemomis, jei tai reikalinga (pvz., bendra duomenų aplinka).