Firma informatyczna Poznań - jak sprawdzić dostawcę przed umową

Wybór firmy informatycznej rozstrzyga się zwykle przed pierwszą linijką kodu, kiedy zamawiający porównuje oferty i nie ma jeszcze czego przetestować. Strona opisuje, jak sprawdzić firmę informatyczną z Poznania na podstawie dwóch rzeczy: tego, co dostawca potrafi pokazać (referencje, demonstracja), i tego, co zapewnia umowa (dostęp do kodu oraz do danych). Nie zawiera rankingu firm ani oceny konkretnych dostawców.

Firma informatyczna Poznań a zakres usług, który trzeba nazwać

Określenie „firma informatyczna” obejmuje dwa różne modele pracy. Pierwszy obejmuje wytwarzanie oprogramowania, od analizy i projektu po testy i wdrożenie. Drugi to utrzymanie środowiska, czyli codzienna opieka nad serwerami oraz stacjami roboczymi. Dostawca, który dobrze robi jedno, nie musi radzić sobie z drugim. Zapytanie ofertowe zaczynające się od słów „potrzebujemy firmy IT” przyciąga oba typy naraz, więc otrzymane oferty są ze sobą nieporównywalne.

Pierwsze pytanie do samego siebie brzmi więc: co ma być wynikiem współpracy. Gotowa aplikacja z protokołem odbioru? Stała opieka z gwarantowanym czasem reakcji? Dostęp do zespołu programistów na godziny? Każda odpowiedź prowadzi do innej umowy i do innych kryteriów oceny. Punktem odniesienia dla pierwszego modelu jest opis tego, jak działa software house w Poznaniu, a dla drugiego strona o outsourcingu informatycznym jako stałej opiece nad infrastrukturą.

SoftwareStudio, firma z Poznania stojąca za serwisem SoftwarePedia, pracuje głównie w pierwszym modelu. Projektuje i wdraża oprogramowanie na zamówienie, rozwija własne systemy z rodziny Studio .net (między innymi WMS.net i VSS.net) oraz integruje je z systemami klienta. Zgodnie z opisem usług prowadzi też wsparcie techniczne i utrzymanie systemów, zakres takiej opieki opisuje strona o obsłudze informatycznej w Poznaniu.

Reguła: oferty porównuje się dopiero po sprowadzeniu ich do tego samego zakresu, bo cena za dwie różne rzeczy nic nie mówi o dostawcy.

Referencje i portfolio - co da się zweryfikować

Referencja ma wartość, jeśli dotyczy projektu porównywalnego z zamawianym. Logo klienta na stronie dostawcy potwierdza tylko, że jakaś współpraca się odbyła, a nie mówi nic o zakresie współpracy, o terminach ani o tym, co stało się po odbiorze. Rozmowa z osobą, która codziennie pracuje na systemie, daje więcej niż dokument z podpisem dyrektora.

• Zakres - referencja dotyczy projektu podobnej wielkości i z podobnymi integracjami do zamawianych.
• Stan produkcyjny - system działa u klienta na co dzień, a nie jest prototypem sprzed kilku lat.
• Rozmówca - kontakt to użytkownik lub administrator systemu, a nie wyłącznie osoba, która podpisała umowę.
• Zmiany po odbiorze - klient potwierdza, kto realizował poprawki i w jakim czasie.

Pytania do referencji są konkretne. Czy zakres z oferty został dostarczony w całości? Jak dostawca reagował na zmiany wymagań w trakcie prac? Ile trwało usunięcie ostatniej poważnej usterki produkcyjnej? Co zmieniło się w zespole dostawcy od czasu wdrożenia i czy ktoś nadal zna ten system? Odpowiedzi „nie wiem” też są informacją. Ogólne zasady oceny stażu dostawcy zebrano na stronie o doświadczeniu dostawcy oprogramowania na rynku IT.

Drugim źródłem wiedzy jest demonstracja na działającym środowisku, a nie na slajdach. SoftwareStudio udostępnia demo online systemów SoftwareStudio, w którym można sprawdzić, jak wygląda gotowy produkt bez rejestracji. Przy aplikacjach pisanych na zamówienie odpowiednikiem jest wersja pilotażowa jednego procesu, uruchomiona na danych testowych zamawiającego.

Umowa o usługi IT - zapisy do sprawdzenia

Umowa z firmą informatyczną ma dwie funkcje: opisuje, co jest dostarczane, i wskazuje, co dzieje się wtedy, gdy coś zawodzi. Pierwsza funkcja bywa dopracowana, druga często zostaje ogólnikiem. Poniższe zestawienie wymienia zapisy, które warto przeczytać osobno, a nie w całości jako „standardowe warunki”.

Reguła: czas reakcji i czas rozwiązania to dwie osobne liczby, a umowa powinna podawać obie.

Zapisy o prawach autorskich i danych osobowych warto przejrzeć z prawnikiem, bo ta strona nie jest poradą prawną. Z perspektywy inżynierskiej ważne są dwie kwestie. Zakres przeniesienia praw musi być opisany w umowie, a nie domniemany, oraz dostawca pracujący na danych produkcyjnych musi mieć do tego tytuł prawny, którym jest zwykle umowa powierzenia przetwarzania danych osobowych.

Dostęp do kodu źródłowego i repozytorium

Kod źródłowy może trafić do zamawiającego na trzy sposoby. Przy przeniesieniu praw autorskich dostaje się go razem z odbiorem. Przy licencji kod zostaje u dostawcy, a zamawiający korzysta z gotowej aplikacji. Przy produkcie własnym dostawcy sam kod nie jest przedmiotem umowy, natomiast dane i sposób ich wyjęcia z systemu jak najbardziej są. Żaden model nie jest z założenia lepszy, ale każdy powinien być nazwany w umowie.

Jeśli kod jest przekazywany, sprawdza się go w praktyce, a nie na podstawie oświadczenia. Repozytorium ma historię zmian z czytelnymi opisami, tagi oznaczają wersje wdrożone na produkcji, a z przekazanego kodu da się zbudować aplikację na czystej maszynie według krótkiej instrukcji. Test zajmuje kilka godzin i pokazuje więcej niż dokumentacja.

git clone https://repozytorium.example/klient/aplikacja.git
cd aplikacja
git log --oneline -5
git tag --list

Cztery polecenia z przykładu pobierają repozytorium, pokazują pięć ostatnich zmian i listę oznaczonych wersji. Brak tagów oznacza, że nikt nie potrafi wskazać, jaki dokładnie kod działa na produkcji. Sposób pracy zespołu z gałęziami Git i przeglądami kodu opisuje strona o firmie programistycznej w Poznaniu.

Dane i kopie zapasowe - dowód działania zamiast deklaracji

Dostawca, który utrzymuje bazę danych, powinien umieć pokazać dwie rzeczy: kiedy powstała ostatnia kopia i czy da się z niej odtworzyć dane. Deklaracja „robimy codzienne backupy” nie rozstrzyga żadnej z nich. Dwa parametry, które warto uzgodnić na piśmie, to RPO, czyli największa akceptowalna utrata danych liczona w czasie, oraz RTO, czyli czas, w którym system ma wrócić do pracy po awarii.

W SQL Server historię kopii pełnych można odczytać z tabeli systemowej. Zapytanie z przykładu zwraca dla każdej bazy datę ostatniej kopii pełnej, a polecenie poniżej sprawdza, czy plik kopii jest kompletny i czytelny.

SELECT database_name,
       MAX(backup_finish_date) AS ostatnia_pelna_kopia
FROM msdb.dbo.backupset
WHERE type = 'D'
GROUP BY database_name;

RESTORE VERIFYONLY FROM DISK = N'D:\Kopie\aplikacja_full.bak';

Reguła: polecenie RESTORE VERIFYONLY potwierdza kompletność zestawu kopii, ale nie sprawdza struktury danych w środku, więc dopiero odtworzenie kopii w środowisku testowym dowodzi, że dane da się odzyskać.

Składnię i ograniczenia opisuje dokumentacja Microsoft Learn dla RESTORE VERIFYONLY. Zamawiający może poprosić o protokół z takiego odtworzenia raz w roku i wpisać go do umowy jako element usługi.

Osobną kwestią jest wyjście z umowy. Dane w otwartym formacie (kopia bazy albo eksport tabel) oraz opis schematu pozwalają przenieść system do innego wykonawcy. Interfejsy integracyjne, na przykład wymiana z ERP, powinny mieć opis kontraktu i przykładowe komunikaty. Mechanizmy takiej wymiany omawia strona o integracji WMS z ERP przez REST i kolejki.

Uprawnienia kont i bezpieczeństwo dostępu

Firma informatyczna, która utrzymuje system, ma do niego dostęp administracyjny, więc jej higiena kont jest częścią bezpieczeństwa zamawiającego. Praktyka sprowadza się do dwóch reguł: konto jest imienne, a uprawnienia wynikają z zakresu pracy. Do tego dochodzi obowiązek wygaszenia konta po odejściu pracownika dostawcy, zapisany z terminem. Konta wspólne typu „admin” uniemożliwiają ustalenie, kto wykonał daną zmianę.

Przegląd uprawnień w bazie można wykonać jednym zapytaniem. Poniższy przykład wypisuje konta należące do roli db_owner, czyli mające pełne prawa w bazie, którą zapytanie sprawdza. Każde z nich powinno mieć uzasadnienie w zakresie usługi, a lista powinna być krótka.

SELECT r.name AS rola, m.name AS konto
FROM sys.database_role_members AS rm
JOIN sys.database_principals AS r ON r.principal_id = rm.role_principal_id
JOIN sys.database_principals AS m ON m.principal_id = rm.member_principal_id
WHERE r.name = 'db_owner';

Osobnym tematem są dane testowe. Środowisko testowe zbudowane z kopii produkcji zawiera dane osobowe, więc dostęp do niego podlega tym samym zasadom co dostęp do produkcji, albo dane przed kopiowaniem są anonimizowane. Zamawiający pyta o to na etapie oferty, bo po wdrożeniu zmiana procedury bywa kosztowna. Podobne pytania dotyczą sposobu przekazywania haseł i kluczy do usług zewnętrznych: przez menedżer haseł, a nie przez komunikator czy wiadomość e-mail.

Ocena techniczna oferty - pytania do zespołu

Ocenę techniczną da się przeprowadzić bez umiejętności programowania, jeśli pytania dotyczą procesu, a nie języka. SoftwareStudio pracuje w stosie opartym na C# i SQL Server, z T-SQL w warstwie danych, a po stronie przeglądarki na JavaScript z biblioteką jQuery. Aplikacje webowe działają bez instalacji na stanowisku. Podobną listę zamawiający powinien otrzymać od każdego dostawcy, wraz z uzasadnieniem, dlaczego dany stos pasuje do zadania. Podstawowe różnice między aplikacją przeglądarkową a instalowaną opisuje strona o aplikacji webowej.

• Środowiska - czy istnieje osobne środowisko testowe z kopią danych, na którym zamawiający akceptuje zmiany przed produkcją.
• Przeglądy - czy każdą zmianę czyta druga osoba, zanim trafi do wersji wdrażanej.
• Wersjonowanie - czy wersja działająca u klienta ma znacznik w repozytorium i numer w aplikacji.
• Zastępowalność - ilu członków zespołu zna dany moduł i co się stanie, gdy jeden z nich odejdzie.

Ostatnie pytanie jest szczególnie istotne przy małych zespołach, bo wiedza o systemie skupiona u jednej osoby jest ryzykiem operacyjnym. Dobra odpowiedź nie sprowadza się do liczby, tylko opisuje sposób przekazywania wiedzy: dokumentację oraz wspólną pracę nad zmianami. Przy zamówieniach pisanych od zera porządek etapów opisuje strona o etapach projektu informatycznego w modelu outsourcingu, a ogólne podejście do dedykowanych rozwiązań strona o oprogramowaniu na zamówienie.

Lokalizacja dostawcy a praca zdalna

Siedziba dostawcy w Poznaniu ułatwia spotkania w trakcie analizy oraz wizyty na miejscu podczas szkoleń. Większość zgłoszeń, w tym diagnoza błędów aplikacji i praca na bazie danych, da się jednak obsłużyć zdalnie. SoftwareStudio deklaruje, że realizuje projekty dla klientów z całej Polski, świadcząc wsparcie techniczne zdalnie i na miejscu, gdy wymaga tego charakter prac. Lokalizacja ma więc największe znaczenie tam, gdzie do systemu podłączony jest sprzęt, na przykład skanery i terminale.

W umowie warto zapisać, w jakim czasie dostawca stawia się na miejscu, kto ponosi koszt dojazdu i jakie prace wymagają obecności technika. Przykład wdrożeń z urządzeniami na hali opisuje strona o firmie informatycznej dla przemysłu i magazynów, czyli integracjach z terminalami i drukarkami. Wymagania stawiane dostawcom obsługującym logistykę omawia z kolei strona o firmach informatycznych z Poznania dla logistyki.

Sprawdzenie dostawcy kończy się propozycją niewielkiego projektu próbnego. Jeden proces, jedno środowisko testowe i jasne kryterium odbioru pozwalają zobaczyć, jak firma pracuje z dokumentacją, jak reaguje na uwagi i czy dotrzymuje terminów, zanim zostanie podpisana umowa na pełny zakres. Pełny zakres usług programistycznych i wdrożeniowych SoftwareStudio opisano na stronie usług SoftwareStudio.