Kto w firmie powinien móc zmienić proces w systemie

Ile czasu mija w Twojej firmie od zdania „ten proces trzeba poprawić” do momentu, w którym poprawka naprawdę działa? Tydzień, kwartał, czy nigdy?

Odpowiedź nie zależy od tego, jak dobry jest system. Zależy od tego, kto ma prawo go zmieniać. Są dwa modele i warto porównać je wprost, bo wybiera się między nimi raz, zwykle nieświadomie, w dniu podpisania umowy.

Model pierwszy: zmianę wprowadza dostawca

Każda modyfikacja procesu, pola czy uprawnienia idzie zgłoszeniem do producenta. Wygląda to bezpiecznie i porządnie, a przez pierwszy rok nawet tak działa.

Potem zaczyna działać arytmetyka. Zmiana ma cenę i termin, więc trzeba ją uzasadnić i przeprowadzić przez wewnętrzną akceptację. Drobne poprawki, które realnie ułatwiłyby ludziom pracę, nie przechodzą przez ten próg, bo nie warto o nie walczyć. Zgłaszane są tylko rzeczy duże i pilne.

Po dwóch latach system ma konfigurację z dnia wdrożenia, a firma pracuje inaczej, niż wtedy pracowała. Różnicę ludzie obsługują arkuszem i mailem, czyli dokładnie tym, od czego zaczynało się wdrożenie.

Ten model ma swoje zalety i nie warto ich ukrywać. Nikt przypadkiem nie zepsuje obiegu faktur, a odpowiedzialność za poprawność konfiguracji leży po stronie z umową. Płaci się za to tempem.

Model drugi: zmianę wprowadza firma

Drugi model przenosi prawo do zmiany do środka organizacji. Poprawkę robi analityk, kierownik administracji albo kontroler, czyli osoba, która zna proces od strony operacyjnej, a nie od strony kodu.

Tempo rośnie natychmiast. Nowe pole we wniosku pojawia się tego samego dnia, a nie w kolejnym kwartale. Kosztem jest inne ryzyko: dług konfiguracyjny. Trzy pola o niemal identycznej nazwie, bo każdy dział dodał swoje. Słownik statusów z pięcioma wariantami tego samego etapu. Odgałęzienie procesu dodane przez kogoś, kto już nie pracuje, i nikt nie wie, czy można je usunąć.

Raport z takiego systemu przestaje mieć sens. Skoro trzy działy opisują to samo trzema polami, nie da się policzyć niczego wspólnego.

Porównanie wprost

Cztery wymiary, w których te modele różnią się najmocniej.

• Czas reakcji. Model dostawcy liczy się w tygodniach i kwartałach, model wewnętrzny w godzinach i dniach.

• Koszt drobnej poprawki. U dostawcy drobna poprawka kosztuje tyle, że zwykle w ogóle nie jest zgłaszana. Wewnątrz kosztuje czas jednej osoby.

• Ryzyko bałaganu. U dostawcy niskie, bo bramkę trzyma ktoś z zewnątrz. Wewnątrz wysokie, jeśli nikt nie pilnuje całości.

• Wiedza o systemie. W pierwszym modelu zostaje u dostawcy. W drugim zostaje w firmie i nie znika razem z umową.

Trzeci wymiar jest jedynym, w którym model wewnętrzny wypada gorzej, i jedynym, który da się zaadresować organizacyjnie. Wystarczy jedna wyznaczona rola z prawem konfigurowania, historia zmian konfiguracji, uprawnienia węższe niż wszystko albo nic oraz miejsce, w którym zmianę sprawdza się przed publikacją.

Co w Opero zmienia analityk bez programisty

Opero jest zbudowane pod drugi model i warto powiedzieć wprost, gdzie przebiega granica. Bez linijki kodu, w samej konfiguracji, jedna przeszkolona osoba zmienia następujące rzeczy.

• Procesy. Cały obieg jako etapy i przejścia między nimi, razem z warunkami i uprawnieniami na każdym kroku.

• Formularze. To, które pola widzi użytkownik przy tworzeniu, podglądzie i edycji rekordu, osobno dla wnioskującego i osobno dla akceptującego.

• Układy. Rozmieszczenie sekcji, zakładek i pól na ekranie, z wersjami roboczymi i publikowanymi oraz powrotem do wersji wcześniejszej.

• Reguły. Automatyzacja według zasady „gdy zajdzie warunek, wykonaj akcję”: ustaw pole, utwórz rekord, wyślij powiadomienie, zablokuj przejście. Regułę testuje się przed wdrożeniem.

• Słowniki. Kontrolowane listy wartości zasilające pola wyboru, z importem i eksportem wpisów.

• Obiekty i pola. Same definicje danych, z ponad dwudziestoma typami pól, projektowane w wersji roboczej struktury, zanim trafią na produkcję.

Programista wchodzi dopiero przy nietypowej logice i do tego służy silnik skryptów. Większość tego, co firma chce poprawić w pierwszym roku po wdrożeniu, leży poniżej tej granicy.

Osobne uprawnienie do konfiguracji ma jeszcze jedną konsekwencję, widoczną dopiero przy audycie. Prawo do zmieniania procesu i dostęp do danych w tym procesie to dwie różne rzeczy, więc analityk może układać obieg kadrowy bez czytania akt pracowników.

Sprawdzian po roku

Jest jedna liczba, która mówi o tym więcej niż każda polityka bezpieczeństwa: ile zmian w systemie Twoja firma wprowadziła samodzielnie przez ostatnie dwanaście miesięcy.

Zero oznacza model pierwszy w najgorszym wydaniu, czyli system zamarznięty i obchodzony bokiem. Dwieście oznacza model drugi bez żadnej dyscypliny. Kilkanaście, każda z podpisem i uzasadnieniem, oznacza system, który dojrzewa razem z firmą.

Jeśli ta liczba u Ciebie wynosi zero, warto zobaczyć konfigurację Opero od środka. Pokazujemy ją na procesie, który akurat uwiera.