Implementation of elements of flexible methodologies in the Bank
Good afternoon, dear habravchane. Earlier I said that the main activities of the Bank in terms of IT processes were organized on ITIL. The only exception was the change management process. The second (and final) part is devoted to the introduction of elements of flexible methodologies in the Bank in the processes of change management in IT.
I encountered the following problems when analyzing the existing process:
• 80% of the tasks are received ad hoc
• the priorities of the tasks are constantly changing
• there is no possibility to carry out work planning
• there is no harmony in the development of systems
• there are no “established rules of the game" when implementing changes
As an internal effect - the emotional burnout of staff, a drop in labor productivity, the lack of innovation.
The main goal of the Bank is to bring new products to the market as quickly and efficiently as possible. Why didn’t this happen? I will show you the three most common scenarios. I am sure they can be found in other financial organizations.
For clarity, we will launch a new loan product - Credit Card. The customer will be the retail business, the main contractor is an external contractor (we will use the outsourcing model that is common in a number of organizations), internal IT performs a service function. And most importantly: all situations will be fictitious, and coincidences random.
The customer begins the implementation of the project, holds meetings with the Contractor. The result is the formation of a project passport for the implementation of the product.
The passport contains all the requirements and processes that our Customer describes, based on the sales process:
• Fields of the client’s profile;
• Requirements for the front system (sale, verification);
• role model;
• Requirements for integration with systems;
• Draft sales process.
And here we come to the first error: after the approval of the concept and the start of the work, it turns out to be unworked (or unaccounted for): participation is financial. monitoring in the process of product identification (blacklists, lists of terrorists, etc.).
It will require refinement of the sales process, changing forms, adding integrations, new roles. As a result: change in the terms and budget of the project. As often happens, one unit cannot know all the processes of other units.
Our Customer holds meetings with all business units, the process becomes as elaborated as possible, but there is no architectural description of the functional implementation in business systems. The customer describes the presentation of the product catalog, the contractor implements the product catalog in his system (that is, in the system that he knows). In the pilot process, it turns out that some of the parameters must be configured in the ABS (the main accounting system of the Bank), otherwise there will be no possibility of the correct calculation of interest.
What we have is additional costs for synchronizing systems (parameters of a loan product) or labor costs transferring the maintenance of the product catalog to the ABS. In the first case, operating expenses for product support increase, in the second case, the increase in the terms and budget of the project.
The third possible case is parallel changes in the main systems initiated by other units or changes in the requirements of the law. The simplest example is adding or changing the fields of a client’s questionnaire, changing their obligation.
Our task was to build an effective implementation process, for this it was necessary to involve all business units in the change management process, as well as reduce conflicts for the IT resource. To do this, we began to look towards flexible methodologies in order to use their artifacts in improving internal processes.
First, we began to look at how implementation is taking place in similar organizations. But many large organizations introduce flexible processes only formally - the head comes to the IT department and says: “So, from today the head of the department becomes a scrum master, we conduct stand-ups and draw sprints.” This change fundamentally does not change anything except the names (managers conduct short-term planning, meetings with subordinates, etc.). Sometimes one person from the business is invited to discuss the IT team, but the discussion at such meetings is purely technical in nature, therefore, profit from this does not work.
We proposed a completely different model, to unite around products, including in a team of representatives from all departments involved in the processes associated with these products (both sales and services). The second significant innovation - the life cycle of a banking product starts from the lead and ends at the time the transaction is closed or resold.
Stage 1 - Fixing Ideas, Preparing CR, Preliminary Assessment.
Any team member describes the change being implemented for preliminary analysis, using the user-story format for this, which eventually ends up in the backend of business analytics. The business analyst organizes weekly meetings where changes are discussed with the participation of the product owner, analysts, and other business units involved in the process. After this stage, the changes fall into the product backlog.
Stage 2 - Setting priorities and planning implementation.
Task planning consists in determining the list of tasks from the backlog that will be included in the next sprint. The product owner is directly responsible for the prioritization of tasks, he is also responsible for the economic feasibility of the work and the quality of the product sold. A team succeeds or makes mistakes as a whole.
Stage 3 - Development, testing, release.
The owner of the product receives the result of each sprint for testing and can influence the further course, for example, adjust the list of further work. All product changes are combined into releases, which consist of several sprints lasting 2-4 weeks.
To conclude this article, I will give an example of a team from the retail business that our fictional product can be assigned to - Credit card:
Credit Card and Acquiring Department (Product Owner)
• Financial Monitoring
Department • Financial and Operational Risk
Control Department • Banking Support Department
• Management information technology
• Management of payment systems
Description of the problem
I encountered the following problems when analyzing the existing process:
• 80% of the tasks are received ad hoc
• the priorities of the tasks are constantly changing
• there is no possibility to carry out work planning
• there is no harmony in the development of systems
• there are no “established rules of the game" when implementing changes
As an internal effect - the emotional burnout of staff, a drop in labor productivity, the lack of innovation.
The main goal of the Bank is to bring new products to the market as quickly and efficiently as possible. Why didn’t this happen? I will show you the three most common scenarios. I am sure they can be found in other financial organizations.
For clarity, we will launch a new loan product - Credit Card. The customer will be the retail business, the main contractor is an external contractor (we will use the outsourcing model that is common in a number of organizations), internal IT performs a service function. And most importantly: all situations will be fictitious, and coincidences random.
The customer begins the implementation of the project, holds meetings with the Contractor. The result is the formation of a project passport for the implementation of the product.
The passport contains all the requirements and processes that our Customer describes, based on the sales process:
• Fields of the client’s profile;
• Requirements for the front system (sale, verification);
• role model;
• Requirements for integration with systems;
• Draft sales process.
And here we come to the first error: after the approval of the concept and the start of the work, it turns out to be unworked (or unaccounted for): participation is financial. monitoring in the process of product identification (blacklists, lists of terrorists, etc.).
It will require refinement of the sales process, changing forms, adding integrations, new roles. As a result: change in the terms and budget of the project. As often happens, one unit cannot know all the processes of other units.
Our Customer holds meetings with all business units, the process becomes as elaborated as possible, but there is no architectural description of the functional implementation in business systems. The customer describes the presentation of the product catalog, the contractor implements the product catalog in his system (that is, in the system that he knows). In the pilot process, it turns out that some of the parameters must be configured in the ABS (the main accounting system of the Bank), otherwise there will be no possibility of the correct calculation of interest.
What we have is additional costs for synchronizing systems (parameters of a loan product) or labor costs transferring the maintenance of the product catalog to the ABS. In the first case, operating expenses for product support increase, in the second case, the increase in the terms and budget of the project.
The third possible case is parallel changes in the main systems initiated by other units or changes in the requirements of the law. The simplest example is adding or changing the fields of a client’s questionnaire, changing their obligation.
Search for a solution
Our task was to build an effective implementation process, for this it was necessary to involve all business units in the change management process, as well as reduce conflicts for the IT resource. To do this, we began to look towards flexible methodologies in order to use their artifacts in improving internal processes.
First, we began to look at how implementation is taking place in similar organizations. But many large organizations introduce flexible processes only formally - the head comes to the IT department and says: “So, from today the head of the department becomes a scrum master, we conduct stand-ups and draw sprints.” This change fundamentally does not change anything except the names (managers conduct short-term planning, meetings with subordinates, etc.). Sometimes one person from the business is invited to discuss the IT team, but the discussion at such meetings is purely technical in nature, therefore, profit from this does not work.
We proposed a completely different model, to unite around products, including in a team of representatives from all departments involved in the processes associated with these products (both sales and services). The second significant innovation - the life cycle of a banking product starts from the lead and ends at the time the transaction is closed or resold.
Stage 1 - Fixing Ideas, Preparing CR, Preliminary Assessment.
Any team member describes the change being implemented for preliminary analysis, using the user-story format for this, which eventually ends up in the backend of business analytics. The business analyst organizes weekly meetings where changes are discussed with the participation of the product owner, analysts, and other business units involved in the process. After this stage, the changes fall into the product backlog.
Stage 2 - Setting priorities and planning implementation.
Task planning consists in determining the list of tasks from the backlog that will be included in the next sprint. The product owner is directly responsible for the prioritization of tasks, he is also responsible for the economic feasibility of the work and the quality of the product sold. A team succeeds or makes mistakes as a whole.
Stage 3 - Development, testing, release.
The owner of the product receives the result of each sprint for testing and can influence the further course, for example, adjust the list of further work. All product changes are combined into releases, which consist of several sprints lasting 2-4 weeks.
Conclusion
To conclude this article, I will give an example of a team from the retail business that our fictional product can be assigned to - Credit card:
Credit Card and Acquiring Department (Product Owner)
• Financial Monitoring
Department • Financial and Operational Risk
Control Department • Banking Support Department
• Management information technology
• Management of payment systems