Ключевые факторы успехов

ITSM-проектов

3 июня 2011 год

Алматы

О чем поговорим

1. Что такое ITSM-проекты, зачем они нужны,

жизненный цикл проекта ?

2. Основные риски ITSM-проекта

3. Внедрение своими силами или силами

консультантов

4. Рекомендации по выбору продукта,

поставщика

5. Вопросы, обсуждение

Компания NAUMEN сегодня

→ 9 лет на рынке программных решений для бизнеса и органов

власти

→ Более 650 проектов реализованных проектов для более чем

500 заказчиков на базе продуктов NAUMEN

→ Свыше 200 сотрудников, из них 100 разработчиков

→ Офисы в Москве, Екатеринбурге, Твери, Челябинске, Киеве

→ Активный участник в развитии российской ИТ-отрасли

1. 230 выполненных проектов в области управления ИТ на базе продукта NaumenService Desk

2. 90% успешных проектов

3. 75% проектов получили развитие

4. Более 3 тысяч рабочих мест ИТ-специалистов

5. Более 3 млн. поддерживаемых пользователей

6. Сертификация PinkVerify на соответствие ITIL v.3

Почему нам можно доверять?

Некоторые из проектов за 10-11 год

Промышленность

и энергетика

Финансовый

сектор

Сервисные компании

Телекоммуникации

Проектные институты

Инвестиции в развитие ИТ

Многократный

рост инвестиций

в ИТ!

0%

10%

20%

30%

40%

50%

60%

1990

1991

1992

1993

1994

1995

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

2010

Инвестиции в ИТ

Доля инвестиций тренд

Плюсы:

1. Скорость процессов

2. Улучшение взаимоотношений с

клиентами

3. Автоматизация операционной

деятельности

Минусы:

1. Рост парка инфраструктуры

2. Сложность и неоднородность

среды ИТ

3. Дорогостоящая поддержка

Операционная деятельность по поддержке

ИТ-инфраструктуры

Рост операционных

расходов не отстает!

Составляющие расходов:

1. Затраты на рабочую силу

2. Затраты на поставщиков

3. Затраты на телеком услуги

В результате:

1. Сокращение инвест-проектов в

пользу сопровождения

2. Штат больше направлен на

сопровождение, чем на развитие

3. Бизнес в плену у ИТ

0%

10%

20%

30%

40%

50%

60%

Операционные расходы в бюджете ИТ

Операц. бюджет Полиномиальная (Операц. бюджет)

Понимание проблем поддержи инфраструктуры

и предоставления ИТ-сервисов

Пользователь:

И к кому мне обращаться?

Интересно долго ли будут

решать проблему?

Надоело мне это, пойду-ка я

домой

Бизнес:

Почему такие затраты на ИТ?

Насколько эффективно

используется инфраструктура?

Как оптимизировать

операционные расходы?

CIO:

Как же обосновать ИТ-бюджет?

Сколько стоит наши ИТ-сервисы?

Нужны ли нам доп. Мощности?

ИТ-служба:

Какой проблемой мне заниматься?

А почему я должен заниматься?

Пользователи подождут

Интересно что у него за HDD?

А есть ли у нас свободные

лицензии Win’07?

Проблемы в управлении ИТ

О проблемах вы знаете

больше и лучше нас!

Мы же знаем,

какие шаги нужно

сделать для их решения!

История ITIL

• Правительство Великобритании – родина и первое внедрение ITIL

→ ITIL (IT Infrastructure Library) –

Библиотека лучших мировых практик по

реализации процессного подхода для

управления ИТ. Развивается более 30 лет.

→ Библиотека ITIL описывает подход к IT как

сервисной организации (ITSM, IT Service

Management).

В основе Naumen Service Desk – лучшие мировые практики

и российский опыт.

ITSM

ITSM (IT Service Management) — процессный подход к предоставлению информационных технологий и обеспечению их использования.

ITSM рекомендует сосредоточиться на требованиях бизнеса, а не на самих технологиях.

Ключевые понятия ITSM:

1. ИТ-сервис (IT Service)

2. Соглашение об уровне предоставления сервиса (SLA)

Сервисный подход

Служба ИТ

Разр

аб

отк

а

Об

сл

уж

ива

ни

е

ра

бочи

х м

ест

Под

де

рж

ка

пр

ил

ож

ени

й

Ад

ми

ни

стр

ир

ова

ни

е

сете

й и

си

сте

м

Инф

ор

ма

ци

онна

я

безо

па

сно

сть

ИТ услуги

Би

знес п

од

разд

ел

ения

Внеш

ние с

ервис-

провайд

еры

, поста

вщ

ики

SLA –

соглашение об

уровне услуг

Договора с внешними

поставщиками и

подрядчиками

Требования к работе подразделений

службы ИТ и инфраструктуре

Процессы предоставления и поддержки ИТ услуг

Каталог ИТ услуг

Еще раз коротко о главном

ITSM – концепция организация работы и взаимодействий ИТ -

подразделения внутри и с внешним миром

Ключевые моменты концепции

- ИТ предоставляет сервисы и мотивируется на предоставление

качественных сервисов.

- Работа ИТ организуется и управляется посредством

процессов.

ITSM – это подход к управлению. Проекты затрагивают людей и

заставляют их меняться.

Результат ITSM проекта – комплексная система управления ИТ,

которая позволит решить поставленные задачи в управлении

ИТ

На что можно рассчитывать в результате ITSM - проекта

На уровне компании:

• улучшаются показатели предоставления ИТ-сервисов (быстрее, дешевле, понятнее)

• стандартизируются корпоративные процедуры (четкие процессы)

• повышается прозрачность деятельности ИТ-отделов (единое информационное пространство)

• направляется к общекорпоративным целям работа ИТ-департамента (ИТ – партнер, а не «черный ящик»)

• повышается инвестиционную привлекательность компании (возможность сертифицироваться на ISO20000)

На что можно рассчитывать в результате

На уровне ИТ:

• навести порядок и сделать ИТ-подразделение управляемым;

• возможность обоснования инвестиций и расходов в инфраструктуру;

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

• сокращение сбоев и времени их устранения в ИТ-инфраструктуре;

• повышение удовлетворенности пользователей, что зачастую является самым болезненным моментом;

Несколько основных групп Рисков:

1.Инициация проекта

2.Проектирование и внедрение

процессов

3.Работа с людьми

4.Автоматизация

Инициация проекта

Инициация = обоснование + планирование

Инициируйте и обосновывайте внутри только то, во

что верите сами:

1.Мода еще не повод

2.Повышение качества управления, на него

никогда не вредно потратить время и силы

3.Цель должна быть важной, не важно в

терминах бизнеса или ИТ

Цели ITSM-проекта. Примеры

Плохие цели:

• Внедрить процесс управления xxx

• Купить Service Desk (хотя смотря с какой стороны смотреть )

Хорошие цели:

• Получить возможность

управлять/измерять/сравнивать и улучшать

деятельности конкретного сервиса

• Навести порядок в ИТ-подразделении, повысить

качество обслуживания пользователей

• Инвентаризация ИТ- активов, учет лицензий

• Выявить корневые проблемы в инфраструктуре

Несколько практических рекомендаций

SMART (Specific, Measurable, Agreed, Realistic, Time-related )

- Однозначно понятная

- Измеримая

- Достижимая

- Ориентированная на результат

- Ограниченная по времени

Аккуратно определяйте границы охвата.

Лучшее не значит большее

Чеклист инициатора ITSM-проекта

5 главных вопросов

• Поставлены ли цели, понимают ли их участники проекта

• Учитывает ли проект интересы всех заинтересованных

сторон

• Существуют ли в компании базовые инструменты

управления

• Есть ли понимание, как принимаются решения и кто за

что отвечает

• Выделены ли ресурсы, в том числе на «после того, как

будут подписаны акты»

Цель определена! Необходимо выполнять проект!

Процессы

Регламенты есть в Интернете

- Типичная ошибка: «внедрим мы сразу 7 процессов»

- Процессы это не документы, это в первую очередь

выстроенное взаимодействие, которое можно измерять и

улучшать

Не бывает внедрений «под ключ» без участия

заказчика

- Никто за Вас не начнет работать по другому

- Вешний консультанта не позволит сделать вам ошибок, и

направит в нужное русло

Процессы это люди. Учите людей!

- Внедрение нового подхода к управлению приводит к

«культурным» изменениям внутри организации

Автоматизация

«Серебряной пули» не существует

Гибкий инструмент позволит развиваться

- Проектное ТЗ это не конец – это только начало

- Поиск «золотой середины» между платформой и готовым

продуктом

- Готовый продукт позволит быстро начать работать

Не стоит основываться только на фича-листах

- Формируйте реальные сценарии использования – они выявят

отличия

- Обращайте внимание на мелочи

Посмотреть на себя

Сколько ИТ специалистов?

+ распределенная структура, холдинговые компании

+ наличие ключевых для бизнеса ИТ - сервисов

+ большое количество однотипных распределенных инфраструктурных

объектов

+ достаточно грамотные пользователи, требовательные к ИТ

+ предоставление внешних ИТ - сервисов

«Специальные» случаи:

Миграция с продуктов, функциональности которых не хватает или

снятых с поддержки производителем

Сертификация на ISO 20000 или другой стандарт качества сервиса

Международные компания, требования аудита

Сравнение систем разных классов

Коробочные

решения

Конструкторы

Масштаб До 10 ИТ специалистов От 10 ИТ специалистов

Структура Отсутствие распределенной

структуры

Распределенная структура

Планы Понятный круг задач,

планы по развитие

отсутствуют

Необходима возможность

развивать процессы

Функции Есть внутренние ресурсы

на доработку, возможно

отказаться от обновлений

Система должна уметь гибко

настраиваться и иметь

развитое API

Нагрузка Низкая нагрузка на систему Архитектура под средние и

высокие нагрузки

Документация Низкие требования к

документированию

Детальное документирование

Опыт Низкие требования к

референсам

Наличие референсов в

вашей области

Важно не забыть про…

1. Концепция продукта технологическая и архитектурная

2. Схема лицензирования

3. Удобство эксплуатации

4. Функциональность

5. Соответствие процессов ITIL

6. Документация язык, полнота

7. Работы, которые возможно сделать на продукте

8. Опыт интегратора

9. Техническая поддержка

Почему не стоит разрабатывать

систему самостоятельно?

1. Инвестирование в непрофильную деятельность.

2. Функциональности системы требуется всѐ больше, а писать ее нет

сил и времени.

3. Разработка без теоретических знаний и практического опыта.

4. Риск ухода разработчика.

5. Риск выхода системы из строя.

6. Качество кода.

7. Отсутствие пользовательской документации.

8. Отсутствие API.

9. Программист не внедренец.

10. Старт начала работы и внедрение сервисного подхода

откладывается во времени.

11. Итоговая стоимость самописной системы будет выше,

Выбор внешнего консультаната

1. Наличие референсов

2. Присутствие в штате поставщика специалистов всех

категорий (не только консультантов)

3. Готовность сделать рефенс-кол, референс визит

4. Готовность выполнить пилотный проект

5. Готовность предоставить документы

6. Опыт команды, которая будет делать проект у Вас

7. Наличие сервисного центра, SLA сервисного центра

Не выбирайте по цене! Цена не говорит ни о чем, пока Вы не

привели состав предложений к единому знаменателю.

Как еще минимизировать риски?

Пилоты, Триалы, Референсы и… техподдержка

1. Требуйте у поставщиков тестовые версии

2. Делайте пилотные проекты

3. Постарайтесь увидеть работающую систему и

поговорить с людьми, которые с ней работали

4. Сервисный центр поставщика работает со своей

системой? А он есть вообще?

С точки зрения организации работы

Внутри в компании

1. Выделенный внутри сотрудник должен обладать общей

компьютерной грамотностью, желателен опыт внедрения

систем автоматизации

2. Сотрудник должен быть увлечен идеей ITSM и обладать

характером исследователя и желанием довести дело до конца

3. Сотрудник должен обладать влиянием внутри компании или

иметь поддержу у высшего руководства

4. Должен быть выделен временной ресурс, если проектном

заниматься по остаточному признаку ничего не получиться

5. Должен быть план действий, а не просто «решили что надо –

купили софт - внедрили».

Поставщик

1. Не должен только отгрузить продукт и забыть про вас

За дополнительной информацией

обращайтесь:

+7 (495) 783-02-87www.naumen.ru

drubin@naumen.ru

sales@naumen.ru

А ТАКЖЕ К НАШИМ ПАРТНЕРАМ

Спасибо, вопросы?