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

В связи с этим хотел бы напомнить всем желающим про ГОСТ Р ИСО/МЭК 12207—99, который является переводом на русский язык стандарта ISO 12207—95 «Информационная технология. Процессы жизненного цикла программных средств». Пересказывать его не буду, любой желающий найдет его текст в Интернете за пару минут. На мой взгляд, этот стандарт очень хорошо стыкуется как с PMBOK в части инициирования и ведения проектов в приложении к ИТ, так и с ITIL в части эксплуатации и сопровождения, да и вообще с самой идеей сервисно-ресурсной модели.

Опираясь на ИСО/МЭК 12207—99, мы можем выстроить процесс управления доработками бизнес-приложений (прикладного ПО) по аналогии с управлением изменениями в ITIL. Далее в настоящей статье штрихами разного размера попробую изобразить возможный вариант.

Какие проблемы чаще всего могут возникать? Из моего опыта, это:

  • нечеткая постановка задачи;
  • конфликт между требуемыми объемами работ и сроками их исполнения;
  • ограниченность ресурсов, выделяемых на доработку;
  • конфликты интересов двух заказчиков;
  • «глобальные» заказы.

Итак, начать предлагаю с формализации про­цедуры подачи запросов на доработку и изменение бизнес-приложений. Запросы нужно оформлять по установленному образцу, служба ИТ должна при необходимости оказывать помощь в их оформлении. Все запросы следует регистрировать и обрабатывать по установленным правилам. Отдельно хочу обратить внимание — необходимо очень четко определить, какие должностные лица имеют право инициировать запрос на доработку бизнес-приложений. Это сразу же позволит отделить недовольное брюзжание отдельных пользователей системы (оно будет всегда) от реальных потребностей заказчиков.

Кем и в каком виде должны быть определены эти правила? На вопрос «кем?» ответ довольно простой — службами ИТ, отвечающими за эксплуатацию и сопровождение бизнес-приложений. Все известные мне попытки возложить разработку таких правил на проектные группы заканчивались неудачно: в лучшем случае писались формальные документы, совершенно не применимые на практике. На вопрос «в каком виде?» универсального ответа нет. Основные требования к содержанию документов, описывающих процессы эксплуатации и сопровождения, определены соответственно в п. 5.4.1 и 5.5.1 ИСО/МЭК 12207—99. Это может быть универсальный для организации регламент (комплекс регламентов) или же отдельные документы для каждого бизнес-приложения (платформы), учитывающие особенности и специфику конкретного бизнес-приложения.

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

Много вопросов всегда возникает о приоритезации запросов. Ресурсы, выделяемые на доработку бизнес-приложений, как правило, довольно скромны. Заказчики всегда хотят, чтобы все было сделано завтра, ну на крайний случай — послезавтра. И при этом обычно еще руководство ИТ‑службы хочет иметь в этой области некоторую «интерактивность с бизнесом». Здесь возможно два варианта:

  • коллегиальный орган с необходимыми компетенциями и полномочиями (например, комитет);
  • процедура оперативного рассмотрения и согласования предлагаемых изменений (типа согласования договоров).

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

Имеется и «подводный камень»: при создании такого комитета на его работу с высокой степенью вероятности будут оказывать влияние имеющиеся в организации проблемы, разногласия, конфликты и т. п. Подобная ситуация неоднократно встречалась на практике в различных организациях. Эффективность работы такого органа (скорость принятия решений) будет низкой. Обычно такие комитеты используют для решения стратегических вопросов и/или для управления портфелем крупных проектов. В этих случаях подобные аспекты все равно необходимо учитывать, и затраты времени на них оправданны. А в случае управления небольшими проектами возможна потеря оперативности.

Предложить эффективную процедуру оперативного согласования тоже сложно. Что можно предложить — классическое веерное согласование, распределенную рабочую группу, свободное голосование по типу «выскажи свое мнение до момента Х или молчи». И у нее всегда будет одно тонкое место: разрешение конфликтных ситуаций, когда два заказчика занимают противоположные позиции и не хотят договориться.

В любом из этих вариантов сроки разработки и запуска процесса могут составить несколько месяцев.

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

  • кратковременная остановка производства;
  • уголовное преследование;
  • отзыв лицензии;
  • задержка выплаты зарплат;
  • административные штрафы;
  • пени и штрафы по договорам и т. д.

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

При желании приоритеты можно определять, привлекая экспертов от бизнес-подразделений, и вообще всячески совершенствовать.

При дефиците ресурса экспертов можно пойти по следующему пути.

  1. Автор запроса сам проставляет приоритет.
  2. Менеджер ИТ, управляющий доработками, при наличии сомнений вступает в диалог с заказчиком и уточняет реальность рисков.
  3. В случае, если приоритет имеет высокий ранг (например, 4 и 5), запрос обязательно направляется экспертам. То же самое — при явно или потенциально конфликтных ситуациях.

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

Пишите автору по адресу asennator@gmail.com