Cykl życia oprogramowania – Software Development Life Cycle

Cykl życia oprogramowania (and. Software Development Life Cyckle – SDLC) jest usystematyzowanym podejściem do tworzenia, rozwoju oraz wycofywania danego programowania. Dzięki procesowemu podejściu wspartego przez narzędzia IT zarządzamy zarówno tym oprogramowaniem, podnosimy jakość, zmniejszamy dług technologiczny oraz zwiększamy dojrzałość organizacji wytwarzania oprogramowania.

SDLC może składać się z kilku procesów:

  1. Analiza wstępna – faza inicjalna dla każdego projektu biznesowego czy informatycznego. Określamy potrzeby, wymagania, potencjalne koszty, możliwości, zasoby potrzebne do realizacji czy ryzyka dla danego projektu. Jego potencjalne korzyści biznesowe, ramy czasowe czy opłacalność (ROI).
  2. Analiza szczegółowa, spis wymagań – szczegółowa analiza wymagań odnośnie systemów, ich integracji, kosztów, harmonogramu prac, zwrotów z inwestycji, ryzyk projektowych, itd. Analiza aspektów technologicznych, UX (User Experience), prawnych, bezpieczeństwa czy operacyjnych np. zmiany w procesach Biura Obsługi Klienta (BOK), itd.
  3. Projektowanie oprogramowania – projektowanie architektury systemów, ich integracji, bezpieczeństwa, skalowalności, zasad kodowanie, frameworków czy interfejsu użytkownika (UI – User Interface).
  4. Wytwarzanie oprogramowania (kodowanie) – najdłuższa faza projektu realizowania wg. wybranej metodyki zarządzania projektem np. Scrum. Podczas tej fazy jest tworzony kod aplikacji zgodnie z zasadami i wymaganiami ustalonymi we wcześniejszych fazach np. tworzenie testów jednostkowych czy automatycznych, dokumentacji, itd.
  5. Integracje i testy – testowanie zarówno interfejsów, szybkości działania, wydajności, bezpieczeństwa czy poprawności integracji danych.
  6. Wdrożenie na produkcję – wdrożenie oprogramowania na produkcję zgodnie z wcześniej ustaloną strategią wdrażania np. testy AB na mniejszej ilości klientów, itd. Testowanie poprawności systemu, integracji oraz infrastruktury tele-informatycznej.
  7. Utrzymanie systemów – utrzymanie systemów łącznie z wykrywaniem i łataniem błędów, zwiększonym ruchem czy większą ilością użytkowników. Zmiany w infrastrukturze tele-informatycznej oraz zwiększanie bezpieczeństwa systemu.
  8. Dalszy rozwój systemu – procedura zgłaszania zmian rozwojowych, ich wdrożenie, testowanie i ich wpływa na działanie systemu czy integracji.
  9. Wyłączenie systemów – upgrady systemów, ich archiwizacja, wyłącznie, migracja danych, itd.

Zapraszamy do zapoznania się z naszą ofertą doradztwa technologicznego i audytów aplikacji

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 300 zadowolonych klientów

Zarządzanie zmianą (Change Management)

Zarządzanie zmianą (Change Management) jest jednym z ważniejszych obszarów biznesowych, szczególnie ważnych dla firm, które przechodzą transformację cyfrową (Digital Transformation). Zmiana organizacyjna może być trudna szczególnie w tradycyjnych biznesach. Wymaga odpowiedniego podejścia, planowania, komunikacji i silnego wsparcia w obszarze zarządzania projektami (Project Management). Zmiana może być jednorazowa, natychmiastowa, może być też długa np. wieloletnia lub cykliczna (organizacja nastawiona na zmiany). Zarządzanie zmianą w większości w przypadków musi przewidzieć opór użytkowników (pracowników), negację zmiany, itd. dlatego zmiana musi za sobą nieść długofalowe korzyści dla pracowników, dopracowane procesy, produkty, strategię, itd. Zmianą powinna być łączona z projektami, gdyż nawet najlepiej wdrożony system informatyczny spotka się z negacją w przypadku braku zarządzania zmianą wśród użytkowników końcowych.

Dla osób zainteresowanych tematyką zarządzania zmianą polecamy model PROSCI Change Management, jeden z najlepszych i najczęściej wdrażanych modeli CM na świecie.

Zobacz także:

Jeśli potrzebujesz wsparcia w obszarze zarządzania zmianą, zarządzania projektami czy optymalizacji procesów biznesowych zapraszamy do kontaktu.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Zarządzanie zmianą a projekty

Zarządzanie zmianą (Change Management) i zarządzanie projektami (Project Management) są ze sobą ściśle powiązane, a sukces jednego jest sukcesem drugiego, podobnie jak porażka. Obszary te są bardzo synergiczne i zależne od siebie. Dlaczego zatem w praktyce różnice dzielące oba obszary są ogromne?

Zarządzanie zmianą może być na poziomie procesów albo organizacji np. zmiana procesów poprzez wdrożenie systemu informatycznego czy zmiana całej organizacji np. w wyniku transformacji cyfrowej (Digital Transformation). Zarządzanie zmianą często korzysta z doświadczenia i kompetencji miękkich celem wprowadzenia zmiany w przeciwieństwie do kompetencji zarządzania projektami, które swoją genezę posiadają w działach inżynierskich. Kompetencje te są ściśle powiązane z technologią, zadaniami i celami. Zarządzanie zmianą natomiast często dotyka takich elementów jak aspekty społeczne, przywództwo czy strategia. Zarządzanie projektami z uwagi na inżynierski charakter posiada także więcej narzędzi w postaci best practices, frameworków czy metodyk.

Warto oba obszary łączyć i sukces jednego łączyć z sukcesem drugiego. Jeśli potrzebujesz wsparcia w obszarze zmian i projektów zapraszamy do kontaktu.

Zobacz naszą ofertę w obszarze Zarządzania kluczowymi projektami

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Ratowanie projektów?

Ratowanie projektów (project recovery) jest dość częstym tematem rozmów z klientami. Projekty, nawet jak korzystamy z dobrych firm wdrożeniowych często napotykają na problemy często nie do przejścia. Ratowanie projektów dotyczy głównie projektów wdrożenia corowych systemów jak systemów ERP, CRM, MES, WMS, TMS, itd., platform eCommerce czy systemów dedykowanych. Wdraża się je wewnętrznie lub zewnętrznie lub w modelu hybrydowym. Z uwagi na ilość systemów jednym z ważniejszych elementów jest też integracja z systemami wewnętrznymi.

Jakie są przyczyny szukania zewnętrznego wsparcia przez klienta?

  • Konflikt z dostawcą
  • Zbyt luźnie przeprowadzona analiza przedwdrożenowa
  • Zbyt długo ciągnąca się analiza przedwdrożeniowa z uwagi na brak wizji końca przez klienta
  • Przekraczanie harmonogramu wdrożenia – np. ryzyko nieskończenia przed sezonem sprzedażowym
  • Przekroczenia budżetu finansowego
  • Brak uwzględnienia w planie wdrożenia kluczowych integracji czy migracji danych
  • Brak stosowanych zapisów w mowach chroniących klienta
  • Źle dobrany dostawca
  • Problemy komunikacyjne po stronie klienta i dostawcy
  • Brak zarządzania ryzykiem (risk management) w projektach
  • Zbyt duża liczba obowiązków pracowników klienta prowadzących projekt
  • Zbyt duża liczba projektów równocześnie prowadzonych przed dostawce
  • itd.

Częstą usługą wykonywaną w takich przypadkach są doradztwo projektowe lub audyt wdrożeniowy projektu lub audyt powdrożeniowy systemu.

Zobacz naszą ofertę doradczą w zakresie Realizacji Kluczowych Projektów.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Audyt projektu wdrożenia systemu

Czemu tak często klienci poszukują wsparcia podczas wdrożenia corowych systemów takich jak systemy ERP, platformy eCommerce, systemy logistyczno-magazynowe TMS i WMS czy aplikacji dedykowanych i obsługujących corowe procesy klienta?

Powodów jest wiele:

  • Brak określenia docelowych procesów biznesowych przez klienta i częsta ich zmiana w trakcie
  • Niezrozumienie przez dostawcę procesów i potrzeb klienta
  • Problemy w komunikacji wynikającej m.in. z obłożenia klienta pracą operacyjną lub dostawcy z uwagi na ilość prowadzonych projektów
  • Brak dedykowanego zespołu wraz odpowiednim poziomem decyzyjności po stroni klienta
  • Ograniczone moce wytwórcze i analityczne po stronie dostawcy oprogramowania
  • Przeciągające się fazy odbiorów i testów modułów często wynikające z niechęci na branie odpowiedzialności za końcową decyzję przez klienta
  • Duża ilość błędów podczas testów i przerzucanie testów na klienta
  • Przekroczenia budżetu w wyniku zmian poza umową
  • Nierealne terminy przyjęte przez klienta i zaakceptowane przez dostawcę liczącego na przeciągnięcie projektu
  • Brak konsultacji wewnętrznej u klienta odnoście interfejsu wdrażanego systemu
  • Brak analizy integracji systemów
  • Brak analizy migracji systemów
  • Brak etapu tzw. czyszczenia danych przygotowującego dane do przeniesienia do nowego systemu.
  • Brak analizy ryzyka wdrożenia systemu i aktualizacja ryzyk w trakcie wdrożenia
  • Brak raportowania stanu wdrożenia systemu i reagowania na odchylenia, zmiany
  • Brak silnych umów regulujących sprawne wdrożenie systemu
  • itd.

Zobacz naszą ofertę wsparcia kluczowych projektów ERP, eCommerce i systemów dedykowanych: Zarządzanie kluczowymi projektami

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Rezygnacja z realizacji projektu w trakcie jego trwania

Jednym z częstszych błędów biznesowych jest kontynuacja projektu w trakcie jego wdrożenia mimo braku uzasadnienia jego dalszego wdrożenia czy z innych powodów. W Polsce panuje przekonania, że wszystkie projekty muszą się udać czyli muszą się skończyć. Dojrzałość biznesowa i projektowa powoduje jednak, że pojawiają się sytuacje z wstrzymaniem realizacji projektów czy całkowitą rezygnacją z ich prowadzenia. Są to decyzje poparte dogłębnymi analizami i przeświadczeniem o słuszności ich decyzji.

Niektóre decyzje o rezygnacji z projektu mogą być proste. Dotyczą one wdrażania systemów, które są nowe w organizacji i nie są corowe jak systemy FK, ERP czy systemy sprzedażowe. Rezygnacja z wdrażania systemu ERP już jest dość odważnym krokiem i powinna być bardzo uzasadniona.

Powody rezygnacji z realizacji projektów mogą dotyczyć:

  • Zmiana strategii firmy
  • Zbyt duże koszty wdrożenia
  • Nieopłacalność inwestycji
  • Brak zasobów wewnętrznych na realizację projektu
  • Pojawienie się ryzyk prawnych
  • Zmiany makroekonomiczne
  • itd.

Powody wstrzymania projektu mogą dotyczyć:

  • Ponownej analizy założeń projektowych
  • Zmiana dostawcy wdrożeniowego i przekazanie mu projektu
  • Zmiana PM-a projektu
  • Audyt wdrożenia projektu (realizacji)
  • Ponowny powrót do analizy przedwdrożeniowej systemu
  • itd.

Jeśli potrzebujesz wsparcia w wyborze dostawców systemów ERP, CRM, itd. czy wsparcia w realizacji projektów zapraszamy do kontaktu.

Zobacz naszą ofertę:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Wdrożenie systemu ERP – typowe błędy

Wdrożenie systemu ERP lub zastąpienie starego systemu nowym jest projektem z kategorii kluczowych i trudnych. Pochłania zarówno duże zasoby finansowe, reorganizuje procesy oraz angażuje dodatkowo całą firmę w długotrwałym procesie wdrożenia.

Aby projekt wdrożenia systemu ERP udał się, należy dobrze przygotować następujące elementy:

  • Analiza procesów AS IS – takich jakie są
  • Analiza procesów TO BE – takich jakie powinny być docelowo wynikające np. z trendów rynkowych (np. automatyzacja) czy strategii firmy
  • Wybór systemu i jego dostawcę najlepiej spełniającego wymagania zarówno biznesowe, finansowe czy technologiczne
  • Zapewnić wewnętrzne zasoby do realizacji projektu z silnym umocowaniem
  • Określić zasady zarządzania projektem, raportowania, zarządzania zmianami i odchyleniami
  • Przeprowadzić dobrze analizę przedwdrożeniową
  • Uporządkować i określić dane potrzebne do migracji
  • Uporządkować architekturę systemów i wymiany danych pomiędzy systemami
  • Spisanie realnych ryzyk projektowych wynikających zarówno u klienta jak i dostawcy
  • itd.

Najczęstsze problemy w realizacji wdrożeń systemu ERP:

  • Brak czasu użytkowników wewnętrznych na pracę przy analizie przedwdrożeniowej i testowaniu systemu
  • Brak buforu czasowego i finansowego dla projektu
  • Zbyt optymistyczny czas wdrożenia – brak zarządzania ryzykiem projektowym uwzględniające zarówno ryzyka u klienta jak i u dostawcy
  • Zbyt ogólna umowa wdrożeniowa lub utrzymania nieregulująca szybkość usuwania błędów krytycznych czy kary za opóźnienia po stronie dostawcy
  • Zbyt dużo projektów u dostawcy i opóźnienia w projekcie lub spadek jakości
  • Przerzucanie testowania funkcjonalności na klienta
  • Brak zarządzania ryzykiem i przygotowania się na wystąpienia ryzyka
  • Synchronizacja prac pomiędzy dostawcami np. w przypadku zmian w innych systemach lub ich integracji
  • Brak lidera projektów silnie umocowanego w zarządzie
  • itd.

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Wdrożenie sklepu internetowego (B2C, B2B) – wyzwania, problemy projektowe, biznesowe i technologiczne

Wdrożenie sklepu internetowego w przypadku prostych procesów, bez własnych stanów magazynowych, produkcji, sprzedaży wielokanałowej (Omnichannel np. Retail), dużej liczny systemów do integracji może być prostym zadaniem. W takiej sytuacji często wybiera się gotowe platformy SaaS (Software as a Service), gdzie ingerencja klienta jest głównie w UX (User Experience), UI (User Interface), moduły płatności, shippingu i ustalenie zasad rozliczania z dostawcą (abonament zależny od zużytych zasobów, ilości transakcji, itd.). W przypadku większych firm czy firm posiadających skomplikowane procesy biznesowe projekt wdrożenia własnej platformy B2B i/lub B2C może być bardziej skomplikowany i może napotkać wiele wyzwań czy problemów na swojej drodze. Poniżej przedstawiamy główne problemy z jakimi możemy się spotkać podczas wdrożeń projektów typu eCommerce:

  • Złe określenie harmonogramu projektu – zbyt optymistyczne, bez bufora, przed sezonem czy pickiem sprzedażowym, bez uwzględniania ważnych i często pomijanych elementów jak przygotowanie SEO, środowisk testowych czy produkcyjnych, testowania, poprawek i zmian. Zobacz Harmonogram projektów eCommerce
  • Zły dobór zasobów zarówno zewnętrznych jak i wewnętrznych – większa część projektów nie udaje się lub ma kłopoty z powodu złego doboru firmy wdrażającej, nie sprawdzenie jej kompetencji, doświadczenia, zasobów, obłożenia projektami oraz z powodu braku wystarczających zasobów do realizacji po stronie wewnętrznej lub po stronie innych dostawców np. systemu ERP czy WMS. Zobacz: Wybór dostawców systemów IT
  • Złe określenie zakresu lub oczekiwań z dostawcą – złe zrozumienie zakresu mające wpływ na harmonogram, ilość zmian i poprawek zarówno od strony zewnętrznej jak i wewnętrznej (tzw. nieskończony proces ulepszania MVP).
  • Złe określenie klienta docelowego – segmentacja klienta, potrzeby, UX
  • Brak uwzględnienia przygotowania dobrej jakości contentu na potrzeby projektu
  • Brak decyzyjności, odpowiedzialności i ról po stronie wewnętrznej
  • itd.

Jeśli potrzebujesz wsparcie przed projektem wdrożenia sklepu B2C i/ lub B2B, masz problemy w trakcie i potrzebujesz wsparcia technologiczno-procesowo-porjektowego zapraszamy do kontaktu.

Zobacz naszą ofertę doradztwa:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Przykładowy harmonogram prac wdrożenia eCommerce B2B, B2C

Harmonogram w każdym projekcie jest bardzo ważnym elementem projektu, nawet w przypadku projektów zwinnych wykorzystujących np. metodyki Scrum. Harmonogram bezpieczny dla eCommerce to wdrożenie produkcyjne z zapasem czasu na testy, przed pikiem sprzedażowym czy sezonem. Jeśli mamy już gotowy zakres projektu, ramy czasowe, budżet, zespół projektowy oraz cele biznesowe do osiągnięcia to pozostaje nam wybór dostawcy (zobacz proces wyboru dostawcy). Dostawca postrzegany jako partner jest kluczowym elementem powodzenia projektu. Po jego wyborze, procesie negocjacyjnym rozpoczynamy tworzenie harmonogramu prac i wdrożenia produkcyjnego.

Przykładowy proces wdrożenia platformy B2C/B2B może wyglądać następująco:

  • Warsztaty z Dostawcą – Customer Map Journey, Persony (segmentacja klienta)
  • Makiety – projektowanie UX (User Experience) i UI (User Interface)
  • Testy użyteczności makiet – testy na użytkownikach wewnętrzne, jakościowe, ilościowe zewnętrzne
  • Projekt graficzny wraz z akceptacjami klienta
  • Konfiguracja środowisk developerskich i testowych
  • Kodowanie Frontendu – kodowanie w wybranej technologii (frameworki)
  • Kodowanie API – np. do integracji Frontend z Backend
  • Kodowanie Backendu, CMS (Content Management System)
  • Integracja z ERP (Enterprise Resources Management) – integracja np. stanów magazynowych, zamówień, danych klientów, statusów płatności, itd.
  • Integracja z PIM (Product Information Management) – integracja contentu
  • Integracja z CRM (Customer Relationship Management) i Marketing Automation
  • Integracja z WMS (Warehouse Management System) – integracja stanów magazynowych i rezerwacji, procesów zwrotów, itd.
  • Integracja z płatnościami – integracja z płatnościami elektronicznymi i procesami rozliczeniowymi w ERP
  • Integracja z kurierami – integracja systemów kurierskich
  • Testy SIT (System Integration Testing) – testy integracyjne kodu plus testy jednostkowe czy systemowe
  • Testy UAT (User Acceptance Test) – testy akceptacyjne czy aplikacja, system jest wykonana zgodnie z założeniami
  • Konfiguracje SEO – przekierowania, seo, itd.
  • Konfiguracja środowiska produkcyjnego
  • Wdrożenie produkcyjne
  • Testy produkcyjne – m.in. testy wydajnościowe, konfiguracyjne
  • Optymalizacja systemu, tuning, rozwój

Zobacz naszą ofertę doradztwa:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

UAT czyli Testy Akceptacyjne

UAT (User Acceptance Tests) to testy akceptacyjne, które pozwalają odebrać stworzone oprogramowanie lub ich fragment przez osoby odpowiedzialne za procesy biznesowe lub klienta końcowego. Pozwalają one w prosty sposób określić dany ekran lub funkcjonalność jest zgodna z oczekiwaniami wszystkich odbiorców oprogramowania.

Testy akceptacyjne powinny uwzględniać np. za ISTBQ:

  • Wymagania użytkowników końcowych
  • Wymagania systemowe
  • Przypadki użycia
  • Procesy biznesowe

Przykłady testów akceptacyjnych UAT:

  • Testy akceptacyjne przez użytkownika wewnętrznego – czy product spełnia wymagania
  • Testy akceptacyjne przez klienta (CAT – Customer Acceptance Test) – czy oprogramowanie spełnia wymagania klienta
  • Testy Alfa – testy wewnętrzne deweloperów np. u wykonawcy
  • Testy Beta – testy poza zespołem wytwarzającym testy np. wśród użytkowników końcowych, itd.
  • Testy zgodności z podpisaną umową
  • Testy zgodności z prawem (legalności)
  • Testy akceptacyjne produkcyjne – testy na środowisku produkcyjnym, w różnych warunkach np. podczas obciążenia, awarii, problemów z danymi, itd.

W metodyce zwinnej Scrum UAT może być częścią Definition of Done czyli opisem jak ma wyglądać oddany produkt. Testy akceptacyjne UAT są w gestii odpowiedzialności Product Ownera i powinny być częścią sprintów Scruma.

Zobacz naszą ofertę doradztwa w zakresie projektów informatycznych

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów