Software i aplikacje
Oprogramowanie dla firm, które wyrosły z gotowych programów.
Gdy obok programu powstaje arkusz, zgody krążą mailem, a status sprawy zna tylko jedna osoba, zespół pracuje pod ograniczenia narzędzia. Projektujemy i budujemy aplikacje webowe i systemy, które obsługują Twój proces — razem z jego danymi, rolami i wyjątkami.
Po czym poznać, że firma wyrosła z gotowego programu?
Zwykle nie po awarii, tylko po zdaniach, które zespół powtarza na co dzień.
-
„Tego nie ma w programie, więc trzymamy to w arkuszu.”
Obok systemu powstał drugi, nieoficjalny — i to on jest aktualny. Dane trzeba przenosić między nimi, a o błąd nietrudno.
-
„Zapytaj w biurze, oni wiedzą, na jakim to jest etapie.”
Status sprawy istnieje w czyjejś głowie, a nie w systemie. Gdy tej osoby nie ma, proces stoi.
-
„U nas ten przypadek robi się inaczej — ręcznie.”
Wyjątek, który zdarza się co tydzień, program traktuje tak, jakby go nie było. Każdy obsługuje go po swojemu.
-
„Do tego trzeba dokupić jeszcze jeden dodatek.”
Kolejne wtyczki łatają braki, ale nie układają procesu. Każda aktualizacja jest ryzykiem, a całość coraz trudniej ogarnąć.
-
„Pokażę Ci, jak to robimy naprawdę, bo w programie wygląda to inaczej.”
Nowa osoba uczy się obejść, a nie narzędzia. Wiedza o procesie jest w ludziach, nie w systemie.
Jeden taki sygnał nie oznacza, że potrzebujesz nowego systemu — czasem wystarczy inaczej ustawić obecny. Kilka naraz to znak, że warto sprawdzić, czy narzędzie nadal pasuje do sposobu pracy.
Czy system pasuje do procesu, czy proces do systemu?
Firma ma swój proces: zlecenie, wycena, akceptacja, realizacja, rozliczenie. Gotowy program często obsługuje tylko część tych kroków, a resztę przejmują arkusz, mail i pamięć pracowników. Dedykowany system zaczyna od procesu, a nie od tego, co przewidział program.
Przykład — kroki, role i nazwy modułów zależą od firmy.
-
Dziś: proces dopasowuje się do programu
Zlecenie mieści się w karcie klienta. Reszta dzieje się obok: wycena w arkuszu, zgoda w mailu, status w czyjejś głowie, rozliczenie w ręcznym zestawieniu.
proces → obejście → arkusz → program → ręczna decyzja → kolejny program
-
Najpierw proces, potem ekrany
Projekt zaczyna się od kroków, danych i decyzji, a nie od pól, które oferuje program. Każde obejście pokazuje, czego narzędzie nie obsługuje.
-
Moduły na miarę kroków
Wycena dostaje kalkulację, akceptacja — własny krok z progiem kwoty. Arkusz i maile przestają być potrzebne, bo ich zadanie przejmuje system.
-
Stany, role i historia
Każde zlecenie ma stan widoczny dla wszystkich, osobę, która ma teraz ruch, i historię zmian. Status nie mieszka już w niczyjej głowie.
-
Po: system pasuje do procesu
Zlecenie przechodzi przez jeden system, od przyjęcia do rozliczenia. Dane, role, stany i kolejne akcje są tam, gdzie dzieje się praca — obok nie zostaje nic do pilnowania.
proces → jeden system: dane, role, stany, akcje
-
Zlecenie
- Proces wymaga
- zlecenie razem z mailem, załącznikami i ustaleniami z rozmowy.
- Gotowy program daje
- kartę klienta z polem na notatkę.
- Obejście
- niepotrzebne — ten krok program obsługuje.
System dopasowany
Moduł zleceń: treść, pliki i ustalenia w jednym miejscu, od razu przy kliencie.
-
Wycena
- Proces wymaga
- wycena zależna od materiału, ilości i terminu.
- Gotowy program daje
- jedno pole „kwota”.
- Obejście
- Arkusz z wyceną — w systemie dopasowanym niepotrzebne.
System dopasowany
Kalkulacja w module wycen. Wynik i jego założenia zapisują się przy zleceniu.
-
Akceptacja
- Proces wymaga
- kierownik zatwierdza wyceny powyżej ustalonej kwoty.
- Gotowy program daje
- brak kroku zatwierdzenia.
- Obejście
- Zgoda mailem — w systemie dopasowanym niepotrzebne.
System dopasowany
Wycena powyżej progu czeka na zatwierdzenie. Kierownik widzi ją na swojej liście.
-
Realizacja
- Proces wymaga
- każdy wie, na jakim etapie jest zlecenie i kto ma teraz ruch.
- Gotowy program daje
- listę zadań niepowiązaną ze zleceniem.
- Obejście
- Status w głowie — w systemie dopasowanym niepotrzebne.
System dopasowany
Każde zlecenie ma stan widoczny dla wszystkich, osobę odpowiedzialną i historię zmian.
-
Rozliczenie
- Proces wymaga
- część zleceń rozlicza się etapami.
- Gotowy program daje
- jedną fakturę na koniec.
- Obejście
- Ręczne zestawienie — w systemie dopasowanym niepotrzebne.
System dopasowany
Etapy rozliczeń przy zleceniu. Dane do faktury przechodzą dalej bez przepisywania.
Po: system pasuje do procesu
Zlecenie przechodzi przez jeden system, od przyjęcia do rozliczenia. Dane, role, stany i kolejne akcje są tam, gdzie dzieje się praca — obok nie zostaje nic do pilnowania.
Nie każdy problem wymaga własnego systemu
Zaczynamy od najmniejszej zmiany, która rozwiąże problem. Własne oprogramowanie ma sens dopiero wtedy, gdy gotowe narzędzie realnie ogranicza proces.
-
Wykorzystać gotowe narzędzie
Kiedy: program ma potrzebne funkcje, tylko nikt nie ustawił ich pod Waszą pracę.
Co robimy: konfiguracja, porządek w danych i uprawnieniach, krótkie szkolenie zespołu.
-
Rozszerzyć to, co działa
Kiedy: program dobrze obsługuje większość procesu, a brakuje jednego elementu.
Co robimy: dodatek, moduł albo wtyczka dopisana do obecnego systemu — bez wymiany całości.
-
Zbudować własny system
Kiedy: obejścia stały się sposobem pracy, a kolejne dodatki niczego nie porządkują.
Co robimy: aplikacja lub system zaprojektowany wokół procesu: jego danych, ról i wyjątków.
Jeśli Twoje programy dobrze obsługują swoje zadania, a problemem jest przepisywanie danych między nimi — to nie jest powód do budowania nowego systemu. To zadanie dla automatyzacji i integracji.
System to nie tylko ekrany
Strona internetowa prowadzi klienta do kontaktu. System obsługuje pracę, która zaczyna się potem — a najważniejsze dzieje się pod spodem: dane, stany, odpowiedzialność i decyzje.
- Dane
- Wszystko o sprawie w jednym miejscu: zakres, pliki, ustalenia i wyliczenia — bez szukania po skrzynkach i arkuszach.
- Stan
- Każda sprawa jest na konkretnym etapie, widocznym dla wszystkich. System pilnuje, żeby nie przeskoczyła kroku, który wymaga decyzji.
- Odpowiedzialność i następny krok
- Wiadomo, kto ma teraz ruch i co ma zrobić. Sprawa nie czeka, aż ktoś sobie o niej przypomni.
- Role
- Handlowiec, kierownik i księgowość pracują na tej samej sprawie, ale każdy widzi i zmienia to, czego potrzebuje.
- Wyjątki
- Nietypowy przypadek ma swoją ścieżkę w systemie, zamiast notatki na marginesie.
- Historia
- Kto, co i kiedy zmienił. Po miesiącu da się odtworzyć, dlaczego zapadła decyzja.
Pierwsza wersja nie musi obsługiwać wszystkiego
Często lepiej zacząć od fragmentu procesu, który dziś sprawia najwięcej kłopotu, sprawdzić go w codziennej pracy i dopiero wtedy rozwijać dalej. Tak działa MVP — pierwsza wersja z najważniejszymi funkcjami, a nie okrojony prototyp.
Co możemy zbudować
- aplikację webową dla zespołu, dostępną z przeglądarki
- panel dla klientów albo partnerów
- narzędzie wewnętrzne do jednego procesu
- moduł, który rozszerza program, którego już używasz
Co wchodzi w projekt
- analiza procesu i wymagań
- model danych, ról i uprawnień
- projekt interfejsu sprawdzony z użytkownikami
- logika biznesowa, wyjątki i połączenia z obecnymi programami
- testy, wdrożenie i przeniesienie danych
- dalszy rozwój po starcie
Co wpływa na zakres i wycenę
- ile kroków procesu obejmuje pierwsza wersja
- liczba ról i to, kto co może widzieć
- wyjątki i reguły, które system ma pilnować
- dane do przeniesienia ze starych narzędzi
- programy, z którymi system ma się łączyć
Technologię dobieramy do rozwiązania, a nie rozwiązanie do technologii. Przed startem mówimy wprost, na czym budujemy i dlaczego.
Od procesu do działającego systemu
Zaczynamy od tego, jak praca wygląda dziś, a nie od technologii. Każdy etap kończy się czymś, co możesz ocenić, zanim pójdziemy dalej.
-
Problem i proces
Poznajemy proces takim, jaki jest naprawdę: kto co robi, gdzie powstają dane, które kroki dzieją się poza programem i jakie wyjątki są częste.
Po tym etapie masz: opis procesu z zaznaczonymi obejściami i odpowiedź, czy potrzebny jest własny system, czy wystarczy zmienić obecny.
-
Wymagania i model
Ustalamy, jakie dane system przechowuje, przez jakie stany przechodzi sprawa, kto co widzi i co zatwierdza. Wybieramy fragment procesu na pierwszą wersję.
Po tym etapie masz: zakres pierwszej wersji, model danych i ról oraz wycenę.
-
Prototyp i projekt
Projektujemy ekrany na prawdziwych przykładach z Twojej firmy i sprawdzamy je z osobami, które będą z nich korzystać.
Po tym etapie masz: projekt interfejsu przetestowany przez przyszłych użytkowników, zanim powstanie kod.
-
Implementacja i testy
Budujemy system etapami i pokazujemy postęp na działającej wersji. Testujemy na realnych przypadkach, także tych nietypowych.
Po tym etapie masz: działającą aplikację sprawdzoną przez Twój zespół na przykładach z codziennej pracy.
-
Wdrożenie i rozwój
Przenosimy potrzebne dane, uruchamiamy system i jesteśmy przy zespole na starcie. Potem dokładamy kolejne fragmenty procesu.
Po tym etapie masz: system, w którym zespół pracuje na co dzień, i plan kolejnych etapów.
Kiedy to już inny zakres
Własny system to nowe narzędzie. Gdy problem da się rozwiązać bez niego, mówimy o tym na początku i prowadzimy temat tam, gdzie pasuje.
-
Programy, których używasz, są dobre — problemem jest przepisywanie danych między nimi.
Automatyzacje i integracjePołączenie istniejących systemów, bez budowania nowego narzędzia.
-
Nietypowa funkcja dotyczy sklepu: konfigurator produktu, zasady koszyka, obsługa zamówień.
E-commerceWszystko, czego przedmiotem jest sklep, prowadzimy jako projekt e-commerce — także wtedy, gdy wymaga pisania kodu.
-
Potrzebujesz przede wszystkim przedstawić ofertę i zbierać zapytania.
Strony WWWStrona prowadzi klienta do kontaktu. Aplikacja obsługuje pracę, która zaczyna się po nim.
-
Chodzi o serwery, konta, licencje albo komputery, na których działają programy.
Wsparcie ITInfrastruktura i codzienna ciągłość pracy firmy.
Nie tylko projektujemy systemy. Jeden rozwijamy sami.
IKTEL Flow to nasz własny system do obsługi zgłoszeń, zadań i terminów zespołu. Budujemy go i rozwijamy na bieżąco — to produkt w trakcie rozwoju, a nie wdrożenie u klienta.
Przy nim projektujemy dokładnie to, co w systemach dla firm: nie same ekrany, ale proces, role i uprawnienia, stany spraw, komunikację w zespole i logikę, która pilnuje terminów. To, czego uczymy się na własnym produkcie, przenosimy do projektów dla klientów.
Zobacz stronę IKTEL Flow- Stany
- Nowe, otwarte, w realizacji, oczekujące. Każda sprawa pokazuje, na jakim jest etapie.
- Role i uprawnienia
- Wykonawca, zlecający, opiekun. Każdy widzi kolejkę spraw dostępnych dla swojego konta.
- Priorytety i terminy
- To, co jest po terminie albo blokuje pracę, trafia na wierzch bez ręcznego pilnowania.
- Komunikacja
- Ogłoszenia, czat i powiadomienia w tym samym miejscu, w którym toczy się praca.
-
Zadanie -
Zgłoszenie -
Kalendarz
Pytania, które słyszymy przed budową systemu
Skąd wiem, czy potrzebuję własnego systemu?
Sygnałem są obejścia, które stały się sposobem pracy: arkusz prowadzony obok programu, zgody w mailach, statusy znane tylko konkretnej osobie, kolejne dodatki, które niczego nie porządkują.
Na pierwszej rozmowie sprawdzamy, czy problem da się rozwiązać konfiguracją, integracją albo rozszerzeniem obecnego narzędzia. Własny system proponujemy dopiero wtedy, gdy te drogi realnie nie wystarczą.
Czy trzeba budować wszystko od zera?
Nie. Często da się rozszerzyć program, który już działa, albo zbudować tylko brakujący moduł obok niego.
Nawet w całkiem nowym systemie korzystamy ze sprawdzonych elementów, takich jak logowanie czy obsługa plików. Piszemy od podstaw to, co jest specyficzne dla Twojego procesu.
Czy można zacząć od małego zakresu?
Tak, i zwykle to najlepszy start. Pierwsza wersja obsługuje fragment procesu, który dziś sprawia najwięcej kłopotu, i od razu trafia do codziennej pracy.
Kolejne części dokładamy na podstawie tego, jak zespół z niej korzysta, a nie na podstawie założeń sprzed startu.
Czy system może współpracować z programami, których już używamy?
Tak. Nowy system może pobierać i przekazywać dane do programu księgowego, sklepu, CRM albo poczty — o ile te programy na to pozwalają.
Przed wyceną sprawdzamy, co udostępniają Twoje narzędzia, i mówimy wprost, co z tego wynika.
Kto rozwija aplikację po wdrożeniu?
Możemy dalej ją rozwijać i utrzymywać — system, który obsługuje proces, zmienia się razem z firmą.
Zasady dostępu do kodu, dokumentacji i ewentualnego przekazania projektu innemu zespołowi ustalamy w umowie, zanim zaczniemy pracę.
Czym różni się aplikacja dedykowana od automatyzacji?
Automatyzacja łączy narzędzia, które już masz, żeby dane przechodziły między nimi same. Aplikacja dedykowana to nowe narzędzie — powstaje wtedy, gdy żaden z obecnych programów nie obsługuje procesu tak, jak on naprawdę przebiega.
W praktyce jedno często uzupełnia drugie: nowy system i tak wymienia dane z programami, które zostają.
TECHNOLOGIA BLIŻEJ CIEBIE
Twój zespół częściej obchodzi program, niż w nim pracuje?
Opisz, co dziś dzieje się obok systemu: arkusze, maile, ręczne zestawienia. Po pierwszej rozmowie wiesz, czy wystarczy zmiana obecnego narzędzia, czy warto zbudować własne — i od którego fragmentu zacząć.