Oprogramowanie dla firm Poznań - współpraca z wykonawcą na miejscu

Oprogramowanie dla firm Poznań - kiedy liczy się lokalny wykonawca

Oprogramowanie dla firm Poznań powstaje zwykle dla zakładów produkcyjnych i magazynów, które mają fizyczny proces do opisania. Bliskość wykonawcy nie zmienia kodu programu. Zmienia natomiast sposób zbierania wymagań i uruchamiania systemu, bo część prac trzeba wykonać przy regale lub bramie, a część da się zrobić z dowolnego miejsca.

SoftwareStudio działa z Poznania i tworzy systemy logistyczne oraz biznesowe w technologiach C# oraz T-SQL na bazie Microsoft SQL Server. Ten artykuł omawia jeden aspekt: jak układa się współpraca z wykonawcą, który może pojawić się w zakładzie. Ofertę wykonawców w mieście porównuje osobny tekst o software house w Poznaniu, a rodzaje systemów pisanych na zamówienie opisuje materiał o aplikacjach na zamówienie.

Reguła: obecność na miejscu jest potrzebna tam, gdzie przedmiotem pracy jest proces fizyczny albo urządzenie, a nie tam, gdzie wystarcza plik i połączenie.

Podział ma znaczenie dla budżetu i harmonogramu. Kto zaplanuje wizyty tylko na warsztaty i uruchomienie, ten zaoszczędzi czas na dojazdach. Kto pominie je całkiem, ten odkryje na etapie odbioru, że opisany proces różni się od tego, który faktycznie działa na hali.

Spotkania analityczne przy stanowiskach pracy

Pierwsze spotkanie ma inny cel niż prezentacja oferty. Analityk wybiera jeden proces, na przykład przyjęcie dostawy albo wydanie narzędzia z narzędziowni, i idzie ścieżką dokumentu od początku do końca. Pyta osobę, która wykonuje zadanie, a nie jej przełożonego, ponieważ operator zna wyjątki, o których nie wspomina żadna instrukcja.

Z takiego przejścia powstaje opis stanu obecnego, czyli mapa kroków z przypisanymi rolami i dokumentami. Na mapie zaznacza się miejsca, w których ktoś przepisuje dane ręcznie. Pełny zakres analizy, wraz z kryteriami oceny środowiska IT, opisuje artykuł o analizie przedwdrożeniowej.

Po serii takich rozmów zespół wykonawcy ma komplet materiałów, z których da się napisać specyfikację. Materiały porządkuje się w czterech dokumentach, które klient akceptuje przed rozpoczęciem programowania.

• Opis procesu - kroki wraz z rolami i dokumentami, w kolejności wykonywania i z zaznaczonymi wyjątkami.
• Lista wymagań - funkcje oraz wymagania pozafunkcjonalne, na przykład liczba jednoczesnych użytkowników i godziny pracy zmian.
• Opis środowiska - serwer aplikacji z bazą SQL Server oraz sieć lokalna razem z urządzeniami końcowymi, które system ma obsłużyć.
• Zakres integracji - lista systemów zewnętrznych, kierunek wymiany danych i moment, w którym dane są przekazywane.

Reguła: wyjątek opisany w analizie kosztuje godzinę pracy programisty, a ten sam wyjątek odkryty po uruchomieniu kosztuje przestój na stanowisku.

Przykład warsztatu - wydanie narzędzia z narzędziowni

Wydanie narzędzia wydaje się prostą operacją, dopóki analityk nie stanie przy okienku. Pracownik prosi o wiertarkę, magazynier sprawdza, czy sprzęt jest sprawny i czy ma aktualną legalizację, a potem zapisuje, kto i na jak długo go wypożycza. Warsztat pokazuje, które z tych kroków są dziś wykonywane z pamięci, a które z kartki przypiętej do szafy.

Każdy taki krok staje się później polem lub regułą w systemie. Jeżeli magazynier nie ma zwyczaju sprawdzać legalizacji, program musi zrobić to za niego i zablokować wydanie. Jeżeli natomiast kilku pracowników dzieli jedno narzędzie, system potrzebuje osobnej reguły przekazania. Takich przypadków nie wymyśli się przy biurku.

Wdrożenie w zakładzie - instalacja i szkolenia

Środowisko - serwer aplikacji i baza danych

System magazynowy lub narzędziowy składa się z aplikacji, bazy Microsoft SQL Server i klientów: przeglądarki oraz terminali z systemem Android. Przed instalacją wykonawca sprawdza wersję bazy, uprawnienia konta usługi i przepustowość sieci między serwerem a halą. Środowisko testowe stawia się osobno, żeby aktualizacje nie zatrzymywały pracy produkcyjnej.

W magazynie osobnym punktem jest zasięg Wi-Fi. Pomiar wykonuje się chodząc z urządzeniem po alejkach, ponieważ regały metalowe i folia stretch tłumią sygnał w sposób, którego nie widać na planie budynku. Wynik pomiaru decyduje o liczbie punktów dostępowych i o tym, czy terminal musi buforować operacje przy krótkich przerwach w łączności.

Migracja danych i uzgodnienie stanów

Dane ze starego systemu lub z arkuszy trafiają do tabel przejściowych. Dopiero po sprawdzeniu przenosi się je do tabel docelowych. Przy migracji stanów magazynowych podstawową kontrolą jest porównanie ilości z obu źródeł. Poniższy przykład ma charakter poglądowy, a nazwy tabel są przykładowe.

SELECT COALESCE(o.ItemCode, n.ItemCode) AS ItemCode,
       ISNULL(o.Qty, 0) AS QtyOld,
       ISNULL(n.Qty, 0) AS QtyNew
FROM dbo.MigrationOldStock AS o
FULL OUTER JOIN dbo.WarehouseStock AS n
     ON n.ItemCode = o.ItemCode
WHERE ISNULL(o.Qty, 0) <> ISNULL(n.Qty, 0);

Zapytanie zwraca tylko pozycje, w których ilości się różnią lub które występują po jednej stronie. Pusty wynik jest warunkiem przejścia do kolejnego kroku. Ogólny przebieg migracji w projektach ERP opisuje artykuł o wdrożeniu systemu ERP, a przygotowanie zespołu magazynowego omawia tekst o przebiegu wdrożenia WMS.

Drukarki etykiet i konto usługi

Drukarki etykiet wymagają osobnej próby. Etykieta generowana z danych dokumentu trafia do drukarki w języku ZPL, więc wykonawca drukuje ją na miejscu, sprawdza czytelność kodu skanerem i dobiera rozmiar papieru oraz gęstość wydruku. Ta sama próba wykrywa terminale, które mają problem z odczytem kodu w słabym świetle.

Osobną czynnością jest konto usługi i uprawnienia do bazy. Aplikacja łączy się z SQL Server przez konto o ograniczonych prawach, a administrator klienta zna hasła, ale nie zna kodu aplikacji. Podział odpowiedzialności zapisuje się w protokole, żeby po wdrożeniu nie było wątpliwości, kto może zmienić konfigurację serwera.

Szkolenia na stanowiskach

Szkolenie prowadzone na własnym sprzęcie klienta pokazuje problemy, które sala szkoleniowa ukrywa: nieczytelny wyświetlacz w mroźni, zbyt krótki kabel skanera, brak miejsca na drukarkę. Operator ćwiczy na rzeczywistych dokumentach z bazy testowej, a nie na przykładach z prezentacji. Prowadzący zapisuje uwagi, które trafiają na listę poprawek przed startem.

Uruchomienie produkcyjne i wsparcie po uruchomieniu

Przełączenie na nowy system planuje się jak zamknięcie okresu rozliczeniowego. Starego systemu nie wolno już zasilać dokumentami, stany zostają zamrożone, a zespół wykonuje ostatnie porównanie z tabelą przejściową. Pierwsze dni pracy odbywają się z obecnością wykonawcy, który obserwuje stanowiska i poprawia błędy na bieżąco.

Po ustabilizowaniu pracy wsparcie przechodzi w tryb zdalny. Zgłoszenia klasyfikuje się według wpływu na proces: awaria zatrzymująca wydawanie towaru ma wyższy priorytet niż prośba o nowy raport. Czasy reakcji wynikają z umowy, dlatego przed podpisaniem trzeba je porównać z godzinami pracy zmian w zakładzie.

W pierwszych dniach mierzy się kilka prostych wskaźników: liczbę zgłoszeń dziennie, czas do pierwszej reakcji i liczbę zgłoszeń wracających po naprawie. Rosnąca liczba powtórzeń oznacza, że poprawka usuwa objaw, a nie przyczynę. Wtedy zespół wraca do analizy zamiast dopisywać kolejne łatki.

Reguła: kopia zapasowa bazy istnieje dopiero wtedy, gdy ktoś przywrócił ją na osobnym serwerze i sprawdził dane.

Do wsparcia należy też kontrola kopii. Pełną kopię z sumą kontrolną wykonuje się poleceniem BACKUP, a poprawność pliku sprawdza RESTORE VERIFYONLY. Szczegóły opisuje dokumentacja tworzenia i przywracania kopii SQL Server.

BACKUP DATABASE [ExampleDb]
  TO DISK = N'D:\Backup\ExampleDb_full.bak'
  WITH CHECKSUM, INIT;

RESTORE VERIFYONLY
  FROM DISK = N'D:\Backup\ExampleDb_full.bak'
  WITH CHECKSUM;

Sam VERIFYONLY nie zastępuje pełnego przywrócenia na serwerze testowym. Sprawdza strukturę pliku, ale nie dowodzi, że aplikacja poprawnie uruchomi się na odtworzonej bazie. Dlatego harmonogram wsparcia zawiera okresowe próby odtworzenia.

Aktualizacje w oknie serwisowym

Aktualizacje po starcie wykonuje się w oknie serwisowym uzgodnionym z kierownikami zmian. Najpierw wersja trafia na bazę testową, gdzie użytkownik odpowiedzialny za proces sprawdza zmienione scenariusze. Dopiero po jego akceptacji wykonawca kopiuje bazę produkcyjną i instaluje nową wersję. Jeżeli aktualizacja zawiedzie, powrót do poprzedniej wersji zajmuje czas przywrócenia kopii, dlatego okno musi go uwzględniać.

Systemy SoftwareStudio wdrażane na miejscu

Zakres wdrożeń zależy od procesu, który firma chce uporządkować. Studio WMS.net obsługuje magazyn, a jego zakres opisuje artykuł o systemie WMS. Studio VSS.net porządkuje awizacje i okna czasowe, Studio RMA.net prowadzi reklamacje i zwroty. Studio TCS.net służy do ewidencji narzędzi i ich wypożyczeń.

Firmy produkcyjne i budowlane korzystają z modelu dostępnego przez Internet, na przykład z Narzędziowni online, która daje wgląd w wypożyczenia z dowolnego miejsca. Organizację narzędziowni i moduły programu opisuje artykuł o programie do narzędziowni.

Poza produktami standardowymi SoftwareStudio pisze moduły uzupełniające ERP tam, gdzie gotowy system nie obejmuje procesu, na przykład logistyki specjalistycznej lub awizacji. Łączniki powstają dla konkretnej wersji ERP klienta. Zestawienia i wydruki tworzy się w narzędziach opisanych w artykule o SQL Report Builder. Działanie systemów można sprawdzić w demo online, zanim zapadnie decyzja o wizycie.

Lokalny wykonawca czy dostawca zdalny - kryteria wyboru

Lokalny wykonawca nie jest z definicji lepszy. Przewaga polega na krótszym czasie dojazdu i możliwości zorganizowania warsztatu na dzień roboczy, a nie na kilka dni. Dostawca zdalny może dysponować większym zespołem albo wiedzą branżową, której lokalny rynek nie oferuje. Wybór zależy od tego, ile pracy projektu odbywa się przy fizycznych stanowiskach.

Przed wyborem warto zadać wykonawcy cztery pytania, które rozstrzygają o jakości współpracy w praktyce.

• Zakres obecności - w których fazach projektu wykonawca pojawia się w zakładzie i ile osób przyjeżdża.
• Środowisko testowe - czy zmiany trafiają najpierw na bazę testową, a dopiero potem na produkcję.
• Zasady wsparcia - jakie są priorytety zgłoszeń i czasy reakcji zapisane w umowie.
• Własność kodu i danych - kto otrzymuje kod źródłowy i dokumentację oraz kopie bazy po zakończeniu współpracy.

W umowie trzeba też zapisać, czy koszt wizyt jest wliczony w cenę wdrożenia, czy rozliczany osobno. Rozliczenie ryczałtowe upraszcza budżet, ale wymaga jasno opisanego zakresu. Rozliczenie według czasu pracy sprawdza się przy projektach, których zakres zmienia się w trakcie, na przykład gdy po warsztatach dochodzą kolejne procesy do objęcia systemem.

Firmy szukające partnera do stałej opieki nad infrastrukturą znajdą uzupełnienie w tekście o outsourcingu IT w Poznaniu. Informacje o produktach i usługach producenta zbiera portal SoftwareHouse Poznań.