CC BY
125
УДК 004.896
УПРАВЛЕНИЕ 1Т-У СЛУГАМИ КАК ЭФФЕКТИВНОСТИ ПРЕДПРИЯТИЯ
О Матвеев А. Ю., 2016
Иркутский государственный университет, г. Иркутск
Бизнес-образование в экономике знаний
ОСНОВА ДЛЯ
ПОВЫШЕНИЯ
№ 1-2016
Данная статья является введением в такой предмет как Information Technologies Service Management (ITSM). Статья дает понимание, что такое ITSM, для чего он нужен и почему методологии ITSMнеобходимо внедрять на предприятии.
Ключевые слова: ITSM, ITIL, COBIT, бизнес, эффективность, IT-технологии.
В сегодняшний век стремительных изменений, когда количество инноваций в различных сферах нашей жизни растет со скоростью геометрической прогрессии, бизнесу все сложнее и сложнее удается удержаться на плаву, быть конкурентоспособными. Маховиком, раскручивающим и ускоряющим изменения в нашей жизни, служат IT-технологии (Information Technology — Информационные технологии). Поэтому для бизнеса очень важно, чтобы IT-технологии используемые для получения прибыли были надежны, гибки, понятны, управляемы и контролируемы. Чтобы IT могли выполнить такие требования бизнеса и даже предвосхитить их, необходимо применение методологий и практик ITSM.
ITSM (IT Infrastructure Library — библиотека инфраструктуры информационных технологий) — дословно, это управление IT услугами. Если точнее, то ITSM, это концепция управления IT в любой организации, где IT рассматривается как набор услуг, предоставляемых бизнесу.
История развития концепцииITSMначинается с первых попыток стандартизации IT-процессов. В 80-х годах Великобритания переживала экономический спад, а качество IT-услуг, предоставляемых британскому правительству различными поставщиками, было настолько низким, что существовавшее тогда Центральное агентство по вычислительной технике и телекоммуникациям (Central Computer and Télécommunications Agency, CCTA, в настоящее время именуемое Office of Government Commerce, OGC) получило от правительства этой страны указание разработать принципы эффективного и рентабельного использования IT-ресурсов в министерствах и других государственных учреждениях и уже на их основе формировать подход к оказанию IT-услуг, не зависящий от их поставщика. Так появилась ITIL — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. Первая редакция готовилась очень долго, включала в себя более 30 книг. И была закончена к 1996 году. В ней содержались на тот момент лучшие практики (многие не утратили актуальности и по сей день) по организации IT-инфраструктуры. Почти сразу началась разработка второй редакции ITIL, которая была завершена в 2004 году и уже содержала всего 8 книг. Вторая версия более подробно сфокусировалась на описании процесса эффективной передачи IT-услуги потребителю. К
концу 2011 года вышла третья, и пока финальная, версия ITIL. Данная версия полностью сфокусирована на описании IT как услуги. Вот что говорит один из авторов разработки 3-й части Дэвид Кэннон: «...одной из задач, было сделать книги более бизнес-ориентированными. Все это означало полное изменение архитектуры библиотеки и новый стиль изложения. Библиотека теперь содержит не только фундамент, но охватывает также намного более серьезные области».
Понятно, что более 30 книг лучших практик, освоить очень тяжело, тем более, что^ГЬне содержит в себе описания конкретных руководств к действию, т.е. не является методологией. ITIL — только говорит о том, какие лучше практики использовать, но как их внедрять и сопровождать, и какие могут возникнуть вопросы — это в ITIL не затрагивается. Поэтому многие крупные компании начали на основе ITIL строить свои методологии:Microsoít — MOF (Microsoft Operation Framework), HP — HPITSM Reference Model Model, IBM — IT Process Model и многие другие. По своей сути все эти методологии похожи друг на друга, но отличаются в терминологии и основываются на инструментарии, который разрабатывается в этих же компаниях. Отдельно отметим такую методологию как COBIT (COBIT - Control Objectives for Information and Related Technologies — задачи управления для информационных и смежных технологий). Она представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления IT, аудита и IT-безопасности. Стандарт разработан Фондом аудита и контроля информационных систем (ISACA).COBIT, благодаря единой терминологии, служит своеобразной платформой-буфером для конструктивного диалога между всеми участниками бизнеса:
• топ-менеджерами;
• руководителями среднего звена (IT-директором, начальниками отделов);
• непосредственными исполнителями (инженерами, программистами и т. д.);
• аудиторами.
В COBIT детально описаны цели и принципы управления, объекты управления, чётко определены все IT-процессы (задачи), протекающие в компании, и требования к ним, описан возможный инструментарий (практики) для их реализации. В описании IT-процессов также приведены практические рекомендации по управлению IT-безопасностью.
Как можно заметить COBIT является первой попыткой представить IT как услугу понятную для бизнеса, а также делает первые попытки «подружить» IT и бизнес. И вторая, а особенно третья редакции ITIL показывают, что начало положенное в методологии COBIT сейчас является основой для лучшей практики.
Также существуют формальные инструменты, с помощью которых можно оценить IT на надежность, контроль и управляемость. Для подтверждения на соответствие предоставления качественных IT-услуг, IT-структуры компаний или IT-компании оцениваются по стандартамШО 9000:20000 или ISO 9001:2015. Данные стандарты основываются на ITIL и позволяют понять заказчикам IT-услуг, на сколько качественно эти услуги будут им предоставлены.
Внедрение ITSM в организации основывается на выстраивании следующих процессов:
• Процесс управления инцидентами. Процесс заключается в разработке подходов, обеспечивающих быстрое устранение возникающих инцидентов.
• Процесс управления проблемами. Процесс основан по методиках поиска корневых причин инцидентов и занимается разработкой процедур, не позволяющих допускать подобные инциденты в будущем.
• Процесс управления конфигурациями. Это процесс контроля элементов инфраструктуры. Все значимые элементы фиксируются в базе CMDB (Configuration management database — база данных управления конфигурациями) и в дальнейшем мы можем данные элементы регистрировать, инвентаризировать, отслеживать и через эти элементы осуществлять взаимосвязь между остальными процессами.
• Процесс управления изменениями. Этот процесс направлен на контроль над изменениями конфигураций IT-объектов.
• Процесс управления релизами. Релизом называется набор конфигурационных единиц, которые совместно оттестированы и введены в промышленную среду. Данный процесс призван обеспечивать успешное развертывание релизов, обеспечивать интеграцию, хранение и тестирование релизов.
• Процесс управления уровнем услуг. Процесс призван обеспечить ясные соглашения с заказчиком IT-услуг. В рамках этого процесса заключаются SLA (SLA — Service Layer Agreement — соглашение об уровне услуг), выставляются KPI (KPI - Key Performance Indicators — ключевые показатели эффективности).
• Процесс управления мощностями (ёмкостью). В рамках данного процесса осуществляется оптимизация расходов, времени приобретения и размещения IT-ресурсов.
• Процесс управления доступностью. Этот процесс обеспечивает соответствующее размещение ресурсов, предоставляет методы и технологии для поддержки уровня доступности 1Т-услуг.
• Процесс управления непрерывностью. Этот процесс касается планирования и подготовки вариантов устранения чрезвычайных ситуаций с 1Т -услугами в случае остановки бизнеса.
• Процесс управления финансами. Управление Финансами касается экономических вопросов, предоставляемых 1Т-услуг.
По данным процессам задаются метрики, на основании которых можно определять эффективность и качество предоставляемой ГТ-услуги. Внедрение данных процессов позволят добиться надежности предоставляемых услуг, высокого качества предоставляемых услуг, понятность и полную контролируемость. Это является базой. Т.е. грамотное внедрение одной из методологий на базе ГТГЬ и дальнейшей сертификацией по одному из ключевых стандартов, дает бизнесу уверенность в том, что в самый критический момент их ГТ не подведет. Но, как мы уже говорили, мир не стоит на месте. И для развития бизнеса компаниям уже недостаточно того, что их ГГ выстроено в соответствии с тем или иным стандартом или методологией. Это уже не дает конкурентного преимущества потому, что теряется гибкость. Дэвид Кэнном сказал: «Если единственное, что вы хорошо делаете, это поддержка и предоставление сервисов, то жить вашему бизнесу недолго». Другими словами, хорошо и четко выстроенные процессы классического ГTГL\ГTSM в сегодняшних реалиях могут даже мешать компании динамично развиваться и успевать трансформироваться под требования рынка.
Надежность и гибкость в ГТ — это трудно совместимые между собой требования. И сейчас, чтобы эти требования совместить, очень активно развиваются два направления ITSM: облачные сервисы, и совершенно новая концепция «Бизнес — как ГТ». Облачные сервисы больше подходят небольшим компаниям, или для размещения некоторых сервисов крупных компаний. А под концепцией «Бизнес организация как ГТ организация» подразумевается перенос ответственности за внедрение ГТ-проектов компании на заинтересованные бизнес подразделения. И выстраивается максимальная интеграция ГТ-подразделений в бизнес.)
Облачные сервисы — это довольно «раскрученный» подход в организации ГТ, когда бизнесу предлагается на любом уровне от уровня «железа», до уровня приложений размещаться в облаке, тем самым получая уверенность в том, что уровень предоставления ГТуслуг будет осуществляться на самом высоком уровне, который
далеко не каждая фирма сможет сама себе обеспечить за счет содержания собственного IT-подразделения. Но есть и минусы. При переходе в облако мы получаем потенциальную проблему с доступом к данным третьими лицами и в ряде случаев получаем очень тяжело трансформируемые сервисы, которые вряд ли смогут быстро измениться под нужды организации, когда это срочно потребуется. Это о чем и говорил Дэвид про хорошее предоставление и поддержку сервисов. Но все-таки все индивидуально, и для многих молодых организаций облачные сервисы будут помогать в развитии бизнеса, а не мешать ему. Например, фирма-стартап с небольшим штатом сотрудников, размещает свои вычислительные мощности в облаке, но приложения необходимые для бизнеса оставляет под свое управление. В итоге фирма-стартап получает:
1) Надежную масштабируемую инфраструктуру. Надежность получается за счет облака, и гибкость тоже, т.к. в облаке очень быстро нарастить вычислительные мощности не составит труда.
2) Гибкость при изменении своих Бизнес-приложений т.к. они находятся под собственным управлением и штат сотрудников фирмы небольшой, и нет бюрократических барьеров на внедрение инноваций. Но надежность, полностью зависит от квалификации сотрудников фирмы-стартапа.
Облака позволяют взять на себя полное бремя обеспечения надежности предоставления IT услуг, но обеспечение гибкости для внесения изменений в текущие IT-услуги, облака могут предоставлять частично и не во всех случаях. Поэтому при размещении своих IT-сервисов в облаке, стоит очень четко понимать, что это даст бизнесу, т.к. при размещении в облаке не всегда бизнес может получить гибкость, а в тех сервисах, что бизнес не передает в облако не всегда сможет сам обеспечить надежность.
Большие организации чаще всего либо частично, либо вообще не передают свои 1Тсервисы во внешние облака т.к. есть риски несанкционированного доступа к данным. Но им это и не надо, т.к. многие могут позволить себе содержать свои собственные центры обработки данных (ЦОД) и штат высококвалифицированных специалистов. Но проблемы с гибкостью остаются т.к. большие организации страдают большой забюрократизированностью не только IT-процессов, но и внутренних процессов бизнеса. Также есть правило, что чем больше надежность IT-сервиса, тем больше он становится забюрократизирован. Но и без правил, в итоге создающих бюрократию тоже нельзя т.к. иначе бизнес превратится в хаос. Что же делать? Как вырваться из этого круга, когда, повышая надежность, мы теряем в гибкости и наоборот? Посмотрим в корень проблемы. Любую
организацию можно разделить на три архитектурных уровня:
• Уровень технологической архитектуры — это аппаратное и системное программное обеспечение.
• Архитектура прикладных систем — приложения, которые предназначены для управления данными и предоставляют интерфейсы взаимодействия для следующего уровня.
• Уровень бизнес-архитектуры — приложения, программно-аппаратные продукты, компоненты, влияющие на ведение бизнеса компании. Также сюда входят компоненты, описывающие деятельность компании с точки зрения стратегии, целей, состава, финансов. Присутствуют семантические связи, определяющие взаимоотношения всех компонентов уровня бизнес-архитектуры.
Полностью к 1Тотносятся только два первых уровня. Каждый уровень построен на последующем. Прикладные системы базируются на технологическом уровне. Бизнес архитектура взаимодействует с уровнем прикладных систем. Надежность и гибкость обеспечивается как индивидуально для каждого архитектурного уровня, так и на точках взаимодействия между уровнями. Т.к. существует зависимость между уровнями, то надежность и гибкость одного уровня зависит от надежности и гибкости ниже стоящих. Невнимание к одному из архитектурных уровней, такое как недостаточное финансирование, или непродуманность стратегии построения и развития архитектуры уровня приводит всю систему в целом к неспособности обеспечивать одновременно и надёжность, и гибкость, либо вообще приводит к краху всей системы. Существующие технологии и методологии ITSM позволяют, без особых умственных затрат на планирование, построить надежный и гибкий уровень технологической архитектуры. Тоже касается и прикладного уровня, но здесь при планировании построения архитектурного уровня все же требуется использовать грамотное стратегическое видение будущего компании, чтобы в последствии прикладной уровень оказался не только надежным, но и гибким. С бизнес-уровнем сложнее. При рождении компании уровень бизнес архитектуры гибок. Но этот архитектурный уровень растет и развивается вместе с компанией, постепенно обрастая все более и более сложными внутренними слоями, и взаимосвязями, которые надстраиваются друг над другом. В итоге от гибкости не остается и следа. Если бизнес-уровень развивался как попало, то часто и надежность оставляет желать лучшего. Усугубляет ситуацию и то, что в бизнес-архитектуру входят бизнес-приложения, от которых бизнес почему-то часто хочет отгородиться, считая, что это все забота IT. Концепция «Бизнес — как IT» призвана изменить
такую ситуацию. Но пока концепция построена не на каких-то конкретных методологиях или лучших практиках. Первые попытки описать лучшие практики сейчас имеются в ГТГЬ v3. «Бизнес как ГТ». Это симбиоз применения адаптивных организационных структур бизнеса и методологии СОВГТ. Методология СОВГТ приносит надежность и понимание между бизнесом и ГТ. Когда ГТчетко понимает бизнес-требования, оно может работать на опережение, что в свою очередь повышает гибкость бизнес-архитектуры в целом. Когда бизнес понимает, как и когда и в каком виде окупятся инвестиции в ГТ — это повышает уровень надежности уровня бизнес-архитектуры, а также сказывается на надежности более низких уровней. Применение адаптивных организационных структур также повышает гибкость бизнес-архитектуры.^
1. Шмидт, Эрик. Как работает Google / Эрик Шмидт, Джонатан Розенберг; пер. с англ. ООО Издательство «Эксмо» - М.: Эксмо 2015.
2. Cobit 4.1 Российское издание /Аудит и контроль информационных систем; пер. с англ. И. Вдовин - М.: Аудит и контроль информационных систем 2008 -240стр.
3. ITIL - этапы развития. Интервью с Дэвидом Кэнноном. [Электронный ресурс] - URL: http://www.itsmforum.ru/news/all_interest/2012_01_10 -(дата обращения: 16.10.2015).
4. Дэвид Марк, Эрик Моннойе. Директор по информационным технологиям нового поколения./Дэвид Марк, Эрик Моннойе //Вестник McKinsey - 2004. - N8. -С.6-22.
5. Юрген Лаартц, Эрик Моннойе, Александр Шердин. Технологическая архитектура бизнеса: пути обновления ./ Юрген Лаартц, Эрик Моннойе, Александр Шердин //Вестник McKinsey - 2004.- N8. - c.23-32.
6. Джессика Ливингстон. Как все начиналось. Apple, PayPal, Yahoo! и еще 20 историй известных стартапов глазами их основателей / Джессика Ливингстон; пер. с англ. Эксмо - М.:Эксмо 2011.
7. История ITIL. - [Электронный ресурс] // Softinergo: официальный сайт - URL:www.softintegro.ru -(дата обращения: 18.10.2015)
8. Томас Сигерс. ITIL: «за» и «против». 10 способов полюбить ITIL еще сильнее / Томас Сигерс // itSFM -2014 - N1 - С.4-14.
СПИСОК ЛИТЕРАТУРЫ
Cobit 4.1 Российское издание /Аудит и контроль информационных систем; пер. с англ. И. Вдовин -М.: Аудит и контроль информационных систем 2008 - 240с.
ITIL - этапы развития. Интервью с Дэвидом Кэнноном. [Электронный ресурс] - URL: http ://www. itsmforum.ru/news/all_interest/2012_01_1 0 - (дата обращения: 16.10.2015).
Джессика Ливингстон. Как все начиналось. Apple, PayPal, Yahoo! и еще 20 историй известных стартапов глазами их основателей./Джессика Ливингстон; пер. с англ. Эксмо - М.:Эксмо 2011.
Дэвид Марк, Эрик Моннойе. Директор по информационным технологиям нового
поколения./Дэвид Марк, Эрик Моннойе //Вестник McKinsey - 2004. - N8. - С.6-22.
История ITIL. - [Электронный ресурс] // Softinergo: официальный сайт -
URL:www.softintegro.ru - (дата обращения: 18.10.2015)
Томас Сигерс. ITIL: «за» и «против». 10 способов полюбить ITIL еще сильнее / Томас Сигерс // itSFM - 2014 - N1 - С.4-14.
Шмидт, Эрик. Как работает Google / Эрик Шмидт, Джонатан Розенберг; пер. с англ. ООО Издательство «Эксмо» - М.: Эксмо 2015.
Юрген Лаартц, Эрик Моннойе, Александр Шердин. Технологическая архитектура бизнеса: пути обновления ./ Юрген Лаартц, Эрик Моннойе, Александр Шердин //Вестник McKinsey - 2004.-N8.- С.23-32.
It services management — as a basis for improving business performance
© Matveev A.Yu., 2016
This article is an introduction to a subject as Information Technologies Service Management (ITSM).The article gives an insight into what ITSM, what it is and why it is necessary to implement ITSM methodology in the enterprise.
Keywords: ITSM, ITIL, COBIT, Business, performance, IT-technologies.
