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

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

Сегодня будет про понятие бизнес-ценности: что это, зачем это, и почему лучше не использовать этот конструкт и этот термин в процессе сбора и формализации требований.

В качестве вступления

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

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

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

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

1. Понятие ценности в философии

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

• Гносеология – исследование познавательной деятельности человека, её принципов и границ.
• Онтология – исследование общих принципов устройства мира.
• Аксиология – исследование природы ценности и структуры ценности.

Про два первых мы поговорим как-нибудь потом, а вот из аксиологии возьмем, собственно, определение ценности (одно из, не единственное, но они все похожи):

«Ценность — это абстрактное понятие, разделяющее область объектов, к которой оно применяется, на два класса — положительно значимых и отрицательно значимых объектов. Ценность объекта определяется не его свойствами, а значимостью для человека; эта значимость определяется при помощи общественных норм, нравственных идеалов и т.д.»

Из лекций В. Брюшинкина, Балтийский фед. Университет имени Иммануила Канта.

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

Суть:

Ценность – субъективная оценка объекта или явления со стороны индивида, определяемая контекстом.

Таким образом, конструкт ценности всегда существует в рамках триады:

1. Источник ценностной ориентации.
2. Объект, ценность которого определяется источником ценностной ориентации.
3. Собственно, ценность, которую формирует для объекта источник ценностной ориентации.

2. Появление понятия «ценности» в коммерческом дискурсе

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

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

Чтобы ставить перед собой цели для обеспечения положения на рынке, компания должна исследовать свой рынок: кто ее клиент, что он покупает, что представляет для него ценность и какие его потребности еще не удовлетворены.

С этого момента — и коль скоро книжка стала не просто популярной, а известной вплоть до культовости – термин «ценность» был введен и легитимизирован в бизнес-дискурсе.

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

3. Ценность в актуальных концепциях/практиках

3.1 PMBOK

PMBOK, а точнее «PMI —  A Guide to the Project Management Body of Knowledge (PMBOK Guide). Seventh Edition» — последняя редакция от 2021 года.

И далее:

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

То есть, получается, аксиологическая триада «источник-объект-ценность» тут вполне себе просматривается:

1. Источник ценностной ориентации – заинтересованная сторона.
2. Объект – зависит от заинтересованной стороны.
3. Ценность – тоже зависит от заинтересованной стороны.

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

3.2 BABOK

На самом деле, говорить надо не о BABOK, а о «Модели базовых понятий бизнес-анализа» (BACCM), части BABOK, которая описывает понятийный каркас бизнес-анализа. Там более-менее конкретизируются все три основные понятия:

1. Источник ценностной ориентации -> Заинтересованная сторона: Лицо или группа лиц, имеющие отношение к изменению, потребности или решению. Заинтересованные стороны, как правило, могут быть определены в терминах заинтересованности в изменении, влияния изменения на заинтересованные стороны и воздействия заинтересованных сторон на изменение. Заинтересованные стороны группируются по их отношению к потребностям, изменениям или решениям.
2. Объект -> Изменение.
3. Ценность -> Ценность: Стоимость, важность или полезность чего-либо для заинтересованной стороны в данном контексте. Под ценностью могут пониматься потенциальные или реализованные прибыли, выгоды и улучшения. Также возможно снижение ценности в виде потерь, рисков и издержек. Ценность может быть материальной или нематериальной. Материальную ценность можно измерить напрямую. Материальная ценность зачастую имеет значительную денежную составляющую. Нематериальная ценность измеряется косвенно. Нематериальная ценность часто имеет значительный мотивационный компонент, такой как репутация компании или моральный дух сотрудников. В некоторых случаях ценность можно измерить в абсолютных категориях, но во многих случаях она оценивается в относительных величинах: один вариант решения ценнее другого с точки зрения данного множества заинтересованных сторон.

В рамках BABOK необходимо рассмотреть еще два важных элемента:

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

Получается следующая схема:

Категоризация типов ценности в BABOK отсутствует. Но коль скоро каждое изменение индуцируется заинтересованной стороной, рассмотрим стандартный перечень типов ролей, приведенный в самом BACCM:

1. бизнес-аналитик;
2. клиент;
3. специалист в предметной области бизнеса;
4. конечный пользователь;
5. специалист в области реализации;
6. операционная поддержка;
7. руководитель проекта;
8. регулятор;
9. спонсор;
10. поставщик;
11. тестировщик.

И тогда:

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

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

Итого в рамках BABOK:

1. Источником ценностной ориентации являются персонифицированные (хотя бы до бизнес-ролей) заинтересованные стороны.
2. Заинтересованные стороны формулируют потребности, определяют необходимость изменений, а также ценность этих изменений.

При этом BABOK не описывает отдельного понятия «бизнес-ценности» (хотя и использует его уже на стр. 2).

3.3 COBIT

Aka «Control Objectives for Information and Related Technologies» — методология управления информационными технологиями компании. Появилась в 1997 году, актуальная версия — №5, от 2012 года.

COBIT никак не определяет понятие ценности, но вполне конкретно говорит о создании ценности:

Создание ценности означает извлечение прибыли при оптимальных затратах ресурсов при одновременной оптимизации рисков.

Про заинтересованных лиц COBIT говорит следующее:

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

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

Далее COBIT классифицирует цели на различных уровнях.

Цели компании:

Измерение	Цели компании	Отношение к управленческим целям
		Извлечение прибыли	Оптимизация рисков	Оптимизация ресурсов
Финансовое	1 Ценность инвестиций в бизнес для заинтересованных сторон	*		*
	2 Портфолио конкурентноспособных продуктов и услуг	*	*	*
	3 Управление бизнес-рисками		*	*
	4 Соответствие внешним правилам и регуляторным уложениям		*
	5 Финансовая прозрачность	*	*	*
Клиентское/пользовательское	6 Клиентоориентированная культура обслуживания	*		*
	7 Непрерывность и доступность бизнес-услуг		*
	8 Быстрая реакция на изменение бизнес-среды (конъюнктуры, по сути)	*	*	*
	9 Принятие информированных стратегических решений	*		*
	10 Оптимизация стоимости поставки услуг	*		*
Внутреннее	11 Оптимизация функциональности бизнес-процессов	*		*
	12 Оптимизация стоимости бизнес-процессов	*	*	*
	13 Управляемые изменения в бизнесе	*		*
	14 Продуктивность процессов и сотрудников		*
	15 Соответствие внутренним политикам		*
Обучение и профессиональный рост	16 Квалифицированные и мотивированные люди	*	*	*
	17 Культура инноваций на уровне бизнеса и продуктов	*

Цели, связанные с ИТ:

ИТ-измерение	Цели, связанные с ИТ
Финансовое	1 Согласование ИТ-стратегии и бизнес-стратегии
	2 Соответствие ИТ-требованиям и поддержка соответствия бизнеса внешним законам и нормативным актам
	3 Ответственность исполнительного руководства за принятие решений, связанных с ИТ
	4 Управление бизнес-рисками, связанными с ИТ
	5 Реализованные выгоды от инвестиций и портфеля услуг, основанных на ИТ
	6 Прозрачность связанных с ИТ затрат, инвестиций и рисков
Клиентское/пользовательское	7 Предоставление услуг в соответствии с требованиями бизнеса
	8 Уместное использование приложений, информации и технологических решений
Внутреннее	9 ИТ-гибкость
	10 Безопасность информации, инфраструктуры обработки данных и приложений
	11 Оптимизация ИТ-активов, ресурсов и возможностей
	12 Внедрение и поддержка бизнес-процессов путем интеграции приложений и технологий в бизнес-процессы
	13 Осуществление программ, приносящих пользу, в срок, в рамках бюджета и отвечающих требованиям и стандартам качества
	14 Доступность достоверной и полезной информации для принятия решений
	15 Соответствие ИТ внутренним политикам
Обучение и профессиональный рост	16 Компетентный и мотивированный бизнес- и ИТ-персонал
	17 Знания, экспертиза и инициативы в области бизнес-инноваций

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

Термин «бизнес-ценность» в тексте присутствует, но каких-то пояснений COBIT не дает.

3.4 SCRUM

Описание принципов SCRUM-разработки впервые было сформулировано Джеффом Сазерлендом и Кеном Швабером в 1995 г в статье «The Scrum Development process» (за формальным авторством Швабера). Первоначальный документ вообще не содержал слова «ценность» (value) и не оперировал таким понятием. Для многих сегодняшних бизнес-аналитиков это прям открытие.

Но официальный «Scrum Guide» от 2020 года буквально начинается со следующих слов:

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

Кто является источником ценностной ориентации в SCRUM? Её наличие предполагает владелец продукта:

Владелец продукта предполагает, как продукт мог бы повысить свою ценность и полезность в текущем спринте.

А источником ценности являются заинтересованные лица:

Продукт … имеет четкие границы, известные заинтересованные стороны, четко определенных пользователей или заказчиков.

А вот про бизнес-ценность в «Scrum Guide» нет ни слова.

3.5 Agile

Agile-манифест, а также 12 базовых принципов Agile, были сформулированы и подписаны 17-ю представителями крупных компаний-разработчиков ПО в 2001 г. Первый базовый принцип гласит:

Нашим высшим приоритетом является удовлетворение потребностей клиентов путем своевременной и непрерывной поставки ценного программного обеспечения.

При этом Agile не содержит никаких намеков на то, что конкретно имеется в виду под словом «valuable». Но это не мешает соавторам Agile-манифеста разбрасываться «мощными» утверждениями:

• Кент Бек, создатель Extreme Programming (XP), делает следующий шаг и заявляет, что команда XP должна делать только то, что повышает ценность бизнеса.
• Джим Хайсмит утверждает, что “гибкие проекты контролируются не соответствием плану, а соответствием бизнес-ценности”.

И это все без каких-либо пояснений, о чем конкретно речь.

3.6 User story

User story как техника фиксации высокоуровневых требований была сформулирована Кеном Беком в 1997 г, но настоящим «днем рождения» user story считается 2004 г, когда Майк Кон (один из разработчиков Agile и SCRUM в частности) пишет книжку «User Stories Applied: For Agile Software Development».

Формула user story, приведенная в данной книге, и считающаяся «классической»:

As a <role> I can <capability>, so that <receive benefit>

Ни слова про бизнес-ценность и вообще ценность, речь опять про «benefit» для конкретной «role». Более того, Кон пишет там же:

Возникает соблазн сказать: “Каждая US должна быть оценена пользователями”. Но это было бы неправильно. Многие проекты включают в себя US, которые не ценятся пользователями. Помня о различии между пользователем (тем, кто использует программное обеспечение) и покупателем (тем, кто приобретает программное обеспечение), предположим, что команда разработчиков создает программное обеспечение, которое будет развернуто на большой базе пользователей, возможно, на 5000 компьютерах в одной компании. Покупатель подобного продукта может быть очень обеспокоен тем, что каждый из 5000 компьютеров использует одну и ту же конфигурацию программного обеспечения. Это может привести к user story типа “Вся информация о конфигурации считывается из центрального хранилища”. Пользователям все равно, где хранится информация о конфигурации, но покупателям это может быть важно.

4. Так и что же такое «ценность» в современном контексте?

Все та же аксиологическая триада, просто несколько «суженная»:

1. Источник ценностной ориентации – субъект или класс субъектов, сгруппированных по некоторому признаку.
2. Объект – изменение или решение.
3. Ценность – измеримый параметр, значение которого должно измениться после претворения в жизнь изменения или решения. В терминах BABOK, когда «изменение переходит в категорию контекста».

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

5. А «бизнес-ценность» — это что?

Это сужение аксиологической триады до:

1. Источник ценностной ориентации – деперсонифицированный «бизнес», как бы «вся компания» целиком.
2. Объект – финансовый показатель.
3. Ценность – изменение одного или нескольких финансовых показателей, например увеличение прибыли или снижение издержек.

Вроде бы логично получается.

И тут мы переходим к ключевому вопросу:

6. Поможет ли ИТ-аналитику такое определение?

Нет, потому что:

1. Источник бизнес-ценности деперсонифицирован: невозможно обратиться ко «всей компании» с вопросом о том, например, как будет измеряться ценность произведенного изменения или реализованного решения. Или спросить, в чем конкретно «вся компания» видит ценность того или иного изменения.
2. Бизнес-ценность по-настоящему не измерима: в рамках, например, заказной разработки у исчезающе малого количества заказчиков имеются системы метрик, которые действительно позволят говорить о том, как малые изменения (в автоматизации) повлияют на финансовые показатели «всей компании». И это даже минуя тот факт, что практически ни один заказчик не будет сообщать подрядчику свои реальные финансовые показатели.
3. Не любое изменение приводит к получению бизнес-ценности (в смысле вышеприведенного определения). Рефакторинг кода, редизайн интерфейса, изменение модели данных, переезд на новую версию библиотеки не будут прямо влиять на финансовые показатели. Можно через длинную цепочку попробовать предположить, как такие изменения оценить в деньгах. Но цепочка получится такая длинная, а зависимости получатся такими косвенными, что выглядеть это будет крайне неубедительно.
   
   Пример: ценность реализации «тёмной темы» какого-либо ПО заключается в том, что глаза пользователей будут меньше уставать, поэтому они будут меньше болеть, что сократит расходы Заказчика на ДМС.
   
   Таких «сов, натянутых на глобус» я нахожу в аналитических артефактах ежедневно.

Упрощу:

1. Бизнес-аналитика никто не пустит беседовать с менеджментом компании (интересантами в части изменений бизнес-показателей). Настоящим менеджментом, который считает деньги и спускает вниз на руководителей КПЭ.
2. Невозможно измерить бизнес-ценность такого малого приращения функциональных возможностей системы, которое обычно реализуется в рамках спринта или даже 2-3 спринтов: система метрик, которая могла бы ответить на этот вопрос, получится сложнее, чем сама «измеряемая» автоматизированная система.
3. Не любое изменение вообще принципиально может быть оценено в разрезе изменения финансовых показателей.

7. Как быть аналитику, когда заказчик говорит о бизнес-ценности?

Как и всегда – декомпозировать, конкретизировать, персонифицировать.

7.1 Подход №1: По Джервису

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

Коммерческая ценность
Ценность, прямо конвертируемая в прибыль. Примеры изменений:

1. Новая версия программного пакета, за приобретение которого клиенты будут платить;
2. Новая функциональность, за которую можно заплатить, как за модули в веб-приложениях по запросу;
3. Изменения, снижающие эксплуатационные расходы, такие как сокращение количества требуемых серверов за счет улучшения кода или удешевления распространения среди клиентов;
4. Повышение субъективной ценности приложения, чтобы люди были готовы платить за него больше (иногда это называется «качеством» или «потребительской ценностью»).
   
   Оценка – прямая, по прямому доходу или прибыли.

Рыночная ценность
Ценность, образующаяся через новых привлеченных пользователей. Примеры изменений:

1. Функциональность, привлекающая новую группу клиентов;
2. Перенос приложений на другие платформы, такие как смартфоны, с iOS на Android и т.д;
3. Добавление функций, которых нет у конкурентов (или их лучшая реализация).
   
   Оценка – прямая, по изменению кол-ва пользователей.

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

1. Сокращение количества ошибок в задачах или увеличение скорости выполнения задачи за счет автоматизации задачи или ее частей;
2. Повышение удобства использования или качества приложения для снижения нагрузки на службы поддержки;
3. Сокращение времени, необходимого для настройки новых клиентских сред или их развертывания;
4. Сокращение времени выхода на рынок.
   
   Оценка – прямая, по изменению кол-ва операционных расходов.

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

1. Повышение удобства использования приложения для упрощения его использования (и уменьшения фрустрации пользователей);
2. Добавление новой функции, которая часто запрашивается пользователями.
   
   Оценка – прямая, по изменению удовлетворенности/лояльности пользователей.

Предполагаемая (будущая) ценность
Ценность, образующаяся через внедрение новых технологий/подходов/архитектур для получения любой из вышеперечисленных ценностей. Примеры изменений:

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

7.2 Подход №2: По BABOK

Подход BABOC — классификация ценности по видам заинтересованных лиц:

1. бизнес-аналитик;
2. клиент;
3. специалист в предметной области бизнеса;
4. конечный пользователь;
5. специалист в области реализации;
6. операционная поддержка;
7. руководитель проекта;
8. регулятор;
9. спонсор;
10. поставщик;
11. тестировщик.

7.3 Подход №3: По COBIT

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

Итого

1. Как только аналитик слышит от заказчика «… бизнес-ценность…» — надо насторожиться, потому что с большой вероятностью заказчик имеет в виду что-то, понятное ему одному. Настаёт время задавать вопросы:
   1. Что конкретно заказчик имеет в виду под «бизнес-ценностью»? Именно коммерческую ценность? Он готов предоставить методику и показатели для её измерения?
   2. Про какой конкретно тип ценности он говорит?
   3. Можно ли говорить о других типах ценности в рамках обсуждаемых изменений?
   4. О ценности для какого заинтересованного лица идет речь?
2. Если заказчик отвечает невнятно, мычит, или прямо говорит, что не знает – можно начинать перебирать варианты:
   1. ценности по ролям (по BABOC);
   2. ценности по видам (по Джервису);
   3. ценности по целям (по COBIT).
3. Всегда помнить, что как бы вы ни определяли ценность вообще, и бизнес-ценность в частности, она должна быть:
   1. адресной;
   2. измеримой.

И может вообще не включать в себя прямую финансовую выгоду.

И это нормально.

^{Фотография проектных команд заказчика и исполнителя после совещания}

Список использованной литературы:

1. Друкер П., «Практика менеджмента», 2015
2. Швабер К., «Скрам. Гибкое управление продуктом и бизнесом», 2019
3. Cohn M., «User Stories Applied», 2009
4. IIBA, «BABOK V3. Руководство к своду знаний о бизнес-анализе», 2015
5. ISACA, «COBIT 5. A Business Framework for the Governance and Management of Enterprise IT», 2012
6. PMI, «PMBOK Guide. Seventh Edition», 2021
7. Schwaber K., «SCRUM Development Process», 1995
8. Schwaber K., Sutherland J., «The Scrum Guide», 2020
9. Тесля А., «Что такое ценность? Очень кратко»
10. Schwartz M., «What is Business Value?», 2023
11. Verwijs Ch., «What Is This Thing Called “Value”?», 2014