Webtom.pl działa jako firma programistyczna i software house, projektując rozwiązania dla organizacji, których procesów nie da się sprawnie obsłużyć za pomocą standardowej strony, prostego sklepu albo zestawu niepołączonych narzędzi.
Tworzymy oprogramowanie na zamówienie dla firm z Wrocławia i województwa dolnośląskiego: aplikacje webowe, systemy wspierające procesy operacyjne, platformy B2B, panele klientów i partnerów, narzędzia raportowe, konfiguratory oraz integracje pomiędzy systemami.
Pracę rozpoczynamy od poznania procesu, użytkowników, danych, obecnych narzędzi i problemów, które ma rozwiązać system. Dopiero później określamy zakres, architekturę, interfejsy, integracje i technologię.
Nie każdy problem wymaga tworzenia całej platformy od początku. Czasami właściwym rozwiązaniem jest integracja używanych systemów, dodanie jednego modułu, uporządkowanie danych albo modernizacja istniejącej aplikacji. Zakres powinien wynikać z rzeczywistej potrzeby, a nie z chęci zastosowania możliwie najbardziej rozbudowanej technologii.
Pełny zakres naszych usług programistycznych przedstawiamy również na stronie Software House.
System dedykowany warto rozważyć wtedy, gdy problemem nie jest brak kolejnego programu, lecz konieczność połączenia danych, użytkowników i procesów działających obecnie w kilku miejscach.
Najczęstsze sygnały to:
Celem nie powinno być odwzorowanie każdego obecnego działania w kodzie. Analiza ma również wskazać, które etapy można uprościć, połączyć albo usunąć.
Projektujemy rozwiązania wspierające codzienną pracę zespołów: obsługę spraw, zleceń, dokumentów, statusów, zgłoszeń, akceptacji, klientów i danych wewnętrznych.
System może porządkować proces wykonywany dotychczas w arkuszach, wiadomościach e-mail i kilku niepołączonych programach.
Tworzymy aplikacje dostępne z poziomu przeglądarki, przeznaczone dla pracowników, klientów, partnerów lub innych grup użytkowników. Zakres może obejmować logowanie, role, formularze, dashboardy, raporty, powiadomienia oraz integracje.
Aplikacja webowa może być samodzielnym produktem albo częścią większego ekosystemu organizacji.
Panel może udostępniać dokumenty, zamówienia, statusy, rozliczenia, zgłoszenia, dane kontraktowe, materiały i komunikaty właściwe dla konkretnego użytkownika.
Projektujemy zakres danych, role, uprawnienia oraz sposób wymiany informacji pomiędzy panelem a systemami firmy.
System B2B może obsługiwać katalog, indywidualne ceny, zamówienia, zapytania, dokumenty, konta partnerów i integrację z ERP. W bardziej rozbudowanych projektach platforma wspiera również akceptacje, budżety, limity, struktury organizacyjne i pracę handlowców.
Szczegółowy zakres takich realizacji przedstawiamy na stronie systemy B2B.
Projektujemy dashboardy zbierające dane z jednego lub kilku źródeł. Mogą one prezentować sprzedaż, realizację procesów, statusy spraw, aktywność użytkowników, wyniki zespołów albo jakość obsługi.
Przed wdrożeniem ustalamy definicje wskaźników, źródła danych, częstotliwość aktualizacji i uprawnienia do poszczególnych raportów.
Tworzymy narzędzia, w których użytkownik wybiera parametry produktu albo usługi, a system oblicza cenę, wariant, zakres, zapotrzebowanie lub możliwą konfigurację.
Konfigurator może działać jako część strony, sklepu, panelu B2B albo odrębna aplikacja. Szczegółowy zakres takich narzędzi przedstawiamy na stronie konfiguratory produktów.
Łączymy aplikacje, strony, sklepy, CRM, ERP, płatności, magazyny i inne systemy używane w firmie. Integracja może ograniczać ręczne przepisywanie danych, ale wymaga określenia źródła informacji, kierunku wymiany, mapowania, częstotliwości synchronizacji i sposobu obsługi błędów.
Szczegółowy zakres projektów związanych z wymianą danych przedstawiamy na stronie integracje z systemami ERP.
Na początku ustalamy, gdzie przechowywane są informacje o klientach, użytkownikach, produktach, zamówieniach, dokumentach i statusach. Określamy, który system jest źródłem konkretnego rodzaju danych i gdzie mogą być one edytowane.
Bez takiego podziału łatwo doprowadzić do sytuacji, w której ta sama informacja ma różne wartości w kilku narzędziach.
Projektujemy role użytkowników oraz zakres dostępu do danych i funkcji. Uprawnienia mogą zależeć od firmy, działu, stanowiska, typu klienta, lokalizacji, statusu sprawy albo odpowiedzialności za konkretny etap procesu.
Nie ograniczamy analizy do prostego podziału na administratora i użytkownika.
W systemach operacyjnych istotna jest możliwość ustalenia, kto, kiedy i w jaki sposób zmienił dane, dokument, status albo decyzję. Dlatego w zależności od projektu planujemy historię operacji, zdarzenia systemowe i zasady przechowywania informacji.
Zakres rejestrowania powinien być dopasowany do rzeczywistej odpowiedzialności i potrzeb organizacji.
Projektujemy sposób reagowania na niekompletne dane, brak połączenia z systemem zewnętrznym, powtórzone operacje i błędy synchronizacji.
Sam komunikat „wystąpił błąd” nie wystarcza. System powinien umożliwiać ustalenie, czego dotyczył problem i jakie działanie należy wykonać.
Oprócz funkcji analizujemy wydajność, bezpieczeństwo, liczbę użytkowników, przewidywany wolumen danych, ciągłość działania, możliwość rozwoju i sposób wdrażania zmian.
Te elementy wpływają na architekturę równie mocno jak lista ekranów i funkcji.
Określamy zakres danych wymienianych pomiędzy systemami. Mogą to być klienci, konta, produkty, dokumenty, zamówienia, statusy, płatności, zgłoszenia, raporty i pliki.
Ustalamy, czy informacje są przesyłane jednostronnie czy dwukierunkowo. Dla każdego zakresu określamy system źródłowy i zasady aktualizacji.
Nie każda informacja musi być wymieniana w czasie rzeczywistym. Część danych może wymagać natychmiastowej aktualizacji, a inne mogą być przetwarzane cyklicznie albo na żądanie.
Integracja powinna rejestrować błędy, niekompletne dane i nieudane operacje. Ustalamy również, które zdarzenia wymagają ponowienia, interwencji użytkownika albo powiadomienia administratora.
Testujemy nie tylko poprawny scenariusz, ale również brakujące wartości, duplikaty, niedostępność zewnętrznego systemu, nietypowe znaki, duże paczki danych i zmiany statusów.
Możemy przejąć rozwój aplikacji albo systemu wykonanego przez innego dostawcę, ale przed określeniem zakresu, terminu i kosztu musimy poznać jego rzeczywisty stan techniczny.
Weryfikujemy między innymi:
W przypadku starszych aplikacji oceniamy, czy dalsze dodawanie funkcji jest bezpieczne i ekonomicznie uzasadnione. Czasami możliwa jest stopniowa modernizacja, a czasami konieczne jest wydzielenie nowych modułów albo zastąpienie części rozwiązania.
Nie rekomendujemy pełnego przepisywania systemu bez analizy korzyści, ryzyk i możliwości etapowej migracji.
Refaktoryzacja oznacza poprawę struktury technicznej oprogramowania bez zmiany jego uzgodnionego działania z perspektywy użytkowników. Jej zakres powinien wynikać z konkretnych problemów związanych z rozwojem, wydajnością, bezpieczeństwem, testowalnością albo nadmiernymi zależnościami w kodzie.
Przed rozpoczęciem określamy cel, obszary objęte zmianą oraz sposób weryfikacji rezultatów.
Migracja może obejmować dane użytkowników, klientów, dokumenty, historię operacji, statusy, pliki i relacje pomiędzy rekordami. Przed wdrożeniem analizujemy jakość danych, brakujące informacje, duplikaty i zgodność struktur.
Migracja powinna zostać przetestowana na kopii danych przed uruchomieniem produkcyjnym.
WordPress i WooCommerce mogą być częścią bardziej złożonego ekosystemu, jeżeli projekt wymaga dedykowanych funkcji, paneli, integracji, nietypowych procesów albo wymiany danych z systemami firmy.
Standardowe strony WordPress opisujemy na stronie Agencja WordPress Wrocław, a projekty sprzedażowe na stronie Agencja WooCommerce Wrocław. Na stronie software house’u koncentrujemy się wyłącznie na przypadkach, w których te technologie wymagają indywidualnego programowania lub integracji.
Poznajemy użytkowników, cele, obecne narzędzia, dane, ograniczenia i sposób wykonywania pracy. Ustalamy, jaki problem powinien zostać rozwiązany i po czym będzie można ocenić rezultat.
Porządkujemy wymagania, zależności i ryzyka. Oddzielamy funkcje niezbędne na start od elementów, które mogą zostać wdrożone później.
Rezultatem może być opis procesów, uporządkowana lista wymagań i zadań, makiety, założenia architektury oraz estymacja pierwszego etapu.
Określamy moduły, źródła danych, role, integracje, środowiska oraz wymagania dotyczące wydajności i bezpieczeństwa.
Projektujemy przepływy użytkowników, formularze, panele, dashboardy, stany, komunikaty i sposób obsługi błędów. Interfejs powinien odpowiadać rzeczywistemu procesowi, a nie tylko estetycznie prezentować funkcje.
Wdrażamy uzgodnione moduły, frontend, backend, bazę danych i integracje. Kod przechowujemy w repozytorium, a zmiany realizujemy w uporządkowanym procesie.
Uruchamiamy uzgodnione połączenia z systemami zewnętrznymi oraz przygotowujemy migrację danych, jeżeli jest częścią projektu.
Sprawdzamy funkcje, role, uprawnienia, walidację danych, komunikaty, integracje i najważniejsze scenariusze użytkowników. Zakres testów dobieramy do ryzyka oraz rodzaju systemu.
Przygotowujemy środowisko produkcyjne, plan publikacji i sposób weryfikacji systemu po uruchomieniu. W zależności od projektu wdrożenie może być jednorazowe albo etapowe.
Po uruchomieniu możemy realizować poprawki, monitorowanie, aktualizacje, kolejne funkcje i rozwój zgodny z ustalonymi priorytetami. Warunki oraz czasy reakcji zależą od modelu współpracy i ewentualnego SLA.
Określamy, kto dostarcza dane, dokumentację, dostęp do systemów, decyzje i akceptacje. Pozwala to oddzielić prace programistyczne od zależności po stronie klienta i dostawców zewnętrznych.
Ustalamy sposób przechowywania kodu, środowiska testowe i produkcyjne oraz proces publikowania zmian.
Zakres dokumentacji zależy od rodzaju projektu. Może obejmować architekturę, integracje, API, konfigurację, instrukcje administracyjne i opis wdrożenia.
Zasady dotyczące praw do kodu, komponentów zewnętrznych i licencji powinny być określone w umowie. Nie należy zakładać, że każda biblioteka lub usługa zewnętrzna może zostać przekazana na takich samych zasadach jak kod dedykowany.
Model współpracy dobieramy do poziomu określenia zakresu i rodzaju projektu. Model współpracy dobieramy do poziomu określenia zakresu i charakteru projektu. Rozwiązania rozwijane iteracyjnie najczęściej realizujemy w modelu Time & Materials, natomiast mniejsze i dobrze opisane zakresy mogą zostać oszacowane jako zamknięty etap.
Porównując firmy programistyczne, warto sprawdzić nie tylko stawkę i deklarowany termin, ale również sposób analizy, architekturę, proces wdrożeń i możliwość późniejszego utrzymania rozwiązania.
Istotne pytania:
Freelancer może być właściwym wyborem przy małym, dobrze określonym zadaniu. Freelancer może być właściwym wyborem przy małym, dobrze określonym zadaniu. Projekt wymagający wielu kompetencji, integracji i długoterminowego rozwoju zwykle wymaga jednak uporządkowanego zespołu oraz procesu.
Projekt może angażować osoby odpowiedzialne za analizę, architekturę, UX/UI, frontend, backend, integracje, testy i koordynację.
Od ponad 20 lat realizujemy rozwiązania webowe, systemy dedykowane, platformy B2B, WordPress i WooCommerce. Pozwala nam to dobierać skalę technologii do problemu, zamiast automatycznie rekomendować jeden typ systemu.
Oddzielamy funkcje niezbędne od elementów, które mogą zostać wdrożone później. Pozwala to ograniczyć budowanie rozwiązań na zapas.
Analizujemy nie tylko ekrany systemu, ale również źródła danych, role, synchronizację, błędy i odpowiedzialność poszczególnych narzędzi.
Nie deklarujemy kosztu modernizacji albo rozwoju systemu bez poznania kodu, architektury, danych, integracji i środowisk.
Koszt zależy od liczby procesów, ról, widoków, integracji, zakresu UX/UI, migracji danych, wymagań bezpieczeństwa i sposobu dalszego utrzymania. Wycena wymaga wcześniejszego poznania procesu i określenia zakresu pierwszego etapu.
Termin zależy od zakresu, integracji, jakości danych, liczby użytkowników, procesu akceptacji i możliwości etapowania. Po analizie przygotowujemy harmonogram obejmujący zależności po stronie Webtom.pl, klienta i zewnętrznych dostawców.
Przy złożonych systemach discovery pozwala uporządkować procesy, role, dane, integracje i priorytety przed rozpoczęciem programowania. Przy małym i dobrze opisanym zakresie pełny etap discovery może nie być konieczny.
Nie. W wielu projektach rekomendujemy wdrożenie pierwszego etapu rozwiązującego najważniejszy problem, a następnie rozwój kolejnych modułów na podstawie ustalonych priorytetów.
Tak. Projektujemy aplikacje dostępne przez przeglądarkę, przeznaczone dla pracowników, klientów, partnerów i administratorów. Mogą obejmować konta, role, formularze, dashboardy, raporty, dokumenty i integracje.
Tak. Integracja może obejmować użytkowników, klientów, produkty, dokumenty, zamówienia, statusy i inne dane. Zakres zależy od API, dokumentacji, jakości danych oraz ustalonych zasad synchronizacji.
Tak, ale rozpoczęcie rozwoju poprzedzamy analizą kodu, architektury, repozytorium, środowisk, dokumentacji, integracji i zgłoszonych problemów. Dopiero po przeglądzie możemy odpowiedzialnie określić zakres i ryzyka.
Tak. Możemy zaplanować aktualizację technologii, refaktoryzację, wydzielenie modułów, przebudowę integracji albo stopniowe zastępowanie systemu. Rekomendacja zależy od stanu kodu i wartości biznesowej obecnego rozwiązania.
Zasady dotyczące praw do kodu określa umowa. Osobno należy uwzględnić biblioteki, komponenty open source, licencje i usługi zewnętrzne, które podlegają własnym warunkom.
Zakres dokumentacji ustalamy zależnie od rodzaju projektu. Może ona obejmować architekturę, integracje, API, konfigurację środowisk, instrukcje administracyjne i sposób wdrażania zmian.
Projekty rozwijane iteracyjnie najczęściej realizujemy w modelu Time & Materials. Mniejsze i dobrze określone etapy mogą zostać oszacowane jako zamknięty zakres. Model powinien odpowiadać poziomowi niepewności i możliwości zmiany priorytetów.
Tak. Analiza, warsztaty, prezentacje, akceptacje i większość prac mogą odbywać się zdalnie. Warunkiem sprawnej współpracy jest dostępność właściwych osób oraz uporządkowany proces decyzyjny.
Tak. Możemy realizować monitoring, poprawki, aktualizacje, rozwój funkcji i prace techniczne. Zakres, priorytety i czasy reakcji zależą od uzgodnionego modelu współpracy oraz ewentualnego SLA.
Projekt dedykowanego systemu może łączyć aplikacje webowe, platformy B2B, integracje, WordPress, WooCommerce i rozwiązania e-commerce. Zobacz pozostałe usługi Webtom.pl dla firm z Wrocławia:
Opisz proces, który chcesz usprawnić, osoby korzystające z rozwiązania, wykorzystywane obecnie narzędzia oraz dane, które powinny być wymieniane pomiędzy systemami.
Na tej podstawie określimy, czy kolejnym krokiem powinna być analiza techniczna, discovery, projekt UX/UI, przygotowanie integracji, wycena pierwszego etapu czy audyt istniejącego oprogramowania.
Porozmawiajmy o dedykowanym systemie
Sławomir Woźniak
New Business | PL
Zastanawiasz się wg jakich kryteriów wybrać software house do współpracy? Poznaj istotne kryteria.
Software House, agencja interaktywna czy freelancer? Poznaj kluczowe różnice i sprawdź kogo wybrać.
