Transcript ITS

ITS: Standarty, Systemy i Usługi
Doświadczenia z Europy Zachodniej
Andy Graham, White Willow Consulting
David Kelly, Blue Cedar
Włodek Laskowski, Nomad Fund
Marian Ohl, Provent Polska
Sesja... Nr sesji...
Presenters
 Marian Ohl
 Główny Dyrektor d/s ITS
Provent Polska, odpowiedzialny
za całość działalności ITS firmy
Provent Polska
 Poprzednio w Polimexie
Mostostal był Dyrektorem
Wydziały Budowy Dróg,
pracowł też w Przedsiębiorstwie
Robót Inżynieryjnych S. A., a w
Holdingu Huta Ostrowiec był
Wice-Prezesem i Dyrektorem
Finansowym.
 Włodzimierz Laskowski
 Współzałożyciel i Partner
funduszu Venture Capital
Nomad Fund, do którego udało
mu się pozyskać rząd Szwajcarii
(50% udziałowiec).
 Prowadził butik inwestycyjny:
fundraising i sprzedaży firm.
 Poprzednio w GE Capital był
dyrektorem d/s Integracji, jako
członek elitarnego programu
GLDP pracował w USA.
Pracował w bankach
inwestycyjnych w Londynie (
Merrill Lynch, HSBC)
 Absolwent prestiżowej London
School of Economics
2
Prezenterzy
 David Kelly
 Ponad 25 lat doświadczeń w
projektowaniu i zarządzaniu
dużych centr kontroli
drogowych, pobierania opłat,
tunelów i systemów
komunikacyjnych, a także w
wdrażaniu systmów WIM i
stacji ważenia, stacji zasilania,
komunikacji i światłowodów.
 Przez ostatnie 7 lat nad
systemami opłat na
autostradach A2 & A4, ViaToll.
 pracował na całym świecie, w
tym w Brazylii, Tajlandii,
Południowej Afryce, Izraelu i w
większości krajów Europy.
 Andy Graham
 Koncentruje na projektach ITS
związanach z wykorzystaniem
danym z GPS, z opłatami
drogowymi i ich egzekucją i
innymi w Wielkiej Brytanii,
Japonii, Australii, Francji,
Południowej Afryce, Kanadzie,
Irlandi i w USA. Obecnie
pracuje nad wdrożeniem
projektów ITS o bardzo dużej
skali i nad wykorzystaniem tzw.
„big data” do rozwiązywania
problemów ITS w różnych
sytuacjach drogowych.
 Były dyrektor d/s ITS w
oddziale brytyjskim korporacji
AECOM, odpowiedzialny za
wdrażanie centralnych
systemów ITS (np. RDS-TMC).
3
Nasze obserwacje na przestrzeni 20 lat ...
 Politycy i samorządy chcą wdrażać systemy ITS
 Aby oferować lepsze usługi (i mieć to samo co inni))
 Aby oszczędzać fundusze.
 Aby zbierać datkowe przychody (parkowanie, kary..)
 Ale często myślą że “S” znaczy “system”
 Technologia jest z góry wybrana i zakontraktowana
 Nie daje oczekiwanych rezultatów
 Model jest przystosowany do oczekiwań samorządów
 Finansowanie i własność systemów ITS
 Trend odchodzenia od własności do modelu usługowego.
4
A co więcej….
 Oczekują najniższego kosztu ..
 Niska cena wywoławcza inwestycji kapitałowych
 Koszty operacyjne będą problemem później ...
 Chcą kontrolować wybór technologii..
 Kwestia inegracji z innymi systemami i z ludźmi
 Branie całego ryzyka wyboru na siebie
 Często małe doświadczenie w systemach ITS
 Chcą rozwiązać problemy bieżace i pilne (ale czy
planują i myślą o przyszłości też?)
5
Wspieranie działań w przyszłości
 Łatwe dodanie aplikacji i serwisów mobilnych ?
 Jest możliwość dodania tego typu usług niskim (a wręcz
prawie zerowym) kosztem, ale ...
 Wspólne działanie z miastami/obszarami obok w
celu redukcji kosztów?
 Osobne wyspy czy jeden kraj? ….
 Kierowcy doswiadczają granice pomiędzy różnymi
systemami ITS?
 Kto jest właścicielem drogi? Cóż mnie to obchodzi…
 Próba odświeżenia/unowocześnienia po 5 latach
 Zależnośc od dostawców, skazani na wyłączność…
 Takie rzeczy są często pomijane na etapie
projektowania systemu ITS?
 Potencjał integracji w przyszłości jest kluczowy…
6
Taka sytuacja ma miejsce wszędzie...
 To nie są obserwacje tylko jednego kraju ....
 Tylko lokalnych samorządów i miast w którymś
momencie ich ewolucji ITS-owej
 Wielka Brytania, Irlandia, Holandia, USA…
 Wszystkie przechodziły podobn doświadczenia
 Ta są cenne doświadczenia z których mozemy
korzystać ...
 I to jest tematem naszego referatu …
7
Systemy szyte na miarę (dedykowane)
 Systemy które zostały zrobione tylko dla jednego
miasta mają koszty o wiele większe do:
 Ustalenia specyfikacji i parametrów, zaprojektowania,
wybudowania i utrzymania
 Zarządzania (potrzeba ekspertów w danym mieście)
 Odswiężenia / unowocześnienia w przyszłości (tzw.
problemy „legacy”, pozostałości z przeszłości)
 Systemy szyte na miarę mają swoje ryzyka ...
 Dostawca bankrutuje, trzeba pisać nowy kod
komputerowy…
 Nie spełniają oczekiwań (politicy mają z tym duży
problem)
8
Gotowe Vs szyte na miarę (dedykowane) systemy
 Podobnie jak z kupowaniem garnituru: można go
uszyć na miarę, lub kupić w sklepie dany rozmiar
 Generalnie mówiąc gotowe, komercyjne
oprogramowanie IT jest obecnie powszechnie
akceptowane
 Konfiguracja możliwa dla lokalnych potrzeb, nie potrzeba
dedykowanych systemów
 Redukcja kosztów
 Ale wymaga podejścia zgodnie z standartami
 Lepsze gotowe!
 Lepsze dedykowane!
9
Standarty są dookoła nas ...
 GSM
 Twój telefon po prostu „działa” na całym świecie
 HTML – standart Internetu
 Rozmiary ubrań (no prawie...)
 Niektóre standarty są otwarte (jak Internet)
 Niektóre są zamknięte...
10
„Standarty” dla ITS
 Poprzedni prelegenci mówili o FRAME
 To koncentruje się na architecturze w stopniu
szczegółowym
 Standarty de jure
 formalne
 “Standarty” de facto
 nieformalne specyfikacje
 Dostosowane zarówno do gotowych jak i
dedykowanych systemów ITS
11
Korzyści standartów
 Pozwalają producentom na konstrukcję
pojedyńczych wersji danego produktu
 Pozwalają zamawiającemu na specyfikację poziomu
wydajności i możliwości rozwoju dla ich miast
 System jest tylko “czarną skrzynką” którą można zastąpić
 Pozwala na architektorę typu “plug and play”
(„włącz i działa”)
 Redukuje koszty
 Tak samo jakby się kupowało inny system IT...
12
Wybrane przykłady z Europy Zachodniej
 Różne podejścia w róznych krajach
 Ale mają taki sam efekt i skutek
 Gotowe systemy ITS
 Istnieją również inne
13
OCIT/ OTS
 OCIT - Open Communication Interface for Traffic
Control Systems (Interfejs Otwartej Komunikacji dla
Systemów Kontroli Ruchem Drogowym)
 OTS - Open Traffic Systems (Otwarte Systemy
Ruchu Drogowego)
 Standarty używane do integracji systemów
zarządzania ruchem drogowym w niemieckich,
austriackich i szwajcarskich miadtach.
 Zostały ustanowione w 1999
 Dobrze zdefiniowane standarty i specyfikacje
 Standarty de jure
14
UTMC (Urban Traffic Management and Control System)
 Zarządzanie i Kontrola Miejskiego Ruchu
 De facto standart
 Zebranie i dystrybucja dobrych praktyk pomiędzy
zarządców dróg i autostrad w Wielkiej Brytanii od
1997r.
 Przedtem systemy ITS w Wielkiej Brytanii były
„szyte na miarę” i władze/zarządcy dróg byli
uzależnieni od oryginalnych dostawców systemów
ITS w zakresie eksploatacji, ulepszeń i zamian.
 Nowi dostawcy wchodzą na rynek – redukcja
kosztów
15
UTMC jako specyfikacja
 UTMC jest otwartą platformą która pozwala na
kontakt pomiędzy różnymi systemami ITS
 Zaprojektowany przez użytkowników i dostawców
 Możliwość dodania dodatkowych funkcjonalności
kiedy znajdzie się na to finansowanie lub będę
wymagane prawnie
 Np. od monitorowania jakości powietrza do zarządzania
parkingiem
 Eksport danych do innych systemów
16
Przykład elastyczności UTMC
Weymouth
(small seaside town, population 50K)
A perhaps sleepy UK port town with a UTMC system – why would it need to
expand to a whole host of new systems and services – and traffic demand ?
17
Dorset – miejsca regat jachowych w 2012r
To nie transport był głównym tematem – to medale wygrane w regatach tym były
18
UTMC pomogło Zofii Klepackiej ?
19
Usługi ITS a nie systemy...
 Kierunek rozwoju w Europie Zachodniej
 Po co ponosić koszty zakupu sprzętu i oprogramowania?
 Nie kupuj systemu ITS na własnoś – miej to jako usługę
 Systemy IT rządowe migrują do “chmury”
 To dostawca usług jest właścicielem systemu ITS
(sprzętu i oprogramowania)
 Zamawiający płaci tylko za usługi które są dawane
 Płatność zależna od oczekiwanych wskaźników
(KPIs / SLAs – Service Level Agreements)
 Pobór należności i płatności
 Gwarancja dostępności i wydajności systemów ITS
20
W kontrakcie usługowym …...
 To zleceniodawca decyduje o tym jaki poziom ryzyka
spada na dostawcę usług
 Dostawca korzysta z zalet ekonomii skali
 Na przykład, wystarczy jedno centrum danych dla 6
klientów, a nie jedno dla każdego z nich osobno
 Usługi mogą być elastyczne (jeśli używają
standartów)
 Możliwość łatwego dodawania innych systemów ITS
 Płatność za ITS jako za usługę nie wymaga ponoszenia
dużych kosztów z góry
 Dostawca (usług) ma mocną motywację aby
dostarczać systemy gwarantujące wysoki poziom,
czego nie mozna powiedzieć o dostawcy sprzętu.
21
Umowy na usługi ITS – doświadczenia do tej pory
 Dostawca jest motywowany wynagrodzeniem, które
z kolei zależy od poziomu świadczonych usług.
 Wygrana dla obu stron!
 Nie próbuj robić wszystkiego od razu
 Wypracować prosty model i tylko kontrolować zmiany
 Łatwe do zmiarzenia wyniki
 Umowy muszą być elastyczne
 Wykorzystuj najlepszy praktyki z innych źródeł
 Realistyczna długość trwania umowy
 5-7 lat (a nie np. 30 lat)
22
Podsumowanie
 ITS nie jest już kupowaniem pojedyńczego systemu
zaprojektowanego tylko na dzisiejsze potrzeby i to po
najniższych kosztach.
 Rozwiązanie to gotowy system który będzie
odpowiadał potrzebom w przyszłości (zarówno
lokalnym, krajowym jak i globalnym) i który jest
oparty o standarty.
 Skoncentowanie się na wynikach które chce się
osiągnąć, a nie na technologii
 Redukcja ryzyka poprzez umowy na ITS jako usługi
 Co pozwala na nowe modele finasowania ITSu
 lub pozwala na to żeby ITS się samofinansował ............
ale to już zupełnie nowy temat
23
Kontakt – więcej informacji:
E-mail:
[email protected]
[email protected]