Kwalifikacja to brama
Za niski poziom skilla, przeterminowany certyfikat, brak dostępu do hali, brak zmiany: osoba wypada. Punkty jej nie wrócą.
Produkt Framewright / w budowie
ERP wie, co trzeba zrobić. HR wie, kim są ludzie. Systemy projektowe znają plan. Framewright Flow dokłada warstwę, której nie ma żaden z nich: kto ma kwalifikacje, jest dostępny i najlepiej nadaje się do tej pracy teraz.
ERP, system projektowy albo zgłoszeniowy tworzy pracę.
Przeciągnij pierścień albo użyj strzałek
01 Flow w praktyce
Flow to działająca aplikacja webowa plus ekran na hali. Wszystko poniżej to prawdziwy produkt na danych demonstracyjnych.
Za niski poziom skilla, przeterminowany certyfikat, brak dostępu do hali, brak zmiany: osoba wypada. Punkty jej nie wrócą.
Trzy sygnały, wagi ustawiasz sam, a przy każdym kandydacie stoi zwykłe zdanie mówiące, skąd wziął się wynik.
Flow nikogo nie przypisuje. Lider zatwierdza rekomendację albo wybiera kogoś innego i podaje powód.
Pracownik widzi swoją pracę na wspólnym ekranie w hali i potwierdza wykonanie.
Na jakim etapie jest produkt. Flow działa dziś jako aplikacja webowa i ekran na hali. Nie pracuje jeszcze produkcyjnie u żadnego klienta i szukamy pierwszej hali pilotażowej. Bez cennika, bez daty wydania, bez katalogu integracji: to wychodzi z pierwszego pilotażu, nie przed nim.
02 Brakująca warstwa
ERP, HR i systemy projektowe dobrze pilnują swojego kawałka prawdy. Rzadko odpowiadają na pytanie, które rozstrzyga dzień na hali: kto ma zrobić to konkretne zadanie, przy tych konkretnych ograniczeniach, teraz?
Więc odpowiedź siedzi u jednego doświadczonego koordynatora, w arkuszu albo w czyjejś głowie. Działa do dnia, w którym przestaje.
Flow staje obok tych systemów, zamiast je zastępować. Rozsypany kontekst zamienia w przypisanie, które człowiek zatwierdza w kilka sekund.
03 Zadanie przechodzi przez Flow
Każdy krok to zrzut z działającej aplikacji, nie makieta.
Krok 01
Zadania trafiają do Flow z pliku albo z podpiętego systemu źródłowego. Zachowują swój identyfikator, więc zadanie w Flow i to samo zadanie w źródle pozostają jednym zadaniem.
Kolejka to poranek lidera: co jest otwarte, co zaraz się zaczyna i co wciąż nie ma nikogo.
Krok 02
Wymagania wiszą przy typie pracy, nie przy pojedynczym zadaniu. Dopóki ktoś nie powie, czym jest zadanie, Flow nie ma czego sprawdzać i nie zgaduje.
Takie zadania czekają w osobnym koszyku, jedno kliknięcie każde. To celowo widoczna luka zamiast cichego złego przypisania.
Krok 03
Zmiany i nieobecności biorą się z grafiku, który już prowadzicie. Certyfikaty niosą swoją datę ważności, więc kartę wygasającą za tydzień widać już w tym tygodniu.
To kontekst, który czyta silnik dopasowania. To także ekran, na który lider zerka, zanim cokolwiek obieca.
Krok 04
Trzynaście osób z piętnastu odpada przy tym zadaniu. Flow wymienia każdą z nazwiska i mówi, na czym poległa: poziom poniżej minimum, brakująca karta, hala bez dostępu, brak zmiany w oknie.
Lista, której nie da się przepytać, jest tylko krótszym zgadywaniem. To właśnie ta lista sprawia, że ranking nad nią warto czytać.
Krok 05
Bez konta, bez hasła, bez instalowania czegokolwiek. Wspólny ekran w hali, sześciocyfrowy kod należący do osoby, nie do tabletu, i praca, która dziś jest jej.
Jeden przycisk zamyka zadanie. To potwierdzenie liczy się później jako doświadczenie w rankingu, więc pętla karmi samą siebie.
04 Silnik dopasowania
Twardych wymagań nigdy nie wymienia się na wyższy wynik.
Jedno niespełnione i osoba nie jest uprawniona. Żaden wynik tego nie zmieni, a niepełne okno czasowe zamyka bramę, zamiast ją otwierać.
Trzy, nie trzydzieści. Każdy da się policzyć od pierwszego tygodnia pilotażu, a hala bez historii rankuje na razie po skillach i obciążeniu.
Domyślnie 50 / 30 / 20. Przesuwasz suwak, podglądasz skutek na prawdziwym zadaniu i zapisujesz jako nową wersję. Nic się nie zmienia, dopóki nie zapiszesz.
Stare rekomendacje wskazują wagi, które je wyprodukowały, więc decyzja z marca tłumaczy się sama jeszcze we wrześniu.
06 Biuro i hala
Ekran biurowy jest gęsty, bo lider porównuje. Ekran na hali jest niemal pusty, bo ktoś w rękawicach nie powinien czytać.
Żadnego sklepu z aplikacjami, żadnego telefonu służbowego, żadnego hasła na hali. Kod należy do człowieka, tablet należy do hali.
07 Architektura
Warstwa orkiestracji, a nie kolejny system domagający się roli systemu źródłowego.
Dane zostają w systemach, które je posiadają. Flow czyta kontekst, nie anektuje go.
Warstwa, która wie, co każdy człowiek naprawdę może dziś robić.
Każde przypisanie niesie rozumowanie, które je wyprodukowało.
Drogi są dwie: plik z zadaniami i grafikiem oraz adapter bazodanowy napisany pod jeden konkretny system. Nowe źródło to adapter, nie ustawienie. Pierwszy zbudowalibyśmy w trakcie pilotażu.
Zapis zwrotny jest celowo wąski: aktualizacja pól, których system źródłowy i tak używa na wykonawcę i status, za przełącznikiem tylko do odczytu włączonym domyślnie. Pilotaż może działać bez żadnego zapisu.
Jedna instalacja na klienta, stawiana jednym poleceniem, z własną bazą i własnymi kontami. Nie wspólna usługa wielodostępna.
Nie ma katalogu integracji ani marketplace'u. Wymienianie go, zanim powstanie, kosztowałoby nas oboje czas na pierwszym spotkaniu.
08 Pilotaż
Nie dział, nie wdrożenie. Jeden rodzaj pracy, jedna hala, ludzie, którzy naprawdę ją wykonują.
Taki, który się powtarza, ma realne wymagania i dziś przydziela go człowiek znający wszystkich.
Skille i poziomy, karty, które trzeba mieć, miejsca, gdzie wolno wejść. Ta rozmowa zwykle sama w sobie jest wartościowa.
Ludzie, grafik, certyfikaty i otwarta praca. Na start wystarczy eksport do pliku. Żadnego projektu integracyjnego.
Flow rankuje, lider decyduje jak zwykle, a oboje widzicie, czy ranking zgadza się z człowiekiem, który robi to od lat.
Jeśli nie, zostaje wam spisany model kwalifikacji i jasność w głowie. To nie jest nic.
Jeśli większość tego brzmi jak wasza hala, rozmowa o pilotażu jest warta godziny.
Albo napisz wprost na info@framewright.cloud.
To nie jest lista obowiązkowa. Trzy z pięciu to już ciekawa rozmowa.
09 Pytania
Nie. Te systemy dalej są właścicielami swoich danych. Flow czyta kontekst potrzebny do decyzji o przypisaniu i oddaje decyzję. Gdybyście wyłączyli Flow, wasze rejestry zostałyby tam, gdzie zawsze były.
Cztery rzeczy: kim są wasi ludzie, co każdy z nich potrafi i na jakim poziomie, kiedy są na zmianie i czego wymaga praca. Certyfikaty i dostęp do miejsc idą razem z tym. Mniej niż wdrożenie ERP, więcej niż arkusz, i mniej więcej o to chodzi.
Po twardych wymaganiach przypiętych do rodzaju pracy. Skill na wymaganym poziomie albo wyżej, ważny certyfikat, dostęp do miejsca oraz zmiana pokrywająca okno bez wpisanej nieobecności. Niespełnienie choćby jednego usuwa osobę z listy w całości.
Jeśli okno czasowe jest niepełne, dostępności nie da się sprawdzić, więc brama nie przepuszcza, zamiast machnąć ręką.
Trzema sygnałami: o ile skill przekracza minimum, jak niedawno osoba potwierdziła ten sam rodzaj pracy i ile już ma przypisane tego dnia. Wagi ustawiacie sami, domyślnie 50 / 30 / 20, a każdy ranking zapisuje wersję wag, której użył.
Jest liczba od 0 do 100 i to arytmetyka, nie model. Przy każdym kandydacie stoją zdania, z których się wzięła: poziom skilla, dni od podobnej pracy, bieżące obciążenie. Jeśli liczba wygląda źle, widać, który sygnał ją zrobił, i można zmienić wagę.
Tak i jest to normalna rzecz. Wybór kogokolwiek innego niż pierwszy w rankingu prosi o pisemny powód, a nadpisanie zapisuje się z nazwiskiem lidera. Nadpisania nigdy się nie blokuje, tylko zapisuje.
Flow mówi to wprost i wymienia każdą osobę z powodami, na których poległa. Ta lista bywa użyteczniejsza od rekomendacji: pokazuje, czy problem to luka w szkoleniach, przeterminowana karta, czy niedomknięta zmiana.
Nie i jest to decyzja, nie brak. Ekran hali to strona internetowa zbudowana pod wspólny tablet. Nie ma czego instalować, nie ma konta na pracownika ani hasła: sześciocyfrowy kod należy do człowieka, a urządzenie administrator wpina raz.
Dziś trzy rzeczy: zobaczyć pracę przypisaną na dziś i jutro, potwierdzić wykonanie zadania i sprawdzić własne certyfikaty z datami ważności. Zgłaszania odchyleń, załączania dowodów i uruchamiania stopera nie ma.
Tam, gdzie istnieje adapter do danego systemu, tak, i wyłącznie w pola, których ten system już używa na wykonawcę i status. Każda integracja startuje tylko do odczytu i taka zostaje, dopóki ktoś świadomie nie włączy zapisu. Pilotaż może przejść bez zapisania czegokolwiek.
Potencjalnie zero. Zadania, ludzie i grafik mogą wejść plikami i tak zwykle zaczynamy. Porządne podpięcie systemu źródłowego to adapter pisany pod ten system, a decyzja o nim zapada po tym, jak pierwszy proces coś udowodni.
W jednej instalacji dla waszej organizacji, z własną bazą i własnymi kontami, stawianej per klient zamiast jako wspólna usługa. Lokalizacja hostingu to element rozmowy o pilotażu, nie z góry ustalona odpowiedź.
Co zostało zarekomendowane, kto był uprawniony a kto nie, które wagi były aktywne, kto przypisał, czy to było nadpisanie i dlaczego, oraz kiedy pracownik potwierdził. Ślad audytowy jest chroniony na poziomie bazy, nie tylko w aplikacji, więc sama aplikacja nie może go po cichu przepisać.
Dziś po angielsku i niderlandzku, i stąd angielskie zrzuty na tej stronie. Ekran hali musi być w języku człowieka, który przed nim stoi, więc dołożenie kolejnego języka to praca tłumaczeniowa, nie programistyczna.
Jak praca wchodzi, kto decyduje, komu ją dać, i w którym miejscu ta decyzja robi się trudna. Tyle wystarczy, żeby powiedzieć, czy Flow pomoże, czy tylko dołoży ekran.
Porozmawiajmy o pilotażu