Ранее рассматривался вопрос формирования плана по ИТ-подразделению на основе поступивших Заявок от пользователей ИТ-сервисов. Возникает вопрос: как сделать процесс сбора Заявок эффективным? Это один из вопросов, который необходимо решить руководителю ИТ-подразделения в целях оптимизации времени на реагирование ИТ-подразделения на текущую потребность пользователя. Другими словами, завтра «раки по пять рублей» уже не нужны – они нужны сегодня и по «три рубля», а может и наоборот: завтра «раки даже по три рубля» не нужны, они нужны сегодня пусть и по пять.
Наиболее подходящее решение – это применение аппаратно программного комплекса (далее по тексту – АПК), позволяющего обрабатывать Заявки пользователей и накапливать статистику по выполненным Заявкам в различных разрезах. Применение АПК существенно сокращает время прохождения запроса от момента его инициации до принятия в работу конкретным ИТ-специалистом. Также при применении АПК наблюдается экономия расходных материалов таких как: офисная бумага, картриджи и/ или тонер, при условии заправки картриджей силами ИТ-подразделения. При появлении истории обработки (выполнения) Заявок, появляются возможности проведения аналитических исследований и формирования базы знаний предприятия. Отдельным плюсом необходимо отметить перераспределение нагрузки на ИТ-персонал, например: программист должен программировать, а не «срочно» отвечать на вопрос пользователя, который пришел к нему и ждет очереди (из других таких же пользователей), когда тот освободится! Для подобных вопросов организована первая линия поддержки и, в случае, если оператор HelpDesk или группа внедрения и сопровождения не смогла предоставить ответ пользователю, вот тогда идет обращение на второй и третий уровни поддержки (согласно принципов методологии ITIL (IT Infrastructure Library, библиотека инфраструктуры информационных технологий)). Стоит отметить, что и пользователь не тратит свое время в пустую, зная, что на его запрос поступит ответ в заранее обговоренное и согласованное время.
Таким образом применение АПК позволит не только построить эффективное взаимодействие с Заказчиком – конечным потребителей ИТ-услуг, но и будет способствовать повышению качества предоставляемых ИТ-сервисов пользователям. В общем случае, схема взаимодействия потребителей ИТ-услуг (пользователей ИТ-сервисов) и ИТ-подразделения представлена на. Стоит отметить, что внедрение АПК, на уровне зрелости ИТ-подразделения от нулевого до второго (согласно методики оценки уровня зрелости ИТ по CobiT), является Стратегической целью развития ИТ на предприятии.
Вариантов программного обеспечения на рынке достаточно и каждое предприятие может выбрать решение, которое удовлетворяет всем его запросам и потребностям. Также никто не запрещает разработать и внедрить собственное решение, но всегда нужно помнить об эффективности и трезво оценивать окупаемость инвестиций.
На представленной ниже схеме взаимодействия, приведено логическое разделение на первую, вторую и третью линии поддержки пользователей; организационно каждое направление (функция ИТ) может быть выделено в самостоятельную группу, так например: в рассмотренном примере ранее служба технической поддержки или техподдержка (Technical support, Helpdesk, Service desk) – сервисная структура отдела поддержки пользователей, разрешающая проблемы пользователей с компьютерами (как аппаратным, так и программным обеспечением) и периферийным оборудованием. Данная служба является единым центром приема Заявок пользователей и их дальнейшей обработки (назначение ответственных, сроков выполнения и т. п.).
Рисунок 4. Схема взаимодействия структурных подразделений предприятия и ИТ-подразделения
В последующем разделе рассмотрим общую схему взаимодействия более подробно.
5.1. Организация взаимодействия
Для удобства дальнейшего изложения материала, аппаратно-программный комплекс, используемый для приема, регистрации заявок, контроля за выполнением работ, а также для получения статистики по Заявкам будем называть – HelpDesk, а специалистов, отвечающих за прием и распределение Заявок – менеджерами HelpDesk.
Согласно приведенной схеме на., основанием для выполнения работ сотрудниками ИТ-подразделения является Заявка Заказчика в специализированное программное обеспечение – Система регистрации заявок HelpDesk. Данное программное обеспечение становится единой точкой входа/выхода информации для ИТ-подразделения, следовательно исключительную важность в организации взаимодействия играет бизнес-процесс обработки Заявок пользователей.
Далее кратко рассмотрим бизнес-процесс работы с Заявками с применением программного обеспечения HelpDesk, состоящий из нескольких основных шагов.
Шаг первый – прием Заявки пользователя.
При поступлении новой заявки менеджеру HelpDesk приходит оповещение на электронную почту. Менеджер HelpDesk проводит первоначальный анализ заявки. В следующих случаях, когда нет возможности выполнить заявку по одной из следующих причин:
– Дублирующая заявка
– Не входит в компетенцию ИТ-подразделения
– Заявка снята Заказчиком
– Не согласовано с СБ и/или Руководителем по направлению
– Ошибка/неисправность не обнаружена
– Отсутствует техническая возможность
– Не запланирован бюджет
– Нет ТМЦ в наличии (по возможности не рекомендуется применять, а использовать механизм перенесения сроков, по договоренности с Заказчиком на более поздний период)
– Не поддерживаемый ИТ-сервис (отсутствует в списке SLA)
– Недостаточно информации для выполнения Задачи
– Незаинтересованность пользователя
– Другое (необходима расшифровка)
применяется инструмент «Мотивированный отказ».
Шаг второй – назначение Исполнителя работ по Заявке.
Если заявка принята в работу, возможны следующие варианты назначения Исполнителя:
Менеджер HelpDesk назначает исполнителем по заявке себя в случаях, если работы будут выполнены менеджером HelpDesk, если в заявке недостаточно исходных данных. Менеджер HelpDesk добавляет комментарий в заявку о необходимости предоставить дополнительную информацию. Если запрашиваемые данные по истечении трех дней не предоставлены, делает мотивированный отказ с указанием его обоснования.
При поступлении новой заявки по программному ИТ-сервису, требующей изменения программного обеспечения, Исполнителем назначается руководитель отдела разработки и внедрения информационных систем или руководитель подразделения АСУТП, который затем назначает Исполнителя из сотрудников своего отдела или передает заявку в работу сторонним организациям, осуществляющим третью линию поддержки по данному ИТ-сервису.
В прочих случаях Исполнитель по заявке назначается в соответствии с ИТ-сервисом.
Для обеспечения выполнения выше представленной схемы менеджер HelpDesk должен владеть следующей информацией:
Действующий каталог ИТ-сервисов предприятия – обычно перечень ИТ-сервисов закрепляется SLA;
Матрицей распределения ИТ-сервисов за ИТ-сотрудниками с указанием исполняемых функций по ИТ-сервису.
Утвержденный каталог выполняемых работ специалистами ИТ-подразделения.
Действующий регламент управления изменениями на предприятии, отражающий последовательность действий, в случаях внесения изменений в программное обеспечение, инфраструктуру, связь, АСУТП и т. п.
Шаг третий – установка плановых сроков выполнения работ Исполнителем работ по Заявке.
Минимальный срок выполнения работ по Заявке устанавливается три дня.
В случае если менеджер HelpDesk не может самостоятельно определить срок выполнения работ по заявке, он согласовывает сроки с конечным исполнителем по Заявке.
Шаг четвертый – выполнение работ Исполнителем работ по Заявке.
Далее, Исполнитель проводит окончательный анализ поступившей заявки. Руководствуясь регламентирующими документами по ИТ-сервису, наличием или отсутствием технической возможности реализации заявки, Исполнитель принимает заявку в работу или делает «Мотивированный отказ» с указанием его обоснования.
При приеме заявки в работу Исполнитель оценивает плановую трудоемкость работ, текущую загруженность по ранее поступившим заявкам и, при необходимости, изменяет сроки работ с помощью инструмента «Изменить сроки» с обязательным указанием обоснования. Этим инструментом также можно воспользоваться в ходе выполнения работ по заявке. Но, всегда при перенесении сроков выполнения работ по Заявке, Исполнитель должен согласовывать этот перенос с Заказчиком.
При необходимости привлечения других Исполнителей к выполнению работ по Заявке, или в случае выполнения работ по разным позициям каталога работ ИТ-подразделения, создается связанная заявка от имени автора (Заказчика) основной заявки. Причем, о всех происходящих действиях по Заявке, Заказчик уведомляется посредством электронной почты.
В случае, если работы по заявке будут выполнены позднее по объективным причинам, такие как отсутствие технической возможности до конкретного срока, задержка финансирования, приостановка проекта и т. п., Исполнитель может использовать инструмент «Отложить заявку» с обязательным указанием обоснования.
В ходе выполнения работ по заявке для уточнения возникающих вопросов, в программном обеспечении должен быть предусмотрен механизм коммуникации Исполнителя и Заказчика, который используется для фиксации переписки по Заявке, а также предоставляет возможность прикладывать к Заявке дополнительные файлы.
В случае необходимости, заявка может быть переведена в состояние «Изменение» в соответствии с действующим регламентом управления изменениями на предприятии. Ответственность за выполнение работ по изменениям возлагается на руководителя подразделения, в чью функциональную обязанность входит предоставление того или иного информационного сервиса.
Шаг пятый – завершение выполнения работ Исполнителем работ по Заявке.
После выполнения всех работ по заявке, Исполнитель оценивает фактическое время, затраченное на выполнение работ по заявке, фиксирует его и завершает работы с предоставление краткого отчета о выполненных работах.
Шаг шестой – принятие работ по Заявке Заказчиком.
После завершения работ Исполнителем по Заявке, Заказчик получает оповещение о смене статуса Заявки. При необходимости проверки качества выполнения, пользователь тестирует (проверяет) полученный результат. В регламенте взаимодействия должен быть жестко описан срок, за который Заказчик выполняет необходимые действия со своей стороны для принятия решения о закрытии Заявки. Если претензий к качеству и полноте реализации Заявки Заказчик не имеет, то он закрывает Заявку (программное обеспечение должно иметь функционал, позволяющий зафиксировать эту операцию). Ели у Заказчика возникают вопросы и /или не удовлетворенность результатом, то Исполнитель выполняет устранение замечаний в строго отведенный срок и наоборот, если в течении отведенного времени (согласно регламента взаимодействия, обычно не более трех рабочих дней) от пользователя нет обратной связи, то ИТ-подразделение оставляет за собой право закрытия работ по Заявке. И только после этого работы считаются завершенными в полном объеме.
Программное обеспечение HelpDesk, является стандартным программным обеспечением, устанавливаемым на все рабочие места пользователей без дополнительных согласований и разрешений.
Конечно, при этом не отменяются традиционные методы обращения в ИТ-службу, но приоритет выполнения Заявок обязательно должен быть закреплен внутренним регулирующим документом по предприятию, например, регламентируемыми методами создания Заявки пользователем ИТ-сервиса ИТ-подразделению (в порядке убывания приоритета исполнения последним) могут быть:
– Заявка в специализированное программное обеспечение – Система регистрации заявок HelpDesk;
– Письменное обращение по установленной форме;
– Электронное письмо;
– Телефонное обращение;
– Личное обращение к специалистам ИТ-подразделения.
Во всех иных случаях обращения Заказчика к Исполнителю не рассматриваются как Заявка, и ИТ-подразделение не несет ответственности за результат обращения пользователя. При этом любое обращение в ИТ-подразделение отличного от создания заявки в HelpDesk должно быть, в последствии, отражено в вышеуказанном программном обеспечении.
Так, как программное обеспечение HelpDesk играет ключевую роль при организации взаимодействия ИТ-подразделения и пользователей, то для удобства пользователей, должна быть разработана подробная инструкция по созданию, порядку обработки и выполнению заявки в Системе регистрации заявок HelpDesk, которая должна быть введена в действие по правилам внутренней нормативной документации.
Вышеописанный пример приведен для Заявок, не требующих никаких согласований и/ или приобретения ТМЦ, другими словами в регламенте взаимодействия должны быть описаны все возможные варианты видов взаимодействия ИТ-подразделения и пользователей, что будет способствовать пониманию установленной последовательности действий, при появлении соответствующих потребностей у Заказчика.
Например, виды взаимодействия между Заказчиком и ИТ-подразделением могут быть определены следующими схемами:
– Сопровождение информационных сервисов, не требующих дополнительного разрешения контролирующих служб;
– Сопровождение информационных сервисов, требующих участия контролирующих служб/лиц;
– Внесение изменений в функционирующее программное обеспечение предоставляемых ИТ-сервисов предприятия;
– Техническое обслуживание компьютерной техники и периферийного оборудования;
– Техническое обслуживание телефонной связи и/ или корпоративной телефонной связи;
– Консалтинговые услуги;
– Расширение действующего функционала обслуживаемых ИТ-сервисов;
– Создание нового ИТ-сервиса предприятия включая автоматизацию производственных процессов;
– Расширение/модернизация физической топологии ЛВС Заказчика и другие.
Бывают случаи, когда общих схем взаимодействия, закрепленных в регламенте недостаточно или необходима детализация для конкретных ИТ-сервисов. В таких ситуациях руководством предприятия издается приказ по введению детализации к схеме взаимодействия с определением порядка и ответственности сторон. Ярким примером может служить предоставление доступа к программному обеспечению, содержащего персональные данные работников (ФЗ-152).
5.2. Внутренние и внешние регулирующие документы
В предыдущем разделе достаточно подробно был рассмотрен один из основных внешних регулирующих документов ИТ-подразделения – регламент взаимодействия ИТ-подразделения и структурных подразделений предприятия. Для эффективного функционирования данного регламента, руководитель ИТ-подразделения должен разработать и утвердить Соглашение об уровне сервиса (Service Level Agreement – SLA), информация и данные из которого лежит в основе всех последующих внутренних документов по ИТ-подразделению.
Целью документа Соглашение об уровне сервиса является: определение используемых сервисов, установление уровня обслуживания обозначенных сервисов, а также определение зон и мер ответственности сторон Соглашения как для потребителя ИТ-услуг – Заказчика (пользователей ИТ-сервисов) в рамках выполнения работ по предоставлению ИТ-услуг, так и для Исполнителя работ.
Обращения в службу HelpDesk Исполнителя обрабатываются в порядке их поступления. Максимальный срок реакции на обращение определяется установленным уровнем поддержки (SLA) по информационному сервису.
Также Соглашение отражает все тонкости и нюансы обработки обращения с высоким уровнем критичности, требующие экстренного вмешательства или консультации специалистов технической поддержки. К таким обращениям, прежде всего, относятся вопросы восстановления работоспособности. При этом вопросы, которые не могут быть решены с использованием существующего функционала продукта и/или аппаратного комплекса, передаются для решения специалистам для анализа и последующей разработки/изменения, с последующим выпуском обновления программного продукта и/или изменения технических характеристик аппаратного комплекса. Сроки выпуска обновления/изменения определяются в процессе диагностики проблемы и в соответствии с общим планом разработки программного продукта и/или закупки (модернизации) парка компьютерной техники. Время решения обращения может зависеть от критичности обращения, сложности решаемой проблемы и необходимости доработки и/ или модернизации ИТ-сервиса.
Все обращения классифицируются на различные уровни обслуживания. Уровни обслуживания отличаются временем реакции на обращение (и другими параметрами) и зависят от категории проблемы. Все уровни обслуживания должны быть определены и зафиксированы в Соглашении.
В документе должен быть отражен такой критерий как время реакции ИТ-подразделения на Заявку, который определяется общей загрузкой технической поддержки Исполнителя и может быть меньше заявленного в Соглашении об уровне обслуживания. В некоторых случаях решение вопросов может производиться практически сразу же (мгновенно) по получении вопросов или дополнительной информации от пользователей информационных сервисов (потребителей ИТ-услуг). Реакция сотрудников службы технической поддержки Исполнителя на поступление дополнительной информации может быть дольше, но не больше максимального времени реакции, определенного для данного уровня технической поддержки информационного сервиса.
Соглашение должно предусматривать предоставление Исполнителем услуг с уровнем качества, определяемым и контролируемым набором показателей качества.
Качество работы, а также мера выполнения взятых на себя обязательств Исполнителем, может быть измерено соответствующими методиками, закрепленными в Соглашении, на основании анализа опросов удовлетворенности пользователей Заказчика и/или основании статистических данных из HelpDesk Исполнителя. Должна быть определена периодичность опросов, но не реже одного раза в квартал.
В Интернете или печатной литературе можно отыскать множество примеров построения основной таблицы SLA – уровень обслуживания и доступность ИТ-сервисов. Одни варианты более сложные, другие менее. Предлагаю читателю рассмотреть собственный вариант построения представления данной таблицы, опробованный на крупных предприятиях химической промышленности РФ, в котором отражены:
– Номер ИТ-сервиса по порядку
– Наименование информационного сервиса
– Назначение сервиса
– Детализация сервиса
– Количество пользователей
– Критичность сервиса
– Скорость реакции на неисправность (неработоспособность)
– Время предоставления информационного сервиса
– Время предоставления поддержки информационного сервиса
– Максимальное время неработоспособности в месяц
Шаблон таблицы SLA «уровень обслуживания и доступность ИТ-сервисов» представлен в приложении 2.
Хочу отметить, что логичным дополнением к таблице «уровень обслуживания и доступность» станет формирование перечня «Список готового (приобретенного) программного обеспечения в рамках предоставления ИТ-сервисов предприятия» со следующей структурой:
– Номер по порядку
– Наименование программного обеспечения
– Версия программного обеспечения
– Назначение программного обеспечения
– Количество лицензий
Подведем промежуточный итог: ИТ-подразделением уже подготовлены и внедрены следующие внешние регулирующие документы:
– Положение по подразделению.
– Должностные инструкции на каждую должность ИТ-подразделения.
– Приказом по предприятию организован Комитет по ИТ и разработано положение о Комитете по информационным технологиям.
– Приказом генерального директора/ директора предприятия введен в действие «Регламент обращения Стратегических инициатив в области автоматизации».
– Разработан регламент взаимодействия ИТ-подразделения и структурных подразделений предприятия. Регламент введен в должность приказом по предприятию.
– Согласовано и утверждено «Соглашение об уровне сервиса (SLA)».
– Разработан и внедрен «Регламент проведения регламентных работ».
Теперь ИТ-руководитель может приступить к формированию пакета внутренних регулирующих документов по подразделению, таких как:
– Регламент оформления технической документации.
– Регламент управления изменениями.
– Регламент взаимодействия исполнителей по выполнению заявок пользователей в Системе регистрации Заявок HelpDesk.
– Регламент предоставления и изменения прав доступа к программным ИТ-сервисам.
– Регламент разработки документа «Техническое задание».
– Функциональная матрица ответственности по ИТ-сервисам.
– И другие внутренние документы, например: Управление конфигурациями, Управление релизами.
Рассмотрим кратко основные аспекты, которые отражены по внутренних регулирующих документах.
Регламент оформления технической документации – основная цель данного документа вытекает из его названия: внедрение шаблона оформления технической документации для всех видов документов ИТ-подразделения: техническое задание, аналитическая записка, инструкция пользователя, руководство и т. п. Данный шаблон определяет требования не только к эстетическому оформлению выходного документа, но и определяет основные разделы. Например, каждый документ должен содержать:
– Содержание
– Свойства документа – кто, с какой целью, по какому проекту разработал, согласовал или изменил документ
– Общие сведения
– Определения и сокращения
– Характеристика и область применения
– Основание для разработки
– Основной раздел документа
– Примечания
Выполнение данного регламента является обязательным для всех направлений деятельности ИТ-подразделения, за исключением случаев, где оформление документации необходимо выполнять по ГОСТ.
Регламент управления изменениями. В процессе жизненного цикла во все ИТ-сервисы вносятся изменения. Причинами таких изменений обычно бывают:
– Изменение бизнес процессов;
– Устранение найденных ошибок;
– Расширение функциональных возможностей ИТ-сервиса;
– Улучшение эргономических свойств;
– Другие причины улучшающие характеристики предоставляемых ИТ-сервисов.
При внесении изменений в ИТ-сервис, с которым работает большое число пользователей и разработчиков, очень важно соблюдать определенный порядок и дисциплину. Это позволяет качественно планировать ресурсы и работы по модификации существующих ИТ-сервисов, отслеживать историю изменений и обеспечивать взаимозаменяемость сотрудников, планомерно повышать качество предоставляемых ИТ-сервисов.
К изменениям ИТ-сервисов относятся:
– изменения исходного кода программного обеспечения функционирующих информационных систем и программного обеспечения;
– изменения в структуре метаданных, нормативно-справочной информации, изменения печатных форм, а также изменения внешних отчетов и обработок функционирующего программного обеспечения;
– изменение и/или модернизация структурированных кабельных систем (витая пара, ВОЛС и т. д.), если при проведении работ возникает необходимость в установке дополнительного активного сетевого оборудования и/или перемещении уже установленного.
– изменение и/или модернизация кабельных сетей телефонной связи, если при проведении работ возникает необходимость в прокладке телефонного кабеля емкостью более 5 пар, установке новых телефонных распределительных коробок (либо перемещение уже установленных), а также в случае установки телефонных муфт, боксов, кросс-панелей, телефонных шкафов и т. д.
– изменение и/или модернизация объектов АСУТП как уровня программного обеспечения персональных компьютеров, так и контроллеров.
Ответственный специалист Исполнителя после получения Заявки Заказчика, руководствуясь Критериями отнесения Заявки Заказчика к ИТ-сервисам по Запросу на изменение, представленных в данном документе, определяет тип Заявки.
Заявка Заказчика относится к Запросу на изменение ИТ-сервиса, если для ее выполнения необходимо внести Изменение (-ия) в функционирующий ИТ-сервис, при условии, что расчетная трудоемкость выполнения Заявки Исполнителем менее 40 чел./часов.
Заявка Заказчика с трудоемкостью более 40 чел./часов могут быть (по согласованию Сторон) отнесены к классу «Проект» с оформлением соответствующей документации согласно действующим правилам и нормативным требованиям Заказчика.
Регламент взаимодействия исполнителей по выполнению заявок пользователей в Системе регистрации Заявок HelpDesk – данный документ является логическим продолжением инструкции пользователя по работе с «Системой регистрации Заявок HelpDesk», и описывает методы и принципы взаимодействия между ИТ-сотрудниками при реализации Заявки пользователей или Запросов на изменение. Также документ содержит шаблоны еженедельной отчетности по выполненным работам подразделения.
Регламент предоставления и изменения прав доступа к программным ИТ-сервисам – документ определяет процедуру и последовательность действий ИТ-специалистов, а также задействованных в процессе специалистов других подразделений и ответственных лиц при предоставлении и / или расширении прав доступа к конкретным ИТ-сервисам. Документ утверждается приказом генерального директора/ директором предприятия.
Регламент разработки документа «Техническое задание» – документ устанавливает состав, содержание, правила оформления документа «Техническое задание» (далее по тексту – ТЗ), разрабатываемого на автоматизированные системы управления (далее по тексту – АСУ) всех видов и для всех уровней управления на стадии «Технорабочий проект». Документ ТЗ создается для задач реализовываемых любого программного обеспечения, разрабатываемого в ИТ-подразделении, в т. ч. для задач по автоматизации производственных и технологических процессов. Техническое задание готовится при создании, развитии или модернизации автоматизированной системы (далее по тексту – АС), комплекса задач, задачи, программы или программного продукта. ТЗ входит в состав технической документации на АСУ в соответствии с ГОСТ 24.207—80. Данный регламент должен быть разработан в соответствии с требованиями Государственных стандартов на автоматизированные системы:
– Техническое задание на создание автоматизированной системы (ГОСТ 34.602—89)
– Техническое задание. Требования к содержанию и оформлению (ГОСТ 19.201—78)
– Требования к содержанию документа «Описание постановки задачи» (ГОСТ 24.204—80)
– Требования к содержанию документа «Описание алгоритма» (ГОСТ 24.211—82)
– ТЗ на АС является основным документом, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие, и предназначен для описания характеристик АС, условий реализации, входной и выходной информации.
Итоговым штрихом, является Функциональная матрица ответственности по ИТ-сервисам. Это таблица, которая описывает распределение поддерживаемых ИТ-сервисов предприятия между ИТ-специалистами с указанием функционального направления каждого специалиста по критерию: разработка (Development) и сопровождение (Support). Структура матрицы может быть представлена в следующем виде:
– Номер по порядку
– ФИО ИТ-специалиста
– Наименование ИТ-сервиса
– Разработка
– Сопровождение
После заполнения данной структуры все ИТ-сервисы должны быть закреплены и распределены по ИТ-специалистам. По окончании заполнения матрицы ИТ-руководителю необходимо выполнить еще один шаг: разработать и утвердить на уровне руководителя предприятия документ – «Распределение обязанностей и функций ИТ-персонала в разрезе предоставляемых ИТ-сервисов».
Структура таблицы представлена ниже.
Все эти документы и правила описанные в них способствуют созданию эффективной методики взаимодействия ИТ-подразделения и структурных подразделений предприятия, а также четного определения внутренних процессов ИТ. Причем правила взаимодействия и описания процессов представлены на понятном для бизнеса языке и согласованы всеми участниками.