Do naszych rozważań posłużymy się wymyślonym, ale realnym przykładem problemu. Poznaj Mariusza - właściciela (fikcyjnej) firmy produkcyjnej o “Prodmax”.
Mariusz dostaje cyklicznie informacje od swojego pracownika – Tomka z działu Utrzymania Ruchu o braku narzędzia, które usprawniłoby jego pracę. Pracownik skarży się na chaos, ponieważ ludzie zgłaszają awarie mailowo, na karteczkach i słownie - trudno nad tym efektywnie zapanować
Być może pierwszy raz spotykasz z nazwą: “Dział utrzymania ruchu” (w skrócie UTR) i zastanawiasz się, co to za instytucja. 😊 Otóż, UTR zajmuje się dbaniem o to, aby wszystkie maszyny w firmie były sprawne i nie miały przerw w pracy.
Jest to ważny dział z tego względu, że każdy przestój generuje koszty.
Wyobraźmy sobie, że dana maszyna nie działa przez 8 godzin - w zależności od tego, co firma produkuje , czas przestoju w pracy może oznaczać duże straty finansowe.
Wróćmy do pracownika firmy “Prodmax”. Chcąc poradzić sobie z chaosem związanym ze zgłaszanymi awariami, Tomek stworzył plik Excel, który w jakimś stopniu organizuje wszystkie informacje.
Tomek ma jednak jeden, dość istotny problem: nie wie, czego nie wie.
tara się uporządkować wszystkie dane, nadaje im status, priorytet itp., ale na dłuższą metę takie rozwiązanie nie zdaje egzaminu. Pamiętajmy, że mowa o “Prodmaxie” - dużej firmie produkcyjnej.
Mając na uwadze, jak ważny jest Dział Utrzymania Ruchu, właściciel firmy postanawia znaleźć lepsze rozwiązanie niż Excel Tomka.
Poszukiwania rozpoczyna tak, jak wszyscy w podobnej sytuacji - wpisując w Google frazę: “Aplikacje do utrzymania ruchu”. W wynikach wyskakuje kilka gotowych aplikacji, ale to, co od razu można zauważyć, to że takie systemy mają swoją nazwę: CMMS (ang. Computerized Maintenance Management System).
Przeglądając różne aplikacje , Mariusz stwierdza, że jedne z nich są staroświeckie i mają brzydki interfejs (wygląd), a inne są nowoczesne i bardzo rozbudowane. Ma to oczywiście swoje odzwierciedlenie w cennikach.
Mariusz nie ma pewności, czy taka aplikacja spełni ich oczekiwania i czy pracownicy jego firmy będą z niej korzystać.
Jakie decyzje może podjąć w tym momencie?
Zakup subskrybcji na wybraną aplikację w chmurze i płacenie abonamentu.
Poproszenie pracownika działu IT o napisanie prostych skryptów do Excela lub Arkuszy na Google Dysk, które pozwolą zautomatyzować pracę.
Zlecenie napisania dedykowanego rozwiązania zewnętrznej firmie IT.
Brak decyzji – brak zmian obecnej sytuacji działu UTR.
Produkty chmurowe mają różne modele cenowe m.in:
Abonament miesięczny/roczny.
Płatność za użytkownika.
Płatność za zużycie.
Model oparty na modułach.
Płatność jednorazowa.
Aplikacja, która spodobała się Mariuszowi wymaga comiesięcznej płatności za każdego użytkownika. Obliczył, że jego firma potrzebuje około 10 licencji:
Model płatności | Opis | Miesięczny koszt za 10 licencji | Koszt przez 10 lat |
| Miesięczna opłata za subskrypcję aplikacji | 1590 PLN | 190 800 zł (1590 zł/miesiąc 12 miesięcy/rok 10 lat) |
Plusy + rozwiązania:
po dokonaniu płatności można zacząć używać aplikacji od razu,
znikoma inwestycja,
jeśli aplikacja nie spełni oczekiwań można łatwo zrezygnować, nie tracąc dużej ilości pieniędzy.
Minusy - rozwiązania:
zagrożenie, że aplikacja nie rozwiąże problemu, z którym mierzy się firma lub rozwiąże problem, ale w sposób skomplikowany i nieefektywny.
W naszym przykładzie pracownik używał Excela. Jednym z pomysłów, jak rozwiązać problemy Tomka za pomocą Excela jest przeniesienie pliku do Arkuszy Google i wykorzystanie tzw. “AppSheet”.
Arkusz Google z AppSheet to taki “Excel na sterydach”. Jest często wykorzystywany przez firmy do tworzenia różnego rodzaju aplikacji biznesowych, takich jak aplikacje do zarządzania zasobami ludzkimi, monitorowania pracy terenowej, zarządzania magazynem, zarządzania klientami i wiele innych. Dzięki możliwościom tworzenia aplikacji bez kodu, AppSheet umożliwia szybkie wdrożenie niestandardowych rozwiązań bez konieczności angażowania zespołu programistów.
Takie rozwiązanie jest coraz bardziej popularne i ma swoją nazwę: ”low code / no code”, bo nie wymaga pisania nowego kodu.
Może wystarczy kupić kurs działowi IT?
Pracownic_ po kursie bez problemu powinn_ dopiszć skrypty rozwiązujące problemy działu utrzymania ruchu.
Brak automatyzacji, brak jednej bazy danych przy jednoczesnej cyfryzacji działu (tylko w pewnym stopniu oczywiście).
Plusy + rozwiązania:
kosztem jest tylko ewentualny kurs dla pracownika i jego praca,
Twoja organizacja poszerzy wiedzę nt. low code -a tę można ją zastosować w innych działach i procesach w firmie.
Minusy - rozwiązania:
czas - wdrożenie jakiegokolwiek rozwiązania zajmie trochę czasu (trudno dokładnie określić, ile),
będą pojawiały się ograniczenia takiego rozwiązania - pewnych skomplikowanych rzeczy po prostu nie będzie dało się zrobić.
Jeśli nie zdecydowałś się na zakup aplikacji w chmurze i nie jesteś przekonan, że dopisanie własnego rozwiązania będzie dobrym wyborem, możesz rozważyć zatrudnienie zewnętrznej firmy IT, która napisze dedykowane rozwiązanie dla Twojej firmy.
Przesłanki za tym, aby napisać system od zera:
Twoja firma ma jakiś specyficzny proces biznesowy, który jest unikalny na rynku i wyróżnia Twoją firmę na tle konkurencji,
chciał_byś zintegrować narzędzia, aby zautomatyzować procesy (np.: programy księgowe, aplikację bankową), a narzędzia dostępne na rynku tego nie robią,
chciał_byś zacząć wykorzystywać sztuczną inteligencję (AI) (w naszym przykładzie to np.: automatyczne priorytetyzowanie usterek),
chcesz mieć pełną kontrolę nad tym, jak działa i wygląda system.
Plusy + rozwiązania:
wsparcie firmy IT (również po wdrożeniu systemu),
rozwiązanie dedykowane specyficznemu procesowi biznesowemu w Twojej firmie,
pewność, że Twój problem zostanie rozwiązany,
pełna kontrola nad rozwiązaniem,
system, który posłuży firmie przez wiele lat i będzie się rozwijał razem z nią.
Minusy - rozwiązania:
koszt realizacji dedykowanej aplikacji.
czas wdrożenia: konsultacje, praca programistów, testy, poprawki.
Brak decyzji to też decyzja. Jeśli szef z jakiegoś powodu stwierdza, że pomimo pewnych problemów, dział utrzymania ruchu działa wystarczająco dobrze, nie trzeba na siłę wszystkiego cyfryzować.
Spotykając się po raz pierwszy z klientem, niejednokrotnie usłyszeliśmy to trafne i ważne pytanie.
Czy “od zera” to faktycznie “od zera”?
Odpowiedź brzmi: nie.
Czasy, gdy aplikacje pisało się ”na czystej kartce” już dawno minęły. I to bezpowrotnie. Obecnie, w większości przypadków, firmy korzystają z tzw. frameworków czyli bazy kodu, który aplikuje podstawowe funkcjonalności obecne w większości systemów takie, jak np.: logowanie. Można także skorzystać z gotowych bibliotek z komponentami interfejsu użytkownika.
Od zera należy natomiast napisać tzw.: logikę biznesową, czyli przełożyć specyficzne procesy w firmie na kod. I to jest obszar, który jest najważniejszy, powinien być najbardziej dopracowany oraz przetestowany.
Najważniejsze, aby firma zlecająca oprogramowanie i programiści dobrze się zrozumieli. Należy pamiętać, że kod, który powstaje, niekoniecznie działa tak, jak wyglądają procesy, ale tak, jak zrozumiał je programista. Dlatego tak ważny jest etap analizy i konsultacji, aby obie strony zrozumiały jaki jest cel tworzenia systemu.