Trendy w informatyce: Trzy sposoby na zwiększenie innowacji informatycznych

Ron de Jong, dyrektor działu analiz i strategii informatycznej w Oracle

W poprzedniej części artykułu omówiliśmy zachowania, które blokują wprowadzanie innowacji w działach informatycznych. Dzisiaj zastanowimy się, jak można je zmienić. 
Nawet niewielka zmiana podejścia działu informatycznego do innowacji lub transformacji przedsiębiorstwa może pomóc firmie w konkurowaniu na skomplikowanym rynku. Poniżej prezentuję trzy strategie wprowadzenia tej zmiany.

1. Zachowaj otwartość na zmiany. Wspieranie skutecznych innowacji wymaga współpracy wszystkich działów przedsiębiorstwa. Dział informatyczny może przyczyniać się do sukcesu lub też go utrudniać. Dostosowanie się do zmian jeszcze nigdy nie było tak istotne. Produkty, usługi, firmy, a nawet całe branże pojawiają się i znikają w mgnieniu oka. Umiejętność dostosowania się do zmian to zdolność przedsiębiorstwa do rezygnacji z dotychczasowych kompetencji, procesów i technologii, które doprowadziły do sukcesu w przeszłości, na rzecz nowych kompetencji i metod, które zapewnią jej przyszły sukces. Firmy muszą być elastyczne, aby utrzymać się na rynku, i bardzo elastyczne, aby odnosić sukcesy.

2. Dopilnuj, by wkład IT był zgodny z potrzebami przedsiębiorstwa. Czy dział informatyczny przyczynia się do wyróżnienia się firmy na rynku lub obniżenia kosztów? Nie wystarczy samo wprowadzanie innowacji — muszą one jeszcze przynosić wymierne korzyści obecnym i nowym klientom. Celem jest zapewnianie im nowych doświadczeń, które pomogą firmie wyróżnić się na rynku i osiągać długoterminowe korzyści. Czy firma musi opracowywać takie funkcje wewnętrznie, czy są one dostępne na rynku? Tutaj właśnie do gry wkraczają możliwości zapewniane przez chmurę lub rozwiązania skonfigurowane fabrycznie. Aby zachować konkurencyjność, firmy muszą szybko i wydajnie tworzyć te łańcuchy wartości.

3. Pamiętaj, że dział IT nie może wspierać prawdziwych innowacji za pomocą tradycyjnych kompetencji. Problemy, z którymi obecnie mamy do czynienia, są znacznie bardziej złożone niż te, z którymi mierzyliśmy się w przeszłości, i wymagają znacznie szybszych reakcji. Często nie da się ich rozwiązać standardowymi metodami, bo wymagają kreatywności. Firmy osiągające największe sukcesy inwestują w zwiększenie innowacyjności całego przedsiębiorstwa. Poświęcają czas na integrację swoich procesów, pracowników i technologii nie tylko w celu przyspieszenia wprowadzania innowacji, lecz także zapewnienia, by właściwe innowacje były wprowadzane we właściwym czasie. Firmy te rok w rok wyprzedzają konkurencję, a działy informatyczne muszą za nimi nadążać — w przeciwnym wypadku grozi im odejście do lamusa.

Przeczytaj ten artykuł na stronach Oracle Profit Magazine

Jak stymulować innowacje w dziale informatycznym

Ron de Jong, dyrektor działu analiz i strategii informatycznej w Oracle

Innowacje jeszcze nigdy nie były tak potrzebne jak teraz. Firmy inwestują więcej pieniędzy w badania i rozwój niż kiedykolwiek wcześniej, jednak mimo to wielu dyrektorów odnotowuje niezadowalające wyniki. 
Dla większości z nich innowacje stanowią priorytet, ale badania działu analiz obejmujące strategicznych klientów pokazują, że dyrektorzy ds. informatycznych robią w tej dziedzinie bardzo niewiele.

Skoro więc tak wiele firm skupia się na wprowadzaniu innowacji jako strategicznej inicjatywie niezbędnej do przetrwania, dlaczego nie mamy do czynienia z większym zaangażowaniem działu informatycznego? Ze względu na rozwój informatyki można by się spodziewać, że świat zostanie zalany innowacjami, które przyspieszą działalność przedsiębiorstw. Obecnie dostrzegam jednak trzy zachowania, które blokują wprowadzanie innowacji w działach informatycznych.

1. Niesprecyzowane inwestycje w technologię z nadzieją na tworzenie innowacji. Firmy przeznaczają na ten cel dużo pieniędzy, spodziewając się odkrycia kamienia filozoficznego. Takie podejście generuje oczywiście najwyższe inwestycje początkowe i często prowadzi do najmniej przewidywalnych rezultatów. A co gorsza, jeśli inwestycje w technologię nie są skutecznie zintegrowane z kompleksowymi procesami, modelem świadczenia usług i usługami biznesowymi, ich wyniki mogą mieć ograniczoną lub nawet zerową wartość biznesową. Angażowanie się w sam proces innowacji bez połączenia go z innymi procesami to często popełniany błąd.

2. Mieszanie innowacji z inżynierią. W tradycyjnym dziale informatycznym kompetencje są z konieczności szczegółowe i specjalistyczne. Dział informatyczny musi znać komponenty infrastruktury, system operacyjny i bazy danych oraz interakcje pomiędzy konkretną wersją systemu operacyjnego a konkretną wersją bazy danych. W przypadku większości klientów analizowanych przez dział analiz tworzenie tych unikatowych połączeń sprzętu i oprogramowania ma bardzo mały wpływ na innowacyjność, a przewaga takich rozwiązań nad fabrycznie skonfigurowanym stosem rozwiązań jest znikoma lub nawet zerowa. Coraz więcej firm skłania się ku fabrycznie skonfigurowanemu stosowi, w którym wszystkie komponenty są w pełni zintegrowane i dopasowane do konkretnych potrzeb. Szefowie działów informatycznych powinni przygotować swój zespół inżynierów do czerpania korzyści z takich zintegrowanych rozwiązań i tworzenia innowacji za ich pomocą.
Doskonałym przykładem jest tu branża motoryzacyjna, w której duże fragmenty samochodów są oparte na gotowych częściach pochodzących od wyspecjalizowanych dostawców. Żaden producent samochodów nie produkuje wszystkich części samodzielnie. Innowacyjność polega na połączeniu ze sobą tych części w różnych modelach samochodów w taki sposób, aby zaspokoić potrzeby klienta.

3. Łączenie innowacji z obniżaniem kosztów. Ze względu na długi okres presji na oszczędności działy informatyczne obniżały koszty poprzez jak największą standaryzację. Jest to dobry sposób na redukcję kosztów, ale może hamować wprowadzanie innowacji. Znany model „wydajnej granicy” (efficient frontier) stworzony przez Michaela Portera sugeruje, że przedsiębiorstwa stosujące najlepsze procedury mogą wybrać poprawę jakości lub obniżanie kosztów, ale nie te dwie rzeczy naraz. Tak samo ma się sprawa ze zwiększaniem innowacyjności i obniżaniem kosztów: na ogół nie da się osiągnąć obu celów jednocześnie.

W kolejnej części niniejszego opracowania opowiemy, w jaki sposób można zmienić powyższe zachowania dla zwiększenia poziomu innowacji informatycznych. C.D.N.

Transformacja biznesowa pomaga utrzymać konkurencyjność – nowe badanie Oracle/Forbes

Oracle opublikował wyniki badania „Making the Change: Planning, Executing and Measuring a Successful Business Transformation” przeprowadzonego wspólnie z magazynem Forbes. 
W badaniu wzięło udział 534 przedstawicieli kadry zarządzającej dużych globalnych przedsiębiorstw.

Mimo że przeważająca większość respondentów (86%) stwierdziła, iż transformacja biznesowa jest niezbędna dla trwałego sukcesu, wiele przedsiębiorstw ma problemy z jej przeprowadzeniem. Jeden na pięciu uczestników badania był zdania, że w jego przedsiębiorstwie próby transformacji się nie powiodły, a trzech na pięciu respondentów nie podjęło jeszcze próby transformacji.

Niektóre wnioski z badania:
• 86% respondentów uważa, że ich przedsiębiorstwo powinno regularnie przeprowadzać transformację biznesową w celu zachowania konkurencyjności, czyli że w celu utrzymania się na rynku przedsiębiorstwo powinno wyprzedzać trendy branżowe. 
• 82% respondentów wskazało na potrzebę innowacyjności jako na istotny zewnętrzny czynnik stymulujący transformację biznesową.
• 39% respondentów stwierdziło, że brak umiejętności przewidywania zmian na rynku jest największym wyzwaniem w zakresie planowania, które zagraża sukcesowi ich transformacji biznesowej. 35% uznało natomiast, że błędna ocena czynników ryzyka lub brak umiejętności ich przewidzenia stanowi poważne zagrożenie dla przedsiębiorstwa. 
• 27% liderów transformacji biznesowej wykorzystuje metodyki i procesy EPPM (np. takie, jakie oferuje pakiet Oracle Primavera) w całej firmie, podczas gdy wśród ogółu respondentów współczynnik ten wynosi zaledwie 13%.
• 55% liderów transformacji wykorzystuje EPPM przynajmniej w swojej jednostce biznesowej, podczas gdy wśród ogółu respondentów współczynnik ten wynosi 38%.

Respondenci reprezentowali różne regiony: Amerykę Północną i Południową (37%), Europę, Bliski Wschód i Afrykę (29%) oraz Daleki Wschód (34%), jak również szeroki zakres branż, w tym usługi specjalistyczne (10%), bankowość i finanse (7%), branżę produkcyjną (13%), handel detaliczny (6%) i branżę inżynieryjną (6%).

Informacje dodatkowe
Oracle Primavera
Raport: Making the Change: Planning, Executing and Measuring a Successful Business Transformation

Wdrażać i szkolić

Marcin Jahn

Jeśli prowadzimy jakikolwiek projekt wdrożenia systemu IT, wówczas praktycznie zawsze istnieje potrzeba przeszkolenia zespołu użytkowników. 

Jest kilka kluczowych momentów, w których powinny być realizowane takie szkolenia – wymienimy je po kolei. 

• (1) Na początku wdrożenia: szkolenia powinny obejmować zespół wdrażający produkt oraz tzw. użytkowników kluczowych. Na tym etapie zespół poznaje istotne funkcje, możliwości i ograniczenia używanych narzędzi oraz otrzymuje praktyczne wskazówki, jak skutecznie wdrożyć rozwiązanie. Użytkownicy kluczowi modelują system, określają jego wygląd i akceptują końcowy jego wygląd.
• (2) Kolejny etap szkoleń w procesie wdrażania, to tzw. faza produkcyjna – w tym etapie najlepiej oraz najbardziej swobodnie mogą o projekcie wypowiadać się wdrożeniowcy – projektanci systemu.
• I wreszcie etap (3): postprodukcja – rozwiązanie działa, jest stabilne, zachodzi potrzeba doszkolenia nowych członków zespołu oraz użytkowników. Na tym etapie szkolenia mogą dotyczyć zarówno zespołu projektującego, jak i nowych użytkowników systemu. 

Przy konstruowaniu harmonogramu projektu, wydaje się rzeczą niezbędną zaprojektowanie powyższych trzech etapów z uwzględnieniem szkoleń zespołu i użytkowników kluczowych oraz końcowych. Warto zawczasu przeznaczyć na to budżet - biorąc pod uwagę zarówno wielkość zespołu, jak liczbę użytkowników systemu.

Kiedy i dla kogo szkolenia?

Zakres szkoleń jest determinowany rolą konkretnego członka zespołu – nie wszyscy z wszystkiego muszą być przeszkoleni. Nie ma sensu szkolić administratorów z użytkowania określonego narzędzia, jeśli mają się oni zajmować warstwą administracyjną. Podobnie z użytkownikami – zbędna jest im wiedza administratora, bowiem nie to będzie wchodzić w ich kompetencje. Wybór szkoleń i ich zakres powinien zostać ustalony przy udziale dostawcy szkoleń oraz project managera, prowadzącego wdrożenie danego rozwiązania. 

Ważna uwaga: nie powinno się rezygnować ze szkoleń po zakończeniu wdrożenia. Powoduje to swoistą „konserwację” systemu i użytkowników. Stan taki może być dobry przez zaledwie rok, może dwa. Nowe trendy wymuszą przeprojektowanie systemu – przeniesienie go do innego środowiska (np. cloud) – słowem przewartościowanie. Jeżeli więc zespół ma odpowiedzieć na to wyzwanie – musi zawczasu być do niego przygotowany. 
Dobrym pomysłem w tym zakresie jest stworzenie tzw. centrum kompetencyjnego. Centrum takie będzie projektować ścieżki rozwoju, czuwać nad umiejętnościami pracowników w zależności od powierzonej im roli. Być może korzystne będzie skatalogowanie szkoleń, utworzenie repozytorium projektowego, z którego mogliby swobodnie korzystać pracownicy. 

I ostatnia wskazówka: szkolenia powinny kończyć się certyfikacją. Certyfikowanie pozwoli zespołowi podnieść swoją rangę i jednocześnie określić poziom wiedzy, którym zespół dysponuje– tym samym określając jego kompetencje projektowe.

O autorze 
Marcin Jahn jest Dyrektorem sprzedaży szkoleń w Oracle University.

Oracle Unified Method

czyli metodyka prowadzenia projektów IT według Oracle
Remigiusz Wasilewski

Obecnie w projektach informatycznych najbardziej popularny jest tzw. model iteracyjno-przyrostowy. Polega on na tym, że projekt IT jest dzielony na ciąg iteracji z których każda kolejna kończy się dostarczeniem klientowi kolejnego, coraz bardziej szczegółowego projektu lub produktu, który spełnia w coraz większym zakresie wymagania klienta. Ogólnie metodyki te dzielą się na tzw. zwinne (Agile) i bardziej formalne – takie, jak „Rational Unified Process” rozwijana przez firmę IBM.

Oracle od pewnego czasu rozwija swoją własną metodykę Oracle Unified Method (OUM), która w sposób pragmatyczny łączy zalety metodyk zwinnych i formalnych. 

Podstawowe cechy OUM 
Najważniejsze cechy OUM, to ukierunkowanie na procesy biznesowe, iteracyjność i przyrostowość, zorientowanie na architekturę i na ryzyko, a także skalowalność i adaptowalność.
Jednakże najważniejszym wyróżnikiem metodyki OUM jest jej całościowe podejście do projektu. Zazwyczaj metodyki prowadzenia projektów IT koncentrują się jedynie na stronie implementacyjnej. OUM patrzy na projekt dużo bardziej holistycznie i wyróżnia 3 punkty widzenia. Pierwszym z nich jest
Wizja (Envision) – zawierająca takie aspekty jak analiza biznesowa przedsiębiorstwa, architektura korporacyjna, zarządzanie zmianą w organizacji oraz zarządzanie strategiczne.
Kolejnym aspektem jest Implementacja (Implementation). Podobnie jak to jest w innych metodykach z rodziny Unified Process, implementacja podzielona jest na fazy, a każda z nich kończy się tzw. kamieniem milowym. W ramach każdej z faz występuje jedna lub więcej iteracji. W trakcie każdej z faz realizowane są procesy takie jak np.: Wymagania biznesowe, Analiza, Projektowanie, Implementacja, czy Testowanie. Wyróżniającą cechą metodyki Oracle jest dodanie fazy produkcji, jako samodzielnego bytu uruchamianego po fazie wdrożenia.
Ostatni punkt widzenia, to Zarządzanie (Manage) - obejmuje zarówno proces zarządzania projektem jak i całym portfolio projektów.

Przebieg implementacji z podziałem na fazy i procesy

Standardy OUM
Siłą OUM jest bazowanie na powszechnie uznanych standardach. Daje to dużą uniwersalność i stabilność metodyki. Wśród standardów, na których opiera się OUM można znaleźć praktycznie wszystkie stosowane w branży, a więc:
· Unified Process (UP)
· Project Management Institute Body of Knowledge (PMI PMBOK)
· Business Analysis Body of Knowledge (IIBA BABOK)
· Unified Modeling Language (UML)
· Business Process Model and Notation (BPMN)
· Information Technology Infrastructure Library (ITIL)

Zastosowanie OUM w projektach IT
Oracle Unified Method dostarcza podczas prowadzenia projektu zalecany podział projektu na fazy i zadania, następnie definicję sposobu pracy w projekcie dla poszczególnych członków zespołu projektowego, szablony dokumentów i wreszcie zalecenia oraz instrukcje pracy w poszczególnych etapach projektu.
Zakres tematyczny projektów prowadzonych według OUM jest bardzo szeroki; mamy tu zarówno tworzenie aplikacji chmurowych, BI, czy aplikacji typu COTS, jak upgrade istniejącego oprogramowania, wdrożenie WebCenter, tworzenie „mapy drogowej” wdrażania technologii chmurowej, czy wdrożenie architektury korporacyjnej np. TOGAF.

Podsumowanie
W dzisiejszych czasach klientowi nie powinno wystarczać zapewnienie, że wykonawca będzie realizował projekt zgodnie z jakąś uniwersalną metodologią. Klient powinien wymagać od wykonawcy umiejętności prowadzenie projektu IT zgodnie z najlepszymi praktykami dla konkretnych typów projektów. Dodatkowo ważne jest, aby wszyscy wykonawcy prowadzili projekty w podobny sposób - najlepiej zgodnie z przyzwyczajeniami klienta.
W przekonaniu autora OUM ułatwia - zarówno wykonawcom jak i klientom - wspólne prowadzenie projektu zgodnie z najlepszymi praktykami, sprawdzonymi przez firmę Oracle na wielu różnorodnych projektach. Ważne jest to, że stosowanie metodyki OUM nie wiąże się z dodatkowymi opłatami ze strony klienta. Jedynym warunkiem wykorzystywania jej w projekcie jest to, by wykonawca miał odpowiednio wysoki poziom partnerstwa z Oracle (co najmniej Złoty) i rzecz jasna był przekonany, że stosowanie tej metodyki jest zgodne z jego kulturą pracy!

Informacje o autorze
Remigiusz Wasilewski jest certyfikowanym ekspertem Metodyki OUM, pracuje w firmie Proximus S.A.

Dowiedz się więcej
Oracle Unified Method (OUM)
Metodyka wdrożeń Aplikacji Oracle