Jak uniknąć nadmiernego uzależnienia od dostawcy oprogramowania: co uzgodnić

Uzależnienia od dostawcy oprogramowania nie widać, dopóki współpraca działa dobrze. Odkrywa się je w dniu, w którym trzeba coś zmienić — dostawcę, abonament albo osobę prowadzącą projekt — a nikt w firmie nie potrafi powiedzieć, gdzie są dane, na kogo zarejestrowane są usługi i co jest potrzebne, aby uruchomić je gdzie indziej. To nie kwestia zaufania: to kwestia inwentaryzacji, którą robi się już dziś, z dostawcą, któremu Państwo ufają.

Celem nie jest możliwość zmiany dostawcy od jutra. Celem jest to, aby pozostanie przy nim było wyborem, a nie jedyną możliwą drogą.

Inwentaryzacja: co istnieje i na czyje nazwisko

Pierwszym ćwiczeniem jest sporządzenie listy. Robi się ją raz, aktualizuje przy każdej zmianie, i służy do wykrycia miejsc, w których firma nie jest właścicielem tego, czego używa na co dzień.

Dane: samo ich wyeksportowanie nie wystarczy, potrzebne są relacje

Eksport klientów do arkusza kalkulacyjnego to lista nazwisk, a nie Państwa archiwum. Archiwum tworzą powiązania, a to właśnie powiązania gubi się jako pierwsze.

• Identyfikatory: jeśli klienci mają wewnętrzny kod, musi się on pojawiać także w eksportach zamówień, w przeciwnym razie ponowne ich powiązanie to praca ręczna.
• Historia: poprzednie stany, daty zmian, kto co zrobił. Często eksportowany jest tylko ostatni stan.
• Załączniki: umowy, zdjęcia, podpisane dokumenty. To pliki, a nie wiersze, i trzeba je eksportować z informacją, z czym były powiązane.
• Pola obliczane: sumy, terminy, punktacje. Jeśli nie zostaną zachowane, trzeba je odtworzyć, znając formułę, która musi więc być gdzieś spisana.
• Format: otwarty i czytelny bez programu, który go wygenerował. Archiwum wyeksportowane w formacie zastrzeżonym nadal zależy od tego samego narzędzia.

Wsparcie, utrzymanie i rozwój to trzy różne rzeczy

Trzeba je nazywać trzema różnymi nazwami, w przeciwnym razie w chwili potrzeby okazuje się, że to, co było potrzebne, nie było objęte abonamentem.

• Wsparcie: usunięcie usterki. Trzeba określić, czym jest usterka, jak się ją zgłasza i w jakim czasie zostaje podjęta.
• Utrzymanie: aktualizacje komponentów, bezpieczeństwo, dostosowania w razie zmian w otoczeniu systemu. Trzeba określić, kto decyduje o jego wykonaniu i czy jest ono wliczone w cenę.
• Rozwój: zmiany i nowe funkcje. Trzeba określić, jak są wyceniane i kto je zatwierdza.
• Przekazanie projektu: co zostaje przekazane, w jakim czasie i w jakiej formie, jeśli współpraca się zakończy. To punkt, którego niemal nikt nie zapisuje na początku, czyli wtedy, gdy łatwo o nim rozmawiać bez napięcia.

Test: prawdziwy eksport, przynajmniej raz

Lista nigdy nieprzetestowanych gwarancji jest mało warta. Weryfikacja kosztuje pół dnia i należy ją przeprowadzić, gdy wszystko działa dobrze, a nie wtedy, gdy staje się potrzebna.

1. Warto poprosić o pełny eksport danych, a nie próbkę wybraną przez kogoś innego.
2. Otworzyć go na komputerze firmowym, bez użycia narzędzi użyczonych przez dostawcę.
3. Wziąć trzy rzeczywiste i złożone przypadki — klienta z wieloma zamówieniami, sprawę z załącznikami, historię z długim przebiegiem — i odtworzyć je na podstawie plików. Jeśli się nie uda, eksport jest niekompletny.
4. Spróbować przywrócić kopię zapasową w osobnym środowisku. Kopia, której nigdy nie przywrócono, to kopia, o której nic się nie wie.
5. Spisać, czego brakuje i czego nie da się odtworzyć: ta lista jest prawdziwym wynikiem testu.

Przykładowy pakiet przekazania

Ma charakter poglądowy, do dostosowania do wielkości projektu. To lista tego, co powinno istnieć w firmie i pozostawać aktualne, niezależnie od tego, kto to utrzymuje.

• Lista dostępów, z podanym dla każdego firmowym właścicielem konta.
• Adres archiwum kodu, gdy jego przekazanie przewiduje umowa, wraz z instrukcją uruchomienia.
• Opis architektury na kilku stronach: jakie elementy istnieją i jak się ze sobą komunikują.
• Lista komponentów zewnętrznych i odpowiadających im warunków użytkowania.
• Procedura kopii zapasowych: gdzie się znajdują, jak często są wykonywane, jak długo są przechowywane, jak się je przywraca.
• Próbka eksportu danych wraz z wyjaśnieniem pól.
• Kontakty operacyjne oraz sposób postępowania w przypadku awarii.

Czego ten przewodnik nie obejmuje

Tutaj mowa jest o ciągłości technicznej: dostępach, danych, dokumentacji, testach. Własność kodu, prawa użytkowania, klauzule umowne i warunki odstąpienia od umowy znajdują się na innej płaszczyźnie i należy je zweryfikować w umowie oraz z prawnikiem, ponieważ to, co tu opisano jako dostępne, zależy przede wszystkim od tego, co zostało zapisane w umowie. Wybór między standardowym systemem a oprogramowaniem na zamówienie oraz kontrole uprawnień i kopii zapasowych mają swoje własne przewodniki.