Successful Business Transformation within a Russian Information Technology Company

Lead Author: Brian White

This article describes a successful business transformation of an information technology enterprise. The topic may be of particular interest, especially because this transformation was accomplished by a Russian company during the republic’s fast-growing economic recovery.

For addition information, refer to the closely related topics of Enabling Businesses and Enterprises and Enterprise Systems Engineering.

Background

In 2001, the top management of the IBS company in Moscow initiated a fundamental transformation to change the company’s strategy and business model. The company was one of the biggest Russian information technology (IT) systems integrators at that time, with about 900 employees. Annual revenues of about $80M were mainly generated by information technology (IT) infrastructure projects (complex computing systems, multi-service networks, etc.) and hardware and software distribution. The transformation of the company to form new capabilities in IT services and the associated consulting area is the main topic in the case study.

During the transformation period (from 2001 to the present) IBS was represented as a set of autonomous business units (BUs), called constituent systems, which are virtual, independent businesses with the following characteristics:

Profit and loss reporting was required for each BU according to management accounting procedures
BU management established and independently conducted human resources, technology, and product policy
A centralized back-office was organized to provide supporting functions for each BU. Thus, BUs do not have back-offices; they rely on and “pay” a corporate governing center (CGC) for these services.

A thorough enterprise systementerprise system (ES) transformation was executed as a set of activities: mission analysis and capabilities decomposition, business architecting, planning of the project program, and implementation of the new business model.

Before and after transformation IBS was an exemplar directed system of systems (sos)system of systems (sos): the constituent BUs are autonomous but their operations are supervised by CGC. At the same time IBS also has significant features of an acknowledged SoS: the constituent BUs retain their independent development and sustainment approaches, and changes in the company are based on collaboration between the CGC and each constituent; even operations of BUs are not controlled but only supervised/governed by the CGC through “soft” recommendations and coordination.

IBS was a quite mature ES before the transformation, and it was thoroughly upgraded to form new capabilities of the whole system as well as of the constituents.

Purpose

In 2000-2001 IBS management forecasted considerable growth of the Russian IT services and consulting market based on the fast growing Russian economy, which was rapidly recovering from the national financial crisis of 1998. The largest corporations started overseas expansion and borrowed from international markets to finance this growth. IBS predicted corresponding growth in the complexity of business processes and their associated software and hardware systems, all of which should require more consulting and IT services.

Based on this forecast, management established a strategy goal to double the share of IT services and consulting from 25% to 50% over one year; further growth in this business was planned as a long-term trend.

The consulting and IT services business is very complex technologically and organizationally and dramatically differs from IBS’s former infrastructure focus. Thus, a fundamental transformation was required, and it was executed during 2002.

Initially detected problems appeared as expenditures exceeding resources, slow delivery of the projects and reworking. Later, as it was expected, new problems appeared, for example, disinterest of BUs’ managers in developing new technologies or raising qualified employees’ motivation. All those problems were solved during transformation and during further development.

The first step of the transformation included strategic analysis and mission-to-capabilities decomposition. Five major capability groups to be focused on were defined. The groups and exemplar capabilities for each group are represented at Figure 1.

Figure 1. Mission and capabilities desired. (Belov 2014) Reprinted with permission of Taylor and Francis, New York, NY. All other rights are reserved by the copyright owner.

Challenges

All main challenges were caused by knowledge/information deficit described by three factors listed as a, b, and c below.

a. The lack of experience in enterprise transformation (and capability-based approaches, even the lack of any textbooks or guides in those areas) was the major challenge which IBS management faced. The task to be solved did not devolve to organizational changes (which was a well-developed and described area), but was appropriately allocated to enterprise systementerprise system or system of systems (SoS)system of systems (SoS) engineering. In spite of the lack of experience, it was decided to prepare and execute the transformation based on the company’s employees without involving external consultants. The following arguments supported the decision.

The task to be solved was not typical, so there weren’t widely used and well tested algorithms or methods, and there weren’t a lot of consultants experienced in exactly what was needed. So only consultants with general experience (strategy consulting, organizational management) might be hired.
The Russian consulting industry in 2001-2002 was not well developed, so only foreign professionals were available. But foreign consultants would have needed to study Russian specifics; such study would have unduly lengthened the duration and increased the cost of the transformation.
A joint transformation team would have to be formed, and IBS employees would have to be involved: management would have to be interviewed and be involved in decision making. In any case, all employees would have to participate in change implementations.
External consultants are not stakeholders; so their level of interest in helping to achieve success might not be very high, and their output also might not be outstanding.
Unwillingness to open professional secrets and other intellectual property issues to direct competitors were other factors that prevented hiring of external consultants.

Thus, the final decision was to execute the transformation without involvement of external consulting resources. A special BoU responsible for business processes development was established and an agileagile program management approach was applied to handle challenges and to pursue opportunities as well as to mitigate risks.

b. A very high complexity IBS as an enterprise system or SoS. Management recognized that the company and its environment was very complex, with many different agents, many constituents, and countless relationships; and that an enterprise system or SoS might become even more complex after transformation. This complexification happened as the company became an “extended enterprise,” the governing hierarchies weakened, and the demand for more sophisticated relationships increased.

c. The risk of mistaken forecast of IT market development. The expected growth of the consulting and services market might have not happened. In this case the transformation would have been senseless. This challenge generated additional emotional stress for management.

Systems Engineering Practices

The SE task of the transformation was established in the form: to develop required capabilities for an enterprise system or SoS – IBS company. The SE process might be represented by the following specific IBS interpretation of the vee (v) modelvee (v) model (“V model”) with Stages 1 through 7 (Figure 2).

Initially (Stage 1) the mission was translated to capabilities (Figure 1); “understanding the constituent systems (BUs) and their relationships” was executed. The transformation team found that capabilities might not be directly translated to any business-agent. Neither BUs (they serve as resource pools), nor projects (being temporal elements), nor employees (each of them have a finite set of skills, experience, responsibilities, etc.) might realize necessary capabilities.

Realizing this (Stage 2) transformation team defined several key areas (Figure 2) of company’s operations or activities which were supposed to be changed to form new capabilities. Appropriate artifacts (procedures, guides, documents, software systems) to support new capabilities were developed and implemented for each of the areas; these new assets formed exactly the corporate infrastructure of new business model.

Figure 2. “V model” of the systems engineering process of the transformation. (Belov 2014) Reprinted with permission of Taylor and Francis, New York, NY. All other rights are reserved by the copyright owner..

For each new and legacy system (Stage 3), a set of conceptual design documents was developed, describing approaches, polices, processes, and procedures. The entire set of documents formed the business architecture description of the company. The description connected all key areas and defined a target operation model of the company after transformation. This architecture represented multiple views of the IBS company, and thus aptly reflected its enterprise system or SoS nature.

Somewhat in contrast with the conventional linear systems engineering approach advocated by the V model, Stages 4-6 were conducted in parallel to save time and resources. The company’s performance (Stage 7) should be monitored based on indicators’ measurements, and improvements should be developed and implemented (arrows from Stage 3 to Stage 7). Such iterations have been executed in practice not only during transformation but also later, when procedures, guides and the whole systems were updated.

Integration and interoperability of the new systems required a thorough integration of parallel development jobs. So joint workgroups were formed of the employees at the level of low officers; and CGC played the role of integrated workgroup at the management level. Actually, multi-level integrated workgroups were formed.

The major complexity and risks derived from the challenges described above.

The transformation team developed and used an approach which is very similar to the agile development approach to address those risks. The following principles were used to manage the portfolio of projects in case of uncertainty and deficit of knowledge.

Form solutions as fast as possible (but not necessarily with pure quality) to test them in practice faster.
Recognizing failures are unavoidable, perceive them readily and react rationally.
In case of failure, analyze the situation and find a new solution, generate changes, and update the plan.
Work in parallel, verifying and coordinating intermediate results.
The schedule might be corrected and updated but should not be jeopardized by improper execution.
Formulate and test the most critical and most questionable solutions at first.
Start from pilot area and then expand to embrace the entire scope.
Use high quality monitoring and a “manual control mode” for piloting and testing developing solutions but not additional aspects to limit waste of the resources.

Following those principles, including a very strong discipline of execution, a high level of the sponsorship and all-employee involvement enabled the transformation to be completed on time without hiring consultants while keeping and developing on-going business.

Lessons Learned

IBS’s accomplishment of the mission was the major result of ES transformation. Shareholders and management recognized that new capabilities had been formed, that the company could deliver consulting and services, sell and execute complex projects, manage consulting resources effectively, measure its performance, and plan and forecast financial results. Created capabilities are emergent in some sense because they are not directly related to concrete constituents (BUs, or employee, or projects) but are realized by means of integrated end-to-end processes and functions, which are executed in the projects by employees.

The systems organization did not dramatically change during transformation; “visible structure” was not practically changed: no new types of business-agents appeared, existing types did not change much. Those factors did not create new capabilities. Target capabilities were formed as the result of development and implementation of, it would seem, auxiliary and supporting tools – new capabilities support systems. New capabilities were formed mainly by the changes in the intangible areas of governing media, corporate culture, relations, and personnel competences; as well as by the creation of new capabilities support systems; without considerable changes in main company’s business-agents. (Refer to Figure 3.)

The main challenges which management faced (the lack of experience and the ambiguity of market growth forecast) made the uncertainty factor the critical one in the transformation.

What Worked and Why?

An agile program management in general demonstrated its efficiency and applicability to “soft and uncertain” tasks, especially in triggering a pre-established process for dealing with unexpected events; the main aspects of the approach are:

Senior and credible sponsors
Multi-level integrated project team(s)
Open information exchange
Partnership and collaboration
Proactive and motivated parties and constituents
Creative and innovative way of development

Figure 3. The results of transformation. (Belov 2014) Reprinted with permission of Taylor and Francis, New York, NY. All other rights are reserved by the copyright owner.

Prioritizing and focusing on the most ambiguous elements of systems design
Piloting and subsequent roll-out in realistic environments
Strong project scope control
Strong project execution control – time schedule and resources control.

What Did Not Work and Why?

Perhaps corporate knowledge base development was the only more or less serious task which was not solved in transformation. The company’s management understood the usefulness of knowledge accumulation and further alienation from the carriers in utilizing their business knowledge, so the goal of developing their own knowledge base was established. Special database and software systems were developed with appropriate guides, reports and data collection forms; but formal regulation to fill in engineering knowledge accumulation templates did not work. However, this issue later progressed quite naturally and simply: common folders were established to store project data in free formats. Such folders served to accumulate knowledge but in flat, unstructured form.

Best Practices and Replication Prospects

The following methods and approaches were proven as efficient and convenient in transformation.

Capability-based development approach and capability-based architecting might be recommended to be utilized in creation and transformation of an enterprise system or SoS. These focused all efforts on the required capabilities and involved very important relations from mission to capabilities and to functions in the systems engineering process.
An agile program management might be used to solve a wide range of fuzzy and ambiguous problems of different scale in the areas of SE, ES engineering, and SoS engineering where there is much uncertainty and lack of expertise and proven methods or algorithms to solve them. The combination of “soft” and very creative designs with strong planning and progress control is the crucial foundation of this approach.
Key area definition and development appropriate to generating new capabilities for support systems (core consulting and services technologies, project implementation systems, systems for business unit growth, management accounting systems, motivation systems). Precisely defining these areas and developing integrated systems in these areas might be considered as quite common for application to a broader group of ESs.

References

Works Cited

Belov, M. 2014. "IBS Group, Eastern European ITS Services – Capability-Based Development for Business Transformation," in Case Studies in System of Systems, Enterprise Systems, and Complex Systems Engineering, A. Gorod et al., (Eds.). Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.

Primary References

Belov, M. 2014. “IBS Group, Eastern European ITS Services – Capability-Based Development for Business Transformation.” Case Studies in System of Systems, Enterprise Systems, and Complex Systems Engineering. Gorod, A., B. E. White, V. Ireland, S. J. Gandhi, and B. J. Sauser, (Eds.). Boca Raton, FL: CRC Press, Taylor & Francis Group. Scheduled for publication in July 2014. http://www.taylorandfrancis.com/books/details/9781466502390/.