Podstawowe błędy popełniane przy wdrażaniu systemów komputerowych.

Ilość upadających projektów.

W dobie transformacji cyfrowej i ciągłego niedoboru rąk do pracy automatyzacja zadań powtarzalnych oraz gromadzenie danych stały się nie tylko trendem ale też koniecznością. Dlatego też coraz więcej organizacji wdraża systemy komputerowe, które w pierwszym rzędzie mają odciążyć pracowników od powtarzalnych zadań. Mają także zbierać dane, które w następnym kroku będą wykorzystane do analizy aktualnej sytuacji, poszukiwania błędów w historii oraz przewidywaniu przyszłości. Niestety duża część projektów, zarówno tych małych, jak i tych dużych kończy się niepowodzeniem, czego skutkiem są poniesione koszty, a końcowy efekt jest niezadowalający. Wdrożenie systemu w firmie, jak każda ze zmian, u większości ludzi wywołuje strach i opór. Istotne jest, aby poza technicznymi aspektami systemu pamiętać również o tych ludzkich. Poniżej podaję kilka błędów, jakie zaobserwowałem podczas mojej kariery zawodowej. Są to błędy,  które znacząco wpłynęły na efekt końcowy.

Brak dobrego przygotowania do projektu.

Na początku był chaos, a potem ktoś postanowił wdrożyć system (najczęściej ERP). Tak może się zaczynać opis większości projektów, które nie zakończyły się sukcesem. Często wielu menedżerów uważa, że wdrożenie systemy zaprowadzi porządek w ich organizacji. Niestety system komputerowy jest tylko narzędziem i można w nim zaimplementować niemalże każdy proces biznesowy niezależnie czy jest wydajny, czy nie. Dlatego przed przystąpieniem do wdrażania systemu należy przygotować ogólną analizę biznesową całej organizacji oraz szczegółową dla obszaru który zmierzamy automatyzować. Analiza biznesowa pomoże w znalezieniu obszarów, które są niewydajne, lub są wąskimi gardłami oraz pomoże w wyeliminowaniu procesów, które są nieopłacalne. Musimy zdać sobie sprawę z tego, że błędy popełnione na poziomie analizy biznesowej będą się ciągły przez cały projekt. Dlatego w przypadku wykrycia takich błędów warto wykonać krok wstecz w celu ich wyeliminowania, niż uparcie dążyć do zachowania terminów i budżetów.  

Brak zapewnienia zasobów.

Na etapie analizy należy również zaprojektować, jak wdrażane narzędzie będzie się komunikować z już istniejącymi: jakie dane będą wymieniane między systemami i który względem którego będzie nadrzędny.

Systemy same się nie wdrażają, a do wdrożenia systemu wymagane jest zaangażowanie wielu pracowników w organizacji – dział IT, kierownicy i przełożeni wszystkich szczebli, użytkownicy końcowi. Na początku należy przygotować analizę biznesową oraz opis funkcjonalności. Należy wykonać instalacje oraz opracować system tworzenia kopii zapasowych oraz monitorowania rozwiązania. Konieczne jest przeprowadzanie szkoleń. Pracownicy muszą mieć czas na wdrożenie się w nowe rozwiązanie, do czego będą potrzebować wsparcia konsultantów. To wszystko wymaga czasu i powinno być zaplanowane w planach każdego zaangażowanego działu. Często zarząd/przełożeni uważają, że może się to wydarzyć w tak zwanym międzyczasie bądź potrzeba na to tak mało czasu, że można tego nie planować. W większości organizacji, z którymi miałem kontakt, tak planowano pracę swoim pracownikom, aby mieli wypełnione całe 8 godzin. Dołożenie kolejnego obowiązku powodowało, że musieli oni pracować po godzinach bądź musieli zrezygnować z jakiś innych zadań. Często destabilizowało to aktualną sytuację w firmie, za co obarczane było wdrożnenie nowego systemu. To z kolei powodowało opór ze strony przełożonych. Dlatego konieczne jest zarezerwowanie niezbędnych zasobów przed przystąpieniem do wdrożenia. Wdrożenie systemu jest tymczasową sytuacja i zatrudnianie nowych pracowników jest bezcelowe. Lepszym rozwiązaniem będzie zatrudnienie firmy zewnętrznej (np. do przygotowania analizy biznesowej), bądź posiłkowanie się wynajmem pracowników wspomagających pracę np działu IT. Warto też zaplanować wdrożenie w tak zwanym sezonie ogórkowy dla branży. Łatwiej wówczas będzie znaleźć czas na wyszkolenie użytkowników końcowych i wdrożenie ich w nowe narzędzie.

Zbyt duży zakres projektu.

Zbyt duży zakres wdrażanego systemu niesie za sobą dwa zagrożenia. Pierwszy to potrzeba zaangażowania dużej ilości pracowników firmy. Taka sytuacja może zdestabilizować codzienną pracę organizacji, a co za tym idzie, może spowodować zachwianie płynności finansowej. Drugi  problem pojawia się podczas wdrażania systemu w zbyt dużym zakresie. Doprowadzamy wówczas do sytuacji, w której czas potrzebny na przygotowanie rozwiązania jest na tyle długi, że po zakończeniu wdrożenia rozwiązanie jest już nieprzystające do realiów rynkowych oraz nie pasuje do organizacji. Cyfryzacja małych obszarów organizacji skraca czas liczony od podjęcia decyzji o wdrożeniu, do wdrożenia produkcyjnego rozwiązania. Ryzyko jakie niesie ze sobą jest małe ze względu  niewielki obszar jakiego dotyka. Oczywiście taki sposób wdrożenia wymaga integracji nowego rozwiązania ze starym sposobem prowadzenia procesów w organizacji. Generuje to koszty, jednak koszty poniesione w przypadku nieudanego wdrożenia rozwiązania w całej organizacji mogą znacznie przerastać koszty stopniowego wdrażania.

Ciągłe zmiany w systemie.  

Tworzenie oprogramowania zgodnie ze specyfikacją jest równie łatwe jak chodzenie po wodzie. Łatwe, pod warunkiem że jedno i drugie jest zamrożone. Niestety bardzo rzadko zdarza się, aby założenia początkowe były dotrzymane do końca projektu. Często jest to podyktowane słabym przygotowaniem do projektu przez zamawiającego. W trakcie projektu okazuje się, że poza głównym procesem biznesowym jest dużo pobocznych, realizujących marginalny odsetek przypadków, które powinny być wyeliminowane/zewidencjonowane na   poziomie analizy biznesowej. Każdy wyłom w procesie narusza stabilność logiki biznesowej, co powoduje błędy i zagrożenie dla jakości danych. W dobie metodyk zwinnych lepszym podejściem do realizacji projektów (zwłaszcza średnich i dużych) jest realizowanie ich w procesie iteracyjnym, co ułatwia szybsze wykrycie nieobsłużonych przypadków.

Brak dobrych testów.

Niektórzy twierdzą, że nie ma złych systemów, tylko są źlę przetestowane. Jest w tym dużo racji. Często osoby odpowiedzialne za testowanie rozwiązania po stronie zamawiającego dostają ten obowiązek, jako dodatkowy do swojej pracy bieżącej i po prostu z braku czasu wykonują go niedostatecznie dobrze. System powinien być testowany również przez reprezentacyjnych użytkowników końcowych, gdyż to oni najlepiej wiedzą, jak będą używać systemu i poza wykryciem błędów, są w stanie zasugerować zmiany ułatwiające pracę. Często na etapie wdrażania usprawnień w systemie, popełniany jest istotny błąd: testowana jest zamówiona, wąska funkcjonalność, a nie cały proces. Niestety oprogramowanie jest produktem, w którym wprowadzenie jednej małej  zmiany może wywołać problem w zupełnie innym miejscu. Dlatego po dostarczeniu nowej wersji przez dostawcę konieczne jest przetestowanie podstawowych procesów od początku do końca np: od założenia zamówienia do wysłania faktury.

Przerzucenie całej odpowiedzialności za wdrożenie na dostawcę.

Częstym błędem przy wdrażaniu aplikacji jest przerzucanie całej odpowiedzialności za powodzenie projektu na dostawcę. Dostawca, pomimo szczerych chęci ma ograniczone możliwości do motywowania i egzekwowania wyników po stronie klienta.  Bez takiej współpracy nie ma możliwości na to, aby projekt się powiódł. Firmy podchodzą do wdrożenia, jak do zakupu samochodu. Mniej więcej tak to wygląda, gdy kupujemy rozwiązanie “pudełkowe” lub w modelu SaaS. Kiedy jest konieczne dopasowanie rozwiązania do aktualnych systemów organizacji, bądź jest to system wykonywany na zamówienie, konieczna jest współpraca pracowników po stronie zamawiającego. Należy też pamiętać, że po etapie wdrożenia to pracownicy firmy powinni być w stanie utrzymywać system w podstawowym zakresie. Może się zdażyć np., że firma dostarczająca rozwiązanie upadnie, a czas potrzebny na przejęcie utrzymania przez inna firmę może być na tyle duży (może się również zdarzyć, że żadna firma nie będzie chciał się podjąć takiego utrzymania), że konieczne będzie utrzymywanie systemu przez pracowników wewnętrznych. Dlatego warto wyznaczyć ludzi, którzy będą brali aktywny udział we wdrożeniu rozwiązania i będą stanowili integralną część zespołu stworzonego razem z pracownikami partnera/dostawcy. Im więcej wiedzy firma przejmie w trakcie wdrożenia, tym bardziej efektywnie będzie w stanie wykorzystywać system, a koszty utrzymania będą niższe.  

Brak zaangażowania ze strony zespołu, a czasem wręcz opór.

Nowy system w organizacji jak każda zmiana wywołuje u większości ludzi strach i opór. Strach z reguły dotyczy tego, czy sobie poradzą z nowym narzędziem, a nawet tego, czy pracodawca ich nie zwolni w związku z przejęciem części obowiązków przez system. To jest sprawa czysto psychologiczna i nie zamierzam się o niej tu wypowiadać. Jest to sprawa kluczowa i często zapomniana w sytuacji wdrażania aplikacji, która może doprowadzić do porażki. O wdrażaniu zmian jest napisane kilka książek, a  o podstawach można poczytać np tu.

Wybór najtańszego rozwiązania a nie najlepiej pasującego do  wymagania.

W Polsce ciągle przy wyborze większości rzeczy, czy to w życiu prywatnym, czy służbowym, dominujące znaczenie ma cena. Często ludzie popełniają błąd wybierania najtańszego rozwiązania, nie patrząc na inne czynniki. Podczas wyboru produktu powinniśmy sobie uzmysłowić, że projekty które są tanie, często nie są priorytetowe dla dostawcy, wręcz leżą w marginalnym obszarze jego zainteresowania. Tani projekt oznacza też, że dostawca nie oddelegowuje do niego najlepszych ludzi, gdyż dobrzy fachowcy są drodzy, a bilans na końcu projektu musi się zgadzać. Cena zawsze miała i będzie miała duże znaczenie przy wyborze rozwiązania, jednak poza ceną należy również uwzględnić inne aspekty takie, jak czas potrzebny dostawcy na dostarczenie rozwiązania. Im wcześniej rozwiązanie będzie gotowe do użytku (chociażby w niepełnym zakresie), tym szybciej zacznie przynosić wymierne wartości. Należy również zwrócić uwagę na referencje firmy. Oczywiście nie wyklucza to sytuacji, w której najtańsze rozwiązanie będzie równie dobre, jak ich droższe odpowiedniki, ale wybór rozwiązania i partnera, który będzie je wdrażał nie powinno być podyktowane tylko i wyłącznie ceną.

Podsumowanie

Rzadko się zdarza, żeby powyższe błędy występowały pojedynczo. Najczęściej występują całymi stadami, gdyż jedne z nich pociągają za sobą pozostałe: brak zapewnienia zasobów powoduje, że rozwiązanie będzie źle przetestowane, a zespół po stronie zamawiającego nie będzie traktował wdrożenia priorytetowo. Bardzo ważne jest, żeby projekt i organizacja była właściwie przygotowana, wówczas większość prac idzie płynnie i zgodnie z planem, a efekt końcowy jest zadowalający. Poza całkowitym upadkiem projektu, może się również zdarzyć, że projekt zostanie wdrożony z kilkuletnim opóźnieniem. W dobie tak dynamicznych zmian może to spowodować, że tuż  po zakończeniu wdrożeń projekt będzie przestarzały, będzie wymagał zmian i dostosowania do realiów. W dobrze przygotowanej transformacji cyfrowej proces powinien wyglądać mniej więcej tak:

  • Analiza biznesowa
  • Zapewnienie zasobów i przygotowanie zespołu
  • Wybór rozwiązania
  • Wdrożenie testowe a potem produkcyjne
  • Ogłoszenie sukcesu

Często pierwsze dwa punkty są pomijane, a cały proces zaczyna się od wyboru rozwiązania, który pada na najtańsze rozwiązanie, co ostatni punkty przekształca w ogłoszenie klapy.

Kopia bezpieczeństwa to konieczność

Dlaczego powinieneś mieć kopię bezpieczeństwa.

Podobno ludzie dzielą się na dwie grupy: na tych chorych psychicznie i na tych nieprzebadanych,  ale dzielą się również na tych co robią kopię bezpieczeństwa, oraz na tych co takie kopię będą robić – tak przynajmniej mówi przysłowie.

W dobie świata cyfrowego posiadamy coraz więcej dóbr, które istnieją tylko w formie cyfrowej. Zarówno tych prywatnych, jak i tych firmowych: zdjęcia, filmy, ebooki, faktury, zamówienia, bazy kontrahentów itp. Niestety dane takie są podatne na “znikanie”, a ich odzyskanie z uszkodzonego nośnika nie jest tanie, czasem nawet nie jest możliwe.  Jak się zabezpieczyć przed sytuacją, w której stracimy nasze dane? Oczywiście należy robić kopię bezpieczeństwa. W tym wpisie skupię się głównie na danych biznesowych, ale zaadoptowanie opisanych technik do danych prywatnych nie powinno stanowić problemu.

Na początek cztery historie mrożące krew w żyłach (choć niektórych one pewnie zagotowały).

Historia pierwsza – e24cloud.com:

Był rok 2012. Wszyscy mówili o chmurze obliczeniowej, część ludzi nawet ją używała. A tu nagle grom z jasnego nieba. Jeden z dużych polskich dostawców usług chmury obliczeniowej, Beyond  i ich usługa e24cloud.com, zalicza wpadkę. Padają im macierze dyskowe, co wiąże się z utrata danych klientów. Okazuje się, że awaria jest naprawdę gruba, bo macierze dyskowe z kopią zapasową również uległy uszkodzeniu. Okazało się, że uszkodzeniu uległy jedynie kontrolery dysków RAID. Czyli dane są, tylko nie wiadomo jak je poskładać, tak żeby dały logiczny wynik. Cała historia była opisana na ich blogu, ale aktualnie wpis już nie jest osiągalny. Ostatecznie udało się odzyskać dane z dysków i klienci otrzymali je, jednak kosztowało to dużo pieniędzy zarówno operatora, jak i jego klientów, których usługi nie były dostępne przez dość długi czas. O całej sprawie można jeszcze poczytać w internecie np tu i tu.

Historia druga – Pixar:

Sytuacja ta wydarzyła się dość dawno temu i opisana jest w książce “Kreatywność S.A” autorstwa Ed Catmull i Amy Wallace. Ed Catmull jest założycielem firmy zajmującej się tworzeniem kreskówek – Pixar. Pewnie wszyscy słyszeli o takich hitach jak “Toy story”, “Potwroy i spółka” i wiele, wiel innych. Pewnie nigdy byśmy się nie dowiedzieli, że powstanie jednej z nich zawisło na włosku, gdyby nie powyższa książka.  Sytuacja wyglądała tak: komuś się “omsknął paluszek” i na komputerze, na którym były składowane materiały związane z jedną z produkcji poleciało: rm -r. Dla tych, co nie wiedzą, co to oznacza: w systemach Unixowych komenda taka powoduje permanentne usunięcie plików, czyli nie da się ich odzyskać z kosza. Pierwszą ich myślą po zaistniałej sytuacji było odzyskanie plików z kopii zapasowej. Niestety okazało się, że kopia zapasowa jest uszkodzona i nie jest możliwe odzyskanie plików. Przyparci do muru rozpaczliwie szukali rozwiązania sytuacji bez wyjścia. Okazało się, że jedna z pracownic, pracująca nad tym projektem często pracuje z domu i posiada kopię plików na swoim komputerze prywatnym. Gdyby nie ta “nielegalna” kopia, to film by nie powstał, a kilka lat pracy kilkudziesięciu ludzi poszłoby na marne generując milionowe koszty.

Historia trzecia – 2be.pl.

Sytuacja wydarzyła się początkiem roku 2016. Firma hostingowa 2be.pl zalicza wpadkę i padają im wszystkie usługi hostingowe. Firma tłumaczy się, że jest to spowodowane włamaniem na ich serwery. Okazuje się, że poza aktualnymi danymi firma straciła również kopie zapasowe – wszystko podobno zostało usunięte przez osoby, które włamały się na serwery. Po dość niejasnych tłumaczeniach ze strony samej firmy, jak i jej właściciela sytuacja się nie zmiania. Po kilku tygodniach od zdarzenia (taki okres nie działania  jest zabójcz dla większości przedsięwzięć internetowych) właściciel ogłasza, że sprzedaje/zamyka całą swoją działalność Adweb (poza hostingiem w ramach grupy były również inne firmy działające w obszarze internetu). Po tym posunięciu klienci zostali z niczym: bez danych, bez możliwości przeniesienia swoich domen na inne hostingi itd. Po roku od zdarzenia internet obiegła informacja, że były właściciel Adweb zmarł, przyczyną jego śmierci była choroba neurologiczna. Problemy firmy były po części podyktowane problemami zdrowotnymi.  Przykra sprawa, ale z punktu widzenia klientów nic to nie zmienia: praca ich życia, pot i łzy poszły na marne i muszą wszystko zaczynać od nowa.

Historia czwarta – z mojego życia zawodowego.

Kilka lat temu pracowałem przy systemie CRM dla dość dużego portalu internetowego. W tym systemie odbywała się sprzedaż i fakturowanie zleceń klientów, czyli sprawa dość poważna. Była to duża firma: deweloperzy zajmowali się tworzeniem systemu, a administratorzy administrowaniem baz danych i systemu. W pewny piękny i słoneczny dzień okazało się, że część danych w bazie jest uszkodzona. Nie chodziło o to, że dane są złe, lecz że nie można się do nich dobrać, gdyż silnik bazy zgłasza problem z odczytem. Pierwszym pomysłem było przywrócenie bazy z kopii zapasowej. Niestety okazało się, że kopia też jest uszkodzona i konieczne było wycofanie się naprawdę daleko, żeby znaleźć dobrą kopię zapasową. Pociągnęło to za sobą utratę danych, które trzeba było odtworzyć.

Wnioski z powyższych historii:

  1. Brak kopii zapasowej jest proszeniem się o problemy.
  2. Nawet jak masz kopię to nie jesteś bezpieczny.
  3. Jak umiesz liczyć, to licz na siebie.

No dobra, czyli nie można nic zrobić żeby czuć się bezpiecznym?  

Poniżej kilka wskazówek jak zmniejszyć ryzyko utraty danych:

  1. Rób kopie i przestrzegaj zasady 3-2-1
    1. Trzy kopie zapasowe
    2. Na dwóch różnych nośnikach – np na serwerze i dysku zewnętrznym
    3. Jedna kopia poza infrastrukturą firmową – np w chmurze obliczeniowej
  2. Testuj swoją kopię zapasową. Utwórz środowisko odpowiadające twojemu środowisku  produkcyjnemu, co jakiś czas odtwórz na nim kopię zapasową i sprawdź, czy jest możliwe otworzenie wszystkich ważnych danych z kopii zapasowej. Zawsze możesz wykorzystać takie środowisko do testowania nowych zmian które zamierzasz wdrożyć.
  3. Nawet jak twój dostawca zapewnia cię, że posiada kopię zapasową, warto robić swoją kopię. W przypadku problemów z dostawcą łatwo będziesz mógł się przenieść do innego dostawcy, odtwarzając środowisku ze swojej kopii zapasowej.

Jeśli chodzi o sam proces robienie kopii zapasowej, to do większości systemów baz danych jak i CMSów (np. WordPress) są darmowe narzędzia, które ułatwiają wykonywanie takiej kopii, jak i przywracanie danych z kopii. To jednak jest już historia na całkiem inny wpis.

Wnioski

Posiadamy coraz więcej dóbr cyfrowych i nie zdajemy sobie sprawy, jak szybko możemy je utracić. W większości przypadków utrata danych jest nieodwracalna, a jedynym sposobem zapewnienia sobie bezpieczeństwa jest robienie kopii zapasowych. Więc rób kopię i bądź bezpieczny :).

Kiedy będą autonomiczne samochody

Od pewnego czasu można zauważyć duży szum wywołany wokół sztucznej inteligencji i samochodów autonomicznych. Sztuczna inteligencja jest bardzo szerokim tematem, jednak jej znaczy wycinek stanowi podstawę procesu tworzenia wspomnianych samochodów. Patrząc po doniesieniach prasowych, raczej większość tych konstrukcji jest w fazie prototypu. Co jakiś czas pojawiają się informacje o problemach z tymiż prototypami i wypadkach, jakie ona spowodowały. Przyglądając się tym badaniom można zadać sobie pytanie: A może samochody autonomiczne wcale nie są nam potrzebne? Może są wręcz niebezpieczne dla człowieka?

Zacznijmy od tego co mamy teraz w naszych samochodach. Aktualnie większość, jak nie wszystkie nowe samochody posiadają liczne systemy wspomagające prowadzenie samochodu: ABS, ESP to już jest standard. Dodatkowo w lepiej wyposażonych modelach mamy asystentów pasa ruchu, monitoring zmęczenia kierowcy, aktywny tempomat itp. Już teraz część „odpowiedzialności” przejmują za nas systemy. Jednak póki co nie są one wstanie zastąpić człowieka w 100%. Droga do tego choć jeszcze daleka, może się okazać krótsza, niż nam się wydaje.

Podstawowy problem samochodów autonomicznych związany jest z zapewnieniem bezpieczeństwa. (https://www.weforum.org/agenda/2017/08/germany-has-developed-a-set-of-ethical-guidelines-for-self-driving-cars/). Zasadniczym pytaniem brzmi, kogo auto ma narazić w przypadku sytuacji kryzysowej: pasażera, czy pieszego? Do momentu, w którym nie rozwiążemy tego problemu, jesteśmy skazani na stan przejściowy, czyli samochody semiautonomiczne – maszyny wspierane przez człowieka w sytuacjach kryzysowych. Samochód będzie w 100% autonomiczny, gdy będzie potrafił przewidzieć wcześniej niż człowiek sytuacje kryzysowe i odpowiednio na nią zareagować.

Samochód autonomiczny, poprzez analizę otaczającego go świata powinien być w stanie rozpoznać zachowania ludzi, czy  obiektów, które mogą doprowadzić do nieprzewidywalnych i kryzysowych sytuacji. Maszyna powinna   zrobić wszystko, aby takiej sytuacji uniknąć, lub złagodzić jej konsekwencje.

Warto się zastanowić, co jeśli sytuacja kryzysowa powstanie w taki sposób, że nie będzie możliwe jej przewidzenie. Powiedzmy, że ktoś wybiegnie zza samochodu, tuż przed maskę samochodu. Rozwiązanie jest proste, jeśli na drogach większość pojazdów będą stanowiły samochody autonomiczne wyposażone w system analizy otoczenia, to będą one mogły informować się wzajemnie o zagrożeniu. Jednak zdarzyć się może, że sami będziemy podróżować pustą drogą, skąd wtedy pobierać informacje? Wówczas pomocy musimy szukać w analizie otoczenia. Zajmować się tym będą analizatory zamontowane w lampach, znakach, przystankach itp. Czyli do bezpiecznego działania samochodów autonomicznych potrzebujemy „inteligentnego otoczenia”. Taki system najłatwiej będzie zrealizować na autostradach, gdzie mamy ograniczony ruch pieszy (nie wykluczając przypadków specjalnych), a nasycenie ruchu samochodami autonomicznym w 50%, daje szanse na pełną analizę otoczenia zapewniającą bezpieczeństwo ruchu. Jeśli na autostradzie co drugi pojazd będzie autonomiczny, system będzie w stanie przewidzieć sytuacje kryzysowe powodowane przez tradycyjnych użytkowników drogi.

W miastach takie rozwiązanie sprawdzałoby się dobrze w specjalnych centrach, ponieważ na niedużym stosunkowo obszarze łatwiej będzie wdrożyć odpowiednie rozwiązania. Zamknięcie centrów miast dla ruchu innego niż autonomiczny i wpuszczenie tam samochodów elektrycznych, dostępnych dla użytkowników na zasadach podobnych do działania taksówek lub Ubera, pomogłoby rozwiązać palące problemy parkowania w centrach oraz smogu. W miastach poza samochodami oczywiście mogłyby się poruszać autonomiczne autobusy, czy tramwaje.

Patrząc na statystyki wypadków i ich przyczyn, wyeliminowanie człowieka z procesu prowadzenia samochodu może przynieść tylko pozytywne skutki. Niestety pozbawi nas to frajdy z jazdy samochodem, a sam samochód zostanie sprowadzony do transportera z punktu A do B. W erze pojazdów autonomicznych przestanie mieć znaczenie ile koni mamy pod maską i jak szybko osiągamy „setkę”.

Niestety obecna technologia jeszcze nie jest  gotowa na realizacje w pełni bezpiecznych systemów i pojazdów autonomicznych. Do realizacji tego typu rozwiązań potrzeba miliardów peta bajtów danych, które niezbędne są do nauki modeli, szybkiego przesyłu danych, wspólnych interfejsów, a także do porozumiewania się samochodów pomiędzy sobą, jak i z otoczeniem.

Podsumowując, jesteśmy skazani na samochody autonomiczne dla własnego bezpieczeństwa. Pytanie brzmi, kiedy pojawią się w naszym życiu.