Aplikacje

Współpraca z Klientem zaczyna się zwykle od przeczytania maila z opisem jego problemu (nie odbieram połączeń z nieznanych numerów). Po zapoznaniu się z meritum (wymiana kilku maili) umawiam się z Klientem na spotkanie wstępne lub rozmowę on-line. Może się jednak zdarzyć, że projekt jest mały i maile wystarczą.

Jeśli projekt wymaga większych konsultacji, to pojawiam się w Firmie Klienta. Tam często jestem oprowadzany po liniach produkcyjnych, albo omawiamy projekt w biurze na projektorze.

W przypadku, gdy spotkanie nie jest możliwe, preferuję sesję on-line na TeamViewer.

Gdy już wiem jakie są główne bolączki Klienta, pierwszą rzeczą jaką robię jest checklista problemów tzn. zadań do wykonania.

W przypadku aplikacji do zarządzania zajęciami była ich cała masa. Wiedziałem, że:
⬜️ aplikacja ma służyć na lata, a nie działać tylko dla bieżącego semestru
⬜️ liczba zajęć w planie musi się zgadzać z narzuconą przez MEN siatką godzin dla przedmiotów
⬜️ nauczyciele mają swoje biznesy, więc mogą pracować tylko w wybranych terminach
⬜️ nauczyciel nie może mieć przypisanych dwóch lub więcej zajęć w tym samym terminie
⬜️ nauczyciel musi mieć przynajmniej jedną wolną niedzielę w miesiącu
⬜️ nauczyciel może pracować maksymalnie pięć dni w tygodniu
⬜️ w danej sali nie mogą się odbywać w tym samym czasie różne zajęcia
⬜️ nie każda sala jest wystarczająco pojemna, aby pomieścić całą klasę
⬜️ trzeba wziąć pod uwagę zastępstwa (L4) i zmiany nauczycieli w trakcie semestru
⬜️ aplikacja powinna tworzyć spersonalizowane raporty dla uczniów i nauczycieli

Dokładniej te problemy opisałem w osobnej notce na BLOGU

Oczywiście to tylko wierzchołek góry lodowej, dużo rzeczy wyszło nam też w trakcie prac.

Ta część jest niezmiernie ważna przy każdym większym projekcie. Należy dobrze przemyśleć logikę działania całej aplikacji, rozpisać to sobie, rozrysować. Zastanowić się nad budową poszczególnych plików i arkuszy, a także nad powiązaniami pomiędzy nimi.

Pośpiech jest tutaj złym doradcą. Lepiej poświęcić nieco więcej czasu teraz, niż wykonać 50% projektu i stwierdzić, że poszliśmy w złym kierunku i trzeba wrócić do początku….

W przypadku aplikacji dla Szkoły, wiedziałem, że będę potrzebował kilka ważnych rzeczy:
🟩 rozbudowanego formularza, w którym Pani X (operator programu) będzie mogła dodać zajęcia do konkretnej komórki w arkuszu.
🟩 szablonu/grafika, do którego Pani X będzie przenosić dane z formularza. Wiedziałem jednak, że zanim Pani X zacznie pracę nad dodawaniem zajęć, inne makro musi wcześniej wgrać pusty terminarz na nowy semestr (kilkanaście tygodni do przodu licząc od daty startowej). Chodzi o kolumny B:G. Oprócz tego, do osobnego wiersza (nr 10) makro będzie mi wgrywać klasy utworzone w nowym semestrze. Dla każdej klasy przeznaczyłem dwie kolumny: z nazwą zajęć i numerem sali.

🟩 arkusz, który będzie mi konwertował dane z GRAFIKA do tabeli bazodanowej. Absolutnie NIEZBĘDNA rzecz, aby potem dokonywać jakichkolwiek obliczeń na danych z GRAFIKA.
🟩 arkusz z siatką zajęć dla każdej klasy
🟩 arkusz z aktualną listą nauczycieli i zgłoszonymi terminami absencji
🟩 kilka innych arkuszy pomocniczy i raportujących

Nie jest to część odpowiadająca za komunikację z użytkownikiem. Chodzi tutaj o zaprojektowanie wyglądu i układu formatek/szablonów, do których makra będą zrzucać przetworzone dane lub je stamtąd odczytywać.

W przypadku naszej aplikacji musiałem zaprojektować szablony XLTM (osobne pliki) dotyczące m.in. miesięcznej ewidencji czasu pracy nauczyciela, planu lekcji dla ucznia czy planu lekcji dla nauczyciela. Do tych formatek dane są zapisywane i powstają osobne raporty.

W pliku głównym zaś chodziło o przygotowanie wyglądu arkuszy, które opisałem w poprzednim punkcie. W przypadku arkusza NIEOBECNOŚCI czy SZKOŁA chodziło o odczyt danych. Odpowiednio – zgłoszonych nieobecności i siatki zajęć dla klas.

Interfejs aplikacji (jak wskazuje nazwa) to zespół narzędzi, które odpowiadają za komunikację pomiędzy użytkownikiem, a programem.

Do najważniejszych elementów interfejsu aplikacji EXCEL/VBA należą:
🟨 formularze użytkownika tzw. USERFORMS – ich celem jest głównie pobieranie informacji od operatora programu
🟨 osobna karta na wstążce lub dedykowana wstążka – tutaj mamy całą gamę kontrolek, chociaż Klienci często życzą sobie aby na wstążce znajdowały się tylko przyciski (DUŻE!). Wynika to z faktu, że aplikacje często są obsługiwane przez osoby, które słabo poruszają się w Excelu. Stąd prośba, aby wstążka była maksymalnie uproszczona i łatwa w obsłudze. Oprócz przycisków możemy jednak umieszczać na wstążce np. listy rozwijane, galerie, pola tekstowe, przyciski opcji czy pola wyboru.
🟨 kontrolki osadzone w arkuszu (formanty ActiveX lub formanty formularza) – w mniejszych aplikacjach zastępują one USERFORMS, ale dają mniejsze możliwości i gorzej się prezentują
🟨 różne narzędzia Excelowe np. sprawdzanie poprawności lub formatowanie warunkowe
🟨 Opcjonalnie! Menu podręczne czyli wyskakujące menu (pop-up), które może się pojawić np. po kliknięciu w prawy klawisz myszy lub dwuklik. W praktyce zdarzają się rzadko, natomiast dawniej (gdy nie było wstążki) stanowiły podstawę interfejsu aplikacji wraz z paskami narzędzi i paskiem menu.

W przypadku aplikacji dla Szkoły zaprojektowałem formularz, który jest tak naprawdę “mózgiem” całego programu + kilka innych formularzy pomocnych przy generowaniu raportów.

Powstała także osobna wstążka do zarządzania aplikacją.

W końcu dotarliśmy do części programistycznej, bo nasze wszystkie pomysły musimy zacząć w końcu wcielać w życie.

Kod może znajdować w następujących miejscach.
🟦 moduły zwykłe – nie są związane z żadnym obiektem Excela – umieszcza się tam makra, które przypisane są do odpowiednich kontrolek na wstążce, ale też makra i funkcje pomocnicze czy stałe globalne. PS. Do jednego przycisku często przypina się makro główne, które składa się z kilku mniejszych procedur.
🟦 moduły formularza – to jest oprogramowanie całego formularza i jego kontrolek
🟦 moduły arkusza – chodzi o uruchomienie makra w momencie zajścia określonego zdarzenia w obrębie tego arkusza np. zmiana komórki lub zmiana zaznaczenia. W przypadku kontrolek ActiveX osadzonych w arkuszu, kod musi znajdować się właśnie w module arkusza, w którym osadzona jest kontrolka.
🟦 moduł skoroszytu – chodzi o uruchomienie makra w momencie zajścia określonego zdarzenia w obrębie pliku np. w momencie jego otwarcia, zamknięcia, zapisu czy próbie wydruku.
🟦 moduły klas – zaawansowany temat – stosujemy wtedy gdy chcemy używać własnych obiektów

W przypadku aplikacji do zarządzania zajęciami większość kodu znajduje się w modułach zwykłych. Poniżej wklejam screen z listą makr zawartą w Module 1. Chodzi w nim o wyczyszczenie starych danych i przygotowanie formatki pod nowy semestr. Temu zadaniu przypisany jest pierwszy przycisk na wstążce.

W aplikacji mam cztery formularze, więc każdy z nich zawiera odpowiedni kod. Zwłaszcza bardzo obszerny jest kod dotyczący formularza UGrafikZajec. Jak wspomniałem, jest to “mózg” całej aplikacji.

Mam także kod zawarty w modułach niektórych arkuszy. Chodzi tam głównie o aktualizację pewnych zakładek w momencie zmian w arkuszu SZKOŁA (np. dodanie zastępstw) i konwersję GRAFIKA ZAJĘĆ do tabeli bazodanowej. Musi się to odbywać niejako “w locie”.

W aplikacji nie użyłem modułów klas, ani zdarzeń poziomu skoroszytu.

Końcową fazą jest zawsze testowanie aplikacji, najpierw robię to u siebie, później wspólnie robimy testy u Klienta. Tutaj sprawdzamy różne hipotezy i scenariusze wydarzeń, przewidujemy i notujemy ewentualne rzeczy do skorygowania.

Przy tak zaawansowanym projekcie, niektóre rzeczy wychodzą też “w praniu”. Może się zdarzyć, że pewnych rzeczy w ogóle na wstępie nie wzięliśmy pod uwagę, mogą się też pojawić jakieś nowe okoliczności np. dodanie szkoły weekendowej. ŻYCIE!

Osobiście bardzo lubię tą fazę projektu.

A tu dla odmiany etap, którego najbardziej nie lubię, czyli tworzenie instrukcji obsługi i dokumentacji. Jest on jednak niezbędny, aby w przyszłości łatwiej i szybciej poradzić sobie w przypadku trudności z działaniem aplikacji.

Jak jednak wspomniałem w innej notce Klienci nie lubią czytać instrukcji – zazwyczaj piszą do mnie maila lub dzwonią. Chcą szybko rozwiązać problem.

Opisałem najważniejsze etapy pracy nad aplikacją. Jest to pewien proces, ale poszczególne etapy się tutaj przenikają. Można pracować nad interfejsem, ale nagle zachodzi potrzeba zmian w układzie arkusza. Można zająć się programowaniem, ale okazuje się, że trzeba jeszcze dodać jakieś kontrolki na formularzu.

Jak widać, jest to masa roboty na każdym polu. Niestety często zdarzają mi się Klienci dyletanci, którzy po trzygodzinnym spotkaniu konkludują: Ale to nie powinno być takie trudne? Albo co gorsza. Chcą “kombajn”, a myślą, że chcą “kosiarkę” i kwitują całą rozmowę tekstem: Kilka makr powinno wystarczyć?… To właśnie im dedykuję ten wpis 😂

PS. Jeśli chcesz mi zlecić aplikację – dobrze by było gdybyś znał orientacyjny budżet na ten projekt. Wtedy ja mógłbym zaproponować rozwiązanie adekwatne do ceny. Rozbieżności często są duże i wg mnie szkoda tracić czas na takie wielogodzinne spotkanie. Szanujmy się.

W praktyce natomiast świetnie sprawdza się schemat, że najpierw Klient zgłasza się do mnie z (faktycznie!) małym projektem. A potem, widząc efekty, decyduje się na rozbudowę. Tak właśnie było z KADRĄ – zaczęliśmy od prostej tabeli liczącej godziny pracy nauczycieli. Potem zrobiliśmy formularz, całą aplikację do zarządzania zajęciami, moduł do monitorowania frekwencji (praktycznie 30% projektu), a na końcu jeszcze moduł do zatrudniania nauczycieli i księgę uczniów.

Problem/Rozwiązanie:

Aplikacja pomogła Szkole rozwiązać problemy związane z układaniem planu zajęć dla 20-kilku klas (szkoła dzienna, zaoczna i wieczorowa).

Narzędzie uwzględnia wiele warunków: m.in. zgłoszone przez nauczycieli terminy nieobecności (cykliczne i losowe), kolizje terminów (nauczyciel ma już w grafiku przypisane zajęcia z inną klasą), ustawowy obowiązek przynajmniej jednej wolnej niedzieli w miesiącu i maksymalnie 5-dniowy tydzień pracy.

Do tego dochodzą inne założenia: właściwy dobór sal (brak kolizji i uwzględnienie pojemności) czy pokrycie liczby godzin w grafiku z narzuconą przez Ministerstwo siatką godzin dla przedmiotów.

Oprócz zarządzania grafikiem zajęć, aplikacja generuje raporty dla uczniów i nauczycieli, pomaga zarządzać zatrudnieniem i prowadzi ewidencję czasu pracy….

Projekt zakończył się sporym sukcesem, więc Szkoła zleciła mi do wykonania osobny moduł do monitorowania i raportowania frekwencji uczniów, a także modyfikację aplikacji do zarządzania księgą ucznia.

Więcej na temat aplikacji napisałem w osobnym wpisie na blogu
https://www.swiatexcela.pl/2019/08/27/135-aplikacja-do-zarzadzania-szkola-w-excelu-to-mozliwe

Referencja:

Czas realizacji: 3,5-4 miesiące
Skala trudności: 9/10

Problem/Rozwiązanie:

Problemem przedsiębiorstwa był zakup odpowiedniej ilości stali, zazwyczaj zamawiano jej zbyt dużo. Dzięki wdrożeniu aplikacji firma zyskała podwójnie – zaoszczędziła czas i pieniądze.

Celem aplikacji była optymalizacja zakupu belek stalowych, tak aby zminimalizować pozostałości (odpad).

Sprzedawcy oferują belki w kilku różnych wymiarach – kupujący zazwyczaj potrzebuje jednak zupełnie innych długości. Aplikacja OPTISTAL nie tylko pokazuje jakie belki należy kupić (i w jakich ilościach), ale również pokazuje jak należy pociąć każdą belkę!

Raport dla nawet najbardziej skomplikowanego zamówienia powstaje w kilka sekund. Program zawiera bardzo dużo ustawień pomocniczych np. podanie potrzebnych długości wraz z ilościami, edycję dostępnych u sprzedawcy długości wraz z ilościami (może się zdarzyć, że dysponuje on tylko kilkoma sztukami belki określonej długości), utworzenie raportu cenowego i jego eksport.

Produkt nie korzysta z SOLVERA (pierwsze wersje aplikacji bazowały na nim, ale przeliczanie trwało bardzo długo i nie zawsze kończyło się zwróceniem zadowalających wyników), tylko z konkretnego algorytmu sortującego, który przenosi praktycznie cały odpad na ostatnią belkę. W ten sposób aplikacja daje znakomite wyniki w przypadku zamówień bardzo złożonych.

Program przez pewien czas również znajdował się w sprzedaży i miał swoją dedykowaną stronę. Ostatecznie jednak zrezygnowałem z jego promowania ponieważ praca nad nim pochłaniała mi zbyt wiele czasu.

Czas realizacji: 5-6 miesięcy
Skala trudności: 10/10

Problem/Rozwiązanie:

Problemem korporacji był zbyt długi czas, jaki pracownik HR przeznaczał na rozliczanie delegacji. Co więcej, było to wykonywane manualnie, co przy skomplikowanych założeniach, zazwyczaj kończyło się błędami i późniejszą korektą…

Biorąc pod uwagę, że wyjazdy były częste, Firma zdecydowała się zlecić mi zautomatyzowanie tej czynności.

Idea była taka, że pracownicy będą rozliczać się sami. Ich zadaniem będzie przyniesienie gotowego, wydrukowanego dokumentu (z paragonami) do sprawdzenia…

Aplikacja bazuje na dwóch rozbudowanych szablonach (oszacowanie + rozliczenie kosztów), pliku z historią kursów kilkudziesięciu walut, pliku dla HR i pliku do nadawania unikatowych numerów delegacjom (osobna numeracja dla kraju i zagranicy).

Narzędzie przenosi dane z arkusza do specjalnego szablonu (formularz rozliczenia delegacji), który jest gotowy do wydruku.

Program zezwala na wpisywanie pozycji kosztowych w dowolnej walucie, prawidłowo wylicza dietę (zależnie od kraju, czasu podróży, ilości posiłków) czy kurs po jakim powinna zostać rozliczona dana pozycja. Aplikacja zawiera wiele szczegółowych założeń.

Czas realizacji: 3 miesiące
Skala trudności: 9/10

Problem/Rozwiązanie:

Korporacja chciała usprawnić proces produkcyjny. Problemem była komunikacja pomiędzy działem produkcji a magazynem.

Często zdarzało się, że magazyn nie dostarczał na czas odpowiedniej ilości danego komponentu, co skutkowało przestojem…

Stworzyłem aplikację, która na bazie pliku źródłowego z SAP tworzy raporty opóźnień w zamówieniach.

Od teraz każda linia produkcyjna posiada swój osobny raport, który jest wyświetlany na wielkim monitorze. Opóźnienia są posortowane malejąco, więc magazyn wie, które zamówienia są priorytetowe….

Aplikacja była z czasem rozbudowywana. Dodaliśmy m.in. możliwość tworzenia raportów łączonych (kilka linii na jednym raporcie) i możliwość rotacji komponentów pomiędzy liniami (pominięcie magazynu).

Czas realizacji: 2 miesiące
Skala trudności: 8/10

Problem/Rozwiązanie:

Następne aplikacje, których celem było usprawnienie procesu produkcyjnego.

Tym razem korporacja chciała kontrolować dostępny zapas wyrobów gotowych… Na wykresie zestawiamy aktualną ilość z poziomem maksymalnym (nadprodukcja), minimalnym (niedobór) i krytycznym (zagrożenie).

Program umożliwia dostosowanie layoutu pod własne potrzeby (wyświetlanie w sztukach lub kanbanach, ukrycie/odkrycie pól).

Projekt okazał się sukcesem, więc Klient zdecydował się, aby podobną aplikację stworzyć do wizualizacji poziomu zapasów komponentów.

Czas realizacji: 2 miesiące
Skala trudności: 8/10

Problem/Rozwiązanie:

Firma wydzieliła na magazynie dwa regały, aby przetestować nowy sposób rozlokowania towaru…. 

Aplikacja, którą opracowałem sugeruje rozmieszczenie towaru (palety euro vs. “drobnica”) w wyznaczonym do tego celu miejscu (adres składa się z nazwy regału, kolumny i poziomu) uwzględniając priorytet nadany przez operatora programu.

System nie tylko decyduje o tym jak mają zostać rozmieszczone nowe dostawy, ale również rejestruje wydania towaru i korekty ilości. Dzięki temu firma cały czas monitoruje zapasy na magazynie.

Aplikacja dla każdego typu operacji drukuje m.in. nowe etykiety (z kodami kreskowymi) z aktualną ilością towaru czy np. kartę z potwierdzeniem odebrania towaru.

Czas realizacji: 1,5-2 miesiące
Skala trudności: 8/10

Problem/Rozwiązanie:

Korporacja miała problem z ustaleniem rzeczywistego czasu pracy swoich pracowników.

Poza tym potrzebny był mechanizm, który sprawdzałby zgodność planu (system ADP) z realizacją (RCP). Chodziło głównie o sytuacje, w których pracownik miał przyjść do pracy, a nie przyszedł i vice versa.

Firma chciała aby raporty z rejestrem czasu pracy pracowników były wysyłane do przypisanych im TeamLeaderów, zaś zbiorczy plik do osób z HR….

Zaprojektowałem aplikację, która najpierw zaczytuje dane z plików tekstowych (chronologiczny rejestr tzw. “odbić” kartą – system generuje 3 pliki dziennie), następnie tworzy tabelę z rejestrem czasu pracy dla każdego pracownika i porównuje te dane z systemem ADP (moduł przechowujący dane o planowanych nieobecnościach).

Następnie każdy z kilkunastu TeamLeaderów otrzymuje mailem raport XLSX z informacją na temat czasu pracy podległych mu pracowników. Raport dotyczący wszystkich pracowników jest również wysyłany do wyznaczonych osób z HR.

Czas realizacji: 2 miesiące
Skala trudności: 8/10

Problem/Rozwiązanie:

Planista produkcji miał problem z precyzyjnym wyliczeniem sztuk wyrobów gotowych, jakie mają zostać wyprodukowane. Szacował to orientacyjnie.

Raport tekstowy generowany z SAP był zbyt ogólny i pokazywał jedynie pewne okresy, w których należy produkować dany wyrób….

Przygotowałem aplikację, która w pierwszej kolejności usuwa dane, które nie należą do danego tygodnia produkcyjnego. Następnie oblicza rzeczywisty czas pracy na każdej zmianie (eliminuje przerwy potrzebne np. na przezbrojenie maszyn) i rozbija plan proporcjonalnie do niego.

Następnie wyniki są zaczytywane do specjalnych formatek.

Zyskiem dla firmy niewątpliwie jest lepsza organizacja i kontrola produkcji, co przekłada się na oszczędność wynikającą z braku opóźnień.

Czas realizacji: 1 miesiąc
Skala trudności: 6/10

Problem/Rozwiązanie:

Problemem korporacji była rejestracja komponentów, które uległy uszkodzeniu w procesie produkcyjnym i wymagają zezłomowania….

Aplikacja, którą zaprojektowałem w sprawny sposób pozwala zaczytywać z formularza (tryb pojedynczy) lub formatki (tryb masowy) referencje, które mają ulec zezłomowaniu.

W następnym etapie drukuje formularz potwierdzający, a także dodaje dane do pliku z historią zezłomowanych komponentów.

Dzięki temu ostatniemu plikowi firma otrzymuje zbiorcze statystyki dotyczące m.in. przyczyn zezłomowania (tzw. kody błędów), kosztów (wartość komponentów jak i MPK), metod likwidacji czy lokalizacji, w której sprzęt ma zostać zutylizowany.

Czas realizacji: 1 miesiąc
Skala trudności: 5/10

Problem/Rozwiązanie:

Korporacja chciała przeprowadzić badanie wśród swoich pracowników na temat istniejących warunków pracy…

Dzięki ankiecie złożonej z 70-pytań (10 kategorii), sprawdziliśmy jak poszczególne obszary są oceniane przez pracowników.

Oprócz oceny bieżącej sytuacji, badana była również ważność danego zagadnienia. Dzięki takiemu porównaniu, firma dostrzegła różnice pomiędzy  potrzebami pracowników, a stanem faktycznym.

W odpowiedzi wdrożyła odpowiednie działania naprawcze. Dane były analizowane ogólnie, jak również ze względu na konkretne zmienne tj. płeć, przedział wiekowy, wykształcenie, staż pracy, stanowisko, dział.

W anonimowej ankiecie wypełnianej w całości na komputerze (pracownik nie musiał nawet dotykać klawiatury – tylko mysz) wzięło udział kilkuset pracowników.

Czas realizacji: 1 miesiąc
Skala trudności: 6/10