Budowa celów architektury korporacyjnej IT dla środowisk zintegrowanych w sektorze publicznym
|
|
- Sabina Renata Gajewska
- 10 lat temu
- Przeglądów:
Transkrypt
1 Dr Jerzy Roszkowski 1 Marcin Cwajna 2 Budowa celów architektury korporacyjnej IT dla środowisk zintegrowanych w sektorze publicznym 1. Streszczenie W chwili obecnej sektor publiczny w naszym kraju zaczyna budować i wdraŝać u siebie architekturę korporacyjną. Przyczyną podjęcia działań w tym kierunku jest: DuŜy wzrost złoŝoności Zintegrowanych Środowisk na co składa się: wiele komponentów (systemów), złoŝone procesy. analiza komunikacji międzysystemowej stała się krytyczna. Wielu końcowych uŝytkowników (nowe role w organizacjach publicznych): Analityk Biznesowy, Architekt Rozwiązania, Architekt Edycji, Główni Architekci, brak moŝliwości dzielenia się wiedzą. Brak narzędzi do centralnego zarządzania architekturą aplikacji (równieŝ na rynku): wiele projektów i edycji systemów, wiele diagramów w projektach, brak zarządzania zmianą w prowadzeniu projektów. Brak formalnej specyfikacji zapisu architektury: wiele diagramów ale brak modeli architektury. Prezentowany artykuł przedstawia rezultaty niektórych prac badawczych podjętych przez autorów w kilku sektorach: publicznym i telekomunikacji w Polsce w zakresie architektury dotyczących: celów architektonicznych, w tym: określanie macierzy celów architektonicznych, określanie celów projektowych (ustalenie mierników celów), metodyki w tym: metodyki budowy architektury w zakresie. 2. Architektura korporacyjna w sektorze publicznym Przedstawiona tutaj koncepcja modelowania wymagań i architektury jest w pełni zgodna z TOGAF 3. Ze względu na obszerność tematu artykuł ogranicza się do zdefiniowania celów : biznesowych, architektonicznych i projektowych w sektorze telekomunikacyjnym. e projektowe ujęte są w postaci wymagań na metodykę projektowania architektury w tym sektorze. Artykuł powstał jako rezultat pracy badawczej dla sektora publicznego i 1 Management Systems Consulting, Łódź, Poznańska 28/1. jerzy.roszkowski@neostrada.pl 2 HomeCenter.pl, Bielsko-Biała, ul. Leszczyńska 29,. marcin.cwajna@homecenter.pl 3 TOGAF ang. The Open Group Architecture Framework szkielet dla architektury korporacyjnej, który zapewnia kompleksowe podejście do projektowania, planowania, implementacji oraz zarządzania informacyjną architekturą przedsiębiorstwa. Architektura jest modelowana typowo na czterech poziomach (domenach): Procesy biznesowe, Zastosowanie, Dane, Technologia. Grupa The Open Group udostępnia specyfikację TOGAF bezpłatnie dla organizacji do ich własnego, niekomercyjnego wykorzystania. 1
2 telekomunikacyjnego i jako rezultat realizowanych tamŝe przez autorów projektów i wdroŝeń w środowiskach zintegrowanych. 3. e architektoniczne W wyniku badań cele architektoniczne podzielono na grupy, w których wyodrębniono cele szczegółowe. Całość została przedstawiona na rysunku 1 przy pomocy modelu celów zgodnie z metodyką ARIS 4. PoniŜej w tabelach podano przyjęte definicje poszczególnych celów w grupach. A. Elastyczne środowisko IT Osiągnięcie wysokiej elastyczności jest celem złoŝonym wynikającym z moŝliwości konfiguracyjnych środowiska i "łatwości" developmentu. Elastyczność określa podatność środowiska na zmiany. W tej grupie wyróŝniono i zdefiniowano następujące podcele: Tabela 1- Grupa podcelów: elastyczne środowisko IT Symbol architektoniczny Opis Jak mierzyć? Wskaźnik* 100% dla linii lotniczych (przykład punkt 5.) A1 Wysoka konfigurowalność A1.1 Minimalna ilość miejsc konfiguracji dla danej klasy zagadnień A1.2 Wysoka liczba konfigurowalnych parametrów Konfigurowalność jest cechą środowiska/systemu określającą procent funkcjonalności, którą moŝna zmieniać w trybie konfiguracji wykorzystując do tego określoną ilość miejsc konfiguracji. em jest osiągnięcie wysokiej konfigurowalności. Osiągnięcie poŝą zmian konfiguracyjnych wymaga modyfikacji szeregu systemów poprzez wprowadzenie modyfikacji w jednym lub więcej miejscach. em jest ograniczenie miejsc wymagających konfiguracji do niezbędnego minimum. W szczególności parametry z danej klasy zagadnień powinny być konfigurowalne tylko raz, w wyniku czego byłby konfigurowalny jeden lub więcej system. Przeniesienie konfiguracji z miejsca konfiguracji do danego systemu powinno być automatyczne. Przykład: jeśli konfigurujemy produkt dokonujemy to tylko jeden raz w centralnym katalogu produktów w wyniku czego następuje konfiguracja n-systemów (CRM, Billing, EAI, OM, inne..) biorących udział w zamówieniach i obsłudze danego produktu. em jest osiągnięcie jak największej liczby parametrów konfigurowalnych. W pierwszej kolejności naleŝy dąŝyć do zapewnienia konfigurowalności dla parametrów najczęściej modyfikowanych i tych dla których koszt zmian developerskich jest wysoki. Wskaźnik konfigurowalności jest wektorem o postaci [STR,SKP] l -liczba klas zagadnień, klasy zadane listą; lista klas zagadnień STR = Stopień redundancji miejsc konfiguracji = Σ l liczba miejsc konfigurowalnych globalnie/liczba miejsc konfigurowalnych. em jest MIN(STR) SKP =Stopień konfigurowalności parametrów = liczba parametrów konfigurowalnych w wybranym obszarze/liczba wszystkich parametrów w tym samym obszarze 9,52 25% 4 ARIS - ang. Architecture of Integrated Information Systems, metodologia architektury i narzędzia rozwijane przez firmę IDS Scheer 2
3 Symbol architektoniczny Opis Jak mierzyć? Wskaźnik* 100% dla linii lotniczych (przykład punkt 5.) A2 A3 A4 Niska złoŝoność developmentu Automatyzacja testów Wystarczająca skalowalność procesów Inaczej "łatwy" development. em jest osiągnięcia stanu w którym realizacja pewnego zbioru wymagań biznesowych będzie miała minimalną złoŝoność (wyraŝoną np. w Function Points). Development - zmiany w systemach realizowanych w trybie prac rozwojowych (nie będących zmianami konfiguracyjnymi). em jest ułatwienie testowalności rozwiązania, umoŝliwienie przeprowadzenia większej liczby testów i wyeliminowanie tego czynnika jako ograniczenia/wąskiego gardła w rozwoju całego środowiska. Systemy realizujące procesy powinny mieć wydajność odpowiadające bieŝącym wymaganiom i być skalowalne zgodnie określonymi załoŝeniami. Iloraz liczby elementów architektury do liczby elementów architektury charakteryzujących się moŝliwością modyfikacji za pomocą prostego developmentu. Wskaźnik automatyzacji testów = liczba testów przeprowadzonych automatycznie/liczba wszystkich testów Iloraz liczby skalowalnych elementów architektury i liczby elementów w architekturze 23,81% 4,76% 80,95% B. Proste środowisko IT złoŝony grupujący cele określające cechy bądź stan środowiska w zakresie funkcjonalności, procesów, i komponentów systemowych. W tej grupie wyróŝniono i zdefiniowano następujące podcele: Tabela 2- Grupa podcelów: proste środowisko IT Symbol architektoniczny Opis Jak mierzyć? Wskaźnik* 100% dla linii lotniczych (przykład punkt 5.) B3 Odpowiednie pokrycie funkcji przez systemy B3.1 Minimalna redundancja funkcjonalności B3.2 Prawidłowa alokacja funkcjonalności em jest odpowiednia, zgodna z najlepszą wiedzą i załoŝeniami rozwoju środowiska alokacja funkcji do systemów. Redundancja funkcjonalności jest liczba powtórzeń uŝycia danego komponentu lub funkcji w zdefiniowanym obszarze przy realizacji tej samej funkcjonalności. Określona jest tylko dla funkcji, które mogą być obsługiwane w sposób globalny. Do alokacji funkcjonalności do systemów przyjmuje się Application Map (AM) jako referencje. Zatem prawidłowa alokacja oznacza zgodność z AM. Strategia architektoniczna moŝe stanowić inaczej i w takich przypadkach jest nadrzędna względem AM. Wektor postaci [WRF, WPA] WRF= Wskaźnik redundancji funkcjonalnej = łączna liczba funkcji/(σ (liczby powtórzeń dla wszystkich funkcji*miara krotności funkcji) WPA = Wskaźnik poprawności alokacji = funkcjonalność poprawnie zaalokowana do systemów/funkcjon alność zaalokowana do systemów 47,17% 52.00% 3
4 Symbol architektoniczny Opis Jak mierzyć? Wskaźnik* 100% dla linii lotniczych (przykład punkt 5.) B4 Optymalne procesy systemowe em jest optymalizacja w zakresie projektowania procesów systemowych - maksymalna automatyzacja, uniwersalność i odpowiednie (pod kątem czasu trwania, oczekiwania i wykorzystania zasobów) dobranie liczby kroków procesów systemowych. B4.1 Optymalna liczba kroków procesowych B4.2 Maksymalna automatyzacja B4.3 Wysoka uniwersalność zastosowania procesów B5 Właściwa jakość meta i Optymalizacja procesu polegająca na takim doborze i podziale kroków procesowych zapewniająca minimalny czas trwania, minimalny czas oczekiwania, maksymalne wykorzystanie zasobów em jest realizowanie funkcjonalności automatycznych, czyli bez uŝycia kroków manualnych (o ile wymagania biznesowe nie stanowią inaczej). em jest wdraŝanie rozwiązań zapewniających ponowne uŝywanie wdroŝonych procesów. Inaczej pisząc procesy powinny być generyczne z moŝliwością reuŝycia. Osiągana poprzez wdroŝenie procesu zarządzania danymi na którego składają się: -Zarządzanie danymi referencyjnymi -Standardy -Zarządzanie metadanymi -Jakość i certyfikacja - Zapewnienie właściwych -Bezpieczeństwo Określona jest wektorem: [Min(T w ), Min(T o ), Max( WWZ)], gdzie Min(Tw) - to minimalny łączny czas wykonania, Min(To) - to minimalny czas oczekiwania, Max(WWZ)- to wskaźnik wykorzystania przydzielonych zasobów WA= Współczynnik automatyzacji = liczba kroków wykonanych automatycznie / liczba wszystkich kroków. LPG = liczba procesów generycznych, SR = stopień reuŝycia procesów generycznych SR= Σ (krotności reuŝycia)*miara krotności reuŝycia/lpg Potrzebna definicja procesu generycznego [1260, 0.5, 40%] 47% 35% B5.1 Minimalna redundancja i meta Inaczej dublowanie się informacji Wskaźnik redundancji = WRD= liczba zdublowanych/ liczba wszystkich ; Wartośc wskaźnika WRD 9,00% 4
5 B5.2 Kompletność B5.3 Prawidłowa alokacja B5.4 Odpowiedni model konceptualny (spójność, zakres biznesowy) B6 Optymalny dobór sprzętu i technologii B6.1 Optymalny dobór sprzętu i licencji B6.2 Ujednolicenie technologii B7 Minimalizacja zaleŝności Definicja kompletności : 1.Opis kaŝdej danej powinien dać się skompletować do postaci informacji tj jest moŝe być przedstawiony w postaci czwórki piątki: (N, D, DD, JM, T), gdzie N- nazwa danej, D- definicja danej, DD - Dziedzina danej, JM - jednostka miary, T - czas. 2. Dane powinny zawierać wszystkie informacje niezbędne dla danego obszaru biznesowego 3.Dane spełniają wszystkie wymagane reguły biznesowe w przedmiotowym obszarze 4. Dane są wystarczająco dokładne i prawdziwe. Prawidłowa alokacja oznacza zgodnie z modelem funkcjonalnym w sektorze (np. w Telekomach : modele etom i TAM) o ile strategie nie mówią inaczej. em jest wdraŝanie rozwiązań zapewniających odpowiednie, zgodne z długoterminowymi załoŝeniami dla środowiska zapewnienie masterowości oraz procesów dystrybucji tych. 1.em jest zapewnienie takiego modelu który będzie zawierał dane spójne (spełnienie co 3 reguł normalizacji Codd'a). 2. Zakres biznesowy i granulacja taka jaką wymagają funkcje realizowane przez system. em jest wybór komponentów optymalnych kosztowo w zakresie wdroŝenia i utrzymania. Optymalny dobór oznacza równieŝ niską awaryjność. em jest wybór komponentów optymalnych kosztowo w zakresie wdroŝenia i utrzymania. Optymalny dobór oznacza równieŝ niską awaryjność. em jest ujednolicenie technologii w zakresie sprzętu i software. em jest minimalizacja zaleŝności. Minimalizacja zaleŝności ma prowadzić do zmniejeszenie ilości relacji w środowisku tylko do niezbędnych. dla maksimum funkcji WP=WP(WRD), gdzie WP - wydajność przetwarzania Wskaźnik niekompletności = liczba niekompletnych/licz ba wszystkich PAD= Liczba grup prawidłowo zaalokowanych w Hurtowni Danych lub w systemach architektury/liczba grup w elementach architektury OMK=Liczba grup w architekturze spełniających 3 reg. Codda/liczba wszystkich grup ODS= Przeciętna liczba nieuszkodzonych elementów arch. technicznej w ciągu 1 roku/liczba elementów architektury techn. UT= liczba spójnych technologicznie rozwiązań El. Architektury/ ogólna liczba El. architektury 0,50% 99% 100% 99% 80% Niska 5
6 architektoniczny A1.1 Minimalna ilość miejsc konfiguracji dla danej klasy zagadnień A1.2 Wysoka liczba konfigurowalnych parametrów BC5.1.3 B5.2 B5.3 B5.1.4 A1 A Elastyczne środowisko Wysoka konfigurowalność A2 Niska złoŝoność developmentu A3 Automatyzacja testów Minimalna redundancja meta Wysoka jakość Prawidłowa alokacja Odpowiedni model konceptualny B5 Właściwa jakość i meta B Proste środowisko B3 Odpowiednie pokrycie funkcji przez systemy B4 Optymalne procesy systemowe B6 Optymalny dobór sprzętu i technologii B7 Optymalne komponenty systemowe B3.1 Minimalna redundancja funkcjonalności B3.2 Prawidłowa allokacja funkcjonalności Optymalna liczba kroków procesowych B4.1 Maksymalna automatyzacja B4.2 Wysoka uniwesalność zast. B4.3 procesów Wystarczająca skalowalność procesów Optymalny dobór sprzętu i licencji Ujednolicenie technologii C Niezawodne środowisko B4.4 B6.1 B6.2 ReuŜycie komponentów B7.1 C1 Wysoka dostępność C2 Niska liczba błędów Niska liczba awarii C1.1 Krótki czas C1.2 niedostępności planowej Niska liczba błędów w środowisku testowym Niska liczba błedów w środowisku produkcyjnym D Minimalizacja ryzyka C2.1 C2.2 D1 Gotowość na nieprzewidziane zdarzenia D2 Unikanie katastrof architektonicznych E Efekywne środowisko E1 Niska pracochłonność zmian w środowisku E2 Niskie koszty utrzmania elementarny F Kompletne środowisko F1 Gotowość na projekty z roadmapy F2 Dostosowanie do moŝliwości organizacji F3 Uwzglednienie ograniczeń prawnych technicznych i pozostałych Czynnik sukcesu Minimalizacja zaleŝności B7.2 Rys 1. Model celów architektonicznych w środowisku zintegrowanym architektury korporacyjnej IT. Źródło: opracowanie własne. 6
7 C. Niezawodne środowisko IT em jest osiągnięcie stanu, w którym środowisko wspiera procesy biznesowe zgodnie z załoŝoną dostępnością i bezbłędnie. Jednocześnie powinien być zapewniony dostateczny poziom bezpieczeństwa ciągłości rozwoju i utrzymania. W tej grupie wyróŝniono i zdefiniowano następujące podcele: Tabela 3- Grupa podcelów: niezawodne środowisko IT Sym bol architektoniczny Opis Jak mierzyć? C1 Wysoka dostępność Dostępność oznacza zdolność do realizacji procesów biznesowych. em jest osiągnięcie wysokiej dostępności i co z tego wynika unikanie wszelkich zdarzeń mających na dostępność wpływ negatywny. Dotyczy to zarówno zdarzeń nieplanowanych (awarii) i planowanych (wyłączenie w trakcie wdroŝenia). Niska awaryjność em minimalizacja liczby i skutków awarii. liczba, skutki awarii Definicja awarii i skutek awarii C1.1 C1.2 Krótki czas niedostępności planowej C2 em jest skrócenie czasu wyłączenia środowiska/komponentu środowiska w trakcie wdraŝania funkcjonalności na produkcję. Niska liczba błędów em jest jak najniŝsza liczba powaŝnych błędów. Błędy nie są traktowane tak samo, większa waga przypisywana jest do błędów krytycznych, mniejsza do niekrytycznych. Nie kaŝdy błąd musi powodować awarię czy zmniejszenie dostępności, ale kaŝdy ma wpływ na koszty i czas TTM. C2.1 Niska liczba błędów na środowisku testowym C2.2 Niska ilość błędów na środowisku produkcyjnym em jest jak najniŝsza liczba błędów na środowisku testowym. Znaczenie ma waga błędu. em jest jak najniŝsza liczba błędów na środowisku produkcyjnym. Znaczenie ma waga błędu. Wskaźnik* 100% dla linii lotniczych (przykład punkt 5.) 23 awarie w skali roku. Awaria = ITIL incydent Wskaźnik dostępności = czas niedostępności w trakcie wdroŝeń/całkowity czas pracy 1% WB=WBT+WBP gdzie WB - współczynnik liczby błędów WBT=Współczynn ik waŝony liczby błędów TESTOWANIA= Σ w i /LB, gdzie LB ogólna liczba błedów, w i = 1 dla błędu gdzie krytycznego w i = 1/2 dla błędu niekrytycznego, i wskaźnik błędu WBP=Współczynn ik waŝony liczby błędów produkcyjnych= Σ w i /LB, gdzie LB ogólna liczba błedów, w i = 1 dla błędu gdzie krytycznego w i = 1/2 dla błędu niekrytycznego, i wskaźnik błędu poniŝej 2,00% poniŝej 0,01% 7
8 D. Minimalizacja ryzyka em jest minimalizacja ryzyka. W tej grupie wyróŝniono i zdefiniowano następujące podcele: Tabela 4 - Grupa podcelów: minimalizacja ryzyka Sym bol architektoniczny Opis Jak mierzyć? Wskaźnik* 100% dla linii lotniczych (przykład punkt 5.) D1 D2 Gotowość na nieprzewidziane zdarzenia Unikanie "Katastrof architektonicznych" Rozwój architektury powinien być prowadzony w taki sposób Ŝeby oprócz sprawnej i efektywnej realizacji bezpośrednich zadań biznesowych i konkretnych projektów z roadmapy środowisko IT było przygotowane na zdarzenia nieprzewidziane. Przykład takiego zdarzenia: połączenie z nowym operatorem. MoŜe to oznaczać odpowiednią dekompozycje funkcjonalności, zachowanie odpowiedniej elastyczności procesów, czy inne cechy środowiska nie ujęte pozostałymi celami architektonicznymi. Katastrofa architektoniczna to naturalny rozwój systemu w czasie którego popełniono błąd prowadzący do braku moŝliwości dalszego rozwoju systemu/architektury (np. przypadek starego OV). Wynikiem takiego zdarzenia moŝe być powołanie projektu, którego jedynym bądź głównym celem będzie zapewnienie ciągłości biznesowej. em jest unikanie takich katastrof. niemierzalne - konieczne określenie miary Prawdopodobieństw o kata strofy = Sumaryczna pracochłonność projektów, które nie dają wartości dodanej dla biznesu/łączna pracochłonność wszystkich projektów Na podstawie doświadczeń przy incydentach (niezidentyfi kowanych awariach) - maksymalny czas odtworzenia do działania produkcyjne go nie przekroczył 3 godz 0,80% E. Efektywne środowisko IT em jest osiąganie wymagań biznesowych przy minimalizacji całościowego kosztu związanego ze środowiskiem wspierającym/realizującym te wymagania. Na koszt ten składa się koszt wdroŝenia i utrzymania. W tej grupie wyróŝniono i zdefiniowano następujące podcele: Tabela 5 - Grupa podcelów: efektywne środowisko Sym bol architektoniczny Opis Jak mierzyć? Wskaźnik* 100% dla linii lotniczych (przykład punkt 5.) E1 Niska pracochłonność zmian deweloperskich w środowisku em jest osiągnięcie stanu w którym koszt realizacji zmian deweloperskich (o określonej złoŝoności) jest minimalny. WSP = Wartość prac developerskich ( w zakresie niezbędnych zmian wynikających ze zmian w strategii lub uwarunkowań biznesowych/wartość wszystkich prac 47,92% 8
9 developerskich E2 Niskie koszty utrzymania em jest osiągnięcie niskiego kosztu utrzymania środowiska. koszty utrzymania na jednostkę funkcjonalności 3840 PLN F. Kompletne środowisko IT Kompletność środowiska określa stopień i gotowość do realizacji wymagań. Wymaganiami są bezpośrednie wymagania zgłaszane w projektach, roadmapa projeków, moŝliwości organizacji i ograniczenia. em jest stworzenie środowiska umoŝliwiającego kompletną realizacje wymagań. Unikamy sytuacji w której ograniczenia środowiska uniemoŝliwiają realizacje niektórych wymagań. W tej grupie wyróŝniono i zdefiniowano następujące podcele: Tabela 6 - Grupa podcelów: kompletne środowisko IT Sym bol architektoniczny Opis Jak mierzyć? Wskaźnik* 100% dla linii lotniczych (przykład punkt 5.) F1 F2 F3 Gotowość na projekty z roadmapy Dostosowanie do moŝliwości organizacji Uwzględnienie ograniczeń prawnych, technicznych i pozostałych em jest dąŝenie do takiej postaci środowiska, która umoŝliwia i ułatwia (w rozumieniu kosztów i czasu rozwoju), w chwili obecnej i w przyszłości, wdraŝanie kolejnych zmian, przewidzianych w roadmapie projektów. MoŜliwości organizacji, które nie mogą być w skończonym czasie zmodyfikowane powinny być brane pod uwagę jako sztywne ograniczenia dla projektów wpływających na architekturę. Spełnienie tego ograniczenia staje się więc jednym z celów architektonicznych, podobnym do spełnienia wymagań biznesowych. em jest uwzględnienie ograniczeń mogących wpływać na środowisko. W szczególności naleŝy wziąć pod uwagę ograniczenia prawne i techniczne. GPR= Liczba projektów w Roadmaoie które mogą być wykonane bez modyfikacji architektury/ liczba wszystkich projektów z Roadmapy OP= Liczba elementów architektury, które w przypadku zmiany otoczenia prawnego, technicznego nie spowoduje konieczności modyfikacji architektury/ogólna liczba elementów architektury 80% gotowości Na poziomie 80% 4. e architektoniczne w zakresie w sektorze publicznym Budowa architektury jest ściśle związana z celami architektonicznymi w tym zakresie i wymaganiami jakie ma ona spełniać w środowisku. PoniŜej na rysunku przedstawiono diagram celów architektonicznych w zakresie (wg standardu Aris). Ze względu na wieloaspektowość dekompozycji celów dekompozycja ta nie moŝe być wszędzie 9
10 rozłączna. e szczegółowe które występują kilkakrotnie w drzewie nazwano celami wspólnymi (common goals). e architektoniczne w zakresie są jednym z aspektów wymagań na proste środowisko. Kompletność i jakość umoŝliwia posługiwanie się nimi w przetwarzaniu, natomiast zapewnienie interoperacyjności związane jest z budową złoŝonych komunikatów jednoznacznie zrozumiałych przez nadawcę (system wytwarzający) i odbiorcę (system odbierający). B5.1.1 Właściwa masterowość Właściwe procesy dystrybucji Właściwa integralność B5.1.2 Prawidłowa alokacja BC5.1.3 Minimalna redundancja meta B5.1 Właściwa jakość /meta w zakresie musi spełniać B Proste środowisko B5.2 Kompletność B5.1.4 Odpowiedni model konceptualny B5.3 Interoperacyjność informacyjna BC5.1.5 Wymagalna spójność Rys.2. e architektoniczne w zakresie.source: author's study 5. Wymagania w zakresie modelowania Na poniŝszym rysunku przedstawiono wymagania na model konceptualny Wymagalna granulacja (inaczej ziarnistość ) oznacza wymaganą powtarzalną długość okresu czasowego w którym dane są gromadzone Odpowiedni zakres biznesowy - oznacza zakres modelu powinien obejmować zakres biznesowy niezbędny dla realizacji celu biznesowego. Zgodność ze standardami i wzorcami oznacza zgodność z UML (diagram klas, oraz normalizację do 3 formy normalnej Codd a). 10
11 B5.1.4 Odpowiedni model konceptualny musi spełniać warunki Minimalna redundancja meta Wymagalna spójność Wymagalna granulacja Odpowiedni zakres biznesowy Zgodność ze standardami i wzorcami BC5.1.3 BC5.1.5 B B B Rys 3. Wymagania na modele. Źródło: opracowanie własne. 6. Przykład i ocena architektury IT dla jednostki sektora publicznego PoniŜej na przykładzie architektury IT linii lotniczych (jednoosobowa spółka skarbu państwa) pokazano jak wykaz celów i mierników podany w punkcie 3 moŝe posłuŝyć do oceny tej architektury w tym do określenia jej mocnych i słabych punktów oraz wskazania kierunków dalszego rozwoju Ogólny opis architektury IT linii lotniczej Głównym elementem architektury jest System Rezerwacyjny NAV, w którym zaszyte są główne części procesu sprzedaŝowego. Klienci rezerwują, odwołują rejsy. Wokół systemu NAV została zbudowana hurtownia, która przetwarza dane z systemu NAV i tymi danymi zasila zarówno inne systemy, jak i bezpośrednio, przy uŝyciu komponentów Business Objects udostępnia przetworzone dane uŝytkownikom (szczególnie dotyczy to finansów). Dane do hurtowni są generowane codziennie przez System rezerwacyjny na konto FTP z którego moduł BulkLoadMapper ładuje dane do Bazy. Moduł ten słuŝy takŝe do kontroli poprawności jak i do kontroli integracji (sprawdzanie powtórzeń i kontynuacji ). System navitaire, jest zasilany danymi z potwierdzeń płatności oraz z modułu słuŝącego do administracyjnego anulowania rejsów. Wokół hurtowni osadzone są systemy (komponenty), które na podstawie z systemu rezerwacyjnego umoŝliwiają: Rozliczenia Agentów, którzy sprzedają rejsy firmy Moduł Call Center, który zasilany jest danymi do IVR Moduł, który umoŝliwia rozliczenia personelu pokładowego Raporty dla Finansów i Księgowości (takŝe VAT) Raporty sprzedaŝowe 11
12 Revenue Management Moduł raportowy (takŝe do wysyłania SMSów) Aby w ramach powyŝszych modułów zapewnić poprawność i łatwą ich interpretację, dodatkowo Hurtownia jest ładowana Kursami Walut, Informacjami z wpływów na rachunki Bankowe (co z resztą z jednej strony jest podstawą do obliczania Cash Flow a z drugiej strony po przetworzeniu zasila system rezerwacyjny w drugą stronę zmieniając statusy rezerwacji), informacjami z usług płatności (np. w hipermarketach) jak BillBird czy Bibit (płatności kartami). Dodatkowo, dane z systemu rezerwacyjnego po przetworzeniu zasilają firmę ubezpieczeniową, a moduł konfiguracyjny umoŝliwia stosowną parametryzację rozliczeń pomiędzy linią lotniczą a dostawcą produktu ubezpieczeniowego. Hurtownia zasilana jest takŝe danymi z modułu Netline Crew (w którym są zawarte informacje o personelu pokładowym i godzinach wylatanych w ramach rejsów) Zestawienie komponentów architektury IT linii lotniczej PoniŜej w tabeli 7 przedstawiono wykaz komponentów architektury IT linii lotniczej uzupełniający opis przedstawiony w punkcie 6.1. Tabela 7 Wykaz komponentów architektury przedstawionej na rysunku 4 Lp Component Opis elementu Relacja 1. System Główny system, które dane są podstawą Rezerwacyjny systemów informatycznych w firmie Navitaire(1) 2 BulkLoadMapper (2) Komponent, który zasila hurtownie. 3. Potwierdzenia płatności do NAV (3) Moduły, pobierające dane z usług płatności. 4 Bibit (4) Komponent, który zasila NAV potwierdzeniami obciąŝania Kart Kredytowych 5 BillBird (5) Pobiera dane z systemu BillBird i zasila transakcjami hurtownię. Następnie moduł potwierdzeń płatności zasila NAV. 6 Ubezpieczenia (6) Zasilany przetworzonymi transakcjami z systemu rezerwacyjnego moduł, pozwalający na obliczenie naleŝnych Komponent zasila hurtownię oraz jest zasilany potwierdzeniami płatności (bibit, billbird), oraz anulacjami rejsów Zasila hurtownię danymi w formacie XML generowanymi automatycznie z systemu rezerwacyjnego Zasila NAV zmieniając statusy rezerwacji na zapłacone Interfejs: Weryfikacja w NAV płatności i klientów, ładowanie hurtowni transakcjami Billbird zasila hurtownię transakcjami Zasila firmę ubezpieczeniową danymi do rozliczeń ubezpieczalni kwot. 7 SMS Gates (7) Moduł wysyłający SMSy Zasilany jest przez moduł SMS.jar, który pobiera dane z modułu raportowego (róŝne rapory) 8 BanTransactions (8) Moduł, zasilający hurtownię transakcjami płatności za rezerwacje w formie przelewu. 9 FK (9) System Finansowo-Księgowy Zasilany jest z hurtowni danymi finansowymi i rejestrami VAT 10 Revenue Zasila hurtownię Management (10) System pozwalający na zarządzanie wpływami, pozwalający na modyfikację taryf po wnioskowaniu na konkurencji 11 Helpdesk (11) Moduł do obsługi zgłoszeń, powiązany jest z modułem raportowym i modułem nadawania uprawnień jak i workflow. 12 Agents (12) Moduł do obliczania zarobków Agentów. Wysyłający cyklicznie raporty generowane Zasila hurtownię z formatu MT940 (konwerter) NiezaleŜny pod względem, obudowany modułem raportowym i modułem nadawania uprawnień jak i workflow. Zasilany z systemu NAV i bazy parametryzującej wewnętrznej. 12
13 na podstawie umów z Agentami (3000 agentów w Polsce i zagranicą) 13 Kadry (13) System Kadry płace umoŝliwiający obsługę (pisma, urlopy delegacje itp.) i drukowanie rozliczeń, PIT itp. Zasilany przez moduł raportowy obliczający wynagrodzenia personelu na przykładzie lotów (Netline Crew) oraz Systemu rezerwacyjnego. 14 Ntline Crew(14) System operacyjny dla załóg lotów Zasila hurtownię 15 Obieg dok. kosztowych (15) System umoŝliwiający kwalifikację kosztów w obszary działania spółki oraz księgujący na odpowiednie konta koszty Zasilany przez uŝytkowników (koszty, plany kont obszary), wykorzystujący moduł raportowy i nadawania uprawnień, ładujący system FK. 16 NBP (16) Kursy Walut (dzienne) Moduł zasila hurtownię (wszystkie dostępne kursy walut) 17 IVR (17) Moduł zasilający usługę IVR w Call Center Pobiera dane z systemu Rezerwacyjnego za pośrednictwem modułu raportowego hurtowni. 18 Call Center Moduł zasilający Call Center w dane pominięte w systemie rezerwacyjnym (np. reklamacje) Moduł ładujący dane z systemu NAV do Call Center. 13
14 cmp Components HTTP HTTP Konkurencja BillBird (5) BillBird File format SFTP-port Ubezpieczenia (6) SFTP-port CSV Format SMS Gates (7) ODBC-ORACLE port JDBC Port Oracle ODBC SMS.jar MSSQL ODBC Bank Transactions (8) HTTPS-Port MT940 on HTTPS FK (9) MSSQL DB Port MSSQL DB PORT Revenue Management (10) MySQL Port ODBC for MySQL ODBC for MySQL Revenue Mapper.NET MSSQL DB Port Helpdesk (11) Agents (12) HTTP-WebApplication HTTPS SMTP-Port MSSQL Server Data WebApp on HTTPS Kadry (13) MS SQL Server MS SQL Server Data Netline Crew (14) SFTP-Port XML Files JDBC for MSSQL Server MS SQL Se rver Data Pła tności Ubezpie czenia SMS M odule Ba nk Transactions FK Rev enue Management Database Warehouse Helpdesk Rozliczenia agentów Kadry Netline Crew For Agents App CallCenter Bibit Potwierdze nia płatności do NAV SFTP-port SFTP-port CallCenterData Webservices on HTTPS CSV Format XML File Format SFTP-Port BulLoadDB BulkLoad Text File format CurrencyValue File MSSQL Data Wszystkie aplikacje działały na Warstwie MSSQL SERVER..NET słuŝył jedynie do prezentacji i wprowadzania. Wszelkie obliczenia w procedurach wbudowanych MS SQL SERVER CallCenter (18) GetCCData SFTP-Port Potwierdzenia płatności do NAV (3) BulkLoadMapper (2) SFTP-port Import X ML data IVR (17) SFTP-port NBP (16) SFTP-Port SQL Intranet.NET Application + MS SQL SERVER Stored Procedures Raporty FK, Navitaire, Statystyczne Obieg dokument ów kosztowych (15) Helpdesk Bibit (4) SFTP-port Navitaire (1) Rozliczenia Agnetów IIS Web Server Wynagrodzenia personelu pokładowego Rys 4. Przykładowa architektura środowiska zintegrowanego IT linii lotniczych (jednoosobowa spółka skarbu państwa). Źródło: opracowanie własne. 14
15 6.2. e biznesowe PoniŜsza tabela przedstawia najwaŝniejsze cele biznesowe stawiane przed środowiskiem IT Tabela 8 Strategiczne cele biznesowe środowiska IT linii lotniczej ID biznesowy 1 Osiągnięcie odpowiedniej pozycji (dla klientów z Polski) rynku lotniczego typu LOW COST (konkurencja to WIZZAir, RyanAir, Norwegian, Na niektórych kierunkach Lutfhansa). 2 Osiągnięcie cen, które spowodują wzrost sprzedaŝy. 3 ZrównowaŜenie realizacji oraz sprzedaŝy pomiędzy sezonami LATO-ZIMA. 4 Rezygnacja z głównych lotnisk (migracja na lotniska małe, podmiejskie). Ewentualne zmiany (dodanie nowych, rezygnacja z obecnych) celów biznesowych będą miały wpływ na cele architektoniczne a to moŝe powodować zmianę architektury docelowej lub połoŝyć nacisk na inne aspekty w ramach obecnej architektury Mapowanie niektórych celów biznesowych na niektóre cele architektoniczne Tabela przedstawia stopień wpływu realizacji celu architektonicznego na osiągnięcie danego celu biznesowego (X wpływ duŝy, x wpływ mały). Przykład interpretacji: Osiągnięcie celów architektonicznych [A], [C], [E] będzie miało pozytywny wpływ na realizacje celu biznesowego [1]. Tabela 9 Mapowanie celów biznesowych na cele architektoniczne dla linii lotniczych. e biznesowe e architektoniczne Wysoka konfigurowalność Osiągnięcie odpowiedniej pozycji (dla klientów z Polski) rynku lotniczego typu LOW COST Osiągnięcie cen, które spowodują wzrost sprzedaŝy ZrównowaŜ -enie realizacji oraz sprzedaŝy pomiędzy sezonami LATO- ZIMA Rezygnacja z głównych lotnisk (migracja na lotniska małe, podmiejskie) [1] [2] [3] [4] [A] X X X Proste środowisko IT [B] x X Niezawodne środowisko IT [C] Minimalizacja ryzyka [D] X Efektywne środowisko IT Kompletne środowisko IT x [E] X X [F] x x 15
16 6.4. Ocena architektury środowiska zintegrowanego IT linii lotniczych PoniŜej pokazano wykres radarowy wyliczonych mierników ( po w ostatniej kolumnie tabel od 1- do 7 dla architektury IT linii lotniczych. Rys.5. Wykres radarowy wartości mierników architektury dla architektury IT linii lotniczych. W rysunku powyŝszym dla wskaźników (nx) B5.1 B5.2, C1.1, C1.2, C2.1, C2.2, D2 oraz E1, zostały odwrócone wskaźniki, do postaci 100%-nx% aby uzyskać stan wskaźnika 100% obrazującego najlepsze moŝliwe rozwiązanie architektoniczne. W zakresie mierników typu A oraz E (niezbędna jest wspólna interpretacja) (tj. konfigurowalności architektury) wyraźnie widać, iŝ jest to słaby jej punkt. Miernik pokazuje, Ŝe w przypadku pojawienia się nowych potrzeb biznesowych, zmiany będą czasochłonne i wymagana będzie ingerencja zarówno programistyczna o duŝym stopniu złoŝoności. Dalej naleŝy wyciągnąć wniosek, iŝ pociągnie to za sobą wielowarstwowe zmiany, które wymagać będą testów integracyjnych. Jest to słaby element architektury. Na wykresie widzimy, Ŝe architektura daje na ponad 80% moŝliwość wyskalowania procesów, jednak duŝym kosztem. Mierniki typu B (odpowiednie pokrycie funkcji przez systemy oraz redundancja ) wskazują na wyŝszą niŝ przeciętną koncepcję rozwiązania (oscylacja w okolicy 70%). Optymalizacja powinna polegać na przeanalizowaniu procesów biznesowych i ich optymalizacji tym nie mniej spełnia ona załoŝenia. Z tego miernika moŝe wynikać, iŝ architektura podczas procesu projektowania nie uwzględniała wszystkich celów biznesowych i część z niej powstało ad-hoc. Dodatkowo, naleŝy takŝe wyciągnąć wniosek, iŝ hurtownia i jej redundancja została zaprojektowana wzorcowo. 16
17 Mierniki typu C oraz D. Tu zdecydowanie widać mocno przemyślaną koncepcję, która duŝy nacisk (98%) kieruje na poziom dostępności, niezawodności środowiska oraz jego wydajność. W tym zakresie architektura jest wzorcowa. Miernik F pokazuje, Ŝe architektura ponadprzeciętnie jest przygotowana na nowe projekty i Ŝe z punktu widzenia i ich redundancji, łatwe będzie zarówno pokrycie funkcjonalne jak i ew. rozwój. Ogólnie, moŝna postawić tezę, Ŝe architektura jest przygotowana ponadprzeciętnie 67,66% (zakładając przeciętność architektury na poziomie osiągnięcia średniego wskaźnika = 30% - dla większości niedojrzałych architektur korporacyjnych) i została przygotowana przez zespół projektantów stawiających nacisk bardziej na SLA, czy teŝ dostępność systemu oraz przez specjalistów od integracji i hurtowni. 7. Podsumowanie Definiowanie celów architektonicznych i biznesowych jest podstawowym i pierwszym krokiem w budowaniu architektury korporacyjnej. W TOGAF ADM jest ustalane to w kroku "architecture vision. W pracy przedstawiono wyniki badań w tym zakresie przeprowadzonych przez autorów w kilku sektorach: telekomunikacyjnym, publicznym. e architektoniczne mogą posłuŝyć do oceny aktualnego stany architektury IT i wytyczenia jej kierunków rozwoju. W artykule pokazano przykładową skróconą ocenę (ze względu na dopuszczalną objętość pracy) architektury IT linii lotniczych. Kolejnym krokiem po zdefiniowaniu celów architektonicznych jest budowa repozytorium wytycznych i zasad, określonych dla powyŝszych. Wytyczne i zasady słuŝą kontroli realizacji celów podczas iteracyjnego rozwoju architektury IT. Dalszych pogłębionych analiz i badań wymaga przełoŝenie celów biznesowych (w sektorze) na cele architektoniczne. Tematy i prace poruszone w artykule cieszą się duŝym zainteresowaniem i w związku ze zgłoszonym zapotrzebowaniem będą dalej rozwijane przez autorów w sektorze przemysłu. Literatura [1]. Jacob M.,Jonkers H.., (2004) Quantitative Analysis of Enterprise Architectures, ArchiMate Deliverable D3.5.1 b, Telematica Institut, [2]. Lankhorst M., (2005) Enterprise Architecture at Work, Modeling, Communication and Analysis, Springer Verlag [3]. Richardson G., Jackson B., Dickson G.,(1990) A Principles-Based Enterprise Architecture, MIS Quartely, vol 14, no.4. [4] Roszkowski J., (2004), Analiza i projektowanie strukturalne (eng. analysis and design), Helion, ISBN: [5]. Roszkowski J. (2007) The Formal Approach to Definition of the Requirements for the Needs of Computer Application Selection and Implementation, Proc. of the 16th International Conference on Systems Science ICSS'07 [7]. Roszkowski J.,Kobyliński A., (October ), Quality Management Reference Models for Business Intelligence Class Systems, The 8 th International Conference on Perspectives in Business Informatics Research, Kristianstad University College, Sweden [8]. Roszkowski. J., (2010), The simulation of processes in the integrated computer environment in the TELCO sector, Proc. of the 7 Symposium Modeling and Computer Simulation, Łódź, College of Computer Science 17
18 [9]. Scheer A. W. (2000), Business Process Modeling, Springer-Verlag, Berlin,Heidelberg, New York, ISBN: [10]. Scheer A.W., (1994), Business Process Engineering, Springer-Verlag, Berlin, Heidelberg, New York, [11]. TOGAF Version Enterprise Edition, (2007), ISBN: Van Haren Publishing [12]. Wegemann A., (2003) On the systemic Enterprise Architecture Methodology,Proc. of the International Conference on Enterprise Information Systems, Angers, France 18
Budowa celów architektury korporacyjnej IT dla środowisk zintegrowanych w sektorze publicznym
Budowa celów architektury korporacyjnej IT dla środowisk zintegrowanych w sektorze publicznym Autorzy: Dr Jerzy Roszkowski 1 KONIECZNOŚĆ ZARZĄDZANIA ARCHITEKTURĄ KORPORACYJNĄ Koszt złoŝoności IT -ZłoŜoność
przedstawiony na rysunku 3 będący rozwinięciem procesu 02 (Konfiguracja i rozwinięcie komponentów ZS GTP) z rysunku 1. TABELA 3
SYMULACJA PROCESÓW W INFORMATYCZNYM ŚRODOWISKU ZINTEGROWANYM W SEKTORZE TELCO dr Jerzy Roszkowski, Management Systems Consulting, 93-134 Łódź, ul. Poznańska 28/1 email: jerzy.roszkowski@neostrada.pl Streszczenie
HP Service Anywhere Uproszczenie zarządzania usługami IT
HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone
VII Kongres BOUG 03 października 2012
Raportowanie SLA w duŝej organizacji Studium przypadku VII Kongres BOUG 03 października 2012 Zdefiniowanie przypadku Zadanie do wykonania: Jak przenieść ustalenia formalne na efektywnie raportujący system?
SYMULACJA PROCESÓW W INFORMATYCZNYM ŚRODOWISKU ZINTEGROWANYM W SEKTORZE TELCO"
SYMULACJA PROCESÓW W INFORMATYCZNYM ŚRODOWISKU ZINTEGROWANYM W SEKTORZE TELCO" DR Jerzy Roszkowski - Management Systems Consulting Główny Architekt, Wydział Architektury Korporacyjnej rola w zadaniu :
ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI
ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI XVIII Forum Teleinformatyki mgr inż. Michał BIJATA, doktorant, Wydział Cybernetyki WAT Michal.Bijata@WAT.edu.pl, Michal@Bijata.com 28 września 2012 AGENDA Architektura
PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>
Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji
Szczegółowy opis przedmiotu umowy. 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów:
Rozdział I Szczegółowy opis przedmiotu umowy Załącznik nr 1 do Umowy Architektura środowisk SharePoint UMWD 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów: a) Środowisko
ZAŁĄCZNIK NR 3 OPIS PRZEDMIOTU ZAMÓWIENIA DOTYCZĄCY WDROŻENIA PLATFORMY ZAKUPOWEJ
ZAŁĄCZNIK NR 3 OPIS PRZEDMIOTU ZAMÓWIENIA DOTYCZĄCY WDROŻENIA PLATFORMY ZAKUPOWEJ 1. PRZEDMIOT ZAMÓWIENIA Przedmiotem zamówienia jest dostarczenie i wdrożenie systemu informatycznego dalej Platforma zakupowa
Modelowanie i analiza systemów informatycznych
Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The
Budowa modeli wymagań dla Regionalnych Systemów Informacji Medycznej opartych o hurtownie danych
Dr Jerzy ROSZKOWSKI Management Systems Consulting Budowa modeli wymagań dla Regionalnych Systemów Informacji Medycznej opartych o hurtownie danych TIAPiSZ 09 Definiowanie wymagań Główny problem: Jak definiować
Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą
Załącznik nr 8 do SIWZ Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 3-CPI-WZP-44/13 Lp. Zakres wykonywanych czynności Liczba osób Imiona i nazwiska osób, którymi dysponuje wykonawca
Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski 26.05.2011
Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF Tomasz Turski 26.05.2011 Plan prezentacji Architektura korporacyjna Frameworki Pryncypia Metodyka TOGAF
BUDOWA MODELI WYMAGAŃ DLA REGIONALNYCH SYSTEMÓW INFORMACJI MEDYCZNEJ OPARTYCH O HURTOWNIĘ DANYCH
Dr Jerzy ROSZKOWSKI 1 BUDOWA MODELI WYMAGAŃ DLA REGIONALNYCH SYSTEMÓW INFORMACJI MEDYCZNEJ OPARTYCH O HURTOWNIĘ DANYCH Wstęp Definiowanie wymagań biznesowych oraz wymagań na system jest fundamentalną rzeczą
JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?
K O N F E R E N C J A I N F O S H A R E 2 0 0 7 G d a ń s k 25-26.04.2007 JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? Zespół Zarządzania Technologiami Informatycznymi Prezentacja dr inż.
Modernizacja systemu gromadzenia i przetwarzania informacji hydrogeologicznych
151 Dział tematyczny VII: Modernizacja systemu gromadzenia i przetwarzania informacji hydrogeologicznych 152 Zadanie 31 System przetwarzania danych PSH - rozbudowa aplikacji do gromadzenia i przetwarzania
bo od managera wymaga się perfekcji
bo od managera wymaga się perfekcji MODELOWANIE PROCESÓW Charakterystyka modułu Modelowanie Procesów Biznesowych (BPM) Modelowanie procesów biznesowych stanowi fundament wdroŝenia systemu zarządzania jakością
System Obsługi Wniosków
System Obsługi Wniosków Wersja 2.0 1 System Obsługi Wniosków wersja 2.0 System Obsługi Wniosków to nowoczesne rozwiązanie wspierające proces obsługi wniosków o produkty bankowe. Pozwala na przyjmowanie,
Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne.
Załącznik nr 1a do Zapytania ofertowego nr POIG.08.02-01/2014 dotyczącego budowy oprogramowania B2B oraz dostawcy sprzętu informatycznego do projektu pn. Budowa systemu B2B integrującego zarządzanie procesami
System klasy BPMS jako wstęp do optymalizacji architektury aplikacyjnej w spółkach dystrybucyjnych i obrotowych
System klasy BPMS jako wstęp do optymalizacji architektury aplikacyjnej w spółkach dystrybucyjnych i obrotowych Wisła, 21/11/2012 Carrywater Group S.A. www.carrywater.com Al. Jerozolimskie 65/79, 00-697
Warsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni
Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni Warsztaty FRAME I. Cel Zapoznanie uczestników z możliwościami wykorzystania Europejskiej Ramowej Architektury ITS FRAME (zwanej dalej FRAME ) oraz jej narzędzi
Usługi analityczne budowa kostki analitycznej Część pierwsza.
Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.
Hurtownie danych i business intelligence - wykład II. Zagadnienia do omówienia. Miejsce i rola HD w firmie
Hurtownie danych i business intelligence - wykład II Paweł Skrobanek, C-3 pok. 321 pawel.skrobanek@pwr.wroc.pl oprac. Wrocław 2005-2008 Zagadnienia do omówienia 1. 2. Przegląd architektury HD 3. Warsztaty
Audyt oprogramowania systemu B2B oprogramowanie umożliwiające zarządzanie informacjami o produktach:
ZAŁĄCZNIK NR 1 Dodatkowe informacje dotyczące audytu systemu informatycznego B2B - zakres prac. Audyt oprogramowania (testy akceptacyjne i bezpieczeństwa) systemu informatycznego System B2B automatyzujący
ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.
ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego
Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.
Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja
Korzyści z integracji danych klienta. Seminarium PIU Jakość danych w systemach informatycznych ZU Warszawa 25.03.2009 Przygotowała Ewa Galas
Korzyści z integracji danych klienta Seminarium PIU Jakość danych w systemach informatycznych ZU Warszawa 25.03.2009 Przygotowała Ewa Galas Definicje CDI ( Customer Data Integration) koncepcja integracji
2011-11-04. Instalacja SQL Server Konfiguracja SQL Server Logowanie - opcje SQL Server Management Studio. Microsoft Access Oracle Sybase DB2 MySQL
Instalacja, konfiguracja Dr inŝ. Dziwiński Piotr Katedra InŜynierii Komputerowej Kontakt: piotr.dziwinski@kik.pcz.pl 2 Instalacja SQL Server Konfiguracja SQL Server Logowanie - opcje SQL Server Management
PREZENTACJA FUNKCJONALNA SYSTEMU PROPHIX
PREZENTACJA FUNKCJONALNA SYSTEMU PROPHIX Architektura i struktura funkcjonalna systemu PROPHIX PROPHIX Corporate Performance Management (Zarządzanie Wydajnością Firmy) System do samodzielnego planowania,
Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus
Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix
Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011
Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo
Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami
Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary
Małopolska Agencja Rozwoju Regionalnego S.A.
Małopolska Agencja Rozwoju Regionalnego S.A. Przestrzeń Twojego sukcesu! Projekt Określone w czasie działanie podejmowane w celu stworzenia niepowtarzalnego produktu lub usługi Projekt - cechy słuŝy realizacji
Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek
Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC Jarosław Świerczek Punkty funkcyjne Punkt funkcyjny to metryka złożoności oprogramowania wyznaczana w oparciu o określające to oprogramowanie
udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych
Rola architektury systemów IT Wymagania udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu metod modelowania architektury systemów IT - UML, systemów zorientowanych na usługi, systemów
Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne
Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne Rafał Czubik Krzysztof Komorowski IBM 2008 IBM Corporation Metodyka jest ważna Procesy i moduły Obszary decyzyjne
ZARZĄDZANIE DOKUMENTACJĄ. Tomasz Jarmuszczak PCC Polska
ZARZĄDZANIE DOKUMENTACJĄ Tomasz Jarmuszczak PCC Polska Problemy z zarządzaniem dokumentacją Jak znaleźć potrzebny dokument? Gdzie znaleźć wcześniejszą wersję? Która wersja jest właściwa? Czy projekt został
Prowadzący Andrzej Kurek
Prowadzący Andrzej Kurek Centrala Rzeszów Oddziały Lublin, Katowice Zatrudnienie ponad 70 osób SprzedaŜ wdroŝenia oprogramowań firmy Comarch Dopasowania branŝowe Wiedza i doświadczenie Pełna obsługa: Analiza
Case study: Mobilny serwis WWW dla Kolporter
Case study: Mobilny serwis WWW dla Kolporter Sklep internetowy Kolporter.pl oferuje swoim Klientom blisko 100 000 produktów w tym: ksiąŝki, muzykę, film i gry. Kolporter postanowił stworzyć nowy kanał
Systemy Business Intelligence w praktyce. Maciej Kiewra
Systemy Business Intelligence w praktyce Maciej Kiewra Wspólna nazwa dla grupy systemów: Hurtownia danych Pulpity menadżerskie Karty wyników Systemy budżetowe Hurtownia danych - ujednolicone repozytorium
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Oferta Banku Zachodniego WBK S.A. na usługę Elektronicznej Identyfikacji NaleŜności dla. Warszawa, 2008-11- 14
Oferta Banku Zachodniego WBK S.A. na usługę Elektronicznej Identyfikacji NaleŜności dla Warszawa, 2008-11- 14 I. Opis usługi Elektroniczna Identyfikacja NaleŜności Elektroniczna Identyfikacja NaleŜności
Projekty infrastrukturalne w obszarze obiektów przetwarzania danych. Piotr Trzciński
Projekty infrastrukturalne w obszarze obiektów przetwarzania danych Piotr Trzciński O zespole Zespół 6 osób Odpowiedzialność za: Utrzymanie infrastruktury data centre w Polsce, w tym: Service Management
Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie
Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie
Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW
01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe ZARZĄDZANIE SERWISEM IT PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe ZARZĄDZANIE SERWISEM IT Semestr 1 Moduły
Testy poziom po poziomie
poziom po poziomie Prowadzący: Tomasz Mielnik Eliza Słonińska Agenda 1. Modele prowadzenia projektów 2. V-Model 3. Poziomy testów 4. Typy testów 5. Zadanie 1 Modele prowadzenia projektów Wodospadowy (ang.
Wprowadzenie do Hurtowni Danych. Mariusz Rafało
Wprowadzenie do Hurtowni Danych Mariusz Rafało mariusz.rafalo@hotmail.com WPROWADZENIE DO HURTOWNI DANYCH Co to jest hurtownia danych? Hurtownia danych jest zbiorem danych zorientowanych tematycznie, zintegrowanych,
Opis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
III Edycja ITPro 16 maja 2011
III Edycja ITPro 16 maja 2011 SharePoint 2010 SharePoint jako platforma ERP Paweł Szczecki pawel.szczecki@predica.pl Prelegent Paweł Szczecki Współwłaściciel firmy Predica sp. z o.o. Odpowiedzialny za
Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.
Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.pl Obsługa wniosków kredytowych Potrzeba elastyczności
1 Wprowadzenie do J2EE
Wprowadzenie do J2EE 1 Plan prezentacji 2 Wprowadzenie do Java 2 Enterprise Edition Aplikacje J2EE Serwer aplikacji J2EE Główne cele V Szkoły PLOUG - nowe podejścia do konstrukcji aplikacji J2EE Java 2
Spis treści. Część I Wprowadzenie do pakietu oprogramowania Analysis Services
Spis treści Wstęp... ix Odkąd najlepiej rozpocząć lekturę?... ix Informacja dotycząca towarzyszącej ksiąŝce płyty CD-ROM... xi Wymagania systemowe... xi Instalowanie i uŝywanie plików przykładowych...
mint software Business Solutions Development Team
mint software Business Solutions Development Team kim jesteśmy Tworzymy wyspecjalizowane oprogramowanie dla branży finansowej oraz e-commerce W każdym projekcie nasz zespół jest skupiony na realizacji
Usługa: Testowanie wydajności oprogramowania
Usługa: Testowanie wydajności oprogramowania testerzy.pl przeprowadzają kompleksowe testowanie wydajności różnych systemów informatycznych. Testowanie wydajności to próba obciążenia serwera, bazy danych
Metodyka projektowania komputerowych systemów sterowania
Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania
Ryzyko systemów informatycznych Fakty
Od bezpieczeństwa informacji do bezpiecznej firmy Metodyka SABSA Tomasz Bejm, Aleksander Poniewierski Ryzyko systemów informatycznych Fakty Citigroup utracił dane i historie transakcji prawie 4 milionów
PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>
Załącznik nr 4.6 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA
Zapytanie ofertowe 13-09-2013
Zapytanie ofertowe W związku z realizacją projektu współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Działania 8.2 Programu Operacyjnego Innowacyjna Gospodarka 2007-2013,
Instrukcja zmian w wersji Vincent Office
Instrukcja zmian w wersji 1.14 Vincent Office 1. Admin-zarządzanie podatnikami. a) przenoszenie planu kont między podatnikami. KaŜdy nowo załoŝony podatnik posiada wzorcowy plan kont opracowny przez naszą
Wewnętrzny Pomiar Ryzyka* (WPR)
Wewnętrzny Pomiar Ryzyka* (WPR) *Def2000/WPR Cel prezentacji Celem pokazu jest przedstawienie podstawowej charakterystyki aplikacji WPR (Wewnętrzny Pomiar ryzyka) oraz zasad jej obsługi przez UŜytkowników.
Kultura usługowa i jej znaczenie dla relacji biznes - IT
Kultura usługowa i jej znaczenie dla relacji biznes - IT Andrzej Bartkowiak Dyrektor Centrum Kompetencji Zarządzania Usługami IT BZ WBK System Zarządzania Usługami to zestaw wyspecjalizowanych zdolności
SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42
SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH info@prointegra.com.pl tel: +48 (032) 730 00 42 1. WPROWADZENIE... 3 2. KORZYŚCI BIZNESOWE... 4 3. OPIS FUNKCJONALNY VILM... 4 KLUCZOWE FUNKCJE
CASE STUDIES TEST FACTORY
CASE STUDIES TEST FACTORY Wiodący niemiecki bank inwestycyjny 01. Wsparcie klienta przez wysoko wykwalifikowany zespół analityków testowych oraz inżynierów automatyzacji testów Bankowość Wdrożenie nowego
CRM w logistyce. Justyna Jakubowska. CRM7 Specjalista Marketingu
CRM w logistyce Justyna Jakubowska CRM7 Specjalista Marketingu CRM w logistyce Prezentacja firm more7 Polska dostawca systemu CRM Autor i producent systemu do zarządzania relacjami z klientem CRM7; Integrator
Architektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011
Architektura informacji w ochronie zdrowia Warszawa, 29 listopada 2011 Potrzeba Pomiędzy 17 a 19 kwietnia 2011 roku zostały wykradzione dane z 77 milionów kont Sony PlayStation Network. 2 tygodnie 25 milionów
Baza danych to zbiór wzajemnie powiązanych ze sobą i zintegrowanych danych z pewnej dziedziny.
PI-14 01/12 Baza danych to zbiór wzajemnie powiązanych ze sobą i zintegrowanych danych z pewnej dziedziny.! Likwidacja lub znaczne ograniczenie redundancji (powtarzania się) danych! Integracja danych!
Zapewnij sukces swym projektom
Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie
Procesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Opis systemu CitectFacilities. (nadrzędny system sterowania i kontroli procesu technologicznego)
Opis systemu CitectFacilities (nadrzędny system sterowania i kontroli procesu technologicznego) I. Wstęp. Zdalny system sterowania, wizualizacji i nadzoru zostanie wykonany w oparciu o aplikację CitectFacilities,
Nowoczesne aplikacje mobilne i ich rola w podnoszeniu jakości danych
Nowoczesne aplikacje mobilne i ich rola w podnoszeniu jakości danych www.ascen.pl 1 Agenda O firmie Zarządzanie jakością danych Aplikacje mobilne i ich rola w zarządzaniu jakością danych 2 O firmie Data
DOBÓR ŚRODKÓW TRANSPORTOWYCH DLA GOSPODARSTWA PRZY POMOCY PROGRAMU AGREGAT - 2
InŜynieria Rolnicza 14/2005 Michał Cupiał, Maciej Kuboń Katedra InŜynierii Rolniczej i Informatyki Akademia Rolnicza im. Hugona Kołłątaja w Krakowie DOBÓR ŚRODKÓW TRANSPORTOWYCH DLA GOSPODARSTWA PRZY POMOCY
Skuteczna Strategia CRM - wyzwanie dla organizacji. Artur Kowalski Prometriq
Skuteczna Strategia CRM - wyzwanie dla organizacji Artur Kowalski Prometriq Wrocław, 19-11-2009 Jest tylko jedna strategia sukcesu Polega ona na precyzyjnym zdefiniowaniu docelowego odbiorcy i zaoferowaniu
Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz
Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i
Aurea BPM Dokumenty pod kontrolą
Aurea BPM Dokumenty pod kontrolą 1 Aurea BPM unikalna platforma o wyróżniających cechach Quality Software Solutions Aurea BPM Aurea BPM system informatyczny wspomagający zarządzanie procesami biznesowymi
MONEVA POLSKA Sp. z o.o. Ul Przemysłowa 4. 58-160 Świebodzice Polska NIP: 884 23 65 516. Regon:891138010 Świebodzice 6.07.2010 ZAPYTANIE OFERTOWE
MONEVA POLSKA Sp. z o.o. Ul Przemysłowa 4 58-160 Świebodzice Polska NIP: 884 23 65 516 Regon:891138010 Świebodzice 6.07.2010 ZAPYTANIE OFERTOWE W związku uzyskaniem dofinansowania w ramach Regionalnego
Oprogramowanie systemu B2B zakup licencji na oprogramowanie umożliwiające zarządzanie informacjami o produktach:
ZAŁĄCZNIK NR 1 Dodatkowe informacje dotyczące systemu informatycznego B2B - zakres prac. Opracowanie systemu informatycznego (wykonanie, instalacja i konfiguracja / wdrożenie oraz usługi szkoleniowe) System
ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.
ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. 1 Załącznik Nr 2 do Część II SIWZ Wyciąg ze standardów, zasad i wzorców integracyjnych obowiązujących
Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa
Budowa systemu wspomagającego podejmowanie decyzji Metodyka projektowo wdrożeniowa Agenda Systemy wspomagające decyzje Business Intelligence (BI) Rodzaje systemów BI Korzyści z wdrożeń BI Zagrożenia dla
JIRA, jako narzędzie wspierające zarządzanie projektami w dużej organizacji
JIRA, jako narzędzie wspierające zarządzanie projektami w dużej organizacji Wdrożenie procesu wytwórczego w Jira w Grupie Cyfrowy Polsat Grupa Kapitałowa Cyfrowy Polsat S.A. Warszawa, 14 marca 2018 JIRA
Od papierowych procedur do automatycznych procesów biznesowych w urzędzie dobre praktyki Michał Prusaczyk
Od papierowych procedur do automatycznych procesów biznesowych w urzędzie dobre praktyki Michał Prusaczyk O mnie Prelegent Michał Prusaczyk Senior Associate Consultant Podsumowanie Michał w ciągu ostatnich
9.5 Rozliczanie zaopatrzenia w przedmioty ortopedyczne i środki pomocnicze
Po zakończeniu prac z listą raportów zwrotnych naleŝy kliknąć w przycisk opcji Powrót do listy raportów. Opcja ta spowoduje przywrócenie głównego okna obszaru Sprawozdawczość. 9.5 Rozliczanie zaopatrzenia
Bazy danych i ich aplikacje
ORAZ ZAPRASZAJĄ DO UDZIAŁU W STUDIACH PODYPLOMOWYCH Celem Studiów jest praktyczne zapoznanie słuchaczy z podstawowymi technikami tworzenia i administrowania bazami oraz systemami informacyjnymi. W trakcie
BADANIE WYBRANYCH PROCESÓW REALIZOWANYCH W SZPITALACH NA STYKU Z SYSTEMAMI E-ZDROWIA
ZAŁĄCZNIK C Anna Gontarek-Janicka 1 BADANIE WYBRANYCH PROCESÓW REALIZOWANYCH W SZPITALACH NA STYKU Z SYSTEMAMI E-ZDROWIA SPIS TREŚCI WSKAZÓWKI METODYCZNE DO PRZEPROWADZENIA BADAŃ... 2 WYKAZ WYBRANYCH PROCESÓW
Zintegrowany System Zarządzania w Śląskim Centrum Społeczeństwa Informacyjnego
Zintegrowany System Zarządzania w Śląskim Centrum Społeczeństwa Informacyjnego Beata Wanic Śląskie Centrum Społeczeństwa Informacyjnego II Śląski Konwent Informatyków i Administracji Samorządowej Szczyrk,
Portale raportowe, a narzędzia raportowe typu self- service
Portale raportowe, a narzędzia raportowe typu self- service Bartłomiej Graczyk Kierownik Projektów / Architekt rozwiązań Business Intelligence E mail: bartek@graczyk.info.pl Site: www.graczyk.info.pl Agenda
KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA PROJEKTAMI W PRZEDSIĘBIORSTWIE
KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA PROJEKTAMI W PRZEDSIĘBIORSTWIE Seweryn SPAŁEK Streszczenie: Zarządzanie projektami staje się coraz bardziej powszechne w przedsiębiorstwach produkcyjnych, handlowych
1. Wybór systemu ERP. 2. Wzajemne relacje systemów ERP i BPMS.
Agenda 1. Wybór systemu ERP. 2. Wzajemne relacje systemów ERP i BPMS. 1 dr inż. Marek Szelągowski AFiB Vistula marek.szelagowski@dbpm.pl Naszą misją jest: Wspieranie naszych klientów w wypracowywaniu usprawnień
Dopasowanie IT/biznes
Dopasowanie IT/biznes Dlaczego trzeba mówić o dopasowaniu IT-biznes HARVARD BUSINESS REVIEW, 2008-11-01 Dlaczego trzeba mówić o dopasowaniu IT-biznes http://ceo.cxo.pl/artykuly/51237_2/zarzadzanie.it.a.wzrost.wartosci.html
1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Data Governance jako część ładu korporacyjnego
Data Governance jako część ładu korporacyjnego Prof. SGH, dr hab. Andrzej Sobczak Kurs: Wprowadzenie do problematyki Data Governance Zakres tematyczny kursu Data Governance jako część ładu korporacyjnego
SYSTEM WSMS ZARZĄDZANIE STANDARDEM STACJI ROBOCZYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42
SYSTEM WSMS ZARZĄDZANIE STANDARDEM STACJI ROBOCZYCH info@prointegra.com.pl tel: +48 (032) 730 00 42 1. WPROWADZENIE... 3 2. KORZYŚCI BIZNESOWE... 4 3. OPIS FUNKCJONALNY WSMS... 4 WSMS AUDIT... 6 WSMS SM...
TECHNOLOGIA JSP W TWORZENIU APLIKACJI ROZPROSZONYCH NA PRZYKŁADZIE SYSTEMU ZARZĄDZANIA NIERUCHOMOŚCIAMI W GMINIE
InŜynieria Rolnicza 14/2005 Jerzy Dąbkowski, Marcin Kowalski Katedra InŜynierii Rolniczej i Informatyki Akademia Rolnicza w Krakowie TECHNOLOGIA JSP W TWORZENIU APLIKACJI ROZPROSZONYCH NA PRZYKŁADZIE SYSTEMU
PureSystems zautomatyzowane środowisko aplikacyjne. Emilia Smółko Software IT Architect
PureSystems zautomatyzowane środowisko aplikacyjne. Emilia Smółko Software IT Architect Wbudowana wiedza specjalistyczna Dopasowane do zadania Optymalizacja do aplikacji transakcyjnych Inteligentne Wzorce
Usługa: Audyt kodu źródłowego
Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności
Zakres wykładu. Podstawy InŜynierii Oprogramowania
Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,
Elektroniczna Księga Wieczysta
Elektroniczna Księga Wieczysta Aspekty wdrażania systemu informatycznego świadczącego usługi drogą elektroniczną Robert Ciurkot Dyrektor Departamentu Konsultingu Grupa Bull Grupa Bull na świecie 50 krajów
Ankieta. Systemy finansowo-księgowe w jednostkach sektora finansów publicznych
Ankieta. Systemy finansowo-księgowe w jednostkach sektora finansów publicznych ID odpowiedzi 673 Identyfikacja jednostki Pytania o dane identyfikujące jednostkę 1. Proszę o podanie pełnej nazwy jednostki
9.5 Rozliczanie zaopatrzenia w przedmioty ortopedyczne i środki pomocnicze
Fragment instrukcji obsługi systemu SZOI przygotowanej przez P.I. Kamsoft - 09.02.2009 r. 9.5 Rozliczanie zaopatrzenia w przedmioty ortopedyczne i środki pomocnicze Obszar Sprawozdawczość/Zaopatrzenie
Wrocław, dnia 01.07.2013 ZAPYTANIE OFERTOWE
Wrocław, dnia 01.07.2013 ZAPYTANIE OFERTOWE W związku z realizacją projektu pn. WdroŜenie internetowego systemu B2B integrującego zarządzanie procesami biznesowymi w zakresie sprzedaŝy pneumatyki z partnerami