Jedna osoba wie, jak system działa
Program napisał dawny wykonawca albo pracownik, który wciąż tu jest. Tylko on wie, dlaczego system nalicza rabat w ten sposób, a jego odejście zostawia firmę z kodem, którego nikt nie czyta.
Modernizacja systemów, które już działają
Twój system przebudowany po jednej części, bez zatrzymania pracy: wiedza o nim spisana w testach, składniki w wersjach ze wsparciem i kod, który da się zmieniać.
Sytuacje
Z czym przychodzą do nas klienci
Firma pracuje na systemie, który powstał lata temu i obsługuje jej główny proces: zamówienia, produkcję, rozliczenia. Działa, ale coraz wolniej, każda zmiana czeka w kolejce, a na pytanie, dlaczego zrobił to, co zrobił, odpowiada jedna osoba. Wymiana na nowy system oznacza długi okres bez zmian i dzień, w którym wszystko przełącza się naraz.
Producent nie wspiera już wersji, na której stoi system
Baza danych, system operacyjny albo gotowe elementy kodu innych producentów są w wersji bez poprawek, także bezpieczeństwa. Nowsza wersja nie przyjmie starego kodu bez zmian, a zmian nikt nie chce ruszać, bo nie wiadomo, co przestanie działać.
Każda zmiana trwa długo, a system zwalnia
Nowy cennik albo pole w formularzu czekają długo, bo kod jest spleciony: poprawka w jednym miejscu zmienia zachowanie w innym. Zmiany sprawdzają ludzie ręcznie, a z rosnącą liczbą danych system zwalnia i firma obchodzi go arkuszami.
Zakres
Co robimy
Modernizacja to przebudowa działającego systemu po jednej części. Najpierw rozkładamy go na części: dane, reguły (kod, który liczy ceny i terminy), ekrany, połączenia z innymi systemami i składniki, na których to stoi, jak wersja bazy danych i serwery. O każdej części decydujemy osobno: zostaje, jest wymieniana albo przenoszona na wersję ze wsparciem.
Co zostaje, co wymieniamy
Dane zostają prawie zawsze; przenosimy je na wersję bazy danych, do której producent wydaje poprawki. Składniki bez wsparcia aktualizujemy jako pierwsze, bo na nich stoi reszta. Reguły wymieniamy po jednej, według liczby zmian, które za każdą czekają, ekrany tam, gdzie spowalniają pracę. Połączenia z innymi systemami zostawiamy; ich uporządkowanie w jedno miejsce wymiany danych to osobny zakres.
Zanim ruszymy kod, otaczamy go testami automatycznymi: programami, które zapisują, jak system odpowiada dziś na każdy typ sprawy, i sprawdzają to po każdej zmianie. Wiedza o regułach przechodzi z pamięci jednej osoby do testów; ta osoba czyta z nami kod i tłumaczy każdą regułę. Refaktoryzacja, czyli przebudowa kodu bez zmiany tego, co system robi, sprawia, że zmiana w jednym miejscu przestaje psuć inne. Miejsca, gdzie system zwalnia, przebudowujemy pod kątem skalowalności, czyli obsługi większego ruchu.
Stare i nowe obok siebie
Nową część uruchamiamy obok starej, na tych samych danych, więc stary system widzi wszystko, co zapisze nowa. Między nimi stoi przełącznik: ustawienie, które kieruje daną funkcję do starego albo nowego kodu bez instalowania nowej wersji. Przez uzgodniony czas obie wersje liczą to samo, a wyniki porównujemy. Stary kod wyłączamy, gdy różnice znikną, a gdy nowa część zawiedzie, przełącznik wraca na starą.
Kiedy przepisanie od zera jest błędem
Gdy nikt nie potrafi wypisać wszystkiego, co system dziś robi: system pisany od zera odtwarza to, co ludzie pamiętają, a reszta wraca po przełączeniu jako reklamacje. Przebudowa po części wyłapuje to przed wyłączeniem starego kodu. Gdy rdzeń liczy dobrze, a przeszkadza to, co wokół niego: wolne ekrany, brak raportów, składniki bez wsparcia; wymiana otoczenia to mniejszy zakres niż nowy system. Nowy system budujemy, gdy analiza pokaże, że stary rdzeń nie obsłuży procesu, którego firma potrzebuje; to osobny zakres.
Wynik
Co dostajesz
- Mapa systemu: funkcje, dane, połączenia i wersje składników, z decyzją: zostaje, wymieniana albo aktualizowana.
- Plan przebudowy w krokach: kolejność, co działa po każdym kroku i jak wrócić do poprzedniego stanu.
- Testy automatyczne zapisujące dzisiejsze zachowanie systemu, uruchamiane przy każdej zmianie.
- Spis reguł działania systemu, zebrany od osób, które go znają, czytelny dla kolejnego wykonawcy.
- Przebudowane części w codziennej pracy, z kodem i dokumentacją po stronie firmy.
Przebieg
Jak przebiega praca
Rozpoznajemy system.
Czytamy kod i bazę danych, rozmawiamy z osobą, która system zna, i mierzymy, gdzie zwalnia. Wynik: mapa systemu i plan przebudowy z pierwszym krokiem do Twojej akceptacji.
Zabezpieczamy to, co jest.
Budujemy testy automatyczne, stawiamy środowisko testowe, czyli kopię systemu do sprawdzania zmian przed uruchomieniem u pracowników, i aktualizujemy składniki bez wsparcia. Wynik: system w wersjach ze wsparciem, gotowy do przebudowy.
Wymieniamy po jednej części.
Nowa część rusza obok starej, za przełącznikiem, z porównaniem wyników. Wynik: kolejne funkcje w nowym kodzie, stary kod wyłączany po Twoim potwierdzeniu.
Przekazujemy system.
Oddajemy kod, dokumentację i sposób wprowadzania zmian, uczymy Twoich ludzi uruchamiać testy. Wynik: system zmienia Twój zespół albo wykonawca według umowy; utrzymanie po starcie to osobny zakres.
Doświadczenie
Doświadczenie zespołu
Osoby z zespołu przebudowywały system monitoringu infrastruktury dostawcy usług internetowych na rynku amerykańskim pod kątem skalowalności, czyli obsługi większego obciążenia. Przenosiły też system workflow, czyli obiegu zadań, do chmury Azure i automatyzowały jego obsługę, dla klienta z rynku europejskiego.
Umów spotkanie
Umów rozmowę o problemie
Opisujesz proces albo system, który przestał wystarczać, i mówisz, co ma się zmienić. Rozmowa nic nie kosztuje.
Telefon: +48 455 406 404
Przed umową
Pytania, które zarząd powinien zadać wykonawcy modernizacji
- Które części systemu zostają, które wymieniacie i dlaczego?
- Co działa po pierwszym kroku i czy możemy się na nim zatrzymać?
- Jak sprawdzicie, że nowa część liczy to samo, co stara, i kto u nas to potwierdzi?
- Jak wrócimy do starej wersji, gdy nowa część zawiedzie, i kto o tym decyduje?
- Kto rozmawia z osobą, która dziś jako jedyna zna system, i w jakiej formie zostaje jej wiedza?
- Czy kod, testy i dokumentacja należą do nas i czy inny wykonawca może je przejąć?
Od którego miejsca zacząć, zależy od tego, co dziś hamuje pracę, dlatego pierwszym krokiem jest analiza systemu i procesu, zakończona rekomendacją: co zostaje, co wymienić i w jakiej kolejności.
Systemy dedykowane
System zbudowany pod Twój proces tam, gdzie gotowy produkt wymusza zmianę pracy, z kodem i dokumentacją, które należą do Twojej firmy.
Zobacz zakres
Łączenie systemów w jedną całość
Jedno miejsce, przez które ERP, CRM, system branżowy i arkusze wymieniają dane same, z opisem każdej wymiany i podglądem, czy działa.
Zobacz zakres
Portale operacyjne
Miejsce, w którym klient, partner albo pracownik sam składa wniosek, zamówienie lub zgłoszenie i sprawdza jego status, a dział obsługi widzi każdą sprawę w jednym podglądzie.
Zobacz zakres
Utrzymanie i rozwój
Twój system po starcie pod opieką zespołu, który go zbudował: poprawki, zmiany z procesu i przepisów, aktualizacje składników i podgląd pracy, w kolejności, którą ustalasz z nami.
Zobacz zakresJak zaczynamy
Rozmowa o problemie
Opisujesz proces albo system, który przestał wystarczać, i mówisz, co ma się zmienić. Rozmowa nic nie kosztuje.
Analiza pod NDA
Badamy proces i systemy i oddajemy rekomendację z zakresem prac. Zakres, termin i cenę analizy znasz przed jej startem.
Oferta
Dostajesz zakres, zespół, harmonogram i cenę wdrożenia. Decydujesz, czy ruszamy.
Koszt analizy zaliczamy na poczet wdrożenia, jeśli je zamówisz.
Telefon: +48 455 406 404 E-mail: contact@aliaxit.com