ERP od kuchni

Dostawcy zaawansowanych rozwiązań IT dla biznesu co kilka miesięcy udostępniają klientom nowe i coraz bardziej zaawansowane wersje swoich systemów. Nowsza wersja ERP ma przede wszystkim poprawić jakość pracy w firmie, bo ta jest jak człowiek: rośnie, rozwija się i zmienia.

System informatyczny jest jak garnitur, ale nawet najlepiej skrojona marynarka i spodnie wymagają czasem poprawek krawieckich. Tak samo jest z systemem ERP. Z analiz, przeprowadzonych podczas wielu spotkań z klientami BPSC, jednoznacznie wynika, że najbardziej pożądanym kierunkiem rozwoju jest podnoszenie jakości. Objawia się ono w różnych obszarach – optymalizacja długo trwających operacji, większy nacisk na testowanie, rozbudowa dokumentacji i materiałów edukacyjnych, standaryzacja powtarzalnych rozwiązań indywidualnych itp. Dlatego, oprócz wprowadzania nowych funkcjonalności, należy zadbać, by zostały dopracowane te istniejące. Często to one są istotne dla doświadczonych użytkowników. Podniesienie jakości produktu jest mniej widowiskowe niż dodawanie nowych modułów. Ale przedsiębiorstwa użytkujące systemy ERP od lat cenią sobie ten kierunek rozwoju tak samo (lub nawet bardziej), jak nowe gadżety.

Jak to się zaczyna?

Fundamenty są najważniejsze i to od nich należy zacząć. Najlepiej odpowiednio wcześniej, nie zaś na przysłowiowe „hurra”. Zmiany, jakie pojawiają się w kolejnych odsłonach, powinny być spójne i przygotowywać grunt pod plany, które będą realizowane za jakiś czas. A żeby móc „z głową” realizować dalekosiężne, wieloletnie wizje, trzeba zacząć od przemyślanego i perspektywicznego ustawienia procesów rozwoju oprogramowania. Bez właściwego rytmu i sposobu pracy często pojawia się odczucie, że nawet najśmielsze wizje realizowane są jakby w zwolnionym tempie i na ślepo.

W naszym przypadku kamieniem milowym było skuteczne wdrożenie Scruma w poprzednich latach. W każdym z 4 obszarów biznesowych (Produkcja, Zarządzanie Łańcuchem Dostaw, Finanse i Personel) oraz w warstwie architektury aplikacji pojawili się Product Ownerzy. Są to osoby, które doskonale znają oczekiwania, potrzeby czy wymagania użytkowników. Zarządzają oni tzw. Backlogami zmian – listami wszystkich znanych potrzeb w ich produktach. Ich zadaniem jest takie uporządkowanie Backlogu, by w pierwszej kolejności wykonane zostały prace przynoszące klientom największe korzyści. Nie jest to zadanie proste, szczególnie mając pod opieką system, z którego korzystają setki zupełnie odmiennych przedsiębiorstw. Co więcej – te listy nie są stałe. Praktycznie codziennie pojawiają się nowe zgłoszenia serwisowe, pomysły rozwojowe, informacje zwrotne od deweloperów i klientów, które trzeba uwzględnić i ocenić ich wartość. Efektem tej pracy jest wyraźna poprawa efektywności, rozumiana jako poświęcenie znacznie większej części czasu na te zadania, które są najbardziej oczekiwane przez klientów.

Kolejną rolą, bardzo istotną dla jakości i wartości wykonywanych prac, jest rola Scrum Mastera, który odpowiedzialny jest za stałe doskonalenie sposobów pracy zespołów deweloperskich, wprowadzanie i pilnowanie przyjętych zasad oraz usuwanie przeszkód obniżających wartość ich pracy. Dzięki wiedzy i narzędziom, jego wkład w efektywność spotkań, utrzymanie rygorów jakościowych i polepszanie współpracy w zespołach jest nieocenione.

Wykorzystaj potencjał zespołu

Sensem wdrażania Scruma jest maksymalizacja wartości pracy zespołów deweloperskich. Praca w regularnych, krótkich cyklach czasowych (zwanych w Scrumie „Sprintami”) pozwala na bieżąco oceniać i korygować kierunki rozwoju. Product Owner co 2-3 tygodnie formuje plan pracy w taki sposób, żeby po następnym Sprincie jakość i wartość produktu była jak największa. Znakomite efekty przyniosło również dołączenie do każdego zespołu dedykowanego testera. Po co? Aby pomóc w maksymalnym skróceniu czas pomiędzy zakończeniem programowania a przetestowaniem zmienionej funkcji. To bezpośrednio przełożyło się na poprawę jakości – nie tylko aplikacja jest niemal cały czas stabilna, ale także programiści poprawiają znalezione błędy niemal od razu. Jest to znacznie bardziej efektywne niż wcześniej u nas stosowane akcje masowego testowania tuż przed wydaniem nowej wersji.

Każdy zespół deweloperski posiada swoje standardy, które musi spełniać każda wykonana praca. Jest to tzw. Definicja ukończenia. Bazą są ustalenia wspólne dla wszystkich zespołów, wynikające z uzgodnień na poziomie całego działu (typu – sposób publikowania poprawek, standardy nazewnictwa, procedury zapisywania prac w repozytorium itp.). Na tej bazie poszczególne zespoły przyjmują dodatkowe założenia, które są walidowane przed zakończeniem prac. Daje to czytelny obraz i zrozumienie, co dokładnie zostało wykonane w Sprincie. Pozwala też rzetelnie szacować przyszłe prace i określać ile z nich da się wykonać w różnych przedziałach czasu.

Wszystkie te zmiany nie miałyby dużego znaczenia bez określenia najważniejszego – co tak naprawdę stanowi wartość dla naszych klientów. Prawdziwą rewolucją było przejście od domyślania się do zapytania i uzyskania odpowiedzi. Wiele zgłoszonych uwag i potrzeb było zgodnych z naszymi odczuciami, ale zdarzały się również zdumiewające odkrycia. Wiele elementów „mało istotnych” zostało zrealizowanych w najnowszej wersji systemu dlatego, że klienci w swoich głosach uznali je za ważniejsze, niż większość planowanych prac rozwojowych. Ich obecność na przeglądach prac, wykonanych w Sprintach przez zespoły deweloperskie była okazją do weryfikacji przydatności, poprawności i zgodności z ich oczekiwaniami.

Wymiana wiedzy została również doceniona przez klientów – ich pozytywne opinie o zmienionym modelu współpracy i słuchaniu ich głosu znalazły swoje odbicie w corocznych badaniach poziomu satysfakcji z produktu. Wskaźnik wzrósł o niemal 20 proc.!

Podsumowując – klienci bardzo cenią sobie jakość. Nie tylko tą, wykazywaną przez arkusze testowe czy metryki kodu. Ale przede wszystkim jakość, rozumianą jako tworzenie produktu, który jak najlepiej spełnia ich potrzeby. Dlatego potrzebny jest dialog. On nie tylko usprawnienia pracę, ale także pozwala uwolnić kapitał intelektualny. Ważne jest, by ten dialog przerodził się w rozmowę z użytkownikami aplikacji. Dzięki temu przyszłe wersje systemu, będą za każdym razem dostarczały takich rozwiązań, jakich klienci najbardziej oczekują i jakie cenią.

Ramka z autorem

Lucjan Giza to dojrzały (ponad 20 lat doświadczenia) projektant i twórca aplikacji biznesowych. Nie stroni od kodowania, testowania nowinek i prac architektonicznych. Realizuje się w podnoszeniu standardów jakości pracy i usprawnianiu działania organizacji. Obecnie czerpie ze zdobytych doświadczeń i umiejętności podczas zarządzania Działem Rozwoju w BPSC. Prywatnie – pasjonat gokartów, turystyki górskiej i muzyki klasycznej.