1. Ключевые факторы успехов
ITSM-проектов
3 июня 2011 год
Алматы

2. О чем поговорим
1. Что такое ITSM-проекты, зачем они нужны,
жизненный цикл проекта ?
2. Основные риски ITSM-проекта
3. Внедрение своими силами или силами
консультантов
4. Рекомендации по выбору продукта,
поставщика
5. Вопросы, обсуждение

3. Компания NAUMEN сегодня
→ 9 лет на рынке программных решений для бизнеса и органов
власти
→ Более 650 проектов реализованных проектов для более чем
500 заказчиков на базе продуктов NAUMEN
→ Свыше 200 сотрудников, из них 100 разработчиков
→ Офисы в Москве, Екатеринбурге, Твери, Челябинске, Киеве
→ Активный участник в развитии российской ИТ-отрасли

5. Почему нам можно доверять?
1. 230 выполненных проектов в области
управления ИТ на базе продукта Naumen
Service Desk
2. 90% успешных проектов
3. 75% проектов получили развитие
4. Более 3 тысяч рабочих мест ИТ-
специалистов
5. Более 3 млн. поддерживаемых
пользователей
6. Сертификация PinkVerify на соответствие
ITIL v.3

6. Некоторые из проектов за 10-11 год
Промышленность
и энергетика
Финансовый
сектор
Сервисные компании
Телекоммуникации
Проектные институты

8. Инвестиции в развитие ИТ
Инвестиции в ИТ Многократный
60%
50%
рост инвестиций
40%
в ИТ!
30%
20%
10%
0%
2001
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2002
2003
2004
2005
2006
2007
2008
2009
2010
Доля инвестиций тренд
Плюсы: Минусы:
1. Скорость процессов 1. Рост парка инфраструктуры
2. Улучшение взаимоотношений с 2. Сложность и неоднородность
клиентами среды ИТ
3. Автоматизация операционной 3. Дорогостоящая поддержка
деятельности

9. Операционная деятельность по поддержке
ИТ-инфраструктуры
Операционные расходы в Рост операционных
бюджете ИТ
60%
50%
расходов не отстает!
40%
30%
20%
10%
0%
Операц. бюджет Полиномиальная (Операц. бюджет)
Составляющие расходов: В результате:
1. Затраты на рабочую силу 1. Сокращение инвест-проектов в
2. Затраты на поставщиков пользу сопровождения
3. Затраты на телеком услуги 2. Штат больше направлен на
сопровождение, чем на развитие
3. Бизнес в плену у ИТ

10. Понимание проблем поддержи инфраструктуры
и предоставления ИТ-сервисов
Бизнес:
Почему такие затраты на ИТ? CIO:
Насколько эффективно Как же обосновать ИТ-бюджет?
используется инфраструктура? Сколько стоит наши ИТ-сервисы?
Как оптимизировать Нужны ли нам доп. Мощности?
операционные расходы?
ИТ-служба:
Какой проблемой мне заниматься?
А почему я должен заниматься?
Пользователи подождут
Интересно что у него за HDD?
А есть ли у нас свободные
лицензии Win’07?
Пользователь:
И к кому мне обращаться?
Интересно долго ли будут
решать проблему?
Надоело мне это, пойду-ка я
домой

11. Проблемы в управлении ИТ
О проблемах вы знаете
больше и лучше нас!
Мы же знаем,
какие шаги нужно
сделать для их решения!

13. История ITIL
• Правительство Великобритании – родина и первое внедрение ITIL
→ ITIL (IT Infrastructure Library) –
Библиотека лучших мировых практик по
реализации процессного подхода для
управления ИТ. Развивается более 30 лет.
→ Библиотека ITIL описывает подход к IT как
сервисной организации (ITSM, IT Service
Management).
В основе Naumen Service Desk – лучшие мировые практики
и российский опыт.

14. ITSM
ITSM (IT Service Management) — процессный подход к
предоставлению информационных технологий и
обеспечению их использования.
ITSM рекомендует сосредоточиться на требованиях бизнеса, а
не на самих технологиях.
Ключевые понятия ITSM:
1. ИТ-сервис (IT Service)
2. Соглашение об уровне предоставления сервиса (SLA)

15. Сервисный подход
Служба ИТ
провайдеры, поставщики
Бизнес подразделения
Каталог ИТ услуг
Внешние сервис-
ИТ услуги
Администрирование
Информационная
сетей и систем
Обслуживание
рабочих мест
безопасность
приложений
Разработка Договора с внешними
Поддержка
SLA –
соглашение об поставщиками и
уровне услуг подрядчиками
Требования к работе подразделений
службы ИТ и инфраструктуре
Процессы предоставления и поддержки ИТ услуг

16. Еще раз коротко о главном
ITSM – концепция организация работы и взаимодействий ИТ -
подразделения внутри и с внешним миром
Ключевые моменты концепции
- ИТ предоставляет сервисы и мотивируется на предоставление
качественных сервисов.
- Работа ИТ организуется и управляется посредством
процессов.
ITSM – это подход к управлению. Проекты затрагивают людей и
заставляют их меняться.
Результат ITSM проекта – комплексная система управления ИТ,
которая позволит решить поставленные задачи в управлении
ИТ

17. На что можно рассчитывать в
результате ITSM - проекта
На уровне компании:
• улучшаются показатели предоставления ИТ-сервисов
(быстрее, дешевле, понятнее)
• стандартизируются корпоративные процедуры (четкие
процессы)
• повышается прозрачность деятельности ИТ-отделов
(единое информационное пространство)
• направляется к общекорпоративным целям работа ИТ-
департамента (ИТ – партнер, а не «черный ящик»)
• повышается инвестиционную привлекательность
компании (возможность сертифицироваться на ISO
20000)

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

20. Несколько основных групп Рисков:
1.Инициация проекта
2.Проектирование и внедрение
процессов
3.Работа с людьми
4.Автоматизация

21. Инициация проекта
Инициация = обоснование + планирование
Инициируйте и обосновывайте внутри только то, во
что верите сами:
1. Мода еще не повод
2. Повышение качества управления, на него
никогда не вредно потратить время и силы
3. Цель должна быть важной, не важно в
терминах бизнеса или ИТ

22. Цели ITSM-проекта. Примеры
Плохие цели:
• Внедрить процесс управления xxx
• Купить Service Desk (хотя смотря с какой стороны смотреть )
Хорошие цели:
• Получить возможность
управлять/измерять/сравнивать и улучшать
деятельности конкретного сервиса
• Навести порядок в ИТ-подразделении, повысить
качество обслуживания пользователей
• Инвентаризация ИТ- активов, учет лицензий
• Выявить корневые проблемы в инфраструктуре

23. Несколько практических рекомендаций
SMART (Specific, Measurable, Agreed, Realistic, Time-related )
- Однозначно понятная
- Измеримая
- Достижимая
- Ориентированная на результат
- Ограниченная по времени
Аккуратно определяйте границы охвата.
Лучшее не значит большее

24. Чеклист инициатора ITSM-проекта
5 главных вопросов
• Поставлены ли цели, понимают ли их участники проекта
• Учитывает ли проект интересы всех заинтересованных
сторон
• Существуют ли в компании базовые инструменты
управления
• Есть ли понимание, как принимаются решения и кто за
что отвечает
• Выделены ли ресурсы, в том числе на «после того, как
будут подписаны акты»
Цель определена! Необходимо выполнять проект!

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

26. Автоматизация
«Серебряной пули» не существует
Гибкий инструмент позволит развиваться
- Проектное ТЗ это не конец – это только начало
- Поиск «золотой середины» между платформой и готовым
продуктом
- Готовый продукт позволит быстро начать работать
Не стоит основываться только на фича-листах
- Формируйте реальные сценарии использования – они выявят
отличия
- Обращайте внимание на мелочи

28. Посмотреть на себя
Сколько ИТ специалистов?
+ распределенная структура, холдинговые компании
+ наличие ключевых для бизнеса ИТ - сервисов
+ большое количество однотипных распределенных инфраструктурных
объектов
+ достаточно грамотные пользователи, требовательные к ИТ
+ предоставление внешних ИТ - сервисов
«Специальные» случаи:
 Миграция с продуктов, функциональности которых не хватает или
снятых с поддержки производителем
 Сертификация на ISO 20000 или другой стандарт качества сервиса
 Международные компания, требования аудита

29. Сравнение систем разных классов
Коробочные Конструкторы
решения
Масштаб До 10 ИТ специалистов От 10 ИТ специалистов
Структура Отсутствие распределенной Распределенная структура
структуры
Планы Понятный круг задач, Необходима возможность
планы по развитие развивать процессы
отсутствуют
Функции Есть внутренние ресурсы Система должна уметь гибко
на доработку, возможно настраиваться и иметь
отказаться от обновлений развитое API
Нагрузка Низкая нагрузка на систему Архитектура под средние и
высокие нагрузки
Документация Низкие требования к Детальное документирование
документированию
Опыт Низкие требования к Наличие референсов в
референсам вашей области

30. Важно не забыть про…
1. Концепция продукта технологическая и архитектурная
2. Схема лицензирования
3. Удобство эксплуатации
4. Функциональность
5. Соответствие процессов ITIL
6. Документация язык, полнота
7. Работы, которые возможно сделать на продукте
8. Опыт интегратора
9. Техническая поддержка

31. Почему не стоит разрабатывать
систему самостоятельно?
1. Инвестирование в непрофильную деятельность.
2. Функциональности системы требуется всѐ больше, а писать ее нет
сил и времени.
3. Разработка без теоретических знаний и практического опыта.
4. Риск ухода разработчика.
5. Риск выхода системы из строя.
6. Качество кода.
7. Отсутствие пользовательской документации.
8. Отсутствие API.
9. Программист не внедренец.
10. Старт начала работы и внедрение сервисного подхода
откладывается во времени.
11. Итоговая стоимость самописной системы будет выше,

33. Выбор внешнего консультаната
1. Наличие референсов
2. Присутствие в штате поставщика специалистов всех
категорий (не только консультантов)
3. Готовность сделать рефенс-кол, референс визит
4. Готовность выполнить пилотный проект
5. Готовность предоставить документы
6. Опыт команды, которая будет делать проект у Вас
7. Наличие сервисного центра, SLA сервисного центра
Не выбирайте по цене! Цена не говорит ни о чем, пока Вы не
привели состав предложений к единому знаменателю.

34. Как еще минимизировать риски?
Пилоты, Триалы, Референсы и… техподдержка
1. Требуйте у поставщиков тестовые версии
2. Делайте пилотные проекты
3. Постарайтесь увидеть работающую систему и
поговорить с людьми, которые с ней работали
4. Сервисный центр поставщика работает со своей
системой? А он есть вообще?

36. С точки зрения организации работы
Внутри в компании
1. Выделенный внутри сотрудник должен обладать общей
компьютерной грамотностью, желателен опыт внедрения
систем автоматизации
2. Сотрудник должен быть увлечен идеей ITSM и обладать
характером исследователя и желанием довести дело до конца
3. Сотрудник должен обладать влиянием внутри компании или
иметь поддержу у высшего руководства
4. Должен быть выделен временной ресурс, если проектном
заниматься по остаточному признаку ничего не получиться
5. Должен быть план действий, а не просто «решили что надо –
купили софт - внедрили».
Поставщик
1. Не должен только отгрузить продукт и забыть про вас

37. Спасибо, вопросы?
За дополнительной информацией
обращайтесь:
+7 (495) 783-02-87
www.naumen.ru
drubin@naumen.ru
sales@naumen.ru
А ТАКЖЕ К НАШИМ ПАРТНЕРАМ