Differences
This shows you the differences between two versions of the page.
en:metody_dokument:rizeni_jednotlivych_ict_reseni [2021/06/01 09:10] – created Tomáš Šedivec | en:metody_dokument:rizeni_jednotlivych_ict_reseni [2021/07/01 09:39] (current) – revision Tomáš Šedivec | ||
---|---|---|---|
Line 5: | Line 5: | ||
Act No. 365/2000 Coll. assumes that the Information Concept of the Czech Republic will also address the issue of management of public administration information systems. It is appropriate to use the recommendations of the MŘICT unchanged and thus to apply them in the full scope of the ICT portfolio (IT architecture) of the OVS. However, as with any other methodology, | Act No. 365/2000 Coll. assumes that the Information Concept of the Czech Republic will also address the issue of management of public administration information systems. It is appropriate to use the recommendations of the MŘICT unchanged and thus to apply them in the full scope of the ICT portfolio (IT architecture) of the OVS. However, as with any other methodology, | ||
- | The management of each IS can be described and guidance and accelerators for it can be provided in the [[[:knowledge_base|Knowledge base]] either focusing on the detail of the phases and activities in the IS life cycle stage or focusing on typical activities and methods that, although usually occurring in certain phases, may also be repetitive and overlapping (e.g. supplier selection, project management, mitigating supplier dependency, etc.). | + | The management of each IS can be described and guidance and accelerators for it can be provided in the [[:en: |
- | This chapter introduces and combines both perspectives. Detailed information and accelerators, | + | This chapter introduces and combines both perspectives. Detailed information and accelerators, |
- | All activities in the management of individual IS must be carried out in the context of the whole Authority and eGovernment of the Czech Republic and the EU, within the framework of the activities and procedures described further in [[methods_document: | + | All activities in the management of individual IS must be carried out in the context of the whole Authority and eGovernment of the Czech Republic and the EU, within the framework of the activities and procedures described further in [[metody_dokument: |
===== Management of information systems by stages and phases of their life cycle ===== | ===== Management of information systems by stages and phases of their life cycle ===== | ||
Line 50: | Line 50: | ||
The decomposition of these individual life stages into the structure: " | The decomposition of these individual life stages into the structure: " | ||
- | )), is elaborated in the table " | + | )), is elaborated in the table " |
The scenario of the life cycle activities of the ICT service of the Ministry of the Interior (also referred to as " | The scenario of the life cycle activities of the ICT service of the Ministry of the Interior (also referred to as " | ||
Line 68: | Line 68: | ||
- Process and management methods - the sequence of sub-phases, steps and deliverables of the phase, if prescribed. Along with this, the rules for joint or otherwise interrelated management within a phase, project and linear. | - Process and management methods - the sequence of sub-phases, steps and deliverables of the phase, if prescribed. Along with this, the rules for joint or otherwise interrelated management within a phase, project and linear. | ||
- | In this introductory edition of the MIRCT, for clarity and readability, | + | In this introductory edition of the MIRCT, for clarity and readability, |
The different parts of each phase of an IS lifecycle also have different forms of governance - linear and programmatic/ | The different parts of each phase of an IS lifecycle also have different forms of governance - linear and programmatic/ | ||
Line 93: | Line 93: | ||
Relationship between IS life cycle phases and phases of a typical implementation project. | Relationship between IS life cycle phases and phases of a typical implementation project. | ||
- | Additional deliverables and milestones of the implementation project phases are described in the detailed | + | Additional deliverables and milestones of the implementation project phases are described in the detailed [[:en: |
**Overlapping life cycle stages.** The life cycle stages of an IS may overlap with each other with a phase shift. Thus, at the same time, some IS services are routinely operated, some services from earlier stages are already being phased out and disposed of, and new services from the next stage of system development are being planned or implemented. | **Overlapping life cycle stages.** The life cycle stages of an IS may overlap with each other with a phase shift. Thus, at the same time, some IS services are routinely operated, some services from earlier stages are already being phased out and disposed of, and new services from the next stage of system development are being planned or implemented. | ||
Line 126: | Line 126: | ||
While **Stage 1 - Strategy** is an integral part of each life stage of an individual IS, it is fully applicable and dominated by the methods and means of strategic management and planning of ICT at the level of the whole department and office, in the context of eGovernment of the Czech Republic and the EU, see [[metody_dokument: | While **Stage 1 - Strategy** is an integral part of each life stage of an individual IS, it is fully applicable and dominated by the methods and means of strategic management and planning of ICT at the level of the whole department and office, in the context of eGovernment of the Czech Republic and the EU, see [[metody_dokument: | ||
- | To facilitate and support the processes of the strategy management phase, the [[[:knowledge_base|Knowledge base]] NA VS ČR will be gradually added to the following: | + | To facilitate and support the processes of the strategy management phase, the [[:en: |
- Principles, procedures and examples to support the development of so-called digitally friendly legislation. | - Principles, procedures and examples to support the development of so-called digitally friendly legislation. | ||
Line 212: | Line 212: | ||
* Creating the enablers to evaluate measurable parameters of projects, solutions and suppliers in Phase 6. | * Creating the enablers to evaluate measurable parameters of projects, solutions and suppliers in Phase 6. | ||
- | Optimizing this confluence of planning streams, ensuring those assumptions and facilitating all activities will be the subject of documents and tools that will be part of the next edition of the MRICT and [[[:knowledge_base|Knowledge base]]. | + | Optimizing this confluence of planning streams, ensuring those assumptions and facilitating all activities will be the subject of documents and tools that will be part of the next edition of the MRICT and [[:en: |
=== Planning principles and rules === | === Planning principles and rules === | ||
Line 258: | Line 258: | ||
* joint management of large (e.g. project) and small (e.g. line, interim) changes - with shared processes, tools and resources. | * joint management of large (e.g. project) and small (e.g. line, interim) changes - with shared processes, tools and resources. | ||
- | In particular, to facilitate and support the processes of the implementation management phase, the following will be progressively added to the [[[:knowledge_base|Knowledge base]]: | + | In particular, to facilitate and support the processes of the implementation management phase, the following will be progressively added to the [[:en: |
- Recommended practices and methodologies for creating and recording analytical models at the solution architecture (SA) and solution design (SD) level | - Recommended practices and methodologies for creating and recording analytical models at the solution architecture (SA) and solution design (SD) level | ||
Line 273: | Line 273: | ||
* Acceptance of the solution is always done by the client (contracting authority, subject matter manager) in cooperation with other stakeholders (integrated OVS, SZR, ...). | * Acceptance of the solution is always done by the client (contracting authority, subject matter manager) in cooperation with other stakeholders (integrated OVS, SZR, ...). | ||
* The structure of the project steps, deliverables and methods must correspond to the chosen type of solution to be implemented (off-the-shelf software, custom development, | * The structure of the project steps, deliverables and methods must correspond to the chosen type of solution to be implemented (off-the-shelf software, custom development, | ||
- | * Projects with higher user adaptation requirements must include adaptation activities according to the OCM methodology, | + | * Projects with higher user adaptation requirements must include adaptation activities according to the OCM methodology, |
* The activities of the implementation phase of an IS must always be carried out in accordance with the implementation management methods at the level of the whole unit/office and using common methods and tools. | * The activities of the implementation phase of an IS must always be carried out in accordance with the implementation management methods at the level of the whole unit/office and using common methods and tools. | ||
* In the case of a large project being implemented by a contractor with a global best practice project and development management methodology, | * In the case of a large project being implemented by a contractor with a global best practice project and development management methodology, | ||
Line 297: | Line 297: | ||
- | A number of sub-activities, | + | A number of sub-activities, |
An important project activity at the beginning of implementation is the establishment of project structures and the mobilisation of its internal human and material resources. | An important project activity at the beginning of implementation is the establishment of project structures and the mobilisation of its internal human and material resources. | ||
Line 321: | Line 321: | ||
The provision of user and technical support is crucial to support both aspects of operations (continuous service delivery and identification and implementation of changes). | The provision of user and technical support is crucial to support both aspects of operations (continuous service delivery and identification and implementation of changes). | ||
- | For more information on the key methods used in managing operations at the level of each IS, see [[methods_document: | + | For more information on the key methods used in managing operations at the level of each IS, see [[metody_dokument: |
In addition to activities to ensure the operation of individual information system services, it is necessary to build and use operations management capabilities centrally, across ISs, whether it is for example: | In addition to activities to ensure the operation of individual information system services, it is necessary to build and use operations management capabilities centrally, across ISs, whether it is for example: | ||
Line 332: | Line 332: | ||
* overall planning and resource management for operations | * overall planning and resource management for operations | ||
- | For more information, | + | For more information, |
- | In particular, the following accelerators will be gradually added to the [[:knowledge_base|Knowledge base]] to facilitate and support the processes of the operations management phase: | + | In particular, the following accelerators will be gradually added to the [[:en: |
- General suggestions for availability and response monitoring | - General suggestions for availability and response monitoring | ||
Line 561: | Line 561: | ||
The basic rule and recommendation of the ISTC for the ICT units of the OVS is to move to managing the relationship between providers and customers of information systems support functions through services, if they have not already done so | The basic rule and recommendation of the ISTC for the ICT units of the OVS is to move to managing the relationship between providers and customers of information systems support functions through services, if they have not already done so | ||
- | The next edition of the MDICT document and the ongoing additions to the [[:knowledge_base|Knowledge base]] will develop information, | + | The next edition of the MDICT document and the ongoing additions to the [[:en: |
* management of the Service Catalogue by department and individual organisation, | * management of the Service Catalogue by department and individual organisation, | ||
Line 574: | Line 574: | ||
Recommendations and practical guidance tools for planning requirements for the additional resources necessary for IS development, | Recommendations and practical guidance tools for planning requirements for the additional resources necessary for IS development, | ||
- | It is essential that the management of the development of a single IS must always and fully use the methods and tools for the management of the development of IT assets of the whole authority, i.e. portfolios of assets layer by layer, e.g. development plans for key platforms, see more in [[methods_document: | + | It is essential that the management of the development of a single IS must always and fully use the methods and tools for the management of the development of IT assets of the whole authority, i.e. portfolios of assets layer by layer, e.g. development plans for key platforms, see more in [[metody_dokument: |
==== ISVS decommissioning and migration rules ==== | ==== ISVS decommissioning and migration rules ==== | ||
Line 660: | Line 660: | ||
* Subject matter administrators shall store information about their ISVs in the IS about ISVs (i.e. in the catalogue of currently operated ISVs) in the required structure, including any requirement to use [[nap: | * Subject matter administrators shall store information about their ISVs in the IS about ISVs (i.e. in the catalogue of currently operated ISVs) in the required structure, including any requirement to use [[nap: | ||
- | Criteria for the use of [[nap: | + | Criteria for the use of [[nap: |
==== Rules for better purchasing of ICT solutions ==== | ==== Rules for better purchasing of ICT solutions ==== | ||
Line 720: | Line 720: | ||
* Maintaining documentation of IS and ICT services in models that comply with TOGAF and ArchiMate standards. | * Maintaining documentation of IS and ICT services in models that comply with TOGAF and ArchiMate standards. | ||
- | Further factual and technical additions will be included in future editions and in the [[[: | + | Further factual and technical additions will be included in future editions and in the [[: |
== Achieving long-term balanced partnerships with suppliers (avoiding Vendor-Lock-In) == | == Achieving long-term balanced partnerships with suppliers (avoiding Vendor-Lock-In) == | ||
- | The ISTC and the [[:Knowledge Base|Knowledge Base]] will help to establish and maintain a long-term balanced partnership between ICT services and their suppliers by publishing a series of guides and tools, such as model contracts and tender documents or standards and how-to guides. Consideration will also be given to a model whereby the sub-contracts of individual PSCs will refer to the general terms and conditions of the public administration, | + | The ISTC and the [[:en: |
Each PSC would still have a choice or modification, | Each PSC would still have a choice or modification, | ||
Line 736: | Line 736: | ||
Therefore, purchasing OSS is definitely risky if we do not consider all the implications. In any case, using OSS does not give us management and administration for free. The long-term sustainability of OSS is not dependent on a short-term solution. The primary view must be the life of the information unit over its 5+ year lifetime, with a clear strategy for how to continue to operate it beyond the baseline 5 years (relevant to TCO). | Therefore, purchasing OSS is definitely risky if we do not consider all the implications. In any case, using OSS does not give us management and administration for free. The long-term sustainability of OSS is not dependent on a short-term solution. The primary view must be the life of the information unit over its 5+ year lifetime, with a clear strategy for how to continue to operate it beyond the baseline 5 years (relevant to TCO). | ||
- | A separate methodology will be developed for the use and suitability of integration of each OSS product. It will focus not only on the integration of OSS elements into information units, but also on the possibility of sharing successful products such as a filing cabinet or anonymiser. More information on this topic will be published in [[[: | + | A separate methodology will be developed for the use and suitability of integration of each OSS product. It will focus not only on the integration of OSS elements into information units, but also on the possibility of sharing successful products such as a filing cabinet or anonymiser. More information on this topic will be published in [[: |
=== Rules for valuation of IS development or modification === | === Rules for valuation of IS development or modification === | ||
Line 750: | Line 750: | ||
An important step is to unify the types of contracts according to content, length, scope, etc., i.e. to bring uniformity and order to the contractual system in the management of ICT relations with suppliers. Furthermore, | An important step is to unify the types of contracts according to content, length, scope, etc., i.e. to bring uniformity and order to the contractual system in the management of ICT relations with suppliers. Furthermore, | ||
- | One of the objectives of the next edition of the MRICT and the continuous updating of the [[[:knowledge_base|Knowledge base]] is to provide additional information, | + | One of the objectives of the next edition of the MRICT and the continuous updating of the [[:en: |
==== Concepts for managing the successful implementation of proposed ICT change projects ==== | ==== Concepts for managing the successful implementation of proposed ICT change projects ==== | ||
Line 760: | Line 760: | ||
Informatics in the Authority serves its internal clients, informatics projects are intended to contribute to the achievement of Authority-wide goals, and public service change projects increasingly rely on informatics support. In addition, all projects in the Authority share a limited amount of project-appropriate human resources. Therefore, all individual ISMS projects need to be coordinated with each other within the ICT Unit, then more broadly across all projects across the Authority and, in the future, the eGovernment of the country. | Informatics in the Authority serves its internal clients, informatics projects are intended to contribute to the achievement of Authority-wide goals, and public service change projects increasingly rely on informatics support. In addition, all projects in the Authority share a limited amount of project-appropriate human resources. Therefore, all individual ISMS projects need to be coordinated with each other within the ICT Unit, then more broadly across all projects across the Authority and, in the future, the eGovernment of the country. | ||
- | The coordination of projects, their linking to programmes and the management of project portfolios is a service of the Project Office of the Authority (also referred to as " | + | The coordination of projects, their linking to programmes and the management of project portfolios is a service of the Project Office of the Authority (also referred to as " |
== ISMS development programme management == | == ISMS development programme management == | ||
Line 766: | Line 766: | ||
All projects that are related to each other in time, subject matter or otherwise, must be managed as a programme to ensure that together they deliver greater value and with greater certainty than if they were managed separately. | All projects that are related to each other in time, subject matter or otherwise, must be managed as a programme to ensure that together they deliver greater value and with greater certainty than if they were managed separately. | ||
- | Whereas project management is primarily focused on achieving planned outputs while maintaining consumption of planned resources, programme management is primarily focused on meeting strategic objectives and achieving expected benefits. From this perspective, | + | Whereas project management is primarily focused on achieving planned outputs while maintaining consumption of planned resources, programme management is primarily focused on meeting strategic objectives and achieving expected benefits. From this perspective, |
== ISVS project management as part of a portfolio == | == ISVS project management as part of a portfolio == | ||
Line 776: | Line 776: | ||
For each individual ISMS project, it follows that it must be clearly assigned to one director or manager and thus become part of his/her portfolio, his/her responsibility and his/her reporting to the SC and the management of the office. | For each individual ISMS project, it follows that it must be clearly assigned to one director or manager and thus become part of his/her portfolio, his/her responsibility and his/her reporting to the SC and the management of the office. | ||
- | For more information on project portfolio management techniques, see [[methods_document: | + | For more information on project portfolio management techniques, see [[metody_dokument: |
=== Rules for managing individual ISVS implementation projects ===. | === Rules for managing individual ISVS implementation projects ===. | ||
Line 819: | Line 819: | ||
* and others | * and others | ||
- | In the [[[:knowledge_base|Knowledge base]] a table of expected job and service roles for each project role will be prepared. | + | In the [[:en: |
Appointments must be made in writing, via a letter of appointment signed by the appointee and the supervisor/ | Appointments must be made in writing, via a letter of appointment signed by the appointee and the supervisor/ | ||
Line 845: | Line 845: | ||
Project management must include an ongoing and final evaluation of the results and benefits achieved, and a guided learning of lessons learned. | Project management must include an ongoing and final evaluation of the results and benefits achieved, and a guided learning of lessons learned. | ||
- | More information and rules on the management of ICT projects and their portfolios, including links to human resources management, will be issued by the Ministry of the Interior of the Czech Republic in the form of an update of the Methodology for IT Project Management, which will also be published as part of the [[[: | + | More information and rules on the management of ICT projects and their portfolios, including links to human resources management, will be issued by the Ministry of the Interior of the Czech Republic in the form of an update of the Methodology for IT Project Management, which will also be published as part of the [[: |
== Risk and security management in implementation projects == | == Risk and security management in implementation projects == | ||
Line 851: | Line 851: | ||
An important and non-negotiable part of project management is, besides managing the scope, time and resources of the project (budget, people and technology/ | An important and non-negotiable part of project management is, besides managing the scope, time and resources of the project (budget, people and technology/ | ||
- | Project risk and security management includes the management of cyber risks and security in accordance with their management methods and using tools at the level of the entire ICT unit and office, [[methods_document: | + | Project risk and security management includes the management of cyber risks and security in accordance with their management methods and using tools at the level of the entire ICT unit and office, [[metody_dokument: |
Other principles such as " | Other principles such as " | ||
Line 857: | Line 857: | ||
=== Approval of projects by the HA Department of the Ministry of Interior ==== | === Approval of projects by the HA Department of the Ministry of Interior ==== | ||
- | The process is managed in accordance with the OHA's continuously issued Methodological Guidelines and their corresponding forms, see the OHA website, which together with other guidance and tools will be continuously updated in the [[[:knowledge_base|Knowledge base.]] | + | The process is managed in accordance with the OHA's continuously issued Methodological Guidelines and their corresponding forms, see the OHA website, which together with other guidance and tools will be continuously updated in the [[:en: |
=== Principles for documenting the actual implementation of an IT solution ===. | === Principles for documenting the actual implementation of an IT solution ===. | ||
Line 867: | Line 867: | ||
Optimally, this activity should be included as an integral part of the acceptance processes and the responsibility for it should be assigned to the organisationally competent Technical Administrator. | Optimally, this activity should be included as an integral part of the acceptance processes and the responsibility for it should be assigned to the organisationally competent Technical Administrator. | ||
- | Standards, templates and typical examples of such documentation will be progressively updated in the [[[:knowledge_base|Knowledge base]]. | + | Standards, templates and typical examples of such documentation will be progressively updated in the [[:en: |
== Documentation of program modifications == | == Documentation of program modifications == | ||
Line 885: | Line 885: | ||
Proper acceptance of the deliverables is also directly related to the so-called Ex-ante approach to planning and change management (see [[method_document: | Proper acceptance of the deliverables is also directly related to the so-called Ex-ante approach to planning and change management (see [[method_document: | ||
- | It is the intention of the MŘICT to follow the types of contracts concluded ([[metody_dokument: | + | It is the intention of the MŘICT to follow the types of contracts concluded ([[metody_dokument: |
===== Rules for effective management of operations and service delivery, service procurement and continuous improvement ===== | ===== Rules for effective management of operations and service delivery, service procurement and continuous improvement ===== | ||
Line 913: | Line 913: | ||
If you use an information system, centralise all requests in one place and have a team responsible for dealing with them, then the subsequent classification of these requests will quite naturally speed up their settlement. | If you use an information system, centralise all requests in one place and have a team responsible for dealing with them, then the subsequent classification of these requests will quite naturally speed up their settlement. | ||
- | Other methods of ISVS client care will be included in future editions of the MIRCT and updated in the [[[:knowledge_base|Knowledge base]] after discussion with the professional community. | + | Other methods of ISVS client care will be included in future editions of the MIRCT and updated in the [[:en: |
===== ISVS Indirect Governance Rules ===== | ===== ISVS Indirect Governance Rules ===== | ||
- | ISVS indirect governance methods will be included in the next editions of the DGICT and updated in the [[[:knowledge base|Knowledge base]] after consultation with the expert community.] | + | ISVS indirect governance methods will be included in the next editions of the DGICT and updated in the [[:en: |