Вполне естественно, что перед тем как поддерживать услуги их нужно внедрить, но это естественно только в случае когда Вы начинаете разворачивать инфраструктуру с нулю, в случае если же услуги и сервисы уже кое-как внедрены, а Вам нужно внедрять ITIL поверх уже существующей инфраструктуры (как, к слову, и бывает в большинстве случае), в таком случае вы в первую очередь внедрите поддержку существующих услуг, а уже затем начнете внедрять предоставление услуг. Чем собственно, по такому сценарию я и занялся после внедрения поддержки.
- Процесс управления уровнем услуг - процесс улучшения качества предоставляемых пользователям сервисов, осуществляемый через всесторонний мониторинг, анализ инцидентов и проблем, уровень доступности сервисов и непосредственный анонимный опрос пользователей сервисов. Сутью этого процесса для нас стали аналитические действия каждого сотрудника ИТ, направленный на улучшение сервисов, за которые непосредственно ответственен исполнитель. Все этапы жизни этого процесса были сведены в единую точку входа-выхода, в том числе и анкетирование пользователей. Как показала практика из всех опрошенных пользователей около 10 % могут дать рекомендации, до которых мы сами бы не дошли. И проблема в основном в разной картине мира. Пользователь видит сервис совсем по-другому, нежели технический специалист. В то время когда ИТ ориентируется в основном на функциональность, мощность, гибкость, масштабируемость, пользователь интересуется простотой, доступностью, совместимостью. И вот здесь возникает вопрос : таки ИТ для бизнеса, или бизнес для ИТ? Как показывает практика, большинство сотрудников ИТ даже не мыслят в направлении бизнеса, их интересуют только технические вопросы. И после этого мы хотим понимания?
Непосредственными составляющими этого процесса являются - Каталог услуг и Соглашение об уровне услуг(SLA). Составление этих ключевых документов является довольно трудоемким процессом, особенно в компании, где число сервисов больше 30. ITIL так же рекомендует составить Требование к уровню услуг, но мы по своей лени и для удобства объединяем все это в одном документе - SLA. Так же, как внутренний документ службы, разработана Программа улучшения сервиса. Но об этом все позже в отдельных статьях.
- Процесс управления финансами - мероприятия направленные на рентабельное распоряжение финансовыми ресурсами службы информационных технологий, управление активами, проведение всестороннего анализа финансовой деятельности, установление постоянных взаимоотношений с контрагентами. В принципе, этот процесс был уже налажен и его оставалось только перенести на новую платформу.
- Процесс управления мощностью - процесс направленный на постоянное поддержание необходимого уровня услуг, посредством контроля и планирования мощностей, масштабируемость приложений, определение требующихся мощностей, востановление ключевых сервисов после сбоев. Процесс был полностью включен в CMDB, в него же и вошла база данных мощностей. Основными видами деятельности на поле управления мощностями стали проектирование, согласование и оптимизацию мощностей. Управление востановление систем после сбоя было выведено в отдельный процесс. На практике, этот процесс оказался практически клоном процесса управления конфигурациями, с отличием в том, что он в основном направлен на планирование и согласование. В общем больших трудностей он так же не вызвал, учитывая, что в начальной стадии он уже функционировал и оставалось только закрепить его на программной платформе и начать пользоваться.
- Процесс управления непрерывностью - процесс направленный на непрерывность предоставления услуг пользователям информационных систем и выполнение соглашения об уровне услуг. Наиболее сложный в практическом плане процесс. Выполнение SLA вообще непростая вещь. Этот процесс мы объеденили с Процессом управления доступностью, т.к. существенной разницы для нашей компании не увидели.
Вот примерно так, выглядит наша модель Предоставления услуг
- Процесс управления финансами - мероприятия направленные на рентабельное распоряжение финансовыми ресурсами службы информационных технологий, управление активами, проведение всестороннего анализа финансовой деятельности, установление постоянных взаимоотношений с контрагентами. В принципе, этот процесс был уже налажен и его оставалось только перенести на новую платформу.
- Процесс управления мощностью - процесс направленный на постоянное поддержание необходимого уровня услуг, посредством контроля и планирования мощностей, масштабируемость приложений, определение требующихся мощностей, востановление ключевых сервисов после сбоев. Процесс был полностью включен в CMDB, в него же и вошла база данных мощностей. Основными видами деятельности на поле управления мощностями стали проектирование, согласование и оптимизацию мощностей. Управление востановление систем после сбоя было выведено в отдельный процесс. На практике, этот процесс оказался практически клоном процесса управления конфигурациями, с отличием в том, что он в основном направлен на планирование и согласование. В общем больших трудностей он так же не вызвал, учитывая, что в начальной стадии он уже функционировал и оставалось только закрепить его на программной платформе и начать пользоваться.
- Процесс управления непрерывностью - процесс направленный на непрерывность предоставления услуг пользователям информационных систем и выполнение соглашения об уровне услуг. Наиболее сложный в практическом плане процесс. Выполнение SLA вообще непростая вещь. Этот процесс мы объеденили с Процессом управления доступностью, т.к. существенной разницы для нашей компании не увидели.
Вот примерно так, выглядит наша модель Предоставления услуг
Комментариев нет:
Отправить комментарий