Управление it отделом 8 скачать конфигурацию. Управление IT-отделом
В народе есть замечательная крылатая фраза "Сапожник без сапог". Она в полной мере описывает ситуацию, в которой оказываются ИТ-отделы организаций и обслуживающие компании. Люди, которые помогают другим пользователям решать проблемы с техникой, исправлять ошибки в программах, восстанавливать работоспособность программ и оборудования. Пытаются навести порядок и привить культуру работы с оборудованием и программным обеспечением, сами же не могут навести порядок у себя! О чем идет речь? Приведем примеры.
Случай 1. Бухгалтер обращается к начальнику ИТ-отдела.
Бухгалтер. Скажи, пожалуйста, у меня не печатает принтер, не мог бы сказать своим ребятам, что бы они пришли и поменяли картридж?
Начальник ИТ. Сейчас. Повесите на трубке. (голос за кадром: Вова, у нас есть картриджи? ответ за кадром: Не, нету. Закончились...)
Начальник ИТ. Эээ. Марь Ивановна, понимаете, у нас закончились картриджи...
Бухгалтер. А почему не купили раньше, чтобы запас был? Мне первичку печатать надо, клиенты ждут!
Начальник ИТ. Ну...
Случай 2. Начальник ИТ-отдела обращается к администратору компьютерных сетей.
Начальник ИТ. Коль, ты забрал у поставщика доп. память, которую обещали поставить зам. директору?
Админ. Нет. Мы ее еще не оплатили...
Начальник ИТ. Как? Я неделю назад ему обещал, что сегодня поставим... Почему не оплатили?
Админ. Эээ. Ну... Я забыл... Работы много, всего не запомнишь...
Начальник ИТ. Хочешь, я тебя с собой сегодня возьму к зам. директору, ты ему об этом расскажешь?
Случай 3. Системный администратор обращается к технику компьютерных сетей.
Сисадмин. Слушай, а куда делся системный блок, который с двумя винтами в рэйде? Раньше он стоял у Ивановой.
Техник. Так она уволилась...
Сисадмин. А комп куда делся?
Техник. Я не знаю... Наверное поставили кому-нибудь.
Сисадмин. ?!
К сожалению, в се эти случаи из реальной жизни. Естественно, все это откладывает негативный отпечаток не только на конкретных людей, но и на ИТ-службу в целом. Ведь, как обычно бывает: хорошее не запоминают, а плохое помнят долго...
Действительно, если в организации три компьютера и один эникейщик на них, то для него нет смысла вести свой учет, но если компьютеров, 25, 50, 100 и работают несколько специалистов... На возникающие вопросы:
- У кого стоит тот или иной компьютер?
- Где взять "лишнюю" память DDR 3, чтобы срочно доукомплектовать системный блок, который в ремонте?
- Хватит ли расходных материалов, которые лежат на складе на следующий месяц?
- Куда дели материнскую плату, которая, я точно помню, была!?
- Когда у поставщика нужно забрать системный блок?
- Кто из сотрудников мне звонил 15 мин. назад? Помню, что кто-то звонил, а кто и что хотел, не помню...
Вопросы можно продолжить, но суть от этого не изменится. При достаточно большом количестве оборудования и нескольких специалистах т акой объем информации, попросту, не удержать в голове и даже на бумаге это сделать крайне трудно .
На помощь приходит наша конфигурация, которая закрывает все потребности ИТ.
Для кого предназначено решение?
Конфигурация предназначена для ИТ-подразделений любой организации и компаний, занимающихся обслуживанием клиентов. В нем могут работать системные администраторы, программисты, эникейщики, техники компьютерных сетей, а так же руководители, которые должны их контролировать.
Основные возможности решения
Service Desk
Остановимся на ключевых элементах построенного нами Service Desk и перечислим возможности, чтобы понимать, что есть, что. Итак, наш Service Desk умеет следующее:
- Самостоятельное обращение пользователей через Web-интерфейс;
- Создание заданий на основании входящих писем на электронный ящик службы поддержки;
- Настраиваемые процессы с возможностью настройки этапов исполнения и назначения исполнителей;
- Настраиваемые этапы выполнения процессов (цвет, фон, иконка, состояние);
- Использование под процессов в заданиях;
- Прикрепление скриншотов к заданию сделанных пользователем одной кнопкой;
- Просмотр, как собственных заданий, так и заданий подчиненных сотрудников;
- Прикрепление произвольных файлов в задании;
- Обмен сообщениями с пользователем;
- Управление шаблонами всех видов оповещений;
- Создание дочерних под заданий по задаче. Это позволяет, например, руководителю отдела разбить крупную задачу по подчиненным и контролировать выполнение каждой подзадачи;
- Фиксирование всех изменений в задании;
- Привязка базы знаний к заданиям;
- Оценка качества выполнения задания;
- Диаграмма Ганта с возможностью просмотра выполнения задания по периоду, этапу и исполнителю, а так же сравнение с контрольной датой выполнения.
- Большие возможности по анализу выполненных/невыполненных/просроченных заданий.
- Неограниченный список наблюдателей, которые оповещаются при изменении в задании любого реквизита(ов) с указанием, что конкретно было изменено. Наблюдателем можно назначить любого пользователя;
- Оповещение наблюдателей заданий одним из способов: Электронным письмом (e-mail); SMS (sms.ru, МТС, Билайн); В самой конфигурации;
Учет оборудования
Помимо подсистемы Service Desk, есть возможность вести учет оборудования. Все документы связаны в единый комплекс, а работа с ними сделана максимально удобно.
- Заказы поставщикам, контроль их оплаты и поставки.
- Отражение всех операций на местах хранения (Поступление, Перемещение, Списание, Инвентаризация, Сборка (комплектация), Разбиение комплекта). Кроме оборудования можно работать так же и с сопутствующей номенклатурой (телефоны, СИМ-карты, мебель ИТ-отдела и т.д.)
- Количественный и суммовой учет номенклатуры по материально-ответсвенным лицам. За каждым местом хранения (не важно что это склад, или рабочее место) есть возможность закрепить ответственного сотрудника. Кроме этого можно за каждым рабочим местом закрепить ответственного сотрудника ИТ-отдела (когда в организации разные люди обслуживают разные подразделения).
- Планирование собственных расходов и подсистема "Бюджетирование". План-фактный анализ расходов по бюджетам.
- Работа с вспомогательным оборудованием (работа со сканером штрих-кодов).
- Групповой импорт данных о составе оборудования из Everest, AIDA64, WMI.
- Поддержка схем сетей, кабинетов, зданий. А так же привязка рабочих мест на схемах.
- Возможность вести учет сразу по нескольким организациям.
- Учет программного обеспечения и лицензий с возможностью просмотра информации об истечении сроков их действий и срока их обновлений.
- Учет логинов и паролей пользователей.
- Загрузка изображений номенклатуры из интернета.
Обслуживание и ремонт техники
Учет оборудования - это конечно хорошо, но есть еще одно важное направление - обслуживание и ремонты. Данная подсистема имеет следующие возможности:
- Проведение обслуживания, как собственными силами, так и силами сторонних организаций.
- Оплата и контроль услуг сторонним организациям за ремонт и обслуживание.
- Обслуживание на рабочем месте, где произошла проблема и отражение этого факта в программе.
- Учет расходных материалов и контроль количественных показателей оборудования (количество заправок картриджей, количество отпечатанных листов и т.д.)
- Возможность во время обслуживания и ремонта быстро докупить, списать, переместить на склад, установить со склада комплектующие.
Эта подсистема увязана с общими остатками и оплатами и является дополнением подсистемы "Учет оборудования".
Еще пару слов
Помимо всего прочего, есть множество дополнительных удобных механизмов, которые сделают работу с конфигурацией не обременительной. Ну и еще одно неоспоримое преимущество конфигурации над конкурентами: открытость к модификациям и доработкам. Если у Вас есть свои блоки учета, которые не вписываются в рамки конфигурации, вы можете самостоятельно доработать конфигурацию под собственные нужды.
Причины купить
Конфигурация "Управление IT-отделом 8" на рынке уже более 4-х лет. За это время у нас появились сотни клиентов, есть свои методики работы, наработки и свое видение хорошего решения. Мы собрали все пожелания пользователей предыдущей версии 2.1 и попытались реализовать их в версии 3.0. Мы хотим, чтобы наше решение было лучшим!
Если у Вас остались вопросы, прошу на демо-сервер посмотреть на конфигурацию собственными глазами.
www.softonit.ru
Введение
Необходимость демонстрировать вклад IT-подразделения в поддержание развития и эффективной деятельности организации заставила IT-руководителей рассмотреть различные методы управление ИТ -процессами. На текущий день в мире имеется несколько популярных методик руководства ИТ структурой компании. Далее мы рассмотрим и сравним основные из них.
IT Infrastructure Library (переводится как библиотека инфраструктуры информационных технологий) - подстраиваемая структурная методика, агрегирующая авангардные знания в сфере управление ИТ и позволяющая формировать оказание качественных услуг в области информационных технологий. ITIL методология основана на моделировании процедур, применяемых при реализации функций менеджмента и управления. Библиотека содержит исчерпывающий набор процедур управления, что позволяет определить состав структуры IT-службы и требования к навыкам её специалистов.
IT Service Management (ITSM) - собрание 10 процедур, изложенных в основе ITIL: книгах Service Delivery, Service Support.
На сегодняшний день большинство компаний в управление ИТ следует методам ITIL только в двух областях, замкнутых на предоставлении и поддержке сервисов. (Начинающих заведомо информируют о том, что большинство менеджеров IT-служб и эксперты применяют слово ITIL только в контексте поддержки ИТ-сервисов.) Улучшать качество поддержки предоставляемых услуг довольно легко, поэтому большинство IT-менеджеров и консультантов по ITIL советуют двигаться в этом направлении.
Control Objectives for Information and Related Technology (переводится как контрольные объекты информационных и смежных технологий) - методика информационной защищённости в управление ИТ , передаёт руководителям, консультантам и пользователям IT список стандартных объектов аудита и содействует разработке средств управления информационными технологиями и проверке их функционирования в рамках всей организации.
С этой целью COBIT различает 34 критерия аудита управления ИТ, один на отдельную IT - процедуру, которые объединены четырьмя доменами:
- Организация и Планирование;
- Внедрение и Проектирование;
- Сопровождение и Эксплуатация;
- Мониторинг.
Взаимосвязь CobiT и ITIL
Публичная модель CobiT занимает определённую зону в совокупном собрании шаблонов, методов и инструкций управление ИТ . Во-первых, это методика менеджмента и аудита IT. В то время как, ITIL это библиотека наилучшего прикладного управления предоставлением IT-услуг, а CobiT предназначается и для управления ИТ и для аудита ИТ. Задачи ITIL, также, как и другие процедуры, могут обслуживаться и регулироваться стандартом CobiT.
Для руководства определяются задачи менеджмента, описанные в Методах управления, а для контроля - объекты аудита, приведенные в Принципах контроля.
CobiT даёт руководителям шанс довести желания и стремления бизнеса до менеджеров IT-служб, трансформируя долгосрочные и краткосрочные цели корпорации в ясные и прозрачные задачи управление ИТ . Менеджеры IT-сервисов, также, руководят начальниками департаментов, руководствуясь указаниями, полученными от CobiT. Методика ITIL используется для улучшения процедуры сопровождения информационных сервисов в управлении.
В том случае, когда методы оказания и сопровождения IT услуг (ITIL) в корпорации не установлены, то Cobit обеспечивает методы руководства для этой области. Кроме этого, CobiT возможно использовать для регулирования процесса эксплуатации информационной системы, правда, только в менеджменте и анализе.
Таким образом, IT-аудиторы формируют, исследуют данные и передают формы и заключения менеджерам корпорации, следуя руководству аудитора CobiT. Опираясь на экспертных оценках и выводах об уровне приближения к ключевым показателям, менеджмент фирмы аргументированно, учитывая соответствие IT целей и бизнес задач, реализует руководство ИТ задачами корпорации для достижение определенных целей в бизнесе.
CMM
Capability Maturity Model (переводится как модель зрелости процессов разработки софта) - методика, позволяющая оценить степень зрелости процедур разработки программного обеспечения и дать оценку (от 1 до 5). Улучшенная разновидность Capability Maturity Model Integration (CMMI) содержит в себе рекомендации по повышению качества операций управление ИТ , а также методы руководства разработкой, получением и сопровождением услуг или продуктов.
Six Sigma
Six Sigma - система управления уровнем качества на основании фактов и данных. Она даёт возможность контролировать изменения в управление ИТ , таким образом, можно достичь очень хороших показателей качества услуг и продуктов. Модель Six Sigma основана на статистической зависимости, согласно которой сбои случаются очень редко при соблюдении определенных величин контрольных показателей.
Information Security
Функционирование подавляющего большинства бизнес-сервисов в управление ИТ не представляется возможным без специального программного обеспечения. Общеизвестно, что основная масса задач реализуется одним или несколькими информационными сервисами.
Ввод систем для управления информационной безопасностью (СУИБ) - значительное событие, задачей которого служит руководство процедурами информационного снабжения корпорации и устранения нелегитимного получения данных.
Желаемый уровень ИБ должен быть прописан в соглашении об уровне сервиса (SLA - Service Level Agreement). Задачей управления ИБ служит непрерывная гарантия защищенности услуг на должном уровне, а информационная защищенность является важным показателем надёжности управление ИТ . Для провайдеров сервисов, задача руководства информационной безопасностью благоприятствует улучшению защищенности IT-инфраструктуры.
Стандарт ISO 17799:2005 является сборником практических рекомендаций, отражающих основные концепции организации СУИБ, а также содержит рекомендации по формированию, реализации и мониторингу мероприятий информационной безопасности.
Недостатки ITIL
Основное несовершенство ITIL пользователям видится в том, что библиотека ITIL не предоставляет практических руководств по применению в управление ИТ изложенного в ней опыта. Каждой корпорации следует создать на основе методов ITIL свои индивидуальные процессы.
В ряде случаев, может возникнуть необходимость привлечения консультантов. Реализация в организации методов ITIL, возможно, затребует вспомогательного времени и дополнительных людей.
Хотя создание новых процедур обычно происходит в течение нескольких месяцев, масштаб требуемых новшеств может быть столь велик, что на введение новых процессов у некоторых IT-подразделений могут уйти годы.
Вероятно, возникнет необходимость смены номеров телефонов полностью всех сотрудников IT-департамента, т.к. представители бизнеса обычно обращались непосредственно к инженерам, без участия службы технической поддержки. Возможно, потребуется принять на работу дополнительных специалистов, если при внедрении проекта ITIL будут выявлены недостатки в управление ИТ уровнем сервиса и разрешением инцидентов.
SOA
Service-Oriented Architecture (переводится как сервисные архитектуры). Она даёт возможность выстроить архитектуру, включающую в себя провайдеров и пользователей услуг, организовывая для них связи по мере необходимости. Она организует механизм компоновки приложений, складывающихся из служб с типовыми интерфейсами, которые могут реализовать всю бизнес-задачу целиком.
Данные сервисы состоят из неоднократно применимых подмодулей, которые не зависят от применяемых операционных систем, средств разработки, исходных данных и схем обработки. Использование процессов IT в составе независимых сервисов, которые имеют стандартные интерфейсы управление ИТ даёт возможность реализовать гибкую систему, составляющую бизнес-сервисы с непрочно связанными программными модулями.
Данный вид связи модулей гарантирует допустимость компоновки исходной системы, соответствующей сегодняшним требованиям бизнес пользователей, с последующим её переконфигурированием при изменении бизнес требований.
ITIL и SOA
В системах, построенных на компонентных-сервисах, все части модульных программ и службы управление ИТ , фактически могут размещаться на разных серверных площадках, удалённых географически, модули также взаимодействуют между собой по определённым алгоритмам.
При этом вероятно наличие сложных проблем, связанных с администрированием сервисов. Для устранения этой проблемы, возможно, использовать ITIL. Стандартные системы администрирования сконцентрированы на увеличении быстродействия аппаратных и программных средств, а процедуры, описанные в ITIL, используют администрирование более широко.
ITIL учитывает анализ выполнения сотрудниками своих функций, внесение изменений в программные и аппаратные модули, установление очерёдности выполнения работ в управлении ИТ и ряд других факторов.
Процесс ITIL Управление конфигурациями
Configuration management является наиболее важным в управление ИТ . Задача процесса - построить и содержать в соответствующем состоянии аппаратную конфигурацию инфраструктуры.
Configuration management database - это база данных управления конфигурацией. База CMDB лежит в основе каждого процесса. Она предоставляет возможность контроля над отдельным ресурсом и имеет хронику проделанных действий.
CMDB является физическим отражением IT-активов, которые есть у корпорации: программное обеспечение, сервера, компьютеры, маршрутизаторы и т.д. Дополнительно в базе зафиксированы изменения всех активов, список инцидентов, относящихся к работе каждого ресурса и описание роли объекта в общей инфраструктуре. Реализована связь с инцидентами, проблемами, нарядами, изменениями и т.д.
Процесс ITIL Управление мощностью
Низкая мощность структуры управление ИТ ведет к возникновению требований к увеличению скорости работы информационных систем, в крайнем случае, к остановке работы.
Между тем, лишняя, не потребляемая мощность, говорит о неэффективном расходе бюджета.
Задача этой ITIL процедуры - определить логический баланс между расходами и необходимостью, с целью обоснования затрат на мощность ИТ и соответствия сегодняшним, и предполагаемым нуждам корпорации.
Управление производительностью
Измерение, мониторинг ИТ инфраструктуры для наилучшей отдачи. Осуществляется периодическое определение конфигураций компьютеров, мониторинг различных параметров, предупреждение об уменьшении свободного места на диске ниже критического значения и т.д.
Может быть настроен мониторинг нескольких сотен параметров конфигураций компьютеров.
База данных мощностей содержит данные по емкости объектов управление ИТ инфраструктуры, является частью CMDB.
Процесс ITIL Управление непрерывностью
Задача процесса - контроль непрерывности оказания услуг, поддержание функции управление ИТ непрерывностью производства, гарантированное возобновление работы компонент и сервисов ИТ (серверные модули, маршрутизаторы, программное обеспечение, коммуникационное оборудование, техническая поддержка) в установленные и утверждённые бизнесом сроки.
Обеспечение гарантированного восстановления структуры, нужной для выполнения бизнес процессов, при чрезвычайных ситуациях: отключение электроэнергии и т.д.
Заключение
Наибольшую известность, пожалуй, имеют ITIL и COBIT. На самом деле ITIL и Cobit в основном говорят о подобных вещах в управление ИТ (что неудивительно).
Для внедрения Cobit Вам необходимо организовать свой отдел IT-аудита или воспользоваться услугами сторонних, сертифицированных по стандарту Cobit аудиторов. Это связано с дополнительными затратами.
Кроме этого, для многих организаций представляет интерес один из процессов ITIL - диспетчерская служба Service Desk. Поэтому, скорее всего, наибольшее распространение получает ITIL, в основном за счёт интереса к Service Desk и отсутствия затрат на IT-аудит.
С другой стороны, технически грамотный, образованный, талантливый IT-менеджер и сам без теории может правильно выстроить все необходимые процессы управление ИТ , руководствуясь профессиональными знаниями и интуицией, но теоретическая основа никогда не помешает, лучше быть в курсе последних новшеств в сфере IT менеджмента.
Таким образом, в конечном счете, как вести учёт решать Вам, мы лишь предлагаем инструмент, способный выполнить наибольшую функциональность (свободу действий и фантазии).
Вопросы для самопроверки
1. Какие критерии лежат в основе классификации информационных систем менеджмента?
2. Какими особенностями обладают информационные системы поддержки принятия решений?
3. Перечислите основные особенности использования информационных систем оперативного анализа данных.
4. Какие типы закономерностей могут быть выявлены методами Data Mining?
5. Расскажите об особенностях принятия управленческих решений в условиях многокритериальности.
6. Перечислите основные функциональные возможности систем электронного документооборота.
3.1 Организация управления: место ИТ отдела в организационной структуре управления предприятием. Взаимосвязь с подразделениями предприятия
Правильное и эффективное функционирование информационного подразделения любого предприятия или ведомства определяется местом ИТ отдела в организационной структуре управления предприятием, его взаимосвязями с другими подразделениями компании, степенью влияния на основной бизнес компании.
Повышение значимости ИТ отдела для поддержки и развития основного бизнеса компании и разумный рост затрат на информационные технологии – вот две основополагающие тенденции последнего времени. Как следствие - повышается статус ИТ - руководителя, который из начальника ИТ-департамента (исполнение решений в области ИТ) становится ИТ - директором, отвечающим за выработку и реализацию ИТ-стратегии.
К возможным типам структур управления ИТ в крупной компании можно отнести три подхода – жесткая централизация, децентрализованная структура, мягкая централизация.
Построение управления по принципу жесткой централизации означает создание единого ИТ подразделения в компании. Весь персонал объединяется в одном структурном подразделении, вся ответственность по вопросам, связанным с ИТ, ложится на руководителя единого ИТ подразделения. Такой подход для западных компаний встречается редко, но в России достаточно распространен. Сильной стороной такого подхода является наличие единого ИТ бюджета.
В децентрализованной структуре, присущей крупным холдинговым структурам, ИТ департамент не вмешивается в деятельность региональных ИТ служб, но в то же время занимается представлением интересов ИТ служб на местах перед акционерами, проводит оценку их деятельности и занимается консолидацией отчетности ИТ служб дочерних компаний. К положительным аспектам построения такого взаимодействия можно отнести наличие большей самостоятельности в принятии решений на местах и ускоренному внедрению передовых технологий. В тоже время, такой подход негативно сказывается на разработке единой ИТ стратегии, а распыление высококлассных специалистов повышает риски успешного завершения ИТ проектов на местах.
В случае с мягкой централизацией за центром остаются законодательные, контрольные и представительские функции. При мягкой централизации ИТ департамент, не имея прямых рычагов воздействия на принятие решения на уровне все ИТ подразделений, должен разрабатывать стандарты, рекомендация и требования к информационным системам, организовывать обучение всех ИТ специалистов холдинговой структуры, осуществлять ИТ аудит.
Существует международный стандарт ISO/IEC 15288, который помогает провести четкую грань разделения полномочий среди всех ИТ структур компании .
В соответствии с мировым опытом принято говорить о пяти стилях работы ИТ-подразделения в компании :
· унаследованный стиль работы (Heritage) - тактическое управление технологиями, обеспечение выполнения обещанного, ориентация на повышение эффективности использования ИТ,
· согласованный стиль работы (Aligned) - стратегическое управление технологиями, согласование ИТ и бизнеса,
· заинтересованный стиль работы (Engaged) - ориентация на совершенствование бизнеса, повышение гибкости и ценности ИТ-подразделения для бизнеса, приоритетный акцент на развитие и поддержку бизнес-систем,
· проникающий стиль работы (Pervasive) - ориентация на структурное преобразование бизнеса, восприятие информации и процессов как стратегических активов,
· выгодный стиль работы (Commodity) - ИТ рассредоточены в рамках бизнеса, руководство бизнес-подразделений полностью владеет ИТ-ресурсами и управляет ИТ, не имея специальных ролей для ИТ.
В настоящее время преобладающим типом работы ИТ подразделений является унаследованный стиль. Руководство компании и ИТ - отдела может выбрать разные схемы работы в зависимости от модели согласования задач ИТ и бизнеса.
Компания Gartner предлагает четыре модели взаимодействия ИТ подразделения с другими подразделениями компании в зависимости от стратегии развития бизнеса (активная или пассивная по отношению к рынку) и роли ИТ-подразделения (тактическая, обслуживающая, или стратегическая, развивающая):
· модель «дворецкий» подразумевает, что ИТ отдел предугадывает потребности бизнеса, не мешает работе основных подразделений, прикладывает минимальные усилия для управления своей внутренней работой, предоставляет дополнительные услуги даже без повышения их оплаты,
· модель «предприниматель» включает полную интеграцию ИТ и бизнеса, управление рисками, акцент на развитие, минимум внимания оперативному руководству,
· модель «мельница» ориентирована на сдерживание затрат на ИТ и повышение надежности функционирования, принятие руководящих решений выглядит как метод самозащиты,
· модель «член команды» предполагает высокую степень согласованности с бизнесом, интегрированность в структуру предприятия, работу в плотном контакте с другими подразделениями, сама работа ИТ ориентирована на бизнес-процесс и достижение результата, ИТ подразделение стремится к повышению ценности ИТ для бизнеса.
На рис. 3.1 представлены возможные варианты расположения подразделения обработки информации в организационной структуре управления предприятием.
Рис. 3.1 Место подразделения обработки информации в организационной структуре управления предприятием
В соответствии с принципом «первый руководителя» наиболее обоснованное расположение подразделения информации соответствует позиции 1, при которой отдел обработки информации, руководимый директором информационной системы (Chief Information Officer, CIO) подчинен непосредственно генеральному директору предприятия.
Такое размещение отдела необходимо для осуществления интегрированной обработки информации, охватывающей все подразделения предприятия.
Иногда в силу исторических причин, связанных очередностью внедрения информатизации отдельных задач управления, подразделение обработки информации находятся в подчинение тех главных специалистов предприятия, к сфере интересов которых относятся функциональные подсистемы ИС. Например, отдел обработки информации может быть подчинен директору по экономике (позиция 2). Так, одной из первых подсистем, внедряемых на предприятии, является подсистема бухгалтерского учета, что может привлечь за собой подчинение отдела обработки информации главному бухгалтеру.
Несмотря на то, что в этих случаях отделы обработки информации находятся на среднем уровне управления, курирующий их главные специалисты не являются профильными специалистами в сфере обработки информации и к тому же загружены своей основной работой.
При «лоскутной» информатизации отдельных комплексов задач, подразделение обработки информации в виде бюро обработки информации оказываются на нижнем уровне управления. В качестве примера можно указать подчинение бюро обработки информации технологическому отделу, что соответствует позиции 3.
Очевидно что, позиции 2 и 3 являются переходными и со временем должны уступить место позиции 1. Наличие выделенного централизованного подразделения обработки информации может сопровождаться присутствием в подразделениях предприятия специалистов обработки информации. В этом случае имеет место матричная структура управления, при которой дисциплинарное подчинение IT-специалистов возлагается на руководителя данного подразделения, а профессиональное руководство осуществляет представитель центрального подразделения обработки информации.
Следует отметить, что в настоящее время приобретает распространение обработка информации на условиях аутсорсинга, в том числе с использованием провайдерских услуг и web серверов приложения (Aplication Service Provider, ASP).
Взаимосвязи ИТ - отдела с другими подразделениями компании регламентируются рядом документов: ИТ - стратегией или аналогичным документом, лицензионной политикой, методиками и регламентами сопровождения и эксплуатации ИС компании, внутрифирменными стандартами управления проектами в сфере ИТ, требованиям по интеграции ИС подразделений компании.
Для управления в области ИТ используются международные стандарты:
· COBIT® (Control Objectives for Information and related Technology),
· CMMI® (Capability Maturity Model Integration),
· ISO/IEC 20000® (International Standardization Organization, IT Service Management),
· ISO/IEC 38500® (International Standardization Organization, IT Governance).
Это попытка дать ответ на вопрос одного “ИТ-шника” (моего хорошего знакомого): “Что за теория такая – ITIL – и зачем мне, работающему с компьютерами профессионально уже -дцать лет, она нужна?”. Поскольку должность его – “Начальник отдела управления информационными системами” – подразумевает некий элемент менеджмента, ответить коротко: “Это не теория и тебе ни к чему” не получилось. Пришлось за рюмкой чая разобраться:
Чем управляем?
“Персоналу шесть душ, локалка на две сотни рабочих мест плюс серверов с десяток, телефония, Интернет-канал…”.
Наверное, такое понимание сферы своей деятельности и объектов управления присуще большинству ИТ-менеджеров, имеющих в подчинении от двух до десятка работников и отвечающих “за все, что с проводами, кроме кофеварки”. Обычно такое описание сферы ответственности устраивает и их руководство – коротко и ясно. Гораздо труднее получить ответ на простой вопрос – “зачем?”. Формулировка отдела ИТ обычно столь же проста сколь и бессодержательна: “Чтоб все работало и юзеры не жаловались.” Руководство со своей стороны далеко не всегда понимает не только чем заняты все эти “компьютерщики”, но и что компании дают сервера, Интернет – вообще все это компьютерное хозяйство кроме разве что ноутбука самого директора. Из-за этого не только затруднено нормальное взаимопонимание между ИТ и руководством компании (например, обсуждение затрат на ИТ упирается в тот же вопрос – “зачем?” – а объяснять директору преимущества клиент-серверной модели занятие зачастую неблагодарное), но и фактическая польза для бизнеса от затрат и усилий ИТ-подразделения неизмеряема, неуправляема и, как следствие, низка.
Говорить о пользе ИТ, выгоде от вложений в информационную инфраструктуру можно только в том случае, если на выходе есть (точнее, виден) некий продукт, вернее, поскольку речь идет о работе с информацией, услуга. Отдел Информатики как, например, и бухгалтерия предоставляет бизнесу услуги. В случае бухгалтерии это выставление счетов, составление необходимой отчетности, анализ финансовх потоков, а в случае ИТ – использование 1С, возможность сетевой печати или доступ в Интернет. К сожалению, руководству трудно самостоятельно сформулировать, какие конкретно ИТ-услуги нужны бизнесу. В такой ситуации ИТ-менеджер – единственный человек, который может (и заинтересован) “наводить мосты” между работой своего отдела и основной сферой деятельности компании. Построение “списка услуг” поможет в первую очередь ему самому – как для того, чтобы обоснованно “пробивать” финансирование или увеличение штата, так и для более эффективной организации труда в подразделении.
Получив благодаря такому списку ответ на вопрос “зачем?”, мы можем по-другому взглянуть на то, чем же все-таки надо управлять. Люди, провода, “железо” – это необходимые инструменты ИТ-менеджера для предоставления бизнесу услуг. Конечно эти инструменты требуют руководства, обслуживания, замен. Но организовывать надо не работу каждой из этих составляющих по отдельности, а использование их как единого целого. Иными словами, управлять предоставлением услуг .
Нужна ли теория?
“Управление услугами – звучит заумно и теоретично. Для книжек по менеджменту оно наверно хорошо, только переходить от всем понятого администрирования локальной сети к какой-нибудь ‘Услуге сетевого доступа’ особого желания нет. В разговорах с руководством можно, конечно, красивыми терминами блеснуть, а вот в реальной работе удобство такого подхода сомнительно.”
Во-первых, речь не идет о том, что надо уволить сисадмина или забыть про правила создания резервных копий. Во-вторых, список услуг, о котором шла речь выше, не главное и уж точно не первое, что имеет смысл брать на вооружение из предлагаемого подхода. Помнить, что ИТ-отдел работает для предоставления услуг, надо в первую очередь для того, чтобы в каждый момент времени ясно понимать: “зачем мы делаем именно это а не иное”. Понимание того, что целью каждой работы, закупки или изменения штатного расписания является польза для бизнеса поможет делать меньше ненужного а необходимое делать лучше.
Как же собственно предлагается планировать, осуществлять, контролировать и оценивать результаты каждодневной деятельности ИТ? В общем и целом – так же, как это уже делается в подавляющем большинстве отделов информатики: работы надо структурировать, объединяя их в группы. Правда, принцип организации таких групп может отличаться от принятого в отделе на данный момент. Конечно, работы по обслуживанию кабельных трасс, настройке протоколов и служб, управлению доменной структурой и т.д. никуда не денутся – это хорошо структурированная последовательность работ, логично объединенная в упомянутый выше процесс администрирования локальной сети. Но всегда ли ваш сетевик готов ради банальной процедуры (например, замена нерабочего сетевого кабеля) отложить увлекательное и высокоинтеллектуальное занятие вроде тонкой настройки листов доступа на маршрутизаторе? Наверное, нет и скорее всего он прав – отвлекаясь на срочные дела, не требующие особой квалификации, он в итоге принесет компании меньше пользы. Подобные рутинные работы поэтому разумно выделить в отдельную группу и создать “отряд быстрого реагирования” (возможно даже из одного человека), задачей которого будет прием заявок от пользователей, оказание им необходимой помощи и ликвидация различных поломок. В случае серьезных аварий, требующих квалифицированного вмешательства, надо наделить эту “службу скорой помощи” правом срочно привлекать других сотрудников к их ликвидации. Таким образом в процесс устранения поломок могут быть вовлечены различные сотрудники, но при этом есть человек, координирующий работы и отвечающий за результат – стабильную работу пользователей.
Основным принципом объединения работ в логически взаимосвязанные последовательности – процессы – предлагается принять наличие у них единой цели. Важно понимать, что при таком подходе мы не учитываем ни существующее распределение работ, ни деление зон ответственности в отделе по технологическому признаку. К достижению цели “любая поломка должна быть ликвидирована в течение часа” могут привлекаться и сисадмин, и ИТ-менеджер, и сторонняя организация. Если мы сможем сформулировать для себя все (или хотя бы основные) цели, в сумме обеспечивающие качественную работу ИТ как поставщика услуг – пол дела сделано. Останется объединить выполняемые работы в группы, каждая из которых ведет к достижению своей цели, и понять, по каким параметрам мы будем оценивать результат каждого такого процесса.
Какие цели и как измерять результат?
“Похоже, ничего оригинального в этом подходе нет. Судя по тому, что мы предоставлением услуг управлять должны, целями у нас они и будут – нормально предоставленные услуги (без перебоев и с хорошими техническими характеристиками). А уж для оценки результатов параметры известны – скорость обработки SQL-запроса, объем Интернет-трафика, время отклика Веб-сервера мерить умеем. Только для каждой услуги процесс строить – не слишком ли неказисто?”
Конечно, неказисто, а главное – не нужно. Нормально предоставляемые услуги – это наша глобальная задача. Для ее решения как минимум надо: чинить то что сломалось как можно быстрее, разрешать возникающие проблемы, точно знать, какое ПО и “железо” у нас есть, иметь правила внедрения нового и замен имеющегося. Ради этих целей – общих для всех услуг – и надо выстраивать процессы. Так что управляем мы не самими услугами (каждой по отдельности), а разными аспектами их предоставления: ликвидацией поломок, разрешением проблем, изменениями в инфраструктуре, ее составом и конфигурацией. Конечно, это далеко не полный список. Надо согласовывать с руководством состав и описание услуг, своевременно готовить планы модернизаций, “считать деньги” и своевременно выявлять “узкие места”, не забывать о безопасности и быть готовым к авариям. Кроме того, как уже говорилось, остаются и операционные процессы (например, управление ЛВС или администрирование СУБД).
Цели у каждого процесса свои – либо непосредственно обеспечивающие должный уровень услуг (например, максимально допустимое время простоя может быть напрямую оговорено в описании услуги) либо “помогающие” другим процессам – точная информация о составе и конфигурации инфраструктуры нужна и при ликвидации поломок и для планирования модернизаций. Но, как уже было сказано, поставить задачу мало – обязательно надо ввести четкие критерии оценки достижения целей.
Такие индикаторы успешности работы процессов должны быть понятны для всех участников (то есть не быть чересчур технически сложными), точно соответствовать цели процесса и быть измеряемыми, то есть мы должны понимать, как конкретно получить числовое значение индикатора. Термины “хорошее”, “быстрый”, “точная” для них недопустимы – нам нужна шкала для измерения, чтобы о любом процессе можно было сказать: “он успешен на 85 процентов”. В каждом случае мы сможем таким образом зафиксировать, к какому результату мы стремимся – например, для управления ликвидацией поломок успехом может считаться: “количество поломок, не исправленных за час, не более пяти процентов от всех случившихся.” Тогда, получив от нашей “службы скорой помощи” статистику по числу поломок и по времени их ликвидации, мы легко оценим успешность по этому параметру. Скорее всего он будет не единственным индикатором для этого процесса – важны также и среднее время исправления и процент поломок, ликвидированных без привлечения дополнительных сотрудников (самим “отрядом быстрого реагирования”). Рассмотренные вместе, значения этих индикаторов говорят нам о качестве выполнения процесса. Поэтому улучшение качества выполнения процесса – это приближение реальных значений индикаторов успешности к целевым. Для того же, чтобы повысить качество всей нашей работы – качество предоставляемых услуг – надо помимо этого “поднять планку” успешности каждого из процессов.
В этом подходе действительно нет ничего оригинального – ориентация на услуги, процессное управление и нацеленность на качество за последние десятилетия стали “общим местом” в менеджменте. Удобство его использования в том, что он содержит готовый набор “подсказок”, основаный на опыте управления ИТ в реальных организациях.
Я уже попытался дать ответ на вторую часть вопроса: “Что за теория такая – ITIL – и зачем она нужна?”.
Если от многократно повторенных слов вроде “услуга”, “процесс”, “качество” еще не уснули, а интерес к тому, каково же оно “в деле”, поввился, обсудим сперва:
Что же все-таки такое этот ИТИЛ?
“Набор подсказок – это, конечно, хорошо, но от подхода к управлению желательно системность получить. И что это за организации, которые свой опыт в свободный доступ выложили? И в каком виде это сделано?”
К сожалению или, скорее, к счастью ИТИЛ (или если уж по-русски БИИТ – Библиотека Инфраструктуры ИТ) особой системностью не отличается. Это не методология, не пошаговая инструкция, что и как надо делать. В первой редакции Библиотека состовла из примерно 40 книг, описывающих разные процессы или аспекты применения этого подхода. Во второй редакции, действующей на данный момент, процессы объединены в группы и по каждой из них выпущена (или вот-вот поввится) отдельная книга.
Официальный автор – британская правительственная организация OGC (Office of Government Commerce), изначальной задачей которой было помочь гос. структурам в формализации их отношений с подрядчиками – поставщиками ИТ-услуг. В Великобритании даже действует официальный стандарт на Управление Услугами (BS 15000), который базируется на ITIL. Хотя формальное авторство принадлежит OGC, в написании участвуют представители и организаций-заказчиков, и поставщиков, и консультантов. В книгах описываются группы процессов (например, Поддержка Услуг – Service Support), объединенные по принципу нахождения на шкале “Технология – Услуги”. Ключевыми считаются две группы – Поддержка и Доставка (Delivery) Услуг.
Про каждый процесс говорится: какими терминами пользуемся, его цели, входы и выходы, функции и роли, связь с другими процессами, деятельности, индикаторы успешности, методы контроля, затраты и выгоды, возможные сложности и советы по внедрению. Хотя в написании авторы базировались на реальном опыте работы, никакой организационной специфики в этих моделях нет. С одной стороны, в этом огромный плюс – отсутствие привязки к конкретным структурам дает возможность использовать ITIL не только в британских государственных организациях, но и в ИТ-компаниях и подразделениях любой формы собственности по всему миру. С другой стороны, для практического внедренения приходитсв либо использовать какую-либо методологию (то есть платить вендору или консультанту), либо внедрять “по собственному разумению”, что требует дополнительных затрат и увеличивает риск неудачи.
Как это реализуется на практике?
“Были бы деньги на консультантов – у них и спрашивал бы. А риск неудачи есть всегда, так что будем пытаться своим умом доходить. Только с чего начинать-то? И что делать с текущей работой?”
Начинать (что вполне естественно) надо с чтения книг Библиотеки. К сожалению, на данный момент переводов на русский нет, а за оригинальные книги придется выложить около 150 долларов за штуку. Альтернативой (во всяком случае, на первом этапе) может быть покупка за 38 долларов “Введения в ITIL” (IT service management – An introduction) издания itSMF (Форума по Управлению Услугами ИТ, объединяющего теоретиков и практиков ITIL). Кстати, уже идут работы по переводу этой книжки на русский. При наличии хотя бы небольшого бюджета также очень желательно сходить на 2-3дневные курсы по основам ITIL – книжки книжками, а общение с практиками дорогого стоит. И конечно очень многое можно почерпнуть в Чети – полная картина при только ее использовании вряд ли сложится, но полезностей можно найти немало.
Когда знания начнут переполнвть – пора начинать ими делиться. Может быть самым важным во внедрении ITIL явлвется изменение психологии сотрудников ИТ, их переориентация с “работы с железками” на “обслуживание Клиента”. На это нельзя жалеть ни времени ни усилий. До тех пор, пока слова “услуга”, “процесс” и “качество” не станут в ИТ-отделе привычными и незаменимыми, никакав формализация процедур ничего не даст. Важно, чтобы сотрудники воспринимали “предоставление услуг” не как дополнительную работу, а как способ оптимизации (в том числе и в их интересах) всей существующей деятельности. Измениться должна также и оценка качества выполнения задач как отдела в целом, так и каждого отдельного работника. Надо стараться меньше говорить о том что “сеть ни разу за год не легла” (хотя это конечно существенно), и чаще спрашивать себя “довольны ли пользователи”?
Текущая работа действительно никуда не денется. Более того, пока она нормально не налажена переходить скажем к уровню Доставки Услуг бессмысленно – доставлять нечего. Так что начинать (если это еще не сделано) надо с технического (Technical) и операционного (Operations) уровней. Естественно в ITIL по ним тоже есть описания процессов, но на этих уровнях, в отличие от Поддержки и Доставки Услуг, достаточно опытный, технически грамотный и нормально образованный ИТ-менеджер может построить “правильные” процессы сам, руководствуясь профессиональными знаниями и интуицией. Надо только не забывать о “трех китах” – пользоваться процессным подходом, вводить (и применять) критерии оценки качества и в каждый момент оценивать, зачем нужна (и какую пользу приносит бизнесу) конкретная железка, канал данных, программа, резервная копия.
Если о наличии бэкапов голова уже не болит, а сбой ПК стал явлением редким – настала пора ИТ-отделу выстраивать взаимоотношения с “внешним миром”. И в превую очередь с теми, без кого его функционирование невозможно – с внутреними и сторонними поставщиками внешних для ИТ услуг. Во многих реализациях ITIL Управление Окружением (Environmenal Management) считается фундаментом функционирования всей информационной системы. Действительно электрика, вентилвция, кондиционирование, обычно не входвщие в сферу ответственности ИТ-отдела, влияют на его работу принципиально. Поэтому пока нет спокойствия и уверенности в этих вопросах – двигаться дальше опасно.
Когда решена и эта задача, можно наконец переходить к реализации первой функции из ITIL-овского блока Поддержки Услуг – создать в отделе Центр Обслуживания. Это еще не реализация какого-то процесса (в Service Support описаны пять процессов и одна функция – function – Service Desk), но в поддержке услуг – один из ключевых элементов. Центр Обслуживания (иногда его называют Help Desk) должен стать единой точкой контакта отдела с “внешним миром”. Таким образом решаются две задачи. Во-первых, это упростит жизнь пользователям – всегда будет к кому обратиться и человек “на телефоне” не сошлется на то, что ему “не до мелочей”. Во-вторых, появлвется возможность фиксировать, документировать и измерять поток работ, выполняемый отделом ИТ. Этим будет сделан первый шаг во внедрении блока процессов Поддержки Услуг.
Что теперь и куда дальше?
“Создать единую точку доступа – хорошая мысль, но ведь человека выделить придется. А потом еще под каждый процесс – отдельного? А где отдача? И как собственно процессы внедрять?”
Трудно однозначно сказать, приведет ли применение ITIL к увеличению потребности в ресурсах (в том числе кадровых) или нет. Это зависит как от уровня зрелости ИТ-отдела до начала внедрения (если он низок, то оптимизация работ может даже привести к их высвобождению) так и от “глубины” внедрения. Но даже если дополнительные ресурсы на каком-то этапе потребуются, не надо забывать о повышении общего качества работы ИТ. Это именно тот козырь, с помощью которого можно “выбивать” деньги у руководства. К сожалению, пока не измеряется качество услуг или хотя бы удовлетворенность пользователей (а это нереально без Центра Обслуживания), цифр и фактов для аргументации нет. Поэтому на этапе создания Центра Обслуживания придется либо обойтись внутреними ресурсами (могли появиться в процессе оптимизации операционного уровня) либо разработать и представить руководству план по реструктуризации отдела (например, берем дополнительного – дешевого – человека на ЦО, оптимизируем работу, через девять месвцев одного из двоих сисадминов сокращаем). Но в любом случае нужен среднесрочный (примерно на год-полтора) план внедрения.
“Кадры решают все”. Продумывав план “ITIL-изации” отдела надо в первую очередь оценить, кто из сотрудников более склонен к аналитической работе, кого можно “допускать до пользователей”, а кому вы можете доверить работу, требующую максимальной педантичности. При этом надо ориентироваться не столько на профессиональные навыки сколько на человеческие качества. Исходя именно из этой оценки выбирайте владельцев процессов. Они будут вместе с вами “выстраивать” процессы, а потом контролировать и улучшать их работу. В выполнение конкретных процедур будут вовлечены и другие сотрудники (в том числе и владельцы других процессов), но отвечать должен он один. При этом ничто не мешает при распределении ответственности и полномочий совмещать разные функции и роли в одной должностной инструкции. Один и тот же сотрудник может быть владельцем одного или нескольких процессов и исполнителем – в других. Даже в отделе из двух человек в принципе возможно “поделить” между собой базовые процессы ITIL – причем с реальной пользой для дела. Если же ИТ-отдел состоит хотя бы из четырех человек распределение ответственности за процессы пройдет как по маслу.
Для того, чтобы все эти управленческие телодвижения приносили удовлетворение вам и были оценены руководством, нужны “быстрые победы”. На этапе оптимизации операционного уровня это регламентация плановых работ (а соответственно повышение их “прозрачности” и четкое планирование). В результате ИТ-менеджеру уже не будут сниться кошмары на тему “А что если PDC ляжет?!” – теперь у него есть регламентный бэкап, процедура восстановления и ответственный сотрудник. В создании Центра Обслуживания главная выгода – появление точки сбора информации обо всех событиях, происходящих в ИТ. Как результат через два – три месяца вы будете иметь статистику по обращениям пользователей, с которой уже можно идти к руководству с предложением о путях снижения их количества. Это уже те самые “цифры и факты”, которые помогают ИТ в разговоре с Бизнесом. С этого и начинается выстраивание отношений “Поставщик – Заказчик”.
Кажется, теперь можно было бы и о внедрении процессов поговорить. Но если до сих пор рассказывать об ITIL можно было на “кухонном” уровне, тут уже требуется строгость определений и формулировок, знание терминологии и т.д. Поэтому настал момент погулять по Сети, а лучше всего сразу заказать книги Библиотеки. Не забывайте также о ценности вербального общения – курсы и семинары бесценный источник знаний. Успехов в ITIL-изации!
Процессы.
Определения.
“Раз ИТИЛ – процессный подход, надо наверно четко описать, а лучше определить – что же такое процесс?”
Можно, конечно, заглянуть в толковый словарь и прочесть там что-то вроде:
- последовательная смена состояний, каких-л. явлений, ход развития чего-л.;
- совокупность последовательных действий для достижения какого-л. результата, напр. производственный п.
Это в общем то и так “интуитивно ясно”. Однако из п.2 мы видим, что помимо “процессов вообще” есть например производственный процесс, так что надо идти глубже, чтобы понять специфику именно ИТИЛовских процессов и получить “рабочее” определение. В нем, во-первых, должно быть собрано специфичное для ИТИЛ содержание (в частности, нацеленность на услуги и качество) и во-вторых, дано внутренее строение и внешние связи.
Итак, начнем изыскания. Наиболее общее определение дает нам ГОСТ Р ИСО 9000 – 2001 : “Процесс – совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы.
В ITIL – точнее в книге “Service support” (“Поддержка услуг”) приводится следующее определение: “A connected series of actions, activities, Changes etc. performed by agents with the intent of satisfying a purpose or achieving a goal.” (“Связанный набор действий, видов деятельности, изменений и т.д., выполняемый агентами с целью удовлетворения потребности или достижения цели.” )
Здесь добавилась важная для понимания процессов составляющая – агенты. Кроме того, вместо выходов (про которые забывать не надо, поскольку при проектировании процесса их придется выделять и специфицировать) упомянуто, что у процесса есть некая цель.
Вот еще одно (CobiT ): “Процесс – это действие, направленное на достижение результата, которое может корректироваться при его выполнении и которое сосредоточенно на достижении конечного результата при оптимальном использовании ресурсов.”
Отсюда мы можем взять две вещи: процесс должен управляться (корректироваться) и его надо строить оптимально.
Можно наверно найте полезные зерна и в других источниках, но большинство так или иначе повторяют уже сказанное. Например в PMBOK 2000 edition читаем: “series of actions bringing about a result” . Так что перейдем к тому, из чего он состоит. Предлагается такое деление процесса на составляющие:
- подпроцесс (subprocess) – является частью процесса, но не теряет его свойств
- деятельность (activity) – набор действий выполняемых одной ролью
- действие (action) – атомарная единица процесса
Кроме того, надо не забыть о том, что процессы надо как-то описывать. Для этого существует процедура – описание логически связанных деятельностей и их исполнителей (для большей детализации и удобства обычно составляют набор Рабочих инструкций, которые определяют, как следует выполнять виды работ, входящие в состав процедур).
И, наконец, помимо ролей для каждого процесса важно определить владельца (именно он отвечает за него, имеет право его менять и т.д.) и менеджера (он осуществляет “оперативное управление”). Конечно это тоже роли, но роли специфические и очень важные. Они должны быть четко определены для каждого процесса, даже если выполнять их будет один человек.
Постараемся теперь ничего не потерять но и без лишнего обойтись:
Процесс – это цикличный и воспроизводимый набор логически связанных деятельностей, направленных на достижение общих целей, описанных процедурами и исполняемых менеджером процесса и другими ролями (агентами) с использованием выделенных ресурсов, управляемый владельцем для оптимизации по затратам с использованием измеряемых характеристик (метрик), который преобразует определенные входы в контролируемые по качеству выходы.
(Process – a cyclic and reproduced set of logicaly related activities connected by general targets, described by procedures and performed by process manager and other roles (agents) using allocated resources, controlled by the owner to be optimal in efforts and costs using measured indicators (metrics), which convert specified inputs into the quality controlled outputs.)
Возможно, результат получился громоздким, но зато теперь мы знаем, что такое процесс “по-ИТИЛовски”.
Методика внедрения процессов.
“Определение внушительное. Только из него все равно не ясно, как процессы эти создавать, в смысле выстраивать.”
Попробуем кратко прикинуть, в каком порядке и что именно надо делать, чтобы “построить” ИТИЛовский процесс.
- Вначале необходимо для процесса определить цели (с ключевыми факторами успеха для первой стадии), входы-выходы, ресурсы, политики.
- Затем составить список процедур (для них – входы-выходы, цель, контроль)
- Далее – шаблоны информационных ресурсов (к примеру – что должно быть в любом trouble ticket), первая версия справочников (к примеру – типы service call, статусы инцедентов, etc).
- Наконец – подробное (пусть черновое, но чтоб по ним работать можно) описание процедур и базовое описание ролей.
- Все, можно “вводить в эксплуатацию” и заниматься:
- корректировкой написанного
- уточнением процедур и ролей
- написанием рабочих инструкций.
Последовательность внедрения ITIL-процессов.
“Отлично, можно приступать. Начинать наверно надо с Процесса Управления Услугами – он ведь ключевой.”
Действительно Управление Услугами – в своем роде “центральное звено” для всех ИТИЛовских процессов. В создающейся “с нуля” организации или подразделении начинать именно с него может быть правильно. Но для уже функционирующей структуры это не лучший путь. Перед тем, как ответить себе на вопрос “за какой процесс браться в первую очередь”, надо понять “что имеем”, то есть оценить степень зрелости как всего ИТ в целом, так и групп процессов управления ИТ. Конечно, для оценки группы процессов придется рассматривать каждый, но для того, чтобы решить, с какого процесса начинать, нужна интегральная оценка зрелости групп.
Методик оценки зрелости существует немало и здесь не место обсуждать их и сравнивать. Предположим, что выбрана некая методика, проведена оценка и на выходе у нас для каждого процесса – балл от 0 до 5. Теперь надо рассмотреть оценки по группам (Operational, Support, Delivery). Если в группе Операционных процессов есть хоть один с баллом ниже тройки – забудьте временно про “отношения Бизнеса и ИТ” и прочие высокие слова – подготовьте себе тылы (в данном контексте под Операционными процессами имеется ввиду все то, что называют Technical, Operations, а также Environmenal Management). Однако не надо забывать о следующей цели – уровне Поддержки Услуг. На нем есть бесценная функция – Центр Обслуживания, которая может помочь и на этапе приведения в порядок операционного уровня. Итак, первый шаг при таком раскладе – создание Центра Обслуживания и “”доведение до ума группы операционных процессов (внутри нее – Technical => Operations => Environmenal, подробнее – зависит от используемых технологий).
Говоря о группе процессов Поддержки Услуг, можно предложить такой порядок: сперва Управление Инцидентами и Проблемами (вместе с “причесыванием” Центра Обслуживания), затем Изменения, потом Конфигурации и Релизы. Опять же надо помнить о следующей цели – Доставке Услуг – и параллельно с процессами уровня Поддержки хотя бы контурно обозначить рамки и содержание Процесса Управления Услугами.
Заработав минимум по три балла процессам поддержки, можно довести до ума Управление Услугами и … сделать шаг в сторону от доставки услуг, задумавшись над тем откуда они (услуги) берутся. Конечно если в вашей организации набор сервисов крайне стабилен и с его изменением вполне справляется операционный уровень – можете не волноваться. Если же время от времени присутствует некий development – самое время заняться именно им. Так что следующий шаг – Production Management.
Если вы добрались до этой стадии – наверно сами разберетесь, в каком порядке внедрять Availability, Capacity и Continuity Management. А Управление Финансами советую оставить “на сладкое” – с него плавно перейдете на Business – IT alignment, займете место CIO…
Все вышесказанное относится в первую очередь к тем ИТ-структурам, в которых идея жить по-ИТИЛовски идет “изнутри”. Если же к вам “сверху” пришло указание <<внедрить SLA за три месяца>> – деваться некуда, порядок внедрения будет совсем другой. Кроме того, это только общие принципы, описывать же порядок для всех вариантов результата оценки зрелости – за отдельные деньги. А тонкостей может всплыть немало. Например, если процесс Service Continuity Management получил ноль баллов – бросьте все и готовьтесь к пожару-наводнению-землетрясению. Так что изучайте внимательно best practice.
И не забывайте – ITIL <=> IMHO
🙂