Każda firma uzbrojona w pakiet aplikacji wspomagających zarządzanie relacjami z klientem mierzy się z kwestiami związanymi z dostępem do uprawnień. 

Kiedy mamy ich za mało, powierzonego zadania nie możemy dokończyć bez angażowania dodatkowych zasobów osobowych, często w postaci wiecznie zapracowanej kadry menadżerskiej. Niekorzystną będzie również sytuacja, w której pracownik posiada za duży dostęp do zasobów firmowych. Nadmiar opcji może po prostu człowieka przytłoczyć i, zamiast usprawnienia pracy, będziemy mieli niepotrzebny stres i opóźnienia. Wprowadza to też zagrożenie, że dane będą niepotrzebnie wyciekać czy, w skrajnym wypadku, dojdzie nawet do ich utraty. Nawet najlepsze narzędzia nie zdadzą się na wiele w przypadku, gdy nie będziemy mieli chociaż podstaw wiedzy, jak je wykorzystać. Dodatkowym punktem, który warto jest poruszyć podczas pracy z systemami CRM, jest ich dostrajanie do mechanizmów naszej działalności. Niezależnie, czy wybierzemy gotowe rozwiązanie, czy zdecydujemy się, aby nasz program stworzyła firma developerska, jedną z pierwszych rzeczy, która czeka nas przy pierwszym kontakcie z gotowym programem, jest odzwierciedlenie struktury osobowej naszej firmy w systemie.

Firma > Oddział > Dział > Stanowisko pracy – dla wskazywania lokalizacji oraz

Administrator > Zarząd > Kierownik > Zastępca > Pracownik – dla określania poziomu stanowiska osób logujących się do systemu.

Takie schematy pozwalają w większości przypadków na zaspokojenie struktury firmy. Naturalnie rozbudowa tych struktur jest możliwa do wprowadzenia wraz z rozwojem firmy, jednak trzeba pamiętać, że  każda przebudowa systemu od momentu zaistnienia potrzeby do jej wdrożenia będzie potrzebowała czasu. Dlatego zawsze przy planowaniu kroków nasuwa nam się pytanie: „Czy na pewno jest mi to potrzebne w tym momencie?”. Wtedy warto zmodyfikować je do formuły: „Czy takie rozwiązanie będzie wystarczające dla firmy za 2–5 lat?”. Część rozwiązań obecnie może wydawać się niepotrzebna, część wyjdzie dopiero w trakcie pracy z systemem, dlatego istotne jest, aby w miarę szczegółowo nakreślić podstawy systemu i potencjalne gałęzie jego rozwoju. 

Równolegle do struktury firmy będzie tworzona kontrola uprawnień.

Każdy moduł, a dalej zakładka/widok modułu i bardzo często same funkcje w widoku nie muszą być dla wszystkich użytkowników systemu dostępne. Tak jak różne są potrzeby każdej firmy, tak ilość i rodzaje takich elementów będą zmienne, natomiast poziomy uprawnień w większości da się zamknąć w stałej liście.

Takie trzy standardowe poziomy uprawnień, które możemy nałożyć na każdy element względem użytkownika systemu, to:

–  Brak dostępu do elementu – dany element nie jest widoczny dla użytkownika,

–  Widok elementu – użytkownik ma wgląd do danego elementu,

–  Edycja elementu – użytkownik ma dostęp do edycji danych w danym elemencie.

Pozycja, która standardową nie jest, ale występuje dosyć często jako oddzielne uprawnienie, to:

–  Generuj dokument z elementu – użytkownik jest uprawniony do wygenerowania pliku z danymi z elementu.

Mamy już strukturę firmy oraz kontrolę uprawnień dla elementów w systemie. Wypadałoby je teraz połączyć tak, by każdy z użytkowników w systemie znalazł się na odpowiednim miejscu z pakietem uprawnień dostosowanych do swojego stanowiska. Personalizację uprawnień dla stanowisk warto przeprowadzać według metody od ogółu do szczegółu, gdzie zestopniowanie takich uprawnień zaczynamy od działu. Gdy ustalimy, do jakich modułów systemu dany dział powinien mieć wgląd (uprawnienie – widok elementu), mamy pewność, że każde kolejne stanowisko, które dodamy do danego działu, będzie miało niezbędne minimum do rozpoczęcia pracy.

Nadając uprawnienia, nie wychodzimy powyżej stanowiska.

Pracownicy, jakkolwiek byliby niezastąpieni, czasami odstępują od stanowiska pracy. Jeżeli nadaliśmy wszystkie uprawnienia pod stanowisko, wystarczy, że nadamy stanowisko pracownikowi, który zastąpi nam powstałe braki osobowe. Natomiast jeżeli nadawalibyśmy uprawnienia pod konkretnego użytkownika, każde zastępstwo wymagałoby weryfikacji uprawnień użytkownika i przydzielania ich osobie zastępującej.

Kolejnymi krokami będzie stworzenie konkretnych stanowisk w dziale: zaczynając od stanowiska najniższego szczebla, którego uprawnienia najprawdopodobniej będą się pokrywały z podstawowym dostępem do działu, poprzez wyższe stanowiska, które stopniowo osiągną wyższe poziomy uprawnień (edycja elementu) oraz dostęp do większej ilości modułów, kończąc na stanowiskach kierowniczych, które znowu otrzymają dostęp większej części systemu oraz do wspominanego wcześniej generowania dokumentów. Warto tutaj zauważyć, że tworzymy uprawnienia dla konkretnego stanowiska. A co, jeżeli pan J. z działu serwisowego będzie potrzebował dodatkowych uprawnień w jakimś module? Na pewno powinna nam się zapalić lampka, czy takie uprawnienie dla danej osoby na pewno jest potrzebne. Jeżeli rozwikłamy już ten problem, to pojawia się kolejny – komu ostatecznie nadajemy to dodatkowe uprawnienie? Pan J. posiada stanowisko i do niego właśnie należy dołożyć takie przywileje.

Dobrze, działy ustawione, stanowiska pracy gotowe. Ktoś pewnie zauważy, że na początku wspominany zakres był trochę szerszy. Przecież zarząd, a tym bardziej administrator, też będzie korzystał z systemu. Dla administratora sprawa jest łatwa, nie ma tutaj mowy o jakichkolwiek ograniczeniach. Administrator trzyma pieczę nad poprawnym działaniem programu, dlatego dziwne byłoby, gdyby nie miał dostępu do któregoś elementu.

Jeżeli zaś chodzi o stanowiska związane z zarządem, tutaj potrzeby każdego użytkownika należy potraktować indywidualnie ze względu na to, że część kadr zadowoli się wglądem w moduły, a część zechce ingerować w treści. Jednak z czasem, u któregoś z użytkowników, pojawić się może potrzeba tak nietypowa, że wymagana będzie zmiana widoku.

Tak przygotowana struktura daje nam podstawy do poprawnej pracy zarówno w systemie, jak i samej firmie, co bezpośrednio przekłada się na optymalizację wydajności i minimalizację problemów związanych z dostępem do odpowiednich elementów.