Jak wygląda współpraca z software house (proces krok po kroku)
Sprawdź, jak wygląda współpraca z software house – od analizy po wdrożenie i rozwój. Poznaj proces krok po kroku i uniknij kosztownych błędów.
Webtom.pl projektuje i rozwija dedykowane oprogramowanie dla firm ze Szczecina, które potrzebują rozwiązania dopasowanego do własnych procesów, użytkowników, danych i reguł biznesowych.
Projekt może obejmować system biznesowy, aplikację webową, panel klienta lub partnera, integrację istniejących narzędzi, automatyzację wybranego procesu albo dalszy rozwój oprogramowania, które firma już posiada.
Punktem wyjścia nie jest technologia. Najpierw analizujemy proces, role użytkowników, dane, zależności oraz miejsca, w których standardowe narzędzia przestają odpowiadać rzeczywistemu sposobowi działania organizacji.
Dopiero wtedy określamy, czy właściwym kierunkiem jest system dedykowany, integracja, mniejsza automatyzacja, rozwój istniejącej aplikacji czy wykorzystanie gotowego rozwiązania.
Własne oprogramowanie powinno mieć uzasadnienie biznesowe lub operacyjne. Jeżeli standardowe narzędzie realizuje wymagania bez istotnych kompromisów, nie rekomendujemy budowy dedykowanego systemu tylko dlatego, że jest technicznie możliwa.
Więcej o takich realizacjach opisujemy w usłudze Systemy dedykowane.
Firma może realizować ten sam zasadniczy proces dla wielu klientów, partnerów lub rynków. Dane, główne etapy i historia działań mogą pozostawać wspólne niezależnie od konkretnego scenariusza.
Wybrane kroki procesu mogą jednak zależeć od rynku, typu klienta, partnera, kanału albo innego warunku biznesowego.
System może wymagać innych informacji w zależności od tego, kto korzysta z procesu i jaki wariant obsługi został uruchomiony.
W konkretnych scenariuszach mogą obowiązywać inne dokumenty, szablony albo zasady ich generowania.
To, do którego użytkownika lub zespołu trafia kolejny etap, może zależeć od typu klienta, partnera, rynku albo statusu sprawy.
Nie każdy wariant procesu musi korzystać z tych samych systemów zewnętrznych. Reguły powinny określać, kiedy i gdzie dane są przekazywane.
Dane powinny pozwalać analizować wspólny proces jako całość, ale również rozróżniać warianty, jeżeli jest to potrzebne biznesowo.
Celem nie jest tworzenie osobnego systemu dla każdego wariantu. Dobrze zaprojektowana architektura oddziela wspólny rdzeń procesu od reguł, które rzeczywiście wymagają różnego działania.
Projektujemy rozwiązania dla procesów, których nie można efektywnie obsłużyć standardowym narzędziem albo których specyfika uzasadnia stworzenie własnego software.
Budujemy systemy uwzględniające użytkowników, role, dane, statusy, reguły biznesowe i wymagane integracje.
Tworzymy aplikacje dostępne przez przeglądarkę, przeznaczone dla pracowników, klientów, partnerów lub innych grup użytkowników.
Zakres może obejmować logowanie, dane indywidualne, dokumenty, statusy, historię działań lub funkcje odpowiadające konkretnemu procesowi.
Łączymy rozwiązania z zewnętrznymi systemami i usługami, gdy wymiana danych jest potrzebna do prawidłowego działania procesu.
Analizujemy miejsca, w których powtarzalne działania, ręczne przepisywanie danych lub generowanie dokumentów mogą zostać zautomatyzowane.
Możemy przejąć działający projekt i dalej go rozwijać po wcześniejszej analizie technologii, kodu, integracji i środowiska.
Dedykowane oprogramowanie ma sens wtedy, gdy system powinien odpowiadać sposobowi działania firmy zamiast wymuszać na organizacji dostosowanie całego procesu do ograniczeń gotowego produktu.
Przed developmentem określamy użytkowników, role, dane, etapy procesu, reguły biznesowe oraz zależności od systemów zewnętrznych.
Pozwala to rozdzielić wymagania potrzebne w pierwszej wersji od funkcji, które mogą zostać rozwinięte później.
Oprogramowanie na zamówienie nie powinno jednak zastępować gotowego narzędzia bez wyraźnego powodu. Decyzja o budowie własnego systemu powinna wynikać z realnej potrzeby biznesowej, technologicznej lub operacyjnej.
System może udostępniać inne funkcje pracownikowi, administratorowi, klientowi albo partnerowi.
Aplikacja może prowadzić użytkownika przez kolejne etapy procesu i kontrolować, jakie działania są dostępne w konkretnym statusie.
Informacje mogą być przechowywane centralnie zamiast w kilku arkuszach, wiadomościach i niezależnych narzędziach.
W systemach obsługujących ważne procesy warto mieć możliwość sprawdzenia, kto i kiedy wykonał określone działanie.
Zakres może obejmować generowanie, udostępnianie lub przechowywanie dokumentów powiązanych z konkretną sprawą.
Aplikacja może być rozwijana etapowo wraz ze zmianą potrzeb i pojawianiem się nowych scenariuszy.
Jeśli standardowy produkt realizuje najważniejsze wymagania bez kosztownych obejść, może być lepszym rozwiązaniem niż tworzenie własnego systemu.
Czasami problem można rozwiązać przez właściwą konfigurację narzędzia, które firma już posiada.
Jeżeli systemy dobrze realizują własne zadania, ale nie wymieniają danych, problemem może być brak integracji, a nie brak kolejnego produktu.
Wybrany fragment procesu może zostać usprawniony bez budowania dużej aplikacji od początku.
Własne rozwiązanie ma sens, gdy specyficzny proces, reguły biznesowe albo zależności pomiędzy użytkownikami i danymi rzeczywiście wymagają indywidualnej architektury.
Przed rozpoczęciem integracji określamy, który system jest odpowiedzialny za konkretną informację.
Dane mogą przepływać jednokierunkowo albo w kilku kierunkach, zależnie od procesu.
Analizujemy dokumentację oraz możliwości techniczne zewnętrznego systemu.
Integracja powinna określać nie tylko co przekazujemy, ale również kiedy, w jakich warunkach i dla jakiego wariantu procesu.
Należy uwzględnić sytuację, w której system zewnętrzny jest czasowo niedostępny lub zwraca nieprawidłową odpowiedź.
Przy istotnych procesach warto mieć możliwość sprawdzenia, czy operacja została wykonana oraz jakie dane zostały przesłane.
Jeżeli istotną częścią projektu jest wymiana danych z systemem ERP, szerszy zakres takich prac opisujemy w usłudze Integracje z systemami ERP.
Jeżeli te same informacje są przenoszone pomiędzy systemami przez pracowników, warto sprawdzić możliwość automatycznej wymiany.
System może generować dokumenty na podstawie danych już dostępnych w procesie.
Zmiana etapu może uruchamiać określone działania bez ręcznej obsługi.
Reguły mogą automatycznie kierować sprawę do właściwego użytkownika lub zespołu.
Dane mogą być agregowane bez konieczności ręcznego tworzenia kolejnych zestawień
Sprawdzamy stack, strukturę projektu i najważniejsze zależności.
Analizujemy wybrane elementy kodu istotne dla planowanego zakresu dalszych prac.
Ustalamy, które systemy zewnętrzne są krytyczne dla działania obecnego rozwiązania.
Sprawdzamy dostępne materiały i określamy obszary wymagające dodatkowego poznania.
Weryfikujemy sposób developmentu, testowania i wdrażania kolejnych wersji.
Nie zakładamy automatycznie konieczności przepisywania systemu. Najpierw oceniamy, które problemy realnie ograniczają dalszy rozwój.
Na tej podstawie można określić priorytety: stabilizacja, refactoring wybranych elementów, nowe funkcje, integracje albo większa przebudowa.
Określenia software house i firma programistyczna są często używane zamiennie, ale w praktyce zakres odpowiedzialności może się różnić.
Firma programistyczna może realizować przede wszystkim development na podstawie przygotowanej wcześniej specyfikacji.
Software house może uczestniczyć również w analizie procesu, określaniu reguł biznesowych, architekturze rozwiązania, UX/UI, integracjach, testach i dalszym rozwoju systemu.
Nie oznacza to, że jeden model jest zawsze lepszy. Kluczowe jest dopasowanie kompetencji wykonawcy do rzeczywistego zakresu projektu.
Określamy, jaki proces ma zostać usprawniony oraz jaki efekt biznesowy powinno zapewnić rozwiązanie.
Ustalamy, kto będzie korzystał z systemu oraz jakie role i uprawnienia są potrzebne.
Określamy najważniejsze informacje, statusy, zależności i warunki wpływające na działanie procesu.
Rozdzielamy funkcje potrzebne na start od elementów, które można rozwijać później.
Projektujemy strukturę rozwiązania oraz zależności pomiędzy jego głównymi elementami.
Jeżeli system posiada interfejs użytkownika, projektujemy potrzebne widoki i ścieżki działania.
Realizujemy uzgodnione funkcje frontendowe i backendowe.
Łączymy rozwiązanie z systemami i usługami objętymi zakresem.
Sprawdzamy funkcje, role, przepływy i integracje.
Uruchamiamy zaakceptowaną wersję na przygotowanym środowisku.
System może być dalej rozwijany o kolejne funkcje, reguły i integracje.
Szczegółowo cały proces opisujemy również w artykule Jak wygląda współpraca z software house (proces krok po kroku).
Wybór modelu współpracy powinien wynikać z wielkości i charakteru projektu. Przy niewielkim, dobrze określonym zadaniu pojedynczy specjalista może być odpowiednim rozwiązaniem.
Większy system może natomiast wymagać kilku kompetencji jednocześnie:
W takim przypadku zaletą zespołu jest możliwość połączenia tych kompetencji w jednym procesie. Nie oznacza to jednak, że każdy projekt wymaga pełnego zespołu przez cały okres realizacji.
Jeżeli standardowy produkt obsługuje proces bez istotnych ograniczeń i kosztownych obejść, budowa własnego odpowiednika może nie być uzasadniona.
Nowy software nie rozwiąże procesu, którego zasady nie zostały jeszcze określone.
Jeśli dwa obecne systemy działają poprawnie, ale nie wymieniają danych, właściwym rozwiązaniem może być ich połączenie.
Nie każdy problem wymaga rozbudowanej aplikacji.
Dedykowane oprogramowanie wymaga dalszego utrzymania i podejmowania decyzji również po pierwszym wdrożeniu.
Najpierw określamy problem, proces i zakres, a dopiero później dobieramy rozwiązanie technologiczne.
Możemy realizować zarówno logikę systemu, jak i jego interfejs.
Jeżeli projekt wymaga interfejsu, możemy połączyć development z projektowaniem doświadczenia użytkownika.
Realizujemy projekty wymagające wymiany danych z systemami i usługami zewnętrznymi.
Możemy stworzyć system od początku albo rozpocząć od analizy działającego rozwiązania.
Od ponad 20 lat projektujemy i rozwijamy rozwiązania internetowe oraz dedykowane systemy.
Po pierwszej wersji możemy realizować kolejne funkcje, integracje i etapy.
Jeżeli projekt wymaga zaprojektowania interfejsu systemu, zakres takich prac opisujemy również w usłudze Projektowanie UX/UI.
Software house projektuje, tworzy i rozwija oprogramowanie dla firm, między innymi systemy dedykowane, aplikacje webowe, integracje i rozwiązania automatyzujące procesy biznesowe.
Firma IT może świadczyć szeroki zakres usług związanych ze sprzętem, sieciami, infrastrukturą lub outsourcingiem informatycznym. Software house koncentruje się przede wszystkim na projektowaniu i rozwoju oprogramowania.
Określenia mogą być używane zamiennie, ale zakres software house może obejmować poza developmentem również analizę, architekturę, UX/UI, integracje, testy i dalszy rozwój rozwiązania.
To rozwiązanie tworzone pod konkretne procesy, użytkowników, dane i reguły biznesowe organizacji zamiast dostosowywania całego procesu do ograniczeń gotowego produktu.
Gdy gotowe rozwiązania nie obsługują kluczowego procesu, wymagają wielu ręcznych obejść albo własny software ma istotne uzasadnienie biznesowe lub technologiczne.
Jeżeli gotowe narzędzie realizuje wymagania przy rozsądnym koszcie i bez istotnych ograniczeń, jego wdrożenie może być lepsze niż stworzenie własnego odpowiednika.
Koszt zależy od liczby funkcji, użytkowników i ról, reguł biznesowych, UX/UI, integracji, migracji danych, testów oraz złożoności technicznej.
Termin zależy od zakresu i złożoności rozwiązania. Większe projekty można dzielić na kolejne etapy.
Tak, jeżeli da się wydzielić pierwszą wersję rozwiązującą najważniejszy problem i pozwalającą zweryfikować kluczowe założenia.
Tak. Zakres może obejmować aplikacje dla pracowników, klientów, partnerów lub innych użytkowników, wraz z odpowiednimi rolami, danymi i funkcjami.
Tak, jeżeli zewnętrzny system udostępnia odpowiedni mechanizm integracji. Zakres zależy od dokumentacji, danych i procesu.
Tak. Można zaprojektować wspólny rdzeń procesu oraz reguły uruchamiane zależnie od typu użytkownika, klienta, partnera, rynku lub innego warunku biznesowego.
Tak. Przed większym zakresem developmentu analizujemy technologię, kod, integracje, środowisko oraz elementy wpływające na możliwość dalszego rozwoju.
Tak. W większych projektach można określić pierwszy zakres oraz kolejne etapy zgodnie z priorytetami biznesowymi i technologicznymi.
Tak. Możemy realizować kolejne funkcje, integracje, optymalizację i inne uzgodnione prace. Zakres oraz czasy reakcji zależą od modelu współpracy i ewentualnego SLA.
Jeżeli zakres projektu jest już określony, sprawdź również wyspecjalizowane usługi Webtom.pl dla firm ze Szczecina:
Jeżeli projekt obejmuje kilka tych obszarów jednocześnie, zakres możemy uporządkować przed przygotowaniem właściwego planu realizacji.
Planujesz dedykowany system, aplikację webową albo integrację? A może posiadasz już oprogramowanie, które wymaga dalszego rozwoju? Opisz proces, użytkowników, dane, najważniejsze reguły biznesowe, obecne narzędzia oraz systemy, z którymi rozwiązanie powinno współpracować. Na tej podstawie określimy, czy właściwym kierunkiem jest system dedykowany, aplikacja webowa, integracja, automatyzacja, rozwój istniejącego oprogramowania czy realizacja projektu w kilku etapach.
Skontaktuj się z nami
Sławomir Woźniak
New Business | PL