Any management textbook says that each and every company must be ready to change. The majority of business leaders probably do their best to understand and adhere to this principle. But few think of a company as a complex socio-technical system, and the development of a complex system requires specialist knowledge and skills. Unfortunately, many of today’s top managers do not even know of the existence of an activity such as organizational development. And this is perhaps the nub of the problem, because until these managers understand precisely what organizational development is, the vast majority of business problems will remain unsolved. Of course, understanding is not sufficient in itself to create change. It is only the beginning, and a lot of hard work remains.
Organizational development is an activity intended to develop and thereby improve a company. Many people think it is a poorly formalized activity, something involving intuition and the «right» people. In this article, I will do my best to debunk this myth.
A company is a complex structure that comprises three main systems:
- An operating system for the production, sale and delivery of a product to the consumer.
- A service system to ensure that the operating system remains functional.
- A development system, the purpose of which is to design products and create new operating and service systems or, in other words, to actively develop the organization — to undertake organizational development.
Figure 1. The structure of a company as a complex system
One of the main features of organizational development is the need to design in triplicate: the product (as a separate system, and sometimes quite a complex one), an operating system to support this product, and a service system to support the operating system.
ORGANIZATIONAL DEVELOPMENT
Taking these preliminary remarks into account, we are able to list exactly which functions should be included in organizational development:
- Drafting a set of requirements.
- Creation of a business model and a development plan.
- Product development.
- Design business architecture.
- Creation or modification of operating and maintenance systems.
Let’s take a closer look at each of these.
1. Drafting a set of requirements
A stakeholder, interested party or involved party is an individual or organization that has rights, shares or interest in a system, or the parts thereof, that satisfy their needs or expectations.
Drafting a set of requirements is a way of formalizing the wishes, explicit and implicit, that a stakeholder may have in respect of a product or an operating and maintenance systems, and enables these requirements to be included in the design of the respective entities.
Here are some examples of stakeholders:
- Product requirements are mainly a reflection of the wishes of the customer, although in some cases (for example, with food), government regulators may also be a major stakeholder.
- Owners normally have requirements in terms of the performance (profit is one possible example) and reliability of their business systems. Government regulators may set requirements for operating and maintenance systems to ensure they meet industrial and environmental safety specifications.
In order to define such requirements, environmental and customer needs are analyzed. External environment analyses are primarily aimed at studying the markets (customers, technologies, suppliers), identifying competitors, and tracking changes in legislation. In the case of global enterprises, these can also include the forecasting of government policies and demographics. Customer needs analyses include collecting comments and suggestions from existing customers and clarifying the needs of potential customers.
The requirements for operating and maintenance systems may result from analyses of the effectiveness of the company’s internal activities. These include:
- Conclusions as to whether the operating and maintenance systems are achieving the required levels of performance;
- Benchmarking with other companies;
- Collecting comments and suggestions from employees (corresponds to the practice of involving personnel in the methodology in lean manufacturing).
Problems and variations in the way systems are operating may also be transformed into requirements that are normally taken into account in the next design cycle and often result in changes to the architecture of operating and maintenance systems (hereinafter the business architecture). Unlike external environmental analysis, which may not be affordable for all companies, internal performance analysis and customer needs analysis are required in every company.
Addressing the needs of stakeholders and collecting the ideas and suggestions of employees are ongoing activities, and the requirements ensuing from these sources can be significant. Unfortunately, it is rarely possible to implement all of them, and it is therefore important to prioritize. Employees engaged in prioritization must not only have a good understanding of customer needs but also be aware of the current state of the company in order to make decisions as to what needs to be implemented immediately and what can wait. Another important factor is that many requirements may relate to one and the same element of the system: e.g. a department, business process or IT system. And the implementation of even one requirement may involve a significant increase in overheads: system reconfiguration, employee training, approbation, etc. So it often makes sense to accumulate the requirements relating to a given element of the system and refer them for implementation in batches. This not only saves on overheads and labor, but also cut the unnecessary stress caused to employees by a constant stream of changes.
2. Creation of a business model and a development plan
Business models show how a business is going to make money. A good example of a simple business model is Osterwalder’s business model canvas. It captures consumer segments, sales distribution channels, value propositions, key activities, key resources, and other important components.
Figure 2. Example of the Daimler’s Activity Model from Business Model Generation by A. Osterwalder and Yves Pignet
One of the most drastic ways of satisfying a company’s accumulated requirements would be the development or correction of its business model. This could happen when the requirements are so substantial that they cannot be met by simply making minor adjustments to current products or optimizing the existing business architecture.
In many ways, a company’s business model is its business architecture concept. Development of the business architecture concept is an important step in the design of any complex corporate system, since it is the business architecture which ultimately allows decisions to be made on how requirements can be met without a detailed (and therefore time-consuming and expensive) design of all system components. Usually, several alternative business models are developed prior to selecting the most favorable one based on key measures (economic ones included). The concepts and requirements formulated during the business model development process are then transferred for more detailed study to the Product Development department.
It should be pointed out that the fate of the entire business may well depend on the quality of development of the business model, since mistakes made in the business model can rarely be rectified during the later stages of organizational development. Even the most effective business architecture cannot correct mistakes made at the time of choosing a product or selecting a particular sales channel.
If adjustments have to be made to the business model, then it is very probable that the company is set to face major changes. These might include designing new products, redesigning business architecture and, of course, implementing real-life changes. It can take long periods of time, e.g. 2 or 3 years. A company development plan is usually used to ensure that the works are completed on time.
3. Product development
These procedures include product design. Ultimately, product design is the detailed description of a product in terms of its construction, consumer properties, and means of manufacture. Typically, products are designed somewhat in advance of their respective business architecture, because the product itself and its manufacturing technology will also impose requirements on the business architecture (for example, on the equipment to be used for its production, transportation and storage).
The product development function has two main «branches». One of these deals with ongoing improvements to existing products. The other deals with the development of new products based on their concept and new product requirements.
4. Design business architecture
Business architecture design is carried out for the purposes of designing (describing) operating and maintenance systems. Business architecture design is capable of describing a company with the precision needed to bring it to life. It incorporates a wide range of activity models (models of functions, business processes), models of corporate organizational structure, functional objects, means of production and information systems. This is the most time-consuming stage of the entire organizational development process. Those costs will however be recovered, for careful work at the business architecture design stage means eliminating errors in the organization of company activity. Many business leaders are somewhat dismissive of the business architecture design function. They believe that once an objective has been defined, employees themselves will find a way of achieving and formalizing it to the extent of their abilities. And yes, this does happen. But only in a limited number of situations, for example, in small companies staffed by very able and resourceful employees. Another misconception is that somehow the required technology will sooner or later come about by itself or be developed in a process of trial and error. More often than not, this does not happen, and even where it does, the expenditure of resources necessary to correct the errors is too high.
5. Creation or modification of operating and maintenance systems
This is the last stage of the organizational development process and therefore the stage at which the business architecture project becomes reality. Depending on the number of staff and means of production included in the design, the following will take place at this stage:
- Selection (or rotation) and training of employees.
- Purchasing or manufacture of the means of production.
- Implement an information system.
- Assembly of all components into a single system.
In an already existing company, this stage will involve rebuilding of only some of its parts. In a new company, this stage will see the company created from scratch.
It is rarely possible to successfully create a complex system at the first try. The plans must therefore include a developed technology approval stage and a way of refining the final business architecture design.
Note 1
Despite having already presented the various stages of organizational development and the cause-and-effect relationships between them as some kind of ordered, linear progression, it would be quite wrong to assume that, in real life, these invariably take place one after the other. Since time is such a valuable resource, in practice it makes sense to do as much of the work in parallel as possible. For example, the business architecture design stage can actually begin before the product development stage has been completed. A degree of back-tracking from later to earlier stages invariably takes place. For example, if it were not possible to implement some of the business architecture requirements, it may be necessary to go back, rethink the business model or even make alterations to the requirements themselves.
Note 2
It should be noted that in design companies, it is rarely a specific one-off product that is being developed in the course of organizational development, but rather an entire class of products that the business system must be capable of producing. In the above case, it is for the class of products that the operating system must be constructed and the means of production selected. When accepting customer orders, the properties of a specific product are already defined in the context of the company’s operational activities.
Note 3
The organizational development structure should not be thought of as a rigid framework into which every individual company case should somehow fit. Companies tend to have their own nuances that should be taken into account when structuring the various organizational development functions.
How often does organizational development need to happen?
If we return to our opening premise — i.e. that each and every company must be ready to change — the question that comes begging is how often? I believe that in the current business environment, a company must be ready to change continuously. This does not, of course, mean that changes must occur daily, or that an entire company must be completely rebuilt. Such a concept may actually be desirable, but it is doubtful that the people working in the company would be able to cope with it. And so it makes much more sense to somehow accumulate requirements, form them into batches, and implement them periodically (the practice of maintaining a backlog in SCRUM). Some batches will be global — and therefore enjoy a longer implementation period — while others will be of an operational nature and implemented more frequently. Examples of global batches include the creation of new products, changing distribution channels, entering new consumer segments. Examples of operational batches include ongoing product development that does not require changes to the business model, improvements made to operating and maintenance systems. The operational batch approach is rather similar in nature to the Agile system development methodology of continuous small change.
Who should carry out organizational development?
Here, we shall look at two opposing points of view (and of course, many alternative options exist between those poles). Some experts believe that a separate department should be set up in each and every company to carry out business architecture design for all functions of the organization. These experts justify their opinion by pointing out that top and middle managers rarely possess the necessary special competencies that would allow them to successfully play the role of the business architect, i.e. the design engineer of their given business activity. Whilst this opinion carries some weight, it should be remembered that the maintenance of such a department would be a major cost center, since such a function would need to employ highly-qualified specialists with extensive experience in the organizing of activities in a wide range of subject areas.
We believe that involving management in the design of the business architecture system is essential for any company wishing to become successful. First and foremost, it is unreasonable to expert managers to be effective if they are not given the power to change the technology of their activity, i.e. to become business architects. Managers must be given direct responsibility for the efficiency and development of the activities entrusted to them. It therefore follows that:
- Each and every working day, at least for a percentage of the time, the manager must play the role of a business architect.
- The company must have an ongoing system of incentives for managers, which should be focused on company development.
In order to coordinate organizational development activities, companies must at least create an organizational development unit (depending on the size of the company, this might be a single office, a department or an entire section), the head of which must be capable of performing at least two roles:
- Chief business architect responsible for the overall business architecture of the entire company;
- Chief methodologist responsible for all aspects of organizational development methodology.
In small companies (and sometimes even in large organizations), the role of the chief business architect can be taken on by the head of the company.
Organizational development departments should also have a business analyst whose responsibility is to support managers in the tooling and procedural aspects of business architecture design. In order to ensure that long-term and large-scale development projects are implemented on time, organizational development departments must have access to managers responsible for project time and financial properties planning.
Figure 3. Organizational development structure
We have now come to the end of our review of organizational development activities and their implementation. We have shown that organizational development is a tangible activity with clear boundaries. As such, organizational development can be implemented in any company without the need to employ superheroes. In conclusion, I would like to point out that sadly, the business world of today is heavy with competition and crisis, and it is important that managers move quickly to grasp the essence of organizational development. No one needs to look far to see examples of companies becoming insolvent and shutting down, or of unsuccessful companies being taken over by successful ones. And since many companies do not operate with even the minimum margin of safety, such examples can become widespread during downturns in the economy.
Attachment. Organizational development activity diagram
January 2022
Share