Альфа коммерческой возможности ​

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

Эта идея попадает в головы двум фирмам. Они придумывают более-менее одинаковую концепцию системы (тяжёлая металлическая часть, снабжённая удобной деревянной рукояткой). Но одна фирма специализируется на функции «забивала» (не исключая побочно выполняемой функции «разбивала») и называет свой продукт «молоток» с плоским бойком и клином с острым носком в головке молотка:

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

«Простая» проблема предложения системы в том, что для понятного набора функций системы (говорится об известной концепции системы) нужно предложить её конструкцию из подсистем (синтезировать концепцию каждой подсистемы, и так на много уровней вниз). В случае потребностей конструктивные решения обычно не так очевидны, о них должно быть сделано рациональное предположение, а затем предложена такая концепция целевой системы (хотя бы на уровне идеи), которая могла бы удовлетворить концепции использования. Эта работа увязывает два неизвестных вероятностных (предпринимательские гипотезы!) описания двух разных систем (надсистема с концепцией использования и целевая с концепцией системы) и исключает разные неприемлемые варианты типа запроса на скатерть-самобранку (легко предложить концепцию использования, нелегко предложить конструкцию системы) или дешёвый («чтобы был не дороже билета на самолёт, иначе наш маркетинговый отдел возражает!») пассажирский транспорт на Марс. Это исключает и вариант «вот наши инженеры сделали Глюклу, она очень хитро устроена и хорошо издаёт забавные звуки (глюкает), когда крутится в воде, теперь мы не знаем, куда бы её приткнуть --- где бы мог пригодиться такой сервис? Никто не знает, где нужна такая функция?».

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

А ещё не надо писать банальности, которые всем известны --- типа «интерес в том, чтобы система была дешёвой». Это проверяется путём подстановки слова «обувь» вместо названия системы. Скажем, написано «глюкла должна быть дешёвой» --- «обувь должна быть дешёвой». Хорошо звучит, никакого онтологического дребезга. Значит, мы сказали какую-то общеизвестную истину, которую можно и не говорить, «спасибо, Кэп»^[1].

В любом случае, повторим ещё раз (ибо все студенты по десять раз задают этот вопрос): алгоритма выдвижения предпринимательской гипотезы как идеи проекта нет, это сугубо творческий акт. Это «поиск аффордансов в нише», как говорят вслед за биологами специалисты по дизайну (и affordance тут один из синонимов к opportunity, по-русски это всё будет «возможности»^[2]).

Альфа коммерческой возможности (opportunity/«возможно делать», не путать с possibility/«вероятно/возможно существование») нужна для отслеживания в ходе проекта по созданию/изменению целевой системы самой возможности его выполнения, отслеживанию того, что возможность не исчезла по ходу проекта --- для этого предполагается, что система будет развиваться. Целевая система будет разрабатываться, изготавливаться, эксплуатироваться и в ходе этого постоянно развиваться/модернизироваться только в том случае, когда

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

Можно возразить, что не все проекты связаны с какими-то коммерческими возможностями (скажем, политические проекты). Нет, это не так. Все: если денег на пропитание команды нет, то команда не будет работать, займётся чем-то другим, чтобы её члены могли банально выжить. Если же люди работают, не требуя оплаты, да ещё и оплачивают работу своего оборудования (включая компьютеры и связь), то это просто означает, что они сами за это и платят (ибо находятся в двух ролях: члены организации проекта и внешние проектные роли). Мы тут про роли, а не про конкретных людей. Это важно, ибо в «некоммерческих проектах» придётся всё равно оценивать их выполнимость, определять потребность в ресурсах, планировать «коммерческую/ресурсную/бизнес возможность». И тут нужно не ошибаться: например, если помогаете голодным в Африке, то заказчиками::«внешние проектные роли» являются спонсоры/благотворители, а изготавливаете сытых/бенефициаров::«целевая система»! Заказчики не сами голодные, а те, кто платит за их сытость! Голодные тут бенефициары, а не заказчики благотворительности! И если благотворителей нет, а голодных много, то «нет коммерческой возможности кого-то накормить», проекта нет. Нужно быть очень внимательным при обсуждении альфы коммерческой возможности в «некоммерческих проектах»! Там часто очень контринтуитивные рассуждения. Если вы, например, хотите затеять небольшую войну как проект, то какие-то люди могут посчитать, что у них от вашего проекта будет не прибыль, а убыток, и будут готовы заплатить деньгами, другими ресурсами, собственным трудом за то, чтобы помешать вашему проекту: и «маленькая победоносная война» закончится крахом по ресурсным соображениям. Это неважно, речь идёт о горячей войне, холодной войне или торговой войне. Альфа «коммерческая возможность» говорит о том, быть проекту или не быть, о ней нельзя забывать в ходе всего проекта (как и обо всех остальных). И помним, что её нужно отслеживать всё время проекта: системы не только создаются в их первой версии как MVP, но и постоянно развиваются, участвуют в техноэволюции.

Альфой коммерческой возможности занимаются главным образом (это подробней обсуждается в курсе «Системный менеджмент» в разделах про стратегирование):

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

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

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

Состояние альфы коммерческой возможности может характеризоваться самыми разными документами: «бизнес-планом», «концепцией», «обоснованием инвестиций/инвестиционным меморандумом», «бюджетом проекта», «рыночным исследованием», «проектным предложением» и т.п.. Эти документы в свою очередь отражают состояние «концепции использования», «концепции системы», различных моделей, которые разрабатываются в ходе стратегирования (в курсе «Системный менеджмент» подробно разбираются три такие модели --- бизнес-модель, модель оргразвития и модель целеполагания). Так что альфа коммерческой возможности может иметь в качестве своих подальф самые разные подальфы самых разных других альф.

Коммерческая возможность выполнить проект --- это деятельная инициатива, предпринимательство как предсказание будущего, изобретательство в чистом виде, методы/практики работы с этой альфой слабоформализуемы, там больше работает не прикладное, а фундаментальное мышление «из первых принципов» --- ибо это решение проблем, которые раньше не встречались, и очень часто в предметных областях, которых ещё нет (если компания первой выходит на рынок в надежде его захватить раньше, чем придут конкуренты). Прежде всего работа с этой альфой связана со способностью предугадать будущее, а это делается на основе хороших порождающих моделей/generative models, то есть лучших общих представлений об устройстве мира (в частности, наши фундаментальные курсы интеллект-стека дают ровно такую модель, мета-мета-модель мира --- абстрактное его многоуровневое описание).

Альфа коммерческой возможности в ходе проекта проходит следующие состояния/контрольные точки, но их нужно понимать не только как контрольные точки в выпуске первой версии системы (чаще всего это MPV, minimal viable product, минимальный жизнеспособный продукт), но и инкрементов в улучшениях --- каких-то новых фич системы, каких-то модернизаций самой системы, улучшающих её способность удовлетворить потребности, быть аффордансом в нише, которой занимаются внешние проектные роли^[3]:

• Выявлена (identified): найдена идея; найден как минимум один исполнитель проектной роли, желающий сделать инвестицию в понимание коммерческой возможности; определены другие проектные роли.
• Нужно решение (solution needed): установлены потребности; определены проблемы и их причины, имеется концепция использования, целевая система/solution одобряется внешними проектными ролями как нужная, был предложен как минимум один вариант концепции системы, одобряемый внутренними проектными ролями.
• Польза установлена (value established): польза^[4] от реализации проекта была определена количественно; влияние решения/solution/целевой системы на внешние проектные роли понятно; польза системы внешними проектными ролями понимается; критерии успешности ясны; результаты ясны и выражены количественно.
• Жизнеспособна (viable): целевая система возможна с учётом всех известных ограничений; риски приемлемы и управляемы; проект выгоден; причины для создания целевой системы (или её инкремента/фичи/модернизации) понимаются; ясно, что проект как реализация коммерческой возможности жизнеспособен.
• Реализована (addressed): коммерческая возможность реализована; целевая система введена в эксплуатацию; внешние проектные роли удовлетворены;
• Извлекается выгода (benefit accrued): проект создания целевой системы принёс выгоду; возврат на инвестиции приемлем.

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

Достижение каждого состояния альфы «возможности» проверяется прохождением вышеупомянутого чеклиста, и свидетельствуется какими-то артефактами (документами тех или иных моделей надсистемы, целевой системы и систем в цепочках создания), но в нашем курсе мы не будем подробно это рассматривать. Это предмет системной инженерии и системного менеджмента, отдельных курсов.

Сама себя альфа коммерческой возможности не двигает, возможность бизнеса сама себя не выявляет, «инициативы» по проекту сами по себе не ведут к коммерческому успеху. «Безумные изобретатели» предпринимают безумные проекты, но эти проекты часто не ведут к выгоде --- нет работы с альфой коммерческой возможности! Альфа коммерческой возможности весьма медленно переходит в состояние «извлекается выгода», часто это занимает несколько лет. Для этого нужна упорная работа команды проекта, а эта работа должны проводиться по какому-то методу, каким-то практикам, в том числе с альфой возможности работают и фундаментальные мыслительные практики (трансдисциплины, поддержанные моделерами) интеллект-стека (физика, онтология, рациональность, исследования, этика, риторика, методология, системная инженерия в числе них), а также понимание того, что надо будет проект как-то организационно оформлять (системный менеджмент).