Bieżąca obsługa i wsparcie techniczne działających systemów

Bieżąca obsługa projektów

Bieżąca obsługa dotyczy działających sklepów internetowych, platform sprzedażowych, dedykowanych systemów webowych i aplikacji, które są już używane przez klientów, pracowników lub inne grupy użytkowników. W ramach bieżącej obsługi zajmujemy się problemami z działaniem systemu, drobnymi zmianami, aktualizacjami, poprawkami, konfiguracją oraz bieżącym wsparciem programistycznym i technicznym.

Najczęściej są to zadania dotyczące istniejącego rozwiązania i jego aktualnego działania. Może to być aktualizacja modułu lub wtyczki, poprawienie błędu, zmiana konfiguracji, modyfikacja niewielkiego elementu strony, zmiana tekstu, problem z istniejącą funkcją, integracją albo działaniem serwera. Bieżąca obsługa nie oznacza więc wyłącznie reagowania na awarie. Obejmuje również sytuacje, w których firma chce szybko zmienić konkretny element działającego systemu.

Ma to znaczenie szczególnie w przypadku sklepów i systemów, które są częścią codziennej pracy firmy. Nawet niewielka zmiana może być potrzebna ze względu na sprzedaż, obsługę klientów, wymagania prawne, działanie integracji albo pracę zespołu. Możliwość zlecenia takiej zmiany bez rozpoczynania osobnego projektu pozwala utrzymywać system zgodnie z bieżącymi potrzebami firmy.

Klient nie musi wiedzieć, co technicznie jest przyczyną problemu. Może napisać, że nie może wykonać określonej czynności, pojawia się konkretny komunikat albo dana funkcja przestała działać. Weryfikujemy wtedy, co dzieje się po stronie technicznej. Możemy odtworzyć ścieżkę użytkownika, sprawdzić konfigurację, logi, integracje, działanie modułów lub inne elementy systemu, a następnie ustalić przyczynę i sposób rozwiązania problemu.

W przypadku problemów z istniejącą funkcją staramy się najpierw ustalić przyczynę, a nie tylko usunąć widoczny objaw. Problem może wynikać na przykład z aktualizacji, konfiguracji, modułu, integracji, zmian po stronie zewnętrznego dostawcy albo infrastruktury. Ustalenie źródła problemu pozwala uniknąć sytuacji, w której chwilowo usunięty objaw wraca po kolejnej aktualizacji lub wpływa na inne elementy systemu.

Jeżeli rozwiązanie wymaga zaangażowania innej firmy, np. dostawcy hostingu, operatora płatności, systemu ERP, firmy kurierskiej lub producenta modułu, możemy skontaktować się z jej supportem i pomóc w przeprowadzeniu całego procesu. Dzięki temu klient nie musi samodzielnie ustalać, która firma odpowiada za konkretny problem i przekazywać informacji technicznych pomiędzy kilkoma dostawcami.

Bieżąca obsługa obejmuje przede wszystkim mniejsze zadania, które wpływają na aktualny stan systemu. Nie ma jednak sztywnej granicy pomiędzy bieżącą obsługą a rozwojem projektu. Niewielka aktualizacja może zostać wykonana jako zadanie bieżące, natomiast większa aktualizacja platformy, PHP lub kluczowego komponentu może wymagać szerszych prac i zostać potraktowana jako rozwój projektu.

Podobnie zmiana tekstu może być prostym zadaniem bieżącym, podczas gdy stworzenie nowej sekcji, funkcji lub integracji będzie już osobnym zadaniem rozwojowym. Jeżeli zakres prac wykracza poza prostą zmianę lub wymaga szerszej analizy, informujemy o tym klienta i ustalamy dalszy sposób realizacji.

1. Kontakt i zgłaszanie tematów

Formy kontaktu z nami są bezpośrednie. Klient może do nas zadzwonić, napisać wiadomość e-mail albo zgłosić temat bezpośrednio w Sopchy Panel.

Jeżeli temat techniczny zostanie zgłoszony w panelu, trafia bezpośrednio do osoby zajmującej się danym obszarem. Klient nie musi czekać na przekazanie zgłoszenia przez customer service. Jest to szczególnie istotne w przypadku problemów technicznych, gdy liczy się szybkie rozpoczęcie weryfikacji.

Klient może wybrać sposób kontaktu odpowiedni do sytuacji. Jeżeli temat wymaga szybkiego omówienia, może zadzwonić. Jeżeli potrzebne jest przekazanie szczegółów, zrzutów ekranu lub informacji dotyczących konkretnego zadania, może skorzystać z e-maila albo Sopchy Panel.

Zgłoszenie przez panel ma dodatkową funkcję: temat pozostaje zapisany w historii projektu razem z komentarzami, statusem, osobą odpowiedzialną i czasem poświęconym na jego realizację. Dzięki temu informacje nie są uzależnione wyłącznie od wcześniejszej rozmowy telefonicznej lub korespondencji e-mail.

2. Priorytety i czas reakcji

Priorytety ustalamy wspólnie z klientem. Nie sortujemy zgłoszeń wyłącznie według tego, czy wystąpił błąd krytyczny, jak duża jest zmiana, ile czasu zajmie jej wykonanie albo czy klient jest nowy, czy współpracuje z nami od kilku lat.

Przy ustalaniu kolejności prac uwzględniamy znaczenie danego zadania dla firmy. Temat, który technicznie jest niewielką zmianą, może mieć dla klienta duże znaczenie biznesowe.

Przykładowo brak awarii sklepu nie oznacza, że temat jest nieważny. Jeżeli klient potrzebuje zmienić informację w stopce ze względu na wymagania prawne, może być to dla niego pilna zmiana, mimo że sklep działa prawidłowo. W takiej sytuacji traktujemy ją jako pilne zadanie.

Czas reakcji na bieżące sprawy może wynosić nawet mniej niż 5 minut. W godzinach pracy, jeżeli pojawia się pilny temat, staramy się znaleźć osobę, która może zająć się nim od razu. Dotyczy to również większych problemów, jeżeli ich szybkie podjęcie jest istotne dla działania projektu.

Nie oznacza to, że każde zgłoszenie ma gwarantowany czas realizacji poniżej 5 minut. Formalne czasy reakcji i zakres SLA ustalamy indywidualnie z klientem. Szybkie rozpoczęcie weryfikacji nie jest również równoznaczne z natychmiastowym usunięciem problemu. Przyczyna awarii może wymagać analizy kodu, logów, konfiguracji, infrastruktury lub działania zewnętrznego systemu.

W przypadku standardowej współpracy nie odkładamy bieżących tematów na kolejny miesiąc tylko dlatego, że pojawiły się inne zadania. W godzinach pracy klient może się z nami skontaktować, a my informujemy, kiedy zajmiemy się danym tematem. Jeżeli coś jest pilne, staramy się zająć tym możliwie szybko.

Jeżeli rozwiązanie problemu wymaga dłuższej analizy, informujemy klienta o tym, co zostało sprawdzone i kiedy przekażemy kolejną informację. Pozwala to klientowi wiedzieć, że temat został przyjęty i jest prowadzony, nawet jeśli jego rozwiązanie nie jest możliwe w ciągu kilku minut.

3. Monitoring dostępności

W ramach bieżącej obsługi możemy również monitorować dostępność strony lub sklepu. Monitoring może obejmować cały serwis albo wybrane, kluczowe podstrony, na przykład karty produktów.

System monitorujący sprawdza, czy strona lub wskazany element odpowiada prawidłowo. Jeżeli pojawi się problem z dostępnością po stronie serwera, automatycznie wysyłane jest powiadomienie do Sopchy oraz klienta.

Monitoring może wykonywać kolejne próby sprawdzenia dostępności i wysyłać następne powiadomienia, jeżeli problem nadal występuje. Częstotliwość sprawdzania oraz warunki wysyłania alertów ustalamy z klientem.

Monitoring jest szczególnie istotny dla sklepów i systemów, których niedostępność może bezpośrednio wpływać na sprzedaż lub pracę firmy. Pozwala rozpocząć sprawdzanie problemu zanim klient albo użytkownik sam zgłosi, że strona nie działa.

Jeżeli wystąpi krótka przerwa w działaniu serwera i strona wróci do działania po kilku sekundach lub minutach, problem może zakończyć się bez konieczności naszej ingerencji. Jeżeli niedostępność się utrzymuje, sprawdzamy jej przyczynę. W przypadku długotrwałej współpracy możemy również reagować na takie sytuacje zgodnie z ustalonym zakresem obsługi.

Przykładowo, jeżeli monitoring wykryje błąd HTTP 500, możemy rozpocząć od sprawdzenia logów i elementów, które mogły spowodować problem. Jeżeli przyczyną okaże się wadliwy moduł, w określonych sytuacjach możemy tymczasowo wyłączyć problematyczny element, aby przywrócić działanie systemu, a następnie przeprowadzić właściwą poprawkę.

4. Aktualizacje, optymalizacja i integracje

Bieżąca obsługa może obejmować aktualizacje modułów, wtyczek oraz innych elementów systemu. Przed wykonaniem większej aktualizacji sprawdzamy jej wpływ na działanie projektu.

Jeżeli aktualizacja jednego elementu wymaga zmiany PHP, platformy lub innych zależności, analizujemy cały zakres prac zamiast wykonywać zmianę bez sprawdzenia jej konsekwencji.

Przykładowo aktualizacja modułu może wymagać nowszej wersji PHP, podczas gdy obecna wersja projektu jest zależna od starszego środowiska. W takiej sytuacji samo zaktualizowanie modułu może nie być możliwe bez zmian w innych elementach systemu.

Sprawdzamy wtedy zależności i przedstawiamy klientowi możliwe rozwiązania. Jeżeli dalsze dokładanie zmian do starego projektu jest nieopłacalne, możemy również zarekomendować przebudowę części systemu albo stworzenie nowego projektu.

Takie podejście pozwala uniknąć sytuacji, w której pojedyncza aktualizacja powoduje problemy z innymi funkcjami sklepu lub tworzy kolejne zależności techniczne.

Bieżąca obsługa może także obejmować optymalizację działania istniejącego rozwiązania. Jeżeli sklep lub system działa wolno, analizujemy przyczynę problemu. W zależności od sytuacji możemy optymalizować kod, usuwać niepotrzebne moduły, zmieniać konfigurację, poprawiać sposób działania integracji albo rekomendować migrację na inną infrastrukturę.

Nie zakładamy z góry, że wolne działanie oznacza konieczność zmiany serwera. Najpierw sprawdzamy, co jest faktycznym źródłem problemu, ponieważ przyczyną może być kod, konfiguracja, baza danych, moduł, integracja albo infrastruktura.

W ramach obsługi możemy również analizować problemy związane z integracjami. Jeżeli przestaje działać wymiana danych pomiędzy sklepem a ERP, systemem płatności, firmą kurierską, BaseLinkerem lub innym systemem, sprawdzamy, na którym etapie pojawia się problem.

Jeżeli przyczyna znajduje się po stronie zewnętrznego dostawcy, możemy skontaktować się z jego supportem. Jeżeli problem znajduje się po stronie naszego rozwiązania, wykonujemy odpowiednią poprawkę. Takie rozdzielenie pozwala ustalić, za który element odpowiada Sopchy, a który znajduje się poza naszym systemem.

5. Bezpieczeństwo, serwer i zewnętrzni dostawcy

Bieżąca obsługa może również dotyczyć bezpieczeństwa działającego projektu. Możemy sprawdzić, czy w systemie nie pojawiły się podejrzane pliki lub moduły, przeanalizować próby nieautoryzowanego dostępu czy nietypowy ruch oraz w razie potrzeby wdrożyć dodatkowe zabezpieczenia, np. Cloudflare.

Są to działania podejmowane w ramach konkretnego problemu lub potrzeby projektu. Nie należy ich utożsamiać z pełnym audytem bezpieczeństwa. Jeżeli klient potrzebuje kompleksowej oceny bezpieczeństwa systemu, zakres takiej usługi powinien zostać ustalony osobno.

Sopchy może również pomóc w kwestiach związanych z serwerem i infrastrukturą, ale nie jest dostawcą hostingu. Za hosting i backupy odpowiada zazwyczaj dostawca infrastruktury.

W zależności od wybranej usługi hosting może zapewniać automatyczne kopie zapasowe, często wykonywane co najmniej raz dziennie. Jeżeli projekt wymaga dodatkowych kopii lub niestandardowego rozwiązania, ustalamy zakres odpowiedzialności i sposób realizacji indywidualnie.

Jeżeli konieczna jest zmiana konfiguracji serwera, migracja lub inna praca po stronie infrastruktury, współpracujemy z dostawcą hostingu. Możemy pomóc wybrać odpowiednią infrastrukturę, ocenić jej dopasowanie do projektu, przygotować wymagania techniczne, skonfigurować elementy znajdujące się w naszym zakresie oraz skontaktować się z supportem dostawcy.

Jeżeli hosting zapewnia określoną konfigurację lub migrację w ramach swojej usługi, korzystamy z tej możliwości zamiast wykonywać tę samą pracę ponownie. Dzięki temu zakres odpowiedzialności pomiędzy Sopchy a dostawcą infrastruktury pozostaje jasno określony.

W przypadku problemów z zewnętrznymi systemami kontaktujemy się również bezpośrednio z ich dostawcami. Może to dotyczyć operatorów płatności, systemów ERP, firm kurierskich, dostawców modułów, systemów marketingowych czy innych usług wykorzystywanych przez projekt.

Klient nie musi wtedy samodzielnie przekazywać informacji technicznych pomiędzy kilkoma firmami. Sopchy może pomóc ustalić, gdzie znajduje się problem, zebrać potrzebne informacje i skoordynować komunikację z dostawcą odpowiedzialnym za dany element.

6. Rozwój projektu i granica bieżącej obsługi

Bieżąca obsługa może prowadzić do większych prac rozwojowych. Jeżeli podczas rozwiązywania problemu okaże się, że obecne rozwiązanie jest przestarzałe, ma ograniczenia techniczne albo wymaga zmian w kilku powiązanych elementach, przedstawiamy klientowi możliwe warianty dalszego działania.

Nie realizujemy automatycznie każdej wskazanej przez klienta zmiany bez sprawdzenia jej konsekwencji. Jeżeli widzimy rozwiązanie, które będzie bezpieczniejsze, prostsze lub bardziej opłacalne, informujemy o tym i przedstawiamy rekomendację.

Przykładowo, jeżeli klient chce zaktualizować pojedynczy moduł, ale jego nowa wersja wymaga aktualizacji PHP i platformy, nie traktujemy tego jako prostego zadania polegającego na kliknięciu aktualizacji. Najpierw sprawdzamy zależności i określamy, jaki zakres prac jest rzeczywiście potrzebny.

Podobnie, jeżeli klient chce dodać nową funkcję, która wymaga zmian w procesie zakupowym, bazie danych i kilku integracjach, może zostać potraktowana jako osobny etap rozwoju projektu.

Takie rozróżnienie pozwala klientowi wiedzieć, czy zleca pojedynczą zmianę w działającym systemie, czy rozpoczyna większe prace rozwojowe wymagające osobnego zakresu i estymacji.

7. Dokumentowanie prac i przejrzystość współpracy

Wszystkie bieżące zadania są rejestrowane w Sopchy Panel. Klient może sprawdzić status zadania, osobę odpowiedzialną, czas poświęcony na realizację oraz komentarze dotyczące wykonanych prac. Może również odpowiadać bezpośrednio w panelu.

Dzięki temu historia zgłoszenia pozostaje przypisana do konkretnego projektu i można do niej wrócić również później. Jest to szczególnie istotne w przypadku projektów rozwijanych przez wiele miesięcy lub lat, gdy trzeba sprawdzić, dlaczego została wykonana określona zmiana albo co było przyczyną wcześniejszego problemu.

Przy regularnej współpracy prowadzimy również cykliczne spotkania statusowe, podczas których omawiamy wykonane prace, bieżące problemy oraz kolejne zadania.

W przypadku pojedynczych lub sporadycznych zgłoszeń nie ma potrzeby organizowania dodatkowych spotkań. Temat może zostać zgłoszony bezpośrednio i obsłużony w ramach bieżącej współpracy.

Klient powinien mieć możliwość sprawdzenia, czy temat został przyjęty, kto się nim zajmuje, jaki jest jego status i jakie prace zostały wykonane. Dlatego informacje dotyczące zadań są zapisywane w miejscu dostępnym dla klienta, zamiast pozostawać wyłącznie w wewnętrznej komunikacji zespołu.

8. Formy współpracy i rozliczenie

Bieżące prace realizujemy w modelu godzinowym. Klient może zlecać pojedyncze zadania wtedy, kiedy są potrzebne, albo korzystać z ustalonej puli godzin przeznaczonej na bieżące wsparcie.

Nie ma obowiązku wykupywania stałego abonamentu, jeżeli klient nie potrzebuje regularnie rezerwowanej liczby godzin. Zadania mogą być zlecane w miarę pojawiania się potrzeb.

Drugą możliwością jest abonament z określoną miesięczną pulą godzin dla klientów, którzy chcą mieć zarezerwowaną część dostępności zespołu.

Takie podejście pozwala dopasować sposób współpracy do rzeczywistego sposobu korzystania z systemu. Firma, która potrzebuje jedynie okazjonalnych aktualizacji i poprawek, nie musi utrzymywać stałej puli godzin. Firma, która regularnie potrzebuje wsparcia, może natomiast zarezerwować dostępność zespołu.

Czas pracy jest rejestrowany w Sopchy Panel. Klient może sprawdzić, ile czasu zostało poświęcone na konkretne zadanie oraz jakie prace zostały wykonane.

9. Odpowiedzialność za rozwiązanie

Sopchy prowadzi bieżącą obsługę projektów w oparciu o zakres odpowiedzialności ustalony z klientem. Jeżeli problem wynika z prac wykonanych przez Sopchy, poprawiamy własny błąd bez dodatkowego rozliczania klienta za jego usunięcie.

Jeżeli problem wynika z elementu znajdującego się poza naszym zakresem, np. działania zewnętrznego dostawcy, infrastruktury, operatora płatności albo zmiany po stronie zewnętrznego systemu, informujemy klienta o przyczynie i możliwym sposobie dalszego działania.

Przyjęcie odpowiedzialności za konkretny element systemu nie oznacza automatycznie odpowiedzialności za wszystkie zewnętrzne usługi, z których korzysta projekt. Dlatego przy problemach technicznych ustalamy, gdzie znajduje się przyczyna i który element wymaga działania.

Prace programistyczne realizujemy wewnętrznie. Sopchy nie outsourcuje developmentu. Zaangażowanie zewnętrznych firm może być potrzebne w przypadku systemów, usług lub infrastruktury znajdujących się poza naszym zakresem, np. hostingu, operatora płatności, systemu ERP czy innego zewnętrznego dostawcy.

Podsumowanie

Celem bieżącej obsługi jest utrzymanie działającego projektu i reagowanie na potrzeby, które pojawiają się po jego uruchomieniu. Klient może zgłosić problem z istniejącą funkcją, potrzebę wykonania niewielkiej zmiany, aktualizację, problem z integracją, serwerem lub innym elementem systemu.

Klient nie musi samodzielnie określać technicznego rozwiązania. Może opisać, co chce osiągnąć albo co przestało działać, a Sopchy sprawdzi przyczynę, określi sposób rozwiązania i wykona prace znajdujące się w naszym zakresie.

Bieżąca obsługa obejmuje zarówno drobne zmiany, jak i reagowanie na problemy techniczne, monitoring dostępności, aktualizacje, optymalizację, wsparcie przy integracjach i współpracę z zewnętrznymi dostawcami. Jeżeli zadanie wymaga większej przebudowy lub stanowi nową funkcjonalność, może zostać przekazane do procesu rozwoju projektu.

Dla firmy oznacza to możliwość utrzymywania i zmieniania działającego systemu bez konieczności rozpoczynania nowego projektu przy każdej potrzebie. Zakres prac może być dopasowywany do aktualnej sytuacji, a większe zmiany są oddzielane od prostych zadań, gdy wymagają dodatkowej analizy, planowania lub testów.

Bieżąca obsługa nie kończy się na samym wykonaniu zgłoszenia. Istotne jest również ustalenie przyczyny problemu, określenie odpowiedzialności, zapisanie wykonanych prac oraz przekazanie klientowi informacji o statusie i dalszych działaniach.