Service coordinate axes or how to combine IT and telecommunications management methodologies
There are two perfectly working models:
Over the past few years, IT and telecommunications have merged so much that differences in methodologies become a drag on real technical projects. Is it possible to combine the views of IT and technical specialists in one? My answer is yes!
')
Attempts to combine these two views still boil down to a simple mapping of some concepts into others, which does not bring them closer to understanding, but only confirms that both methodologies essentially describe the same activity. There is a great desire to combine these two views into one, moving away from the labels “IT approach” and “telecommunication approach” and focusing on the essence. The essence is simple - the provision of services.
We are always between two poles: certainty and uncertainty, development and operational activity. Running PDCA, we gain experience, expand our knowledge and capabilities. But at the same time, the cycle does not give an answer to the question of exactly where the border between development and operational activity lies. This is important because the management of development and model operations are very different. The second problem of the PDCA is the lack of focus on the client. Every time we look at the problem from the inside of the company in this process: streamlined processes, efficient infrastructure, performance of the SLA are important to us. But the client may still be dissatisfied.
But before moving on to the second model, let's take a closer look at the Check area. It can be divided into two important parts:
In the area of ​​activity planning, the situation is similar. Can we plan the laying of the wall after the incident of the destruction of part of the wall (work to eliminate errors) or the project of building a great wall (system development)? Should
bricklayer, who was issued a work order, think about it? And what qualification and level of consciousness should such a person have?
Thus, the Plan area can be divided into two subregions:
This is what we get with the PDCA cycle:
Pay attention to the transitions from Check to Plan, bypassing the Act, which is not needed if we are talking about standard errors and the standard reaction to it.
This gives straightforward answers to a few common questions:
- Is it possible not to register the incident?
Yes, if the monitoring system detected an error, the error is insignificant, it can be corrected automatically or with minimal actions (transition 1 in the figure above). The event is recorded at a lower level of the event funnel - in the monitoring log, but it does not reach the recording of the incident.
- Is it possible to perform work on the infrastructure without the agreement of the RfC?
Yes, if this is done by the infrastructure monitoring / management system itself, or if the work is typical, standard (transitions 1 and 2 in the figure). It is only necessary to understand the effect of the work on the interruption of the service and agree, if necessary, the time windows of this interruption. Change is always unique, therefore standard RfC does not exist!
- Is classical release management required to perform typical jobs or implement monitoring tools?
Not. Simplified forms of control work more efficiently (transition 2 in the figure).
Transition 1 shows how autorun works. When a deviation in the system automatics logic or typical instructions of people can quickly fix the problem in a short time. This is similar to interrogation polls and actions on them. For example, auto control is the autopilot of an airplane. Or opening the valve of a steam boiler if the pressure reaches a critical point. At the same time, the person opening the valve may not have the qualifications sufficient to understand his actions. Arrow in the red zone - follow the instructions.
This is transition 2. If errors occur that the system cannot correct itself, you connect more qualified people. People from the monitoring center quickly resolve the problem using their standard script. For example, if the pilot of the aircraft sees that the autopilot has failed - he takes manual control.
On transition 3 there is a slower analysis, which has no standard instructions. It analyzes errors with an obscure cause, the situation as a whole, and so on. The main indicator is the quality of the analysis and the quality of the solution. It is important that the third level should not take too many resources - so the decision is made in the Act step in the model, that is, data on the state of the system are passed on. At the same time, with an average impact on a business, a compromise is required between the speed of decision making and the quality of analysis, and with a strong influence on business, the quality of analysis allows one to make an optimal management decision.
On the Act area, we move from passive observation of the system to its active change. At the same time, monitoring can lead us beyond the Act to change the system for the purpose of routine error correction (operational activity), or for development (substantial creative - that is, atypical change). In this case, the more atypical reference data used in passing through the Act, the more important the decision will be, and the more accurately the event correlation should be. The separation between monitoring and scheduling allows the BSS / OSS to be represented like this:
Now look again at the PDCA.
There are two problems of applying this model purely:
But we already have a BSS / OSS, painted on the PDCA. Now we simply combine these two models.
There are now exactly two processes for each pole. Why? Here you can draw an analogy from the field of construction. We are accustomed to reasoning that absolutely all business is driven by customer demand. Then, when building a house, it would be logical to first find the first client on the market, willing to buy an apartment, make a deal with him and build him a corner apartment on the first floor of the future house. So, the client for the client, to bring the storeys of the house to the high-rise building. Only, after all, nobody does that. The construction of a house and the sale of apartments move in parallel, interdependent and inseparable from each other.
The direct conclusion that follows from this model is the importance of striking a balance between business and infrastructure, between projects and condition monitoring. Here is the same model from operations to development:
Workflow in such a model is two counter-flows of events generated by clients and infrastructure. The model is customer-oriented, and its content is highly dependent on the type of client with which the system interacts. It is better to build such a model separately for the client, supplier, internal employee, etc.
Here is an example:
- PDCA (Plan-Do-Check-Act) quality cycle, which will be used in IT-processes;
- And the BSS / OSS model, which is used to manage telecom processes.
Over the past few years, IT and telecommunications have merged so much that differences in methodologies become a drag on real technical projects. Is it possible to combine the views of IT and technical specialists in one? My answer is yes!
')
Attempts to combine these two views still boil down to a simple mapping of some concepts into others, which does not bring them closer to understanding, but only confirms that both methodologies essentially describe the same activity. There is a great desire to combine these two views into one, moving away from the labels “IT approach” and “telecommunication approach” and focusing on the essence. The essence is simple - the provision of services.
We are always between two poles: certainty and uncertainty, development and operational activity. Running PDCA, we gain experience, expand our knowledge and capabilities. But at the same time, the cycle does not give an answer to the question of exactly where the border between development and operational activity lies. This is important because the management of development and model operations are very different. The second problem of the PDCA is the lack of focus on the client. Every time we look at the problem from the inside of the company in this process: streamlined processes, efficient infrastructure, performance of the SLA are important to us. But the client may still be dissatisfied.
But before moving on to the second model, let's take a closer look at the Check area. It can be divided into two important parts:
- Operational - “identification of errors” (bugs) and work on them in order to quickly restore the quality of services provided.
- Development - “identifying the state of the system” (problems), in order to analyze data on the operation of the system and propose solutions to problems, prevent errors and find ways to improve the system as a whole.
In the area of ​​activity planning, the situation is similar. Can we plan the laying of the wall after the incident of the destruction of part of the wall (work to eliminate errors) or the project of building a great wall (system development)? Should
bricklayer, who was issued a work order, think about it? And what qualification and level of consciousness should such a person have?
Thus, the Plan area can be divided into two subregions:
- Operational - “management of orders for standard works” (ordering);
- Development - “change planning” (change).
This is what we get with the PDCA cycle:
Pay attention to the transitions from Check to Plan, bypassing the Act, which is not needed if we are talking about standard errors and the standard reaction to it.
This gives straightforward answers to a few common questions:
- Is it possible not to register the incident?
Yes, if the monitoring system detected an error, the error is insignificant, it can be corrected automatically or with minimal actions (transition 1 in the figure above). The event is recorded at a lower level of the event funnel - in the monitoring log, but it does not reach the recording of the incident.
- Is it possible to perform work on the infrastructure without the agreement of the RfC?
Yes, if this is done by the infrastructure monitoring / management system itself, or if the work is typical, standard (transitions 1 and 2 in the figure). It is only necessary to understand the effect of the work on the interruption of the service and agree, if necessary, the time windows of this interruption. Change is always unique, therefore standard RfC does not exist!
- Is classical release management required to perform typical jobs or implement monitoring tools?
Not. Simplified forms of control work more efficiently (transition 2 in the figure).
Automanagement
Transition 1 shows how autorun works. When a deviation in the system automatics logic or typical instructions of people can quickly fix the problem in a short time. This is similar to interrogation polls and actions on them. For example, auto control is the autopilot of an airplane. Or opening the valve of a steam boiler if the pressure reaches a critical point. At the same time, the person opening the valve may not have the qualifications sufficient to understand his actions. Arrow in the red zone - follow the instructions.
Error monitoring and planning of typical work
This is transition 2. If errors occur that the system cannot correct itself, you connect more qualified people. People from the monitoring center quickly resolve the problem using their standard script. For example, if the pilot of the aircraft sees that the autopilot has failed - he takes manual control.
System state monitoring and change planning
On transition 3 there is a slower analysis, which has no standard instructions. It analyzes errors with an obscure cause, the situation as a whole, and so on. The main indicator is the quality of the analysis and the quality of the solution. It is important that the third level should not take too many resources - so the decision is made in the Act step in the model, that is, data on the state of the system are passed on. At the same time, with an average impact on a business, a compromise is required between the speed of decision making and the quality of analysis, and with a strong influence on business, the quality of analysis allows one to make an optimal management decision.
On the Act area, we move from passive observation of the system to its active change. At the same time, monitoring can lead us beyond the Act to change the system for the purpose of routine error correction (operational activity), or for development (substantial creative - that is, atypical change). In this case, the more atypical reference data used in passing through the Act, the more important the decision will be, and the more accurately the event correlation should be. The separation between monitoring and scheduling allows the BSS / OSS to be represented like this:
Now look again at the PDCA.
There are two problems of applying this model purely:
- The processes of working with clients and work with the infrastructure are combined.
- The decision point is at the top, not in the center (common sense suggests).
But we already have a BSS / OSS, painted on the PDCA. Now we simply combine these two models.
Combining models
There are now exactly two processes for each pole. Why? Here you can draw an analogy from the field of construction. We are accustomed to reasoning that absolutely all business is driven by customer demand. Then, when building a house, it would be logical to first find the first client on the market, willing to buy an apartment, make a deal with him and build him a corner apartment on the first floor of the future house. So, the client for the client, to bring the storeys of the house to the high-rise building. Only, after all, nobody does that. The construction of a house and the sale of apartments move in parallel, interdependent and inseparable from each other.
The direct conclusion that follows from this model is the importance of striking a balance between business and infrastructure, between projects and condition monitoring. Here is the same model from operations to development:
Workflow in such a model is two counter-flows of events generated by clients and infrastructure. The model is customer-oriented, and its content is highly dependent on the type of client with which the system interacts. It is better to build such a model separately for the client, supplier, internal employee, etc.
Here is an example:
Key findings
- The de facto border between IT and telecommunications no longer exists.
- Focus IT - the company's client. Internal employees are only a special case of customers.
- BSS / OSS is a powerful tool that it’s time to use in managing any services. The above “Service Coordinate Axes” allow you to keep both the process and architectural views of the client in focus, as well as to see the problems that arise at the junctions of the domains.4. The company's internal processes themselves must be vertically balanced - between clients and infrastructure, and horizontally - between monitoring and projects. Distortions lead to problems. The resulting model openly declares to business: you can’t strike at a purely project activity, nor can you stop just by maintaining the achieved level of quality. You can not rely on the conclusion of contracts with customers, not backed by their infrastructural capabilities.
- There must be a balance in both axes. What a balance - it depends on the current business goals. In two extreme cases, this hardening and gradual growth in the existing architecture, or a leap to innovation and architecture transformation.
- All functional and system elements of the organization's architecture can be laid in the resulting seven layers. If there is a void somewhere, it is a hint that either you forgot to automate something or your business is really unbalanced. As an example, I will give the domain Customer Experiene. It is absolutely symmetrical to the Technical Performance domain, and therefore, during its construction completely predictable information flows arise.
Source: https://habr.com/ru/post/196726/
All Articles