Introduction of elements of flexible methodologies in the Bank
Good afternoon, dear habravchane. Earlier, I said that the main activity of the Bank in terms of IT processes was organized at ITIL. The only exception was the change management process. The second (and final) part is devoted to the implementation of flexible methodologies in the Bank in IT change management processes.
I encountered the following problems when analyzing an existing process:
• 80% of tasks go ad hoc
• task priorities 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 effect 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 the three most common scenarios. I am sure they can be found in other financial organizations.
For clarity, we will launch a new credit product - Credit Card. The customer will be the retail business, the main contractor is the external contractor (we will use the outsourcing model that is common in a number of organizations), the internal IT performs the service function. And most importantly: all situations will be fictional, and coincidences are random.
The customer starts the project implementation, holds meetings with the Contractor. The result of the formation of the project passport for the implementation of the product.
All requirements and processes described by our Customer fall into a passport, based on the sales process:
• Client questionnaire fields;
• Front-end system requirements (sales, 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, they are left unworked (or unrecorded): participation of the fin. monitoring in the process of product identification (blacklists, lists of terrorists, etc.).
It will be necessary to refine the sales process, change forms, add integrations, new roles. As a result: a change in the timing and budget of the project. As often happens - one unit can not know all the processes of other units.
Our customer holds meetings with all business units, the process becomes the most elaborate, but there is no architectural description of the implementation of the functionality 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 he knows). In the process of the pilot, it turns out that part of the parameters must be configured in the ABS (the main accounting system of the Bank), otherwise there will be no possibility of correct interest calculation.
What we have is the additional costs of synchronizing systems (credit product parameters) or labor costs of transferring the product catalog to the ABS. In the first case, the operating expenses for product maintenance increase, in the second, the project’s time and budget increase.
The third possible case - parallel changes in the main systems, initiated by other units or changes in legal requirements. The simplest example is the addition or change of customer questionnaire fields, the change of 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 over IT resources. To this end, 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 takes place in similar organizations. But many large organizations are introducing flexible processes only formally - the head comes to the IT department and says: “So, from today on, the head of the department becomes a scram master, conduct stand-ups and draw sprints.” This change does not fundamentally change anything except names (managers conduct short-term planning, meetings with subordinates, etc.). Sometimes IT teams invite one person from the business to discuss, but the discussion at such meetings is purely technical in nature, so there is no profit from this.
We proposed a completely different model, to unite around the products, including representatives from all departments involved in the processes associated with these products (both sales and service) in the team. The second significant innovation - the life cycle of the banking product starts from the lead and ends at the moment of closing or reselling the transaction.
Stage 1 - Fixing the Idea, Preparing the CR, Preliminary Assessment.
Any team member describes the implemented change for a preliminary analysis, using the user-story format, which eventually ends up in the business analyst backlog. The business analyst organizes weekly meetings where the 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 backlog of the product.
Stage 2 - Prioritization and Implementation Planning
Planning tasks is to determine the list of tasks from the backlog, which will be included in the next sprint. The owner of the product is directly responsible for prioritizing tasks, and he is responsible for the economic viability of the work and the quality of the product sold. The team succeeds or makes mistakes as a unit.
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, correct the list of further works. All product changes are combined into releases, which consist of several sprints lasting 2-4 weeks.
As a conclusion of the article, I’ll give an example of a team from a retail business, to which our fictional product can be assigned - Credit Card:
Credit Card Management and Acquiring (Product Owner)
• Financial Monitoring Department
• Management of financial and operational risk control
• Management of banking operations
• Management of Information Technology
• Payment Management
Description of the problem
I encountered the following problems when analyzing an existing process:
• 80% of tasks go ad hoc
• task priorities 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 effect 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 the three most common scenarios. I am sure they can be found in other financial organizations.
For clarity, we will launch a new credit product - Credit Card. The customer will be the retail business, the main contractor is the external contractor (we will use the outsourcing model that is common in a number of organizations), the internal IT performs the service function. And most importantly: all situations will be fictional, and coincidences are random.
The customer starts the project implementation, holds meetings with the Contractor. The result of the formation of the project passport for the implementation of the product.
All requirements and processes described by our Customer fall into a passport, based on the sales process:
• Client questionnaire fields;
• Front-end system requirements (sales, 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, they are left unworked (or unrecorded): participation of the fin. monitoring in the process of product identification (blacklists, lists of terrorists, etc.).
It will be necessary to refine the sales process, change forms, add integrations, new roles. As a result: a change in the timing and budget of the project. As often happens - one unit can not know all the processes of other units.
Our customer holds meetings with all business units, the process becomes the most elaborate, but there is no architectural description of the implementation of the functionality 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 he knows). In the process of the pilot, it turns out that part of the parameters must be configured in the ABS (the main accounting system of the Bank), otherwise there will be no possibility of correct interest calculation.
What we have is the additional costs of synchronizing systems (credit product parameters) or labor costs of transferring the product catalog to the ABS. In the first case, the operating expenses for product maintenance increase, in the second, the project’s time and budget increase.
The third possible case - parallel changes in the main systems, initiated by other units or changes in legal requirements. The simplest example is the addition or change of customer questionnaire fields, the change of their obligation.
Finding 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 over IT resources. To this end, 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 takes place in similar organizations. But many large organizations are introducing flexible processes only formally - the head comes to the IT department and says: “So, from today on, the head of the department becomes a scram master, conduct stand-ups and draw sprints.” This change does not fundamentally change anything except names (managers conduct short-term planning, meetings with subordinates, etc.). Sometimes IT teams invite one person from the business to discuss, but the discussion at such meetings is purely technical in nature, so there is no profit from this.
We proposed a completely different model, to unite around the products, including representatives from all departments involved in the processes associated with these products (both sales and service) in the team. The second significant innovation - the life cycle of the banking product starts from the lead and ends at the moment of closing or reselling the transaction.
Stage 1 - Fixing the Idea, Preparing the CR, Preliminary Assessment.
Any team member describes the implemented change for a preliminary analysis, using the user-story format, which eventually ends up in the business analyst backlog. The business analyst organizes weekly meetings where the 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 backlog of the product.
Stage 2 - Prioritization and Implementation Planning
Planning tasks is to determine the list of tasks from the backlog, which will be included in the next sprint. The owner of the product is directly responsible for prioritizing tasks, and he is responsible for the economic viability of the work and the quality of the product sold. The team succeeds or makes mistakes as a unit.
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, correct the list of further works. All product changes are combined into releases, which consist of several sprints lasting 2-4 weeks.
Conclusion
As a conclusion of the article, I’ll give an example of a team from a retail business, to which our fictional product can be assigned - Credit Card:
Credit Card Management and Acquiring (Product Owner)
• Financial Monitoring Department
• Management of financial and operational risk control
• Management of banking operations
• Management of Information Technology
• Payment Management
Source: https://habr.com/ru/post/336554/
All Articles