“Управление приложениями”: сервис начинается с ТЗ

Cnews

Оригинал статьи

Согласно многочисленным исследованиям, у предприятий сокращается доля ИТ-инвестиций в общем объеме за счет роста эксплутационных затрат. Что кажется вполне логичным, так как период интенсивной автоматизации завершается, Компании эксплуатируют уже созданное. Причем затраты на эксплуатацию определялись сделанными ранее инвестициями, а серьезно разбираться с этими затратами приходилось уже после завершения проектов. Имея большой опыт внедрения информационных систем, а также опыт организации сервисных процессов на основе ITIL, консультанты “Деснол Софт” часто сталкиваются с проблемами организации обслуживания, разрешимыми только на стыке проектных и сервисных работ. Как результат накопленных знаний и опыта решений в Компании развилось направление “Управление приложениями” (Application Management).

Как работает “Управление приложениями”?

Представьте себе проект внедрения системы, причем не важно, делаете вы его своими силами или привлекаете команду со стороны. В любом проекте, независимо от его сложности и масштаба, можно выделить ряд четко выраженных стадий и контрольных точек, одна из которых – передача системы в эксплуатацию.

А теперь остановитесь на секунду, и попробуйте задать себе вопрос: что обычно происходит в этот момент?

Проектная команда в ходе работы абсолютно четко документировала все функциональные возможности системы, тщательно заботясь о полноте документации. На момент передачи в эксплуатацию требования к сервису программного продукта готовы, четко прописаны в эксплутационной документации, имеются инструкции и обучен обслуживающий персонал. У вас имеются нормативы и обоснованная смета затрат на обслуживание системы. Идеальная картина, не правда ли? К сожалению, крайне редко встречается на практике. Почему? Дело не только в квалификации проектной команды. Причины лежат гораздо глубже, рассмотрим ситуацию подробнее.

Проекты и сервис

Рассмотрим два типа деятельности: создание чего-либо уникального за ограниченное время (проектная), и продолжительную по времени и повторяющуюся (обслуживание). Обычно проект завершается в момент передачи системы в эксплуатацию, и система передается на обслуживание. По статистике – до 80% затрат за весь жизненный цикл системы приходится на ее эксплуатацию и 20% - на проект.

Каждому виду деятельности соответствуют свои технологии управления, методологии и области знаний, наиболее удобные для конкретной фазы жизненного цикла. Для проектирования может быть использованы ISO 15288, RUP, ГОСТ 34.ХХ, и другие. Для организации обслуживания стандартом де-факто служит библиотека передового опыта ITIL (Information Technology Infrastructure Library).

Если цель проектной деятельности – получить результат с заданным качеством и бюджетом в определенные сроки, то задача обслуживания – обеспечение работоспособности с заданными уровнем сервиса и стоимостью. Отсюда проистекает разница в инструментах, подходах, квалификации и мотивации сотрудников, а также ряд важных выводов:

  • невозможно сделать оптимальный проект, не привлекая сервисных специалистов,
  • невозможно организовать эффективный сервис системы, не участвуя в ее проектировании.

Игнорирование этих моментов вызывает различные проблемы. К примеру, проектная команда закупает дешевое оборудование, чтобы уложиться в бюджет проекта. Стоимость последующей эксплуатации может возрасти при этом многократно, но этот фактор при выборе учитывается с низким приоритетом или не используется совсем.

Кто же отвечает за взаимодействие? Очевидно, проектная группа не мотивирована на привлечение сервисных специалистов. В то же время, сервисная команда может просто не знать о начале проекта, или узнать о нем слишком поздно.

Данный вопрос находится в компетенции ИТ-руководителя. Необходимо организовать регулярный процесс, обеспечивающий участие сервисных специалистов в проекте с момента формирования концепции.

Библиотека ITIL, том Application Management

Каким образом учесть и проконтролировать требования к обслуживанию системы еще в ходе проекта? Этому вопросу полностью посвящен один из томов ITIL, библиотеки передового опыта ИТ, который так и называется – «Управление приложениями». Ключевая мысль заключается в следующем - нужно управлять приложением, учитывая весь жизненный цикл системы, привлекая разнопрофильных специалистов на всех стадиях цикла, от возникновения идеи до «смерти» системы, а это от трех до семи и более лет.

В литературе разработки программных систем основной упор делается на первые стадии жизненного цикла разработки – постановка требований, проектирование, разработка, внедрение (Requirements, Design, Build, Deploy). О стадиях эксплуатации и оптимизации (Operate, Optimize) в лучшем случае упоминается поверхностно, а иногда не говорится ничего.

В то же время ядро ITIL (тома Service Support, Service Delivery) не делает акцента на разработке программных систем, рассматривая их с момента передачи в эксплуатацию. Осуществление процессов “Управление релизами”, “Управление изменениями” будет недостаточно.

Таким образом, книга Application Management решает важнейшую задачу – описывает организацию регулярного взаимодействия проектной и сервисной команд. Для каждой стадии проекта она содержит рекомендации в виде списка требований по обслуживанию с точки зрения процессов ITIL. Сотрудник поддержки (отвечающий за какой-либо процесс в терминах ITIL) знает, какие требования необходимо контролировать на каждой стадии проекта. Естественно, все рекомендации требуют адаптации для конкретных условий, необходима определенная зрелость как сервисных, так и проектных процессов. Тем не менее, эти принципы можно использовать для отдельно взятого проекта, особенно если он «проблемный» и критичный для организации.

Практика “Управления приложениями” в России

Практика “Управления приложениями” в России сейчас напоминает ситуацию с внедрением сервисных процессов несколько лет назад. Большинство предприятий, разрабатывающие и внедряющие программные высоко критичные для бизнеса системы, рано или поздно осознают важность учета эксплутационных характеристик. Обычно после того, как наступают один-два раза на дорогостоящие грабли.

Например, в одном из удаленных региональных подразделений крупной Компании для поддержки всей сетевой инфраструктуры было выбрано оптимальное решение на крупном сервере известной Компании-производителя. Однако требования к ремонтопригодности не было принято во внимание. В результате, случись поломка, «упала» бы сеть, к которой подключены сотни пользователей, а минимальный срок доставки нового сервера составляет от трех до пять дней. Для непрерывного производства ситуация равносильная катастрофе. Был закуплен второй такой же дорогостоящий дублирующий сервер. Причина? При проектировании сетевой инфраструктуру одно из важнейших сервисных требований банально осталось «за кадром».

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

Кроме того, сервер можно было не покупать – подрядчик был готов предоставить в аренду необходимые серверные ресурсы. Одновременно решалась и проблема масштабирования. Этот вариант не рассматривался проектной командой изначально, так как специалисты, принимающие решения, не мыслили в терминах услуг – зато отлично проектировали инфраструктуру. В результате, Компания потратила напрасно несколько сотен тысяч долларов.

Всех этих проблем удалось бы избежать, будь требования к сервису учтены на стадии постановки задач к системе, на стадии инициации проекта. Но ответственный сервис-менеджер появился уже после разработки системы и после принятия решения о закупке сервера. В случае, если бы был организован процесс контроля сервисных требований – скорее всего заказчик купил бы услугу, более выгодную в данном примере, а не тратился бы на собственную инфраструктуру. Наличие хорошо организованной тендерной процедуры тоже не защитило Компанию, тендер был отлично проведен, затраты предусмотрены бюджетом и планом работ. Просто задачу можно было решить другим способом.

Безусловно, нужно понимать, что внедрение “Управления приложениями” по всем системам на предприятии «с нуля» невозможно, для этого используемые проектные и сервисные технологии работы должны достигнуть минимального уровня зрелости. На предприятии должны существовать минимально выстроенные сервисные процессы (“Управления уровнем сервиса”, “Инцидентами”, “Изменениям”, “Конфигурациями” и пр.), представители которых и будут формулировать эксплутационные требования к системе. Их нужно учитывать, а это возможно только в том случае, если достаточно формализована собственно проектная работа.

В то же время, при наличии одной-двух высококритичных систем не имеет смысла сразу выстраивать «тяжелые», дорогие сервисные процессы. Достаточно ввести “Управление приложениями” и необходимый сервис только для нескольких критичных систем – там, где это более всего требуется.

Описание процесса Desnol Application Management

На стадии инициации проекта формулируется набор сервисных требований, и ответственные за их реализацию в программной системе. Все требования постоянно актуализируются в ходе проекта, организовано взаимодействие сервисной и проектной команды. Внутренняя это команда или внешний контрагент (в случае аутсорсинга), неважно – суть взаимодействия от этого не меняется. Таким образом, к моменту сдачи системы в эксплуатацию сервисные требования будут учтены в ходе разработки и внедрения. Желательно, чтобы управление сервисными требованиями было автоматизировано. Для этого в одном из подразделений Компании “Деснол Софт” было разработано соответствующее программное обеспечение.

Информационная система “Desnol Soft: Application Management” автоматизирует деятельность, относящуюся к объединению областей знаний по “Управлению ИТ-проектами” и “Управлению ИТ- сервисом”. Продукт охватывает только управление сервисными требованиями, не затрагивая управление прочими требованиями и не заменяя системы управления проектами.

Основная цель информационной системы "Управления приложениями" - обеспечение гарантий, что разрабатываемое или внедряемое приложение отвечает требованиям к сервису, а выполнение всех требований было проконтролировано. Основные пользователи Компании – ИТ-директора, сервис-менеджеры (менеджеры сервисных процессов), а также проектные команды. Система позволяет планировать и контролировать выполнение сервисных требований на всем жизненном цикле систем, количественно оценивать выполнение сервисных требований на каждой стадии жизненного цикла, а также по всем системам на предприятии. Количественная оценка качества учета сервисных параметров системы может быть зафиксирована в различные моменты времени.

Показателем высокой зрелости процесса является его влияние на другие процессы организации: внедряя “Управление приложениями”, можно решить вопрос о стоимости сервиса.

Сколько стоит сервис?

В настоящее время многие предприятия проводят большую работу по определению стоимости обслуживания систем. Как правило, выясняется, что использование внешних нормативов практически невозможно. Сложность вызывает как определение состава операций по услуге, нормирование собственно операций, так и утверждение этих норм на предприятии.

Если предприятие хочет стать счастливым обладателем нормативов, не вызывающих сомнения у первых лиц, то достаточно на стадии проектирования предусмотреть разработку норм в техническом задании или проектной документации. Нормы будут автоматически утверждены на момент приемки эксплутационной документации и не вызовут сомнений у финансовых служб. Учитывая высокую скорость обновления ИТ-инфраструктуры и приложений, за два – три года использования процесса “Управления приложениями” можно получить полную систему нормативов на обслуживание систем предприятия. Причем это справедливо для всех типов систем: инфраструктурные системы, автоматизация предприятия, производства или технологических процессов.

Мышление в терминах услуг

Привлекая специалистов по ИТ-сервису в проект в ряде случаев сокращало не только бюджет проекта, но сроки внедрения в три-четыре раза. Одному предприятию потребовалось срочно поставить систему подготовки документации по ремонту самолетов. Разработка системы была частью более крупного проекта – строящегося ремонтного ангара. Суть системы – одновременно с выходом самолета из ангара, система должна была выдать обновленный диск документации, записав все произведенные изменения. Без диска самолет из ангара выехать не сможет. Простой порядка нескольких минут уже измеряется крупной цифрой и как следствие, требования к доступности системы очень высоки. Проектный отдел составил план работ, проект технического задания: подобрал необходимое ПО, сервер и компьютеры, однако гарантировать требуемую доступность было очень затруднительно (по бюджету и времени разработки). На первоначальном этапе оказалось, что план работ не может уложиться в отведенное время. Убытки предприятия могли быть огромны, что делать? К счастью, на предприятии думали о внедрении сервисных процессов на базе ITIL, и в числе прочих вариантов рассматривалась покупка услуги, грубое описание которой уже было в техническом задании. Поставщики были готовы, руководство решило сделать услугу еще более комплексной – вместе с необходимым АРМ, включающим в себя сервер и программное обеспечение, были арендованы еще и обученные операторы. Все, что потребовалось от заказчика: подготовить место, мебель и подписать контракт на обслуживание с необходимым уровнем сервиса.

Данный пример характерно показывает, что часто предприятию нет необходимости выполнять проект, обзаводиться основными средствами – купить услугу бывает проще, быстрее, дешевле и менее рискованно. Проектная команда должна уметь мыслить в терминах услуг.

Резюме

Итак, получив возможность тщательно контролировать учет эксплутационных требований в ходе разработки или внедрению системы, Компания управляет системой на всем жизненном цикле, оптимизирует стоимость владения. Экономия затрат составляет как минимум 15-20%, а в ряде случаев достигает 60-80%. Правильная формулировка услуг, которые получит предприятие после внедрения системы, может изменить весь проект, сократив не только его бюджет, но и сроки, поможет правильно определить риски. К моменту сдачи в эксплуатацию системы необходимые сервисы, их качество и стоимость обслуживания будут ясны и прозрачны. Что обеспечит успешность проекта не только до срока приемки, но и на этапе длительной и надежной эксплуатации. Не стоит забывать и о том, что плохо организованная эксплуатация способна испортить отношения к идеально реализованной системе и проекту, тогда как хороший сервис никогда не уронит достоинства успешно реализованного проекта.

Сергей Овчинников, Александр Жилинский

Мы помогаем бизнесу
быть эффективным!