19 błędów w zarządzaniu IT
- 06.07.2012, godz. 13:17
Prezentujemy listę błędów w zarządzaniu IT, których bezwzględnie należy unikać.
Prezentujemy listę błędów w zarządzaniu IT, których bezwzględnie należy unikać.
<b>Kurczowe trzymanie się "dobrze znanych" rozwiązań</b>
Częstym błędem szefów działów IT, podejmujących nową pracę, jest wprowadzanie na siłę rozwiązań i praktyk, stosowanych w poprzedniej firmie, w nowym środowisku o innych warunkach technologicznych i potrzebach biznesowych. To, że się sprawdziły w jednych warunkach nie oznacza przecież, że muszą się sprawdzić w nowych.
Przemysł IT dynamicznie się rozwija - warto skorzystać z okazji by znaleźć właściwe rozwiązanie, bez ograniczania się do tych dobrze już znanych.
<b>Ignorowanie wpływu czynnika ludzkiego na bezpieczeństwo</b>
Obecnie administratorzy dysponują całym arsenałem narzędzi bezpieczeństwa. Warto jednak pamiętać słowa Kevina Mitnicka - najsłabszym połączeniem każdej sieci jest człowiek. Większość dobrze zabezpieczonych od strony technicznej sieci, jest wciąż podatna na atak wykorzystujący inżynierię społeczną. Jak zachowają się użytkownicy naszej sieci jeśli zostaną np. sprytnie zmanipulowani do podania hasła, czy innych poufnych danych przez telefon?
Edukacja użytkowników jest nieodłącznym elementem polityki bezpieczeństwa. Muszą być świadomi możliwości ataków z użyciem inżynierii społecznej i muszą wiedzieć jak na nie odpowiedzieć.
<b>Błędne podejście do open source</b>
Wiele firm jest nastawionych mocno podejrzliwie do pewnych technologii czy platform. Dotyczy to bardzo często open source. Oznacza to pomijanie wielu stabilnych, skalowalnych i przystępnych kosztowo rozwiązań, które dostępne są właśnie w tym modelu.
Nie należy jednak popadać w przesadę . Próba budowania "szytego na miarę" rozwiązania na bazie otwartego kodu źródłowego może opóźnić rozwój informatyczny przedsiębiorstwa. Zamiast zmuszać deweloperów do "sklejania" niezbyt do siebie pasujących rozwiązań, warto sprawdzić, czy nie powstało rozwiązanie komercyjne, spełniające nasze założenia.
<b>BYOD - brak wsparcia technicznego (i kontroli) prywatnych urządzeń</b>
Zdarza się, że BYOD (Bring Your Own Device) wiąże się w niektórych firmach z tym, że pracownicy stają się swoim prywatnym działem IT. Czasami wynika to z niechęci świadczenia wsparcia dla nienależącego do firmy sprzętu, czasami jest gestem zaufania wobec, często dobrze obeznanych w nowych technologiach, pracowników.
Każde urządzenie jakie pojawia się w firmie (ściślej, które w jakikolwiek sposób służy do dostępu do firmowych danych) musi być do pewnego stopnia wspierane (i kontrolowane) przez firmowy dział IT. Nawet obyci informatycznie użytkownicy częściej znają możliwości niż ewentualne zagrożenia związane z BYOD.
Na rynku pojawia się coraz więcej urządzeń i rozwiązań pozwalających na zarządzanie prywatnymi urządzeniami mobilnymi wykorzystywanymi w korporacji. Przed opracowaniem polityki BYOD warto dobrać odpowiednie narzędzia, pozwalające z jednej strony zatroszczyć się o bezpieczeństwo danych, z drugiej nie odbierające użytkownikom komfortu pracy na ich ulubionych urządzeniach.
<b>Zła strategia outsourcingu</b>
Pierwszym z dwóch popełnianych błędów jest powierzenie ważnych funkcji IT zewnętrznym wykonawcom, co pozwala na komfort uniknięcia trudu ich zrozumienia. Outsourcing tych funkcji faktycznie ten komfort zapewni, ale może też znacznie utrudnić ich uproszczenie.
Drugim często popełnianym grzechem jest kurczowe trzymanie funkcji, które można łatwo i efektywnie wyprowadzić na zewnątrz, zwłaszcza w erze cloud computingu. Takie podejście może jednak być przyczyną nieszczęścia. Przykład: Hostowanie krytycznych z punktu widzenia dochodów firmy aplikacji we własnych murach ze względu na brak zaufania do zewnętrznych operatorów. Konkurencja bardziej otwarta na dobrze przygotowane usługi w chmurze nieźle zarobi na każdej awarii w takiej opartej na własnych zasobach firmie.
<b>Specjalista managerem?</b>
Awans dobrego specjalisty na managera nie musi ani dobre dla niego ani dla firmy. Profesjonalista, swobodnie poruszający się w świecie nowych technologii, niekoniecznie musi równie dobrze radzić sobie w zarządzaniu zespołem. Mogą pomóc w tym szkolenia, ale warto dobrze się zastanowić czy awansowana osoba rzeczywiście ma do tego predyspozycje.
Również sam zainteresowany powinien się zastanowić, czy chce spróbować swoich sił na nowym stanowisku - jego dotychczasowe zostanie zapewne zajęte przez kogoś innego i powrót nie będzie możliwy. W rezultacie błędu firma straci cenionego fachowca, zaś dla on sam pracę.
<b>Niezastąpieni specjaliści</b>
Wydaje się że to bardzo wygodne jeśli jeden pracownik zna na wylot systemy - zarządzanie nimi, rozwiązywanie problemów itp. ma w małym palcu. Jednak taki niezastąpiony specjalista jest czymś czego powinno się starannie unikać. Zastanówmy się co się stanie jeśli poważnie zachoruje, będziemy musieli go zwolnić, albo sam postanowi skorzystać z innej oferty pracy?
Zamiast kreować takich wyspecjalizowanych ekspertów należy zadbać o pracę zespołową. Wszechstronni pracownicy działu IT będą bardziej przydatni, a niezawodne działanie systemów IT nie będzie oparte na wiedzy jednego eksperta.
<b>Złe podejście do haseł</b>
W kwestiach bezpieczeństwa zwykle koncentruje się uwagę na najnowszych zagrożeniach, zaniedbując nieco to co bardzo ważne - politykę haseł. Słabe czy nawet nie ustawione hasła kont użytkowników czy administratorów, dobrze znane hasła, słabe funkcje skrótu tworzące pliki z hasłami - każda z tych rzeczy może być przyczyną poważnych problemów firmy.
Słabe hasła są złe, ale polityka wymuszająca bardzo skomplikowane hasła jest równie zła. Użytkownicy zmuszeni do korzystania z trudnych do zapamiętania haseł będą je po prostu zapisywać na karteczkach przyklejanych do monitora czy układanych pod klawiaturą.
Hasła muszą być dobre, ale też wymagania ich dotyczące muszą być rozsądne.
<b>Brak szacunku dla starszych ... rozwiązań </b>
Młodzi informatycy często nie mogą pogodzić się z tym, że w ich firmie krytyczne procesy mogą nadal być obsługiwane przez wiekowe rozwiązania. Tymczasem specjalista IT powinien przedkładać niezawodność nad urodę. Aplikacje z zielonym ekranem nie będą tak piękne jak najnowsze widżety, ale stary dobry system nie narazi nas na takie ryzyko jak nowiutki i niesprawdzony.
Modernizowanie starych systemów może jednak się nie opłacać. W czasach zaciskania pasa nie warto pozbywać się tych „dinozaurów”, które potrafią jeszcze na siebie zarobić.
<b>Utrata kontroli nad krytycznymi zasobami</b>
Polecenie zwierzchników: „dział marketingu potrzebuje uruchamiać kwerendy SQL w trybie ad-hoc na produkcyjnej bazie danych”. Umożliwienie tego nie jest wielkim problemem, więc wykonujemy to polecenie. Potem co czwartek, przed cotygodniowym zebraniem działu marketingu, obserwujemy jak serwer „ledwo dyszy”, gdy jest bombardowany źle sformułowanymi zapytaniami. Jakie dostajemy następne polecenie? „Rozwiązać problem z wydajnością”.
Doświadczenie i decyzje menedżera IT decydują o jakości informatyki w firmie. Dlatego jeśli zajmujący się biznesem zwierzchnicy żądają wykonania zadań, które będą miały na tę jakość zły wpływ, to nie powinniśmy unikać za wszelką cenę konfrontacji. Musimy jasno przedstawić sprawę. Zły pomysł to zły pomysł, nawet jeśli zwierzchnicy tego nie rozumieją
<b>Stawianie na niesprawdzone rozwiązania</b>
Publiczne wersje beta są dziś bardzo rozpowszechnione. I może się pojawić pokusa skorzystania z takiego niesprawdzonego rozwiązania w środowisku produkcyjnym. Nie wolno jej ulec. Możemy się pobawić w beta-testera na naszym laptopie, ale nie w centrum danych. Zamiast tego po prostu kontrolujmy rozwój produktu – bądźmy świadomi nowych wersji, poznawajmy je, ale wprowadzajmy tylko te, które są stabilne.
Eksperymentujmy z pilotażowymi projektami tylko na wycinku struktury firmy. Kiedy wprowadzamy nowe rozwiązanie, bądźmy pewni, że ma ono wsparcie techniczne.
<b>Zbytnie przywiązanie do jednego dostawcy</b>
Wiele firm stale korzysta z usług jednego dostawcy, który zaspokaja ich wszystkie potrzeby informatyczne. A wielcy dostawcy uwielbiają oferować rozwiązania zintegrowane i kontrakty wsparcia technicznego, które „załatwiają wszelkie problemy”. Taka oferta bardzo często trafia do przekonania zapracowanych działów IT. Jeśli jednak kontrakt, któremu ufamy, obejmuje też niedojrzałe produkty, przerastające możliwości dostawcy, to mamy problem.
Związanie się z takim niedopracowanym rozwiązaniem będzie skutkować długotrwałymi reperkusjami. Z jednej strony korzystanie z oferty dostawcy, z którym od dawna współpracujemy, ma swój biznesowy sens. Z drugiej - jeśli w danej kategorii to ktoś inny ma lepsze rozwiązanie, dlaczego z niego nie skorzystać?
<b>Strach przed wirtualizacją</b>
Jeśli nie korzystamy z dobrodziejstw wirtualizacji, to bardzo komplikujemy sobie życie. Uruchamianie wielu wirtualnych maszyn na pojedynczym fizycznym hoście kapitalnie podnosi wskaźnik wykorzystania sprzętu, tym samym zwiększając zwrot z naszych inwestycji w hardware. Wirtualizacja umożliwia nam szybkie wdrażanie i migracje nowych systemów, a także tworzenie odseparowanego środowiska (sandbox) do testowania nowego oprogramowania i różnych konfiguracji systemów operacyjnych.
Co prawda jacyś dostawcy mogą twierdzić, że ich produktów nie można instalować w zwirtualizowanych środowiskach, ale to właśnie jest powód, żeby im już podziękować. Wirtualizacja przynosi zbyt dużo dobrego, by ją ignorować.
<b>Błędna strategia dla przetwarzania w chmurze</b>
Cloud computing obiecuje wiele korzyści: zdolność zwiększania zasobów i funkcjonalności bez inwestowania w nową infrastrukturę i szkolenia nowych pracowników, brak konieczności zakupu nowych licencji na oprogramowanie itp. Ale skutki niekontrolowanego skoku w chmurę mogą być gorsze niż przegapienie możliwości tej usługowej platformy. Obietnice bez pokrycia, problemy z integracją i bezpieczeństwem – oto, co może nas wtedy czekać. Nie możemy też zakładać, że całą odpowiedzialność za nasz niedziałający system będziemy mogli po prostu zrzucić na dostawcę usług. Dlatego nasza przygoda z chmurą musi mieć bardzo przemyślane podstawy.
<b>Brnięcie w wadliwe projekty</b>
Nie każdy projekt musi kończyć się sukcesem. Trzeba nauczyć się wcześnie dostrzegać oznaki problemów i odpowiednio szybko działać. Projekt może się chwiać z tysiąca różnych powodów, a dalsze inwestowanie w niego może pogłębić problemy. Dlatego powinniśmy mieć dla każdego projektu przygotowaną strategię wyjścia oraz zdolność jej uruchomienia, zanim wadliwy projekt zakończy się prawdziwą katastrofą.
<b>Ustalanie nierealistycznych terminów</b>
Podczas planowania nasz entuzjazm i zbyt duża wiara we własne siły mogą prowadzić na manowce. Krótki, optymistyczny termin może się stać niewykonalny. Zawsze rezerwujmy tyle czasu, by wszystkie cele mogły być zrealizowane, nawet jeśli wydają nam się z początku proste i w mig do wykonania. Zawsze lepiej jest przeszacować niż niedoszacować, a elastyczność jest często kluczem do sukcesu projektu.
Upewnijmy się, że określiliśmy potencjalne obszary ryzyka dużo wcześniej niż ustaliliśmy konkretne daty, zwłaszcza wtedy gdy współpracujemy z zewnętrznymi dostawcami i wykonawcami. Jeśli nasze oczekiwania będą wynikać z racjonalnych przesłanek, to nie będziemy zmuszeni do oddawania niekompletnego lub pełnego błędów rozwiązania
<b>Nierozumienie znaczenia skali</b>
Jesteśmy przekonani, że dobrze wdrożone rozwiązanie uwzględnia rozwój. Ale ryzyko, że w naszym systemie będą piętrzyć się ukryte problemy gdy biznes urośnie, i tak pozostaje duże. Każdy system jest odporny tak jak jego najsłabsze ogniwo. Każdy proces wymagający ręcznej interwencji będzie barierą dla procesów automatycznych wynikających z niego – i nie ma znaczenia, ile sprzętu w to zaangażujemy.
Oszczędzanie na zasobach to kolejny sposób na ból głowy w przyszłości. Nieważne jak sprytnym posunięciem wyda nam się dziś uruchomienie oddziałowej bazy danych na mało obciążonym obecnie serwerze webowym albo wykorzystanie stacji roboczej także w charakterze sieciowej pamięci masowej – nie róbmy tego! Dzisiaj mało znaczący projekt jutro może nabrać znaczenia krytycznego – a my będziemy musieli się pocić, rozdzielając procesy zrośnięte jak bliźniaki syjamskie.
<b>Nie chronienie ruchomej granicy naszej sieci</b>
Wzrost mobilności pracowników naszej firmy w połączeniu z prawdziwym wysypem urządzeń mobilnych i zatarciem granicy między urządzeniem prywatnym i służbowym (BYOD) – wszystko to sprawia, że dział IT jest teraz odpowiedzialny za zabezpieczanie systemów w sieciach, których nie kontroluje, oraz zabezpieczanie firmowej sieci z urządzeniami, których nie posiada.
W coraz bardziej rozproszonym środowisku IT zcentralizowane podejście do bezpieczeństwa sieci przestaje wystarczać. Dlatego powinniśmy być nieufni w stosunku do strategii zabezpieczania krytycznych zasobów i danych, która nie uwzględnia ruchomej granicy firmowej sieci.
<b>Skupianie się bardziej na kosztach niż na korzyściach</b>
TCO „rządzi”, w rezultacie mamy ograniczony dostęp użytkowników do sieci, eliminowanie szkoleń, instalowanie minimalnego zestawu oprogramowania. Nie ważne, że ograniczony dostęp do sieci tłumi innowacyjność, brak szkoleń obniża produktywność a minimum oprogramowania ogranicza efektywność biznesu. Ważne, że firma oszczędziła kilka złotych na budżecie IT.
Obcinanie funduszy na IT jest jak zrobienie klimatyzacji w pokoju w ten sposób, by chłodne powietrze dmuchało tylko na termostat. Wszyscy się pocą, ale ponieważ jedyny termometr w pokoju jest połączony z termostatem, to jego wskazania są w porządku.
A przecież zamiast na kosztach, należy skupić się na tym, co firma może zyskać, wydając więcej na IT.
Computerworld dostarcza najświeższe informacje, opinie, prognozy i analizy z branży IT w Polsce i na świecie.
W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]