Анализ бизнес-ценности требований в контексте заинтересованных сторон

Есть философская проблема: большинство ИТ-специалистов при работе над внешними проектами не осознают бизнес-целей заказчика.

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

Но, когда ты встаешь на сторону заказчика и пытаешься найти команду, чтобы реализовать проекты уже для себя – мир почему-то переворачивается. Ты начинаешь удивляться. Как так? Вроде все очевидно, понятно. Объясняешь исполнителям, а они не понимают.

Это интересная коллизия, ее нужно пережить.

Но, поскольку бизнес умный, и ИТ тоже умные, они пытаются договариваться.

В результате развиваются проектные технологии, создаются новые инструменты и методологии (Scrum, Kanban и прочие), чтобы бизнес и ИТ смогли договориться и улучшить свое взаимодействие.

Решение проблемы, что система «не едет» – образ мышления через единство бизнеса и ИТ

На слайде – цитата из свода знаний COBIT, описывающего методологию управления ИТ-стратегией компаний.

Суть этой цитаты сводится к тому, что ИТ и бизнес – это одно целое. Бизнес не может развиваться без ИТ. Они должны правильно взаимодействовать между собой и работать в синергии, выстраивая образ мышления через единство бизнеса и ИТ.

Проблема классического проекта автоматизации в том, что он может выглядеть так:

• собрали требования;

• спроектировали и создали систему;

• запустили;

• а на этапе опытно-промышленной эксплуатации выясняется, что система «не едет».

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

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

Неочевидные участники процесса автоматизации

Здесь важно задуматься о том, сколько сторон участвует в проекте.

Принято считать, что в проекте участвуют две стороны:

• Заказчик;

• Исполнитель.

Но по факту сторон всегда минимум три:

• Бизнес;

• Пользователи;

• и ИТ, причем с двух сторон:

  • со стороны заказчика;

  • и со стороны исполнителя, если это подрядная работа.

Если бизнес, ИТ и пользователи тянут развитие системы в разные стороны, запустить и реализовать проект становится практически невозможно – вне зависимости от того, насколько качественно все сработали.

Очевидно, что в таком проекте не продумана работа с заинтересованными сторонами. Давайте кратко разберемся, кто из них кто.

Бизнес в ИТ-проекте – это, как правило, собственники либо топ-менеджмент. Бизнес в проекте решает одну из трёх задач:

• Оптимизация ресурсов любых видов (снижение затрат).

• Снижение рисков.

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

К пользователям в ИТ-проекте относятся:

• Специалисты – реальные физические пользователи, которые нажимают на кнопки.

• Линейные руководители – те, кто объясняют специалистам, как должны быть устроены бизнес-процессы, выстраивают работу в компании и контролируют ее выполнение.

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

• Принципы, политики и подходы

• Процессы

• Организационная структура

• Культура, этика и поведение

• Информация

• Услуги, инфраструктура и приложения

• Люди, навыки и компетенции

Каждый фактор влияния существует независимо, но имеет одинаковый набор атрибутов, которые должны быть проработаны. Таких атрибута четыре:

• Цель.

• Заинтересованные стороны.

• Жизненный цикл.

• Хорошие (общепринятые) практики.

Далее мы разберем факторы влияния на конкретном примере.

И последняя заинтересованная сторона в проекте – это ИТ. К ИТ относятся:

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

• Техническая инфраструктура компании – сюда относится как техника, так и ПО.

Важно! Практически всегда со стороны ИТ работает совместная команда от заказчика и исполнителя. Для удачного выполнения проекта их интересы должны совпадать.

Комбинации взаимодействия

Идеальная ситуация на проекте – когда Бизнес, ИТ и Пользователи тянут проект в одну сторону.

В этом случае проект легко и просто «взлетает», никаких проблем нет.

Но гораздо чаще встречаются варианты с противодействием – кратко их рассмотрим.

Вариант противодействия №1. Пользователи против.

Это самая распространенная ситуация, которая характеризуется следующим образом:

• ИТ и Бизнес выступают за проект. Бизнес хочет развиваться, ИТ это понимает и поддерживает.

• Пользователи сопротивляются внедрению и не хотят менять привычный уклад.

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

Но особо беспокоиться из-за этого не стоит. Большинство проектов так и протекает Ситуация рабочая. Нужно вникать, анализировать, разъяснять, предлагать решения.

Вариант противодействия №2. ИТ против.

В этом случае:

• Бизнес и пользователи понимают, что нужно развитие.

• Но ИТ это не интересно – разработчики не хотят терять то, что сами создавали годами.

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

Здесь три возможных инструмента влияния:

• Реформировать ИТ.

• Привлекать подрядчиков на реализацию проекта

• Мотивировать и переубеждать ИТ, вовлекать их в проект.

Вариант противодействия №3. Бизнес против.

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

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

А когда бизнес не осознает экономического результата, с финансированием могут быть сложности.

Чтобы избежать этой проблемы, важно четко ограничить цели такого проекта.

• Целями такого проекта не могут быть бизнес-цели – нужно либо локализовать цели до каких-то технических инициатив, либо поделить проект на участки.

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

Но с этим вариантом нужно работать аккуратно.

Вариант противодействия №4. ИТ и бизнес одновременно против.

Это сценарий еще сложнее, чем предыдущий случай – и он тоже опасный.

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

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

Здесь проблема в том, что:

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

• Без поддержки ИТ будет трудно.

• Раз бизнес все устраивает, ресурсы могут не выделить.

В этой ситуации, скорее всего, время проекта еще не наступило – имеет смысл просто подождать.

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

В большой такой проект лучше не вписываться – это гиблое дело.

Вариант противодействия №5. Пользователи и Бизнес против.

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

Но ни пользователи, ни бизнес не хотят ничего менять – «работает – не трожь».

Соответственно, даже если ИТ убедит бизнес выделить деньги на проект, поддержки со стороны бизнеса все равно не будет.

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

Вариант 6. Когда пользователи и ИТ против, а бизнес – за.

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

А на местах такой потребности нет, там все нормально, все работает. Никто не понимает, зачем это нужно.

В таком внедрении точно будут внутренние проблемы. Более того, в компании уже, скорее всего, есть проблемы. Но в проекте проблем будет еще больше.

Скорее всего, такой проект вообще не будет реализован. Бизнес отстранится, делегирует реализацию на уровень подчинения, а поскольку пользователи и ИТ в проекте абсолютно не заинтересованы, то помогать вам во внедрении не будут. Лучше в такой проект вообще не ввязываться.

Алгоритм проверки требования на бизнес-ценность.

В алгоритме проверки требования на бизнес-ценность три шага:

1. Оценка требования на наличие конкретной бизнес-ценности. Каждое требование должно приносить пользу, и бизнес-ценность каждого требования должна быть оценена.

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

3. Оценка реализуемости на основе факторов влияния.

Все три шага разберем подробнее – рассмотрим, что за факторы влияния, и как они работают.

Инициировать требование может любой из участников.

• Бизнес – обычно инициирует верхнеуровневые задачи.

• ИТ – технические задачи.

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

Важно, что обосновывать ценность требования всегда должен инициатор.

У требования может быть два вида влияния на бизнес-ценность – прямое или косвенное.

Прямое влияние требования чаще всего связано с оптимизацией бизнес-показателей.

• снижение уровня брака

• увеличение товарооборота или объемов производства;

• снижение себестоимости;

• оптимизация складских запасов;

• и т.п.

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

• увеличение скорости процессов;

• адаптация процессов под изменившиеся условия;

• снижение рисков;

• и т.п.

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

Реализуемость, сроки, стоимость либо трудоемкость реализации требования оценивает ИТ.

Кроме этого, именно ИТ совместно с инициатором требования предлагает различные варианты решения.

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

Соответственно, изменения согласует бизнес, а также пользователи-владельцы смежных бизнес-процессов.

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

• Бизнес поставил складу задачу снизить риски отгрузок по неподтвержденным заявкам. Обычно менеджер отправляет на склад заявку, склад начинает отгружать, потом менеджер вспоминает, что его попросили скорректировать заказ. Менеджер пишет письма с корректировками, а на складе уже успели отгрузить. Бизнес ставит задачу – отгружать только подтвержденные заявки.

• Для решения задачи склад решает ввести в оборот новый бумажный документ с подписью менеджеров. Менеджер подписывает заказ на бумаге, отправляет на склад. Если возникнет проблема, заказ из бумажной версии считается финальной версией заявки.

• Одновременно у делопроизводства стоит бизнес-задача по минимизации бумажного документооборота – переход от бумажных документов к электронным.

Поскольку все это делается в одном проекте, возникает явный конфликт бизнес-целей:

• с одной стороны – нужно снизить риски неподтвержденных заявок;

• с другой стороны – нужно оптимизировать бумажный документооборот.

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

Шаг 2. Оценка соответствия рамок нахождения требования в границах бизнес-целей

Помните, в начале доклада я говорил о том, что через мышление бизнес-целями можно удерживать рамки проекта? Классически, все требования можно разделить на три уровня:

• Бизнес-требования (уровень целей)

• Пользовательские (процессный уровень)

• Функциональные (системный уровень)

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

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

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

Важно, что вся иерархия требований должна быть реализована на 100%. Если внизу ее какая-то важная функция чуть-чуть не доделана, выходит, что бизнес-задача тоже не доделана – все это вместе не заработает.

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

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

Шаг 3. Оценка реализуемости требования на основе факторов влияния.

Об оценке реализуемости требования и факторах влияния расскажу на примере.

Я уже рассказывал, что есть семь факторов влияния, которые сформулированы в COBIT. Это просто области, которые существуют в каждой компании, потому что в каждой компании есть:

• Принципы, политики и подходы

• Процессы

• Организационная структура

• Культура, этика и поведение

• Информация

• Услуги, инфраструктура и приложения

• Люди, навыки и компетенции

Предположим, что бизнес ставит в ИТ цель – перевести работу с документами с бумажного варианта на электронный. Спрашивает у ИТ – сколько нужно времени?

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

Со стороны факторов влияния в этой ситуации мы можем наблюдать следующее:

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

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

• Со стороны оргструктуры тоже может быть проблема. Например, оргструктура не готова, требуется какие-то новые позиции вводить, реформировать.

• Корпоративная культура тоже может навредить. Например, если у сотрудников нет привычки делать записи, они опаздывают на совещания, игнорируют письма и так далее.

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

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

Следовательно, каждое требование нужно согласовать, в том числе, с ними.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.