Wstęp

  • Czy lubicie niemal natychmiastowo otrzymać informację zwrotna, że to co robicie ma sens?
  • Czy wolicie unikać projektów, które są pisane do szuflady pod kątem wyimaginowanego problemu?
  • Czy lubicie jak tworzone przez Was rzeczy faktycznie rozwiązują jakiś problem biznesowy?

Ostatnio miałem przyjemność siłować się z pewnym z pozoru banalnym problemem - sklejania dużej ilość arkuszy kalkulacyjnych.

Zaczęło się jak zwykle - dwie koleżanki z innego działu nieśmiało zapytały, czy znam VBA. Bez wahania odparłem, że znam. Okazało się, że chciały się nauczyć pisać makra w Excelu. To była dość nietypowa prośba jak na osoby niebędące programistami.

Pociągnąłem temat by dowiedzieć się gdzie jest ten przysłowiowy pies pogrzebany.

Problem

Moje koleżanki pracują w dziale do którego trafia duża ilość dokumentów od liderów właśnie w formacie Excel. Liderzy zbierają konkretne potrzeby od członków swojego zespołu, następnie uploadują wypełnione arkusze na wewnętrzną platformę. Po upływie deadline’u one muszą przejrzeć około 150 arkuszy i stworzyć z nich jeden główny arkusz.

  • Po co im to potrzebne?
  • Do szacowania budżetu tego działania.
  • Do sprawdzenia możliwości realizacji konkretnych potrzeb.
  • Do aktywnego zarządzania budżetem - jeśli coś można kupić taniej teraz w przedsprzedaży (czy tzw. “early bird”) to czemu tego nie zrobić.
  • Do zarządzania ryzykiem związanym np. z niezadowoleniem osób.

Mamy więc zdefiniowanego interesariusza: specjalistki z pewnego działu.

Zdefiniujmy także sobie miarę sukcesu. Ilości arkuszy jakie przychodzą od liderów nie jesteśmy w stanie zmniejszyć - jest to coś, co wynika z procesów wewnątrzfirmowych. Możemy co najwyżej dostarczyć dwie wartości:

  • Komfort pracy - określany jako ilość arkuszy które ręcznie będą musiały przetworzyć. Im mniejsza liczba arkuszy do przetworzenia tym lepiej.
  • Czas pracy - ile sumarycznie zajmie im proces scalania tych arkuszy, plus czas synchronizacji. We dwie pracują nad spojeniem wszystkich tych arkuszy w jeden wspólny arkusz.

Przyjrzyjmy się ile obecnie zajmuje ręczne przetwarzanie tych arkuszy. Po zapytaniu, okazało się, że około tygodnia pracy 2 osób. Co daje nam niebagatelną liczbę 80 roboczogodzin.

Przepraszam z góry za tą korpojednostkę :)

Poszukiwanie rozwiązania

Najlepszym rozwiązaniem byłoby niewątpliwie narzędzie osadzone w ekosystemie platformy na którą wrzucane są te Excele. Wymagałoby to zaangażowania specjalistów od systemów wewnętrznych, którzy chwilowo nie mają czasu na taki projekt (aktywnie działają w projektach dla klientów). Dodatkowo wiadomo, że takie wymaganie ma dla nich bardzo niski priorytet - gdy pracują dla klienta, dostarczają pieniądze.

Według zasady “cokolwiek jest lepszego od niczego” szukamy takiego rozwiązania, które niskim kosztem czasu pracy jednego developera dostarczy jakiekolwiek ulepszenie procesu na poziomie przynajmniej 1% w bardzo krótkim czasie.

Mówimy tu o dwóch dniach (weekend, bo od poniedziałku trzeba było zacząć pracę z excelami.)

Jak widzicie, nie mamy czasu na to, by szukać idealnego rozwiązania, którego wytwarzanie będzie pewnie trwało z kilka miesięcy. Szukam czegoś na tu i teraz. Nie musi to być idealne rozwiązanie, ważne by pomagało. Ważny jest ten impact factor.

1% to umowna granica która pokazuje nam, że przynosimy wartość dla interesariusza. W tym wypadku oznacza to, że jeśli zmniejszyć czas pracy o 1 h lub o 2 arkusze to będzie to już sukces.

Może to brzmieć jak mały przyrost korzyści, ale jest to już lepsze niż nic - zwłaszcza w perspektywie dłuższego czasu.

Dostępne strategie

Uwzględniając czas i zasoby, zawęziłem potencjalne opcje rozwiązania tego problemu do dwóch możliwości:

  • Microsoft Office zawiera wbudowane narzędzie do łączenia exceli. Wymaga ono jednak ręcznego kontrolowania procesu przez podawanie zakresów arkuszy do połączenia.
  • Można napisać makro w Excelu, które otwiera inne excele w katalogu, wczytuje dane i w odpowiedni sposób sortuje.

Pierwsze rozwiązanie pozytywnie wpływało na obie założone miary, ale w znacznie mniejszym stopniu niż to drugie. Przy 150 arkuszach można się łatwo pogubić i nie zauważyć prostego błędu np: przeoczenia jednej osoby. Pozwalało zaoszczędzić tylko 50% czasu, przy dużym ryzyku popełnienia błędu oraz przekopiowaniu nieistotnych danych lub błędnych danych.

Dodatkowo - co się okazało po zgłębieniu tematu - trzeba było filtrować pewne niechciane wiersze (czyli wykonywać dodatkową pracę).

Dodajmy do tego, że arkusze pojawiały się w nieokreślonych odstępach czasowych (także już te wcześniej otrzymane, ale z poprawkami) co powodowało, że cały proces trzeba było powtarzać wielokrotnie.

Drugie rozwiązanie miało niewątpliwą przewagę - mogłem stworzyć pojedynczy przycisk, który ukrywa cały proces łączenia. Powtarzalna praca, niezależnie od ilości arkuszy wykonywana była po naciśnięciu pojedynczego przycisku. Działało to zarówno dla 1 jak i 150 dokumentów.

Dodatkowo mogłem kontrolować co i gdzie trafia, oraz jak będzie prezentowane. Wszystko z poziomu kodu.

Zdecydowałem się na implementację tego drugiego rozwiązania. Zajęło mi to 5h w niedzielę.

Estymowany wpływ na wcześniej zdefiniowane wartości to:

  • Ilość arkuszy z którymi pracowały specjalistki - 150.
  • Czas łączenia 150 arkuszy to koło 2 minut.

Rozwiązanie w pełni automatyzowało proces przetwarzania arkuszy, ale wymagało nadal zgrania ich do jednego katalogu gdzie miał się znajdować ten dokument wspólny. Samo zgrywanie pewnie zajęło około 30 minut przez każdą ze specjalistek, co daje nam 60 minut.

Czy było to rozwiązanie idealne? Nie.

Czy pasowało do potrzeb interesariuszy? Do pewnego stopnia. Nadal wymagało pewnych poprawek. Nie brałem pod uwagę danych o których istnieniu nie widziałem, więc jeszcze kilkurazowo podchodziłem i zmieniałem kod.

VBA ma tą specyfikę pracy, że niemal natychmiast widać efekt zmian, więc mogłem dostać feedback typu “tak - o to mi chodziło”, “ nie do końca - chciałam by to się tak wyświetlało; czekaj, pokażę Ci”

Nie szukałem rozwiązania idealnego tylko wystarczająco dobrego i osiągalnego przy danych zasobach (worek umiejętności jakie posiadam i czas jaki mi pozostał do poniedziałku), tak by poprawić jakość pracy.

Podsumowanie problemu zgodnie z podejściem 111111

  • Interesariusz: pewien dział w pewnej firmie
  • Co najmniej 1% przyrostu: zmniejszyć czas potrzebny na pracę z arkuszami oraz ilość arkuszy z którymi muszą pracować.
  • Wartość: komfort pracy
  • 1 tydzień: stworzenie aplikacji która to umożliwi. W maks 2 dni. Zajęło to faktycznie 5h
  • Czynność: Przetwarzanie potrzeb pracowników
  • Strategia: stworzenie makra w języku VBA i podpięcie go pod pojedynczy przycisk, tak, aby przetwarzać arkusze w katalogu
  • Aktualna wartości mierników: 80 roboczogodzin, 150 arkuszy
  • Wartości prognozowane po wprowadzeniu strategii: 2 minuty na przetwarzanie plus czas potrzebny na zgranie arkuszy do folderu.
  • Czas nie uwzględniony w szacowaniu: 1h na wprowadzanie poprawek.

Podsumowanie

Cokolwiek jest lepsze niż nic. Ten 1% może naprawdę poprawić komuś komfort pracy. 1 h z czasu pracy może wydawać się małym zyskiem, ale należy popatrzeć na korzyść nie z naszego punktu widzenia a z punktu widzenia interesariuszy - jak ważny dla nich jest zysk tego 1%.

Jeśli rozumiemy problem i jesteśmy w stanie opisać problem z pomocą mierników które są istotne z punktu widzenia interesariuszy oraz przypisać informację o koszcie tego rozwiązania, możemy porównać ze sobą różne strategie i wybrać tą najlepszą.

Co to znaczy najlepsza strategia? Możemy albo maksymalizować zysk albo zminimalizować koszt. W naszym wypadku zależało nam na balansowaniu pomiędzy tymi dwoma kryteriami.

W jaki sposób wybrać najlepszą z dostępnych strategii?

Popatrzcie:

  • Strategia A wymaga od programisty zainwestowania 5h pracy i daje zysk 148h (99%) plus dodatkowy czas na poprawki.
  • Strategia B wymaga od nas 0 (zero) h pracy deweloperskiej, 1 h czasu na wytłumaczenie jak to działa i daje zysk 40 godzin pracy (50% miernika), ale jest obarczona dużym ryzykiem popełnienia błędu w trakcie pracy.

Lepsza jeśli chodzi o impact i korzyść jest bez wątpienia strategia A.