Jeden proces zamiast kilku niezależnych narzędzi
Wyobraźmy sobie firmę, w której zapytanie od klienta przychodzi e-mailem, handlowiec zapisuje dane w arkuszu, dział realizacji otrzymuje informacje przez komunikator, a po wykonaniu usługi ktoś jeszcze przepisuje dane do programu rozliczeniowego. Każdy z tych etapów może działać poprawnie, ale cały proces jest podatny na opóźnienia i pomyłki.
Aplikacja webowa może połączyć poszczególne czynności w jeden przepływ. Utworzenie zlecenia automatycznie udostępnia dane odpowiedniej osobie, zmiana statusu uruchamia kolejne zadanie, a informacje wprowadzone raz są wykorzystywane na dalszych etapach. Zamiast pięciu oddzielnych operacji powstaje jeden proces z jasno określonym przebiegiem.
W praktyce można w ten sposób obsługiwać między innymi:
- zapytania, klientów i historię kontaktów;
- zamówienia oraz kolejne etapy ich realizacji;
- zadania zespołów i terminy wykonania prac;
- produkty, stany magazynowe lub dokumentację;
- raportowanie i przepływ danych pomiędzy działami;
- komunikację z zewnętrznymi systemami przez integracje.
Nie oznacza to, że jedna aplikacja musi zastąpić wszystkie używane programy. Często lepszym rozwiązaniem jest połączenie istniejących systemów i stworzenie wspólnego miejsca, z którego użytkownik obsługuje najważniejszą część procesu.
Automatyzacja zaczyna się od uporządkowania informacji
Automatyzowanie chaosu zwykle nie daje dobrych rezultatów. Jeżeli dwa działy inaczej rozumieją status zamówienia albo te same dane są zapisywane w kilku formatach, samo napisanie dodatkowej funkcji nie rozwiąże problemu.
Dlatego projekt aplikacji biznesowej zaczyna się znacznie wcześniej niż programowanie. Najpierw trzeba ustalić, skąd pochodzą informacje, kto ich potrzebuje, co dzieje się z nimi później i które działania rzeczywiście wymagają decyzji człowieka.
Dopiero wtedy można sensownie zdecydować, co powinno odbywać się automatycznie. System może na przykład przesłać powiadomienie po zmianie statusu, wygenerować dokument na podstawie zapisanych danych, przekazać informacje do innej aplikacji albo zablokować przejście do następnego etapu, jeżeli brakuje wymaganych informacji.
Takie mechanizmy nie muszą być skomplikowane technologicznie. Ich wartość wynika przede wszystkim z tego, że eliminują drobne czynności wykonywane codziennie przez wiele osób.
Aplikacja powinna wynikać ze sposobu działania firmy
Gotowe systemy mają dużą zaletę: można stosunkowo szybko rozpocząć pracę. Problem pojawia się wtedy, gdy firma posiada proces, który trudno dopasować do narzuconego schematu. Zespół zaczyna tworzyć obejścia, dodatkowe arkusze i instrukcje opisujące, jak korzystać z programu w sposób, którego producent nie przewidział.
W takich sytuacjach dedykowana aplikacja może odwzorowywać rzeczywistą kolejność pracy. Użytkownik widzi funkcje potrzebne na swoim stanowisku, formularze zawierają dane wykorzystywane w danym procesie, a statusy odpowiadają faktycznym etapom realizacji.
MadeByRogal opisuje, jak projektować aplikacje internetowe dla firm z uwzględnieniem zarówno potrzeb biznesowych, jak i użyteczności, technologii, bezpieczeństwa oraz późniejszego rozwoju systemu. Taka perspektywa jest istotna, ponieważ dobrze zaprojektowana aplikacja nie kończy się na liście funkcji. Musi jeszcze pasować do pracy konkretnych użytkowników i umożliwiać dalsze zmiany, gdy przedsiębiorstwo rozwija swoje procesy.
Integracje ograniczają ręczne przepisywanie danych
Aplikacja webowa rzadko działa całkowicie samodzielnie. W przedsiębiorstwie mogą już funkcjonować systemy ERP, CRM, płatności, księgowość, rozwiązania magazynowe czy platformy sprzedażowe. Tworzenie ich odpowiedników od podstaw często nie ma uzasadnienia.
Znacznie większe korzyści może przynieść integracja. Dane wprowadzone przez klienta w formularzu mogą automatycznie trafić do systemu obsługi, informacja o płatności może zmienić status zamówienia, a dane potrzebne do raportowania mogą zostać pobrane z kilku źródeł bez przygotowywania zestawienia ręcznie.
Dobrze zaplanowana integracja ogranicza również liczbę miejsc, w których powstają rozbieżności. Jeżeli pracownik nie musi przepisywać numeru zamówienia, adresu czy wartości transakcji z jednego programu do drugiego, maleje ryzyko zwykłego błędu przy wprowadzaniu danych.
Przed połączeniem systemów dobrze określić:
- które informacje mają być synchronizowane;
- w którym systemie znajduje się źródło właściwych danych;
- jak często informacje powinny być aktualizowane;
- co ma się wydarzyć, gdy połączenie chwilowo przestanie działać;
- którzy użytkownicy mogą odczytywać lub zmieniać określone dane.
To zagadnienia techniczne, ale ich konsekwencje są przede wszystkim organizacyjne. Błąd w przepływie informacji może zatrzymać dalszy etap realizacji równie skutecznie jak awaria samej aplikacji.
Dostęp przez przeglądarkę nie oznacza braku wymagań technicznych
Aplikacja internetowa nie wymaga klasycznej instalacji na komputerze użytkownika, lecz nadal jest pełnoprawnym oprogramowaniem. Jej architektura musi uwzględniać liczbę użytkowników, sposób przechowywania danych, integracje, poziomy uprawnień oraz przewidywany rozwój.
Znaczenie ma także responsywność. Pracownik magazynu korzystający z telefonu potrzebuje innego układu interfejsu niż osoba analizująca rozbudowany raport na monitorze. Sam fakt, że aplikację da się otworzyć na mniejszym ekranie, nie oznacza jeszcze wygodnej obsługi.
Podobnie wygląda kwestia wydajności. System może działać poprawnie podczas testów na niewielkiej bazie danych, a zwalniać po kilku miesiącach intensywnego użytkowania. Projektując aplikację, trzeba więc myśleć nie tylko o jej pierwszej wersji, lecz także o liczbie danych, zapytań i operacji, które pojawią się później.
System rozwija się razem z procesem
Pierwsza wersja aplikacji rzadko zawiera wszystko, czego firma będzie potrzebowała za kilka lat. Zmieniają się procedury, pojawiają się nowe kanały sprzedaży, kolejne integracje i dodatkowe role użytkowników. Oprogramowanie biznesowe musi mieć możliwość reagowania na te zmiany.
Nie oznacza to konieczności tworzenia od początku rozbudowanego systemu ze wszystkimi potencjalnymi funkcjami. Rozsądniejszym podejściem bywa uruchomienie rozwiązania obejmującego najważniejszy proces, obserwowanie jego rzeczywistego wykorzystania i rozwijanie kolejnych elementów na podstawie konkretnych potrzeb.
Dzięki temu aplikacja pozostaje narzędziem wspierającym działalność, zamiast z czasem stać się technicznym ograniczeniem. Jej użyteczność najlepiej oceniać nie liczbą dostępnych modułów, lecz tym, ile zbędnych operacji znika z codziennej pracy i jak sprawnie informacja przechodzi od jednego etapu procesu do następnego.
