2012, November

1. Basic Notions of System Analysis

1.1. Definitions

The system is a means of achieving the goal of users (stakeholders) of the system.

• The system can be specially created or adapted to achieve the goal.
• The system necessarily has one or more target properties. If the target properties are several, then they can have different values (different significance) for the user of the system.

The problem - occurs when the system does not allow you to achieve the goals set for it:

• the target property does not reach the target level or
• the target property become worse or may become worse.

System Analysis is a structured approach to the achievement of the goal through the identification and resolution of problems.

1.2. When Does a Problem Arise?

An actively used system attracts problems like a magnet. Here are the most typical problems that accompany the system over the time of all its life cycle:

Creating a new system

• launching new products (goods, services) to the market,
• launch of new equipment,
• creating a new social movement,
• creating new technology, etc.

Changing (improving) an existing system - is usually related to changing the goals of the user of the system.

• increasing production volumes on existing equipment,
• increasing the level of customer loyalty,
• increase in market share,
• reducing costs on existing equipment, etc.

Changing external conditions for the system

• changing markets (suppliers, consumers, labor market, insurance, transport services ...),
• changing regulatory requirements, etc.

Practically always the very existence of the system causes the existence of a problem: it is difficult to imagine the owner or user of the system who would not want to make their system more efficient, manageable, reliable and safe.

1.3. Algorithm of System Analysis

Applied system analysis is a methodology or some sort of "technology" for improving systems. Like any technology, system analysis involves the sequential execution of certain operations. Each operation has a goal. Some particular result is expected after completion of each operation. Below is the algorithm of applied system analysis and outlines the main goals of its stages.

Making the language of description of the system definition the terms for system description Defining the target system properties using the system description language Modelling the system establishing the relations between expectations of stakeholders and system target properties establishing the relations between exernal and internal factors and parameters Identifying the problem search for critical parameters - system parameters negatively affecting its target properties Verification: Is the problem identified? the correlation between the values ​​of the critical parameters of the system and the deviations of its target properties from the desired values Problem solving Identifying the root causes of the problem of the system defining actions to improve the system Implementing improvement actions Verification: Is the solution reliable? revealing correlations between critical system parameters and improving its target properties Stabilizing the solution standardization of improving actions, the effectiveness of which is proven monitoring the correlation of the state of critical system parameters and the result achieved

The quality of implementation of system analysis should be confirmed by the effectiveness of actions changing the system that lead to solving the problem. Therefore, to fully implement the system analysis, it is not enough only to perform just "analysis of the system" (to understand the nature of the problem), but it is necessary to find and implement the right improving actions.

2. almaGRID is an Instrument of Applied System Analysis

2.1. Intended Purpose of almaGRID

almaGRID is a software specially designed as a toolbox for applied system analysis instruments for various areas including:

• social systems,
• financial systems,
• ecological systems,
• technical and engineering systems,
• production and service systems.

almaGRID allows, in a multiuser and multilingual environment:

• define the terms of the system description,
• build a system model,
• identify critical system parameters,
• analyze scenarios of system behavior and
• develop an adequate strategy for its progression.

After the program is installed on your computer, "almaGRID" item will appear in the menu or ribbon of MS Excel. Clicking on it you will get access to the functions of almaGRID. almaGRID menu items:

• Terms and Criteria
• Grids
• Objects

are used directly for implementation of the system analysis operations in:

• formation of description language of the system,
• composition of the system model, and
• revealing a problem.

2.2. Anatomy of almaGRID

almaGRID is a MS Excel add-in programm extending its functionality. Excel files are used for input and viewing the information stored in a database.

If the project file is located in a network you can organize joint work on the project by a group of users (managers, experts, analysts, operators, observers etc.) while restricting their rights of access to the project information. For example, some users just enter the information, others perform its analysis, still others formulate the strategy, and still others are engaged in implementation of the actions and control of the result.

A user of almaGRID can easily import, in his/her projects of system analysis, any existing information on the system that is contained in Excel files (or in other information systems from which the data can be exported to Excel). It means that, when using almaGRID, one will not need to manually enter, into a system analysis project, a large quantity of the information accumulated by the user, but it will just be necessary to "turn" the existing Excel workbooks into the form that is "understandable" to almaGRID program.

On the other hand, Excel files that are "adjusted" for working with almaGRID can be viewed and changed on any other computers in which almaGRID is not installed—because they still remain Excel files! A file changed on a computer without almaGRID (for example, data were entered in a ready-made format that was sent by e-mail) can be opened on a computer where almaGRID is installed, and the entered data can be transferred to the project file.

3. Technology of Applied System Analysis

3.1. Formation of the System Description Language

3.1.1. How to Come to an Agreement about the System Description Terms

The first stage of the system analysis is reaching an agreement, among all participants of the analysis, as to what the system is and which parameters describe the state of the system. To succeed in that, first you should come to an agreement concerning the terms (words, phrases, measurement units etc.) to be used for description of the system.

Imagine what could happen if each of the analysis participants would start using his/her own words to denominate the same component, function or parameter of the system! And now imagine that the participants, on top of that, speak different national languages—then added to the task of unifying the terms is the need to come to an agreement as to the translation of these terms into various languages that would be uniform for all.

So, the system description language is the structure of terms that is satisfactory for all participants of the system analysis.

• A term is a word or phrase denominating or describing the system's part, function or parameter.
• A term tree is formed by the terms that are arranged in a hierarchical (treelike) structure.
• The same term of the system description can form part of different branches of the term tree.
• New terms can be supplemented to the term tree:
  • by importing them from the cells of Excel workbook,
  • by importing them from other projects, or
  • by editing them directly in the window of management of the project terms (almaGRID- Terms and Criteria).
• The same term can be entered in different national languages.

3.2. Constructing the System Model

3.2.1. What is the System Model?

A model is our knowledge of the system. The knowledge of the system may be presented in different forms. A verbal description, a graphic presentation, a mathematical formulation etc. are models.

In practice of applied system analysis, when speaking about mathematical models of the system (mathematical description of the system), most often the following models are meant:

• Models constructed on the basis of generalization of the system historical data for the previous periods (statistical models). For example, after analyzing the seasonal information
  • on actual sales of tourist vouchers from N city,
  • on the number and price of the tickets sold for any mode of transport to N city,
  • on the number and price of the tickets sold for any mode of transport from N city,
  • on actual income of the inhabitants of N city,
  one can construct a seasonal model of sales of tourist vouchers to depend upon the number and level of welfare of the guests and inhabitants of N city. Construction of a statistical model requires arrangement of convenient collection of the data on the system state.
• Models constructed on the basis of mathematical formulation of the phenomena that take place in the system (phenomenological models). For example, knowing mathematical formulas that connect the rate of wear of a bearing with
  • its rotation velocity,
  • axle load,
  • temperature,
  • lubricant parameters,
  one can construct a model of the bearing service life and determine periodicity of its inspection and lubrication to ensure the required duration of its trouble-free operation.

Generally, both of these approaches are used in applied system analysis, in a combination that allows constructing a most realistic (adequate) model of the system with least effort.

3.2.2. Objects

When collecting statistical data on the system or making its phenomenological or any other description, we should have a possibility to store our knowledge on the system in a form convenient for us. In almaGRID, "object" is such form of presenting the knowledge on the system.

An object is a unit of information on the system. A number, text, logical constant, formula, almaGRID instruction, hyperlink or image may be an object.

Each object should have at least one criterion. A criterion is a term or a chain of terms taken from the term tree. While an object is a unit of information on the system, its criteria show what kind of information on the system the object contains

Since the criteria are formed on the basis of the system description terms that are agreed upon by all the participants of the analysis, the information on the system contained in the object is equally understandable to and unambiguously interpreted by all the analysis participants.

The criteria sequence order is not important. Several objects with an identical set of criteria can exist in a project.

In the system model, objects perform various functions that sometimes change during the analysis. The objects can be represented by:

• targeted features of the system (profitability of an enterprise, service life of a structure etc.);
• parameters of the system (quantity of the raw materials purchased, parameters of the technological process etc.); or
• restrictions imposed on the system (area of the warehouse, weekly hours etc.).

3.2.3. Grids

A grid is a table for entering and displaying the information on the system. The grid has a body and headings. Cells of the grid body display the objects that have the criteria shown in the heading cells that are in the same line and column as the object.

If a formula-type object has a link to a cell of the grid body, then such link is, when saving the grid, automatically replaced by the link to the object displayed in this cell of the grid. In the above example, "=24/С7" formula entered in a cell of the body of any grid on this worksheet will, when saving the grid, be automatically replaced by "=24/almaNNNNNNx" formula in which almaNNNNNNx is a link to the object with the criteria:

• [M1-01: waved band]
• [average speed between stops, meters/hour]
• [L1-2: extruder].

In our example, the constant of 90 corresponds to the object with such criteria. The value of this object can be at any time changed to another constant, formula or result of aggregation of other objects. Then a new value of the changed object will be used when calculating the values of the objects that link to the changed object.

If an Excel macro is used in a formula-type object, the macro will be saved when saving such object in the project file (the macro name must have "alma_" symbols at the beginning).

Change of a term position in the term tree, or editing of the name of a term that forms part of criteria of any object, will not break the relations of this object with other objects. For example, you can

• find a better or more exact wording of the term name or its translation to another national language, or
• change the structure of the term tree after changing the structure of the system that you are examining,

and this will not result in destruction of integrity of the system model, since the objects contain the links only to the objects' criteria but not to their specific wordings.

Essentially, a grid is represented by the areas in an Excel worksheet that are marked in a special way (for such marking, one should only select a range of cells and inform almaGRID of what the range actually is – the grid body or one of its headings). When marking the grid in the Excel worksheet, one can indicate what action for the grid synchronization with the project file will be performed automatically when opening the workbook in Excel:

• if the grid is a means for viewing the content of the project file, the objects from the project file will be automatically downloaded to it,
• if the grid is used as a form for entering information, the information from the grid will be transferred to the project file when opening the file with such grid.

3.3. Revealing a Problem

3.3.1. How to Formulate the Problem Correctly?

Revealing a problem means finding the system's elements/parameters that have a detrimental effect on targeted features of the system. The problem is revealed when the interrelation between deviations of the system's targeted features and the system's specific parameters is established.

Many people must have encountered phrases like “Everybody knows that small demand for our products is caused by an insufficient period of their storage, therefore we should buy new equipment that would allow manufacturing the products with a longer period of storage”. Alongside with that, before taking important decisions, many people must be willing to hear, instead of “Everybody knows…” argument, or better yet to see, the proofs of the following:

• the efforts will be made in a direction that is most important for achieving the result, and
• these efforts will be least costly.

Moreover, it is desirable that:

• the proofs would be formulated with the use of simple and previously agreed terms and would not be studded with peculiar words understandable only for a "narrow circle of specialists";
• the proofs would be easily read and unambiguously interpreted by any person involved in the process of the decision taking.

If a problem is revealed incorrectly, any changes of the system aimed at eliminating such "problem" are useless or sometimes even dangerous since they could lead to a still greater deviation of the system's targeted features from the desirable values.

System analysis, as a methodological approach, is aimed at reducing the risk of incorrect revelation of the system's problem. If the system description terms are formulated correctly and an adequate model of the system is constructed, the use of system analysis should, ideally, lead to revelation of the same problem, whoever would perform the analysis. Surely the expert's influence is great, but largely it has an impact upon the time spent on the problem revelation, rather than upon the analysis quality.

In order to reveal a problem, one should present the available information on the system (the system model) in such a form where a certain parameter of the system (the one the problem is connected with) would have a considerable greater contribution, as compared to other parameters of the same type, to the system's targeted feature. The following specialized tools of system analysis are intended for that:

• aggregation, and
• decomposition.

Aggregation and decomposition are performed to present the information on the system in such a way that would be most convenient for searching the system's parameters that influence a negative value of its targeted function.

3.3.2. Aggregation

Aggregation is consolidation of several objects into one. During aggregation, almaGRID searches all the objects that meet the aggregation rules, and then applies an aggregate function to the found objects, for example, it sums up the values of the found objects, determines their arithmetic average, calculates total quantity of the found objects etc. One can place the result of aggregation in an aggregate-type object and use its value for further analysis.

To define the rules for aggregation, one should just specify what criteria the objects to be aggregated must have. To define the rules for selecting the objects for aggregation, one can choose a whole branch of the criteria tree while indicating, for this branch, the sublevels the criteria of which must be present in the objects to be aggregated.

In the above example, almaGRID will create an aggregate-type object as a sum of durations (in minutes):

• for the time period including "2009-01 (Jan)-19, Mon" and "2009-01 (Jan)-20, Tue";
• in Line 1;
• of all changes of the format ("Product change: waved tube -> waved band", "Product change: smooth tube -> waved tube", "Product change: waved band -> smooth tube");
• performed by all shifts of operators/adjusters ("shift 24-07", "shift 15-23", "shift 08-15").

Upper levels of the term tree are schematically shown below. The inserts show the term tree branches" fragments that were used to construct the aggregates.

The same term may be present in various nodes of the term tree, therefore branches may be created, if necessary, to be specially intended for setting the rules for selecting the objects to be aggregated. This actually lifts the restriction on making the rules for aggregation of the information on the system contained in the project file.

A once created aggregate-type object will change its value:

• upon a change of the values of the objects to be aggregated that are included into it,
• upon a change of the structure of the branches of the term tree that are used for setting the rules for selecting the objects to be aggregated (adding or removing any term), or
• upon adding or removing, from the project file, the objects that meet the rules for selection for aggregation.

An aggregate-type object is the same unit of the information on the system as all the rest of the objects, and therefore, in its turn, it can be an element of an aggregate object of a higher level.

Aggregation is not only a tool of analysis; it also allows describing additional, generalized (aggregate) parameters of the system. Such aggregate parameters are often found among targeted features of the system. For example, if there is a production system model constructed on the basis of collecting the data on duration of the equipment stay in various states,

then, by creating aggregate objects, one can determine the equipment efficiency as a share of productive time of its usage:

A problem arises if we are not happy with the efficiency value. Solving the problem (improving the production system) implies eliminating the causes that lead to decrease if its efficiency. It is evident that there is a great many of such causes, and eliminating each of them is rather troublesome and costly. The logic of the system analysis supposes revelation of most important circumstances that lead to emergence of the problem and concentration of the efforts on these very circumstances.

In the example under consideration, the greatest loss of efficiency is related to "Change of packing type". Now we should study out which are the non-productive losses of time that occur upon changing the packing type. Decomposition, another standard tool of system analysis, can help in that.

3.3.3. Decomposition

Decomposition - is presentation of the whole in the form of its component parts. From the viewpoint of solving the task of the problem revelation, decomposition implies determining the contribution of various parameters of the system (terms of the system description) to the aggregate feature that must be improved.

In the above example, the duration of the equipment downtime for changing the packing type can be decomposed according to the types of this operation, i.e. the total time spent on changing the packing type can be broken by the time spent on changing the packing [packets] -> [boxes] and [boxes] -> [packets], separately.

To construct a grid with the decomposition result, a decomposition axis should be selected. A decomposition axis is a term from the sublevels of which a great number of criteria will be formed to be used for executing the decomposition. When selecting an axis, indication shall be made as to the depth of the sublevel from which the terms for decomposition will be taken.

Aggregate objects are placed in the cells of the grid body. If necessary, decomposition of these objects may be continued along other axes while getting increasingly detailed information on the influence of various parameters of the system on its targeted feature.

It is possible to change aggregate function of the objects that are obtained as a result of decomposition. For example, the above graph indicates that the total time spent on changing the packing type [boxes] -> [packets] exceeds the total time for changing the packing type [packets] -> [boxes]. To understand this situation better, one may, for example, make decomposition of the time for changing the packing type [boxes] -> [packets] by the average duration of this operation in each shift of operators.

Making use of the possibilities of aggregation and decomposition, one can see the duration of each event of changing the packing type [boxes] -> [packets] or construct a histogram of distribution of the number of these events according to their duration.

The sequence of the aggregations and decompositions ends upon revelation of critical terms of the system description—the parameters that influence an unsatisfactory value of the system's targeted feature to the maximum extent. It is these parameters improvement and stabilization that one should concentrate on when executing next stages of the system analysis.

If one fails to reveal the critical parameters, the system description can be changed:

• by adding new terms of description,
• by regrouping the existing terms,
• by detailing the terms through creating additional sublevels in them etc.,

and the data collection can be continued. Adjustment of the system description and the data collection is continued until one manages to reliably reveal the system's critical parameters.

The above approach implies changing the system description (term tree) while making the analysis: from simple to detailed one. This allows giving a very precise and easy answer to the questions:

• To what extent should the system description be detailed (for example, up to the pieces of equipment, up to the assemblies, …, up to the atoms, …)?
• What information on the system and to what amount should be collected?

When making system analysis, the system description should be detailed and the data collection should be organized only where this is required to reliably reveal the critical parameters.

3.4. Solving a Problem

3.4.1. What Does Solving a Problem Mean?

Solving a problem means eliminating the root (deep) causes of undesirable values of the critical parameters that lead to deviation of the system's targeted feature from the set value. To solve a problem one should:

• Find the root causes.
• Determine the improving actions that would lead to eliminating the root causes.
• Implement (realize) the actions for improvement.
• Make sure that the improvement actions taken have really improved the system's targeted feature.

Correct solution of a problem supposes making a minimum required impact on the system to lead to the expected result. The actions that do not lead to improvement of the system's targeted feature are erroneous. The logic of system analysis is aimed at:

• reduction of the risk of erroneous actions, and
• validity of effectiveness of the improving actions.

3.4.2. Searching Root Causes and Determining Improvement Actions

For searching root causes of undesirable state of the system's critical parameters, it is common to perform

• cause-effect analysis or
• phenomenological analysis.

When performing cause-effect analysis, one constructs a diagram/tree of cause-effect relations in which a specific undesirable state of a critical parameter is the "root", and its root causes are the "leaves".

Completeness and depth ("branchiness of the crown") of this tree, as well as its form, depend on the people (experts) who participate in the analysis. In its essence, the result of cause-effect analysis is a graphical presentation of the knowledge of the experts who participate in the analysis.

When performing phenomenological analysis, one constructs a model of the phenomenon that is responsible for the value of the critical parameter, and using this model analyzes "what if" scenarios while selecting such values of the system's parameters that ensure a desirable level of the system's targeted feature.

Let us exemplify phenomenological analysis. In designing a fireproof material, its targeted features were as follows:

• costs of the energy that is necessary for the material production,
• thermal resistance of the material,
• ultimate compression strength of the material, and
• porosity of the material.

These targeted features are not equivalent both for the producer and for the consumer. The more significant a targeted feature is, the more important it is for the feature to reach the targeted level.

Costs of the energy that is necessary for the material production depend on duration and temperature of the material thermal treatment. The material's targeted features that are important for the consumer also depend on these parameters. Then the task of the system analysis is to select such conditions of the material production (duration and temperature of its thermal treatment) that would ensure minimum energy consumption with maximum values of the material's targeted features.

To solve this task, it is convenient to construct a phenomenological model—a model of the phenomenon (technological process) that results in forming the material's targeted features. The dependency of the material's porosity on duration and temperature of its burning was constructed on the basis of experimental data.

The phenomenological model was made more complete by way of adding to it the known equations that relate the material's porosity to its physical and mechanical features. The following was taken as "initial approximation" of parameters/baseline scenario of the technological process:

Then, by constructing "what if" scenarios, we selected such scenario of change of the "initial approximation" of parameters of the technological process that results, according to the values of the targeted features" importance that we have taken, in maximum value of the selection criterion. The selection criterion is defined as a sum of the system's targeted features that are:

• normalized to the range from 1 to 10 (to be able to compare the quantities that differ in their nature and value), and
• ranked according to their significance (to have regard to importance of each of the targeted features).

As a result, "Increase of the burning temperature by 150 °C" appeared to be the most favorable scenario. It should be noted that almaGRID allows constructing scenarios of change of any (not necessarily directly related) parameter that is described in the project's term tree. If a targeted feature does not depend on the parameter being modified, the feature remains unchanged.

If necessary, one can construct scenarios with not one but several parameters" values being changed simultaneously. Besides, one can select, for calculating the selection criterion, any methodology that would be most adequate for the situation: the scenarios, ways of normalization and ranking according to significance—all this is described by the terms located in the project's term tree.

3.4.3. Execution of Actions for Improvement and Control of Effectiveness of the Actions

The substance of the actions for improvement depends on professionalism of the system analysis participants. Only intimate knowledge of the subject field allows competent formulation of an adequate improving action. Nevertheless, "correct" improving actions always have a number of signs:

• The actions are aimed at eliminating the root causes of the critical parameters" deviation from the desirable values, rather than at eliminating the symptoms.
• The actions are strictly focused on one of the following six basic categories of the objects being changed:
  • Equipment
  • Material
  • Method
  • Person
  • Measurement instrumentation
  • Environment
• The actions are described by the same terms as the system itself.
• The actions must be executable during the "useful life" of the information on critical parameters of the system.
• The system analysis participants personally organize or execute the improving actions and also control their execution.
• Effectiveness of the actions is determined only by actual improvement of the system's targeted feature.

If critical parameters are revealed correctly and influence, to the maximum extent, the deviation of the system's targeted feature from the desirable value, their correction should lead to improvement of the system's targeted feature.

Since almaGRID stores the whole information about the system in a single information space, the following questions can be answered, with the help of the information, for each line of the plan of improving actions:

• What must the action be executed for?
• What improvement of the system's targeted feature is expected after executing the action (or the group of actions)?

3.5. Stabilizing the Solution

3.5.1. How Not to Lose the Achieved Improvement of the System?

After the efficiency of the improving actions is proved (the system's targeted feature has improved), it is necessary to see to it that the achieved result is not lost with the lapse of time. Specific ways of stabilizing the achieved result depend on the nature of the system, but in most cases they are as follows:

• creation or change of the work procedures that ensure the required level of the system's targeted feature; and
• constant tracing of each case of deviation of the targeted feature from the achieved level while taking the countermeasures aimed, inter alia, at correcting the existing procedures.

Any system that was created for achieving a certain purpose is to a greater or lesser extent formalized. Virtually any system has its "operating instruction". If one carries out the instruction, the system achieves its purposes:

• a washing machine has its operating instruction (the linen is clean, not torn, the machine does not break down etc.),
• a country has its laws (the citizens are protected, GDP grows, the budget is executed etc.),
• there is a recipe for baking a cake (the cake is tasty, beautiful, safe etc.).

If such "system operating instruction" is not carried out or is carried out carelessly, it is most likely that the system's targeted feature will appear lower than the expected level.

The difficulty is in determining correctly what things should be described in the "system operating instruction": there is no sense in describing everything at once because it is impossible. According to the logic of system analysis,

• first of all one should standardize maintenance of the parameters that influence the system's targeted features to the maximum extent;
• then one should standardize maintenance of the rest of the parameters described in the term tree;
• all the things that have not come within the system description (have not proved useful for solving the problem) need not be described.

The form and content of the system's term tree are constantly changing, as solution of each new problem (they are constantly arising) practically always leads to the need to update the system description. Therefore the "system operating instruction" should be flexible and convenient for modification—only in this case it will be relevant.

Storage of the whole information about the system in a single information space of almaGRID allows regarding, as the "system operating instruction", the grid into which the objects (numbers, text, images, hyperlinks etc.) pertaining to the system's parameters were taken. Any changes and adjustments of these parameters automatically appear to be accounted for in such standard.

Appearance of such instruction is completely separated from its content. The appearance can be easily changed:

• several documents can be merged into one,
• a document can be divided into fragments,
• descriptions in a document can be made more or less detailed,
• and so on and so forth.

A multitude of the document types can exist simultaneously, but all of them will be reflecting the information on the system that is updated and relevant for the moment.

By the way, this document which is a short "operating instruction" for applied system analysis was prepared in almaGRID: almaGRID itself is a system with the targeted feature of reducing your efforts and improving the quality of system analysis of your systems.

4. References

Russell L. Ackoff, The Art of Problem Solving: accompanied by Ackoff's Fables. John Wiley & Sons: New York, 1978

Russell L. Ackoff, Management in Small Doses. John Wiley & Sons: New York, 1989

Learn more

Применение цифровых платформенных решений при организации "воронки проектов" и управлении программой развития

Одной из наиболее часто решаемых управленческих задач является организация деятельности по развитию. Залог успеха такой деятельности заключается в правильном ответе на два вопроса: Какие именно проекты нужно инициировать, чтобы обеспечить существенный скачок в развитии? Как организовать выполнение этих проектов с вовлечением всех заинтересованных сторон и ключевых участников? Read more »