Spis treści
„Bo tabele się zapchały”.
Takie uzasadnienie wymiany systemu ERP usłyszałem, gdy obejmowałem stanowisko dyrektora IT. Nowy system działał już od kilku miesięcy. W samej decyzji nie uczestniczyłem.
Nie będę więc rozstrzygał, czy migracja była słuszna. Ale obok tego zdania trudno było mi przejść obojętnie.
Zacząłem sprawdzać. W konfiguracji nowego systemu, działającego lokalnie, nie znalazłem zaplanowanych zadań utrzymaniowych dla bazy danych. Zajrzałem też do konfiguracji poprzedniego ERP, pozostawionego kilku osobom do podglądu. Tam było podobnie.
Czy to oznacza, że brak utrzymania spowodował problemy? Nie wiem. Prace mogły być wykonywane inaczej, a niektóre czynności bazy danych realizowane są automatycznie. Nie miałem też pełnego obrazu przesłanek wcześniejszej migracji.
Miałem natomiast coraz większą ochotę zapytać: co właściwie się „zapchało”? Przestrzeń na dysku? Wydajność? Możliwości rozwoju? A może sposób, w jaki zarządzano systemem?
Każda z tych odpowiedzi prowadziłaby do trochę innej rozmowy. Nie każda — do wymiany ERP.
Nie ustaliłem na tej podstawie, czy migracja była konieczna. Nie chcę też udawać, że znam zakończenie tej historii. Pozostało ważniejsze pytanie: jak odróżnić rzeczywiste ograniczenie systemu od problemu, który tylko w nim widać?
Gdzie boli, a gdzie jest przyczyna
Podobną pułapkę widziałem wielokrotnie, tylko na mniejszą skalę.
Ktoś proponował usprawnienie w konkretnym miejscu systemu. Pomysł brzmiał sensownie. Można było zamówić zmianę, przetestować ją, zamknąć zgłoszenie i z zadowoleniem odnotować kolejny sukces.
Zamiast tego proponowałem czasem cofnąć się o kilka kroków. Skąd wzięła się potrzeba? Co wydarzyło się wcześniej w procesie? Co ma się zmienić w działaniu firmy, nie tylko na ekranie?
Po kilku rozmowach okazywało się nieraz, że poprawka powinna powstać w zupełnie innym miejscu. Albo że zaproponowane rozwiązanie pozwoliłoby jedynie łatwiej znosić problem, którego nadal byśmy nie usunęli.
Nie oznacza to, że użytkownik źle zgłosił potrzebę. Często najlepiej wie, gdzie problem odczuwa. Nie musi wiedzieć, gdzie problem powstaje.
Zanim więc powiem „zrobimy” albo „nie da się”, chcę wiedzieć, co właściwie próbujemy naprawić.
To nie zawsze była popularna propozycja. Ktoś przychodził przecież z gotowym pomysłem i oczekiwał decyzji, a ja proponowałem kolejne pytania. Łatwo pomylić taki krok wstecz z opóźnianiem pracy. Trudniej dostrzec, że szybkie wdrożenie niewłaściwej poprawki nie jest szczególnym osiągnięciem.
Wymiana też bywa właściwą odpowiedzią
Nie zamierzam bronić każdego starego systemu tylko dlatego, że rano nadal wystawia faktury.
Bywają rzeczywiste ograniczenia technologiczne, brak wsparcia, istotne ryzyko bezpieczeństwa, trudności z integracją albo koszt utrzymania tak wysoki, że migracja jest rozsądną decyzją. Czasem naprawdę trzeba wymienić całość.
Ale warto wiedzieć dlaczego. Co jest przeszkodą, jakie mamy dowody, jakie rozwiązania porównaliśmy i co firma otrzyma w zamian za ryzyko zmiany.
Jeżeli mamy kilka możliwych wyjaśnień problemu, a każde prowadzi do innej inwestycji, najważniejszą decyzją nie jest jeszcze wybór dostawcy. Najpierw trzeba ustalić, które wyjaśnienie wytrzymuje konfrontację z faktami. Może się okazać, że największą wartością pierwszego etapu projektu jest właśnie to, czego postanowiliśmy nie robić.
Bo jeśli pomylimy objaw z przyczyną, możemy zamówić bardzo kosztowną odpowiedź na niewłaściwe pytanie.
Źródła i uwagi techniczne
- Microsoft Learn, Object Specifications and Limitations — Business Central — techniczne ograniczenia obiektów i danych; nie stanowi diagnozy opisanego przypadku.
- Microsoft Learn, Maintain Indexes Optimally to Improve Performance and Reduce Resource Utilization — nie wszystkie zadania utrzymania indeksów muszą działać cyklicznie; ich potrzebę warto mierzyć.
- Microsoft Learn, Update Statistics — SQL Server — część czynności optymalizacyjnych SQL Server wykonuje automatycznie.
