Successful Business Transformation within a Russian Information Technology Company
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 based 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 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 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) : 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.
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 system or 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 agile 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 system of systems (sos) . Management recognized that the company and its environment was very complex, with a lot different agents, many constituents, and countless relationships; and that an enterprise system or system of systems (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 system of systems (sos) – IBS company. The SE process might be represented by the following specific IBS interpretation of the vee (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 serves 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.
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 system of systems (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
- 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 system were developed with appropriate guides, reports and data collection forms; but formal regulation to fill in engineering knowledge accumulation templates did not work. However later this issue 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 system of systems (sos) . These focused all efforts on the required capabilities and involved very important relations from mission to capabilities and to functions in systems engineering process.
- Agile-stylized 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, System of Systems (SoS)(glossary) engineering where there is much uncertainty and lacks 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.” 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. Boca Raton, FL: CRC Press, Taylor & Francis Group. Scheduled for publication in July 2014. http://www.taylorandfrancis.com/books/details/9781466502390/. Accessed 29 March 2014.
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. Boca Raton, FL: CRC Press, Taylor & Francis Group. Scheduled for publication in July 2014. http://www.taylorandfrancis.com/books/details/9781466502390/. Accessed 29 March 2014.
Additional References
None
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus