Background and objectives
Financial institutions must understand the business activities carried on by them and identify, monitor and control the risks associated therewith. This also applies for changes resulting from the business and risk strategies. The “minimum requirements for risk management” (MaRisk) provide a corresponding adaptation process for this purpose according to AT 8.2 “Changes to operational processes or structures” in order to reasonably control the risks due to the lack of knowledge of the impacts of changes in the organisational structures.
In order to fulfil the minimum regulatory requirements, reporting duties and framework conditions, the financial institutions must implement corresponding regulations and processes in the form of organisational guidelines.
In the case of planned “changes to operational processes or structures”, an impact analysis of the planned changes must already be carried out prior to the implementation of essential changes in the structure and process organisation and in the IT systems. In this case, it concerns continuing to ensure the impacts of the planned changes on the control processes and the control intensity and the functionality and effectiveness of the internal control systems (ICS) under the changed framework conditions and to respond reasonably to the changes of the risk situation.
The execution of these projects requires a suitable process model for the project, quality and change management with the associated work equipment, committees and report and escalation processes. The objective of the changes in the planned framework (scope, quality, time and costs) are difficult to achieve and, from experience, the risk profile is negatively affected without a structured, ordered and comprehensible approach in the individual project phases. This is unfortunately often demonstrated in practice with IT (software) projects which often fail, only partly achieve the intended objective or require significantly more time and costs than was originally planned.
Impacts on the risk profile
If, for example, it concerns the implementation of software migration projects in a customer-specific system environment, i.e. not a standardised software update (release-change), then essential changes in the IT applications and processes in question are frequently associated therewith. This requires implementation to comply with the regulatory requirements under MaRisk AT 8.2. In further consideration, more detail will not be given at this point on the changes of the specialist risk profile, the existing work processes and the control activities integrated therein, but rather on the implementation project. However, it is mandatory to take into account these above-mentioned requirements accordingly. Well-developed project management, ideally closely linked to the management of operational risks is helpful for this purpose and usually essential. In the case of planned changes of operational processes or structures, the risks primarily result from typical project and project environment risks.
Phase-oriented process model
The requirements with respect to a structured, comprehensible and documented approach were further specified by the “Banking Regulatory Requirements for IT Systems (BAIT)” of 3/11/2017 and the consultation draft 04-2018 “Insurance Regulatory Requirements for IT Systems (VAIT)” has been in place since 13/3/2018. However, it is worth noting that these requirements are overall not new and have already long been part of the established norms, standards and best practices and correlate with a professional approach.
Phase model for changes
Irrespective of the trigger and the type of change, the changes are carried out in the organisational structure in identical phases which are repeatedly passed through for iterative processes. The “three-phase model” for changes breaks down the project process into individual phases and delivers the rough structure for the project:
Trigger (problem) – project idea
Analysis of task and solution(s) – preliminary study
Decision/resolution by management (rejection or approval with/without requirements) – project initialisation or non-implementation
Specification – definition of requirements
Implementation – realisation
Testing – test
Activation – productive start-up
Stabilisation – error correction, support in the introductory phase
Review – remaining work
Project completion – look back (“lessons learned”)
In the case of essential or comprehensive changes to the work processes, it is essential for the specialist departments to prepare in advance corresponding specialist concepts with the specialist requirements which should generally be obligatory. However, this is usually successful only with comprehensive support from IT application management and with the involvement of specialists in the form of work and time-intensive workshops. If a complete and understandable requirements specification is omitted, then there is a very high risk that the projects fail or cannot be implemented within the desired framework (time, costs, scope and quality). In order to ensure the completeness and consistency of the specialist concepts, the requirements must be quality-assured from different points of view and with the involvement of the governance functions. In this case, the realistic implementability, the sequence of implementation and the dependencies with other projects in the company should be taken into account. Acceptance of the specialist concepts by the specialist departments should generally not be omitted. This applies equally to the IT technical concepts in order to provide a trusted and accepted basis for implementation.
Phase model for software development
When implementing a software migration project in a customer-specific system environment, it is very important to not only structure the project process, but also to consider the software development process with all associated phases as an integral part of the project.
The process of a phase-oriented software development project is outlined schematically below:
Phase I – requirements analysis
Phase II – design
Phase III – implementation
Phase IV – test and acceptance
Phase V – delivery and production start
Phase VI – stabilisation phase
The above-mentioned phase model of software development is embedded into the project management. Depending on the scope, structure and process model in the project, the individual phases are passed through repeatedly.
Test and acceptance of the system
Testing is an essential and major challenge in order to verify the completeness of the implementation of the solution and the correct processing functionality. These tasks are mainly bundled in one separate partial project and planned, processed, monitored and controlled based on a test concept with the different test stages. In order to transparently and comprehensibly design the testing, all phases of the test process (test planning, execution, documentation, evaluation and reporting) should be depicted in a test management tool. The acceptance process based on defined criteria includes all test stages and regulates the requirements for the transition to the next test stage and for all test procedures. It is the proof that the functional and non-functional requirements have been fulfilled. The test execution is therefore necessarily carried out in separate system environments which are separated from the production environment. With regard to the test data used, requirements under data protection law must be observed.
A comprehensive test environment is usually provided for the final acceptance test including all associated systems (interfaces) which largely corresponds both functionally and with regard to its hardware outfitting to the future production environment.