Zanim zapytasz

Od rozmowy, w której opowiadacie, co dziś zabiera najwięcej czasu. Nie potrzebujemy do niej gotowej specyfikacji ani listy wymagań. Po rozmowie dostajecie od nas opis tego, co widzimy, wraz z propozycją, od którego procesu zacząć.

Nie. Pierwsza rozmowa i wstępne rozpoznanie procesu są bezpłatne i do niczego nie zobowiązują.

Nie. Najczęściej firma czuje, że „coś zajmuje za dużo czasu”, ale nie wie, gdzie dokładnie leży problem. Znalezienie tego miejsca jest częścią naszej pracy.

Najczęściej z małymi i średnimi firmami produkcyjnymi, handlowymi i usługowymi, w których procesy rosły latami i nikt ich nigdy nie poukładał od nowa.

Zdalnie na co dzień, na miejscu wtedy, gdy trzeba zobaczyć proces na własne oczy: halę, magazyn, obieg dokumentów. Mapowania procesu produkcyjnego nie da się zrobić przez ekran.

Flawless to automatyzacja tego, co już macie: łączenie systemów, które ze sobą nie rozmawiają. Vortex to budowa narzędzia, którego nie ma na rynku w potrzebnej formie. Meridian to uporządkowanie i spisanie procesów, zwykle zanim cokolwiek się automatyzuje.

Jeżeli proces jest znany i powtarzalny, zwykle od Flawless. Jeżeli nikt w firmie nie potrafi go jednoznacznie opisać, od Meridian. Vortex ma sens wtedy, gdy istniejące narzędzia nie obejmują tego, jak faktycznie pracujecie.

Tak, to jest zwykle punkt wyjścia. Pracowaliśmy między innymi z Comarch ERP XL, arkuszami, pocztą, systemami magazynowymi i księgowymi. Jeżeli system ma API lub eksport danych, da się go podłączyć.

Wtedy szukamy innej drogi: eksportów, plików wymiany, bazy danych. W praktyce rzadko zdarza się proces, którego nie da się podłączyć w żaden sposób.

Nie. Zajmujemy się automatyzacją, oprogramowaniem wewnętrznym i porządkowaniem procesów.

Jednego i drugiego, zależnie od tego, co jest tańsze w utrzymaniu. Jeżeli gotowe narzędzie rozwiązuje problem, nie budujemy zamiennika tylko po to, żeby był nasz.

Pojedynczy, dobrze opisany proces to zwykle kilka tygodni. Większe wdrożenia, obejmujące całe przedsiębiorstwo, liczy się w miesiącach, bo najwięcej czasu zabiera nie kod, tylko zmapowanie tego, jak firma naprawdę pracuje.

Po rozmowie i wstępnym rozpoznaniu podajemy zakres i widełki. Nie wyceniamy projektów w ciemno, na podstawie samego opisu w mailu.

Tak i zwykle tak radzimy. Jeden proces, policzalny efekt, decyzja o kolejnym kroku dopiero potem.

Pierwsze działające fragmenty pokazujemy w trakcie, nie na końcu. Nie pracujemy w trybie, w którym przez trzy miesiące nic nie widać.

Mówimy o tym wprost. Czasem tańszym rozwiązaniem jest zmiana samego procesu, nie narzędzia.

Zostajemy na czas, w którym zespół oswaja się z nowym przepływem, poprawiamy to, co w praktyce okazuje się niewygodne, i przekazujemy dokumentację.

Dobre wdrożenie wymaga od zespołu jak najmniej. Jeżeli korzystanie z narzędzia wymaga szkolenia, zwykle znaczy to, że narzędzie jest źle zaprojektowane.

Umawiamy się na zasady wsparcia przed startem: czas reakcji i zakres. Awarie zdarzają się najczęściej po zmianach po stronie systemów, z którymi się integrujemy.

Nie. Kod i dokumentację przekazujemy na zasadach ustalonych w umowie, a procesy zostają spisane. Chcemy być wyborem, nie warunkiem działania firmy.

Tak, jeśli jest taka potrzeba. Częściej jednak firma wraca po kolejny proces niż po poprawki do poprzedniego.

Tam, gdzie zdecydujecie: na Waszej infrastrukturze albo w usłudze, z której już korzystacie. Nie przenosimy danych do własnych systemów.

Tak, standardowo, jeszcze przed szczegółową rozmową o procesach.

Wyłącznie osoby pracujące nad Waszym wdrożeniem, w zakresie potrzebnym do jego wykonania. Po zakończeniu dostęp jest zamykany.

Ten sam mały zespół, z którym rozmawiacie od początku. Nie przekazujemy projektów dalej, do osób, które nie znają kontekstu.

Tak, z obu stron: wykształcenie inżynierskie z logistyki i lata pracy bezpośrednio w produkcji, zanim zaczęliśmy budować narzędzia dla innych firm. Więcej piszemy o tym na stronie O nas.

To świadomy wybór. Wolimy robić mniej rzeczy i robić je dobrze, niż być organizacją, która robi wszystko dla każdego.