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.

  1. 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

  2. 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.

  3. 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.

  4. 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.

  5. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  1. 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.

  2. 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.

  3. 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.

Schemat poglądowy jednej sprawy w systemie.
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.

  1. 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.

  2. 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ę.

  3. 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.

  4. 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.

  5. 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 integracje

    Połączenie istniejących systemów, bez budowania nowego narzędzia.

  • Nietypowa funkcja dotyczy sklepu: konfigurator produktu, zasady koszyka, obsługa zamówień.

    E-commerce

    Wszystko, 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 WWW

    Strona 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 IT

    Infrastruktura 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.
Pulpit IKTEL Flow: powitanie pracownika, licznik 7 elementów wymagających uwagi i lista zadań i zgłoszeń z terminem, statusem i priorytetem.
Pulpit IKTEL Flow: powitanie pracownika, licznik 7 elementów wymagających uwagi i lista zadań i zgłoszeń z terminem, statusem i priorytetem.
Pulpit: najpierw sprawy, które mogą zablokować pracę
  • Zadanie w IKTEL Flow: zakres pracy, dyskusja oraz plan wykonania z osobą przypisaną, zlecającym, działem, terminem i przyciskami zakończenia lub anulowania zadania.
    Zadanie w IKTEL Flow: zakres pracy, dyskusja oraz plan wykonania z osobą przypisaną, zlecającym, działem, terminem i przyciskami zakończenia lub anulowania zadania.
    Zadanie
  • Zgłoszenie w IKTEL Flow: rozmowa z wpisami zespołu i karta sprawy z osobą przypisaną, działem zgłaszającym, kategorią i działem odpowiedzialnym.
    Zgłoszenie w IKTEL Flow: rozmowa z wpisami zespołu i karta sprawy z osobą przypisaną, działem zgłaszającym, kategorią i działem odpowiedzialnym.
    Zgłoszenie
  • Kalendarz w IKTEL Flow w widoku agendy: przełączniki Miesiąc, Tydzień, Dzień i Agenda, filtr zadań i wydarzeń oraz wydarzenia dnia z godzinami.
    Kalendarz w IKTEL Flow w widoku agendy: przełączniki Miesiąc, Tydzień, Dzień i Agenda, filtr zadań i wydarzeń oraz wydarzenia dnia z godzinami.
    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ąć.