Modernizacja systemów

Zaplanowania modernizacja systemów informatycznych często jest rezultatem nowej strategii biznesowej, dużych kosztów utrzymania i rozwoju systemów, niskiego poziomu bezpieczeństwa, wydajności czyli często określenia długu technologicznego. Określenie wielkości długu technologicznego i ryzyka z nim związane są często elementem zarządzania ryzykiem w firmie (Risk Management) oraz są uwzględnione w planie zachowania ciągłości biznesowej (Business Continuity Plan -BCP). Systemy zastane Legacy są obecnie jednym z poważniejszych wyzwań dla działów IT utrudniających rozwojów biznesowy.

Nowe strategie cyfrowe czy transformacje cyfrowe (Digital Transformation) wymagają od IT wysokoskalowalnych systemów, natychmiastowych zmian biznesowych, łatwych integracji oraz bezpieczeństwa danych. Dodatkowo presja na systemy IT jest ciągle w obszarze kosztów utrzymania tych systemów i ich rozwoju. Każda Strategia IT powinna obejmować elementy architektury systemów, ich rozwoju, a w przypadku długu technologicznego corowych systemów ich modernizację lub wymianę.

Modernizacja systemu jest często planowana na podstawie wykonanego audytu jakości kodu źródłowego, wydajności, architektury czy bezpieczeństwa.

Strategie IT realizowane przez Dyrektorów IT (CIO) odnosnie systemów Legacy

Strategie odnośnie systemów Legacy są związane m.in. z ważnością systemu, ilością wprowadzanych zmian, wystawieniem na ryzyko np. wycieku danych, ryzykiem wydajności systemu, itd. Strategie Legacy:

  • Strategia nie rób nic z systemem – utrzymanie
  • Eliminacja kluczowych problemów np. wydajnościowych czy bezpieczeństwa
  • Strategia modernizacji – refaktoring
  • Strategia wymiany systemu

Częste kierunki modernizacji systemów Legacy

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Architektura Cloud Native

Cloud Native to technologia wykorzystania chmury przy tworzeniu własnych aplikacji. Technologia korzystające z mikroserwisów, kontenerów czy usług bezserwerowych tzw. Serverless.

Planując architekturę Cloud Native należy zacząć m.in od pytania o stopień „przenaszalności” aplikacji pomiędzy dostawcami chmury (Vendor-lock). Kolejne pytania dotyczą apliakacji, które będziemy tworzyli lub przenosili. Dostawca chmury powinien być dopasowany do tych aplikacji, aby wykorzystać najlepiej ich możliwości.

W przypadku chęci uniezależnienia się od dostawcy chmury często stosuje się popularne kontenery np. na Kubernetes czy Amazon Elastic Container Service (Docker). Kontenery pozwalają na łatwą przenaszalność aplikacji pomiędzy środowiskami, budowanie mikroserwisów czy niemal nieograniczoną skalowalność.

Innym typem budowania aplikacji dla technologii Cloud Native jest wykorzystanie funkcjonalności chmur typu Serverless. Usługi tego typu są dostarczane przez wszystkich dostawców chmur jak AWS, Google GCP czy Microsoft Azure.

Aplikacje Cloud Native (Native Cloud Application – NCA) są tworzone zgodnie z zasadą rozdzielania zadań na usługi (mikroserwisy, mikrousługi) i zgodnie z zasadą oddzielania ich od infrastruktury np. z wykorzystaniem kontenerów czy funkcji serverless.

Jeśli potrzebujesz wsparcia w architekturze systemów czy audycie swoich aplikacji zapraszamy do kontaktu.

Zobacz także: doradztwo strategiczne IT

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

Wydajność w systemach i aplikacjach

Wydajność jest jednym z ważniejszych elementów funkcjonowania systemów, aplikacji czy usług informatycznych. Problemy z wydajnością są odczuwalne od razu, widoczne przez klienta i potrafiące wpłynąć na nasze przychody czy zyski np. poprzez niezrealizowanie umownego poziomu SLA (Service Level Agreement).

Problemy z wydajnością mogą dotyczyć:

  • Niepoprawnie stworzonej aplikacji lub zapytań sql do bazy
  • Ataków na dostępność i wydajność usług (Ataki DoS i DDos – Denial of Service)
  • Niepoprawnych konfiguracji bazy danych
  • Braki w zasobach sprzętowych serwerów czy macierzy
  • Niepoprawne konfiguracje serwerów i ich usług

Najczęstsze problemy spotykany w ostatnim roku związane z systemami i wydajnością:

  • Mało wydajne środowisko serwerowe
  • Brak rozdzielanie serwerów bazodanowych od aplikacyjnych
  • Pojedyncze bazy danych, brak separacji
  • Niewydajne API
  • Niepoprawne konfiguracja baz danych np. mała alokacja pamięci RAM
  • Niezoptymalizowane zapytania do baz danych
  • Brak wykorzystania cachowania
  • Brak wykorzystania narzędzi typu CDN czy Cloud dla aplikacji internetowych
  • Brak wykorzystania modularności czy mikrousług w architekturze platform czy sklepów internetowych
  • Problemy wydajnościowe na poziomie intergacji i wymiany danych pomiędzy sklepami internetowymi a systemami ERP czy WMS.

Zobacz także:

Jeśli potrzebujesz wsparcia w zakresie architektury systemów, poprawy wydajności czy audycie kodu źródłowego zapraszamy do kontaktu.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Centrum usług wspólnych (CUW) – Shared Service

Centra usług wspólnych (Shared Service Center, SSC) są bardzo popularną formą tworzenia struktur korporacyjnych wydzielając i centralizując kluczowe usługi w osobnych podmiotach. Podmioty te świadczą usługi głównie dla klienta wewnętrznego choć zawsze pojawia się strategi dywersyfikacja przychodów i otwarcie się na klienta zewnętrznego często konkurencyjnego do klienta wewnętrznego.

Najpopularniejszymi usługami świadczonymi przez tzw. CUW-y są usługi finansowo-księgowe i informatyczne z uwagi na ich skomplikowanie, czasochłonność, powtarzalność i często dużą dojrzałość procesu. Głównymi powodami powoływania shared service-ów lub jednostek BPO (Business Process Outsourcing) w Polsce są niższe koszty obsługi procesów niż w innych krajach, dostęp do wyspecjalizowanej kadry, aspekty kulturowe oraz przewidywalność gospodarcza czy prawna (!).

CUW-y informatyczne skupiają się na świadczeniu następujących usług:

  • Wytwarzanie oprogramowania
  • Utrzymanie systemów tele-informatycznych jak np. systemów SAP
  • Usługi Service Desk (Help Desk)
  • Utrzymanie infrastruktury sieciowej i tele-informatycznej

Głównymi parametrami takich usług jest cena świadczenia usługi oraz jakość świadczenia usługi SLA (Service Level Agreement). Często shared service specjalizują się w jednej usłudze np. centrum kompetencyjne SAP, które utrzymuje i rozwija systemy SAP dla całej grupy. Często centrum kompetencyjne skupia się np. tylko na wytwarzaniu oprogramowania i jego utrzymaniu.

Ostatnio bardzo popularne są shared service specjalizujące się w działaniach badawczo-rozwojowych (B+R, R&D – Research and Development).

Często wydzielenie shared service-ów lub tworzenie centrów kompetencyjnych jest elementem strategii cyfrowej transformacji a często wynika z analizy kosztów i możliwości.

Zobacz także:

Jeśli potrzebujesz wsparcia w cyfrowej transformacji, optymalizacji procesów IT zapraszamy do kontaktu.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Mikroserwisy w eCommerce – Architektura eCommerce

Mikroserwisy są podstawą architektury rozproszonej systemów zdecydowanie różniącej się od architektury monolitycznej oprogramowania. Mikroserwisy są pojedynczymi komponetntami, aplikacjami czy modułami realizującymi daną funkcjonalność lub świadczący usługi. Mikroserwisy wymieniają się danymi lub wchodzą w interakcję z innymi modułami architektury poprzez np. API (Application Programming Interface).

Mikroserwisy – korzyści

Mikroserwisy posiadają wiele korzyści np.:

  • Łatwiejsze zarządzanie architekturą oprogramowania, modułami, usługami
  • Łatwiejszy development w postaci rozwijania danych komponentów przez osobne zespoły
  • Minimalizacja błędów w innych modułach
  • Skalowanie na poziomie danej usługi nie systemu
  • Zwiększenie ciągłości biznesowej w przypadku awarii, internetu, Data Center, itd.
  • Zwiększenie wydajności systemu
  • Zmniejszenie (potencjalne) kosztów rozwojowych systemu

Mikroserwisy – wady

  • Zwiększenie stopnia trudności oprogramowania i projektu z uwagi na złożoność architektury rozproszonej (komunikacja pomiędzy usługami, itd.)
  • Zwiększenie kosztów wytworzenie i i utrzymania systemu
  • Zwiększenie skomplikowania testów usług dostawrczanych przez mikroserwisy
  • Trudniejsze wdrażania niż w architekturze monolitycznej

Mikroserwisy w eCommerce?

Mikroserwisy świetnie wpisują się w architekturę systemów eCommerce szczególnie tam gdzie jest dużo systemów takich jak sklepy internetowe B2B i B2C, pasaże handlowe, systemy wymiany danych, systemy kurierskie, systemy PIM (Product Information Management), systemy OMS (Order Management System), systemy CRM (Customer Relationship Management), systemy ERP (Enterprise Resources Management), systemy WMS (Warehouse Management System), systemy Marketplance, systemy do obsługi BOK (Biuro Obsługi Klienta), systemy kioskowe lub POS (Point of Sales) czt programy lojalnościowe. Mikroserwisy świetnie wkomponowują się w podejście Headless w CMS (Content Management System) oddzialającego backend od frontendu czy wykorzystaniu PWA (Progressive Web Application).

Jeśli potrzebujesz wsparcia w obszarze architektury eCommerce czy optymalizacji procesów eCommerce zapraszamy do kontaktu.

Zobacz naszą ofertę doradztwa:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Architektura Serverless (bezserwerowa)

Architektura bezserwerowa (Serverless Architecture) pozwala programistom na koncentrowaniu się na kodzie anie na serwerach. W tej architekturze płacimy za dostępność całej infrastruktury na żądanie np. wraz ze zwiększeniem obciążenia czyli tylko wtedy kiedy my czy nasi klienci używają zasobów serwerowych. W modelu serverless nie martwimy się zarówno utrzymaniem infrastruktury, jej updatami, licencjami, skalowaniem, wydajnością, konfiguracjami, backupami czy zespołem administratorów.

Architektura bezserwerowa pozwala na wykonywanie kodu w tradycyjnej architekturze monolitycznej jak i w architekturze rozproszonej (mikroserwisy).

Architektura bezserwerowa jest jedną z odmian platform chmurowych PaaS (Platform as a Service), IaaS (Infrastructure as a Service) i często określana także jako FaaS (Function as a Service).

Popularnymi na rynku usługami Serverless / FaaS są np. AWS Lambda, Azure Functions i Google Cloud Functions.

Zobacz naszą ofertę na doradztwo w obszarze IT:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów