Поделиться
“Управление приложениями”: сервис начинается с ТЗ
Согласно многочисленным исследованиям, у предприятий сокращается доля ИТ-инвестиций в общем объеме за счет роста эксплутационных затрат. Что кажется вполне логичным, так как период интенсивной автоматизации завершается, компании эксплуатируют уже созданное. Причем затраты на эксплуатацию определялись сделанными ранее инвестициями, а серьезно разбираться с этими затратами приходилось уже после завершения проектов. Имея большой опыт внедрения информационных систем, а также опыт организации сервисных процессов на основе 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) знает, какие требования необходимо контролировать на каждой стадии проекта. Естественно, все рекомендации требуют адаптации для конкретных условий, необходима определенная зрелость как сервисных, так и проектных процессов. Тем не менее, эти принципы можно использовать для отдельно взятого проекта, особенно если он «проблемный» и критичный для организации.
Практика “Управления приложениями” в России
Практика “Управления приложениями” в России сейчас напоминает ситуацию с внедрением сервисных процессов несколько лет назад. Большинство предприятий, разрабатывающие и внедряющие программные высоко критичные для бизнеса системы, рано или поздно осознают важность учета эксплутационных характеристик. Обычно после того, как наступают один-два раза на дорогостоящие грабли.
Например, в одном из удаленных региональных подразделений крупной компании для поддержки всей сетевой инфраструктуры было выбрано оптимальное решение на крупном сервере известной компании-производителя. Однако требования к ремонтопригодности не было принято во внимание. В результате, случись поломка, «упала» бы сеть, к которой подключены сотни пользователей, а минимальный срок доставки нового сервера составляет от трех до пять дней. Для непрерывного производства ситуация равносильная катастрофе. Был закуплен второй такой же дорогостоящий дублирующий сервер. Причина? При проектировании сетевой инфраструктуру одно из важнейших сервисных требований банально осталось «за кадром».
Другой пример. В одной из крупных российских компаний несколько лет назад проектная деятельность находилась на достаточно высоком уровне, тогда как сервисные процессы только начинали внедряться. Для разработанной подрядчиком крупной распределенной информационной системы был необходим мощный центральный сервер. Уже на тот момент были понятны требования со стороны бизнеса к уровню доступности системы. С большим трудом был куплен сервер и установлен на собственной площадке заказчика, но компания – производитель сервера едва уложилась в отведенное время восстановления в случае сбоя. А кроме сбоя собственно сервера был возможен как сбой СУБД, так и сбой прикладной части системы, которую обслуживают другие подрядчи. Только на разработку процесса взаимодействия между всеми эксплуатирующими организациями было затрачено большое количество времени и финансовых вложений. По ходу дела выяснилось, что подрядчик сможет гарантировать вдвое меньший срок полного восстановления системы и в два раза дешевле – при условии установки сервера на площадку подрядчика, что было допустимо в проекте.
Кроме того, сервер можно было не покупать – подрядчик был готов предоставить в аренду необходимые серверные ресурсы. Одновременно решалась и проблема масштабирования. Этот вариант не рассматривался проектной командой изначально, так как специалисты, принимающие решения, не мыслили в терминах услуг – зато отлично проектировали инфраструктуру. В результате, компания потратила напрасно несколько сотен тысяч долларов.
Всех этих проблем удалось бы избежать, будь требования к сервису учтены на стадии постановки задач к системе, на стадии инициации проекта. Но ответственный сервис-менеджер появился уже после разработки системы и после принятия решения о закупке сервера. В случае, если бы был организован процесс контроля сервисных требований – скорее всего заказчик купил бы услугу, более выгодную в данном примере, а не тратился бы на собственную инфраструктуру. Наличие хорошо организованной тендерной процедуры тоже не защитило компанию, тендер был отлично проведен, затраты предусмотрены бюджетом и планом работ. Просто задачу можно было решить другим способом.
Безусловно, нужно понимать, что внедрение “Управления приложениями” по всем системам на предприятии «с нуля» невозможно, для этого используемые проектные и сервисные технологии работы должны достигнуть минимального уровня зрелости. На предприятии должны существовать минимально выстроенные сервисные процессы (“Управления уровнем сервиса”, “Инцидентами”, “Изменениям”, “Конфигурациями” и пр.), представители которых и будут формулировать эксплутационные требования к системе. Их нужно учитывать, а это возможно только в том случае, если достаточно формализована собственно проектная работа.
В то же время, при наличии одной-двух высококритичных систем не имеет смысла сразу выстраивать «тяжелые», дорогие сервисные процессы. Достаточно ввести “Управление приложениями” и необходимый сервис только для нескольких критичных систем – там, где это более всего требуется.
Короткая ссылка
