Блог Кирилла Позднякова

Коммерциализация, коммерциализация, коммерциализация

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

Читаем

Всем привет! Была небольшая пауза в постах. Собирал новые мысли.

Обновил сайт Лаборатории архетипов. Там — наши исследования и проекты о том, как компании выбирают стратегию и организуют работу.
Заходите посмотреть. Если какая-то тема окажется близкой — пишите, будем рады поработать вместе.

Гипотеза ИТ платформы

Код ИТ платформы 101, поиск внутренней эффективности за счет синергии.

Формулировка гипотезы:

Мы считаем, что [внутренние потребители], сталкивающиеся с [дублированием, несовместимостью или высокой стоимостью локальных решений] и использующие [разрозненные альтернативы], смогут создавать больший системный эффект с помощью [общей способности, платформы, стандарта или интерфейса], потому что она обеспечивает [повторное использование, совместимость или снижение совокупных издержек] за счёт [общих компонентов и правил].
Распространение будет происходить через [стандарты, интерфейсы и механизм подключения]. Финансирование — через [корпоративный или платформенный бюджет].
Потенциал составляет [число потребителей, объём повторного использования и системный эффект], реализация потребует [затраты и команда].
Гипотеза получит достаточное подтверждение, если [критерий подключения, повторного использования, TCO или времени интеграции] будет достигнут за [срок].

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

Гипотеза цифровой трансформации

Центр цифровой трансформации в предложенной мной типологии имеет код 100. А значит тоже должен искать способ достижения цели через проверку гипотез.

Например такую:

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

Тут особенно легко перепутать внедрение информационной системы с изменением работы. Система запущена. Люди продолжают работать по-старому. Формально проект завершён, но исходная гипотеза не доказана.

Управление гипотезами

Что мы обычно слышим на встрече:
- Сколько задач выполнено?
- Когда будет релиз?
- Мы укладываемся в бюджет?
- Какой SLA?

Это нормальные вопросы для R0

А часто ли мы слышим:

Какие гипотезы вы сейчас проверяете?
- Что именно пока неизвестно?
- Какое доказательство откроет зеленый свет?
- Сколько мы готовы вложить до его получения?

Эти вопросы означают что подразделение работает в режиме R1

А так может выглядеть шаблон гипотезы для задачи коммерциализации ИТ решения:

Мы считаем, что [клиенты], испытывающие [проблему] и использующие [альтернативу], готовы купить [решение], потому что оно обеспечивает [УТП] за счёт [суперсил решения].
Продажа будет осуществляться через [канал или партнёра] по модели [источник дохода и цена].
Потенциал составляет [число клиентов и выручка], реализация потребует [затраты и команда].
Гипотеза получит достаточное подтверждение для следующего решения, если [измеримый критерий] будет достигнут за [срок].

В следующих постах я приведу шаблоны для других типов поисковых гипотез.

Все мы знаем про CRM и воронку продаж. А часто ли мы слышим про воронку гипотез? Часто ли сравниваем ее с целями по росту выручки или повышению эффективности?

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

В новой статье с Михаилом Корольковым разбираем внедрение ИИ через модель организационной культуры Эдгара Шейна: почему запреты не останавливают использование ИИ, откуда возникает разрыв между декларируемыми ценностями и реальными практиками и почему внедрение ИИ в итоге становится задачей организационного проектирования.

https://blog.bitobe.ru/article/kultura-vnedreniya-ii-kak-soglasovat-instrumenty-pravila-i-kulturu-organizatsii/

После трех опросов у меня осталось некоторое беспокойство.

Во втором опросе только 5% участников ответили, что работу, созданную с помощью LLM, нельзя считать выполненной. Остальные варианты допускали такую работу: кому-то достаточно достойного результата, большинству нужна проверка исполнителем.

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

И здесь возникает риск.

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

В первом опросе 51% участников выбрали ответ: запрет внешних LLM не повышает информационную безопасность, использование просто уходит в тень.

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

Третий опрос добавил еще одну деталь: 63% считают освоение ИИ общей ответственностью сотрудника и компании. Значит, от организации ждут доступных инструментов, правил и помощи в освоении.

Для меня эти ответы складываются в разрыв.

Компания может декларировать безопасную работу с ИИ. Сотрудник уже считает LLM нормальным рабочим инструментом.

Между ними остается запрет без удобного и легального способа решить ту же задачу.

И вот здесь использование ИИ становится невидимым для компании.

Интересно - что компании оставят внутри закрытого контура и что разрешат отдавать публичным LLM под контролем.

От гороскопа к стратегии

После постов про R, V и C можно пытаться раздать всем готовые типы.

Эксплуатация - 000. Венчурный продукт - 111. Зрелый продукт - 011. Бэк-офису снова достаётся ретроградный Меркурий.

Я открыл Стратегию-2028 Московской биржи и на базе описанного подхода выделил четыре контура.

Торгово-клиринговая инфраструктура - 000. Способ установлен, результат принимается по нормативу, критические исключения уходят наверх. Ошибка считается дефектом.

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

«Финуслуги» - 111. Рабочая связка продукта, сегмента, канала и доверия заранее неизвестна. Ответ виден в поведении клиента. Команде нужны права быстро менять гипотезы и делать малые ставки.

Изменение культуры и процессов - 100. Способ сократить time-to-market приходится искать. Результат принимают внутренние контуры, крупные права сохраняются у спонсора.

Из стратегии можно вывести - четыре режима работы.

Если всем выдать 000, «Финуслуги» утонут в согласованиях. Если всем выдать 111, инфраструктура начнёт экспериментировать там, где слово «эксперимент» особенно бодрит.

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

Ну вот и закончилась скучная история про три оси.

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

Теперь можно сделать главное — раздать всем коды.

000 — классическая ИТ-служба
Простая, надежная ИТ-служба c SLA, нет поиска, работаем внутри, сидим на бюджете

001 — shared service center
SLA на месте, ресурсы планируем сами — исходя из объёма услуг.
Появляется биллинг. Сначала в Excel. Потом Excel становится критической информационной системой.

010 — фабрика фич
Заказчиков много, они же принимают работу. Мы разрабатываем.

T&M, поэтому C=0. Даже если fix price, все равно доплатят, поэтому T&M.

В бэклоге 700 задач. Каждая нужна вчера. Приоритет у всех одинаковый: высокий.

011 — продуктовая фабрика
Идём к клиентам проверять ценность, ресурсами управляем сами.

100 — центр цифровой трансформации
Ищем эффекты внутри компании. Ресурсы — в рамках бюджета.

101 — платформа
Ищем эффекты внутри компании, ресурсы планируем сами.
Все хотят общую платформу. Особенно пока общие стандарты не коснулись их лично.

110 — НИОКР
Ищем ценность для рынка, живём на бюджете.
Можно полгода доказывать, что эксперименту нужны ещё полгода.

111 — внутренний венчур
Ищем ценность для рынка, ресурсами управляем сами.

Самая бодрая комбинация. Особенно до появления первого настоящего клиента.

Получился почти корпоративный гороскоп.

Знак зодиака — три цифры.

А у вашей комнады какой код?

Итак, в предыдущих постах я рассказал о двух осях - R и V. Сегодня поговорим о C.

Если ось R - про природу знания, ось V - про место оценки ценности, то C - про субъектность.

Буква C - от английского Control. Обычно это слово переводят как «контроль». В моей модели речь о праве принять решение, когда готового правила для ситуации нет.

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

Это я называю критическим остаточным решением. Субъектность здесь имеет следующий смысл: чьё понимание ситуации становится обязательным действием организации.

C0 - решение принимается снаружи контура.

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

C1 - решение принимается внутри контура.

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

C1 не даёт команде права решать всё. У неё должен быть понятный мандат: какие решения она принимает сама, какими ресурсами распоряжается и при каком риске обязана выйти на системный уровень.

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

В 1986 году Grossman и Hart в работе The Costs and Benefits of Ownership связали собственность с остаточными правами контроля в ситуациях, не описанных контрактом. В 1997 году Aghion и Tirole в работе Formal and Real Authority in Organizations разделили формальную и реальную власть.

Для моей модели отсюда следует вывод: C надо определять по реальным решениям.

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

Если частые обратимые решения поместить в C0, внешний центр постепенно превращается в очередь согласований. Если системное решение отдать в C1 без ограничений, локальный результат может улучшиться за счёт соседних контуров.

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

Ось V

Про R я уже написал. Сегодня - вторая ось, V.

R (repertoire) - набор известных способов работы. V (value) - ценность результата.

Ось V отвечает на вопрос: кто вправе сказать, что работа закончена и результат годится?

V0 - результат признает сама компания.

V0 выбирается, когда:

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

V1 - результат должен пройти независимую проверку.

V1 выбирается, когда:

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

Например.

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

Компания выводит на рынок новый продукт. Руководство может утвердить идею, бюджет и план запуска. Клиента это решение ни к чему не обязывает. Он голосует покупкой и использованием. Это V1.

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

У оси V нет одного прямого аналога в литературе. Это мой синтез нескольких идей. Kohli и Jaworski в работе Market Orientation показали, что информация о рынке должна доходить до решений компании. Meyer и Rowan в работе Institutionalized Organizations описали организации, в которых успех определяют принятые правила и ожидания.

Для моей модели это два способа решить, считается ли работа успешной.

Что меняется в управлении.

В V0:

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

В V1:

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

Если V1 вести как V0, внутреннее одобрение подменяет реакцию клиента. Презентации зеленые, план выполнен, клиент все равно не выбирает результат.

Если V0 вести как V1, обязательная функция начинает доказывать свою популярность и может остаться без ресурсов.

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

Ось R

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

Ось R - это про то, известен ли способ действия или его надо искать.

R0 - установленный способ выбирается, если:

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

R1 - поиск способа выбирается, если:

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

Например.

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

Если стоит задача выйти на новый рынок, но мы пока не знаем, с чем выходить, мы строим гипотезы и проверяем их. Это R1. Выход из контура — выводы о том, что продается, кому и при каких условиях.

В 1991 году James G. March в работе Exploration and Exploitation in Organizational Learning разделил поиск новых возможностей - exploration - и использование уже известного - exploitation.

Из его работы следует важный для моей модели вывод: для этих двух состояний нужны разные подходы к управлению.

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

Что в них разного.

В R0:

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

В R1:

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

Если R1 управлять как R0, гипотеза быстро превращается в обязательство, а отрицательный результат - в провал команды. После этого команда начинает выбирать гипотезы с заранее понятным результатом. Формально работа идет успешно, но поиск постепенно исчезает.

Если R0 управлять как R1, каждый начинает заново изобретать способ работы. Процесс теряет стабильность, качество начинает зависеть от конкретного человека, растет число исключений.

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

Стратегию предложил ИИ. Кто тогда автор? Если искусственный интеллект предлагает идеи, анализирует варианты, и даже формирует стратегию, что остается человеку?

Разбираем по косточкам.

https://blog.bitobe.ru/article/strategiyu-predlozhil-ii-kak-sohranit-avtorstvo-vybora-za-komandoy/

С 1 сентября 2026 года в России вступит в силу закон об искусственном интеллекте. Ну вступит и вступит.

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

Это пересекается с темой авторства. На днях в блоге BITOBE и, возможно, в их блоге на РБК выйдет наша с Михаилом Корольковым статья об авторстве при работе с LLM. Там мы говорим о других аспектах авторства, вне юридической плоскости. Спойлерить не буду.

Но почему я задумался об этом именно в контексте закона?

Вроде бы по условиям использования большинства коммерческих сервисов на базе LLM права на результат передаются пользователю. У OpenAI, например, сказано: во взаимоотношениях между компанией и пользователем результат принадлежит пользователю — в той мере, в какой это допускает применимое законодательство. OpenAI не претендует на исключительные права на созданный результат.

С авторским правом всё сложнее. Его регулирует законодательство конкретной страны. Если результат полностью создан моделью без существенного творческого вклада человека, такой объект может вообще не охраняться авторским правом.
Если человек использовал LLM как инструмент — определил замысел, многократно перерабатывал материал, отбирал варианты и так далее, — итоговая работа уже может считаться произведением человека.

И вот вчера пролетела новость: с одного промпта создали шутер. Я зашел на GitHub — там лежит сам промпт и всего два коммита.

Возникают ли у такого продукта авторские права?

И если да, кому они принадлежат: тому, кто написал промпт, или тому, кто обучил LLM? Или никому?

LLM хорошо справляется с интеллектуальной рутиной: написать текст, написать код.

Я уже писал: вопрос - в проверке. Или, как говорит Андрей Карпати, - в верификации.

Всё, что подлежит быстрой верификации, работает. Остальное требует человека.

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

Почему так происходит?

Потому что неверно оценили детерминированность чат-бота. Система пока не может надёжно оценивать верность собственных ответов и проводить их валидацию. Человек может.

Более того, у клиента нет полномочий, которые есть у оператора колл-центра.

Значит, человека необходимо оставить в колл-центре. Всю рутину по диагностике и сбору информации отдать LLM и ИИ-агентам. Взаимодействие с клиентом и принятие решений оставить за оператором.

Это может повысить эффективность и при этом не оттолкнуть клиентов.

Вот такое размышление.

Кажется, что ИИ снижает транзакционные издержки.

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

Но одновременно выросла стоимость другого процесса - проверки.

Мы теряем доверие к резюме.

Перестали верить экспертным постам.

Настороженно относимся к книгам, написанным ИИ.

Надо постоянно проверять код, который он сгенерировал.

Отсюда кажется, что:

ИИ не уничтожает транзакционные издержки.

Он переносит их.

Издержки создания информации падают.

Издержки проверки достоверности растут.

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

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

Отсюда возникает гипотеза:

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

Меняется структура издержек, создавая новый рынок - рынок доверия.

Интересно, если эта гипотеза верна, то компании будущего будут конкурировать уже не качеством ИИ, а способностью быстро отвечать на один вопрос:

Почему этому можно доверять?

Михаил Корольков прислал статью с интересной мыслью: похоже, мы постепенно переходим от Software as a Service к Service as Software.

Когда-то SaaS казался главным изменением: больше не покупаем коробку с программой, пользуемся сервисом.

Теперь парадигма меняется.

Если ИИ уже умеет анализировать, рассуждать, принимать решения и выполнять значительную часть интеллектуальной работы, то почему услуге вообще нужен человек в каждой операции? А если нужен, то в каком объеме? Может сам клиент справится?

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

Консалтинг. Аналитика. Подбор. Проектирование. Юридическая работа. Финансовый анализ.

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

Я тоже сейчас осторожно экспериментирую именно в этом направлении. Все чаще ловлю себя на мысли - «какую услугу можно превратить в ПО?».

Думаю, именно здесь будет происходить следующая большая волна изменений.