Как снизить риски при управлении запросами

Логотип компании
Как снизить риски при управлении запросами
Правильно организованный процесс управления запросами необходим для сбора, анализа, синтеза и расстановки приоритетов в ИТ-департаменте

Успех организаций во многом зависит от внедрения ИТ-приложений и услуг, пишет в своем блоге Золтан Йен (Zoltán Jenei), основатель компании Improve ITM Ltd, поскольку предоставляемые ими возможности не только служат необходимыми предпосылками бизнес-операций, но и формируют их ядро, во многих отраслях становясь основным и решающим фактором деловых процессов.

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

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

1. Бизнес-«хотелка» вместо бизнес-потребности

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

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

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

2. Фрагментированные, несогласованные запросы

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

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

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

3. Фокус на реализации, а не на потребности

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

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

4. Неоптимальная организация приоритезации

Хотя многие организации добились значительных успехов, чтобы стать более «гибкими и плоскими», традиционные иерархические структуры все еще приводят к неоптимизированным и фрагментированным процессам. Например, различные отделы продаж и маркетинга могут сначала сформулировать свои требования. Затем происходит консолидация на уровне директора по продажам и маркетингу (CSMO). В качестве следующего шага этот список первоочередных потребностей CSMO объединяется со списком других областей, таких как сфера деятельности директора по финансам (CFO), операционного директора (COO) и других, чтобы получить приоритеты на уровне компании. Если объединение представляет собой механический процесс, в частности, первоочередные требования на уровне организации являются актуальными запросами от каждого из направлений, за ними следуют средние и низкоприоритетные запросы, то результат весьма вероятно окажется не оптимальным.

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

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

Заключение

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

Читайте также
Управление качеством программного обеспечения (QA) становится очень важным. Одним из ключевых моментов — это правильный подход к управлению документацией. Хорошо организованные документы упростят работу всей команды. В этой статье я составил чек-лист, который поможет вам наладить стандарты, держать документы актуальными. Также расскажу, как внедрить новые подходы QA, чтобы сотрудники не устроили восстание.

Опубликовано 30.06.2019

Похожие статьи