Systemy chmurowe są jakieś inne… – procesy zakupowe

Data: 2020-05-06
Autor: Sebastian Konkol
Systemy chmurowe są jakieś inne… – procesy zakupowe

Do tego, że składową przekazu dotyczącego Cloud Computing  jest marketingowo wzmacniany hype nie trzeba chyba przekonywać. O krytycznym spojrzeniu na skalę hype w komunikacji zagadnień chmurowych, na przykład w odniesieniu do uzasadnień finansowych usług chmurowych, napisano już wiele. Rzecz jasna, nie tak wiele, jak marketingu w tej sprawie. Dodałem także kilka groszy od siebie do tej publicznie prowadzonej dyskusji. Jednym z warunków urzeczywistniania tak fantastycznych business case jest zdolność do prowadzenia skutecznych procesów zakupowych. Czy kontekst zakupów chmurowych coś tu namiesza?

Nie przedstawię tu, rzecz jasna, kompletnej recepty na prowadzenie procesów zakupowych dla usług chmurowych. Świadczę takie usługi, więc – dla konkretnej organizacji i planów zakupowych – chętnie pomogę kompleksowo. Pokażę jednak kilka przykładów, jak bardzo kupowanie usług chmurowych miesza w praktykach zakupowych.

Procesy zakupowe mają kilka aspektów, ale – na potrzeby niniejszego skrótu zagadnienia – skupię się na dwóch z nich: optymalizacji zakupów (działania o charakterze negocjacji, grupowanie zakupów dla zwiększenia skali, przesuwanie w czasie do „lepszego okresu” itp.) oraz weryfikacja realizacji umowy (czy wydatki podążają za sporządzanymi ich planami, będącymi podstawą dla osiągnięcia korzyści z optymalizacji).

Optymalizacja, jak każde działanie „parawojenne”, jest skuteczna, jeśli jest prowadzona na własnych warunkach, a nie narzuconych sytuacją. Aby zyskać, trzeba wiedzieć coś więcej i to wcześniej. Negocjacje w warunkach postawienia pod ścianą nie są najczęściej skuteczną formą optymalizacji. Tym bardziej, że dla większości podmiotów korzystających z usług chmurowych – w konsekwencji porównania wielkości ich biznesu do wielkości biznesu usługodawcy chmurowego – cennik usług jest zwykle cennikiem detalicznym i nie jest raczej obszarem poddawanym znaczącym negocjacjom.

Kontrola wydatków, będąca podstawą weryfikacji realizacji umowy z perspektywy zakupowej, ma sens na etapie zaciągania zobowiązań. Na tej samej zasadzie controlling i rachunkowość zarządcza są czymś innym, niż księgowość. Praktyka pokazuje jednak, że często kontroli podlegają dopiero wydatki, co jest znaczącym ograniczeniem dla egzekwowania założeń optymalizacji. Usługi chmurowe, z perspektywy zaciągania zobowiązań, to najczęściej formy przedpłacone (subskrypcja, czy budżet do wykorzystania), co poddaj w wątpliwość wszelkie możliwości optymalizacji opartej wyłącznie na mechanizmach zakupowych.

Przydałby się jakiś przykład, więc dla przykładu podam przykład. Uzasadnienia biznesowe dla wyboru usług chmurowych w miejsce innych form wykorzystania infrastruktury (własne Data Centre, kolokacja, hosting) obejmują zwykle możliwości szerokiego wykorzystania mechanizmów skutkujących obniżaniem opłat. Takie mechanizmy to działania ściśle techniczne, np. administracyjne wyłączanie maszyn IaaS na czas braku ich utylizacji (np. na zakończenie każdego dnia pracy), downsizing kontenerów serwujących aplikacje (o ile upsize zwykle nie niesie sprzeciwu developerów, o tyle automatyka downsize wymaga wyrafinowania w konstrukcji), przyjmowanie schematów opłat rozliczania wyłącznie zużytych zasobów SaaS. Każdy taki model skutkuje – rzecz jasna jedynie na poziomie kontrolingu – przyjęciem jakiegoś budżetu (np. na użytkowanie IaaS) i koniecznością weryfikacji efektywności realizacji założonych działań (np. osiągniętego obniżenia użycia zasobów, redukcji liczby licencji czy skuteczności ich konwersji do tańszych). I tu ujawnia się „tempo chmury”, w którym zachodzące zdarzenia skutkują konsekwencjami finansowymi w czasie krótszym o rząd wielkości (lub nawet kilka rzędów), niż w przypadku rozwiązań on-premises. Drugim kluczowym elementem zmieniającym podejście do procesów zakupowych usług chmurowych jest realne ważenie wydatków oczekiwanym poziomem jakości (QoS / SLA). Podkreślam realne, nie zaś roszczeniowe – realne, czyli oparte o dowody uzasadniające godziny dostępności usług, czasy niedostępności, czasy przywracania w oparciu o finansowe mierniki wartości biznesowej „utraconego czasu”. Ma znaczenie zarówno w wymiarze świadomego obniżenia oczekiwań dla umożliwienia obniżenia kosztów, jak i w wymiarze skuteczności monitorowania realizacji SLA wpływających nie tylko na abstrakcyjne umowy, ale na rozliczenia finansowe. Krótko mówiąc, zagadnienia jakości stanowić mogą nawet większościowy udział w kosztach przedsięwzięcia i ma to sens, jeśli są uzasadnione. QoS/SLA everywhere oraz wbudowanie zdolności egzekwowania w działania operacyjne, bo w przypadku usług chmurowych ryzyko przekroczenia budżetu jest w całości przeniesione na kupującego.

Gdyby do zagadnień zakupowych z „tempem chmury” przyłożyć obecne praktyki zespołów source’ingowych (wymagania, dokumentacja, akceptacje, postępowania przetargowe, negocjacje, zamówienia do umów ramowych), kompletny paraliż ich działań nastąpiłby najpóźniej po kwartale. Pomijając nawet zagadnienie – wtedy już absurdalnych – kosztów takiej działalności. „Tempo chmury” wymaga przemyślenia także praktyk zakupowych. Na ich kształt trzeba bowiem spojrzeć – tak samo, jak w przypadku praktyk zarządzania technologią – nie z punktu widzenia poprawy stosowanych obecnie rozwiązań organizacyjnych, ale od podstaw, od celów i uwarunkowań, od definicji, kwestionując każde „wierzenie” i „wieloletnią praktykę”. Stosowanie dotychczasowych praktyk w świecie „tempa chmury” oznacza działanie zawsze reaktywne, postawione pod ścianą, więc widoki osiągnięcia poziomów KPI definiowanych dla zespołów zakupowych byłyby raczej marne.

Jeśli więc naprawdę chodzi o optymalizację zakupów, „tempo chmury” narzuca włączenie procesów zakupowych w działalność operacyjną, splątanie ich w działaniami ściśle technicznymi, z monitoringiem dopasowanym do wymogów śledzenia zmiennych umowy wpływających na cenę, a także na wywieranie skutecznego wpływu optymalizacyjnego. Najważniejszą jednak różnicą jest prosta konstatacja, że optymalizacja oznacza skierowanie działań do wnętrza firmy, a nie w kierunku dostawcy – zakupy stają się więc przede wszystkim jednostką kontrolną dla organizacji, a nie jej dostawców.