Transition applications. How do we pick up apps in support
A little bit about us, the customer, projects and history
The team of our company provides application support services for 80+ applications of a German customer. Over 5 years of cooperation, we have developed a trusting relationship. About once a year, the customer incurs costs, looks at how much our team is worth and with what quality it works, and decides to outsource another dozen or two internal applications.
Our customer is a major manufacturer of servers and office equipment. Applications that come to us, mainly created for accounting, sales planning, orders and reporting at different levels. We also have an internal corporate portal on SharePoint on support and everything that usually happens on a large organization in SharePoint (recruitment, workflow, etc.).
')
Our team provides 2, 3, 4 lines of support for SharePoint and applications on .NET. We solve incidents, fix bugs and problems, and change application code when necessary. We also develop from scratch, but this is the story of another article.
During these 5 years, we carried out the transfer of knowledge 4 times, and we had the experience that we want to share. Internal practices, how to plan the transfer, then to fit into the budget and schedule, and avoid problems in the future, when the service starts.
Service Translation Planning
Before you start planning, we request two documents :
We also request the entire set of available documentation, code and all records of incidents, if you can see them. We ask you to make several overview presentations for each application, where you can ask questions to those who understand it.
Once in the heads clarifies the scale of thedistress of the transferred volume, it's time to open the MS Project and plan a plan.
For each of the transmitted applications, we plan:
Planning a service translation is similar to a regular project plan. The difficulty is that the edge to which you reach in the analysis of the application, you install yourself. How thoroughly the code will understand, how seriously you need to understand business processes, how accurately you are going to reproduce the environment in which the application runs. I have no special recommendations where to stay. We stop when, in general, how it is clear, and in detail we are able to figure out on our own. These details are what will distinguish you for the first six months - a year from the current service provider. First, you will solve problems longer, sometimes much longer. It is necessary to explain to the customer that the service will first be very slow if the transfer of knowledge is inexpensive, and vice versa. Looking for a middle ground is better with the customer, given its budget and the importance of the smooth operation of applications.
In addition to the plan, this stage involves the creation of a register of risks, which we have laid in the assessment.
Important : all necessary information should be brought to all interested people on time. To give on the side of the service is very uncomfortable, especially for the first time. It is important that people learn to trust you, for this your actions should become as clear and transparent for them as possible. Reports on the status of the work should go regularly. If you do not meet the deadline, or nakosyachili, the customer should know about it as soon as possible.
Tranny on start
After the plan is ready, the contract is signed, and the team is assembled, you can start.
The transfer of knowledge looks like any other project that goes according to plan. You can use the management methodology that is right for you. We took 2-week Scramov iterations, and they worked fine. Stack of project documents prepared by Prince 2.
As in any project, it happens that suddenly you need to do something that is not in the description of work (oh, we forgot that this is not one business case, but three). It happens that you underestimate the complexity of the work. If you are an experienced manager, you also have a buffer for this risk.
But there is a difficulty that we encountered only on a knowledge transfer project: strong resistance. Inside the customer, the environment is not homogeneous, there are often people who are not very happy with the decision of the management to outsource the projects. Often, the current service provider boycotts the transfer of documentation, does not come to the knowledge transfer session, or does not tell you everything you need to know. In this case, all you can do is escalate, and, if nothing happens, increase the cost of the transaction. This situation and ways to work with it need to be discussed before the transfer of knowledge began, of course, in the risk register this item should be.
At the exit from the service translation project, we also provide:
In addition, an official sign-off should be held, acceptance of work from the translation project manager to the service manager.
The service manager, of course, begins to work much earlier than at the time of sign-off. Even before the transfer of knowledge, the size of the tracking team usually pretends with it, by the time of the sign-off our assumptions about the team are only confirmed and adjusted. The service manager participates in the creation of a preliminary version of the main service processes.
These processes describe:
The first months of service, these processes will be debugged and changed. From the preliminary version they will develop into complete working versions. This is another transparency tool: whatever we do, we are predictable for the customer.
When we train a service team and try to provide a service under the supervision of the current support service, the load of the service manager sometimes becomes even greater than that of the project manager for the translation. And, of course, he should discuss the SLA and write a contract for the provision of the service. So, we can say that the service manager is working tirelessly throughout the entire project to translate the service.
In order to have even fewer problems, people who will work as part of a service team will necessarily participate in the transfer of knowledge. This is the core of the future team. After completion of the translation project, they help the team to learn new knowledge.
When the service is a little settled, after about 3-6 months, we start the process of improving the service. It is based on kanban. This process has helped us reduce the cost of service by half, but this is the topic of the next article.
Posted by: Fkleto4ku
The team of our company provides application support services for 80+ applications of a German customer. Over 5 years of cooperation, we have developed a trusting relationship. About once a year, the customer incurs costs, looks at how much our team is worth and with what quality it works, and decides to outsource another dozen or two internal applications.
Our customer is a major manufacturer of servers and office equipment. Applications that come to us, mainly created for accounting, sales planning, orders and reporting at different levels. We also have an internal corporate portal on SharePoint on support and everything that usually happens on a large organization in SharePoint (recruitment, workflow, etc.).
')
Our team provides 2, 3, 4 lines of support for SharePoint and applications on .NET. We solve incidents, fix bugs and problems, and change application code when necessary. We also develop from scratch, but this is the story of another article.
During these 5 years, we carried out the transfer of knowledge 4 times, and we had the experience that we want to share. Internal practices, how to plan the transfer, then to fit into the budget and schedule, and avoid problems in the future, when the service starts.
Service Translation Planning
Before you start planning, we request two documents :
- Service description for each application, including:
- a brief description of the application: what it is for;
- what business processes automates;
- what kind of tasks we have to do: close the incidents and do regular maintenance work, monitor, solve problems, etc.
- Questionnaire form for each application:
- how many users use the application;
- they are internal or external;
- are there key users;
- how many incidents are solved on average per year, etc.
We also request the entire set of available documentation, code and all records of incidents, if you can see them. We ask you to make several overview presentations for each application, where you can ask questions to those who understand it.
Once in the heads clarifies the scale of the
For each of the transmitted applications, we plan:
- regular knowledge transfer sessions;
- deployment of development environment for the application, code analysis;
- writing or finishing documentation (business processes, test plans, etc.);
- review of incidents and problems; creating an incident knowledge base;
- work on incidents in the current support group (they do the work - we are looking);
- transfer of knowledge gained to the support team;
- work under the supervision of the current support group (we do the work - they insure).
Planning a service translation is similar to a regular project plan. The difficulty is that the edge to which you reach in the analysis of the application, you install yourself. How thoroughly the code will understand, how seriously you need to understand business processes, how accurately you are going to reproduce the environment in which the application runs. I have no special recommendations where to stay. We stop when, in general, how it is clear, and in detail we are able to figure out on our own. These details are what will distinguish you for the first six months - a year from the current service provider. First, you will solve problems longer, sometimes much longer. It is necessary to explain to the customer that the service will first be very slow if the transfer of knowledge is inexpensive, and vice versa. Looking for a middle ground is better with the customer, given its budget and the importance of the smooth operation of applications.
In addition to the plan, this stage involves the creation of a register of risks, which we have laid in the assessment.
Important : all necessary information should be brought to all interested people on time. To give on the side of the service is very uncomfortable, especially for the first time. It is important that people learn to trust you, for this your actions should become as clear and transparent for them as possible. Reports on the status of the work should go regularly. If you do not meet the deadline, or nakosyachili, the customer should know about it as soon as possible.
Tranny on start
After the plan is ready, the contract is signed, and the team is assembled, you can start.
The transfer of knowledge looks like any other project that goes according to plan. You can use the management methodology that is right for you. We took 2-week Scramov iterations, and they worked fine. Stack of project documents prepared by Prince 2.
As in any project, it happens that suddenly you need to do something that is not in the description of work (oh, we forgot that this is not one business case, but three). It happens that you underestimate the complexity of the work. If you are an experienced manager, you also have a buffer for this risk.
But there is a difficulty that we encountered only on a knowledge transfer project: strong resistance. Inside the customer, the environment is not homogeneous, there are often people who are not very happy with the decision of the management to outsource the projects. Often, the current service provider boycotts the transfer of documentation, does not come to the knowledge transfer session, or does not tell you everything you need to know. In this case, all you can do is escalate, and, if nothing happens, increase the cost of the transaction. This situation and ways to work with it need to be discussed before the transfer of knowledge began, of course, in the risk register this item should be.
At the exit from the service translation project, we also provide:
- recommendations for changing the code;
- completed checklist for service start: what has been done, what has not been done from the planned one and why;
- preliminary version of the basic processes of the new service;
- the register of risks of a new service, with simplified plans, of course;
- lessons learned: what went wrong and how not to plunge into it the next time.
In addition, an official sign-off should be held, acceptance of work from the translation project manager to the service manager.
The service manager, of course, begins to work much earlier than at the time of sign-off. Even before the transfer of knowledge, the size of the tracking team usually pretends with it, by the time of the sign-off our assumptions about the team are only confirmed and adjusted. The service manager participates in the creation of a preliminary version of the main service processes.
These processes describe:
- how often event logs are checked;
- how to work, if you need help from another team to close the ticket;
- how to close tickets in the system and much more, without which the service will not work like a clock.
The first months of service, these processes will be debugged and changed. From the preliminary version they will develop into complete working versions. This is another transparency tool: whatever we do, we are predictable for the customer.
When we train a service team and try to provide a service under the supervision of the current support service, the load of the service manager sometimes becomes even greater than that of the project manager for the translation. And, of course, he should discuss the SLA and write a contract for the provision of the service. So, we can say that the service manager is working tirelessly throughout the entire project to translate the service.
In order to have even fewer problems, people who will work as part of a service team will necessarily participate in the transfer of knowledge. This is the core of the future team. After completion of the translation project, they help the team to learn new knowledge.
When the service is a little settled, after about 3-6 months, we start the process of improving the service. It is based on kanban. This process has helped us reduce the cost of service by half, but this is the topic of the next article.
Posted by: Fkleto4ku
Source: https://habr.com/ru/post/252173/
All Articles