Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		 Previous revision
en:metody_dokument:rizeni_na_urovni_utvaru_ict [2021/06/01 09:17] – created Tomáš Šedivecen:metody_dokument:rizeni_na_urovni_utvaru_ict [2021/07/01 09:43] (current) – Tomáš Šedivec
Line 61: Line 61:
 The ICT unit should also maintain the relevant part of the motivational architecture in all four vertical domains to share with the team and the rest of the office an understanding of its motivation and mission, its performance, its security, and its regulations and constraints. The ICT unit should also maintain the relevant part of the motivational architecture in all four vertical domains to share with the team and the rest of the office an understanding of its motivation and mission, its performance, its security, and its regulations and constraints.
  
-It can be assumed that through the activity of the pilot offices in adopting these Management Methods, validated models of each domain of the ICT capability architecture will emerge and be generalized and published in [[:nap_document|NAP]] and in [[:knowledge_base|Knowledge base]] as reference models and accelerators for the modeling of the OVS.+It can be assumed that through the activity of the pilot offices in adopting these Management Methods, validated models of each domain of the ICT capability architecture will emerge and be generalized and published in [[:nap_document|NAP]] and in [[:en:znalostni_baze|Knowledge base]] as reference models and accelerators for the modeling of the OVS.
  
  
Line 72: Line 72:
 Nevertheless, the full responsibility for planning and managing the acquisition, retention and development of qualified IT capacity remains with the management of the individual public administrations. Nevertheless, the full responsibility for planning and managing the acquisition, retention and development of qualified IT capacity remains with the management of the individual public administrations.
  
-The MoI will issue a Methodology (or concept) for human resources management for this area of ICT management and will publish further information and tools in [[[:znalostni_baze|Knowledge base]].+The MoI will issue a Methodology (or concept) for human resources management for this area of ICT management and will publish further information and tools in [[:en:znalostni_baze|Knowledge base]].
  
 ==== Approach to Human Resource Development Informatization ==== ==== Approach to Human Resource Development Informatization ====
Line 158: Line 158:
 ==== Concept of ICT economic management in public administration ==== ==== Concept of ICT economic management in public administration ====
  
-It will be completed after discussion with the professional community and published in the next issues of MŘICT and in [[[:knowledge_base|Knowledge base]].+It will be completed after discussion with the professional community and published in the next issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ==== Contract and Supplier Management ==== ==== Contract and Supplier Management ====
Line 178: Line 178:
   * Contract management also includes a link to the management of risks associated with contract failure and to the management of budgets to secure contract obligations.   * Contract management also includes a link to the management of risks associated with contract failure and to the management of budgets to secure contract obligations.
  
-More practical recommendations and aids on managing contracts with suppliers will be released in [[[:knowledge_base|Knowledge base]] over time.+More practical recommendations and aids on managing contracts with suppliers will be released in [[:en:znalostni_baze|Knowledge base]] over time.
  
 ==== Comprehensive License Management ==== ==== Comprehensive License Management ====
Line 202: Line 202:
 It is also part of the licence manager's remit to have the necessary knowledge, documentation and tools to successfully handle OSS/FS throughout the IS lifecycle (solution design, tender documentation, contractual provisions, code management, documentation, sharing, etc.). It is also part of the licence manager's remit to have the necessary knowledge, documentation and tools to successfully handle OSS/FS throughout the IS lifecycle (solution design, tender documentation, contractual provisions, code management, documentation, sharing, etc.).
  
-Further factual and technical additions will be included in subsequent editions of the MŘICT and updated in the [[[:knowledge_base|Knowledge base]] after discussion with the expert community. +Further factual and technical additions will be included in subsequent editions of the MŘICT and updated in the [[:en:znalostni_baze|Knowledge base]] after discussion with the expert community. 
  
 ===== Managing ICT proprietary information systems ===== ===== Managing ICT proprietary information systems =====
Line 214: Line 214:
  
 Further factual and technical additions related to the different key types of information systems used by the ICT service for internal management and delivery of its services (CMDB(( Configuration Management DataBase Further factual and technical additions related to the different key types of information systems used by the ICT service for internal management and delivery of its services (CMDB(( Configuration Management DataBase
-)), ServiceDesk, etc.), will be included in the next editions of the MŘICT and updated in the [[[:znalostni_baze|Knowledge base]] after discussion with the expert community. +)), ServiceDesk, etc.), will be included in the next editions of the MŘICT and updated in the [[:en:znalostni_baze|Knowledge base]] after discussion with the expert community. 
  
 ===== Strategic planning and management of ICT OSS ===== ===== Strategic planning and management of ICT OSS =====
Line 250: Line 250:
 Each architectural engagement successfully concludes with the approval of its deliverables by the Authority's Architectural Board and their acceptance by the sponsor. Each architectural engagement successfully concludes with the approval of its deliverables by the Authority's Architectural Board and their acceptance by the sponsor.
  
-The National Architectural Framework (NAR) document provides complete guidelines for the development of an architectural vision and complete individual OVS architecture. Further details and aids, especially on the different types of architectural engagements, are continuously updated in the [[[:knowledge_base|Knowledge base]].+The National Architectural Framework (NAR) document provides complete guidelines for the development of an architectural vision and complete individual OVS architecture. Further details and aids, especially on the different types of architectural engagements, are continuously updated in the [[:en:znalostni_baze|Knowledge base]].
  
 === Roles, processes and disciplines within the Architectural Change Authority ===. === Roles, processes and disciplines within the Architectural Change Authority ===.
Line 281: Line 281:
   * cross-cutting architectures - the overall Enterprise architecture and its vision.   * cross-cutting architectures - the overall Enterprise architecture and its vision.
  
-As such, the field of architecture is a subset of architecture, requiring similar specific qualifications and knowledge from the architects responsible. The role of the lead architect for the discipline is responsible for the design, management and development of the architectures in each discipline. The responsibilities and roles of these roles will be detailed in further annexes of the MŘICT in [[[:knowledge_base|Knowledge base]].+As such, the field of architecture is a subset of architecture, requiring similar specific qualifications and knowledge from the architects responsible. The role of the lead architect for the discipline is responsible for the design, management and development of the architectures in each discipline. The responsibilities and roles of these roles will be detailed in further annexes of the MŘICT in [[:en:znalostni_baze|Knowledge base]].
  
 === Principles, patterns and reference architectures - standards for architectural change === === Principles, patterns and reference architectures - standards for architectural change ===
Line 297: Line 297:
 It is desirable that both (state and own) principles, patterns and reference models are fully applied throughout the life cycle of individual ISVs and reflected in the standardisation and unification of architectures across the authority, including, for example, the promotion of individual standardised platforms in tender documents for the selection of suppliers under the HPAA. It is desirable that both (state and own) principles, patterns and reference models are fully applied throughout the life cycle of individual ISVs and reflected in the standardisation and unification of architectures across the authority, including, for example, the promotion of individual standardised platforms in tender documents for the selection of suppliers under the HPAA.
  
-Further substantive and technical additions, concerning architectural principles, patterns and reference models, will be included in subsequent editions of the NAR and NAP and updated in the [[[:znalostni_baze|Knowledge base]] after consultation with the professional community.+Further substantive and technical additions, concerning architectural principles, patterns and reference models, will be included in subsequent editions of the NAR and NAP and updated in the [[:en:znalostni_baze|Knowledge base]] after consultation with the professional community.
  
 === ICT Service Design by Solution Architecture and Service Management Toolkit ==== === ICT Service Design by Solution Architecture and Service Management Toolkit ====
Line 338: Line 338:
 The methodological and knowledge base of the OSS IK is the individual model of the existing and target architecture of the office. The OVS Information Concept is the official (so-called deliverable) document for the results of the work of the office architecture. The methodological and knowledge base of the OSS IK is the individual model of the existing and target architecture of the office. The OVS Information Concept is the official (so-called deliverable) document for the results of the work of the office architecture.
  
-Further factual and technical additions related to the development of the OVS Information Concept will be included in subsequent editions of the NAR and NAP, issued as OHA methodological guidance and updated in the [[[:knowledge_base|Knowledge base]] after consultation with the professional community.+Further factual and technical additions related to the development of the OVS Information Concept will be included in subsequent editions of the NAR and NAP, issued as OHA methodological guidance and updated in the [[:en:znalostni_baze|Knowledge base]] after consultation with the professional community.
  
 ==== Other methods of strategic ICT management ==== ==== Other methods of strategic ICT management ====
  
-Additional methods for strategic planning and management of the ICT Unit, in addition to the Office Architecture and the IK OVS, will be included in subsequent editions of the MIRCT and updated in the [[[:knowledge_base|Knowledge base]] after consultation with the professional community. +Additional methods for strategic planning and management of the ICT Unit, in addition to the Office Architecture and the IK OVS, will be included in subsequent editions of the MIRCT and updated in the [[:en:znalostni_baze|Knowledge base]] after consultation with the professional community. 
  
 ==== Change Implementation Plan (Roadmap) ==== ==== Change Implementation Plan (Roadmap) ====
Line 354: Line 354:
 Change management is crucial for the proper functioning of ICT services and the ICT unit. Change is a big driver that affects the whole ICT environment and the organisation itself. Managing expectations or requirements is fundamental. In the vast majority, it is the requirements that can be implemented in the form of change. As indicated above, change aligns the ITIL methodology, which manages more the operation and development of existing services, and TOGAF, which focuses on new services, or is even appropriate to use in combination with the ITIL approach for major changes within existing services. Change management is crucial for the proper functioning of ICT services and the ICT unit. Change is a big driver that affects the whole ICT environment and the organisation itself. Managing expectations or requirements is fundamental. In the vast majority, it is the requirements that can be implemented in the form of change. As indicated above, change aligns the ITIL methodology, which manages more the operation and development of existing services, and TOGAF, which focuses on new services, or is even appropriate to use in combination with the ITIL approach for major changes within existing services.
  
-All of the above processes need to be defined consistently, including roles and responsibilities. The good practices and elaborated methods of the approach of combining ITIL and TOGAF will be part of a detailed methodology that will elaborate this topic in more detail including templates and diagrams in [[[:knowledge_base|Knowledge base]]. +All of the above processes need to be defined consistently, including roles and responsibilities. The good practices and elaborated methods of the approach of combining ITIL and TOGAF will be part of a detailed methodology that will elaborate this topic in more detail including templates and diagrams in [[:en:znalostni_baze|Knowledge base]]. 
  
 Furthermore, the RFC and the IT architecture need to be put into context definitively and conceptually. The abbreviation RFC, derived from the English title "Request for change", represents a request for change in the Authority's environment. RFC in the context of architecture management is a request for change impacting one or more architectural domains. Furthermore, the RFC and the IT architecture need to be put into context definitively and conceptually. The abbreviation RFC, derived from the English title "Request for change", represents a request for change in the Authority's environment. RFC in the context of architecture management is a request for change impacting one or more architectural domains.
Line 385: Line 385:
 In order to increase the transparency of the preparation of new services of the OVS and its department and to make the resulting solutions more efficient, it is advisable to use pilot projects when building new services, with the possibility of involving the expert public in the design and testing of solution concepts, thus verifying the need, suitability, functionalities and other aspects of the proposed solutions. This procedure provides users with the opportunity to test services and functionalities already at the time of their design, and at the same time the opportunity to comment on the form of the design, or to send suggestions for changes, extensions, or optimization of the proposed services. In this way, it can be ensured that the services are designed with the expectations of the clients - citizens in mind, and any possible inconsistencies, contradictions or additional requirements/expectations of the VS clients are captured at the outset and incorporated into the solution concept of the newly developed service. Another indisputable benefit of the implementation of verification projects is the specification of the requirements for the target solution and expected functionalities. In the context of possible public procurement for the delivery of whole or parts of services, a precise set of clearly defined functionalities can already be requested. This minimises the risk of inefficiently requesting functionality that will not be used in the future and the risk of a large number of change requests for optimisation or customisation of the services used. In order to increase the transparency of the preparation of new services of the OVS and its department and to make the resulting solutions more efficient, it is advisable to use pilot projects when building new services, with the possibility of involving the expert public in the design and testing of solution concepts, thus verifying the need, suitability, functionalities and other aspects of the proposed solutions. This procedure provides users with the opportunity to test services and functionalities already at the time of their design, and at the same time the opportunity to comment on the form of the design, or to send suggestions for changes, extensions, or optimization of the proposed services. In this way, it can be ensured that the services are designed with the expectations of the clients - citizens in mind, and any possible inconsistencies, contradictions or additional requirements/expectations of the VS clients are captured at the outset and incorporated into the solution concept of the newly developed service. Another indisputable benefit of the implementation of verification projects is the specification of the requirements for the target solution and expected functionalities. In the context of possible public procurement for the delivery of whole or parts of services, a precise set of clearly defined functionalities can already be requested. This minimises the risk of inefficiently requesting functionality that will not be used in the future and the risk of a large number of change requests for optimisation or customisation of the services used.
  
-More detailed information, guides, procedures and tools will be issued as a separate methodological document and as a continuously updated part of the [[[:knowledge_base|Knowledge base]] after consultation with the expert community.+More detailed information, guides, procedures and tools will be issued as a separate methodological document and as a continuously updated part of the [[:en:znalostni_baze|Knowledge base]] after consultation with the expert community.
  
 ==== Project and Programme Management Office ==== ==== Project and Programme Management Office ====
Line 405: Line 405:
 At a second, lower level, already exclusively for ICT projects, this coordination and management takes place in the project management, strategy and IT architecture units within the ICT unit of the Authority. At a second, lower level, already exclusively for ICT projects, this coordination and management takes place in the project management, strategy and IT architecture units within the ICT unit of the Authority.
  
-Further factual and technical additions on the whole issue of project and programme management will be included in the next editions of the MŘICT and updated in the [[[:knowledge_base|Knowledge base]] after consultation with the professional community.+Further factual and technical additions on the whole issue of project and programme management will be included in the next editions of the MŘICT and updated in the [[:en:znalostni_baze|Knowledge base]] after consultation with the professional community.
  
 === Categorisation of programmes and projects === === Categorisation of programmes and projects ===
Line 467: Line 467:
 In a situation where planned changes in the Authority and its ICT lead to more programmes and projects than the Authority's available financial, human and material resources, a process of 'project prioritisation' must be demonstrably applied. This should be done at least once a year, in the context of budget planning, or whenever concurrently running or planned projects hit the limits of the Authority's resources. The prioritisation process consists of allocating the available resources and allocating them only to projects that make the greatest contribution to the Authority's objectives or that are required by legislative changes. Projects that, due to their currently lower priority, do not reach the Authority's resources will not be started or will be stopped until their priorities are raised or the Authority's available project resources are increased. The process described above is the responsibility of the Authority's Project Office. The Project Office must be informed of all projects from the time pre-project preparation begins. In a situation where planned changes in the Authority and its ICT lead to more programmes and projects than the Authority's available financial, human and material resources, a process of 'project prioritisation' must be demonstrably applied. This should be done at least once a year, in the context of budget planning, or whenever concurrently running or planned projects hit the limits of the Authority's resources. The prioritisation process consists of allocating the available resources and allocating them only to projects that make the greatest contribution to the Authority's objectives or that are required by legislative changes. Projects that, due to their currently lower priority, do not reach the Authority's resources will not be started or will be stopped until their priorities are raised or the Authority's available project resources are increased. The process described above is the responsibility of the Authority's Project Office. The Project Office must be informed of all projects from the time pre-project preparation begins.
  
-More information and rules on the management of IT project portfolios, including links to human resources management, will be issued by the MoI in the form of an update to the Methodology for the Management of IT Projects and Diverse Accelerators in [[[:knowledge_base|Knowledge base]].+More information and rules on the management of IT project portfolios, including links to human resources management, will be issued by the MoI in the form of an update to the Methodology for the Management of IT Projects and Diverse Accelerators in [[:en:znalostni_baze|Knowledge base]].
  
 === Management of individual IT projects === === Management of individual IT projects ===
Line 477: Line 477:
 In many cases this is done, but it is not recommended that the implementation of small or small changes is managed by the Change Manager. In the case of small changes, so-called coordination is preferable, where the execution is carried out by the Change Coordinator. In the case of simple coordination, a given change management role does not have as many formal documentation and management responsibilities as the Project Manager role, and in most cases coordinates multiple changes and reports more succinctly at the Operations Management level of operations in some cases this tends to be the Project Development level. In many cases this is done, but it is not recommended that the implementation of small or small changes is managed by the Change Manager. In the case of small changes, so-called coordination is preferable, where the execution is carried out by the Change Coordinator. In the case of simple coordination, a given change management role does not have as many formal documentation and management responsibilities as the Project Manager role, and in most cases coordinates multiple changes and reports more succinctly at the Operations Management level of operations in some cases this tends to be the Project Development level.
  
-Change management will be added after discussion with the technical community and published in future issues of MŘICT and in [[[:knowledge_base|Knowledge base]].+Change management will be added after discussion with the technical community and published in future issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ===== IS Operations Management and Service Delivery ===== ===== IS Operations Management and Service Delivery =====
Line 483: Line 483:
 ==== Managing support for clients and users of ICT services ==== ==== Managing support for clients and users of ICT services ====
  
-The management of support to clients and users of ICT services will be completed after consultation with the professional community and published in future issues of the MŘICT and in [[[:knowledge base|Knowledge base]].+The management of support to clients and users of ICT services will be completed after consultation with the professional community and published in future issues of the MŘICT and in [[:en:en:znalostni_baze|Knowledge base]].
  
 ==== ICT Operations Management ==== ==== ICT Operations Management ====
Line 491: Line 491:
 In the environment of OVS and its department, an approach to the definition of contractual parameters of services in so-called service data sheets should be gradually introduced. The basic idea of the approach is that services are provided through one or more interfaces and each interface is classified in terms of importance according to the categories "Gold", "Silver" and "Bronze". Shared catalogue sheets can then be created for each service category and application-specific services can be addressed within concise, dedicated catalogue sheets if required. This approach can be applied in the preparation of any contract with the character of delivery of operation and support services. In the environment of OVS and its department, an approach to the definition of contractual parameters of services in so-called service data sheets should be gradually introduced. The basic idea of the approach is that services are provided through one or more interfaces and each interface is classified in terms of importance according to the categories "Gold", "Silver" and "Bronze". Shared catalogue sheets can then be created for each service category and application-specific services can be addressed within concise, dedicated catalogue sheets if required. This approach can be applied in the preparation of any contract with the character of delivery of operation and support services.
  
-The management of ICT operations at the level of the whole Authority will be completed after consultation with the technical community and published in future editions of the MŘICT and in the [[[:knowledge_base|Knowledge base]].+The management of ICT operations at the level of the whole Authority will be completed after consultation with the technical community and published in future editions of the MŘICT and in the [[:en:znalostni_baze|Knowledge base]].
  
 ==== Monitoring ICT Operations and Services ==== ==== Monitoring ICT Operations and Services ====
Line 497: Line 497:
 Each system, application or service must be designed and implemented in such a way that it can be integrated into the monitoring system of the OVS and the departmental organisation. The monitoring system must cover the metrics that are identified as automatically monitored in the Service Level Agreements (SLAs) and monitor these metrics in accordance with the procedures and parameters defined in the SLAs. In addition to the metrics so marked, the monitoring must monitor and evaluate other metrics common to the type of system or application. Each system, application or service must be designed and implemented in such a way that it can be integrated into the monitoring system of the OVS and the departmental organisation. The monitoring system must cover the metrics that are identified as automatically monitored in the Service Level Agreements (SLAs) and monitor these metrics in accordance with the procedures and parameters defined in the SLAs. In addition to the metrics so marked, the monitoring must monitor and evaluate other metrics common to the type of system or application.
  
-Detailed methodologies and technical proposal regarding monitoring tools will be completed after discussion with the expert community and published in future issues of the MŘICT and in the [[[:knowledge_base|Knowledge base]].+Detailed methodologies and technical proposal regarding monitoring tools will be completed after discussion with the expert community and published in future issues of the MŘICT and in the [[:en:znalostni_baze|Knowledge base]].
  
 ===== Risk and Security Management in the ICT Unit ===== ===== Risk and Security Management in the ICT Unit =====
Line 538: Line 538:
   * {{:documents:methodology_for_impact_assessment_nukib_v.1.2_s_prilohou.pdf|Guidelines for impact assessment}}   * {{:documents:methodology_for_impact_assessment_nukib_v.1.2_s_prilohou.pdf|Guidelines for impact assessment}}
  
-Risk map type annexes including the legend, supporting questions and impact measurements, and other factual and technical additions will be published in future editions of the MRICT and in the [[[:knowledge_base|Knowledge base]] after discussion with the expert community.+Risk map type annexes including the legend, supporting questions and impact measurements, and other factual and technical additions will be published in future editions of the MRICT and in the [[:en:znalostni_baze|Knowledge base]] after discussion with the expert community.
  
 ==== ICT Security Management ==== ==== ICT Security Management ====
Line 568: Line 568:
 ==== Managing the overall service portfolio ==== ==== Managing the overall service portfolio ====
  
-To be added after discussion with the expert community and published in future editions of MŘICT and in [[[:knowledge_base|Knowledge base]].+To be added after discussion with the expert community and published in future editions of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ==== Application Portfolio Management ==== ==== Application Portfolio Management ====
  
-To be added after consultation with the expert community and published in future issues of MŘICT and in [[[:znalostni_baze|Knowledge base]].+To be added after consultation with the expert community and published in future issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ==== Technology Portfolio Management ==== ==== Technology Portfolio Management ====
  
-To be completed after consultation with the expert community and published in future issues of MŘICT and in [[[:znalostni_baze|Knowledge base]].+To be completed after consultation with the expert community and published in future issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ==== Management of OVS Data Collections ==== ==== Management of OVS Data Collections ====
  
-To be completed after discussion with the expert community and published in future issues of MŘICT and in [[[:znalostni_baze|Knowledge base]].+To be completed after discussion with the expert community and published in future issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ==== A different approach to the acquisition and management of ICT commodities ==== ==== A different approach to the acquisition and management of ICT commodities ====
  
-To be completed after consultation with the expert community and published in future editions of MŘICT and in [[[:znalostni_baze|Knowledge base]].+To be completed after consultation with the expert community and published in future editions of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ===== Approach to indirect management and oversight of informatization (governance) ===== ===== Approach to indirect management and oversight of informatization (governance) =====
  
-To be completed after consultation with the expert community and published in future editions of MŘICT and in [[[:knowledge_base|Knowledge base]].+To be completed after consultation with the expert community and published in future editions of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ==== Introduction of service quality management ==== ==== Introduction of service quality management ====
  
-To be completed after consultation with the expert community and published in future issues of MŘICT and in [[[:znalostni_baze|Knowledge base]].+To be completed after consultation with the expert community and published in future issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ==== Reporting for ICT management and governance ==== ==== Reporting for ICT management and governance ====
  
-To be added after discussion with the expert community and published in future issues of MŘICT and in [[[:knowledge_base|Knowledge base]].+To be added after discussion with the expert community and published in future issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ==== ICT Controlling and Benchmarking ==== ==== ICT Controlling and Benchmarking ====
Line 612: Line 612:
   -Development of **controlling** public administration ICT services.   -Development of **controlling** public administration ICT services.
  
-Further information on ICT controlling and benchmarking will be discussed with the professional community and published in future issues of MŘICT and in [[[:znalostni_baze|Knowledge base]].+Further information on ICT controlling and benchmarking will be discussed with the professional community and published in future issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].
  
 ===== Standardisation in ICT management ===== ===== Standardisation in ICT management =====
  
-A comprehensive and challenging chapter on standardisation in ICT will be added after discussion with the professional community and published in future issues of MŘICT and in [[[:znalostni_baze|Knowledge base]].+A comprehensive and challenging chapter on standardisation in ICT will be added after discussion with the professional community and published in future issues of MŘICT and in [[:en:znalostni_baze|Knowledge base]].