SYSTEMY DEDYKOWANE Jak określić przedmiot zamówienia? Adam Rzeźnicki Application Management Services Program Manager 2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice
Systemy dedykowane jak określić przedmiot zamówienia? Agenda Wyzwania i problemy współczesnego IT a OPZ Systemy dedykowane Systemy dedykowane Co trzeba uwzględnić przy tworzeniu OPZ?
Wyzwania i problemy Wyzwania i problemy współczesnego IT a OPZ
Wyzwania IT zmienia biznes i podejście do zarządzania Wszystko jest ze sobą połączone Każdy oczekuje szybkich rezultatów Przedsiębiorstwo i IT w jednym Gotowości na ciągłe wyzwania i nowe możliwości W dowolnym miejscu, czasie oraz w dowolny sposób UPZP Rozdział 2, art.29, pkt.1 Przedmiot zamówienia opisuje się w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wszystkie wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. 4
Problemy IT stojące przed Zamawiającymi Nadmiarowość w portfelach aplikacji Złożoność portfela aplikacji Różnorodność technologii Starzenie się aplikacji Niekompatybil ność aplikacji Nieustanna presja na budżet IT w celu robienia więcej za mniej Niejasne TCO aplikacji Niezadowalające relacyjność pomiędzy wymaganiami biznesowymi i portfelem aplikacji Optymalizacja wykorzystania budżetu oprogramowania 5
Życie w przestarzałym środowisku Realia Aplikacje nie muszą znajdować się w środowisku mainframe by mogły być uznane za przestarzałe Dzisiaj każda aplikacja, która hamuje realizację stale zmieniających się wymagań może być uznana za przestarzałą Starsze aplikacje są znacznie bardziej odporne na zmiany i ewolucje, aby sprostać dzisiejszym potrzebom biznesu To działa. Dlaczego to zmieniać? Ryzyko Unikanie modernizacji przestarzałych aplikacji może spowodować utratę elastyczności, aby móc skutecznie konkurować z bardziej sprawnymi i adaptatywnymi systemami Pewnego dnia system przestanie działać i nikt nie będzie w stanie go naprawić Platforma stanie się nieaktualna i ostatecznie nie wspieralna bez wyraźnej ścieżki modernizacji
Modernizacja jest Wyzwaniem Dekady H Niepodatne na zmiany środowiska IT są kosztowne w utrzymaniu, trudne do zmiany, hamują produktywność, wzrost oraz innowacje Wydajność Rigid Widoczność Elastyczność Jakość Wydajność Szybkość many IT organizations are overly focused on what tactical step to take next and are missing the everworsening bigger picture with respect to IT modernization. Signs Indicate a Train Wreck Is Coming, Unless You Modernize IT, Gartner August, 2008 Sprawne Przedsiębiorstwo/Organizacja Uproszczone procesy biznesowe Zdolność absorbcji gwałtownego wzrostu Scentralizowane zarządzanie danymi Wysoko skalowalne i bezpieczne sieci Zapewnienie platformy integracyjnej Umiejętność odnowy/modernizacji aplikacji Umiejętność zarządzania programami i procesami IT L Elastyczność Biznesowa H
Wiele firm już rozpoczęło działania w tym kierunku 45% przedstawicieli wyższego kierownictwa twierdzi, że albo właśnie zakończyli, są w trakcie, albo planują projekty modernizacyjne IT. Zgodnie z danymi Forrester Research, 3 NAJWAŻNIEJSZE PRIORYTETY dla liderów IT to: MODERNIZACJA przestarzałych aplikacji; KONSOLIDACJA nadmiarowych aplikacji; UPGRADE starych pakietów aplikacyjnych. IT modernization: An exercise in alignment, Economist Intelligence Unit, September 2009 Application Modernization and Migration Trends in 2009/2010, Forrester, November 2009
SYSTEMY DEDYKOWANE Co trzeba uwzględnić przy tworzeniu OPZ?
Podejście do budowy/modernizacji systemu/aplikacji Wiele strategii modernizacji jest wymagane do określenia we właściwy sposób poziomu ryzyka, potencjalnych korzyści i priorytetów biznesowych każdego systemu/ aplikacji Cele, stan obecny, kontekst Strategie budowy/modernizacji Etapy Etap 1 - Ocena aplikacji/systemu Etap 2 - Zdefiniowanie ścieżki i planowanie Etap 3 - Realizacja przedsięwzięcia Etap 4 Ograniczenie ryzyka /tranzycja Etap 5 Osiągnięcie rezultatów i przejście do utrzymania Budowa/Modernizacja polega na zrozumieniu opcji i stworzeniu operacyjnie bezpiecznej ścieżki
Cele, stan obecny, kontekst Możliwe opcje Zachowanie istniejącego status quo Zachowanie jak największego zakresu podstawowej struktury aplikacji, a jeśli to nie jest możliwe migrowanie jej do tańszych platform i/lub o wyższej wydajności. Zrozumienie reguł i logiki biznesowej. Przedefiniowanie istniejących aplikacji jako usługi Zmiana Budowa nowych systemów, wymiana starych aplikacji na oprogramowanie klasy ERP, modernizacja aplikacji do SOA lub chmury Wycofanie Archiwizacja starych danych oraz aplikacji Cele Umożliwienie realizacji nowych wymagań biznesowych i zwiększenie przejrzystości mapowania procesów biznesowych na funkcjonalności aplikacji Zmniejszone wydatki na utrzymanie Skrócenie/optymalizacja czasu wdrożenia/modernizacji/wprowadzania zmian systemu Wyższa jakość i bezpieczeństwo Wyrównanie portfela aplikacji i stopnia ich kompatybilności Zmniejszenie zależności od przestarzałych technologii Zarchiwizowanie danych
Strategie modernizacji cz.1 Dokumentacja i szkolenia/relearn Proces, w ramach którego identyfikowane i dokumentowane są m.in. kwestie praw autorskich, logiki biznesowej, danych aplikacyjnych, relacji z innymi systemami/aplikacjami. Umożliwia zachowanie poniesionych inwestycji. Restrukturyzacja/Optymalizacja/Refactor Optymalizacja kodu w celu poprawy efektywności pracy aplikacji. Analiza starszych aplikacji mainframe, analizowanie wydajności kodu, zidentyfikowanie nieefektywnych segmentów kodu oraz wykonanie jego restrukturyzacji, opracowanie zaktualizowanego kodu za pomocą najlepszych praktyk i metodyk. Migracja/Rehost Migracja dotychczasowych aplikacji do tańszych nowoczesnych platform bez znaczących zmian w cechach i funkcjach biznesowych. Modernizacja/Zmiana interfejsów/reinterface Zmiana interfejsów dotychczasowych aplikacji poprzez tworzenie nowych, ekranowych interfejsów użytkowników oraz nie ekranowych interfejsów wykorzystanych do wymiany danych z innymi systemami/aplikacjami, a co za tym idzie zwiększenia zakresu wymiany danych, wydajności i możliwości aplikacji.
Strategie modernizacji cz.2 Przeprojektowanie/Re-architect Przeprojektowanie i przepisanie przestarzałych aplikacji w oparciu języki programowania wyższego poziomu, z uwzględnieniem zidentyfikowanych wymagań zarówno technicznych jak i biznesowych. Zastąpienie/Wymiana/Replace Spójne podejście do wymiany dotychczasowej aplikacji na gotowe standardowe oprogramowanie, branżowe standardy aplikacyjne lub nowo tworzone aplikacje. Wycofanie z eksploatacji/retire Wycofanie starszych aplikacji z portfela aplikacji. HP ocenia powiązania między wycofywanymi aplikacjami, a następnie zarządza ich zamknięciem w taki sposób, aby nie zakłócić działania przedsiębiorstwa.
Etap 1: Ocena środowiska informatycznego AKCJE Inwentaryzacja Określenie zasobów, procesów i ograniczeń Analiza Analiza pod kątem racjonalizacji/optymalizacji komponentów IT w kontekście celów/wymagań biznesowych Decyzja Opracowanie mapy drogowej WYNIKI Przejrzystość portfela aplikacyjnego Określenie prawdziwych rozmiarów aplikacji Identyfikacja zduplikowanego kodu Identyfikacja komponentów systemu(ów) i ich relacji Oparte na faktach raporty wspomagające podejmowanie decyzji i planowanie finansowe Mapa drogowa dla rozwoju systemu
Etap 2: Zdefiniowanie ścieżki budowy/modernizacji i planowanie Zdefiniowanie ścieżki i planowanie Ocena/weryfikacja Portfolio Aplikacji IT Określenie/weryfikacja strategicznych wartości/modułów/funkcji systemu/aplikacji Określenie/potwierdzenie możliwych opcji budowy/modernizacji aplikacji Functional Quality - Fulfillment (by process/ application) 2 0-2 -4-6 Wybór strategii budowy/modernizacji ARCH ARCH BOS BOS ITPS/ ICSS DMD Client MMB RCOM/ OMS Mainstreet SAF-T Scanner Scanner One Line Scanner DMD Client F&G DMD Client MMB Remittance Batchdrive KE3 NCSS QSP Sumasoft ICR DMD Client F&G Data Entry - Trailer Life Batchdrive BOS DMD Client MMB Sumasoft DMD Client F&G -8-10 Przedstawienie i zatwierdzenie ustaleń Zbudowanie przypadku biznesowego Opracowanie planu działań budowy/modernizacji General Ledger Replace Timeline Apps Modernization Assessment Period Year 1 Year 2 Year 3 Year 4 Year 5 Investment $50,000 $160,000 $40,000 $0 $0 Benefit $0 $70,000 $230,000 $70,000 $70,000 Net Benefit ($50,000) ($90,000) $190,000 $70,000 $70,000 Re-learn Re-factor Wave 1 $250,000 Confirm Re-interface (P1) Re-interface (P2) Re-learn(2) Replace (SAP) $200,000 Wave 2 Configure Test Configure Test Deploy $150,000 Data Conversion Benefit $100,000 Net Benefit Wave 3 Retire $50,000 Investment $0 ($50,000) ($100,000) Break Even Point Year 1 Year 2 Year 3 Year 4 Year 5 Program Office and Governance Jul 2007 Jan 2008 Jul 2008 Jan 2009 Jul 2009 Jan 2010 Jul 2010
Etap 3: Realizacja przedsięwzięcia Realizacja przedsięwzięcia Ustanowienie Projektu/Programu Budowy/Modernizacji Zdefiniowanie Architektury Aplikacji Modelowanie Architektury Biznesowej Transformacja/przekształcenie Procesów Biznesowych Modernizacja Applikacji Szczegółowy Plan Projektu Modernizacji
Etap 4 - Ograniczenie ryzyka / tranzycja Ograniczenie ryzyka / tranzycja Przygotowanie Planu przejścia Ograniczenie Ryzyka Operacyjnego Optymalizacja Zasobów Utrzymaniowych Przejście do Stanu Operacyjnego Zarządzanie Środowiskiem Uruchomienie Zmodernizowanych Aplikacji
Etap 5: Osiągnięcie rezultatów i przejście do utrzymania Utrzymanie/zarządzanie systemem/aplikacją Zdefiniowanie i wdrożenie modelu utrzymaniowego Definicja, wdrożenie i zarządzanie usługami utrzymaniowymi (ITIL), w szczególności zarządzanie poziomami usług Definicja i wdrożenie modelu w zakresie obszarów operacyjnych/administracji systemu Definicja, wdrożenie i zarządzanie procesami cyklu wytwarzania aplikacji i środowiskami pomocniczymi (np. deweloperskie, testowe, UAT, preprodukcja) Korelacja utrzymania z projektami transformacyjnymi Ciągłe ulepszanie jakości świadczonych usług
PODSUMOWANIE OPZ dla systemu dedykowanego co jest ważne? Cel budowy systemu: jakie istotne wymagania biznesowe i społeczne maja zostać spełnione; określenie kluczowych mierników sukcesu (KPI). Stan obecny: inwentaryzacja; Tasks analiza efektywności obecnego rozwiązania. Stan docelowy: określenie sposobu budowy/modernizacji oraz modelu eksploatacji i utrzymania systemu; mapa drogowa i plan zarządzania ryzykiem przedsięwzięcia. OPZ a kryteria oceny ofert W opisie przedmiotu zamówienia Zamawiający wskazuje swoje rzeczywiste potrzeby. Powinien przy tym stosować takie zasady opisu, które umożliwią każdemu wykonawcy złożenie oferty i będą zgodne z prawem. Zasady sporządzania opisu przedmiotu zamówienia zostały określone w art. 29-31 UPZP.
DZIĘKUJEMY ZA UWAGĘ