Поделиться
“Управление приложениями”: сервис начинается с ТЗ
Согласно многочисленным исследованиям, у предприятий сокращается доля ИТ-инвестиций в общем объеме за счет роста эксплутационных затрат. Что кажется вполне логичным, так как период интенсивной автоматизации завершается, компании эксплуатируют уже созданное. Причем затраты на эксплуатацию определялись сделанными ранее инвестициями, а серьезно разбираться с этими затратами приходилось уже после завершения проектов. Имея большой опыт внедрения информационных систем, а также опыт организации сервисных процессов на основе ITIL, консультанты “Деснол Софт” часто сталкиваются с проблемами организации обслуживания, разрешимыми только на стыке проектных и сервисных работ. Как результат накопленных знаний и опыта решений в компании развилось направление “Управление приложениями” (Application Management).Описание процесса Desnol Application Management
На стадии инициации проекта формулируется набор сервисных требований, и ответственные за их реализацию в программной системе. Все требования постоянно актуализируются в ходе проекта, организовано взаимодействие сервисной и проектной команды. Внутренняя это команда или внешний контрагент (в случае аутсорсинга), неважно – суть взаимодействия от этого не меняется. Таким образом, к моменту сдачи системы в эксплуатацию сервисные требования будут учтены в ходе разработки и внедрения. Желательно, чтобы управление сервисными требованиями было автоматизировано. Для этого в одном из подразделений компании “Деснол Софт” было разработано соответствующее программное обеспечение.
Информационная система “Desnol Soft: Application Management” автоматизирует деятельность, относящуюся к объединению областей знаний по “Управлению ИТ-проектами” и “Управлению ИТ- сервисом”. Продукт охватывает только управление сервисными требованиями, не затрагивая управление прочими требованиями и не заменяя системы управления проектами.
Основная цель информационной системы "Управления приложениями" - обеспечение гарантий, что разрабатываемое или внедряемое приложение отвечает требованиям к сервису, а выполнение всех требований было проконтролировано. Основные пользователи компании – ИТ-директора, сервис-менеджеры (менеджеры сервисных процессов), а также проектные команды. Система позволяет планировать и контролировать выполнение сервисных требований на всем жизненном цикле систем, количественно оценивать выполнение сервисных требований на каждой стадии жизненного цикла, а также по всем системам на предприятии. Количественная оценка качества учета сервисных параметров системы может быть зафиксирована в различные моменты времени.
Показателем высокой зрелости процесса является его влияние на другие процессы организации: внедряя “Управление приложениями”, можно решить вопрос о стоимости сервиса.
Сколько стоит сервис?
В настоящее время многие предприятия проводят большую работу по определению стоимости обслуживания систем. Как правило, выясняется, что использование внешних нормативов практически невозможно. Сложность вызывает как определение состава операций по услуге, нормирование собственно операций, так и утверждение этих норм на предприятии.
Если предприятие хочет стать счастливым обладателем нормативов, не вызывающих сомнения у первых лиц, то достаточно на стадии проектирования предусмотреть разработку норм в техническом задании или проектной документации. Нормы будут автоматически утверждены на момент приемки эксплутационной документации и не вызовут сомнений у финансовых служб. Учитывая высокую скорость обновления ИТ-инфраструктуры и приложений, за два – три года использования процесса “Управления приложениями” можно получить полную систему нормативов на обслуживание систем предприятия. Причем это справедливо для всех типов систем: инфраструктурные системы, автоматизация предприятия, производства или технологических процессов.
Мышление в терминах услуг
Привлекая специалистов по ИТ-сервису в проект в ряде случаев сокращало не только бюджет проекта, но сроки внедрения в три-четыре раза. Одному предприятию потребовалось срочно поставить систему подготовки документации по ремонту самолетов. Разработка системы была частью более крупного проекта – строящегося ремонтного ангара. Суть системы – одновременно с выходом самолета из ангара, система должна была выдать обновленный диск документации, записав все произведенные изменения. Без диска самолет из ангара выехать не сможет. Простой порядка нескольких минут уже измеряется крупной цифрой и как следствие, требования к доступности системы очень высоки. Проектный отдел составил план работ, проект технического задания: подобрал необходимое ПО, сервер и компьютеры, однако гарантировать требуемую доступность было очень затруднительно (по бюджету и времени разработки). На первоначальном этапе оказалось, что план работ не может уложиться в отведенное время. Убытки предприятия могли быть огромны, что делать? К счастью, на предприятии думали о внедрении сервисных процессов на базе ITIL, и в числе прочих вариантов рассматривалась покупка услуги, грубое описание которой уже было в техническом задании. Поставщики были готовы, руководство решило сделать услугу еще более комплексной – вместе с необходимым АРМ, включающим в себя сервер и программное обеспечение, были арендованы еще и обученные операторы. Все, что потребовалось от заказчика: подготовить место, мебель и подписать контракт на обслуживание с необходимым уровнем сервиса.
Данный пример характерно показывает, что часто предприятию нет необходимости выполнять проект, обзаводиться основными средствами – купить услугу бывает проще, быстрее, дешевле и менее рискованно. Проектная команда должна уметь мыслить в терминах услуг.
Резюме
Итак, получив возможность тщательно контролировать учет эксплутационных требований в ходе разработки или внедрению системы, компания управляет системой на всем жизненном цикле, оптимизирует стоимость владения. Экономия затрат составляет как минимум 15-20%, а в ряде случаев достигает 60-80%. Правильная формулировка услуг, которые получит предприятие после внедрения системы, может изменить весь проект, сократив не только его бюджет, но и сроки, поможет правильно определить риски.
К моменту сдачи в эксплуатацию системы необходимые сервисы, их качество и стоимость обслуживания будут ясны и прозрачны. Что обеспечит успешность проекта не только до срока приемки, но и на этапе длительной и надежной эксплуатации. Не стоит забывать и о том, что плохо организованная эксплуатация способна испортить отношения к идеально реализованной системе и проекту, тогда как хороший сервис никогда не уронит достоинства успешно реализованного проекта.
Сергей Овчинников, Александр Жилинский
Материал публикуется на правах рекламы
Короткая ссылка
