A look at business using the ISO 15288 life cycle diagram
This article again wants to return to the problem of an adequate presentation of the business and its components. The fact that there is a problem of adequate representation is evidenced by various sources: these are typical business process models developed by various associations, and specific examples of business modeling that I have to face.
Quite by chance, reading the materials according to ISO 15288, I saw the scheme "System interaction with Typical Enabling Systems" (the original form of the scheme is intentionally shown only at the end of the article), in which you can see quite clearly:
')
I immediately wanted to try to apply this scheme to decomposition into parts of a business system, and I share the results of this attempt in this article.
One of the basic concepts of ISO 15288 is the life cycle of a system, which is schematically depicted as follows:
The life cycle stages reflect the following idea: “The steps of developing a new system can be viewed as a gradual“ materialization ”of the system — a gradual transition from an abstract need to assembling and installing usable components that jointly perform complex functions in order to satisfy this need” [A. Kosyakov, “System engineering, p.143]. It should be understood that this is a simplified image of the actual course of the stages, which in reality may overlap each other in time, alternate (for example, the operation of the system and its maintenance), etc. But we, nevertheless, this scheme will be enough to visualize some fundamental ideas.
I adapted the idea of ​​the life cycle in relation to the subject area of ​​business systems:
Let's try to look at the structure of a business system through the prism of life cycle stages. First, we depict the target system we want to produce:
In the case of a business system, the target system is usually called the term “Product”, and I will continue to use it as the main one. The product can be quite complicated (car), it can be quite simple (for example, an ax), this is not important for this article. Everything is a system, and all systems have a life cycle.
Obviously, the product must at least be produced, and as a maximum, it must still be advertised, sold, delivered, etc. In the diagram, this is displayed as follows:
The term “Production System” may not be very successful for conveying the necessary meaning, but so far I have not thought of anything better. In business, this is usually called “Operations,” but this is an even more unfortunate term.
Important facts that are reflected in this scheme:
Also in the business system there is usually (but not necessarily!) A service system that deals with the “repair” of the Production system. In the term “repairs,” I include both periodic, routine maintenance, and the replacement of unusable parts with suitable ones. The service system allows the Production System to exist for an arbitrarily long time, fulfilling its functions for the production of the Product:
At this stage, the reader may already have questions: where do the Production and Service Systems come from, and also who is engaged in the design and product development?
If you answer this question with a narrative, then I would formulate it like this:
A team of competent people is gathered who discuss the concept of the product and the ability to produce it.
If the concept is satisfactory and the ability to produce a product exists, then the team begins to move towards implementation: to develop detailed projects of the Product, Production and Supporting systems, as well as to implement the projects of Production and Supporting systems in the material.
After the implementation of the Production System in the material, it should be ready to start producing the Product. Let's reflect this narrative in the form of a diagram:
Important facts that are reflected in this scheme:
1) First, on this scheme, the boundaries of a typical business system have already become visible, which in this case can be called the system engineering term “system of systems” (SoS):
“In fact, whenever a series of independent and workable systems are combined to acquire opportunities that go beyond the sum of the capabilities of individual systems, we get a system of systems. Of course, the level of integration can vary significantly. At one end of the spectrum is SoS, fully integrated at the earliest stages of development, when individual systems, although capable of operating independently, were designed almost exclusively for SoS. At the other end, we encounter systems that are loosely coupled for a temporary solution of a local problem without any formal grounds other than the consent of their owners ”, [A. Kosyakov,“ System Engineering ”, p.119].
I think both such and such types of SoS are found in business systems. To this I would like to add that business at the top level of the presentation is not a “rigid” hierarchical system, as is commonly believed, namely, a system of systems, because:
a) the systems in it are in fairly specific connections, and not in the “Part-Whole” links:
In this case, you can also recall the theory of activity (for example, the SMD methodology of GP Schedrovitsky) and say that the systems are objects and means in some activities. However, their roles may vary. For example, in the creation of the Production System, the Production System is the object, and the Development System is the means of activity. When the Production System is built, it becomes a means in the production of the Product (or in the production of money in the form of profit, if you look at the bottom line)
b) the systems are sufficiently autonomous with respect to each other (long periods of time can exist without each other), and can also be replaced with other systems (for example, maintenance of the Production system can be outsourced).
2) The development system provides the “Development” stage of the Product’s life cycle almost completely, but a small part of the “Development” stage is provided by the Production system. In practice, this happens when there is a need to clarify the design of the product at the stage of receiving a customer’s order. At the same time, the development system actually designs a whole class of products, as well as a Production System, which is capable of producing this class of products without its restructuring. For example, it may be a company for the production of plastic windows: A production system is created to be able to produce a whole range of differently sized windows, and a specific window is also designed when an order is received by the Production system.
In the case when the Production System produces the product time after time without changes, the Development System provides the “Development” stage of the Product completely. But for other types of companies (project, software) other options are possible to ensure the product life cycle.
Facts that are not reflected in this diagram:
The option for the business that deals with the services / provision of services is given below (Figure 7):
In this case, we can say that:
a) There is no product as a separate artifact from the business system.
b) The production system is in this case the target system.
c) The production system at the “Functioning” stage provides service to customers.
An example of such business systems is a hairdresser or a taxi service.
Additionally, you can consider extending the business system diagram in Figure 6 for two cases.
The first case, when there is a need for service of the Product. In this case, a Service System for the Product must also be created:
There are common situations when the Service system belongs to several owners. For example, in the case of the production of household appliances, the Service system includes itself as a manufacturing enterprise (produces spare parts) and a network of service centers owned by certain legal entities.
It is obvious that, if necessary, to ensure the “Write-off” stage of the Product, it is also necessary to build the utilization system. An example of a product, when necessary, is currently a car.
The second case, which I would like to bring, concerns the work of investment companies and venture funds. In this case, we are already talking about the "machine" for the mass creation of business systems:
On the diagram, I reflected the fact that the Business Replication System is partially involved in the design of the Product and the Production System. If the plan ends successfully, then it creates a Development System, which continues to work on creating a business system.
In the subject area of ​​engineering business systems, one of the key issues is how processes (or functions) are distinguished. There is a widespread view that business is such a vigorous "porridge" in which the activity itself is closely intertwined with the activity to improve this activity.
The objective of this article was to give a clear picture that there should be 3 systems in a business and the corresponding activities. The logic of work (technology) of each of the three systems is fundamentally different. People usually mix these technologies into one whole, both in their heads and in models. Nothing good comes out of it. Therefore, in practice, it should become clear that if, for example, the chief engineer thinks about a new production line, then at this moment he is a business architect and sits (performs a role) in the Development System. And if he manages the repair of the production line, then at this moment he is the service personnel and sits in the Service System. And he should have time for each type of activity.
In a future article, I plan to address the issue of modeling such a structure of a business system using common modeling notations.
This variant of the schematic image is taken from ISO / IEC TR 24748-1 "TECHNICAL
REPORT. Systems and software engineering - Lifecycle management. Part 1 ”In almost the same form, it appeared in ISO / IEC 15288: 2002, although from the latest edition of 2015 this scheme was put in the ISO / IEC TR 24748 manual.
Dmitry Pinayev, GC "Modern management technologies"
Quite by chance, reading the materials according to ISO 15288, I saw the scheme "System interaction with Typical Enabling Systems" (the original form of the scheme is intentionally shown only at the end of the article), in which you can see quite clearly:
- types of systems involved in the creation and maintenance of the target system
- communication of these systems with the target system.
')
I immediately wanted to try to apply this scheme to decomposition into parts of a business system, and I share the results of this attempt in this article.
One of the basic concepts of ISO 15288 is the life cycle of a system, which is schematically depicted as follows:
The life cycle stages reflect the following idea: “The steps of developing a new system can be viewed as a gradual“ materialization ”of the system — a gradual transition from an abstract need to assembling and installing usable components that jointly perform complex functions in order to satisfy this need” [A. Kosyakov, “System engineering, p.143]. It should be understood that this is a simplified image of the actual course of the stages, which in reality may overlap each other in time, alternate (for example, the operation of the system and its maintenance), etc. But we, nevertheless, this scheme will be enough to visualize some fundamental ideas.
I adapted the idea of ​​the life cycle in relation to the subject area of ​​business systems:
Let's try to look at the structure of a business system through the prism of life cycle stages. First, we depict the target system we want to produce:
In the case of a business system, the target system is usually called the term “Product”, and I will continue to use it as the main one. The product can be quite complicated (car), it can be quite simple (for example, an ax), this is not important for this article. Everything is a system, and all systems have a life cycle.
Obviously, the product must at least be produced, and as a maximum, it must still be advertised, sold, delivered, etc. In the diagram, this is displayed as follows:
The term “Production System” may not be very successful for conveying the necessary meaning, but so far I have not thought of anything better. In business, this is usually called “Operations,” but this is an even more unfortunate term.
Important facts that are reflected in this scheme:
- A production system is also a system that goes through its life cycle stages.
- The arrow shows the relationship between the systems, namely: The production system at the “Operation” stage provides the Product with the “Production” life cycle stage. Or, to put it more simply: the diagram reflects the fact that the Production System produces the Product.
- The production system partially provides the Product with the “Development” stage. An explanation of what meaning is put into it will be given below.
Also in the business system there is usually (but not necessarily!) A service system that deals with the “repair” of the Production system. In the term “repairs,” I include both periodic, routine maintenance, and the replacement of unusable parts with suitable ones. The service system allows the Production System to exist for an arbitrarily long time, fulfilling its functions for the production of the Product:
At this stage, the reader may already have questions: where do the Production and Service Systems come from, and also who is engaged in the design and product development?
If you answer this question with a narrative, then I would formulate it like this:
A team of competent people is gathered who discuss the concept of the product and the ability to produce it.
If the concept is satisfactory and the ability to produce a product exists, then the team begins to move towards implementation: to develop detailed projects of the Product, Production and Supporting systems, as well as to implement the projects of Production and Supporting systems in the material.
After the implementation of the Production System in the material, it should be ready to start producing the Product. Let's reflect this narrative in the form of a diagram:
Important facts that are reflected in this scheme:
1) First, on this scheme, the boundaries of a typical business system have already become visible, which in this case can be called the system engineering term “system of systems” (SoS):
“In fact, whenever a series of independent and workable systems are combined to acquire opportunities that go beyond the sum of the capabilities of individual systems, we get a system of systems. Of course, the level of integration can vary significantly. At one end of the spectrum is SoS, fully integrated at the earliest stages of development, when individual systems, although capable of operating independently, were designed almost exclusively for SoS. At the other end, we encounter systems that are loosely coupled for a temporary solution of a local problem without any formal grounds other than the consent of their owners ”, [A. Kosyakov,“ System Engineering ”, p.119].
I think both such and such types of SoS are found in business systems. To this I would like to add that business at the top level of the presentation is not a “rigid” hierarchical system, as is commonly believed, namely, a system of systems, because:
a) the systems in it are in fairly specific connections, and not in the “Part-Whole” links:
- The development system plans, designs and develops the Production and Maintenance System;
- The service system is engaged in the "repair" of the Production System.
In this case, you can also recall the theory of activity (for example, the SMD methodology of GP Schedrovitsky) and say that the systems are objects and means in some activities. However, their roles may vary. For example, in the creation of the Production System, the Production System is the object, and the Development System is the means of activity. When the Production System is built, it becomes a means in the production of the Product (or in the production of money in the form of profit, if you look at the bottom line)
b) the systems are sufficiently autonomous with respect to each other (long periods of time can exist without each other), and can also be replaced with other systems (for example, maintenance of the Production system can be outsourced).
2) The development system provides the “Development” stage of the Product’s life cycle almost completely, but a small part of the “Development” stage is provided by the Production system. In practice, this happens when there is a need to clarify the design of the product at the stage of receiving a customer’s order. At the same time, the development system actually designs a whole class of products, as well as a Production System, which is capable of producing this class of products without its restructuring. For example, it may be a company for the production of plastic windows: A production system is created to be able to produce a whole range of differently sized windows, and a specific window is also designed when an order is received by the Production system.
In the case when the Production System produces the product time after time without changes, the Development System provides the “Development” stage of the Product completely. But for other types of companies (project, software) other options are possible to ensure the product life cycle.
Facts that are not reflected in this diagram:
- In practice, the Development System in the development cycle repeatedly performs the stages “Design-Design” for the Product, Production and Service Systems, as well as “Production” for the Production and Service Systems.
As noted at the beginning of the article, this type of scheme does not allow to concisely reflect this fact. - Who is involved in the “Design-Development-Production” stages for the Development System?
Obviously, she herself can not appear out of nowhere. Most often, in practice, the process of creating a “System of Development” is poorly formalized and looks like this: the main stakeholder (for example, an investor) is looking for a manager who forms a team. Further, this team carries out primary research, which was already mentioned above. If it is possible to create a business system, the team becomes the “Development System”: on a one-time or permanent basis. In the latter case, it must be borne in mind that the Development System may also need to be rebuilt.
There are other situations where the process of creating a “Development System” is well formalized; it will be discussed below. - It does not reflect how the Production and Service Systems are written off, as in practice, this is quite rare.
The option for the business that deals with the services / provision of services is given below (Figure 7):
In this case, we can say that:
a) There is no product as a separate artifact from the business system.
b) The production system is in this case the target system.
c) The production system at the “Functioning” stage provides service to customers.
An example of such business systems is a hairdresser or a taxi service.
Additionally, you can consider extending the business system diagram in Figure 6 for two cases.
The first case, when there is a need for service of the Product. In this case, a Service System for the Product must also be created:
There are common situations when the Service system belongs to several owners. For example, in the case of the production of household appliances, the Service system includes itself as a manufacturing enterprise (produces spare parts) and a network of service centers owned by certain legal entities.
It is obvious that, if necessary, to ensure the “Write-off” stage of the Product, it is also necessary to build the utilization system. An example of a product, when necessary, is currently a car.
The second case, which I would like to bring, concerns the work of investment companies and venture funds. In this case, we are already talking about the "machine" for the mass creation of business systems:
On the diagram, I reflected the fact that the Business Replication System is partially involved in the design of the Product and the Production System. If the plan ends successfully, then it creates a Development System, which continues to work on creating a business system.
Conclusion
In the subject area of ​​engineering business systems, one of the key issues is how processes (or functions) are distinguished. There is a widespread view that business is such a vigorous "porridge" in which the activity itself is closely intertwined with the activity to improve this activity.
The objective of this article was to give a clear picture that there should be 3 systems in a business and the corresponding activities. The logic of work (technology) of each of the three systems is fundamentally different. People usually mix these technologies into one whole, both in their heads and in models. Nothing good comes out of it. Therefore, in practice, it should become clear that if, for example, the chief engineer thinks about a new production line, then at this moment he is a business architect and sits (performs a role) in the Development System. And if he manages the repair of the production line, then at this moment he is the service personnel and sits in the Service System. And he should have time for each type of activity.
In a future article, I plan to address the issue of modeling such a structure of a business system using common modeling notations.
Application. Original diagram from ISO 15288
This variant of the schematic image is taken from ISO / IEC TR 24748-1 "TECHNICAL
REPORT. Systems and software engineering - Lifecycle management. Part 1 ”In almost the same form, it appeared in ISO / IEC 15288: 2002, although from the latest edition of 2015 this scheme was put in the ISO / IEC TR 24748 manual.
Dmitry Pinayev, GC "Modern management technologies"
Source: https://habr.com/ru/post/299328/
All Articles