System dla firmy może wyglądać kompletnie na podstawie makiety i nadal nie pasować do codziennej pracy. Dopiero realne dane pokazują, czy statusy są jednoznaczne, raporty odpowiadają na właściwe pytania, a koniec miesiąca rzeczywiście zamyka się w jednym procesie.
KERNAL BUSINESS jest osobnym systemem — nie kolejną wersją ERP STAVIA. Powstał wokół pracy KERNAL z klientami, projektami, raportami, wydatkami i budżetem firmy. Etap 12 został odebrany 1 września, ale najważniejsze lekcje nie wynikają z numeru etapu. Wynikają z pracy na prawdziwym obiegu.
Moduł nie jest procesem
Lista klientów, lista projektów i tabela wydatków mogą działać poprawnie jako osobne funkcje. Firma potrzebuje jednak odpowiedzi na pytania przekraczające granice ekranów: którego projektu dotyczy koszt, czy raport został zaakceptowany, jak wydatek wpływa na budżet i czy miesiąc można już zamknąć.
Dlatego rozwój BUSINESS koncentrował się na połączeniach pomiędzy obiektami i odpowiedzialności za następny krok. Wspólny rdzeń nie jest magazynem rekordów. Jest miejscem, w którym klient, projekt, praca i pieniądze tworzą jeden obieg.
Portal klienta ma własną granicę
Klient powinien widzieć informacje potrzebne do współpracy, ale nie wewnętrzne operacje firmy. Portal jest więc osobną warstwą korzystającą z kontrolowanego zakresu danych projektu. To rozdzielenie jest ważniejsze niż próba pokazania wszystkiego jednym typem użytkownika.
Budżet ujawnia brakujące powiązania
Budżet firmy szybko obnaża dane zapisane bez kontekstu. Wydatek bez projektu, okresu albo właściciela może istnieć w bazie, ale nie wspiera decyzji. Raporty kosztowe i obieg miesiąca wymusiły doprecyzowanie powiązań oraz reguł zamknięcia.
Odbiór etapu nie kończy rozwoju
Formalne zamknięcie etapu oznacza, że określony zakres spełnia kryteria odbioru. Nie oznacza, że system przestaje się zmieniać. Realne użycie nadal ujawnia miejsca do uproszczenia, dodatkowe zabezpieczenia i pytania, których nie było w pierwotnym planie.
Przykładem jest integracja z KERNAL ID. BUSINESS zachowuje własny model pracowników i własne reguły, ale logowanie oraz provisioning korzystają już ze wspólnej warstwy tożsamości. System pozostaje samodzielnym produktem, a jednocześnie dołącza do spójnego ekosystemu.
Najlepszy backlog powstaje podczas pracy
Nie każda uwaga użytkownika powinna natychmiast stać się funkcją. Realne dane pomagają jednak odróżnić problem powtarzalny od pojedynczego wyjątku. Dzięki temu kolejne iteracje wynikają z obserwowanego procesu, a nie z listy ekranów, które dobrze wyglądają na prezentacji.