IT strategy is one of the functional strategies used to implement the company’s business strategy. When developing an IT strategy, there is often no analysis of the company’s strategic goals, their impact on business processes and systems (business applications, IT architecture), and there is no analysis of the company’s business processes. In a simplified form, the IT strategy reflects the target system map, the current system map, and the action plan for implementing the transition from the current to the target map. Functional strategies are needed to show the impact of functional units (IT, marketing, finance, HR, etc.) on achieving the company’s overall strategic goals.
The article examines a real case, which is not a textbook example to follow, but is interesting in itself as a real practice of developing an IT strategy in a situation where the business strategy is not formalized, but a set of strategic goals and indicators is set, and there is a financial model for the medium term, and nevertheless, the circumstances have developed in such a way that it is necessary to present “up” a conceptual picture of how the company will develop in terms of IT, and what justifies the company’s declared planned investments in IT. The IT strategy should reflect the priorities of the business strategy (this point in this example is implemented as much as possible), and should contain organizational development tasks (the company’s business processes).
At that time, we agreed that the IT strategy should be developed using the classic IBM approach, through the construction and analysis of a component model of the investment and development business, due to the clarity and visibility of the IT development tasks in this approach. What is a component? The answer to this question, an overview and assessment of the CBM (Component Business Model) approach by IBM can be found here at the link . ( CBM, Component Business Model™ is a methodology used to represent a company’s activities as a set of individual business components distributed by business competencies and management (responsibility) levels, for the analysis and identification of improvement and innovation opportunities. ) The methodology is ambiguous, and its ambiguity is associated with the subjectivity of component formation; expert assessments are always subjective. A component is not equal to a business process; for example, in the Sales block, a fairly important process of “bringing an object to market” was omitted. But such moments were recognized as insignificant for the fulfillment of the task at hand – to form the company’s IT strategy.
Within the timeframe and budget, we agreed on a work plan, in which interviewing managers took center stage at the first stage.
It took some time to determine the key starting point — to agree on a common vision of how our investment and development business is structured, what components the business consists of. We had to argue and convince that for an investor-developer in development, tender purchases are one of the key end-to-end business processes, which must be reflected in the component model in an explicit form, etc. We did not build the component model exactly according to the CBM methodology (we did not look for a component at the intersection of competencies and management levels, rather we started from Porter’s value chain). Then, against the background of an agreed map of key business components, we began to work out the expectations of department heads, their wishes, problems, etc. related to IT during interviews.
In subsequent stages of the work, the approach used allowed us to very clearly present the results of interviews with department heads – the expectations of managers from IT, the importance of each component for achieving strategic goals, the potential for automating components and, ultimately, to come to an understanding of the priorities for automating components.
Management expectations of IT – the expectations that IT, across its relevant components, will contribute to the achievement of the three stated strategic objectives.
The visualization is interesting, and possibly useful if the entire team of department heads has a high level of management education, has a common picture of how the strategic process is structured, and works well together to achieve common goals.
The methodology involves measuring subtle things (expectations, significance, etc.), the results of the measurements seem to be informative and clear, but if you dig deeper, there are too many ifs, too many conventions… These points raise doubts about the reliability of the conclusions; when re-discussing expectations/significance, etc., the assessments may change and the whole picture will “float”.
The degree of significance of a business component was expertly determined from the point of view of how much this component contributes explicitly or implicitly to the achievement of the company’s strategic goals. Components with a high level of significance are highlighted in black.
To assess the potential, it is important to know the IT solutions market as a whole and have an idea of the current level of automation in the industry in question (development, construction), understand the level of automation of competitors, and the standard solutions used.
What I want to say… When we interview department heads, each of whom is responsible for their own area, about the business system as a whole, we get a not very expressive picture, a “game of democracy”. The managers’ judgments may not always be based on strategic goals and objectives, factors of the current assessment of the situation may come into play – “it’s already convenient to work, why change anything”, or “we need to change/automate the process, because the quality of the current interaction is not satisfactory”.
Component automation priorities
Coverage of components by automation systems
The final slides were more interesting for the management because they provide a picture on one sheet, which shows all the functional components of the business and the coverage of these components by different systems. Against the background of such maps, it is easier to discuss the company’s medium-term and long-term investments in IT.
The model of interaction of systems is perhaps not the best example of a model. On the slide Model of interaction of systems, criticality and frequency of information flow are rather ephemeral factors, perceived by the management as rather abstract things… And nevertheless, this model of interaction of systems performs a useful and visual function for the management – to show, for example, that the analytical system is necessary in the interests of all interested departments of the company, and if the commercial department “usurped” the analytical system (in this example, Qlick Sense), then this moment provokes additional costs for the creation of another analytical system – a separate analyst administers Qlick Sense in the interests of a separate department (commercial), another system and the resource is allocated for support in the interests of other departments (finance, production, etc.).
An external consultant, Alexander Ch., was engaged to develop this IT strategy. There was an interesting experience of cooperation. But unfortunately, due to the reorganization, it was not possible to implement this strategy in full. The compilation of these models requires quite serious architectural competencies.
Pros: interesting visualization of assessments for IT tasks, visibility of the current state of IT projects, automation of business processes.
Cons: subjectivity of department heads, who may sincerely or supposedly not understand the real benefits of IT in the area of responsibility of their department, weak analysis of competitors in the IT solutions used.
Since this was the first attempt to formulate an IT strategy, the very fact that a systemic document on the prospects for IT development in the company was born, which can be criticized and improved, the main thing is that there is something to push off from, can be considered a success and a value.