Cybernetic model adaptation strategy
 

I. Migration formula

1. We will mark the current organization status (before dia$par) as point A:

dia$par.Enterprise (today) = A

Target organization status ("to be" model) will be marked as point B:

dia$par.Enterprise (today + Δt) = B

Objective: to take organization status from configuration A to configuration B.

NB: Point B corresponds to the "to be" image, which is formulated and agreed upon before the transit actions.

B is NOT the enterprise "pinnacle of evolution" at all.
Starting at point B the enterprise ability to transform increases colossally and the enterprise continues to evolve "within" the managing meta-system.

2. The according model configuration will be defined by the same letters with "primes".

We’ll say, that organization A configuration is complimentary to model A" configuration, if A" defines business processes in configuration A:

dia$par.Matrix = A'
A ~ A'

Same as B ~ B' and so on.

The cybernetic model configuration in dia$par package will be marked as 0".
By the time the organization transits to dia$par the model configuration must be complimentary to B, namely B".

3. The final migration formula is described in a series of equations:

dia$par.Enterprise (project life cycle): A → B (1)
dia$par.Matrix (project life cycle): 0' → B' (2)
B ~ B ' (3)

or (A → B) ~ (B' ← 0')

Equation (2) describes the implementation project team goal in the narrow sense: developers of the dia$par integrator (dia$par model engineers) and organization business process experts (dia$par process engineers).

This is the integrator’s primary line of responsibility.

4. Equation (1) requires changes in organization processes before switching to dia$par.

All-in-all, these changes are a natural part of the dia$par transition project to a wide extent.

However, for obvious reasons of administrative nature these events and responsibilities lie with the organization management (dia$par.Enterprise).

Therefore, an administrative sponsor appears in the mutual mapping migration strategy, who is the senior executive in terms of the migrating business unit. In most cases, this is the company CEO.

The administrative sponsor status does NOT require full commitment to the project implementation process.

Sponsor’s mission is to be responsible for the set of actions (1) and possibly to manage the process of their implementation.

That’s where the dia$par integrator provides every kind of assistance on its part.

 

II. Project team fractal: downward branch two-in-box root system

1. In the process of project architecture development the full organization model function is decomposed into function blocks (oriented graph nodes), which group along the primary value chains of that organization.

2. Every function block additionally can be decomposed into basically any number of sub-blocks, forming subsidiary nodes in the architecture framework.

Change Management Center visual interface allows to see the latest project architecture with the information on the process of execution for the whole model and for every node individually.

3. Every node in the function block (node) root system always has two managers (block leaders): on the customer side (.Enterprise — eleader) and on the integrator side (.Matrix — mleader).

The responsibility for the overall model status lies with the transit leaders (TLs): dia$par migration project co-managers from the organization (enterprise transit leader — ETL) and integrator developer teams (model transit leader — MTL) accordingly.

4. A specific configuration of the function block (and managers) tree does NOT have anything to do with company bureaucratic organizational structure in general.

All block leaders, including TLs are chosen exclusively on the competence basis.

Every block leader is ultimately responsible for the implementation of changes in terms of his function blocks and at the interface between neighboring value chains of the adjacent function owners.

And likewise — they have full power in terms of making decisions on changes in business logic. Within their own block, of course.

A certain employee can be the leader of any number of blocks, located on any "level" of the model decomposition tree.

Logical assignment and following distribution of blocks among the leader candidates is conducted solely on the basis of personal competence.

 

III. Migration path

1. Let’s take the S" space of the possible model configurations (which corresponds to the S space of the possible states of the actual organization).

Due to their one-to-one correspondence, we will illustrate only the S space and the points, which represent the current organization status — A and the "to be" model — B.

Keeping in mind that these are not actually points, but closely linked by mutual mapping two-sided replication status pairs "Enterprise ~ Model" (A ~ A' and B ~ B').

AB vector shows the shortest path.

However, the shortest does NOT mean the fastest.

Or the most profitable.

Ask mountain-climbers or military leaders.

2. The most profitable path for the organization from point A to point B can lie through intermediary points A₀, A₁ and so on.

The choice of a certain migration path is influenced by a huge amount of factors, the main of which are

• managers" readiness for organization management changes

and

• managers" ability to implement them properly.

Project’s bottleneck for dia$par transition is always the implementation of changes in an actual organization: dia$par.Matrix model, however, can by changed by programmers on the fly, doesn’t have an opinion, doesn’t object, doesn’t sabotage and doesn’t take sick days.

3. The real possibilities of management in terms of making cognitive coordinated changes in the organization are always limited by at least

• the scale, complexity and following business process momentum of the organization,

and

• the level of actual management controllability of basic business processes by company management.

Migration trajectory for the enterprise is evaluated by dia$par integrator based on the results of a express survey, and determined during the development of the Functions Reference of the cybernetic model.

4. Transit features of branched and/or geographically distributed conglomerate organizations.

4.1 A business unit of a conglomerate of any size can be placed in dia$par, as long as it’s enclosed.

Meaning, if the connections of this business unit with other components of the conglomerate can be represented in a "supplier — buyer" paradigm without the loss of information.

As a rule, this is either a separate line of business GE Money Bank as a part of General Electric), or a detached division — like Opel in General Motors.

Formally speaking, a separate business unit can be placed in dia$par if its value chains are closed primary within its perimeter.

4.2 Migration to dia$par by a conglomerate is the final step of a sequential process of increasing dia$par perimeter, while absorbing business units of progressively larger size one by one.

4.3 A separate migration to dia$par of functional units (like a trade company warehouse, e.g.) is formally possible, but has no economic sense, and conflicts with the fundamental logic of process approach.

The difference between functional units and logically separated business units is NONclosure: basically, they are separate sections of value chains.

They generally begin and end outside the mandate of a functional unit.

In our example of a trade company warehouse the "transfer of goods" (as a fragment of the "sale" chain) begins with the salesroom or an online shop.

"Product arrival" as a part of the "purchase" chain, begins in the similarly-named department.

 

IV. Understanding entities. Mutual mapping prism

1. A common ERP paradigm approach to business process automation — function "modules", distributed according to the bureaucratic organizational structure of the company, must be disconcertingly discarded.

2. There are two types of mutual mapping entities, which describe the core of company business, for the business process architect of the organization managed with dia$par: mchains and mpacks.

Mchains are no less than classic value chains, but in a mathematically standardized understanding of mutual mapping.

"Links" of mchains are called msteps.

Mpacks are the things that move through the virtual mchains conveyors.

"Product" in the widest sense.

While being a "raw material" at the first mstep of a specific mchain, in the end it is a "finished product", which is passed on to the internal or external (on a new mchain) buyers.

3. Business process structure of any organization can be described by a complex of mchains and mpacks.

The mutual mapping abstraction is the most natural among suggestion, being user-friendly and relevant to the natural business logic.

A businessman-manager with experience in process approach will spend less than 15 minutes remembering new terms while learning mutual mapping.

4. Here are some fairly different business models and an example of their understanding in mutual mapping to illustrate the approach’s versatility

The main mchains of a trade company, consisting of one shop, will be "purchase" and "sale" (and a lot of less important ones).

Mpacks (trade goods) move along these two main mchains.

In this case, the "product in a wide sense" corresponds with actual material products (like beer and chocolates).

dia$par Integrator has only one main mchain:

"cybernetic model adaptation".

"Products"-mpacks, which move along this mchain are cybernetic model code fragments, developed by integrator programmers (warehouse, production…) of an organization getting ready for transition to dia$par.

At the entry of mchain there’s "raw material" — a basic configuration of a cybernetic model from the distributive.

At the end of mchain (relevant to the accomplished transition to dia$par) there’s a model, successfully adapted to the necessary level of detail and completeness, which reliably functions in mutual mapping two-sided replication.

While moving along the main mchain, model code fragments pass through msteps like "Brief development", "Testing", etc.

 

V. General IEM test

1. The beginning of section III is wrong.

One-to-one correspondences between the given variety of possible organization statuses and cybernetic model are impossible.

These are "lies-to-children" (T. Pratchett). More precisely — for the sake of convenience.

2. Actually, there are more possible options of dia$par.Matrix model configurations, that can practically correspond to the current status of a certain organization, that there are atoms in the Universe.

However, a lot of obviously correct conclusions (The sun rotates around Earth) turn out to be obviously wrong after a mature deliberation (which doesn’t come easy).

3. Common question — what to go by?

How to configure the right model?

How to figure out that it’s right?

How to compare alternative options?

Or — at least how — to make a conclusion?

We don’t have an answer like "42".
It might not even exist.

However, we have a compass.

4. Since dia$par program systems meet the IEM System requirements, dia$par users can follow versatile, math-based approaches, developed within the IEM Enterprise theory.

Moreover, in terms of searching for the optimal model configuration, as well as detecting possibilities of profitable changes for the organization itself.