Metodyka Cele kontrolne W y t y c z n e z a r z ą d z a n i a M

4.1

M e t o d y k a

C e l e k o n t r o l n e

W y t y c z n e z a r z ą d z a n i a

M o d e l e d o j r z a ł o ś c i

Sponsorzy tłumaczenia: Deloitte, Ernst&Young, Grupa Allegro, KPMG

IT Governance Institute®

Instytut IT Governance Institute (ITGITM) (www.itgi.org) powstał w 1998 roku, aby rozwijać międzynarodowe koncepcje i standardy dotyczące kierowania i sprawowania kontroli nad technologią informatyczną (IT) w przedsiębiorstwach. Efektywny nadzór informatyczny pomaga sprawić, by technologia informatyczna wspierała cele biznesowe, pozwala optymalizować inwestycje w IT oraz odpowiednio zarządzać ryzykiem i możliwościami dotyczącymi IT. Instytut ITGI oferuje dostęp do unikalnych badań, zasobów elektronicznych oraz studiów przypadków, aby pomóc osobom kierującym przedsiębiorstwami w sprawowaniu nadzoru informatycznego.

ZastrzeżenieInstytut ITGI („Wydawca”) opracował i wydał tę publikację, noszącą tytuł CobiT® 4.1 („Opracowanie”), głównie jako materiał edukacyjny przeznaczony dla dyrektorów ds. informatyki (CIO), wyższej kadry zarządzającej, osób kierujących działami IT oraz specjalistów ds. kontroli. Wydawca nie gwarantuje, że zastosowanie się do jakichkolwiek wskazówek zawartych w Opracowaniu zapewni korzystne rezultaty. Należy zakładać, że Opracowanie może nie zawierać wszystkich poprawnych informacji, procedur i testów, które są odpowiednio ukierunkowane na uzyskanie takich samych rezultatów. Aby określić stosowność określonych informacji, procedur lub testów, dyrektorzy ds. informatyki (CIO), wyższa kadra zarządzająca, osoby kierujące działami IT i specjaliści ds. kontroli powinni kierować się własną oceną specyficznych warunków działania konkretnych systemów lub środowisk IT.

PublikacjaCopyright © 2007 IT Governance Institute. Wszelkie prawa zastrzeżone. Żadna część niniejszej publikacji nie może być używana, kopiowana, powielana, modyfikowana, rozpowszechniana, wyświetlana, przechowywana w systemie wyszukiwania i udostępniania informacji ani nadawana w żadnej formie ani przy użyciu żadnych środków (elektronicznych, mechanicznych, poprzez fotokopiowanie, nagrywanie itp.) bez uprzedniej pisemnej zgody instytutu ITGI. Dozwolone jest powielanie wybranych części publikacji wyłącznie do wewnętrznego, niekomercyjnego lub akademickiego użytku pod warunkiem zachowania wszystkich cech wskazujących na źródło materiału. W odniesieniu do niniejszej publikacji nie udziela się żadnych innych praw ani pozwoleń.

Polityka jakościNiniejsze Dzieło zostało przełożone na język polski z angielskiej wersji CobiT 4.1 przez Warszawski Oddział ISACA (Stowarzyszenie Audytu, Bezpieczeństwa i Kontroli Systemów Informacyjnych) za zgodą ISACA. ISACA Warszawa bierze na siebie wyłączną odpowiedzialność za wierność i dokładność tłumaczenia. Prawo autorskie©2010 ISACA (“ISACA”). Wszelkie prawa zastrzeżone. Żadna część niniejszej publikacji nie może być użyta, powielana, odtwarzana, zmieniana, rozpowszechniana, ujawniana, przechowywana w jakimkolwiek systemie przechowywania danych, ani przekazywana w jakiejkolwiek formie (drogą elektroniczną, metodą mechaniczną, kserograficzną, poprzez nagrywanie, ani w żaden inny sposób) bez uprzedniej pisemnej zgody ISACA. Zrzeczenie się odpowiedzialności ISACA stworzyła CobiT 4.1 („Dzieło”) głównie jako zasoby edukacyjne dla zawodowych kontrolerów. ISACA nie daje gwarancji, że Dzieło przyniesie oczekiwane rezultaty. Nie należy zakładać, że Dzieło zawiera wszystkie stosowne informacje, procedury i testy, ani że pomija inne informacje, procedury i testy, które dawałyby te same rezultaty. Aby stwierdzić poprawność danej informacji, procedury lub testu, kontrolerzy powinni odnieść się do własnego osądu okoliczności stwarzanych przez dany system lub środowisko technologii informacyjnej.

Quality StatementThis Work is translated into Polish from the English language version of COBIT 4.1 by the ISACA Warsaw Chapter of the Information Systems Audit and Control Association (ISACA) with the permission of ISACA. The ISACA Warsaw Chapter assumes sole responsibility for the accuracy and faithfulness of the translation.

Copyright©2010 ISACA (“ISACA”). All rights reserved. No part of this publication may be used, copied, reproduced, modified, distributed, displayed, stored in a retrieval system, or transmitted in any form by any means (electronic, mechanical, photocopying, recording or otherwise), without the prior written authorization of ISACA.

DisclaimerISACA created COBIT 4.1 (“Work”) primarily as an educational resource for controls professionals. ISACA makes no claim that use of any of the Work will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific information, procedure or test, the controls professional should apply his or her own professional judgment to the specific circumstances presented by the particular systems or information technology environment.

IT Governance Institute3701 Algonquin Road, Suite 1010Rolling Meadows, IL 60008 USATel.: +1.847.590.7491Faks: +1.847.253.1443E-mail: [email protected] internetowa: www.itgi.org

CobiT 4.1

© 2007 IT Governance Institute. All rights reserved. www.itgi.org

1© 2007 IT Governance Institute. All rights reserved. www.itgi.org

CobiT 4.1Podziękowania

IT Governance Institute pragnie złożyć podziękowania następującym osobom i instytucjom:Eksperci: autorzy i recenzenciMark Adler, CISA, CISM, CIA, CISSP, Allstate Ins. Co., Stany ZjednoczonePeter Andrews, CISA, CITP, MCMI, PJA Consulting, Wielka BrytaniaGeorges Ataya, CISA, CISM, CISSP, MSCS, PBA, Solvay Business School, BelgiaGary Austin, CISA, CIA, CISSP, CGFM, KPMG LLP, Stany ZjednoczoneGary S. Baker, CA, Deloitte & Touche, KanadaDavid H. Barnett, CISM, CISSP, Applera Corp., Stany ZjednoczoneChristine Bellino, CPA, CITP, Jefferson Wells, Stany Zjednoczone John W. Beveridge, CISA, CISM, CFE, CGFM, CQA, Massachusetts Office of the State Auditor, Stany ZjednoczoneAlan Boardman, CISA, CISM, CA, CISSP, Fox IT, Wielka BrytaniaDavid Bonewell, CISA, CISSP-ISSEP, Accomac Consulting LLC, Stany ZjednoczoneDirk Bruyndonckx, CISA, CISM, KPMG Advisory, BelgiaDon Canilglia, CISA, CISM, Stany ZjednoczoneLuis A. Capua, CISM, Sindicatura General de la Nación, ArgentynaBoyd Carter, PMP, Elegantsolutions.ca, KanadaDan Casciano, CISA, Ernst & Young LLP, Stany ZjednoczoneSean V. Casey, CISA, CPA, Stany ZjednoczoneSushil Chatterji, Edutech, SingapurEdward Chavannes, CISA, CISSP, Ernst & Young LLP, Stany ZjednoczoneChristina Cheng, CISA, CISSP, SSCP, Deloitte & Touche LLP, Stany ZjednoczoneDharmesh Choksey, CISA, CPA, CISSP, PMP, KPMG LLP, Stany ZjednoczoneJeffrey D. Custer, CISA, CPA, CIA, Ernst & Young LLP, Stany ZjednoczoneBeverly G. Davis, CISA, Federal Home Loan Bank of San Francisco, Stany ZjednoczonePeter De Bruyne, CISA, Banksys, BelgiaSteven De Haes, University of Antwerp Management School, BelgiaPeter De Koninck, CISA, CFSA, CIA, SWIFT SC, BelgiaPhilip De Picker, CISA, MCA, National Bank of Belgium, BelgiaKimberly de Vries, CISA, PMP, Zurich Financial Services, Stany ZjednoczoneRoger S. Debreceny, Ph.D., FCPA, University of Hawaii, Stany ZjednoczoneZama Dlamini, Deloitte & Touche LLP, Republika Południowej AfrykiRupert Dodds, CISA, CISM, FCA, KPMG, Nowa ZelandiaTroy DuMoulin, Pink Elephant, KanadaBill A. Durrand, CISA, CISM, CA, Ernst & Young LLP, KanadaJustus Ekeigwe, CISA, MBCS, Deloitte & Touche LLP, Stany ZjednoczoneRafael Eduardo Fabius, CISA, Republica AFAP S.A., UrugwajUrs Fischer, CISA, CIA, CPA (Swiss), Swiss Life, SzwajcariaChristopher Fox, ACA, PricewaterhouseCoopers, Stany ZjednoczoneBob Frelinger, CISA, Sun Microsystems Inc., Stany ZjednoczoneZhiwei Fu, Ph. D, Fannie Mae, Stany ZjednoczoneMonique Garsoux, Dexia Bank, BelgiaEdson Gin, CISA, CFE, SSCP, Stany ZjednoczoneSauvik Ghosh, CISA, CIA, CISSP, CPA, Ernst & Young LLP, Stany ZjednoczoneGuy Groner, CISA, CIA, CISSP, Stany ZjednoczoneErik Guldentops, CISA, CISM, University of Antwerp Management School, BelgiaGary Hardy, IT Winners, Republika Południowej AfrykiJimmy Heschl, CISA, CISM, KPMG, AustriaBenjamin K. Hsaio, CISA, Federal Deposit Insurance Corp., Stany ZjednoczoneTom Hughes, Acumen Alliance, AustraliaMonica Jain, CSQA, Covansys Corp., Stany ZjednoczoneWayne D. Jones, CISA, Australian National Audit Office, AustraliaJohn A. Kay, CISA, Stany ZjednoczoneLisa Kinyon, CISA, Countrywide, Stany ZjednoczoneRodney Kocot, Systems Control and Security Inc., Stany ZjednoczoneLuc Kordel, CISA, CISM, CISSP, CIA, RE, RFA, Dexia Bank, BelgiaLinda Kostic, CISA, CPA, Stany ZjednoczoneJohn W. Lainhart IV, CISA, CISM, IBM, Stany ZjednoczonePhilip Le Grand, Capita Education Services, Wielka Brytania.Elsa K. Lee, CISA, CISM, CSQA, AdvanSoft International Inc., Stany ZjednoczoneKenny K. Lee, CISA, CISSP, Countrywide SMART Governance, Stany ZjednoczoneDebbie Lew, CISA, Ernst & Young LLP, Stany ZjednoczoneDonald Lorete, CPA, Deloitte & Touche LLP, Stany ZjednoczoneAddie C.P. Lui, MCSA, MCSE, First Hawaiian Bank, Stany ZjednoczoneDebra Mallette, CISA, CSSBB, Kaiser Permanente, Stany Zjednoczone

i T G o v e r n a n c e i n s T i T u T e

© 2007 IT Governance Institute. All rights reserved. www.itgi.org2

Charles Mansour, CISA, Charles Mansour Audit & Risk Service, Wielka Brytania Mario Micallef, CPAA, FiA, National Australia Bank Group, AustraliaNiels Thor Mikkelsen, CISA, CIA, Danske Bank, DaniaJohn Mitchell, CISA, CFE, CITP, FBCS, FiIA, MIIA, QiCA, LHS Business Control, Wielka BrytaniaAnita Montgomery, CISA, CIA, Countrywide, Stany ZjednoczoneKarl Muise, CISA, City National Bank, Stany ZjednoczoneJay S. Munnelly, CISA, CIA, CGFM, Federal Deposit Insurance Corp., Stany ZjednoczoneSang Nguyen, CISA, CISSP, MCSE, Nova Southeastern University, Stany ZjednoczoneEd O’Donnell, Ph.D., CPA, University of Kansas, Stany ZjednoczoneSue Owen, Department of Veterans Affairs, AustraliaRobert G. Parker, CISA, CA, CMC, FCA, Robert G. Parker Consulting, KanadaRobert Payne, Trencor Services (Pty) Ltd., Republika Południowej AfrykiThomas Phelps IV, CISA, PricewaterhouseCoopers LLP, Stany ZjednoczoneVitor Prisca, CISM, Novabase, PortugaliaMartin Rosenberg, Ph.D., IT Business Management, Wielka BrytaniaClaus Rosenquist, CISA, TrygVesata, DaniaJaco Sadie, Sasol, Republika Południowej AfrykiMax Shanahan, CISA, FCPA, Max Shanahan & Associates, AustraliaCraig W. Silverthorne, CISA, CISM, CPA, IBM Business Consulting Services, Stany ZjednoczoneChad Smith, Great-West Life, KanadaRoger Southgate, CISA, CISM, FCCA, CubeIT Management Ltd., Wielka BrytaniaPaula Spinner, CSC, Stany ZjednoczoneMark Stanley, CISA, Toyota Financial Services, Stany ZjednoczoneDirk E. Steuperaert, CISA, PricewaterhouseCoopers, BelgiaRobert E. Stroud, CA Inc., Stany ZjednoczoneScott L. Summers, Ph.D., Brigham Young University, Stany ZjednoczoneLance M. Turcato, CISA, CISM, CPA, City of Phoenix IT Audit Division, Stany ZjednoczoneWim Van Grembergen, Ph.D., University of Antwerp Management School, BelgiaJohan Van Grieken, CISA, Deloitte, BelgiaGreet Volders, Voquals NV, BelgiaThomas M. Wagner, Gartner Inc., Stany ZjednoczoneRobert M. Walters, CISA, CPA, CGA, Office of the Comptroller General, KanadaFreddy Withagels, CISA, Capgemini, BelgiaTom Wong, CISA, CIA, CMA, Ernst & Young LLP, KanadaAmanda Xu, CISA, PMP, KPMG LLP, Stany Zjednoczone

Podziękowania za udział w projekcie tłumaczenia na język polski:Mirosław Kaliński - Prezes Stowarzyszenia ISACA Warszawa, CISA, PolskaPaweł Popow - Kierownik projektu tłumaczenia, CISA, Proama, PolskaMagdalena Szeżyńska - recenzent, Ph.D., CISA, PolskaDominik Miklaszewski - recenzent, CISSP, CISA, PolskaMichał Nieżurawski - recenzent, CGEIT, CISM, CISSP, CISA, CRISC, PolskaPiotr Dzwonkowski - recenzent, CISA, CISM, CRISC - LINKIES, Management Consulting Polska, PolskaMariusz Piwnik - recenzent, CISA, Stowarzyszenie ISACA Warszawa, PolskaAdam Białachowski - recenzent, CISA, B-Act Sp. z o.o., PolskaJakub Bojanowski - CBCP, CFE, CIA, CISA, CISM, Deloitte, PolskaMariusz Ustyjańczuk - CISA, Deloitte, Polska

Rada Naukowa ITGIEverett C. Johnson, CPA, Deloitte & Touche LLP (obecnie emerytowany), Stany Zjednoczone — Międzynarodowy PrzewodniczącyGeorges Ataya, CISA, CISM, CISSP, Solvay Business School, Belgia — WiceprzewodniczącyWilliam C. Boni, CISM, Motorola, Stany Zjednoczone — WiceprzewodniczącyAvinash Kadam, CISA, CISM, CISSP, CBCP, GSEC, GCIH, Miel e-Security Pvt. Ltd., Indie — WiceprzewodniczącyJean-Louis Leignel, MAGE Conseil, Francja — Wiceprzewodniczący Lucio Augusto Molina Focazzio, CISA, Kolumbia — WiceprzewodniczącyHoward Nicholson, CISA, City of Salisbury, Australia — WiceprzewodniczącyFrank Yam, CISA, FHKIoD, FHKCS, FFA, CIA, CFE, CCP, CFSA, Focus Strategic Group, Hong Kong — WiceprzewodniczącyMarios Damianides, CISA, CISM, CA, CPA, Ernst & Young LLP, Stany Zjednoczone — były Międzynarodowy Przewodniczący Robert S. Roussey, CPA, University of Southern California, Stany Zjednoczone — były Międzynarodowy PrzewodniczącyRonald Saull, CSP, Great-West Life and IGM Financial, Kanada — Członek Rady

Komitet ds. Ładu InformatycznegoTony Hayes, FCPA, Queensland Government, Australia — Przewodniczący

CobiT 4.1Podziękowania (cd.)


CobiT 4.1Max Blecher, Virtual Alliance, Republika Południowej AfrykiSushil Chatterji, Edutech, SingapurAnil Jogani, CISA, FCA, Tally Solutions Limited, Wielka BrytaniaJohn W. Lainhart IV, CISA, CISM, IBM, Stany ZjednoczoneRómulo Lomparte, CISA, Banco de Crédito BCP, PeruMichael Schirmbrand, Ph.D., CISA, CISM, CPA, KPMG LLP, AustriaRonald Saull, CSP, Great-West Life Assurance and IGM Financial, KanadaKomitet sterujący ds. metodyki CobiTRoger Debreceny, Ph.D., FCPA, University of Hawaii, Stany Zjednoczone — PrzewodniczącyGary S. Baker, CA, Deloitte & Touche, KanadaDan Casciano, CISA, Ernst & Young LLP, Stany ZjednoczoneSteven De Haes, University of Antwerp Management School, BelgiaPeter De Koninck, CISA, CFSA, CIA, SWIFT SC, BelgiaRafael Eduardo Fabius, CISA, República AFAP SA, UrugwajUrs Fischer, CISA, CIA, CPA (Swiss), Swiss Life, SzwajcariaErik Guldentops, CISA, CISM, University of Antwerp Management School, BelgiaGary Hardy, IT Winners, Republika Południowej AfrykiJimmy Heschl, CISA, CISM, KPMG, AustriaDebbie A. Lew, CISA, Ernst & Young LLP, Stany ZjednoczoneMaxwell J. Shanahan, CISA, FCPA, Max Shanahan & Associates, AustraliaDirk Steuperaert, CISA, PricewaterhouseCoopers LLC, BelgiaRobert E. Stroud, CA Inc., Stany Zjednoczone

Zespół Doradczy ITGIRonald Saull, CSP, Great-West Life Assurance and IGM Financial, Kanada — PrzewodniczącyRoland Bader, F. Hoffmann-La Roche AG, SzwajcariaLinda Betz, IBM Corporation, Stany ZjednoczoneJean-Pierre Corniou, Renault, FrancjaRob Clyde, CISM, Symantec, Stany ZjednoczoneRichard Granger, NHS Connecting for Health, Wielka BrytaniaHoward Schmidt, CISM, R&H Security Consulting LLC, Stany ZjednoczoneAlex Siow Yuen Khong, StarHub Ltd., SingapurAmit Yoran, Yoran Associates, Stany Zjednoczone

Jednostki powiązane i sponsorzy ITGIOddziały ISACAAmerican Institute for Certified Public AccountantsASIS InternationalThe Center for Internet SecurityCommonwealth Association of Corporate GovernanceFiDA InformInformation Security ForumThe Information Systems Security AssociationInstitut de la Gouvernance des Systèmes d’InformationInstitute of Management AccountantsISACAITGI JapanSolvay Business SchoolUniversity of Antwerp Management SchoolAldion Consulting Pte. Lte.CAHewlett-PackardiBMLogLogic Inc.Phoenix Business and Systems Process Inc.Symantec CorporationWolcott Group LLCWorld Pass IT Solutions


CobiT 4.1sPis Treści

Wprowadzenie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Metodyka CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Planowanie i organizacja. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Nabywanie i wdrażanie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Dostarczanie i wsparcie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Monitorowanie i ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Załącznik I — Tabele powiązań celów i procesów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Załącznik II — Przyporządkowanie procesów IT do głównych obszarów ładu informatycznego, struktury ramowej COSO, zasobów informatycznych CobiT i kryteriów informacji CobiT . . . . . . . . . . . . . . . . . . . . 173

Załącznik III — Model dojrzałości kontroli wewnętrznej. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Załącznik IV — CobiT 4.1 — najważniejsze materiały źródłowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Załącznik V — Wzajemne relacje między metodyką CobiT 3rd Edition a metodyką CobiT 4.1 . . . . . . . . . 179

Załącznik VI — Podejście do badań i rozwoju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Załącznik VII — Terminologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Załącznik VIII — Metodyka CobiT i powiązane produkty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Będziemy wdzięczni za wszelkie uwagi na temat metodyki CobiT 4.1. Można je zgłaszać na stronie www.isaca.org/cobitfeedback.

w P r o w a d z e n i e

WPR

oW

aD

ZE

NIE


wProwadzenieW wielu przedsiębiorstwach zasoby informacyjne i wspierające je technologie są najcenniejszymi, ale często w niedostatecznym stopniu rozumianymi aktywami. Przedsiębiorstwa odnoszące sukcesy dostrzegają korzyści, jakie zapewniają technologie informatyczne (IT) i wykorzystują je do zwiększania swojej wartości w ocenie interesariuszy. Przedsiębiorstwa te rozumieją również konieczność zarządzania związanymi z tym ryzykami, takimi jak rosnąca potrzeba zachowania zgodności z przepisami czy krytyczna zależność wielu procesów biznesowych od IT.

Potrzeba uzyskania zapewnienia co do wartości IT, zarządzanie ryzykami związanymi z IT oraz zwiększone wymogi dotyczące kontroli nad zasobami informacyjnymi są obecnie postrzegane jako kluczowe elementy ładu korporacyjnego. Wartość, ryzyko i kontrola stanowią istotę ładu informatycznego.

Ład informatyczny należy do zakresu obowiązków kadry kierowniczej oraz zarządu i obejmuje przywództwo, struktury organizacyjne oraz procesy, dzięki którym IT może wspierać i rozwijać strategię oraz cele organizacji.

Ponadto, ład informatyczny integruje i formalizuje dobre praktyki, tak aby działalność informatyczna przedsiębiorstwa wspierała realizację celów biznesowych. Ład informatyczny umożliwia przedsiębiorstwu pełne wykorzystanie jego zasobów informacyjnych, a tym samym maksymalizację korzyści, wykorzystywanie pojawiających się możliwości i zdobywanie przewagi konkurencyjnej. Osiągnięcie tych efektów wymaga stosowania odpowiedniej metodyki kontroli nad technologiami informatycznymi, która jest zgodna ze standardem COSO (ang. Committee of Sponsoring Organisations of the Treadway Commission — Komitet Organizacji Sponsorujących Komisję Treadway'a) Internal Control — Integrated Framework (Zintegrowana kontrola wewnętrzna — struktura ramowa), który zapewnia powszechnie akceptowane ramy systemu kontroli wewnętrznej dla ładu korporacyjnego i zarządzania ryzykiem, lub z innymi, podobnymi metodykami.

Organizacje powinny spełniać wymogi dotyczące jakości, zasad powiernictwa i bezpieczeństwa swoich zasobów informacyjnych podobnie jak ma to miejsce w przypadku pozostałych aktywów. Przedstawiciele kadry kierowniczej powinni również dbać o optymalizację wykorzystania dostępnych zasobów IT, w tym aplikacji, informacji, infrastruktury i osób. Aby dopełnić tych obowiązków, a także aby osiągnąć założone cele, kadra kierownicza powinna znać stan architektury IT przedsiębiorstwa i zdecydować, jaki nadzór i kontrolę powinna zapewnić technologia informatyczna.

Control Objectives for Information and related Technology (CobiT®), czyli cele kontroli nad technologiami informatycznymi i pokrewnymi, stanowią zbiór dobrych praktyk pogrupowanych w domeny i procesy i prezentujący odpowiednie działania w zrozumiałym i logicznym porządku. Dobre praktyki CobiT odzwierciedlają wspólne stanowisko ekspertów. Koncentrują się one głównie na kontroli, a w mniejszym stopniu na wykonaniu. Praktyki te pomagają optymalizować inwestycje związane z IT, zapewniają dostępność usług oraz dostarczają wskaźników, które pozwalają wykryć ewentualne nieprawidłowości.

Aby działalność IT skutecznie spełniała wymagania biznesowe, kierownictwo firmy powinno wdrożyć wewnętrzny system lub metodykę kontroli. Metodyka kontroli CobiT umożliwia zaspokojenie tych potrzeb poprzez:• zapewnienie powiązania z wymaganiami biznesowymi;• zorganizowanie działalności IT w ramach ogólnie akceptowanego modelu procesów; • określenie głównych zasobów IT, które mają być wykorzystywane; • zdefiniowanie celów kontroli zarządczej, które należy uwzględnić.

Biznesowe ukierunkowanie metodyki CobiT przejawia się w powiązaniu celów biznesowych z celami IT, zapewnieniu mierników i modeli dojrzałości umożliwiających ocenę wyników, a także w określeniu odpowiednich obowiązków właścicieli procesów biznesowych i IT.

Ukierunkowanie metodyki CobiT na procesy przejawia się w modelu procesów, który dzieli IT na cztery domeny i 34 procesy związane z obszarami odpowiedzialności w zakresie planowania, budowy, eksploatacji i monitorowania, zapewniając całościowy wgląd w działalność IT. Pojęcia odnoszące się do architektury korporacyjnej pomagają określić zasoby niezbędne do zapewnienia prawidłowego działania procesów, takie jak aplikacje, informacje, infrastruktura czy osoby.

Podsumowując: aby zapewnić dostępność informacji, których potrzebuje przedsiębiorstwo do osiągania swoich celów, zarządzanie zasobami IT musi odbywać się w ramach zbioru naturalnie pogrupowanych procesów.

W jaki jednak sposób przedsiębiorstwo może sprawować nadzór nad IT, aby zapewnić sobie dostępność potrzebnych informacji? Jak powinno zarządzać ryzykiem i zabezpieczać zasoby IT, od których jest tak zależne? Co powinno zrobić, aby działalność IT osiągała swoje cele i wspierała działalność biznesową?

W pierwszej kolejności kierownictwo musi określić cele kontrolne, które definiują ostateczny cel wdrożenia zasad, planów i procedur, a także struktury organizacyjne, które zapewniają:• osiąganie celów biznesowych;• zapobieganie niepożądanym zdarzeniom lub ich wykrywanie i wprowadzanie odpowiednich poprawek.

WproWadzenie

WPR

oW

aD

ZE

NIE


CobiT 4.1Ponadto w dzisiejszych złożonych środowiskach biznesowych zarządzający stale poszukują skondensowanych i aktualnych informacji, aby szybko i skutecznie podejmować trudne decyzje dotyczące wartości, ryzyka i kontroli. Co powinno podlegać pomiarowi i w jaki sposób? Przedsiębiorstwa potrzebują obiektywnych wskaźników mówiących, w którym miejscu się znajdują i gdzie niezbędna jest poprawa. Powinny także wdrożyć zestaw narzędzi zarządzania, aby monitorować osiągany postęp. Ilustracja 1 przedstawia niektóre standardowe pytania oraz narzędzia informacyjne wykorzystywane w zarządzaniu w celu uzyskania potrzebnych odpowiedzi. Jednak panele kontrolne wymagają wskaźników, karty wyników — pomiarów, a porównania — skali porównawczej.

Odpowiedzią na potrzebę ustanowienia i monitorowania odpowiedniego poziomu kontroli i wydajności IT jest definicja CobiT:• analizy porównawczej wydajności i potencjału procesów IT wyrażonej w postaci modeli dojrzałości, opartych na modelu

dojrzałości CMM (ang. Capability Maturity Model) opracowanym przez Software Engineering Institute;• celów i mierników procesów IT służących do definiowania i pomiaru ich wyników oraz wydajności w oparciu o koncepcję

zrównoważonej karty wyników biznesowych autorstwa Roberta Kaplana i Davida Nortona;• celów czynności niezbędnych do utrzymania tych procesów pod kontrolą w oparciu o cele kontrolne metodyki CobiT.

Ocena potencjału procesu w oparciu o modele dojrzałości CobiT jest kluczowym elementem wdrożenia nadzoru informatycznego. Po określeniu krytycznych procesów IT i mechanizmów kontrolnych dalsza analiza w oparciu o modele dojrzałości umożliwia identyfikację braków w ich potencjale i poinformowanie o nich kierownictwa firmy. Na tej postawie mogą zostać opracowane plany działań, które pozwolą osiągnąć pożądany poziom funkcjonalności.

Tak więc metodyka CobiT wspomaga sprawowanie nadzoru informatycznego (ilustracja 2) poprzez stworzenie metodyki, która zapewnia, że:• działalność IT jest dostosowana do potrzeb firmy;• działalność IT wspiera działalność biznesową i maksymalizuje osiągane korzyści;• zasoby IT są wykorzystywane w odpowiedzialny sposób;• odpowiednio zarządza się ryzykiem informatycznym.

Podstawowe znaczenie dla nadzoru informatycznego ma pomiar wydajności. Jest on przewidziany w modelu CobiT i obejmuje ustalenie i monitorowanie mierzalnych celów, jakie mają osiągać procesy IT (wynik procesu), a także określenie, w jaki sposób mają je osiągać (funkcjonalność i wydajność procesu). Wiele badań wykazało, że brak przejrzystości kosztów, wartości i ryzyka informatycznego jest jednym z głównych czynników uzasadniających konieczność nadzoru informatycznego. Choć ważne są również inne obszary działań, przejrzystość uzyskuje się głównie poprzez pomiar wydajności.

W jaki sposób odpowiedzialni menedżerowie prowadzą działalność przedsiębiorstwa zgodnie z planem?

W jaki sposób przedsiębiorstwo może osiągać wyniki satysfakcjonujące dla największej możliwej liczby interesariuszy?

W jaki sposób można w odpowiednim czasie dostosować przedsiębiorstwo do trendów i rozwoju występujących w jego otoczeniu?

Wskaźniki?

Miary?

Skale?

PANEL KONTROLNY

KARTY WYNIKÓW

ANALIZY PORÓWNAWCZEJ

Ilustracja 1 — Informacje zarządcze

Ilustracja 2 — Obszary nadzoru informatycznego

• Dopasowanie strategiczne Koncentruje się na zapewnieniu powiązania między planami biznesowymi a planami IT; obejmuje definiowanie, utrzymywanie i weryfikację propozycji tworzenia wartości IT, a także dostosowywanie działalności IT do działalności przedsiębiorstwa.

• Dostarczanie wartości odnosi się do realizacji propozycji tworzenia wartości poprzez cykl dostawy, tj. zapewnienia, że technologie informatyczne dostarczą obiecane korzyści zgodnie z przyjętą strategią, koncentrując się na optymalizacji kosztów i dostarczaniu wartości nieodłącznie tkwiących w IT.

• Zarządzanie zasobami odnosi się do optymalizacji inwestycji i prawidłowego zarządzania krytycznymi zasobami IT: aplikacjami, informacjami, infrastrukturą i osobami. Kluczowe znaczenie w tej dziedzinie ma optymalizacja wiedzy i infrastruktury.

• Zarządzanie ryzykiem wymaga świadomości wyższej kadry zarządzającej o istnieniu ryzyka, właściwego zrozumienia skłonności przedsiębiorstwa do podejmowania ryzyka („apetytu na ryzyko”), zrozumienia wymagań zachowania zgodności, przejrzystości w sferze znaczącego ryzyka dla przedsiębiorstwa oraz wbudowania odpowiedzialności za zarządzanie ryzykiem w strukturę organizacyjną.

• Pomiar wydajności obejmuje śledzenie i monitorowanie wdrożenia strategii, realizacji projektów, wykorzystania zasobów, wydajności procesów i dostępności usług za pomocą np. zrównoważonych kart wyników, które umożliwiają przełożenie strategii na działania służące osiąganiu mierzalnych celów (poza konwencjonalną księgowością).


Wspomniane obszary nadzoru informatycznego opisują zagadnienia, którymi powinna zająć się kadra zarządzająca, aby sprawować nadzór informatyczny w przedsiębiorstwie. Kierownictwo operacyjne wykorzystuje procesy do organizacji i zarządzania bieżącą działalnością IT. Metodyka CobiT dostarcza ogólny model procesów, obejmujący wszystkie procesy właściwe funkcjom IT, zapewniając wspólny model odniesienia, zrozumiały dla kierownictwa operacyjnego działu IT i firmy. Model procesów CobiT został przyporządkowany do głównych obszarów ładu informatycznego (patrz Załącznik II — Przyporządkowanie procesów IT do głównych obszarów ładu informatycznego, struktury ramowej COSO, zasobów informatycznych CobiT i kryteriów informacji CobiT), zapewniając powiązanie między działaniami wykonawczymi kierowników operacyjnych a tym, co chce nadzorować kierownictwo wyższego szczebla.

Aby móc sprawować efektywny nadzór, kierownictwo wyższego szczebla powinno wymagać wprowadzenia przez kierowników operacyjnych mechanizmów kontrolnych (w ramach zdefiniowanej ramowej struktury mechanizmów kontrolnych) dla wszystkich procesów IT. Cele kontrolne IT CobiT są zorganizowane według procesów IT. Tak zdefiniowana struktura zapewnia przejrzyste powiązania między wymaganiami nadzoru informatycznego, procesami IT i mechanizmami kontrolnymi dotyczącymi IT.

Metodyka CobiT jest skoncentrowana na tym, co jest niezbędne do prawidłowego zarządzania i sprawowania kontroli nad IT, i dotyczy wysokiego poziomu zarządzania. Metodyka CobiT jest zgodna i zharmonizowana z innymi, bardziej szczegółowymi standardami i dobrymi praktykami dotyczącymi IT (patrz Załącznik IV — CobiT 4.1 – najważniejsze materiały źródłowe). Metodyka CobiT łączy w sobie wiedzę zawartą w tych materiałach, grupując najważniejsze cele w ramach jednej ramowej struktury, która jest również powiązana z potrzebą nadzoru i wymaganiami biznesowymi.

Struktura ramowa COSO (oraz podobne, zgodne z nią struktury) jest ogólnie przyjętą strukturą ramową systemu kontroli wewnętrznej dla przedsiębiorstw. Metodyka CobiT jest ogólnie przyjętą strukturą ramową systemu kontroli wewnętrznej dla IT.

Produkty CobiT zostały zostały zorganizowane na trzech poziomach (ilustracja 3), określonych z myślą o zapewnieniu wsparcia dla:• kadry zarządzającej i zarządów;• kierownictwa firm i działów IT;• specjalistów ds. nadzoru, kontroli

wewnętrznej, kontroli i bezpieczeństwa.

Produkty CobiT obejmują następujące pozycje:• Board Briefing on IT Governance, 2nd

Edition — pomaga osobom pełniącym funkcje kierownicze zrozumieć, dlaczego ład informatyczny jest ważny, jakich dotyczy zagadnień i na czym polega ich odpowiedzialność za zarządzanie nim.

• Management guidelines/maturity models — pomaga w określaniu odpowiedzialności, pomiarze wydajności oraz analizie porównawczej i eliminowaniu braków w potencjale.

• Frameworks — organizuje cele nadzoru informatycznego i dobre praktyki według domen i procesów IT oraz powiązuje je z potrzebami firmy.

• Control objectives — dostarcza pełen zestaw wymagań wysokiego poziomu, który powinno uwzględnić kierownictwo, aby sprawować efektywną kontrolę nad każdym z procesów IT.

• IT Governance Implementation Guide: Using CobiT ® and Val IT TM, 2nd Edition — przedstawia ogólny plan działania w celu wdrożenia nadzoru informatycznego z wykorzystaniem metodyki CobiT i Val ITTM.

• CobiT ® Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition — tłumaczy, dlaczego warto wdrożyć mechanizmy kontrolne oraz jak je wdrożyć.

• IT Assurance Guide: Using CobiT ®— dostarcza wskazówek, w jaki sposób metodyka CobiT może służyć do wspierania różnorodnych działań kontrolnych i omawia zalecane etapy testowania dla wszystkich procesów IT i celów kontrolnych.

Schemat zawartości metodyki CobiT przedstawiony na ilustracji 3 prezentuje podstawowe grupy odbiorców, ich pytania dotyczące nadzoru informatycznego oraz odpowiednie produkty, które dostarczają odpowiedzi. Dostępne są również produkty uzupełniające, przeznaczone do specjalnych celów i dotyczące takich dziedzin, jak bezpieczeństwo albo określonych przedsiębiorstw.

Modele dojrzałości

Wytyczne zarządzania

Board Briefing on ITGovernance, 2nd EditionW jaki

sposób zarząd wykonuje swoje obowiązki?

Kadra zarządzająca i zarządy

W jaki sposób mierzymy wydajność? W jaki sposób porównujemy się z innymi? W jaki sposób poprawiamy nasze wyniki

na przestrzeni czasu?Kierownictwo firm i działów technologicznych

Co to jest struktura nadzoru informatycznego?

W jaki sposób dokonujemy oceny struktury nadzoru informatycznego?

W jaki sposób wdrażamy tę strukturę w przedsiębiorstwie?

Specjaliści ds. nadzoru, kontroli wewnętrznej, kontroli i bezpieczeństwa

IT GovernanceImplementation Guide,

2nd Edition

COBIT Control Practices,2nd Edition

Cele mechanizmów kontrolnych

IT Assurance GuideStruktury COBIT i Val IT

Główne praktyki zarządzania

Niniejszy schemat oparty na COBIT przedstawia ogólnie stosowane produkty i ich głównych odbiorców. Istnieją również produkty pochodne do szczególnych celów (IT Control Objectives for Sarbanes-Oxley, 2 nd Edition), dla domen, takich jak bezpieczeństwo (COBIT Security Baseline and Information Security Governance: Guidance for Boards of Directors and Executive Management ), lub dla szczególnych przedsiębiorstw (COBIT Quickstart dla małych i średnich przedsiębiorstw lub dla dużych przedsiębiorstw pragnących przejść na poziom bardziej obszernego wdrażania nadzoru informatycznego).

Ilustracja 3 — Schemat zawartości metodyki CobiT

WproWadzenie


CobiT 4.1Wszystkie wspomniane komponenty metodyki CobiT są ze sobą wzajemnie powiązane i zapewniają wsparcie w realizacji potrzeb nadzoru, zarządzania, audytu i kontroli wewnętrznej różnych grup odbiorców, jak pokazano na ilustracji 4.

CobiT to metodyka wraz z zestawem pomocnych narzędzi, które umożliwiają menedżerom wypełnienie luki w obszarze wymogów kontrolnych, zagadnień technicznych i ryzyka biznesowego oraz poinformowanie interesariuszy o poziomie sprawowanej kontroli. Metodyka CobiT umożliwia rozwój przejrzystej polityki i dobrej praktyki kontroli IT w przedsiębiorstwach. Metodyka CobiT jest nieustannie aktualizowana i uzgadniana z innymi standardami i wytycznymi. Dlatego metodyka CobiT stała się platformą integrującą dobre praktyki w dziedzinie IT i ramową strukturą dla nadzoru informatycznego, która pomaga w zrozumieniu i zarządzaniu ryzykiem i korzyściami związanymi z IT. Struktura procesów w ramach metodyki CobiT i jej odnoszące się do wysokiego poziomu zarządzania, ukierunkowane na biznes podejście zapewnia całościowy wgląd w działalność IT oraz dotyczące jej decyzje, które należy podjąć.

Korzyści z wdrożenia CobiT jako metodyki sprawowania nadzoru informatycznego obejmują:• Lepsze dopasowanie poprzez ukierunkowanie na biznes.• Zrozumiały dla kierownictwa wgląd w to, co robi dział IT.• Przejrzyste pojęcia własności i odpowiedzialności dzięki ukierunkowaniu na procesy.• Ogólną akceptowalność dla stron trzecich i organów regulacyjnych.• Powszechne zrozumienie wszystkich interesariuszy dzięki wspólnemu językowi.• Spełnienie wymagań COSO dla środowiska systemu kontroli IT.

W dalszej części niniejszego dokumentu znajduje się opis metodyki CobiT oraz wszystkich podstawowych komponentów struktury CobiT, zorganizowanych według czterech domen i 34 procesów IT CobiT. Jest to praktyczny materiał podręczny dla wszystkich korzystających z pełnego wydania metodyki CobiT. Przydatne materiały pomocnicze znajdują się również w załącznikach.

Najbardziej wyczerpujące i aktualne informacje na temat metodyki CobiT i powiązanych z nią produktów, włączając narzędzia online, przewodniki wdrożeń, studia przypadków, biuletyny i materiały edukacyjne, są dostępne na stronie www.isaca.org/cobit.

wymagania

kontrolowane za pomocą

badane za pomocą

mierzone

za po

mocą

w zakre

sie wyda

jności

wykonyw

ane

na pod

stawie

w zakresie dojrzałości

wdrożone za pomocąw za

kresie

wyn

ików

informacje

uzyskane z

badane za pomocą

Cele

Cele mechanizmów kontrolnych

Testy wyników działania

mechanizmów kontrolnych

Kluczowe czynności

Praktyki w obszarze stosowania


Testy w obszarze projektowania


Modele dojrzałości

Miary wyniku

Wskaźniki wydajności

z podziałem na

oparte naTabela odpowiedzialności

i rozliczalności

biznesowe

Procesy IT

Cele IT

Ilustracja 4 — Wzajemne powiązania komponentów struktury CobiT

M e T o d y k a c o b i T

ME

To

Dy

Ka

Co

BIT


MeTodyka cobiT

Misja CobiT:Badanie, rozwój, publikowanie i promowanie miarodajnej, aktualnej i powszechnie uznanej struktury ramowej nadzoru informatycznego, do przyjęcia przez przedsiębiorstwa w celu codziennego stosowania przez kierownictwo firm, specjalistów IT oraz specjalistów ds. audytu i kontroli wewnętrznej.

POTRZEBa isTNiENia sTRUKTURY RaMOWEj sYsTEMU KONTROLi iT DLa ZaPEWNiENia NaDZORU iNFORMaTYCZNEGOStruktura ramowa systemu kontroli IT na potrzeby zapewnienia nadzoru informatycznego definiuje przyczyny, dla których niezbędny jest nadzór informatyczny, uczestniczących w nim interesariuszy oraz cele, które system kontroli IT powinien osiągać.

DlaczegoKierownictwo najwyższego szczebla w coraz większym stopniu zdaje sobie sprawę ze znaczącego wpływu informacji na sukces przedsiębiorstwa. Kierownictwo oczekuje większego zrozumienia sposobu wykorzystania technologii informatycznych oraz większego prawdopodobieństwa ich skutecznego wykorzystania do uzyskania przewagi konkurencyjnej. W szczególności kierownictwo najwyższego szczebla potrzebuje wiedzy, czy zarządzanie informacjami w przedsiębiorstwie odbywa się w taki sposób, że przedsiębiorstwo:• będzie z dużym prawdopodobieństwem osiągać swoje cele;• jest wystarczająco odporne, aby uczyć się i adaptować do nowych warunków;• rozsądnie zarządza ryzykiem, przed którym staje;• prawidłowo rozpoznaje i wykorzystuje pojawiające się możliwości.

Przedsiębiorstwa, które osiągają sukcesy, rozumieją ryzyko, wykorzystują zalety technologii informatycznych i znajdują sposoby na:• dostosowanie strategii IT do strategii biznesowej;• zapewnienie inwestorów i udziałowców, że organizacja spełnia standardy należytej dbałości o minimalizację ryzyka

informatycznego;• stopniowe wdrożenie w przedsiębiorstwie strategii IT i określenie jej celów;• uzyskanie wartości z inwestycji w IT;• stworzenie struktur organizacyjnych, które ułatwią wdrożenie strategii i celów;• stworzenie konstruktywnych relacji i zapewnienie efektywnej komunikacji między sferą biznesową i informatyczną

oraz z zewnętrznymi partnerami;• pomiar wydajności IT.

Przedsiębiorstwa nie są w stanie radzić sobie efektywnie z powyższymi wymaganiami bez przyjęcia i wdrożenia odpowiedniej struktury mechanizmów kontrolnych i nadzoru informatycznego, aby móc:• zapewnić powiązanie z wymaganiami biznesowymi;• zapewnić przejrzystość oceny spełniania tych wymagań;• zorganizować swoją działalność w ramach ogólnie akceptowanego modelu procesów;• określić główne zasoby, które mają być wykorzystywane; • zdefiniować cele kontroli zarządczej, które należy uwzględnić.

Ponadto struktury nadzoru i mechanizmów kontrolnych stają się częścią dobrej praktyki zarządzania IT i umożliwiają zaprowadzenie ładu informatycznego i zapewnienie zgodności ze stale zwiększającymi się wymaganiami regulacyjnymi.

Dobre praktyki w dziedzinie IT stały się istotne za sprawą wielu czynników:• Kierownictwa i zarządy firm wymają większego zwrotu z inwestycji w IT, tj. oczekują dostarczania przez IT tego,

czego potrzebuje firma, aby zwiększać swoją wartość w oczach interesariuszy.• Zaniepokojenie zwiększającymi się nakładami na IT.• Potrzeba sprostania wymaganiom regulacyjnym dotyczącym mechanizmów kontrolnych w sferze IT, w takich obszarach,

jak ochrona prywatności czy sprawozdawczość finansowa (np. Ustawa Sarbanesa-Oxley'a w Stanach Zjednoczonych) oraz w niektórych branżach, takich jak branża finansowa, farmaceutyczna czy ochrona zdrowia.

• Wybór dostawców usług oraz zarządzanie outsourcingiem i nabywaniem usług. • Rosnąca złożoność ryzyka informatycznego, np. związanego z bezpieczeństwem sieciowym.• Inicjatywy dotyczące nadzoru informatycznego, które uwzględniają przyjęcie struktury mechanizmów kontrolnych i dobrych

praktyk, aby wspomóc monitorowanie i doskonalenie działalności IT o krytycznym znaczeniu w celu zwiększenia wartości biznesowej i ograniczenia ryzyka biznesowego.

• Potrzeba optymalizacji kosztów poprzez stosowanie tam, gdzie to możliwe, ustandaryzowanych, a nie specjalnie opracowanych rozwiązań.• Zwiększająca się dojrzałość i wynikająca z niej akceptacja dla dobrze ugruntowanych standardów, takich jak CobiT, IT

Infrastructure Library (ITIL), ISO serii 27000 (standardy dotyczące bezpieczeństwa informacji), ISO 9001:2000 Quality Management Systems — Requirements, Capability Maturity Model® Integration (CMMI), Projects in Controlled Environments 2 (PRINCE2) oraz A Guide to the Project Management Body of Knowledge (PMBOK).

• Potrzeba dokonania oceny przez przedsiębiorstwa, jak radzą sobie z ogólnie przyjętymi standardami i jak wypadają na tle podobnych firm (analiza porównawcza).

MeTodyka CobiT

ME

To

Dy

Ka

Co

BIT


CobiT 4.1KtoStruktura nadzoru i mechanizmów kontrolnych musi służyć wielu wewnętrznym i zewnętrznym interesariuszom, z których każdy ma określone potrzeby:• Interesariusze w przedsiębiorstwie, którzy są zainteresowani generowaniem wartości z inwestycji w IT: – ci, którzy podejmują decyzje inwestycyjne; – ci, którzy decydują o wymaganiach; – ci, którzy korzystają z usług IT.• Wewnętrzni i zewnętrzni interesariusze, którzy świadczą usługi IT: – ci, którzy zarządzają organizacją IT i procesami; – ci, którzy rozwijają potencjał; – ci, którzy obsługują usługi.• Wewnętrzni i zewnętrzni interesariusze odpowiedzialni za kontrolę/zarządzanie ryzykiem: – ci, którzy odpowiadają za bezpieczeństwo, ochronę prywatności i/lub zarządzanie ryzykiem; – ci, którzy nadzorują zachowanie zgodności; – ci, którzy wymagają lub wykonują czynności kontroli wewnętrznej i audytu.

CoAby spełnić powyższe wymagania, metodyka nadzoru informatycznego i kontroli IT powinna:• Być ukierunkowana na biznes, aby zapewniać zgodność między celami biznesowymi i celami IT.• Zapewniać ukierunkowanie na procesy, aby zdefiniować zakres i stopień pokrycia wraz ze zdefiniowaną strukturą

umożliwiającą łatwe poruszanie się po zawartości.• Być ogólnie akceptowana dzięki zachowaniu zgodności z przyjętymi dobrymi praktykami i standardami w dziedzinie IT oraz

niezależna od określonych technologii.• Zapewniać wspólny język komunikacji poprzez wybór i stosowanie zbioru terminów i definicji, które są powszechnie zrozumiałe

dla wszystkich interesariuszy.• Pomagać w spełnianiu wymagań regulacyjnych poprzez zachowanie zgodności z powszechnie przyjętymi standardami ładu

korporacyjnego (np. COSO) i mechanizmami kontroli IT wymaganymi przez organy regulacyjne i zewnętrznych audytorów.

W jaKi sPOsóB METODYKa CobiT ZasPOKaja TE POTRZEBYW odpowiedzi na powyższe potrzeby opracowano metodykę CobiT, która jest ukierunkowana na biznes, zorientowana na procesy, oparta na mechanizmach kontrolnych oraz pomiarach.

Ukierunkowanie na biznesOrientacja biznesowa jest głównym zagadnieniem metodyki CobiT. Opracowano ją nie tylko na potrzeby dostawców i użytkowników usług IT oraz audytorów, ale co ważniejsze — także w celu zapewnienia kompleksowego zbioru wskazówek dla zarządzających i właścicieli procesów biznesowych.

Projekt CobiT opiera się na następującym założeniu (ilustracja 5):

Aby przedsiębiorstwo mogło zapewnić sobie dostępność informacji, których potrzebuje do osiągania swoich celów, musi inwestować w zasoby IT, zarządzać nimi i sprawować nad nimi kontrolę, wykorzystując zorganizowany zbiór procesów, aby zapewnić sobie dostępność usług, które dostarczą mu potrzebnych informacji.

Aby zapewnić dostosowanie do wymagań biznesowych, w centrum uwagi metodyki CobiT znajduje się zarządzanie i sprawowanie kontroli nad informacjami.

KRyTERIa INFoRMaCJI CobiTAby realizować cele biznesowe, informacje muszą spełniać pewne kryteria kontrolne, które w metodyce CobiT określa się jako wymagania biznesowe dla informacji. W oparciu o szersze wymogi dotyczące jakości, zasad powiernictwa i bezpieczeństwa zdefiniowano siedem różnych, częściowo pokrywających się kryteriów informacji:• Efektywność odnosi się do informacji, które są adekwatne i istotne dla procesów biznesowych, a także dostarczane w terminowy,

prawidłowy, spójny i użyteczny sposób.• Wydajność dotyczy dostarczania informacji przy optymalnym (najbardziej wydajnym i ekonomicznym) wykorzystaniu zasobów.• Poufność dotyczy ochrony wrażliwych informacji przed nieautoryzowanym użyciem.• Integralność odnosi się do dokładności i kompletności informacji, a także ich poprawności w odniesieniu do wartości

i oczekiwań biznesowych.

Wymagania biznesowe

Procesy IT

Zasoby ITInformacje o przedsiębiorstwie COBIT

które odpowiadają na

stanowią siłę napędową inwestycji w

w celu dostarczania które są wykorzystywane przez

Ilustracja 5 — Podstawowa zasada metodyki CobiT


• Dostępność odnosi się do informacji, które są dostępne wtedy, gdy są niezbędne dla procesu biznesowego — obecnie i w przyszłości. Dotyczy również mechanizmów ochrony niezbędnych zasobów i związanych z nimi możliwości.

• Zgodność dotyczy zgodności z przepisami prawa, wymaganiami regulacyjnymi i postanowieniami umów, którym podlega proces biznesowy — np. narzuconymi z zewnątrz kryteriami biznesowymi czy wewnętrzną polityką firmy.

• Wiarygodność odnosi się do dostarczania kierownictwu odpowiednich informacji, aby umożliwiać mu prowadzenie firmy i wypełnianie swoich obowiązków powierniczych i nadzorczych.

CElE BIZNESoWE I CElE ITPodczas gdy kryteria informacji dostarczają ogólnej metody definiowania wymagań biznesowych, zdefiniowanie zbioru ogólnych celów biznesowych i celów IT zapewnia ukierunkowaną biznesowo i bardziej miarodajną podstawę do określenia wymagań biznesowych i mierników, które umożliwią pomiar efektywności w osiąganiu tych celów. Każde przedsiębiorstwo wykorzystuje technologie informatyczne do realizacji inicjatyw biznesowych, co można określić mianem celów biznesowych dla IT. Załącznik I przedstawia macierz ogólnych celów biznesowych i celów IT oraz pokazuje, w jaki sposób są one przyporządkowane do kryteriów informacji. Te ogólne przykłady mogą zostać wykorzystane jako wskazówki do określenia specyficznych wymagań biznesowych, celów i mierników dla danego przedsiębiorstwa.

Jeśli IT ma skutecznie świadczyć usługi wspierające realizację strategii przedsiębiorstwa, konieczne jest przejrzyste zdefiniowanie własności i kierunku wymagań biznesowych (klient) oraz pełne zrozumienie, co i w jaki sposób powinien dostarczyć dział IT (dostawca). Ilustracja 6 pokazuje, w jaki sposób strategia przedsiębiorstwa powinna zostać przetransponowana przez firmę na cele odnoszące się do inicjatyw, których realizację umożliwia IT (cele biznesowe dla IT). Cele te powinny prowadzić do precyzyjnego sformułowania własnych celów IT (cele IT), które z kolei definiują zasoby i potencjał IT (architektura korporacyjna systemów informatycznych) niezbędny do pomyślnej realizacji części strategii przedsiębiorstwa przynależnej do IT.1

Gdy zostaną już określone wspólne cele, konieczne jest monitorowanie ich realizacji, aby odpowiadała ona oczekiwaniom. Osiąga się to poprzez mierniki, które odpowiadają poszczególnym celom i są zapisywane na karcie wyników IT.

Aby klient mógł zrozumieć cele IT i kartę wyników IT, wszystkie cele i powiązane z nimi mierniki powinny być wyrażone przy użyciu terminologii biznesowej, która jest zrozumiała dla klienta. W połączeniu z efektywnym dopasowaniem hierarchii celów zapewnia to duże prawdopodobieństwo potwierdzenia przez stronę biznesową, że IT wspiera realizację celów przedsiębiorstwa.

Załącznik I — Tabele powiązań celów i procesów przedstawiają ogólny obraz tego, jak ogólne cele biznesowe odnoszą się do celów IT, procesów IT i kryteriów informacji. Tabele ilustrują zakres metodyki CobiT i ogólne relacje biznesowe między metodyką CobiT a czynnikami wpływającymi na działalność przedsiębiorstwa. Jak pokazano na ilustracji 6, czynniki te pochodzą ze sfery biznesowej i nadzorczej przedsiębiorstwa (pierwsza koncentruje się w większym stopniu na funkcjonalności i szybkości dostarczania rozwiązań, podczas gdy druga na opłacalności, zwrocie z inwestycji (ROI) i zapewnieniu zgodności.

MeTodyka CobiT

1 Należy zauważyć, że zdefiniowanie i wdrożenie architektury IT przedsiębiorstwa wiąże się również z określeniem wewnętrznych celów IT, które przyczyniają się do realizacji celów biznesowych, ale się z nich bezpośrednio nie wywodzą.

wymagają wpływają na

powodują powstanie

Wymagania biznesowe

Kryteria informacji

Usługi informacyjne

Wymagania dotyczące nadzoru

dostarczają

wymagają

uruchamiająProcesy IT

Infrastruktura i osoby

Aplikacje

Informacje

Cele biznesowe IT Architektura korporacyjna IT

Karta wynikówIT

Cele biznesowe IT Cele IT

Architektura korporacyjna

IT

Strategia przedsiębiorstwa

Ilustracja 6 — Definiowanie celów IT i architektury IT przedsiębiorstwa


CobiT 4.1ZaSoBy ITOrganizacja IT realizuje wyznaczone cele poprzez jasno zdefiniowany zbiór procesów, które wykorzystują ludzkie umiejętności i infrastrukturę techniczną do zapewnienia działania zautomatyzowanych aplikacji biznesowych, jednocześnie wykorzystując informacje biznesowe. Zasoby te wraz z procesami tworzą architekturę korporacyjną systemów informatycznych (jak pokazano na ilustracji 6).

Aby móc spełnić wymagania biznesowe wobec IT, przedsiębiorstwo musi zainwestować w zasoby niezbędne do stworzenia adekwatnego potencjału technicznego (np. systemu planowania zasobów przedsiębiorstwa (ERP)), mogącego zapewnić wsparcie dla potencjału biznesowego (np. wdrożenie łańcucha dostaw), czego efektem jest osiągnięcie pożądanego rezultatu (np. zwiększenie sprzedaży i zysków).

Zasoby IT określone w ramach metodyki CobiT można zdefiniować w następujący sposób:• aplikacje to zautomatyzowane systemy użytkownika i procedury manualne, które służą do przetwarzania informacji.• Informacje to dane we wszystkich postaciach, wprowadzane, przetwarzane i dostarczane przez systemy informatyczne w dowolnej formie wykorzystywanej przez firmę. • Infrastruktura to technologia i środki (tj. sprzęt, systemy operacyjne, systemy zarządzania bazami danych, sieci, multimedia

oraz środowisko, w którym się one znajdują i które je wspiera), które umożliwiają przetwarzanie danych przez aplikacje.• osoby to pracownicy niezbędni do planowania, organizacji, nabywania, wdrażania, dostarczania, zapewniania wsparcia,

monitorowania i oceny systemów i usług informatycznych. Zależnie od potrzeb, mogą być to pracownicy wewnętrzni, zewnętrzni lub kontraktowi.

Ilustracja 7 pokazuje, jak jaki sposób cele biznesowe dla IT wpływają na to, jak powinno przebiegać zarządzanie zasobami IT przez procesy IT, aby osiągnąć cele IT.

Orientacja na procesyMetodyka CobiT definiuje działalność IT w ramach ogólnego modelu procesów w czterech domenach (dziedzinach). Domeny te to Planowanie i organizacja, Nabywanie i wdrażanie, Dostarczanie i wsparcie oraz Monitorowanie i ocena. Domeny odpowiadają tradycyjnym obszarom odpowiedzialności IT: planowania, budowy, obsługi i monitorowania.

Metodyka CobiT zapewnia model odniesienia dla procesów i wspólny język komunikacji dla wszystkich osób w przedsiębiorstwie, aby przyglądać się działaniu IT i zarządzać nim. Wprowadzenie modelu operacyjnego i wspólnego języka komunikacji we wszystkich obszarach firmy związanych z IT jest jednym z najważniejszych początkowych kroków w kierunku odpowiedniego nadzoru. Zapewnia to również strukturę ramową dla pomiaru i monitorowania wydajności IT, komunikacji z dostawcami usług oraz wdrażania najlepszych praktyk zarządzania. Model procesów zachęca również do zdefiniowania własności procesów, zakresów odpowiedzialności i rozliczalności.

Dla efektywnego nadzoru nad działalnością IT istotne jest określenie rodzajów działalności i ryzyka w obszarze IT, którymi należy zarządzać. Zwykle są one podzielone na obszary odpowiedzialności w zakresie planowania, budowy, obsługi i monitorowania. W metodyce CobiT obszary te (domeny), jak pokazano na ilustracji 8, określane są jako:• Planowanie i organizacja (Po) — określa kierunek dla dostarczania

rozwiązań (AI) i świadczenia usług (DS).• Nabywanie i wdrażanie (aI) — obejmuje dostarczanie rozwiązań

i przekazywanie ich w celu zamiany w usługi.• Dostarczanie i wsparcie (DS) — obejmuje odbiór rozwiązań

i przystosowanie ich, aby były użyteczne dla użytkowników końcowych.

• Monitorowanie i ocena (ME) — obejmuje monitorowanie wszystkich procesów, aby zapewnić podążanie w określonym kierunku.

PlaNoWaNIE I oRGaNIZaCJa (Po)Domena ta, obejmująca zagadnienia strategiczne i taktyczne, dotyczy określenia sposobu, w jaki działalność IT mogłaby najlepiej przyczynić się do osiągnięcia celów biznesowych. Realizacja wizji strategicznej powinna być planowana, komunikowana i zarządzana z uwzględnieniem różnych perspektyw. Wymaga również zapewnienia odpowiedniej organizacji i infrastruktury technicznej. Domena ta zwykle odpowiada na następujące pytania związane z zarządzaniem:• Czy strategia IT jest dostosowana do strategii biznesowej?• Czy przedsiębiorstwo w optymalny sposób wykorzystuje swoje zasoby?• Czy wszyscy w organizacji rozumieją cele IT?• Czy znane jest ryzyko IT i czy zarządza się nim?• Czy jakość systemów informatycznych jest odpowiednia do potrzeb firmy?

Cele przedsiębiorstwa

Procesy IT

Cele IT

Czynniki nadzoru

Wyniki działalności

Osob

y

Infra

stru

ktur

a

Info

rmac

ja

Aplik

acje

Ilustracja 7 — Zarządzanie zasobami IT w celu osiągania celów IT

Planowanie i organizacja

Nabywanie i

wdrażanie

Dostarczanie i

wsparcie

Monitorowanie i ocena

Ilustracja 8 — Cztery powiązane domeny metodyki CobiT


NaByWaNIE I WDRażaNIE (aI)Aby możliwa była realizacja strategii IT, konieczne jest określenie i stworzenie lub nabycie rozwiązań informatycznych, a następnie ich wdrożenie i zintegrowanie z procesem biznesowym. Ponadto domena ta obejmuje również zmiany i utrzymanie istniejących systemów, aby mogły one nadal realizować cele biznesowe. Domena ta zwykle odpowiada na następujące pytania związane z zarządzaniem:• Czy nowe projekty są w stanie dostarczyć rozwiązania, które będą spełniać potrzeby firmy?• Czy nowe projekty mogą być zrealizowane terminowo i w ramach budżetu?• Czy nowe systemy po ich wdrożeniu będą działać prawidłowo?• Czy można wprowadzić zmiany bez zakłócania bieżącej działalności biznesowej?

DoSTaRCZaNIE I WSPaRCIE (DS)Domena ta dotyczy rzeczywistego dostarczania potrzebnych usług, które obejmuje świadczenie usług, zarządzanie bezpieczeństwem i ciągłością, wsparcie techniczne dla użytkowników oraz zarządzanie danymi i infrastrukturą operacyjną. Zwykle odpowiada ona na następujące pytania związane z zarządzaniem:• Czy usługi IT są dostarczane zgodnie z priorytetami biznesowymi?• Czy koszty IT są zoptymalizowane?• Czy pracownicy są w stanie korzystać z systemów IT w produktywny i bezpieczny sposób?• Czy zapewniona jest odpowiednia poufność, integralność i dostępność gwarantująca bezpieczeństwo informacji?

MoNIToRoWaNIE I oCENa (ME)Wszystkie procesy IT powinny być regularnie poddawane ocenie pod kątem ich jakości i zgodności z wymaganiami kontrolnymi. Domena ta obejmuje kwestie zarządzania wydajnością, monitorowania systemu kontroli, zgodności z wymaganiami regulacyjnymi i nadzoru. Zwykle odpowiada ona na następujące pytania związane z zarządzaniem:• Czy wydajność IT podlega pomiarowi, aby wykrywać problemy zanim jest za późno?• Czy kierownictwo dba o to, aby wewnętrzne mechanizmy kontrolne były efektywne i wydajne?• Czy efekty działalności IT można powiązać z celami biznesowymi?• Czy istnieją odpowiednie mechanizmy kontroli poufności, integralności i dostępności w celu zapewnienia bezpieczeństwa

informacji?

W ramach tych czterech domen metodyka CobiT wyodrębnia 34 ogólnie stosowane procesy IT (ich pełną listę przedstawiono na ilustracji 23). Podczas gdy większość przedsiębiorstw ma zdefiniowane wymagania dotyczące obowiązków w zakresie planowania, budowy, obsługi i monitorowania w dziedzinie IT i większość wykorzystuje te same kluczowe procesy, niewiele z nich ma taką samą strukturę procesów lub stosuje wszystkie 34 procesy CobiT. Metodyka CobiT obejmuje pełną listę procesów, które mogą zostać wykorzystane w celu weryfikacji kompletności czynności i obowiązków. Nie wszystkie jednak one muszą mieć zastosowanie, a co więcej, każde przedsiębiorstwo może wykorzystywać je w wybranej przez siebie kombinacji.

Każdy z 34 procesów został powiązany ze wspieranymi celami biznesowymi i celami IT. Uwzględniono również informacje o tym, w jaki sposób można dokonywać pomiaru realizacji celów, jakie są kluczowe czynności i najważniejsze efekty oraz kto jest za nie odpowiedzialny.

Oparcie na mechanizmach kontrolnychMetodyka CobiT definiuje cele kontrolne dla wszystkich 34 procesów, a także cele wspólne dla wszystkich procesów oraz cele dla aplikacyjnych mechanizmów kontrolnych.

PRoCESy WyMaGaJą MEChaNIZMóW KoNTRolNyChMechanizmy kontrolne są definiowane jako polityki, procedury, praktyki i struktury organizacyjne stworzone w celu racjonalnego zapewnienia realizacji celów biznesowych oraz zapobiegnięcia lub wykrycia i przeciwdziałania skutkom niepożądanych zdarzeń.

Cele kontrolne IT obejmują pełen zestaw wymagań wysokiego poziomu, które powinno uwzględnić kierownictwo, aby sprawować efektywną kontrolę nad poszczególnymi procesami IT. Cele kontrolne:• to opisy działań zarządczych mających na celu zwiększenie wartości lub zmniejszenie ryzyka;• obejmują polityki, procedury, praktyki i struktury organizacyjne;• są określone w celu racjonalnego zapewnienia realizacji celów biznesowych oraz zapobiegnięcia lub wykrycia i przeciwdziałania

skutkom niepożądanych zdarzeń.

Kierownictwo firmy dokonuje wyborów dotyczących celów kontrolnych poprzez:• wybór tych, które są właściwe;• podjęcie decyzji, które z nich zostaną wdrożone;• wybór sposobu ich wdrożenia (częstotliwość, zakres, automatyzacja itp.);• akceptację ryzyka niewdrożenia celów, które mogą mieć zastosowanie.

MeTodyka CobiT


CobiT 4.1Pewną wskazówką może być standardowy model kontroli przedstawiony na ilustracji 9. Ilustruje on zasady rządzące następującą analogią: Gdy zostaje ustawiona temperatura pokojowa (standard) dla systemu ogrzewania (proces), system stale sprawdza (porównuje) temperaturę w pokoju (informacje kontrolne) i przekazuje sygnały (działanie) do systemu ogrzewania, aby ten dostarczył więcej lub mniej ciepła.

Kierownictwo operacyjne wykorzystuje procesy do organizacji i zarządzania bieżącą działalnością IT. Metodyka CobiT opisuje ogólny model procesów, obejmujący wszystkie procesy właściwe funkcjom IT, zapewniając wspólny model odniesienia, zrozumiały dla kierownictwa operacyjnego działu IT i firmy. Aby możliwe było sprawowanie efektywnego nadzoru, konieczne jest wprowadzenie przez kierowników operacyjnych mechanizmów kontrolnych (w ramach zdefiniowanego systemu kontroli) dla wszystkich procesów IT. Ponieważ cele kontrolne IT CobiT są zorganizowane według procesów IT, metodyka zapewnia przejrzyste powiązania między wymaganiami nadzoru informatycznego, procesami IT i mechanizmami kontrolnymi dotyczącymi IT.

Każdy z procesów IT CobiT ma odpowiedni opis i kilka celów kontrolnych. Razem składają się one na charakterystykę dobrze zarządzanego procesu.

Cele kontrolne są oznaczone dwuliterowym kodem domeny (PO, AI, DS i ME) oraz numerem procesu i numerem celu kontrolnego. Oprócz celów kontrolnych każdego procesu IT CobiT określone są również ogólne wymagania kontrolne, które są oznaczone numerami PCn (numery ogólnych mechanizmów kontrolnych wspólne dla każdego procesu). Aby mieć pełny obraz wymagań kontrolnych, należy je rozpatrywać łącznie z celami kontrolnymi procesu.

PC1 Cele procesuZdefiniować i przekazać konkretne, mierzalne, przekładalne na działania, realistyczne, zorientowane na efekty i aktualne (SMARRT) cele procesu, aby zapewnić efektywną realizację każdego z procesów IT. Zapewnić ich powiązanie z celami biznesowymi i wsparcie przez odpowiednie mierniki.

PC2 Własność procesuOkreślić właściciela każdego z procesów IT i jasno zdefiniować jego role i obowiązki. Uwzględnić np. odpowiedzialność za projekt procesu, interakcje z innymi procesami, rozliczalność końcowych efektów, pomiar wydajności procesu oraz określenie możliwości doskonalenia.

PC3 Powtarzalność procesuZaprojektować i wdrożyć każdy z kluczowych procesów IT w taki sposób, aby był on powtarzalny i stale zapewniał oczekiwane rezultaty. Określić logiczną i jednocześnie elastyczną i skalowalną sekwencję czynności, która będzie prowadzić do uzyskania pożądanych rezultatów, będąc przy tym wystarczająco sprawną, aby sprostać różnym oczekiwaniom i zagrożeniom. Tam gdzie to możliwe zastosować jednorodne procesy i dostosowywać je tylko wtedy, gdy jest to nieuniknione.

PC4 Role i obowiązkiZdefiniować kluczowe czynności i końcowe efekty procesu. Przydzielić i zakomunikować jednoznaczne role i obowiązki w celu efektywnego i wydajnego wykonywania i udokumentowania kluczowych czynności oraz zapewnienia rozliczalności końcowych efektów procesu.

PC5 Polityka, plany i proceduryOkreślić i poinformować, w jaki sposób wszystkie polityki, plany i procedury, które stymulują proces IT, będą dokumentowane, weryfikowane, utrzymywane, zatwierdzane, przechowywane, komunikowane i wykorzystywane do szkolenia. Określić odpowiedzialność za każdą z tych czynności i w odpowiednim czasie zweryfikować, czy są one prawidłowo wykonywane. Zapewnić, by polityki, plany i procedury były dostępne, prawidłowe, zrozumiałe i aktualne.

PC6 Doskonalenie wydajności procesuOkreślić zestaw mierników, które umożliwią ocenę wyników i wydajności procesu. Określić docelowe wartości, które odzwierciedlają cele procesu oraz wskaźniki wydajności, które umożliwiają osiągnięcie celów procesu. Określić, w jaki sposób będą pozyskiwane dane. Porównać rzeczywiste pomiary z docelowymi wartościami i w razie potrzeby podjąć działania w celu wyeliminowania odchyleń. Dostosować mierniki, docelowe wartości i metody do stosowanego podejścia do monitorowania ogólnej wydajności IT.

Efektywne mechanizmy kontrolne ograniczają ryzyko, zwiększają prawdopodobieństwo dostarczenia wartości i zapewniają poprawę wydajności dzięki zmniejszeniu liczby błędów i bardziej spójnemu podejściu do zarządzania.

Ponadto metodyka CobiT podaje dla każdego procesu przykłady, które go ilustrują, ale nie w normatywny czy wyczerpujący sposób. Zawierają one:• Ogólne parametry wejściowe i wyjściowe• Czynności i wskazówki dotyczące ról i obowiązków ujęte w ramach modelu RACI (ang. Responsible — Odpowiedzialny,

Accountable — Rozliczany, Consulted — Konsultujący, Informed — Informowany)• Kluczowe cele czynności (najważniejsze rzeczy do zrobienia)• Mierniki

DZIAŁANIE

KONTROLOWANIE INFORMACJI

Normy Standardy Cele

ProcesPorównywanie

Ilustracja 9 — Model kontroli


Oprócz świadomości niezbędnych mechanizmów kontrolnych, właściciele procesów powinni wiedzieć, jakiego wkładu potrzebują od innych oraz czego inni potrzebują od ich procesu. Metodyka CobiT zawiera również ogólne przykłady najważniejszych elementów wejściowych i wyjściowych dla każdego procesu, włączając zewnętrzne wymagania IT. Istnieją pewne elementy wyjściowe, które stanowią wkład wejściowy do wszystkich innych procesów (oznaczone jako „WSZYSTKIE” w tabelach elementów wyjściowych), ale nie są one wymienione jako elementy wejściowe we wszystkich procesach i zwykle obejmują standardy jakościowe i wymagania dotyczące mierników, strukturę procesu IT, udokumentowane role i obowiązki, strukturę mechanizmów kontrolnych IT przedsiębiorstwa, polityki IT oraz role i obowiązki personelu.

Zrozumienie ról i obowiązków dla każdego procesu jest kluczem do efektywnego nadzoru. Metodyka CobiT zawiera tabele RACI dla poszczególnych procesów. W modelu tym „rozliczany” (ang. accountable) oznacza osobę, która wskazuje kierunek i zatwierdza daną czynność. „odpowiedzialny” (ang. responsible) to natomiast osoba, która wykonuje dane zadanie. Pozostałe dwie role — „konsultujący” (ang. consulted) i „informowany” (ang. informed) — dotyczą wszystkich osób, które są zaangażowane w proces i wspierają go.

BIZNESoWE I INFoRMaTyCZNE MEChaNIZMy KoNTRolNEWewnętrzne mechanizmy kontrolne przedsiębiorstwa mają wpływ na działalność IT na trzech poziomach:• Na poziomie kadry zarządzającej ustalane są cele biznesowe i polityki, a także podejmowane decyzje, w jaki sposób rozlokować

i zarządzać zasobami przedsiębiorstwa, aby realizować jego strategię. Ogólne podejście do nadzoru i kontroli jest określane przez zarząd i komunikowane w całym przedsiębiorstwie. Te ustalone na najwyższym poziomie cele i polityki mają bezpośredni wpływ na środowisko kontrolne IT.

• Na poziomie procesów biznesowych mechanizmami kontrolnymi objęte są określone czynności biznesowe. Większość procesów biznesowych jest zautomatyzowana i zintegrowana z systemami aplikacji IT, co oznacza, że wiele mechanizmów kontrolnych na tym poziomie jest także zautomatyzowanych. Te mechanizmy kontrolne określa się mianem aplikacyjnych mechanizmów kontrolnych. Jednak niektóre mechanizmy kontrolne w ramach procesu biznesowego, takie jak autoryzowanie do wykonywania transakcji, rozdzielanie obowiązków czy uzgodnienia stanów, pozostają procedurami manualnymi. Dlatego mechanizmy kontrolne na poziomie procesu biznesowego stanowią połączenie manualnych mechanizmów kontrolnych obsługiwanych przez stronę biznesową oraz zautomatyzowanych biznesowych i aplikacyjnych mechanizmów kontrolnych. Wszystkie one są definiowane i zarządzane przez stronę biznesową, jednak aplikacyjne mechanizmy kontrolne wymagają działań na poziomie IT związanych z ich zaprojektowaniem i zaprogramowaniem w aplikacji.

• Aby wspierać procesy biznesowe, dział IT świadczy usługi IT — zwykle w postaci usługi wspólnej dla wielu procesów biznesowych, ponieważ wiele procesów programistycznych i operacyjnych IT jest przeznaczonych dla całego przedsiębiorstwa, a znaczna część infrastruktury IT jest udostępniana jako usługa wspólna (np. sieci, bazy danych, systemy operacyjne czy pamięć masowa). Mechanizmy kontrolne obejmujące wszystkie czynności usługowe IT określa się mianem ogólnych mechanizmów kontrolnych IT. Niezawodne działanie ogólnych mechanizmów kontrolnych jest niezbędne, aby móc zaufać działaniu aplikacyjnych mechanizmów kontrolnych. Na przykład niewłaściwe Zarządzanie zmianami może zagrażać (przypadkowo lub celowo) niezawodności zautomatyzowanych kontroli integralności.

oGólNE MEChaNIZMy KoNTRolNE IT I aPlIKaCyJNE MEChaNIZMy KoNTRolNEOgólne mechanizmy kontrolne to mechanizmy kontrolne wbudowane w procesy i usługi IT. Przykłady adresują:• Rozwój systemów• Zarządzanie zmianą• Bezpieczeństwo• Operacje komputerowe

Mechanizmy kontrolne wbudowane w aplikacje procesów biznesowych określa się zwykle mianem aplikacyjnych mechanizmów kontrolnych. Ich przykłady to:• Kompletność• Dokładność• Ważność• Autoryzacja• Rozdzielenie obowiązków

Metodyka CobiT zakłada, że projektowanie i wdrażanie zautomatyzowanych aplikacyjnych mechanizmów kontrolnych należy do zakresu obowiązków działu IT i mieści się w domenie „Nabywanie i wdrażanie” zgodnie z wymaganiami biznesowymi określonymi na podstawie kryteriów informacji CobiT, jak pokazano na ilustracji 10. Zarządzanie operacyjne i odpowiedzialność za nadzorowanie aplikacyjnych mechanizmów kontrolnych nie jest domeną IT, lecz należy do właściciela procesu biznesowego.

Dlatego odpowiedzialność za aplikacyjne mechanizmy kontrolne należy od początku do końca do wspólnego zakresu odpowiedzialności sfery biznesowej i IT, ale charakter odpowiedzialności zmienia się w następujący sposób:• Sfera biznesowa jest odpowiedzialna za prawidłowe: – zdefiniowanie wymagań funkcjonalnych i kontrolnych; – korzystanie ze zautomatyzowanych usług.• Dział IT jest odpowiedzialny za: – zautomatyzowanie i wdrożenie biznesowych wymagań funkcjonalnych i kontrolnych; – ustanowienie mechanizmów kontrolnych w celu utrzymywania integralności aplikacyjnych mechanizmów kontrolnych.

Dlatego procesy IT CobiT obejmują ogólne mechanizmy kontrolne oraz te aspekty aplikacyjnych mechanizmów kontrolnych, które związane są z ich tworzeniem; odpowiedzialność za ich definiowanie i wykorzystanie operacyjne spoczywa na sferze biznesowej.

MeTodyka CobiT


CobiT 4.1

Poniższa lista zawiera zbiór zalecanych celów dla aplikacyjnych mechanizmów kontrolnych. Są one oznaczone numerami ACn (numery aplikacyjnych mechanizmów kontrolnych).

AC1 Przygotowanie i autoryzacja danych źródłowychZapewnić, by dokumenty źródłowe były przygotowywane przez upoważniony i wykwalifikowany personel zgodnie z ustalonymi procedurami i z uwzględnieniem odpowiedniego rozdziału obowiązków wobec pochodzenia i zatwierdzania tychże dokumentów. Błędy i przeoczenia można zminimalizować poprzez zaprojektowanie odpowiedniego formularza wprowadzania danych. Wykrywać błędy i odstępstwa, aby można było je zgłosić i poprawić.

AC2 Gromadzenie i wprowadzanie danych źródłowychZapewnić, by dane były wprowadzane w odpowiednim czasie przez upoważniony i wykwalifikowany personel. Korygowanie i ponowne wprowadzanie danych, które zostały błędnie wprowadzone, powinno odbywać się bez obniżania pierwotnych poziomów autoryzacji transakcji. Jeśli jest to konieczne do rekonstrukcji, należy zachować przez odpowiednio długi czas oryginalne dokumenty źródłowe.

AC3 Kontrola dokładności, kompletności i autentycznościZapewnić, by transakcje były dokładne, kompletne i poprawne. Zweryfikować poprawność wprowadzonych danych i zmodyfikować je lub odesłać je do poprawy możliwie jak najbliżej punktu powstania.

AC4 Integralność i poprawność przetwarzaniaZachować integralność i poprawność danych przez cały cykl przetwarzania. Wykrycie błędnych transakcji nie powinno zakłócać przetwarzania prawidłowych transakcji.

AC5 Ocena efektów, uzgadnianie i postępowanie z błędamiUstanowić procedury i powiązane obowiązki, aby zapewnić: uprawnione obchodzenie się z danymi wyjściowymi, dostarczanie ich właściwym odbiorcom oraz ich ochronę podczas przesyłania; weryfikację, wykrywanie i korygowanie niedokładności danych wyjściowych; właściwe wykorzystanie informacji zawartych w danych wyjściowych.

AC6 Uwierzytelnianie i integralność transakcji Przed przekazaniem danych transakcyjnych między wewnętrznymi aplikacjami a funkcjami biznesowymi/operacyjnymi (lub na zewnątrz przedsiębiorstwa) należy sprawdzić poprawność ich adresowania, autentyczność pochodzenia oraz integralność zawartości. Zapewnić zachowanie autentyczności i integralności podczas przesyłania lub transportu.


Ogólne mechanizmy kontroli IT

Odpowiedzialność w obszarze ITOdpowiedzialność

w sferze biznesuOdpowiedzialność

w sferze biznesu

Zautomatyzowane usługi

Nabywaniei

wdrażanie

Dostarczanie i

wsparcie


Aplikacyjne mechanizmy kontrolne

Wymagania funkcjonalne

Wymagania kontrolne

Biznesowe mechanizmy

kontrolne

Biznesowe mechanizmy

kontrolne

Ilustracja 10 — Granice między mechanizmami kontroli wewnętrznej, aplikacyjnej oraz ogólnymi mechanizmami kontroli IT w przedsiębiorstwie


Oparcie na pomiarachPodstawową potrzebą każdego przedsiębiorstwa jest zrozumienie stanu swoich systemów IT i podjęcie decyzji co do poziomu zarządzania i kontroli, jaki powinno im zapewnić. W celu wybrania właściwego poziomu, przedsiębiorstwo powinno zadać sobie pytanie: jak daleko powinniśmy się posunąć i czy koszty są uzasadnione korzyściami?

Uzyskanie obiektywnego obrazu wydajności własnej działalności nie jest łatwe. Co powinno podlegać pomiarowi i w jaki sposób? Przedsiębiorstwa potrzebują wskaźników mówiących, w którym miejscu się znajdują i gdzie niezbędna jest poprawa. Powinny także wdrożyć zestaw narzędzi zarządzania, aby monitorować osiągany postęp.Metodyka CobiT zajmuje się tymi zagadnieniami, dostarczając:• Modele dojrzałości, które umożliwiają analizę porównawczą i określenie niezbędnego poszerzenia potencjału.• Cele w zakresie wydajności i mierniki dla procesów IT, które pozwalają ocenić, w jaki sposób procesy realizują cele biznesowe

i IT, i są używane do pomiaru wydajności wewnętrznych procesów w oparciu o metodę zrównoważonej karty wyników.• Cele czynności dla zapewnienia efektywnego przebiegu procesów.

MoDElE DoJRZaŁośCI Wyższa kadra kierownicza w prywatnych i publicznych przedsiębiorstwach coraz częściej staje przed koniecznością oceny jakości zarządzania działalnością IT. W celu znalezienia odpowiedzi należy opracować przykłady biznesowe, w których osiągnięto poprawę oraz odpowiedni poziom zarządzania i kontroli nad infrastrukturą informatyczną. Jeśli niektórzy mają wątpliwości, czy jest to właściwe postępowanie, powinni dokonać rachunku kosztów i korzyści oraz odpowiedzieć na następujące pytania:• Co robią nasi konkurenci z branży i jak wypadamy na ich tle?• Jakie dobre praktyki są przyjęte w branży i jak wypadamy na ich tle?• Czy na podstawie tych porównań można powiedzieć, że wypadamy wystarczająco dobrze?• W jaki sposób możemy stwierdzić, co należy zrobić, aby osiągnąć odpowiedni poziom zarządzania i kontroli nad naszymi

procesami IT?

Udzielenie rzeczowych odpowiedzi na te pytania może być trudnym zadaniem. W odpowiedzi na potrzebę uzyskania wiedzy, co należałoby robić w bardziej wydajny sposób, kierownictwo IT stale poszukuje narzędzi porównawczych i służących samoocenie. Opierając się na modelu procesów CobiT, właściciel procesu powinien mieć możliwość dokonywania stopniowych porównań z celem kontrolnym. Pozwala to zrealizować trzy potrzeby:1. Uzyskanie względnego miernika aktualnej sytuacji przedsiębiorstwa.2. Określenie sposobu efektywnego decydowania o tym, w jakim należy podążać kierunku.3. Uzyskanie narzędzia do pomiaru postępu względem celu.

Modelowanie dojrzałości na potrzeby zarządzania i sprawowania kontroli nad procesami IT opiera się na metodzie oceny organizacji. Jej stopień dojrzałości może być oceniony w skali od 0 (brak) do 5 (optymalna). Podejście to opiera się ma modelu dojrzałości opracowanym przez Software Engineering Institute (SEI) na potrzeby oceny dojrzałości potencjału (zdolności do) rozwijania oprogramowania. Mimo nawiązania do koncepcji SEI, jej realizacja w ramach metodyki CobiT znacząco różni się od pierwotnego podejścia SEI, które było ukierunkowane na zasady projektowania oprogramowania, organizacje dążące do osiągnięcia doskonałości w tej dziedzinie oraz formalną ocenę poziomów dojrzałości, która umożliwiłaby „certyfikowanie” programistów. Metodyka CobiT zawiera ogólną definicję skali dojrzałości CobiT, która jest podobna do skali CMM, ale odnosi się do natury procesów zarządzania IT CobiT. Z tej ogólnej skali zostały wyprowadzone szczegółowe modele dla wszystkich 34 procesów CobiT. Niezależnie od modelu skale nie powinny być zbyt szczegółowe, ponieważ mogłoby to uczynić system zbyt trudnym w użyciu i sugerować precyzję, która nie jest uzasadniona. A generalnym celem jest stwierdzenie, gdzie występują problemy i w jaki sposób określić priorytety, aby uzyskać poprawę. Celem nie jest natomiast ocena stopnia zgodności z celami kontrolnymi.

Stopnie dojrzałości zostały określone jako profile procesów IT, które przedsiębiorstwo może interpretować jako opisy możliwych obecnych i przyszłych stanów. Nie mają one charakteru modelu progowego, w którym nie można przejść do następnego, wyższego poziomu bez spełnienia wszystkich warunków niższego poziomu. W odróżnieniu od pierwotnego podejścia SEI CMM, modele dojrzałości CobiT nie mają na celu precyzyjnego pomiaru poziomów ani poświadczania, że dany poziom został osiągnięty Ocena dojrzałości CobiT służy bardziej do tworzenia profilu, w którym spełnione są warunki odpowiadające kilku poziomom dojrzałości, jak pokazano na przykładzie na ilustracji 11.

MeTodyka CobiT


Dzieje się tak dlatego, ponieważ często ocena dojrzałości z wykorzystaniem modeli CobiT wykazuje, że dana implementacja znajduje się na kilku różnych poziomach, nawet jeśli nie jest kompletna ani wystarczająca. Jej mocne strony mogą być więc wykorzystane do dalszego rozwoju w celu podniesienia poziomu dojrzałości. Na przykład niektóre części procesu mogą być dobrze zdefiniowanie i nawet jeśli jest on niekompletny, błędem byłoby stwierdzenie, że nie jest w ogóle zdefiniowany.

Wykorzystując modele dojrzałości opracowane dla wszystkich 34 procesów IT CobiT, kierownictwo może określić:• Rzeczywistą wydajność przedsiębiorstwa — w którym miejscu znajduje się obecnie.• Aktualny stan branży — porównanie.• Cel dla doskonalenia przedsiębiorstwa — w którym miejscu przedsiębiorstwo chce być.• Pożądaną ścieżkę rozwoju od „tak jest” do „tak powinno być”.

Aby uzyskane rezultaty można było łatwo wykorzystać na odprawach kierownictwa, gdzie będą służyć jako wsparcie dla uzasadnienia biznesowego przyszłych planów, należy zastosować graficzną formę prezentacji (ilustracja 12).

Schemat graficzny wykorzystuje opisy zawarte w ogólnym modelu dojrzałości przedstawionym na ilustracji 13.

CobiT to metodyka opracowana na potrzeby zarządzania procesami IT, która kładzie silny nacisk na kontrolę. Skale dojrzałości muszą być praktyczne w zastosowaniu i stosunkowo łatwe do zrozumienia. Zagadnienie zarządzania procesami IT jest samo w sobie złożone i subiektywne, dlatego najlepszym podejściem jest dokonanie moderowanej oceny, która podnosi świadomość, pozwala osiągnąć szeroki konsensus i motywuje do wprowadzenia udoskonaleń. Oceny tej można dokonać albo na podstawie opisów poziomów dojrzałości traktowanych całościowo, albo w bardziej rygorystyczny sposób, tj. odnosząc się oddzielnie do każdego ze stwierdzeń zawartych w opisach. W każdym przypadku niezbędna jest odpowiednia znajomość procesu, który podlega ocenie.

Zaletą podejścia opartego na modelu dojrzałości jest to, że umożliwia ono stosunkowo łatwe określenie miejsca przedsiębiorstwa na skali dojrzałości i stwierdzenie, co jest niezbędne do poprawy aktualnej pozycji. Skala uwzględnia wartość 0, ponieważ możliwe jest, że dany proces w ogóle w przedsiębiorstwie nie istnieje. Skala od 0 do 5 jest oparta na prostej skali dojrzałości, która pokazuje, w jaki sposób proces ewoluuje od stanu nieistnienia do stanu optymalnych możliwości.

CobiT 4.1

OBJAŚNIENIE UŻYTYCH SYMBOLI OBJAŚNIENIE UŻYTYCH RANKINGÓW

Nieistniejące

0

Początkowe/

1

Powtarzalne, lecz intuicyjnedoraźne

2

Zdefiniowany proces

3

Kontrolowane i mierzalne

4

Zoptymalizowane

5

0—Procesy zarządzania nie są w ogóle stosowane.1—Procesy są doraźne i zdezorganizowane.2—Procesy mają regularną strukturę.3—Procesy są dokumentowane, a informacje o nich są przekazywane.4—Procesy są monitorowane i mierzone.5—Dobre praktyki są przestrzegane i zautomatyzowane.

Obecny status przedsiębiorstwa

Średnia dla branży

Cel przedsiębiorstwa

Ilustracja 12 — Graficzny schemat modeli dojrzałości

0,7

0,6

0,5

0,4

0,3

0,2

0,1

0Poziom 1

modelu dojrzałościPoziom 2




modelu dojrzałości

Możliwy poziom dojrzałości procesu IT Przykład ten przedstawia proces odbywający się głównie na poziomie 3, w którym nadal jednak występują problemy dotyczące zgodności z wymaganiami w zakresie niższych poziomów, podczas gdy proces ten zawiera już elementy pomiaru wydajności

(poziom 4) i optymalizacji (poziom 5).

Ilustracja 11 — Możliwe poziomy dojrzałości procesu IT


Jednak zdolność do zarządzania procesem nie jest tym samym co wydajność procesu. Być może wymagana zdolność, określona przez cele biznesowe i cele IT, nie musi odnosić się w jednakowym stopniu do całego środowiska IT, lecz np. tylko do ograniczonej liczby systemów lub jednostek. Pomiar wydajności, jak zostanie to omówione poniżej, ma kluczowe znaczenie dla określenia aktualnej efektywności działania przedsiębiorstwa w zakresie procesów IT.

Choć odpowiednio wykorzystywana zdolność zarządzania zmniejsza ryzyko, przedsiębiorstwo nadal musi analizować, jakie mechanizmy kontrolne są niezbędne dla ograniczenia ryzyka adekwatnie do jego skłonności do podejmowana ryzyka i do celów biznesowych. Mechanizmy te są wytyczane celami kontrolnymi CobiT. W załączniku III przedstawiono model dojrzałości wewnętrznych mechanizmów kontrolnych, który ilustruje dojrzałość przedsiębiorstwa w odniesieniu istnienia i działania tych mechanizmów. Często analiza jest podejmowana w odpowiedzi na zewnętrzne czynniki, jednak najlepiej, aby odbywała się zgodnie z opisem procesów CobiT: PO6 Komunikowanie celów i kierunków zarządzania oraz ME2 Monitorowanie i ocena wewnętrznych mechanizmów kontrolnych.

Zdolność, pokrycie i kontrola to trzy wymiary dojrzałości procesu, które przedstawiono na ilustracji 14.

Model dojrzałości to sposób pomiaru tego, jak dobrze rozwinięte są procesy zarządzania, tzn. jakie są ich rzeczywiste zdolności. To, jak dobrze powinny być rozwinięte lub jakimi powinny charakteryzować się zdolnościami, zależy głownie od celów IT i leżących u ich podstaw potrzeb firmy, które wspierają. To, jak duża część tych zdolności jest w rzeczywistości realizowana, zależy w dużej mierze od zwrotu z inwestycji, który pragnie uzyskać przedsiębiorstwo. Istnieją na przykład krytyczne procesy i systemy, które wymagają bardziej rygorystycznego zarządzania bezpieczeństwem niż te o mniejszym znaczeniu. Z drugiej strony stopień zaawansowania mechanizmów kontrolnych, które muszą być zastosowane w ramach procesu, w większym stopniu zależy od skłonności przedsiębiorstwa do podejmowania ryzyka i odpowiednich wymagań dotyczących zachowania zgodności.

Skale modelu dojrzałości mogą pomóc specjalistom w wyjaśnieniu kierownictwu, gdzie występują niedostatki w zarządzaniu procesem IT oraz w określeniu celów, które należałoby osiągnąć. Odpowiedni model dojrzałości będzie zależał od celów biznesowych przedsiębiorstwa, środowiska działania oraz praktyk stosowanych w branży. W szczególności poziom dojrzałości zarządzania będzie uzależniony od zależności przedsiębiorstwa od procesów IT, jego zaawansowania technologicznego i co najważniejsze — od wartości informacji, które posiada przedsiębiorstwo.

Ilustracja 13 — Ogólny model dojrzałości

0 Nieistniejące — całkowity brak rozpoznawalnych procesów. Przedsiębiorstwo nie dostrzegło nawet istnienia problemu, który wymaga rozwiązania.

1 Wstępne/doraźne — Istnieją dowody na to, że przedsiębiorstwo dostrzegło problemy wraz z koniecznością ich rozwiązania. Nie są to jednak ustandaryzowane procesy. Zamiast nich, do rozwiązywania poszczególnych problemów stosuje się doraźne podejście. Ogólne podejście do zarządzania nie jest podejściem zorganizowanym.

2 Powtarzalne lecz intuicyjne — procesy zostały rozwinięte do poziomu, na którym różne osoby wykonujące to samo zadanie postępują zgodnie z podobnymi procedurami. Nie ma formalnych szkoleń, standardowe procedury nie zostały zakomunikowane, a podjęcie odpowiedzialności pozostawiono jednostkom. Występuje wysoki poziom zależności od wiedzy poszczególnych osób, dlatego prawdopodobne jest występowanie błędów.

3 Zdefiniowane procesy — istnieją ustandaryzowane i udokumentowane procedury, które zostały zakomunikowane poprzez szkolenie. Pracownicy są upoważnieni do ich stosowania. Jest jednak mało prawdopodobne, że odstępstwa od stosowania procedur zostaną wykryte. Procedury nie są zaawansowane, a są raczej formalizacją istniejących praktyk.

4 Kontrolowane i mierzalne — kierownictwo monitoruje i ocenia zgodność z procedurami, a także podejmuje odpowiednie czynności, gdy procesy nie działają efektywnie. Procesy są stale doskonalone i stanowią źródło dobrych praktyk. W ograniczony lub fragmentaryczny sposób wykorzystywane są rozwiązania zautomatyzowane oraz narzędzia.

5 Zoptymalizowane — procesy zostały dopracowane do poziomu dobrej praktyki w oparciu o efekty ciągłego doskonalenia i modelowanie dojrzałości w innych przedsiębiorstwach. Technologia informatyczna jest wykorzystywana w zintegrowany sposób do automatyzacji toku pracy, zapewniając narzędzia służące poprawie jakości i wydajności oraz sprawiając, że przedsiębiorstwo szybko adaptuje się do zmieniających się warunków.

MeTodyka CobiT

0

1

2

3

4

5

100%

JAK (zdolność)

ILE(zakres)

CO (kontrola) Podstawowe czynniki

Misja i cele IT

Zwrot z inwestycji i wydajność kosztowa

Ryzyko i zgodność

Ilustracja 14 — Trzy wymiary dojrzałości


CobiT 4.1Strategiczny punkt odniesienia dla przedsiębiorstwa w dziedzinie doskonalenia zarządzania i kontroli nad procesami IT mogą stanowić wyłaniające się międzynarodowe standardy i najlepsze praktyki. Pojawiające się dzisiaj praktyki mogą wyznaczać oczekiwany przyszły poziom wydajności procesów, dlatego warto brać je pod uwagę planując, gdzie przedsiębiorstwo chciałoby się znajdować za jakiś czas.

Modele dojrzałości zostały zbudowane w oparciu o ogólny model jakościowy (patrz ilustracja 13) do którego stopniowo, poprzez kolejne poziomy, dodawane są zasady odpowiednie dla poniższych atrybutów:• Świadomość i komunikacja• Polityki, plany i procedury• Narzędzia i automatyzacja• Umiejętności i kompetencje• Odpowiedzialność i rozliczalność• Ustalanie celów i pomiar

Tabela atrybutów dojrzałości przedstawiona na ilustracji 15 zawiera charakterystyki sposobów zarządzania procesami IT i opisuje, w jaki sposób ewoluują one od nieistniejącego do zoptymalizowanego procesu. Atrybuty te można wykorzystać do bardziej kompleksowej oceny, analizy braków i planowania udoskonaleń.

Podsumowując, modele dojrzałości przedstawiają ogólny profil etapów rozwoju przedsiębiorstwa w dziedzinie zarządzania i kontroli procesów IT. Są one:• Zbiorem wymagań i aspektów stwarzania możliwości na różnych poziomach dojrzałości.• Skalą, na której w łatwy sposób można zmierzyć różnice.• Skalą, która może służyć do pragmatycznych porównań.• Podstawą do ustalania pozycji „tak jest” i „tak powinno być”. • Podstawą do analizy braków w celu określenia, co należy zrobić, aby osiągnąć wybrany poziom.• Obrazem sposobu zarządzania procesami IT w przedsiębiorstwie (rozpatrywane łącznie).

Modele dojrzałości CobiT koncentrują się na dojrzałości, ale niekoniecznie na pokryciu i poziomie kontroli. Nie są one wartościami liczbowymi, do których trzeba dążyć, ani nie zostały stworzone, by stanowić formalną podstawę do przyznawania certyfikatów z wyraźnymi progami, które trudno jest osiągnąć. Zostały natomiast opracowane w taki sposób, aby mieć zawsze zastosowanie — dzięki opisom poziomów pozwalającym przedsiębiorstwu znaleźć te, które najlepiej pasują do jego procesów. Odpowiedni poziom jest zależny od typu przedsiębiorstwa, środowiska i strategii.

Decyzje dotyczące pokrycia, poziomu kontroli oraz sposobu wykorzystywania zdolności zależą od rachunku kosztów i korzyści. Na przykład wysoki poziom zarządzania bezpieczeństwem może być niezbędny tylko w przypadku systemów przedsiębiorstwa o najbardziej krytycznym znaczeniu. Innym przykładem może być wybór między wykonywaną raz w tygodniu manualną weryfikacją a stałą zautomatyzowaną kontrolą.

Chociaż wyższy poziom dojrzałości oznacza zwiększoną kontrolę nad procesem, przedsiębiorstwo nadal powinno analizować, uwzględniając czynniki ryzyka i wartości, jakie powinno stosować mechanizmy kontrolne. W analizie tej pomocne będą ogólne cele biznesowe i cele IT zdefiniowane w ramach tej metodyki. Mechanizmy kontrolne są warunkowane przez cele kontrolne CobiT i koncentrują się na tym, co jest realizowane w ramach procesu. Modele dojrzałości koncentrują się głównie na tym, jak dobrze zarządzany jest proces. W załączniku III przedstawiono ogólny model dojrzałości, który ilustruje stan środowiska kontroli wewnętrznej oraz ustanowienia mechanizmów kontrolnych w przedsiębiorstwie.

Środowisko mechanizmów kontrolnych jest prawidłowo wdrożone, jeśli uwzględnione są wszystkie trzy aspekty dojrzałości (zdolność, pokrycie i kontrola). Zwiększenie dojrzałości powoduje zmniejszenie ryzyka i poprawę wydajności, prowadząc do mniejszej liczby błędów, większej przewidywalności procesów i ekonomicznego wykorzystania zasobów.

PoMIaR WyDaJNośCICele i mierniki są zdefiniowane w metodyce CobiT na trzech poziomach:• Cele IT i mierniki, które definiują to, czego firma oczekuje od IT oraz w jaki sposób to mierzyć.• Cele procesu i mierniki, które definiują, co musi dostarczać proces IT, aby wspierać realizację celów IT oraz w jaki sposób

to mierzyć.• Cele czynności i mierniki, które określają, co musi dziać się w ramach procesu, aby osiągnąć wymaganą wydajność oraz w jaki

sposób to mierzyć.


Ilustracja 15 — Tabela atrybutów dojrzałości

Ś

wia

do

mo

ść i

Po

lityk

i, p

lany

N

arzę

dzi

a

Um

ieję

tno

ści

Od

po

wie

dzi

alno

ść

Ust

alan

ie c

eló

w

ko

mun

ikac

ja

i pro

ced

ury

i a

uto

mat

yzac

ja

i ko

mp

eten

cje

i ro

zlic

zaln

ość

i p

om

iar

1

Poja

wia

się

św

iado

moś

ć

Prak

tyko

wan

e je

st d

oraź

ne

Mog

ą is

tnie

ć pe

wne

nar

zędz

ia;

Nie

są o

kreś

lone

um

ieję

tnoś

ci

Nie

zdefi

niow

ano

poję

ć

Cele

nie

są

jasn

o zd

efini

owan

e

po

trzeb

y is

tnie

nia

proc

esu.

po

dejś

cie

do p

roce

sów

i pr

akty

k.

używ

ane

są s

tand

ardo

we

ni

ezbę

dne

dla

proc

esu.

ro

zlic

zaln

ości

i n

ie d

okon

uje

się

żadn

ych

na

rzęd

zia

kom

pute

row

e.

i o

dpow

iedz

ialn

ości

. Pra

cow

nicy

pom

iaró

w.

W

ystę

puje

spo

rady

czna

Pr

oces

y i p

olity

ki

Ni

e is

tnie

je p

lan

szko

leń

bi

orą

odpo

wie

dzia

lnoś

ć

ko

mun

ikac

ja d

otyc

ząca

ni

e są

zde

finio

wan

e.

Nie

ma

plan

oweg

o po

dejś

cia

i n

ie o

dbyw

a si

ę fo

rmal

ne

z w

łasn

ej in

icja

tyw

y

pr

oble

mów

.

do k

orzy

stan

ia z

nar

zędz

i. sz

kole

nie.

na

dor

aźny

ch z

asad

ach.

2

Istn

ieje

św

iado

moś

ć

Poja

wia

ją s

ię p

odob

ne i

pow

szec

hnie

Ist

niej

ą w

spól

ne p

odej

ścia

W

kry

tycz

nych

obs

zara

ch o

kreś

lone

Pra

cow

nicy

maj

ą po

czuc

ie

Wyz

nacz

a si

ę pe

wne

cel

e;

po

trzeb

y dz

iała

nia.

st

osow

ane

proc

esy,

ale

są o

ne

do s

toso

wan

ia n

arzę

dzi,

są

min

imal

ne w

ymag

ania

od

pow

iedz

ialn

ości

i zw

ykle

są

są u

stal

one

pew

ne k

ryte

ria

w w

ięks

zośc

i int

uicy

jne

ze w

zglę

du

ale

są o

parte

na

rozw

iąza

niac

h do

tycz

ące

umie

jętn

ości

. z

niej

rozl

icza

ni, n

awet

jeśl

i nie

fin

anso

we,

ale

wie

o n

ich

tylk

o

Ki

erow

nict

wo

prze

kazu

je

na in

dyw

idua

lne

kom

pete

ncje

. op

raco

wan

ych

prze

z kl

uczo

we

je

st to

form

alni

e uz

godn

ione

. w

yższ

a ka

dra

zarz

ądza

jąca

.

info

rmac

je o

ogó

lnyc

h

os

oby.

Szko

leni

a od

byw

ają

się

racz

ej

Gdy

poja

wi s

ię p

robl

em,

W o

doso

bnio

nych

obs

zara

ch

pr

oble

mac

h.

Niek

tóre

asp

ekty

pro

cesu

zale

żnie

od

potrz

eb n

iż na

pod

staw

ie n

ie w

iado

mo,

kto

pon

osi

stos

owan

y je

st n

ieko

nsek

wen

tny

są p

owta

rzal

ne d

zięk

i M

ogły

zos

tać

zaku

pion

e

uzgo

dnio

nego

pla

nu i

zdar

zają

od

pow

iedz

ialn

ość

i mog

ą m

onito

ring.

in

dyw

idua

lnym

kom

pete

ncjo

m

spec

jalis

tycz

ne n

arzę

dzia

, si

ę ni

efor

mal

ne s

zkol

enia

w

ystę

pow

ać te

nden

cje

i m

oże

istn

ieć

pew

na

ale

praw

dopo

dobn

ie

doty

cząc

e w

ykon

ywan

ej p

racy

. do

wza

jem

nego

obw

inia

nia

się.

do

kum

enta

cja

oraz

nie

form

alne

ni

e są

uży

wan

e pr

awid

łow

o

zroz

umie

nie

polit

yki i

pro

cedu

r. lu

b ni

e są

w o

góle

uży

wan

e. 3

Is

tnie

je z

rozu

mie

nie

Po

jaw

ia s

ię s

toso

wan

ie

Zost

ał o

prac

owan

y pl

an

We

wsz

ystk

ich

obsz

arac

h zo

stał

y

Zdefi

niow

ana

jest

Us

talo

no p

ewne

cel

e i w

skaź

niki

potrz

eby

dzia

łani

a.

dobr

ych

prak

tyk.

w

ykor

zyst

ania

i st

anda

ryza

cji

zdefi

niow

ane

i udo

kum

ento

wan

e

odpo

wie

dzia

lnoś

ć i r

ozlic

zaln

ość

dot

yczą

ce e

fekt

ywno

ści,

ale

na

rzęd

zi w

cel

u au

tom

atyz

acji

w

ymag

ania

dot

yczą

ce u

mie

jętn

ości

. za

pro

ces

oraz

okr

eśle

ni s

ą

nie

są o

ne k

omun

ikow

ane;

Zarz

ądza

nie

jest

bar

dzie

j Zd

efini

owan

o i u

doku

men

tow

ano

pr

oces

u.

Opra

cow

ano

form

alny

pla

n

wła

ścic

iele

pro

cesu

. Wła

ścic

iel

istn

ieje

wyr

aźne

pow

iąza

nie

sfor

mal

izow

ane

pr

oces

y, po

lityk

ę i p

roce

dury

szko

leń,

ale

sfo

rmal

izow

ane

pr

oces

u zw

ykle

nie

ma

jedn

ak

Mea

sure

men

t pro

cess

es z

cel

ami

i z

orga

nizo

wan

e po

d

dla

wsz

ystk

ich

kluc

zow

ych

Uż

ywa

się

narz

ędzi

sz

kole

nia

nada

l opi

eraj

ą si

ę

pełn

ych

upra

wni

eń, a

by

bizn

esow

ymi.

Poja

wia

się

pom

iar

w

zglę

dem

kom

unik

acyj

nym

. cz

ynno

ści.

w p

odst

awow

ym z

akre

sie,

na

indy

wid

ualn

ych

inic

jaty

wac

h.

wyk

onyw

ać s

woj

e za

dani

a

doty

cząc

y pr

oces

ów, a

le n

ie je

st

al

e m

oże

nie

odby

wać

w ty

m z

akre

sie.

ko

nsek

wen

tnie

sto

sow

any.

si

ę to

zgo

dnie

z u

stal

onym

Pr

zyję

to z

ałoż

enia

zró

wno

waż

onej

plan

em, a

nar

zędz

ia m

ogą

ka

rty w

ynik

ów IT

i cz

asem

intu

icyjn

ie

ni

e by

ć ze

sob

ą zi

nteg

row

ane.

st

osuj

e si

ę an

aliz

ę pr

zycz

yny

po

dsta

wow

ej.

4

Istn

ieje

zro

zum

ieni

e

Proc

es je

st „

zdro

wy”

i ko

mpl

etny

; W

droż

ono

narz

ędzi

a zg

odni

e

Wym

agan

ia d

otyc

zące

um

ieję

tnoś

ci

Akce

ptow

ana

jest

W

ydaj

ność

i ef

ekty

wno

ść p

odle

gają

wsz

ystk

ich

wym

agań

. st

osow

ane

są n

ajle

psze

z

usta

ndar

yzow

anym

pla

nem

, są

ruty

now

o ak

tual

izow

ane

od

pow

iedz

ialn

ość

i roz

licza

lnoś

ć po

mia

row

i i s

ą ko

mun

ikow

ane

wew

nętrz

ne p

rakt

yki.

a ni

ektó

re z

nic

h zo

stał

y

dla

wsz

ystk

ich

dzie

dzin

, zap

ewni

ona

za

proc

es i

funk

cjon

uje

ona

i o

dnos

zone

do

celó

w b

izne

sow

ych

Stos

owan

e są

doj

rzał

e

zi

nteg

row

ane

z in

nym

i,

jest b

iegłoś

ć w

e w

szys

tkich

kry

tycz

nych

w s

posó

b, k

tóry

poz

wal

a

oraz

stra

tegi

czne

go p

lanu

IT.

te

chni

ki i

stan

dard

owe

W

szys

tkie

asp

ekty

pro

cesu

po

krew

nym

i nar

zędz

iam

i. ob

szar

ach

i zac

hęca

się

do u

zysk

iwan

ia w

łaśc

icie

low

i pro

cesu

w p

ełni

W

nie

któr

ych

obsz

arac

h, z

wyją

tkam

i

narz

ędzi

a ko

mun

ikac

ji.

są u

doku

men

tow

ane

i pow

tarz

alne

.

certy

fikat

ów.

real

izow

ać s

woj

e ob

owią

zki.

okre

ślon

ymi p

rzez

kie

row

nict

wo,

Po

lityk

a je

st z

atw

ierd

zona

Stos

owan

e są

doj

rzał

e te

chni

ki

Istn

ieje

kul

tura

nag

radz

ania

, st

osow

ana

jest

met

oda

i z

aapr

obow

ana

prze

z ki

erow

nict

wo.

Uż

ywa

się

narz

ędzi

w

szko

leni

a zg

odni

e z

plan

em s

zkol

eń k

tóra

mot

ywuj

e do

poz

ytyw

nych

zró

wno

waż

onej

kar

ty w

ynik

ów

Przy

jęte

i pr

zest

rzeg

ane

są

najw

ażni

ejsz

ych

obsz

arac

h

i zac

hęca

się

do

dzie

leni

a si

ę

zach

owań

. or

az d

okon

ywan

a je

st s

tand

aryz

acja

st

anda

rdy

rozw

ijani

a

w c

elu

zarz

ądza

nia

proc

esem

w

iedz

ą. Z

aang

ażow

ani s

ą w

szys

cy

an

aliz

y pr

zycz

yny

pods

taw

owej

.

i u

trzym

ywan

ia p

roce

sów

i m

onito

row

ania

kry

tycz

nych

w

ewnę

trzni

eks

perc

i w d

anej

Poja

wia

się

idea

cią

głeg

o

i pro

cedu

r.

czyn

nośc

i i m

echa

nizm

ów

dzie

dzin

ie i

ocen

iana

jest

dosk

onal

enia

.

kont

roln

ych.

ef

ekty

wno

ść p

lanu

szk

oleń

. 5

Is

tnie

je d

alek

o id

ące,

St

osow

ane

są n

ajle

psze

W

cał

ym p

rzed

sięb

iors

twie

Or

gani

zacj

a fo

rmal

nie

zach

ęca

W

łaśc

icie

le p

roce

sów

są

Is

tnie

je z

inte

grow

any

syst

em

uk

ieru

nkow

ane

ze

wnę

trzne

pra

ktyk

i i s

tand

ardy

. w

ykor

zyst

ywan

e są

do

cią

głeg

o do

skon

alen

ia

upow

ażni

eni d

o po

dejm

owan

ia

pom

iaru

wyd

ajno

ści z

apew

niaj

ący

na p

rzys

złoś

ć zr

ozum

ieni

e

usta

ndar

yzow

ane

zest

awy

narz

ędzi.

um

ieję

tnoś

ci w

opa

rciu

o ja

sno

decy

zji i

dzi

ałań

. Akc

epta

cja

po

wią

zani

e w

ydaj

nośc

i IT

z ce

lam

i

wym

agań

. Do

kum

enta

cja

proc

esów

zos

tała

Na

rzęd

zia s

ą w

peł

ni z

inte

grow

ane

zde

finio

wan

e os

obis

te

odpo

wie

dzia

lnoś

ci z

osta

ła

bizn

esow

ymi p

oprz

ez p

owsz

echn

e

rozw

inię

ta d

o po

stac

i z

inny

mi p

okre

wny

mi n

arzę

dzia

mi,

i or

gani

zacy

jne

cele

. w

kon

sekw

entn

y sp

osób

za

stos

owan

ie z

rów

now

ażon

ej

Pr

akty

kow

ane

jest

akt

ywne

za

utom

atyz

owan

ego

toku

pra

cy.

aby

zape

wni

ać k

ompl

ekso

we

rozp

owsz

echn

iona

w c

ałej

ka

rty w

ynik

ów. O

dstę

pstw

a

po

dejś

cie

do in

form

owan

ia

Proc

esy,

polit

yki i

pro

cedu

ry

wsp

arci

e dl

a pr

oces

ów.

Szko

leni

e i e

duka

cja

wsp

iera

ją

orga

niza

cji.

są p

owsz

echn

ie i

kons

ekw

entn

ie

o

prob

lem

ach

w o

parc

iu

są u

stan

dary

zow

ane

najle

psze

zew

nętrz

ne p

rakt

yki

pr

zeka

zyw

ane

do w

iado

moś

ci

o

trend

y; s

toso

wan

e

i zin

tegr

owan

e, a

by u

moż

liwia

ć Uż

ywa

się n

arzę

dzi,

aby

wsp

iera

ć o

raz

stos

owan

ie n

ajno

wsz

ych

kier

owni

ctw

a i s

toso

wan

a je

st

są

doj

rzał

e te

chni

ki

kom

plek

sow

e za

rząd

zani

e

dosk

onal

enie

pro

cesu

ko

ncep

cji i

tech

nolo

gii.

an

aliz

a pr

zycz

yny

pods

taw

owej

.

i zin

tegr

owan

e na

rzęd

zia

i d

osko

nale

nie.

i a

utom

atyc

znie

wyk

ryw

ać

Dzie

leni

e się

wie

dzą

stan

owi

Pow

szec

hną

prak

tyką

jest

kom

unik

acji.

odst

ępst

wa

w k

ontro

li.

elem

ent k

ultu

ry p

rzed

sięb

iors

twa

ciąg

łe d

osko

nale

nie.

i w

draż

ane

są s

yste

my

op

iera

jące

się

na

wie

dzy.

Korz

ysta

się

ze

wsk

azów

ek

zew

nętrz

nych

eks

pertó

w

i lid

erów

bra

nży.

MeTodyka CobiT


Cele są definiowane z góry w dół, co oznacza, że cel biznesowy określa pewną liczbę celów IT, które mają wspierać jego realizację. Cel IT jest osiągany poprzez jeden proces lub interakcję kilku procesów. Dlatego cele IT pomagają definiować różne cele procesów. Z kolei każdy cel procesu wymaga wykonania pewnej liczby czynności, więc określa cele czynności. Ilustracja 16 przedstawia przykład relacji między celem biznesowym, celem IT, celem procesu i celem czynności.

Terminy KGI i KPI wykorzystywane w poprzednich wersjach metodyki CobiT zostały zastąpione dwoma rodzajami mierników: • Miary wyników, określane wcześniej jako kluczowe wskaźniki celów (KGI), wskazują, czy cele zostały osiągnięte. Ponieważ

można je uzyskać dopiero po fakcie, określa się je mianem „wskaźników następujących”.• Wskaźniki wydajności, określane wcześniej mianem kluczowych wskaźników wydajności (KPI), wskazują, czy cele mogą zostać

osiągnięte. Ponieważ można je uzyskać zanim znany jest wynik procesu, określa się je mianem „wskaźników wyprzedzających”.

Ilustracja 17 przedstawia możliwe miary wyników dla użytego przykładu.

Miary wyników niższego poziomu działania w organizacji stają się wskaźnikami wydajności dla wyższego poziomu. Zgodnie z przykładem przedstawionym na ilustracji 16 miara wyniku wskazująca, że wykrywanie i eliminowanie nieuprawnionego dostępu osiąga zakładany poziom, wskazuje również na większe prawdopodobieństwo tego, że usługi IT zdołają oprzeć się atakom i zostać po nich przywrócone do działania. W ten sposób miara wyniku stała się wskaźnikiem wydajności dla celu wyższego poziomu. Ilustracja 18 pokazuje, w jaki sposób miary wyników dla analizowanego przykładu stają się miernikami wydajności.

Miary wyników to wskaźniki, które informują kierownictwo (post factum), czy funkcja, proces lub czynność IT osiągnęła swoje cele. Miary wyników dla funkcji IT są często wyrażane w kategoriach kryteriów informacji takich jak:• Dostępność informacji potrzebnych dla wsparcia potrzeb biznesowych.• Brak ryzyka dotyczącego integralności i poufności.• Opłacalność procesów i operacji.• Potwierdzenie wiarygodności, efektywności i zgodności.

Wskaźniki wydajności definiują miary, które określają, na ile dobrze działalność biznesowa, funkcja IT lub proces IT umożliwia realizację określonych celów. Są one wskaźnikami wyprzedzającymi, które pozwalają ocenić prawdopodobieństwo osiągnięcia celu, dlatego warunkują cele wyższego poziomu. Często mierzą one dostępność odpowiednich zdolności, praktyk i umiejętności, a także wyników podstawowych czynności. Na przykład usługa dostarczana przez IT jest celem dla IT, ale jednocześnie wskaźnikiem wydajności i miernikiem zdolności dla firmy. Stąd wskaźniki wydajności określa się czasem mianem czynników wydajnościowych — zwłaszcza w kontekście zrównoważonych kart wyników.

CobiT 4.1

Cele IT

Cel biznesowy Cel IT Cel procesu

Cele procesu Cele czynności

Utrzymać reputację przedsiębiorstwa i przywództwo.

Zapewnić odporność usług IT na ataki oraz możliwość przywrócenia tych usług

do normalnego stanu.

Zapewnić odporność usług IT na ataki oraz możliwość

przywrócenia tych usług do normalnego stanu.

Wykrywać i rozpoznawać nieupoważniony dostęp.

Wykrywać i rozpoznawać nieupoważniony dostęp.

Rozumieć wymagania dotyczące bezpieczeństwa,

słabych punktów i zagrożeń.

Ilustracja 16 — Przykład zależności między celami

Cel biznesowy Cel IT Cel procesu Cel czynności

Miara wyniku Miara wyniku Miara wyniku Miara wyniku


Liczba incydentów powodujących

kłopotliwe sytuacje na forum publicznym.



Liczba rzeczywistych incydentów IT

mających wpływ na działalność.

Wykrywać i rozpoznawać nieupoważniony

dostęp.

Liczba rzeczywistychincydentów spowodowanych

nieupoważnionym dostępem.

Rozumieć wymagania dotyczące

bezpieczeństwa, słabych punktów

i zagrożeń.

Częstość weryfikacji typu monitorowanych zdarzeń dotyczących

bezpieczeństwa.

Ilustracja 17 — Możliwe miary wyników dla przykładu z ilustracji 16


MeTodyka CobiT

Dlatego dostarczone mierniki są jednocześnie miarą wyników funkcji IT, procesu IT lub czynności podlegającej pomiarowi oraz wskaźnikiem wydajności ułatwiającym realizację celu poziomów wyższych aktywności: biznesu, funkcji IT lub procesu IT.

Ilustracja 19 przedstawia relacje między celem biznesowym, celem IT, celem procesu i celem czynności oraz różne mierniki. Gdy się patrzy od lewej do prawej strony na górze, widać, że cele wynikają z siebie kolejno. Poniżej celu znajduje się jego miara wyniku. Mała strzałka wskazuje, że dany miernik jest jednocześnie wskaźnikiem wydajności dla celu wyższego poziomu.

Przykład dotyczy procesu DS5 Zapewnianie bezpieczeństwa systemów. Metodyka CobiT pozwala określić mierniki tylko do poziomu wyników realizacji celów IT — co pokazuje przerywana linia. Choć są one również wskaźnikami wydajności dla celów biznesowych określonych dla IT, metodyka CobiT nie dostarcza miar wyników dla celów biznesowych.

Cele biznesowe i cele IT wykorzystane w części metodyki CobiT dotyczącej celów i mierników, są omówione szczegółowo (wraz z ich relacjami) w załączniku I. Dla każdego procesu IT w ramach modelu CobiT przedstawione są cele i mierniki, jak pokazano na ilustracji 20.

Mierniki opracowano biorąc pod uwagę następujące wymagania:• Wysoka skuteczność względem wysiłku na pozyskanie (tj. pozyskanie informacji dotyczących wydajności i realizacji celów

względem włożonego w to wysiłku).• Wewnętrzna porównywalność (np. zmiana procentowa względem wartości bazowej lub wartości liczbowej w czasie).• Zewnętrzna porównywalność niezależnie od wielkości przedsiębiorstwa lub branży.• Lepiej mieć kilka dobrych mierników (a nawet jeden bardzo dobry, na który może wpływać wiele czynników) niż długą listę

mierników o niskiej jakości.• Łatwo mierzalne, nie do pomylenia z celami.

Cel biznesowy Cel IT

StymulacjaStymulacja

Stymulacja

Cel procesu

Miernik wydajności Miernik wydajności Miernik wydajności


bezpieczeństwa.


dostęp.




Liczba rzeczywistych incydentów IT

mających wpływ na działalność.

Liczba rzeczywistych incydentów spowodowanych

nieupoważnionym dostępem.

Ilustracja 18 — Możliwe czynniki poprawy wydajności dla przykładu z ilustracji 16

Rozumieć wymagania dotyczące

bezpieczeństwa, słabych punktów

i zagrożeń.


dostęp do, informacji aplikacji i infrastruktury.

Zapewnić odporność usług IT na ataki

oraz możliwość przywrócenia tych

usług do normalnego stanu.


Cel czynności

Cel procesu

Cel IT

Cel biznesowy


bezpieczeństwa.

Liczba rzeczywistych incydentów

spowodowanych nieupoważnionym

dostępem.

Liczba rzeczywistych incydentów IT mających

wpływ na działalność.

Liczba incydentów powodujących

kłopotliwe sytuacjena forum publicznym.

Miernik biznesowy Miara wyniku

Wskaźnik wydajności

Miernik IT Miara wyniku


mierzony ze względu na mierzony ze względu na mierzony ze względu na mierzony ze względu na

Zdefiniować cele.

Określić wydajność.

Dokonać pomiaru osiągnięć.Ul

epsz

yć i d

opas

ować

.

Miernik procesu Miara wyniku


Ilustracja 19 — Relacje między procesem, celami i miernikami (DS5)


Model metodyki CobiTMetodyka CobiT łączy więc wymagania biznesowe dotyczące informacji i nadzoru z celami dotyczącymi funkcji usług IT. Model procesów CobiT umożliwia prawidłowe zarządzanie i kontrolowanie czynności IT i zasobów, które je wspierają, w oparciu o cele kontrolne CobiT oraz ich dostosowanie i monitorowanie z wykorzystaniem celów i mierników CobiT, jak pokazano na ilustracji 21.

CobiT 4.1Ilustracja 20 — Prezentacja celów i mierników

pomiar

IT CzynnościProces

Cele

Mie

rnik

i

pomiar pomiar

stymulacja

stymulacja

usta-lenie

usta-lenie

Kryteria informacji

Zasoby IT

Procesy IT

Miary wyniku

Wskaźniki wydajności

Opisy procesów

Cele biznesowe

Procesy IT

Cele IT

Czynniki nadzoru

Wyniki działalności

Osob

y

Infra

stru

ktur

a

Info

rmac

ja

Aplik

acje

Ilustracja 21 — Zarządzanie, kontrola, dopasowanie i monitoring zgodnie z modelem CobiT


Podsumowując: zasoby IT są zarządzane przez procesy IT w celu osiągnięcia celów IT, które odpowiadają wymaganiom biznesowym. Jest to podstawowa zasada metodyki CobiT, którą przedstawiono w postaci sześcianu CobiT (ilustracja 22).

W bardziej szczegółowym ujęciu całą strukturę metodyki CobiT można przedstawić w postaci graficznej, jak pokazano na ilustracji 23. Przedstawia ona model procesów CobiT dla czterech domen obejmujących 34 ogólne procesy, które zarządzają zasobami IT, aby dostarczać informacje potrzebne do prowadzenia działalności biznesowej zgodnie z wymaganiami biznesowymi i dotyczącymi nadzoru.

Ogólna akceptowalność metodyki CobiTMetodyka CobiT powstała w oparciu o analizę i harmonizację istniejących standardów i dobrych praktyk w dziedzinie IT i jest zgodna z ogólnie przyjętymi zasadami nadzoru. Dotyczy ona wysokiego poziomu zarządzania, jest ukierunkowana na wymagania biznesowe, obejmuje pełen zakres działalności IT i koncentruje się bardziej na tym, co należy osiągnąć niż w jaki sposób osiągnąć cel w postaci efektywnego nadzoru, zarządzania i kontroli. Dlatego łączy w sobie praktyki z dziedziny nadzoru informatycznego i odpowiada na potrzeby kadry zarządzającej, osób kierujących działalnością biznesową i IT, specjalistów ds. nadzoru, kontroli wewnętrznej i bezpieczeństwa oraz specjalistów ds. audytu i kontroli systemów informatycznych. Stanowi ona dopełnienie innych standardów i dobrych praktyk i może być stosowana w połączeniu z nimi.

Wdrożenie dobrych praktyk powinno być zgodne ze strukturą kontroli i nadzoru w przedsiębiorstwie, odpowiednie dla organizacji i zintegrowane z innymi metodami i praktykami, które są już stosowane. Standardy i dobre praktyki nie są panaceum na wszystkie problemy. Ich efektywność zależy od tego, w jaki sposób zostaną wdrożone i będą aktualizowane. Ich użyteczność jest największa, gdy są wykorzystywane jako zbiór zasad oraz punkt wyjścia do opracowania szczegółowych procedur. Aby praktyki nie stały się bezużyteczne, kierownictwo i pracownicy powinni wiedzieć, co robić, w jaki sposób i dlaczego jest to ważne.

Aby dostosować dobre praktyki do wymagań biznesowych, zaleca się stosowanie metodyki CobiT na najwyższym poziomie zarządzania, zapewniając ogólną strukturę mechanizmów kontrolnych w oparciu o model procesów IT, który generalnie powinien pasować do każdego przedsiębiorstwa. Specyficzne praktyki i standardy dotyczące odrębnych obszarów mogą zostać przypisane do struktury CobiT, tworząc w ten sposób hierarchię materiałów pomocniczych.

Metodyka CobiT jest adresowana do różnych użytkowników, takich jak:• Kadra zarządzająca — aby mogła uzyskać wartość z inwestycji w IT oraz zrównoważyć ryzyko i inwestycje w system kontroli

w często nieprzewidywalnym środowisku IT.• Kierujący działalnością biznesową — aby mogli otrzymać zapewnienie co do zarządzania i kontroli nad usługami IT

świadczonymi wewnętrznie lub przez strony trzecie.• Kierownictwo IT — aby mogło świadczyć usługi IT wymagane przez biznes w celu realizacji strategii biznesowej w

kontrolowany i kierowany sposób.• audytorzy — aby mogli uzasadniać swoje opinie i/lub służyć doradztwem w sprawie wewnętrznych mechanizmów kontrolnych.

Metodyka CobiT została opracowana i jest rozwijana przez niezależny instytut badawczy, działający na zasadach non-profit, w oparciu o specjalistyczną wiedzę członków afiliowanego stowarzyszenia, ekspertów z branży oraz specjalistów ds. kontroli i bezpieczeństwa. Jej zawartość opiera się na ciągłych badaniach dotyczących dobrych praktyk w dziedzinie IT i jest stale rozwijana, aby zapewniać obiektywne i praktyczne źródło wiedzy dla wszystkich użytkowników.

Metodyka CobiT jest ukierunkowana na cele i zakres nadzoru informatycznego, zapewniając, że zawarta w niej struktura mechanizmów kontrolnych jest wyczerpująca i zgodna z zasadami sprawowania nadzoru informatycznego w przedsiębiorstwie, dzięki czemu jest możliwa do przyjęcia przez zarządy, kierownictwo wykonawcze, audytorów i organy regulacyjne. W załączniku II znajduje się tabela, która ilustruje, w jaki sposób cele kontrolne CobiT’s są przyporządkowane do pięciu obszarów nadzoru informatycznego oraz działań kontrolnych COSO.

MeTodyka CobiT

Proc

esy I

T

Wymagania biznesowe

Zasoby IT

Efektywność

Wydajność

Poufność

Integralność

Dostępność

Zgodność

Wiarygodność

DOMENY

PROCESY

CZYNNOŚCI

Aplik

acje

Info

rmac

ja Osob

y

Infra

stru

ktur

a

Ilustracja 22 — Sześcian CobiT


CobiT 4.1

Nadzór informatyczny

Dopasowanie strategiczne, dostarczanie wartości, zarządzanie ryzykiem, zarządzanie zasobami, z

arząd

zanie

wyd

ajno

ścią

Wymagania biznesowe i dotyczące nadzoru

Kryteria informacji i aplikacyjne mechanizmy kontrolne

Umożliwianie dostępu do informacji i technologii

Zasoby IT: aplikacje, informacje, infrastruktura, ludzie

Dostarczanie procesów IT

Mechanizmy kontrolne procesów i dojrzałość procesó

w

Kierowanie Kontrol

a


Dostarczanie i wsparcie

Monitorowanie i ocenaCele Mierniki

Nabywanie i wdrażanie

P=czynnik podstawowy (Primary) S=czynnik drugorzędny (Secondary)

P P

P S P

SPS

S P P

SPP

Cele Mierniki Praktyki Modeledojrzałości

Dopasowanie strategiczneDostarczanie

wartościZarządzanie

ryzykiemZarządzanie zasobami

Pomiar wydajności

Ilustracja 24 — Metodyka CobiT i obszary nadzoru informatycznego

Ilustracja 24 pokazuje, w jaki sposób różne elementy metodyki CobiT są przyporządkowane do obszarów nadzoru informatycznego.

Ilustracja 23 — Ogólna struktura metodyki CobiT

i T G o v e r n a n c e i n s T i T u T e


MeTodyka CobiTJak kOrzystać z teJ książki

Poruszanie się po zawartości metodyki CobiTKażdy proces IT CobiT jest zaopatrzony w opis wraz kluczowymi celami i miernikami przedstawionymi w formie kaskadowej (ilustracja 25).

Przegląd podstawowych komponentów metodyki CobiT Metodyka CobiT składa się z następujących podstawowych komponentów, które omówiono w niniejszej publikacji i które są uporządkowane według 34 procesów IT, dając pełen obraz tego, jak kontrolować, zarządzać i mierzyć każdy z procesów. Każdy proces jest omówiony w czterech częściach, z których każda zajmuje około jedną stronę:• Cześć 1 (ilustracja 25) zawiera opis procesu podsumowujący jego cele, przedstawiony w formie kaskadowej. Na tej samej

stronie przedstawione jest również przyporządkowanie procesu do kryteriów informacji, zasobów IT i obszarów nadzoru informatycznego w taki sposób, że oznaczenie P wskazuje na podstawową relację, a S — na drugorzędną.

• Część 2 zawiera zestawienie celów kontrolnych dla danego procesu.• Część 3 zawiera zestawienie elementów wejściowych i wyjściowych dla procesu, tabelę RACI oraz cele i mierniki.• Część 4 zawiera model dojrzałości dla danego procesu.

Ilustracja 25 — Nawigacja CobiT

Kontrola nad procesem iT

nazwa procesu

który spełnia wymaganie biznesowe dla it

podsumowanie najważniejszych celów IT

poprzez skupienie się na

podsumowanie najważniejszych celów procesu

jest osiągana poprzez

cele czynności

oraz mierzona poprzez

najważniejsze mierniki

Efektywność

Wydajność

Poufność

Integralność

Dostępność

Zgodność

Wiarygodność

Aplikacje

informacja

Infrastruktura

Ludzie



Dostarczaniei wsparcie


W ramach każdego procesu IT cele kontrolne mają postać ogólnych stwierdzeń dotyczących minimum dobrych praktyk zarządzania w celu zapewnienia kontroli nad procesem


CobiT 4.1Inny sposób odczytywania zawartości opisu procesu jest następujący:• Elementy wejściowe procesu to elementy, których właściciel procesu potrzebuje od innych.• Cele kontrolne w opisie procesu wskazują to, co właściciel procesu powinien zrobić.• Elementy wyjściowe procesu to elementy, które musi dostarczyć właściciel procesu.• Cele i mierniki odnoszą się do tego, w jaki sposób powinien odbywać się pomiar procesu.• Tabela RACI definiuje, co powinno być delegowane i do kogo.• Model dojrzałości pokazuje, co należy zrobić w celu uzyskania poprawy.

W tabeli RACI wyszczególnione są stanowiska (role) dla wszystkich procesów:• Dyrektor generalny (CEO)• Dyrektor ds. finansowych (CFO)• Członkowie zarządu• Dyrektor ds. informatyki (CIO)• Właściciel procesu biznesowego• Kierownik działu operacyjnego• Główny architekt• Kierownik ds. rozwoju• Kierownik ds. administracji IT (w większych przedsiębiorstwach kierownicy ds. personalnych, ds. budżetu oraz ds. kontroli

wewnętrznej)• Kierownik biura zarządzania projektami (PMO) lub analogiczna funkcja• Specjaliści ds. zapewnienia zgodności, audytu, zarządzania ryzykiem i bezpieczeństwa (pełniący obowiązki kontrolne, a nie

operacyjne w dziedzinie IT)

W przypadku niektórych procesów pojawiają się dodatkowe stanowiska specyficzne dla danego procesu — np. kierownik ds. service desk/incydentów w przypadku procesu DS8.

Należy pamiętać o tym, że chociaż opracowanie powstało na postawie doświadczeń wielu ekspertów oraz szczegółowych badań i analiz, przedstawione elementy wejściowe, wyjściowe, obowiązki, mierniki i cele mają wyłącznie poglądowy, a nie normatywny i wyczerpujący charakter. Jest ono źródłem specjalistycznej wiedzy, z którego przedsiębiorstwo powinno wybrać te elementy, które w efektywny sposób będą spełniać jego potrzeby wynikające z przyjętej strategii, celów i polityk.

Użytkownicy komponentów metodyki CobiTKierownictwo może wykorzystywać metodykę CobiT do oceny procesów IT, wykorzystując cele biznesowe i cele IT wymienione w załączniku I do objaśnienia celów procesów IT oraz modele dojrzałości procesów do oceny rzeczywistej wydajności.

Osoby pracujące nad wdrożeniem i audytorzy mogą określić odpowiednie wymagania kontrolne na podstawie celów kontrolnych oraz obowiązki na podstawie czynności i powiązanych tabel RACI.

Wszyscy potencjalni użytkownicy mogą korzystać z metodyki CobiT jako ogólnego podejścia do zagadnienia zarządzania i nadzoru informatycznego w powiązaniu z bardziej szczegółowymi standardami, takimi jak:• ITIL dla świadczenia usług;• CMM dla dostarczania rozwiązań;• ISO/IEC 27001/27002 dla bezpieczeństwa informacji;• PMBOK lub PRINCE2 dla zarządzania projektami.

załącznikiNa końcu opracowania znajdują się następujące materiały dodatkowe:I. Tabele powiązań celów i procesów (trzy tabele)II. Przyporządkowanie procesów IT do głównych obszarów nadzoru informatycznego, struktury ramowej COSO, zasobów

informatycznych CobiT i kryteriów informacji CobiTIII. Model dojrzałości kontroli wewnętrznejIV. CobiT 4.1 — najważniejsze materiały źródłoweV. Wzajemne relacje między metodyką CobiT® 3rr Edition© a metodyką CobiT 4.1VI. Podejście do badań i rozwojuVII. TerminologiaVIII. Metodyka CobiT i powiązane produkty

P l a n o w a n i e i o r G a n i z a c j a

PO1 Definiowanie planu strategicznego ITPO2 Definiowanie architektury informacjiPO3 Ustalanie kierunku technologicznegoPO4 DefiniowanieprocesówIT,organizacjiiwzajemnychzależnościPO5 ZarządzanieinwestycjamiITPO6 KomunikowaniecelówikierunkuzarządzaniaPO7 ZarządzaniezasobamiludzkimiwITPO8 ZarządzaniejakościąPO9 OcenaizarządzanieryzykieminformatycznymPO10 Zarządzanieprojektami

Pla

No

Wa

NIE

I oR

Ga

NIZ

aC

Ja


Planowanie i organizacjaDefiniowanie planu strategicznego IT PO1

oPis Procesu


Definiowanie planu strategicznego IT


dotyczące wspierania lub rozwijania strategii biznesowej i wymagań dotyczących nadzoru przy jednoczesnym zapewnieniu przejrzystości korzyści, kosztów i ryzyka


uczestniczeniu kierownictwa działu IT i firmy w przekładaniu wymagań biznesowych na ofertę usług oraz w opracowaniu strategii umożliwiającej dostarczanie tych usług w przejrzysty i efektywny sposób,


• zaangażowanie kierownictwa firmy i wyższej kadry zarządzającej w dostosowanie planowania strategicznego IT do aktualnych i przyszłych potrzeb biznesowych;

• zrozumienie aktualnych zdolności IT; • określenie hierarchii ważności celów biznesowych, która kwantyfikuje

wymagania biznesowe


• procent celów IT w planie strategicznym IT, które wspierają realizację strategicznego planu biznesowego;

• procent projektów IT w portfelu projektów IT, które mają bezpośrednie odniesienie do planów taktycznych IT;

• opóźnienia miedzy aktualizacjami planu strategicznego IT a aktualizacjami planów taktycznych IT.





PO1 Definiowanie planu strategicznego iT

Planowanie strategiczne IT jest niezbędne do zarządzania i kierowania wszystkimi zasobami IT zgodnie ze strategią i priorytetami biznesowymi. Dział IT i interesariusze biznesowi są odpowiedzialni za zapewnienie uzyskiwania optymalnej wartości z portfeli projektów i usług. Plan strategiczny powoduje, że kluczowi interesariusze lepiej rozumieją możliwości i ograniczenia technologii IT, umożliwia ocenę aktualnej wydajności, wskazuje wymagania dotyczące potencjału i zasobów ludzkich, a także określa poziom niezbędnych inwestycji. Strategia i priorytety biznesowe powinny mieć odzwierciedlenie w portfelach i powinny być realizowane poprzez plany taktyczne IT, które w zwięzły sposób określają krótkookresowe cele, plany i zadania rozumiane i akceptowane zarówno przez stronę biznesową, jak i IT.

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

SP

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

ZASO

BAM

I

ZARZĄDZANIEZASOBAMI

NADZÓR INFORMATYCZNY

Podstawowy Drugorzędny

Pla

No

Wa

NIE

I oR

Ga

NIZ

aC

Ja



Po1.1 Zarządzanie wartością IT Współpracować ze stroną biznesową w celu zapewnienia tego, że portfel inwestycji przedsiębiorstwa opartych o technologie IT będzie obejmował programy mające solidne uzasadnienie biznesowe. Uznać, że istnieją obligatoryjne, utrzymujące się i uznaniowe inwestycje, które różnią się złożonością i stopniem swobody w alokowaniu funduszy. Procesy IT powinny zapewniać efektywne i wydajne dostarczanie komponentów IT dla programów oraz wczesne ostrzeganie o wszelkich odstępstwach od planu, w tym dotyczących kosztów, harmonogramu i funkcjonalności, które mogą mieć wpływ na oczekiwane wyniki programów. Usługi IT powinny być realizowane na podstawie sprawiedliwych i wykonalnych umów SLA. Należy wyraźnie określić i monitorować rozliczalność za uzyskiwanie korzyści i kontrolowanie kosztów. Wprowadzić system uczciwych, przejrzystych, powtarzalnych i porównywalnych ocen uzasadnień biznesowych, uwzględniających wartość finansową, ryzyko niedostarczenia zdolności oraz ryzyko nieuzyskania oczekiwanych korzyści.

Po1.2 Zgodność między działalnością biznesową a IT Wprowadzić procesy dwukierunkowej edukacji i obustronnego zaangażowania w planowanie strategiczne w celu osiągnięcia zgodności i integracji działalności biznesowej i IT. Poszukiwać kompromisu między wymaganiami biznesowymi i IT w celu określenia wspólnie uzgodnionych priorytetów.

Po1.3 ocena aktualnej zdolności i wydajności Ocenić aktualną zdolność i wydajność dostarczania rozwiązań i usług, aby określić punkt odniesienia dla przyszłych wymagań. Określić wydajność w kategoriach wkładu IT w realizację celów biznesowych, funkcjonalność, stabilność, złożoność, koszty oraz mocne i słabe strony.

Po1.4 Plan strategiczny IT Stworzyć we współpracy z odpowiednimi interesariuszami plan strategiczny, który definiuje, w jaki sposób realizacja celów IT będzie przyczyniać się do realizacji strategicznych celów przedsiębiorstwa, oraz określa związane z tym koszty i ryzyko. Powinien on zawierać informacje, w jaki sposób IT będzie wspierać programy inwestycji oparte o technologie IT oraz usługi i zasoby IT. Dział IT powinien określić, w jaki sposób zostaną osiągnięte cele, jakie będą wykorzystywane pomiary, a także jakie bedą procedury uzyskania formalnego zatwierdzenia przez interesariuszy. Plan strategiczny IT powinien zawierać budżet inwestycyjny/operacyjny, źródła finansowania, strategię zaopatrzenia, strategię nabywania oraz wymagania prawne i regulacyjne. Plan strategiczny powinien być wystarczająco szczegółowy, aby umożliwiać zdefiniowanie taktycznych planów IT.

Po1.5 Plany taktyczne IT Stworzyć portfel planów taktycznych IT, które wynikają z planu strategicznego IT. Plany taktyczne powinny zawierać programy inwestycyjne oparte o technologie IT, usługi IT i zasoby IT. Plany taktyczne powinny opisywać niezbędne inicjatywy IT, wymagania dotyczące zasobów oraz sposób, w jaki będzie monitorowane i zarządzane wykorzystanie zasobów i osiąganie korzyści. Plany taktyczne powinny być wystarczająco szczegółowe, aby umożliwiać zdefiniowanie planów projektów. Aktywnie zarządzać zbiorem taktycznych planów i inicjatyw IT poprzez analizę portfeli projektów i usług.

Po1.6 Zarządzanie portfelem IT Aktywnie zarządzać wraz ze stroną biznesową portfelem programów inwestycji opartych o technologie IT, które są niezbędne do osiągnięcia określonych strategicznych celów biznesowych, poprzez identyfikację, definiowanie, ocenę, określanie hierarchii ważności, wybór, inicjowanie, zarządzanie i kontrolowanie programów. Powinno to obejmować objaśnienie pożądanych wyników biznesowych, zapewnienie, aby cele programów wspierały osiąganie wyników, zrozumienie całego zakresu działań i nakładów niezbędnych do osiągnięcia wyników, wyraźne określenie rozliczalności i towarzyszących jej kryteriów, zdefiniowanie projektów w ramach programu, przydzielenie zasobów i funduszy, przekazanie pełnomocnictwa i uruchomienie niezbędnych projektów przy rozpoczęciu programu.

cele konTrolne

Planowanie i organizacjaDefiniowanie planu strategicznego ITPO1


wyTyczne zarządzania

Cele i mierniki

Źródło Elementy wejściowePO5 Sprawozdaniadotyczącekosztówikorzyści PO9 Ocena ryzykaPO10 ZaktualizowanyportfelprojektówITDS1 Nowe/zaktualizowanewymaganiadotyczące

usług;zaktualizowanyportfel usługIT

* Strategiaipriorytetybiznesowe* PortfelprogramówME1 Danewejściowewydajnościnapotrzeby

planowania ITME4 Raportnatematstanuładu

informatycznego;kierunekstrategicznydlaITokreślonyprzezprzedsiębiorstwo

*DanewejściowespozastrukturyCobiT

Elementy wyjściowe Przeznaczenie Strategiczny plan IT PO8 PO9 AI1 DS1 Taktyczne plany IT PO9 AI1 DS1PortfelprojektówIT PO5 PO6 PO10 AI6PortfelusługIT PO5 PO6 PO9 DS1 Strategia zaopatrzenia IT DS2 StrategianabywaniaIT AI5

• Opóźnienie między aktualizacjami strategicznych/taktycznych planów biznesowych a aktualizacjami planów strategicznych/taktycznych IT

• Procent zebrań poświęconych planom strategicznym/taktycznym IT, w których aktywnie uczestniczyli przedstawiciele strony biznesowej

• Opóźnienia miedzy aktualizacjami planu strategicznego IT a aktualizacjami planów taktycznych IT

• Procent taktycznych planów IT zgodnych z uprzednio zdefiniowaną strukturą/zawartością tych planów

• Procent inicjatyw/projektów IT wspieranych przez właścicieli biznesowych

• Stopień aprobaty właścicieli biznesowych dla planów strategicznych/taktycznych IT

• Stopień zgodności z wymaganiami biznesowymi i dotyczącymi nadzoru

• Poziom zadowolenia strony biznesowej z aktualnego stanu (liczba, zakres itp.) portfela projektów i aplikacji

• Procent celów IT w planie strategicznym IT, które wspierają realizację strategicznego planu biznesowego

• Procent inicjatyw IT w planie taktycznym IT, które wspierają realizację taktycznych planów biznesowych

• Procent projektów IT w portfelu projektów IT, które mają bezpośrednie odniesienie do planów taktycznych IT

Czynności• Zaangażowanie kierownictwa firmy

i wyższej kadry zarządzającej w dostosowanie planowania strategicznego IT do aktualnych i przyszłych potrzeb biznesowych

• Zrozumienie aktualnych zdolności IT• Określenie hierarchii ważności celów

biznesowych, która kwantyfikuje wymagania biznesowe

• Przekładanie planów strategicznych IT na plany taktyczne

IT• Odpowiadać na wymagania biznesowe

zgodnie ze strategią biznesową.• Odpowiadać na wymagania nadzoru

zgodnie z oczekiwaniami zarządu.

Procesy• Określić, w jaki sposób wymagania

biznesowe są przekładane na oferty usług.

• Określić strategię dostarczania ofert usług.

• Wesprzeć zarządzanie portfelem inwestycji opartych o technologie IT.

• Zapewnić przejrzystość wpływu ryzyka biznesowego na cele i zasoby IT.

• Zapewnić przejrzystość i zrozumiałość kosztów, korzyści, strategii, polityki i poziomów usług IT.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Powiązanie celów biznesowych z celami IT. C I A/R R CIdentyfikowanie krytycznych zależności i bieżącej wydajności. C C R A/R C C C C C CTworzenie planu strategicznego IT. A C C R I C C C C I CTworzenie planów taktycznych IT. C I A C C C C C R IAnalizowanie portfeli programowych i zarządzanie portfelami projektów i usług. C I I A R R C R C C I

Tabela RACI wskazuje osoby odpowiedzialne (ang. Responsible), rozliczane (Accountable), konsultujące (Consulted) i informowane (Informed).


PO2…PO6PO2…PO6

Planowanie i organizacjaDefiniowanie planu strategicznego IT PO1

pomiar pomiar pomiar

usta-lenie

usta-lenie

Cele

Mie

rnik

i

stymulacja

stymulacja



Zarządzanie procesem „Definiowanie planu strategicznego IT”, który spełnia wymaganie biznesowe dla IT dotyczące wspierania lub rozwijania strategii biznesowej i wymagań dotyczących nadzoru przy jednoczesnym zapewnieniu przejrzystości korzyści, kosztów i ryzyka, jest:

0 Nieistniejące gdyNie odbywa się planowanie strategiczne IT. Kierownictwo nie jest świadome potrzeby planowania strategicznego IT w celu wspierania realizacji celów biznesowych.

1 Początkowe/doraźne gdyKierownictwo IT dostrzega potrzebę planowania strategicznego IT. Planowanie strategiczne IT odbywa się na doraźnych zasadach, zależnie od określonej potrzeby biznesowej. Planowanie strategiczne IT jest okazjonalnie omawiane na zebraniach kierownictwa działu IT. Dostosowanie wymagań biznesowych, aplikacji i technologii odbywa się raczej w reakcji na bieżące potrzeby niż w ramach ogólnoorganizacyjnej strategii. Identyfikacja ryzyka strategicznego następuje nieformalnie dla poszczególnych projektów.

2 Powtarzalne lecz intuicyjne gdyKierownictwo firmy uczestniczy w planowaniu strategicznym IT na doraźnych zasadach. Aktualizacja planów IT odbywa w odpowiedzi na polecenia kierownictwa. Decyzje strategiczne są podejmowane dla poszczególnych projektów bez zachowania spójności z ogólną strategią organizacji. Ryzyko i korzyści użytkowników z najważniejszych decyzji strategicznych są rozpoznawane w sposób intuicyjny.

3 Zdefiniowane gdyPrzyjęta polityka określa, kiedy i w jaki sposób ma odbywać się planowanie strategiczne IT. Planowanie strategiczne IT opiera się na zorganizowanym podejściu, które jest udokumentowane i znane wszystkim pracownikom. Proces planowania IT jest stosunkowo dobrze zorganizowany i zapewnia duże prawdopodobieństwo prawidłowego planowania. Wdrożenie procesu zależy jednak od decyzji poszczególnych menedżerów i nie ma procedur umożliwiających weryfikację procesu. Ogólna strategia IT uwzględnia spójną definicję ryzyka, które jest skłonna podejmować organizacja nastawiona na innowacyjne lub zachowawcze działanie. Strategie IT w dziedzinie finansów, technologii i zasobów ludzkich w coraz większym stopniu wpływają na nabywanie nowych produktów i technologii. Planowanie strategiczne IT jest omawiane na zebraniach kierownictwa firmy.

4 Kontrolowane i mierzalne gdyPlanowanie strategiczne IT jest standardową praktyką i odstępstwa od niej są dostrzegane przez kierownictwo. Planowanie strategiczne IT jest zdefiniowaną funkcją zarządzania za którą odpowiada kierownictwo wyższego szczebla. Kierownictwo ma możliwość monitorowania procesu planowania strategicznego IT, podejmowania na tej podstawie świadomych decyzji oraz pomiaru jego efektywności. Sporządzane są zarówno krótko- jak i długoterminowe plany IT, które są następnie stopniowo propagowane w organizacji i w razie potrzeby aktualizowane. Strategia IT oraz strategia ogólnoorganizacyjna w coraz większym stopniu są skoordynowane poprzez wspieranie procesów biznesowych i zdolności przynoszących wartość dodaną oraz przez dopasowanie sposobu wykorzystania aplikacji i technologii do reorganizacji procesów biznesowych. Istnieje dobrze zdefiniowany proces decydowania o wykorzystaniu wewnętrznych i zewnętrznych zasobów niezbędnych do rozwoju systemów i operacji.

5 Zoptymalizowane gdyPlanowanie strategiczne IT jest udokumentowanym, żywym procesem. Jest ono stale uwzględniane przy ustalaniu celów biznesowych i poprzez inwestycje w technologie IT przekłada się na rzeczywistą wartość biznesową. W procesie planowania strategicznego stale aktualizuje się założenia dotyczące ryzyka i wartości dodanej. Opracowywane są realistyczne długoterminowe plany IT, które są następnie stale aktualizowane, tak aby odzwierciedły zmieniające się uwarunkowania technologiczne i biznesowe. Przeprowadzane są analizy porównawcze względem dobrze rozumianych i wiarygodnych norm branżowych. Analizy te są następnie uwzględniane w procesie formułowania strategii. Plan strategiczny zawiera stwierdzenia dotyczące tego, w jaki sposób rozwój nowych technologii może stymulować rozwój nowych zdolności biznesowych i zwiększyć przewagę konkurencyjną organizacji.

Model dojrzałości

Planowanie i organizacjaDefiniowanie planu strategicznego ITPO1



Definiowanie architektury informacji


dotyczące zdolności szybkiego reagowania na wymagania w celu dostarczania wiarygodnych i spójnych informacji oraz bezproblemowej integracji aplikacji z procesami biznesowymi


stworzeniu modelu danych przedsiębiorstwa, który zawiera schemat klasyfikacji danych w celu zapewnienia integralności i spójności wszystkich danych,


• zapewnienie trafności architektury informacji i modelu danych; • określenie właścicieli danych; • klasyfikowanie informacji według uzgodnionego schematu klasyfikacji


• procent nadmiarowych/zduplikowanych elementów danych; • procent aplikacji niezgodnych z metodyką architektury informacji

wykorzystywaną przez przedsiębiorstwo; • częstotliwość weryfikacji poprawności danych.

oPis Procesu





PO2 Definiowanie architektury informacji

Funkcja systemów informatycznych tworzy i regularnie aktualizuje model informacji biznesowych oraz definiuje odpowiednie systemy w celu optymalizacji wykorzystania tych informacji. Obejmuje to opracowanie słownika danych korporacyjnych z zasadami składni danych organizacji, schematem klasyfikacji danych oraz poziomami bezpieczeństwa. Proces ten poprawia jakość podejmowania decyzji związanych z zarządzaniem dzięki zapewnieniu dostępu do rzetelnych i bezpiecznych informacji, a także umożliwia racjonalizację zasobów systemów informatycznych, tak aby były odpowiednio dopasowane do strategii biznesowych. Ten proces IT jest również niezbędny do zwiększenia rozliczalności i odpowiedzialności za integralność i bezpieczeństwo danych oraz poprawy efektywności i kontroli nad współdzieleniem danych pomiędzy aplikacjami i jednostkami.

S S PP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIEWARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Planowanie i organizacjaDefiniowanie architektury informacji PO2



Po2.1 Model architektury informacji przedsiębiorstwa Stworzyć i utrzymywać model informacji przedsiębiorstwa umożliwiający tworzenie aplikacji i działania wspierające podejmowanie decyzji, zgodny z planami IT opisanymi w procesie PO1. Model ten powinien ułatwiać optymalne tworzenie, wykorzystywanie i współdzielenie informacji przez firmę w sposób, który zachowuje ich integralność oraz jest elastyczny, funkcjonalny, efektywny kosztowo, terminowy, bezpieczny i odporny na awarie.

Po2.2 Słownik danych przedsiębiorstwa i zasady składni danych Utrzymywać słownik danych przedsiębiorstwa, który zawiera zasady składni danych organizacji. Słownik ten powinien umożliwiać udostępnianie elementów danych aplikacjom i systemom, sprzyjać jednakowemu zrozumieniu danych przez użytkowników z działu IT i użytkowników biznesowych oraz zapobiegać tworzeniu niezgodnych ze sobą elementów danych.

Po2.3 Schemat klasyfikacji danych Stworzyć schemat klasyfikacji obwiązujący w całym przedsiębiorstwie, oparty na kategoriach krytycznego znaczenia i wrażliwości danych przedsiębiorstwa (np. do publicznej wiadomości, poufne, ściśle tajne).Schemat ten powinien zawierać szczegółowe informacje na temat właścicieli danych, definicję odpowiednich poziomów bezpieczeństwa i chroniących mechanizmów kontrolnych oraz krótki opis wymagań dotyczących zachowywania i niszczenia danych, a także ich krytycznego znaczenia i wrażliwości. Powinien on być wykorzystywany jako podstawa do stosowania mechanizmów kontrolnych, takich jak mechanizmy kontroli dostępu, archiwizacja czy szyfrowanie.

Po2.4 Zarządzanie integralnością Zdefiniować i wdrożyć procedury w celu zapewnienia integralności i spójności wszystkich danych przechowywanych w elektronicznej postaci, takiej jak bazy, hurtownie i archiwa danych.

cele konTrolne

Planowanie i organizacjaDefiniowanie architektury informacjiPO2



Cele i mierniki

PO1 Strategiczne i taktyczne plany ITAI1 StudiumwykonalnościwymagańbiznesowychAI7 PrzeglądpowdrożeniowyDS3 InformacjedotyczącewydajnościipotencjałuME1 Danewejściowewydajnościnapotrzeby

planowania IT

Schematklasyfikacjidanych AI2Zoptymalizowaneplanysystemówbiznesowych PO3 AI2Słownikdanych AI2 DS11 Architektura informacji PO3 DS5Klasyfikacjaprzypisanychdanych DS1 DS4 DS5 DS11 DS12Proceduryinarzędziaklasyfikacji *

*ElementywyjściowepozastrukturęCobiT

• Częstotliwość aktualizacji modelu danych przedsiębiorstwa

• Procent elementów danych, które nie mają właściciela

• Częstotliwość weryfikacji poprawności danych

• Poziom uczestnictwa społeczności użytkowników

• Procentowy poziom zadowolenia użytkowników modelu informacji (np. czy słownik danych jest przyjazny dla użytkownika?)

• Procent nadmiarowych/zduplikowanych elementów danych

• Procent elementów danych, które nie są częścią modelu danych przedsiębiorstwa

• Procentowy poziom niezgodności ze schematem klasyfikacji danych

• Procent aplikacji niezgodnych z architekturą informacji

Czynności• Zapewnienie trafności architektury

informacji i modelu danych• Określenie właścicieli danych• Klasyfikowanie informacji według

uzgodnionego schematu klasyfikacji• Zapewnienie spójności między

komponentami infrastruktury IT (np. architekturą informacji, słownikami danych, aplikacjami, składnią danych, schematami klasyfikacji i poziomami bezpieczeństwa)

• Utrzymywanie integralności danych

IT• Zoptymalizować wykorzystanie

informacji.• Zapewnić bezproblemową integrację

aplikacji z procesami biznesowymi.• Odpowiadać na wymagania biznesowe

zgodnie ze strategią biznesową.• Zapewnić zdolność szybkiego

reagowania IT.

Proces• Stworzyć model danych

przedsiębiorstwa. • Ograniczyć nadmiarowość danych.• Wspierać efektywne zarządzanie

informacjami.

Tworzenie i utrzymywanie modelu informacji w korporacji/przedsiębiorstwie. C I A C R C C CTworzenie i utrzymywanie słownika(-ów) danych korporacyjnych. I C A/R R CUstanawianie i utrzymywanie schematu klasyfikacji danych. I C A C C I C C RZapewnienie właścicielom danych procedur i narzędzi do klasyfikowania systemów informacyjnych. I C A C C I C C RWykorzystywanie modelu informacji, słownika danych i schematu klasyfikacji w celu C C I A C R C I planowania zoptymalizowanych systemów biznesowych.

Czynności

Tabela RACI FunkcjeDy

rekto

r gen

eraln

y (CE

O)Dy

rekto

r ds.

finan

sowy

ch (C

FO)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em



Planowanie i organizacjaDefiniowanie architektury informacji PO2

Źródło Elementywejściowe Elementywyjściowe PrzeznaczenieŹródło Elementy wejściowe Elementy wyjściowe Przeznaczenie


stymulacja

stymulacja

usta-lenie

usta-lenie

Cele

Mie

rnik

i



Zarządzanie procesem „Definiowanie architektury informacji”, który spełnia wymaganie biznesowe dla IT dotyczące zdolności szybkiego reagowania na wymagania w celu dostarczania wiarygodnych i spójnych informacji oraz bezproblemowej integracji aplikacji z procesami biznesowymi, jest:

0 Nieistniejące gdyNie ma świadomości znaczenia architektury informacji dla organizacji. W organizacji nie ma wiedzy, kompetencji ani odpowiedzialności niezbędnej do opracowania takiej architektury.

1 Początkowe/doraźne gdyKierownictwo dostrzega potrzebę istnienia architektury informacji. Rozwój niektórych komponentów architektury informacji odbywa się na doraźnych zasadach. Definicje odnoszą się bardziej do danych niż do informacji i wynikają z oferty producentów oprogramowania aplikacji. Występuje niespójna i sporadyczna komunikacja dotycząca potrzeby istnienia architektury informacji.

2 Powtarzalne lecz intuicyjne gdyPojawia się proces definiowania architektury informacji i różne osoby w organizacji przestrzegają podobnych lecz nieformalnych i intuicyjnych procedur. Pracownicy zdobywają umiejętności tworzenia architektury informacji poprzez praktyczne doświadczenie i powtarzalne stosowanie określonych technik. Wymagania techniczne stymulują rozwój komponentów architektury informacji przez poszczególnych pracowników.

3 Zdefiniowane gdyZnaczenie architektury informacji jest rozumiane i akceptowane. Określona jest również i jasno komunikowana odpowiedzialność za jej zapewnienie. Związane z tym procedury, narzędzia i techniki choć nie są zaawansowane, zostały ustandaryzowane i udokumentowane oraz są przedmiotem nieformalnej działalności szkoleniowej. Opracowano podstawową politykę dotyczącą architektury informacji uwzględniającą pewne wymagania strategiczne, jednak zgodność z polityką, standardami i narzędziami nie jest konsekwentnie egzekwowana. Istnieje formalnie zdefiniowana funkcja administracji danych określająca ogólnoorganizacyjne standardy i zaczyna się rozwijać sprawozdawczość dotycząca dostarczania i wykorzystywania architektury informacji. Pojawia się zastosowanie zautomatyzowanych narzędzi, ale wykorzystywane procesy i zasady wynikają z oferty producentów oprogramowania baz danych. Opracowano formalny plan szkoleń, ale sformalizowane szkolenia nadal opierają się na indywidualnych inicjatywach.

4 Kontrolowane i mierzalne gdyOpracowanie i egzekwowanie stosowania architektury informacji jest w pełni wspierane przez formalne metody i techniki. Egzekwowana jest odpowiedzialność za wydajność procesu rozwoju architektury i mierzone są korzyści z jej wykorzystania. Szeroko stosowane są pomocnicze zautomatyzowane narzędzia, ale nie są one zintegrowane. Zidentyfikowano podstawowe mierniki i funkcjonuje system pomiarowy. Proces definiowania architektury informacji ma proaktywny charakter i jest skoncentrowany na realizacji przyszłych potrzeb biznesowych. W celu zapewnienia zgodności organizacja administracji danymi aktywnie uczestniczy w działaniach związanych z rozwojem aplikacji. W pełni wdrożone jest zautomatyzowane repozytorium. Wdrażane W celu wykorzystywania zawartości informacji w bazach danych wdrażane są bardziej złożone modele danych. Systemy informowania kierownictwa i systemy wspomagania decyzji wykorzystują dostępne informacje.

5 Zoptymalizowane gdyArchitektura informacji jest konsekwentnie egzekwowana na wszystkich poziomach. Stale podkreślana jest wartość architektury informacji dla przedsiębiorstwa. Pracownicy działu IT mają kompetencje i umiejętności niezbędne do stworzenia i utrzymywania trwałej i szybko reagującej architektury informacji, która odpowiada wszystkim wymaganiom biznesowym. Informacje dostarczane przez architekturę informacji są konsekwentnie i powszechnie wykorzystywane. Powszechnie korzysta się z dobrych praktyk branżowych w dziedzinie rozwoju i utrzymywania architektury informacji, podobnie jak z wyników procesu ciągłego doskonalenia. Zdefiniowana jest strategia wykorzystywania informacji poprzez hurtownie danych i zdefiniowane są technologie eksploracji danych. Architektura informacji jest stale udoskonalana i uwzględnia niestandardowe informacje dotyczące procesów, organizacji i systemów.

Model dojrzałości

Planowanie i organizacjaDefiniowanie architektury informacjiPO2


oPis Procesu


Ustalanie kierunku technologicznego


dotyczące posiadania stabilnych, efektywnych kosztowo, zintegrowanych i ustandaryzowanych systemów aplikacji, zasobów i zdolności, które spełniają obecne i przyszłe wymagania biznesowe


zdefiniowaniu i wdrożeniu planu infrastruktury technicznej, architektury i standardów, które uwzględniają i wykorzystują możliwości technologiczne,


• powołanie forum, które będzie określać kierunek rozwoju architektury i weryfikować zgodność;

• opracowanie planu infrastruktury technicznej zrównoważonego pod względem kosztów, ryzyka i wymagań;

• zdefiniowanie standardów infrastruktury technicznej w oparciu o wymagania architektury informacji


• liczbę i rodzaj odstępstw od planu infrastruktury technicznej; • częstotliwość przeglądów/aktualizacji planu infrastruktury

technicznej; • liczbę platform technologicznych według ich funkcji

w przedsiębiorstwie.





PO3 Ustalanie kierunku technologicznego

Funkcja usług informatycznych określa kierunek rozwoju technologicznego wspierający działalność biznesową. Wymaga to stworzenia planu infrastruktury technicznej oraz rady ds. architektury, która określa i zarządza jasno sprecyzowanymi i realistycznymi oczekiwaniami wobec tego, co może zaoferować technologia w odniesieniu do produktów, usług i mechanizmów ich dostarczania. Plan ten jest regularnie aktualizowany i obejmuje takie aspekty, jak architektura systemów, kierunek technologiczny, plany nabycia, standardy, strategie migracji czy rozwiązania awaryjne. Umożliwia to odpowiednio szybkie reagowanie na zmiany w środowisku konkurencyjnym, uzyskiwanie korzyści skali w odniesieniu do zatrudnienia i inwestycji w obszarze systemów informatycznych, a także lepsze współdziałanie platform i aplikacji.

PP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Planowanie i organizacjaUstalanie kierunku technologicznego PO3



Po3.1 Planowanie kierunku technologicznego Analizować istniejące i powstające technologie i planować kierunek technologiczny, który będzie odpowiedni do realizacji strategii IT oraz architektury systemów biznesowych. Określić w planie, które technologie mają potencjał do stworzenia nowych możliwości biznesowych. Plan powinien dotyczyć architektury systemów, kierunku technologicznego, strategii migracji oraz aspektów rozwiązań awaryjnych dla komponentów infrastruktury.

Po3.2 Plan infrastruktury technicznej Stworzyć i utrzymywać plan infrastruktury technicznej, który jest zgodny z planami strategicznymi i taktycznymi IT. Plan powinien być zgodny z przyjętym kierunkiem technologicznym i obejmować rozwiązania awaryjne oraz określać kierunek dla nabywania zasobów technicznych. Powinien on uwzględniać zmiany w środowisku konkurencyjnym, korzyści skali w odniesieniu do zatrudnienia i inwestycji w obszarze systemów informatycznych, a także lepsze współdziałanie platform i aplikacji.

Po3.3 Monitorowanie przyszłych trendów i regulacji Wprowadzić proces monitorowania trendów dotyczących sektora biznesowego, branży, technologii, infrastruktury oraz wymagań prawnych i regulacyjnych. Uwzględniać następstwa trendów przy rozwijaniu planu infrastruktury technicznej IT.

Po3.4 Standardy technologiczne W celu zapewnienia spójnych, efektywnych i bezpiecznych rozwiązań technicznych dla całego przedsiębiorstwa należy powołać forum technologiczne, które określi wytyczne dla technologii, będzie służyć doradztwem w sprawie produktów infrastrukturalnych i wyboru technologii oraz oceniać zgodność z tymi standardami i wytycznymi. Forum to powinno powinno dobierać standardy technologiczne i praktyki, uwzględniając ich znaczenie dla działalności biznesowej, ryzyko oraz zgodność z zewnętrznymi regulacjami.

Po3.5 Rada ds. architektury IT Powołać radę ds. architektury IT określającą wytyczne dotyczące architektury i służącą doradztwem w kwestiach jej zastosowania, a także weryfikującą zachowanie zgodności. Podmiot ten powinien nadawać kierunek projektowaniu architektury IT, tak aby umożliwiała ona realizację strategii biznesowej i uwzględniała wymagania dotyczące zachowania zgodności i zapewnienia ciągłości. Jest to powiązane z procesem PO2 Definiowanie architektury informacji.

cele konTrolne

Planowanie i organizacjaUstalanie kierunku technologicznegoPO3



Cele i mierniki

PO1 Strategiczne i taktyczne plany ITPO2 Zoptymalizowanyplansystemów

biznesowych,architekturainformacjiAI3 AktualizacjestandardówtechnologicznychDS3 Informacjedotyczącewydajnościipotencjału

Możliwościtechnologiczne AI3Standardytechnologiczne AI1 AI3 AI7 DS5Regularneaktualizacjedotyczące AI1 AI2 AI3 „stanu technologicznego” Plan infrastruktury technologicznej AI3Wymaganiadotycząceinfrastruktury PO5

• Częstotliwość spotkań organizowanych przez forum technologiczne

• Częstotliwość spotkań organizowanych przez radę ds. architektury IT

• Częstotliwość przeglądów/aktualizacji planu infrastruktury technicznej

• Liczba i rodzaj odstępstw od planu infrastruktury technicznej

• Procent niezgodności ze standardami technologicznymi

• Liczba platform technologicznych według ich funkcji w przedsiębiorstwie

Czynności• Zdefiniowanie standardów infrastruktury

technicznej w oparciu o wymagania architektury informacji

• Opracowanie planu infrastruktury technicznej zrównoważonego pod względem kosztów, ryzyka i wymagań

• Powołanie forum, które będzie określać kierunek rozwoju architektury i weryfikować zgodność

IT• Zoptymalizować infrastrukturę, zasoby

i potencjał IT.• Nabywać i utrzymywać zintegrowane

i ustandaryzowane systemy aplikacji.

Proces• Rozpoznawać i wykorzystywać

możliwości technologiczne.• Opracować i wdrożyć plan infrastruktury

technicznej.• Zdefiniować architekturę i standardy

technologiczne dla infrastruktury IT.

Utworzenie i utrzymywanie planu infrastruktury technicznej. I I A C R C C CUtworzenie i utrzymywanie standardów technologicznych. A C R C I I IPublikowanie standardów technologicznych. I I A I R I I I IMonitorowanie rozwoju technologii. I I A C R C C CDefiniowanie (przyszłego) (strategicznego) wykorzystania nowej technologii. C C A C R C C C

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em



Planowanie i organizacjaUstalanie kierunku technologicznego PO3



stymulacja

stymulacja

usta-lenie

usta-lenie

Cele

Mie

rnik

i



Zarządzanie procesem „Ustalanie kierunku technologicznego”, który spełnia wymaganie biznesowe dla IT dotyczące posiadania stabilnych, efektywnych kosztowo, zintegrowanych i ustandaryzowanych systemów aplikacji, zasobów i zdolności, które spełniają obecne i przyszłe wymagania biznesowe, jest:

0 Nieistniejące gdyNie ma świadomości znaczenia planowania infrastruktury technicznej dla organizacji. Nie ma wiedzy ani kompetencji niezbędnych do stworzenia planu infrastruktury technicznej. Brakuje zrozumienia dla faktu, że planowanie zmiany technologicznej ma kluczowe znaczenie dla efektywnej alokacji zasobów.

1 Początkowe/doraźne gdyKierownictwo dostrzega potrzebę planowania infrastruktury technicznej. Rozwój komponentów technologicznych i wdrażanie powstających technologii odbywa się na doraźnych zasadach i w izolowanych obszarach. Funkcjonuje reaktywne i ukierunkowane operacyjnie podejście do planowania infrastruktury. Kierunki rozwoju technologicznego są uzależnione od często sprzecznych ze sobą planów ewolucji produktów dotyczących sprzętu i oprogramowania systemowego, a także od producentów oprogramowania aplikacji. Komunikacja dotycząca potencjalnego wpływu zmian technologicznych jest niespójna.

2 Powtarzalne lecz intuicyjne gdyKomunikowana jest potrzeba i znaczenie planowania infrastruktury technicznej. Planowanie ma taktyczny charakter i jest skoncentrowane bardziej na rozwiązywaniu problemów technicznych niż na wykorzystaniu technologii do realizacji celów biznesowych. Ocena zmian technologicznych jest pozostawiona różnym osobom, które realizują intuicyjny, ale podobny proces. Pracownicy zdobywają umiejętności planowania infrastruktury technicznej poprzez praktyczne doświadczenie i powtarzalne stosowanie pewnych technik. Pojawiają się powszechnie stosowane techniki i standardy rozwoju elementów infrastruktury.

3 Zdefiniowane gdyKierownictwo jest świadome znaczenia planu infrastruktury technicznej. Proces tworzenia planu infrastruktury technicznej jest stosunkowo dobrze zorganizowany i zgodny z planem strategicznym IT. Istnieje zdefiniowany, udokumentowany i dobrze komunikowany plan infrastruktury technicznej, ale jest niekonsekwentnie stosowany. Kierunkowi rozwoju infrastruktury technicznej towarzyszy zrozumienie, w oparciu o ocenę ryzyka i strategię organizacji, w jakich dziedzinach organizacja chce być liderem, a w jakich chce pozostawać w tyle pod względem wykorzystania technologii. Kluczowi dostawcy są wybierani na podstawie oceny ich długoterminowych planów rozwoju technologii i produktów, zgodnie z przyjętym kierunkiem rozwoju organizacji. Mają miejsce formalne szkolenia i komunikacja dotycząca ról i zakresów odpowiedzialności.

4 Kontrolowane i mierzalne gdyKierownictwo zapewnia rozwój i utrzymywanie planu infrastruktury technicznej. Pracownicy działu IT mają odpowiednie kompetencje i umiejętności do tworzenia planu infrastruktury technicznej. Brany jest pod uwagę potencjalny wpływ zmieniających się i powstających technologii. Kierownictwo może identyfikować odstępstwa od planu i zawczasu przeciwdziałać problemom. Została określona odpowiedzialność za opracowanie i utrzymywanie planu infrastruktury technicznej. Proces tworzenia planu infrastruktury technicznej ma zaawansowany charakter i zdolność reagowania na zmiany. Do procesu wprowadzono wewnętrzne dobre praktyki. Strategia zarządzania zasobami ludzkimi jest zgodna z kierunkiem technologicznym, aby pracownicy działu IT byli zdolni do zarządzania zmianami technologicznymi. Zdefiniowane są plany migracji związane z wprowadzaniem nowych technologii. Wykorzystywany jest outsourcing i współpraca partnerska w celu zapewnienia dostępu do niezbędnych kompetencji i umiejętności. Kierownictwo dokonało analizy dopuszczalnego poziomu ryzyka w odniesieniu do wiodącego lub zachowawczego wykorzystania technologii w rozwijaniu nowych możliwości biznesowych lub efektywności operacyjnej.

5 Zoptymalizowane gdyIstnieje komórka badawcza mająca za zadanie analizę pojawiających się i rozwijających się technologii oraz dokonywanie oceny porównawczej organizacji w odniesieniu do norm branżowych. Kierunek rozwoju planu infrastruktury technicznej jest w większym stopniu wyznaczany przez branżowe i międzynarodowe standardy i osiągnięcia niż przez dostawców technologii. Potencjalny wpływ zmiany technologicznej jest oceniany na poziomie wyższej kadry zarządzającej. Zmiany kierunku technologicznego są formalnie zatwierdzane przez kierownictwo. Organizacja ma stabilny plan infrastruktury technicznej, który odzwierciedla wymagania biznesowe, umożliwia szybkie reagowanie i może być zmodyfikowany w obliczu zmian w środowisku biznesowym. Egzekwowany jest proces ciągłego doskonalenia planu infrastruktury technicznej. Do określania kierunku rozwoju technologicznego w szerokim zakresie wykorzystywane są dobre praktyki branżowe.

Model dojrzałości

Planowanie i organizacjaUstalanie kierunku technologicznegoPO3


oPis Procesu


Definiowanie procesów IT, organizacji i wzajemnych zależności,


dotyczące zdolności szybkiego reagowania na wymagania strategii biznesowej przy jednoczesnym zachowaniu zgodności z wymaganiami nadzoru i zapewnieniu określonych i kompetentnych punktów kontaktu


stworzeniu przejrzystych, elastycznych i zdolnych do szybkiego reagowania struktur organizacyjnych działu IT oraz zdefiniowaniu i wdrożeniu procesów IT z ich właścicielami, rolami i zakresami odpowiedzialności, zintegrowanych z procesami biznesowymi i procesami podejmowania decyzji,


• zdefiniowanie struktury ramowej procesów IT; • stworzenie odpowiednich jednostek i struktury organizacyjnej; • zdefiniowanie ról i zakresów odpowiedzialności


• procent ról z udokumentowanym opisem stanowiska i uprawnień; • liczbę jednostek biznesowych/procesów, które nie są wspierane przez

organizację IT, a powinny być zgodnie z przyjętą strategią; • liczbę podstawowych działań IT poza organizacją IT, które nie są

zatwierdzone lub nie podlegają standardom organizacyjnym IT.





PO4 Definiowanie procesów it, organizacji i wzajemnych zależności

Organizacja działu IT jest definiowana przez wymagania dotyczące personelu, umiejętności, funkcji, odpowiedzialności, uprawnień, ról i obowiązków oraz nadzoru. Organizacja ta jest wbudowana w strukturę ramową procesów IT, która zapewnia przejrzystość i kontrolę, a także zaangażowanie wyższej kadry zarządzającej i kierownictwa firmy. Komitet strategiczny zapewnia nadzór zarządu i rady nadzorczej nad IT, a jeden lub więcej komitetów sterujących, w których uczestniczy strona biznesowa i IT, określają hierarchię ważności zasobów IT zgodnie z potrzebami firmy. Dla wszystkich funkcji, ze szczególnym uwzględnieniem kontroli, zapewnienia jakości, zarządzania ryzykiem, bezpieczeństwa informacji, własności danych i systemów oraz rozdziału obowiązków, przewidziane są odpowiednie procesy, polityka administracyjna i procedury. Dział IT jest zaangażowany w odpowiednie procesy decyzyjne w taki sposób, aby na czas zapewnić wsparcie dla wymagań biznesowych.

PP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Planowanie i organizacjaDefiniowanie procesów IT, organizacji i wzajemnych zależności PO4



Po4.1 Struktura ramowa procesów IT Zdefiniować strukturę procesów IT w celu realizacji planu strategicznego IT. Struktura ta powinna określać strukturę danego procesu IT oraz jego relacje z pozostałymi procesami IT (np. aby eliminować luki i nakładanie się procesów), ich właścicieli, dojrzałość, pomiar wydajności, doskonalenie, zapewnienie zgodności, cele jakościowe oraz plany ich realizacji. Powinna ona zapewniać integrację między procesami specyficznymi dla IT a zarządzaniem portfelem przedsiębiorstwa, procesami biznesowymi i procesami zmian biznesowych. Struktura procesów IT powinna być zintegrowana z systemem zarządzania jakością oraz strukturą wewnętrznych mechanizmów kontrolnych.

Po4.2 Komitet strategiczny ds. IT Powołać komitet strategiczny ds. IT na poziomie zarządu. Komitet powinien zapewniać odpowiednią realizację nadzoru informatycznego, będącego częścią ładu korporacyjnego, doradztwo w związane z wyborem kierunku strategicznego oraz przegląd najważniejszych inwestycji w imieniu zarządu.

Po4.3 Komitet sterujący ds. IT Powołać Komitet sterujący ds. IT (lub odpowiednik), składający się z przedstawicieli głównego kierownictwa, kierownictwa biznesowego i kierownictwa działu IT, aby:• określać hierarchię ważności programów inwestycji opartych o technologie IT zgodnie ze strategią i priorytetami biznesowymi;• śledzić stan projektów i rozwiązywać konflikty zasobów;• monitorować poziomy usług i doskonalenie usług.

Po4.4 organizacyjne umiejscowienie funkcji działu IT Umiejscowić funkcję IT w ogólnej strukturze organizacyjnej i w ramach modelu biznesowego, który jest adekwatny do roli IT w przedsiębiorstwie, a zwłaszcza do jej znaczenia dla realizacji strategii biznesowej i poziomu operacyjnej zależności od IT. Hierarchia podległości służbowej dyrektora ds. informatyki (CIO) powinna być adekwatna do znaczenia działu IT w przedsiębiorstwie.

Po4.5 Struktura organizacyjna działu IT Określić wewnętrzną i zewnętrzną strukturę organizacyjną działu IT, która odzwierciedla potrzeby biznesowe. Ponadto wdrożyć proces okresowych przeglądów struktury organizacyjnej IT w celu dostosowywania wymagań zatrudnienia i strategii pozyskiwania zasobów do oczekiwanych celów biznesowych i zmieniających się uwarunkowań.

Po4.6 określenie ról i zakresów odpowiedzialności Określić i zakomunikować role i zakresy odpowiedzialności personelu IT oraz użytkowników końcowych, które wyznaczają granice między uprawnieniami personelu IT i użytkowników końcowych, ich zakresy odpowiedzialności oraz rozliczalność za realizację potrzeb organizacji.

Po4.7 odpowiedzialność za zapewnienie jakości IT Określić odpowiedzialność za realizację funkcji zapewnienia jakości (QA) i zorganizować grupę ds. zapewnienia jakości dysponującą odpowiednimi kompetencjami w zakresie systemów, mechanizmów kontrolnych i komunikacji w dziedzinie zapewnienia jakości. Zapewnić, aby umiejscowienie w strukturze organizacyjnej, zakres odpowiedzialności i wielkość grupy ds. zapewnienia jakości były adekwatne do wymagań organizacji.

Po4.8 odpowiedzialność za zarządzanie ryzykiem, bezpieczeństwo i zgodność Określić własność i zakres odpowiedzialności związanej z zarządzaniem ryzykiem informatycznym na odpowiednim poziomie wyższej kadry zarządzającej. Zdefiniować i przydzielić role mające krytyczne znaczenie dla zarządzania ryzykiem informatycznym, uwzględniając odpowiedzialność za bezpieczeństwo informacji, bezpieczeństwo fizyczne oraz zapewnienie zgodności. Określić odpowiedzialność za zarządzanie ryzykiem i bezpieczeństwem na poziomie ogólnoorganizacyjnym, tak aby można było radzić sobie z problemami ogólnoorganizacyjnymi. Niezbędne może być przydzielenie dodatkowych obowiązków w zakresie zarządzania bezpieczeństwem na poziomie właściwym dla określonych systemów. Uzyskać wskazówki wyższej kadry zarządzającej dotyczące skłonności do podejmowania ryzyka informatycznego oraz akceptacji ewentualnego ryzyka szczątkowego.

Po4.9 Własność danych i systemów Zapewnić stronie biznesowej procedury i narzędzia umożliwiające wykonywanie obowiązków związanych z własnością danych i systemów informatycznych. Właściciele powinni podejmować decyzje dotyczące klasyfikacji informacji i systemów oraz ich ochrony zgodnie określoną klasyfikacją.

Po4.10 Nadzór Wdrożyć odpowiednie praktyki nadzoru w ramach funkcji IT zapewniające odpowiednie wykonywanie ról i obowiązków, ocenę tego, czy wszyscy pracownicy mają wystarczające uprawnienia i zasoby, aby wykonywać swoje role i obowiązki, a także dla wykonywania ogólnego przeglądu wskaźników KPI.

Po4.11 Rozdział obowiązków Wprowadzić rozdział ról i obowiązków w celu ograniczenia możliwości narażenia na szkodę krytycznego procesu przez pojedynczą osobę. Zapewnić, aby pracownicy działali wyłącznie w ramach swoich uprawnień przypisanych do ich ról i stanowisk.

cele konTrolne

Planowanie i organizacjaDefiniowanie procesów IT, organizacji i wzajemnych zależnościPO4


Po4.12 obsada stanowisk w dziale IT Oceniać wymagania dotyczące obsady stanowisk regularnie i/lub czynić to w przypadku znaczących zmian w środowisku biznesowym, operacyjnym lub informatycznym, tak aby mieć pewność, że dział IT dysponuje odpowiednimi zasobami, by właściwie wspierać realizację celów biznesowych.

Po4.13 Kluczowy personel IT Zdefiniować i zidentyfikować kluczowy personel IT (np. zastępstwa/personel rezerwowy) i zminimalizować zależność od pojedynczych osób pełniących kluczowe funkcje.

Po4.14 Polityka i procedury dotyczące pracowników kontraktowych Zapewnić, aby konsultanci i pracownicy kontraktowi, którzy wspierają funkcję IT, znali i zachowywali zgodność z polityką organizacji dotyczącą ochrony zasobów informacyjnych oraz spełniali wymagania wynikające z zawartych umów.

Po4.15 Relacje Ustanowić i utrzymywać optymalną strukturę koordynacji, komunikacji i współdziałania między funkcją IT a różnymi innymi stronami w ramach funkcji IT i poza nią, takimi jak zarząd, kadra kierownicza, jednostki biznesowe, indywidualni użytkownicy, dostawcy, specjaliści ds. bezpieczeństwa, zarządzający ryzykiem, korporacyjna grupa ds. zgodności, podmioty świadczące usługi outsourcingu i pozamiejscowe kierownictwo.




strona celowo pozostawiona pusta



Cele i mierniki

Źródło Elementy wejściowe PO1 Plany strategiczne i taktycznePO7 Politykaiproceduryzarządzaniazasobami

ludzkimiIT,macierzumiejętnościIT,opisystanowisk

PO8 DziałaniazwiązanezpodnoszeniemjakościPO9 Planydziałańnaprawczychzwiązanych

z ryzykiem informatycznymME1 PlanydziałańnaprawczychME2 Sprawozdaniedotycząceefektywności

mechanizmówkontrolnychITME3 Katalogwymagańprawnychiregulacyjnych

dotyczącychświadczeniausługITME4 Udoskonaleniastrukturyramowejprocesów

Elementy wyjściowe PrzeznaczenieStrukturaramowaprocesówIT ME4Udokumentowaniwłaścicielesystemów AI7 DS6 Organizacja i relacje w IT PO7StrukturaramowaprocesówIT,udokumentowaneroleWszy- iobowiązki stkieUdokumentowaneroleiobowiązki PO7

• Procent ról z udokumentowanym opisem stanowiska i uprawnień

• Procent funkcji/procesów operacyjnych IT, które są powiązane z biznesowymi strukturami operacyjnymi

• Częstotliwość spotkań komitetu strategicznego i sterującego

• Wyniki (badań) zadowolenia interesariuszy

• Liczba inicjatyw biznesowych opóźnionych z powodu bezwładu organizacyjnego IT lub braku niezbędnych zdolności

• Liczba procesów biznesowych, które nie są wspierane przez organizację IT, a powinny być zgodnie z przyjętą strategią

• Liczba podstawowych działań IT poza organizacją IT, które nie są zatwierdzone lub nie podlegają standardom organizacyjnym IT

• Liczba obowiązków kolidujących z punktu widzenia rozdziału obowiązków

• Liczba problemów eskalowanych lub nierozwiązanych z powodu braku lub niewystarczającego określenia zakresu odpowiedzialności

• Procent interesariuszy zadowolonych z szybkości reagowania działu IT

Czynności• Zdefiniowanie struktury ramowej

procesów IT• Stworzenie odpowiednich jednostek

i struktury organizacyjnej

IT• Odpowiadać na wymagania nadzoru

zgodnie z oczekiwaniami zarządu.• Odpowiadać na wymagania biznesowe

zgodnie ze strategią biznesową.• Zapewnić zdolność szybkiego

reagowania IT.

Proces• Ustanowić elastyczne i zdolne do

szybkiego reagowania struktury organizacyjne i relacje w IT.

• Jasno zdefiniować właścicieli, role i zakresy obowiązków dla wszystkich procesów IT i relacji interesariuszy.

Ustanowienie struktury organizacyjnej działu IT, w tym komitetów i powiązań z C C C A C C C R C I interesariuszami i dostawcami. Zaprojektowanie struktury procesów IT. C C C A C C C R C CIdentyfikacja właścicieli systemów. C C A C R I I I I IIdentyfikacja właścicieli danych. I A C C I R I I I CUstanowienie i wdrożenie ról i zadań IT, w tym nadzór I I A I C C C R C C nad obowiązkami i ich podział.

Czynności

Tabela RACI Funkcje

Dyrek

tor ge

neral

ny (C

EO)

Dyrek

tor ds

. fina

nsow

ych (

CFO)

Człon

ek za

rządu

Dyrek

tor ds

. infor

matyk

i (CIO

)

Właś

ciciel

proc

esu b

iznes

oweg

o

Kierow

nik dz

iału o

perac

yjneg

oGł

ówny

arch

itekt

Kierow

nik ds

. rozw

ojuKie

rownik

ds. a

dmini

strac

ji IT

Kierow

nik bi

ura za

rządz

ania

projek

tami (P

MO)

Kontr

ola w

ewnę

trzna

; Aud

yt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em





stymulacja

stymulacja

usta-lenie

usta-lenie

Cele

Mie

rnik

i



Zarządzanie procesem „Definiowanie procesów IT, organizacji i wzajemnych zależności”, który spełnia wymaganie biznesowe dla IT dotyczące zdolności szybkiego reagowania na wymagania strategii biznesowej przy jednoczesnym zachowaniu zgodności z wymaganiami nadzoru i zapewnieniu określonych i kompetentnych punktów kontaktu, jest:

0 Nieistniejące gdyOrganizacja IT nie jest ustanowiona tak, aby koncentrować się na osiąganiu celów biznesowych.

1 Początkowe/doraźne gdyDziałania i funkcje IT są wdrażane na doraźnych i niespójnych zasadach. Dział IT jest angażowany w projekty biznesowe dopiero na późniejszych etapach. Uznaje się, że dział IT ma pełnić tylko funkcję wspierającą, bez uwzględnienia ogólnoorganizacyjnej perspektywy. Istnieje domniemane zrozumienie potrzeby organizacji IT; jednak role i obowiązki nie są sformalizowane ani egzekwowane.

2 Powtarzalne lecz intuicyjne gdyFunkcja IT jest zorganizowana, aby reagować taktycznie (ale w niespójny sposób) na potrzeby klientów i relacje z dostawcami. Komunikowana jest potrzeba dobrej organizacji i zarządzania relacjami z dostawcami, ale decyzje wciąż są uzależnione od wiedzy i umiejętności kluczowych osób. Pojawiają się powszechnie stosowane techniki zarządzania organizacją IT i relacjami z dostawcami.

3 Zdefiniowane gdyIstnieją zdefiniowane role i obowiązki dla organizacji IT i stron trzecich. Zasady organizacji IT są udokumentowane, komunikowane i zgodne ze strategią IT. Zdefiniowane jest środowisko kontroli wewnętrznej. Istnieją sformalizowane relacje z innymi jednostkami, w tym komitetami sterującymi, jednostkami audytu wewnętrznego i kierownictwami firm–dostawców. Organizacja IT jest funkcjonalnie kompletna. Istnieją definicje funkcji, które mają być pełnione przez personel IT oraz przez użytkowników. Zdefiniowane i spełniane są najważniejsze wymagania dotyczące zatrudnienia i kompetencji w dziale IT. Istnieje formalna definicja relacji z użytkownikami i stronami trzecimi. Zdefiniowany i wdrożony jest rozdział ról i obowiązków.

4 Kontrolowane i mierzalne gdyOrganizacja IT aktywne reaguje na zmiany i uwzględnia wszystkie role niezbędne do spełniania wymagań biznesowych. Zarządzanie IT, własność procesów, rozliczalność i odpowiedzialność są zdefiniowane i zrównoważone. W organizacji funkcji IT uwzględniono wewnętrzne dobre praktyki. Kierownictwo działu IT ma wystarczające kompetencje i umiejętności, aby definiować, wdrażać i monitorować preferowaną organizację i relacje. Istnieją ustandaryzowane mierniki wpierające realizację celów biznesowych oraz zdefiniowane przez użytkowników kluczowe czynniki sukcesu (CSF). Dostępne są wykazy umiejętności pomocne w wyborze odpowiednich osób do realizacji projektów i we wspieraniu rozwoju zawodowego. Zdefiniowany i egzekwowany jest stan równowagi między umiejętnościami i zasobami, które są dostępne wewnętrznie, a tymi, które wymagają pozyskiwania z zewnątrz. Struktura organizacyjna IT w odpowiedni sposób odzwierciedla potrzeby biznesowe, dostarczając usługi, które są dostosowane do strategicznych procesów biznesowych, a nie do odosobnionych rozwiązań technologicznych.

5 Zoptymalizowane gdyStruktura organizacyjna IT jest elastyczna i zdolna do adaptacji. Wdrażane są dobre praktyki branżowe. W szerokim zakresie wykorzystuje się technologię do monitorowania wydajności organizacji i procesów IT. Jednocześnie rozwiązania technologiczne pozwalają organizacji lepiej radzić sobie z jej złożonością i geograficznym rozproszeniem. Funkcjonuje proces ciągłego doskonalenia.

Model dojrzałości



oPis Procesu


Zarządzanie inwestycjami IT,


dotyczące stałej i wymiernej poprawy efektywności kosztowej działalności IT oraz jej wkładu w zapewnienie rentowności działalności biznesowej dzięki zintegrowanym i ustandaryzowanym usługom, które spełniają oczekiwania użytkowników końcowych


podejmowaniu decyzji o efektywnych i wydajnych inwestycjach i portfelach IT oraz ustalaniu i monitorowaniu wykonania budżetów IT zgodnie ze strategią IT i decyzjami inwestycyjnymi,


• prognozowanie i przydzielanie budżetów; • definiowanie formalnych kryteriów inwestycyjnych (zwrot z inwestycji,

okres zwrotu, zaktualizowana wartość netto [NPV]); • pomiar i ocenę wartości biznesowej w odniesieniu do prognoz


• procentową obniżkę kosztu jednostkowego dostarczonych usług IT; • procentową wartość odchylenia od budżetu względem łącznego

budżetu; • Procentowa wartość nakładów na IT, które stymulują wzrost wartości

biznesowej (np. wzrost sprzedaży/dostępności usług dzięki większej dostępności połączeń).





PO5 zarządzanie inwestycjami it

Istnieje i jest utrzymywana struktura zarządzania programami inwestycji opartymi o technologie IT, która obejmuje koszty, korzyści, określanie hierarchii ważności w ramach budżetu, formalny proces planowania budżetu oraz zarządzanie budżetem. Odbywają się konsultacje z interesariuszami w celu identyfikacji i kontrolowania łącznych kosztów i korzyści w kontekście planów strategicznych i taktycznych IT oraz inicjowania w razie potrzeby działań korygujących. Proces sprzyja partnerstwu między interesariuszami po stronie IT i stronie biznesowej; umożliwia efektywne i wydajne wykorzystanie zasobów IT i zapewnia przejrzystość i rozliczalność całkowitego kosztu posiadania (TCO), realizacji korzyści biznesowych oraz zwrotu z inwestycji opartych o technologie IT.

SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI


ZARZ

ĄDZA

NIE

RYZY

KIEM




Planowanie i organizacjaZarządzanie inwestycjami IT PO5



Po5.1 Struktura zarządzania finansowego Stworzyć i utrzymywać strukturę finansową umożliwiającą zarządzanie inwestycjami i kosztami aktywów i usług IT poprzez portfele inwestycji opartych o technologie IT, uzasadnienia biznesowe i budżety IT.

Po5.2 określanie hierarchii ważności w ramach budżetu IT Wdrożyć proces podejmowania decyzji w celu określania hierarchii ważności dla alokacji zasobów IT na potrzeby operacji, projektów i utrzymywania infrastruktury, aby zmaksymalizować wkład IT w optymalizację zwrotu z portfela programów inwestycji przedsiębiorstwa opartych o technologie IT oraz z innych usług i zasobów IT.

Po5.3 Planowanie budżetu ITOkreślić i wdrożyć praktyki tworzenia budżetu odzwierciedlającego priorytety określone przez portfel programów inwestycji przedsiębiorstwa opartych o technologie IT oraz uwzględniającego stałe koszty obsługi i utrzymywania aktualnej infrastruktury. Praktyki te powinny wspierać tworzenie ogólnego budżetu IT, a także budżetów poszczególnych programów, ze szczególnym uwzględnieniem komponentów IT tych programów. Praktyki powinny umożliwiać bieżącą weryfikację, doskonalenie i zatwierdzenie ogólnego budżetu oraz budżetów poszczególnych programów.

Po5.4 Zarządzanie kosztami Wdrożyć proces zarządzania kosztami umożliwiający porównywanie rzeczywistych kosztów z budżetami. Koszty powinny podlegać monitorowaniu i raportowaniu. Wszelkie odstępstwa powinny być w odpowiednim czasie identyfikowane i oceniane pod kątem ich wpływu na realizację programów. Następnie powinny zostać podjęte odpowiednie działania naprawcze (wraz ze sponsorem biznesowym programu), a w razie potrzeby także dokonana aktualizacja uzasadnienia biznesowego programu.

Po5.5 Zarządzanie korzyściami Wdrożyć proces monitorowania korzyści wynikających z zapewnienia i utrzymywania odpowiednich zdolności IT. Wkład IT w działalność biznesową — zarówno jako składowa programów inwestycji opartych o technologie IT, jaki i regularne wsparcie operacyjne — powinien być określony i udokumentowany w uzasadnieniu biznesowym, uzgodniony, monitorowany i raportowany. Raporty powinny być przedmiotem analizy i tam, gdzie istnieją możliwości ulepszenia wkładu IT, powinny być zdefiniowane i podjęte odpowiednie działania. W przypadku, gdy zmiana wkładu IT ma wpływ na realizację programu lub gdy wpływ taki mają zmiany w innych, powiązanych programach, należy zaktualizować uzasadnienie biznesowe.

cele konTrolne

Planowanie i organizacjaZarządzanie inwestycjami ITPO5



Cele i mierniki

PO1 PlanstrategicznyiplanytaktyczneIT,portfeleprojektówiusług

PO3 WymaganiadotycząceinfrastrukturyPO10 ZaktualizowanyportfelprojektówITAI1 Studiumwykonalnościwymagań

biznesowychAI7 PrzeglądypowdrożenioweDS3 Planwydajnościipotencjału(wymagania)DS6 FinanseITME4 Oczekiwanekorzyścibiznesowezinwestycji

biznesowychopartychotechnologieIT

Sprawozdaniadotyczącekosztówikorzyści PO1 AI2 DS6 ME1 ME4BudżetyIT DS6ZaktualizowanyportfelusługIT DS1ZaktualizowanyportfelprojektówIT PO10

• Procent projektów z założonymi z góry korzyściami

• Procent usług IT, których koszty są rejestrowane

• Procent projektów poddawanych po zakończeniu przeglądowi

• Częstotliwość raportowania korzyści• Procent projektów, dla których dostępne

są informacje dotyczące ich realizacji (np. efektywność kosztowa, realizacja harmonogramu, profil ryzyka)

• Procent inwestycji IT przewyższających lub spełniających założone korzyści biznesowe

• Procent czynników stymulujących wzrost wartości IT będących jednocześnie czynnikami stymulującymi wzrost wartości biznesowej

• procentową wartość nakładów na IT, które stymulują wzrost wartości biznesowej (np. wzrost sprzedaży/dostępności usług dzięki większej dostępności połączeń).

• Liczba odstępstw od budżetu• Procentowa wartość odchylenia od

budżetu względem łącznego budżetu• Procentowa obniżka jednostkowego

kosztu dostarczonych usług IT• Procent inwestycji IT dostarczających

założone korzyści

Czynności• Definiowanie formalnych kryteriów

inwestycyjnych (zwrot z inwestycji, okres zwrotu, zaktualizowana wartość netto [NPV])

• Prognozowanie i rozdzielanie budżetów• Pomiar i ocena wartości biznesowej

w odniesieniu do prognoz

IT• Zwiększać efektywność kosztową IT

i jej wkład w zapewnienie rentowności działalności biznesowej.

• Zapewnić przejrzystość i zrozumiałość kosztów, korzyści, strategii, polityki i poziomów usług IT.

• Zapewnić, aby efektywność kosztowa szła w parze z wysoką jakością usług IT, ich ciągłym doskonaleniem i gotowością do przyszłych zmian.

Proces• Zapewnić możliwość podejmowania

decyzji dotyczących inwestycji i portfela IT.

• Ustalać i monitorować budżety IT zgodnie ze strategią IT i decyzjami dotyczącymi inwestycji IT.

• Optymalizować koszty IT i maksymalizować korzyści IT.

Utrzymywanie portfela programów. A R R R C I IUtrzymywanie portfela projektów. I C A/R A/R C C C C IUtrzymywanie portfela usług. I C A/R A/R C C C I Ustanowienie i utrzymywanie procesu planowania budżetu IT. I C C A C C C R CIdentyfikowanie, przekazywanie informacji na temat i monitorowanie inwestycji w IT, kosztówi wartości dla firmy. I C C A/R C C C R C C

Czynności


rekto

r gen

eraln

y (CE

O)Dy

rekto

r ds.

finan

sowy

ch (C

FO)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em



Planowanie i organizacjaZarządzanie inwestycjami IT PO5



stymulacja

stymulacja

usta-lenie

usta-lenie

Cele

Mie

rnik

i



Zarządzanie procesem „Zarządzanie inwestycjami IT”, który spełnia wymaganie biznesowe dla IT dotyczące stałej i wymiernej poprawy efektywności kosztowej działalności IT oraz jej wkładu w zapewnienie rentowności działalności biznesowej dzięki zintegrowanym i ustandaryzowanym usługom, które spełniają oczekiwania użytkowników końcowych, jest:

0 Nieistniejące gdyNie ma świadomości znaczenia wyboru inwestycji IT i planowania ich budżetów. Nie są śledzone ani monitorowane inwestycje i wydatki w IT.

1 Początkowe/doraźne gdyOrganizacja dostrzega potrzebę zarządzania inwestycjami IT, ale jest ona niekonsekwentnie komunikowana. Określanie odpowiedzialności za wybór inwestycji IT i planowanie budżetów odbywa się na doraźnych zasadach. Zdarzają się odosobnione przypadki nieformalnie udokumentowanego wyboru inwestycji IT i planowania budżetu. Inwestycje IT są uzasadniane na doraźnych zasadach. Podejmowane są doraźne i ukierunkowane operacyjnie decyzje budżetowe.

2 Powtarzalne lecz intuicyjne gdyIstnieje domniemane zrozumienie potrzeby wyboru inwestycji IT i planowania budżetów. Komunikowana jest potrzeba wyboru inwestycji i procesu planowania budżetów. Zachowanie zgodności jest uzależnione od inicjatywy pojedynczych osób w organizacji. Pojawiają się powszechnie stosowane techniki tworzenia elementów budżetu IT. Podejmowane są doraźne i ukierunkowane taktycznie decyzje budżetowe.

3 Zdefiniowane gdyPolityka i procesy dotyczące inwestycji i planowania budżetowego są zdefiniowane, udokumentowane i komunikowane i obejmują kluczowe zagadnienia biznesowe i techniczne. Budżet IT jest dostosowany do planów strategicznych i taktycznych IT. Proces planowania budżetowego i wyboru inwestycji IT jest sformalizowany, udokumentowany i komunikowany. Pojawia się formalne szkolenie, ale opiera się głównie na indywidualnych inicjatywach. Ma miejsce formalne zatwierdzanie wyboru inwestycji i budżetów IT. Pracownicy działu mają kompetencje i umiejętności niezbędne do planowania budżetu IT i rekomendowania odpowiednich inwestycji IT.

4 Kontrolowane i mierzalne gdyOdpowiedzialność i rozliczalność za wybór inwestycji i planowanie budżetów jest przypisana konkretnej osobie. Identyfikuje się i rozwiązuje przypadki odstępstw od budżetu. Dokonywana jest formalna analiza kosztów, która obejmuje bezpośrednie i pośrednie koszty realizowanych operacji, a także proponowane inwestycje z uwzględnieniem wszystkich kosztów w ciągu całego cyklu ich życia. Funkcjonuje ustandaryzowany proces aktywnego planowania budżetów. W planach inwestycyjnych uwzględnia się wpływ przesuwania nakładów na rozwój i kosztów operacyjnych ze sfery sprzętu i oprogramowania na rzecz integracji systemów i zasobów ludzkich IT. Korzyści i zwrot z inwestycji są oceniane w kategoriach finansowych i niefinansowych.

5 Zoptymalizowane gdyWykorzystuje się dobre praktyki branżowe w celu analizy porównawczej kosztów i znalezienia sposobów na zwiększenie efektywności inwestycji. W procesie wyboru inwestycji i planowania budżetowego dokonuje się analizy osiągnięć technologicznych. Proces zarządzania inwestycyjnego jest stale doskonalony w oparciu o wiedzę zdobytą z analizy rzeczywistej realizacji inwestycji. Decyzje inwestycyjne uwzględnią trendy poprawy relacji ceny do wydajności. W sformalizowany sposób poszukuje się i ocenia alternatywne źródła finansowania w kontekście istniejącej struktury kapitałowej organizacji, korzystając z formalnych metod oceny. Aktywnie identyfikuje się odstępstwa. Decyzje inwestycyjne uwzględniają analizę długoterminowych kosztów i korzyści w odniesieniu do całego cyklu życia inwestycji.

Model dojrzałości

Planowanie i organizacjaZarządzanie inwestycjami ITPO5


oPis Procesu


Komunikowanie celów i kierunku zarządzania,


dotyczące dostarczania dokładnych i aktualnych informacji na temat aktualnych i przyszłych usług IT oraz związanego z nimi ryzyka i odpowiedzialności


dostarczaniu interesariuszom precyzyjnych, zrozumiałych i zatwierdzonych polityk, procedur, wytycznych i innych dokumentów w ramach struktury mechanizmów kontrolnych IT,


• zdefiniowanie struktury mechanizmów kontrolnych IT; • opracowanie i wdrożenie polityk IT; • egzekwowanie polityk IT


• liczbę zakłóceń w działalności biznesowej spowodowanych zakłóceniami w świadczeniu usług IT;

• procent interesariuszy, którzy rozumieją strukturę mechanizmów kontrolnych przedsiębiorstwa;

• procent interesariuszy, którzy nie zachowują zgodności z polityką.





PO6 komunikowanie celów i kierunku zarządzania

Kierownictwo rozwija strukturę mechanizmów kontrolnych IT przedsiębiorstwa oraz definiuje i komunikuje przyjętą politykę. Wdrożony jest stały program komunikacji — zatwierdzony i wspierany przez kierownictwo — który służy informowaniu o misji, celach świadczenia usług, politykach i procedurach itp. Komunikacja wspiera osiąganie celów IT i zapewnia świadomość i zrozumienie ryzyka biznesowego i ryzyka IT oraz celów i kierunku zarządzania. Proces zapewnia zachowanie zgodności z odpowiednimi przepisami prawa i regulacjami.

SP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Planowanie i organizacjaKomunikowanie celów i kierunku zarządzania PO6



Po6.1 Polityki IT i środowisko systemu kontroli Zdefiniować elementy środowiska kontroli IT zgodnie z filozofią zarządzania i stylem działania kierownictwa przedsiębiorstwa. Elementy te powinny uwzględniać oczekiwania/wymagania dotyczące dostarczania wartości z inwestycji IT, skłonności do podejmowania ryzyka, zachowania integralności, wartości etycznych, kompetencji pracowników, rozliczalności i odpowiedzialności. Środowisko kontroli powinno opierać się na kulturze, która wspiera dostarczanie wartości przy jednoczesnym zarządzaniu znaczącym ryzykiem, zachęca do międzywydziałowej współpracy i pracy zespołowej, promuje zachowanie zgodności i ciągłe doskonalenie procesów oraz dobrze radzi sobie z odstępstwami od procesów (włączając awarie).

Po6.2 Ryzyko informatyczne przedsiębiorstwa i struktura mechanizmów kontrolnych Stworzyć i utrzymywać strukturę, która definiuje ogólne podejście przedsiębiorstwa do ryzyka i kontroli IT i jest zgodna z polityką i środowiskiem kontrolnym IT oraz strukturą ryzyka i mechanizmów kontrolnych przedsiębiorstwa.

Po6.3 Zarządzanie polityką IT Opracować i utrzymywać zestaw polityk służących wspieraniu strategii IT. Polityki te powinny wskazywać swoje intencje i uwzględniać role i obowiązki, proces obsługi wyjątków, podejście do zachowania zgodności oraz odniesienia do procedur, standardów i wytycznych. Odpowiedniość polityki powinna być regularnie potwierdzana i zatwierdzana.

Po6.4 Wdrażanie polityki, standardów i procedur Wdrożyć i egzekwować przestrzeganie polityk IT przez wszystkich objętych nią pracowników, tak aby stała się ona integralną częścią wszystkich działań przedsiębiorstwa.

Po6.5 Komunikowanie celów i kierunku działalności IT Wzmacniać świadomość i zrozumienie dla celów biznesowych oraz celów i kierunków działania IT wśród odpowiednich interesariuszy i użytkowników IT w przedsiębiorstwie.

cele konTrolne

Planowanie i organizacjaKomunikowanie celów i kierunku zarządzaniaPO6


• Zdefiniowanie struktury mechanizmów kontrolnych IT

• Opracowanie i wdrożenie polityk IT• Egzekwowanie polityk IT• Definiowanie i utrzymywania planów

komunikacji


Cele i mierniki

PO1 PlanystrategiczneitaktyczneIT,portfeleprojektówiusług

PO9 Wytycznezarządzaniaryzykiem informatycznym

ME2 SprawozdaniedotycząceefektywnościmechanizmówkontrolnychIT

StrukturamechanizmówkontrolnychIT Wszy- przedsiębiorstwa stkie Polityka IT Wszy- stkie

• Częstotliwość przeglądów/aktualizacji polityki

• Terminowość i częstotliwość komunikowania się z użytkownikami

• Częstotliwość przeglądów/aktualizacji struktury mechanizmów kontrolnych IT

• Liczba przypadków naruszenia poufności informacji

• Liczba zakłóceń w działalności biznesowej spowodowanych zakłóceniami w świadczeniu usług IT

• Poziom zrozumienia kosztów, korzyści, strategii, polityki i poziomów usług IT

• Procent interesariuszy, którzy rozumieją politykę IT

• Procent interesariuszy, którzy rozumieją strukturę mechanizmów kontrolnych przedsiębiorstwa

• Procent interesariuszy, którzy nie zachowują zgodności z polityką.

CzynnościIT Proces• Stworzyć powszechnie obowiązującą

i kompleksową strukturę mechanizmów kontrolnych IT.

• Opracować powszechnie obowiązującyi kompleksowy zestaw polityk IT• Informować o strategii, politykach

i strukturze mechanizmów kontrolnych IT.

• Zapewnić przejrzystość i zrozumiałość kosztów, korzyści, strategii, polityk i poziomów usług IT.

• Zapewnić, aby można było polegać na zautomatyzowanych transakcjach biznesowych i procesach wymiany informacji.

• Zapewnić, aby nieuprawnione osoby nie miały dostępu do kluczowych i poufnych informacji.

• Zapewnić, aby potencjalne zakłócenie lub zmiana w dostępności usług IT miała minimalny negatywny wpływ na działalność biznesową.

• Zapewnić prawidłowe wykorzystanie i wydajość aplikacji oraz stosowanych rozwiązań technicznych

• Zapewnić, aby usługi i infrastruktura IT były zdolne prawidłowo oprzeć się i powrócić do działania po awarii na skutek błędu, celowego ataku lub katastrofy.

Ustanowienie i utrzymywanie środowiska i struktury mechanizmów kontrolnych IT. I C I A/R I C C C COpracowanie i utrzymywanie polityk dotyczących IT. I I I A/R C C C R CPrzekazywanie informacji dotyczących struktury mechanizmów kontrolnych IT, celów i kierunków IT. I I I A/R R C


Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em


Planowanie i organizacjaKomunikowanie celów i kierunku zarządzania PO6



stymulacja

stymulacja

usta-lenie

usta-lenie

Cele

Mie

rnik

i



Zarządzanie procesem „Komunikowanie celów i kierunku zarządzania”, który spełnia wymaganie biznesowe dla IT dotyczące dostarczania dokładnych i aktualnych informacji na temat aktualnych i przyszłych usług IT oraz związanego z nimi ryzyka i odpowiedzialności, jest:

0 Nieistniejące gdyKierownictwo nie stworzyło pozytywnego środowiska kontrolnego IT. Nie jest dostrzegana potrzeba określenia polityk, planów, procedur ani procesów zapewniania zgodności.

1 Początkowe/doraźne gdyKierownictwo doraźnie realizuje wymagania środowiska kontroli informacji. Polityki, procedury i standardy są opracowywane i komunikowane na doraźnych zasadach i zależnie od potrzeb. Procesy rozwoju, komunikacji i zapewniania zgodności są nieformalne i niespójne.

2 Powtarzalne lecz intuicyjne gdyPotrzeby i wymagania efektywnego środowiska kontroli informacji są prawdopodobnie rozumiane przez kierownictwo, jednak praktyki mają w znacznej mierze nieformalny charakter. Potrzeba istnienia polityk, planów i procedur kontroli jest komunikowana przez kierownictwo, jednak ich opracowanie jest pozostawione uznaniu poszczególnych menedżerów i obszarów biznesowych. Jakość jest postrzegana jako pożądana filozofia działania, jednak praktyki są pozostawione uznaniu poszczególnych menedżerów. Szkolenia odbywają się w razie potrzeby i obejmują pojedyncze osoby.

3 Zdefiniowane gdyKierownictwo stworzyło, udokumentowało i komunikuje istnienie kompletnego środowiska zarządzania jakością i kontroli informacji, które obejmuje strukturę ramową polityk, planów i procedur. Proces tworzenia polityki jest zorganizowany, utrzymywany i znany pracownikom, a istniejące polityki, plany i procedury są stosunkowo dobrze opracowane i obejmują kluczowe zagadnienia. Kierownictwo rozumie znaczenie świadomości zagrożeń i zasad bezpieczeństwa IT i inicjuje programy zwiększania świadomości. Dostępne są formalne szkolenia mające na celu wspieranie środowiska kontroli informacji, ale nie są rygorystycznie realizowane. Podczas gdy istnieje ogólna struktura rozwoju polityk i procedur kontroli, zgodność z tymi politykami i procedurami nie jest konsekwentnie monitorowana. Istnieje ogólna struktura ramowa rozwoju. Ustandaryzowane i sformalizowane są techniki promowania świadomości bezpieczeństwa.

4 Kontrolowane i mierzalne gdyKierownictwo bierze odpowiedzialność za komunikowanie polityki kontroli wewnętrznej i deleguje odpowiedzialność oraz przeznacza odpowiednie zasoby, aby dostosowywać środowisko do znaczących zmian. Istnieje pozytywne, proaktywne środowisko kontroli informacji, uwzględniające dążenie do zapewnienia jakości oraz świadomość zagrożeń i zasad bezpieczeństwa IT. Opracowany, utrzymywany i komunikowany jest kompletny zbiór polityk, planów i procedur, który stanowi połączenie wewnętrznych dobrych praktyk. Została stworzona metodyka wdrażania zgodności i jej późniejszych kontroli.

5 Zoptymalizowane gdyŚrodowisko kontroli informacji jest dostosowane do struktury i wizji zarządzania strategicznego oraz podlega częstym przeglądom, aktualizacjom i ciągłemu doskonaleniu. Angażuje się wewnętrznych i zewnętrznych ekspertów, tak aby zapewnić wdrażanie dobrych praktyk branżowych zgodnie z wytycznymi kontroli i technikami komunikacji. W organizacji powszechnie stosuje się monitoring, samoocenę i kontrolę zgodności. Do utrzymywania baz wiedzy polityk i świadomości oraz do optymalizacji komunikacji wykorzystuje się technologię poprzez zastosowanie automatyzacji pracy biurowej i komputerowych narzędzi szkoleniowych.

Model dojrzałości

Planowanie i organizacjaKomunikowanie celów i kierunku zarządzaniaPO6


oPis Procesu


Zarządzanie zasobami ludzkimi w IT,

który spełnia wymaganie biznesowe dla it dotyczące zatrudniania kompetentnych i zmotywowanych pracowników w celu tworzenia i dostarczania usług IT

poprzez skupienie się na zatrudnianiu i szkoleniu pracowników, motywowaniu ich poprzez przejrzyste ścieżki kariery, przydzielaniu ról, które są adekwatne do umiejętności, ustanowieniu zdefiniowanego procesu oceny, tworzeniu opisów stanowisk i zapewnianiu świadomości zależności rezultatów od działań pojedynczych osób,


• ocenę wyników pracy pracowników; • zatrudnianie i szkolenie pracowników IT w celu wpierania realizacji planów

taktycznych IT; • łagodzenie ryzyka nadmiernej zależności od kluczowych zasobów


• poziom zadowolenia interesariuszy z kompetencji i umiejętności pracowników IT;

• poziom rotacji pracowników IT; • procent certyfikowanych pracowników IT w stosunku do potrzeb.





PO7 zarządzanie zasobami ludzkimi w it

W celu tworzenia i dostarczania usług IT na potrzeby biznesowe zatrudniani i utrzymywani są kompetentni pracownicy. Odbywa się to poprzez stosowanie zdefiniowanych i uzgodnionych praktyk wspierających rekrutację, szkolenie, ocenę wyników pracy i promowanie, a także rozwiązywanie stosunku pracy. Proces ten ma krytyczne znaczenie, ponieważ zasoby ludzie są bardzo ważne, a środowisko nadzoru i kontroli wewnętrznej jest w wysokim stopniu zależne od motywacji i kompetencji pracowników.

P P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

Podstawowy DrugorzędnyPodstawowy Drugorzędny

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM



Planowanie i organizacjaZarządzanie zasobami ludzkimi w IT PO7



Po7.1 Rekrutacja i utrzymywanie pracowników Realizować proces rekrutacji pracowników IT zgodnie z ogólną polityką i procedurami organizacji w dziedzinie zarządzania kadrami (np. zatrudnianie, pozytywne środowisko pracy, ukierunkowanie). Wdrożyć procesy zapewniające odpowiednie ulokowanie pracowników IT, którzy dysponują niezbędnymi umiejętnościami do realizacji celów organizacji.

Po7.2 Kompetencje pracowników Regularnie sprawdzać, czy pracownicy mają odpowiednie kompetencje, aby mogli wypełniać swoje obowiązki na podstawie swojego wykształcenia, szkolenia i/lub doświadczenia. Zdefiniować najważniejsze wymagania dotyczące kompetencji informatycznych i sprawdzać, czy są one utrzymywane, wykorzystując w stosownych przypadkach programy kwalifikacyjne i certyfikacyjne.

Po7.3 obsada stanowiskZdefiniować, monitorować i nadzorować stanowiska, przypisane do nich obowiązki i strukturę wynagrodzeń, włączając wymóg zachowania zgodności z politykami i procedurami zarządzania, kodeksem etyki i praktykami wykonywania zawodu. Poziom nadzoru powinien odpowiadać „wrażliwości” stanowiska oraz zakresowi przydzielonych obowiązków.

Po7.4 Szkolenie pracowników Przy zatrudnianiu zapewnić pracownikom odpowiednie ukierunkowanie, a następnie bieżące szkolenie w celu utrzymywania ich wiedzy, umiejętności, zdolności i świadomości wewnętrznych mechanizmów kontrolnych i potrzeby zapewnienia bezpieczeństwa na poziomie niezbędnym do osiągania celów organizacji.

Po7.5 Zależność od pojedynczych osób Minimalizować narażenie na krytyczną zależność od kluczowych osób poprzez gromadzenie wiedzy (dokumentacja), dzielenie się wiedzą, planowanie przejmowania stanowisk i rezerwy kadrowe.

Po7.6 Procedury weryfikacji pracowników Uwzględnić procedury weryfikacji przygotowania zawodowego w procesie rekrutacji do działu IT. Zakres i częstotliwość okresowych przeglądów tych weryfikacji powinny zależeć od wrażliwości i/lub znaczenia danego stanowiska i powinny dotyczyć pracowników etatowych, pracowników kontraktowych i dostawców.

Po7.7 ocena wyników pracy pracowników Dokonywać terminowo regularnej oceny realizacji indywidualnych celów wynikających z celów organizacji, określonych standardów i obowiązków przypisanych do danego stanowiska. W stosownych przypadkach, identyfikowanych na podstawie oceny wyników pracy i postępowania, pracownicy powinni być objęci programem coachingu.

Po7.8 Zmiana i zakończenie pracy Podejmować celowe działania związane ze zmianą pracy, a zwłaszcza z jej zakończeniem. W celu minimalizacji ryzyka i zapewnienia ciągłości stanowiska należy zorganizować transfer wiedzy, przekazanie obowiązków oraz anulowanie praw dostępu.

cele konTrolne

Planowanie i organizacjaZarządzanie zasobami ludzkimi w ITPO7



Cele i mierniki

PO4 OrganizacjairelacjewIT;udokumentowaneroleiobowiązki

AI1 Studiumwykonalnościwymagańbiznesowych

PolitykaiproceduryzarządzaniazasobamiludzkimiIT PO4MacierzumiejętnościIT PO4 PO10 Opisy stanowisk PO4Umiejętnościikompetencjepracowników,włączając DS7 indywidualneszkolenieSpecyficznewymaganiaszkoleniowe DS7Roleiobowiązki Wszy- stkie

• Procent pracowników działu IT, którzy zrealizowali plany rozwoju zawodowego

• Procent pracowników działu IT z udokumentowanymi i terminowo weryfikowanymi ocenami wyników pracy

• Procent stanowisk w dziale IT z opisami stanowisk i warunków zatrudnienia

• Średnia liczba dni poświęcanych na szkolenie i rozwój (w tym coaching) na osobę rocznie

• Wskaźnik rotacji personelu IT • Procent certyfikowanych pracowników IT

w stosunku do potrzeb• Średnia liczba dni potrzebnych

do obsadzenia wolnego stanowiska w dziale IT

• Poziom zadowolenia interesariuszy z kompetencji i umiejętności pracowników IT

• Poziom rotacji pracowników IT• Procent zadowolonych pracowników

działu IT (miernik złożony)

• Procent pracowników działu IT, którzy spełniają wymagania profilu kompetencji dla ról określonych w strategii

• Procent obsadzonych ról IT• Procent dni pracy straconych na skutek

nieplanowanych nieobecności• Procent pracowników działu IT, którzy

ukończyli roczny plan szkoleń IT• Stosunek liczby pracowników

kontraktowych do liczby pracowników etatowych względem planowanej wartości

• Procent pracowników działu IT, którzy przeszli weryfikację przygotowania zawodowego

• Procent stanowisk w dziale IT z wykwalifikowanym personelem rezerwowym

Czynności• Zatrudnianie i szkolenie pracowników

IT w celu wpierania realizacji planów taktycznych IT

• Łagodzenie ryzyka nadmiernej zależności od kluczowych zasobów

• Ocena wyników pracy pracowników

IT• Nabywać i utrzymywać umiejętności

informatyczne, które odpowiadają strategii IT.

• Zapewnić zdolność szybkiego reagowania IT.

Proces• Wypracować profesjonalne praktyki

zarządzania zasobami ludzkimi IT. • Efektywnie wykorzystywać cały

personel IT, minimalizując zależność od kluczowych pracowników.

Identyfikacja umiejętności w obszarze IT, opisów pozycji, przedziałów wynagrodzeń i C A C C C R C wzorców osobistej wydajności. Realizowanie polityk i procedur HR właściwych dla działu IT (rekrutacja, zatrudnianie, A R R R R R C weryfikacja, wynagradzanie, szkolenie, ocena, awansowanie i zwalnianie).

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor ds

. fina

nsow

ych (

CFO)

Człon

ek za

rządu

Dyrek

tor ds

. infor

matyk

i (CIO

)

Właś

ciciel

proc

esu b

iznes

oweg

o

Kierow

nik dz

iału o

perac

yjneg

oGł

ówny

arch

itekt

Kierow

nik ds

. rozw

ojuKie

rownik

ds. a

dmini

strac

ji IT

Kierow

nik bi

ura za

rządz

ania

projek

tami (P

MO)

Kontr

ola w

ewnę

trzna

; Aud

yt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em



Planowanie i organizacjaZarządzanie zasobami ludzkimi w IT PO7



stymulacja

stymulacja

usta-lenie

usta-lenie

Cele

Mie

rnik

i



Zarządzanie procesem „Zarządzanie zasobami ludzkimi w IT”, który spełnia wymaganie biznesowe dla IT dotyczące zatrudniania kompetentnych i zmotywowanych pracowników w celu tworzenia i dostarczania usług IT, jest:

0 Nieistniejące gdyNie ma świadomości znaczenia dostosowania zarządzania zasobami ludzkimi IT do procesu planowania infrastruktury technicznej organizacji. Nie ma osoby lub grupy osób formalnie odpowiedzialnych za zarządzanie zasobami ludzkimi w IT.

1 Początkowe/doraźne gdyKierownictwo dostrzega potrzebę zarządzania zasobami ludzkimi w IT. Proces zarządzania zasobami ludzkimi w IT ma nieformalny i doraźny charakter. Jest on operacyjnie ukierunkowany na zatrudnianie i zarządzanie pracownikami działu IT. Rozwija się świadomość wpływu gwałtownych zmian w środowisku biznesowym i technologicznym oraz zwiększającej się złożoności rozwiązań na potrzebę nowych umiejętności i poziomów kompetencji.

2 Powtarzalne lecz intuicyjne gdyPraktykowane jest taktyczne podejście do zatrudniania i zarządzania personelem IT, wynikające bardziej ze specyficznych potrzeb projektów niż świadomej chęci równoważenia potrzeb wewnętrznej i zewnętrznej dostępności wykwalifikowanych pracowników. Obywają się nieformalne szkolenia nowych pracowników, którzy następnie uczestniczą w szkoleniach organizowanych zależnie od potrzeb.

3 Zdefiniowane gdyIstnieje zdefiniowany i udokumentowany proces zarządzania zasobami ludzkimi w IT. Istnieje plan zarządzania zasobami ludzkimi IT. Praktykowane jest strategiczne podejście do zatrudniania i zarządzania personelem IT. Opracowano formalny plan szkoleń w celu realizacji potrzeb pracowników działu IT. Stworzono również plan rotacyjny, który ma na celu rozszerzenie umiejętności technicznych i związanych z zarządzaniem biznesowym.

4 Kontrolowane i mierzalne gdyOdpowiedzialność za tworzenie i utrzymywanie planu zarządzania zasobami ludzkimi w IT jest przypisana do konkretnej osoby lub grupy osób dysponujących odpowiednimi kompetencjami i umiejętnościami do wykonywania tych zadań. Proces tworzenia i zarządzania planem zarządzania zasobami ludzkimi w IT umożliwia szybkie reagowanie na zmiany. W organizacji istnieją ustandaryzowane mierniki umożliwiające identyfikację odstępstw od planu zarządzania zasobami ludzkimi, ze szczególnym uwzględnieniem zarządzania rozwojem i rotacją pracowników działu IT. Dokonuje się przeglądów wynagrodzeń i wydajności, których wyniki są następnie porównywane z innymi organizacjami IT i dobrymi praktykami branżowymi. Zarządzanie zasobami ludzkimi IT ma aktywny charakter i uwzględnia tworzenie ścieżek kariery.

5 Zoptymalizowane gdyPlan zarządzania zasobami ludzkimi w IT jest stale aktualizowany, aby spełniać zmieniające się wymagania biznesowe. Zarządzanie zasobami ludzkimi w IT jest zintegrowane z planowaniem infrastruktury technicznej, zapewnianiem wykorzystania i rozwoju dostępnych umiejętności informatycznych. Zarządzanie zasobami ludzkimi w IT jest dostosowane do kierunku strategicznego przedsiębiorstwa i odpowiednio reaguje na jego zmiany. Komponenty zarządzania zasobami ludzkimi w IT są zgodne z dobrymi praktykami branżowymi w takich obszarach, jak wynagrodzenia, ocena wydajności, uczestnictwo w formach branżowych, transfer wiedzy czy szkolenia i mentoring. Programy szkoleniowe dotyczące nowych produktów i standardów technologicznych są opracowywane przed ich wdrożeniem w organizacji.

Model dojrzałości

Planowanie i organizacjaZarządzanie zasobami ludzkimi w ITPO7


oPis Procesu


Zarządzanie jakością,


dotyczące zapewnienia stałej i wymiernej poprawy jakości dostarczanych usług IT


zdefiniowaniu systemu zarządzania jakością, bieżącym monitorowaniu dokonań względem założonych celów oraz wdrożeniu programu ciągłego doskonalenia usług IT,


• zdefiniowanie standardów i praktyk zarządzania jakością; • monitorowanie i ocenę wewnętrznych i zewnętrznych dokonań względem

określonych standardów i praktyk zarządzania jakością; • ciągłe doskonalenie systemu zarządzania jakością


• procent interesariuszy zadowolonych z jakości IT (średnia ważona); • procent procesów IT, które są formalnie poddawane okresowym

przeglądom jakości i które spełniają założone cele jakościowe; • procent procesów objętych przeglądem jakości.





PO8 zarządzanie jakością

Stworzony i utrzymywany jest system zarządzania jakością, który obejmuje sprawdzone procesy i standardy rozwoju i nabywania. Jest to możliwe dzięki planowaniu, wdrażaniu i utrzymywaniu systemu zarządzania jakością przy jednoczesnym zapewnieniu przejrzystych wymagań, procedur i polityk. Wymagania dotyczące jakości są wyrażane i komunikowane poprzez wymierne i możliwe do osiągnięcia wskaźniki. Ciągłe doskonalenie odbywa się poprzez bieżący monitoring, analizę i eliminowanie odstępstw, a także informowanie interesariuszy o osiąganych wynikach. Zarządzanie jakością ma kluczowe znaczenie dla zapewnienia, by działalność IT wnosiła wartość dodaną do działalności biznesowej, ciągłego doskonalenia i zapewnienia przejrzystości dla interesariuszy.

S SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Planowanie i organizacjaZarządzanie jakością PO8



Po8.1 System zarządzania jakością Wprowadzić i utrzymywać system zarządzania jakością (QMS) zapewniający standardowe, formalne i ciągłe podejście do zarządzania jakością, które jest zgodne z wymaganiami biznesowymi. System QMS powinien określać wymagania i kryteria jakościowe, kluczowe procesy IT oraz ich sekwencję i interakcje, a także polityki, kryteria i metody definiowania, wykrywania, korygowania i zapobiegania niezgodności. System QMS powinien definiować organizacyjną strukturę zarządzania jakością, określając role, zadania i zakresy odpowiedzialności. Wszystkie kluczowe obszary powinny opracować swoje własne plany jakościowe zgodne z przyjętymi kryteriami i polityką oraz rejestrować dane jakościowe. Monitorować i mierzyć efektywność i poziom akceptacji systemu zarządzania jakością i w razie potrzeby udoskonalać go.

Po8.2 Standardy IT i praktyki związane z zarządzaniem jakością Określić i utrzymywać standardy, procedury i praktyki dla kluczowych procesów IT, aby umożliwić organizacji realizację założeń systemu zarządzania jakością. W doskonaleniu i dostosowywaniu praktyk zarządzania jakością organizacji wykorzystywać jako odniesienie dobre praktyki branżowe.

Po8.3 Standardy rozwoju i nabywania Przyjąć i utrzymywać odpowiednie standardy rozwoju i nabywania, które odpowiadają cyklowi życia końcowego produktu i uwzględniają zatwierdzanie na kluczowych etapach realizacji w oparciu o uzgodnione kryteria. Uwzględnić standardy kodowania, konwencje nazewnictwa, formaty plików, standardy projektowania schematów i słowników danych, standardy interfejsów użytkownika, współdziałanie, wydajność działania systemów, skalowalność, standardy programowania i testowania, plany testów, a także testy jednostkowe, regresyjne i integracyjne.

Po8.4 Ukierunkowanie na klienta Ukierunkować zarządzanie jakością na klientów poprzez określenie ich wymagań i uzgodnienie ich ze standardami i praktykami IT. Zdefiniować role i obowiązki dotyczące rozwiązywania konfliktów między użytkownikami/klientami a organizacją IT.

Po8.5 Ciągłe doskonalenie Utrzymywać i regularnie informować o ogólnym planie zarządzania jakością, który promuje ciągłe doskonalenie.

Po8.6 Pomiar, monitorowanie i przegląd jakości Zdefiniować, zaplanować i wdrożyć pomiary umożliwiające stałe monitorowanie zgodności z systemem zarządzania jakością i wartości, jakie dostarcza ten system. Wyniki pomiarów, monitoringu i zarejestrowane informacje powinny być wykorzystywane przez właściciela procesu do podejmowania odpowiednich działań korygujących i prewencyjnych.

cele konTrolne

Planowanie i organizacjaZarządzanie jakościąPO8



Cele i mierniki

PO1 Plan strategiczny ITPO10 SzczegółoweplanyprojektówME1 Planydziałańnaprawczych

Standardynabywania AI1 AI2 AI3 AI5 DS2Standardyrozwoju PO10 AI1 AI2 AI3 AI7Wymaganiadotyczącestandardówjakości Wszy- imierników stkieDziałaniazwiązanezpodnoszeniemjakości PO4 AI6

• Procent projektów objętych przeglądem jakości

• Procent pracowników działu IT objętych szkoleniem w zakresie świadomości/zarządzania jakością

• Procent procesów i projektów IT, którym towarzyszy aktywne uczestnictwo interesariuszy w obszarze zarządzania jakością

• Procent procesów objętych przeglądem jakości

• Procent interesariuszy uczestniczących w badaniach jakości

• Procent interesariuszy zadowolonych z jakości IT (średnia ważona)

• Procent defektów wykrytych przed rozpoczęciem produkcji

• Procentowy spadek liczby groźnych incydentów na użytkownika miesięcznie

• Procent projektów IT, które zostały poddane przeglądowi jakości i uzyskały zatwierdzenie jako spełniające cele jakościowe

• Procent procesów IT, które są formalnie poddawane okresowym przeglądom jakości i które spełniają założone cele jakościowe

Czynności• Zdefiniowanie standardów i praktyk

zapewnienia jakości• Monitorowanie i ocena wewnętrznych

i zewnętrznych dokonań względem określonych standardów i praktyk zapewnienia jakości

IT• Zapewnić, aby użytkownicy końcowi byli

zadowoleni z oferty i poziomu usług.• Ograniczyć niedoskonałości

w dostarczaniu rozwiązań i usług oraz konieczność ich usuwania.

• Realizować projekty na czas i w ramach budżetu, spełniając standardy jakości.

Proces• Ustanowić standardy jakościowe i kulturę

jakości dla procesów IT.• Stworzyć wydajną i efektywną funkcję

zapewnienia jakości IT.• Monitorować efektywność procesów

i projektów IT.

Zdefiniowanie systemu zarządzania jakością. C C A/R I I I I I I CUstanowienie i utrzymywanie systemu zarządzania jakością. I I I A/R I C C C C C CStworzenie standardów jakości i przekazywanie informacji na ich temat w całej organizacji. I A/R I C C C C C CStworzenie planu jakości dotyczącego ciągłego doskonalenia i zarządzanie tym planem. A/R I C C C C C CMierzenie, monitorowanie i weryfikowanie zgodności z celami dotyczącymi jakości. A/R I C C C C C C

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em



Planowanie i organizacjaZarządzanie jakością PO8



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie jakością”, który spełnia wymaganie biznesowe dla IT dotyczące zapewnienia stałej i wymiernej poprawy jakości dostarczanych usług IT, jest:

0 Nieistniejące gdyW organizacji nie istnieje proces planowania systemu zarządzania jakością (QMS) ani nie jest stosowana metodyka cyklu życia rozwoju systemu (SDLC). Wyższa kadra zarządzająca i pracownicy działu IT nie dostrzegają potrzeby istnienia programu zarządzania jakością. Projekty i operacje nigdy nie są poddawane przeglądowi jakości.

1 Początkowe/doraźne gdyKierownictwo jest świadome potrzeby istnienia systemu zarządzania jakością. Jeśli istnieje system zarządzania jakością, jest on zależny od działań pojedynczych osób. Kierownictwo dokonuje nieformalnych ocen jakości.

2 Powtarzalne lecz intuicyjne gdyWdrożony jest program służący definiowaniu i monitorowaniu działań związanych z funkcjonowaniem systemu zarządzania jakością w IT. Działania te są ukierunkowane na inicjatywy związane z projektami i procesami IT, a nie z procesami o wymiarze ogólnoorganizacyjnym.

3 Zdefiniowane gdyZdefiniowany proces QMS jest komunikowany przez kierownictwo w całym przedsiębiorstwie i obejmuje zarządzanie jakością na poziomie IT i użytkownika końcowego. Pojawia się program szkolenia i kształcenia służący nauczaniu zarządzania jakością na wszystkich poziomach organizacji. Zdefiniowane są podstawowe oczekiwania dotyczące jakości, które są współdzielone pomiędzy projektami, a także wewnątrz organizacji IT. Pojawiają się powszechnie stosowane narzędzia i praktyki w dziedzinie zarządzania jakością. Planuje się i okazjonalnie przeprowadza badania zadowolenia z jakości.

4 Kontrolowane i mierzalne gdySystem zarządzania jakością obejmuje wszystkie procesy, włączając w to procesy zależne od stron trzecich. Dla mierników jakości tworzona jest ustandaryzowana baza wiedzy. Do uzasadniania inicjatyw związanych z systemem zarządzania jakością stosuje się metodę analizy kosztów i korzyści. Pojawiają się analizy porównawcze w odniesieniu do branży i konkurencji. Realizowany jest program szkolenia i kształcenia służący nauczaniu zarządzania jakością na wszystkich poziomach organizacji. Narzędzia i praktyki podlegają standaryzacji i okresowo przeprowadza się analizę przyczyn pierwotnych. Konsekwentnie przeprowadzane są badania zadowolenia z jakości. Istnieje ustandaryzowany i dobrze zorganizowany program pomiaru jakości. Kierownictwo działu IT tworzy bazę wiedzy dla mierników jakości.

5 Zoptymalizowane gdySystem zarządzania jakością jest zintegrowany i egzekwowany w odniesieniu do wszystkich czynności IT. Procesy zarządzania jakością są elastyczne i umożliwiają dostosowanie do zmian w środowisku IT. Baza wiedzy dla mierników jakości jest wzbogacona o dobre praktyki pochodzące z zewnątrz. Rutynowo przeprowadza się analizę porównawczą w odniesieniu do zewnętrznych standardów. Badanie zadowolenia z jakości jest ciągłym procesem, który prowadzi do analizy przyczyn podstawowych i działań doskonalących. Dostarczane jest formalne zapewnienie co do poziomu systemu zrządzania jakością.

Model dojrzałości

Planowanie i organizacjaZarządzanie jakościąPO8


oPis Procesu


Ocena i zarządzanie ryzykiem informatycznym,


dotyczące analizy i informowania o ryzyku informatycznym oraz jego potencjalnym wpływie na realizację procesów i celów biznesowych


rozwoju struktury ramowej zarządzania ryzykiem, która jest zintegrowana ze strukturami ramowymi zarządzania ryzykiem biznesowym i operacyjnym, ocenie ryzyka, łagodzeniu ryzyka oraz informowaniu o ryzyku szczątkowym,


• zapewnienie, aby zarządzanie ryzykiem było w pełni zintegrowane, wewnętrznie i zewnętrznie, z procesem zarządzania i konsekwentnie stosowane;

• dokonywanie oceny ryzyka; • rekomendowanie i informowanie o planach działania mających na celu

eliminowanie ryzyka


• procent celów IT o krytycznym znaczeniu objętych oceną ryzyka; • procent rozpoznanych czynników ryzyka IT, dla których opracowano

plan działania; • procent planów działania związanych z zarządzaniem ryzkiem, które

zostały zatwierdzone do wdrożenia.





PO9 Ocena i zarządzanie ryzykiem informatycznym

Stworzona i utrzymywana jest struktura ramowa zarządzania ryzykiem. Dokumentuje ona występujące powszechnie i uzgodnione poziomy ryzyka IT, strategie jego łagodzenia oraz ryzyko szczątkowe. Rozpoznawany, analizowany i oceniany jest potencjalny wpływ nieplanowanych zdarzeń na realizację celów organizacji. Przyjęte są strategie łagodzenia ryzyka służące minimalizacji szczątkowego ryzyka do akceptowalnego poziomu. Wnioski z oceny są zrozumiałe dla interesariuszy i wyrażone w kategoriach finansowych, aby umożliwić im dostosowanie ryzyka do akceptowalnego poziomu tolerancji.

SS S SPP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Planowanie i organizacjaOcena i zarządzanie ryzykiem informatycznym PO9



Po9.1 Struktura ramowa zarządzania ryzykiem informatycznym Stworzyć strukturę ramową zarządzania ryzykiem IT, która jest zgodna ze strukturą ramową zarządzania ryzkiem organizacji (przedsiębiorstwa).

Po9.2 Ustalanie kontekstu ryzyka Ustalić kontekst, w którym stosowana jest struktura oceny ryzyka, aby zapewnić odpowiednie rezultaty. Powinno to obejmować ustalenie wewnętrznego i zewnętrznego kontekstu każdej oceny ryzyka, celu oceny, a także kryteriów, według których oceniane jest ryzyko.

Po9.3 Identyfikacja zdarzeń Zidentyfikować zdarzenia (ważne, realistyczne zagrożenia, które wykorzystują istotną podatność), które mogą mieć potencjalny negatywny wpływ na realizację celów lub operacji przedsiębiorstwa, uwzględniając aspekty biznesowe, regulacyjne, prawne, technologiczne, operacyjne oraz związane z partnerami handlowymi i zasobami ludzkimi. Określić rodzaj wpływu i utrzymywać te informacje. Rejestrować i utrzymywać informacje o istotnym ryzyku w rejestrze ryzyka.

Po9.4 ocena ryzyka Oceniać w powtarzalny sposób prawdopodobieństwo i potencjalny wpływ rozpoznanego ryzyka, używając metod jakościowych i ilościowych. Prawdopodobieństwo i wpływ nieodłącznego i szczątkowego ryzyka powinien być oceniany indywidualnie, według kategorii i w odniesieniu do portfela.

Po9.5 odpowiedź na ryzyko Rozwinąć i utrzymywać proces odpowiedzi na ryzyko, mający na celu stałe łagodzenie wystawienia na ryzyko poprzez działanie efektywnych kosztowo mechanizmów kontrolnych. Proces odpowiedzi na ryzyko powinien określać strategie postępowania z ryzykiem (takie jak unikanie, redukcja, współdzielenie lub akceptacja) i związane z tym obowiązki, a także uwzględniać poziomy tolerancji ryzyka.

Po9.6 Utrzymywanie i monitorowanie realizacji planu działań związanych z zarządzaniem ryzykiem Określić priorytet i zaplanować czynności kontrolne na wszystkich poziomach w celu wdrożenia, w razie potrzeby, określonych odpowiedzi na ryzyko, włączając określenie kosztów, korzyści i odpowiedzialności za wykonanie. Uzyskać zatwierdzenie dla rekomendowanych działań i akceptację ewentualnego ryzyka szczątkowego oraz zapewnić, aby podejmowane działania należały do właścicieli objętych nimi procesów. Monitorować realizację planów i raportować wszelkie odstępstwa wyższej kadrze zarządzającej.

cele konTrolne

Planowanie i organizacjaOcena i zarządzanie ryzykiem informatycznymPO9



Cele i mierniki

PO1 PlanystrategiczneitaktyczneIT,portfelusługIT

PO10 PlanzarządzaniaryzykiemprojektówDS2 Ryzykowspółpracyzdostawcami DS4 Wyniki testu planu awaryjnegoDS5 Zagrożeniabezpieczeństwaipodatność

nazagrożeniaME1 HistorycznetrendyryzykaizdarzeńME4 Skłonnośćprzedsiębiorstwa

dopodejmowaniaryzykawdziedzinieIT

Ocena ryzyka PO1 DS4 DS5 DS12 ME4 Raportowanie ryzyka ME4Wytycznezarządzaniaryzykieminformatycznym PO6Planydziałańnaprawczychzwiązanychzryzykiem PO4 AI6 informatycznym

• Wartość procentowa budżetu IT przeznaczona na działania związane z zarządzaniem (oceną i łagodzeniem) ryzykiem

• Częstotliwość przeglądów procesu zarządzania ryzkiem IT

• Procent zatwierdzonych ocen ryzyka• Liczba sprawozdań z monitoringu ryzyka

sporządzonych zgodnie z uzgodnioną częstotliwością

• Procent zidentyfikowanych zdarzeń IT wykorzystanych w ocenach ryzyka

• Procent planów działania związanych z zarządzaniem ryzkiem, które zostały zatwierdzone do wdrożenia

• Procent celów IT o krytycznym znaczeniu objętych oceną ryzyka

• Procent ocen ryzyka IT zintegrowanych z podejściem do oceny ryzyka IT

• Procent rozpoznanych krytycznych zdarzeń IT, które zostały poddane ocenie

• Liczba nowo rozpoznanych czynników ryzyka IT (w porównaniu z poprzednią oceną)

• Liczba znaczących incydentów spowodowanych przez czynniki ryzyka, które nie zostały rozpoznane w ramach procesu oceny ryzyka

• Procent rozpoznanych czynników ryzyka IT, dla których opracowano plan działania

Czynności• Zapewnienie, aby zarządzanie ryzykiem

było zintegrowane z procesem zarządzania

• Dokonywanie regularnej oceny ryzyka wraz z wyższą kadra kierowniczą i kluczowymi pracownikami

• Rekomendowanie i informowanie o planach działania mających na celu eliminowanie ryzyka

IT• Zabezpieczać osiąganie celów IT. • Zapewnić przejrzystość wpływu ryzyka

biznesowego na cele i zasoby IT.• Uwzględniać i chronić wszystkie zasoby

IT.

Proces• Określić i ograniczyć

prawdopodobieństwo i wpływ ryzyka IT.• Przygotować efektywne kosztowo plany

działania dla krytycznych czynników ryzyka IT.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Określanie zgodności zarządzania ryzykiem IT i organizacji (np. co do oceny ryzyka). A R/A C C R/A I IZrozumienie odpowiednich strategicznych celów biznesowych. C C R/A C C IZrozumienie odpowiednich celów procesów biznesowych. C C R/A IIdentyfikacja wewnętrznych celów IT i ustanawianie kontekstu ryzyka. R/A C C C IIdentyfikacja zdarzeń powiązanych z celami (niektóre zdarzenia są ukierunkowane na biznes [biznes = A], a niektóre na IT[IT= A, biznes = C]). I A/C A R R R R CDokonywanie oceny ryzyka związanego ze zdarzeniami. A/C A R R R R CDokonywanie oceny i wyboru odpowiedzi na ryzyko. I I A A/C A R R R R CPriorytetyzowanie i planowanie czynności kontrolnych. C C A A R R C C C CZatwierdzanie i zapewnianie środków na realizację planów działania dotyczących ryzyka. A A R I I I I IUtrzymywanie i monitorowanie planu działania dotyczącego ryzyka. A C I R R C C C C C R



Planowanie i organizacjaOcena i zarządzanie ryzykiem informatycznym PO9



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Ocena i zarządzanie ryzykiem informatycznym”, który spełnia wymaganie biznesowe dla IT dotyczące analizy i informowania o ryzyku informatycznym oraz jego potencjalnym wpływie na realizację procesów i celów biznesowych, jest:

0 Nieistniejące gdyNie jest dokonywana ocena ryzyka dla procesów i decyzji biznesowych. Organizacja nie rozważa potencjalnego wpływu zagrożeń bezpieczeństwa i niewiadomych związanych z projektami rozwojowymi na działalność biznesową. Zarządzanie ryzykiem w kontekście nabywania rozwiązań i świadczenia usług IT nie jest brane pod uwagę.

1 Początkowe/doraźne gdyCzynniki ryzyka IT są rozpatrywane na doraźnych zasadach. Ma miejsce nieformalna ocena ryzyka dla poszczególnych projektów. Ocena ryzyka jest czasem uwzględniana w planie projektu, ale rzadko jest przydzielana określonym menedżerom. Od czasu do czasu, dla niektórych projektów, uwzględniane są specyficzne czynniki ryzyka IT związane z bezpieczeństwem, dostępnością i integralnością. Czynniki ryzyka mające wpływ na codzienną działalność są rzadko omawiane na zebraniach kierownictwa. Tam, gdzie uwzględniane jest ryzyko, jego łagodzenie jest niekonsekwentne. Pojawia się zrozumienie znaczenia ryzyka IT i potrzeby jego uwzględniania.

2 Powtarzalne lecz intuicyjne gdyPodejście do oceny ryzyka jest rozwijane i wdrażane według uznania kierowników projektów. Zarządzanie ryzykiem odbywa się zwykle na wysokim poziomie w organizacji i dotyczy najczęściej tylko znaczących projektów lub rozwiązań problemów. Tam, gdzie rozpoznano czynniki ryzyka, zaczynają być wdrażane procesy jego łagodzenia.

3 Zdefiniowane gdyOgólnoorganizacyjna polityka zarządzania ryzykiem definiuje, kiedy i w jaki sposób należy dokonywać oceny ryzyka. Zarządzanie ryzykiem odbywa się w ramach zdefiniowanego i udokumentowanego procesu. Dla wszystkich pracowników dostępne są szkolenia w dziedzinie zarządzania ryzykiem. Decyzje dotyczące realizacji procesu zarządzania ryzykiem i udziału w szkoleniach są pozostawione indywidualnemu uznaniu. Metodyka oceny ryzyka jest przekonująca i godna zaufania, dzięki czemu zapewnia rozpoznanie wszystkich najważniejszych czynników ryzyka. Proces łagodzenia kluczowych czynników ryzyka jest po ich rozpoznaniu zazwyczaj wdrażany. Opisy stanowisk uwzględniają obowiązki związane z zarządzaniem ryzkiem.

4 Kontrolowane i mierzalne gdyOcena i zarządzanie ryzykiem są standardowymi procedurami. Odstępstwa od procesu zarządzania ryzykiem są raportowane kierownictwu działu IT. Zarządzanie ryzykiem IT należy do zakresu odpowiedzialności kierownictwa wyższego szczebla. Ryzyko jest oceniane i łagodzone na poziomie poszczególnych projektów, a także regularnie w odniesieniu do całej działalności IT. Kierownictwo otrzymuje informacje dotyczące zmian w środowisku biznesowym i IT, które mogą mieć istotny wpływ na scenariusze ryzyka informatycznego. Kierownictwo jest w stanie monitorować bieżący stan ryzyka i podejmować świadome decyzje dotyczące jego akceptowalnego poziomu. Wszystkie rozpoznane czynniki ryzyka mają swoich określonych właścicieli, a wyższa kadra kierownicza i kierownictwo działu IT określa poziomy ryzyka tolerowane przez organizację. Kierownictwo działu IT określa standardowe miary oceny ryzyka i definiuje stosunek ryzyka do stopy zwrotu. Kierownictwo planuje budżet przeznaczony na zarządzanie ryzykiem, aby regularnie dokonywać oceny ryzyka. Stworzona jest baza danych zarządzania ryzykiem i część procesu zarządzania ryzykiem zaczyna być zautomatyzowana. Kierownictwo działu IT rozważa strategie łagodzenia ryzyka.

5 Zoptymalizowane gdyZarządzanie ryzykiem jest rozwinięte do poziomu dobrze zorganizowanego, ogólnoorganizacyjnego procesu, który jest egzekwowany i dobrze zarządzany. Dobre praktyki są stosowane w całej organizacji. Pozyskiwanie, analiza i raportowanie danych zarządzania ryzykiem są w dużym stopniu zautomatyzowane. Korzysta się z doświadczeń liderów w tej dziedzinie, a organizacja IT bierze udział w wymianie doświadczeń w ramach grup branżowych. Zarządzanie ryzykiem jest całkowicie zintegrowane ze wszystkimi operacjami biznesowymi i IT, dobrze postrzegane i w znacznym stopniu są w nie zaangażowani użytkownicy usług IT. Kierownictwo wykrywa odstępstwa i podejmuje działania, gdy ważne decyzje operacyjne i inwestycyjne w obszarze IT są podejmowane bez uwzględnienia planu zarządzania ryzykiem. Kierownictwo stale ocenia strategie łągodzenia ryzyka.

Model dojrzałości

Planowanie i organizacjaOcena i zarządzanie ryzykiem informatycznymPO9


oPis Procesu


Zarządzanie projektami,


dotyczące zapewnienia dostarczania rezultatów projektów w uzgodnionych ramach czasowych, budżetowych i jakościowych


zdefiniowanym programie i podejściu do zarządzania projektami IT, które umożliwia uczestniczenie w nim interesariuszy oraz monitorowanie ryzyka i postępu projektów,


• zdefiniowanie i egzekwowanie programu, wybranego podejścia i struktury projektów;

• wydanie wytycznych zarządzania projektami; • planowanie każdego z projektów wyszczególnionych w portfelu projektów


• procent projektów spełniających oczekiwania interesariuszy (na czas, w ramach budżetu i wymagań — średnia ważona);

• procent projektów objętych przeglądem powdrożeniowym; • procent projektów zgodnych ze standardami i praktykami

zarządzania projektami.





PO10 zarządzanie projektami

Wdrożony jest program i struktura ramowa zarządzania projektami dla wszystkich projektów IT. Struktura umożliwia prawidłowe określanie hierarchii ważności i koordynację wszystkich projektów. Obejmuje ona takie elementy, jak ogólny plan, przydział zasobów, definicje rezultatów, akceptację użytkowników, etapy realizacji, zapewnienie jakości, formalny plan testów, testowanie oraz przegląd powdrożeniowy, tak aby zapewnić możliwość zarządzania ryzykiem projektu i dostarczenie wartości dla firmy. Takie podejście ogranicza ryzyko nieplanowanych kosztów i anulowania projektów, usprawnia komunikację ze stroną biznesową i z użytkownikami końcowymi oraz zwiększa ich zaangażowanie, zapewnia dostarczenie wartości i odpowiednią jakość rezultatów oraz maksymalizuje ich wkład w realizację programów inwestycji opartych o technologie IT.

P P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

ZASO

BAM

I




Planowanie i organizacjaZarządzanie projektami PO10



Po10.1 Struktura zarządzania programem Utrzymywać program projektów odnoszący się do portfela programów inwestycji opartych o technologie IT poprzez identyfikację, definiowanie, ocenę, określanie hierarchii ważności, wybór, inicjowanie, zarządzanie i kontrolowanie projektów. Zapewnić, aby projekty wspierały realizację celów programów. Koordynować działania i wzajemne zależności między wieloma projektami, zarządzać wkładem, jaki wnoszą poszczególne projekty objęte programem w oczekiwane rezultaty oraz realizować wymagania i rozwiązywać konflikty dotyczące zasobów.

Po10.2 Struktura zarządzania projektami Wdrożyć i utrzymywać strukturę zarządzania projektami, która definiuje zakres i granice zarządzania projektami, a także metodę, którą należy przyjąć i stosować w przypadku każdego podejmowanego projektu. Struktura i wspierająca ją metoda powinny być zintegrowane z procesem zarządzania programami.

Po10.3 Podejście do zarządzania projektem Określić podejście do zarządzania projektem, dostosowane do wielkości, złożoności i wymagań regulacyjnych dla każdego projektu. Struktura nadzoru nad projektem powinna uwzględniać role, obowiązki i odpowiedzialność sponsora programu, sponsorów projektu, komitetu sterującego, biura projektowego i kierownika projektu, a także mechanizmy, dzięki którym mogą oni wypełnić te obowiązki (takie jak raportowanie czy przeglądy etapów projektu). Zapewnić, aby wszystkie projekty IT miały sponsorów posiadających wystarczające uprawnienia do sprawowania roli właścicielskiej przy realizacji projektu w ramach ogólnego programu strategicznego.

Po10.4 Zaangażowanie interesariuszy Zapewnić zaangażowanie i udział udział interesariuszy w definiowaniu i realizacji projektu w ramach ogólnego programu inwestycji opartych o technologie IT.

Po10.5 określenie zakresu projektu Zdefiniować i udokumentować istotę i zakres projektu, tak aby uzyskać i potwierdzić powszechne zrozumienie przez interesariuszy zakresu projektu oraz tego, w jaki sposób odnosi się on do innych projektów w ramach ogólnego programu inwestycji opartych o technologie IT. Przed uruchomieniem projektu definicja powinna zostać formalnie zatwierdzona przez sponsorów programu i projektu.

Po10.6 Uruchamianie faz projektu Zatwierdzać uruchomienie każdej znaczącej fazy projektu i informować o tym wszystkich interesariuszy. Zatwierdzenie wstępnej fazy powinno opierać się na decyzjach związanych ze sprawowaniem nadzoru nad programem. Zatwierdzanie kolejnych faz powinno być poprzedzone przeglądem i akceptacją rezultatów poprzedniej fazy projektu oraz zatwierdzeniem zaktualizowanego uzasadnienia biznesowego przy następnym znaczącym przeglądzie programu. W przypadku pokrywania się faz projektu moment zatwierdzenia startu kolejnych faz powinien być określony przez sponsorów porogramu i projektów.

Po10.7 Zintegrowany plan projektu Stworzyć formalny i zatwierdzony zintegrowany plan projektu (uwzględniający zasoby biznesowe oraz zasoby systemów informatycznych), aby ukierunkować realizację i kontrolę nad projektem przez cały cykl jego życia. Zapewnić zrozumienie i udokumentowanie czynności i wzajemnych zależności między wieloma projektami w ramach programu. Plan projektu powinien być utrzymywany przez cały cykl życia projektu. Plan projektu oraz jego zmiany powinny być zatwierdzane zgodnie ze strukturą nadzoru nad programem i projektami.

Po10.8 Zasoby na potrzeby projektu Zdefiniować obowiązki, relacje, uprawnienia i kryteria wydajności dla członków zespołu realizującego projekt oraz określić podstawy dla nabywania i wyznaczania do realizacji projektu kompetentnych pracowników i/lub pracowników kontraktowych. Należy zaplanować i zarządzać zaopatrzeniem w produkty i usługi niezbędne do realizacji celów każdego z projektów zgodnie z praktykami zaopatrzenia stosowanymi w organizacji.

Po10.9 Zarządzanie ryzykiem projektu Eliminować lub minimalizować czynniki ryzyka związane z poszczególnymi projektami poprzez systematyczny proces planowania, rozpoznawania, analizowania, reagowania, monitorowania i kontrolowania obszarów lub zdarzeń, które mogą potencjalnie spowodować niepożądaną zmianę. Należy określić i centralnie rejestrować czynniki ryzyka, które dotyczą procesu zarządzania projektem i rezultatów projektu.

Po10.10 Plan jakości projektu Przygotować plan zarządzania jakością, który opisuje system zapewnienia jakości projektu oraz sposób jego wdrożenia. Plan powinien zostać formalnie zweryfikowany i zatwierdzony przez wszystkie zainteresowane strony, a następnie włączony do zintegrowanego planu projektu.

cele konTrolne

Planowanie i organizacjaZarządzanie projektamiPO10


Po10.11 Kontrola nad zmianami projektu Stworzyć system kontroli zmian dla każdego projektu, tak aby wszystkie zmiany pierwotnych parametrów projektu (np. kosztów, harmonogramu, zakresu, jakości) były odpowiednio weryfikowane, zatwierdzane i uwzględniane w zintegrowanym planie projektu, zgodnie ze strukturą nadzoru nad programem i projektami.

Po10.12 Planowanie metod kontroli i audytu w projekcieW fazie planowania projektu określić zadania kontroli i audytu niezbędne dla wsparcia akredytacji nowych lub zmodyfikowanych systemów i uwzględnić je w zintegrowanym planie projektu. Zadania te powinny dawać gwarancję, że wewnętrzne mechanizmy kontrolne i rozwiązania z zakresu bezpieczeństwa spełniają zdefiniowane wymogi.

Po10.13 Pomiar, sprawozdawczość i monitorowanie realizacji projektu Mierzyć postęp realizacji projektu, biorąc pod uwagę takie kryteria, jak jego zakres, harmonogram, jakość, koszty i ryzyko. Zidentyfikować wszelkie odstępstwa od planu. Ocenić wpływ odstępstw na realizację projektu i ogólnego programu i poinformować o tym kluczowych interesariuszy. W razie potrzeby zarekomendować, wdrożyć i monitorować działania naprawcze zgodne ze strukturą nadzoru nad programem i projektami.

Po10.14 Zamknięcie projektu Na zakończenie każdego projektu uzyskać od interesariuszy potwierdzenie, że projekt przyniósł zaplanowane rezultaty i korzyści. Określić i poinformować o wszystkich pozostałych czynnościach niezbędnych do uzyskania zaplanowanych rezultatów projektu i korzyści z programu, a także zebrać i udokumentować wszystkie wnioski do wykorzystania w przyszłych projektach i programach.







Cele i mierniki

Źródło Elementy wejściowePO1 PortfelprojektówITPO5 ZaktualizowanyportfelprojektówITPO7 MacierzumiejętnościITPO8 StandardyrozwojuAI7 Przeglądpowdrożeniowy

Elementy wyjściowe PrzeznaczenieSprawozdaniadotyczącewydajnościprojektów ME1Planzarządzaniaryzykiemprojektów PO9WytycznezarządzaniaprojektamiSzczegółoweplanyprojektów PO8 DS6ZaktualizowanyportfelprojektówIT PO1 PO5

• Procent projektów zgodnych ze standardami i praktykami zarządzania projektami

• Procent certyfikowanych lub przeszkolonych kierowników projektów

• Procent projektów objętych przeglądem powdrożeniowym

• Procent interesariuszy uczestniczących w projektach (wskaźnik zaangażowania)

• Procent projektów spełniających oczekiwania interesariuszy (na czas, w ramach budżetu i wymagań — średnia ważona)

• Procent projektów zrealizowanych na czas i w ramach budżetu

• Procent projektów spełniających oczekiwania interesariuszy

Czynności• Zdefiniowanie i egzekwowanie struktury

ramowej i podejścia do programów i projektów

• Wydanie wytycznych zarządzania projektami

• Planowanie każdego z projektów ujętych w portfelu projektów


zgodnie ze strategią biznesową.• Realizować projekty na czas i w ramach

budżetu, spełniając standardy jakości.• Odpowiadać na wymagania nadzoru

zgodnie z oczekiwaniami zarządu.

Proces• Wdrożyć mechanizmy monitorowania

projektu i kontroli kosztów/terminów.• Zapewnić przejrzystość stanu realizacji

projektu.• Podejmować w odpowiednim czasie, na

kluczowych etapach, decyzje związane z zarządzaniem projektem.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntrola

wew

nętrz

na; A

udyt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Definiowanie struktury zarządzania programem/portfelem inwestycji w IT. C C A R C CUstanowienie i utrzymywanie struktury zarządzania projektami IT. I I I A/R I C C C C R CUstanowienie i utrzymywanie systemu monitorowania, pomiaru i zarządzania projektami IT. I I I R C C C C A/R CTworzenie kart projektów, harmonogramów, planów jakości, budżetów oraz planów komunikacji i zarządzania ryzykiem. C C C C C C C A/R CZapewnianie udziału i zaangażowania interesariuszy projektu. I A R C CZapewnianie efektywnej kontroli nad projektami i zmianami w projektach. C C C C C A/R CDefiniowanie i wdrażanie metod kontroli, audytu i weryfikacji projektów. I C I A/R C





Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja

AI1…AI7 AI1…AI7



Zarządzanie procesem „Zarządzanie projektami”, który spełnia wymaganie biznesowe dla IT dotyczące zapewnienia dostarczania rezultatów projektów w uzgodnionych ramach czasowych, budżetowych i jakościowych, jest:

0 Nieistniejące gdyOrganizacja nie wykorzystuje technik zarządzania projektami i nie bierze pod uwagę wpływu nieumiejętnego zarządzania projektami i niepowodzeń w ich rozwoju na działalność biznesową.

1 Początkowe/doraźne gdyZastosowanie technik i podejść do zarządzania projektami IT jest pozostawione uznaniu poszczególnych menedżerów IT. Kierownictwo nie angażuje się w sprawowanie nadzoru właścicielskiego i zarządzanie projektami. Kluczowe decyzje dotyczące zarządzania projektami są podejmowane bez udziału klientów i kierowników działów użytkowników. Klienci i użytkownicy nie są lub są zaangażowani w niewielkim stopniu w definiowanie projektów IT. W dziale IT nie ma przejrzystej organizacji zarządzania projektami. Nie są zdefiniowane role i obowiązki związane z zarządzaniem projektami. Projekty, harmonogramy i kluczowe etapy są słabo lub nie są w ogóle zdefiniowane. Czas pracy i wydatki związane z realizacją projektów nie są monitorowane ani porównywane z budżetem.

2 Powtarzalne lecz intuicyjne gdyWyższa kadra zarządzająca zyskuje i komunikuje świadomość potrzeby zarządzania projektami IT. Organizacja realizuje proces rozwoju i wykorzystywania pewnych technik i narzędzi w ramach poszczególnych projektów. Projekty IT mają nieformalnie zdefiniowane cele biznesowe i techniczne. Interesariusze są w ograniczonym stopniu zaangażowani w zarządzanie projektami IT. Zostały opracowane wstępne wytyczne dla wielu aspektów zarządzania projektami. Zastosowanie wytycznych zarządzania projektami jest pozostawione uznaniu danego kierownika projektu.

3 Zdefiniowane gdyWdrożony i komunikowany jest proces zarządzania projektami IT i towarzysząca mu metodyka. Projekty IT są zdefiniowane wraz z odpowiednimi celami biznesowymi i technicznymi. Wyższa kadra zarządzająca działu IT i strony biznesowej zaczyna angażować się w zarządzanie projektami IT. W ramach działu utworzone jest biuro zarządzania projektami ze wstępnie zdefiniowanymi rolami i obowiązkami. Projekty IT są monitorowane z uwzględnieniem zdefiniowanych i aktualizowanych kluczowych etapów, harmonogramu, budżetu i pomiarów postępu w realizacji. Głównie dzięki indywidualnym inicjatywom dostępne są szkolenia w dziedzinie zarządzania projektami. Zdefiniowane są procedury zapewnienia jakości i czynności powdrożeniowe, jednak nie są powszechnie stosowane przez kierownictwo IT. Projekty zaczynają być zarządzane w ramach portfeli.

4 Kontrolowane i mierzalne gdyKierownictwo wymaga formalnych i ustandaryzowanych mierników projektów oraz przeglądu wniosków z przebiegu projektów po ich zakończeniu. Zarządzanie projektami podlega pomiarowi i ocenie w całej organizacji, a nie tylko w dziale IT. Udoskonalenia procesu zarządzania projektami mają sformalizowany charakter i są przedmiotem wymiany informacji z członkami zespołów projektowych, którzy zostali przeszkoleni w tej dziedzinie. Kierownictwo działu IT wdraża strukturę organizacji projektów z udokumentowanymi rolami, obowiązkami i kryteriami wydajności pracowników. Określone są kryteria oceny realizacji projektu na każdym z kluczowych etapów. Wartość i ryzyko podlegają pomiarowi i zarządzaniu przed, w trakcie i po zakończeniu projektów. Projekty w coraz większym stopniu realizują bardziej cele organizacji niż tylko cele IT. Mają one mocne i aktywne wsparcie ze strony sponsorów z wyższej kadry zarządzającej oraz interesariuszy. Planowane są odpowiednie szkolenia w dziedzinie zarządzania projektami dla pracowników biura zarządzania projektami i całego działu IT.

5 Zoptymalizowane gdyMetodyka zarządzania, która obejmuje cały cykl życia projektów i programów, jest wdrożona, egzekwowana i zintegrowana z kulturą całej organizacji. Wdrożona jest i realizowana na bieżąco inicjatywa identyfikacji i instytucjonalizacji najlepszych praktyk zarządzania projektami. Zdefiniowana i wdrożona jest strategia IT dotycząca rozwoju zaopatrzenia i projektów operacyjnych. Biuro zintegrowanego zarządzania projektami jest odpowiedzialne za zarządzanie projektami i programami od ich rozpoczęcia do fazy powdrożeniowej. Ogólnoorganizacyjne planowanie programów i projektów zapewnia najlepsze wykorzystanie zasobów użytkowników i zasobów IT do wsparcia inicjatyw strategicznych.

Model dojrzałości


n a b y w a n i e i w d r a ż a n i e

ai1 Identyfikowanierozwiązańzautomatyzowanychai2 Nabywanieiutrzymywanieaplikacjiai3 Nabywanieiutrzymywanieinfrastrukturytechnicznejai4 Umożliwianiedziałaniaiużytkowaniaai5 NabywaniezasobówITai6 Zarządzaniezmianamiai7 Instalowanieiakredytowanierozwiązańizmian

Na

By

Wa

NIE

I WD

Ra

ża

NIE


Nabywanie i wdrażanieIdentyfikowanie rozwiązań zautomatyzowanych AI1oPis Procesu


„Identyfikowanie rozwiązań zautomatyzowanych”,


dotyczące przekładania wymagań funkcjonalnych i kontrolnych biznesu na efektywne i wydajne projektowanie zautomatyzowanych rozwiazań


identyfikacji rozwiązań, które są wykonalne pod względem technicznym i opłacalne,


• definiowanie wymagań biznesowych i technicznych; • opracowywanie studiów wykonalności zgodnie ze standardami wykonawczymi; • zatwierdzanie (lub odrzucanie) wymagań i wyników studiów wykonalności


• liczbę projektów, które nie przyniosły zakładanych korzyści z powodu nieprawidłowych założeń wykonalności;

• procent studiów wykonalności zatwierdzonych przez właścicieli procesów biznesowych;

• procent użytkowników zadowolonych z dostarczonych funkcji.





ai1 identyfikowanie rozwiązań zautomatyzowanych

Aby móc w efektywny i wydajny sposób spełnić wymagania biznesowe, potrzeby dotyczące nowej aplikacji lub funkcji wymagają dokonania analizy przed jej nabyciem lub stworzeniem. Proces ten obejmuje zdefiniowanie potrzeb, rozważenie alternatywnych źródeł, analizę wykonalności pod względem technicznym i finansowym, analizę ryzyka, kosztów i korzyści oraz podjęcie ostatecznej decyzji o samodzielnym wykonaniu lub zakupie. Wszystkie te kroki umożliwiają organizacjom ograniczenie do minimum kosztów nabycia i wdrożenia rozwiązań, zapewniając jednocześnie zachowanie możliwości osiągania celów biznesowych.

SP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Na

By

Wa

NIE

I WD

Ra

ża

NIE


Nabywanie i wdrażanieIdentyfikowanie rozwiązań zautomatyzowanychAI1


aI1.1 Zdefiniowanie i utrzymanie funkcjonalnych i technicznych wymagań biznesowych Zidentyfikować, uszeregować pod względem ważności, określić i uzgodnić funkcjonalne i techniczne wymagania biznesowe dotyczące całego zakresu inicjatyw niezbędnych do osiągnięcia oczekiwanych rezultatów programu inwestycji opartych na technologiach IT.

aI1.2 Raport dotyczący analizy ryzyka Zidentyfikować, udokumentować i dokonać analizy ryzyk związanych z wymaganiami biznesowymi i projektem rozwiązania w ramach procesu definiowania wymagań, obowiązującego w organizacji.

aI1.3 Studium wykonalności i określenie alternatywnych sposobów postępowania Sporządzić studium wykonalności zawierające analizę możliwości realizacji wymagań. Kierujący działalnością biznesową powinni przy wsparciu działu IT dokonać oceny wykonalności i alternatywnych sposobów postępowania, a następnie wydać rekomendację dla sponsora biznesowego.

aI1.4 Wymagania, decyzja dotycząca wykonalności i zatwierdzenie Sprawdzić, czy proces wymaga zatwierdzenia przez sponsora biznesowego funkcjonalnych i technicznych wymagań biznesowych oraz sprawozdań ze studiów wykonalności na określonych wstępnie kluczowych etapach. Sponsor biznesowy powinien podjąć ostateczną decyzję odnośnie wyboru rozwiązania i podejścia do jego nabycia.

cele konTrolne


Nabywanie i wdrażanieIdentyfikowanie rozwiązań zautomatyzowanych AI1


Cele i mierniki

PO1 Strategiczne i taktyczne plany ITPO3 Regularneaktualizacjedotyczące„stanu

technologicznego”,standardy technologiczne

PO8 Standardynabywaniaistandardy wykonawcze

PO10 Wytycznezarządzaniaprojektami iszczegółoweplanyprojektów

AI6 Opisprocesuzmian DS1 Umowy SLADS3 Planwydajnościipotencjału(wymagania)

Studiumwykonalnościwymagańbiznesowych PO2 PO5 PO7 AI2 AI3 AI4 AI5

• Procent projektów w rocznym planie IT będących przedmiotem studiów wykonalności

• Procent studiów wykonalności zatwierdzonych przez właścicieli procesów biznesowych

• Liczba projektów, które nie przyniosły zakładanych korzyści z powodu nieprawidłowych założeń wykonalności

• Procent użytkowników zadowolonych z dostarczonych funkcji

• Procent interesariuszy zadowolonych z trafności studium wykonalności

• Zakres, w jakim zmienia się definicja korzyści od studium wykonalności po etap wdrożenia

• Procent portfela aplikacji, który nie jest zgodny z architekturą

• Procent studiów wykonalności opracowanych na czas i w ramach budżetu

Czynności• Definiowanie wymagań biznesowych

i technicznych• Opracowywanie studiów wykonalności

zgodnie ze standardami wykonawczymi• Wczesne uwzględnianie wymagań

dotyczących bezpieczeństwa i kontroli • Zatwierdzanie (lub odrzucanie) wymagań

i wyników studiów wykonalności

IT• Określić, w jaki sposób funkcjonalne

i kontrolne wymagania biznesowe są przekładane na efektywne i wydajne rozwiązania zautomatyzowane.

• Odpowiadać na wymagania biznesowe zgodnie ze strategią biznesową.

Proces• Określić rozwiązania, które spełniają

wymagania użytkownika.• Określić rozwiązania, które są wykonalne

pod względem technicznym i opłacalne.• Podjąć decyzję „zakupić czy wykonać

samodzielnie”, która optymalizuje wartość i minimalizuje ryzyko.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)

Zdefiniowanie funkcjonalnych i technicznych wymagań biznesowych. C C R C R R A/R IUstanowienie procesów dotyczących integralności/aktualności wymagań. C C C A/R CIdentyfikacja, udokumentowanie i przeanalizowanie ryzyka procesów biznesowych. A/R R R R C R R CPrzeprowadzenie studium wykonalności/oceny skutków w zakresie wdrożenia proponowanych wymagań biznesowych. A/R R R C C C R CDokonanie oceny korzyści operacyjnych proponowanych rozwiązań IT. I R A/R R I I I RDokonanie oceny korzyści biznesowych proponowanych rozwiązań. A/R R C C C I ROpracowanie procesu zatwierdzania wymagań. C A C C C R CZaaprobowanie i zatwierdzenie proponowanych rozwiązań. C A/R R R C C C I R C


Kontr

ola w

ewnę

trzna

; Aud

yt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecze

ństw

em




Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Identyfikowanie rozwiązań zautomatyzowanych”, który spełnia wymaganie biznesowe dla IT dotyczące przekładania wymagań funkcjonalnych i kontrolnych firmy na efektywne i wydajne projektowanie zautomatyzowanych rozwiązań, jest:

0 Nieistniejące gdyOrganizacja nie wymaga określania wymagań funkcjonalnych do tworzenia, wdrażania lub modyfikacji rozwiązań w postaci systemów, usług, infrastruktury, oprogramowania i danych. W organizacji nie ma świadomości istnienia rozwiązań technicznych, które mogłyby odpowiadać prowadzonej działalności biznesowej.

1 Początkowe/doraźne gdyIstnieje świadomość potrzeby definiowania wymagań i identyfikowania rozwiązań technicznych. Grupy osób spotykają się nieformalnie w celu omówienia potrzeb i czasem dokumentuje się wymagania. Rozwiązania są identyfikowane przez pojedyncze osoby w oparciu o ograniczoną wiedzę rynkową lub ofertę dostawców. W minimalnym zakresie prowadzone są zorganizowane badania lub analizy dostępnych technologii.

2 Powtarzalne lecz intuicyjne gdyDo identyfikacji rozwiązań IT stosuje się w organizacji różne intuicyjne podejścia. Rozwiązania identyfikuje się w nieformalny sposób, w oparciu o doświadczenie i wiedzę pracowników działu IT. Sukces poszczególnych projektów zależy od doświadczenia kilku kluczowych osób. Jakość dokumentacji i sposób podejmowania decyzji są bardzo zróżnicowane. Podejście do definiowania wymagań i identyfikacji rozwiązań technicznych nie jest zorganizowane.

3 Zdefiniowane gdyIstnieją przejrzyste i zorganizowane podejścia do wyboru rozwiązań IT. Podejście do wyboru rozwiązań IT wymaga rozważenia alternatyw ocenianych pod kątem wymagań biznesowych lub wymagań użytkowników, możliwości technologicznych, analizy ekonomicznej, oceny ryzyka i innych czynników. Proces wyboru rozwiązań IT jest stosowany w przypadku niektórych projektów w oparciu o takie przesłanki, jak decyzje pojedynczych członków zespołu, ilość czasu poświęconego przez kierownictwo czy znaczenie i priorytet pierwotnego wymagania biznesowego. Stosuje się zorganizowane podejście do definiowania wymagań i identyfikacji rozwiązań technicznych.

4 Kontrolowane i mierzalne gdyIstnieje ugruntowana metodyka identyfikacji i oceny rozwiązań IT, która jest stosowana dla większości projektów. Dokumentacja projektów jest dobrej jakości, a każdy etap jest odpowiednio zatwierdzany. Wymagania są dobrze wyspecyfikowane i zgodne ze zdefiniowanymi strukturami. Rozpatrywane są alternatywne rozwiązania z uwzględnieniem analizy kosztów i korzyści. Metodyka jest przejrzysta, zdefiniowana, ogólnie zrozumiała i mierzalna. Identyfikacja i ocena rozwiązań IT jest oparta na jasno zdefiniowane zasady współpracy między kierownictwem działu IT a stroną biznesową.

5 Zoptymalizowane gdyMetodyka identyfikacji i oceny rozwiązań IT jest przedmiotem ciągłego doskonalenia. Metodyka nabywania i wdrażania jest wystarczająco elastyczna, aby móc stosować ją zarówno w przypadku dużych, jak i małych projektów. Metodyka jest wspierana przez wewnętrzne i zewnętrzne bazy wiedzy, zawierające materiały źródłowe na temat rozwiązań technicznych. Metodyka zapewnia tworzenie dokumentacji w ramach określonej struktury, która sprawia, że produkcja i utrzymanie są efektywne. Często identyfikuje się nowe możliwości wykorzystania technologii do uzyskania przewagi konkurencyjnej, modyfikacji procesu biznesowego i poprawy ogólnej efektywności. Kierownictwo wykrywa ewentualne przypadki zatwierdzenia rozwiązań IT bez uwzględnienia alternatywnych technologii lub funkcjonalnych wymagań biznesowych i podejmuje odpowiednie działania.

Model dojrzałości

Nabywanie i wdrażanieIdentyfikowanie rozwiązań zautomatyzowanychAI1


oPis Procesu


Nabywanie i utrzymywanie aplikacji,


dotyczące dostosowania dostępnych aplikacji do wymagań biznesowych, w odpowiednim czasie przy uzasadnionych kosztach,


zapewnieniu terminowego i efektywnego kosztowo procesu rozwoju programowania,


• przekładanie wymagań biznesowych na specyfikację rozwiazania; • przestrzeganie standardów programowania w przypadku wszystkich

modyfikacji; • oddzielanie procesu rozwoju programowania, testowania i czynności

operacyjnych


• liczbę problemów produkcyjnych (na aplikację) powodujących widoczny przestój;

• procent użytkowników zadowolonych z dostarczonych funkcji.





ai2 Nabywanie i utrzymywanie aplikacji

Aplikacje są udostępniane zgodnie z wymaganiami biznesowymi. Proces obejmuje projektowanie aplikacji, prawidłowe włączanie aplikacyjnych mechanizmów kontrolnych i wymagań dotyczących bezpieczeństwa oraz tworzenie konfiguracji zgodnie z obowiązującymi standardami. Pozwala to organizacjom właściwie wspierać operacje biznesowe za pomocą odpowiednich zautomatyzowanych aplikacji.

S SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Nabywanie i wdrażanieNabywanie i utrzymywanie aplikacji AI2



aI2.1 Projektowanie wysokiego poziomu Przełożyć wymagania biznesowe na ogólną specyfikację projektową, biorąc pod uwagę kierunek technologiczny i architekturę informacji organizacji. Uzyskać zatwierdzenie specyfikacji projektowych przez kierownictwo, tak aby ogólny projekt odpowiadał wymaganiom. Dokonać ponownej oceny, jeśli w fazie programowania lub utrzymywania pojawią się istotne rozbieżności techniczne lub logiczne.

aI2.2 Projektowanie szczegółowe Opracować szczegółowy projekt oraz wymagania techniczne dla oprogramowania aplikacji. Zdefiniować kryteria akceptacji wymagań. Uzyskać zatwierdzenie wymagań, aby uzyskać pewność, że odpowiadają one ogólnemu projektowi. Dokonać ponownej oceny, jeśli w fazie programowania lub utrzymywania pojawią się istotne rozbieżności techniczne lub logiczne.

aI2.3 aplikacyjne mechanizmy kontrolne i audytowalność Tam gdzie to stosowne wdrożyć biznesowe mechanizmy kontrolne do zautomatyzowanych aplikacyjnych mechanizmów kontrolnych, tak aby przetwarzanie było dokładne, kompletne, terminowe, uprawnione i audytowalne.

aI2.4 Bezpieczeństwo i dostępność aplikacji Spełnić wymagania dotyczące bezpieczeństwa i dostępności aplikacji w odniesieniu do rozpoznanych czynników ryzyka i zgodnie z klasyfikacją danych organizacji, architekturą informacji, architekturą bezpieczeństwa informacji i tolerancją na ryzyko.

aI2.5 Konfiguracja i wdrożenie nabytych aplikacji Skonfigurować i wdrożyć nabyte oprogramowanie aplikacji w celu realizacji celów biznesowych.

aI2.6 Znacząca modyfikacja istniejących systemów W przypadku znaczących zmian istniejących systemów, które skutkują istotnymi zmianami w aktualnych projektach i/lub funkcjach należy zrealizować podobny proces programowania jak w przypadku nowych systemów.

aI2.7 Programowanie aplikacji Zapewnić, aby zautomatyzowane funkcje były rozwijane zgodnie ze specyfikacją projektową, standardami programowania i dokumentacji, wymaganiami dotyczącym jakości oraz standardami dopuszczenia. Zapewnić uwzględnienie wszystkich aspektów prawnych i umownych w przypadku aplikacji tworzonych przez strony trzecie.

aI2.8 Zapewnienie jakości aplikacji Opracować, zapewnić niezbędne środki i zrealizować plan zapewnienia jakości oprogramowania, aby uzyskać jakość określoną w specyfikacji wymagań oraz wewnętrznej polityce i procedurach dotyczących jakości.

aI2.9 Zarządzanie wymaganiami wobec aplikacji Śledzić poszczególne wymagania (również te odrzucone) podczas projektowania, programowania i wdrażania aplikacji i zatwierdzać zmiany wymagań w ramach wprowadzonego procesu zarządzania zmianami.

aI2.10 Utrzymanie aplikacjiOpracować strategię i plan utrzymania aplikacji.

cele konTrolne

Nabywanie i wdrażanieNabywanie i utrzymywanie aplikacjiAI2



Cele i mierniki

Źródło Elementy wejściowePO2 Słownikdanych,schematklasyfikacji

danych,zoptymalizowanyplansystemów biznesowych

PO3 Regularneaktualizacjedotyczące„stanutechnologicznego”

PO5 SprawozdaniadotyczącekosztówikorzyściPO8 Standardynabywaniaistandardy

wykonawczePO10 Wytycznezarządzaniaprojektami,

szczegółoweplanyprojektówAI1 Studiumwykonalnościwymagań

biznesowychAI6 Opisprocesuzmian

Elementy wyjściowe PrzeznaczenieSpecyfikacjamechanizmówkontrolnych DS5 bezpieczeństwaaplikacjiWiedzaoaplikacjachipakietachoprogramowania AI4 Decyzje zaopatrzeniowe AI5WstępniezaplanowaneumowySLA DS1Specyfikacjadostępności,ciągłości DS3 DS4 iodtwarzania

• Procent projektów aplikacji z opracowanym i wykonanym planem zapewnienia jakości oprogramowania

• Procent projektów aplikacji objętych odpowiednim przeglądem i zatwierdzeniem zgodności ze standardami programowania

• Średni czas dostarczenia funkcji (w oparciu o takie mierniki, jak punkty funkcyjne czy linie kodu)

• Średni czas programowania w celu dostarczenia funkcji (w oparciu o takie mierniki, jak punkty funkcyjne czy linie kodu)

• Procent projektów zapewniających zmianę w działalności biznesowej w wymaganym czasie

• Liczba projektów, które nie przyniosły zakładanych korzyści z powodu złego projektu lub wykonania aplikacji

• Procent użytkowników zadowolonych z dostarczonych funkcji

• Procent projektów rozwojowych zrealizowanych na czas i w ramach budżetu

• Procent prac rozwojowych poświęconych na utrzymanie istniejących aplikacji

• Liczba problemów produkcyjnych (na aplikację) powodujących widoczny przestój

• Liczba usterek zgłaszanych miesięcznie (na punkt funkcyjny)

Czynności• Przekładanie wymagań biznesowych na

specyfikacje projektowe• Przestrzeganie standardów

programowania w przypadku wszystkich modyfikacji

• Określanie hierarchii ważności wymagań zależnie od znaczenia biznesowego

• Oddzielanie faz programowania, testowania i czynności operacyjnych

• Wykorzystywanie inwestycji w istniejącą technologię

IT• Określić, w jaki sposób funkcjonalne

i kontrolne wymagania biznesowe są przekładane na efektywne i wydajne rozwiązania zautomatyzowane.

• Nabywać i utrzymywać zintegrowane i ustandaryzowane systemy aplikacji.

Proces• Nabywać i utrzymywać aplikacje, które

w efektywny kosztowo sposób spełniają zdefiniowane wymagania biznesowe.

• Nabywać i utrzymywać aplikacje zgodnie ze strategią i architekturą IT.

• Zapewnić, aby proces programowania przebiegał terminowo i w efektywny kosztowo sposób.

Czynności

Tabela RACI Funkcje

CEO

CFO

Człon

ek za

rządu

CIO Właś

ciciel

proc

esu b

iznes

oweg

o

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

TPM

O

Kontr

ola w

ewnę

trzna

; Aud

yt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecze

ństw

em

Przełożenie wymagań biznesowych na specyfikacje projektowe na wysokim poziomie. C C A/R R CPrzygotowanie szczegółowych wymagań projektowych i technicznych wobec oprogramowania. I C C C A/R R COkreślenie aplikacyjnych mechanizmów kontrolnych w zakresie projektu. R C A/R R RDostosowanie i wdrożenie nabytej zautomatyzowanej funkcjonalności. C C A/R R COpracowanie sformalizowanych metod i procesów w celu zarządzania procesem rozwoju aplikacji. C C C A C R CStworzenie planu zapewniania jakości oprogramowania dla projektu. I C R A/R CŚledzenie wymagań dotyczących aplikacji i zarządzanie nimi. R A/ROpracowanie planu utrzymania aplikacji. C C A/R C



Nabywanie i wdrażanieNabywanie i utrzymywanie aplikacji AI2


Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Nabywanie i utrzymywanieaplikacji”, który spełnia wymaganie biznesowe dla IT dotyczące dostosowania dostępnych aplikacji do wymagań biznesowych, w odpowiednim czasie i przy uzasadnionych kosztach, jest:

0 Nieistniejące gdyNie istnieje proces projektowania i specyfikacji aplikacji. Zwykle aplikacje są pozyskiwane na podstawie ofert producentów, rozpoznawalności marek lub znajomości konkretnych produktów przez pracowników działu IT, bez uwzględnienia lub z uwzględnieniem w niewielkim stopniu rzeczywistych wymagań.

1 Początkowe/doraźne gdyIstnieje świadomość, że niezbędny jest proces nabywania i utrzymywania aplikacji. Podejścia do nabywania i utrzymywania aplikacji zmieniają się zależnie od projektu. Istnieje ryzyko niezależnych zakupów indywidualnych rozwiązań spełniających wybrane wymagania biznesowe, co skutkuje problemami z utrzymaniem i wsparciem tych rozwiązań.

2 Powtarzalne lecz intuicyjne gdyIstnieją różne, choć podobne, procesy nabywania i utrzymywania aplikacji, oparte na kompetencjach osób zatrudnionych w dziale IT. Współczynnik powodzenia dla aplikacji zależy w dużym stopniu umiejętności i doświadczenia pracowników działu IT. Utrzymywanie aplikacji jest zwykle problematyczne i ulega pogorszeniu w przypadku utraty przez organizację wiedzy dostępnej wewnętrznie. Przy projektowaniu lub nabywaniu oprogramowania aplikacji w niewielkim stopniu uwzględnia się wymagania bezpieczeństwa i dostępności aplikacji.

3 Zdefiniowane gdyIstnieje przejrzysty, zdefiniowany i ogólnie zrozumiały proces nabywania i utrzymywania aplikacji. Jest on zgodny ze strategią IT i strategią biznesową. Podejmowana jest próba konsekwentnego stosowania udokumentowanego procesu w przypadku różnych aplikacji i projektów. Metodyki są z reguły mało elastyczne i trudne do zastosowania we wszystkich przypadkach, prawdopodobne jest więc pomijanie pewnych kroków. Czynności utrzymania są zaplanowane, ujęte w harmonogramie i koordynowane.

4 Kontrolowane i mierzalne gdyIstnieje formalna i dobrze zrozumiała metodyka, która obejmuje proces projektowania i specyfikacji, kryteria nabycia, proces testowania oraz wymagania dotyczące dokumentacji. Istnieją udokumentowane i uzgodnione mechanizmy zatwierdzania zapewniające wykonanie wszystkich kroków i autoryzację wyjątków. Praktyki i procedury ewoluują i są dobrze dopasowane do organizacji, stosowane przez wszystkich pracowników i odpowiednie dla większości wymagań aplikacji.

5 Zoptymalizowane gdyPraktyki nabywania i utrzymywania aplikacji są zgodne ze zdefiniowanym procesem. Podejście jest oparte na komponentach, ze wstępnie zdefiniowanymi, ustandaryzowanymi aplikacjami, które są dostosowane do potrzeb biznesowych. Jest ono stosowane w całym przedsiębiorstwie. Metodyka nabywania i utrzymywania aplikacji jest zaawansowana i umożliwia szybkie wdrożenia, co pozwala szybko i elastycznie reagować na zmieniające się wymagania biznesowe. Metodyka nabywania i wdrażania aplikacji jest przedmiotem ciągłego doskonalenia i jest wspierana przez wewnętrzne i zewnętrzne bazy wiedzy zawierające materiały źródłowe i opisy dobrych praktyk. Metodyka zapewnia tworzenie dokumentacji w ramach określonej struktury, która sprawia, że produkcja i utrzymywanie są efektywne.

Model dojrzałości

Nabywanie i wdrażanieNabywanie i utrzymywanie aplikacjiAI2


oPis Procesu


Nabywanie i utrzymywanie infrastruktury technicznej,


dotyczące nabywania i utrzymywania zintegrowanej i ustandaryzowanej infrastruktury IT


zapewnieniu odpowiednich platform dla aplikacji biznesowych zgodnie ze zdefiniowaną architekturą IT i standardami technologicznymi,


• stworzenie planu nabycia technologii, który jest zgodny z planem infrastruktury technicznej;

• planowanie utrzymywania infrastruktury; • wdrożenie mechanizmów wewnętrznej kontroli, bezpieczeństwa i

weryfikowalności


• procent platform, które nie są zgodne ze zdefiniowaną architekturą IT i standardami technologicznymi;

• liczbę krytycznych procesów biznesowych wspieranych przez przestarzałą (lub będącą taką wkrótce) infrastrukturę;

• liczbę komponentów infrastruktury, które nie są już objęte wsparciem technicznym (lub nie będą w najbliższej przyszłości).





ai3 Nabywanie i utrzymywanie infrastruktury technicznej

Organizacje realizują proces nabywania, wdrażania i modernizacji infrastruktury technicznej. Wymaga to zaplanowanego podejścia do nabywania, utrzymywania i ochrony infrastruktury zgodnie z przyjętą strategią technologiczną oraz zapewnienia środowisk rozwoju i testowania. Pozwala to zapewnić bieżące wsparcie technologiczne dla aplikacji biznesowych.

SSS P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Nabywanie i wdrażanieNabywanie i utrzymywanie infrastruktury technicznej AI3



aI3.1 Plan nabycia infrastruktury technicznej Opracować plan nabycia, wdrożenia i utrzymywania infrastruktury technicznej, który spełnia ustalone funkcjonalne i techniczne wymagania biznesowe i jest zgodny z przyjętym kierunkiem technologicznym organizacji.

aI3.2 ochrona i dostępność zasobów infrastruktury Wdrożyć mechanizmy wewnętrznej kontroli, bezpieczeństwa i weryfikowalności podczas konfiguracji, integracji i utrzymywania sprzętu i oprogramowania systemowego w celu ochrony zasobów oraz zapewnienia ich dostępności i integralności. Zakres odpowiedzialności związany z wykorzystaniem wrażliwych komponentów infrastruktury powinien być jasno zdefiniowany i zrozumiany przez osoby zajmujące się rozwojem i integracją komponentów infrastruktury. Ich użycie powinno być monitorowane i podlegać ocenie.

aI3.3 Utrzymywanie infrastruktury Opracować strategię i plan utrzymywania infrastruktury i zapewnić, aby jego zmiany pozostawały pod kontrolą zgodnie z procedurami zarządzania zmianami. Uwzględnić okresowe przeglądy w odniesieniu do potrzeb biznesowych, zarządzanie łatami oprogramowania, strategie modernizacji, czynniki ryzyka, ocenę podatności oraz wymagania bezpieczeństwa.

aI3.4 środowisko testowania funkcjonalności Stworzyć środowiska rozwoju i testowania w celu wsparcia efektywnego i wydajnego testowania komponentów infrastruktury pod kątem funkcjonalności i integracji.

cele konTrolne

Nabywanie i wdrażanieNabywanie i utrzymywanie infrastruktury technicznejAI3



Cele i mierniki

PO3 Planinfrastrukturytechnicznej,standardy imożliwości,regularneaktualizacjedotyczące„stanutechnologicznego”

PO8 StandardynabywaniaistandardyrozwojuPO10 Wytycznezarządzaniaprojektamii


biznesowychAI6 OpisprocesuzmianDS3 Planwydajnościipotencjału(wymagania)

Decyzje zaopatrzeniowe AI5Skonfigurowanysystemdotestowania/instalacji AI7Wymaganiaśrodowiskafizycznego DS12Aktualizacjestandardówtechnologicznych PO3 Wymagania monitorowania systemu DS3Wiedzanatematinfrastruktury AI4Wstępniezaplanowaneumowydotyczącepoziomu DS1 technicznegousług(OLA)

• Liczba i rodzaj doraźnych zmian komponentów infrastruktury

• Liczba niezrealizowanych zleceń nabycia• Średni czas konfiguracji komponentów

infrastruktury

• Liczba krytycznych procesów biznesowych wspieranych przez przestarzałą (lub będącą taką wkrótce) infrastrukturę

• Procent platform, które nie są zgodne ze zdefiniowaną architekturą IT i standardami technologicznymi

• Liczba różnych platform technologicznych według ich funkcji w przedsiębiorstwie

• Procent komponentów infrastruktury nabytych poza ustanowionym procesem nabywania

• Liczba komponentów infrastruktury, które nie są już objęte wsparciem technicznym (lub nie będą w najbliższej przyszłości).

Czynności• Stworzenie planu nabycia technologii,

który jest zgodny z planem infrastruktury technicznej

• Planowanie utrzymywania infrastruktury• Zapewnienie infrastruktury środowiska

rozwoju i testowania• Wdrożenie mechanizmów

wewnętrznej kontroli, bezpieczeństwa i audytowalności

IT• Nabywać i utrzymywać zintegrowaną

i ustandaryzowaną infrastrukturę IT.• Zoptymalizować infrastrukturę, zasoby

i potencjał IT.• Zapewnić elastyczność IT.

Proces• Zapewnić odpowiednie platformy

dla aplikacji biznesowych zgodnie ze zdefiniowaną architekturą IT i standardami technologicznymi.

• Zapewnić niezawodną i bezpieczną infrastrukturę IT.

Czynności


rekto

r gen

eraln

y (CE

O)Dy

rekto

r ds.

finan

sowy

ch (C

FO)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntrola

wew

nętrz

na; A

udyt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Określenie procedury/procesu nabywania. C A C C C R IOmówienie z dostawcami (zatwierdzonymi) wymagań dotyczących infrastruktury. C/I A I R C C R IOkreślenie strategii i planu utrzymania infrastruktury. A R R R CSkonfigurowanie komponentów infrastruktury. A R C I



Nabywanie i wdrażanieNabywanie i utrzymywanie infrastruktury technicznej AI3



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Nabywanie i utrzymywanie infrastruktury technicznej”, który spełnia wymaganie biznesowe dla IT dotyczące nabywania i utrzymywania zintegrowanej i ustandaryzowanej infrastruktury IT, jest:

0 Nieistniejące gdyZarządzanie infrastrukturą techniczną nie jest uznawane za wystarczająco ważne, aby się nim zająć.

1 Początkowe/doraźne gdyBez żadnego ogólnego planu dokonuje się zmian w infrastrukturze dla każdej nowej aplikacji. Chociaż istnieje świadomość tego, że infrastruktura IT jest ważna, nie ma do niej spójnego, całościowego podejścia. Czynności związane z utrzymaniem realizują doraźne potrzeby. Środowisko produkcyjne jest jednocześnie środowiskiem testowym.

2 Powtarzalne lecz intuicyjne gdyIstnieje spójność taktycznych podejść do nabywania i utrzymywania infrastruktury IT. Nabywanie i utrzymywanie infrastruktury IT nie jest oparte na żadnej zdefiniowanej strategii i nie uwzględnia potrzeb aplikacji biznesowych, które powinny być wspierane przez IT. Istnieje zrozumienie, że infrastruktura IT jest ważna, co jest poparte kilkoma sformalizowanymi praktykami. Zaplanowane są wybrane czynności utrzymania, ale nie ma ich pełnego harmonogramu ani koordynacji. Dla niektórych środowisk istnieje odrębne środowisko testowe.

3 Zdefiniowane gdyIstnieje przejrzysty, zdefiniowany i ogólnie zrozumiały proces nabywania i utrzymywania infrastruktury IT. Proces wspiera realizację potrzeb krytycznych aplikacji biznesowych i jest dostosowany do strategii IT i strategii biznesowej, ale nie jest konsekwentnie stosowany. Czynności konserwacyjne są zaplanowane, ujęte w harmonogramie i koordynowane. Istnieją odrębne środowiska produkcyjne i testowe.

4 Kontrolowane i mierzalne gdyProces nabywania i utrzymywania infrastruktury technicznej został rozwinięty do poziomu, na którym dobrze sprawdza się w większości sytuacji, jest konsekwentnie stosowany i ukierunkowany na wielokrotne użycie. Infrastruktura IT odpowiednio wspiera aplikacje biznesowe. Proces jest dobrze zorganizowany i ma aktywny charakter. Koszty i czas niezbędne do uzyskania oczekiwanego poziomu skalowalności, elastyczności i integracji są częściowo zoptymalizowane.

5 Zoptymalizowane gdyProces nabywania i utrzymywania infrastruktury technicznej ma aktywny charakter i jest ściśle powiązany z krytycznymi aplikacjami biznesowymi i architekturą techniczną. Przestrzegane są dobre praktyki w odniesieniu do rozwiązań technicznych, a organizacja jest świadoma najnowszych osiągnięć w dziedzinie platform i narzędzi zarządzania. Ograniczenie kosztów uzyskuje się dzięki racjonalizacji i standaryzacji komponentów infrastruktury oraz automatyzacji. Wysoki poziom świadomości technicznej pozwala na określenie optymalnych sposobów aktywnego podnoszenia wydajności, w tym również opcji outsourcingu. Infrastruktura IT jest postrzegana jako główny czynnik umożliwiający wykorzystanie technologii informatycznych.

Model dojrzałości

Nabywanie i wdrażanieNabywanie i utrzymywanie infrastruktury technicznejAI3


oPis Procesu


Umożliwianie działania i użytkowania,


dotyczące zapewnienia zadowolenia użytkowników końcowych z oferty i poziomu usług oraz bezproblemowej integracji aplikacji i rozwiązań technicznych z procesami biznesowymi


dostarczeniu użytkownikom odpowiednich podręczników obsługi i użytkowania oraz materiałów szkoleniowych w celu przekazania wiedzy niezbędnej do prawidłowej obsługi i użytkowania systemów,


• tworzenie i udostępnianie dokumentacji przekazującej wiedzę; • wymianę informacji i szkolenie użytkowników kierujących działalnością

biznesową, personelu pomocniczego i personelu operacyjnego; • produkcję materiałów szkoleniowych


• liczbę aplikacji, w przypadku których procedury IT są dobrze zintegrowane z procesami biznesowymi;

• procent właścicieli biznesowych zadowolonych ze szkoleń dotyczących aplikacji i materiałów pomocniczych;

• liczbę aplikacji, którym towarzyszy odpowiednie szkolenie użytkowników i szkolenie w zakresie wsparcia operacyjnego.





ai4 Umożliwianie działania i użytkowania

Udostępniana jest wiedza na temat nowych systemów. Proces ten wymaga tworzenia dokumentacji i podręczników dla użytkowników i działu IT oraz szkolenia w celu zapewnienia prawidłowego użytkowania i działania aplikacji oraz infrastruktury.

S S SP P S

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Nabywanie i wdrażanieUmożliwianie działania i użytkowania AI4



aI4.1 Planowanie rozwiązań operacyjnych Opracować plan rozpoznania i dokumentacji wszystkich technicznych, operacyjnych oraz użytkowych kwestii tak, aby wszystkie osoby, które będą obsługiwać, użytkować i utrzymywać rozwiązania zautomatyzowane, mogły wykonywać swoje obowiązki.

aI4.2 Transfer wiedzy do kierownictwa firmy Przekazać wiedzę osobom kierującym działalnością biznesową, aby mogły one przejąć własność systemów i danych i sprawować obowiązki związane z dostarczaniem i zapewnianiem jakości usług, wewnętrzną kontrolą oraz administrowaniem aplikacjami.

aI4.3 Transfer wiedzy do użytkowników końcowych Przekazać wiedzę i umiejętności, aby umożliwić użytkownikom końcowym efektywne i wydajne użytkowanie systemów wspierających procesy biznesowe.

aI4.4 Transfer wiedzy do personelu operacyjnego i pomocniczego Przekazać wiedzę i umiejętności, aby umożliwić personelowi operacyjnemu i wsparcia technicznego efektywne i wydajne dostarczanie, wspieranie i utrzymywanie systemów oraz związanej z nimi infrastruktury.

cele konTrolne

Nabywanie i wdrażanieUmożliwianie działania i użytkowaniaAI4



Cele i mierniki

PO10 Wytycznezarządzaniaprojektamiiszczegółoweplanyprojektów

AI1 Studiumwykonalnościwymagańbiznesowych

AI2 Wiedzaoaplikacjachipakietachoprogramowania

AI3 WiedzanatematinfrastrukturyAI7 ZnaneiakceptowanebłędyDS7 Wymaganeaktualizacjedokumentacji

Podręczniki:użytkownika,operacyjny,dot.wsparcia, AI7 DS4 DS8 DS9 DS11 DS13 technicznyidot.administracjiWymaganiadotyczącetransferuwiedzy napotrzebywdrożeniarozwiązania DS7Materiałyszkoleniowe DS7

• Frekwencja użytkowników i operatorów na szkoleniach dotyczących poszczególnych aplikacji

• Odstęp czasu między wprowadzeniem zmian a aktualizacją materiałów szkoleniowych, procedur i dokumentacji

• Dostępność, kompletność i dokładność dokumentacji dotyczącej użytkowania i obsługi

• Liczba aplikacji, którym towarzyszy odpowiednie szkolenie użytkowników i szkolenie w zakresie wsparcia operacyjnego

• Liczba aplikacji, w przypadku których procedury IT są dobrze zintegrowane z procesami biznesowymi

• Procent właścicieli biznesowych zadowolonych ze szkoleń dotyczących aplikacji i materiałów pomocniczych

• Liczba incydentów spowodowanych brakiem wystarczającej dokumentacji i szkoleń dotyczących użytkowania i obsługi

• Liczba żądań szkolenia przyjętych przez jednostkę Service Desk

• Wskaźniki zadowolenia ze szkoleń i dokumentacji dotyczącej procedur użytkowania i obsługi

• Zmniejszenie kosztów produkcji/utrzymania dokumentacji dla użytkowników, procedur operacyjnych i materiałów szkoleniowych

Czynności• Tworzenie i udostępnianie dokumentacji

przekazującej wiedzę• Wymiana informacji i szkolenie

użytkowników, kierujących działalnością biznesową, personelu pomocniczego i personelu operacyjnego

• Produkcja materiałów szkoleniowych

IT• Zapewnić prawidłowe wykorzystanie

i wydajość aplikacji oraz stosowanych rozwiązań technicznych

• Zapewnić, aby użytkownicy końcowi byli zadowoleni z oferty i poziomu usług.

• Zapewnić bezproblemową integrację aplikacji z procesami biznesowymi.

• Ograniczyć niedoskonałości w dostarczaniu rozwiązań i usług oraz konieczność ich usuwania.

Proces• Zapewnić odpowiednie podręczniki

obsługi i użytkowania oraz materiały szkoleniowe dla aplikacji i rozwiązań technicznych.

• Przekazać wiedzę niezbędną do sprawnego działania systemów.

Czynności

Tabela RACI Funkcje

Człon

ek za

rządu

Dyrek

tor d

s. fin

anso

wych

(CFO

)Dy

rekto

r ds.

infor

matyk

i (CIO

)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

kt

Dyrek

tor g

ener

alny (

CEO)

Kier

ownik

ds. r

ozwo

juKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktam

i (PM

O)Ko

ntrola

wew

nętrz

na; A

udyt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Zesp

ół ds

. wdr

ażan

iaDz

iał sz

koleń

Opracowanie strategii w celu doprowadzenia rozwiązania do poziomu operacyjnego. A A R R I R C Opracowanie metodyki transferu wiedzy. C A C ROpracowanie podręczników procedur dla użytkownika końcowego. A/R R C COpracowanie dokumentacji technicznej dla pracowników operacyjnych i wsparcia. A/R C COpracowanie i przeprowadzenie szkoleń. A A R RDokonanie oceny wyników szkoleń i ulepszenie dokumentacji zgodnie z wymaganiami. A A R R



Nabywanie i wdrażanieUmożliwianie działania i użytkowania AI4



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Umożliwianie działania i użytkowania”, który spełnia wymaganie biznesowe dla IT dotyczące zapewnienia zadowolenia użytkowników końcowych z oferty i poziomu usług oraz bezproblemowej integracji aplikacji i rozwiązań technicznych z procesami biznesowymi, jest:

0 Nieistniejące gdyNie istnieje proces tworzenia dokumentacji dla użytkowników, podręczników operacyjnych i materiałów szkoleniowych. Jedyne materiały, które istnieją, to te dostarczone z zakupionymi produktami.

1 Początkowe/doraźne gdyIstnieje świadomość potrzeby posiadania procesu tworzenia dokumentacji. Dokumentacja jest tworzona okazjonalnie i niekonsekwentnie rozpowszechniana wśród ograniczonych grup odbiorców. Znaczna część dokumentacji i wiele procedur jest nieaktualnych. Przygotowanie materiałów szkoleniowych ma zwykle postać jednorazowych projektów o zróżnicowanej jakości. Praktycznie nie ma integracji procedur między różnymi systemami i jednostkami biznesowymi. Jednostki biznesowe nie wnoszą wkładu w projektowanie programów szkoleniowych.

2 Powtarzalne lecz intuicyjne gdyStosowane są podobne podejścia do tworzenia procedur i dokumentacji, jednak nie są one oparte na zorganizowanym podejściu lub metodyce. Nie ma jednolitego podejścia do tworzenia procedur użytkowania i obsługi. Materiały szkoleniowe są opracowywane przez pojedyncze osoby lub zespoły projektowe, a ich jakość zależy od zaangażowanych osób. Jakość procedur i wsparcia dla użytkowników waha się od złej do bardzo dobrej przy niewielkiej spójności i integracji w ramach organizacji. Realizowane lub wspierane są programy szkoleniowe dla strony biznesowej i użytkowników, ale nie ma ogólnego planu ich realizacji.

3 Zdefiniowane gdyIstnieje jasno zdefiniowana, akceptowana i zrozumiała struktura tworzenia dokumentacji, podręczników operacyjnych i materiałów szkoleniowych. Procedury są przechowywane i utrzymywane w oficjalnej bibliotece, która jest dostępna dla wszystkich zainteresowanych osób. Poprawki w dokumentacji i procedurach są wprowadzane na doraźnych zasadach. Procedury są dostępne w trybie offline i można korzystać z nich i utrzymywać je w przypadku katastrofy. Istnieje proces określający zasady aktualizacji procedur i tworzenia materiałów szkoleniowych, które mają być jasno sprecyzowanym efektem projektu zmian. Mimo istnienia zdefiniowanych podejść rzeczywista zawartość jest zróżnicowana, ponieważ nie ma kontroli nad egzekwowaniem zgodności ze standardami. Użytkownicy są nieformalnie zaangażowani w proces. Do tworzenia i rozpowszechniania procedur w coraz większym stopniu wykorzystuje się zautomatyzowane narzędzia. Szkolenia dla strony biznesowej i użytkowników są planowane i uwzględniane w harmonogramach.

4 Kontrolowane i mierzalne gdyIstnieje zdefiniowana struktura utrzymywania procedur i materiałów szkoleniowych, która jest wspierana przez kierownictwo działu IT. Przyjęte podejście do utrzymywania procedur i materiałów szkoleniowych obejmuje wszystkie systemy i jednostki biznesowe, tak aby procesy mogły być rozpatrywane z perspektywy biznesowej. Procedury i materiały szkoleniowe są zintegrowane, aby uwzględniać wzajemne zależności i interfejsy. Istnieją mechanizmy kontrolne zapewniające zgodność ze standardami, a procedury są opracowane i utrzymywane dla wszystkich procesów. W ramach procesu ciągłego doskonalenia gromadzi i analizuje się opinie strony biznesowej i użytkowników na temat dokumentacji i szkoleń. Dokumentacja i materiały szkoleniowe prezentują zwykle przewidywalny, dobry poziom wiarygodności i przystępności. Prowadzony jest rozwój procesu zautomatyzowanego zarządzania i dokumentacji procedur. Zautomatyzowane tworzenie procedur jest w coraz większym stopniu zintegrowane z rozwojem systemu aplikacji, co pomaga w zapewnieniu spójności i dostępu dla użytkowników. Szkolenia dla strony biznesowej i użytkowników są szybko dostosowywane do potrzeb firmy. Kierownictwo działu IT opracowuje mierniki dla procesu tworzenia i dostarczania dokumentacji oraz materiałów i programów szkoleniowych.

5 Zoptymalizowane gdyProces formalizacji tworzenia dokumentacji operacyjnej i użytkownika jest stale doskonalony poprzez wdrażanie nowych narzędzi lub metod. Materiały proceduralne i szkoleniowe są traktowane jako stale rozwijająca się baza wiedzy, która jest utrzymywana w postaci elektronicznej z wykorzystaniem nowoczesnych technologii zarządzania wiedzą, organizacji pracy i dystrybucji, dzięki czemu są one dostępne i łatwe w utrzymaniu. Dokumentacja i materiały szkoleniowe są aktualizowane, tak aby odzwierciedlały zmiany organizacyjne, operacyjne i dotyczące oprogramowania. Tworzenie dokumentacji i materiałów szkoleniowych oraz realizacja programów szkoleniowych są w pełni zintegrowane z działalnością biznesową i definicjami procesów biznesowych. Dlatego bardziej wspierają realizację ogólnoorganizacyjnych wymagań niż tylko procedur IT.

Model dojrzałości

Nabywanie i wdrażanieUmożliwianie działania i użytkowaniaAI4


oPis Procesu


Nabywanie zasobów IT,


dotyczące poprawy efektywności kosztowej IT i jej wkładu w zapewnienie rentowności działalności biznesowej


nabywaniu i utrzymywaniu umiejętności IT odpowiadających strategii oraz zintegrowanej i ustandaryzowanej infrastruktury IT, a także ograniczaniu ryzyka zaopatrzenia IT


• korzystanie z profesjonalnego doradztwa dotyczącego prawa i zawierania umów; • definiowanie procedur i standardów zaopatrzenia; • pozyskiwaniu zamówionego sprzętu, oprogramowania i usług zgodnie

z określonymi procedurami


• liczbę sporów dotyczących umów zaopatrzeniowych; • kwotę oszczędności na kosztach zakupu; • procent interesariuszy zadowolonych z dostawców.





ai5 Nabywanie zasobów iT

Zasoby IT — w tym zasoby ludzkie, sprzęt, oprogramowanie i usługi — muszą być jakiś sposób dostarczane. Wymaga to zdefiniowania i egzekwowania procedur zaopatrzenia, wyboru dostawców, ustalania warunków umów i samego nabywania. Zapewnia to organizacji możliwość pozyskiwania wszystkich niezbędnych zasobów IT w terminowy i efektywny kosztowo sposób.

S SP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Nabywanie i wdrażanieNabywanie zasobów IT AI5



aI5.1 Kontrola nad zaopatrzeniem Opracować i wdrożyć zbiór procedur i standardów, które są zgodne z ogólną strategią nabywania i procesem zaopatrzenia organizacji biznesowej, w celu nabywania infrastruktury IT, obiektów, sprzętu, oprogramowania i usług potrzebnych firmie.

aI5.2 Zarządzanie umowami z dostawcami Ustanowić procedurę zawierania, modyfikacji i rozwiązywania umów ze wszystkimi dostawcami. Procedura powinna obejmować co najmniej określanie zakresu odpowiedzialności i zobowiązań dotyczących zagadnień prawnych, finansowych, organizacyjnych, dokumentacji, wydajności, bezpieczeństwa, własności intelektualnej oraz rozwiązywania umów (włączając klauzule odszkodowawcze). Wszystkie umowy i zmiany w umowach powinny weryfikowane przez radców prawnych.

aI5.3 Wybór dostawców Wybierać dostawców zgodnie z uczciwą i formalną procedurą, aby zapewnić najbardziej opłacalny wybór w oparciu o określone wymagania. Wymagania powinny być zoptymalizowane z uwzględnieniem informacji od potencjalnych dostawców.

aI5.4 Nabywanie zasobów IT Chronić i egzekwować interesy organizacji we wszystkich umowach dotyczących nabycia, uwzględniając prawa i obowiązki wszystkich stron w postanowieniach umów dotyczących nabycia oprogramowania, zasobów programistycznych, infrastruktury i usług.

cele konTrolne

Nabywanie i wdrażanieNabywanie zasobów ITAI5



Cele i mierniki

Źródło ElementywejściowePO1 StrategianabywaniaITPO8 StandardynabywaniaPO10 Wytycznezarządzaniaprojektamii


biznesowych AI2-3 Decyzje zaopatrzenioweDS2 Katalogdostawców

Wymaganiadotyczącezarządzaniarelacjami DS2 zewnętrznymi Dostarczone elementy AI7Postanowieniaumów DS2

• Odstęp czasu między zleceniem zakupu a podpisaniem umowy lub zakupem

• Liczba zleceń zakupu zrealizowanych w ramach listy preferowanych dostawców

• Liczba zapytań ofertowych wymagających poprawienia na podstawie odpowiedzi dostawców

• Liczba zleceń zakupu zrealizowanych na czas

• Liczba zmian dostawców dla tego samego rodzaju nabywanych towarów lub usług

• Liczba odpowiedzi na zapytania ofertowe

• Liczba sporów dotyczących umów zaopatrzeniowych

• Kwota oszczędności na kosztach zakupu• Procent interesariuszy zadowolonych

z dostawców

• Procent wstępnych wymagań spełnionych przez wybrane rozwiązanie

• Procent zamówień zgodnych z obowiązującą polityką i procedurami zaopatrzenia

• Zmniejszenie koszów jednostkowych nabytych towarów lub usług

Czynności• Korzystanie z profesjonalnego doradztwa

prawnego i dotyczącego umów• Definiowanie procedur i standardów

zaopatrzenia• Pozyskiwanie zamówionego sprzętu,

oprogramowania i usług zgodnie z określonymi procedurami

IT• Nabywać i utrzymywać zintegrowane

i ustandaryzowane systemy aplikacji.• Nabywać i utrzymywać zintegrowaną

i ustandaryzowaną infrastrukturę IT.• Nabywać i utrzymywać umiejętności

informatyczne, które odpowiadają strategii IT.

Proces• Ograniczać ryzyko zaopatrzenia IT.• Zapewniać korzystny stosunek jakości do

ceny zaopatrzenia IT.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. roz

woju

Kier

ownik

ds. a

dmini

strac

ji IT

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntrola

wew

nętrz

na; A

udyt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Opracowanie polityk i procedur dotyczacych zaopatrzenia IT dostosowanych do polityk dotyczących zaopatrzenia na poziomie korporacyjnym. I C A I I I R C Ustanowienie/utrzymywanie listy akredytowanych dostawców. A/R Dokonanie oceny i wyboru dostawców za pośrednictwem procesu zapytania ofertowego. C C A R R R R COpracowanie umów chroniących interesy organizacji. R C A R R R CDokonywanie zaopatrzenia w zgodzie z ustanowionymi procedurami. A R R R C



Nabywanie i wdrażanieNabywanie zasobów IT AI5



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Nabywanie zasobów IT”, który spełnia wymaganie biznesowe dla IT dotyczące zwiększania efektywności kosztowej IT i jej wkładu w zapewnienie rentowności działalności biznesowej, jest:

0 Nieistniejące gdyNie ma zdefiniowanego procesu dostarczania zasobów IT. Organizacja nie dostrzega potrzeby istnienia przejrzystej polityki i procedur zaopatrzenia, aby wszystkie zasoby IT były dostarczane w terminowy i efektywny kosztowo sposób.

1 Początkowe/doraźne gdyOrganizacja dostrzega potrzebę posiadania udokumentowanej polityki i procedur, które zapewniają powiązanie procesu nabywania zasobów IT z ogólnym procesem zaopatrzenia organizacji biznesowej. Umowy dotyczące nabycia zasobów IT są sporządzane i zarządzane przez kierowników projektów i inne osoby bardziej na podstawie fachowych ocen niż formalnej polityki i procedur. Występuje tylko doraźna relacja między korporacyjnymi procesami zakupowymi i zarządzania umowami a działalnością IT. Umowy dotyczące zakupu podlegają zarządzaniu raczej w końcowej fazie projektów niż ciągły sposób.

2 Powtarzalne lecz intuicyjne gdyIstnieje organizacyjna świadomość potrzeby posiadania podstawowej polityki i procedur zakupowych IT. Polityka i procedury są częściowo zintegrowane z ogólnym procesem zaopatrzenia organizacji biznesowej. Procesy zaopatrzenia są głównie wykorzystywane w przypadku dużych i rozpoznawalnych projektów. Obowiązki i odpowiedzialność za zaopatrzenie IT i zarządzanie umowami są określane na podstawie indywidualnego doświadczenia kierowników kontraktów. Dostrzega się znaczenie zarządzania dostawcami i zarządzania relacjami, jednak odbywa się to tylko z indywidualnej inicjatywy. Procesy zarządzania kontraktami są głównie wykorzystywane w przypadku dużych lub rozpoznawalnych projektów.

3 Zdefiniowane gdyKierownictwo określa politykę i procedury zakupowe IT. Polityka i procedury są zgodne z ogólnym procesem zaopatrzenia organizacji biznesowej. Zakupy IT są w dużym stopniu zintegrowane z ogólnymi systemami zaopatrzenia firmy. Istnieją standardy IT dotyczące nabywania zasobów IT. Jeśli chodzi o zarządzanie umowami, dostawcy zasobów IT podlegają mechanizmom zarządzania projektami organizacji. Kierownictwo IT komunikuje potrzebę prawidłowego zarządzania zakupami i umowami w całym dziale IT.

4 Kontrolowane i mierzalne gdyZakupy IT są całkowicie zintegrowane z ogólnymi systemami zaopatrzenia firmy. Standardy IT dotyczące nabywania zasobów IT są wykorzystywane do wszystkich zakupów. Pomiary dotyczące zarządzania umowami i zaopatrzeniem są istotne dla biznesowych uzasadnień zakupów IT. Dostępne są sprawozdania dotyczące działalności zakupowej IT, która wspiera realizację celów biznesowych. Kierownictwo jest zwykle świadome odstępstw od polityki i procedur zakupowych IT. Rozwija się strategiczne zarządzanie relacjami. Kierownictwo IT egzekwuje stosowanie procesu zarządzania zakupami i umowami dla wszystkich procesów, analizując pomiary wydajności.

5 Zoptymalizowane gdyKierownictwo realizuje zaopatrzenie w zasoby poprzez procesy zakupowe IT. Kierownictwo egzekwuje zgodność z polityką i procedurami zakupowymi IT. Dokonywane są pomiary dotyczące zarządzania umowami i zaopatrzeniem, które są istotne dla uzasadnień biznesowych zakupów IT. Z większością dostawców i partnerów nawiązywane są z czasem dobre relacje, których jakość podlega pomiarowi i monitorowaniu. Relacjami zarządza się w sposób strategiczny. Standardy, polityka i procedury IT dotyczące nabywania zasobów IT podlegają zarządzaniu strategicznemu i odpowiadają pomiarom procesu. Kierownictwo IT komunikuje strategiczne znaczenie prawidłowego zarządzania zakupami i umowami w całym dziale IT.

Model dojrzałości

Nabywanie i wdrażanieNabywanie zasobów ITAI5


oPis Procesu


Zarządzanie zmianami,


dotyczące spełniania wymagań biznesowych zgodnie ze strategią biznesową przy jednoczesnym ograniczaniu niedoskonałości w procesie dostarczania rozwiązań i usług oraz konieczności ich usuwania


kontrolowaniu ocen skutków, zatwierdzaniu i wdrażaniu wszystkich zmian w infrastrukturze IT, aplikacji i rozwiązań technicznych, ograniczaniu do minimum błędów wynikających z niekompletnych specyfikacji zgłoszeń oraz wstrzymywaniu wdrożeń niezatwierdzonych zmian,


• definiowanie i komunikowanie procedur zmian, w tym zmian wprowadzanych w trybie awaryjnym;

• ocenianie, określanie hierarchii ważności i zatwierdzania zmian; • śledzenie stanu i raportowanie zmian


• liczbę awarii lub błędów danych spowodowanych niedokładnymi specyfikacjami lub niekompletną oceną skutków;

• ilość ponownej pracy poświęconej na modyfikacje aplikacji lub infrastruktury spowodowane nieodpowiednimi specyfikacjami zmian;

• procent zmian dokonanych w ramach formalnego procesu kontroli zmian;





ai6 zarządzanie zmianami

Wszystkie zmiany (w tym doraźna obsługa i poprawki) dotyczące infrastruktury i aplikacji w środowisku produkcyjnym podlegają w kontrolowany sposób formalnemu zarządzaniu. Zmiany (również te dotyczące procedur, procesów oraz parametrów systemów i usług) są rejestrowane, oceniane i zatwierdzane przed wdrożeniem oraz oceniane po wdrożeniu względem planowanych rezultatów. Pozwala to minimalizować ryzyko negatywnego wpływu na stabilność lub integralność środowiska produkcyjnego.

SP P P P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Nabywanie i wdrażanieZarządzanie zmianami AI6



aI6.1 Standardy i procedury zmian Ustanowić formalne procedury zarządzania zmianami, tak aby obsługiwać w ustandaryzowany sposób wszystkie zgłoszenia (włączając konserwację i poprawki) zmian aplikacji, procedur, procesów, parametrów systemów i usług, a także stanowiących ich podstawę platform.

aI6.2 ocena, określanie hierarchii ważności i zatwierdzanie skutków Oceniać wszystkie zgłoszenia zmian w zorganizowany sposób, aby określić ich wpływ na system operacyjny i jego funkcjonalność. Zapewnić, aby zmiany były sklasyfikowane, uszeregowane pod względem ważności i zatwierdzone.

aI6.3 Zmiany wprowadzane w trybie awaryjnym Wprowadzić proces definiowania, zgłaszania, testowania, dokumentowania, oceny i zatwierdzania zmian wprowadzanych w trybie awaryjnym, które nie mieszczą się w ramach istniejącego procesu zmian.

aI6.4 śledzenie i raportowanie stanu zmian Stworzyć system śledzenia i raportowania w celu dokumentowania odrzuconych zmian, informowania o stanie zatwierdzonych i realizowanych oraz wykonanych zmian. Upewnić się, że zatwierdzone zmiany są wdrażane zgodnie z planem.

aI6.5 Zakończenie i dokumentacja zmian Po każdym wdrożeniu zmian zaktualizować odpowiednio dokumentację i procedury dotyczące objętego nimi systemu, a także dokumentację i procedury dla użytkowników.

cele konTrolne

Nabywanie i wdrażanieZarządzanie zmianamiAI6



Cele i mierniki

PO1 PortfelprojektówITPO8 DziałaniazwiązanezpodnoszeniemjakościPO9 Planydziałańnaprawczychzwiązanych

z ryzykiem informatycznymPO10 Wytycznezarządzaniaprojektami

iszczegółowyplanprojektów DS3 Wymagane zmiany DS5 Wymagane zmiany w zakresie

bezpieczeństwaDS8 Zgłoszeniaserwisowe/zgłoszeniazmianDS9-10 Zgłoszeniazmian(gdzieiwjakisposób

wprowadzićpoprawkę)DS10 Dokumentacjaproblemu

Opis procesu zmian Sprawozdaniadotyczącestanuzmian ME1Zatwierdzeniezmiany AI7 DS8 DS10

• Procent zmian zarejestrowanych i śledzonych przy użyciu zautomatyzowanych narzędzi

• Procent zmian dokonanych w ramach formalnego procesu kontroli zmian

• Stosunek zatwierdzonych zgłoszeń zmian do zgłoszeń odrzuconych

• Liczba utrzymywanych różnych wersji każdej z aplikacji biznesowych lub elementów infrastruktury

• Liczba i rodzaj zmian wprowadzanych w trybie awaryjnym komponentów infrastruktury

• Liczba i rodzaj poprawek komponentów infrastruktury

• Liczba awarii lub błędów danych spowodowanych niedokładnymi specyfikacjami lub niekompletną oceną skutków

• Ilość ponownej pracy poświęconej na modyfikacje aplikacji spowodowane nieodpowiednimi specyfikacjami zmian

• Zaoszczędzony czas i nakład pracy związany z wprowadzaniem zmian

• Procent zmian, które były poprawkami wprowadzonymi w trybie awaryjnym

• Procent zmian infrastruktury zakończonych niepowodzeniem ze względu na nieodpowiednie specyfikacje zmian

• Liczba zmian, które nie były formalnie śledzone, raportowane lub zatwierdzone

• Liczna zaległych zgłoszeń zmian

Czynności• Definiowanie i komunikowanie procedur

zmian, w tym zmian i poprawek wprowadzanych w trybie awaryjnym

• Ocenianie, określanie hierarchii ważności i zatwierdzania zmian

• Tworzenie harmonogramów zmian• Śledzenie stanu i raportowanie zmian


zgodnie ze strategią biznesową.• Ograniczyć niedoskonałości



• Określić, w jaki sposób funkcjonalne i kontrolne wymagania biznesowe są przekładane na efektywne i wydajne rozwiązania zautomatyzowane.

• Zachować integralność informacji i infrastruktury przetwarzania.

Proces• Dokonywać zatwierdzonych zmian

infrastruktury IT i aplikacji.• Oceniać wpływ zmian na infrastrukturę

IT, aplikacje i rozwiązania techniczne.• Śledzić i raportować stan zmian

kluczowym interesariuszom.• Ograniczać do minimum błędy

wynikające z niekompletnych specyfikacji zgłoszeń.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntrola

wew

nętrz

na; A

udyt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Opracowanie i wdrożenie procesu stałego rejestrowania, oceny i priorytetyzacji żądań dotyczących zmian. A I R C R C C CDokonywanie oceny i priorytetyzacji zmian w oparciu o potrzeby biznesowe. I R A/R C R C R CZapewnienie następowania wszelkich awaryjnych i krytycznych zmian w zgodzie z zatwierdzonym procesem. I I A/R I R C

Zatwierdzanie zmian. I C A/R RZarządzanie istotnymi informacjami dotyczącymi zmian i ich rozpowszechnianie. A I R C R I R C



AI1…AI3

Nabywanie i wdrażanieZarządzanie zmianami AI6



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie zmianami”, który spełnia wymaganie biznesowe dla IT dotyczące spełniania wymagań biznesowych zgodnie ze strategią biznesową przy jednoczesnym ograniczaniu niedoskonałości w procesie dostarczania rozwiązań i usługi oraz konieczności ich usuwania, jest:

0 Nieistniejące gdyNie ma zdefiniowanego procesu zarządzania zmianami, a zmiany są dokonywane praktycznie bez żadnej kontroli. Nie ma świadomości, że dokonanie zmiany może mieć destrukcyjny wpływ na operacje IT i operacje biznesowe, ani świadomości korzyści, jakie daje zarządzanie zmianami.

1 Początkowe/doraźne gdyDostrzega się potrzebę zarządzania i kontrolowania zmian. Praktyki są zróżnicowane i istnieje możliwość dokonywania niezatwierdzonych zmian. Zmiany są słabo lub nie są w ogóle dokumentowane, a dokumentacja konfiguracji jest niekompletna i niewiarygodna. Prawdopodobne jest pojawienie się błędów oraz przerw w działaniu środowiska produkcyjnego spowodowanych złym zarządzaniem zmianami.

2 Powtarzalne lecz intuicyjne gdyIstnieje nieformalny proces zarządzania zamianami i większość zmian jest zgodnych z tym podejściem, jest ono jednak niezorganizowane, słabo zaawansowane i podatne na błędy. Dokładność dokumentacji konfiguracji jest niejednorodna i tylko w ograniczonym stopniu planuje się i ocenia skutki przed dokonaniem zmiany.

3 Zdefiniowane gdyIstnieje zdefiniowany, formalny proces zarządzania zmianami, obejmujący klasyfikowanie, określanie hierarchii ważności, procedury awaryjne, zatwierdzanie zmian i zarządzanie wersjami; pojawia się zagadnienie zachowania zgodności. Stosowane są rozwiązania wprowadzane w trybie awaryjnym i procesy są często pomijane. Mogą zdarzać się błędy i od czasu do czasu niezatwierdzone zmiany. Analiza wpływu zmian w obszarze IT na operacje biznesowe staje sformalizowana, aby wspierać planowane wdrożenia nowych aplikacji i technologii.

4 Kontrolowane i mierzalne gdyProces zarządzania zmianami jest dobrze rozwinięty i konsekwentnie realizowany w przypadku wszystkich zmian; liczba wyjątków jest ograniczona do minimum. Proces jest wydajny i efektywny, ale w celu zapewnienia odpowiedniej jakości opiera się w znacznym stopniu na manualnych procedurach i mechanizmach kontrolnych. Wszystkie zmiany są przedmiotem dokładnego planowania i oceny skutków, aby ograniczyć do minimum prawdopodobieństwo problemów powdrożeniowych. Istnieje proces zatwierdzania zmian. Dokumentacja zarządzania zmianami jest aktualna i prawidłowa i towarzyszy jej formalne śledzenie zmian. Dokumentacja konfiguracji jest na ogół dokładna. Planowanie i wdrażanie zmian w ramach procesu zarządzania zmianami IT staje się w coraz większym zintegrowane ze zmianami w procesach biznesowych, aby zapewnić realizację zmian szkoleniowych i organizacyjnych oraz uwzględnić zagadnienie zachowania ciągłości biznesowej. Zarządzanie zmianami IT jest w zwiększonym stopniu skoordynowane z doskonaleniem procesów biznesowych. Istnieje jednorodny proces monitorowania jakości i wydajności procesu zarządzania zmianami.

5 Zoptymalizowane gdyProces zarządzania zmianami jest regularnie weryfikowany i aktualizowany, tak aby pozostawał zgodny z dobrymi praktykami. Proces weryfikacji opiera się na wynikach monitoringu. Informacje dotyczące konfiguracji są skomputeryzowane i umożliwiają sprawowanie kontroli nad wersjami. Śledzenie zmian ma zaawansowany charakter i wykorzystuje narzędzia do wykrywania nieuprawnionego lub nielicencjonowanego oprogramowania. Zarządzanie zmianami IT jest zintegrowane z zarządzaniem zmianami biznesowymi, aby zapewnić, że technologie IT będą służyć zwiększaniu wydajności i tworzeniu nowych możliwości biznesowych dla organizacji.

Model dojrzałości

Nabywanie i wdrażanieZarządzanie zmianamiAI6


oPis Procesu


Instalowanie i akredytowanie rozwiązań i zmian,


dotyczące wdrażania nowych lub zmodyfikowanych systemów, które po zainstalowaniu działają bez znaczących problemów


testowaniu, czy aplikacje i rozwiązania infrastrukturalne są dostosowane do założonego celu i wolne od błędów, oraz planowaniu wprowadzenia do produkcji,


• stworzenie metodyki testowania; • planowanie wdrożenia; • ocenę i zatwierdzenie rezultatów testów przez kierujących działalnością

biznesową; • dokonywanie przeglądów powdrożeniowych


• czas przerw w działaniu aplikacji lub liczbę poprawek danych spowodowanych nieprawidłowym testowaniem;

• procent systemów, które zapewniają oczekiwane korzyści (na podstawie pomiarów w ramach procesu powdrożeniowego);

• procent projektów z udokumentowanym i zatwierdzonym planem testów.





ai7 instalowanie i akredytowanie rozwiązań i zmian

Stworzone nowe systemy wymagają włączenia do eksploatacji. Wymaga to prawidłowego testowania w dedykowanym środowisku przy użyciu odpowiednich danych testowych, opracowania instrukcji wdrożenia i migracji, planowania wprowadzenia i rzeczywistego przekazania do produkcji, a także przeglądu powdrożeniowego. Pozwala to uzyskać zakładane rezultaty i zapewnić, że systemy operacyjne będą spełniać uzgodnione oczekiwania.

S S SP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Nabywanie i wdrażanieInstalowanie i akredytowanie rozwiązań i zmian AI7



aI7.1 Szkolenie W ramach każdego projektu rozwoju i wdrożenia lub modyfikacji systemów informatycznych zapewnić szkolenie pracowników odpowiednich działów po stronie użytkownika oraz grupy operacyjnej z działu IT zgodnie z przyjętym planem szkolenia i wdrożenia i przy użyciu związanych z nim materiałów.

aI7.2 Plan testów W oparciu o ogólnoorganizacyjne standardy opracować plan testów, który definiuje role, obowiązki oraz kryteria wejścia i wyjścia. Zapewnić zatwierdzenie planu przez odpowiednie strony.

aI7.3 Plan wdrożenia Opracować plan wdrożenia oraz plan awaryjny/wycofania zmiany. Uzyskać ich zatwierdzenie przez odpowiednie strony.

aI7.4 środowisko testowe Zdefiniować i stworzyć bezpieczne środowisko testowe, reprezentatywne dla środowiska planowanych operacji pod względem bezpieczeństwa, wewnętrznych mechanizmów kontrolnych, praktyk operacyjnych, jakości danych, wymagań ochrony prywatności oraz obciążeń.

aI7.5 Konwersja systemów i danych Zaplanować konwersję danych i migrację infrastruktury w ramach organizacyjnych metod rozwoju (wytwarzania), uwzględniając ścieżki rewizyjne, mechanizmy wycofywania i rozwiązania awaryjne.

aI7.6 Testowanie zmian Testować niezależnie zmiany, zgodnie z przyjętym planem testów, przed migracją do środowiska operacyjnego (produkcyjnego). Zapewnić, aby plan uwzględniał kwestie bezpieczeństwa i wydajności.

aI7.7 Końcowy test zatwierdzający Zapewnić, aby właściciele procesu biznesowego i interesariusze z działu IT ocenili rezultaty procesu testowania zgodnie z planem testów. Po zakończeniu serii testów określonych w planie testów oraz niezbędnych testów regresyjnych usunąć istotne błędy wykryte w procesie testowania. Po dokonaniu oceny zatwierdzić przekazanie do produkcji.

aI7.8 Przekazanie do produkcji Po zakończeniu testów kontrolować przekazanie zmodyfikowanego systemu do środowiska operacyjnego, zachowując zgodność z planem wdrożenia. Uzyskać zatwierdzenie przez kluczowych interesariuszy, takich jak użytkownicy, właściciel systemu czy kierownictwo operacyjne. W stosownych przypadkach uruchomić system na krótki czas równolegle ze starym systemem i porównać zachowanie i rezultaty.

aI7.9 Przegląd powdrożeniowy Określić procedury zgodnie z organizacyjnymi standardami zarządzania zmianami w celu zapewnienia przeglądu powdrożeniowego przewidzianego w planie wdrożenia.

cele konTrolne

Nabywanie i wdrażanieInstalowanie i akredytowanie rozwiązań i zmianAI7



Cele i mierniki

Źródło Elementy wejściowePO3 StandardytechnologicznePO4 UdokumentowaniwłaścicielesystemówPO8 StandardyrozwojuPO10 Wytycznezarządzaniaprojektamii

szczegółowyplanprojektówAI3 Skonfigurowanysystemdotestowania/

instalacjiAI4 Podręczniki:użytkownika,operacyjny,dot.

wsparcia,technicznyidot.administracji AI5 Dostarczone elementyAI6 Zatwierdzeniezmiany

Elementy wyjściowe PrzeznaczenieWprowadzoneelementykonfiguracji DS8 DS9Znaneiakceptowanebłędy AI4Przekazaniedoprodukcji DS13Planwprowadzeniaidystrybucjioprogramowania DS13Przeglądpowdrożeniowy PO2 PO5 PO10Monitoringwewnętrznejkontroli ME2

• Stopień zaangażowania interesariuszy w proces instalacji i akredytacji

• Procent projektów z udokumentowanym i zatwierdzonym planem testów

• Liczba wniosków z przeglądu powdrożeniowego

• Procent błędów znalezionych podczas przeglądu jakości funkcji instalacji i akredytacji

• Liczba zmian bez wymaganego zatwierdzenia kierownictwa przed wdrożeniem

• Procent interesariuszy zadowolonych z integralności danych nowych systemów

• Procent systemów, które zapewniły oczekiwane korzyści (na podstawie pomiarów w ramach procesu powdrożeniowego)

• Liczba błędów znalezionych podczas wewnętrznych lub zewnętrznych audytów dotyczących procesu instalacji i akredytacji

• Modyfikacje konieczne po wdrożeniu z powodu z nieodpowiednich testów akceptacyjnych

• Zgłoszenia użytkowników do jednostki Service Desk z powodu niewystarczającego szkolenia

• Przerwy w działaniu aplikacji lub poprawki danych z powodu nieodpowiedniego testowania

Czynności• Stworzenie metodyki testów, która

zapewnia odpowiednie testy akceptacyjne przed wdrożeniem

• Śledzenie zmian we wszystkich elementach konfiguracji

• Planowanie wprowadzenia• Dokonywanie przeglądów

powdrożeniowych• Ocena i zatwierdzanie rezultatów

testów przez kierujących działalnością biznesową

IT• Zapewnić to, że można polegać na

zautomatyzowanych transakcjach biznesowych i procesach wymiany informacji.

• Ograniczyć niedoskonałości w dostarczaniu rozwiązań i usług oraz konieczność ich usuwania.

• Odpowiadać na wymagania biznesowe zgodnie ze strategią biznesową.

• Zapewnić bezproblemową integrację aplikacji z procesami biznesowymi.

• Zapewnić prawidłowe wykorzystanie i wydajość aplikacji oraz stosowanych rozwiązań technicznych

• Zapewnić to, że usługi i infrastruktura IT będą zdolne prawidłowo oprzeć się i powrócić do działania po awarii na skutek błędu, celowego ataku lub katastrofy.

Proces• Sprawdzić i potwierdzić, czy aplikacje

i rozwiązania techniczne są dostosowane do założonego celu.

• Udostępnić i odpowiednio rozdysponować zatwierdzone aplikacje i rozwiązania techniczne.

• Przygotować użytkowników biznesowych i operatorów do użytkowania aplikacji i rozwiązań technicznych.

• Zapewnić to, że nowe aplikacje biznesowe i zmiany istniejących aplikacji będą wolne od błędów.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntrola

wew

nętrz

na; A

udyt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Tworzenie i przegląd planów wdrożenia. C A I C C R C CZdefiniowanie i przegląd strategii badań (kryteria wejścia i wyjścia) oraz metodyki planu badań operacyjnych. C A C C C R C CZbudowanie i utrzymywanie repozytorium wymagań biznesowych i technicznych oraz badanie przypadków w zakresie akredytowanych systemów. A RPrzeprowadzenie konwersji systemu i testów integracyjnych w środowisku testowym. I I R C C A/R I CWdrożenie środowiska testowego i przeprowadzenie końcowych testów zatwierdzających. I I R A C A/R I CZalecenie wsparcia produkcji w oparciu o uzgodnione kryteria akredytacji. I R A R C R I C



Nabywanie i wdrażanieInstalowanie i akredytowanie rozwiązań i zmian AI7


Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Instalowanie i akredytowanie rozwiązań i zmian”, który spełnia wymaganie biznesowe dla IT dotyczące wdrażania nowych lub zmodyfikowanych systemów, które po zainstalowaniu działają bez znaczących problemów, jest:

0 Nieistniejące gdyNie istnieją sformalizowane procesy instalacji lub akredytacji i ani wyższa kadra kierownicza, ani pracownicy działu IT nie dostrzegają potrzeby weryfikacji, czy rozwiązania są dostosowane do założonego celu.

1 Początkowe/doraźne gdyIstnieje świadomość potrzeby weryfikacji i potwierdzania, że wdrażane rozwiązania służą zamierzonemu celowi. Testy są przeprowadzane dla niektórych projektów, jednak inicjatywa zależy od indywidualnej decyzji zespołów projektowych, a podejścia są zróżnicowane. Nie istnieje lub rzadko zdarza się formalna akredytacja lub zatwierdzenie.

2 Powtarzalne lecz intuicyjne gdyIstnieje pewna spójność podejść do testowania i akredytacji, jednak zwykle nie są one oparte na żadnej metodyce. O podejściu do testowania decydują zespoły programistyczne i zwykle nie obejmuje ono testowania integracyjnego. Istnieje nieformalny proces zatwierdzania.

3 Zdefiniowane gdyIstnieje formalna metodyka dotycząca instalacji, migracji, konwersji i akceptacji. Procesy instalacji i integracji są zintegrowane z cyklem życia systemów i do pewnego stopnia zautomatyzowane. Na podstawie indywidualnych decyzji szkolenie, testowanie i przejście do stanu produkcyjnego i akredytacji może odbiegać od zdefiniowanego procesu. Jakość systemów wchodzących do produkcji nie jest jednakowa i nowe systemy są często źródłem istotnych problemów powdrożeniowych.

4 Kontrolowane i mierzalne gdyProcedury są sformalizowane i rozwinięte w taki sposób, aby były dobrze zorganizowane i praktyczne, ze zdefiniowanymi środowiskami testowymi i procedurami akredytacji. W praktyce większość znaczących zmian systemów jest zgodna z tym sformalizowanym podejściem. Ocena spełniania wymagań użytkowników jest ustandaryzowana i mierzalna, a towarzyszące jej mierniki mogą być efektywnie weryfikowane i analizowane przez kierownictwo. Jakość systemów wchodzących do produkcji jest satysfakcjonująca dla kierownictwa mimo pewnej ilości problemów powdrożeniowych. Automatyzacja procesu jest doraźna i zależna od projektu. Kierownictwo może być zadowolone z aktualnego poziomu efektywności mimo braku oceny powdrożeniowej. System testowy dobrze odzwierciedla rzeczywiste środowisko. Testy obciążeniowe dla nowych i testy regresyjne dla istniejących systemów są wykonywane w przypadku większych projektów.

5 Zoptymalizowane gdyW efekcie ciągłego doskonalenia procesy instalacji i akredytacji zostały rozwinięte do poziomu dobrej praktyki. Są one w pełni zintegrowane z cyklem życia systemów i tam gdzie to stosowne zautomatyzowane, dzięki czemu ułatwiają skuteczne szkolenie, testowanie i przejście nowych systemów do fazy produkcyjnej. Dobrze rozwinięte środowiska testowe, rejestry problemów i procesy eliminowania błędów zapewniają wydajne i efektywne przejście do środowiska produkcyjnego. Akredytacja ma zwykle miejsce bez konieczności modyfikacji, a problemy powdrożeniowe zwykle ograniczają się do niewielkich poprawek. Przeglądy powdrożeniowe są ustandaryzowane, a płynące z nich wnioski są wykorzystywane do ciągłego doskonalenia jakości procesu. Konsekwentnie wykonywane są testy przeciążeniowe dla nowych i testy regresyjne dla zmodyfikowanych systemów.

Model dojrzałości

Nabywanie i wdrażanieInstalowanie i akredytowanie rozwiązań i zmianAI7

d o s T a r c z a n i e i w s P a r c i e

Ds1 DefiniowanieizarządzaniepoziomamiusługDs2 ZarządzanieusługamizewnętrznymiDs3 ZarządzaniewydajnościąipojemnościąDs4 ZapewnianieciągłościusługDs5 ZapewnieniebezpieczeństwasystemówDs6 IdentyfikowanieirozliczaniekosztówDs7 KształcenieiszkoleniaużytkownikówDs8 ZarządzaniejednostkąServiceDeskiincydentamiDs9 ZarządzaniekonfiguracjąDs10 ZarządzanieproblemamiDs11 ZarządzaniedanymiDs12 ZarządzanieśrodowiskiemfizycznymDs13 Zarządzanieoperacjami

Do

STa

RC

Za

NIE

i w

spar

cie


Dostarczanie i wsparcieDefiniowanie i zarządzanie poziomami usług DS1oPis Procesu


„Definiowanie i zarządzanie poziomami usług”,


dotyczące zapewnienia zgodności kluczowych usług IT ze strategią biznesową


identyfikacji wymagań dotyczących usług, uzgodnieniu poziomów usług i monitorowaniu osiągnięć w zakresie poziomu usług,


• formalizację wewnętrznych i zewnętrznych umów zgodnie z wymaganiami i zdolnością realizacji;

• raportowanie osiągnięć w zakresie poziomu usług (sprawozdania i spotkania); • identyfikację i informowanie o nowych i uaktualnionych wymaganiach

dotyczących usług na potrzeby planowania strategicznego


• procent interesariuszy biznesowych zadowolonych z tego, że usługi są świadczone na uzgodnionym poziomie;

• liczbę dostarczonych usług nie ujętych w katalogu; • liczbę formalnych spotkań z klientami biznesowymi (rocznie)

poświęconych przeglądowi umów SLA.





Ds1 Definiowanie i zarządzanie poziomami usług

Efektywna wymiana informacji między kierownictwem IT a klientami biznesowymi na temat niezbędnych usług jest możliwa dzięki udokumentowanej definicji usług IT i uzgodnieniu ich poziomów. Proces obejmuje również monitorowanie i terminowe raportowanie interesariuszom realizacji poziomów usług. Proces ten umożliwia dostosowanie usług IT do odpowiadających im wymagań biznesowych.

SSSSSP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Do

STa

RC

Za

NIE

i w

spar

cie



DS1.1 Struktura ramowa zarządzania poziomami usług Zdefiniować strukturę, która zapewni sformalizowany proces zarządzania poziomami usług między klientem a dostawcą usług. Struktura powinna zachowywać stałą zgodność z wymaganiami i priorytetami biznesowymi oraz ułatwiać współpracę między klientem a dostawcą. Metodyka powinna obejmować proces definiowania wymagań wobec usług i tworzenia definicji usług, umów SLA i OLA oraz źródeł finansowania. Atrybuty te powinny być uwzględnione w katalogu usług. Metodyka powinna określać strukturę organizacyjną zarządzania poziomami usług, uwzględniając role, zadania i zakres odpowiedzialności wewnętrznych i zewnętrznych dostawców usług i klientów.

DS1.2 Definicja usług Oprzeć definicje usług IT na ich charakterystykach i wymaganiach biznesowych. Zapewnić, aby były one uporządkowane i przechowywane centralnie, wdrażając podejście wykorzystujące katalog usług.

DS1.3 Umowy dotyczące poziomu jakości usług (Sla) Zdefiniować i uzgodnić umowy SLA dla wszystkich krytycznych usług IT w oparciu o wymagania klienta i zdolności IT. Powinny one uwzględniać zobowiązania klienta, wymagania dotyczące wsparcia technicznego; ilościowe i jakościowe mierniki umożliwiające pomiar parametrów usług zatwierdzonych przez interesariuszy, uzgodnienia dotyczące finansowania i zagadnień handlowych (jeśli dotyczy) oraz role i obowiązki (w tym nadzór nad wykonaniem umów SLA). Wziąć pod uwagę takie zagadnienia, jak dostępność, niezawodność, wydajność, potencjał wzrostu, poziomy wsparcia, planowanie ciągłości, bezpieczeństwo i ograniczenia popytu.

DS1.4 Umowy dotyczące poziomu jakości usług wewnętrznych (ola)Zdefiniować umowy OLA, które określają, w jaki sposób usługi będą dostarczane technicznie, aby w optymalny sposób wspierać realizację umów SLA. Umowy OLA powinny określać procesy techniczne w kategoriach istotnych dla dostawcy i mogą wspierać kilka umów SLA.

DS1.5 Monitorowanie i raportowanie osiągnięć w zakresie poziomu usług Stale monitorować określone kryteria dotyczące poziomu realizacji usług. Sprawozdania dotyczące osiągnięć w zakresie poziomu usług powinny być dostarczane w formie zrozumiałej dla interesariuszy. Należy analizować i wykorzystywać statystyki z monitoringu w celu identyfikacji niekorzystnych i korzystnych trendów w odniesieniu do poszczególnych usług, jak i całości usług.

DS1.6 Przegląd umów i kontraktów dotyczących poziomu jakości usług Dokonywać regularnego przeglądu umów SLA i kontraktów z wewnętrznymi i zewnętrznymi dostawcami usług, aby upewnić się, że są one obowiązujące i aktualne oraz że uwzględniono zmiany dotyczące wymagań.

cele konTrolne

Dostarczanie i wsparcieDefiniowanie i zarządzanie poziomami usługDS1



Cele i mierniki

PO1 PlanystrategiczneitaktyczneIT,portfelusługIT

PO2 KlasyfikacjaprzypisanychdanychPO5 ZaktualizowanyportfelusługITAI2 WstępniezaplanowaneumowySLAAI3 WstępniezaplanowaneumowyOLADS4 Wymaganiadotycząceobsługikatastrofy,

łączniezrolamiizakresem odpowiedzialności

ME1 WymaganiadotyczącewydajnościnapotrzebyplanowaniaIT

Sprawozdaniezprzegląduumów DS2Sprawozdaniadotyczącewydajnościprocesu ME1Nowe/zaktualizowanewymaganiadotycząceusług PO1UmowySLA AI1 DS2 DS3 DS4 DS6 DS8 DS13UmowyOLA DS4 DS5 DS6 DS7 DS8 DS11 DS13ZaktualizowanyportfelusługIT PO1

• Liczba formalnych spotkań ze stroną biznesową (rocznie) poświęconych przeglądowi umów SLA

• Procent poziomów usług uwzględnionych w sprawozdaniach

• Procent poziomów usług objętych zautomatyzowaną sprawozdawczością

• Liczba dni roboczych potrzebnych na dostosowanie poziomu usługi po uzgodnieniu z klientem

• Procent interesariuszy biznesowych zadowolonych z tego, że usługi są świadczone na uzgodnionym poziomie

• Procent użytkowników zadowolonych z tego, że usługi są świadczone na uzgodnionym poziomie

• Liczba dostarczonych usług nie ujętych w katalogu

• Procent usług spełniających wymagania dotyczące poziomu usług

• Procent poziomów usług podlegających pomiarowi

Czynności• Definiowanie usług• Formalizacja wewnętrznych

i zewnętrznych umów zgodna z wymaganiami i możliwościami realizacji

• Raportowanie osiągniętych poziomów usług (sprawozdania i spotkania)

• Zapewnienie, aby sprawozdania były dostosowane do potrzeb odbiorcy

• Przekazywanie informacji o nowych i uaktualnionych wymaganiach dotyczących usług na potrzeby planowania strategicznego


zadowoleni z oferty i poziomu usług.• Odpowiadać na wymagania biznesowe

zgodnie ze strategią biznesową.• Zapewnić przejrzystość i zrozumiałość

kosztów, korzyści, strategii, polityk i poziomów usług IT.

Proces• Zapewnić wspólne zrozumienie

wymaganych poziomów usług.• Sformalizować i monitorować umowy

SLA i kryteria realizacji.• Dostosować dostarczane usługi do

uzgodnionych poziomów usług.• Stworzyć aktualny katalog usług, zgodny

z celami biznesowymi.

Czynności

Tabela RACI Funkcje

Człon

ek za

rządu

Dyrek

tor d

s. fin

anso

wych

(CFO

)Dy

rekto

r ds.

infor

matyk

i (CIO

)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

kt

Dyrek

tor g

ener

alny (

CEO)

Kier

ownik

ds. ro

zwoju

Kier

ownik

ds. a

dmini

strac

ji IT

Kier

ownik

biur

a zar

ządz

ania

proje

ktam

i (PMO)

Kont

rola

wewn

ętrzn

a; Au

dyt;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Kier

ownik

ds. u

sług

Tworzenie struktury w celu definiowania usług IT. C A C C I C C I C R Stworzenie katalogu usług IT. I A C C I C C I I RZdefiniowanie umów SLA dla krytycznych usług IT. I I C C R I R R C C A/RZdefiniowanie umów OLA w celu spełnienia warunków umów SLA. I C R I R R C C A/RMonitorowanie i raportowanie kompleksowych wyników w zakresie poziomu usług. I I R I I I A/RWeryfikacja umów SLA i UC. I I C R R R C A/RWeryfikacja i aktualizacja katalogu usług IT. I A C C I C C I I RStworzenie planu ulepszania usług. I A I R I R C C I R



Dostarczanie i wsparcieDefiniowanie i zarządzanie poziomami usług DS1

Źródło Elementy wejściowe Elementy wyjściowe Przeznaczenie


Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Definiowanie i zarządzanie poziomami usług”, który spełnia wymaganie biznesowe dla IT dotyczące zapewnienia zgodności kluczowych usług IT ze strategią biznesową, jest:

0 Nieistniejące gdyKierownictwo nie dostrzega potrzeby istnienia procesu definiowania poziomów usług. Nie jest przypisana odpowiedzialność ani rozliczalność za ich monitorowanie.

1 Początkowe/doraźne gdyIstnieje świadomość potrzeby zarządzania poziomami usług, ale proces ma charakter doraźny i nieformalny. Nie jest określona odpowiedzialność ani rozliczalność za definiowanie i zarządzanie usługami. Jeśli dokonuje się pomiarów wydajności, mają one tylko jakościowy charakter i nieprecyzyjnie zdefiniowane cele. Sprawozdawczość jest nieformalna, sporadyczna i niekonsekwentna.

2 Powtarzalne lecz intuicyjne gdyIstnieją uzgodnione poziomy usług, ale mają nieformalny charakter i nie podlegają przeglądom. Sprawozdawczość dotycząca poziomu usług jest niekompletna i może być może być nieadekwatna lub myląca dla klientów. Jest ona uzależniona od umiejętności i inicjatywy poszczególnych menedżerów. Wyznaczony jest koordynator ds. poziomu usług, który ma określone obowiązki, ale ograniczony zakres uprawnień. Istnieje proces zapewnienia zgodności z umowami SLA, ale jest dobrowolny i nieegzekwowany.

3 Zdefiniowane gdyObowiązki są dobrze zdefiniowane, ale z uznaniowo określonym zakresem uprawnień. Istnieje proces tworzenia umów SLA, który uwzględnia punkty kontrolne dla oceny poziomów usług i zadowolenia klientów. Usługi i poziomy usług są zdefiniowane, udokumentowane i uzgodnione w ramach standardowego procesu. Identyfikuje się odstępstwa od uzgodnionego poziomu usług, ale procedury postępowania z nimi są nieformalne. Istnieje wyraźne powiązanie między zapewnieniem oczekiwanego poziomu usług a zapewnionym finansowaniem. Poziomy usług są uzgodnione, ale mogą one nie odpowiadać potrzebom biznesowym.

4 Kontrolowane i mierzalne gdyPoziomy usług są coraz częściej definiowane w fazie określania wymagań dla systemów i uwzględniane w projektach środowisk aplikacji i środowisk operacyjnych. Rutynowo dokonuje się pomiaru i oceny zadowolenia klientów. Pomiary wydajności odzwierciedlają bardziej potrzeby klientów niż cele IT. Pomiary do oceny poziomu usług stają się ustandaryzowane i odzwierciedlają normy branżowe. Kryteria definiowania poziomów usług odnoszą się do nieodzowności dla działalności biznesowej i uwzględniają takie czynniki, jak dostępność, niezawodność, wydajność, potencjał wzrostu, wsparcie użytkownika, planowanie ciągłości i względy bezpieczeństwa. Gdy nie są zapewniane założone poziomy usług, przeprowadza się analizę przyczyny podstawowej. Sprawozdawczość procesu monitorowania poziomów usług staje się coraz bardziej zautomatyzowana.Zdefiniowane i dobrze zrozumiałe jest ryzyko operacyjne i finansowe związane z niezapewnieniem uzgodnionych poziomów usług. Wprowadzony formalny system pomiaru jest utrzymywany.

5 Zoptymalizowane gdyPoziomy usług są stale oceniane, aby zapewnić zgodność z celami IT i celami biznesowymi przy jednoczesnym wykorzystaniu technologii (włączając stosunek kosztów i korzyści). Cały proces zarządzania poziomami usług jest przedmiotem ciągłego doskonalenia. Poziom zadowolenia klientów jest stale monitorowany i zarządzany. Oczekiwane poziomy usług odzwierciedlają strategiczne cele jednostek biznesowych i są oceniane względem norm branżowych. Kierownictwo działu IT dysponuje potrzebnymi zasobami i zasadami rozliczeń, aby osiągać założone cele poziomu usług, a system wynagradzania przewiduje zachęty do osiągania tych celów. W ramach procesu ciągłego doskonalenia, wyższa kadra zarządzająca monitoruje mierniki wydajności.

Model dojrzałości

Dostarczanie i wsparcieDefiniowanie i zarządzanie poziomami usługDS1


oPis Procesu


Zarządzanie usługami zewnętrznymi,


dotyczące zapewnienia zadowalającego poziomu usług zewnętrznych przy jednoczesnym zachowaniu przejrzystości korzyści, kosztów i ryzyka


ustanowieniu relacji i wzajemnych zobowiązań z rzetelnymi zewnętrznymi dostawcami usług i monitorowanie dostarczania usług w celu weryfikacji i zapewnienia realizacji umów,


• identyfikację i klasyfikację usług dostawców; • identyfikację i łagodzenie ryzyka współpracy z dostawcami; • monitorowanie i pomiar wydajności dostawców


• liczbę skarg użytkowników dotyczących zakontraktowanych usług; • procent ważnych dostawców spełniających jasno zdefiniowane

wymagania i kryteria poziomów usług; • procent ważnych dostawców objętych monitoringiem.





Ds2 zarządzanie usługami zewnętrznymi

Potrzeba zapewnienia, że usługi dostarczane przez strony trzecie (dostawców, producentów i partnerów) spełniają wymagania biznesowe, wymaga istnienia efektywnego procesu zarządzania usługami zewnętrznymi. Proces ten jest realizowany poprzez jasne zdefiniowanie ról, obowiązków i oczekiwań w umowach z zewnętrznymi dostawcami, a także weryfikowanie i monitorowanie tych umów pod kątem efektywności i zgodności. Efektywne zarządzanie usługami zewnętrznymi minimalizuje ryzyko biznesowe związane z dostawcami, którzy nie realizują umów.

S S S S SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieZarządzanie usługami zewnętrznymi DS2



DS2.1 Identyfikacja wszystkich relacji z dostawcami Zidentyfikować wszystkie usługi dostawców i sklasyfikować je według typu dostawcy, znaczenia i nieodzowności. Prowadzić formalną dokumentację relacji technicznych i organizacyjnych obejmujących role i obowiązki, cele, oczekiwane rezultaty oraz referencje osób reprezentujących dostawców.

DS2.2 Zarządzanie relacjami z dostawcami Sformalizować proces zarządzania relacjami dla każdego dostawcy. Właściciele relacji powinni współpracować przy rozwiązywaniu problemów po stronie klienta i dostawcy i zapewniać wysoką jakość relacji w oparciu o zaufanie i przejrzystość (np. poprzez umowy SLA).

DS2.3 Zarządzanie ryzkiem współpracy z dostawcami Na bieżąco identyfikować i łagodzić ryzyko dotyczące zdolności dostawców do świadczenia usług w bezpieczny i efektywny sposób. Zapewnić, aby umowy były zgodne z uniwersalnymi standardami biznesowymi oraz wymaganiami prawnymi i regulacyjnymi. Zarządzanie ryzykiem powinno również uwzględniać takie zagadnienia, jak: umowy o zachowaniu poufności (NDA), umowy escrow, dalszą zdolność doświadczenia usług, zgodność z wymaganiami dotyczącymi bezpieczeństwa, alternatywni dostawcy, kary i nagrody itp.

DS2.4 Monitorowanie wydajności dostawców Wprowadzić proces monitorowania świadczenia usług, aby zapewnić, że dostawca spełnia aktualne wymagania biznesowe, realizuje postanowienia kontraktu i umów SLA oraz że jego wydajność jest konkurencyjna w stosunku do alternatywnych dostawców i warunków rynkowych.

cele konTrolne

Dostarczanie i wsparcieZarządzanie usługami zewnętrznymiDS2



Cele i mierniki

PO1 Strategia zaopatrzenia ITPO8 Standardynabywania AI5 Postanowieniaumów,wymaganiazarządcze

dotyczącerelacjizpodmiotamizewnętrznymiDS1 UmowySLA,sprawozdaniezprzeglądu

umówDS4 Wymaganiadotycząceobsługikatastrofy,

łączniezrolamiizakresem odpowiedzialności

Sprawozdaniadotyczącewydajnościprocesu ME1Katalogdostawców AI5Ryzykowspółpracyzdostawcami PO9

• Procent ważnych dostawców podlegających jasno zdefiniowanym wymaganiom i kryteriom poziomów usług

• Procent ważnych dostawców objętych monitoringiem

• Pozom zadowolenia strony biznesowej z efektywności komunikacji z dostawcą

• Pozom zadowolenia dostawcy z efektywności komunikacji ze stroną biznesową

• Liczba znaczących incydentów związanych z niezachowaniem zgodności przez dostawcę (w danym okresie)

• Liczba skarg użytkowników dotyczących zakontraktowanych usług

• Procent wydatków na zakupy zrealizowane przy zachowaniu zasady konkurencyjności

• Procent ważnych dostawców spełniających jasno zdefiniowane wymagania i kryteria poziomów usług

• Liczba formalnych sporów z dostawcami • Procent kwestionowanych faktur

dostawców

Czynności• Identyfikacja i kategoryzacja usług

dostawców• Identyfikacja i łagodzenie ryzyka

współpracy z dostawcami• Monitorowanie i pomiar wydajności

dostawców

IT• Zapewnić obustronne zadowolenie

z relacji z zewnętrznymi dostawcami.• Zapewnić, aby użytkownicy końcowi byli

zadowoleni z oferty i poziomu usług.• Zapewnić przejrzystość i zrozumiałość

kosztów, korzyści, strategii, polityki i poziomu usług IT.

Proces• Ustanowić relacje i wzajemne

zobowiązania z rzetelnymi zewnętrznymi dostawcami.

• Monitorować świadczenie usług i weryfikować zgodność z umowami.

• Zapewnić, aby dostawca zachowywał zgodność z odpowiednimi wewnętrznymi i zewnętrznymi standardami.

• Podtrzymywać chęć dostawców do kontynuowania relacji.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. roz

woju

Kier

ownik

ds. a

dmini

strac

ji IT

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Zidentyfikowanie i skategoryzowanie stosunków usługowych z podmiotami zewnętrznymi. I C R C R A/R C CZdefiniowanie i udokumentowanie procesów zarządzania dostawcami. C A I R I R R C CStworzenie procesu oceny dostawców oraz polityk i procedur wyboru. C A C C C R C CIdentyfikacja, ocena i ograniczanie ryzyk związanych z dostawcami. I A R R R C CMonitorowanie świadczenia usług przez dostawców. R A R R R C COcena celów długoterminowych wszystkich interesariuszy w zakresie stosunków usługowych. C C C A/R C C C C R C C



Dostarczanie i wsparcieZarządzanie usługami zewnętrznymi DS2



stymulacja

stymulacja

Cele

Mie

rnik

i

usta-lenie

usta-lenie



Zarządzanie procesem „Zarządzanie usługami zewnętrznymi”, który spełnia wymaganie biznesowe dla IT dotyczące zapewnienia zadowalającego poziomu usług zewnętrznych przy jednoczesnym zachowaniu przejrzystości korzyści, kosztów i ryzyka, jest:

0 Nieistniejące gdyOdpowiedzialność i rozliczalność nie jest zdefiniowana. Nie ma formalnej polityki ani procedur dotyczących zawierania umów z podmiotami zewnętrznymi. Zewnętrzne usługi nie są zatwierdzane ani weryfikowane przez kierownictwo. Nie dokonuje się pomiarów, a zewnętrzni dostawcy nie sporządzają sprawozdań. Ze względu na brak obowiązku sporządzania sprawodzań wyższa kadra kierownicza nie jest świadoma jakości dostarczanych usług.

1 Początkowe/doraźne gdyKierownictwo jest świadome potrzeby posiadania udokumentowanej polityki o procedur zarządzania relacjami z podmiotami zewnętrznymi, w tym zawartymi umowami. Nie ma standardowych warunków umów z dostawcami. Pomiary dotyczące świadczonych usług są nieformalne i doraźne. Praktyki są zależne od doświadczenia (np. na żądanie) danej osoby i dostawcy.

2 Powtarzalne lecz intuicyjne gdyProces nadzoru nad zewnętrznymi dostawcami usług, towarzyszącym ryzykiem i dostarczaniem usług ma nieformalny charakter. Wykorzystuje się podpisaną umowę pro forma ze standardowymi warunkami (np. z wolnym miejscem na podanie opisu usług). Dostępne są sprawozdania dotyczące dostarczonych usług, ale nie wspierają one realizacji celów biznesowych.

3 Zdefiniowane gdyIstnieją dobrze udokumentowane procedury zarządzania usługami zewnętrznymi, z przejrzystymi procesami weryfikacji i negocjacji z dostawcami. Po podpisaniu umowy o świadczenie usług relacje z zewnętrznym dostawcą są czysto kontraktowe. Rodzaj świadczonych usług jest opisany w umowie wraz z wymaganiami o charakterze prawnym, operacyjnym i kontrolnym. Odpowiedzialność za nadzór nad usługami zewnętrznymi jest określona. Warunki umów są określane w oparciu o ustandaryzowane szablony. Ryzyko związane z korzystaniem z usług zewnętrznych jest oceniane i raportowane.

4 Kontrolowane i mierzalne gdyFormalne i ustandaryzowane kryteria definiowania warunków umowy są ustalone, włączając w to: zakres prac, usług/elementów, które mają być dostarczone, a także założenia, harmonogram, koszty, warunki fakturowania i zakres odpowiedzialności. Odpowiedzialność za zarządzanie umowami i dostwcami jest określona. Kwalifikacje, ryzyko i zdolności dostawców są weryfikowane na bieżąco. Wymagania dotyczące usług są definiowane w powiązaniu z celami biznesowymi. Istnieje proces weryfikacji świadczonych usług w odniesieniu do warunków umowy, który zapewnia możliwość oceny aktualnych i przyszłych usług zewnętrznych. W procesie zaopatrzenia wykorzystywane są modele ustalania ceny transferowej. Wszystkie zaangażowane strony są świadome wymagań dotyczących obsługi, kosztów i kluczowych etapów. Istnieją uzgodnione cele i mierniki na potrzeby sprawowania nadzoru nad dostawcami usług.

5 Zoptymalizowane gdyUmowy podpisane z zewnętrznymi dostawcami są weryfikowane w określonych odstępach czasu. Określona jest odpowiedzialność za zarządzanie dostawcami i jakością świadczonych przez nich usług. Monitoruje się zgodność realizacji umów z wymaganiami operacyjnymi, prawnymi i kontrolnymi i egzekwuje działania korygujące. Zewnętrzni dostawcy są poddawani okresowo niezależnym przeglądom okresowym, których wyniki są wykorzystywane w celu poprawy jakości świadczenia usług. Pomiary są zróżnicowane w zależności od zmieniających się warunków biznesowych. Umożliwiają one wykrywanie potencjalnych problemów z zewnętrznymi usługami. Wyczerpujące sprawozdania dotyczące osiągnięć w zakresie poziomu usług są powiązane z systemem wynagradzania dostawców. Na podstawie pomiarów, kierownictwo odpowiednio dostosowuje proces nabywania i monitorowania usług zewnętrznych.

Model dojrzałości

Dostarczanie i wsparcieZarządzanie usługami zewnętrznymiDS2


oPis Procesu


Zarządzanie wydajnością i potencjałem,


dotyczące optymalizacji infrastruktury, zasobów i potencjału IT zależnie od potrzeb biznesowych


spełnianiu wymagań umów SLA dotyczących czasu reakcji, minimalizowaniu czasu przestojów oraz ciągłym doskonaleniu wydajności i potencjału IT poprzez monitorowanie i pomiary.


• planowanie i zapewnianie potencjału i dostępności systemów; • monitorowanie i raportowanie wydajności systemów; • modelowanie i prognozowanie wydajności systemów


• miesięczną liczbę godzin straconych na użytkownika na skutek nieprawidłowego planowania potencjału;

• procent wartości szczytowych, gdy obciążenie docelowe zostało przekroczone;

• procent czasu reakcji, gdy nie są spełnione warunki umów SLA.





Ds3 zarządzanie wydajnością i potencjałem

Potrzeba zarządzania wydajnością i potencjałem zasobów IT wymaga procesu, który umożliwia okresowy przegląd aktualnej wydajności i potencjału zasobów IT. Proces ten obejmuje również prognozowanie przyszłych potrzeb na podstawie wymagań dotyczących obciążenia, zasobów pamięci i rozwiązań awaryjnych. Daje to gwarancję stałej dostępności zasobów informatycznych wspierających realizację wymagań biznesowych.

SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieZarządzanie wydajnością i potencjałem DS3



DS3.1 Planowanie wydajności i potencjału Wprowadzić proces planowania służący przeglądowi wydajności i potencjału zasobów IT w celu zapewnienia po uzasadnionych kosztach potencjału i wydajności niezbędnych do przetwarzania w sposób określony w umowach SLA uzgodnionych ilości danych. Plany dotyczące potencjału i wydajności powinny wykorzystywać odpowiednie techniki modelowania w celu stworzenia modelu aktualnej i prognozowanej wydajności, potencjału i przepustowości zasobów IT.

DS3.2 aktualna wydajność i potencjałOcenić aktualną wydajność i potencjał zasobów IT w celu stwierdzenia, czy jest dostępny wystarczający potencjał i wydajność, aby osiągnąć uzgodnione poziomy usług.

DS3.3 Przyszła wydajność i potencjałRegularnie prognozować wydajność i potencjał zasobów IT, aby ograniczyć do minimum ryzyko zakłóceń w świadczeniu usług na skutek niewystarczającego potencjału lub spadku wydajności; zidentyfikować również nadmiary potencjału w celu ewentualnej relokacji. Zidentyfikować trendy dotyczące obciążenia i sporządzić prognozy na potrzeby planowania wydajności i potencjału.

DS3.4 Dostępność zasobów IT Zapewnić wymagany potencjał i wydajność, biorąc pod uwagę takie czynniki, jak standardowe obciążenia, sytuacje awaryjne, wymagania dotyczące zasobów pamięci oraz cykl życia zasobów IT. Należy wykorzystywać takie rozwiązania, jak określanie hierarchii ważności zadań, mechanizmy zapewnienia odporności na błędy czy praktyki alokacji zasobów. Kierownictwo powinno zapewnić, aby plany awaryjne odpowiednio rozwiązywały kwestie dostępności, potencjału i wydajności poszczególnych zasobów IT.

DS3.5 Monitorowanie i raportowanie Stale monitorować wydajność i potencjał zasobów IT. Gromadzone dane powinny służyć dwóm celom:• utrzymywaniu i dostosowywaniu aktualnej wydajności zasobów do potrzeb IT oraz rozwiązywaniu problemów dotyczących

odporności, rozwiązań awaryjnych, aktualnych i prognozowanych obciążeń, planów przechowywania oraz nabywania zasobów;• raportowaniu dostępności usług na potrzeby strony biznesowej, zgodnie z umowami SLA.

Wszystkie sprawozdania dotyczące odstępstw powinny zawierać zalecenia odnośnie działań korygujących.

cele konTrolne

Dostarczanie i wsparcieZarządzanie wydajnością i potencjałemDS3



Cele i mierniki

AI2 Specyfikacjadostępności,ciągłościiodtwarzania

AI3 Wymagania monitorowania systemu DS1 Umowy SLA

Informacjedotyczącewydajnościipotencjału PO2 PO3Planwydajnościipotencjału(wymagania) PO5 AI1 AI3 ME1Wymaganezmiany AI6Sprawozdaniadotyczącewydajnościprocesu ME1

• Częstotliwość prognozowania wydajności i potencjału

• Procent zasobów uwzględnionych w ocenach potencjału

• Procent zasobów monitorowanych przez narzędzia scentralizowane

• Liczba straconych godzin miesięcznie na użytkownika na skutek nieprawidłowego planowania potencjału

• Liczba krytycznych procesów biznesowych nieuwzględnionych w przyjętym planie dostępności usług

• Obciążenie szczytowe i wskaźniki całkowitego obciążenia

• Procent wartości szczytowych, gdy przekroczone jest obciążenie docelowe

• Procent czasu reakcji, gdy nie są spełnione warunki umów SLA

• Współczynnik występowania błędów transakcji

Czynności• Planowanie i zapewnianie potencjału

i dostępności systemów• Monitorowanie i raportowanie

wydajności systemów• Modelowanie i prognozowanie

wydajności systemów


zgodnie ze strategią biznesową.• Zapewnić dostępność usług IT

adekwatnie do potrzeb.• Zoptymalizować infrastrukturę, zasoby

i potencjał IT.

Proces• Monitorować i dokonywać pomiarów

obciążeń szczytowych i czasów odpowiedzi transakcji.

• Zapewniać czas odpowiedzi określony w umowach SLA.

• Ograniczać do minimum błędy transakcji.• Ograniczać do minimum czas przestojów.• Optymalizować wykorzystanie zasobów

IT.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Ustanowienie procesu planowania w celu weryfikacji wydajności i potencjału zasobów IT. A R C C C CDokonywanie weryfikacji bieżącej wydajności i potencjału zasobów IT. C I A/R C C CSporządzenie prognoz dotyczących wydajności i potencjału zasobów IT. C C A/R C C C CPrzeprowadzenie analizy luk w celu identyfikacji rozbieżności między zasobami IT. C I A/R R C C IOpracowanie planu awaryjnego w razie możliwego braku dostępności zasobów IT. C I A/R C C I CCiągłe monitorowanie i dostarczanie raportów dotyczących dostępności, wydajności i potencjału zasobów IT. I I A/R I I I I



Dostarczanie i wsparcieZarządzanie wydajnością i potencjałem DS3



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie wydajnością i potencjałem”, który spełnia wymaganie biznesowe wobec IT dotyczące optymalizacji infrastruktury, zasobów i potencjału IT zależnie od potrzeb biznesowych, jest:

0 Nieistniejące gdyKierownictwo nie dostrzega, że kluczowe procesy biznesowe mogą wymagać wysokiego poziomu wydajności IT lub, że ogólne zapotrzebowanie strony biznesowej na usługi IT może przekraczać ich potencjał. Nie występuje proces planowania potencjału.

1 Początkowe/doraźne gdyUżytkownicy stosują doraźne rozwiązania w przypadku występowania ograniczeń dotyczących wydajności i potencjału. Istnieje bardzo mała świadomość potrzeby planowania potencjału i wydajności przez właścicieli procesów biznesowych. Działania w dziedzinie zarządzania wydajnością i potencjałem są zwykle doraźne. Proces planowania potencjału i wydajności ma nieformalny charakter. Zrozumienie obecnego i przyszłego potencjału i wydajności zasobów IT jest ograniczone.

2 Powtarzalne lecz intuicyjne gdyZarządzający działem biznesowym i działem IT są świadomi negatywnego wpływu, jaki ma brak zarządzania wydajnością i potencjałem. Potrzeby dotyczące wydajności są na ogół spełniane w oparciu o ocenę poszczególnych systemów oraz wiedzę zespołu projektowego i ds. wsparcia. Mogą być stosowane pojedyncze narzędzia do diagnozowania problemów związanych z wydajnością i potencjałem, ale spójność rezultatów jest uzależniona od kompetencji pojedynczych kluczowych osób. Nie dokonuje się ogólnej oceny potencjału wydajności IT ani nie rozważa sytuacji szczytowych obciążeń i najgorszych scenariuszy. Istnieje prawdopodobieństwo wystąpienia nieoczekiwanych problemów z dostępnością, których diagnozowanie i usunięcie może być czasochłonne. Wszelkie pomiary wydajności są dokonywane głownie na potrzeby IT, a nie klienta.

3 Zdefiniowane gdyWymagania dotyczące wydajności i potencjału są zdefiniowane dla całego cyklu życia systemu. Zdefiniowane są wymagania dotyczące poziomu usług i mierników, które mogą być wykorzystane do pomiaru wydajności operacyjnej. Wymagania dla przyszłej wydajności i potencjału modelowane są w oparciu o zdefiniowany proces. Sporządzane są sprawozdania ze statystykami wydajności. Nadal prawdopodobne jest wystąpienie problemów z wydajnością i potencjałem, których usunięcie może być czasochłonne. Mimo poinformowania o poziomach usług, użytkownicy i klienci mogą mieć wątpliwości co do ich dostępności.

4 Kontrolowane i mierzalne gdyDostępne są procesy i narzędzia służące do pomiaru wykorzystania, wydajności i potencjału systemu, a wyniki są porównywane z określonymi celami. Dostępne są aktualne informacje dotyczące ustandaryzowanych statystyk wydajności oraz alarmujących incydentów związanych z niewystarczającą wydajnością i potencjałem. Problemy z niewystarczającą wydajnością i potencjałem są rozwiązywane zgodnie z określonymi i ustandaryzowanymi procedurami. Wykorzystywane są zautomatyzowane narzędzia do monitorowania określonych zasobów, takich jak przestrzeń dyskowa, sieci, serwery i bramki sieciowe. Statystyki dotyczące wydajności i potencjału są raportowane w odniesieniu do procesu biznesowego, więc użytkownicy i klienci rozumieją zdefiniowane poziomy usług IT. Użytkownicy są ogólnie zadowoleni z bieżącej dostępności usług, ale mogą zgłaszać potrzebę nowych, wyższych poziomów dostępności. Mierniki dla pomiaru wydajności i potencjału usług IT są uzgodnione, ale mogą być sporadycznie i niekonsekwentnie stosowane.

5 Zoptymalizowane gdyPlany dotyczące wydajności i potencjału są w pełni zsynchronizowane z prognozami potrzeb biznesowych. Infrastruktura IT i potrzeby biznesowe są poddawane regularnej ocenie w celu zapewnienia optymalnego potencjału przy możliwie jak najniższych kosztach. Narzędzia do monitorowania krytycznych zasobów IT są ustandaryzowane, wykorzystywane na wszystkich platformach i powiązane z ogólnoorganizacyjnym systemem zarządzania incydentami. Narzędzia monitorujące wykrywają i mogą automatycznie rozwiązać problemy dotyczące wydajności i potencjału. Przeprowadza się analizę trendów, która pozwala przewidzieć zbliżające się problemy z wydajnością spowodowane zwiększającymi się potrzebami biznesowymi, umożliwiając planowanie i unikanie niespodziewanych problemów. Mierniki służące do pomiaru wydajności i potencjału IT zostały precyzyjnie uwzględnione w miarach wyników i wskaźnikach wydajności wszystkich krytycznych procesów biznesowych i podlegają konsekwentnemu pomiarowi. Na podstawie analizy tych pomiarów kierownictwo dostosowuje plany dotyczące wydajności i potencjału.

Model dojrzałości

Dostarczanie i wsparcieZarządzanie wydajnością i potencjałemDS3


oPis Procesu


Zapewnianie ciągłości usług,

który spełnia wymaganie biznesowe wobec it

które dotyczy minimalizacji negatywnego wpływu potencjalnej przerwy w dostępności usług IT na działalność biznesową


zapewnieniu odporności rozwiązań zautomatyzowanych i opracowaniu, utrzymywaniu i testowaniu planów zapewnienia ciągłości usług IT,


• opracowanie i utrzymywanie (doskonalenie) planów awaryjnych IT; • szkolenie w zakresie panów awaryjnych IT oraz ich testowanie; • przechowywanie kopii planów awaryjnych i danych w pozamiejscowych

lokalizacjach


• liczbę godzin straconych miesięcznie na użytkownika na skutek nieplanowanych przestojów;

• liczbę krytycznych procesów biznesowych zależnych od usług IT, które nie są objęte planem zapewnienia ciągłości usług IT.





Ds4 zapewnianie ciągłości usług

Potrzeba zapewnienia ciągłości usług IT wymaga opracowania, utrzymywania i testowania planów zapewnienia ciągłości usług IT z wykorzystaniem pozamiejscowej lokalizacji kopii zapasowych oraz zapewnienia okresowych szkoleń w dziedzinie planowania ciągłości. Efektywny proces zapewnienia ciągłości usług minimalizuje prawdopodobieństwo i negatywny wpływ znaczącej przerwy w dostępności usług IT na działanie kluczowych funkcji i procesów biznesowych.

SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

ZASO

BAM

I




Dostarczanie i wsparcieZapewnianie ciągłości usług DS4



DS4.1 Metodyka zapewnienia ciągłości IT Opracować metodykę zapewnienia ciągłości usług IT w celu wsparcia zarządzania ciągłością działalności biznesowej przedsiębiorstwa w ramach spójnego procesu. Celem metodyki powinna być pomoc w określeniu niezbędnej odporności infrastruktury oraz wkład w opracowanie planu odtwarzania po katastrofie i panu awaryjnego IT. Metodyka powinna określać organizacyjną strukturę zarządzania ciągłością, obejmując role, zadania i zakres odpowiedzialności wewnętrznych i zewnętrznych dostawców usług, ich kierownictwo oraz klientów, a także procesy planowania, które określają zasady i struktury w zakresie dokumentacji, testowania i realizacji planu odtwarzania po katastrofie i planu awaryjnego IT. Plan powinien również uwzględniać takie zagadnienia, jak określenie kluczowych zasobów, monitorowanie i raportowanie dostępności kluczowych zasobów, przetwarzanie alternatywne oraz zasady tworzenia kopii zapasowych i odtwarzania.

DS4.2 Plany zapewnienia ciągłości IT W oparciu o stworzoną strukturę opracować plany zapewnienia ciągłości usług IT, mające na celu ograniczenie negatywnego wpływu znaczącej przerwy w dostępności usług na kluczowe funkcje i procesy biznesowe. Plany powinny opierać się na zrozumieniu ryzyka potencjalnego wpływu na procesy biznesowe i uwzględniać wymagania dotyczące odporności systemów, przetwarzania alternatywnego i zdolności do odtworzenia wszystkich krytycznych usług IT. Powinny one również obejmować wytyczne dotyczące użycia, role i zakres odpowiedzialności, procedury, procesy komunikacji oraz zalecenia dotyczące testowania.

DS4.3 Krytyczne zasoby IT Zwrócić szczególną uwagę na elementy określone w planie zapewnienia ciągłości usług IT jako te o kluczowym znaczeniu, aby zapewnić ich odporność i określić priorytety dotyczące procesu odtwarzania. Unikać zakłóceń spowodowanych odtwarzaniem elementów o mniejszym znaczeniu i zadbać o to, aby czas reakcji i proces odtwarzania były zgodne z hierarchią ważności potrzeb biznesowych, jednocześnie zapewniając utrzymanie kosztów na możliwym do zaakceptowania poziomie i zgodność z wymaganiami regulacyjnymi i wynikającymi z umów. Rozważyć wymagania dotyczące odporności, czasu reakcji i odtwarzania dla różnych poziomów (np. od jednej do czterech godzin, od czterech do 24 godzin, powyżej 24 godzin) oraz krytyczne dla działalności biznesowej okresy operacyjne.

DS4.4 Utrzymywanie planu zapewnienia ciągłości IT Zachęcić kierownictwo działu IT do zdefiniowania i realizacji procedur kontroli zmian, aby zapewnić, że plan zapewnienia ciągłości usług IT będzie zawsze aktualny i będzie stale odzwierciedlał rzeczywiste wymagania biznesowe. Informować o zmianach procedur i zakresu odpowiedzialności w przejrzysty i terminowy sposób.

DS4.5 Testowanie planu zapewnienia ciągłości IT Regularnie testować plan zapewnienia ciągłości usług IT, aby mieć pewność, że systemy IT mogą być skutecznie przywrócone do działania, że wyeliminowano niedociągnięcia, a plan jest aktualny. Wymaga to starannego przygotowania, dokumentacji, raportowania wyników testów i zależnie od nich — wdrożenia planu działania. Należy rozważyć zakres testowania — od odtwarzania pojedynczych aplikacji, poprzez scenariusze testowania zintegrowanego, po testowanie kompleksowe i zintegrowane testowanie rozwiązań dostawców.

DS4.6 Szkolenie w zakresie planu zapewnienia ciągłości IT Zapewnić wszystkim właściwym osobom udział w sesjach szkoleniowych dotyczących procedur oraz ról i zakresu odpowiedzialności w przypadku wystąpienia zdarzenia o charakterze incydentu lub katastrofy. Zweryfikować i poprawić efektywność szkolenia zależnie od wyników testów planu awaryjnego.

DS4.7 Dystrybucja planu zapewnienia ciągłości IT Określić zdefiniowaną i podlegającą zarządzaniu strategię dystrybucji, aby zapewnić odpowiednią i bezpieczną dystrybucję planów oraz ich dostępność we właściwym miejscu i czasie dla odpowiednio upoważnionych zainteresowanych stron. Należy zwrócić szczególną uwagę na zapewnienie dostępności planów w przypadku każdego scenariusza katastrofy.

DS4.8 odtwarzanie i wznawianie usług IT Zaplanować działania, które mają być podjęte w okresie przywracania i wznawiania usług IT. Mogą one obejmować uruchomienie ośrodków zapasowych, inicjowanie alternatywnego przetwarzania, komunikację z klientami i interesariuszami oraz procedury wznawiania usług. Zapewnić, aby kierujący działalnością biznesową rozumieli wymagania czasowe związane z odtwarzaniem usług IT oraz konieczność inwestycji w rozwiązania techniczne umożliwiające realizację potrzeb biznesowych dotyczących procesów odtwarzania i wznawiania.

DS4.9 Przechowywanie kopii zapasowych poza podstawową lokalizacją Przechowywać poza główną lokalizacją wszystkie krytyczne nośniki kopii zapasowych, dokumentację i inne zasoby IT niezbędne do odtworzenia usług IT i realizacji planów zapewnienia ciągłości działalności biznesowej. Określić zawartość pamięci zapasowej we współpracy między właścicielami procesów biznesowych i personelem IT. Zarządzanie kopiami zapasowymi poza lokalizacją podstawową powinno być zgodne z polityką klasyfikacji danych i praktykami przedsiębiorstwa dotyczącym nośników pamięci. Zarządzający działem IT powinni zapewnić dokonywanie okresowej oceny rozwiązań pozamiejscowych (co najmniej raz do roku) pod kątem zawartości, ochrony środowiskowej i bezpieczeństwa. Należy zapewnić zgodność sprzętu i oprogramowania, aby możliwe było przywrócenie zarchiwizowanych danych, a także okresowo testować i odświeżać zarchiwizowane dane.

DS4.10 Przegląd po wznowieniu Ustalić, czy kierownictwo działu IT ustanowiło procedury oceny adekwatności planu jeśli chodzi o udane wznowienie działalności IT po katastrofie, a także odpowiedniej aktualizacji planu.

cele konTrolne

Dostarczanie i wsparcieZapewnianie ciągłości usługDS4



Cele i mierniki

Źródło Elementy wejściowePO2 Klasyfikacjaprzypisanychdanych PO9 Ocena ryzykaAI2 Specyfikacjadostępności,ciągłościi

odtwarzaniaAI4 Podręczniki:użytkownika,operacyjny,dot.

wsparcia,technicznyidot.administracji DS1 Umowy SLA i OLA

Elementy wyjściowe Przeznaczenie Wyniki testu planu awaryjnego PO9KrytycznośćjednostekkonfiguracjiIT DS9 Plan przechowywania i ochrony kopii zapasowych DS11 DS13Progiincydentu/katastrofy DS8Wymaganiadotycząceobsługikatastrofy–łącznie DS1 DS2 zrolamiizakresemodpowiedzialnościSprawozdaniadotyczącewydajnościprocesu ME1

• Czas, jaki upłynął między testami danego elementu ujętego w planie zapewnienia ciągłości usług IT

• Liczba godzin szkolenia w zakresie zapewnienia ciągłości usług IT rocznie na danego pracownika działu IT

• Procent krytycznych komponentów infrastruktury objętych automatycznym monitoringiem dostępności

• Częstotliwość weryfikacji planu zapewnienia ciągłości usług IT

• Liczba straconych godzin miesięcznie na użytkownika na skutek nieplanowanych przestojów

• Procent dostępności zgodnie z umowami SLA

• Liczba krytycznych procesów biznesowych zależnych od usług IT, które nie są objęte planem zapewnienia ciągłości usług IT

• Procent testów, które zakończyły się osiągnięciem celów odtworzenia

• Częstotliwość występowania przerw w działaniu systemów o krytycznym znaczeniu

Czynności• Opracowanie i utrzymywanie

(doskonalenie) planów awaryjnych IT• Szkolenie w zakresie panów awaryjnych

IT oraz ich testowanie• Przechowywanie kopii planów

awaryjnych i danych w pozamiejscowych lokalizacjach

IT• Zapewnić dostępność usług IT

adekwatnie do potrzeb.• Zapewnić, aby potencjalna przerwa

lub zmiana w dostępności usług IT miała minimalny negatywny wpływ na działalność biznesową.

• Zapewnić, aby usługi i infrastruktura IT były zdolne oprzeć się i powrócić do działania po awariach na skutek błędu, celowego ataku lub katastrofy.

Proces• Wprowadzić plan zapewnienia

ciągłości usług IT, który wspiera plany zapewnienia ciągłości działalności biznesowej.

• Opracować plany zapewnienia ciągłości usług IT, które mogą zostać zrealizowane i będą utrzymywane i testowane.

• Ograniczyć do minimum możliwość wystąpienia przerwy w świadczeniu usług IT.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Opracowanie struktury zapewnienia ciągłości IT. C C A C R R R C C RPrzeprowadzenie analizy wpływu na działalność i oceny ryzyka. C C C C A/R C C C C COpracowanie i utrzymywanie planów zapewnienia ciągłości IT. I C C C I A/R C C C CZidentyfikowanie i skategoryzowanie zasobów IT w oparciu o cele dotyczące przywracania usług. C A/R C I C IZdefiniowanie i przestrzeganie procedur dotyczących kontroli nad zmianami w celu zapewnienia aktualności planu zachowania ciągłości IT. I A/R R R R IRegularne badanie planu zapewnienia ciągłości IT. I I A/R C C I IOpracowanie dalszego planu działania w oparciu o wyniki badań. C I A/R C R R R IZaplanowanie i przeprowadzenie szkoleń z zakresu ciągłości IT. I R A/R C R I IZaplanowanie procesu przywracania i wznawiania usług IT. I I C C A/R C R R R C Zaplanowanie i wdrożenie procesu przechowywania i ochrony zapasowych danych. I A/R C C I IUstanawianie procedur dotyczących prowadzenia przeglądów po dokonaniu wznowienia. C I A/R C C C



Dostarczanie i wsparcieZapewnianie ciągłości usług DS4


Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zapewnianie ciągłości usług”, który spełnia wymaganie biznesowe wobec IT dotyczące minimalizacji negatywnego wpływu potencjalnej przerwy w dostępności usług IT na działalność biznesową, jest:

0 Nieistniejące gdyNie ma zrozumienia ryzyka, podatności ani zagrożeń w odniesieniu do działalności IT, a także wpływu, jaki może mieć utrata usług IT na działalność biznesową. Zapewnienie ciągłości działania usług nie jest uznawane za kwestię, która wymaga uwagi kierownictwa.

1 Początkowe/doraźne gdyOdpowiedzialność za zapewnienie ciągłości działania usług ma nieformalny charakter, a uprawnienia do wykonywania związanych z tym obowiązków są ograniczone. Kierownictwo zaczyna sobie uświadamiać ryzyko oraz potrzebę zapewnienia ciągłości usług. Uwaga kierownictwa w obszarze zapewnienia ciągłości usług skupia się bardziej na zasobach infrastrukturalnych niż na usługach IT. W przypadku występowania zakłóceń w świadczeniu usług użytkownicy stosują rozwiązania doraźne. Reakcje działu IT na znaczące zakłócenia w dostępności usług są doraźne i nieprzygotowane. Czasowe wyłączenia związane z potrzebami działu IT są zaplanowane, ale nie uwzględniają one wymagań biznesowych.

2 Powtarzalne lecz intuicyjne gdyPrzypisana jest odpowiedzialność za zapewnienie ciągłości działania usług. Podejście do zapewnienia ciągłości usług nie ma kompleksowego charakteru. Raportowanie dostępności systemów jest sporadyczne, może być niekompletne i nie uwzględnia wpływu na działalność biznesową. Nie ma udokumentowanego planu zapewnienia ciągłości usług, znane są jednak jego najważniejsze założenia i występuje dążenie do zapewnienia stałej dostępności usług. Istnieje spis systemów i komponentów o krytycznym znaczeniu, może on jednak nie być wiarygodny. Pojawiają się praktyki związane z zapewnieniem ciągłości usług, ale ich powodzenie zależy od pojedynczych osób.

3 Zdefiniowane gdyRozliczalność zarządzania ciągłością usług ma jednoznaczny charakter. Wyraźnie zdefiniowana i przypisana jest odpowiedzialność za planowanie i testowanie ciągłości usług. Plan zapewnienia ciągłości usług IT jest udokumentowany i oparty na przesłankach krytyczności systemów i wpływu na działalność biznesową. Okresowo sporządzane są sprawozdania z testów ciągłości usług. Pojedyncze osoby wykazują inicjatywę w przestrzeganiu standardów i uczestniczą w szkoleniach, aby umiejętnie postępować w przypadku większych incydentów lub katastrofy. Kierownictwo informuje konsekwentnie o potrzebie planowania w celu zapewnienia ciągłości usług. Stosowane komponenty zapewniające wysoką dostępność oraz nadmiarowość systemów. Utrzymywany jest spis systemów i komponentów o krytycznym znaczeniu.

4 Kontrolowane i mierzalne gdyEgzekwowane są standardy i odpowiedzialność za zapewnienie ciągłości działania usług. Przypisana jest odpowiedzialność za utrzymywanie planu zapewnienia ciągłości usług. Czynności związane z jego utrzymywaniem opierają się na wynikach stałego testowania ciągłości usług, wewnętrznych dobrych praktykach oraz ocenie zmieniającego się środowiska IT i środowiska biznesowego. Gromadzone są ustrukturyzowane dane dotyczące zapewnienia ciągłości usług, które są poddawane analizie, raportowaniu i stanowią podstawę do działań. Odbywają są oficjalne i obowiązkowe szkolenia dotyczące procesów zapewnienia ciągłości usług. Konsekwentnie wdrażane są dobre praktyki zapewniania dostępności systemów. Praktyki zapewnienia dostępności i planowanie ciągłości usług mają na siebie wzajemny wpływ. Incydenty zakłócające ciągłość działania podlegają klasyfikacji a odpowiednie ścieżki eskalacyjne są dobrze znane osobom zaangażowanym. Cele i mierniki zapewnienia ciągłości usług są opracowane i uzgodnione, jednak mogą nie podlegać systematycznemu pomiarowi.

5 Zoptymalizowane gdyZintegrowane procesy zapewnienia ciągłości usług uwzględniają analizy porównawcze i najlepsze zewnętrzne praktyki. Plan zapewnienia ciągłości usług IT jest zintegrowany z planami zapewnienia ciągłości działalności biznesowej i rutynowo aktualizowany. Wymóg zapewnienia ciągłości usług jest spełniany przez usługodawców i najważniejszych dostawców. Przeprowadzane są kompleksowe testy planu zapewnienia ciągłości usług IT, a ich wyniki stanowią podstawę do aktualizacji planu. Gromadzenie i analiza danych służą ciągłemu doskonaleniu procesu. Praktyki zapewnienia dostępności i planowanie ciągłości usług są w pełni ze sobą zgodne. Kierownictwo zapewnia, że pojedynczy punkt awarii nie będzie przyczyną katastrofy lub poważnego incydentu. Procedury eskalacjj są rozumiane i w pełni egzekwowane. Cele i mierniki zapewnienia ciągłości usług podlegają systematycznym pomiarom. Na podstawie uzyskanych pomiarów kierownictwo modyfikuje plany dotyczące zapewnienia ciągłości usług.

Model dojrzałości

Dostarczanie i wsparcieZapewnianie ciągłości usługDS4


oPis Procesu


Zapewnianie bezpieczeństwa systemów,


dotyczące zachowania integralności informacji i infrastruktury przetwarzającej oraz ograniczenia do minimum wpływu podatności i incydentów bezpieczeństwa


definiowaniu polityki, planów i procedur dotyczących bezpieczeństwa IT oraz wykrywaniu, raportowaniu i eliminowaniu podatności i incydentów bezpieczeństwa,


• zrozumienie wymagań, podatności i zagrożeń; • zarządzanie tożsamościami i uprawnieniami użytkowników w ustandaryzowany

sposób; • regularne testowanie bezpieczeństwa


• liczbę incydentów niszczących reputację organizacji w oczach opinii publicznej;

• liczbę systemów, które nie spełniają wymagań dotyczących bezpieczeństwa;

• liczbę naruszeń zasady rozdziału obowiązków.





Ds5 zapewnianie bezpieczeństwa systemów

Potrzeba zachowania integralności informacji i ochrony zasobów IT wymaga istnienia procesu zarządzania bezpieczeństwem. Proces ten obejmuje określenie i utrzymywanie ról i zakresów odpowiedzialności, polityki, standardów oraz procedur dotyczących bezpieczeństwa IT. Zarządzanie bezpieczeństwem obejmuje również monitoring bezpieczeństwa oraz okresowe testowanie i wdrażanie działań eliminujących zidentyfikowane słabe strony zabezpieczeń lub incydenty. Efektywne zarządzanie bezpieczeństwem zapewnia ochronę wszystkich zasobów IT, aby ograniczyć do minimum wpływ podatności i incydentów bezpieczeństwa na działalność biznesową.

SSSP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieZapewnianie bezpieczeństwa systemów DS5



DS5.1 Zarządzanie bezpieczeństwem IT Zarządzać bezpieczeństwem IT na najwyższym, właściwym organizacyjnie poziomie, tak aby zarządzanie działaniami związanymi z zapewnieniem bezpieczeństwa było zgodne z wymaganiami biznesowymi.

DS5.2 Plan zapewnienia bezpieczeństwa IT Przełożyć wymagania: biznesowe, dotyczące ryzyka oraz zachowania zgodności, na ogólny plan zapewnienia bezpieczeństwa IT, biorąc pod uwagę infrastrukturę IT oraz kulturę bezpieczeństwa. Zapewnić wdrożenie planu w ramach polityk i procedur bezpieczeństwa wraz z odpowiednimi inwestycjami w obszarach usług, personelu, oprogramowania i sprzętu. Zapewnić odpowiedni poziom informowania interesariuszy i użytkowników o politykach i procedurach dotyczących bezpieczeństwa.

DS5.3 Zarządzanie tożsamością Zapewnić możliwość jednoznacznej identyfikacji wszystkich użytkowników (wewnętrznych, zewnętrznych i tymczasowych) i ich działań w obszarze systemów informatycznych (aplikacje biznesowe, środowisko IT, obsługa, rozwój i utrzymanie systemów). Określić tożsamości użytkowników za pomocą mechanizmów uwierzytelniania. Potwierdzić, że prawa dostępu użytkowników do systemów są zgodnie ze zdefiniowanymi i udokumentowanymi potrzebami biznesowymi oraz że do tożsamości użytkowników dołączone są wymagania ich stanowisk pracy. Zapewnić, aby nadawanie praw dostępu użytkownikom odbywało się na wniosek ich przełożonych, było zatwierdzane przez właścicieli systemów i wdrażane przez osobę świadomą wymagań bezpieczeństwa. Przechowywać dane tożsamości użytkowników i praw dostępu w centralnym repozytorium. Wdrożyć opłacalne rozwiązania techniczne i proceduralne oraz utrzymywać ich aktualność, aby umożliwiać identyfikację, uwierzytelnianie i egzekwowanie praw dostępu użytkowników.

DS5.4 Zarządzanie kontami użytkowników Uregulować kwestie wnioskowania, ustanawiania, wydawania, zawieszania, modyfikacji i zamykania kont oraz powiązanych uprawnień użytkowników w ramach zbioru procedur zarządzania kontami użytkowników. Uwzględnić procedurę zatwierdzania przewidującą przyznawanie uprawnień dostępu przez właściciela danych lub systemu. Procedury te, uwzględniające standardowe i awaryjne przypadki, powinny dotyczyć wszystkich użytkowników (wewnętrznych i zewnętrznych), w tym również administratorów (użytkownicy uprzywilejowani). W przypadku wszystkich typów użytkowników prawa i obowiązki dotyczące dostępu do systemów i zasobów informacyjnych przedsiębiorstwa powinny być określone w umowach. Należy dokonywać regularnego przeglądu kierowniczego wszystkich kont i związanych z nimi uprawnień.

DS5.5 Testowanie, nadzorowanie i monitorowanie bezpieczeństwa W aktywny sposób testować i monitorować wdrożenie rozwiązań w dziedzinie bezpieczeństwa IT. Bezpieczeństwo IT powinno podlegać terminowej weryfikacji, aby zapewnić, że zachowywany jest zatwierdzony bazowy stan bezpieczeństwa zasobów informacyjnych przedsiębiorstwa. Funkcje rejestracji i monitorowania powinny umożliwiać wczesne przeciwdziałanie i/lub wykrywanie oraz terminowe raportowanie nietypowych i/lub niewłaściwych czynności, które mogą wymagać interwencji.

DS5.6 Definicja incydentu związanego z bezpieczeństwem Jasno zdefiniować i rozpowszechnić informacje o charakterystyce potencjalnych incydentów związanych z bezpieczeństwem, tak aby można było je prawidłowo klasyfikować i uwzględniać w procesie zarządzania problemami i incydentami.

DS5.7 ochrona technologii zabezpieczeń Zapewnić, aby technologia bezpieczeństwa była odporna na ingerencje i nie ujawniać bez potrzeby dokumentacji dotyczącej bezpieczeństwa.

DS5.8 Zarządzanie kluczami kryptograficznymi Określić politykę i procedury dotyczące generowania, zmiany, unieważniania, niszczenia, dystrybucji, poświadczania, przechowywania, wprowadzania, użycia i archiwizacji kluczy kryptograficznych, aby zapewnić ich ochronę przed modyfikacją i nieuprawnionym ujawnieniem.

DS5.9 ochrona przed złośliwym oprogramowaniem, jego wykrywanie i wprowadzanie poprawek Wprowadzić w całej organizacji rozwiązania prewencyjne, umożliwiające wykrywanie zagrożeń i wprowadzanie poprawek (zwłaszcza aktualnych poprawek do zabezpieczeń i mechanizmów kontroli antywirusowej) w celu zapewnienia ochrony systemów i technologii informatycznych przed złośliwym oprogramowaniem (wirusami, robakami, oprogramowaniem szpiegującym, niechcianą pocztą itp.).

DS5.10 Bezpieczeństwo sieciowe Stosować techniki zabezpieczeń i odpowiednie procedury zarządzania (np. zapory ogniowe, urządzenia zabezpieczające, segmentację sieci, wykrywanie włamań) w celu autoryzacji dostępu i kontrolowania przepływu informacji z i do sieci.

DS5.11 Wymiana wrażliwych danych Wymieniać wrażliwe dane transakcyjne wyłącznie przy użyciu bezpiecznych ścieżek lub nośników i odpowiednich mechanizmów kontrolnych, aby zapewnić autentyczność zawartości, dowód dostarczenia, dowód odbioru i niezaprzeczalność pochodzenia.

cele konTrolne

Dostarczanie i wsparcieZapewnianie bezpieczeństwa systemówDS5



Cele i mierniki

Źródło Elementy wejściowePO2 Architekturainformacji;klasyfikacje

przypisanychdanychPO3 Standardytechnologiczne PO9 Ocena ryzykaAI2 Specyfikacjakontrolnychmechanizmów

bezpieczeństwaaplikacji DS1 Umowy OLA

Elementy wyjściowe PrzeznaczenieDefinicjaincydentuzwiązanegozbezpieczeństwem DS8Określonewymaganiaszkoleniowedotyczące świadomościbezpieczeństwa DS7Sprawozdaniadotyczącewydajnościprocesu ME1Wymaganezmianywzakresiebezpieczeństwa AI6Zagrożeniabezpieczeństwaipodatnośćna PO9 zagrożeniaPlanipolitykizapewnieniabezpieczeństwaIT DS11

• Częstotliwość weryfikacji rodzajów zdarzeń dotyczących bezpieczeństwa, podlegających monitorowaniu

• Liczba i rodzaj przestarzałych kont• Liczba odrzuconych nieautoryzowanych

adresów IP, portów i rodzajów ruchu• Procent złamanych i unieważnionych

kluczy kryptograficznych• Liczba przyznanych, unieważnionych,

przywróconych lub zmienionych praw dostępu

• Liczba incydentów mających wpływ na działalność biznesową

• Liczba systemów, które nie spełniają wymagań dotyczących bezpieczeństwa

• Czas potrzebny na przyznanie, zmianę i wycofanie uprawnień dostępu

• Liczba i rodzaj przypuszczalnych i rzeczywistych naruszeń zasad dostępu

• Liczba naruszeń zasady rozdziału obowiązków

• Procent użytkowników, którzy nie przestrzegają standardów ustanawiania haseł

• Liczba i rodzaj wykrytych i zablokowanych złośliwych kodów

Czynności• Zrozumienie wymagań, zagrożeń

i podatności na zagrożenia bezpieczeństwa

• Zarządzanie tożsamościami i uprawnieniami użytkowników w ustandaryzowany sposób

• Definiowanie incydentów związanych z bezpieczeństwem

• Regularne testowanie bezpieczeństwa

IT• Zapewnić, aby nieuprawnione osoby nie

miały dostępu do kluczowych i poufnych informacji.

• Zapewnić, aby można było polegać na zautomatyzowanych transakcjach biznesowych i procesach wymiany informacji.

• Zachować integralność informacji i infrastruktury przetwarzania.

• Inwentaryzować i chronić wszystkie zasoby IT.

• Zapewnić, aby usługi i infrastruktura IT były zdolne oprzeć się i powrócić do działania po awariach na skutek błędu, celowego ataku lub katastrofy.

Proces• Umożliwiać dostęp do krytycznych

i wrażliwych danych wyłącznie uprawnionym osobom.

• Rozpoznawać, monitorować i raportować zagrożenia i incydenty związane z bezpieczeństwem.

• Wykrywać i rozwiązywać problemy związane z nieuprawnionym dostępem do informacji, aplikacji i infrastruktury.

• Ograniczyć do minimum wpływ zagrożeń i incydentów związanych z bezpieczeństwem.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Zdefiniowanie i utrzymywanie planu zapewnienia bezpieczeństwa IT. I C C A C C C C I I RZdefiniowanie, ustanowienie i obsługiwanie procesu zarządzania tożsamościami (kontami). I A C R R I CMonitorowanie potencjalnych i rzeczywistych incydentów związanych z bezpieczeństwem. A I R C C ROkresowe przeglądy i walidacja praw dostępu i przywilejów użytkowników. I A C RUstanowienie i utrzymywanie procedur dotyczących utrzymywania i zabezpieczania kluczy kryptograficznych. A R I CWdrożenie i utrzymywanie technicznych i proceduralnych mechanizmów kontrolnych w celu ochrony przepływów informacji pomiędzy sieciami. A C C R R CPrzeprowadzanie okresowych ocen podatności. I A I C C C R



Dostarczanie i wsparcieZapewnianie bezpieczeństwa systemów DS5


Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zapewnianie bezpieczeństwa systemów”, który spełnia wymaganie biznesowe wobec IT dotyczące zachowania integralności informacji i infrastruktury przetwarzającej oraz ograniczenia do minimum wpływu zagrożeń bezpieczeństwa i incydentów, jest:

0 Nieistniejące gdyOrganizacja nie dostrzega potrzeby zapewnienia bezpieczeństwa IT. Nie jest określony zakres odpowiedzialności ani rozliczalności za zapewnienie bezpieczeństwa. Nie są wdrożone metody pomiaru wspierające zarządzanie bezpieczeństwem IT. Nie ma sprawozdawczości dotyczącej bezpieczeństwa IT ani procesów reagowania w sytuacjach naruszenia bezpieczeństwa IT. Zupełnie nie występuje rozpoznawalny proces administrowania bezpieczeństwem systemów.

1 Początkowe/doraźne gdyOrganizacja dostrzega potrzebę zapewnienia bezpieczeństwa IT. Świadomość potrzeby zapewnienia bezpieczeństwa zależy głównie od pojedynczych osób. Bezpieczeństwo IT jest zapewniane na doraźnych zasadach. Bezpieczeństwo IT nie podlega pomiarowi. Wykryte przypadki naruszenia bezpieczeństwa IT wywołują reakcje typu „szukanie winnego”, ponieważ nie jest jasno określony zakres odpowiedzialności. Reakcje na przypadki naruszenia bezpieczeństwa IT są nieprzewidywalne.

2 Powtarzalne lecz intuicyjne gdyOdpowiedzialność za bezpieczeństwo IT spoczywa na koordynatorze ds. bezpieczeństwa IT, jednak jego uprawnienia do zarządzania są ograniczone. Świadomość potrzeby zapewnienia bezpieczeństwa jest fragmentaryczna i ograniczona. Chociaż systemy dostarczają informacji dotyczących bezpieczeństwa, nie są one analizowane. Usługi świadczone przez strony trzecie mogą nie spełniać określonych potrzeb organizacji dotyczących bezpieczeństwa. Rozwijana jest polityka dotycząca bezpieczeństwa, ale nie towarzyszą jej adekwatne umiejętności i narzędzia. Sprawozdawczość dotycząca bezpieczeństwa IT jest niekompletna, nierzetelna lub nietrafna. Dostępne są szkolenia z dziedziny bezpieczeństwa, są one jednak głównie realizowane z inicjatywy pojedynczych osób. Bezpieczeństwo IT jest postrzegane głównie jako przedmiot odpowiedzialności i domena działu IT, a nie domena obszaru biznesowego.

3 Zdefiniowane gdyIstnieje świadomość zagrożeń i zasad bezpieczeństwa i jest ona promowana przez kierownictwo. Zdefiniowane są procedury bezpieczeństwa, które są zgodne z polityką bezpieczeństwa IT. Określone i znane są zakresy odpowiedzialności za bezpieczeństwo IT, nie są one jednak konsekwentnie egzekwowane. Istnieje plan zapewnienia bezpieczeństwa IT i rozwiązania w tej dziedzinie opierające się na analizie ryzyka. Sprawozdawczość w dziedzinie bezpieczeństwa nie ma wyraźnego odniesienia do działalności biznesowej. Przeprowadzane są doraźne testy bezpieczeństwa (np. testowanie możliwości włamania). Dostępne są szkolenia z dziedziny bezpieczeństwa dla pracowników działu IT i zajmujących się działalnością biznesową, jednak ich planowanie i zarządzanie nimi ma nieformalny charakter.

4 Kontrolowane i mierzalne gdyOdpowiedzialność za bezpieczeństwo IT jest wyraźnie określona, egzekwowana i podlega zarządzaniu. W konsekwentny sposób dokonuje się analizy ryzyka naruszenia bezpieczeństwa IT i analizy skutków. Polityka i procedury bezpieczeństwa są uzupełniane przez określone wymagania bazowe dotyczące bezpieczeństwa. Obowiązkowe jest stosowanie metod promujących świadomość potrzeby zapewnienia bezpieczeństwa. Ustandaryzowane są procedury identyfikacji, uwierzytelniania i autoryzacji. Od pracowników odpowiedzialnych za audyt i zarządzanie bezpieczeństwem wymaga się uzyskania certyfikatów bezpieczeństwa. Testy bezpieczeństwa wykonuje się przy użyciu standardowych i sformalizowanych procesów, co prowadzi do podnoszenia poziomu bezpieczeństwa. Procesy zapewnienia bezpieczeństwa IT są skoordynowane z ogólną funkcją bezpieczeństwa organizacji. Sprawozdawczość dotycząca bezpieczeństwa IT jest powiązana z celami biznesowymi. Szkoleniem w dziedzinie bezpieczeństwa IT objęte są zarówno dział biznesowy, jak i dział IT. Szkolenia z dziedziny bezpieczeństwa IT są planowane i podlegają zarządzaniu w sposób odpowiadający potrzebom biznesowym i zdefiniowanym profilom ryzyka. Zdefiniowano cele i mierniki zarządzania bezpieczeństwem, ale nie dokonuje się jeszcze pomiarów.

5 Zoptymalizowane gdyBezpieczeństwo IT należy do wspólnego zakresu odpowiedzialności zarządzających działalnością biznesową i działalnością IT oraz jest zintegrowane z celami biznesowymi dotyczącymi bezpieczeństwa korporacyjnego. Wymagania dotyczące bezpieczeństwa IT są wyraźnie zdefiniowane, zoptymalizowane i uwzględnione w zatwierdzonym planie bezpieczeństwa. Użytkownicy i klienci są w coraz większym stopniu odpowiedzialni za definiowanie wymagań dotyczących bezpieczeństwa, a funkcje związane z zapewnieniem bezpieczeństwa są wbudowywane w aplikacje na etapie ich projektowania. Incydenty związane z bezpieczeństwem spotykają się z szybkim przeciwdziałaniem dzięki sformalizowanym procedurom reagowania na incydenty wspieranym przez zautomatyzowane narzędzia. Okresowo przeprowadza się oceny bezpieczeństwa, a tym samym efektywności wdrożenia planu zapewnienia bezpieczeństwa. Systematycznie gromadzone i analizowane są informacje dotyczące zagrożeń i podatności na zagrożenia. W odpowiedni sposób wdraża się i informuje o mechanizmach kontrolnych służących zmniejszeniu ryzyka. W celu ciągłego doskonalenia procesu stosuje się testy bezpieczeństwa, analizę przyczyny podstawowej incydentów związanych z bezpieczeństwem oraz aktywne podejście do rozpoznawania ryzyka. Procesy i technologie związane z zapewnieniem bezpieczeństwa są zintegrowane na poziomie ogólnoorganizacyjnym. Mierniki zarządzania bezpieczeństwem podlegają pomiarowi, gromadzeniu i komunikacji. Na ich podstawie, w ramach procesu ciągłego doskonalenia, kierownictwo odpowiednio modyfikuje plan zapewnienia bezpieczeństwa.

Model dojrzałości

Dostarczanie i wsparcieZapewnianie bezpieczeństwa systemówDS5


oPis Procesu


Identyfikowanie i rozliczanie kosztów,


dotyczące zapewnienia przejrzystości i zrozumienia kosztów IT oraz poprawy opłacalności dzięki świadomemu wykorzystaniu usług IT


pełnym i dokładnym rejestrowaniu kosztów IT, rzetelnym systemie rozliczeń uzgodnionym z użytkownikami biznesowymi oraz systemie terminowego raportowania dotyczącego wykorzystania usług IT i alokacji kosztów,


• dostosowanie opłat do jakości i ilości świadczonych usług; • stworzenie i uzgodnienie pełnego modelu kosztów; • wprowadzenie opłat zgodnie z uzgodnioną polityką


• procent rachunków za usługi IT przyjętych/zapłaconych przez kierujących działalnością biznesową;

• procentowe rozbieżności między budżetami, prognozami a rzeczywistymi kosztami;

• procent całkowitych kosztów IT, które są rozliczane zgodnie z przyjętymi modelami kosztów.





Ds6 identyfikowanie i rozliczanie kosztów

Potrzeba funkcjonowania rzetelnego i sprawiedliwego systemu rozliczania kosztów IT na rzecz obszaru biznesowego wymaga ich dokładnego pomiaru i porozumienia z użytkownikami biznesowymi, co zapewnia rzetelność rozliczeń. Proces ten obejmuje stworzenie i wykorzystywanie systemu, który umożliwia rejestrowanie, alokowanie i raportowanie kosztów IT w odniesieniu do poszczególnych użytkowników usług. Rzetelny system rozliczeniowy umożliwia obszarowi biznesowemu podejmowanie bardziej świadomych decyzji dotyczących wykorzystania usług IT.

PP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieIdentyfikowanie i rozliczanie kosztów DS6



DS6.1 Definicje usług Zidentyfikować wszystkie koszty IT i przyporządkować je do usług IT w celu stworzenia przejrzystego modelu kosztów. Usługi IT powinny być powiązane z procesami biznesowymi, tak aby strona biznesowa mogła określić związane z nimi poziomy opłat za usługi.

DS6.2 Księgowość IT Rejestrować i rozliczać rzeczywiste koszty zgodnie z modelem kosztów przedsiębiorstwa. Rozbieżności między prognozami a rzeczywistymi kosztami powinny być przedmiotem analizy i raportowania zgodnie z systemami pomiaru finansowego przedsiębiorstwa.

DS6.3 Modelowanie i naliczanie kosztów Wprowadzić i stosować model rozliczania kosztów IT oparty na definicjach usług, który umożliwia obliczanie stawek rozliczeniowych za poszczególne usługi. Model kosztów IT powinien zapewniać, aby naliczanie opłat za usługi było możliwe do określenia, mierzalne i przewidywalne dla użytkowników, a tym samym zachęcające ich do prawidłowego korzystania z zasobów.

DS6.4 Utrzymywanie modelu kosztów Regularnie dokonywać przeglądu i oceny porównawczej modelu kosztów/rozliczeń, aby był on adekwatny i odpowiedni do ewoluującej działalności biznesowej i IT.

cele konTrolne

Dostarczanie i wsparcieIdentyfikowanie i rozliczanie kosztówDS6



Cele i mierniki

PO4 UdokumentowaniwłaścicielesystemówPO5 Sprawozdaniadotyczącekosztówikorzyści,

budżetyITPO10 Szczegółoweplanyprojektów DS1 Umowy SLA i OLA

FinanseIT PO5Sprawozdaniadotyczącewydajnościprocesu ME1

• Procent użytkowników biznesowych zaangażowanych w definiowanie modeli kosztów

• Częstotliwość weryfikacji modelu alokacji kosztów

• Procent kosztów, które są rozliczane automatycznie/ręcznie

• Procent rachunków za usługi IT przyjętych/zapłaconych przez kierujących działalnością biznesową

• Koszt jednostkowy usługi w czasie• Wartość procentowa zadowolenia działu

biznesowego (ankieta) z modelu kosztów usług IT

• Procentowe rozbieżności między budżetami, prognozami i rzeczywistymi kosztami

• Procent całkowitych kosztów IT, które są rozliczane zgodnie z przyjętymi modelami kosztów

• Procent kosztów kwestionowanych przez stronę biznesową

Czynności• Weryfikacja rozliczonych kosztów przez

kierujących działalnością biznesową• Dostosowanie opłat do jakości

świadczonych usług• Stworzenie i uzgodnienie pełnego modelu

kosztów• Wprowadzenie opłat zgodnie

z uzgodnioną polityką• Regularna analiza porównawcza kosztów

IT• Zapewniać przejrzystość i zrozumiałość

kosztów, korzyści, strategii, polityki i poziomów usług IT.

• Zwiększać efektywność kosztową IT i jej wkład w zapewnienie rentowności działalności biznesowej.


Proces• Zdefiniować w rzetelny i sprawiedliwy

sposób koszty i usługi IT.• Dokładnie rejestrować koszty usług IT.• Rzetelnie i sprawiedliwie rozdzielać

koszty IT między odbiorców usług IT.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Przyporządkowanie infrastruktury IT do świadczonych usług/wspieranych procesów biznesowych. C C A C C C C R CZidentyfikowanie wszystkich kosztów IT (np. dotyczących osób, technologii) i przyporządkowanie ich do usług IT według kosztu jednostkowego. C A C C C R C Ustanowienie i utrzymywanie procesu dotyczącego księgowości i kontroli kosztów IT. C C A C C C C R CUstanowienie i utrzymywanie polityk i procedur dotyczących pobierania opłat. C C A C C C C R C



Dostarczanie i wsparcieIdentyfikowanie i rozliczanie kosztów DS6



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Identyfikowanie i rozliczanie kosztów”, który spełnia wymaganie biznesowe wobec IT dotyczące zapewnienia przejrzystości i zrozumienia kosztów IT oraz poprawy opłacalności dzięki świadomemu wykorzystaniu usług IT, jest:

0 Nieistniejące gdyNie istnieje żaden rozpoznawalny proces służący identyfikacji i rozliczaniu kosztów świadczonych usług informatycznych. Organizacja nie dostrzega nawet potrzeby zajęcia się kwestią rozliczania kosztów i nie istnieje żadna wymiana informacji na ten temat.

1 Początkowe/doraźne gdyWystępuje ogólne zrozumienie kwestii kosztów usług informatycznych, nie ma jednak rozbicia kosztów na użytkownika, klienta, dział, grupę użytkowników, funkcje usług, projekty czy rezultaty. Praktycznie nie istnieje monitoring kosztów – kierownictwo otrzymuje wyłącznie raporty dotyczące ich łącznej wartości. Koszty IT są rozliczane jako ogólne koszty operacyjne. Strona biznesowa nie otrzymuje informacji o kosztach ani korzyściach wynikających ze świadczonych usług.

2 Powtarzalne lecz intuicyjne gdyIstnieje ogólna świadomość potrzeby identyfikacji i rozliczania kosztów. Rozliczanie kosztów opiera się na nieformalnych lub podstawowych założeniach (np. dotyczących kosztów sprzętu) i praktycznie nie ma powiązania z nośnikami wartości. Procesy rozliczania kosztów są powtarzalne. Nie ma formalnych szkoleń ani komunikacji dotyczącej standardowych procedur identyfikacji i rozliczania kosztów. Nie jest określona odpowiedzialność za gromadzenie informacji o kosztach lub za ich rozliczanie.

3 Zdefiniowane gdyIstnieje zdefiniowany i udokumentowany model kosztów usług informatycznych. Zdefiniowany jest proces umożliwiający powiązanie kosztów IT z usługami dostarczanymi użytkownikom. Istnieje odpowiedni poziom świadomości dotyczący kosztów powiązanych z usługami informatycznymi. Strona biznesowa otrzymuje podstawowe informacje dotyczące kosztów.

4 Kontrolowane i mierzalne gdyOdpowiedzialność i rozliczalność związana z zarządzaniem kosztami usług informatycznych jest zdefiniowana i w pełni zrozumiała na wszystkich poziomach oraz wspierana poprzez formalne szkolenia. Identyfikacja i raportowanie bezpośrednich i pośrednich kosztów odbywa się w terminowy i zautomatyzowany sposób, a informacje są przekazywane kadrze zarządzającej, właścicielom procesów biznesowych oraz użytkownikom. Ogólnie rzecz biorąc, monitoruje i ocenia się koszty, a w przypadku wykrycia odchyleń podejmowane są odpowiednie działania. Raportowanie kosztów usług informatycznych jest powiązane z celami biznesowymi i umowami SLA oraz monitorowane przez właścicieli procesów biznesowych. Dział finansów weryfikuje zasadność procesu rozliczania kosztów. Istnieje zautomatyzowany system księgowania kosztów, jest on jednak bardziej zorientowany na funkcję usług informatycznych niż na procesy biznesowe. Uzgodnione są cele i mierniki na potrzeby pomiaru kosztów, jednak nie podlegają konsekwentnemu pomiarowi.

5 Zoptymalizowane gdyKoszty świadczonych usług podlegają identyfikacji, rejestracji, sumowaniu i raportowaniu, a informacje są przekazywane kierownictwu, właścicielom procesów biznesowych i użytkownikom. Koszty są identyfikowane jako jednostki rozliczeniowe i mogą trafiać do systemu rozliczeniowego, który w odpowiedni sposób, w oparciu o dane wykorzystania, obciąża użytkowników za dostarczone usługi. Szczegółowe dane dotyczące kosztów wspierają wykonanie umów SLA. Monitoring i ocena kosztów usług są wykorzystywane do optymalizacji kosztów zasobów IT. Uzyskane dane liczbowe są wykorzystywane do weryfikacji osiąganych korzyści w procesie planowania budżetu organizacji. Raportowanie kosztów usług informatycznych przez inteligentne systemy raportowania umożliwia wczesne ostrzeganie o zmieniających się wymaganiach biznesowych. Wykorzystywany jest model zmiennych kosztów będących pochodną ilości przetwarzanych danych dla każdej z dostarczanych usług. W oparciu o analizę porównawczą i ciągłe doskonalenie zarządzanie kosztami zostało udoskonalone do poziomu praktyki branżowej. Optymalizacja kosztów jest trwałym procesem. Kierownictwo weryfikuje cele i mierniki w ramach procesu ciągłego doskonalenia systemów pomiaru kosztów.

Model dojrzałości

Dostarczanie i wsparcieIdentyfikowanie i rozliczanie kosztówDS6


oPis Procesu


Kształcenie i szkolenie użytkowników,


dotyczące efektywnego i wydajnego korzystania z aplikacji i rozwiązań technicznych oraz zapewnienia zgodności działań użytkowników z politykami i procedurami


dokładnym zrozumieniu potrzeb szkoleniowych użytkowników systemów IT, realizacji efektywnej strategii szkoleniowej oraz pomiarze efektów,


• stworzenie programu szkoleń; • organizację szkoleń; • realizację szkoleń; • monitorowanie i sporządzanie sprawozdań dotyczących efektywności szkoleń


• liczbę zgłoszeń do jednostki Service Desk związanych z brakiem szkoleń użytkowników;

• procentowy poziom zadowolenia interesariuszy z zapewnianych szkoleń;

• odstęp czasu między zidentyfikowaniem potrzeby szkoleniowej a przeprowadzeniem szkolenia.





Ds7 kształcenie i szkolenie użytkowników

Skuteczne kształcenie wszystkich użytkowników systemów IT, w tym również pracowników działu IT, wymaga identyfikacji potrzeb szkoleniowych poszczególnych grup użytkowników. Oprócz identyfikacji potrzeb proces ten obejmuje również określenie i realizację strategii efektywnego szkolenia oraz pomiar wyników. Efektywny program szkolenia zapewnia zwiększenie efektywności wykorzystania technologii poprzez zmniejszenie liczby błędów użytkowników, zwiększenie wydajności, a także zgodności z najważniejszymi mechanizmami kontrolnymi (np. rozwiązaniami w dziedzinie bezpieczeństwa użytkowania).

SP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI


ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieKształcenie i szkolenie użytkowników DS7



DS7.1 Rozpoznanie potrzeb edukacyjnych i szkoleniowych Wprowadzić i regularnie aktualizować program szkoleń dla poszczególnych grup docelowych pracowników, uwzględniając:• aktualne i przyszłe potrzeby biznesowe oraz strategię;• wartość informacji jako zasobu;• wartości korporacyjne (wartości etyczne, kulturę kontroli i bezpieczeństwa itp.);• wdrożenie nowej infrastruktury IT i oprogramowania (tj. pakietów, aplikacji);• aktualne i przyszłe umiejętności, profile kompetencji oraz potrzeby dotyczące certyfikacji i/lub poświadczania kwalifikacji, a także

ponownego uzyskania uprawnień;• metody realizacji (np. szkolenia stacjonarne, internetowe), wielkość grupy docelowej, dostępność i czas.

DS7.2 Realizacja szkoleń i potrzeb edukacyjnych W oparciu o rozpoznane potrzeby edukacyjne i szkoleniowe określić grupy docelowe i ich uczestników, efektywne mechanizmy dostarczania, wykładowców, specjalistów ds. szkoleń i mentorów. Wyznaczyć specjalistów ds. szkoleń i zorganizować odbywające się terminowo sesje szkoleniowe. Rejestrować zapisy (uwzględniając warunki wstępne), obecności oraz oceny uczestnictwa w sesjach szkoleniowych.

DS7.3 ocena przeprowadzonych szkoleń Po zakończeniu szkolenia ocenić zawartość edukacyjną i szkoleniową pod kątem istotności, jakości, efektywności, przyswojenia wiedzy, kosztów oraz wartości. Wyniki oceny powinny służyć jako dane wejściowe do tworzenia programu przyszłych szkoleń i realizacji sesji szkoleniowych.

cele konTrolne

Dostarczanie i wsparcieKształcenie i szkolenie użytkownikówDS7



Cele i mierniki

PO7 Umiejętnościikompetencjeużytkowników,włączającindywidualneszkolenia;specjalnewymagania szkoleniowe

AI4 Materiałyszkoleniowe,wymaganiadotyczą-cewdrożeniarozwiązańzwiązaneztransfe-remwiedzy

DS1 Umowy OLADS5 Specjalnewymaganiaszkoleniowedotyczą-

ceświadomościzagrożeńizasadbezpie-czeństwa

DS8 Sprawozdaniadotyczącezadowoleniaużyt-kowników

Sprawozdaniadotyczącewydajnościprocesu ME1Wymaganeaktualizacjedokumentacji AI4

• Częstotliwość aktualizacji programu szkoleń

• Odstęp czasu między zidentyfikowaniem potrzeby szkoleniowej a przeprowadzeniem szkolenia

• Wzrost wydajności pracowników będący efektem lepszej znajomości systemów

• Procentowy wzrost zadowolenia użytkowników z wdrożenia usług, systemów lub nowych technologii

• Liczba zgłoszeń do jednostki Service Desk w sprawie szkoleń lub z prośbą o odpowiedź na pytanie

• Procentowy poziom zadowolenia interesariuszy z zapewnianych szkoleń

• Procent przeszkolonych pracowników

Czynności• Stworzenie programu szkoleń • Organizacja szkoleń• Realizacja szkoleń• Monitorowanie i sporządzanie

sprawozdań dotyczących efektywności szkoleń


zadowoleni z oferty i poziomu usług.• Zapewnić prawidłowe wykorzystanie

i wydajość aplikacji oraz stosowanych rozwiązań technicznych.

• Zoptymalizować infrastrukturę, zasoby i potencjał IT.

Proces• Wprowadzić program szkoleń dla

użytkowników na wszystkich poziomach z wykorzystaniem najbardziej opłacalnych metod.

• Przekazać wiedzę użytkownikom aplikacji i rozwiązań technicznych.

• Zwiększyć świadomość ryzyka i odpowiedzialności wiążącej się z użytkowaniem aplikacji i rozwiązań technicznych.

Czynności


rekto

r gen

eraln

y (CE

O)Dy

rekto

r ds.

finan

sowy

ch (C

FO)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

oju

Dział

szko

leń

Kier

ownik

ds. a

dmini

strac

ji IT

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Identyfikacja i charakterystyka potrzeb szkoleniowych użytkowników. C A R C C C C C C ROpracowanie programu szkoleń. C A R C I C C C I RProwadzenie działań dotyczących świadomości, edukacji i szkoleń. I A C C I C C C I RPrzeprowadzanie oceny szkoleń. I A R C I C C C I RIdentyfikacja i ocena najlepszych metod i narzędzi prowadzenia szkoleń. I A/R R C C C C C C R Tabela RACI wskazuje osoby odpowiedzialne (ang. Responsible), rozliczane (Accountable), konsultujące (Consulted) i informowane (Informed).


Dostarczanie i wsparcieKształcenie i szkolenie użytkowników DS7



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Kształcenie i szkolenieużytkowników”, który spełnia wymaganie biznesowe wobec IT dotyczące efektywnego i wydajnego korzystania z aplikacji i rozwiązań technicznych oraz zapewnienia zgodności działań użytkowników z polityką i procedurami, jest:

0 Nieistniejące gdyW ogóle nie istnieje program szkolenia i kształcenia. Organizacja nie dostrzega nawet potrzeby zajęcia się kwestią szkoleń i nie istnieje żadna wymiana informacji na ten temat.

1 Początkowe/doraźne gdySą oznaki, że organizacja dostrzega potrzebę istnienia programu szkolenia i kształcenia, jednak nie istnieją żadne ustandaryzowane procesy. Wobec braku programu pracownicy samodzielnie określają własne potrzeby i uczestniczą w kursach szkoleniowych. Niektóre z tych szkoleń dotyczą kwestii etycznego postępowania, świadomości zagrożeń i zasad bezpieczeństwa systemów oraz praktyk dotyczących bezpieczeństwa. Ogólnemu podejściu kierownictwa brakuje spójności i występuje tylko sporadyczna i niekonsekwentna wymiana informacji dotyczących problemów i podejścia do zagadnienia szkolenia i kształcenia.

2 Powtarzalne lecz intuicyjne gdyW całej organizacji istnieje świadomość potrzeby istnienia programu szkolenia i kształcenia oraz powiązanych z nim procesów. Szkolenie zaczyna być uwzględniane w indywidualnych planach pracy pracowników. Procesy są rozwinięte do poziomu, na którym odbywają się nieformalne szkolenia, a grupy szkoleniowe są prowadzone przez różnych instruktorów, przy czym do tych samych zagadnień stosowane są różne podejścia. Niektóre z cykli szkoleń dotyczą kwestii etycznego postępowania, świadomości zagrożeń i zasad bezpieczeństwa systemów oraz praktyk dotyczących bezpieczeństwa. W wysokim stopniu polega się na wiedzy pojedynczych osób. Odbywa się jednak stała wymiana informacji dotyczących ogólnych problemów oraz potrzeby ich rozwiązania.

3 Zdefiniowane gdyIstnieje program szkolenia i kształcenia oraz wymiana informacji na jego temat, a pracownicy i kadra kierownicza określają i dokumentują potrzeby szkoleniowe. Procesy szkolenia i kształcenia są ustandaryzowane i udokumentowane. Realizację programu szkolenia i kształcenia wspierają określone budżety, zasoby, infrastruktura i specjaliści ds. szkoleń. Pracownicy uczestniczą w oficjalnych szkoleniach dotyczących etycznego postępowania oraz świadomości zagrożeń i zasad bezpieczeństwa systemów oraz praktyk dotyczących bezpieczeństwa. Większość procesów związanych ze szkoleniem i kształceniem jest monitorowanych, jednak nie wszystkie odstępstwa są dostrzegane przez kierownictwo. Tylko okazjonalnie analizuje się problemy dotyczące szkolenia i kształcenia.

4 Kontrolowane i mierzalne gdyIstnieje kompleksowy program szkolenia i kształcenia, który przynosi wymierne efekty. Wyraźnie określony jest zakres odpowiedzialności i ustalona jest własność procesu. Szkolenie i kształcenie są elementami ścieżek kariery pracowników. Kierownictwo wspiera szkolenia i uczestniczy w sesjach szkoleniowych. Wszyscy pracownicy przechodzą szkolenie dotyczące etycznego postępowania oraz świadomości zagrożeń i zasad bezpieczeństwa systemów. Wszyscy pracownicy odbywają na odpowiednim poziomie szkolenia dotyczące praktyk zapewnienia bezpieczeństwa systemów w celu ochrony przed skutkami awarii wpływającymi na dostępność, poufność i integralność. Kierownictwo monitoruje zgodność, stale przeglądając (weryfikując) i aktualizując program i procesy szkolenia. Procesy są doskonalone i wymagają stosowania najlepszych wewnętrznych praktyk.

5 Zoptymalizowane gdySzkolenie i kształcenie przynoszą efekt w postaci poprawy indywidualnej wydajności pracowników. Szkolenie i kształcenie są elementami o decydującym znaczeniu dla ścieżek kariery pracowników. Programy szkolenia i kształcenia są wspierane przez odpowiednie budżety, zasoby, infrastrukturę i instruktorów. Procesy są dopracowane i podlegają ciągłemu doskonaleniu z wykorzystaniem najlepszych zewnętrznych praktyk i modelowania dojrzałości z analizą porównawczą względem innych organizacji. Wszystkie problemy i odstępstwa są analizowane pod kątem przyczyn podstawowych i w odpowiedniej chwili podejmowane są skuteczne działania zaradcze. Istnieje pozytywne nastawienie do etycznego postępowania i przestrzegania zasad bezpieczeństwa systemów. Technologie IT są wykorzystywane w szerokim zakresie oraz w zintegrowany i zoptymalizowany sposób w celu automatyzacji i zapewnienia narzędzi do realizacji programu szkolenia i kształcenia. Korzysta się ze wskazówek zewnętrznych ekspertów w dziedzinie szkoleń oraz z analiz porównawczych.

Model dojrzałości

Dostarczanie i wsparcieKształcenie i szkolenie użytkownikówDS7


oPis Procesu


Zarządzanie jednostką Service Desk i incydentami,


dotyczące umożliwienia efektywnego wykorzystania systemów IT poprzez rozwiązywanie i analizę zgłoszeń, pytań i incydentów zgłaszanych przez użytkowników końcowych


profesjonalnej realizacji funkcji Service Desk wyrażającej się w szybkim reagowaniu, przejrzystych procedurach eskalacji oraz analizie rozwiązań i trendów,


• stworzenie i zapewnienie działania jednostki Service Desk; • monitorowanie i raportowanie trendów; • zdefiniowanie przejrzystych kryteriów i procedur eskalacji


• poziom zadowolenia użytkowników z działania pierwszej linii wsparcia;

• procent rozwiązanych incydentów w uzgodnionym/możliwym do zaakceptowania czasie;

• liczbę porzuconych połączeń.





Ds8 zarządzanie jednostką service Desk i incydentami

Terminowe i skuteczne reagowanie na zapytania i problemy użytkowników systemów IT wymaga istnienia dobrze zaprojektowanego i realizowanego procesu zarządzania jednostką Service Desk i incydentami. Proces ten uwzględnia wdrożenie funkcji Service Desk wraz z rejestrowaniem i eskalacją incydentów, analizą trendów i przyczyn źródłowych oraz rozwiązywaniem problemów. Korzyścią biznesową jest m.in. wzrost wydajności dzięki szybkiemu rozwiązywaniu problemów użytkowników. Ponadto dzięki efektywnej sprawozdawczości firma może eliminować przyczyny podstawowe (np. słabe szkolenie użytkowników).

PP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieZarządzanie jednostką Service Desk i incydentami DS8



DS8.1 Service Desk Stworzyć jednostkę Service Desk, która będzie pośredniczyć w kontaktach z działem IT w celu rejestrowania, wymiany informacji, przekazywania i analizy wszystkich zgłoszeń, incydentów, zgłoszeń serwisowych i żądań udzielenia informacji. Ustanowić procedury monitorowania i eskalacji w oparciu o uzgodnione poziomy usług zależne od odpowiednich umów SLA, które umożliwiają klasyfikację i określenie ważności każdego zgłoszonego problemu jako incydentu, zgłoszenia serwisowego lub żądania udzielenia informacji. Mierzyć poziom zadowolenia użytkowników z jakości działania jednostki Service Desk i usług IT.

DS8.2 Rejestrowanie zapytań klientów Wprowadzić funkcję i system umożliwiający rejestrowanie i śledzenie wszystkich zgłoszeń, incydentów, zgłoszeń serwisowych i żądań udzielenia informacji. Powinien on ściśle współpracować z procesami zarządzania incydentami, zarządzania problemami, zarządzania zmianami, zarządzania potencjałem i zarządzania dostępnością. Incydenty powinny być klasyfikowane według ważności procesów biznesowych i usług, a następnie, w razie potrzeby, kierowane do właściwego zespołu zarządzania problemami. Klienci powinni być informowani o statusie swoich zapytań.

DS8.3 Eskalacja incydentów Wdrożyć procedury umożliwiające odpowiednią eskalację incydentów, które nie mogą zostać rozwiązane natychmiast (zgodnie z ograniczeniami umów SLA), a także umożliwiające zastosowanie rozwiązań doraźnych. Zapewnić, aby w przypadku incydentów zgłoszonych przez użytkowników własność i monitorowanie cyklu życia incydentów pozostawały domeną jednostki Service Desk niezależnie od tego, która grupa IT pracuje nad rozwiązaniem.

DS8.4 Zamykanie incydentów Wprowadzić procedury umożliwiające terminowe monitorowanie obsługi zapytań klientów. Zapewnić, aby po rozwiązaniu incydentu jednostka Service Desk zarejestrowała kroki rozwiązania i potwierdzić, że podjęte działania były uzgodnione z użytkownikiem. Rejestrować i raportować także nierozwiązane incydenty (znane błędy i rozwiązania doraźne) w celu zapewnienia niezbędnych informacji do prawidłowego zarządzenia problemami.

DS8.5 Sprawozdawczość i analiza trendów Sporządzać sprawozdania z działalności jednostki Service Desk, aby umożliwić kierownictwu pomiar wydajności usługi i czasu reakcji oraz identyfikację trendów lub powtarzających się problemów w celu ciągłego doskonalenia usługi.

cele konTrolne

Dostarczanie i wsparcieZarządzanie jednostką Service Desk i incydentamiDS8



Cele i mierniki

AI4 Podręczniki:użytkownika,operacyjny,dot.wsparcia,technicznyidot.administracji

AI6 ZatwierdzeniezmianyAI7 Wprowadzoneelementykonfiguracji DS1 Umowy SLA i OLADS4 Progiincydentu/katastrofyDS5 Definicjaincydentuzwiązanegoz

bezpieczeństwemDS9 Szczegółykonfiguracji/zasobówITDS10 Znaneproblemy,błędyirozwiązaniadoraźneDS13 Zgłoszeniaincydentów

Zgłoszeniawnioskuousługę/zmianę(RFC) AI6Sprawozdaniadotycząceincydentów DS10Sprawozdaniadotyczącewydajnościprocesu ME1Sprawozdaniadotyczącezadowoleniaużytkowników DS7 ME1

• Procent incydentów i zgłoszeń serwisowych przekazanych i zarejestrowanych przy użyciu zautomatyzowanych narzędzi

• Liczba dni szkolenia na pracownika jednostki Service Desk rocznie

• Liczba połączeń obsługiwanych przez pracownika jednostki Service Desk na godzinę

• Procent incydentów, które wymagają lokalnego wsparcia (wsparcia w terenie, osobistej wizyty)

• Liczba nierozwiązanych problemów (zapytań)

• Poziom zadowolenia użytkowników z działania pierwszej linii wsparcia (jednostki Service Desk lub bazy wiedzy)

• Procent incydentów rozwiązanych w uzgodnionym/możliwym do zaakceptowania czasie

• Procent rozwiązań na pierwszej linii w odniesieniu do łącznej liczby zgłoszeń

• Procent ponownie otwartych incydentów• Liczba porzuconych połączeń • Średni czas trwania incydentów zależnie

od ich ważności• Średni czas odpowiedzi na zgłoszenie

telefoniczne oraz za pośrednictwem poczty e-mail lub Internetu.

Czynności• Stworzenie i zapewnienie działania

jednostki Service Desk• Monitorowanie i raportowanie trendów• Dostosowanie priorytetów rozwiązywania

incydentów do wymagań biznesowych• Zdefiniowanie przejrzystych kryteriów

i procedur eskalacji


zadowoleni z oferty i poziomu usług.• Zapewnić prawidłowe wykorzystanie

i wydajość aplikacji oraz stosowanych rozwiązań technicznych

• Zapewnić dostępność usług IT adekwatnie do potrzeb.

Proces• Analizować, dokumentować i eskalować

incydenty w terminowy sposób.• Odpowiadać na zapytania w precyzyjny

i terminowy sposób.• Regularnie analizować trendy incydentów

i zapytań.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Kier

ownik

ds. S

ervic

e Des

k/

incyd

entó

w

Opracowanie procedur klasyfikacji (ścisłość i wpływ) i eskalacji (funkcjonalnych i hierarchicznych). C C C C C C C A/RWykrywanie i rejestrowanie incydentów/zgłoszeń/zapytań o usługi/informacje. A/R Klasyfikowanie, badanie i diagnozowanie zapytań. I C C C I A/RRozwiązywanie, przywracanie do normalnego stanu i zamykanie incydentów. I R R R C A/R Informowanie użytkowników (np. o aktualizacji statusów). I I A/RTworzenie sprawozdawczości zarządczej. I I I I I I A/R



Dostarczanie i wsparcieZarządzanie jednostką Service Desk i incydentami DS8



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie jednostką Service Desk i incydentami”, który spełnia wymaganie biznesowe wobec IT dotyczące umożliwienia efektywnego wykorzystania systemów IT poprzez rozwiązywanie i analizę zgłoszeń, pytań i incydentów zgłaszanych przez użytkowników końcowych, jest:

0 Nieistniejące gdyNie ma wsparcia umożliwiającego uzyskiwanie odpowiedzi i rozwiązywanie problemów użytkowników. W ogóle nie istnieje proces zarządzania incydentami. Organizacja nie dostrzega istnienia problemu, który wymaga rozwiązania.

1 Początkowe/doraźne gdyKierownictwo zdaje sobie sprawę z potrzeby istnienia procesu wspieranego przez narzędzia i personel, umożliwiającego udzielanie odpowiedzi na zapytania użytkowników i zarządzanie rozwiązywaniem incydentów. Nie istnieje jednak ustandaryzowany proces i zapewniane jest tylko doraźne wsparcie. Kierownictwo nie monitoruje zapytań użytkowników, incydentów ani trendów. Nie istnieje proces eskalacji zapewniający rozwiązywanie problemów.

2 Powtarzalne lecz intuicyjne gdyIstnieje organizacyjna świadomość potrzeby funkcji Service Desk oraz procesu zarządzania incydentami. Pomoc jest udzielana na nieformalnych zasadach przez grupę kompetentnych osób. Osoby te mają do dyspozycji pewne wspólne narzędzia pomocne w rozwiązywaniu incydentów. Nie ma formalnych szkoleń ani komunikacji dotyczącej standardowych procedur, a odpowiedzialność jest pozostawiona indywidualnemu uznaniu.

3 Zdefiniowane gdyPotrzeba obecności funkcji Service Desk i procesu zarządzania incydentami jest dostrzeżona i zaakceptowana. Procedury są ustandaryzowane i udokumentowane, a nieformalne szkolenia mają miejsce. Kwestia szkolenia i przestrzegania standardów jest jednak pozostawiona indywidualnemu uznaniu. Opracowane są odpowiedzi na często zadawane pytania (FAQ) oraz wskazówki dla użytkowników, jednak użytkownicy muszą je sami odnaleźć i mogą ich nie przestrzegać. Zapytania i incydenty są śledzone w sposób niezautomatyzowany i indywidualnie monitorowane, nie istnieje jednak formalny system sprawozdawczości. Nie weryfikuje się terminowości odpowiedzi na zapytania i incydenty, więc niektóre z nich mogą pozostać nierozwiązane. Użytkownicy otrzymali przejrzyste informacje, gdzie i w jaki sposób powinni informować o problemach i incydentach.

4 Kontrolowane i mierzalne gdyIstnieje pełne zrozumienie korzyści, jakie daje proces zarządzania incydentami na wszystkich poziomach organizacji, a w odpowiednich jednostkach organizacyjnych wdrożona jest funkcja Service Desk. Używa się zautomatyzowanych narzędzi i technik w powiązaniu z centralną bazą wiedzy. Członkowie zespołu Service Desk ściśle współpracują z zespołem ds. zarządzania problemami. Wyraźnie określony jest zakres odpowiedzialności i monitoruje się efektywność. Ustalone i znane są procedury komunikacji, eskalacji i rozwiązywania incydentów. Personel jednostki Service Desk jest przeszkolony, a procesy są doskonalone poprzez wykorzystywanie oprogramowania dostosowanego do poszczególnych zadań. Kierownictwo określa mierniki wydajności jednostki Service Desk.

5 Zoptymalizowane gdyProces zarządzania incydentami i funkcja Service Desk są wdrożone i dobrze zorganizowane. Ich działanie jest zorientowane na klienta i charakteryzuje się kompetencją, ukierunkowaniem na klienta i chęcią niesienia pomocy. Systematycznie analizuje i raportuje się wartości mierników. Integralną częścią bazy wiedzy są obejmujące szeroki zakres zagadnień i wyczerpujące odpowiedzi na często zadawane pytania. Dostępne są narzędzia umożliwiające samodzielną diagnostykę i rozwiązywanie incydentów przez użytkowników. Doradztwo jest spójne, a incydenty są rozwiązywane szybko w ramach zorganizowanego procesu eskalacji. Kierownictwo wykorzystuje zintegrowane narzędzie do analizy statystyk wydajności procesu zarządzania incydentami i funkcji Service Desk. Procesy zostały dopracowane do poziomu najlepszych praktyk w branży w oparciu o analizę wskaźników wydajności, ciągłe doskonalenie oraz analizę porównawczą względem innych organizacji.

Model dojrzałości

Dostarczanie i wsparcieZarządzanie jednostką Service Desk i incydentamiDS8


oPis Procesu


Zarządzanie konfiguracją,


dotyczące optymalizacji infrastruktury, zasobów i potencjału IT oraz inwentaryzacji zasobów IT


stworzeniu i utrzymywaniu dokładnego i kompletnego repozytorium atrybutów i parametrów bazowych konfiguracji zasobów oraz porównywaniu ich ze stanem faktycznym,


• stworzenie centralnego repozytorium wszystkich składników konfiguracji; • identyfikację składników konfiguracji i utrzymywanie ich; • weryfikację integralności danych o konfiguracji


• liczbę problemów ze spełnieniem wymagań biznesowych spowodowanych nieprawidłową konfiguracją zasobów;

• liczbę stwierdzonych różnic między repozytorium konfiguracji a faktyczną konfiguracją zasobów;

• procent nabytych licencji, które nie zostały uwzględnione w repozytorium.





Ds9 zarządzanie konfiguracją

Zapewnienie integralności konfiguracji sprzętu i oprogramowania wymaga stworzenia i utrzymywania dokładnego i kompletnego repozytorium konfiguracji. Proces ten obejmuje gromadzenie informacji dotyczących wstępnej konfiguracji, określenie punktów wyjściowych, weryfikację i audyt informacji dotyczących konfiguracji oraz w razie potrzeby aktualizację repozytorium konfiguracji. Efektywne zarządzanie konfiguracją zapewnia większą dostępność systemów, ograniczenie do minimum problemów produkcyjnych oraz szybsze rozwiązywanie problemów.

S S SP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieZarządzanie konfiguracją DS9



DS9.1 Repozytorium konfiguracji i konfiguracja bazowaWprowadzić narzędzie pomocnicze i centralne repozytorium, które będzie zawierać wszystkie istotne informacje dotyczące elementów konfiguracji. Monitorować i rejestrować wszystkie zasoby i zmiany w zasobach. Utrzymywać konfigurację bazową dla elementów konfiguracji każdego systemu i usługi jako punktu odniesienia, do którego należy powrócić po wdrożeniu zmian.

DS9.2 Identyfikacja i utrzymywanie elementów konfiguracji Wprowadzić procedury konfiguracji w celu wsparcia zarządzania i rejestracji wszystkich zmian w repozytorium konfiguracji. Zintegrować te procedury z procedurami zarządzania zmianami, zarządzania incydentami i zarządzania problemami.

DS9.3 Przegląd integralności konfiguracji Dokonywać okresowego przeglądu danych konfiguracji w celu sprawdzenia i potwierdzenia historycznego i bieżącego stanu integralności konfiguracji. Dokonywać okresowego przeglądu zainstalowanego oprogramowania w odniesieniu do polityki użytkowania oprogramowania, aby zidentyfikować osobiste lub nielicencjonowane oprogramowanie albo przypadki nadmiaru oprogramowania w stosunku do aktualnych umów licencyjnych. Raportować, podejmować odpowiednie działania i korygować błędy i odstępstwa.

cele konTrolne

Dostarczanie i wsparcieZarządzanie konfiguracjąDS9



Cele i mierniki


AI7 WprowadzoneelementykonfiguracjiDS4 NieodzownośćelementówkonfiguracjiIT

Szczegółykonfiguracji/zasobówIT DS8 DS10 DS13Zgłoszeniazmian(RFC)(gdzieiwjakisposób AI6 wprowadzićpoprawkę)Sprawozdaniadotyczącewydajnościprocesu ME1

• Średni odstęp czasu między zidentyfikowaniem rozbieżności a jej usunięciem

• Liczba rozbieżności związanych z niekompletnymi lub brakującymi informacjami dotyczącymi konfiguracji

• Procent elementów konfiguracji zgodnych z określonymi poziomami usług, jeśli chodzi o wydajność, bezpieczeństwo i dostępność

• Liczba problemów ze spełnieniem wymagań biznesowych spowodowanych nieprawidłową konfiguracją zasobów

• Liczba stwierdzonych różnic między repozytorium konfiguracji a rzeczywistą konfiguracją zasobów

• Procent nabytych licencji, które nie zostały uwzględnione w repozytorium

Czynności• Wdrożenie centralnego repozytorium

wszystkich elementów konfiguracji• Identyfikacja elementów konfiguracji

i utrzymywanie danych konfiguracji• Weryfikacja integralności danych

konfiguracji

IT• Zoptymalizować infrastrukturę, zasoby

i potencjał IT.• Uwzględniać i chronić wszystkie zasoby

IT.

Proces• Wdrożyć repozytorium wszystkich

zasobów, atrybutów konfiguracji i punktów odniesienia.

• Utrzymywać integralność repozytorium konfiguracji.

• Dokonywać przeglądu rzeczywistych konfiguracji zasobów pod kątem zgodności z punktami odniesienia w repozytorium.

Czynności


rekto

r gen

eraln

y (CE

O)Dy

rekto

r ds.

finan

sowy

ch (C

FO)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Kier

ownik

ds. k

onfig

urac

ji

Opracowanie procedur dotyczących planowania zarządzania konfiguracjami. C A C I C C RGromadzenie informacji dotyczących wstępnej konfiguracji i ustanawianie punktów odniesienia. C C C I A/R Weryfikowanie i badanie informacji dotyczących konfiguracji (w tym wykrywanie niedozwolonego oprogramowania). I A I I A/RAktualizowanie repozytorium konfiguracji. R R R I A/R



Dostarczanie i wsparcieZarządzanie konfiguracją DS9



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie konfiguracją”, który spełnia wymaganie biznesowe wobec IT dotyczące optymalizacji infrastruktury, zasobów i potencjału IT oraz inwentaryzacji zasobów IT, jest:

0 Nieistniejące gdyKierownictwo nie docenia korzyści istnienia procesu, który umożliwia sporządzanie sprawozdań i zarządzanie infrastrukturą IT, zarówno w odniesieniu do konfiguracji sprzętu, jak i oprogramowania.

1 Początkowe/doraźne gdyDostrzegana jest potrzeba zarządzania konfiguracją. Podstawowe zadania zarządzania konfiguracją, takie jak prowadzenie wykazów sprzętu i oprogramowania, są wykonywane na indywidualnych zasadach. Nie są zdefiniowane standardowe praktyki.

2 Powtarzalne lecz intuicyjne gdyKierownictwo jest świadome potrzeby kontroli konfiguracji IT i rozumie korzyści, jakie zapewniają dokładne i kompletne informacje dotyczące konfiguracji, jednak całkowicie polega w tym względzie na wiedzy i kompetencjach personelu technicznego. Do pewnego stopnia używa się narzędzi do zarządzania konfiguracją, jednak różnią się one między platformami. Ponadto nie są zdefiniowane standardowe praktyki robocze. Zawartość danych konfiguracji jest ograniczona i nie jest wykorzystywana w powiązanych procesach, takich jak zarządzanie zmianami i zarządzanie problemami.

3 Zdefiniowane gdyProcedury i praktyki robocze są udokumentowane, ustandaryzowane i są przedmiotem komunikacji, jednak kwestia szkoleń i stosowania standardów zależy od indywidualnych decyzji. Co więcej, na różnych platformach wdrażane są podobne narzędzia do zarządzania konfiguracją. Mało prawdopodobne jest wykrycie odstępstw od procedur, a fizyczna weryfikacja jest prowadzona w niekonsekwentny sposób. Stosuje się pewne zautomatyzowane rozwiązania wspomagające śledzenie zmian sprzętu i oprogramowania. W powiązanych procesach wykorzystywane są dane konfiguracji.

4 Kontrolowane i mierzalne gdyPotrzeba zarządzania konfiguracją jest dostrzegana na wszystkich poziomach organizacji i rozwijane są dobre praktyki. Istnieje wymiana informacji na temat procedur i standardów, które są uwzględniane w szkoleniu. Przypadki odstępstw są monitorowane, śledzone i ujmowane w sprawozdaniach odstępstw. W celu egzekwowania standardów i poprawy stabilności wykorzystywane są zautomatyzowane narzędzia, takie jak technologia push (automatyczne przesyłanie informacji do odbiorców). Systemy zarządzania konfiguracją obejmują większość zasobów IT i umożliwiając prawidłowe zarządzanie wersjami i kontrolę nad dystrybucją. Konsekwentnie dokonuje się analizy i fizycznej weryfikacji wyjątków oraz poszukuje się ich przyczyn podstawowych.

5 Zoptymalizowane gdyZarządzanie wszystkimi zasobami IT odbywa się w ramach centralnego systemu zarządzania konfiguracją, który zawiera wszystkie niezbędne informacje na temat komponentów, ich wzajemnych relacji oraz zdarzeń. Dane konfiguracji są zgodne z katalogami producentów. Istnieje pełna integracja powiązanych procesów, które wykorzystują i aktualizują dane konfiguracji w zautomatyzowany sposób. Sprawozdania z audytu konfiguracji bazowych dostarczają niezbędne informacje dotyczące napraw, obsługi serwisowej, gwarancji, modernizacji i oceny technicznej poszczególnych elementów. Egzekwowane są zasady dotyczące ograniczenia instalacji niedozwolonego oprogramowania. Kierownictwo prognozuje naprawy i modernizacje na podstawie sprawozdań z analiz, wprowadza zaplanowane modernizacje oraz zapewnia możliwości odświeżania technologii. Śledzenie i monitorowanie poszczególnych zasobów IT zapewnia ich ochronę i zapobiega ich kradzieży, niewłaściwemu użyciu i nadużyciu.

Model dojrzałości

Dostarczanie i wsparcieZarządzanie konfiguracjąDS9


oPis Procesu


Zarządzanie problemami,


dotyczące zapewnienia zadowolenia użytkowników końcowych z oferty i poziomu usług, a także ograniczenia niedoskonałości w procesie dostarczania rozwiązań i usług oraz konieczności ich usuwania


rejestrowaniu, śledzeniu i rozwiązywaniu problemów operacyjnych, poszukiwaniu przyczyny podstawowej wszystkich istotnych problemów oraz na definiowaniu rozwiązań zidentyfikowanych problemów operacyjnych,


• analizę przyczyn podstawowych zgłaszanych problemów; • analizę trendów; • przyjmowanie odpowiedzialności za problemy i uzyskiwanie postępu w ich

rozwiązywaniu


• liczbę powtarzających się problemów, które wpływają na działalność biznesową;

• procent problemów rozwiązanych w wymaganym czasie; • częstotliwość sprawozdań lub aktualizacji dotyczących bieżącego

problemu zależnie od jego ważności.





Ds10 zarządzanie problemami

Efektywne zarządzanie problemami wymaga identyfikacji i klasyfikacji problemów, analizy przyczyn podstawowych i rozwiązywania problemów. Proces zarządzania problemami obejmuje również formułowanie zaleceń dotyczących poprawy, utrzymywania dokumentacji problemów oraz weryfikacji stanu działań korygujących. Efektywny proces zarządzania problemami znacznie poprawia dostępność systemów, podnosi poziom usług, ogranicza koszty oraz zwiększa wygodę i zadowolenie klientów.

SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI


ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieZarządzanie problemami DS10



DS10.1 Identyfikacja i klasyfikacja problemów Wdrożyć procesy umożliwiające raportowanie i klasyfikowanie problemów rozpoznanych w ramach procesu zarządzania incydentami. Czynności związane z klasyfikacją problemów są podobne do tych, które towarzyszą klasyfikacji incydentów; powinny one umożliwiać określenie kategorii, wpływu, pilności i priorytetu. Klasyfikować problemy, przyporządkowując je do odpowiednich grup lub dziedzin (np. sprzęt, oprogramowanie, oprogramowanie wspomagające). Grupy te mogą odpowiadać organizacyjnym zakresom odpowiedzialności bazy użytkowników i klientów oraz powinny być podstawą do przekazywania problemów właściwemu personelowi wsparcia.

DS10.2 śledzenie i rozwiązywanie problemów Zadbać o to, aby system zarządzania problemami zapewniał odpowiednie ścieżki rewizyjne umożliwiające śledzenie, analizowanie i określenie przyczyny podstawowej każdego ze zgłoszonych problemów z uwzględnieniem:• wszystkich powiązanych elementów konfiguracji;• nierozwiązanych problemów i incydentów;• znanych i przypuszczalnych błędów;• śledzenia trendów problemów.

Określić i zainicjować trwałe rozwiązania eliminujące przyczynę podstawową, kierując żądania dokonania zmian w ramach istniejącego procesu zarządzania zmianą. Podczas całego procesu rozwiązywania problemu zarządzający problemami powinni otrzymywać od zarządzających zmianami regularne sprawozdania dotyczące postępów w rozwiązywaniu problemów i usuwaniu błędów. Zarządzający problemami powinni monitorować wpływ problemów i znanych błędów na usługi świadczone użytkownikom. W przypadku gdy ten wpływ staje się poważny, zarządzający problemami powinni przekazać problem na wyższy poziom np. do odpowiedniej kadry kierowniczej w celu podniesienia priorytetu zgłoszenia zmiany lub wprowadzenia zmiany w trybie pilnym. Należy monitorować postęp rozwiązywania problemu w odniesieniu do umów SLA.

DS10.3 Zamykanie problemów Wprowadzić procedurę zamykania dokumentacji problemu po potwierdzeniu pomyślnego rozwiązania znanego problemu lub po uzgodnieniu ze stroną biznesową alternatywnego rozwiązania problemu.

DS10.4 Integracja zarządzania konfiguracją, incydentami i problemami Zintegrować powiązane procesy zarządzania konfiguracją, incydentami i problemami w celu zapewnienia efektywnego zarządzania problemami i możliwości wprowadzania ulepszeń.

cele konTrolne

Dostarczanie i wsparcieZarządzanie problemamiDS10



Cele i mierniki

AI6 ZatwierdzeniezmianyDS8 SprawozdaniadotycząceincydentówDS9 Szczegółykonfiguracji/zasobówITDS13 Dziennikibłędów

Zgłoszeniazmian(gdzieiwjakisposób wprowadzićpoprawkę) AI6Dokumentacjaproblemu AI6Sprawozdaniadotyczącewydajnościprocesu ME1Znaneproblemy,błędy DS8 irozwiązaniadoraźne

• Średni odstęp czasu między zarejestrowaniem problemu a określeniem jego przyczyny podstawowej

• Procent problemów, które objęto analizą przyczyny podstawowej

• Częstotliwość sprawozdań lub aktualizacji dotyczących bieżącego problemu zależnie od jego ważności

• Liczba powtarzających się problemów, które wpływają na działalność biznesową

• Liczba zakłóceń w działalności biznesowej spowodowanych problemami operacyjnymi

• Procent zarejestrowanych i śledzonych problemów

• Procent powracających problemów (w danym okresie czasu) według ich ważności

• Procent problemów rozwiązanych w wymaganym czasie

• Liczba otwartych/nowych/zamkniętych problemów według ich ważności

• Średnia i odchylenie standardowe odstępu czasu między zidentyfikowaniem problemu a jego rozwiązaniem

• Średnia i odchylenie standardowe odstępu czasu między rozwiązaniem problemu a jego zamknięciem

Czynności• Przyznanie wystarczającego zakresu

uprawnień menedżerowi ds. zarządzania problemami

• Analiza przyczyn podstawowych zgłaszanych problemów

• Analiza trendów• Przyjmowanie odpowiedzialności za

problemy i uzyskiwanie postępu w ich rozwiązywaniu


zadowoleni z oferty i poziomu usług.• Ograniczyć niedoskonałości


• Zabezpieczać osiąganie celów IT.

Proces• Rejestrować i śledzić problemy

operacyjne do czasu ich rozwiązania.• Poszukiwać przyczyny podstawowej

wszystkich istotnych problemów.• Zdefiniować rozwiązania dla

rozpoznanych problemów operacyjnych.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Kier

ownik

ds. z

arzą

dzan

ia pr

oblem

ami

Identyfikowanie i klasyfikowanie problemów. I I C A C C I RDokonywanie analizy przyczyn podstawowych. C C A/R Rozwiązywanie problemów. C A R R R C CWeryfikacja statusu problemów. I I C A/R C C C C R Wydawanie zaleceń dotyczących poprawy i tworzenie odpowiedniego zgłoszenia zmiany. I A I I I RProwadzenie rejestru problemów. I I I I A/R



Dostarczanie i wsparcieZarządzanie problemami DS10



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie problemami”, który spełnia wymaganie biznesowe wobec IT dotyczące zapewnienia zadowolenia użytkowników końcowych z oferty i poziomu usług, a także ograniczenia niedoskonałości w procesie dostarczania rozwiązań i usług oraz konieczności ich usuwania, jest:

0 Nieistniejące gdyNie ma świadomości potrzeby zarządzania problemami, a także nie rozróżnia się problemów od incydentów. Dlatego nie podejmuje się prób określenia przyczyny podstawowej incydentów.

1 Początkowe/doraźne gdyPersonel dostrzega potrzebę zarządzania problemami i eliminowania ich przyczyn. Najbardziej kompetentni pracownicy służą pewną pomocą w rozwiązywaniu problemów dotyczących ich obszaru kompetencji, jednak nie jest określony obszar odpowiedzialności za zarządzanie problemami. Nie odbywa się wymiana informacji, co jest źródłem dodatkowych problemów i strat produktywnego czasu na poszukiwanie rozwiązań.

2 Powtarzalne lecz intuicyjne gdyIstnieje duża świadomość korzyści, jakie zapewnia zarządzanie problemami związanymi z IT zarówno w jednostkach biznesowych, jak i wśród osób pełniących funkcje związane z dostarczaniem usług informatycznych. Proces rozwiązywania problemów rozwinięto do poziomu, na którym kilka kluczowych osób jest odpowiedzialnych za identyfikację i rozwiązywanie problemów. Wymiana informacji między pracownikami odbywa się w nieformalny i doraźny sposób. Poziom usług dostarczanych społeczności użytkowników jest zróżnicowany i obniżany przez niedostatek uporządkowanej wiedzy, która dysponuje menedżer ds. zarządzania problemami.

3 Zdefiniowane gdyPotrzeba efektywnego, zintegrowanego systemu zarządzania problemami jest akceptowana i potwierdzana przez wsparcie kierownictwa; przewidziane są budżety na obsadę etatów i szkolenie. Procesy rozwiązywania i eskalacji problemów mają ustandaryzowany charakter. Rejestrowanie i śledzenie problemów i ich rozwiązań jest rozproszone po zespole szybkiego reagowania, który wykorzystuje dostępne narzędzia bez ich centralizacji. Istnieje duże prawdopodobieństwo niewykrycia odstępstw od ustalonych norm i standardów. Wymiana informacji między pracownikami odbywa się w aktywny i formalny sposób. Dokonywany przez kierownictwo przegląd incydentów i analiza identyfikacji problemów ma ograniczony i nieformalny charakter.

4 Kontrolowane i mierzalne gdyProces zarządzania problemami jest rozumiany na wszystkich poziomach organizacji. Wyraźnie określony jest zakres odpowiedzialności i własności. Metody i procedury są udokumentowane oraz są przedmiotem komunikacji i pomiaru pod kątem efektywności. Większość problemów jest identyfikowanych, rejestrowanych i ujętych w sprawozdaniach, po czym inicjowane są działania w celu ich rozwiązania. Wiedza i kompetencje są doceniane, podtrzymywane i rozwijane do wyższych poziomów, ponieważ omawiana funkcja jest postrzegana jako jeden z zasobów i głównych czynników sprzyjających osiąganiu celów IT i doskonaleniu usług IT. Proces zarządzania problemami jest dobrze zintegrowany z innymi powiązanymi procesami, takimi jak zarządzanie incydentami, zmianami, dostępnością i konfiguracją, i ułatwia klientom zarządzanie danymi, infrastrukturą i operacjami. Dla procesu zarządzania problemami zostały uzgodnione cele i mierniki.

5 Zoptymalizowane gdyProces zarządzania problemami został rozwinięty do poziomu, na którym ma on charakter aktywny i ukierunkowany na przyszłość, przyczyniając się do realizacji celów IT. Przewiduje się i przeciwdziała problemom. Poprzez regularne kontakty z dostawcami i ekspertami utrzymywana jest wiedza dotycząca wzorców przeszłych i przyszłych problemów. Rejestrowanie, raportowanie i analiza problemów i rozwiązań są zautomatyzowane i w pełni zintegrowane z zarządzaniem danymi konfiguracji. Konsekwentnie dokonuje się pomiaru realizacji celów. Większość systemów jest wyposażonych w automatyczne mechanizmy wykrywania i ostrzegania, których działanie jest poddawane stałemu śledzeniu i ocenie. Proces zarządzania problemami jest analizowany pod kątem ciągłego doskonalenia na podstawie analizy mierników, a dotyczące go sprawozdania są przekazywane interesariuszom.

Model dojrzałości

Dostarczanie i wsparcieZarządzanie problemamiDS10


oPis Procesu


Zarządzanie danymi,


dotyczące optymalizacji wykorzystania informacji oraz zapewnienia ich dostępności adekwatnie do potrzeb


zachowaniu kompletności, dokładności, dostępności i bezpieczeństwa danych,


• sporządzanie kopii zapasowych danych i testowanie procedur ich przywracania; • zarządzanie miejscową i pozamiejscową pamięcią masową do przechowywania

danych; • bezpieczne pozbywanie się danych i sprzętu


• wyrażony procentowo poziom zadowolenia użytkowników z dostępności danych;

• procent pomyślnie przywróconych danych; • liczbę incydentów związanych z koniecznością odzyskania

wrażliwych danych po pozbyciu się nośników.





Ds11 zarządzanie danymi

Efektywne zarządzanie danymi wymaga opracowania właściwych wymagań dla danych. Proces zarządzania danymi obejmuje również wprowadzenie efektywnych procedur zarządzania biblioteką mediów, sporządzaniem kopii zapasowych i odzyskiwaniem danych, a także prawidłowym pozbywaniem się nośników. Efektywne zarządzanie danymi pomaga zapewnić odpowiednią jakość, aktualność i dostępność danych biznesowych.

P P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieZarządzanie danymi DS11



DS11.1 Wymagania biznesowe dotyczące zarządzania danymi Sprawdzać, czy wszystkie dane przeznaczone do przetwarzania są otrzymywane i przetwarzane w całości, dokładnie i terminowo, a wszystkie dane wyjściowe są dostarczane zgodnie z wymaganiami biznesowymi. Wspierać realizację potrzeb związanych z ponownym uruchamianiem i ponownym przetwarzaniem.

DS11.2 organizacja przechowywania i utrzymywania danych Zdefiniować i wdrożyć procedury efektywnego i wydajnego przechowywania, utrzymywania i archiwizacji danych, które pozwolą osiągać cele biznesowe przy zachowaniu zgodności z polityką bezpieczeństwa organizacji i wymaganiami regulacyjnymi.

DS11.3 System zarządzania biblioteką mediów Zdefiniować i wdrożyć procedury utrzymywania spisu przechowywanych i zarchiwizowanych nośników w celu zapewnienia ich użyteczności i integralności.

DS11.4 Pozbywanie się danych Zdefiniować i wdrożyć procedury umożliwiające spełnienie wymagań firmy dotyczących ochrony danych wrażliwych i oprogramowania w sytuacji pozbywania się lub przesyłania danych i sprzętu.

DS11.5 Kopie zapasowe i przywracanie danych Zdefiniować i wdrożyć procedury dotyczące sporządzania kopii zapasowych i przywracania systemów, aplikacji, danych i dokumentacji, tak aby odbywały się one zgodnie z wymaganiami biznesowymi i planem zapewnienia ciągłości.

DS11.6 Wymagania bezpieczeństwa dotyczące zarządzania danymi Zdefiniować i wdrożyć politykę i procedury dotyczące określania i stosowania wymagań bezpieczeństwa odnoszących się do odbioru, przetwarzania, przechowywania i przesyłania danych, które pozwolą osiągać cele biznesowe przy zachowaniu zgodności z polityką bezpieczeństwa organizacji i wymaganiami regulacyjnymi.

cele konTrolne

Dostarczanie i wsparcieZarządzanie danymiDS11



Cele i mierniki

PO2 Słownikdanych;sporządzonaiprzypisanaklasyfikacjadanych


DS1 Umowy OLA DS4 Plan przechowywania i ochrony kopii

zapasowychDS5 Planipolitykizapewnieniabezpieczeństwa

IT

Sprawozdaniadotyczącewydajnościprocesu ME1Instrukcjedlaoperatoradotyczącezarządzania DS13 danymi

• Częstotliwość testowania nośników kopii zapasowych

• Średni czas przywracania danych

• Liczba przypadków niemożności odzyskania danych o krytycznym znaczeniu dla procesów biznesowych

• Wyrażony procentowo poziom zadowolenia użytkowników z dostępności danych

• Liczba incydentów braku zgodności z przepisami prawa na skutek problemów dotyczących zarządzania przechowywaniem danych

• Procent pomyślnie przywróconych danych

• Liczba incydentów związanych z koniecznością odzyskania wrażliwych danych po pozbyciu się nośników

• Liczba przestojów lub incydentów zagrażających integralności danych, które zostały spowodowane niewystarczającą pojemnością pamięci masowej

Czynności• Sporządzanie kopii zapasowych danych

i testowanie procedur ich przywracania • Zarządzanie pamięcią masową do

przechowywania danych w lokalizacji firmy i poza nią.

• Bezpieczne pozbywanie się danych i sprzętu

IT• Zoptymalizować wykorzystanie

informacji.• Zapewnić, aby nieuprawnione osoby nie

miały dostępu do kluczowych i poufnych informacji.

• Zapewniać zgodność IT z przepisami prawa, wymaganiami regulacyjnymi i umowami.

Proces• Zachowywać kompletność, dokładność,

dostępność i bezpieczeństwo danych.• Zapewniać bezpieczeństwo danych przy

pozbywaniu się nośników.• Efektywnie zarządzać nośnikami pamięci

masowych.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Ujęcie wymagań przechowywania i utrzymywania danych, w odpowiednich procedurach. A I C R CDefiniowanie, utrzymywanie i wdrażanie procedur dotyczących zarządzania biblioteką mediów. A R C C I CDefiniowanie, utrzymywanie i wdrażanie procedur dotyczących bezpiecznego usuwania mediów i sprzętu. A C R I CTworzenie kopii zapasowych danych w zgodzie ze schematem. A RDefiniowanie, utrzymywanie i wdrażanie procedur dotyczących odzyskiwania danych. A C R C C I



Dostarczanie i wsparcieZarządzanie danymi DS11



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie danymi”, który spełnia wymaganie biznesowe wobec IT dotyczące optymalizacji wykorzystania informacji oraz zapewnienia ich dostępności adekwatnie do potrzeb, jest:

0 Nieistniejące gdyDane nie są postrzegane jako zasoby firmy. Nie jest również określona własność danych ani indywidualna odpowiedzialność za zarządzanie danymi. Jakość i bezpieczeństwo danych są na słabym poziomie albo w ogóle nie istnieją.

1 Początkowe/doraźne gdyOrganizacja dostrzega potrzebę efektywnego zarządzania danymi. Stosowane jest doraźne podejście do określania wymagań bezpieczeństwa dla zarządzania danymi, ale nie istnieją żadne formalne procedury komunikacji. Nie ma specjalistycznych szkoleń dotyczących zarządzania danymi. Odpowiedzialność za zarządzanie danymi nie jest jasno określona. Istnieją procedury sporządzania kopii zapasowych i przywracania oraz ustalenia dotyczące pozbywania się danych.

2 Powtarzalne lecz intuicyjne gdyŚwiadomość potrzeby efektywnego zarządzania danymi jest rozpowszechniona w całej organizacji. Zaczyna występować własność danych na wysokim poziomie zarządzania. Wymagania bezpieczeństwa dotyczące zarządzania danymi są udokumentowane przez kluczowe osoby. W dziale IT w pewnym zakresie odbywa się monitoring najważniejszych czynności związanych z zarządzaniem danymi (np. sporządzania kopii zapasowych, przywracania i pozbywania się danych). Odpowiedzialność za zarządzanie danymi jest nieformalnie przypisana do kluczowych pracowników działu IT.

3 Zdefiniowane gdyRozumiana i akceptowana jest potrzeba zarządzania danymi w ramach działu IT i całej organizacji. Określona jest odpowiedzialność za zarządzanie danymi. Własność danych jest przypisana odpowiedzialnej osobie, która kontroluje ich integralność i bezpieczeństwo. W dziale IT sformalizowane są procedury zarządzania danymi i wykorzystywane są pewne narzędzia do sporządzania kopii zapasowych i przywracania danych oraz do pozbywania się sprzętu. W pewnym zakresie prowadzony jest monitoring zarządzania danymi. Zdefiniowane są podstawowe mierniki wydajności. Pojawia się szkolenie pracowników zajmujących się zarządzaniem danymi.

4 Kontrolowane i mierzalne gdyW organizacji rozumiana jest potrzeba zarządzania danymi i akceptowane są związane z tym działania. Odpowiedzialność za zarządzanie i własność danych jest jasno zdefiniowana, przypisana i komunikowana wewnątrz organizacji. Procedury są sformalizowane, powszechnie znane i występuje zjawisko dzielenia się wiedzą. Pojawia cię korzystanie ze wspólnych narzędzi. Cele i wskaźniki wydajności są uzgodnione z klientami i monitorowane w ramach dobrze zdefiniowanego procesu. Odbywają się formalne szkolenia dla pracowników zajmujących się zarządzaniem danymi.

5 Zoptymalizowane gdyW organizacji rozumiana jest potrzeba zarządzania danymi oraz rozumiane i akceptowane są wszystkie związane z tym działania. Aktywnie dąży się do rozpoznania przyszłych potrzeb i wymagań. Odpowiedzialność za własność i zarządzanie danymi jest jasno określona, powszechnie znana wewnątrz organizacji i terminowo aktualizowana. Procedury są sformalizowane i powszechnie znane, a dzielenie się wiedzą jest standardową praktyką. Wykorzystuje się zaawansowane narzędzia w celu maksymalnej automatyzacji procesu zarządzania danymi. Cele i wskaźniki wydajności są uzgodnione z klientami, powiązane z celami biznesowymi i konsekwentnie monitorowane w ramach dobrze zdefiniowanego procesu. Stale bada się możliwości doskonalenia. Szkolenie pracowników zajmujących się zarządzaniem danymi ma zinstytucjonalizowany charakter.

Model dojrzałości

Dostarczanie i wsparcieZarządzanie danymiDS11


oPis Procesu


Zarządzanie środowiskiem fizycznym,


dotyczące ochrony zasobów komputerowych i danych firmy oraz minimalizacji ryzyka wystąpienia przerwy w działalności biznesowej


zapewnieniu i utrzymywaniu odpowiedniego środowiska fizycznego, umożliwiającego ochronę zasobów IT przed niepowołanym dostępem, uszkodzeniem lub kradzieżą,


• wdrożenie fizycznych środków bezpieczeństwa; • wybór odpowiedniej infrastruktury i zarządzanie nią


• liczbę przestojów spowodowanych incydentami w obszarze środowiska fizycznego;

• liczbę incydentów spowodowanych naruszeniami lub uchybieniami dotyczącymi bezpieczeństwa fizycznego;

• częstotliwość ocen i przeglądów ryzyka fizycznego.





Ds12 zarządzanie środowiskiem fizycznym

Ochrona sprzętu komputerowego i personelu wymaga dobrze zaprojektowanej i zarządzanej infrastruktury fizycznej. Proces zarządzania środowiskiem fizycznym obejmuje zdefiniowanie wymagań wobec fizycznej siedziby, wybór odpowiedniej infrastruktury oraz zaprojektowanie efektywnych procesów monitorowania czynników środowiskowych i zarządzania fizycznym dostępem. Efektywne zarządzanie środowiskiem fizycznym ogranicza występowanie przerw w działalności na skutek szkód dotykających sprzętu komputerowego i personelu.

P P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Dostarczanie i wsparcieZarządzanie środowiskiem fizycznym DS12



DS12.1 Wybór miejsca i rozmieszczenia Określić i wybrać fizyczne lokalizacje dla sprzętu IT w celu wsparcia strategii technologicznej powiązanej ze strategią biznesową. Wybór lokalizacji i plan rozmieszczenia powinien uwzględniać ryzyko związane z potencjalnymi katastrofami naturalnymi i spowodowanymi przez człowieka, jednocześnie biorąc pod uwagę odpowiednie przepisy prawa i regulacje — np. dotyczące bezpieczeństwa i higieny pracy.

DS12.2 Fizyczne środki bezpieczeństwa Zgodnie wymaganiami biznesowymi określić i wdrożyć fizyczne środki bezpieczeństwa w celu zabezpieczenia lokalizacji i fizycznych zasobów. Fizyczne środki bezpieczeństwa powinny umożliwiać efektywne zapobieganie, wykrywanie i łagodzenie ryzyka związanego z kradzieżą, działaniem temperatury, ognia, dymu, wody, drgań oraz z ryzyka związanego z terroryzmem, wandalizmem i brakiem zasilania, a także działaniem środków chemicznych lub materiałów wybuchowych.

DS12.3 Fizyczny dostęp Zdefiniować i wdrożyć procedury umożliwiające przyznanie, ograniczenie i cofnięcie prawa dostępu to pomieszczeń, budynków i innych obszarów zgodnie z potrzebami firmy, uwzględniając sytuacje awaryjne. Dostęp do pomieszczeń, budynków i innych obszarów powinien być uzasadniony, zatwierdzony, rejestrowany i monitorowany. Powinno odnosić się to do wszystkich osób wchodzących do pomieszczeń, w tym pracowników, pracowników tymczasowych, klientów, dostawców, gości i innych stron trzecich.

DS12.4 ochrona przed czynnikami środowiskowymi Zaprojektować i wdrożyć rozwiązania zapewniające ochronę przed czynnikami środowiskowymi. Zainstalować specjalistyczny sprzęt i urządzenia monitorujące i kontrolujące środowisko.

DS12.5 Zarządzanie infrastrukturą fizyczną Zarządzać infrastrukturą, w tym urządzeniami zasilającymi i komunikacyjnymi, zgodnie z przepisami prawa i regulacjami, wymaganiami technicznymi i biznesowymi, specyfikacjami producentów oraz przepisami BHP.

cele konTrolne

Dostarczanie i wsparcieZarządzanie środowiskiem fizycznymDS12



Cele i mierniki

PO2 Klasyfikacjaprzypisanychdanych PO9 Ocena ryzykaAI3 Wymaganiaśrodowiskafizycznego

Sprawozdaniadotyczącewydajnościprocesu ME1

• Częstotliwość szkolenia personelu w dziedzinie rozwiązań z zakresu bezpieczeństwa, ochrony i infrastruktury

• Procent przeszkolonego personelu w dziedzinie rozwiązań z zakresu bezpieczeństwa, ochrony i infrastruktury

• Liczba testów dotyczących łagodzenia ryzyka przeprowadzonych w ubiegłym roku

• Częstotliwość ocen i przeglądów ryzyka fizycznego

• Liczba przestojów spowodowanych incydentami w obszarze środowiska fizycznego

• Liczba urazów spowodowanych przez środowisko fizyczne

• Liczba zagrożeń bezpieczeństwa spowodowanych incydentami w obszarze środowiska fizycznego

• Liczba incydentów spowodowanych naruszeniami lub uchybieniami dotyczącymi bezpieczeństwa fizycznego

• Liczba incydentów związanych z nieuprawnionym dostępem do infrastruktury komputerowej

Czynności• Wdrożenie fizycznych środków

bezpieczeństwa• Dokładny wybór infrastruktury

i zarządzanie nią

IT• Zapewnić, aby usługi i infrastruktura

IT zdolne były skutecznie oprzeć się awariom, a w przypadku awarii na skutek błędu, celowego ataku, lub katastrofy, skutecznie po niej powrócić.

• Zapewnić, aby nieuprawnione osoby nie miały dostępu do kluczowych i poufnych informacji.


• Uwzględniać i chronić wszystkie zasoby IT.

Proces• Zapewnić i utrzymywać odpowiednie

środowisko fizyczne dla infrastruktury i zasobów IT.

• Ograniczyć dostęp do środowiska fizycznego osobom, które nie potrzebują takiego dostępu.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Definiowanie wymaganego poziomu ochrony fizycznej. A/R C CDokonywanie wyboru i zamówienia miejsca działalności (centrum danych, biuro itp.). I C C C C A/R C C C CWdrażanie komponentów środowiska fizycznego. I A/R I I CZarządzanie środowiskiem fizycznym (w tym utrzymywanie, monitorowanie i raportowanie). A/R CDefiniowanie i wdrażanie procedur dotyczących autoryzacji i utrzymywania dostępu fizycznego. C I A/R I I I C



Dostarczanie i wsparcieZarządzanie środowiskiem fizycznym DS12



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie środowiskiem fizycznym”, który spełnia wymaganie biznesowe wobec IT dotyczące ochrony zasobów komputerowych i danych firmy oraz minimalizacji ryzyka wystąpienia przerwy w działalności biznesowej, jest:

0 Nieistniejące gdyNie ma świadomości potrzeby ochrony infrastruktury lub inwestycji w zasoby informatyczne. Nie są monitorowane ani kontrolowane czynniki środowiskowe, takie jak zagrożenie pożarowe, zapylenie, parametry zasilania, zbyt wysoka temperatura czy nadmierna wilgotność.

1 Początkowe/doraźne gdyOrganizacja uznaje istnienie potrzeby biznesowej dotyczącej zapewnienia odpowiedniego środowiska fizycznego, które będzie chronić zasoby i personel przed zagrożeniami pochodzenia ludzkiego i naturalnego. Zarządzanie infrastrukturą i sprzętem jest zależne od umiejętności i predyspozycji kluczowych osób. Personel może przemieszczać się w obiektach bez żadnych ograniczeń. Kierownictwo nie monitoruje środowiskowych mechanizmów kontrolnych w obiektach ani przemieszczania się personelu.

2 Powtarzalne lecz intuicyjne gdyŚrodowiskowe mechanizmy kontrolne są wdrożone i monitorowane przez personel operacyjny. Zapewnienie fizycznego bezpieczeństwa jest nieformalnym procesem, kierowanym przez niewielką grupę pracowników o wysokim poczuciu odpowiedzialności za bezpieczeństwo fizycznej infrastruktury. Procedury dotyczące utrzymywania infrastruktury nie są dobrze udokumentowane i opierają się na dobrych praktykach kilku osób. Cele dotyczące zapewnienia fizycznego bezpieczeństwa nie są oparte na żadnych formalnych standardach, a kierownictwo nie sprawdza, czy są one osiągane.

3 Zdefiniowane gdyPotrzeba utrzymywania kontrolowanego środowiska informatycznego jest rozumiana i akceptowana w organizacji. Środowiskowe mechanizmy kontrolne, prewencyjna konserwacja i zapewnienie fizycznego bezpieczeństwa są pozycjami budżetowymi, które są zatwierdzone i monitorowane przez kierownictwo. Stosowane są ograniczenia dostępu i tylko uprawnieni pracownicy mają dostęp do infrastruktury informatycznej. Goście są rejestrowani i poruszają się w towarzystwie pracowników (zależnie od osoby). Fizyczna infrastruktura jest skromna i mało zauważalna. Władze cywilne monitorują zgodność z przepisami BHP. Ryzyka są ubezpieczane przy minimalnych nakładach na optymalizację kosztów ubezpieczenia.

4 Kontrolowane i mierzalne gdyW pełni rozumiana jest potrzeba utrzymywania kontrolowanego środowiska informatycznego, co widoczne jest w strukturze organizacyjnej i podziale budżetu. Wymagania środowiskowe i dotyczące bezpieczeństwa fizycznego są udokumentowane, a dostęp jest ściśle kontrolowany i monitorowany. Zakres odpowiedzialności jest zdefiniowany i znany. Pracownicy zajmujący się infrastrukturą są w pełni przeszkoleni na wypadek sytuacji awaryjnych i w zakresie praktyki BHP. Wykorzystywane są ustandaryzowane mechanizmy kontrolne ograniczające dostęp do infrastruktury i pozwalające zachować kontrolę nad czynnikami środowiskowymi i wpływającymi na bezpieczeństwo. Kierownictwo monitoruje skuteczność mechanizmów kontrolnych i zgodność z przyjętymi standardami. Kierownictwo określiło cele i mierniki umożliwiające ocenę zarządzania środowiskiem informatycznym. Funkcja odzyskiwania zasobów informatycznych stanowi integralną część procesu zarządzania ryzykiem organizacyjnym. W celu optymalizacji zakresu ubezpieczenia i związanych z tym kosztów wykorzystuje się zintegrowane informacje.

5 Zoptymalizowane gdyIstnieje uzgodniony, długoterminowy plan dotyczący infrastruktury niezbędnej do zapewnienia wsparcia dla środowiska informatycznego organizacji. Dla całej infrastruktury zdefiniowane są standardy, dotyczące m.in. wyboru miejsca, konstrukcji, ochrony, bezpieczeństwa personelu, rozwiązań technicznych i instalacji elektrycznych oraz ochrony przed czynnikami środowiskowymi (np. ogniem, wyładowaniami atmosferycznymi czy powodzią). Cała infrastruktura jest zinwentaryzowana i sklasyfikowana w ramach procesu bieżącego zarządzania ryzykiem. Dostęp jest ściśle kontrolowany, dostosowany do potrzeb wykonywanej pracy i stale monitorowany; wszyscy goście zawsze poruszają się w towarzystwie pracowników. Środowisko jest monitorowane i kontrolowane przy użyciu specjalistycznego sprzętu, a w pomieszczeniach ze sprzętem nie przebywają pracownicy. Realizacja celów podlega systematycznemu pomiarowi i ocenie. Programy prewencyjnej konserwacji narzucają ścisłe przestrzeganie harmonogramów, a urządzenia wrażliwe poddawane są regularnym testom. Strategia i standardy dotyczące infrastruktury są dostosowane do zakładanych poziomów dostępności usług IT i zintegrowane z planami zapewnienia ciągłości działalności biznesowej oraz zarządzaniem kryzysowym. Kierownictwo stale dokonuje przeglądów i optymalizuje infrastrukturę w oparciu o cele i mierniki, wykorzystując możliwości zwiększenia jej wkładu w realizację potrzeb firmy.

Model dojrzałości

Dostarczanie i wsparcieZarządzanie środowiskiem fizycznymDS12


oPis Procesu


Zarządzanie operacjami,


dotyczące zachowania integralności danych i zapewnienia, aby infrastruktura IT była zdolna oprzeć się i powrócić do działania po wystąpieniu błędów i awarii


osiągnięciu odpowiedniego poziomu usług operacyjnych dla planowanego przetwarzania danych, ochronie wrażliwych danych wyjściowych oraz monitorowaniu i konserwacji infrastruktury,


• eksploatację środowiska informatycznego zgodnie z ustalonymi poziomami usług i instrukcjami;

• konserwację infrastruktury IT


• liczbę poziomów usług dotkniętych incydentami operacyjnymi; • liczbę godzin nieplanowanych przestojów spowodowanych

incydentami operacyjnymi; • procent zasobów sprzętowych ujętych w harmonogramach

prewencyjnej konserwacji.





Ds13 zarządzanie operacjami

Kompletne i dokładne przetwarzanie danych wymaga efektywnego zarządzania procedurami przetwarzania danych i skrupulatnej konserwacji sprzętu. Proces ten obejmuje definiowanie polityki i procedur operacyjnych dla efektywnego zarządzania planowanym przetwarzaniem, ochrony wrażliwych danych, monitorowania wydajności infrastruktury oraz zapewnienia prewencyjnej konserwacji sprzętu. Efektywne zarządzanie operacjami pomaga zachować integralność danych i ograniczyć opóźnienia w działalności biznesowej oraz koszty operacyjne IT.

SSP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM


DOMENY



Dostarczanie i wsparcieZarządzanie operacjami DS13



DS13.1 Procedury i instrukcje operacyjne Zdefiniować, wdrożyć i utrzymywać procedury operacji IT, zapewniając, aby personel operacyjny znał wszystkie wyznaczone zadania operacyjne. Procedury operacyjne powinny obejmować czynności związane z przekazywaniem zmiany (formalne czynności dla pracy zmianowej - przekazywanie obowiązków, aktualizacje stanu, problemy operacyjne, procedury eskalacji i informacje dotyczące aktualnego zakresu obowiązków) w celu zapewnienia wsparcia dla uzgodnionych poziomów usług i ciągłości działania.

DS13.2 Tworzenie harmonogramów prac Zorganizować tworzenie harmonogramów prac, procesów i zadań wsadowych w najbardziej efektywnej kolejności, maksymalizując wydajność i wykorzystanie w celu spełnienia wymagań biznesowych.

DS13.3 Monitorowanie infrastruktury IT Zdefiniować i wdrożyć procedury monitorowania infrastruktury IT i dotyczących jej zdarzeń. Zapewnić przechowywanie chronologicznie uporządkowanych informacji w postaci dzienników operacji, aby umożliwić odtwarzanie, przegląd i sprawdzanie sekwencji czasowych operacji oraz innych czynności towarzyszących lub wspomagających wykonywanie operacji.

DS13.4 Dokumenty wrażliwe i urządzenia wyjściowe Wprowadzić odpowiednie mechanizmy ochrony fizycznej, praktyczną rozliczalność i zarządzanie wrażliwymi zasobami IT, takimi jak specjalne formularze, instrumenty zbywalne, specjalne drukarki czy tokeny zabezpieczające.

DS13.5 Prewencyjna konserwacja sprzętu Zdefiniować i wdrożyć procedury zapewniające terminową konserwację infrastruktury, aby ograniczyć częstotliwość występowania i wpływ awarii lub spadków wydajności.

cele konTrolne

Dostarczanie i wsparcieZarządzanie operacjamiDS13



Cele i mierniki


AI7 Planyprzekazaniadoprodukcjioraz wprowadzeniaidystrybucjioprogramowania

DS1 Umowy SLA i OLA DS4 Plan przechowywania i ochrony kopii

zapasowychDS9 Szczegółykonfiguracji/zasobówITDS11 Instrukcjedlaoperatoradotyczące

zarządzaniadanymi

Zgłoszeniaincydentów DS8Dziennikibłędów DS10Sprawozdaniadotyczącewydajnościprocesu ME1

• Liczba dni szkoleniowych rocznie dla personelu operacyjnego

• Procent zasobów sprzętowych ujętych w harmonogramach prewencyjnej konserwacji

• Procent harmonogramów prac, które są zautomatyzowane

• Częstotliwość aktualizacji procedur operacyjnych

• Liczba poziomów usług dotkniętych incydentami operacyjnymi

• Liczba godzin nieplanowanych przestojów spowodowanych incydentami operacyjnymi

• Liczba incydentów związanych z przestojem i opóźnień spowodowanych odstępstwem od procedur operacyjnych

• Procent zaplanowanej pracy i zamówień, które nie zostały zrealizowane na czas

• Liczba incydentów związanych przestojem i opóźnień na skutek nieodpowiednich procedur

Czynności• Eksploatacja środowiska

informatycznego zgodnie z ustalonymi poziomami usług i instrukcjami oraz przy zachowaniu ścisłego nadzoru

• Prewencyjna konserwacja i monitorowanie infrastruktury IT


IT zdolne były skutecznie oprzeć się awariom, a w przypadku awarii na skutek błędu, celowego ataku, lub katastrofy, skutecznie po niej powrócić.

• Zapewnić, aby użytkownicy końcowi byli zadowoleni z oferty i poziomu usług.

• Zapewnić dostępność usług IT adekwatnie do potrzeb.

Proces• Zdefiniować procedury operacyjne

i dostosować je do uzgodnionych poziomów usług.

• Realizować zaplanowane i specjalnie zamówione usługi przetwarzania w ramach uzgodnionych poziomów usług.

• Zapewnić fizyczne mechanizmy ochrony informacji wrażliwych.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. rozw

ojuKi

erow

nik ds

. adm

inistr

acji I

T

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Tworzenie/modyfikowanie procedur operacyjnych (w tym podręczników, list kontrolnych, planowania zmian, przekazywania dokumentacji, procedur eskalowania itp.). A/R I Tworzenie harmonogramu obciążeń i zadań wsadowych. C A/R C CMonitorowanie infrastruktury i przetwarzania oraz rozwiązywanie problemów. A/R IZarządzanie fizycznymi danymi wyjściowymi (np. papier, media) i ich zabezpieczanie. A/R CWprowadzanie poprawek lub zmian do harmonogramu i infrastruktury. C A/R C C CWdrażanie/ustanawianie procesu ochrony urządzeń uwierzytelniających przed zakłóceniami, utratą i kradzieżą. A R I CPlanowanie i przeprowadzanie konserwacji prewencyjnej. A/R



Dostarczanie i wsparcieZarządzanie operacjami DS13



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zarządzanie operacjami”, który spełnia wymaganie biznesowe wobec IT dotyczące zachowania integralności danych i zapewnienia, aby infrastruktura IT była zdolna oprzeć się i powrócić do działania po wystąpieniu błędów i awarii, jest:

0 Nieistniejące gdyOrganizacja nie poświęca czasu ani zasobów na zapewnienie podstawowego wsparcia IT i czynności związanych z przetwarzaniem.

1 Początkowe/doraźne gdyOrganizacja dostrzega potrzebę organizacji funkcji wsparcia IT. Wprowadzonych jest kilka standardowych procedur, a czynności operacyjne mają z natury doraźny charakter. Większość procesów operacyjnych jest zaplanowana nieformalnie, a zamówione usługi przetwarzania są akceptowane bez uprzedniej weryfikacji. Komputery, systemy i aplikacje wspierające procesy biznesowe podlegają częstym przerwom w działaniu, opóźnieniom lub są niedostępne. Oczekiwanie przez pracowników na dostępność zasobów powoduje stratę czasu. Nośniki wyjściowe pojawiają się czasem w nieoczekiwanych miejscach lub nie pojawiają się w ogóle.

2 Powtarzalne lecz intuicyjne gdyOrganizacja zdaje sobie sprawę z kluczowej roli, jaką odgrywają czynności operacyjne IT w zapewnieniu funkcji wsparcia IT. Środki budżetowe na narzędzia są rozdzielane na zasadach doraźnych. Operacje wsparcia IT mają nieformalny i intuicyjny charakter. Występuje duża zależność od umiejętności i predyspozycji pojedynczych osób. Instrukcje mówiące, co należy robić, kiedy i w jakiej kolejności, nie są udokumentowane. Odbywają się wybrane szkolenia dla operatorów i istnieją pewne formalne standardy operacyjne.

3 Zdefiniowane gdyPotrzeba zarządzania operacjami komputerowymi jest rozumiana i akceptowana w organizacji. Na ten cel przeznaczone są odpowiednie zasoby i przeprowadzane są szkolenia stanowiskowe. Powtarzalne funkcje są formalnie zdefiniowane, ustandaryzowane, udokumentowane i znane pracownikom. Zdarzenia i rezultaty ukończonych zadań są rejestrowane i w ograniczonym stopniu raportowane do kierownictwa. Wprowadza się zautomatyzowane tworzenie harmonogramów i inne narzędzia w celu ograniczenia interwencji operatorów. Wprowadzane są mechanizmy kontrolne dla wdrożeń nowych zadań operacyjnych. Opracowana jest formalna polityka mająca na celu ograniczenie nieplanowanych zdarzeń. Zawierane z dostawcami umowy serwisowe i konserwacji mają nadal nieformalny charakter.

4 Kontrolowane i mierzalne gdyOperacje komputerowe i zakresy odpowiedzialności dotyczącej wsparcia są jasno zdefiniowane, a ich własność jest odpowiednio przypisana. Operacje są wspierane przez zasoby budżetowe przeznaczone na nakłady kapitałowe i kadry. Szkolenie jest sformalizowane i ma ciągły charakter. Harmonogramy i zadania są dokumentowane i znane — zarówno wewnątrz działu IT, jak i klientom biznesowym. Istnieje możliwość pomiaru i monitorowania codziennych czynności w odniesieniu do ustandaryzowanych umów dotyczących wydajności i określonych poziomów usług. Wszelkie odstępstwa od przyjętych norm spotykają się z szybkimi działaniami zaradczymi i są korygowane. Kierownictwo monitoruje wykorzystanie zasobów informatycznych i realizację przydzielonych prac i zadań. W ramach ciągłego doskonalenia podejmowany jest wysiłek w celu podniesienia poziomu automatyzacji procesu. Z dostawcami zawarte są formalne umowy serwisowe i dotyczące konserwacji. Istnieje pełna zgodność z procesami zarządzania problemami, potencjałem i dostępnością, wsparta analizą przyczyn błędów i awarii.

5 Zoptymalizowane gdyOperacje wsparcia IT są efektywne, wydajne i odpowiednio elastyczne, aby realizować potrzeby poziomów usług przy minimalnym spadku wydajności. Procesy zarządzania operacyjnego IT są ustandaryzowane i udokumentowane w bazie wiedzy oraz są przedmiotem ciągłego doskonalenia. Zautomatyzowane procesy wspierające działają bez zakłóceń i przyczyniają się do zapewnienia stabilnego środowiska. Wszystkie problemy i awarie są analizowane w celu określenia przyczyny podstawowej. Regularne spotkania z osobami zarządzającymi zmianami zapewniają terminowe uwzględnianie zmian w harmonogramach produkcji. We współpracy z dostawcami analizuje się stan sprzętu pod kątem wieku i objawów nieprawidłowego działania, a konserwacja ma z reguły prewencyjny charakter.

Model dojrzałości

Dostarczanie i wsparcieZarządzanie operacjamiDS13

M o n i T o r o w a n i e i o c e n a

ME1 MonitorowanieiocenawydajnościITME2 MonitorowanieiocenakontroliwewnętrznejME3 ZapewnianiezgodnościzzewnętrznymiregulacjamiME4 Zapewnienieładuinformatycznego

Mo

NIT

oR

oW

aN

IE

I oC

EN

a


Monitorowanie i ocenaMonitorowanie i ocena wydajności IT ME1

oPis Procesu


Monitorowanie i ocena wydajności IT,


dotyczącą przejrzystości i zrozumienia kosztów, korzyści, strategii, polityki i poziomów usług IT zgodnie z wymaganiami nadzoru


monitorowaniu i raportowaniu mierników procesu oraz identyfikacji i wdrażaniu działań mających na celu zwiększenie wydajności,


• analizę sprawozdań dotyczących wydajności i przekładanie ich na sprawozdania zarządcze;

• ocenę wydajności w odniesieniu do ustalonych celów oraz inicjowanie niezbędnych działań naprawczych


• zadowolenie kierownictwa i jednostki nadzorującej ze sprawozdawczości dotyczącej wydajności;

• liczbę ulepszeń stymulowanych przez działania monitorujące; • procent monitorowanych procesów o krytycznym znaczeniu.





Me1 Monitorowanie i ocena wydajności it

Efektywne zarządzanie sprawnością IT wymaga procesu monitorowania. Proces ten obejmuje zdefiniowanie odpowiednich wskaźników wydajności, raportowanie wydajności w terminowy i systematyczny sposób oraz odpowiednie reagowanie na odstępstwa. Monitorowanie jest niezbędne do zapewnienia, że podejmowane są odpowiednie działania zgodnie z przyjętym kierunkiem i polityką.

S SSSSP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Mo

NIT

oR

oW

aN

IE

I oC

EN

a



ME1.1 Podejście do monitorowania Określić ogólną strukturę monitoringu oraz podejście do definicji zakresu, metodyki i procesu, które mają stanowić odniesienie dla pomiaru dostarczania rozwiązań i usług IT oraz monitorowania wkładu IT w działalność biznesową. Zintegrować tę strukturę z korporacyjnym systemem zarządzania wydajnością.

ME1.2 Definiowanie i gromadzenie danych z monitoringu Zdefiniować we współpracy z działem biznesowym zrównoważony zbiór celów wydajności i uzyskać jego akceptację przez dział biznesowy i innych interesariuszy. Zdefiniować wartości odniesienia, do których będą porównywane wyniki i określić dostępne dane umożliwiające pomiar realizacji celów. Wprowadzić procesy umożliwiające gromadzenie aktualnych i dokładnych danych w celu raportowania postępu w realizacji celów.

ME1.3 Metoda monitoringu Wdrożyć metodę monitorowania wydajności (np. zrównoważona karta wyników) umożliwiającą rejestrowanie celów i pomiarów, dostarczającą konkretnych i wszechstronnych informacji na temat wydajności IT i dostosowaną do systemu monitoringu przedsiębiorstwa.

ME1.4 ocena wydajności Okresowo dokonywać oceny wydajności w odniesieniu do celów, analizować przyczyny odstępstw i inicjować działania naprawcze, aby wyeliminować przyczyny ich powstawania. W odpowiednim czasie przeprowadzić analizę podstawowych przyczyn występujących odstępstw.

ME1.5 Sprawozdawczość na potrzeby zarządu i kierownictwa Opracowywać sprawozdania dla wyższej kadry zarządzającej dotyczące wkładu IT w działalność biznesową, zwłaszcza w odniesieniu do wydajności portfela działalności przedsiębiorstwa, programów inwestycji opartych o technologie IT, a także wydajności poszczególnych programów w dostarczaniu rozwiązań i usług. W sprawozdaniach dotyczących stanu należy uwzględniać informacje o stopniu realizacji zaplanowanych celów, wykorzystanych zasobach finansowych, osiągniętych celach wydajności oraz zidentyfikowanych i złagodzonych ryzykach. Uprzedzać przeglądy dokonywane przez wyższą kadrę zarządzającą, proponując działania naprawcze w odniesieniu do najbardziej znaczących odstępstw. Dostarczać sprawozdania dla wyższej kadry zarządzającej i zabiegać o informacje zwrotne z przeglądów dokonywanych przez kierownictwo.

ME1.6 Działania naprawcze Określać i inicjować działania naprawcze w oparciu o monitoring, ocenę i sprawozdania dotyczące wydajności. W tym również działania następcze wobec monitoringu, sprawozdań i ocen, takie jak:• przegląd, uzgodnienie i wprowadzenie zaleceń kierownictwa;• określenie odpowiedzialności za działania naprawcze;• śledzenie efektów podjętych działań.

cele konTrolne

Monitorowanie i ocenaMonitorowanie i ocena wydajności ITME1



Cele i mierniki

PO5 SprawozdaniadotyczącekosztówikorzyściPO10 Sprawozdaniadotyczącewydajnościprojek-

tówAI6 SprawozdaniadotyczącestanuzmianDS1-13 SprawozdaniadotyczącewydajnościprocesuDS3 Planwydajnościipotencjału(wymagania)DS8 Sprawozdaniadotyczącezadowoleniaużyt-

kownikówME2 Sprawozdaniedotycząceefektywności

mechanizmówkontrolnychITME3 Sprawozdaniedotyczącezgodnościdziałal-

nościITzzewnętrznymiwymaganiamipraw-nymi i regulacyjnymi

ME4 Sprawozdaniedotyczącestanunadzoruinformatycznego

Danewejściowewydajnościnapotrzeby PO1 PO2 DS1 planowania ITPlanydziałańnaprawczych PO4 PO8Historycznetrendyryzykaizdarzeń PO9Sprawozdaniedotyczącewydajnościprocesu ME2

• Odstęp czasu między stwierdzeniem niedoskonałości a zainicjowaniem działania

• Opóźnienie w aktualizacji pomiarów, aby odzwierciedlały rzeczywiste cele, miary, wartości docelowe i wartości porównawcze dla wydajności

• Liczba mierników (na proces)• Liczba relacji przyczynowo–skutkowych,

które zidentyfikowano i włączono do monitoringu

• Nakład pracy niezbędny do zgromadzenia danych pomiarowych

• Liczba problemów nie zidentyfikowanych przez proces pomiarowy

• Procent mierników, które mogą być poddane analizie porównawczej względem standardów branżowych i ustalonych celów

• Liczba zmian dotyczących docelowych wartości dla wskaźników efektywności i wydajności procesów IT

• Poziom zadowolenia kierownictwa i jednostki nadzorującej ze sprawozdawczości dotyczącej wydajności

• Liczba wyeliminowanych niedoskonałości procesów

• Poziom zadowolenia interesariuszy z procesu pomiaru

• Procent monitorowanych procesów o krytycznym znaczeniu

• Liczba ulepszeń stymulowanych przez działania monitorujące

• Liczba zrealizowanych celów wydajności (wskaźniki pod kontrolą)

Czynności• Gromadzenie i analiza sprawozdań

dotyczących wydajności i przekładanie ich na sprawozdania zarządcze

• Ocena wydajności w odniesieniu do ustalonych celów oraz inicjowanie niezbędnych działań naprawczych


zgodnie ze wskazówkami zarządu.• Odpowiadać na wymagania biznesowe

zgodnie ze strategią biznesową.• Zapewnić, aby efektywność kosztowa

szła w parze z wysoką jakością usług IT, ich ciągłym doskonaleniem i gotowością do przyszłych zmian.

• Zapewniać przejrzystość i zrozumiałość kosztów, korzyści, strategii, polityk i poziomów usług IT.

Proces• Określić mierzalne cele dla IT

i kluczowych procesów.• Mierzyć, monitorować i raportować

mierniki procesów.• Identyfikować i wdrażać działania

umożliwiające poprawę wydajności.

Czynności


rekto

r gen

eraln

y (CE

O)Dy

rekto

r ds.

finan

sowy

ch (C

FO)

Zarzą

d

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. roz

woju

Kier

ownik

ds. a

dmini

strac

ji IT

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Ustanowienie podejścia do monitorowania. A R C R I C I C I C Identyfikowanie i gromadzenie możliwych do zmierzenia celów wspierających cele biznesowe. C C C A R R RTworzenie kart wyników. A R C R CDokonywanie oceny wydajności. I I A R R C R CSporządzanie raportów dotyczących wydajności. I I I R A R R C R C IIdentyfikowanie i monitorowanie działań związanych z doskonaleniem wydajności. A R R C R C C



Monitorowanie i ocenaMonitorowanie i ocena wydajności IT ME1



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Monitorowanie i ocenawydajności IT”, który spełnia wymaganie biznesowe wobec IT dotyczące przejrzystości i zrozumienia kosztów, korzyści, strategii, polityki i poziomów usług IT zgodnie z wymaganiami nadzoru, jest:

0 Nieistniejące gdyW organizacji nie jest wdrożony proces monitorowania. Dział IT nie prowadzi niezależnego monitorowania projektów ani procesów. Nie są dostępne użyteczne, aktualne i dokładne sprawozdania. Nie dostrzega się potrzeby określenia dobrze zrozumiałych celów procesów.

1 Początkowe/doraźne gdyKierownictwo dostrzega potrzebę gromadzenia i oceny informacji dotyczących procesów monitorowania. Nie są określone standardowe procesy gromadzenia i oceny informacji. Wdrażanie monitorowania i wybór mierników odbywa się na doraźnych zasadach, zależnie od potrzeb określonych projektów i procesów IT. Monitorowanie jest na ogół wdrażane doraźnie w przypadku incydentów, które powodują stratę lub kłopotliwą sytuację dla organizacji. Dział księgowości monitoruje podstawowe wskaźniki finansowe dotyczące działalności IT.

2 Powtarzalne lecz intuicyjne gdyZdefiniowane są podstawowe mierniki, które mają być monitorowane. Istnieją określone metody i techniki gromadzenia i oceny danych, jednak procesy nie są wdrożone w całej organizacji. Interpretacja wyników monitorowania opiera się na kompetencjach kluczowych osób. W celu gromadzenia informacji wybrano i wdrożono ograniczoną liczbę narzędzi, jednak informacje te nie są zbierane w zaplanowany sposób.

3 Zdefiniowane gdyKierownictwo komunikuje i wdraża standardowe procesy monitorowania. Wdrożone są programy kształcenia i szkolenia w dziedzinie monitorowania. Rozwijana jest sformalizowana baza wiedzy zawierająca historyczne informacje dotyczące wydajności. Oceny nadal dokonywane są na poziomie pojedynczych procesów i projektów IT i nie są zintegrowane dla wszystkich procesów. Zdefiniowane są narzędzia do monitorowania procesów i poziomów usług IT. W oparciu o tradycyjne kryteria finansowe i operacyjne zdefiniowane są mierniki wkładu usług informatycznych w działalność całej organizacji. Zdefiniowane są mierniki dotyczące wydajności IT, mierniki niefinansowe, mierniki strategiczne, mierniki zadowolenia klientów oraz poziomy usług. Zdefiniowana jest metodyka pomiaru wydajności.

4 Kontrolowane i mierzalne gdyKierownictwo definiuje granice tolerancji, w których muszą funkcjonować procesy. Sprawozdawczość wyników monitorowania jest ustandaryzowana i znormalizowana. Mierniki są zintegrowane dla wszystkich projektów i procesów IT. Systemy raportowania dotyczące zarządzania organizacją IT są sformalizowane. Zautomatyzowane narzędzia są zintegrowane i wykorzystywane w całej organizacji do gromadzenia i monitorowania informacji dotyczących działania aplikacji, systemów i procesów. Kierownictwo może oceniać wydajność na podstawie uzgodnionych kryteriów, które zostały zatwierdzone przez interesariuszy. Mierniki służące do oceny działalności IT są dostosowane do celów organizacji.

5 Zoptymalizowane gdyRozwijany jest proces ciągłego doskonalenia jakości w zakresie aktualizacji ogólnoorganizacyjnych standardów i polityki monitorowania oraz wdrażania dobrych praktyk stosowanych w branży. Wszystkie procesy monitorowania są zoptymalizowane i wspierają realizację celów organizacji. Rutynowo do pomiaru wydajności stosowane są mierniki dostosowane do potrzeb biznesowych; są one zintegrowane z narzędziami oceny strategicznej, takimi jak zrównoważona karta wyników IT. Monitorowanie procesów i ich stałe doskonalenie są zgodne z ogólnoorganizacyjnymi planami doskonalenia procesów biznesowych. Analizy porównawcze na tle branży i kluczowych konkurentów przybierają sformalizowany charakter i opierają się na zrozumiałych kryteriach.

Model dojrzałości

Monitorowanie i ocenaMonitorowanie i ocena wydajności ITME1


oPis Procesu


Monitorowanie i ocena kontroli wewnętrznej,


dotyczącą ochrony realizacji celów IT oraz zapewnienia zgodności z odpowiednimi przepisami prawa, regulacjami i umowami dotyczącymi IT


monitorowaniu procesów kontroli wewnętrznej w odniesieniu do działalności IT oraz identyfikacji działań doskonalących,


• zdefiniowanie systemu wewnętrznych mechanizmów kontrolnych wbudowanych w strukturę procesów IT;

• monitorowanie i raportowanie efektywności wewnętrznych mechanizmów kontrolnych IT;

• informowanie kierownictwa o błędach zidentyfikowanych w wyniku kontroli w celu podjęcia odpowiednich działań


• liczbę poważnych naruszeń wewnętrznych mechanizmów kontrolnych;

• liczbę inicjatyw udoskonalenia mechanizmów kontrolnych; • liczbę i zakres samoocen mechanizmów kontrolnych.





Me2 Monitorowanie i ocena kontroli wewnętrznej

Wprowadzenie efektywnego programu kontroli wewnętrznej IT wymaga dobrze zdefiniowanego procesu monitorowania. Proces ten obejmuje monitorowanie i raportowanie błędów zidentyfikowanych w wyniku kontroli, rezultatów samooceny oraz przeglądów zewnętrznych. Najważniejszą korzyścią z monitorowania kontroli wewnętrznej jest zapewnienie efektywności i wydajności operacji oraz zgodności z odpowiednimi przepisami prawa i regulacjami.

SS S S SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI


ZARZ

ĄDZA

NIE

RYZY

KIEM




Monitorowanie i ocenaMonitorowanie i ocena kontroli wewnętrznej ME2



ME2.1 Monitorowanie struktury wewnętrznych mechanizmów kontrolnych Stale monitorować, porównywać i doskonalić środowisko kontrolne oraz strukturę mechanizmów kontrolnych IT, aby realizować cele organizacji.

ME2.2 Przegląd nadzorczy Monitorować i oceniać wydajność i efektywność wewnętrznych mechanizmów kontrolnych przeglądu nadzorczego IT.

ME2.3 Błędy zidentyfikowane w wyniku kontroli Identyfikować wyjątki w zakresie kontroli i analizować oraz identyfikować ich przyczyny podstawowe. W odpowiedni sposób przekazywać błędy zidentyfikowane w wyniku kontroli na wyższe poziomy kompetencji i informować interesariuszy. Podejmować niezbędne działania korygujące.

ME2.4 Samoocena kontroli Oceniać kompletność i efektywność kontroli kierownictwa nad procesami, polityką i umowami IT w ramach programu ciągłej samooceny.

ME2.5 Zapewnienie wewnętrznej kontroli W razie potrzeby dodatkowo potwierdzać kompletność i efektywność wewnętrznych mechanizmów kontrolnych poprzez przeglądy zewnętrzne.

ME2.6 Wewnętrzne mechanizmy kontrolne u stron trzecich Dokonywać oceny stanu wewnętrznych mechanizmów kontrolnych u zewnętrznych dostawców usług. Uzyskać potwierdzenie, że działalność zewnętrznych dostawców usług jest zgodna z wymaganiami prawnymi i regulacyjnymi oraz zobowiązaniami umownymi.

ME2.7 Działania naprawcze Identyfikować, inicjować, monitorować i wdrażać działania naprawcze wynikające z ocen i sprawozdań kontrolnych.

cele konTrolne

Monitorowanie i ocenaMonitorowanie i ocena kontroli wewnętrznejME2



Cele i mierniki

AI7 MonitorowaniekontroliwewnętrznejME1 Sprawozdaniedotyczącewydajnościprocesu

Sprawozdaniedotycząceefektywności PO4 PO6 ME1 ME4 mechanizmówkontrolnychIT

• Liczba i zakres samoocen mechanizmów kontrolnych

• Liczba i pokrycie wewnętrznych mechanizmów kontrolnych objętych przeglądem nadzorczym

• Odstęp czasu między wystąpieniem niedoskonałości wewnętrznego mechanizmu kontrolnego a uwzględnieniem jej w sprawozdaniu

• Liczba, częstotliwość i pokrycie sprawozdań dotyczących wewnętrznej zgodności

• Poziom zadowolenia wyższej kadry zarządzającej ze sprawozdań z monitorowania kontroli wewnętrznej

• Liczba poważnych naruszeń wewnętrznych mechanizmów kontrolnych

• Częstotliwość incydentów dotyczących kontroli wewnętrznej

• Liczba niedoskonałości wskazanych przez zewnętrzne raporty kwalifikacyjne i certyfikacyjne

• Liczbę inicjatyw udoskonalenia mechanizmów kontrolnych

• Liczba przypadków braku zgodności z wymaganiami regulacyjnymi lub prawnymi

• Liczba podjętych na czas działań wobec problemów z kontrolą wewnętrzną

Czynności• Zdefiniowanie systemu wewnętrznych

mechanizmów kontrolnych wbudowanych w strukturę procesów IT

• Monitorowanie i raportowanie efektywności wewnętrznych mechanizmów kontrolnych IT

• Informowanie kierownictwa o błędach zidentyfikowanych w wyniku kontroli w celu podjęcia odpowiednich działań


IT były zdolne skutecznie oprzeć się i powrócić do działania po awariach na skutek błędu, celowego ataku lub katastrofy.

• Zabezpieczać osiąganie celów IT.• Zapewniać zgodność IT z przepisami

prawa, wymaganiami regulacyjnymi i umowami.

• Uwzględniać i chronić wszystkie zasoby IT.

Proces• Monitorować realizację celów kontroli

wewnętrznej określonych dla procesów IT.

• Identyfikować działania doskonalące kontrolę wewnętrzną.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Zarzą

d

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. roz

woju

Kier

ownik

ds. a

dmini

strac

ji IT

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Monitorowanie i kontrolowanie działań dotyczących kontroli wewnętrznej w IT. A R R R RMonitorowanie procesu samooceny. I A R R R CMonitorowanie prowadzenia niezależnych przeglądów, audytów i badań. I A R R R CMonitorowanie procesu kontroli wewnętrznej w odniesieniu do mechanizmów kontrolnych stosowanych przez podmioty zewnętrzne. I I I A R R R C

Monitorowanie procesu identyfikacji i oceny wyjątków w zakresie kontroli. I I I A I R R R CMonitorowanie procesu identyfikacji i rozwiązywania problemów dotyczących wyjątków w zakresie kontroli. I I I A I R R R C

Sporządzanie sprawozdań dla głównych interesariuszy. I I I A/R ITabela RACI wskazuje osoby odpowiedzialne (ang. Responsible), rozliczane (Accountable), konsultujące (Consulted) i informowane (Informed).


Monitorowanie i ocenaMonitorowanie i ocena kontroli wewnętrznej ME2



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Monitorowanie i ocena kontroli wewnętrznej”, który spełnia wymaganie biznesowe wobec IT dotyczące ochrony realizacji celów IT oraz zapewnienia zgodności z odpowiednimi przepisami prawa i regulacjami, jest:

0 Nieistniejące gdyW organizacji brakuje procedur monitorowania efektywności wewnętrznych mechanizmów kontrolnych. Nie stosuje się żadnych metod raportowania kierownictwu, w jaki sposób działają wewnętrzne mechanizmy kontrolne. Nie istnieje ogólna świadomość potrzeby zapewnienia bezpieczeństwa operacyjnego i wewnętrznych mechanizmów kontrolnych IT. Kierownictwo i pracownicy nie mają świadomości istnienia wewnętrznych mechanizmów kontrolnych.

1 Początkowe/doraźne gdyKierownictwo dostrzega potrzebę zapewnienia stałego zarządzania i kontroli nad IT. Do oceny adekwatności wewnętrznych mechanizmów kontrolnych kompetencje pojedynczych osób są wykorzystywane w sposób doraźny. Kierownictwo działu IT nie określiło formalnie odpowiedzialności za monitorowanie efektywności wewnętrznych mechanizmów kontrolnych. Oceny wewnętrznych mechanizmów kontrolnych IT dokonuje się w ramach tradycyjnych audytów finansowych z wykorzystaniem metodyki i kwalifikacji, które nie odpowiadają potrzebom funkcji usług informatycznych.

2 Powtarzalne lecz intuicyjne gdyOrganizacja wykorzystuje nieformalne sprawozdania z kontroli, aby inicjować działania korygujące. Ocena kontroli wewnętrznej jest zależna od kwalifikacji kluczowych osób. W organizacji istnieje zwiększona świadomość monitorowania wewnętrznych mechanizmów kontrolnych. Kierownictwo działu IT regularnie monitoruje efektywność wewnętrznych mechanizmów kontrolnych, które uznaje za kluczowe. Do monitorowania wewnętrznych mechanizmów kontrolnych zaczyna się używać metodyki i narzędzi, ale nie towarzyszy temu żaden plan. Czynniki ryzyka właściwe dla środowiska IT są rozpoznawane w oparciu o umiejętności pojedynczych osób.

3 Zdefiniowane gdyKierownictwo wspiera i wprowadza monitorowanie kontroli wewnętrznej. Opracowana jest polityka i procedury oceniania i sprawozdawczości z działań związanych z monitorowaniem kontroli wewnętrznej. Zdefiniowany jest program kształcenia i szkolenia w dziedzinie monitorowania kontroli wewnętrznej. Zdefiniowany jest proces przeglądów służących samoocenie i zapewnieniu kontroli wewnętrznej z przypisanymi rolami dla odpowiedzialnych menedżerów z działu biznesowego i IT. Wykorzystuje się narzędzia, ale niekoniecznie są one zintegrowane ze wszystkimi procesami. W ramach struktur mechanizmów kontrolnych opracowanych specjalnie dla organizacji IT stosuje się politykę oceny ryzyka procesów IT. Zdefiniowana jest polityka dotycząca łagodzenia ryzyka specyficznego dla określonych procesów.

4 Kontrolowane i mierzalne gdyKierownictwo wdraża metodykę monitorowania wewnętrznej kontroli IT. Organizacja określa poziomy tolerancji dla procesu monitorowania kontroli wewnętrznej. Wdrożone są narzędzia umożliwiające standaryzację ocen i automatyczne wykrywanie błędów zidentyfikowanych w wyniku kontroli. Ustanowiona jest formalna funkcja wewnętrznej kontroli IT z wyspecjalizowanymi i certyfikowanymi specjalistami, którzy wykorzystują formalną strukturę mechanizmów kontrolnych zatwierdzoną przez wyższą kadrę zarządzającą. Wykwalifikowani pracownicy działu IT rutynowo uczestniczą w ocenach kontroli wewnętrznej. Istnieje baza wiedzy zawierająca historyczne informacje dotyczące monitorowania kontroli wewnętrznej. W ramach monitorowania kontroli wewnętrznej stosowana jest wzajemna weryfikacja.

5 Zoptymalizowane gdyKierownictwo wprowadza ogólnoorganizacyjny program ciągłego doskonalenia, który uwzględnia zdobyte doświadczenia i branżowe dobre praktyki w dziedzinie monitorowania kontroli wewnętrznej. W stosownych przypadkach organizacja wykorzystuje zintegrowane i aktualizowane narzędzia, które umożliwiają efektywną ocenę kluczowych mechanizmów kontrolnych IT i szybkie wykrywanie incydentów / problemów / wyłączeń dotyczących monitorowania kontroli IT. Formalnie wdrożone są mechanizmy dzielenia się wiedzą dotyczącą funkcji usług informatycznych. Analizy porównawcze dotyczące standardów branżowych i dobrych praktyk mają sformalizowany charakter.

Model dojrzałości

Monitorowanie i ocenaMonitorowanie i ocena kontroli wewnętrznejME2


oPis Procesu


Zapewnianie zgodności z zewnętrznymi regulacjami,


dotyczącą zapewnienia zgodności z wymaganiami prawnymi, regulacyjnymi oraz tymi wynikającymi z umów


określeniu odpowiednich przepisów prawa, regulacji i umów oraz stopnia zgodności z nimi działalności IT, a także na optymalizacji procesów IT w celu ograniczenia ryzyka braku zgodności,


• określenie wymagań prawnych, regulacyjnych oraz tych wynikających z umów, które odnoszą się do IT;

• ocenę wpływu wymagań dotyczących zgodności; • monitorowanie i raportowanie zgodności z tymi wymaganiami


• koszt braku zgodności IT, włączając ugody i grzywny; • średni odstęp czasu między zidentyfikowaniem problemów

dotyczących zgodności z zewnętrznymi regulacjami a ich rozwiązaniem;

• częstotliwość przeglądów zgodności.





Me3 zapewnianie zgodności z zewnętrznymi regulacjami

Efektywny nadzór nad zachowaniem zgodności wymaga wprowadzenia procesu weryfikacji w celu zapewnienia zgodności z wymaganiami prawnymi, regulacyjnymi oraz tymi wynikającymi z umów. Proces ten obejmuje identyfikację wymagań zgodności, optymalizację i ocenę dostosowania, uzyskanie gwarancji spełniania wymagań oraz integrację sprawozdawczości dotyczącej zgodności IT ze sprawozdawczością całej firmy.

SP

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

Monitorowanie i ocenaZapewnianie zgodności z zewnętrznymi regulacjami ME3

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM






ME3.1 określenie zewnętrznych wymagań prawnych, regulacyjnych oraz tych wynikających z umów W ciągły sposób identyfikować lokalne i międzynarodowe przepisy prawa, regulacje i inne zewnętrzne wymagania, z którymi należy zachowywać zgodność, uwzględniając je w politykach, standardach, procedurach i metodykach IT przedsiębiorstwa.

ME3.2 optymalizacja dostosowania do zewnętrznych regulacji Weryfikować i dostosowywać politykę, standardy, procedury i metodyki IT, aby uwzględniały one i komunikowały wymagania prawne, regulacyjne oraz te wynikające z umów.

ME3.3 ocena zgodności z zewnętrznymi regulacjami Potwierdzić zgodność polityki, standardów, procedur i metodyki IT z wymaganiami prawnymi i regulacyjnymi.

ME3.4 Zapewnienie zgodności Uzyskać i dać gwarancję zgodności i przestrzegania wszystkich wewnętrznych polityk wynikających z wewnętrznych wytycznych lub zewnętrznych wymagań prawnych, regulacyjnych oraz tych wynikających z umów, potwierdzając, że odpowiedzialny właściciel procesu podjął w odpowiednim czasie wszelkie działania naprawcze, aby wyeliminować braki zgodności.

ME3.5 Zintegrowana sprawozdawczość Zintegrować sprawozdawczość IT dotyczącą zgodności z wymaganiami prawnymi, regulacyjnymi i tymi wynikającymi z umów z analogiczną sprawozdawczością innych funkcji biznesowych.

cele konTrolne

Monitorowanie i ocenaZapewnianie zgodności z zewnętrznymi regulacjamiME3



Cele i mierniki

* Wymaganiadotyczącezapewnieniazgodno-ścizprzepisamiprawairegulacjami

PO6 PolitykaIT

*DanewejściowespozastrukturyCobiT

Katalogwymagańprawnychiregulacyjnych dotyczącychświadczeniausługIT PO4 ME4SprawozdaniedotyczącezgodnościdziałalnościIT zzewnętrznymiwymaganiamiprawnymi ME1 i regulacyjnymi

• Średni odstęp czasu między zidentyfikowaniem problemów dotyczących zgodności z zewnętrznymi regulacjami a ich rozwiązaniem

• Średni odstęp czasu między publikacją nowych przepisów prawa lub regulacji a zainicjowaniem przeglądu zgodności

• Liczba dni szkoleniowych na pracownika IT rocznie przeznaczonych na szkolenie w dziedzinie zapewnienia zgodności

• Koszt braku zgodności IT, włączając ugody i grzywny

• Liczba problemów związanych z brakiem zgodności; zgłoszonych zarządowi lub wywołujących publiczne komentarze bądź kłopotliwą sytuację

• Liczba krytycznych problemów związanych z brakiem zgodności rocznie

• Częstotliwość przeglądów zgodności

Czynności• Określenie wymagań prawnych,

regulacyjnych i wynikających z umów, które odnoszą się do IT

• Edukowanie personelu IT w kwestii odpowiedzialności za zapewnienie zgodności

• Ocena wpływu wymagań dotyczących zgodności

• Monitorowanie i raportowanie zgodności z zewnętrznymi wymaganiami

IT• Zapewnić zgodność IT z przepisami

prawa, wymaganiami regulacyjnymi i umowami.

Proces• Zidentyfikować odpowiednie przepisy

prawa, regulacje i umowy i określić stopień zgodności IT.

• Zapewnić dostosowanie polityki, planów i procedur IT, aby efektywnie zarządzać ryzykiem braku zgodności.

• Minimalizować wpływ problemów z zapewnieniem zgodności IT na działalność firmy.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Zarzą

d

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. roz

woju

Kier

ownik

ds. a

dmini

strac

ji IT

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Definiowanie i wykonywanie procesu służącego identyfikacji wymogów prawnych i regulacyjnych oraz wymogów wynikających z umów i polityk. A/R C I I I C I RDokonywanie oceny zgodności działań w obszarze IT z politykami, planami i procedurami IT. I I I A/R I R R R R R R ISkładanie sprawozdań dotyczących pozytywnych wyników w zakresie zapewniania zgodności działań w obszarze IT z politykami, planami i procedurami IT. A/R C C C C C C RUczestnictwo w działaniach na rzecz dostosowywania polityk, planów i procedur IT do wymogów zgodności. A/R C C C C C RIntegracja sprawozdawczości IT dotyczącej wymogów prawnych z podobnymi raportami pochodzącymi z innych funkcji biznesowych. A/R I I I R I R



Monitorowanie i ocenaZapewnianie zgodności z zewnętrznymi regulacjami ME3



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zapewnianie zgodności z zewnętrznymi regulacjami”, który spełnia wymaganie biznesowe wobec iT dotyczące zapewnienia zgodności z wymaganiami prawnymi, regulacyjnymi oraz tymi wynikającymi z umów, jest:

0 Nieistniejące gdyIstnieje niewielka świadomość zewnętrznych regulacji, które odnoszą się do IT i nie istnieje żaden proces zapewnienia zgodności z wymaganiami regulacyjnymi, prawnymi oraz tymi wynikającymi z umów.

1 Początkowe/doraźne gdyIstnieje świadomość istnienia wymagań regulacyjnych, prawnych oraz tych wynikających z umów, które mają wpływ na organizację. Funkcjonują nieformalne procesy służące zapewnieniu zgodności, ale tylko w przypadku, gdy jest to związane z potrzebą realizacji nowego projektu lub w następstwie audytów albo przeglądów.

2 Powtarzalne lecz intuicyjne gdyIstnieje zrozumienie potrzeby zapewnienia zgodności z zewnętrznymi regulacjami i potrzeba ta jest komunikowana. W dziedzinach, w których zapewnienie zgodności jest powtarzalnym wymogiem (np. w przypadku regulacji finansowych czy przepisów dotyczących ochrony prywatności), opracowane są specjalne procedury, które obowiązują w cyklu rocznym. Nie jest to jednak standardowe podejście. W wysokim stopniu polega się na wiedzy i odpowiedzialności pojedynczych osób i istnieje duże prawdopodobieństwo wystąpienia błędów. Odbywają się nieformalne szkolenia dotyczące zewnętrznych regulacji i kwestii zgodności.

3 Zdefiniowane gdyW celu zapewnienia zgodności z wymaganiami regulacyjnymi, prawnymi i wynikającymi z umów istnieją opracowane, udokumentowane i komunikowane polityki, plany i procedury, jednak niektóre z nich nie zawsze są przestrzegane, a inne mogą być nieaktualne lub niepraktyczne, jeśli chodzi o możliwości wdrożenia. Monitorowanie ma niewielki zakres i istnieją wymagania dotyczące zgodności, które nie zostały uwzględnione. Odbywają się szkolenia w zakresie zewnętrznych wymagań prawnych i regulacyjnych odnoszących się do organizacji, a także zdefiniowanego procesu zapewnienia zgodności. Istnieją standardowe ogólne wzory umów i procesy prawne w celu minimalizacji ryzyka związanego z odpowiedzialnością umowną.

4 Kontrolowane i mierzalne gdyW pełni rozumiane są problemy i zagrożenia związane z zewnętrznymi wymaganiami oraz potrzeba zapewnienia zgodności na wszystkich poziomach. Istnieje formalny program szkoleń mający zapewnić, aby wszyscy pracownicy byli świadomi swoich obowiązków związanych z zapewnieniem zgodności. Wyraźnie określony jest zakres odpowiedzialności i rozumiana jest własność procesu. Proces obejmuje przegląd środowiska służący identyfikacji zewnętrznych wymagań i zachodzących zmian. Istnieje mechanizm umożliwiający monitorowanie przypadków braku zgodności z zewnętrznymi wymaganiami, egzekwowanie wewnętrznych praktyk i wdrażanie działań naprawczych. Przypadki braku zgodności są standardowo analizowane pod kątem przyczyn podstawowych w celu znalezienia trwałych rozwiązań. W określonych przypadkach, dotyczących np. obowiązujących regulacji czy powtarzalnych umów serwisowych, stosuje się ustandaryzowane wewnętrzne dobre praktyki.

5 Zoptymalizowane gdyIstnieje dobrze zorganizowany, wydajny i egzekwowany proces zapewnienia zgodności z zewnętrznymi regulacjami, oparty na pojedynczej, centralnej funkcji, która zapewnia doradztwo i koordynację dla całej organizacji. Istnieje rozległa wiedza na temat obowiązujących zewnętrznych regulacji oraz przyszłych trendów i przewidywanych zmian, a także potrzeba nowych rozwiązań. Organizacja bierze udział w zewnętrznych dyskusjach z organami regulacyjnymi i grupami branżowymi, aby lepiej rozumieć i wpływać na kształtowanie dotyczących jej zewnętrznych regulacji. Rozwijane są dobre praktyki zapewniające skutecznie zgodność z zewnętrznymi regulacjami, co pozwala ograniczyć do minimum przypadki braku zgodności. Istnieje centralny, obejmujący całą organizację system nadzoru, umożliwiający kierownictwu dokumentowanie toku pracy oraz pomiar i doskonalenie jakości i efektywności procesu monitorowania zgodności. Wdrożony proces samooceny zgodności z zewnętrznymi regulacjami został udoskonalony do poziomu dobrej praktyki. Styl i kultura zarządzania organizacją w odniesieniu do zapewnienia zgodności są odpowiednio ugruntowane, a procesy są na tyle dobrze zaprojektowane, aby szkolenia można było ograniczyć tylko do nowego personelu oraz przypadków znaczących zmian.

Model dojrzałości

Monitorowanie i ocenaZapewnianie zgodności z zewnętrznymi regulacjamiME3


oPis Procesu


Zapewnienie ładu informatycznego,


dotyczącą integracji ładu informatycznego z ładem korporacyjnym i zapewnienia zgodności z przepisami prawa, regulacjami i umowami


sporządzaniu sprawozdań dla zarządu dotyczących strategii, wydajności i ryzyka IT oraz dostosowywaniu się do wymagań nadzoru zgodnie ze wskazówkami zarządu,


• ustanowienie ram ładu informatycznego w ramach ładu korporacyjnego; • uzyskanie niezależnego potwierdzenia stanu ładu informatycznego


• częstotliwość sprawozdań zarządu dotyczących IT dla interesariuszy (łącznie z oceną stanu dojrzałości);

• częstotliwość sprawozdań działu IT dla zarządu (łącznie z oceną stanu dojrzałości);

• częstotliwość niezależnych przeglądów zgodności IT.





Me4 zapewnienie ładu informatycznego

Ustanowienie efektywnego ładu informatycznego obejmuje zdefiniowanie struktur organizacyjnych, procesów, kierownictwa, ról i zakresów odpowiedzialności, które zapewnią, że inwestycje w dziedzinie IT będą dostosowane i zrealizowane zgodnie ze strategią i celami przedsiębiorstwa.

S S S S SP P

Efektyw

ność

Wydajno

śćPouf

ność

Integra

lność

Dostępn

ośćZgod

ność

Wiarygod

ność

Osoby

Informacj

a

Aplikacj

e

Infrast

ruktura

DOPASOWANIE

STRATEGICZNE

POMIAR

WYDAJNOŚCI

DOSTARCZANIE

WARTOŚCI

ZARZ

ĄDZA

NIE

RYZY

KIEM




Monitorowanie i ocenaZapewnienie ładu informatycznego ME4



ME4.1 Ustanowienie ram ładu informatycznego Zdefiniować, ustanowić i dostosować ramy ładu informatycznego do ogólnych zasad ładu korporacyjnego i środowiska mechanizmów kontrolnych. Oprzeć strukturę na odpowiednim procesie IT i modelu kontrolnym oraz jednoznacznie określić kwestie odpowiedzialności i odpowiednich praktyk, aby uniknąć niepowodzeń kontroli wewnętrznej i przeoczeń. Potwierdzić, że ramy ładu informatycznego zapewniają zgodność z przepisami prawa i regulacjami oraz że są dostosowane i umożliwiają realizację strategii i celów przedsiębiorstwa. Sporządzać sprawozdania na temat stanu i problemów dotyczących ładu informatycznego.

ME4.2 Dopasowanie strategiczne Umożliwić zarządowi i kierownictwu zrozumienie strategicznych zagadnień dotyczących IT, takich jak rola IT, wykorzystywane technologie czy potencjał IT. Zapewnić porozumienie między stroną biznesową i IT co do wkładu potencjału IT w realizację strategii biznesowej. Współpracować z zarządem i utworzonymi organami nadzorującymi, takimi jak komitet strategiczny ds. IT, w celu określenia kierunku strategicznego dla zarządzania IT, dbając o to, aby przyjęta strategia i cele zostały przekazane do jednostek biznesowych i funkcji IT oraz aby współpraca między stroną biznesową i IT przebiegała w atmosferze wzajemnego zaufania. Umożliwić dopasowanie strategiczne i operacyjne działalności IT do działalności biznesowej, zachęcając do współodpowiedzialności za podejmowanie strategicznych decyzji i odnoszenia korzyści z inwestycji opartych o technologie IT.

ME4.3 Dostarczanie wartości Zarządzać programami inwestycji opartych o technologie IT oraz innymi zasobami i usługami IT, aby wnosiły one możliwie jak największą wartość w realizację strategii i celów przedsiębiorstwa. Zapewnić: zrozumienie oczekiwanych korzyści biznesowych z inwestycji opartych o technologie IT oraz całego zakresu nakładów niezbędnych do ich osiągnięcia; opracowanie kompleksowych i spójnych uzasadnień biznesowych oraz ich zatwierdzenie przez interesariuszy; zarządzanie zasobami i inwestycjami w całym cyklu ich życia; aktywne zarządzanie realizacją korzyści — np. poprzez wkład w nowe usługi, wzrost wydajności czy skrócenie czasu reakcji na żądania użytkowników. Egzekwować zdyscyplinowane podejście do zarządzania portfelem, programami i projektami, dbając o to, aby strona biznesowa przejmowała własność inwestycji opartych o technologie IT, a strona IT zapewniała optymalizację kosztów udostępniania potencjału i usług IT.

ME4.4 Zarządzanie zasobami Nadzorować inwestycje, wykorzystanie i alokację zasobów IT poprzez dokonywanie regularnych ocen inicjatyw i operacji IT w celu zapewnienia odpowiedniej optymalizacji zasobów ich dostosowania do aktualnych i przyszłych celów strategicznych i wymagań biznesowych.

ME4.5 Zarządzanie ryzykiem We współpracy z zarządem określić skłonność przedsiębiorstwa do podejmowania ryzyka w dziedzinie IT i uzyskać pewność, że praktyki zarządzania ryzykiem IT są na tyle skuteczne, by rzeczywiste ryzyko IT nie przekraczało akceptowanego poziomu. Uwzględnić w strukturze organizacyjnej odpowiedzialność za zarządzanie ryzykiem, zapewniając, aby strona biznesowa i IT regularnie oceniały i informowały o ryzyku związanym z działalnością IT oraz by stosunek przedsiębiorstwa do ryzyka IT był przejrzysty dla wszystkich interesariuszy.

ME4.6 Pomiar wydajności Potwierdzić, że uzgodnione cele IT zostały osiągnięte bądź przekroczone lub że postęp w realizacji celów IT jest zgodny z oczekiwaniami. W przypadku, gdy cele nie zostały osiągnięte lub postęp nie jest zgodny z oczekiwaniami, należy dokonać przeglądu działań naprawczych podjętych przez kierownictwo. Przekazywać zarządowi sprawozdania na temat odpowiednich portfeli, programu i wydajności IT, aby umożliwić wyższej kadrze zarządzającej ocenę postępu przedsiębiorstwa w realizacji określonych celów.

ME4.7 Niezależna gwarancja Uzyskać niezależne potwierdzenie (wewnętrzne lub zewnętrzne) zgodności działalności IT z odpowiednimi przepisami prawa i regulacjami, polityką, standardami i procedurami przedsiębiorstwa, ogólnie przyjętymi praktykami oraz wymogiem efektywnego i wydajnego działania.

cele konTrolne

Monitorowanie i ocenaZapewnienie ładu informatycznegoME4



Cele i mierniki

PO4 Struktura procesu ITPO5 Sprawozdaniadotyczącekosztówikorzyści PO9 Ocena i raportowanie ryzykaME2 Sprawozdaniedotycząceefektywności

mechanizmówkontrolnychITME3 Katalogwymagańprawnychiregulacyjnych

dotyczącychświadczeniausługIT

Udoskonaleniastrukturyprocesów PO4Sprawozdaniedotyczącestanunadzoru PO1 ME1 informatycznegoOczekiwanekorzyścibiznesowezinwestycji opartych o technologie IT PO5KierunekstrategicznydlaITokreślonyprzez PO1 przedsiębiorstwoSkłonnośćprzedsiębiorstwadopodejmowania PO9 ryzykawdziedzinieIT

• Procent pracowników przeszkolonych w dziedzinie zachowania ładu (np. kodeksu postępowania)

• Liczba specjalistów ds. etyki na dział• Częstotliwość występowania zagadnienia

ładu informatycznego w porządku obrad na spotkaniach poświęconych kierowaniu/strategii IT

• Procent członków zarządu przeszkolonych lub mających doświadczenie w dziedzinie nadzoru informatycznego

• Wiek uzgodnionych rekomendacji• Częstotliwość informowania zarządu

o wynikach badań zadowolenia interesariuszy

• Liczba przypadków, gdy problematykę IT wprowadzono w aktywny sposób do porządku obrad zarządu

• Częstotliwość sprawozdań zarządu dotyczących IT dla interesariuszy (łącznie z oceną stanu dojrzałości)

• Liczba aktualnych zagadnień IT, którymi zajmuje się zarząd

• Częstotliwość sprawozdań działu IT dla zarządu (łącznie z oceną stanu dojrzałości)

• Liczba naruszeń ładu• Częstotliwość niezależnych przeglądów

zgodności IT

Czynności• Ustanowienie ram ładu informatycznego

w ramach ładu korporacyjnego• Uzyskanie niezależnego potwierdzenia

stanu ładu informatycznego


zgodnie z oczekiwaniami zarządu.• Zapewniać przejrzystość i zrozumiałość

kosztów, korzyści, strategii, polityki i poziomów usług IT.

• Zapewniać zgodność IT z przepisami prawa, wymaganiami regulacyjnymi i umowami.


Proces• Zintegrować cele ładu informatycznego

z celami ładu korporacyjnego.• Opracowywać kompletne i aktualne

sprawozdania dla zarządu dotyczące strategii, wydajności i ryzyka IT.

• Odpowiadać na wątpliwości i zapytania zarządu dotyczące strategii, wydajności i ryzyka IT.

• Uzyskać niezależne potwierdzenie dotyczące zgodności z polityką, planami i procedurami IT.

Czynności

Tabela RACI Funkcje

Dyrek

tor g

ener

alny (

CEO)

Dyrek

tor d

s. fin

anso

wych

(CFO

)

Zarzą

d

Człon

ek za

rządu

Dyrek

tor d

s. inf

ormat

yki (C

IO)

Właścic

iel pr

oces

u bizn

esow

ego

Kier

ownik

dział

u ope

racy

jnego

Głów

ny ar

chite

ktKi

erow

nik ds

. roz

woju

Kier

ownik

ds. a

dmini

strac

ji IT

Kier

ownik

biur

a zar

ządz

ania

proje

ktami (P

MO)Ko

ntro

la we

wnętr

zna;

Audy

t;

Zarzą

dzan

ie ryz

ykiem

i bez

piecz

eństw

em

Ustanowienie nadzoru wykonawczego i zarządczego oraz wspieranie działalności w obszarze IT. A R C C C CDokonywanie przeglądu, zatwierdzanie i dostosowywanie wydajności IT, strategii IT, zarządzania zasobami i ryzykiem do strategii biznesowej i przekazywanie informacji na jej rzecz. A R I I R CUzyskiwanie okresowej niezależnej oceny wydajności i zgodności z politykami, planami i procedurami. A R C I C I I I I I RAnalizowanie wyników niezależnych ocen oraz zapewnianie wdrożenia uzgodnionych zaleceń przez kierownictwo. A R C I C I I I I I RGenerowanie raportu dotyczącego nadzoru informatycznego. A C C C R C I I I I I C



Monitorowanie i ocenaZapewnienie ładu informatycznego ME4



Cele

Mie

rnik

i

usta-lenie

usta-lenie

stymulacja

stymulacja



Zarządzanie procesem „Zapewnienie ładu informatycznego”, który spełnia wymaganie biznesowe wobec IT dotyczące integracji ładu informatycznego z ładem korporacyjnym i zachowania zgodności z przepisami prawa i regulacjami, jest:

0 Nieistniejące gdyW ogóle nie istnieje rozpoznawalny proces zapewniania ładu informatycznego. Organizacja nie dostrzega istnienia problemu, który wymaga rozwiązania. Dlatego nie ma żadnej wymiany informacji na ten temat.

1 Początkowe/doraźne gdyIstnieje świadomość istnienia problemu ładu informatycznego i potrzeba jego rozwiązania. W poszczególnych przypadkach stosuje się doraźne rozwiązania. Kierownictwo działa w doraźny sposób i tylko sporadycznie i niekonsekwentnie informuje o problemach i podejściach do ich rozwiązania. Kierownictwo dysponuje tylko przybliżonymi informacjami na temat wkładu działalności IT w działalność biznesową. Kierownictwo tylko doraźnie reaguje na incydenty, które powodują stratę lub kłopotliwą sytuację dla organizacji.

2 Powtarzalne lecz intuicyjne gdyIstnieje świadomość problemów związanych z zapewnieniem ładu informatycznego. Działania związane z zapewnieniem ładu informatycznego i wskaźniki wydajności, które obejmują procesy planowania, dostarczania i monitorowania działalności IT, są na etapie rozwoju. W oparciu o indywidualne decyzje identyfikowane są procesy wymagające udoskonalenia. Kierownictwo określa podstawowe mierniki ładu informatycznego oraz metody i techniki oceny, jednak proces ten nie jest wdrożony w całej organizacji. Komunikacja dotycząca standardów i zakresu odpowiedzialności w dziedzinie zapewnienia ładu jest pozostawiona indywidualnemu uznaniu. Pojedyncze osoby realizują proces zapewnienia ładu w ramach różnych projektów i procesów IT. Procesy, narzędzia i mierniki służące ocenie ładu informatycznego IT są ograniczone i mogą nie być używane w pełnym zakresie z powodu braku wiedzy na temat sposobu ich działania.

3 Zdefiniowane gdyKierownictwo zdaje sobie sprawę z wagi potrzeby zapewnienia ładu informatycznego i informuje o tym w ramach organizacji. Opracowany jest podstawowy zbiór wskaźników ładu informatycznego wraz ze zdefiniowanymi i udokumentowanymi relacjami między miarami wyników a wskaźnikami wydajności. Procedury są ustandaryzowane i udokumentowane. Kierownictwo informuje o ustandaryzowanych procedurach i prowadzone są szkolenia. Zostały określone narzędzia pomocne w pełnieniu nadzoru nad ładem informatycznym. Zdefiniowano panele kontrolne jako element zrównoważonej karty wyników biznesowych IT. Kwestia szkolenia, przestrzegania i stosowania standardów jest jednak pozostawiona indywidualnemu uznaniu. Procesy mogą być monitorowane, jednak istnieje niewielkie prawdopodobieństwa wykrycia odstępstw / błędów / incydentów przez kierownictwo, ponieważ większość działań jest realizowanych z indywidualnej inicjatywy.

4 Kontrolowane i mierzalne gdyIstnieje pełne zrozumienie zagadnienia ładu informatycznego na wszystkich poziomach. Precyzyjnie określono, kto jest klientem, a zdefiniowany zakres odpowiedzialności jest monitorowany poprzez umowy SLA. Wyraźnie określony jest zakres odpowiedzialności i ustalona jest własność procesu. Procesy informatyczne i ład informatyczny są dostosowane i zintegrowane ze strategią biznesową i strategią IT. Doskonalenie procesów IT opiera się głównie na analizie ilościowej i możliwe jest monitorowanie i pomiar zgodności z procedurami i miernikami procesów. Wszyscy interesariusze procesów są świadomi ryzyka, znaczenia technologii IT i możliwości, które może zaoferować. Kierownictwo definiuje granice tolerancji, w których muszą funkcjonować procesy. Technologia jest wykorzystywana w ograniczonym, głównie taktycznym wymiarze oraz w oparciu o dojrzałe techniki i narzucone standardowe narzędzia. Nadzór informatyczny jest zintegrowany z procesami planowania strategicznego i operacyjnego oraz monitoringu. Wskaźniki wydajności wszystkich działań związanych z zapewnieniem ładu informatycznego są rejestrowane i monitorowane, co pozwala na udoskonalenia w skali całego przedsiębiorstwa. Jasno określona jest ogólna odpowiedzialność za wydajność kluczowych procesów, a efektywne zarządzanie jest nagradzane w oparciu o kluczowe wskaźniki wydajności.

5 Zoptymalizowane gdyIstnieje pogłębione i ukierunkowane na przyszłość zrozumienie zagadnień i rozwiązań dotyczących zapewnienia ładu informatycznego. Szkolenia i komunikacja są wspierane przez najnowsze koncepcje i rozwiązania techniczne. W oparciu o efekty ciągłego doskonalenia i modelowania dojrzałości we współpracy z innymi organizacjami procesy zostały udoskonalone do poziomu dobrej praktyki branżowej. Dzięki wdrożeniu odpowiedniej polityki IT organizacja, personel i procesy mają zdolność do szybkiej adaptacji i w pełni wspierają wymagania ładu informatycznego. Wszystkie problemy i odstępstwa są analizowane pod kątem przyczyn podstawowych i w odpowiedniej chwili podejmowane są skuteczne działania zaradcze. Technologie IT są wykorzystywane w szerokim zakresie oraz w zintegrowany i zoptymalizowany sposób w celu automatyzacji toku pracy oraz poprawy jakości i wydajności. Ryzyko i wyniki procesów IT są zdefiniowane, zrównoważone i komunikowane w całym przedsiębiorstwie. Korzysta się ze wskazówek zewnętrznych ekspertów oraz z analiz porównawczych. W organizacji powszechnie stosuje się monitoring, dokonuje samooceny i informuje o oczekiwaniach związanych z zapewnieniem ładu. W optymalny sposób wykorzystuje się technologię do wspierania pomiarów, analiz, komunikacji i szkolenia. Ład korporacyjny i informatyczny są strategicznie powiązane, a zasoby ludzkie, technologiczne i finansowe są wykorzystywane do zwiększania przewagi konkurencyjnej przedsiębiorstwa. Działania związane z zapewnieniem ładu informatycznego są zintegrowane z procesem zapewnienia ładu korporacyjnego.

Model dojrzałości

Monitorowanie i ocenaZapewnienie ładu informatycznegoME4

z a ł ą c z n i k i

T a b e l e P o w i ą z a ń c e l ó w i P r o c e s ó w

WtymzałącznikuprzedstawionocałościowąstrukturępowiązańogólnychcelówbiznesowychzcelamiIT,procesamiITorazkryteriamiinformacji.Zawieraontrzytabele:1.Pierwszatabelaprezentujeprzyporządkowaniecelówbiznesowych,uszeregowanychzgodniezezrównoważonąkartąwyników,docelówITikryteriówinformacji.Pomagatookreślić—wodniesieniudodanegoogólnegocelubiznesowego—celeIT,którezwyklewspierająrealizacjętegocelu,orazkryteriainformacjiCobiT,któreodnosząsiędotegocelubiznesowego.Zbioru17celównienależytraktowaćjakopełnegozestawieniawszystkichmożliwychcelówbiznesowych.Jesttowybóristotnychcelówbiznesowych,któremogąmiećwyraźnywpływnadziałalnośćwdziedzinieIT(celebiznesowepowiązanezdziałalnościąIT).

2.WdrugiejtabeliprzedstawionoprzyporządkowaniecelówITdoprocesówITikryteriówinformacjiCobiT,naktórychopierająsięceleIT.

3.Trzeciatabelaprezentujeodwrotneprzyporządkowanie,wskazującdlakażdegoprocesuITwpieraneprzezniegoceleIT.

TabeleilustrujązakresmetodykiCobiTiogólnerelacjebiznesowemiędzymetodykąCobiT aczynnikamibiznesowymi,umożliwiającprzyporządkowanietypowychcelówbiznesowychpowiązanychzdziałalnościąITdoprocesówITniezbędnychdoichwparcia(poprzezceleIT).Wtabelachprzedstawionoogólnecele,dlategonależytraktowaćjejakozbiórwytycznych,którewymagajądostosowaniadospecyfikidanegoprzedsiębiorstwa.

WceluzapewnieniaodniesieniadokryteriówinformacjidotyczącychwymagańbiznesowychwramachmetodykiCobiT 3rdEditiontabeleprzedstawiająrównieżnajważniejszekryteriainformacjiwspieraneprzezcelebiznesoweiceleIT.

Uwagi:1.KryteriainformacjiprzedstawionewtabelidotyczącejcelówbiznesowychzostałyokreślonenapodstawieagregacjikryteriówdlapowiązanychcelówITorazsubiektywnejocenykryteriów,któresąnajbardziejistotnedladanegocelubiznesowego.Niepróbowanookreślać,któremająpierwszorzędne,aktóredrugorzędneznaczenie.Mająonewyłączniepoglądowycharakter,abyużytkownicymogliprzeprowadzićpodobnyproces,dokonującocenywłasnychcelówbiznesowych.

2.OdniesieniadokryteriówinformacjiopierwszorzędnymidrugorzędnymznaczeniuwtabelidotyczącejcelówITzostałyokreślonenapodstawieagregacjikryteriówdlakażdegozprocesówITorazsubiektywnejocenyjegoznaczeniadladanegoceluIT,ponieważniektóreprocesymająwiększeznaczeniedlarealizacjicelówITniżinne.Mająonewyłączniepoglądowycharakter,abyużytkownicymogliprzeprowadzićpodobnyproces,dokonującocenywłasnychcelówIT.

Za

łą

cZ

nik i

Ce

Le


Cele

bizn

esow

e

Kryte

ria in

form

acji C

OBIT

Cele

IT

Pers

pekt

ywa

fina

nsow

a

Pers

pekt

ywa

klie

nta

Pers

pekt

ywa

wew

nętr

zna

Pers

pekt

ywa

dot

yczą

cauc

zeni

a s

ię i

rozw

oju

Efektywność WydajnośćPoufnośćIntegralność DostępnośćZgodnośćWiarygodność

Zape

wnić

wysk

oki z

wrot

z inw

estyc

ji w za

kresie

obsz

aru IT

.

24

✔

Zarzą

dzać

ryzy

kiem

bizne

sowy

m zw

iązan

ym z

obsz

arem

IT.

2 14

17

18

19

20

21

22

✔

✔ ✔

Popra

wić ł

ad ko

rporac

yjny i

prze

jrzys

tość.

2

18

✔

Popra

wić o

rienta

cję na

klien

ta i p

oziom

świad

czen

ia us

ług.

3

23

✔

Ofero

wać k

onku

rency

jne pr

oduk

ty i u

sługi.

5

24

✔ ✔

Zape

wniać

ciąg

łość d

ziałan

ia i d

ostęp

ność

usług

.

10

16

22

23

✔

✔

Stwo

rzyć m

ożliw

ości

spraw

nego

reag

owan

ia na

zmien

iając

e się

wyma

gania

bizn

esow

e.

1 5

25

✔

✔

Osiąg

nąć o

ptyma

lizac

ję ko

sztów

świad

czen

ia us

ług.

7

8 10

24

✔

Uzys

kiwać

wiar

ygod

ne i p

rzyda

tne in

forma

cje sł

użąc

e pod

ejmow

aniu

decy

zji str

ategic

znyc

h.

2 4

12

20

26

✔

✔

✔

Popra

wić i

utrzy

mywa

ć fun

kcjon

alnoś

ć proc

esów

bizn

esow

ych.

6

7 11

✔ ✔

Obniż

yć ko

szty

proce

sów.

7 8

13

15

24

✔

Zape

wniać

zgod

ność

z ze

wnętr

znym

i prze

pisam

i, reg

ulacja

mi or

az um

owam

i.

2 19

20

21

22

26

27

✔

✔

Zape

wniać

zgod

ność

z po

lityka

mi w

ewnę

trzny

mi.

2

13

✔

✔

Zarzą

dzać

zmian

ami w

dział

alnoś

ci prz

edsię

biorst

wa.

1

5 6

11

28

✔

✔

Polep

szyć

i utrz

ymyw

ać pr

oduk

tywno

ść op

eracy

jną i p

racow

ników

.

7 8

11

13

✔ ✔

Zarzą

dzać

inno

wacja

mi w

zakre

sie pr

oduk

tów i d

ziałal

nośc

i prze

dsięb

iorstw

a.

5 25

28

✔ ✔

Pozy

skiw

ać i u

trzym

ywać

wyk

walifi

kowa

nych

i zmo

tywow

anyc

h prac

ownik

ów.

9

✔

✔

1 2 3 4 5 6 7 8 9

10 11 12 13 14 15 16 17

ZałącZnik i

POw

iąza

Nie

Cel

ów b

izN

esOw

yCh

z C

elaM

i it

załą

cznik i — Tabe

le Powiąza

ń cel

ów i Pr

oce

sów

Za

łą

cZ

nik i

Ce

Le


CobiT 4.1

Odpo

wiad

ać na

wym

agan

ia biz

neso

we zg

odnie

ze st

rateg

ią biz

neso

wą.

Odpo

wiad

ać na

wym

agan

ia na

dzoru

zgod

nie z

ocze

kiwan

iami z

arząd

u.

Zape

wnić,

aby u

żytko

wnicy

końc

owi b

yli za

dowo

leni z

ofert

y i po

ziomó

w us

ług.

Zopty

maliz

ować

wyk

orzys

tanie

inform

acji.

Zape

wnić

zdoln

ość s

zybk

iego r

eago

wania

IT.

Okreś

lić, w

jaki

spos

ób fu

nkcjo

nalne

i kon

trolne

wym

agan

ia biz

neso

we są

prze

kłada

ne na

efek

tywne

i wyd

ajne r

ozwi

ązan

ia za

utoma

tyzow

ane.

Naby

wać i

utrzy

mywa

ć zint

egrow

ane i

ustan

daryz

owan

e sys

temy a

plika

cji.

Naby

wać i

utrzy

mywa

ć zint

egrow

aną i

ustan

daryz

owan

ą infr

astru

kturę

IT.

Naby

wać i

utrzy

mywa

ć umi

ejętno

ści in

forma

tyczn

e, któ

re od

powi

adają

strat

egii I

T.

Zape

wnić

obus

tronn

e zad

owole

nie z

relac

ji z ze

wnętr

znym

i dos

tawca

mi.

Zape

wnić

bezp

roblem

ową i

ntegra

cję ap

likac

ji z pr

oces

ami b

iznes

owym

i.

Zape

wnić

przejr

zysto

ść i z

rozum

iałoś

ć kos

ztów,

korzy

ści, s

trateg

ii, po

lityk i

pozio

mów

usług

IT.

Zape

wnić

prawi

dłowe

wyk

orzys

tanie

i wyd

ajość

aplik

acji o

raz st

osow

anyc

h roz

wiąz

ań te

chnic

znyc

h.

Uwzg

lędnia

ć i ch

ronić

wszy

stkie

zaso

by IT

.

Zopty

maliz

ować

infra

struk

turę,

zaso

by i p

otenc

jał IT

.

Ogran

iczyć

nied

osko

nałoś

ci w

dosta

rczan

iu roz

wiąz

ań i u

sług o

raz ko

niecz

ność

ich u

suwa

nia.

Zabe

zpiec

zać o

siąga

nie ce

lów IT

.

Zape

wnić

przejr

zysto

ść w

pływu

ryzy

ka bi

znes

oweg

o na c

ele i z

asob

y IT.

Zape

wnić,

aby n

ieupra

wnion

e oso

by ni

e miał

y dos

tępu d

o kluc

zowy

ch i p

oufny

ch in

forma

cji.

Zape

wnić,

aby m

ożna

było

poleg

ać na

zauto

matyz

owan

ych t

ransa

kcjac

h bizn

esow

ych i

proc

esac

h wym

iany i

nform

acji.

Zape

wnić,

aby u

sługi

i infra

struk

tura I

T były

zdoln

e praw

idłow

o oprz

eć si

ę i po

wróc

ić do

dział

ania

po aw

ariac

h na s

kutek

błęd

u, ce

loweg

o atak

u lub

katas

trofy.

Zape

wnić,

aby p

otenc

jalne

zakłó

cenie

lub z

mian

a w do

stępn

ości

usług

IT m

iała m

inima

lny ne

gatyw

ny w

pływ

na dz

iałaln

ość b

iznes

ową.

Zape

wnić

dostę

pnoś

ć usłu

g IT a

dekw

atnie

do po

trzeb

.

Zwięk

szać

efek

tywno

ść ko

sztow

ą obs

zaru

IT ora

z jej

wkład

do re

ntown

ości

bizne

su.

Reali

zowa

ć proj

ekty

na cz

as i w

rama

ch bu

dżetu

, spe

łniają

c stan

dardy

jako

ściow

e.

Zach

ować

integ

ralno

ść in

forma

cji i i

nfras

truktu

ry prz

etwarz

ania.

Zape

wniać

zgod

ność

IT z

przep

isami

praw

a, wy

maga

niami

regu

lacyjn

ymi i

umow

ami.

Zape

wnić,

aby e

fektyw

ność

kosz

towa s

zła w

parze

z wy

soką

jako

ścią

usług

IT, ic

h ciąg

łym do

skon

alenie

m i g

otowo

ścią

do pr

zysz

łych z

mian

.

Proc

esy

Kryte

ria in

form

acji C

OBIT

Cele

IT

Efektywność WydajnośćPoufnośćIntegralność DostępnośćZgodnośćWiarygodność

POw

iąza

Nie

Cel

ów it

z P

rOC

esaM

i it

171

MaCierz POwiązaŃ PrOCesów it z CelaMi it

ZałącZnik i

i T G o v e r n a n c e i n s T i T u T e 171

172i T G o v e r n a n c e i n s T i T u T e

CobiT 4.1

172

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28Planowanie i organizacjaPO1 Definiowanie planu strategicznego IT. ✔ ✔

PO2 Definiowanie architektury informacji. ✔ ✔ ✔ ✔

PO3 Ustalanie kierunku technologicznego. ✔ ✔

PO4 Definiowanie procesów IT, organizacji i wzajemnych zależności. ✔ ✔ ✔

PO5 Zarządzanie inwestycjami IT. ✔ ✔ ✔

PO6 Komunikowanie celów i kierunkuzarządzania. ✔ ✔ ✔ ✔ ✔ ✔

PO7 Zarządzanie zasobami ludzkimi w IT. ✔ ✔

PO8 Zarządzanie jakością. ✔ ✔ ✔

PO9 Ocena i zarządzanie ryzykiem informatycznym. ✔ ✔ ✔

PO10 Zarządzanie projektami. ✔ ✔ ✔

Nabywanie i wdrażanieAI1 Identyfikowanie rozwiązań zautomatyzowanych. ✔ ✔

AI2 Nabywanie i utrzymywanie aplikacji. ✔ ✔

AI3 Nabywanie i utrzymywanie infrastruktury technicznej. ✔ ✔ ✔

AI4 Umożliwianie działania i użytkowania. ✔ ✔ ✔ ✔

AI5 Nabywanie zasobów IT. ✔ ✔ ✔

AI6 Zarządzanie zmianami. ✔ ✔ ✔ ✔ ✔

AI7 Instalowanie i akredytowanie rozwiązań i zmian. ✔ ✔ ✔ ✔ ✔ ✔

Dostarczanie i wsparcieDS1 Definiowanie i zarządzanie poziomami usług. ✔ ✔ ✔

DS2 Zarządzanie usługami zewnętrznymi. ✔ ✔ ✔

DS3 Zarzadzanie wydajnością i pojemnością. ✔ ✔ ✔

DS4 Zapewnienie ciągłości usług. ✔ ✔ ✔

DS5 Zapewnienie bezpieczeństwa systemów. ✔ ✔ ✔ ✔ ✔

DS6 Identyfikowanie i rozliczanie kosztów. ✔ ✔ ✔

DS7 Kształcenie i szkolenie użytkowników. ✔ ✔ ✔

DS8 Zarządzanie jednostką Service Desk i incydentami. ✔ ✔ ✔

DS9 Zarządzanie konfiguracją. ✔ ✔

DS10 Zarządzanie problemami. ✔ ✔ ✔

DS11 Zarządzanie danymi. ✔ ✔ ✔

DS12 Zarządzanie środowiskiem fizycznym. ✔ ✔ ✔ ✔

DS13 Zarządzanie operacjami. ✔ ✔ ✔

Monitorowanie i ocenaME1 Monitorowanie i ocena wydajności IT. ✔ ✔ ✔ ✔

ME2 Monitorowanie i ocena kontroli wewnętrznej. ✔ ✔ ✔ ✔

ME3 Zapewnianie zgodności z zewnętrznymi regulacjami. ✔

ME4 Zapewnienie ładu informatycznego. ✔ ✔ ✔ ✔

Spełn

iać w

ymag

ania

bizne

sowe

w zg

odzie

ze st

rate

gią bi

znes

ową.

Spełn

iać w

ymag

ania

dotyc

zące

nadz

oru

w zg

odzie

z ins

trukc

jami z

arzą

du.

Zape

wnić

satys

fakc

ję uż

ytkow

ników

końc

owyc

h z of

erow

anyc

h

usług

i poz

iomu t

ych u

sług.

Zopt

ymali

zowa

ć wyk

orzys

tywan

ie inf

ormac

ji.

Zape

wnić

spra

wne f

unkc

jonow

anie

IT.

Okreś

lić sp

osób

, w ja

ki biz

neso

we w

ymag

ania

funkc

jonaln

e i ko

ntroln

e

są tra

nspo

nowa

ne na

skute

czne

i wyd

ajne r

ozwi

ązan

ia za

utomaty

zowa

ne.

Pozys

kać i

utrzy

mywać

zint

egro

wane

i

usta

ndar

yzowa

ne sy

stemy a

plika

cji.

Pozys

kać i

utrzy

mywać

zint

egro

waną

i

usta

ndar

yzowa

ną in

frastr

uktu

rę IT

.

Pozys

kać i

utrzy

mywać

umiej

ętno

ści w

zakre

sie IT

odpo

wiad

ające

dane

j stra

tegii

IT.

Zape

wnić

obus

tronn

ą saty

sfakc

ję w s

tosun

kach

z pod

miotam

i zewn

ętrzn

ymi.

Zape

wnić

łatwą

inte

grac

ję ap

likac

ji

z pro

cesa

mi bizn

esow

ymi.

Zape

wnić

prze

jrzys

tość

i zro

zumiał

ość k

osztó

w IT,

korzy

ści,

strat

egii,

polit

yk i p

oziom

ów us

ług.

Zape

wnić

praw

idłow

e wyk

orzys

tanie

i wyd

ajość

aplik

acji o

raz

stoso

wany

ch ro

związ

ań te

chnic

znyc

h.

Pono

sić od

powi

edzia

lność

za w

szys

tkie a

ktywa

IT i j

e chro

nić.

Zopt

ymali

zowa

ć inf

rastr

uktu

rę IT

, zas

obów

i moż

liwoś

ci.

Zmnie

jszyć

liczb

ę wad

i pop

rawe

k w za

kresie

dosta

rczan

ych

rozw

iązań

i świ

adcz

onyc

h usłu

g.

Zabe

zpiec

zać m

ożliw

ości

osiąg

ania

celów

IT.

Zape

wnić

prze

jrzys

tość

wpł

ywu b

iznes

oweg

o ryzy

k

na ce

le i z

asob

y IT.

Uniem

ożliw

iać do

stęp n

ieupo

ważn

ionyc

h osó

b do

kryty

czny

ch i p

oufn

ych i

nfor

macji.

Zape

wnić

nieza

wodn

ość s

yste

mów za

utom

atyzo

wany

ch tr

ansa

kcji

bizne

sowy

ch i w

ymian

y inf

ormac

ji.

Zape

wnić

odpo

rnoś

ć usłu

g IT i

infra

struk

tury

na aw

arie

wynik

ające

z błęd

u, ce

loweg

o ata

ku lu

b kat

astro

fy.

Zape

wnić

minimaln

y wpły

w na b

iznes

w prz

ypad

ku wy

stąpie

nia za

kłóce

ń

usług

IT lu

b ich

zmian

y.Za

pewn

ić wy

magan

ą dos

tępn

ość u

sług I

T.

Popr

awiać

efek

tywno

ść ko

szto

wą ob

szru

IT or

az je

j wkła

d

do re

ntow

nośc

i bizn

esu.

Reali

zowa

ć pro

jekty

na cz

as i w

ramac

h bud

żetu

, zac

howu

jąc

stand

ardy

jako

ściow

e.Za

chow

ać in

tegr

alnoś

ć inf

ormac

ji i in

frastr

uktu

ry pr

zetw

arza

nia.

Zape

wnić

zgod

ność

obsz

aru I

T z ob

owiąz

ujący

m praw

em, p

rzepis

ami

i umow

ami.

Zape

wnić,

że ob

szar

IT do

starcz

a usłu

g wys

okiej

jako

ść, e

fektyw

nych

kosz

towo

, ciąg

le się

dosk

onali

oraz

jest

przyg

otow

any d

o zmian

w pr

zyszło

ści.

CobiT 4.1

z a ł ą c z n i k i i

P r z y P o r z ą d k owa n i e P r o c e s ów i T d o G ł ówn y c h o b s z a r ów ł a d u i n f o rM a T y c z n e G o , s T r u k T u r y

r aM ow e j coso , z a s o b ów i n f o rM a T y c z n y c h c o b i T i k r y T e r i ów i n f o rM a c j i c o b i T

WtymzałącznikuprzedstawionopowiązaniemiędzyprocesamiinformatycznymiCobiT apięciomaobszaramiładuinformatycznego,komponentamistrukturyramowejCOSO,zasobamiITorazkryteriamiinformacji.Wtabelipodanorównieżwzględnywskaźnikważności(wysoki,średnilubniski),określonynapodstawieanalizyporównawczejzapośrednictwemserwisuCobiTOnline.Przedstawionamacierzilustrujewformiejednostronicowejtabeli,wjakisposóbmetodykaCobiTadresujewymaganiaładuinformatycznegoistrukturyramowejCOSO,atakżepokazujerelacjemiędzyprocesamiITazasobamiinformatycznymiikryteriamiinformacji.OznaczeniePodpowiadarelacjiopierwszorzędnymznaczeniu,aS—odrugorzędnymznaczeniu.BrakPlubSnieoznaczabrakurelacji,lecztylko,żemaonamniejszelubmarginalneznaczenie.Wartościwskaźnikówważnościprzyjętonapodstawiewynikówbadańiopiniiekspertówinależyjetraktowaćtylkojakoogólnewytyczne.Użytkownicypowinnisamidokonaćoceny,któreprocesysąnajważniejszewichorganizacji.

Za

łą

cZ

nik ii

PRZ

YPO

RZ

ąD

kO

Wa

niE


PO1 D

efinio

wanie

plan

u stra

tegicz

nego

IT.

H

P

S S

P

S S

✓ ✓

✓ ✓

P S

PO2 D

efinio

wanie

arch

itektu

ry inf

ormac

ji. L

P S

P S

P

P

✓ ✓

S P

S P

PO3 U

stalan

ie kie

runku

tech

nolog

iczne

go.

M

S S

P S

S P

S

✓

✓

P P

PO4 D

efinio

wanie

proc

esów

IT, o

rganiz

acji i

wzaje

mnyc

h zale

żnoś

ci.

L S

P

P

P

S

S

✓ P

PPO

5 Zarz

ądza

nie in

westy

cjami

IT.

M S

P S

S

S

P

✓

✓

✓ P

P

S

PO6 K

omun

ikowa

nie ce

lów i k

ierun

kuza

rządz

ania.

M

P

P

P

P

✓

✓

P

S

PO7 Z

arząd

zanie

zaso

bami

ludz

kimi w

IT.

L

P

P S

S P

S

✓

P P

PO8 Z

arząd

zanie

jako

ścią.

M

P S

S

P

P

S P

✓ ✓

✓ ✓

P P

S

SPO

9 Oce

na i z

arząd

zanie

ryzy

kiem

inform

atycz

nym.

H

P

P

P

✓ ✓

✓ ✓

S S

P P

P S

SPO

10 Za

rządz

anie

projek

tami.

H

P

S S

S S

S S

P

S ✓

✓

✓ P

P

DS1 D

efinio

wanie

i zarz

ądza

nie po

zioma

mi us

ług.

M

P P

P

P S

P

S S

✓ ✓

✓ ✓

P P

S S

S S

S DS

2 Zarz

ądza

nie us

ługam

i zew

nętrz

nymi

.

L

P S

P S

P S

P

S ✓

✓ ✓

✓ P

P S

S S

S S

DS3 Z

arzad

zanie

wyd

ajnoś

cią i p

ojemn

ością

.

L S

S P

S S

P

S ✓

✓

P

P

S

DS4 Z

apew

nienie

ciąg

łości

usług

. M

S P

S P

S S

P

S

✓ ✓

✓ ✓

P S

P DS

5 Zap

ewnie

nie be

zpiec

zeńs

twa s

ystem

ów.

H

P

P

S S

✓ ✓

✓ ✓

P P

S S

S DS

6 Ide

ntyfik

owan

ie i ro

zlicza

nie ko

sztów

.

L

S P

S

P

✓

✓ ✓

✓

P

P

DS7 K

ształ

cenie

i szk

olenie

użytk

ownik

ów.

L

S P

S S

P

S

✓

P S

DS8 Z

arząd

zanie

jedn

ostką

Serv

ice D

esk i

incy

denta

mi.

L

P

S S

P P

✓

✓

P P

DS9 Z

arząd

zanie

konfi

gurac

ją.

M

P P

S

P

✓

✓ ✓

P

S

S

S

DS10

Zarzą

dzan

ie pro

blema

mi.

M

P

S

S

P

S S

✓ ✓

✓ ✓

P P

S DS

11 Za

rządz

anie

dany

mi.

H

P

P P

P

✓

P

P DS

12 Za

rządz

anie

środo

wiskie

m fiz

yczn

ym.

L

S P

S P

✓

P

P DS

13 Za

rządz

anie

opera

cjami

.

L

P

P S

✓

✓ ✓

✓ P

P

S S

AI1 Id

entyf

ikowa

nie ro

związ

ań za

utoma

tyzow

anyc

h.

M P

P S

S

P

✓

✓

P

SAI2

Nab

ywan

ie i u

trzym

ywan

ie ap

likacji.

M

P P

S

P

✓

P P

S

SAI3

Nab

ywan

ie i u

trzym

ywan

ie inf

rastru

ktury

techn

iczne

j.

L

P

P

✓

S

P

S S

AI4 U

możliw

ianie

dział

ania

i uży

tkowa

nia.

L

S P

S S

P

S

✓

✓ ✓

P P

S

S S

SAI5

Dos

tarcz

anie

zaso

bów

IT.

M

S P

P

✓

✓ ✓

✓ S

P

S AI6

Zarz

ądza

nie zm

ianam

i.

H

P S

S

P

S ✓

✓ ✓

✓ P

P

P P

S

AI7 In

stalow

anie

i akre

dytow

anie

rozwią

zań i

zmian

.

M S

P S

S S

P S

S ✓

✓ ✓

✓ P

S

S S

ME1 M

onito

rowan

ie i o

cena

wyd

ajnoś

ci IT.

H

S S

S S

P

S P

✓ ✓

✓ ✓

P P

S S

S S

S ME

2 Mon

itorow

anie

i oce

na ko

ntroli

wew

nętrz

nej.

M

P

P

P

✓ ✓

✓ ✓

P P

S S

S S

SME3

Zap

ewnian

ie zgo

dnoś

ci z zew

nętrzn

ymi regu

lacjam

i.

H P

P

P S

S ✓

✓ ✓

✓

P S

ME4

Zap

ewnien

ie ład

u inform

atyczn

ego.

H

P P

P P

P P

S

S P

✓ ✓

✓ ✓

P P

S S

S S

S

Dopasowanie strategiczne

ISTOTNOŚĆ

Dostarczanie wartości

Zarządzanie zasobami

Zarządzanie ryzykiem

Pomiar wydajności

Obsz

ary n

adzo

ru in

form

atyc

zneg

o

Efektywność

Wydajność

Poufność

Integralność

Dostępność

Zgodność

Wiarygodność

Kryte

ria in

form

acji C

OBIT

Środowisko mechanizmów kontrolnych

Ocena ryzyka

Działania kontrolne

Informacje i komunikacja

Monitorowanie

COSO

Aplikacja

Informacja

Infrastruktura

Osoby

Zaso

by C

OBIT

Plan

owan

ie i o

rgan

izacja

Naby

wani

e i w

draż

anie

Dost

arcz

anie

i wsp

arcie

Mon

itoro

wani

e i oc

ena

Uwag

a: P

rzypo

rządk

owan

ie w

rama

ch st

ruktu

ry CO

SO op

iera s

ię na

pier

wotne

j stru

kturze

ramo

wej C

OSO.

Odn

osi s

ię ró

wnież

do pó

źniej

szeg

o opr

acow

ania

COSO

Ent

erpr

ise R

isk M

anag

emen

t—In

tegr

ated

Fra

mew

ork,

które

obejm

uje za

gadn

ienia

kontr

oli w

ewnę

trzne

j, kon

centr

ując s

ię w

szer

szym

zakre

sie na

zaga

dnien

iu za

rządz

ania

ryzyk

iem pr

zeds

iębior

stwa.

Choc

iaż m

etody

ka C

obiT

nie m

a na c

elu za

stąpie

nia pi

erwo

tnej s

truktu

ry me

chan

izmów

kontr

olnyc

h COS

O, le

cz ra

czej

uwzg

lędnie

nie je

j zało

żeń,

użytk

ownic

y meto

dyki

CobiT

mog

ą mieć

potrz

ebę w

ykor

zysta

nia te

j str

uktur

y zar

ządz

ania

ryzyk

iem pr

zeds

iębior

stwa z

arów

no w

celu

reali

zacji

swoic

h potr

zeb z

wiąz

anyc

h z ko

ntrolą

wew

nętrz

ną, ja

k i w

droż

enia

bard

ziej ro

zwini

ętego

proc

esu z

arzą

dzan

ia ryz

ykiem

.

P=cz

ynnik

pods

tawow

y (Pr

imar

y) S

=czy

nnik

drug

orzę

dny (

Seco

ndar

y)

ZałącZnik iiza

łącz

nik ii —

Prz

yPo

rządkowanie Pro

cesó

w iT

do Głó

wnych

obs

zaró

w ładu in

forM

aTycz

neG

o, s

TrukTu

ry raMowej coso

, zaso

bów

info

rMaT

ycz

nych c

obiT

i kry

Teriów in

forM

acji c

obiTZ

ał

ąc

Zn

ik ii PR

ZY

POR

Zą

Dk

OW

an

iE


CobiT 4.1strona celowo pozostawiona pusta

z a ł ą c z n i k i i i

M o d e l d o j r z a ł o ś c i w e w n ę T r z n y c h M e c h a n i z M ó w k o n T r o l n y c h

Wtymzałącznikuprzedstawionoogólnymodeldojrzałości,któryilustrujestanśrodowiskakontroliwewnętrznejorazmechanizmówkontrolnychwprzedsiębiorstwie.Pokazujeon,wjakisposóbzwykleewoluujesposóbzarządzaniakontroląwewnętrznąiświadomośćpotrzebywprowadzeniabardziejdoskonałychmechanizmówkontrolnych—odpoziomurozwiązańdoraźnychdopoziomurozwiązańzoptymalizowanych.Prezentowanymodeldostarczaogólnychwskazówek,którepomogąużytkownikommetodykiCobiTokreślić,cojestniezbędnedlazapewnieniaefektywnychmechanizmówkontrolnychwobszarzeITorazumieścićswojeprzedsiębiorstwowodpowiednimmiejscunaskalidojrzałości.

Za

łą

cZ

nik iii

DO

JRZ

ał

OŚĆ

ME

cH

an

iZM

ÓW

k

On

TR

OL

nY

cH


ZałącZnik iii

Poziom Stan środowiska wewnętrznych Ustanowienie wewnętrznych dojrzałości mechanizmów kontrolnych mechanizmów kontrolnych 0 Nieistniejący Nie istnieje świadomość potrzeby istnienia wewnętrznych Nie ma intencji oceny potrzeby istnienia wewnętrznych mechanizmów

mechanizmów kontrolnych. Kontrola nie jest częścią kontrolnych. Incydenty są rozwiązywane w doraźny sposób. kultury ani misji organizacji. Występuje duże ryzyko niedoskonałości kontroli i występowania incydentów.

1 Początkowy/ Istnieje pewna świadomość potrzeby istnienia Nie ma świadomości potrzeby oceny, jakie są potrzeby w dziedzinie doraźny wewnętrznych mechanizmów kontrolnych. Podejście mechanizmów kontrolnych IT. Jeśli się jej dokonuje, to tylko

do ryzyka i wymagań kontrolnych jest doraźne, na doraźnych zasadach, na wysokim poziomie struktury organizacyjnej niezorganizowane i nie towarzyszy mu wymiana i w następstwie poważnych incydentów. Ocena dotyczy tylko informacji ani monitoring. Nie są zidentyfikowane konkretnego incydentu. niedoskonałości. Pracownicy nie są świadomi swojego zakresu odpowiedzialności.

2 Powtarzalny lecz Istnieją mechanizmy kontrolne, ale nie są Ocena potrzeb w zakresie mechanizmów kontrolnych odbywa intuicyjny udokumentowane. Ich działanie jest uzależnione się tylko wtedy, gdy jest niezbędna w przypadku wybranych

od indywidualnej wiedzy i motywacji. Efektywność procesów w celu określenia aktualnego poziomu dojrzałości kontroli, nie jest należycie oceniana. Mechanizmy kontrolne mają docelowego poziomu, który powinien zostać osiągnięty, oraz wiele niedoskonałości, które nie są w odpowiedni sposób istniejących braków. W celu zdefiniowania odpowiedniego podejścia eliminowane i mogą mieć poważne skutki. Działania do mechanizmów kontrolnych dla danego procesu oraz zmotywowania. kierownictwa dotyczące rozwiązywania problemów do realizacji uzgodnionego planu działania stosowane jest nieformalne w obszarze kontroli nie mają priorytetowego charakteru podejście o charakterze warsztatów, w których uczestniczą i nie są konsekwentne. Pracownicy mogą nie być menedżerowie ds. IT i zespół zaangażowany w realizację procesu. świadomi swojego zakresu odpowiedzialności.

3 Zdefiniowany Istnieją mechanizmy kontrolne i są odpowiednio W oparciu o czynniki ryzyka i wartości zidentyfikowano procesy IT udokumentowane. Okresowo oceniana jest efektywność o krytycznym znaczeniu. Dokonuje się szczegółowej analizy w celu operacyjna i występuje przeciętna ilość problemów. określenia wymagań kontrolnych, głównego źródła przyczyn braków Jednak proces oceniania nie jest dokumentowany. oraz możliwości wprowadzenia udoskonaleń. W celu wsparcia analizy Kierownictwo jest w stanie w przewidywalny sposób i zapewnienia, aby właściciel procesu IT był właścicielem procesu rozwiązywać większość problemów związanych oceny i doskonalenia i stymulował jego działanie, oprócz z kontrolą, jednak występują pewne niedoskonałości, moderowanych warsztatów stosuje się odpowiednie narzędzia które mogą mieć poważne konsekwencje. Pracownicy i przeprowadza wywiady. są świadomi swojego zakresu obowiązków w dziedzinie kontroli.

4 Kontolowany Istnieje środowisko efektywnych wewnętrznych Przy pełnym poparciu i w porozumieniu z właścicielami procesów i mierzalny mechanizmów kontrolnych i zarządzania ryzykiem. biznesowych regularnie definiowane są procesy IT o krytycznym

Często dokonuje się formalnej, udokumentowanej oceny znaczeniu. Ocena wymagań kontrolnych jest dokonywana mechanizmów kontrolnych. Wiele mechanizmów w odniesieniu do przyjętej polityki i rzeczywistej dojrzałości kontrolnych jest zautomatyzowanych i regularnie procesów oraz w oparciu o dogłębną i wykorzystującą pomiary poddawanych przeglądowi. Kierownictwo jest zdolne analizę z udziałem kluczowych interesariuszy. Jasno określona identyfikować większość problemów związanych i egzekwowana jest rozliczalność na podstawie ocen. Doskonalenie z kontrolą, ale nie wszystkie są wykrywane w rutynowy strategii odbywa się w oparciu o uzasadnienia biznesowe. sposób. W konsekwentny sposób podejmowane Konsekwentnie monitorowana jest wydajność w osiąganiu pożądanych są działania następcze w celu wyeliminowania rezultatów. Okazjonalnie dokonuje się zewnętrznych przeglądów zidentyfikowanych słabości mechanizmów kontrolnych. mechanizmów kontrolnych. W ograniczonym zakresie stosuje się taktycznie rozwiązania technologiczne w celu automatyzacji mechanizmów kontrolnych.

5 Zoptymalizowany Obejmujący całe przedsiębiorstwo program zarządzania Zmiany dokonywane w firmie uwzględniają krytyczne znaczenie ryzykiem i mechanizmami kontrolnymi umożliwia stałą procesów IT i obejmują wszelkie potrzeby związane z ponowną i efektywną kontrolę oraz rozwiązywanie problemów oceną zdolności sprawowania kontroli nad procesami. Właściciele związanych z ryzykiem. Zarządzanie wewnętrznymi procesów IT regularnie dokonują samooceny w celu potwierdzenia, mechanizmami kontrolnymi i ryzykiem jest zintegrowane że mechanizmy kontrolne charakteryzują się odpowiednim poziomem z praktykami przedsiębiorstwa, wspieranymi przez dojrzałości, aby spełniać potrzeby firmy. Uwzględniają również atrybuty automatyzowany monitoring w czasie rzeczywistym, dojrzałości, aby znaleźć sposób na uczynienie mechanizmów przy pełnej rozliczalności w obszarze monitoringu kontrolnych bardziej wydajnymi i efektywnymi. Organizacja konfrontuje wewnętrznych mechanizmów kontrolnych, zarządzania się z zewnętrznymi dobrymi praktykami i korzysta z zewnętrznego ryzykiem i egzekwowania zgodności. Ocena doradztwa w dziedzinie zapewnienia efektywności wewnętrznych mechanizmów kontrolnych odbywa się w sposób ciągły, mechanizmów kontrolnych. W przypadku procesów o krytycznym w oparciu o analizę braków i przyczyn podstawowych. znaczeniu dokonywane są niezależne przeglądy, aby mieć pewność, Pracownicy są aktywnie zaangażowani w doskonalenie że mechanizmy kontrolne charakteryzują się pożądanym poziomem mechanizmów kontrolnych. dojrzałości i działają w zaplanowany sposób.

załącznik iii — Model dojrzałości wewnęTrznych MechanizMów konTrolnych

Za

łą

cZ

nik iii

DO

JRZ

ał

OŚĆ

ME

cH

an

iZM

ÓW

k

On

TR

OL

nY

cH



z a ł ą c z n i k i v

c o b i T 4 . 1 — n a j w a ż n i e j s z e M a T e r i a ł y ź r ó d ł o w e

Za

łą

cZ

nik iv

Ma

TE

Ria

łY

Ź

RÓ

Dł

OW

E


załącznik iv cobiT 4.1 — najważniejsze MaTeriały źródłowe

We wczesnej fazie rozwoju i aktualizacji metodyki CobiT korzystano z szerokiego zbioru materiałów źródłowych w postaci ponad 40 szczegółowych międzynarodowych standardów, metodyk, wytycznych i dobrych praktyk w dziedzinie IT, aby zapewnić kompletność metodyki CobiT w odniesieniu do wszystkich obszarów kontroli i nadzoru informatycznego.

Ponieważ metodyka CobiT skupia się na tym, co jest niezbędne, aby zapewnić właściwe zarządzanie i kontrolę nad działalnością IT, charakteryzuje się ona wysokim poziomem ogólności. Bardziej szczegółowe standardy i dobre praktyki w dziedzinie IT opisują na wyższym poziomie szczegółowości, w jaki sposób należy zarządzać i kontrolować szczegółowe aspekty działalności IT. Metodyka CobiT łączy w sobie wiedzę zawartą w tych materiałach, grupując najważniejsze cele w ramach jednej ramowej struktury, która jest również powiązana z potrzebą nadzoru i wymaganiami biznesowymi.

W celu zapewnienia odpowiedniego zakresu tematycznego, spójności i dopasowania aktualne wydanie metodyki CobiT (CobiT 4.1) zawiera odniesienia do sześciu najważniejszych globalnych standardów, metodyk i praktyk w dziedzinie IT. Są to: • COSO:

Internal Control — Integrated Framework (Zintegrowana kontrola wewnętrzna — struktura ramowa), 1994 Enterprise Risk Management — Integrated Framework (Zarządzanie ryzykiem przedsiębiorstwa — struktura ramowa), 2004

• Office of Government Commerce (OGC®): IT Infrastructure Library® (Biblioteka infrastruktury IT) (ITIL®), 1999-2004

• International Organisation for Standardisation: Standard ISO/IEC 27000

• Software Engineering Institute (SEI®): SEI Capability Maturity Model (Model dojrzałości) (CMM®), 1993 SEI Capability Maturity Model Integration (Integracja modelu dojrzałości) (CMMI®), 2000

• Project Management Institute (PMI®): A Guide to the Project Management Body of Knowledge (Przewodnik po zasadach zarządzania projektami) (PMBOK®), 2004

• Information Security Forum (ISF): The Standard of Good Practice for Information Security (Standard dobrych praktyk w dziedzinie bezpieczeństwa informacji), 2003

Dodatkowe materiały źródłowe wykorzystane do opracowania metodyki CobiT 4.1:• IT Control Objectives for Sarbanes-Oxley: The Role of IT in the Design and Implementation of Internal Control Over

Financial Reporting (Cele kontrolne w świetle wymagań ustawy Sarbanesa-Oxley'a: rola IT w projektowaniu i wdrażaniu wewnętrznej kontroli sprawozdawczości finansowej), wydanie drugie, IT Governance Institute, USA, 2006

• CISA Review Manual (Podręcznik CISA), ISACA, 2006

ZałącZnik iv

Za

łą

cZ

nik iv

Ma

TE

Ria

łY

Ź

RÓ

Dł

OW

E



z a ł ą c z n i k v

w z a j e M n e r e l a c j e M i ę d z y M e T o d y k ą c o b i T 3 r d e d i T i o n a M e T o d y k ą c o b i T 4 . 1

Za

łą

cZ

nik v

W

za

jeM

ne r

eL

aC

je


załącznik v — wzajeMne relacje Między MeTodyką cobiT 3rd ediTion a MeTodyką cobiT 4.1

ZMiaNY Na POZiOMiE METODYCZNYMNajważniejsze zmiany, jakie wprowadzono w metodyce CobiT w ramach aktualizacji CobiT 4.0 są następujące:• Domena M została przemianowana na ME (ang. Monitor and Evaluate — Monitorowanie i ocena).• M3 i M4 były procesami audytu, a nie procesami IT. Zostały one usunięte, ponieważ są odpowiednio uwzględnione w kilku

standardach audytu IT, jednak w ramach zaktualizowanej metodyki zachowano do nich odniesienia, aby podkreślić potrzebę korzystania przez kierownictwo z funkcji kontroli wewnętrznej.

• ME3 to proces odnoszący się do nadzoru regulacyjnego, który wcześniej mieścił się w ramach procesu PO8.• ME4 obejmuje proces nadzoru nad działalnością IT zgodnie z założeniami ram ładu informatycznego CobiT. Umiejscowienie tego

procesu na końcu łańcucha podkreśla wagę wsparcia, jakie zapewnia każdy z poprzedzających procesów w realizacji ostatecznego celu, jakim jest wdrożenie efektywnego ładu informatycznego w przedsiębiorstwie.

• W związku z usunięciem procesu PO8 i potrzebą zachowania dotychczasowych oznaczeń procesów PO9 Ocena ryzyka i PO10 Zarządzanie projektami (zgodnie z metodyką CobiT 3rd Edition), oznaczenie PO8 przypisano do procesu Zarządzanie jakością (dawny proces PO11). Domena PO obejmuje obecnie dziesięć zamiast jedenastu procesów.

• W domenie AI niezbędne było wprowadzenie dwóch zmian: dodanie procesu zaopatrzenia oraz uwzględnienie w procesie AI5 aspektów zarządzania wersjami. Spowodowało to potrzebę przesunięcia tego procesu na ostatnie miejsce w domenie AI i nadanie mu oznaczenia AI7. Wolne miejsce pod oznaczeniem AI5 zajął nowy proces nabywania zasobów IT. Domena AI obejmuje więc obecnie siedem zamiast sześciu procesów.

Metodyka CobiT 4.1, będąca przyrostową aktualizacją metodyki CobiT 4.0, zawiera:• Rozszerzone wprowadzenie.• Objaśnienie celów i mierników w części metodycznej.• Udoskonalone definicje podstawowych pojęć. Należy również wspomnieć o modyfikacji definicji celu kontrolnego, która obecnie

w większym stopniu odnosi się do praktyki zarządzania.• Udoskonalone cele kontrolne wynikające ze zaktualizowanych praktyk kontrolnych oraz rozwoju metodyki Val IT. Niektóre

cele kontrolne zostały pogrupowane i/lub zmieniono ich opis, aby uniknąć ich pokrywania się i zapewnić ich większą spójność w ramach procesu. Zmiany te spowodowały modyfikację numeracji pozostałych celów kontrolnych. Niektóre z pozostałych celów kontrolnych zostały przeredagowane, aby były bardziej zorientowane na działanie i spójne pod względem słownictwa. Szczegółowe zmiany obejmują m.in.:

– połączenie celów AI5.5 i AI5.6 z AI5.4; – połączenie celów AI7.9, AI7.10 i AI7.11 z AI7.8; – modyfikację celu ME3, tak aby oprócz wymagań prawnych i regulacyjnych uwzględnić zapewnienie zgodności z wymaganiami

wynikającymi z umów.• Zmodyfikowano aplikacyjne mechanizmy kontrolne, aby zapewnić ich większą efektywność w oparciu o działania wspierające

ocenę i raportowanie efektywności mechanizmów kontrolnych. W ten sposób powstała lista sześciu aplikacyjnych mechanizmów kontrolnych, które zastąpiły osiemnaście takich mechanizmów w metodyce CobiT 4.0 — bardziej szczegółowo omówionych w publikacji CobiT Control Practices (Praktyki kontrolne CobiT), wydanie drugie.

• W oparciu o badanie weryfikujące przeprowadzone przez University of Antwerp Management School (Belgia) udoskonalono listę celów biznesowych i celów IT przedstawionych w załączniku I.

• Rozszerzono wkładkę, aby umieścić w niej podręczną listę referencyjną procesów CobiT i zmodyfikowano ogólny schemat przedstawiający domeny, aby uwzględnić odniesienie do procesów i aplikacyjnych mechanizmów kontrolnych metodyki CobiT.

• Uwzględniono wybrane sugestie udoskonaleń zgłoszone przez użytkowników metodyki CobiT (CobiT 4.0 i CobiT Online).

CELE KONTROLNEJak wynika z powyższego opisu modyfikacji na poziomie metodycznym oraz pracy ukierunkowanej na zwiększenie przejrzystości i spójności treści dotyczącej celów kontrolnych, aktualizacja metodyki CobiT spowodowała istotną zmianę zawartych w niej celów kontrolnych. Ich liczba zmniejszyła się z 215 do 210, ponieważ wszystkie ogólne materiały zostały obecnie zachowane na poziomie metodycznym i nie są powtarzane dla każdego procesu. Ponadto wszelkie odniesienia do aplikacyjnych mechanizmów kontrolnych przeniesiono na poziom strukturalny, a szczegółowe cele kontrolne zostały zagregowane w ramach nowych sformułowań. W celu ułatwienia przejścia do nowej struktury celów kontrolnych opracowano poniższe tabele, które pokazują wzajemne relacje między nowymi i starymi celami kontrolnymi.

wytyCzNe zarząDzaNiaDodano również elementy wejściowe i wyjściowe, aby zilustrować, jakiego wkładu wymagają poszczególne procesy od innych oraz co same dostarczają. Uwzględniono również czynności i związaną z nimi odpowiedzialność. Kluczowe czynniki sukcesu z metodyki CobiT 3rd Edition zostały zastąpione przez elementy wejściowe i cele czynności. Mierniki są obecnie oparte na spójnej kaskadowej strukturze celów IT, celów procesów i celów czynności. Zbiór mierników wykorzystywanych w metodyce CobiT 3rd Edition został również zweryfikowany i udoskonalony, aby były one bardziej reprezentatywne i mierzalne.

ZałącZnik v

Za

łą

cZ

nik v

W

za

jeM

ne r

eL

aC

je


CobiT 4.1

CobiT 3rd Edition CobiT 4.1 PO1 Definiowanie planu strategicznego IT. 1.1 IT jako element 1.4 długo- i krótkoterminowego planu organizacji 1.2 Długoterminowy plan IT 1.4 1.3 Długoterminowe 1.4 planowanie IT — podejście i struktura 1.4 Zmiany długoterminowego planu IT 1.4 1.5 Krótkoterminowe 1.5 planowanie dla funkcji IT 1.6 Informowanie o planach IT 1.4 1.7 Monitorowanie 1.3 i ocena planów IT 1.8 Ocena istniejących 1.3 systemów PO2 Definiowanie architektury informacji. 2.1 Model architektury 2.1 informacji 2.2 Słownik danych 2.2 korporacyjnych i zasady składni danych 2.3 Schemat klasyfikacji danych 2.3 2.4 Poziomy bezpieczeństwa 2.3 PO3 Ustalanie kierunku technologicznego. 3.1 Planowanie 3.1 infrastruktury technicznej 3.2 Monitorowanie przyszłych 3.3 trendów i regulacji. 3.3 Rezerwy 3.1 infrastruktury technicznej 3.4 Plany nabycia 3.1, AI3.1 sprzętu i oprogramowania 3.5 Standardy technologiczne 3.4, 3.5 PO4 Definiowanie organizacji i relacji w IT. 4.1 Komitet planowania 4.3 lub komitet sterujący ds. IT 4.2 Organizacyjne 4.4 umiejscowienie funkcji IT 4.3 Przegląd osiągnięć 4.5 organizacyjnych 4.4. Role i odpowiedzialność 4.6 4.5 Odpowiedzialność za 4.7 zapewnienie jakości 4.6 Odpowiedzialność za 4.8 logiczne i fizyczne bezpieczeństwo 4.7 Własność i dozór 4.9 4.8 Własność danych 4.9 i systemów 4.9 Nadzór 4.10 4.10 Rozdział obowiązków 4.11 4.11 Obsada stanowisk w dziale IT 4.12 4.12 Opisy stanowisk 4.6 dla personelu IT 4.13 Kluczowy personel IT 4.13 4.14 Polityka i procedury 4.14 dotyczące pracowników kontraktowych 4.15 Relacje 4.15 PO5 Zarządzanie inwestycjami IT. 5.1 Roczny budżet 5.3 operacyjny IT

CobiT 3rd Edition CobiT 4.1 5.2 Monitorowanie kosztów 5.4 i korzyści 5.3 Uzasadnienie 1.1, 5.3, 5.4, kosztów i korzyści 5.5 PO6 Komunikowanie celów i kierunku

zarządzania. 6.1 Korzystne środowisko 6.1 kontroli informacji 6.2 Odpowiedzialność 6.3, 6.4, 6.5 kierownictwa za politykę 6.3 Informowanie o polityce 6.3, 6.4, 6.5 organizacji 6.4 Zasoby do wdrożenia 6.4 polityki 6.5 Utrzymywanie polityki 6.3, 6.4, 6.5 6.6 Zgodność z polityką, 6.3, 6.4, 6.5 procedurami i standardami 6.7 Zaangażowanie w 6.3, 6.4, 6.5 zapewnienie jakości 6.8 Polityka dotycząca 6.2 struktury kontroli wewnętrznej i bezpieczeństwa 6.9 Prawo własności 6.3, 6.4, 6.5 intelektualnej 6.10 Polityki dotyczące 6.3, 6.4, 6.5 określonych zagadnień 6.11 Informowanie o 6.3, 6.4, 6.5 świadomości bezpieczeństwa IT PO7 Zarządzanie zasobami ludzkimi. 7.1 Rekrutacja i awansowanie 7.1 pracowników 7.2 Kwalifikacje pracowników 7.2 7,3. Role i odpowiedzialność 7.4 7.4 Szkolenie pracowników 7.5 7.5 Szkolenie w dodatkowych 7.6 umiejętnościach lub zastępowalność pracowników 7.6 Procedury weryfikacji pracowników 7.7 7.7 Ocena wyników 7.8 pracy pracowników 7.8 Zmiana i zakończenie pracy 7.8 PO8 Zapewnianie zgodności z zewnętrznymi

regulacjami.8.1 Przegląd zewnętrznych ME3.1 regulacji 8.2 Praktyki i procedury ME3.2 zapewniania zgodności z zewnętrznymi regulacjami 8.3 Zgodność z zasadami ME3.1 bezpieczeństwa i ergonomii 8.4 Prywatność, własność ME3.1 intelektualna i przepływ danych 8.5 Handel elektroniczny ME3.1 8.6 Zgodność z umowami ME3.1 ubezpieczeniowymi PO9 Ocena ryzyka. 9.1 Ocena ryzyka 9.1, 9.2, 9.4 biznesowego 9.2 Podejście do oceny ryzyka 9.4 9.3 Identyfikacja ryzyka 9.3 9.4 Pomiar ryzyka 9.1, 9.2, 9.3, 9.4 9.5 Plan postępowania wobec 9.5 ryzyka 9.6 Akceptacja ryzyka 9.5 9.7 Wybór mechanizmu ochrony 9.5

CobiT 3rd Edition CobiT 4.1 9.8 Zaangażowanie 9.1 w ocenę ryzyka PO10 Zarządzanie projektami. 10.1 Struktura zarządzania 10.2 projektami 10.2 Uczestnictwo działu 10.4 obsługi użytkownika w inicjowaniu projektów 10.3 Uczestnictwo w zespole 10.8 projektowym i zakres odpowiedzialności 10.4 Definiowanie projektów 10.5 10.5 Zatwierdzanie projektów 10.6 10.6 Zatwierdzanie faz projektów 10.6 10.7 Ogólny plan projektów 10.7 10.8 Plan zapewnienia 10.10 jakości systemów 10.9 Planowanie metod 10.12 kontroli wewnętrznej 10.10 Formalne zarządzanie 10.9 ryzykiem projektów 10.11 Plan testów AI7.2 10.12 Plan szkoleń AI7.1 10.13 Plan przeglądów 10.14 (część) powdrożeniowych PO11 Zarządzanie jakością. 11.1 Ogólny plan jakości 8.5 11.2 Podejście do zapewnienia 8.1 jakości 11.3 Planowanie zapewnienia 8.1 jakości 11.4 Przegląd jakościowy 8.1, 8.2 zachowania zgodności ze standardami i procedurami 11.5 Metodyka cyklu życia 8.2, 8.3 rozwoju systemów (SDLC) 11.6 Metodyka SDLC dla 8.2, 8.3 znaczących zmian istniejącej technologii 11.7 Aktualizacja metodyki 8.2, 8.3 SDLC 11.8 Koordynacja 8.2 i komunikacja 11.9 Ramy strukturalne 8.2 nabywania i utrzymywania infrastruktury technicznej 11.10 Relacje z zewnętrznymi 8.2, DS2.3 implementatorami 11.11 Standardy AI4.2, AI4.3, dokumentacji oprogramowania AI4.4 11.12 Standardy testowania AI7.2, AI7.4 oprogramowania 11.13 Standardy testowania AI7.2, AI7.4 systemów 11.14 Testowanie równoległe/ AI7.2, AI7.4 pilotażowe 11.15 Dokumentacja AI7.2, AI7.4 testowania systemów 11.16 Ocena jakościowa 8.2 zachowania zgodności ze standardami programowania 11.17 Przegląd jakościowy 8.2 realizacji celów IT 11.18 Mierniki jakości 8.6 11.19 Sprawozdania z 8.2 przeglądów jakościowych

Wzajemne relacje: CobiT 3rd Edition w odniesieniu do CobiT 4.1


ZałącZnik v

CobiT 3rd Edition CobiT 4.1 DS1 Definiowanie i zarządzanie poziomami usług. 1.1 Struktura umów SLA 1.1 1.2 Aspekty umów SLA 1.3 1.3 Procedury wykonania 1.1 1.4 Monitorowanie i 1.5 sprawozdawczość 1.5 Przegląd umów SLA 1.6 i kontraktów 1.6 Pozycje podlegające opłacie 1.3 1.7 Program doskonalenia 1.6 usług DS2 Zarządzanie usługami zewnętrznymi. 2.1 Interfejsy dostawców 2.1 2.2 Relacje właścicielskie 2.2 2.3 Umowy ze stronami AI5.2 trzecimi 2.4 Kwalifikacje stron trzecich AI5.3 2.5 Umowy outsourcingowe AI5.2 2.6 Ciągłość usług 2.3

CobiT 3rd Edition CobiT 4.1 2.7 Relacje dotyczące 2.3 bezpieczeństwa 2.8 Monitoring 2.4DS3 Zarządzanie wydajnością i potencjałem. 3.1 Wymagania dotyczące 3.1 dostępności i wydajności 3.2 Plan dostępności 3.4 3.3. Monitorowanie i 3.5 sprawozdawczość 3.4 Narzędzia modelujące 3.1 3.5 Aktywne zarządzanie 3.3 wydajnością 3.6 Prognozowanie obciążenia 3.3 3.7 Zarządzanie potencjałem 3.2 zasobów 3.8 Dostępność zasobów 3.4 3.9 Harmonogram dostępności 3.4 zasobów DS4 Zapewnienie ciągłości działania usług. 4.1 Metodyka zapewnienia 4.1 ciągłości IT

CobiT 3rd Edition CobiT 4.1 4.2 Strategia i filozofia 4.1 planu zapewnienia ciągłości IT 4.3 Zawartość planu 4.2 zapewnienia ciągłości IT 4.4 Minimalizacja wymagań 4.3 zapewnienia ciągłości IT 4.5 Utrzymywanie planu 4.4 zapewnienia ciągłości IT 4.6 Testowanie planu 4.5 zapewnienia ciągłości IT 4.7 Szkolenie w zakresie 4.6 planu zapewnienia ciągłości IT 4.8 Dystrybucja planu 4.7 zapewnienia ciągłości IT 4.9 Procedury sporządzania 4.8 kopii zapasowych alternatywnego przetwarzania dla działu obsługi użytkownika 4.10 Krytyczne zasoby IT 4.3 4.11 Zapasowa siedziba 4.8 i sprzęt

CobiT 3rd Edition CobiT 4.1 AI1 Identyfikowanie rozwiązań zautomatyzowanych. 1.1 Określenie wymagań 1.1 informacyjnych 1.2 Określenie 1.3, 5.1, alternatywnych sposobów PO1.4 postępowania 1.3 Określenie 1.3, 5.1, strategii nabywania PO1.4 1.4. Wymagania dotyczące 5.1, 5.3 usług zewnętrznych 1.5 Studium wykonalności 1.3 technicznej 1.6 Studium wykonalności 1.3 ekonomicznej 1.7 Architektura informacji 1.3 1.8 Raport dotyczący analizy 1.2 ryzyka 1.9 Efektywne kosztowo 1.1, 1.2 mechanizmy kontroli bezpieczeństwa 1.10 Projekt ścieżek 1.1, 1.2 rewizyjnych 1.11 Ergonomia 1.1 1.12 Wybór oprogramowania 1.1, 1.3 systemowego 1.13 Kontrola nad 5.1 zaopatrzeniem 1.14 Nabywanie 5.1 oprogramowania 1.15. Pielęgnacja 5.4 oprogramowania zewnętrznego 1.16 Programowanie aplikacji 5.4 objętych umową 1.17 Akceptacja infrastruktury 5.4 1.18 Akceptacja 3.1, 3.2, 3.3, technologii 5.4 AI2 Nabywanie i utrzymywanie aplikacji. 2.1 Metody projektowania 2.1 2.2 Znaczące zmiany 2.1, 2.2, 2.6 istniejących systemów 2.3 Zatwierdzanie projektów 2.1 2.4 Definiowanie i dokumentacja 2.2 wymagań dotyczących plików

CobiT 3rd Edition CobiT 4.1 2.5 Specyfikacje 2.2 oprogramowania 2.6 Projekt gromadzenia 2.2 danych źródłowych 2.7 Definiowanie i dokumentacja 2.2 wymagań dotyczących danych wejściowych 2.8 Definiowanie interfejsów 2.2 2.9 Interfejs użytkownik– 2.2 maszyna 2.10 Definiowanie i dokumentacja 2.2 wymagań dotyczących przetwarzania 2.11 Definiowanie 2.2 i dokumentacja wymagań dotyczących danych wyjściowych 2.12 Kontrolowalność 2.3, 2.4 2.13 Dostępność jako kluczowy 2.2 czynnik projektowania 2.14 Rozwiązania służące 2.3, DS11.5 zapewnieniu integralności IT w oprogramowaniu aplikacji 2.15 Testowanie oprogramowania aplikacji 2.8, 7.4 2.16 Materiały informacyjne 4.3. 4.4 i pomocnicze dla użytkownika 2.17 Ponowna ocena 2.2 projektu systemu AI3 Nabywanie i utrzymywanie infrastruktury

technicznej. 3.1 Ocena nowego 3.1, 3.2, 3.3 sprzętu i oprogramowania 3.2 Prewencyjna DS13.5 konserwacja sprzętu 3.3 Bezpieczeństwo 3.1, 3.2, 3.3 oprogramowania systemowego 3.4 Instalacja oprogramowania 3.1, 3.2, 3.3 systemowego 3.5 Pielęgnacja oprogramowania 3.3 systemowego 3.6 Mechanizmy kontrolne zmian 6.1, 7.3 oprogramowania systemowego 3.7 Użytkowanie i 3.2, 3.3, DS9.3 monitorowanie narzędzi systemowych

CobiT 3rd Edition CobiT 4.1 AI4 Rozwijanie i utrzymywanie procedur. 4.1 Wymagania operacyjne 4.1 i poziomy usług 4.2 Podręcznik procedur dla 4.2 użytkowników 4.3 Podręcznik operacyjny 4.4 4.4 Materiały szkoleniowe 4.3, 4.4 AI5 Instalacja i akredytacja systemów. 5.1 Szkolenie 7.1 5.2 Wymiarowanie wydajności 7.6, DS3.1 oprogramowania aplikacji 5.3 Plan wdrożenia 7.2, 7.3 5.4 Konwersja systemów 7.5 5.5 Konwersja danych 7.5 5.6 Strategie i plany 7.2 testowania 5.7 Testowanie zmian 7.4, 7.6 5.8 Kryteria i wydajność 7.6 testowania równoległego/ pilotażowego 5.9 Końcowy test zatwierdzający 7.7 5.10 Testowanie i akredytacja 7.6 bezpieczeństwa 5.11 Test operacyjny 7.6 5.12 Przekazanie do produkcji 7.8 5.13 Ocena spełniania 7.9 wymagań użytkowników 5.14 Kierowniczy 7.9 przegląd powdrożeniowy AI6 Zarządzanie zmianami. 6.1 Inicjowanie i kontrola 61, 6.4 żądań zmian 6.2 Ocena wpływu 6.2 6.3 Kontrola zmian 7.9 6.4 Doraźne zmiany 6.3 6.5 Dokumentacja 6.5 i procedury 6.6 Zatwierdzone utrzymanie DS5.3 6.7 Polityka wprowadzania 7.9 oprogramowania 6.8 Dystrybucja oprogramowania 7.9


CobiT 4.1 CobiT 3rd Edition CobiT 4.1 4.12 Pozamiejscowa lokalizacja 4.9 kopii zapasowych 4.13 Procedury podsumowujące 4.10 DS5 Zapewnienie bezpieczeństwa systemów. 5.1 Zarządzanie środkami 5.1 bezpieczeństwa. 5.2 Identyfikacja, 5.3 uwierzytelnienie i dostęp 5.3 Bezpieczeństwo dostępu 5.3 sieciowego do danych 5.4 Zarządzanie kontami 5.4 użytkowników 5.5 Przegląd kierowniczy 5.4 kont użytkowników 5.6 Kontrola użytkowników 5.4, 5.5 nad kontami użytkowników 5.7 Nadzór nad 5.5 bezpieczeństwem 5.8 Klasyfikacja danych PO2.3 5.9 Centralne zarządzanie 5.3 identyfikacją i prawami dostępu 5.10 Sprawozdania dotyczące 5.5 naruszeń i działań w celu zapewnienia bezpieczeństwa 5.11 Obsługa incydentów 5.6 5.12 Ponowna akredytacja 5.1 5.13 Zaufanie wobec 5.3, AC6 kontrahentów 5.14 Zatwierdzanie 5.3 transakcji 5.15 Określanie tożsamości 5.11 5.16 Bezpieczna ścieżka 5.11 5.17 Ochrona funkcji 5.7 bezpieczeństwa 5.18 Zarządzanie kluczami 5.8 kryptograficznymi 5.19 Ochrona przed złośliwym 5.9 oprogramowaniem, jego wykrywanie i wprowadzanie poprawek 5.20 Architektura zapory 5.10 ogniowej i połączeń z sieciami publicznymi 5.21 Ochrona pieniądza 13.4 elektronicznego DS6 Identyfikowanie i rozliczanie kosztów. 6.1 Pozycje podlegające 6.1 opłacie 6.2 Procedury kalkulacji 6.3 kosztów 6.3 Procedury fakturowania 6.2, 6.4 i rozliczania się z użytkownikami DS7 Kształcenie i szkolenie użytkowników. 7.1 Rozpoznanie potrzeb 7.1 szkoleniowych 7.2 Organizacja szkoleń 7.2 7.3 Szkolenie w zakresie PO7.4 zasad i świadomości bezpieczeństwa

CobiT 3rd Edition CobiT 4.1 DS8 Pomoc i doradztwo klientom. 8.1 Helpdesk 8.1, 8.5 8.2 Rejestrowanie 8.2, 8.3, 8.4 zapytań klientów 8.3 Eskalacja zapytań 8.3 klientów 8.4 Monitorowanie obsługi 10.3 8.5 Sprawozdawczość 10.1 i analiza trendów DS9 Zarządzanie konfiguracją. 9.1 Rejestrowanie konfiguracji 9.1 9.2 Punkty wyjściowe 9.1 konfiguracji 9.3 Ewidencjonowanie stanu 9.3 9.4 Kontrola konfiguracji 9.3 9.5 Niedozwolone 9.3 oprogramowanie 9.6 Przechowywanie AI3.4 oprogramowania 9.7 Procedury zarządzania 9.2 konfiguracją 9.8 Rozliczalność 9.1, 9.2 oprogramowania DS10 Zarządzanie problemami i incydentami. 10.1 System zarządzania 10.1, 10.2, problemami 10.3, 10.4 10.2 Eskalacja problemów 10.2 10.3 Śledzenie problemów 8.2, 10.2 i ścieżka rewizyjna 10.4 Autoryzacja awaryjnego 5.4, 12.3, i tymczasowego AI6.3 dostępu 10.5 Priorytety awaryjnego 10.1, 8.3 przetwarzania DS11 Zarządzanie danymi. 11.1 Procedury AC1 przygotowywania danych 11.2 Procedury zatwierdzania AC1 dokumentów źródłowych 113 Gromadzenie danych AC1 dokumentów źródłowych 11.4 Obsługa błędów AC1 w dokumentach źródłowych 113 Zachowywanie dokumentów DS11.2 źródłowych 11.6 Procedury zatwierdzania AC2 wprowadzania danych11.7 Kontrola dokładności, AC3 kompletności i zatwierdzenia 11.8 Obsługa błędów AC2, AC4 wprowadzania danych 11.9 Integralność AC4 przetwarzania danych 11.10 Przetwarzanie, AC4 sprawdzanie poprawności i edycja danych 11.11 Obsługa błędów AC4 przetwarzania danych 11.12 Opracowywanie i AC5, 11.2 utrzymywanie danych wyjściowych 11.13 Dystrybucja danych AC5, AC6 wyjściowych

CobiT 3rd Edition CobiT 4.1 11.14 Optymalizacja i uzgadnianie AC5 danych wyjściowych 11.15 Przegląd danych AC5 wyjściowych i obsługa błędów 11.16 Zapewnienie 11.6 bezpieczeństwa raportów wyjściowych 11.17 Ochrona wrażliwych AC6, 11.6 informacji podczas transmisji i transportu 11.18 Ochrona usuniętych 11.4, AC6 wrażliwych informacji 11.19 Zarządzanie 11.2 przechowywaniem danych 11.20 Czas i warunki 11.2 przechowywania 11.21 System zarządzania 11.3 biblioteką mediów 11.22 Odpowiedzialność za 11.3 zarządzanie biblioteką mediów 11.23 Kopie zapasowe 11.5 i przywracanie danych 11.24 Zadania sporządzania 11.4 kopii zapasowych 11.25 Przechowywanie kopii 4.9, 11.3 zapasowych 11.26 Archiwizacja 11.2 11.27 Ochrona 11.6 wrażliwych wiadomości 11.28 Uwierzytelnianie AC6 i integralność 11.29 Integralność transakcji 5.11 elektronicznych 11.30 Trwała integralność 11.2 przechowywanych danych DS12 Zarządzanie infrastrukturą. 12.1 Fizyczne bezpieczeństwo 12.1, 12.2 12.2 Dyskretna siedziba 12.1, 12.2 działu IT 12.3 Towarzyszenie gościom 12.3 12.4 Bezpieczeństwo 12.1, 12.5, i higiena pracy ME3.1 12.5 Ochrona przed 12.4, 12.5 czynnikami środowiskowymi 12.6 Podtrzymanie 12.5 zasilania DS13 Zarządzanie operacjami. 13.1 Podręcznik z instrukcjami 13.1 i procedurami dotyczącymi operacji przetwarzania 13.2 Dokumentacja procesu 13.1 uruchamiania i innych operacji 13.3 Tworzenie 13.2 harmonogramów prac 13.4 Odstępstwa od 13.2 standardowych harmonogramów prac 13.5 Ciągłość przetwarzania 13.1 13.6 Dzienniki operacji 13.1 13.7 Mechanizmy ochrony 13.4 specjalnych formularzy i urządzeń wyjściowych 13.8 Operacje zdalne 5.11


ZałącZnik v CobiT 3rd Edition CobiT 4.1 M1 Monitorowanie procesów. 1.1 Gromadzenie danych z 1.2 monitoringu 1.2 Ocenianie wydajności 1.4 1.3 Ocenianie zadowolenia 1.2 klientów 1.4 Sprawozdania dla 1.5 kierownictwa M2 Ocena adekwatności wewnętrznych mechanizmów kontrolnych. 2.1 Monitoring kontroli wewnętrznej 2.2 2.2 Terminowe działanie 2.1 wewnętrznych mechanizmów kontrolnych 2.3 Raportowanie poziomu 2.2, 2.3 kontroli wewnętrznej 2.4 Zapewnienie 2.4 bezpieczeństwa operacyjnego i kontroli wewnętrznej M3 Uzyskanie niezależnego potwierdzenia. 3.1 Niezależna certyfikacja/ 2.5, 4.7 akredytacja bezpieczeństwa i wewnętrznej kontroli usług IT

CobiT 3rd Edition CobiT 4.1 3.2 Niezależna certyfikacja/ 2.5, 4.7 akredytacja bezpieczeństwa i wewnętrznej kontroli zewnętrznych dostawców usług 3.3 Niezależna 2.5, 4.7 ocena efektywności usług IT 3.4 Niezależna 2.5, 4.7 ocena efektywności zewnętrznych dostawców usług 3.5 Niezależne potwierdzenie 2.5, 4.7 zgodności z przepisami prawa, wymaganiami regulacyjnymi i zobowiązaniami wynikającymi z umów 3.6 Niezależne potwierdzenie 2.5, 2.6, 4.7 zachowywania zgodności z przepisami prawa, wymaganiami regulacyjnymi i zobowiązaniami wynikającymi z umów przez zewnętrznych dostawców usług

CobiT 3rd Edition CobiT 4.1 3.7 Kompetencje 2.5, 4.7 niezależnej funkcji kontroli wewnętrznej 3.8 Aktywny udział 2.5, 4.7 w audycie M4 Zapewnienie niezależnego audytu. 4.1 Karta audytu 2.5, 4.7 4.2 Niezależność 2.5, 4.7 4.3 Etyka i standardy 2.5, 4.7 zawodowe 4.4 Kompetencje 2.5, 4.7 4.5 Planowanie 2.5, 4.7 4.6 Wykonanie prac 2.5, 4.7 audytorskich 4.7 Sprawozdawczość 2.5, 4.7 4.8 Działania kontrolne 2.5, 4.7


CobiT 4.1Wzajemne relacje: CobiT 4.1 w odniesieniu do CobiT 3rd Edition

CobiT 4.1 CobiT 3rd Edition PO1 Definiowanie planu strategicznego IT. 1.1 Zarządzanie wartością IT 5.3 1.2 Zgodność między Nowy działalnością biznesową a IT 1.3 Ocena aktualnej 1.7, 1.8 zdolności i wydajności 1.4 Plan strategiczny IT 1.1, 1.2, 1.3,

1.4, 1.6, AI1.2, AI1.3

1.5 Plany taktyczne IT 1.5 1.6 Zarządzanie portfelem IT Nowy PO2 Definiowanie architektury informacji. 2.1 Model architektury 2.1 informacji przedsiębiorstwa 2.2 Słownik danych 2.2 przedsiębiorstwa i zasady składni danych 2.3 Schemat klasyfikacji 2.3, 2.4, DS5.8 danych 2.4 Zarządzanie integralnością Nowy PO3 Ustalanie kierunku technologicznego. 3.1 Planowanie 3.1, 3.3, 3.4 kierunku technologicznego 3.2 Plan Nowy infrastruktury technicznej 3.3 Monitorowanie przyszłych 3.2 trendów i regulacji 3.4 Standardy technologiczne 3.5 3.5 Rada ds. architektury IT 3.5 PO4 Definiowanie procesów IT, organizacji

i wzajemnych zależności. 4.1 Struktura ramowa

procesów IT Nowy 4.2 Komitet strategiczny ds. IT Nowy 4.3 Komitet sterujący ds. IT 4.1 4.4 Organizacyjne 4.2 umiejscowienie funkcji działu IT 4.5 Struktura organizacyjna 4.3 działu IT 4.6 Określenie ról 4.4, 4.12 i zakresów odpowiedzialności 4.7 Odpowiedzialność za 4.5 zapewnienie jakości IT 4.8 Odpowiedzialność za 4.6 zarządzanie ryzykiem, bezpieczeństwo i zgodność 4.9 Własność danych 4.7, 4.8 i systemów 4.10 Nadzór 4.9 4.11 Rozdział obowiązków 4.10

CobiT 4.1 CobiT 3rd Edition 4.12 Obsada stanowisk w 4.11 dziale IT 4.13 Kluczowy personel IT 4.13 4.14 Polityka i procedury 4.14 dotyczące pracowników kontraktowych 4.15 Relacje 4.15 PO5 Zarządzanie inwestycjami IT. 5.1 Struktura zarządzania Nowy finansowego 5.2 Określanie hierarchii Nowy ważności w ramach budżetu IT 5.3 Planowanie budżetu IT 5.1, 5.3 5.4 Zarządzanie kosztami 5.2, 5.3 5.5 Zarządzanie korzyściami 5.3 PO6 Komunikowanie celów i kierunku

zarządzania. 6.1 Polityka IT i środowisko 6.1 systemu kontroli 6.2 Ryzyko informatyczne 6.8 przedsiębiorstwa i struktura mechanizmów kontrolnych 6.3 Zarządzanie polityką IT 6.2, 6.3, 6.5,

6.6, 6.7, 6.9, 6.10, 6.11

6.4 Wdrażanie polityki, 6.2, 6.3, 6.4, standardów i procedur 6.5, 6.6, 6.7,

6.9, 6.10, 6.11 6.5 Komunikowanie celów 6.2, 6.3, 6.5, i kierunku działalności IT 6.6, 6.7, 6.9,

6.10, 6.11 PO7 Zarządzanie zasobami ludzkimi w IT. 7.1 Rekrutacja i utrzymywanie 7.1 pracowników 7.2 Kompetencje pracowników 7.2 7.3 Obsada stanowisk Nowy 7.4 Szkolenie pracowników 7.3, DS7.3 7.5 Zależność od 7.4 pojedynczych osób 7.6 Procedury weryfikacji 7.5 pracowników 7.7 Ocena wyników 7.6 pracy pracowników 7.8 Zmiana i zakończenie 7.7, 7.8 pracy PO8 Zarządzanie jakością. 8.1 System zarządzania 11.2, 11.3, jakością 11.4

CobiT 4.1 CobiT 3rd Edition 8.2 Standardy IT i praktyki 11.5, 11.6, związane z zarządzaniem 11.7, 11.8, jakością 11.9, 11.10, 11.16, 11.17, 11.19 8.3 Standardy rozwoju 11.5, 11.6, i nabywania 11.7 8.4 Ukierunkowanie na klienta Nowy 8.5 Ciągłe doskonalenie Nowy 8.6 Pomiar, monitorowanie 11.18 i analiza jakości PO9 Ocena i zarządzanie ryzykiem informatycznym.

9.1 Struktura ramowa 9.1, 9.4, 9.8 zarządzania ryzykiem informatycznym 9.2 Ustalanie kontekstu 9.1, 9.4 ryzyka 9.3 Identyfikacja zdarzeń 9.3, 9.4 9.4 Ocena ryzyka 9.1, 9.2, 9.4 9.5 Odpowiedź na ryzyko 9.5, 9.6, 9.7 9.6 Utrzymywanie i Nowy monitorowanie realizacji planu działań związanych z zarządzaniem ryzykiem PO10 Zarządzanie projektami. 10.1 Struktura Nowy zarządzania programem 10.2 Struktura zarządzania 10.1 projektami 10.3 Podejście do zarządzania Nowy projektem 10.4 Zaangażowanie 10.2 interesariuszy 10.5 Określenie zakresu 10.4 projektu 10.6 Uruchamianie faz projektu 10.5, 10.6 10.7 Zintegrowany plan projektu 10.7 10.8 Zasoby na potrzeby projektu 10.3 10.9 Zarządzanie 10.10 ryzykiem projektu 10.10 Plan jakości projektu 10.8 10.11 Kontrola nad Nowy zmianami projektu 10.12 Planowanie metod kontroli i audytu w projekcie 10.9 10.13 Pomiar, sprawozdawczość Nowy i monitorowanie realizacji projektu 10.14 Zamknięcie projektu 10.13 (część)


ZałącZnik v CobiT 4.1 CobiT 3rd Edition AI1 Identyfikowanie rozwiązań zautomatyzowanych.

1.1 Zdefiniowanie 1.1, 1.9, 1.10, i spełnienie funkcjonalnych 1.11, 1.12 i technicznych wymagań biznesowych 1.2 Raport dotyczący analizy 1.8, 1.9, 1.10 ryzyka 1.3 Studium wykonalności 1.3, 1.7, 1.12 i określenie alternatywnych sposobów postępowania 1.4 Wymagania, decyzja Nowy dotycząca wykonalności i zatwierdzenie AI2 Nabywanie i utrzymywanie aplikacji. 2.1 Projektowanie wysokiego 2.1, 2.2 poziomu 2.2 Projektowanie szczegółowe 2.2, 2.4, 2.5,

2.6, 2.7, 2.8, 2.9, 2.10, 2.11, 2.13, 2.17

2.3 Aplikacyjne mechanizmy 2.12, 2.14 kontrolne i audytowalność 2.4 Bezpieczeństwo 2.12 i dostępność aplikacji 2.5 Konfiguracja Nowy i wdrożenie nabytych aplikacji 2.6 Znacząca modyfikacja 2.2 istniejących systemów 2.7 Programowanie Nowy aplikacji 2.8 Zapewnienie jakości 2.15 aplikacji 2.9 Zarządzanie wymaganiami Nowy wobec aplikacji

CobiT 4.1 CobiT 3rd Edition 2.10 Utrzymanie aplikacji Nowy AI3 Nabywanie i utrzymywanie infrastruktury

technicznej. 3.1 Plan nabycia PO3.4, 1.18, infrastruktury 3.1, 3.3, 3.4 technicznej 3.2 Ochrona i dostępność 1.18, 3.1, 3.3, zasobów infrastruktury 3.4, 3.7 3.3 Utrzymanie 1.18, 3.1, 3.3, infrastruktury 3.4, 3.5, 3.7 3.4 Środowisko Nowy testowania funkcjonalności AI4 Umożliwienie działania i użytkowania. 4.1 Planowanie rozwiązań 4.1 operacyjnych 4.2 Transfer wiedzy PO11.11, 4.2 do kierownictwa firmy 4.3 Transfer wiedzy PO11.11, do użytkowników końcowych 2.16, 4.4 4.4 Transfer wiedzy PO11.11, do personelu operacyjnego i 2.16, 4.3, 4.4 pomocniczego AI5 Nabywanie zasobów IT. 5.1 Kontrola nad zaopatrzeniem 1.2, 1.3, 1.4, 1.13, 1.14 5.2 Zarządzanie umowami DS2.3, DS2.5 z dostawcami 5.3 Wybór dostawców 1.4, DS2.4 5.4 Nabywanie zasobów IT 1.15, 1.16, 1.17, 1.18 AI6 Zarządzanie zmianami. 6.1 Standardy i procedury 3.6, 6.1 zmian

CobiT 4.1 CobiT 3rd Edition 6.2 Ocena, określanie hierarchii 6.2 ważności i zatwierdzanie skutków 6.3 Zmiany wprowadzane DS10.4, 6.4 w trybie awaryjnym 6.4 Śledzenie i raportowanie 6.1 stanu zmian 6.5 Zakończenie 6.5 i dokumentacja zmian AI7 Instalowanie i akredytowanie rozwiązań

i zmian. 7.1 Szkolenie PO10.11,

PO10.12, 5.1 7.2 Plan testów PO10.11,

PO11.12, PO11.13, PO11.14, PO11.15, 5.3, 5.6

7.3 Plan wdrożenia 3.6, 5.3 7.4 Środowisko testowe PO11.12, PO11.13,

PO11.14, PO11.15, 2.15, 5.7

7.5 Konwersja systemów 5.4, 5.5 i danych 7.6 Testowanie zmian 5.2, 5.7, 5.8, 5.10, 5.11 7.7 Końcowy test zatwierdzający 5.9 7.8 Przekazanie do produkcji 5.12 7.9 Przegląd 5.13, 5.14 powdrożeniowy

CobiT 4.1 CobiT 3rd Edition DS1 Definiowanie i zarządzanie poziomami usług. 1.1 Struktura ramowa 1.1, 1.3 zarządzania poziomami usług 1.2 Definicje usług Nowy 1.3 Umowy dotyczące 1.2, 1.6 poziomu jakości usług (SLA) 1.4 Umowy dotyczące poziomu Nowy jakości usług wewnętrznych (OLA) 1.5 Monitorowanie 1.4 i raportowanie osiągnięć w zakresie poziomu usług 1.6 Przegląd umów i kontraktów 1.5, 1.7 dotyczących poziomu jakości usług DS2 Zarządzanie usługami zewnętrznymi. 2.1 Identyfikacja wszystkich 2.1 relacji z dostawcami 2.2 Zarządzanie relacjami 2.2 z dostawcami 2.3 Zarządzanie ryzykiem PO11.10, 2.6, współpracy z dostawcami 2.7 2.4 Monitorowanie wydajności 2.8 dostawców

CobiT 4.1 CobiT 3rd Edition DS3 Zarządzanie wydajnością i potencjałem. 3.1 Planowanie wydajności AI5.2, 3.1, 3.4 i potencjału 3.2 Aktualna wydajność 3.7 i potencjał 3.3 Przyszła wydajność 3.5, 3.6 i potencjał 3.4 Dostępność zasobów IT 3.2, 3.8, 3.9 3.5 Monitorowanie 3.3 i raportowanie DS4 Zapewnianie ciągłości usług. 4.1 Metodyka zapewnienia 4.1, 4.2 ciągłości IT 4.2 Plany zapewnienia 4.3 ciągłości IT 4.3 Krytyczne zasoby IT 4.4, 4.10 4.4 Utrzymywanie planu 4.5 zapewnienia ciągłości IT 4.5 Testowanie planu 4.6 zapewnienia ciągłości IT 4.6 Szkolenie w zakresie 4.7 planu zapewnienia ciągłości IT 4.7 Dystrybucja planu 4.8 zapewnienia ciągłości IT

CobiT 4.1 CobiT 3rd Edition 4.8 Odtwarzanie i wznawianie 4.9, 4.11 usług IT 4.9 Przechowywanie kopii 4.12, 11.25 zapasowych poza podstawową lokalizacją 4.10 Przegląd 4.13 po wznowieniu DS5 Zapewnienie bezpieczeństwa systemów. 5.1 Zarządzanie 5.1, 5.12 bezpieczeństwem IT 5.2 Plan zapewnienia Nowy bezpieczeństwa IT 5.3 Zarządzanie tożsamością 5.2, 5.3, 5.9,

5.14, AI6.6 5.4 Zarządzanie kontami 5.4, 5.5, 5.6, użytkowników 5.13, 10.4 5.5 Testowanie, nadzorowanie 5.6, 5.7, 5.10 i monitorowanie bezpieczeństwa 5.6 Definicja incydentu 5.11 związanego z bezpieczeństwem 5.7 Ochrona technologii 5.17 zabezpieczeń 5.8 Zarządzanie kluczami 5.18 kryptograficznymi


CobiT 4.1 CobiT 4.1 CobiT 3rd Edition 5.9 Ochrona przed złośliwym 5.19 oprogramowaniem, jego wykrywanie i wprowadzanie poprawek 5.10 Bezpieczeństwo sieciowe 5.20 5.11 Wymiana wrażliwych 5.15, 5.16 danych 11.29, 13.8 DS6 Identyfikowanie i rozliczanie kosztów. 6.1 Definicje usług 6.1 6.2 Księgowość IT 6.3 6.3 Modelowanie i naliczanie 6.2 kosztów 6.4 Utrzymywanie modelu 6.3 kosztów DS7 Kształcenie i szkolenie użytkowników. 7.1 Rozpoznanie potrzeb 7.1 edukacyjnych i szkoleniowych 7.2 Zapewnianie szkolenia 7.2 i rozwoju 7.3 Ocena przeprowadzonych Nowy szkoleń DS8 Zarządzanie jednostką Service Desk i incydentami. 8.1 Service Desk 8.1 8.2 Rejestrowanie zapytań 8.2, 10.3 klientów 8.3 Eskalacja incydentów 8.2, 8.3, 10.5 8.4 Zamykanie incydentów 8.2

CobiT 4.1 CobiT 3rd Edition 8.5 Sprawozdawczość 8.1 i analiza trendów DS9 Zarządzanie konfiguracją. 9.1 Repozytorium konfiguracji 9.1, 9.2, 9.8 i konfiguracja bazowa 9.2 Identyfikacja 9.7, 9.8 i utrzymywanie elementów konfiguracji 9.3 Przegląd integralności 9.3, 9.4, 9.5 konfiguracji DS10 Zarządzanie problemami. 10.1 Identyfikacja 8.5, 10.1, 10.5 i klasyfikacja problemów 10.2 Śledzenie i rozwiązywanie Nowy problemów 10.3 Zamykanie problemów 8.4, 10.1 10.4 Integracja Nowy, 10.1 zarządzania konfiguracją, incydentami i problemami DS11 Zarządzanie danymi. 11.1 Wymagania biznesowe Nowy dotyczące zarządzania danymi 11.2 Organizacja 11.12, 11.19, przechowywania 11.20, 11.26, i utrzymywania danych 11.30

CobiT 4.1 CobiT 3rd Edition 11.3 System zarządzania 11.21, 11.22, biblioteką mediów 11.25 11.4 Pozbywanie się danych 11.18, 11.24 11.5 Kopie zapasowe i AI2.14, 11.23 przywracanie danych 11.6 Wymagania bezpieczeństwa 11.16, 11.17, dotyczące zarządzania danymi 11.27 DS12 Zarządzanie środowiskiem fizycznym. 12.1 Wybór miejsca 12.1, 12.2, i rozmieszczenia 12.4 12.2 Fizyczne środki 12.1, 12.2 bezpieczeństwa 12.3 Fizyczny dostęp 10.4, 12.3 12.4 Ochrona przed 12.5 czynnikami środowiskowymi 12.5 Zarządzanie fizyczną 12.4, 12.6, infrastrukturą 12.5 DS13 Zarządzanie operacjami. 13.1 Procedury i instrukcje 13.1, 13.2, operacyjne 13.5, 13.6 13.2 Tworzenie 13.3, 13.4 harmonogramów prac 13.3 Monitorowanie Nowy infrastruktury IT 13.4 Dokumenty wrażliwe 5.21, 13.7 i urządzenia wyjściowe 13.5 Prewencyjna AI3.2 konserwacja sprzętu

CobiT 4.1 CobiT 3rd Edition ME1 Monitorowanie i ocena wydajności IT. 1.1 Podejście do monitorowania 1.0* 1.2 Definiowanie i gromadzenie 1.1, 1.3 danych z monitoringu 1.3 Metoda monitoringu Nowy 1.4 Ocena wydajności 1.2 1.5 Sprawozdawczość na 1.4 potrzeby zarządu i kierownictwa 1.6 Działania naprawcze Nowy ME2 Monitorowanie i ocena kontroli wewnętrznej. 2.1 Monitorowanie struktury 2.0*, 2.2 wewnętrznych mechanizmów kontrolnych 2.2 Przegląd nadzorczy 2.1, 2.3 2.3 Błędy zidentyfikowane Nowy w wyniku kontroli

CobiT 4.1 CobiT 3rd Edition 2.4 Samoocena kontroli 2.4 2.5 Zapewnienie wewnętrznej Nowy kontroli 2.6 Wewnętrzne mechanizmy 3.6 kontrolne u stron trzecich 2.7 Działania naprawcze Nowy ME3 Zapewnianie zgodności z zewnętrznymi regulacjami.

3.1 określenie zewnętrznych PO8.1, PO8.3, wymagań prawnych, PO8.4, PO8.5, regulacyjnych oraz tych PO8.6, DS12.4 wynikających z umów 3.2 Optymalizacja dostosowania PO8.2 do zewnętrznych regulacji 3.3 ocena zgodności Nowy z zewnętrznymi regulacjami

CobiT 4.1 CobiT 3rd Edition 3.4 Zapewnienie Nowy zgodności 3.5 Zintegrowana Nowy sprawozdawczość ME4 Zapewnienie ładu informatycznego. 4.1 Ustanowienie ram ładu informatycznego Nowy 4.2 Dopasowanie strategiczne Nowy 4.3 Dostarczanie wartości Nowy 4.4 Zarządzanie zasobami Nowy 4.5 Zarządzanie ryzykiem Nowy 4.6 Pomiar Nowy wydajności 4.7 Niezależna gwarancja Nowy

* Procesy ME1.0 i ME2.0 przedstawione w publikacji Control Practices (Praktyki kontrolne), opublikowanej przez ITGI w 2004 r.

z a ł ą c z n i k v i

P o d e j ś c i e d o b a d a ń i r o z w o j u

Za

łą

cZ

nik v

i P

OD

EJŚc

iE


załącznik vi — Podejście do badań i rozwoju

Rozwój metodyki CobiT jest stale nadzorowany przez komitet sterujący CobiT, w którego skład wchodzą reprezentujący różne kraje przedstawiciele branży informatycznej, środowiska akademickiego i instytucji rządowych oraz specjaliści w dziedzinie nadzoru informatycznego, kontroli wewnętrznej, kontroli i zapewnienia bezpieczeństwa. Stworzenie międzynarodowych grup roboczych miało na celu zapewnienie odpowiedniej jakości oraz eksperckiego nadzoru nad bieżącymi badaniami i efektami prac rozwojowych. Ogólny nadzór nad projektem sprawuje instytut ITGI.

POPRZEDNiE WYDaNia METODYKi CobiTWraz z powstaniem metodyki CobiT, zdefiniowanej w jej pierwszym wydaniu, przełożenie międzynarodowych standardów, wytycznych i badań na dobre praktyki doprowadziło do stworzenia celów kontrolnych. Następnie opracowano wytyczne audytu w celu oceny, czy wspomniane cele kontrolne zostały właściwie wdrożone. Badania przeprowadzone na potrzeby pierwszego i drugiego wydania polegały na gromadzeniu i analizie zidentyfikowanych międzynarodowych źródeł i zostały przeprowadzone przez zespoły działające w Europie (Free University of Amsterdam), Stanach Zjednoczonych (California Polytechnic University) oraz Australii (University of New South Wales). Badania miały na celu kompilację, przegląd, ocenę i właściwe uwzględnienie międzynarodowych standardów technicznych, kodeksów postępowania, standardów jakościowych, standardów zawodowych w dziedzinie audytu oraz praktyk i wymogów branżowych w odniesieniu do metodyki oraz poszczególnych celów kontrolnych. Po zgromadzeniu materiałów i ich analizie badacze stanęli przed wyzwaniem dogłębnej analizy poszczególnych domen i procesów, tak aby móc zaproponować dla każdego z nich nowe lub zmodyfikowane cele kontrolne. Wyniki ich pracy zostały połączone w całość przez komitet sterujący CobiT.

Projekt CobiT 3rd Edition miał na celu opracowanie wytycznych zarządzania oraz aktualizację metodyki CobiT 2nd Edition w oparciu o nowe i zmodyfikowane materiały źródłowe. Ponadto metodyka CobiTzostała zmodyfikowana i udoskonalona z myślą o wsparciu zwiększonej kontroli zarządczej, wprowadzeniu zarządzania sprawnością oraz dalszym rozwoju nadzoru informatycznego. Aby dostarczyć kierującym przedsiębiorstwami wskazówek, w jaki sposób stosować metodykę, tak aby mogli oni dokonywać oceny i wyboru sposobów wdrożenia kontroli i udoskonaleń w dziedzinie technologii informatycznych i pokrewnych, a także pomiarów wydajności, wytyczne zarządzania uwzględniają modele dojrzałości, kluczowe czynniki sukcesu, a także kluczowe wskaźniki celów (KGI) i wydajności (KPI) odnoszące się do celów kontrolnych.

Wytyczne zarządzania zostały opracowane przez 40-osobowy zespół ekspertów z branży informatycznej, środowiska akademickiego i instytucji rządowych oraz specjalistów w dziedzinie nadzoru informatycznego, kontroli wewnętrznej, kontroli i zapewnienia bezpieczeństwa. Uczestniczyli oni w stacjonarnych warsztatach prowadzonych przez profesjonalnych moderatorów, opierając się na wytycznych określonych przez komitet sterujący CobiT. Warsztaty były intensywnie wpierane przez firmy Gartner Group i PricewaterhouseCoopers, które nie tylko profesjonalnie moderowały przebieg prac, ale także były reprezentowane przez kilku ekspertów z dziedziny kontroli, zarządzania sprawnością i bezpieczeństwa informacji. Efektem warsztatów było stworzenie roboczych opisów modeli dojrzałości, kluczowych czynników sukcesu oraz kluczowych wskaźników celów (KGI) i wydajności (KPI) dla każdego z 34 procesów CobiT. Nad zapewnieniem jakości wstępnych efektów prac czuwał komitet sterujący CobiT, a opracowane materiały zostały udostępnione do wglądu w witrynie internetowej stowarzyszenia ISACA. Dokument wytycznych zarządzania oferował nowy zestaw narzędzi przeznaczonych dla kadry zarządzającej, zapewniając jego integrację i spójność z metodyką CobiT.

Aktualizacja celów kontrolnych w ramach metodyki CobiT 3rd Edition, w oparciu o nowe i zmodyfikowane materiały źródłowe, została opracowana przez członków oddziałów stowarzyszenia ISACA przy wsparciu członków komitetu sterującego CobiT. Celem nie było przeprowadzenie globalnej analizy całego materiału ani ponowne zdefiniowanie celów kontrolnych, lecz przeprowadzenie procesu przyrostowej aktualizacji. Efekty rozwoju wytycznych zarządzania zostały następnie wykorzystane do modyfikacji metodyki CobiT — zwłaszcza sformułowań dotyczących uwarunkowań, celów i czynników sprawczych w opisach procesów. Metodyka CobiT 3rd Edition została opublikowana w lipcu 2000 r.

OsTaTNia aKTUaLiZaCja PROjEKTUDążąc do stałego doskonalenia standardów CobiT, komitet sterujący CobiT zainicjował dwuletni program badań w obszarze kilku szczegółowych aspektów metodyki CobiT. Te ukierunkowane projekty badawcze dotyczyły komponentów celów kontrolnych oraz wytycznych zarządzania. Poniżej przedstawiono niektóre z badanych szczegółowych zagadnień.

Badania w obszarze celów kontrolnych• Oddolne dopasowanie między metodyką CobiT a nadzorem informatycznym.• Odgórne dopasowanie między metodyką CobiT a nadzorem informatycznym.• Metodyka CobiT i inne szczegółowe standardy — szczegółowe powiązanie metodyki CobiT z metodykami ITIL, CMM,

COSO, PMBOK oraz standardami dobrych praktyk w dziedzinie bezpieczeństwa informacji (Standard of Good Practice for Information Security, ISF) i standardem ISO 27000 w celu zapewnienia harmonizacji języka, definicji i pojęć.

ZałącZnik vi

Za

łą

cZ

nik v

i P

OD

EJŚc

iE


CobiT 4.1Badania w obszarze wytycznych zarządzania• Analiza związków przyczynowo-skutkowych między wskaźnikami KGI i KPI.• Przegląd jakości wskaźników KGI i KPI oraz czynników CSF w oparciu analizę związków przyczynowo-skutkowych między

wskaźnikami KGI i KPI oraz podział czynników CSF na „to, czego potrzebujesz od innych” oraz „to, co musisz zrobić samodzielnie”.

• Szczegółowa analiza pojęć mierników we współpracy z ekspertami w dziedzinie mierników, mająca na celu udoskonalenie pojęć mierników, stworzenie hierarchii mierników „proces – IT – biznes” oraz zdefiniowania kryteriów jakościowych dla mierników.

• Powiązanie celów biznesowych, celów IT i procesów IT — szczegółowe badanie w ośmiu branżach, które dostarczyło bardziej szczegółowej wiedzy o tym, w jaki sposób procesy CobiT wspierają osiąganie określonych celów IT, a co za tym idzie — celów biznesowych (rezultaty zostały następnie uogólnione).

• Przegląd zawartości modelu dojrzałości w celu zapewnienia odpowiedniej spójności i jakości poziomów dojrzałości w ramach procesów i między nimi, włączając udoskonalenie definicji atrybutów modelu dojrzałości.

Wszystkie z tych projektów zostały zainicjowane i były nadzorowane przez komitet sterujący CobiT, natomiast codziennym zarządzaniem i śledzeniem postępu prac zajmował się mniejszy główny zespół CobiT. Realizacja większości wspomnianych projektów badawczych w znacznym stopniu opierała się na kompetencjach i bezinteresownym zaangażowaniu zespołu członków stowarzyszenia ISACA, użytkowników metodyki CobiT, fachowych doradców i pracowników naukowych. Lokalne grupy robocze działały w Brukseli (Belgia), Londynie (Anglia), Chicago (USA), Canberze (Australia), Cape Town (RPA), Waszyngtonie (USA) i Kopenhadze (Dania), gdzie średnio 2–3 razy do roku spotykało się od pięciu do dziesięciu użytkowników metodyki CobiT, aby realizować określone zadania badawcze lub analityczne przydzielone przez główny zespół CobiT. Ponadto wybrane projekty badawcze zostały przekazane do realizacji uczelniom biznesowym, takim jak University of Antwerp Management School (UAMS) czy University of Hawaii.

Rezultaty tych wysiłków badawczych wraz z uwagami przekazanymi w ciągu kilku lat przez użytkowników metodyki CobiT, a także zagadnieniami, które pojawiły się podczas prac nad rozwojem nowych produktów, takich jak praktyki kontrolne, zostały włączone do głównego projektu CobiT w celu aktualizacji i udoskonalenia celów kontrolnych, wytycznych zarządzania oraz struktury metodyki CobiT. W ramach dwóch dużych zespołów rozwojowych, z których każdy składał się z ponad 40 pochodzących z całego świata ekspertów z dziedzin nadzoru informatycznego, zarządzania i kontroli (menedżerów, konsultantów, pracowników naukowych i audytorów), dokonano przeglądu i gruntownej aktualizacji celów kontrolnych i wytycznych zarządzania. Następnie efekty działań zespołów zostały dopracowane i sfinalizowane przez mniejsze grupy robocze.

Ostateczna wersja robocza została poddana procesowi pełnej weryfikacji z udziałem około 100 specjalistów. Otrzymane komentarze zostały przeanalizowane w ramach końcowego przeglądu pod nadzorem komitetu sterującego CobiT.

Uzyskane materiały zostały następnie opracowane przez komitet sterujący CobiT, główny zespół CobiT i instytut ITGI, tak aby stworzyć w efekcie nową zawartość metodyki CobiT prezentowaną w niniejszej publikacji. Istnienie serwisu CobiT Online oznacza, że dostępna jest obecnie technologia, która umożliwia łatwiejsze zapewnienie aktualności podstawowej zawartości metodyki CobiT, dlatego będzie ona wykorzystywana jako główne repozytorium treści metodyki CobiT. Będzie ona przedmiotem aktualizacji w oparciu o przekazywane uwagi użytkowników, a także okresowe przeglądy wybranych obszarów zawartości. Okresowo zawartość metodyki CobiT będzie również publikowana w formie drukowanej i na nośnikach elektronicznych.

z a ł ą c z n i k v i i

T e r M i n o l o G i a

Za

łą

cZ

nik v

iiT

er

Min

oL

og

ia


załącznik vii — TerMinoloGia

analiza porównawcza — systematyczne podejście do porównywania osiągnięć organizacji w przyswajaniu najlepszych sposobów prowadzenia działalności biznesowej względem innych podmiotów i konkurentów (np. analiza porównawcza jakości, wydajności logistycznej i wielu innych mierników).

analiza przyczyny podstawowej — proces diagnozowania i określania przyczyn zdarzeń, który może pomocny w wyciąganiu wniosków z następstw (zwykle błędów i problemów).

architektura informacji — jeden z komponentów architektury IT (obok aplikacji i technologii). Patrz architektura IT.

architektura IT — opis podstawowej struktury komponentów IT firmy, relacji między nimi, a także sposobów, w jaki wspierają one realizację celów organizacji.

architektura korporacyjna — opis podstawowej struktury komponentów systemu biznesowego lub jednego z elementów tego systemu (np. technologii), relacji między nimi, a także sposobów, w jaki wspierają one realizację celów organizacji.

architektura korporacyjna systemów informatycznych — opis podstawowej struktury komponentów IT firmy, relacji między nimi, a także sposobów, w jaki wspierają one realizację celów organizacji.

Cel kontrolny — opis pożądanego rezultatu lub celu, który powinien zostać osiągnięty poprzez wdrożenie procedur kontrolnych dla danego procesu.

ceO — dyrektor generalny (ang. Chief Executive Officer); osoba zajmująca najwyższą pozycję w hierarchii służbowej organizacji.

CFo — dyrektor ds. finansowych (ang. Chief Financial Officer); osoba odpowiedzialna za zarządzanie ryzykiem finansowym organizacji.

Ciągłość — zapobieganie, minimalizowanie skutków i przywracanie po wystąpieniu przerwy. W tym kontekście mogą być również używane terminy „planowanie wznawiania działalności”, „planowanie odtwarzania po katastrofie” i „planowanie awaryjne”; wszystkie one odnoszą się do aspektu odtwarzania w ramach zachowania ciągłości.

ciO — dyrektor ds. informatyki (ang. Chief Information Officer); osoba kierująca działem IT w organizacji. W niektórych przypadkach funkcja CIO jest rozszerzona do stanowiska dyrektora ds. zarządzania wiedzą (ang. Chief Knowledge Officer, CKO), który zarządza zasobami wiedzy, a nie tylko zasobami informatycznymi. Patrz również CTO.

CoSo (ang. Committee of Sponsoring organisations of the Treadway Commission) — Komitet Organizacji Sponsorujących Komisję Treadway’a. Opracowany przez COSO w 1992 r. raport Internal Control — Integrated Framework (Zintegrowana kontrola wewnętrzna — struktura ramowa) jest powszechnie przyjętym standardem ładu korporacyjnego. Patrz www.coso.org.

CSF (ang. Critical Success Factor) — kluczowy czynnik sukcesu; najważniejsze zagadnienia lub działania w ramach procesów IT, nad którymi powinno uzyskać kontrolę kierownictwo.

cTO — dyrektor ds. technicznych (ang. Chief Technology Officer); odpowiada za wszystkie techniczne zagadnienia w organizacji. Tytuł CTO jest często postrzegany jako synonim CIO.

Czynność — jedno z podstawowych działań podejmowanych w toku realizacji procesu CobiT.

Detekcyjny mechanizm kontrolny — mechanizm kontrolny wykorzystywany do wykrywania zdarzeń (niepożądanych lub pożądanych), błędów i innych okoliczności, które przedsiębiorstwo uznało za mające realny wpływ na przebieg procesu lub końcowy produkt.

Dojrzałość — w działalności biznesowej oznacza stopień niezawodności procesu lub zależności firmy od procesu, który firma mu wyznacza dla osiągnięcia pożądanych celów.

Domena — w ramach metodyki CobiT jest to zbiór celów kontrolnych dotyczących logicznych etapów cyklu życia inwestycji opartych na technologiach IT (Planowanie i organizacja, Nabywanie i wdrażanie, Dostarczanie i wsparcie oraz Monitorowanie i ocena).

Dostawca usług — zewnętrzny podmiot, który dostarcza usługi organizacji.

Element konfiguracji (CI) — komponent infrastruktury (lub element, taki jak żądanie zmiany dotyczące infrastruktury), który znajduje się (lub ma się znajdować) pod kontrolą zarządzania konfiguracją. Elementy konfiguracji mogą znacznie różnić się pod względem złożoności, rozmiaru i typu — poczynając do całych systemów (wraz ze sprzętem, oprogramowaniem i konfiguracją), a kończąc na pojedynczych modułach czy niewielkich komponentach sprzętu.

Incydent informatyczny — każde zdarzenie, które nie jest standardowym elementem działania usługi i powoduje lub może spowodować przerwę w świadczeniu usługi lub obniżenie jej jakości (zgodnie z ITIL).

Informowany (ang. Informed) — w schemacie RACI termin odnoszący się do osoby, która jest na bieżąco informowana o postępie czynności (komunikacja jednokierunkowa).

ZałącZnik vii

Za

łą

cZ

nik v

iiT

er

Min

oL

og

ia


CobiT 4.1ISo 27001 — Information Security Management — Specification with Guidance for Use (Zarządzanie bezpieczeństwem informacji — specyfikacje i wytyczne stosowania): standard zastępujący standard BS7799-2. Ma on na celu zapewnienie podstaw dla zewnętrznego audytu i jest zharmonizowany z innymi standardami zarządzania, takimi jak ISO/IEC 9001 i 14001.

ISo 9001:2000 — kodeks praktyki zarządzania jakością wydany przez Międzynarodową Organizację Normalizacyjną (ang. International Organisation for Standardisation, ISO). Standard ISO 9001:2000, który określa wymagania dla systemu zarządzania jakością w każdej organizacji, która chce wykazać się zdolnością do stałego dostarczania produktów lub usług spełniających określone wymagania jakościowe.

ISo/IEC 27002:2005 — międzynarodowy standard, który definiuje mechanizmy kontrolne poufności, integralności i dostępności informacji.

IT (ang. Information Technology) — technologia informatyczna, tj. sprzęt, oprogramowanie, komunikacja i inne środki wykorzystywane do wprowadzania, przechowywania, przetwarzania, przesyłania i zapisu danych w dowolnej postaci.

ITIl (ang. IT Infrastructure library) — kodeks postępowania dotyczący zarządzania i świadczenia operacyjnych usług IT, opracowany przez brytyjską agencję rządową Office of Government Commerce (OGC).

Karta audytu — dokument zatwierdzony przez zarząd, który definiuje cel, zwierzchnictwo oraz odpowiedzialność dla wewnętrznej działalności audytorskiej.

KGI (ang. Key Goal Indicator) — kluczowy wskaźnik celu; miernik, który pozwala stwierdzić post factum, czy proces IT spełnił stawiane mu wymagania biznesowe. Zwykle wyrażony w postaci kryteriów informacji.

Kluczowe praktyki zarządzania — praktyki zarządzania niezbędne do skutecznej realizacji procesów biznesowych.

Komitet strategiczny ds. IT — komitet na poziomie zarządu dbający o to, aby zarząd był zaangażowany w najważniejsze sprawy i decyzje dotyczące IT. Komitet jest odpowiedzialny przede wszystkim za zarządzanie portfelem inwestycji opartych o technologie IT, usług IT oraz innych zasobów IT. Komitet jest właścicielem tego portfela.

Konsultujący (ang. Consulted) — w schemacie RACI termin odnoszący się do osoby, której opinie są istotne dla danej czynności (komunikacja dwukierunkowa).

KPI (ang. Key Performance Indicator) — kluczowy wskaźnik wydajności; miernik, który określa, na ile dobrze proces sprawdza się w umożliwianiu realizacji określonego celu. KPI są wskaźnikami wyprzedzającymi, które pozwalają określić prawdopodobieństwo osiągnięcia celu i dobrze sprawdzają się jako wskaźniki zdolności, praktyk i umiejętności. Umożliwiają one pomiar realizacji celów czynności, które musi podjąć właściciel procesu, aby zapewnić jego efektywność.

Ład korporacyjny — zbiór obowiązków i praktyk realizowanych przez zarząd i kadrę zarządzającą, mających na celu zapewnienie kierownictwa strategicznego, osiągania założonych celów, odpowiedniego zarządzania ryzykiem oraz odpowiedzialnego wykorzystywania zasobów przedsiębiorstwa.

Mechanizm kontroli dostępu — proces, który pozwala ograniczać i kontrolować dostęp do zasobów systemu komputerowego; logiczny lub fizyczny mechanizm kontrolny mający na celu ochronę przed nieautoryzowanym dostępem lub użyciem.

Miara — standard służący do oceny i określania wydajności względem oczekiwanych wyników. Miary mają ze swej natury ilościowy charakter, wyrażający się w liczbach, jednostkach pieniężnych, procentach itp., ale mogą także opisywać elementy jakościowe, takie jak zadowolenie klienta. Raportowanie i monitorowanie miar pomaga organizacji w ocenie procesów pod kątem efektywności w realizacji strategii.

Miary wyników — miary, które pokazują efekty podjętych działań i które często określa się mianem wskaźników następujących. Często dotyczą one wyników na koniec określonego przedziału czasowego i odnoszą się do wyników historycznych. Nazywa się je również kluczowymi wskaźnikami celów (KGI), które pozwalają stwierdzić, czy cele zostały osiągnięte. Ponieważ można je uzyskać dopiero po fakcie, określa się je mianem „wskaźników następujących”.

Mierniki — Szczegółowe opisy tego, w jaki sposób ma być dokonywana okresowa ilościowa ocena wydajności. Kompletny miernik definiuje używaną jednostkę, częstotliwość, pożądaną wartość docelową, procedurę dokonywania pomiaru oraz procedurę interpretacji oceny.

Mierniki stopnia wykonania — miary, które uważa się za czynniki kształtujące wskaźniki następujące. Ponieważ można je uzyskać zanim znany jest wynik procesu, określa się je mianem „wskaźników wyprzedzających”. Zakładana relacja między obydwoma rodzajami wskaźników sugeruje, że poprawa wartości wskaźnika wyprzedzającego będzie mieć wpływ na bardziej korzystne kształtowanie się wskaźnika następującego. Nazywa się je również kluczowymi wskaźnikami wydajności (KPI), które pozwalają określić prawdopodobieństwo osiągnięcia celów.

Model dojrzałości (CMM) — model opracowany przez instytut Software Engineering Institute (SEI), który jest wykorzystywany przez wiele organizacji do identyfikacji dobrych praktyk pomocnych w ocenie i podwyższaniu poziomu dojrzałości procesu rozwoju oprogramowania.

Najlepsza praktyka — sprawdzona czynność lub proces, który jest z powodzeniem wykorzystywany przez wiele organizacji.


ZałącZnik viiNorma (standard) — obowiązkowe wymaganie. Przykładem może być norma ISO/IEC 20000 (międzynarodowy standard) dotycząca wewnętrznego bezpieczeństwa dla konfiguracji UNIX lub określone ustawowo standardy prowadzenia dokumentacji finansowej. Termin „standard” jest również używany jako określenie kodeksu postępowania lub specyfikacji publikowanych przez organizacje normalizacyjne, takie jak ISO czy BSI.

odporność — w działalności biznesowej jest to zdolność systemu lub sieci do automatycznego wznowienia działania po wystąpieniu jakiejkolwiek przerwy, zwykle przy ograniczonych do minimum skutkach.

odpowiedzialny (ang. Responsible) — w schemacie RACI termin odnoszący się do osoby, która musi zapewnić pomyślne wykonanie czynności.

ogólne komputerowe mechanizmy kontrolne — mechanizmy kontrolne (inne niż aplikacyjne mechanizmy kontrolne) dotyczące środowiska, w którym są rozwijane, utrzymywane i eksploatowane komputerowe systemy aplikacji — a więc odnoszące się do wszystkich aplikacji. Celem ogólnych mechanizmów kontrolnych jest zapewnienie prawidłowego rozwoju i wdrożenia aplikacji, integralności oprogramowania i plików danych oraz operacji komputerowych. Podobnie jak aplikacyjne mechanizmy kontrolne, ogólne mechanizmy kontrolne mogą mieć postać wykonywanych przez człowieka lub zaprogramowanych czynności. Przykładem ogólnych mechanizmów kontrolnych jest opracowanie i wdrożenie strategii i polityki bezpieczeństwa systemów informatycznych, zapewnienie organizacji pracy pozwalającej unikać konfliktu obowiązków oraz planowanie zapobiegania i odtwarzania po katastrofie.

ola (ang. operational level agreement) — umowa dotycząca poziomu technicznego usług; wewnętrzna umowa o świadczeniu usług, która stanowi podstawę do świadczenia usług przez dział IT.

organizacja — sposób, w jaki zorganizowana jest struktura przedsiębiorstwa; może również oznaczać sam podmiot (przedsiębiorstwo).

Panel kontrolny — narzędzie umożliwiające określenie oczekiwań wobec organizacji na każdym z poziomów odpowiedzialności i ciągłe monitorowanie realizacji ustalonych celów.

Panel kontrolny inwestycji informatycznych — narzędzie umożliwiające określenie oczekiwań wobec organizacji na każdym z jej poziomów oraz ciągłe monitorowanie realizacji określonych celów nakładów oraz zwrotu z projektów inwestycyjnych opartych o technologie IT w kontekście wartości biznesowych.

Plan infrastruktury technologicznej — plan rozwiązań technologicznych, zasobów ludzkich i infrastruktury, które umożliwiając aktualne i przyszłe przetwarzanie danych i wykorzystywanie aplikacji.

Plan strategiczny IT — długoterminowy plan (o 3-5-letnim horyzoncie czasowym), w którym kierownictwo firmy i działu IT wspólnie określa, w jaki sposób zasoby IT będą wykorzystywane do realizacji strategicznych celów przedsiębiorstwa.

Plan taktyczny IT — średnioterminowy plan (o 6-18-miesięcznym horyzoncie czasowym), który stanowi przełożenie strategicznego planu IT na niezbędne inicjatywy, wymagania dotyczące zasobów oraz wytyczne monitorowania i zarządzania zasobami i korzyściami.

PMBoK (ang. Project Management Body of Knowledge) — metodyka PMBOK; standard zarządzania projektami opracowany przez Project Management Institute (PMI).

PMo (ang. Project Management officer) — specjalista ds. zarządzania projektami; osoba odpowiedzialna za wdrożenie określonej inicjatywy wspierającej zarządzanie projektami i zwiększającej dyscyplinę zarządzania projektami.

Podział obowiązków — podstawowy wewnętrzny mechanizm kontrolny, który umożliwia zapobieganie lub wykrywanie błędów lub nieprawidłowości poprzez przydzielanie jednym osobom odpowiedzialności za inicjowanie i rejestrowanie transakcji, a innym osobom posiadania zasobów (i nadzoru nad czynnościami osób odpowiedzialnych). Powszechnie stosowany w dużych organizacjach IT, aby zapobiec sytuacji, w której jedna osoba mogłaby wprowadzić do systemu w niezauważony sposób fałszywy lub złośliwy kod.

Polityka — dokument opisujący przyjętą ogólną zasadę lub sposób postępowania. Celem polityki jest wpływanie i nadawanie kierunku aktualnym i przyszłym decyzjom, tak aby były one zgodne z filozofią, celami i planami strategicznymi określonymi przez zarządzających przedsiębiorstwem. Polityka powinna również opisywać konsekwencje postępowania niezgodnego z jej założeniami, sposoby postępowania z odstępstwami, a także metody kontroli i pomiaru zgodności z polityką.

Portfel — zbiór programów, projektów, usług lub zasobów wybranych, zarządzanych i monitorowanych w celu optymalizacji zwrotu z prowadzonej działalności.

Praktyka kontrolna — kluczowy mechanizm kontroli, który wspiera osiąganie celów kontrolnych poprzez odpowiedzialne wykorzystanie zasobów, właściwe zarządzanie ryzykiem oraz dostosowanie działalności IT do potrzeb biznesowych.

Prewencyjny mechanizm kontrolny — wewnętrzny mechanizm kontrolny wykorzystywany do zapobiegania niepożądanym zdarzeniom, błędom i innym okolicznościom, które przedsiębiorstwo uznało za mające realny wpływ na przebieg procesu lub końcowy produkt.

PRINCE2 — opracowana przez agencję OGC metodyka zarządzania projektami (Projects in a Controlled Environment), która obejmuje zagadnienia zarządzania, sprawowania kontroli i organizacji projektów.


CobiT 4.1Problem — w dziedzinie IT jest to nieznana przyczyna źródłowa jednego lub więcej incydentów.

Procedura — dokument opasujący kroki realizacji określonej czynności. Zdefiniowane procedury stanowią części składowe procesu.

Proces — zwykle jest zbiór procedur ukierunkowanych przez polityki i procedury organizacji, które wykorzystują elementy wejściowe z różnych źródeł (również z innych procesów), przetwarzają je i dostarczają elementy wyjściowe (również dla innych procesów). Istnienie procesów ma wyraźne uzasadnienie biznesowe i wiąże się z działaniem ich rozliczanych właścicieli, jasno określonymi rolami i zakresami odpowiedzialności za ich realizację oraz sposobami pomiaru ich wydajności.

Proces biznesowy — patrz Proces.

Program — zorganizowany zbiór niezależnych projektów, które obejmują pełen zakres działań biznesowych, procesów, zasobów ludzkich, technologicznych i działań organizacyjnych, które są potrzebne (niezbędne i wystarczające) do uzyskania jasno określonego wyniku biznesowego.

Program aplikacyjny — program służący do przetwarzania danych biznesowych poprzez takie czynności, jak wprowadzanie, aktualizacja czy kwerenda danych. Należy go odróżniać od programów systemowych, takich jak systemy operacyjne czy programy sterowania siecią, oraz od programów użytkowych, służących np. do kopiowania czy sortowania.

Projekt — zorganizowany zbór czynności ukierunkowanych na zapewnienie przedsiębiorstwu określonej zdolności (która jest konieczna, ale niewystarczająca do osiągnięcia wymaganego wyniku biznesowego) w oparciu o uzgodniony harmonogram i budżet.

Przedsiębiorstwo — grupa osób współpracujących na rzecz osiągnięcia wspólnego celu, zwykle w ramach zorganizowanej struktury, takiej jak korporacja, agencja publiczna, organizacja charytatywna czy instytucja powiernicza.

QMS (ang. Quality Management System) — system zarządzania jakością, który określa polityki i procedury niezbędne do udoskonalenia i sprawowania kontroli nad różnymi procesami, zapewniając w efekcie usprawnienie działania organizacji.

Rozliczany (ang. accountable) — w schemacie RACI termin odnoszący się osoby lub grupy, która jest uprawniona do zatwierdzenia lub akceptacji wykonania działania (i jest ostatecznie odpowiedzialna i rozliczana za prawidłowość działań w posiadanym obszarze).

Ryzyko — w działalności biznesowej jest to prawdopodobieństwo, że dane zagrożenie wykorzysta podatności zasobu lub grupy zasobów skutkując ich utratą i/lub uszkodzeniem; zwykle mierzone pod kątem potencjalnego wpływu i prawdopodobieństwa wystąpienia.

Schemat klasyfikacji danych — przyjęty w przedsiębiorstwie schemat klasyfikacji danych według takich kryteriów, jak nieodzowność, wrażliwość i własność.

SDlC (ang. System Development life Cycle) — cykl życia rozwoju systemu obejmujący fazy rozwoju lub nabywania systemu oprogramowania. Typowe fazy projektu uwzględniają studium wykonalności, studium wymagań, definicję wymagań, szczegółowy projekt, programowanie, testowanie, instalację i przegląd powdrożeniowy. Nie obejmują natomiast czynności związanych z dostarczaniem usług czy realizacją korzyści.

Service Desk — w organizacji IT punkt kontaktowy dla użytkowników usług IT.

Sla (ang. Service level agreement) — umowa, najlepiej w formie dokumentu, między dostawcą usług a klientem/użytkownikiem (klientami/użytkownikami), która definiuje minimalną docelową wydajność usługi oraz sposób ich pomiaru.

Słownik danych — baza danych zawierająca informacje dotyczące nazwy, typu, zakresu wartości, źródła i uprawnień dostępu dla każdego z elementów danych znajdujących się w bazie. Słownik danych wskazuje również, które programy aplikacyjne wykorzystują określone dane, tak aby w sytuacji, gdy analizowana jest struktura danych, można było wygenerować listę programów, które z nich korzystają. Słownik danych być odrębnym system informatycznym, wykorzystywanym na potrzeby zarządzania lub dokumentacji, albo sterować działaniem bazy danych.

Struktura — patrz Struktura mechanizmów kontrolnych.

Struktura mechanizmów kontrolnych — zbiór podstawowych mechanizmów kontrolnych, które ułatwiają wykonywanie obowiązków przez właścicieli procesów biznesowych, aby zapobiec stratom finansowym lub utracie informacji przez organizację.

Tabela RaCI — pokazuje, kto jest odpowiedzialny, rozliczany, konsultujący oraz informowany w ramach struktury organizacyjnej.TcO (ang Total Cost of ownership) — całkowity koszt posiadania; w dziedzinie IT obejmuje on:• koszty eksploatacji; • koszty modernizacji sprzętu i aktualizacji oprogramowania; • koszty niektórych czynności wykonywanych przez użytkowników; • koszty pomocy technicznej; • koszty szkolenia;• pierwotny koszt komputerów i oprogramowania.


Uwierzytelnienie — czynność weryfikacji tożsamości jednostki systemowej (np. użytkownika, systemu, węzła sieci) oraz jej uprawnień do uzyskania dostępu do przetworzonych komputerowo informacji. Stworzone z myślą o ochronie przed nieuprawnionym dostępem uwierzytelnianie może również odnosić się do weryfikacji poprawności danych.

Użytkownik IT — osoba, która wykorzystuje technologię IT w celu wsparcia lub realizacji celu biznesowego.

Wewnętrzny mechanizm kontrolny — polityki, plany i procedury oraz struktury organizacyjne stworzone w celu racjonalnego zapewnienia realizacji celów biznesowych oraz zapobiegnięcia lub wykrycia i przeciwdziałania skutkom niepożądanych zdarzeń.

Właściciele danych — osoby (zwykle kierownicy lub dyrektorzy), które są odpowiedzialne za integralność, dokładne raportowanie i wykorzystanie danych komputerowych.

Wydajność — w dziedzinie IT jest to rzeczywisty stopień wdrożenia procesu lub realizacji jego celów.

Wytyczna — opis określonego sposobu wykonania czegoś, który ma mniej normatywny charakter niż procedura.

Zarządzanie konfiguracją — kontrola nad zmianami zbioru elementów konfiguracji przez cały cykl życia systemu.

Zarządzanie sprawnością — w dziedzinie IT jest to zdolność do zarządzania dowolnym rodzajem wielkości, włączając te dotyczące pracowników, zespołów, procesów, działalności operacyjnej czy zagadnień finansowych. Termin dotyczy kontroli w układzie zamkniętym i regularnego monitoringu pomiarów.

Zautomatyzowane aplikacyjne mechanizmy kontrolne — zbiór mechanizmów kontrolnych wbudowanych w zautomatyzowane rozwiązania (aplikacje).

Zdolność (potencjał) — posiadanie niezbędnych atrybutów do działania lub wykonania.

Zrównoważona karta wyników — spójny zbiór mierników wydajności podzielonych na cztery kategorie. Obejmuje on tradycyjne mierniki finansowe, ale także dotyczące perspektyw relacji z klientami, wewnętrznych procesów biznesowych oraz zdobywania wiedzy i rozwoju. Koncepcja ta została opracowana przez Roberta S. Kaplana i Davida P. Nortona w 1992 r.

ZałącZnik vii



CobiT 4.1

z a ł ą c z n i k v i i i

M e T o d y k a c o b i T i P o w i ą z a n e P r o d u k T y

Za

łą

cZ

nik v

iiipr

od

uk

Ty


ZałącZnik viiizałącznik viii — MeTodyka cobiT i Powiązane ProdukTy

Opracowanie CobiT 4.1 obejmuje następujące elementy:• Metodyka — objaśnia, w jaki sposób metodyka CobiT organizuje nadzór informatyczny, zarządzanie i cele kontrolne oraz dobre

praktyki według dziedzin i procesów IT oraz wiąże je z potrzebami firmy.• opisy procesów — dotyczą 34 procesów IT obejmujących cały zakres obszarów odpowiedzialności IT.• Cele kontrolne — ogólne cele najlepszych praktyk zarządzania dla procesów IT.• Wytyczne zarządzania — oferują narzędzia pomocne w określaniu odpowiedzialności, pomiarze wydajności oraz analizie

porównawczej i eliminowaniu braków zdolności.• Modele dojrzałości — przedstawiają profile procesów IT opisujące ich obecne i przyszłe stany.

W ciągu kilkunastu lat od pierwszego wydania metodyki CobiT jej podstawowa zawartość podlegała ewolucji, której towarzyszyło powstanie licznych opracowań uzupełniających, które odnoszą się do metodyki CobiT. Oto zestawienie aktualnych publikacji powiązanych z metodyką CobiT:• Board Briefing on IT Governance, 2nd Edition — pomaga osobom pełniącym funkcje kierownicze zrozumieć, dlaczego ważny

jest ład informatyczny, jakich dotyczy zagadnień i na czym polega ich odpowiedzialność za zarządzanie nim.• CobiT® Online — umożliwia użytkownikom dostosowanie wersji metodyki CobiT do potrzeb własnego przedsiębiorstwa, a

następnie przechowywanie jej i swobodne korzystanie z jej zawartości. Publikacja ta oferuje dostęp online do realizowanych w czasie rzeczywistym badań, odpowiedzi na często zadawane pytania, analiz porównawczych oraz forum dyskusyjnego, które umożliwia wymianę doświadczeń i pytań.

• CobiT® Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition — dostarcza wskazówek dotyczących unikania ryzyka oraz wartości, jakie można uzyskać z wdrożenia celów kontrolnych, a także instruuje, w jaki sposób wdrażać cele kontrolne. Zaleca się korzystanie z tej publikacji w połączeniu z przewodnikiem IT Governance Implementation Guide: Using CobiT® and Val ITTM, 2nd Edition.

• IT Assurance Guide: Using CobiT®— dostarcza wskazówek, w jaki sposób metodyka CobiT może służyć do wspierania różnorodnych działań kontrolnych i omawia zalecane etapy testowania dla wszystkich procesów i celów kontrolnych CobiT. Opracowanie to zastępuje informacje zawarte w publikacji Audit Guidelines, które dotyczą audytu i samooceny w kontekście celów kontrolnych opisanych w metodyce CobiT® 4.1.

• IT Control Objectives for Sarbanes-Oxley: The Role of IT in the Design and Implementation of Internal Control Over Financial Reporting, 2nd Edition — dostarcza wskazówek, w jaki sposób zapewnić zgodność środowiska IT w oparciu o założenia celów kontrolnych CobiT.

• IT Governance Implementation Guide: Using CobiT® and Val ITTM, 2nd Edition — przedstawia ogólny plan działania w celu wdrożenia nadzoru informatycznego z wykorzystaniem metodyki CobiT oraz zasobów i pomocniczego zestawu narzędzi Val IT.

• CobiT® Quickstart, 2nd Edition — prezentuje podstawowe wytyczne kontroli w małych organizacjach, które mogą stanowić punkt wyjściowy dla większych przedsiębiorstw.

• CobiT® Security Baseline, 2nd Edition — omawia najważniejsze etapy wdrożenia systemu bezpieczeństwa informacji w przedsiębiorstwie.

• Opracowania CobiT Mapping — aktualnie dostępne pod adresem www.isaca.org/downloads: – Aligning CobiT®, ITIL and ISO 17799 for Business Benefit – CobiT® Mapping: Mapping of CMMI® for Development V1.2 With CobiT® 4.0 – CobiT® Mapping: Mapping of COSO Enterprise Risk Management With CobiT® 4.1 – CobiT® Mapping: Mapping of ISO/IEC 17799:2000 With CobiT®, 2nd Edition – CobiT® Mapping: Mapping of ISO/IEC 17799:2005 With CobiT® 4.0 – CobiT® Mapping: Mapping of ITIL With CobiT® 4.0 – CobiT® Mapping: Mapping of NIST SP800-53 With CobiT® 4.1 – CobiT® Mapping: Mapping of PMBOK With CobiT® 4.0 – CobiT® Mapping: Mapping of PRINCE2 With CobiT® 4.0 – CobiT® Mapping: Mapping of SEI’s CMM for Software With CobiT® 4.0 – CobiT® Mapping: Mapping of TOGAF 8.1 With CobiT® 4.0 – CobiT® Mapping: Overview of International IT Guidance, 2nd Edition• Information Security Governance: Guidance for Boards of Directors and Executive Management, 2nd — prezentuje zagadnienie

dotyczące bezpieczeństwa informacji w kontekście biznesowym i oferuje narzędzia i techniki pomocne w identyfikacji problemów związanych z bezpieczeństwem.

Val IT to ogólny termin obejmujący publikacje i przyszłe dodatkowe produkty i działania związane z metodyką Val IT.

Aktualnie dostępne publikacje dotyczące metodyki Val IT:• Value Management: Getting Started, How to Begin Creating Value Through IT-Enabled Business Investments, An Executive

Primer Based on the Val IT Framework — przystępnie napisany przewodnik dla zarządzających firmami i działami IT oraz liderów organizacji, pomocny w podjęciu inicjatywy zarządzania wartością.

• Enterprise Value: Governance of IT Investments — metodyka Val ITTM 2.0, która wyjaśnia, w jaki sposób przedsiębiorstwo może uzyskać optymalną wartość z inwestycji opartych o technologie IT, i która jest oparta na metodyce CobiT. Obejmuje ona:

– Trzy procesy: Zarządzanie wartością, Zarządzanie portfelem i Zarządzanie inwestycjami. – Kluczowe praktyki zarządzania IT — najważniejsze praktyki zarządzania, które korzystnie wpływają na osiąganie pożądanych

rezultatów określonych działań. Wspierają one procesy Val IT i pełnią podobną funkcję jak cele kontrolne CobiT.• Enterprise Value: Governance of IT Investments — uzasadnienie biznesowe, które koncentruje się na jednym kluczowym

elemencie procesu zarządzania inwestycjami.• Enterprise Value: Governance of IT Investments — studium przypadku banku ING, które opisuje, w jaki sposób globalna firma

świadcząca usługi finansowe zarządza portfelem inwestycji IT w kontekście metodyki Val IT.

Najbardziej wyczerpujące i aktualne informacje dotyczące metodyki CobiT i Val IT, powiązanych produktów, studiów przypadków, oferty szkoleniowej, biuletynów oraz inne, związane z tą tematyką informacje można znaleźć pod adresem www.isaca.org/cobit oraz www.isaca.org/valit.

Za

łą

cZ

nik v

iiipr

od

uk

Ty



CobiT 4.1

[email protected]

[email protected]

[email protected]

[email protected]

Documents

Metodyka Cele kontrolne W y t y c z n e z a r z ą d z a n i a M