Od dłuższego czasu nosiłem się z pomysłem na tekst o przetargach. Z racji pracy, którą wykonuję mam z nimi sporo do czynienia – jako przedstawiciel producenta, a często także bezpośredniego oferenta.
Nie będzie to tekst o przetargach regulowanych ustawą o zamówieniach publicznych, ale głównie o tych, które ogłaszają firmy komercyjne, nie podlegające specjalnym regulacjom.
Przetarg – choć nie jest jedyną drogą wyboru dostawcy – może być metodą na obniżenie całkowitego kosztu inwestycji w rozwiązanie, a także sposobem na zorientowanie się w najnowszych technologiach i rozwiązaniach dostępnych aktualnie na rynku. Rozmawiając z wieloma potencjalnymi dostawcami, klienci zyskują lepszą wiedzę o aktualnych możliwościach technologicznych.
Zapytanie o informację – dlaczego to ważne?
Żeby w pełni wykorzystać potencjał procesu przetargowego, zanim zostanie ogłoszone RFP (zapytanie o cenę), firma powinna przejść etap RFI (zapytanie o informację). To najczęściej dość otwarte pytanie, które moglibyśmy streścić tak:
Drogi dostawco, mamy pewną potrzebę. Zakładamy, że umiesz nam w tym pomóc. Zaproponuj coś…
Etap ten – czasem poprzedzony albo prowadzony równolegle z dialogiem technicznym z dostawcami powinien prowadzić do precyzyjnego sformułowania oczekiwań kupującego, które finalnie trafią do potencjalnych oferentów. Innymi słowy – jak już zapoznamy się z dostępnymi na rynku możliwościami, będziemy w stanie lepiej określić własne potrzeby.
Ze smutkiem obserwuję, że dzieje się tak coraz rzadziej. Etap RFI jest albo zupełnie pomijany, albo jeśli w jakiejś formie wystąpił, jego wyniki często są ignorowane. Nawet w dużych zakupach mamy do czynienia tylko z RFP oraz towarzyszącym zapytaniu SIWZem (Specyfikacją Istotnych Warunków Zamówienia). I właśnie do tej praktyki chciałbym się dziś odnieść…
Nie jest tajemnicą, że rynek infrastruktury IT oferuje rozwiązania dość podobne. Podobieństwo wynika z wykorzystania do budowy tych samych komponentów oraz z istnienia standardów przemysłowych. To dzięki standardom mamy szansę połączyć serwery producenta A z macierzami producenta B używając przełączników producenta C w sprawnie działający organizm. Jest to sytuacja bardzo dla kupujących wygodna, ponieważ zapewnia zdrową konkurencję. Jest też niestety potencjalnie ryzykowna…
Produkty – choć są podobne – nie są jednak przecież takie same.
Producenci odmiennie definiują potrzeby klientów, dysponują różnymi doświadczeniami i technologiami, a dzięki temu powstają rozmaite rozwiązania. Raz na jakiś czas ktoś wpada na pomysł produktu odmiennego niż konkurencja, który albo rewolucjonizuje rynek albo z niego znika w niesławie.
Uznanie przez kupującego, że „wszystkie produkty są takie same” i w konsekwencji brak dialogu technicznego czy poważnego traktowania fazy RFI prowadzi do zmniejszenia szansy na wybór optymalnego rozwiązania.
Jednym ze skutków takiego założenia jest prowadzenie kilku odrębnych postępowań zakupowych na różne komponenty infrastruktury. Nie wykluczam sytuacji, w której to właśnie jest droga do osiągnięcia najlepszego rozwiązania za najlepszą cenę. Będzie tak pod warunkiem, że decyzja o takim sposobie zakupu została poprzedzona analizą dotyczącą całego planowanego środowiska i potencjalne zyski przewyższyły związane z tym podejściem ryzyka.
Prowadząc taką analizę dowiemy się od wielu producentów, że zakup dwóch lub więcej części infrastruktury z jednego źródła pozwoli na przykład na tanie zautomatyzowanie rutynowych czynności, co w przyszłości zaowocuje mniejszymi kosztami posiadania albo większą niezawodnością budowanej platformy. Producent w oczywisty sposób stara się skłonić Klientów do korzystania z całego swojego portfolio. Zamawiający może uznać to za nadmierne uzależnienie i kupić moduł automatyzujący pracę z firmy trzeciej albo wykonywać tę samą pracę ręcznie – jest to jego suwerenna decyzja. Czy jednak zanim się ją podejmie nie jest lepiej dowiedzieć się z czego się rezygnuje?
Innym efektem ignorowania różnic między produktami jest bardzo precyzyjne określanie w wymaganiach jak oferent ma realizować potrzebę Zamawiającego. SIWZ nie opisuje potrzeby Klienta w postaci oczekiwanej pojemności, wydajności, odporności na awarie czy możliwości rozbudowy, ale dowiadujemy się jakie dokładnie i ile komponentów mamy włożyć do serwera czy macierzy, żeby spełnić warunki przetargu.
Takie podejście nie tylko odbiera Klientowi możliwość skorzystania z doświadczeń oferentów gromadzących doświadczenia dzięki uczestnictwu w wielu projektach informatycznych. Skutkiem jest także oferowanie konfiguracji zupełnie nieoptymalnych.
Nie zaskoczę nikogo, jeśli napiszę, że z tych samych komponentów powstają często zupełnie różne produkty. Skutkiem bardzo precyzyjnego określenia typu i ilości komponentów przez Zamawiającego może być stworzenie produktu mniej wydajnego, bardziej awaryjnego czy po prostu droższego niż to konieczne. Dlatego namawiam Zamawiających – zostawcie to nam. Napiszcie czego potrzebujecie a o optymalną konstrukcję urządzeń zadbają producenci.
Określanie potrzeb jest sprawą niezwykle delikatną.
Z jednej strony są pewne elementy, które łatwo zmierzyć lub określić np. wydajność, pojemność, odporność na awarie komponentów czy kompatybilność z używanym środowiskiem. Z drugiej strony, są potrzeby znacznie trudniejsze do opisania, na przykład łatwość obsługi. Mają one później olbrzymi wpływ na komfort pracowników, ale też na efektywność pracy, a więc na całkowity koszt posiadania (TCO).
W tym kontekście z żalem przyznaję, że nie spotkałem się jeszcze w żadnym z przetargów z wymaganiem, by jakaś czynność wykonywana często przez administratora dała się zrealizować w X krokach lub w czasie nie dłuższym niż Y minut. A przecież to czy jakieś powtarzalne zadanie wymaga dodatkowego etatu czy piętnastu minut pracy raz na tydzień to wielka różnica w sumarycznych kosztach.
Parametry wydajnościowe to także trudny temat. W Dell Technologies wykonujemy naprawdę dużo pomiarów środowisk Klientów, cały czas gromadząc doświadczenie w ich interpretacji, ale też wiedzę o potrzebach różnych aplikacji. Nawet w miesiącach wakacyjnych, tygodniowo uruchamiamy ponad 2200 projektów pomiarowych obejmujących obciążenia serwerów, macierzy i sieci. Są to zarówno projekty obejmujące pojedyncze maszyny, jak i nawet ponad 120 serwerów w jednym projekcie.
Bywa tak, że zapytanie przetargowe jest także poprzedzane takimi pomiarami. Jakie jest nasze zdziwienie, jeśli zapis przetargowy mówi o wymaganiach nawet 100 (sto) razy większych niż aktualne wykorzystanie. Niekoniecznie jest to błąd. Czasem jest to realna estymacja stanu za dwa trzy lata. Jakże jednak rzadko w zapytaniu przetargowym pada równolegle pytanie o koszt rozbudowy kupowanego środowiska do tej zakładanej w przyszłości wydajności.
Na koniec jeszcze jeden pomysł – kryteria testowania.
Nie jest trudno sformułować wymagania dotyczące pojemności czy wydajności środowiska. Nie jest też trudno napisać, że się te wymagania spełnia. Każdy może tu myśleć o czymś zupełnie innym. Gdybym był kupującym to w każdym dokumencie SIWZ wpisywałbym informację, że deklarowane przez dostawcę parametry będą sprawdzone i opisałbym, w jaki sposób. Dodałbym do tego informację, że jeśli dostawca nie przejdzie testów przeprowadzonych w ciągu 1 miesiąca od instalacji (z możliwością poprawki poprzez dodanie odpowiednich zasobów, jeśli pierwszy test nie poszedł pomyślnie) to całość rozwiązania zostanie zwrócona. Jestem przekonany, że wiele ofert nie ujrzałoby wówczas światła dziennego. Z wielką korzyścią dla samych Zamawiających.
Podsumowując, Drodzy Klienci:
- Rozmawiajmy o rozwiązywaniu potrzeb biznesowych, nie o komponentach i konstrukcji
- Dopiero później, świadomie podejmijcie decyzję o częściach składowych przetargu
- Nie konstruujcie rozwiązań, które chcecie kupić – zostawcie to producentom
- Pomyślcie o wymaganiach definiujących koszt obsługi bieżącej
- Zanim wpiszecie wymagania wydajnościowe czy pojemnościowe zdefiniujcie realistycznie własne potrzeby
- Uwzględnijcie koszt rozbudowy w zapytaniu przetargowym
- Obiecajcie testy po dostawie i podajcie metodologię
I jeszcze raz: rozmawiajmy!
