Коптелов Андрей Константинович

Директор проекта «Контроллинг 24»

Компания IDS Scheer Россия и страны СНГ

 

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

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

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

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

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

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

 

· менеджеров проекта часто интересует, сколько времени и усилий понадобится для разработки требований. Для небольших проектов, которыми обычно занималась наша команда, этот этап обычно стоил от 12 до 15% всех затрат (Wiegers, 1996) · изучение 15 проектов в сфере телекоммуникаций и банковской сферы показало, что в наиболее успешных проектах примерно 28% ресурсов тратилось на разработку требований (Hofmann и Lehner, 2001): 11%— на сбор информации по требованиям, 10% — на моделирование, а 7% на проверку и утверждение. На разработку требований для среднего проекта необходимо,7% всех ресурсов и 38,6% времени · в проектах NASA, в которых затрачивалось более 10% всех ресурсов на разработку требований, затраты и отклонения от графика оказались существенно ниже, чем в проектах, где на требования затрачивалось меньше ресурсов (Hooks иРаггу, 2001) · исследования, проведенные в Европе, показали, что команды, разрабатывающие продукты более быстро, посвятили больше времени и усилий требованиям, чем более медленные команды (Blackburn, Scudder и Van Wassenhove, 1996)

 

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

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

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

Со стратегической точки зрения, необходимо определить какие приоритеты стоят перед компанией с точки зрения автоматизации. Что для компании важнее – стоимость или функциональность? А может быть, критичными сейчас являются длительные и успешные взаимоотношения с внедряющей организацией и знание их консультантами ваших бизнес-процессов. Все это необходимо определить и формализовать, чтобы при принятии решения между группами требований были выставлены приоритеты. Очень часто для понимания существующей ситуации и преимуществ от новой информационной системы, помимо целевых требований необходимо сделать оценку уровня их достижения существующими инструментами. Ведь может быть в компании все в порядке и автоматизации больше не надо? Бывает и так. Хотя в большинстве случаев новые требования бизнеса просто невозможно реализовать на используемой платформе или их реализация достаточно дорога, в результате чего, компания и начинает проект по замене информационной системы.

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

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

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

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

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

Сейчас на российском рынке присутствует несколько инструментов, позволяющих как описывать бизнес-процессы, так и организовать управление требованиями. Одним из таких инструментов является программный продукт ARIS IT Architect от компании IDS Scheer, который позволяет не только описать деятельность компании, и в частности ее бизнес-процессы, но и сформировать требования, а также поддержать процесс управление ими. В качестве заключения, можно привести статистику аналитиков компании The Standish Group: ·

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