Strategie zakupowe, czyli zoo w centrum danych
-
- Krzysztof Jakubik,
- 09.06.2008
Decydując się na współpracę z tylko jednym dostawcą w określonym zakresie, należy go zbadać pod kątem powyższych dwóch parametrów, aby zminimalizować ryzyko. Często bowiem dochodzi do sytuacji, gdy w firmie, w wyniku wygranego przetargu dany sprzęt instaluje jedna firma, a pół roku później, po drugim przetargu, takie same modele urządzeń instaluje druga. W dużej infrastrukturze zapanowanie nad tym, kto za co odpowiada w kontekście serwisowym, graniczy z cudem. Nie mówiąc już o sytuacji, gdy takie same urządzenia, wdrożone przez różne firmy, nie współpracują ze sobą.
Przy usługach IT kupowanych od firm zewnętrznych pojawia się jeszcze wątek związany z przeniesieniem nie tylko odpowiedzialności za dane rozwiązanie, ale także ogólnej wiedzy na jego temat. Klient powinien zwrócić uwagę na to, czy dostawca zabierając do siebie strategiczną wiedzę o jego architekturze IT, całkowicie nie uzależnia od siebie dalszego funkcjonowania firmy. W najgorszej sytuacji, gdy cała wiedza przejdzie do firmy outsourcingowej, nie będziemy w stanie podjąć żadnej decyzji, zarządzać zmianą czy wykonać rozbudowy bez kontaktu z dostawcą usług, a także wyrażenia przez niego zgody. W ten sposób tracimy kontrolę, a dostawca usług zaczyna dyktować nam warunki dotyczące każdej, nawet najmniejszej inwestycji. Ponieważ nie mamy wiedzy na temat tego środowiska, nie jesteśmy w stanie podejmować odpowiednich decyzji. Planując na kolejny rok, chcąc przyłączyć do sieci kolejnych użytkowników, pytamy o to, jakie trzeba poczynić inwestycje, aby zapewnić odpowiednią wydajność. W takiej sytuacji możemy usłyszeć dowolną kwotę i nawet nie jesteśmy w stanie tego skontrolować.
Przy tego typu współpracy, gdy usługi w naszym centrum danych wykonuje firma zewnętrza, należy pozostawić sobie możliwość sprawowania pełnej kontroli. Trzeba zmusić dostawcę usług do tego, by przygotował odpowiednią dokumentację, był odpowiedzialny za jej aktualizację, stworzył tzw. model architektoniczny rozwiązania, którym zawiaduje. Dzięki temu powstanie proces zarządzania zmianą bazujący na uzasadnieniu biznesowym. Takie relacje muszą opierać się na jasno ustalonych, sprecyzowanych zasadach.
W kontekście rozmów o strategiach zakupowych pojawia się problem oprogramowania opartego na otwartym źródle. Szef działu IT jednej z polskich firm powiedział nam, że nawet komercyjnej dystrybucji Linuksa, do której ma wykupione wsparcie, nie powierzyłby krytycznego rozwiązania biznesowego. - "Żaden szef działu IT kierujący się zdrowym rozsądkiem nie powierzy swojego krytycznego rozwiązania systemowi, który rozwija społeczność internetową... W takim przypadku, gdzie konieczne jest zagwarantowanie odpowiedniego czasu reakcji czy przywrócenia systemu do pracy, należy wykorzystać rozwiązanie sprawdzone i wielokrotnie przetestowane w powtarzalnych warunkach. Linux świetnie sprawdzi się tam, gdzie ryzyko biznesowe związane z przestojem systemu jest niewielkie".
Obok systemów otwartych, pojawia się także sprawa otwartych standardów. Kwestia tzw. interoperability jest wymuszana przez rynek i w podstawowych aspektach realizowana przez większość dostawców. Diabeł jednak tkwi w szczegółach. Zdaniem ekspertów, klienci są już na tyle świadomi, że są w stanie powybierać od poszczególnych firm to, co one mają najlepszego. Aby te mogły mieć przewagę konkurencyjną, muszą więc zapewnić możliwość współpracy z konkurencyjnymi rozwiązaniami. Ale dla klienta pojawia się wspominany już problem: co w przypadku, gdy występuje on na styku takich dwóch systemów? Jak rozstrzygać takie kwestie sporne, szczególnie w tej samej warstwie infrastruktury?
