A look at business using the ISO 15288 life cycle diagram
In this article, I again want to return to the problem of an adequate presentation of the business and its components. The fact that there is a problem of adequate presentation is evidenced by different sources: these are typical business process models developed by various associations and specific examples of business modeling that I have to deal with.
Quite by accident, reading materials on ISO 15288, I saw a scheme called “System interaction with Typical Enabling Systems” (the original form of the scheme is intentionally shown only at the end of the article), which clearly shows:
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 stages of the life cycle reflect the following idea: “The steps of developing a new system can be considered as a gradual“ materialization ”of the system - a gradual transition from an abstract need to assembling and assembling workable components that jointly perform complex functions to meet this need” [A. Kosyakov Engineering ”, p.143]. You need to understand that this is a simplified image of the actual course of stages, which in reality can overlap in time, alternate (for example, the functioning 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 a life cycle as applied to the subject area of business systems:
Let's try to look at the structure of a business system through the prism of the stages of the life cycle. First, depict the target system that 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 complex (car), 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, but at the maximum - still 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 come up with anything more successful. In business, this is usually called “Operations,” but it is an even more unfortunate term.
Important facts that are reflected in this scheme:
Also in the business system usually (but not necessarily!) There is a service system that is engaged in the "repair" of the Production system. In the term “repairs” I include both periodic scheduled maintenance and the replacement of unusable parts with fit ones. The service system allows the Production system to exist for an arbitrarily long time, performing its functions of producing the Product:
At this stage, the reader may already have questions: where do the Production and Service systems come from, and who is involved in the design and development of the product?
If I answer this question with a narrative, then I would put it this way:
A team of competent people is going to 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 on to implementation: to develop detailed projects of the Product, Production and Support systems, as well as implement the projects of Production and Support systems in the material.
After the implementation of the Production System in the material, it should be ready to start producing the Product. We reflect this narrative in the form of a diagram:
Important facts that are reflected in this scheme:
1) Firstly, the boundaries of a typical business system, which in this case can be called the system-engineering term “system of systems” (SoS), have already become visible on this scheme:
“In fact, whenever a number of independent and workable systems are combined to acquire capabilities 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 in the very early stages of development, when individual systems, although capable of functioning independently, were designed almost exclusively for SoS. At the other end, we find systems that are loosely coupled to temporarily solve a local problem without any formal justification 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 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 relationships, and not in relationships "Part-Whole":
In this case, one can also recall the theory of activity (for example, the SMD methodology of GP Shchedrovitsky) and say that systems are objects and means in some activities. However, their roles may change. 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 essence of the matter)
b) the systems are quite autonomous relative to each other (there can exist for long periods of time without each other), and can be replaced by other systems (for example, maintenance of the Production system can be outsourced).
2) The development system provides the “Development” stage of the Product 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 order. The development system in this case actually designs a whole class of products, as well as a Production system that is capable of producing this class of products without its restructuring. For example, it may be a company producing plastic windows: A production system is created so as to be able to produce a whole gamut of windows of different sizes, while a specific window is designed when the order is received by the Production system.
In the case when the Production System produces the product over and over again without changes, the Development System provides the stage of “Product Development” in full. But for other types of companies (design, software), other options for ensuring the product life cycle are possible.
Facts that are not reflected in this scheme:
An option for a business that deals with services / providing a service is given below (Fig. 7):
In this case, we can say that:
a) There is no product as an artifact separable from the business system.
b) The production system is in this case the Target system.
c) The production system at the “Operation” stage provides services to customers.
An example of such business systems is a hairdresser or taxi service.
Additionally, you can consider expanding the business system diagram shown in Figure 6 for two cases.
The first case when there is a need for service of the Product. In this case, the 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 both the manufacturer (manufactures spare parts) and the network of service centers owned by individual legal entities.
It is obvious that, if necessary, to ensure the “Write-off” stage of the Product, it is also necessary to build a Utilization System. An example of a product, when needed, is currently a car.
The second case that I would like to cite concerns the work of investment companies and venture funds. In this case, we are already talking about a “machine” for the mass creation of business systems:
In 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 business systems engineering, one of the key questions is how processes (or functions) are distinguished. The widespread view is that business is such an ebullient mess, in which the activity itself is closely intertwined with activities to improve this activity.
The objective of this article was to give a clear picture that there should be 3 systems and corresponding activities in business. The logic of work (technology) of each of the three systems is fundamentally different. People usually mix these technologies into their heads, and in models. Nothing good comes of it. Therefore, in practice, it should become clear that if, for example, the chief engineer thinks of a new production line, then at that moment he is a business architect and sits (plays a role) in the Development System. And if he manages the repair of the production line, then at that moment he is the maintenance staff and sits in the Maintenance system. And he should have time for every type of activity.
In a future article, I plan to consider modeling such a structure of a business system using common modeling notations.
This particular image of the circuit is taken from document ISO / IEC TR 24748-1 “TECHNICAL
REPORT. Systems and software engineering - Lifecycle management. Part 1 ”In almost the same form, he appeared in ISO / IEC 15288: 2002, although from the latest edition of 2015 this scheme was taken out in ISO / IEC TR 24748.
Dmitry Pinaev, GK "Modern Management Technologies"
Quite by accident, reading materials on ISO 15288, I saw a scheme called “System interaction with Typical Enabling Systems” (the original form of the scheme is intentionally shown only at the end of the article), which clearly shows:
- 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 stages of the life cycle reflect the following idea: “The steps of developing a new system can be considered as a gradual“ materialization ”of the system - a gradual transition from an abstract need to assembling and assembling workable components that jointly perform complex functions to meet this need” [A. Kosyakov Engineering ”, p.143]. You need to understand that this is a simplified image of the actual course of stages, which in reality can overlap in time, alternate (for example, the functioning 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 a life cycle as applied to the subject area of business systems:
Let's try to look at the structure of a business system through the prism of the stages of the life cycle. First, depict the target system that 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 complex (car), 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, but at the maximum - still 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 come up with anything more successful. In business, this is usually called “Operations,” but it 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 stages in its life cycle.
- 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 fact that the Production system produces the Product is reflected in the diagram.
- The production system partially provides the Product with the “Development” stage. An explanation of what is the meaning of this will be given below.
Also in the business system usually (but not necessarily!) There is a service system that is engaged in the "repair" of the Production system. In the term “repairs” I include both periodic scheduled maintenance and the replacement of unusable parts with fit ones. The service system allows the Production system to exist for an arbitrarily long time, performing its functions of producing the Product:
At this stage, the reader may already have questions: where do the Production and Service systems come from, and who is involved in the design and development of the product?
If I answer this question with a narrative, then I would put it this way:
A team of competent people is going to 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 on to implementation: to develop detailed projects of the Product, Production and Support systems, as well as implement the projects of Production and Support systems in the material.
After the implementation of the Production System in the material, it should be ready to start producing the Product. We reflect this narrative in the form of a diagram:
Important facts that are reflected in this scheme:
1) Firstly, the boundaries of a typical business system, which in this case can be called the system-engineering term “system of systems” (SoS), have already become visible on this scheme:
“In fact, whenever a number of independent and workable systems are combined to acquire capabilities 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 in the very early stages of development, when individual systems, although capable of functioning independently, were designed almost exclusively for SoS. At the other end, we find systems that are loosely coupled to temporarily solve a local problem without any formal justification 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 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 relationships, and not in relationships "Part-Whole":
- The development system plans, designs and develops the Production and Service system;
- The service system is engaged in the "repair" of the production system.
In this case, one can also recall the theory of activity (for example, the SMD methodology of GP Shchedrovitsky) and say that systems are objects and means in some activities. However, their roles may change. 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 essence of the matter)
b) the systems are quite autonomous relative to each other (there can exist for long periods of time without each other), and can be replaced by other systems (for example, maintenance of the Production system can be outsourced).
2) The development system provides the “Development” stage of the Product 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 order. The development system in this case actually designs a whole class of products, as well as a Production system that is capable of producing this class of products without its restructuring. For example, it may be a company producing plastic windows: A production system is created so as to be able to produce a whole gamut of windows of different sizes, while a specific window is designed when the order is received by the Production system.
In the case when the Production System produces the product over and over again without changes, the Development System provides the stage of “Product Development” in full. But for other types of companies (design, software), other options for ensuring the product life cycle are possible.
Facts that are not reflected in this scheme:
- In practice, the Development System in the development cycle repeatedly performs the “Design-Design” stages 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 circuit does not allow a concise representation of this fact. - Who is involved in the "Design-Production-Production" stages for the Development System?
Obviously, she herself cannot appear from nowhere. Most often, in practice, the process of creating a “Development System” 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 you see the opportunity to create a business system, then 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 when the process of creating the “Development System” is well formalized, it will be considered below. - It does not reflect how the decommissioning of the Production and Maintenance systems occurs, because in practice, this is quite rare.
An option for a business that deals with services / providing a service is given below (Fig. 7):
In this case, we can say that:
a) There is no product as an artifact separable from the business system.
b) The production system is in this case the Target system.
c) The production system at the “Operation” stage provides services to customers.
An example of such business systems is a hairdresser or taxi service.
Additionally, you can consider expanding the business system diagram shown in Figure 6 for two cases.
The first case when there is a need for service of the Product. In this case, the 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 both the manufacturer (manufactures spare parts) and the network of service centers owned by individual legal entities.
It is obvious that, if necessary, to ensure the “Write-off” stage of the Product, it is also necessary to build a Utilization System. An example of a product, when needed, is currently a car.
The second case that I would like to cite concerns the work of investment companies and venture funds. In this case, we are already talking about a “machine” for the mass creation of business systems:
In 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 business systems engineering, one of the key questions is how processes (or functions) are distinguished. The widespread view is that business is such an ebullient mess, in which the activity itself is closely intertwined with activities to improve this activity.
The objective of this article was to give a clear picture that there should be 3 systems and corresponding activities in business. The logic of work (technology) of each of the three systems is fundamentally different. People usually mix these technologies into their heads, and in models. Nothing good comes of it. Therefore, in practice, it should become clear that if, for example, the chief engineer thinks of a new production line, then at that moment he is a business architect and sits (plays a role) in the Development System. And if he manages the repair of the production line, then at that moment he is the maintenance staff and sits in the Maintenance system. And he should have time for every type of activity.
In a future article, I plan to consider modeling such a structure of a business system using common modeling notations.
Application. Original design from ISO 15288
This particular image of the circuit is taken from document ISO / IEC TR 24748-1 “TECHNICAL
REPORT. Systems and software engineering - Lifecycle management. Part 1 ”In almost the same form, he appeared in ISO / IEC 15288: 2002, although from the latest edition of 2015 this scheme was taken out in ISO / IEC TR 24748.
Dmitry Pinaev, GK "Modern Management Technologies"