W tym artykule chciałbym przybliżyć, jak widzimy systemy SPM (ang. Sales Performance Management, czyli zarządzanie efektywnością sprzedaży) z perspektywy wdrożeń takich systemów.

Mam nadzieję, że w ten sposób uda mi się wzbogacić teorię SPM o pewne praktyczne spojrzenie.

Mam również nadzieję, że uda mi się pokazać, jak fascynujący jest świat wynagrodzeń w sprzedaży. Bo jeśli prawdą jest, że sprzedaż to najważniejsza praca na świecie (logika jest taka: wszystko, co jest wymieniane, musiało zostać sprzedane – a swobodna wymiana jest podstawą cywilizowanego świata) – to wynagradzanie za sprzedaż musi być szlachetnym (i w gruncie rzeczy dość złożonym) zajęciem. Wartym tego, by stały za nim zaawansowane systemy informatyczne.

1. Czym jest (a czym nie jest) SPM?

Czym jest system Zarządzania Efektywnością Sprzedaży (SPM)? Odpowiedź na to pytanie może nie być oczywista nawet dla doświadczonych specjalistów w zakresie kompensacji i wynagrodzeń.

Szybkie wyszukanie frazy SPM w google przenosi nas na strony producentów oprogramowania, gdzie możemy dowiedzieć się, że SPM to:

Metoda planowania, zarządzania i analizowania wyników sprzedaży w skali całego przedsiębiorstwa, zwiększania przychodów i utrzymywania pozycji lidera w branży, oparta na danych. Staje się ona obecnie niezbędnym narzędziem dla organizacji, pozwalającym osiągnąć zwinność działania na współczesnych, szybko rozwijających się rynkach. Karrie Lucero z xacltycorp. com

Choć to oczywiście prawda, to z praktycznego biznesowego punktu widzenia system SPM to głównie narzędzie do kalkulacji. Nikt nie przychodzi do nas i nie mówi: „Potrzebuję systemu SPM, żeby zaprojektować plan sprzedaży”. Klienci raczej przychodzą z gotowymi PDF-ami i mówią: „Hej, to są nasze plany sprzedażowe. Czy możecie się upewnić, że one się dobrze przeliczają?” Chodzi o to, że plany sprzedażowe da się wymyśleć choćby na kartce papieru - wsparcie systemów IT nie jest tu koniecznością. Jednak policzyć wykonalnośc takich planów, tego już na kartce łatwo (lub wcale) zrobić się nie da.

Klienci potrzebują zatem przede wszystkim działających kalkulatorów prowizyjnych, aby mogli wynagradzać swoich handlowców. Po drugie, muszą mieć możliwość samodzielnej zmiany zasad naliczania, najlepiej wraz z symulacjami jak ta zmiana wpływa na wypłaty – bez jakiegokolwiek udziału IT. Wszystko inne jest z tej perspektywy drugorzędne. Ważne, ale drugorzędne. Bez solidnego i elastycznego mechanizmu obliczania prowizji od sprzedaży, żaden system SPM nie może dobrze działać.

2. Trzy najważniejsze rzeczy w systemie SPM: obliczenia, obliczenia i jeszcze raz obliczenia.

Parafrazując słynne powiedzenie ze świata nieruchomości, powiedziałbym, że obliczenia są rdzeniem SPM. W trakcie naszych wdrożeń wielokrotnie widzieliśmy, że klienci utrzymują przy życiu starą metodologię obliczeniową, czymkolwiek by ona nie była – przestarzałym systemem opartym na Cobolu, wewnętrznym dodatkiem do SAP lub zaawansowanym arkuszem kalkulacyjnym Excel, którego używali przez ostatnie X lat. Dopóki system, który wdrażamy, nie będzie dawał takich samych (lub lepszych) wyników obliczeń, oba systemy będą działać równolegle. I czasami zdarza się, że wyniki się różnią! I wtedy zazwyczaj okazuje się, że coś było nie tak w starszym systemie. Albo formuły w Excelu "trochę" się przesunęły, albo jest jakiś przypadek graniczny, o którym wie tylko ta pani z 10 piętra.... Wdrożenie nowego systemu jest więc okazją do ponownego przyjrzenia się obliczeniom i wyprostowania ich. Może się nawet okazać, że koszt inwestycji w nowe narzędzie zwróci się po prostu dzięki poprawieniu formuł i zaprzestaniu nadmiernych wypłat. Może też się okazać że zgodnie z regułami wypłaty były za małe.

Ponieważ obliczenia będące sednem SPM są tak ważne, czasami zarządznie prowizjami jest pojęciowo dzielone na SPM i ICM. ICM (Incentive Compensation Management, jest rozumiany (np. przez Gartnera) jako podstawa, rdzeń SPM. Zawiera on oczywiście zasady kalkulacji. Powinien mieć również możliwość elastycznej ich zmiany w dowolnym momencie bez wsparcia z zewnątrz (czy to od IT czy od integratora który wdrażał system). Powinien działać dla predefiniowanych, ale elastycznych populacji odbiorców, pozwalając specjalistom Comp & Ben decydować, który plan ma być zastosowany gdzie i kogo dotyczy. Powinien również posiadać funkcję Quota and Territory Management, czyli Zarządzania Celami i Terytoriami tak, aby można było ustalić cele kwotowe i umożliwić kredytowanie transakcji (czyli przypisywanie ich do konkretnego sprzedawcy).

SPM a ICM

Widzę dwa problemy z podejściem rozdziału na SPM i ICM omówionym powyżej:

1. ICM – rozumiany jest często jako podstawa SPM. Według Gartnera wygląda to tak:

"Gartner definiuje zarządzanie rekompensatami motywacyjnymi (ICM), które obejmuje standardowe raportowanie i analitykę, jako główną z trzech podstawowych możliwości systemu SPM, które obejmują także zarządzanie terytorium i zarządzanie celami. Te podstawowe możliwości łączą się z następującymi możliwościami okołordzeniowymi: planowanie celów, planowanie terytoriów, zaawansowana analityka, grywalizacja i zarządzanie celami” (więcej informacji tutaj)

Według mnie tak zdefiniowany ICM może zostać łatwo pomylony z STI (Short Term Incentives Management – Zarządzaniem Bonusami, czyli inaczej premiami, które wypłacane są za osiągniecie konkretych wyników, nie związanych jednak z transakcjami sprzedażowymi. Mówiąc wprost STI to bonus za osiągnięcie wyników per KPI i niekoniecznie musi dotyczyć sprzedawców i nalezy na to rozróżnienie uważać, lub przynajmniej być jego świadomym.

Co zdaje się ciekwae, według mnie system SPM powinien jednak zawierać elementy STI – możliwość ustalania, zarządzania i obliczania premii które nie są bezpośrenio związane z transakcjami sprzedażowymi. Uważam, że jest to trafne z punktu widzenia wdrożenia. Nie zawsze bowiem jest tak, że handlowcy są wynagradzani wyłącznie na podstawie transakcji, które zawarli w danym okresie. Mogą istnieć inne cele jakościowe i ilościowe, które wydział Comp & Ben lub zarząd może chcieć włączyć do "paczki kompensacyjnej" sprzedawców, a co za tym idzie dorozwiązania SPM. Co więcej, zdarza się wręcz czasami, że nasi Klienci zamawiają wdrożenie premii i bonusów (STI) nazywając wdrożony system - systemem SPM! W świetle przedstawionych wyżej definicji jest to błędne nazewnictwo. Z prespektywy biznesowej klientów jednak ma to jednak sens - gdyż system który wspólnie tworzymy również służy do motywowania sprzedaży (tak jak SPM / ICM) , choć nie ma nic wspólnego z transakcjami sprzedażowymi.

Dla objaśnienia, przyjrzyjmy się poniższemu przykładowi z klasycznej książki: How To Design and Implement Plans That Work: The Complete Guide to Sales Force Incentive Compensation (Jak opracować i wdrożyć plany, które działają: kompletny przewodnik po systemie wynagrodzeń motywacyjnych pracowników sprzedaży) autorstwa A. Zoltnersa, P. Sinha i S. Lorimera.

W poniższym przykładzie widzimy dwa plany. Plan G wygląda jak coś, do czego jesteśmy przyzwyczajeni w systemach SPM. Plan H jednak grawituje w kierunku premii (czyli STI), a nie planu sprzedaży:

Plan H zachęca sprzedawców do pielęgnowania długoterminowych relacji z klientami. Sprzedawca wynagradzany w ramach tego planu jest bardziej skłonny do „robienia tego, co właściwe” dla klienta, nawet jeśli oznacza to poświęcenie krótkoterminowej sprzedaży. Plan G zachęca do innej relacji między sprzedawcami a ich klientami. Zachęca on sprzedawców do „zrobienia wszystkiego, co konieczne, aby dokonać sprzedaży,” a następnie do działania dalej. Często firmy stosujące plany wynagrodzeń takie jak plan G mają oddzielne organizacje serwisowe, aby zaspokajać bieżące potrzeby klientów. W ten sposób pracownicy działu sprzedaży mogą skupić całą swoją energię na sprzedaży.

Przekładając to na język sales plan G jest planem Łowcy, a plan H jest planem Farmera.

Jeśli nie jesteście zaznajomieni z terminologią Łowca/Farmer, odsyłam Was do tego wspaniałego przykładu autorstwa Toma Abbotta poniżej

Chodzi więc o to, że system SPM powinien być w stanie poradzić sobie z obydwoma rodzajami planów, czyli zawierać elementy STI. W przeciwnym razie nie będzie on kompletny.

2. Drugą kwestią, jeśli chodzi o ICM w świecie wynagrodzeń sprzedażowych, jest to, że jak się wydaje, termin SPM jest bardziej powszechny i popularny w nomenklaturze HR. Dlatego firmy, które szukają rozwiązania swoich problemów z naliczaniem prowizji, szukają raczej systemu SPM, a nie stosunkowo mniej popularnego terminu ICM. Ani Gartner, ani Forrester Wave nie uznają domeny ICM, widzą ją raczej jako część SPM i przygotowują rankingi dla systemów SPM, a nie ICM.

Jeśli kalkulacja jest złotem, to elastyczność jest srebrem.

Jeśli miałbym wskazać, co jest drugą najważniejszą rzeczą dla Klientów (obok poprawności obliczeń), to byłaby to elastyczność – możliwość zmiany samych reguł obliczeń.

Bazując na moim doświadczeniu, większość systemów SPM wykorzystuje jakąś formę graficznego kreatora i/lub możliwość pisania pseudokodu (wpisywanego lub w formie drag & drop) do konstruowania formuł, które są następnie tłumaczone na język zapytań bazodoanowych, czyli SQL. SQL jest następnie przesyłany do backendu i analizowany przez bazę danych (tak – bazy danych nie tylko przechowują dane, ale również obliczają!). Na koniec, baza danych zwraca obliczone wartości, które są przedstawiane użytkownikowi. Z perspektywy biznesowej ważne jest to, jak łatwo te reguły są definiowalne i co trzeba zrobić, aby je zmienić.

Ale elastyczność to nie tylko łatwość zmiany formuł lub pisania nowych reguł obliczeniowych. Chodzi również o możliwość swobodnego i łatwego definiowania celów kwotowych, krzywych wypłat, "podłóg" i "sufitów", hierarchii sprzedażowych oraz tego, kogo plany dotyczą (a kogo nie powinny dotyczyć). W dzisiejszym świecie Software as a Service, nikt nie chce polegać na informatykach przy wdrażaniu tego typu zmian. Klienci nie chcą też dzwonić do integratora systemu z prośbą o pomoc. Chcą mieć możliwość samodzielnego zmieniania znacznie większej ilości rzeczy niż tylko samych podstaw. Przy wdrożeniach jest to dla nas w pełni zrozumiałe. Jako integrator systemów zawsze służymy pomocą w większych sprawach (jak np. wdrażanie spiffów czy korekt uznaniowych), ale w dobrze wykonanym systemie SPM/ICM nasza pomoc nie powinna być niezbędna tylko dlatego, że parametr X powinien mieć teraz wartość „z”, a nie „y.”

Pozostałe funkcje SPM

Przyjrzyjmy się także pozostałym cechom, jakie powinien posiadać system SPM (rozumiany nieco szerzej niż tylko same obliczenia).

Według Gartnera, SPM to:

pakiet funkcji operacyjnych i analitycznych, które automatyzują i łączą procesy operacyjne sprzedaży w back-office. SPM jest wdrażany w celu poprawy wydajności i efektywności operacyjnej. Możliwości obejmują zarządzanie wynagrodzeniami motywacyjnymi w sprzedaży, zarządzanie celami, zarządzanie i planowanie norm, zarządzanie i planowanie terytorium, zaawansowaną analitykę i grywalizację.

Jak wspomniano wcześniej, obliczenia są rdzeniem SPM – ponieważ jest to funkcjonalność oczekiwana przede wszystkim przez użytkowników biznesowych, czyli osoby na których ciąży ciężar terminowości i poprawności obliczeń. Jednak aby kalkulacje doszły do skutku, musi się wiele wydarzyć.

Kalkulacyjny rdzeń SPM (często określanego jako ICM, jak wspomniano wcześniej) zdefiniowałbym zatem jako system elementów zgodnych z poniższym Diagramem 1-1.

Każdy rozwinięty system SPM wykorzystuje te elementy w ten czy inny sposób.

Czasami te podstawowe elementy SPM określane jest jako "5C" – "Collect, Credit, Calculate, Compensate, Communicate": zgodnie ze schematem 1-2 poniżej.

Schemat 1-2 "5C" systemu SPM

Schemat "5C" to dobre zobrazowanie wyzwania biznesowego jakim jest wynagradzanie za sprzedaż.

Najpierw należy zebrać dane o transakcjach (Collect), potem przypisać transakcje do konkretnych sprzedawców (zgodnie z nieraz skomplikowanymi i nieoczywistymi regułami kredytowania) (Credit), następnie wyliczyć poziomy prowizji (Calculate), potem wypłacić należne prowizje (Compensate) troszcząc się jednocześnie o to, by uczestnicy planów wiedzieli co, jak i dlaczego się dzieje (Communicate).

Bez tych elementów, system SPM nie spełni swojej podstawowej funkcji obliczania i wypłacania prowizji za sprzedaż.

Pozostałe elementy SPM, (nieujęte na diagramch 1-1 i 1-2) to:

• Symulacje i modelowanie
• Proste raportowanie
• Zaawansowane raportowanie (BI) – często z "self-service"
• Zestawienia wynagrodzeń (Comp Statements)
• Funkcje audytowania i archiwizacji
• Przeliczenia międzyokresowe
• Zarządzanie reklamacjami co do wyliczeń
• Akceptacje (Approval Workflow)
• Praca na urządzeniach mobilnych,
• Powiadomienia i alerty,
• Interfejsy API / integracje,
• Zwroty wynagrodzeń (Clawbacks)

Dopiero ekosystem tych elementów stanowi pełny system SPM w rozumieniu Garntera. Nie musi to jednak oznaczać, że wszystko jest upakowane w jednym narzędziu. Może to być równie dobrze system narzędzi, które wzajemnie się wzbogacają i współdziałają w realizacji oczekiwanych działań.

Skomplikowanie planów sprzedażowych a SPM

Plany sprzedażowe są często skomplikowane.

Zdarza się, że starsi stażem sprzedażowcy doradzają młodszym, żeby nie przejmowali się swoim planem prowizyjnym tylko "robili swoją robotę". Planu sprzedażowego i tak nie zrozumieją.

Zatem przełożenie planów sprzedażowych na system SPM jest wyzwaniem. Nie chodzi tylko o to, aby system był w stanie funkcjonalnie obsłużyć plany. Równie ważne jest to, aby zespół wdrożeniowy wiedział, co te plany oznaczają biznesowo i w rezultacie potrafił przełożyć je na konfigurację elementów systemu (parametryzacja) i wzory matematyczne, które po wykonaniu zachowują się dokładnie tak, jak opisuje to plan sprzedaży.

Skomplikowane czy nie - pracownicy sprzedaży starają sobie radzić z meandrami planów, niezależnie od stopnia ich skomplikowania. Można zdaje się założyć, że zwykle prowadzą własne obliczenia i dają znać, gdy coś jest nie w porządku z ich planem. Dzięki temu system "sam" się oczyszcza z ewentualnych błędów i niespójności.

Jedno jest pewne w tym przypadku – im bardziej złożone plany, tym bardziej prawdopodobne jest, że będzie potrzebne solidne zarządzanie reklamacjami i dysputami wbudowane w system.

Można założyć, że relacja pomiędzy poziomem skomplikowania planu a dysputami wygląda tak jak na diagramie 1-3 poniżej.

Im większy poziom skomplikowania planu tym zapewne niższy poziom zrozumienia planu przez sprzedawcę i wyższe prawdopodobieństwo nieoprawnych obliczeń. Co za tym idzie liczba składanych przez sprzedawców reklamacji co do obliczeń będzie wyższa.

Wniosek

Mam nadzieję, że udało mi się rzucić nieco światła na tę fascynującą sferę kalkulacji prowizyjnych i na inne istotne elementy systemów SPM. Podsumowując kluczowe punkty, które poruszyłem:

• Rdzeniem SPM są obliczenia, czasami rdzeń ten określany jest jako ICM
• Istnieje kilka podstawowych elementów, które umożliwiają obliczenia i sprawiają że system jest dobry (kredytowanie, przypisanie planów sprzedaży, elastyczność reguł obliczeniowych)
• SPM ma szerokie znaczenie i wiele komponentów, nie wszystkie komponenty muszą znajdować się w jednej platformie IT (w pełni zrealizowany SPM może być połączeniem wielu systemów IT).

W kolejnych krokach zbadamy, dlaczego organizacje wykorzystują koncepcję zmiennych wynagrodzeń i dlatego potrzebują systemów SPM do ich zarządzania.

3. Zarządzanie efektywnością sprzedaży - ramy biznesowe

Do tej pory skupialiśmy się na rdzeniu systemu SPM, czyli na obliczeniach.

Teraz chciałbym zrobić krok wstecz i spojrzeć na SPM z perspektywy biznesowej. Dlaczego obliczenia są w ogóle potrzebne? Zbadajmy, jakie czynniki napędzają tę podstawową potrzebę biznesową i jak SPM na nią odpowiada.

Potrzeba zmiennych składników wynagrodzenia

Wydaje się, że można bezpiecznie założyć, że w dojrzałych gospodarkach ponad połowa firm wykorzystuje koncepcję zmiennych wynagrodzeń (variable pay), czyli wynagrodzeń uzależnionych od wyników, lub spełnienia okreslonego celu. Idea ta sięga 1980 roku, kiedy to koncepcja pay-for-performance (płatność za wyniki) została wprowadzona przez American Compensation Association. Przynajmniej tak korzenie tej koncepcji widzi Lori Wisper z Willis Towers Watson w tym interesującym artykule na temat celowego wynagradzania za wyniki.

Obecnie, według Salary.com:

77% firm w Stanach Zjednoczonych stosuje programy zmiennych składników wynagrodzenia jako część swoich pakietów nagród całkowitych.

Europa i reszta świata mogą pozostawać w tyle, jednak wydaje się jasne, że koncepcja wynagradzania za wyniki jest dobrze ugruntowana. Wydaje się też logiczne, że organizacje są skłonne płacić za wyniki.

**Kiedy firma jest spójna wewnętrznie (to znaczy, kiedy to, co robią ludzie pomaga firmie osiągnąć jej godziwe cele), wtedy jest miejsce na rozwój osobisty i synergię działań. Odpowiednie wynagradzanie pomaga w osiągnięciu i utrzymaniu tego stanu.

Zmienił się również rodzaj pracy wykonywanej przez ludzi. W przypadku wielu rodzajów pracy możliwa jest obecnie praca z niemal każdego miejsca i dla niemal każdego na całym świecie. Nadzór i mikro-zarządzanie są trudne i generalnie niemile widziane. Ludzie zdają się doceniać elastyczność i korzyści płynące z samodzielnej pracy. Tradycyjne pojęcie pracownika zanika, a wzmacnia się idea, aby traktować ludzi pracujących razem niezależnie oraz wspierać i doceniać ducha przedsiębiorczości.

Ta postawa jest widoczna w wielu miejscach, od podręcznika Tesli Elona Muska po postawę i filozofię Navala Ravikanta – człowieka stojącego za sukcesem Ubera, Twittera, Opendoor, Stack Overflow, Clubhouse, Notion i wielu innych produktów, które odniosły powodzenie.

Aby tak się jednak stało, koledzy z zespołu i współpracownicy muszą przyjąć osobistą odpowiedzialność za swoje przedsięwzięcia i wyniki. I tu właśnie w grę wchodzi wynagrodzenie zmienne.

Kiedy pracownik również przyjmie taką postawę, coraz większa część wynagrodzenia może być wynagrodzeniem zmiennym, a wynagrodzenie będzie zależało od wyników i będzie z reguły potencjalnie większe niż zwykła płaca zasadnicza. To podejście jest szczególnie popularne w sprzedaży.

Zmienne wynagrodzenie w dziale sprzedaży

Wynagrodzenie zmienne może przybierać różne formy. Może to być premia dla całej firmy, premia zespołowa, premia indywidualna, premia punktowa, udział w zyskach i inne krótkoterminowe nagrody motywacyjne, najprawdopodobniej oparte na obiektywnych wskaźnikach KPI i ważone względem OTB (On Target Bonus, czyli premii za osiągnięcie celu). Mogą one również występować w postaci premii długoterminowych (premii odroczonych), opartych na regulacjach i matrycach odroczeń.

Jednak miejscem, w którym wynagrodzenie zmienne odgrywa największą rolę jest sprzedaż. Najczęściej przybiera formę prowizji wypłacanej za dokonane transakcje, lub premi dla handlowców (najczęściej „farmerów”) za określone zachowania lub osiąganie celów długoterminowych.

Eksperci w tej dziedzinie (między innymi Andris Zoltners) sugerują, że istnieją co najmniej cztery powody, dla których wynagrodzenie zmienne jest tak ważne w sprzedaży.

1. Sprawczość zespołu sprzedażowego.

Ogólnie rzecz biorąc, im większy wpływ mają pracownicy sprzedaży na fakt, że klient dokonuje transakcji, tym większe powinno być ich wynagrodzenie zmienne. Istnieją branże lub marki, w których dokonywanie sprzedaży jest stosunkowo łatwe (np. towary szybkozbywalne) oraz branże, w których cykl sprzedaży jest długi, a zrozumienie i zaangażowanie sprzedawcy jest kluczowe (np. dedykowane oprogramowanie dla przedsiębiorstw, automatyzacja produkcji, roboty). Im trudniejsza i mniej pewna jest sprzedaż, tym bardziej przyciąga ludzi podejmujących ryzyko, którzy są skłonni pracować za niewiele lub nawet za nic w oczekiwaniu na tę jedną dużą transakcję, której poświęcają swój czas. Dlatego nagroda musi być hojna, aby przyciągnąć tak utalentowanych "ryzykantów", jak na przykład Ian Koniak z SalesForce.

2. Wyniki w sprzedaży są zazwyczaj mierzalne.

Zazwyczaj możliwe jest zmierzenie sprzedaży w kategoriach przychodu lub nawet zysku, jaki przynosi dana transakcja. Wyniki sprzedaży są również porównywalne w kategoriach pieniężnych pomiędzy sprzedawcami i terytoriami sprzedaży. Oznacza to, że cele są obiektywne i stosunkowo jasne, a zatem stosowanie zmiennego wynagrodzenia za sprzedaż wydaje się naturalne i słuszne.

3. Sprzedaż ma bezpośredni wpływ na wyniki firmy i samo jej istnienie.

Bez sprzedaży, żadna firma nie może istnieć długo. Sprzedaż ma bezpośredni wpływ na przychody firmy i jej istnienie. Dlatego skłonność do płacenia za wyniki w sprzedaży jest naturalna.

4. Płaca zmienna uwalnia handlowców od mikro-zarządzania i ścisłego nadzoru.

Gdy firmy płacą za wyniki w sprzedaży, osiągane rezultaty, a co za tym idzie wysokość wypłaty lub jej brak motywuje handlowców do samokontroli. Otrzymują oni natychmiastową, a czasami wręcz ostrą informację zwrotną od świata zewnętrznego na temat swoich działań zawodowych.

5. Docenienie sukcesu

Osoby pracujące w sprzedaży często doświadczają odrzucenia i negatywnych emocji. Zmienne wynagrodzenie pomaga odbudować pewność siebie, dodać otuchy sprzedawcy i podnieść morale.

Te idee zostały opisane bardziej szczegółowo w książce Complete Guide to Sales Force Incentive Compensation na stronach 11-12.

Wskaźnik zmiennych wynagrodzeń w dziale sprzedaży

Według Harvard Business Review idealna proporcja przyjęta przez rynki wydaje się wynosić 60 % płacy stałej i 40 % płacy zmiennej, czyli zależnej od wypełnienia celu. Różni się to jednak w zależności od branży.

Im większa jest wpływ działu sprzedaży na decyzję podejmowane przez klienta, tym wynagrodzenie zmienne powinno mieć większy udział w proporcji. Również literatura biznesowa sugeruje takie podejście, patrz artykuł w Financial Express.

Zasada no-cap, czyli bez ograniczeń, może być również dobrym pomysłem, ponieważ usunie problem „daj z siebie wszystko i odejdź”, zapewniając najlepszym pracownikom dalszą motywację, niezależnie od tego, jak dobrze sobie radzą.

Znalezienie właściwej kombinacji płacowo-motywacyjnej to obszerne zadanie, w którym pomoże właściwe wykorzystanie danych firmowych, symulacji i raportów BI dostępnych w ramach systemu SPM.

Znaczenie systemu zarządzania efektywnością sprzedaży

Biznesowa Struktura Wynagrodzeń zaproponowana przez A. Zoltnersa, P. Sinha i E. Lorimera w książce Sales Force Incentive Compensation wygląda następująco:

Ten digram pomaga uchwycić istotną perspektywę: dane przedsiębiorstwo ma bezpośrednią kontrolę tylko nad planem wynagradzania. Sprzedawcy sami wybierają działania, które chcą podjąć. Jeśli system wynagrodzeń jest zły lub niesprawiedliwy, będzie ich raczej demotywował niż motywował do działań.

Również klienci z definicji sami podejmują decyzje zakupowe. Przedsiębiorstwa mają pośredni wpływ na te decyzje przez marketing oraz odpowiednie zachowania sprzedawców - na które z kolei można wpływać między innymi za pomocą planów motywacyjnych i sprzedażowych. Przedsiębiorstwo może na przykład promować skupianie się na długoterminowych potrzebach klientów przez sprzedawców, lub skupienie się na nowej linii produktów - a tym samym pośrednio wpływać na zachowania i na decyzje klientów.

Ważne jest to, że, pomijając marketing, jeśli istnieje tylko jeden punkt wpływu na zachowanie handlowców i decyzje klientów w procesie sprzedaży, (czyli plan sprzedaży i zarządzanie jego realizacją), to dlaczego nie wykorzystać go w pełni? Jeśli przedsiębiorstwo nadal robi to za pomocą arkuszy kalkulacyjnych i e-maili, wydaje się, że nadszedł czas, aby przejść do czegoś bardziej bezpiecznego, funcjonalnego i wygodnego.

Zarządzanie wynagrodzeniami a cykl koniunkturalny

W czym jeszcze może pomóc Sales Performance Management? Ciekawy artykuł P. M Madhani sugeruje, że można nawet pokonać cykl koniunkturalny (lub przynajmniej zmniejszyć rozmiar problemu), odpowiednio manewrując priorytetami i celami handlowców w ramach planów wynagrodzeń sprzedażowych.

Typowy cykl koniunkturalny wygląda następująco:

Idea przedstawiona przez M. Madhani jest taka, że w fazie recesji (kurczenia się) firmy mogą proaktywnie obniżyć koszty stałe wynagrodzeń i skupić się na zmiennych bodźcach płacowych, zwłaszcza tych, które pozwolą utrzymać krytyczne relacje z klientami.

Autor ujmuje to w ten sposób:

Organizacje sprzedażowe, które zamrażają lub obniżają wynagrodzenia albo płacą poniżej stawek rynkowych w fazie ekspansji cyklu biznesowego, ryzykują utratę wartościowych pracowników sprzedaży i będą miały trudności z przyciągnięciem najbardziej utalentowanych sprzedawców. Z drugiej strony, organizacje, które płacą zbyt dużo w okresie recesji, ryzykują pogorszenie swojej kondycji finansowej i zdolności do zatrudniania pracowników sprzedaży, których potrzebują, aby prosperować w trudnych warunkach rynkowych.

To sprawia, że elastyczność informatycznych systemów wynagrodzeń, takich jak SPM, jest strategicznie ważna.

Pułapki niedopasowania zachęt sprzedażowych

Błędna strategia sprzedaży lub niewłaściwe plany prowizyjne mogą przesądzić o przetrwaniu lub upadku organizacji, i to niekoniecznie w czasach kryzysu. Również w spokojnych czasach takie niedopasowanie może wpędzić organizację w poważne kłopoty.

Rozważmy dwa przykłady.

Przykład pierwszy dotyczy firmy CrossComm, byłego konkurenta Cisco w czasach wschodzącego rynku sieci i routerów. Firma wpadła w kłopoty tracąc koncentrację na flagowym produkcie w oczekiwaniu na premierę nowej linii produktowej. Handlowcy podgrzewali atmosferę, przez co ówcześni klienci stracili zainteresowanie kupnem istniejącego sprzętu, w oczekiwaniu na nowy, lepszy sprzęt. Niestety, usterki w nowym produkcie opóźniły jego wejście na rynek, zaś w międzyczasie sprzedaż dotychczasowego produktu gwałtownie się skurczyła. To niemal unicestwiło firmę i przyczyniło się do przejęcia jej przez duńskiego konkurenta – Olicom.

Inny słynny przypadek wadliwego planu prowizyjnego który narobił firmie poważnych kłopotów miał miejsce w Wells Fargo, jednym z głównych banków hipotecznych w Stanach Zjednoczonych.

Poniższy cytat z Forbes wyjaśnia, co się stało:

Problemy zaczęły się, kiedy kierownictwo Wells Fargo zaczęło wywierać presję na szeregowych pracowników banku, aby agresywnie sprzedawali produkty (cross selling) i postawili im [źle dobrane] cele sprzedażowe. Oszustwa wyszły na jaw, gdy pracownicy Wells Fargo założyli miliony kont oszczędnościowych i bieżących dla klientów bez ich wiedzy i zgody.

Ta sprawa kosztowała bank fortunę i poważnie nadszarpnęła jego reputację.

Podsumowanie ram działalności SPM

Mam nadzieję, że tym artykułem udało mi się umieścić systemy SPM (i rykoszetem także inne systemy pokrewne, związane z Total Compensation Management) w perspektywie biznesowej. Uważam, że przy wdrażaniu systemów SPM czy Total Comp ważne jest zrozumienie, po co dane funkcjonalności są w ogóle potrzebne i jaki cel biznesowy spełniają.

Same technikalia IT nie wystarczą. Tylko rozumiejąc perspektywę biznesową można wdrożyć funkcjonalności, które sprostają oczekiwaniom i wypełnią potrzeby biznesowe zainteresowanych osób.

4. Najczęstsze problemy z danymi w Sales Performance Management i jak ich uniknąć

Kolejną sprawą na której chciałbym się skupić w SPM są dane, a dokładniej to, co może pójść z nimi nie tak i jak tego uniknąć.

Prawda jest taka, że jeśli chcesz wdrożyć lub poszerzyć system SPM, czy to poprzez nowe narzędzie do wyliczeń, poprzez Business Intelligence (BI), self-service portal dla pracowników, lub w jakikolwiek inny sposób, jedna rzecz prawie na pewno spowolni Twoje wysiłki. Są to Twoje dane.

Bez dobrej jakości danych wdrożenie będzie się opóźniać a system nie będzie działał. Tymczasem nasze doświadczenie w GGS wskazuje na to, że organizacje z reguły są przekonane, że mają dane znacznie lepszej jakości niż ma to miejsce w rzeczywistości. Dlatego często naszym pierwszym krokiem we wdrożeniach jest praca z danymi i odpowiednie ich przygotowanie.

Dlaczego ludzie myślą, że dane są w lepszym stanie niż są w rzeczywistości

Myślę, że istnieje wiarygodne wyjaśnienie tego powszechnego zjawiska.

1. Po pierwsze, proces prowizyjny w tej chwili jakoś funkcjonuje. Może być nieefektywny. Może odbywać się w Excelu i arkuszach kalkulacyjnych Google. Zarządzanie nim może angażować zbyt wiele osób. Może nie być transarentny i produkować tony ukrytych błędów. Jednak w danym momencie działa - to jest liczy prowizje. Więc skoro daje jakieś wyniki, to musi być oparty na dobrych danych, prawda? Niestety, w dziewięciu przypadkach na dziesięć okazuje się to błędem. Mimo to istnieje tendencja do zakładania, że podczas gdy system SPM będzie się zmieniał i ulepszał, te ulepszenia i innowacje będą nadal oparte na tym samym „sprawdzonym” zestawie danych.

2. Po drugie, dane są często własnością działów zewnętrznych w stosunku do Comp & Ben. Oznacza to, że specjaliści ds. wynagrodzeń muszą polegać na innych działach i innych osobach, ufając, że dane są prawidłowe, i nie mając możliwości łatwej weryfikacji tego założenia. Kiedy więc dochodzi do integracji nowych danych lub powstania jakichkolwiek nowych potrzeb w zakresie danych, mogą wywiązać się pewne tarcia i napięcia pomiędzy działami. Zazwyczaj działy IT nie dysponują czasem i budżetem, aby pomóc w zakresie danych – ponieważ nie przewiduje się zawczasu, że jakakolwiek pomoc w zakresie danych będzie potrzebna. Mało kto myśli o jakichkolwiek buforach czasowych i zasobach wewnętrznych. W takim środowisku emocje i frustracja mogą pojawić się bardzo szybko.

Myślę, że są to dwa główne powody, dla których ludzie zwykle przyjmują, że ich dane HR i SPM są w lepszym stanie niż są w rzeczywistości.

Lista typowych problemów z danymi SPM i jak ich unikać

Poniższa lista powstała w oparciu o rzeczywiste doświadczenia Konsultantów wdrażających lub dostosowujących systemy SPM u swoich Klientów. Dlatego też lista ta ma charakter praktyczny i powinna być pomocna w unikaniu typowych błędów.

1. Brak dostępnych danych dla realizowanego celu

Zdarza się, że zmieniając system (lub ulepszając istniejący), natrafiamy na sytuację, która nie była obsługiwana lub przewidziana do momentu, gdy zmiana ma nastąpić. Przykładowo, do tej pory mogliśmy nie naliczać prowizji prorata (czyli proporcjonalnie do czasu w jakim sprzedawcę obowiązywał dany plan sprzedażowy), a teraz chcielibyśmy zacząć to robić.

Wyobraźmy sobie sytuację, w której firma ma tylko kwartalne plany sprzedaży, a teraz chciałaby przejść na plany półroczne lub roczne. Śledzenie kto był na jakim etapie którego planu i przez jak długi czas mogło do tej pory nie być dla firmy istotne (potencjalnie dopuszczano zmiany stanowisk, stopni lub tytułów tylko na początku nowego kwartału) – jednak teraz, przy nowym podejściu, nagle staje się ważne, aby wiedzieć dokładnie kiedy nastąpiła zmiana. Od tych nowych danych zależeć będą ocena realizacji celów i osiągnięć. Firma musi więc albo zacząć zbierać takie dane, albo zacząć dostarczać dane z istniejącego systemu HCM/ERP do narzędzia SPM - jeśli te dane są już dostępne.

2. Problemy z interpretacją danych / problemy ze znaczeniem danych

Te nieścisłości rodzą się na granicy danych i ich zrozumienia.

Najlepszym sposobem na wyjaśnienie tego typu niespójności jest stwierdzenie, że dane niosą ze sobą znaczenie. Znaczenie to jest zależne od interpretacji. Jeśli dwie lub więcej osób rozumie te same dane w różny sposób, to błędy w logice systemu są nieuniknione. Cytując jednego z konsultantów GGS: „...logika stojąca za danymi [w tym przypadku] okazuje się być czymś innym niż zakładano, dlatego znaczenie danych jest inne, a co za tym idzie, dane mogą być źle wykorzystywane”.

Wyobraźmy sobie sytuację, w której jednostka danych nazywana jest „datą transakcji”. Dla różnych osób może ona oznaczać różne rzeczy. Data transakcji może oznaczać datę podpisania umowy przez Klienta, datę kontrasygnaty, datę akceptacji transakcji przez dział prawny, dział księgowości lub jeszcze coś innego. Jeśli na dacie transakcji oparta jest prowizja, ważne jest, aby osoby uzupełniające dane wiedziały, która data jest właściwą >>datą transakcji<< i odpowiednio ją wypełniły. W przeciwnym razie może się okazać, że wypłacamy prowizje za transakcje, które tak naprawdę jeszcze nie miały miejsca.

Innym przykładem z życia wziętym jest „data zatrudnienia”. W jednym z projektów odkryliśmy, że „data zatrudnienia” jest w rzeczywistości datą przedłużenia umowy, co zmienia perspektywę dla niektórych przypadków. Zdarzało się też, że osobom, które nadal pracują w firmie, wpisano datę w rubryce „data odejścia” – co może mieć fatalne konsekwencje i powodować chaos.

Tego typu błędy powstają, gdy osoby z Comp & Ben nie są świadome logiki stojącej za danymi które są im dostarczane. Może się tak zdarzyć że departament Comp & Ben bez własnej winy, nie zna prawdziwego znaczenia danych przechowywanych i gromadzonych w systemach HCM oraz innych (np. sprzedażowych) źródłach danych.

3. Dane niezgodne ze specyfikacjami

Tego typu problem nie jest problemem danych samych w sobie, jednak może znacząco utrudnić postępy wdrożenia.

Zdarza się, że zespół wdrożeniowy i właściciele danych uzgadniają konkretny format, w jakim dane będą dostarczane (np. ustalają specyfikację techniczną), jednak dostarczone dane nie zachowują ustalonego formatu. Może się to zdarzyć we wszystkich typach integracji, bez względu na to czy są to integracje API, pliki płaskie czy dane pobierane z pośrednich baz danych.

Aby zobrazować problem na prostym przykładzie, wyobraźmy sobie, że w specyfikacji integracji danych ustalono, że średnik będzie separatorem kolumn w pliku płaskim (csv). A potem okazuje się, że sam średnik jest gdzieś użyty jako część danych, np. w polach komentarza. Wtedy struktura pliku nie może być przetworzona zgodnie z ustaleniami i zadanie integracyjne kończy się niepowodzeniem (ponieważ system „myśli,” że w pliku jest więcej kolumn niż jest w rzeczywistości). Innym przykładem mogą być problemy z kodowaniem znaków, nieprawidłowe znaki końca linii lub brakujące węzły w pliku JSON itp.

Tego typu problemy, choć same w sobie nie są krytyczne, mogą poważnie podminować wysiłek związany z integracją danych, jeśli stale się powtarzają.

Ustanowienie dobrej integracji danych może być wyzwaniem i wymaga czasu. Czasami zdarza się więc, że projekty są realizowane na danych niskiej jakości, bez uruchamienia faktycznej integracji. Zazwyczaj wiąże się to z koniecznością wprowadzania zmian w systemie i dodatkową pracą i stresem dla wszystkich zainteresowanych, gdy dobre połączenia zostaną już ustanowione.

Poniższa wypowiedź Pedra Nunesa, jednego z architektów rozwiązań w GGS, pozwala zrozumieć tego typu sytuacje:

Bywały przypadki, w których pliki nie przychodziły zgodnie ze specyfikacjami (niewłaściwy koniec linii, zmieniona kolejność kolumn, niewłaściwe sortowanie). Pomimo przygotowań i wprowadzonych walidacji próby integracji poprzez wadliwy interfejs kończyły się niepowodzeniem. Nie było to przypadek który mogliśmy „naprawić później”, ale musieliśmy poświęcić czas na zbadanie, dlaczego się nie udało i naprawić błędy u źródła.

4. Kwestie dotyczące danych czasowych

Dane czasowe to dane, które odnoszą się do instancji czasowych. Poprzez przechowywanie danych czasowych, jesteśmy w stanie „opowiedzieć historię” o tym, jak sytuacja, którą te dane opisują ewoluowała w czasie. Ten typ danych zazwyczaj ma, według wiki:

• Czas ważności - to okres**,** w którym dany fakt jest zgodny z prawdą w świecie rzeczywistym.
• Czas transakcji to czas, w którym fakt został odnotowany w bazie danych.
• Czas decyzji to czas, w którym podjęto decyzję o tym fakcie.

Dane czasowe mogą być przechowywane na wiele sposobów, np. z datą początkową i końcową konkretnej sytuacji lub tylko z datą początkową (czasami nazywaną "datą od") dla każdej zmiany stanu faktów przechowywanych w tabeli czasowej. W takim przypadku daty końcowe sytuacji są niejawnie obliczane poprzez wykorzystanie dat początkowych kolejnych wpisów.

Z danymi czasowymi może wiązać się kilka problemów:

• dziury czasowe – gdy jakiś okres czasu nie jest uwzględniony w żadnej sytuacji, a powinien być (jedna sytuacja kończy się, gdy druga jeszcze się nie zaczęła),
• pętle czasowe – gdy istnieje okres czasu, dla którego obowiązuje więcej niż jedna sytuacja (data rozpoczęcia danej sytuacji jest większa niż data zakończenia poprzedniej),
• duplikaty – gdy istnieją dwie lub więcej sytuacji dla których nie ma zmian odnośnie opisywanych faktów i dlatego powinny zostać połączone

Nie wszystkie systemy informatyczne generują lub przechowują daty rozpoczęcia lub zakończenia danych sytuacji. Czasami zdarza się, że jesteśmy proszeni o wygenerowanie takich dat, przyjmując jako datę rozpoczęcia danej sytuacji moment, w którym dana sytuacja zostałą przesłana do systemu.

Jest to ryzykowne, ponieważ moment załadowania informacji do systemu staje się wtedy datą początkową (lub datą wejścia w życie) sytuacji czasowej. W tym przypadku, jakakolwiek nieprawidłowość związana z otrzymywaniem danych zmienia obraz, czy też „historię”, którą dane opowiadają. Może się wtedy okazać, że historia ta jest błędna. Dlatego odradzamy używanie tego podejścia w systemach SPM lub Comp & Ben.

Kolejną rzeczą, którą należy rozważyć w przypadku danych czasowych, jest rozmiar tabel faktów. Wyobraźmy sobie, że system przechowuje sto atrybutów danych demograficznych pracowników i powiedzmy, że wynagrodzenie podstawowe jest zawarte w tych danych. W takiej sytuacji, przy każdej zmianie wynagrodzenia należy wpisać nowy rekord do bazy, powtarzając wszystkie wartości dla owych stu atrybutów. Takie powtarzanie informacji jest zbędne. Lepsza jest niewielka tabela zawierająca tylko te fakty które są potrzebne systemowi SPM.

5. Problemy z danymi referencyjnymi / słownikowymi

Zdarza się również, że dana rzecz jest opisana za pomocą więcej niż jednego obiektu danych.

Klasycznym przykładem w SPM jest informacja o transakcjach, która składa się z identyfikatora transakcji, identyfikatora klienta, daty transakcji, kwoty transakcji, waluty transakcji i potencjalnie innyhc danych. Zazwyczaj identyfikator klienta jest następnie zdefiniowany w innym obiekcie danych, który zawiera ten sam identyfikator klienta oraz informacje opisujące klienta, tj. nazwę klienta, adres, itd. Jeśli zdarzy się, że system SPM otrzyma identyfikator klienta wraz z zapisem transakcji/kontraktu, a ten klient nie jest zdefiniowany w innym obiekcie danych, system nie będzie w stanie przetłumaczyć identyfikatora klienta na nazwę klienta i poprawnie wyświetlić tych informacji.

Problemy tego typu są określane jako problemy z danymi referencyjnymi lub słownikowymi. Standardową praktyką jest odrzucenie paczki danych, które zawierają tego typu problemy. Może to prowadzić do nieuznania transakcji, błędnego naliczenia prowizji i sporów zgłaszanych przez sprzedawców – a wszystko z powodu problemów związanych z danymi referencyjnymi.

6. Niewystarczająco dobre dane testowe

Systemy SPM, które są w trakcie tworzenia, potrzebują dobrych danych testowych. Przez dobre dane testowe w tym kontekście rozumiemy:

• dane o złożoności podobnej do danych używanych w systemie rzeczywistym (zwanym również systemem produkcyjnym)
• dane, które obejmują wszystkie możliwe przypadki graniczne
• dane, które można łatwo odtworzyć lub ponownie załadować
• dane w tej samej ilości co dane produkcyjne (czyli dane używane w systemie rzeczywistym)
• dane, które przechowują odniesienia istniejące w danych bieżących (produkcyjnych)
• dane, które niosą ze sobą kontekst biznesowy,

Przyjrzyjmy się każdemu z tych punktów:

• dane o złożoności podobnej do danych używanych w systemie rzeczywistym (zwanym również systemem produkcyjnym)

Ważne jest, aby zmiany w systemie były testowane na danych o podobnej złożoności jak dane rzeczywiste, używane w działających systemach.

Na przykład testowanie krzywych prowizyjnych jest dokładniejsze, gdy wartości wypełnienia celu sprawdzane w odniesieniu do krzywej obejmują wszystkie możliwe zakresy. Lepiej jest przetestować działąnie krzywej dla wypełnienia celu w 0%, 50%, poniżej 100% powyżej 100%, poniżej limitu, powyżej limitu i tak dalej, niż przetestować tę funkcjonalność robiąc sztuczne założenie że wypełnienie celu sprzedażowego wynosi zawsze na pryzkład 100%.

• dane, które obejmują wszystkie możliwe przypadki graniczne

Ten punkt jest podobny do punktu powyżej, z naciskiem na przypadki graniczne, czyli takie, które znajdują się bezpośrednio na granicy przedziałów wartości. Przykładowo, dobrze jest mieć dane testowe, które obejmują sytuację z 31 grudnia danego roku i z 1 stycznia roku następnego.

• dane, które można łatwo odtworzyć / ponownie załadować

Użwanie danych testowych, które są trudne do odtworzenia stworzy niepotrzebną presję na osoby testujące system. Testerzy będą się bali zepsuć coś, lub nadpisać pewne dane testowe, ponieważ wiedzą, że ponowne ich odtworzenie będzie trudne. Będą więc niechętni do szukania dziur w systemie i testowania przypadków granicznych. Będą wiedzieli, że każdy test lub każdy błąd będzie ich kosztował dużo czasu, poświęconego na odtworzenie danych - szczególnie jeśli są one tworzone ręcznie poprzez interfejs użytkownika aplikacji, a nie poprzez uruchomienie skryptu lub ponowne załadowanie danych testowych.

Z tych powodów dobrze jest utrzymywać skrypt usuwania i odtwarzania, najlepiej taki, który tworzy losowo dobre dane testowe, jeśli to możliwe.

• dane w tej samej ilości co dane produkcyjne (czyli dane używane w systemie rzeczywistym)

Zdarza się, że system zachowuje się świetnie z danymi testowymi i ma wysoką wydajność.

Wszystko wtedy idzie dobrze aż do momentu Go-Live, kiedy system jest konfrontowany z milionami wierszy danych, z którymi nie zapoznał się nigdy wcześniej.

Mogą zacząć się wtedy niespodziewane problemy z wydajnością, a cały wysiłek związany z budową systemu stoi pod znakiem zapytania jedynie przez to, że nie załadowano wcześniej wystarczającej ilości danych testowych i nie przetestowano systemu w takiej sytuacji.

• dane, które przechowują odniesienia istniejące w danych bieżących (produkcyjnych)

Dane testowe powinny odzwierciedlać odniesienia obecne w prawdziwych danych. Na przykład, gdy istnieje identyfikator klienta testowego, powinna istnieć również nazwa klienta testowego powiązana z tym identyfikatorem. Powinny one jak najdokładniej odzwierciedlać rzeczywiste scenariusze i odniesienia.

• dane, które niosą ze sobą kontekst biznesowy

Najlepiej, aby system był sprawdzany i testowany również przez osoby, które będą z niego korzystać na co dzień. Idealnie byłoby, gdyby tacy użytkownicy zobaczyli demo nowego systemu (lub wprowadzanych zmian do istniejącego narzędzia) na przykład raz na dwa tygodnie a następnie mieli możliwość sprawdzenia i zapoznania się z systemem. Uzytkownicy będą lepiej reagować i rozumieć system, gdy to, co w nim zobaczą, będzie niosło dla nich kontekst biznesowy. Na przykład, gdy nazwiska sprzedawców są prawdziwymi nazwiskami, a nie tylko ciągami znaków, lub gdy struktura sprzedaży ma sens podobny do prawdziwej struktury. W przeciwnym razie użytkownicy łatwo się pogubią i będą mieli awersję do systemu.

Dlatego warto pamiętać, że ludzie, którzy będą korzystać z systemu na co dzień, lepiej zareagują na testy, i będą bardziej cenić system, gdy dane testowe, które widzą w systemie, są przygotowane dla nich i niosą ze sobą kontekst biznesowy.

Wnioski

Oto, czego z perspektywy wdrażania nauczyliśmy się w ciągu ponad pięciu lat realizacji nowych systemów:

1. Dane prawie nigdy nie są w tak dobrym stanie jak wydaje się że są.

2. Zazwyczaj nie jest łatwo uzyskać korektę danych w źródłach (z różnych powodów, albo dział IT jest przeciążony, zewnętrzny dostawca nie jest skory do współpracy, nie przewidziano budżetu na naprawę danych itp.). Najczęściej więc wspólny zespół projektowy musi zaakceptować fakt, że dane testowe nie są najlepsze, stworzyć obejścia i radzić sobie z sytuacją, jednocześnie wywierając presję na osoby odpowiedzialne za dane w źródłach, aby w końcu je poprawiły.

Jeśli miałbym podsumować temat danych w SPM, powiedziałbym, że ważne jest, aby przed rozpoczęciem projektu stworzyć bufor czasu i energii potrzebny na "walkę" z danymi.

Najprawdopodobniej już na początku wdrożenia pojawią się problemy z danymi. Ich rozwiązanie będzie wymagało czasu i energii. Jednakże, po pewnym czasie intensywnego wysiłku i współpracy, interfejsy danych zostaną ustanowione, problemy z danymi naprawione, a dane nie będą już problemem.

Mam nadzieję, udało mi się naświetlić zagadnienie danych w SPM / ICM i artykuł ten okaże się pomocny przy zmianach w systemach i przy wdrożeniach.