Jak obniżyć koszty usuwania awarii dzięki sztucznej inteligencji? Case study
Obniżenie kosztów usuwania awarii dróg, rur, czy linii wysokiego napięcia? Tak, to możliwe dzięki sztucznej inteligencji.
Czy wprowadzanie innowacji w firmie musi wiązać się z dużymi kosztami? Nie, jeśli zapewnimy sobie wsparcie silnego zespołu, zastosujemy zwinną metodykę pracy i dobrze określimy problem, który chcemy rozwiązać. W tym artykule opowiem o tym, jak razem z kilkuosobowym zespołem R&D zaproponowaliśmy rozwiązanie problemu, który potencjalnie może kilkukrotnie zmniejszyć u naszego Klienta nakłady związane z naprawą usterek.
Sztuczna inteligencja w branży ciepłowniczej, case study
Niedawno miałam przyjemność wspólnie z zespołem zmierzyć się w praktyce z wyzwaniem, w ramach którego udało nam się znaleźć optymalną metodę analizy danych przestrzennych, które od jakiegoś czasu zbierał nasz klient – jedna z największych w Polsce firm z branży ciepłowniczej.
Zaczęliśmy od małej próbki, projektu typu Proof of Concept, w ramach którego mieliśmy sprawdzić, czy uda nam się dzięki automatyzacji procesu wesprzeć ekspertów w wykrywaniu na podstawie zdjęć termicznych drobnych usterek, niewidocznych na pierwszy rzut oka.
To doskonały przykład na to, że innowacja nie musi wiązać się z czasochłonną i kosztowną reorganizacją całej firmy. Można zacząć od prostej optymalizacji, lub automatyzacji prostych czynności, dzięki którym można odciążyć zespół.
Wyzwanie
W przypadku naszego Klienta proces, z którym mieliśmy do czynienia był jednym z tych, którego unowocześnienie miało bardzo dużą wartość biznesową. Stąd pomysł na zautomatyzowanie procesu wykrywania usterek poprzez wykorzystanie algorytmów sztucznej inteligencji.
Drobne usterki generują duże straty ciepła, a co za tym idzie wysokie koszty ich obsługi. Do tej pory wykrywanie usterek sieci odbywało się na dwa sposoby:
- Duże awarie zgłaszane były na podstawie fizycznych oględzin
- Małe usterki, które nie były widoczne na zewnątrz, wykrywane były na podstawie manualnej analizy zdjęć termicznych.
W praktyce analiza polegała na przeglądaniu przez eksperta wszystkich zdjęć zrobionych z drona w celu wykrycia anomalii cieplnych. Proces ten trwał miesiącami, co wpływało również na długi czas potrzebny do wykrycia awarii.
Naszym zadaniem było częściowe zautomatyzowanie tego procesu, czyli wytypowanie miejsc z potencjalnymi usterkami, które ekspert zatwierdzi lub odrzuci.
Efekt
W ramach realizowanego projektu udało nam się:
- Uzyskać skuteczność wykrywania potwierdzonych awarii na poziomie ponad 90% .
- Ułatwić pracę eksperta dzięki wskazaniu konkretnych miejsc z potencjalną usterką.
- Skrócić czas analizy dostępnych danych z 3 miesięcy pracy 3-osobowego zespołu do 3 dni pracy 1 eksperta.
Jeśli chcesz dowiedzieć się:
- w jaki sposób podeszliśmy do rozwiązania tego problemu,
- jakie funkcjonalności zawierał system przygotowany dla klienta,
- kto z Isolution brał udział w projekcie,
- jakie korzyści daje inwestowanie w AI,
pobierz pełną wersję case study poniżej!
Możesz też umówić się na rozmowę z jednym z naszych specjalistów i porozmawiać o tym projekcie oraz poradzić się w kwestii wdrożenia rozwiązań AI w swojej firmie.
Katarzyna Roszczewska, Data Scientist w Isolution
Rynek premiuje zwinność. W tak dynamicznie zmieniającym się świecie zmienia się również podejście do projektowania i rozwoju złożonych systemów IT. Kluczem jest szybka weryfikacja założeń i wypracowanie optymalnego rozwiązania, które da się zwinnie wdrożyć. Tradycyjne podejście oznacza w tym kontekście ogromne ryzyko, m.in. budżetowe związane ze zmieniającymi się wymaganiami, przeciągającym się procesem realizacji projektu, czy szybkim starzeniem się technologii.
Pojawiają się pytania: W jaki sposób przetestować pomysł na rozwiązanie? Co zrobić, żeby sprawnie to rozwiązanie potem wdrożyć? Czy warto sięgnąć po wsparcie z zewnątrz? Jeśli tak, to w którym momencie i jak znaleźć odpowiedniego dostawcę? Co zrobić, żeby rozwiązanie problemu nie przerodziło się w kosztowny, duży, długofalowy i nieefektywny projekt?
Odpowiedzią na te pytania może być Proof of Concept oraz pracujący zwinnie, doświadczony zespół, który ma wiedzę z obszaru tworzenia PoC’ów na podstawie specjalistycznej wiedzy i nowe technologie, np. machine learning, czy big data.
Skąd to przekonanie? W tym materiale podzielę się z Wami naszymi doświadczeniami z realizacji jednego z tego typu projektów, dzięki któremu pomogliśmy Klientowi nie tylko odpowiedzieć na wyzwanie, z którym do nas przyszedł, ale także doprowadzić do technologicznej transformacji całej organizacji.
PoC: zwinnie i konstruktywnie
Z PoC’ami mamy do czynienia od dawna. Ostatnio w coraz większej ilości, ponieważ Klienci coraz częściej przychodzą do nas nie tylko z konkretnym projektem, który chcą wspólnie z nami zrealizować, a z problemem, który mają do rozwiązania. Dlaczego coraz więcej firm decyduje się na rozpoczęcie produktów ścieżką PoC?
- Proof of Concept bez względu na rodzaj problemu, wielkość firmy i branżę pozwala w krótkim czasie, w oparciu o niewielki zespół i niski nakład kosztów przetestować możliwe rozwiązania i sprawdzić, czy pomysły, które już mamy mogą być zrealizowane zgodnie z przyjętymi założeniami.
- Pozwala średnim i dużym firmom zwinniej i efektywniej reagować na zmieniające się oczekiwania rynkowe, a także konkurować w tym kontekście ze zwinnymi start up’ami, np. w kontekście wdrażania innowacji zgodnie z najnowszymi technologiami. Podejście typu Proof of Concept pozwala niskim nakładem kosztów przetestować, czy często droga, nowa technologia przyczyni się do wytworzenia oczekiwanej wartości biznesowej.
PoC to sposób na przetestowanie pomysłu i udowodnienie, że możliwa jest nie tylko jego realizacja zgodnie z przyjętymi założeniami, ale także efekt, na którym nam zależy. Opiera się m.in. na dokładnej analizie wyzwania, na które dany system odpowiada i procesów, które obejmuje. Dzięki temu zaspokajamy wszystkie oczekiwania i potrzeby
Wyzwanie
Jednym z ciekawych projektów typu PoC, który mieliśmy przyjemność realizować, był projekt realizowany dla Klienta, który poprosił nas o wsparcie merytoryczne przy podejściu do przepisania tworzonej od kilkunastu lat aplikacji ERP. ERP był pisany w technologii, która kończyła swój żywot i w którymś momencie pojawiło się ryzyko braku dla niej wsparcia. Dla Klienta był to poważny problem, ponieważ z czasem oznaczałoby to, że nie wychodzą nowe aktualizacje bezpieczeństwa i że jest coraz większy problem ze znalezieniem specjalistów, którzy potrafią w tej technologii pracować.
O Proof of Concept, który uruchomił technologiczną transformację firmy
Projekt rozpoczęliśmy od wywiadu i warsztatów z Klientem. Na tej podstawie powstał zarys architektoniczny nowego rozwiązania. Przy okazji określiliśmy również główne problemy techniczne, z którymi trzeba było uporać się przy okazji drugiego podejścia do systemu. Były to:
- Bardzo słabej jakości kod – pierwszy system pisany był przez bardzo młodych ludzi, którzy pracowali bez nadzoru. Rozwiązanie “wieszało się” przy obsłudze powyżej 50 osób, a docelowo miało obsługiwać kilka tysięcy użytkowników.
- Wdrożenie narzędzia u nowych Klientów zajmowało dwa tygodnie. System nie realizował również wszystkich postawionych przed nim wymogów biznesowych.
- Problem stanowiła również nieatrakcyjna strona wizualna oraz słaby UX. Nie bez znaczenia była także mała konfigurowalność systemu.
- Projekt wykorzystywał też biblioteki, które nie były już wspierane. Powodowało to nieprzewidziane problemy. Każda zmiana wymagała udziału firmy zewnętrznej, co sprawiało, że Klient był uzależniony od dostawcy, bo tylko on mógł wykonywać w systemie jakiekolwiek zmiany.
Na podstawie zebranych informacji zaprojektowaliśmy i zrealizowaliśmy PoC, który kosztował Klienta w sumie 10 MD. Plan polegał na wykorzystaniu struktur danych oraz logiki biznesowej ukrytej w setkach procedur składowanych. Sama architektura starego rozwiązania była imponująca, ale innowacyjne i nietypowe podejście jak na tamten czas powodowało, że sukces połączenia technologii stał pod znakiem zapytania. Opracowane podejście przewidywało weryfikację hybrydy pomiędzy starymi a nowymi technologiami. Stworzenie zupełnie nowego systemu zajęłoby lata, co z punktu widzenia Klienta nie wchodziło w grę.
PoC zakończyliśmy z sukcesem. Udało nam się stworzyć hybrydę wycinka logiki biznesowej pochodzącej ze starej aplikacji wraz z nowoczesnym backendem i frontendem. Projekt, z którym pierwotnie przyszedł do nas Klient, został jednak zamrożony ze względu na skalę kosztów, ale na bazie PoC’a powołany został drugi, który doprowadził w efekcie do technologicznej transformacji całej organizacji. Jak do tego doszło?
Rozwiązanie
Punkt wyjścia
Pierwotnie nasz Klient chciał przepisać system na nowo, korzystając z usług poprzedniego dostawcy. Nas poproszono o konsultacje technologiczne oraz jakościowe i przygotowanie wstępnej wyceny.
W trakcie procesu szybko okazało się, że dotychczasowy dostawca nie podoła nowym wyzwaniom, w związku z czym rozpisany został oficjalny przetarg. Pomogliśmy naszemu Klientowi przygotować materiały oraz warsztaty, w wyniku których miał zostać wyłoniony kolejny dostawca. Większość potencjalnych dostawców zrezygnowało z projektu już na etapie warsztatów. Dlaczego? Ze względu na: złożoność projektu zarówno od strony technologicznej, jak i biznesowej, brak doświadczenia Klienta przy tego typu projektach, brak infrastruktury IT oraz niepełną analizę tematu.
Przyszła kolej na nas. Oszacowaliśmy temat, przedstawiliśmy pierwszą ofertę zgodną z założeniami Klienta i okazało się, że koszt jest dla Niego zbyt duży.
Co w takiej sytuacji zaproponowaliśmy?
Klient nie był gotowy pod względem informatycznym na tak duże przedsięwzięcie, jak napisanie na nowo systemu ERP (oprogramowanie, którego celem jest zintegrowanie wszystkich procesów zachodzących w organizacji). Skala projektu była ogromna, a Klient nie miał odpowiednich kompetencji ani infrastruktury informatycznej. Takiej zmiany niestety nie da się wykonać w ciągu paru tygodni.
Szybko okazało się również, że ERP to nie jedyny system, który wymaga ratunku – system sprzedażowy klienta, który powstawał przez rok, a rozwijany był przez kolejne trzy, pomimo że wytworzony w nowszych technologiach, również wymagał wskrzeszenia.
Mając wszystkie niezbędne dane postanowiliśmy, że najlepiej będzie zacząć od zmniejszenia zakresu, co oznaczało wdrożenie innego, mniejszego systemu, a także przejścia na zwinną metodologię pracy oraz wyznaczenia MVP, czyli najmniejszą, funkcjonalną wersję systemu, która generuje wartość biznesową. Dzięki temu Klient uzyska odpowiednie know-how, jeżeli chodzi o nowoczesny proces wytwórczy systemów informatycznych, a pozyskane kompetencje wykorzysta przy tworzeniu systemu ERP. Uzgadniając nowe założenia dotyczące systemu i podchodząc elastycznie do projektu – mogliśmy zacząć współpracę.
„Pierwotnie zakładaliśmy zupełnie inne podejście do rewitalizacji systemu. Dzięki wykorzystaniu Proof of Concept szybko przekonaliśmy się, że musimy je diametralnie zmienić, jeśli chcemy zrealizować swoje cele, myśląc jednocześnie o budżecie, jaki mamy. W ciągu zaledwie 10 dni nie tylko znaleźliśmy odpowiedź na wyzwanie, jakie mieliśmy, ale również przygotowaliśmy plan, dzięki któremu mogliśmy przeprowadzić tę zmianę” – komentuje Kierownik ds. Rozwoju Systemów Informatycznych, przedstawiciel naszego Klienta odpowiedzialny za realizację projektu.
Nowe podejście
Podczas projektu nasz zespół pracował ramię w ramię z zespołem Klienta. Celem było przekazanie know-how, jeżeli chodzi o nowoczesny proces wytwórczy. Stosowaliśmy też partnerskie podejście – chcieliśmy, aby klient docelowo był samowystarczalny.
Nowe Standardy
Wprowadziliśmy standardy developerskie, a także przeprowadziliśmy szkolenia dla developerów Klienta. Organizowaliśmy również wspólne code review.
Nowy Model Pracy
W trakcie tej współpracy przeprowadziliśmy warsztaty ze Scrum’a i Agile’a, a także analizy. Dostarczyliśmy wzorce projektowe. Wdrożyliśmy Continous Integration, git, gerrit, jenkins i nauczyliśmy zespół Klienta jego obsługi.
Stałe Wsparcie
Po sześciu miesiącach pracy Klient wdrożył MVP systemu na produkcję nie tylko dla siebie, ale również jednego dużego Klienta. Czy na tym etapie nasza praca zakończyła się? Nie. Po wdrożeniu nadal rozwijaliśmy system oraz wspieraliśmy jego utrzymanie.
Efekt rozpoczęcia projektu od PoC’a
Zaczęło się od 1-osobowego zespołu i 10 MD. Po dwóch latach od wdrożenia Klient obsługuje już kilkunastu beneficjentów swojego systemu. System został wdrożony w krótszym, niż pierwotnie zakładał czasie i co ważne, zaczął zarabiać na siebie.
Zwinne podejście spowodowało, że szybko poradziliśmy sobie ze zmieniającymi się wymaganiami, dodając w trakcie prac duże funkcjonalności, nieprzewidziane na starcie projektu. W efekcie dostarczyliśmy wystarczający system za połowę pierwotnej wyceny kompletnego systemu.
Stworzyliśmy również infrastrukturę informatyczną u Klienta, dzięki której realizacja nowych projektów jest teraz dużo sprawniejsza i łatwiejsza. Klient nie jest uzależniony od zewnętrznego dostawcy. Sam może utrzymywać system dzięki temu, że przeszkoliliśmy również Jego zespół. Nas wybiera do jego rozwoju bo chce, a nie musi.
POC – o czym pamiętać?
Bazując na zdobytych doświadczeniach za każdym razem, kiedy Klient przychodzi do nas z jakimś wyzwaniem, proponujemy właśnie rozpoczęcie projektu od PoC’a, ponieważ dzięki temu możemy:
- Dogłębnie ten problem przeanalizować
- Niskim nakładem kosztów przetestować możliwe rozwiązania
- Ograniczyć koszt realizacji projektu, który na tej bazie powstanie
- Wyeliminować możliwe problemy i ryzyka
- Zwiększyć efektywność pracy
O czym warto pamiętać planując wykorzystanie Proof of Concept do szukania odpowiedzi na wyzwania, z którymi sami się borykamy?
- Warto określić, jakie są niewiadome i na jakie pytania chcemy poznać odpowiedzi.
- Należy minimalizować zakres prac. Nie chcemy tworzyć dużej aplikacji. Chcemy jak najmniejszym kosztem zweryfikować potencjalne ryzyka. Na tym etapie nie warto przeznaczać zasobów na rzeczy, które nie wymagają weryfikacji.
- Ważnym elementem podczas PoC jest otwarta głowa. Odpowiedzi, które da nam wczesna weryfikacja, mogą nie być odpowiedziami, które nam się podobają, ale potencjalnie pozwolą nam oszczędzić budżet.
- Podczas tworzenia PoC dostawca musi mieć dużą świadomość biznesową swojego Klienta. Powinien wiedzieć dlaczego i po co jest tworzony PoC. Umożliwi to opracowanie lepszego podejścia do rozwiązania i zauważenie skrótów, które w innym przypadku byłyby nieosiągalne.
- Warto też upewnić się, czy ktoś nie rozwiązał tego problemu już wcześniej. Warto czerpać inspirację i wiedzę od innych.
Artur Żórawski, Founder&CTO Wizards