27.02.2020

Autor: marketing@mwtsolutions.eu

Kategorie: Aktualności, Artykuł

Każdego dnia otrzymujemy zgłoszenia dotyczące wspieranych przez nas aplikacji. Ich zakres jest bardzo szeroki – od pytań typu „how to”, przez propozycje nowych funkcjonalności, po zgłaszanie błędów, które należy wyeliminować. W celu zwiększenia satysfakcji z usługi, większością zgłoszeń klienta zajmuje się jedna osoba. Pozwala to nie tylko utrzymać dobry kontakt między zgłaszającym a supportem, ale również pozwala na łatwiejsze rozwiązywanie pojawiających się problemów, dzięki dobrej znajomości specyfiki danego środowiska. Chcemy podzielić się z Wami spostrzeżeniami odnośnie pracy w supporcie, robiąc to z lekkim przymrużeniem oka, a przy okazji „przemycając” wiedzę która przyda się w codziennym korzystaniu z naszych aplikacji. Zaczynajmy!

Konia z rzędem temu, kto myśli, że poznał już aplikacje na wylot i nic nie może go zaskoczyć. Nasza praca opiera się bardziej na zasadzie „nic dwa razy się nie zdarza”, ponieważ nawet ten sam błąd powtarzający się w trzech różnych środowiskach często oznacza coś zupełnie innego, co w praktyce prowadzi do zupełnie innych metod wyeliminowania go. Jednym z najczęstszych zgłoszeń jest problem z aktualizacją aplikacji. Dlaczego tak się dzieje? Powodów jest wiele. O ile nie ma problemów z podnoszeniem wersji, w momencie kiedy aplikacja nie zawiera dużej ilości danych, o tyle przy bardzo intensywnym użytkowaniu aplikacji pojawiają się pewne czynniki ryzyka.

Aktualizacja aplikacji nie obejmuje tylko samej aplikacji (wprowadzenie poprawek, nowych funkcjonalności, zmian w interfejsie), ale także aktualizacji bazy danych. Czasami dane wprowadzone przez użytkowników (np. zgłaszających) zawierają specyficzne treści, z którymi aplikacja podczas aktualizacji nie może sobie poradzić. W tego typu sytuacjach aktualizacja jest przerywana i tutaj pojawia się problem… bądź też nie ? w zależności od tego, czy osoba zajmująca się aktualizacją postępuje według naszych zaleceń.

Zgodnie z zaleceniem producenta, wszelkich poważnych zmian należy dokonywać najpierw w środowisku testowym tworząc wcześniej backup aplikacji, tak aby w razie problemów móc wrócić do stanu początkowego. Licencja przyznana klientowi może być nie tylko wykorzystana w środowisku produkcyjnym, ale również i testowym – w niektórych sytuacjach jest to wręcz wymagane. Wyobraźmy sobie, że mamy firmę liczącą kilkuset pracowników i w czasie pracy odcinamy im dostęp do aplikacji bez wcześniejszego informowania ich o tym. Ktoś kończył pisać długą wiadomość w określonym szablonie i właśnie naciskał przycisk „Dodaj zgłoszenie” gdy pojawił się komunikat: „Braku dostępu do aplikacji”.

Posiadanie środowiska testowego (co wcale nie jest regułą jak wynika z naszej autopsji) ma też inne zalety. Czasami przedstawiamy rozwiązania wymagające bezpośredniego wykonania kwerend na bazie. Posiadając środowisko testowe możemy od razu przejść do akcji, nie czekając aż wszyscy skończą pracę, a my zostaniemy po godzinach z nadzieją „że nic się nie wysypie”. Uczciwie trzeba zaznaczyć, że czasami „coś się wysypie”, ponieważ nie ma idealnych rozwiązań, bo nie ma też identycznych problemów.

Środowisko testowe, aby miało sens powinno być w identycznej wersji (build) aplikacji co środowisko produkcyjne. Kolejnym ważnym aspektem jest zadbanie o to, aby owe środowisko miało odtworzony jak najświeższy backup.

Innymi często zgłaszanymi problemami są błędy samej aplikacji wykryte podczas codziennego użytkowania. Aplikacja jest sukcesywnie rozbudowywana o nowe ulepszenia i funkcje. Dzieje się to raczej w procesie ewolucji niż rewolucji. Przy wielu dostępnych opcjach, konfiguracjach, odmiennych środowiskach, w których aplikacja działa i biorąc pod uwagę to, że używają jej firmy z różnych branż i w inny sposób korzystają z funkcji aplikacji – tego typu błędy są nieuniknione.

Błąd sklasyfikowany jako poważny, czyli utrudniający korzystanie z aplikacji, zostaje zazwyczaj rozwiązany wraz z kolejną aktualizacją. W momencie, kiedy jest dostępne inne rozwiązanie producent dostarcza stosowne instrukcje. Zastosowanie się do nich powoduje przywrócenie prawidłowego działania aplikacji.

Cykl wydawniczy jest bardzo intensywny. Nowe wersje potrafią się pojawiać z tygodnia na tydzień, rozwiązując szereg zgłaszanych problemów. W tego typu sytuacjach pozostaje jedynie zastosować się do zaleceń i czekać na rozwiązanie zgłaszanych utrudnień.

Ostatnią kwestią, z którą często spotykamy się w pracy w supporcie jest chęć zaawansowanej customizacji portalu pod procesy firmy. Mowa tu o nieszablonowych często złożonych zmianach. Przykłady takich customizacji są wręcz nieograniczone.

Zacznijmy od nieszablonowych zmian w szablonach. Dzięki nim, możemy zapewnić bardziej rozbudowaną automatyzację, od tej dostępnej domyślnie. Wykorzystujemy do tego skrypty wysyłające określone maile do wybranych użytkowników, kiedy zostaną spełnione sprecyzowane warunki. Kolejnym elementem podlegającym personalizacji i zwiększającym automatyzację są raporty i skrypty korzystające z API. Podsumowując robimy wszystko, co możemy, by jak najlepiej spełnić potrzeby naszych klientów.

Praca w supporcie opiera się na ciągłej komunikacji z klientem. Dzięki utrzymaniu regularnego kontaktu w momencie wystąpienia problemu jesteśmy w stanie szybko udzielić pomocy. Warto pamiętać, że wszystkie rozwiązania należy sprawdzić w środowisku klienta. Zmiany, które przyniosą pozytywny skutek u nas, mogą nie zadziałać u klienta w związku z różną konfiguracją środowisk.

Dzielimy się tą wiedzą, abyście zarządzając aplikacjami mogli korzystać z dobrych praktyk, które usprawnią pracę zarówno Waszego, jak i naszego zespołu. Sprawdźcie także gotowe rozwiązania przedstawione poniżej i przekonajcie się, jakie możliwości drzemią w naszych aplikacjach.

SDP Jira CONNECTOR – integracja pomiędzy systemem ServiceDesk Plus, a systemem JIRA Software.

SmartSelfService – portal pozwalający skonsolidować dostęp do najważniejszych funkcji ServiceDesk Plus przy wielu instancjach jednocześnie.

Quick Survey – plugin wzbogacający ankiety wysyłane do użytkowników ServiceDesk Plus w celu oceny wykonania danej usługi.

Resource Protocol – gotowy do wydruku protokół zdawczo-odbiorczy zasobu, tak aby użytkownik mógł potwierdzić swoim podpisem jego odbiór.

 

Chcesz dowiedzieć się więcej o narzędziu i możliwościach ManageEngine ServiceDesk Plus?
Odwiedź naszą stronę!

 

27.02.2020

Autor: marketing@mwtsolutions.eu

Kategorie: Aktualności Artykuł

Newsletter. Bądź na bieżąco.

Kontakt

MWT SOLUTIONS S.A.

ul. Szyperska 14, 61-754 Poznań

Napisz do nas: