Pytania, które padają na pierwszej rozmowie o audycie, wdrożeniu albo budowie aplikacji. Odpowiadamy tak samo, jak odpowiedzielibyśmy przez telefon. Przykłady pochodzą z naszej praktyki i są zanonimizowane.
Bo „działa" zwykle znaczy: działa dziś i dopóki nic się nie zepsuje.
Audyt sprawdza, co się stanie, gdy zawiedzie serwer, odejdzie kluczowa osoba albo ktoś przejmie hasło. Zamiast ogólnego wrażenia, że jest dobrze, dostajecie listę ryzyk z oceną, ile każde może kosztować, i kolejność działań: co zrobić od razu, co w kwartale, co może poczekać.
Pięć obszarów, w kolejności od tych, które najczęściej zawodzą.
Tak, w zakresie technicznym i procesowym.
Sprawdzamy, gdzie są dane osobowe, kto je przetwarza, jak zbierane są zgody i czy da się to wykazać wobec kontroli. Nie zastępujemy prawnika ani kancelarii. Wskazujemy luki i przygotowujemy materiał, z którym prawnik pracuje szybciej, a Wy płacicie mu za mniej godzin.
W małej i średniej firmie: dwa dni warsztatów, dokument w ciągu tygodnia.
Warsztaty prowadzimy z osobami z kluczowych działów, bo problem rzadko widać z jednego miejsca. Wynikiem jest dokument zawierający:
Ten dokument ma wartość sam w sobie. Możecie z nim pójść do kogoś innego i nie będziemy mieli o to pretensji.
Z praktyki: w firmie handlowej, w której odpowiadaliśmy za IT, powstał pełny rejestr systemów, kont administracyjnych i umów z partnerami, przygotowany przed wygaszeniem wewnętrznego zespołu. Dzięki niemu zarząd wiedział, kto ma klucze do czego i ile kosztuje utrzymanie bez własnego działu.
Wiek sam w sobie nie jest problemem. Problemem jest to, co wiek ze sobą przynosi.
Stary system przestaje dostawać poprawki bezpieczeństwa. Nie łączy się z narzędziami, które pojawiły się później: sklepem, systemem relacji z klientami, kurierami, wymogami podatkowymi. I coraz mniej osób na rynku umie go naprawić. Od pewnego momentu każda zmiana staje się droga i ryzykowna, a firma zaczyna układać procesy pod możliwości systemu, zamiast odwrotnie.
Cztery, i żaden nie pojawia się na fakturze.
Porównaniem dwóch liczb, które da się policzyć w kilka godzin.
Pierwsza to roczny koszt obecnego stanu: godziny pracy ręcznej, przestoje, błędy i serwis. Druga to koszt zmiany wraz z jej utrzymaniem. Często okazuje się, że nie trzeba wymieniać wszystkiego: wystarczy połączyć istniejące systemy albo wymienić jeden wąski element, który blokuje resztę.
Często tak, i sprawdzamy to, zanim wydacie te pieniądze.
Wymiana całego systemu trwa miesiącami i paraliżuje pracę, a rozbudowa u producenta starego oprogramowania bywa droga i powolna. Zanim zdecydujecie, sprawdzamy cztery tańsze drogi:
Efekt zwykle przychodzi w tygodniach zamiast miesięcy, za ułamek wyceny dostawcy, a podstawowy system zostaje nietknięty. Jeśli jednak rozbudowa u producenta jest najlepszą drogą, mówimy to wprost i pomagamy ocenić, czy jej cena jest uzasadniona.
Z praktyki: zamiast rozbudowywać system magazynowy, powstały aplikacje do skanowania i sortowania towaru na kolektorach oraz automatyczny import manifestów dostaw, połączone z systemem magazynowym i ERP.
Z praktyki: obsługa zamówienia w firmie handlowej trwała do siedemdziesięciu dwóch godzin, bo dane przenoszono ręcznie między siedmioma systemami. Po zbudowaniu własnego integratora proces stał się automatyczny, a firma uruchomiła nowy sklep internetowy bez zwiększania zatrudnienia.
Sześć etapów, z czego pierwszy decyduje o całej reszcie.
Z trzech powodów, i wszystkie trzy da się usunąć na starcie.
Najwięcej na początku i przy testach, niewiele pomiędzy.
Warsztaty diagnostyczne wymagają pełnej obecności kluczowych osób. Testy wymagają kilku godzin od każdego działu, którego zmiana dotyczy. W pozostałym czasie wystarczają krótkie spotkania przeglądowe. Konkretny wymiar podajemy w ofercie, bo zależy od liczby zaangażowanych działów.
Od kilkunastu lat wdrażamy i łączymy systemy w firmach handlowych.
ERP, sklepy internetowe, systemy magazynowe, systemy relacji z klientami, integracje z kurierami, bramki płatności i obowiązki podatkowe w rodzaju KSeF. Jeśli używacie czegoś, czego nie znamy, mówimy to wprost na etapie diagnozy i oceniamy, czy projekt wymaga specjalisty od tego konkretnego produktu.
To zależy od tego, kto jej używa i gdzie, a nie od tego, co jest teraz modne.
Zaczynamy od pytania o pracę, nie o technologię. Handlowiec u klienta, magazynier ze skanerem i księgowa przy biurku potrzebują trzech różnych narzędzi, nawet jeśli korzystają z tych samych danych.
Nie zawsze, i to jest najczęstszy kosztowny skrót myślowy.
Dobrze zrobiona aplikacja webowa działa też na telefonie i kosztuje mniej. Aplikacja mobilna ma sens, gdy potrzebny jest aparat, skaner, powiadomienia albo praca bez zasięgu. Najczęściej rekomendujemy start od wersji webowej i dobudowanie mobilnej wtedy, gdy rzeczywiste użycie to potwierdzi.
Przesuń tabelę w bok, aby zobaczyć wszystkie typy aplikacji.
| Porównanie | Webowa | Mobilna | Desktopowa |
|---|---|---|---|
| Kiedy najlepsza | Praca w przeglądarce, także na telefonie | Praca w terenie, aparat, skaner i powiadomienia | Praca na konkretnym komputerze i obsługa urządzeń lokalnych |
| Koszt budowy | Zwykle niższy przy wspólnej wersji na wiele urządzeń | Zależy od platform i funkcji urządzenia | Zależy od systemów operacyjnych i integracji lokalnych |
| Aktualizacje | Wdrażane centralnie na serwerze | Dystrybuowane na urządzenia użytkowników | Instalowane na komputerach użytkowników |
| Praca bez internetu | Możliwa po zaprojektowaniu trybu offline | Możliwa po zaprojektowaniu synchronizacji | Możliwa dla danych i funkcji dostępnych lokalnie |
To dla nas punkt wyjścia, nie dodatek na końcu.
Większość naszej pracy polega na łączeniu aplikacji z ERP, magazynem, sklepem i systemem relacji z klientami tak, żeby dane wpisywać raz. Aplikacja, która tworzy kolejne miejsce do ręcznego wprowadzania danych, zwykle pogarsza sytuację zamiast ją poprawiać.
Z praktyki: zbudowane i działające aplikacje obejmują między innymi skanowanie i sortowanie towaru na magazynie z użyciem kolektorów danych, wsparcie ERP w uzupełnianiu opisów produktów, zdjęć i wideo, rejestrację i zarządzanie czasem pracy, proste obiegi zakupów i wniosków urlopowych, aplikację webową dla działu sprzedaży połączoną z ERP oraz panel wysyłkowy dla magazynu.
System wymaga opieki jak każde urządzenie w firmie.
Aktualizacje, kopie zapasowe, monitorowanie i drobne zmiany po uwagach użytkowników. Bez tego po roku lub dwóch zaczynają się awarie i luki bezpieczeństwa, a koszt powrotu do stanu używalności bywa wyższy niż koszt utrzymania przez cały ten czas.
Zależy od liczby systemów i od tego, jak bardzo firma od nich zależy.
Dla typowej małej firmy handlowej układamy trzy warianty:
Każdy wariant ma określoną liczbę godzin i jasny zakres, żeby zarząd wiedział, za co płaci, i mógł świadomie zejść niżej albo wejść wyżej.
Nie, to częsty i rozsądny model, pod jednym warunkiem.
Utrzymanie z zewnątrz działa dobrze, jeśli istnieje rejestr systemów i dostępów, instrukcje dla użytkowników, opisany sposób zgłaszania problemów oraz ustalony czas reakcji. Bez tego każda zmiana wykonawcy zaczyna się od kilku tygodni odkrywania, jak w ogóle działa firma. Pomagamy to zbudować, zanim wiedza zniknie razem z ludźmi.
Nie powinniście i pracujemy tak, żeby do tego nie doszło.
Kod, dostępy administracyjne i dokumentacja należą do Waszej firmy. Przygotowujemy je w taki sposób, żeby inny wykonawca mógł przejąć system bez zaczynania od zera. Jeśli ktoś buduje rozwiązanie, którego nikt poza nim nie rozumie, to nie jest cecha rozwiązania, tylko model biznesowy.
Z praktyki: dla firmy handlowej wygaszającej własny zespół IT powstał model i budżet utrzymania w trzech wariantach, rejestr systemów, migracja kont administratorów oraz instrukcje użytkownika dla kluczowych aplikacji.
Przez ustalenie dwóch, trzech mierzalnych wskaźników, zanim cokolwiek się zacznie.
Mierzymy ich obecną wartość: czas realizacji zamówienia, liczbę godzin pracy ręcznej tygodniowo, liczbę błędów lub reklamacji, liczbę zamówień na pracownika. Okres zwrotu liczymy jako koszt wdrożenia podzielony przez miesięczne oszczędności pomniejszone o miesięczny koszt utrzymania.
Oszczędności to głównie odzyskane godziny pracy, mniej błędów i wyższa sprzedaż przy tym samym zespole.
Wtedy pokazujemy je jako koszt scenariusza, który nie wystąpi.
Firma nie stanie na tydzień po awarii. Nie zapłaci kary za naruszenie ochrony danych. Nie straci wiedzy po odejściu pracownika. To są liczby, które da się oszacować, a zarząd może je porównać z ceną zabezpieczenia. Nie są pewne, ale nie są też wymyślone.
Gdy automatyzujemy proces, który zdarza się rzadko, albo budujemy aplikację, z której nikt nie będzie korzystał.
Na etapie diagnozy mówimy wprost, które pomysły nie mają uzasadnienia biznesowego. Zdarza się, że po dwóch dniach warsztatów rekomendacja brzmi: nie róbcie tego teraz, zróbcie najpierw coś innego za dziesiątą część kwoty. To też jest wynik audytu, za który zapłaciliście.
Bo audyt, wdrożenie i budowa aplikacji to projekty z początkiem i końcem.
Własny pracownik to stały koszt, opłacalny przy ciągłej pracy rozwojowej. Wykonawca z zewnątrz wnosi doświadczenie z wielu wdrożeń, a firma płaci za efekt, nie za etat. Przy stałym, dużym zapotrzebowaniu na rozwój własny zespół bywa tańszy i mówimy to otwarcie.
Wyceniamy projekt jako pakiet o określonym zakresie i efekcie, nie jako listę godzin.
Wiecie z góry, ile zapłacicie i co dostaniecie. Nie ma rachunku, który rośnie wraz z czasem trwania projektu, bo to ustawia interesy obu stron przeciwko sobie. Utrzymanie po wdrożeniu rozliczamy osobno, w ustalonym miesięcznym wymiarze.
Od krótkiej rozmowy o problemie, bez zobowiązań.
Potem dwa dni warsztatów diagnostycznych zakończonych dokumentem rekomendacji. Ten dokument jest Wasz i ma wartość niezależnie od tego, co zdecydujecie dalej.
Przed dostępem do systemów podpisujemy umowę o zachowaniu poufności.
Przy danych osobowych dochodzi umowa powierzenia przetwarzania. Nie publikujemy nazw klientów ani danych z projektów. Wszystkie przykłady na tej stronie są zanonimizowane z tego samego powodu, dla którego Wasz projekt też będzie.
Robimy to od 2008 roku: najpierw programowanie i wdrożenia, przez ostatnie lata kierowanie działem IT w międzynarodowej firmie handlowej.
Powstała tam integracja siedmiu systemów, sklep B2B i B2C oraz narzędzia dla sprzedaży i magazynu. Rozumiemy perspektywę zarządu, bo sami odpowiadaliśmy za budżet IT i za jego uzasadnienie przed zarządem. Wiemy, jak wygląda rozmowa, w której trzeba wytłumaczyć, dlaczego coś kosztuje tyle, ile kosztuje.
Zespół dobieramy do projektu, nie odwrotnie.
Przy mniejszych sprawach wystarcza jedna osoba i wtedy nie płacicie za resztę. Przy większych wdrożeniach dołączają programiści. Za całość, czyli diagnozę, zakres, kontakt z zarządem i jakość, odpowiada jedna osoba i nie zmienia się ona w trakcie projektu.
Branża ma mniejsze znaczenie, niż się wydaje.
Zamówienia, magazyn, faktury, dane klientów i obieg dokumentów wyglądają podobnie w handlu, e-commerce, logistyce, produkcji i usługach. Różni się słownictwo i przepisy, nie mechanika. Specyfikę Waszej firmy poznajemy na warsztatach diagnostycznych, zanim cokolwiek zaprojektujemy, i to jest właśnie powód, dla którego warsztaty są pierwszym etapem, a nie formalnością.
Napisz je własnymi słowami. Odpowiadamy w ciągu jednego dnia roboczego, także wtedy, gdy odpowiedź brzmi „to nie jest praca dla nas".