Ключевые ит отношения в бизнесе это

Сегодня информационные технологии (ИТ) являются неотъемлемой частью большинства предприятий. Все заметнее становится движение от модели «ИТ – поддержка бизнес-операций» к модели «ИТ – бизнес-партнер»: появляются новые модели ведения бизнеса, которые активно используют информационные технологии для предоставления клиентам услуг более высокого качества. ИТ все глубже проникают в деятельность организаций и становятся важным стратегическим активом, которым необходимо управлять

• Каково текущее состояние ИТ в организации?
• Целевое состояние ИТ в организации: где мы хотим оказаться?
• Каковы пути достижения целевого состояния ИТ в организации?

Gartner рекомендует для разработки ИТ стратегии использовать два ключевых инструмента: архитектуру предприятия и финансовые инструменты [13]. Разработка ИТ стратегии ведется на основе формирования и анализа расхождений между существующим состоянием ИТ в организации и целевым состоянием, при котором ИТ соответствуют требованиям состороны бизнеса с учетом перспектив его развития.

Партнерские отношения в бизнесе | Как избежать конфликтов | О чем договориться в первую очередь

На рис. 1 изображено место архитектуры предприятия в контексте стратегического управления ИТ в организации [9]. На самом верху иерархии управления находятся миссия, видение и стратегия организации, которые определяют «образ будущего» и путь, по которому предприятие будет продвигаться для достижения указанного видения и выполнения миссии. Указанная стратегия транслируется в конкретные стратегические цели, которые задают направления развития и указывают основные вехи на пути реализации стратегии.

Рисунок 1. Архитектура предприятия как инструмент стратегического управления ИТ

Архитектура предприятия появляется на этапе формирования набора мероприятий, которые необходимо выполнить для достижения стратегических целей. Описывая различные аспекты организации, архитектура предприятия создает целостное представление о ней и служит основой для описания как бизнеса и ИТ по отдельности, так и связей между ними, атакже для анализа этих связей и оценки воздействия изменений как со стороны бизнеса, так и со стороны ИТ [8].

Планирование архитектурных преобразований, как правило, подразумевает выполнение следующих пяти шагов [11]:

1. Моделирование текущего состояния архитектуры предприятия – базовой архитектуры.
2. Моделирование целевой архитектуры предприятия.
3. Сравнение базовой и целевой архитектур предприятия и выявление различий (GAP-анализ).
4. Создание архитектурной дорожной карты на основе данных GAP анализа.
5. Планирование проектов изменений в соответствии с архитектурной дорожной картой.

Согласно рекомендациям Gartner [13] моделирование базовой и целевой архитектур целесообразно производить на достаточно высоком уровне (не подробнее концептуального уровня). Важно отметить, что при формировании целевой архитектуры и разработке плана проектов обязательно необходимо учитывать требования к ИТ со стороны бизнеса ивнутренние и внешние ограничения, что уменьшает количество возможных вариантов перехода к целевой архитектуре [8]. Таким образом, в рамках разработки ИТ стратегии модели архитектуры предприятия позволяют на основе стратегических целей ИТ разработать цельный план скоординированных проектов, которые обеспечивают последовательный переход от существующей архитектуры к целевой [3].

Как вести бизнес с партнером: четыре ключевых правила

Стратегическое выравнивание бизнеса и ИТ: архитектурный подход

Модель стратегического выравнивания бизнеса и ИТ

Важным аспектом разработки ИТ стратегии является необходимость достижения высокого уровня соответствия возможностей ИТ потребностям и ожиданиям бизнеса. По мнению Дж.

Хендерсона и Н. Венкатрамана, неспособность извлекать выгоду из инвестиций в ИТ связана, во первых, с отсутствием соответствия между бизнес стратегией и ИТ стратегией и, во вторых, с отсутствием динамического процесса, обеспечивающего непрерывное выравнивание бизнеса и ИТ [3]. Для достижения высокой степени соответствия между бизнесом и ИТ они предложили использовать модель стратегического выравнивания SAM (Strategic Alignment Model). Данная модель позволяет анализировать связи между областями бизнеса и ИТ как на стратегическом уровне, так и на операционном. Основные элементы модели SAM изображены на рис. 2.

Рисунок 2. Модель стратегического выравнивания

Модель SAM выделяет в бизнес стратегии и ИТ стратегии по две области, которые рассматривают аспекты, относящиеся к внутренней или внешней для организации среде.

Так, домен бизнес стратегия описывает позицию организации во внешней конкурентной среде: как организация себя позиционирует на рынке, что может предложить клиентам, какими конкурентными преимуществами обладает, в каких партнерских отношениях состоит и т.д. Домен организационная инфраструктура и процессы описывает решения, которые определяют организационную структуру, важнейшие бизнес-процессы, а также решения, связанные с приобретением и развитием навыков, необходимых для получения требуемых организационных компетенций.

Аналогично с областью бизнес стратегии ИТ стратегия описывает позицию организации на внешнем рынке ИТ: какие технологии поддерживают текущие или могут сформировать новые бизнес инициативы, какие конкурентные преимущества (например, надежность системы, гибкость, соотношение затрат и производительности) могут внести позитивный вклад в поддержку текущей или в создание новой бизнес стратегии, каким образом организация будет приобретать необходимые ИТ компетенции и т.д. Область ИТ инфраструктура и процессы, в свою очередь, описывает решения, которые определяют системную архитектуру и ключевые ИТ процессы, а также решения, связанные с приобретением и развитием знаний, необходимых для эффективного управления технической инфраструктурой в рамках организации.

Между доменами модели SAM выделяют два основных типа связей: стратегическое соответствие указывает на необходимость при разработке любой стратегии учитывать аспекты как внутреннего домена, так и внешнего, а функциональная интеграция отражает то, каким образом решения, принятые в области ИТ, воздействуют на решения, принимаемые вобласти бизнеса, и наоборот. Функциональная интеграция между бизнесом и ИТ происходит на двух уровнях: стратегическая интеграция отражает способность ИТ стратегии изменять и поддерживать бизнес стратегию; операционная интеграция подчеркивает критичность обеспечения внутренней согласованности между организационными требованиями и возможностями ИТ.

Перспективы стратегического выравнивания бизнеса и ИТ

Основная критика модели SAM сводится к тому, что она определяет, «что» необходимо делать для выравнивания бизнеса и ИТ, но не указывает «как» это делать [14], т.к. непредлагает конкретных методов выравнивания бизнеса и ИТ. Однако на основе связей между рассмотренными доменами модели SAM авторы модели выделили четыре общих направления или перспективы стратегического выравнивания бизнеса и ИТ [2], которые схематически изображены стрелками 1-4 на рис. 3.

Рисунок 3. Перспективы стратегического выравнивания бизнеса и ИТ

В зависимости от того, какие перспективы используются для выравнивания бизнеса и ИТ, может определяться роль ИТ службы в организации [8].

Например, в перспективе Исполнение стратегии (стрелка 1 на рис. 3) ИТ в организации играет роль центра затрат и не рассматривается в качестве источника конкурентных преимуществ, поэтому в качестве показателя эффективности выравнивания бизнеса и ИТ здесь выступают суммарные затраты на ИТ – чем дешевле, тем лучше.

Перспектива Уровень услуг (стрелка 2 на рис. 3) концентрируется на том, как построить ИТ организацию мирового класса в пределах организации, где ИТ служба выполняет роль поставщика услуг для бизнеса, поэтому наиболее важной становится операционная эффективность ИТ службы.

Использование перспективы Технологический потенциал (стрелка 3 на рис. 3) позволяет взглянуть на ИТ службу в организации как на бизнес партнера, который позволяет реализовать выбранную бизнес стратегию с помощью ИТ, следовательно, наиболее важным показателем эффективности ИТ службы в этом случае является вклад ИТ в добавленную стоимость.

Наконец, перспектива Конкурентный потенциал (стрелка 4 на рис. 3) фокусируется на возможности преобразования бизнес стратегии за счет использования новых возможностей ИТ для приобретения конкурентных преимуществ и предоставления новых продуктов и услуг, а критерии эффективности ИТ службы часто основаны на качественных иколичественных характеристиках, относящихся к лидерству на рынке (например, доля рынка, инновационность продукции).

Оценка зрелости стратегического выравнивания бизнеса и ИТ

Еще одним недостатком модели SAM является то, что она не позволяет оценить качество выравнивания бизнеса и ИТ. Для решения этой проблемы Дж. Лафтмэн разработал модель оценки зрелости стратегического выравнивания бизнеса и ИТ SAMM (Strategic Alignment Maturity Model) [15]. Хотя данная модель и является достаточно общей, при необходимости она может быть адаптирована под конкретную организацию или отрасль для учета их особенностей.

В модели SAMM предлагается пять уровней зрелости стратегического выравнивания бизнеса и ИТ – чем выше уровень зрелости стратегического выравнивания, тем лучше гармонизированы стратегии бизнеса и ИТ:

1. Начальный/неопределенный уровень (Initial/Ad Hoc Process).
2. Повторяемый (Committed Process).
3. Определенный (Established Focused Process).
4. Управляемый (Improved/Managed Process).
5. Оптимизируемый (Optimized Process).

Процесс оценки зрелости стратегического выравнивания бизнеса и ИТ предполагает проведение анкетирования руководителей организации различного уровня.

Оценка зрелости стратегического выравнивания бизнеса и ИТ производится по шести критериям, каждый из которых связан с определенным доменом модели SAM, что позволяет идентифицировать слабые места в текущем состоянии ИТ в организации [16]:

• зрелость коммуникаций между ИТ и бизнесом;
• зрелость оценки вклада ИТ в создание ценности;
• зрелость управления ИТ;
• зрелость отношений между бизнесом и ИТ;
• уровень охвата ИТ и зрелость архитектуры;
• зрелость процессов управления знаниями.

Каждый из указанных критериев и уровней зрелости выравнивания описывается набором атрибутов или качеств, которые могут быть оценены по шкале, представленной в таблице1. Данные качества характеризуют компании, в которых процесс стратегического выравнивания бизнеса и ИТ является достаточно зрелым, поэтому в анкете предлагается указать соответствие предложенного качества оцениваемой организации по шкале от «1 – полностью не соответствует» до «5 – полностью соответствует организации».

Полный перечень атрибутов выравнивания, методика определения уровня зрелости на основе оценок атрибутов могут быть найдены в работе [15].

Применение архитектуры предприятия в качестве инструмента стратегического выравнивания бизнеса и ИТ

Несмотря на то что модель SAM не предлагает использовать какие-либо конкретные инструменты для описания выравниваемых областей и связей между ними, на практике дляэтого часто используются методы и модели архитектуры предприятия [8, 9, 17].

На основе результатов исследования [18] можно утверждать, что все домены модели SAM и связи между ними могут быть смоделированы в рамках архитектуры предприятия, аполученные модели могут быть проанализированы с использованием четырех основных перспектив стратегического выравнивания, в результате чего может быть сформирована целевая архитектура предприятия. Так, например, в IAF (Integrated Architecture Framework) [19] «бизнес стратегия» и «ИТ стратегия» моделируются на контекстуальном иконцептуальном уровнях бизнес архитектуры и системной архитектуры соответственно, а «организационная инфраструктура» и «ИТ инфраструктура» – на логическом и физическом уровнях.

Впервые архитектурный подход к выравниванию бизнеса и ИТ был предложен в работе [20], где утверждалось, что планирование архитектуры информационной системы является стратегически важной задачей, т.к. помогает достичь высокого уровня соответствия возможностей информационной системы потребностям бизнеса. Результаты недавнего исследования [21], в рамках которого был проведен глобальный опрос среди 236 респондентов из 60 стран, подтверждают тезис о том, что использование архитектуры предприятия позволяет повысить уровень зрелости процесса выравнивания в среднем на один-два уровня: с начального (1) и повторяемого (2) до определенного (3) или управляемого (4).

Похожие результаты демонстрирует другое исследование [22], в рамках которого проводился анализ публикаций с целью выяснить, какие выгоды ожидаются от использования архитектуры предприятия для стратегического управления ИТ в организации и какие выгоды действительно получается извлечь. В качестве наиболее реализуемых выгод авторы выделяют повышение качества принятия решений, улучшение структуры бизнеса, уменьшение сложности систем и комплексное понимание предприятия. Также в работе акцентируется внимание на том, что достижение высокой степени выравнивания возможно только в том случае, если в процесс разработки целевой архитектуры, кроме руководителя ИТ службы, вовлечены как высшее руководство, так и руководители других функциональных подразделений, обеспечивая таким образом целостный взгляд на все предприятие.

Дж. Росс и соавторы в работе [17] на основании исследований более 1500 фирм в США также утверждают, что использование архитектуры предприятия в качестве основы длявыравнивания бизнеса и ИТ позволяет существенно сократить несоответствия между ними, однако такой подход требует высокой степени вовлеченности руководства организации впроцесс формирования целевой архитектуры.

В настоящей работе были рассмотрены основные понятия, методы и модели, которые используются для выравнивания бизнеса и ИТ с использованием архитектуры предприятия, изучены связи рассмотренных моделей с архитектурой предприятия.

Кроме этого, рассмотрены результаты зарубежных исследований о роли архитектуры предприятия в стратегическом выравнивании бизнеса и ИТ. Установлено, что использование архитектуры предприятия для стратегического выравнивания бизнеса и ИТ обычно приводит к повышению качества такого выравнивания, но это требует высокого уровня вовлеченности руководства в планирование будущего состояния ИТ организации.

В качестве дальнейшей работы планируется адаптировать модель оценки зрелости стратегического выравнивания SAMM таким образом, чтобы она могла учитывать особенности российских финансовых организаций.

1. E. Overby, A. Bharadwaj and V. Sambamurthy. Enterprise agility and the enabling role of information technology, European Journal of Information Systems, vol. 15, no. 2, pp. 120-131,2006.
2. J. Henderson and N. Venkatraman. Strategic Alignment: Leveraging information technology for transforming organizations, IBM Systems Journal, vol. 32, no. 1, pp. 4-16, 1993.
3. А. Данилин и А. Слюсаренко. Архитектура и стратегия. Инь и ян информационных технологий. – М.: Интернет-университет информационных технологий, 2005.
4. J. Zachman,. A framework for information systems architecture, IBM Systems Journal, vol. 26, no. 3, pp. 276-292, 1987.
5. J. Sowa and J. Zachman. Extending and formalizing the framework for information systems architecture, IBM SYSTEMS JOURNAL, vol. 31, no. 3, pp. 590-616, 1992.
6. J. Zachman. THE FRAMEWORK FOR ENTERPRISE ARCHITECTURE: Background, Description and Utility – EIM Institute, June 2007. [Online]. Available: http://www.eiminstitute.org/library/eimi-archives/volume-1-issue-4-june-2007-edition/the-framework-for-enterprise-architecture-background-description-and-utility. [Accessed 04 092016].
7. The Open Group, TOGAF® 9.1, 2011. [Online]. Available: http://pubs.opengroup.org/architecture/togaf9-doc/arch. [Accessed 2016 09 04].
8. I. Hanschke. Strategic IT Management. A Toolkit for Enterprise Architecture Management. Springer-Verlag Berlin Heidelberg, 2010.
9. M. Lankhorst. Enterprise Architecture at Work: Modelling, Communication and Analysis. 3rd ed., Springer-Verlag Berlin Heidelberg, 2013.
10. А. А. Томпсон-мл., М. Питереф, Д. Гэмбл и А. Д. Стрикленд III. Стратегический менеджмент: создание конкурентного преимущества. – 19-е изд./пер. с англ. – М.: ООО «И.Д. Вильямс», 2015.
11. Р. Васильев, Г. Калянов, Г. Левочкина и О. Лукинова. Стратегическое управление информационными системами/ учебник, ред. Г. Калянов. – М.: Интернет-университет информационных технологий: БИНОМ. Лаборатория знаний, 2014.
12. А.М. Михайлов. 7 подходов к разработке ИТ-стратегии. // «Директор информационной службы», №2, 2004. – С.48-52.
13. Gartner. Six Building Blocks for Creating Real IT Strategies, R-17-3607, 2002.
14. J. Luftman and T. Brier. Achieving and Sustaining Business-IT Alignment, California Management Review, no. 1, pp. 109-122, 1999.
15. J. Luftman. Assessing Business-IT Alignment Maturity, Communications of the Association for Information Systems, vol. 4 Article 14, 2000.
16. J. Luftman, R. Papp and T. Brier. Enablers and Inhibitors of Business-IT Alignment, Communications of the Association for Information Systems, vol. 1 Article 11, 1999.
17. J. Ross, P. Weill and D. Robertson. Enterprise Architecture as Strategy. Creating a foundation for business execution. Boston, Massachusetts: Harvard Business School Press, 2006.
18. L. Cuenca, A. Boza and A. Ortiz. An enterprise engineering approach for the alignment of business and information technology strategy, International Journal of Computer Integrated Manufacturing, vol. 24, no. 11, pp. 974-992, 2011.
19. J. van’t Wout, M. Waage, H. Hartman, M. Stahlecker and A. Hofman. The Integrated Architecture Framework Explained: Why, What, How, Springer Berlin Heidelberg, 2010.
20. M. Parker and R. Benson. Enterprisewide Information Management: State-of-the-Art Strategic Planning, Journal of Information Systems Management, vol. 6, no. 3, pp. 14-23, 1989.
21. M. Alaeddini, H. Asgari, A. Gharibi and M. Rashidi Rad. Leveraging business-IT alignment through enterprise architecture – an empirical study to estimate the extents, Information Technology and Management, pp. 1-28, 2016.
22. H. Wan, X. Luo, B. Johansson and H. Chen. Enterprise Architecture Benefits: The Divergence between Desirability and Realizability in EA Implementation, 14th International Conference on Informatics and Semiotics in Organisations, pp. 62-71, 2013.

Ключевые слова: бизнес-архитектура, архитектура информации (данных), архитектура приложений, технологическая архитектура.

The architectural approach to the business and IT alignment in the organization

Summary: Today, information technology (IT) is an integral part of most businesses. Everything becomes more noticeable movement on the model of «IT – Business operations support» to the model of «IT – business partner»: there are new business models that rely heavily on information technology to provide better quality services to customers. IT deeper penetrate into the activities of organizations and are becoming an important strategic asset that must be managed.

Keywords: business architecture, information architecture (data), application architecture, technology architecture.

Источник: samag.ru

CIO: как строить отношения с бизнесом и стоит ли переходить в бизнес

Опыт НИПИГАЗ говорит о том, что в составе каждого ИТ-проекта должен быть штатный BRM-специалист, выполняющий, по сути, роль интерфейса между ИТ и бизнесом, переводчика с айтишного языка на деловой и обратно. Его ключевой задачей является также сделать так, чтобы ИТ-команда не делила задачи на айтишные и бизнесовые, а воспринимала любые проблемы заказчика как свои собственные и активно участвовала в их решении, ориентируюсь на конечный результат. «Если, например, аналитическая система будет выдавать плохие рекомендации, а вы будете ссылаться на то, что бизнес-подразделения дают неверные исходные данные, то с точки зрения руководства виновной все равно будет ИТ-система. Но вот если вы не просто укажите на ошибки исходных данных, а дадите конкретные рекомендации, как можно их устранить или минимизировать, то начальство безусловно оценит пользу от ИТ», — сказал Андрей Александров.

Одна из функций BRM-специалиста — знание не только задач и процессов бизнес-заказчика, но и его организационной структуры, он должен знать, с кем именно из представителей бизнеса нужно решать ту или иную задачу. При этом именно он должен постоянно держать структуру заказчика в рамках решаемой задачи, чтобы проект не «расползался». Разумеется, это не означает, что не нужно обращать внимания на дополнительные потребности бизнеса, более того, отслеживание этих запросов является важной BRM-задачей, только не нужно стремиться все их включать в уже реализуемый проект, возможно лучше для этого инициировать новый, отметил Андрей Александров.

Отдельный вопрос — борьба за удовлетворенность заказчика. Тут ни в коем случае не нужно дословно следовать принципу «покупатель всегда прав», советует Андрей Александров. Принять оценку заказчика — совсем не означает согласиться с ней, нужно приложить усилия для изменения им своей оценки: обратить внимание на плюсы, которые он почему-то не заметил, более взвешенно изучить замеченные недостатки, учесть мнение других представителей заказчика и пр. И, конечно же, сформировать и предоставить план по устранению замечаний, регулярно информировать о его реализации и потом провести повторную оценку качества проекта.

Андрей Александров сформулировал ряд ключевых BRM-советов:

• перестать делить всех на «своих» и «чужих», но при этом не отделять себя от ИТ-функции;
• заявления типа «это невозможно, потому что», «чтобы это сделать, кто-то должен сделать» — простой путь к утрате доверия бизнеса;
• искать варианты реализации задачи и возможности «сшить» процессы, людей, подразделения — значит создать основу доверия для бизнеса;
• «принять огонь на себя», помочь бизнес-заказчикам договориться между собой;
• договариваться в любой доступной форме, быть на связи и отвечать во всех мессенджерах и средствах связи;
• фокусироваться на конечном результате и ценности, которую он может дать;
• регулярно встречаться с бизнесом и постоянно информировать его;
• не ограничиваться только внутренними заказчиками, включить в зону своей ответственности всех внешних партнеров компании — как поставщиков, так и потребителей;
• налаживать контакты во всех задействованных подразделениях и компаниях.

CIO — лидер цифровой трансформации бизнеса

Почему ИТ-руководитель — ключевая фигура в компании? Отвечая на этот вопрос, вынесенный в заголовок своего выступления, заместитель генерального директора компании «Русская механика» Вадим Ухалов описал динамику эволюции роли ИТ-директора за последнее десятилетие: поддержка бизнеса — оптимизация бизнеса — развитие бизнеса. «Нашей задачей сегодня является не просто повышение эффективности существующего производства, а разработка предложений по качественной трансформации производства на базе современных ИТ», — подчеркнул он. По его словам, повышение значимости ИТ-руководителя для развития бизнеса имеет объективную основу: информация стала сегодня важнейшим ресурсом любого предприятия. Именно доскональный анализ внутренних и внешних информационных потоков позволяет не только совершенствовать уже имеющиеся процессы, но и прогнозировать потребности бизнеса в будущем.

Как CIO перейти в бизнес и преуспеть

С тем, что ИТ-директор играет важную роль в менеджменте компании, никто из участников конференции не спорил, но всех интересовал другой вопрос: каковы перспективы его дальнейшего роста? Обсуждение этой темы выявило два основных варианта ответа: движение по ИТ-направлению в более крупные структуры для реализации более масштабных ИТ-проектов и выход за пределы ИТ в сферу бизнеса.

Первый проректор Ярославского государственного технического университета Денис Наумов, рассказывая о своем опыте перехода из ИТ в бизнес, отметил, что такое перемещение выглядело и для него, и для менеджмента организации как вполне естественный процесс карьерного роста, поскольку ИТ уже давно является базовой системой поддержи и развития этого вуза. По его мнению, позиция ИТ-руководителя позволила ему получить системный взгляд на проблемы организации, познакомиться со всеми основными деловыми процессами и получить изначальное понимание оцифровки процессов. В то же время при переходе на роль бизнес-руководителя он ощущал свое недостаточное умение находить баланс между рабочим и личным временем, а также недостаточное понимание «эмоционального слоя» в человеческих коммуникациях.

Рассказывая о личном опыте реализации «альтернативной ветви эволюции CIO», Дмитрий Сваин кратко сообщил о своем профессиональном жизненном пути: 14 лет в ИТ, от аналитика до ИТ-директора «Костромского завода автокомпонентов» (холдинговая структура, три территории, более 3000 сотрудников и свыше 500 пользователей, штат ИТ-службы — 40 человек). Три с половиной года назад в рамках реорганизации компании акционеры предложили ему перейти на другую деловую роль — руководителя одного из обособленных продуктовых бизнес-дивизионов. По его мнению, в этом качестве он достиг очень неплохих результатов (увеличение объемов и номенклатуры выпускаемой продукции, повышение эффективности производства, в том числе за счет реинжиниринга деловых процессов). Исходя из опыта своей миграции из ИТ в производство он сформулировав полезные замечания и советы при подготовке к смене профессионального курса.

1. При переходе из вспомогательной ветки бизнеса в основную вы перемещаетесь из уютного функционального колодца на передовую, где нужно либо побеждать, либо погибать.
2. Попробуйте заранее определить временной горизонт и периметр вашей «экспедиции» (как глубоко и надолго вы собираетесь погрузиться в новое поле деятельности).
3. Нужно честно ответить самому себе на такие вопросы:
4. Готовы ли вы психологически к масштабным изменениям?
5. Готовы ли вы уйти в «длительное плавание» от семьи?
6. Соответствует ли ваш уровень стрессоустойчивости вызову персональной ответственности за конечный финансовый результат и судьбы сотен или даже тысяч конкретных семей? Сможете ли вы в условиях постоянной высокой неопределенности, рисков и изменчивости ключевых факторов спать ночью как ребенок?
7. Есть ли у вас способ регулярного поддержания высокого уровня ваших энергий — физической, эмоциональной, ментальной и пр.?
8. Выясните для себя:
9. психологические особенности ваших будущих руководителей, кураторов и прочих лиц, принимающих решения;
10. есть ли в вашем будущем коллективе команда единомышленников и одновременно профессионалов в горизонтальном и вертикальном разрезах (не являющих и являющихся вашими подчиненными или вашими начальниками);
11. Согласуйте с будущим работодателем:
12. условия старта и целевые показатели: шлифовать и улучшать работающий механизм или «собирать с нуля» стартап? На кого можно опираться при проведении реформ?
13. ваши полномочия по переформатирования процессов, команды, технологий и пр.
14. Определите примерную инерционность системы, чтобы понять — когда следует ожидать результатов вашей деятельности (чем больше и сложнее система, тем выше инерция). При текущем цикле смены менеджеров в возможно, основные бизнес-результаты вашей работы будут видны только уже при вашем преемнике. В таком случае лучше сразу обсудить с работодателем ваши KPI.
15. Определите все ключевые звенья цепи и оцените риски со самым слабым.

Дмитрий Сваин высказал уверенность: «Если учли эти советы, обладаете достаточной энергией, изрядным везением и разумной долей безумия — у вас обязательно все получится!». (Заметим, что буквально за несколько дней до конференции он принял решения уйти со своего нынешнего поста, не уточнив, какой сфере — ИТ или не-ИТ — посвятит себя в дальнейшем.)

Источник: www.itweek.ru

Построение и развитие ИТ-архитектуры организации

Разработка ИТ-стратегии, иерархического реестра ИТ-систем, графических и архитектурных моделей – из каких этапов состоит процесс создания устойчивой ИТ-инфраструктуры.

ИТ-архитектура является одним из важнейших компонентов организации (корпоративной архитектуры). Есть различные стандарты, подходы и модели (framework) к построению и развитию ИТ-архитектуры и корпоративной архитектуры, например: ITIL, TOGAF, ISO 15288, 20000, 27000, Zachman, COBIT, IT4IT и др.

В данной статье рассмотрим комплекс основных этапов, который уже многократно зарекомендовал себя и апробирован во многих организациях. Каждый этап состоит из набора взаимосвязанных задач и инструкций. Детально они рассмотрены в источниках [1], [2] и [3].

Для создания всех графических моделей, реестров и справочников (классификаторов) по ИТ-архитектуре рекомендуется использовать специализированные программные продукты, например Business Studio, Archi, Microsoft Visio + Excel. Ключевыми исполнителями данных работ являются: ИТ-архитектор и ИТ-департамент в целом, процессный офис (или департамент бизнес-архитектуры), рабочие группы (команды) по соответствующим направлениям. Хотелось бы обратить внимание, что перечисленные далее этапы и задачи не являются разовыми, а должны выполняться постоянно с определённой периодичностью. Т.е. необходимо актуализировать и развивать все модели, справочники (классификаторы) и документы, выпускать новые версии, управлять изменениями. Иначе всё это потеряет ценность и перестанет соответствовать реальной внутренней деятельности организации и внешним факторам (требованиям, условиям).

12 этапов построения и развития ИТ-архитектуры организации

Для данных этапов не обязательна строгая последовательность, некоторые из них могут выполняться параллельно (в зависимости от специфики организации).

1. Разработка ИТ-стратегии

Включает стратегические карты, планы проектов и задач, бюджеты по всем компонентам и уровням ИТ: архитектура приложений, данных, системных технологий, оборудования и др. Эффективность, результативность и качество выполнения планов рекомендуется оценивать с помощью комплексной системы показателей KPI, которые также включаются в систему мотивации соответствующих специалистов и руководителей. Особенно важно при разработке ИТ-стратегии выделить критичную архитектуру и сконцентрировать на ней максимальные ресурсы и внимание. Критичная архитектура – это совокупность бизнес-процессов, ИТ-систем и других компонентов в работе организации, имеющих приоритетное значение в области операционной надёжности, обеспечения непрерывности и стабильности деятельности. ИТ-архитектура организации – это совокупность взаимосвязанных технологических и технических (программно-аппаратных) решений и компонентов, обеспечивающих эффективное функционирование бизнеса.

2. Разработка иерархического реестра (каталога) всех ИТ-систем и ИТ-платформ организации

• CRM и Front-office (маркетинг, продажи, работа с клиентами)
• Электронный документооборот (ЭДО)
• Кадровые и зарплатные системы
• Бухгалтерские системы
• Офисные системы (работа с документами и таблицами)
• BPMS (управление процессами и задачами)
• Юридические системы (договора, законодательство)
• Системы информационной безопасности (Firewall, Antivirus)

Второй слой (реестр) включает в себя: операционные системы, системы виртуализации, системы управления базами данных, платформы для ИТ-разработки и другие системные компоненты, на базе которых работают приложения.

Далее на основе реестров (каталогов) ИТ-систем и ИТ-платформ выполняется разработка иерархических графических моделей ИТ-архитектуры на разных уровнях. Они позволяют визуализировать большие объёмы информации. Их удобно использовать на совещаниях, презентациях, при проведении аналитических работ. Иногда эти модели печатают на листах формата А3, склеивают скотчем и размещают на стене, чтобы постоянно иметь перед глазами всю ИТ-архитектуру организации. На них делается много корректировок и заметок маркерами или карандашами в режиме реального времени, чтобы заново всё не печатать.

3. Заполнение детальных параметров (карточек, спецификаций) всех ИТ-систем и модулей

Карточка ИТ-системы (см. Рис. 1) должна давать наиболее полную, структурированную и актуальную информацию, которая включает следующее:

• Контуры функционирования: test (development), pre-production, production.
• Площадки и расположение: «облачное, cloud based» (за пределами организации), собственные ресурсы.
• Типы лицензий: временные (подписка), постоянные.
• Оборудование и ИТ-платформы, на которых работают ИТ-системы (приложения).
• Владелец ИТ-системы в организации (ответственный).
• Сроки (периодичность) обновления, сроки оплаченной внешней техподдержки.
• Версия и тип (категория) ИТ-системы.
• Финансовая информация: первоначальные вложения (CAPEX), стоимость сопровождения (OPEX).
• Операционные риски и риски информационной безопасности.
• Влияние на критичную архитектуру организации.
• Требования к отказоустойчивости, дублированию компонентов и резервному копированию.
• Срок восстановления системы в случае сбоев.
• Максимальное количество пользователей.
• Зависимость от иностранного программного обеспечения.
• Комментарии и техническая информация.

На основе данных параметров очень удобно автоматически формировать отчёты (точные аналитические срезы) по ИТ-архитектуре. Например, выборка ИТ-систем, которые работают на «облачном формате», имеют самые высокие расходы (OPEX), влияют на критичную архитектуру, имеют высокие риски. Далее на основе данной выборки можно принять решения о модификации ИТ-архитектуры.

4. Разработка архитектурных моделей ИТ-систем

Архитектурная модель ИТ-системы (см. Рис. 2) показывает основные её технические и логические компоненты, а также их взаимодействия (потоки данных). Например, серверная часть (приложение), сервер баз данных, внешние и вспомогательные сервера, клиентская часть (приложение), другие виды устройств и компонентов.

5. Разработка графических моделей по интеграции (связям) ИТ-систем

Необходимо отобразить ключевые потоки данных (см. Рис. 3) между ИТ-системами организации (ИС1 ИС2), между ИТ-системами и базами данных (ИС1 БД1), между ИТ-системами организации и внешними субъектами, другие виды связей (в зависимости от специфики организации). Дополнительно может быть указана информация о протоколах, шлюзах, сервисах, требованиях и т.п.

6. Разработка иерархического реестра (каталога) всех баз данных (структур данных) и их параметров

На тему управления базами данных есть большое количество книг и открытой информации, поэтому оставим этот этап без детализации.

7. Разработка технической архитектуры и дополнительных моделей (в зависимости от задач)

В техническую архитектуру (физический уровень) включаются: сетевая архитектура, архитектура оборудования (инфраструктура), модели центров обработки данных (ЦОД) и производственных площадок (локаций). Обязательно указание (отображение) требований по отказоустойчивости, дублированию (резервированию).

Для объектов архитектуры оборудования могут задаваться следующие параметры:

• Владелец оборудования в организации (ответственный).
• Зависимость от иностранных производителей.
• Сроки периодического технического обслуживания и ремонта.
• Финансовая информация: первоначальные вложения (CAPEX), стоимость сопровождения (OPEX).
• Влияние на критичную архитектуру организации.
• Расположение оборудования (локация).
• Операционные риски и риски информационной безопасности по оборудованию.
• Требования к отказоустойчивости, дублированию, резервированию.
• Комментарии и другая информация.

По технической архитектуре необходимо иметь полный набор актуальных отчётов (таблиц), которые формируются на основе соответствующих графических моделей и реестров (справочников).

В дополнение к технической архитектуре могут разрабатываться другие модели под разные задачи, например в форматах (нотациях): BPMN, ArchiMate, UML. Большое количество примеров содержатся в источниках [1] и [3].

8. Установление связей объектов и моделей ИТ-архитектуры с объектами и моделями бизнес-архитектуры

Очень важно, чтобы построение и развитие ИТ-архитектуры и бизнес-архитектуры выполнялось внутри одной базы данных и платформы, например Business Studio [4]. Только в таком случае мы сможем быстро и эффективно установить большое количество связей (со стратегией, бизнес-процессами, показателями KPI, организационной структурой), проследить взаимные влияния, оценить функционирование и полноту (целостность) всей корпоративной архитектуры.

9. Проработка операционных рисков (ИТ-рисков) и системы информационной безопасности

Параллельно с этапами 1-8 выполняется идентификация, оценка и проработка рисков. Разрабатываются предупреждающие действия (мероприятия) для минимизации и предотвращения рисков. Подробная информация по этой теме содержится в источнике [5]. Следует отменить, что сейчас и на многие годы вперёд для российских организаций главная задача – это уменьшение зависимости от иностранных производителей программного обеспечения и защита критичной архитектуры от внешних угроз.

В рамках системы информационной безопасности разрабатываются модели (матрицы) ролей пользователей и прав доступа к ИТ-системам и базам данных, механизмы защиты информации и другие компоненты в соответствии с международными и российскими стандартами.

10. Разработка нормативных документов и форм документов

Все рассмотренные выше этапы (работы) и их результаты должны быть детально документированы, см. [1]. Разрабатываются и актуализируются нормативные документы, например:

• Положение об ИТ-архитектуре
• Положение об интеграции ИТ-систем
• Порядок ввода (передачи) программного обеспечения в эксплуатацию и вывода из эксплуатации
• Порядок установки, модификации и обслуживания объектов ИТ-инфраструктуры
• Регламент доработки, тестирования и внесения изменений в ИТ-системы
• Положение о распределении прав доступа к ИТ-системам
• Положение об информационной безопасности
• Многое другое

Под формами документов подразумеваются различные образцы и шаблоны: технические задания, заявки, планы, отчёты, приказы, договора, SLA-соглашения и др.

11. Проведение аудита (оценки) ИТ-архитектуры по чек-листу и аналитических работ

Необходимо разработать и заполнить чек-лист с детальными требованиями (более 100). Фрагмент приведён на Рис. 4. Способы оценки требований: наблюдение за работой ИТ-систем и оборудования, наблюдение за работой ИТ-персонала, интервью и опросы сотрудников, изучение документов и отчётов (включая историю значений показателей, историю операционных рисков и др.). На основе проведённого аудита составляется план задач для проработки выявленных недостатков и включается в план развития (оптимизации) ИТ-архитектуры на следующий период (этап 1).

12. Сбор новых требований и задач к автоматизации и цифровизации от подразделений

Требования и задачи к автоматизации формируются непрерывно (практически ежедневно). Они должны быть сгруппированы и ранжированы по приоритетам (важности и срочности). Срочные задачи могут оперативно выполняться в рамках методологий гибкого управления Agile (Scrum, Kanban). Крупные глобальные задачи включаются в план развития ИТ (этап 1).

Рис. 1. ИТ-архитектура (на примере банка, фрагмент) и карточка (набор параметров) ИТ-системы

Рис. 2. Архитектурная модель программного продукта (на примере Business Studio)

Рис. 3. Модели интеграции ИТ-систем (общий вид, без детализации названий фигур и стрелок)

Рис. 4. Фрагмент чек-листа «Диагностика и аудит ИТ-архитектуры организации»

Рекомендуемая литература и источники информации:

Источник: www.it-world.ru