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

Audyt działu informatycznego (IT)

Audyt działu IT jest częścią naszej oferty doradztwa strategicznego IT i budowania strategii IT. Wykonuje się go jeśli klient potrzebuje zwiększyć efektywność działania działu IT, podniesienie dojrzałości działu IT czy procedur, planuje wdrożenie norm ISO lub planuje np. połączenie dwóch spółek i zbudowanie jednej struktury organizacyjnej (zobacz Centrum Usług Wspólnych, Shared Service) czy przygotowuje się do Cyfrowej Transformacji (Digital Transformation).

Audyt zawsze powinien być dostosowany do wielkości organizacji, celów strategicznych firmy na najbliższe lata czy do możliwości dostępności zespołu IT. U jednym klientów głównym elementem jest centrum kompetencyjne SAP, u innych dział Help Desk a u innych dział wytwarzania oprogramowania czy zapewnienia bezpieczeństwa.

Przykładowy zakres audytu IT (patrz także rozszerzony Audyt IT Due Diligence):

  • Audyt procesów, procedur, norm IT – bezpieczeństwo, Service Desk, Business Continuity, zarządzanie dostawcami, standaryzacja, licencjonowanie, itd.
  • Audyt architektury systemów, długu technologicznego (ERP, BI, WMS, CRM, eCommerce, itd.)
  • Audyt obszaru zarządzania projektami lub Biura Projektów
  • Audyt wytwarzania oprogramowaniem
  • Audyt finansów IT
  • Audyt Strategii IT
  • Audyt infrastruktury tele-informatycznej
  • Audyt obszarem zarządzania danymi Big Data
  • Audyt działu R&D
  • Audyt usług tele-informatycznych
  • Audyt własności intelektualnej IP
  • Audyt prawny IT np. umowy z dostawcami
  • Zarządzanie ryzykiem
  • Audyt struktury organizacyjnej i kompetencji IT
  • itd.

Jeśli potrzebujesz wsparcia w obszarze IT, architektury systemów, zarządzania projektami IT zapraszamy do kontaktu.

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

Technologia Headless w eCommerce

Technologia Headless staje się coraz bardziej popularna zarówno w sklepach internatowych czy CMS-ach (Content Management System). Charakteryzuje się tym, że składa siętylko z backendu i nie koncentruje się na warstwie graficznej (frontend) jak było do tej pory. Oprogramowanie Headless może korzystać za pomocą API (Aplication Programming Interface) z różnych interfejsów graficznych zarówno na desktopie czy w mobile.

Obecnie bardzo modne są Headless CMS dla eCommerce i stron internetowych. Typowy CMS dla stron internetowych składa się z trzech elementów:

  • Baza danych
  • Backend – panele do zarządzania treścią
  • Frontend – warstwa wizualna

Headless eCommerce CMS pozwala skupić się na funkcjonalnościach panelu zarządczego, API i integracji z innymi systemami pozostawiając warstwę graficzną wyspecjalizowanym developerom skupiającym się na interfejsie i użyteczności (UX – User Experience, UI – User Interface).

Jakie są zalety Headless eCommerce CMS?

  • Odseparowanie prac and backend i frontend np. celem tworzenia frontendu poprzez zewnętrzną firmę np. agencję interaktywną specjalizującej się w warstwach graficznych i użyteczności
  • Stosowanie wielu różnych interfejsów graficznych np. mobile, internetowe sklepy dedykowane, aplikacja POS (Point of Sales) dla Retail, itd.
  • Często mniejsze koszty wymiany frontendu (zależne od wielu czynników w tym długu technologicznego backendu)
  • Przejrzysta architektura systemów eCommerce
  • Potencjalnie łatwiejsze zarządzanie długiem technologicznym i cyklem życia oprogramowania
  • Zwiększenie poziomu bezpieczeństwa systemu

Jakie są wady Headless eCommerce CMS?

  • Większe koszty developerskie do przygotowania, utrzymania i rozwoju API i frontendu
  • Często zmniejszenie wydajności stron www w wyniku braku doświadczenia w technologii Headless czy API.

Jeśli potrzebujesz wsparcia procesowo-technologicznego w obszarze eCommerce, Retail czy Omnichannel zapraszamy do kontaktu.

Zobacz naszą ofertę doradztwa:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Bezpieczeństwo systemów SAP

Systemy ERP firmy SAP podobnie jak inne systemy ERP powinny być odpowiednio zabezpieczone zarówno w obszarze zapewnienia ciągłości biznesowej (Business Continuity Plan) jak i w obszarze ochrony danych. GoTechnologies wspiera organizacje zarówno przy analizie procesów biznesowych, tworzeniu wymagań dla systemów, wyborze dostawców, doradztwie w zakresie architektury wymiany danych pomiędzy systemami, przy analizach przed wdrożeniowych a także na etapie wdrożeniowym jak i późniejszych audytach systemów SAP.

Audyt bezpieczeństwa systemów SAP może zawierać następujące elementy:

Potencjalne moduły przewidziane do audytu SAP: SD, FI, HR, PY

Zobacz naszą ofertę doradztwa technologicznego:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Zarządzanie ryzykiem IT

Zarządzanie ryzykiem (Risk Management) jest jednym z ważniejszych elementów prowadzenia firmy i powinno być uwzględniane w modelach biznesowych i podejmowaniu decyzji. Zarzadzanie ryzykiem także jest jednym z kluczowych elementów polityki zachowania ciągłości biznesowej (Business Continuity Plan – BCP).

Zarządzanie ryzykiem IT jest jednym z ważniejszych obszarów na mapie ryzyk biznesowych szczególnie przy realizacji procesów biznesowych przez systemy informatyczne, kiedy IT jest driverem rozwoju biznesu lub kiedy firma realizuje strategię cyfrowej transformacji (Digital Transformation). Często ryzyka IT to także ryzyka projektowe czyli nieudane projekty, przekroczenia terminów czy budżetów.

Ryzyka w IT możemy rozpatrywać w następujących obszarach:

  • Ryzyka związane z bezpieczeństwem danych i systemów tele-informatycznych
  • Ryzyka związane z usługami IT
  • Ryzyka związane z systemami IT
  • Ryzyka związane z wdrażaniem systemów IT np. ERP czy integracjami systemów
  • Ryzyka związane z telekomunikacją np. internat, wifi, telefonia IP
  • Ryzyka związane z długiem technologicznym w systemach IT
  • Ryzyka związane z brakiem procesów i procedur IT
  • Ryzyka związane z działaniem usług Help Desk (Service Desk)
  • Ryzyka związane z dostawcami usług i systemów IT (Vendor Locking)
  • Ryzyka związane z RODO (GDPR)
  • Ryzyka związane z Data Center i środowiskami chmurowymi
  • Ryzyka w obszarze wytwarzania oprogramowania
  • Ryzyka w obszarze zarządzania projektami i portfelem projektów
  • Ryzyko związane z utrzymaniem i eksploatacją IT
  • Ryzyko związane z finansami IT
  • itd.

Zobacz naszą ofertę doradztwa strategicznego w obszarze IT, Business Continuity Plan oraz cyfrowej transformacji:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Business Continuity Plan – zachowanie ciągłości biznesowej

BCP Plan (Business Continuity Plan) jest planem zachowania ciągłości biznesowej przygotowanym dla głównych procesów biznesowych z uwzględnieniem realnie mogących wystąpić ryzyk i przygotowanie scenariuszy minimalizacji tych scenariuszy.

Ryzyka biznesowe, które powszechnie występują w otoczeniu biznesowym i mają wpływ na procesy biznesowe:

  • Awarie Data Center
  • Awarie internetu
  • Awarie serwerów
  • Brak zasilania
  • Pożary
  • Sabotaże
  • Kradzież danych
  • itd.

Proces przygotowania planu BCP

Etap 1 – Przygotowanie planu BCP

  • Analiza procesów biznesowych i ich wpływ na prowadzenie biznesu, identyfikacja corowych procesów
  • Analiza ryzyk biznesowych, ich kategoryzacja, prawdopodobieństwo wystąpienia
  • Przygotowanie scenariuszy eliminujących lub ograniczających skutki wystąpienia ryzyka
  • Identyfikacja słabych stron i braku zabezpieczeń dla wystąpienia danego ryzyka
  • Przygotowanie Planu BCP

Etap 2 – Wdrożenie planu BCP

  • Przygotowanie harmonogramu wdrożenia planu BCP
  • Wyznaczenie osób odpowiedzialnych za wdrożenie planu BCP
  • Wdrożenie planu BCP
  • Szkolenia
  • Testowanie poprawności działania procedur BCP

Etap 3 – Audyt Business Continuity

  • Audyt poprawności wdrożenia i założeń planu BCP
  • Rekomendacje zmian w obszarze BCP

Disaster Recovery Plan i Backup Plan

Strategia backupów jest jedną z ważniejszych elementów zabezpieczenia danych przed ich utratą. Disaster Recovery Plan jest planem jak najszybszego przywrócenia usług czy systemów informatycznych po wystąpieniu awarii. Typy awarii są zdefiniowane w Business Continuty Plan jako ryzyka i skategoryzowane od realności ich wystąpienia.

Zarządzanie ryzykiem (Risk Management)

Zarządzanie ryzykiem jest jednym z ważniejszych elementów funkcjonowania zarówno nowoczesnego biznesu jak i IT, często nazywane ERM (Enterprise Management System). W obszarze IT ryzyka definiuje się w obszarach system/aplikacje, projekty, operacje i świadczenie usług. Jednymi z elementów zarządzania ryzykami są strategia bezpieczeństwa (polityka bezpieczeństwa), polityka Disaster Recovery, polityka Backupów czy polityka ochrony danych Data Loss Protection.

Zobacz także:

Jeśli potrzebujesz wsparcia w zabezpieczeniu firmy na wypadek wystąpienia ryzyk, audytu polityki bezpieczeństwa, chcesz zminimalizować dług technologiczny systemów czy architektury, itd. to zapraszamy do kontaktu.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Disaster Recovery Plan

Disaster Recovery Plan powinien być przemyślanym i przetestowanym planem przywrócenia po wystąpieniu awarii działania kluczowych systemów czy usług. DR Plan (lub DRP) jest częścią większego planu zachowania ciągłości biznesowej często nazywanego BCP (Business Continuity Plan).

Awariami są zazwyczaj problemy z infrastrukturą (np. brak prądu, awarie przełączników czy routerów, awarie dysków twardych, itd) czy ataki hakerskie (wewnętrzne i zewnętrzne). Awarie takie mogą wystąpić zarówno na poziomie lokalnym np. piętro czy budynek, na poziomie dzielnicy, miasta czy kraju. Wpływ tych awarii na krytyczne usługi jest określany w analizie ryzyka RA (Risk Analysis) lub analizie wpływu biznesowego BIA (Business Impact Analysis).

Obecnie jednym z największych zagrożeń są ataki na dane firmowe. Kradzież danych, szyfrowanie danych celem okupu, sprzedaż danych są jednymi z groźniejszych zagrożeń mających wpływ na naszą reputację i często istnienie firm.

Założenia Disaster Recovery Plan:

  • Określenie krytycznych aplikacji, usług i procesów
  • Określenie chronionych danych
  • Określenie czasu odtwarzania dla danych procesów, usług, aplikacji
  • Stworzenie polityki backupów
  • itd.

Disaster Recovery Plan powinien być testowany zanim dojdzie do awarii podobnie np. w regularne odtwarzanie i sprawdzanie poprawności backupów.

Disaster Recovery Plan może wykorzystywać zarówno wirtualizacje, środowiska chmurowe, środowiska hybrydowe, systemy Data Loss Protection, systemy redundantne, itd.

Jeśli potrzebujesz wsparcia w doradztwie strategicznym IT, budowanie strategii IT lub Strategii Cyfrowej Transformacji zapraszamy do kontaktu

Doradztwo strategiczne IT, Strategia IT

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów