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

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

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

Сторона затрат

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

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

Стратегии контроля затрат следующие:

Итерации

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

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

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

3. Вы получаете хорошее представление о потенциально достижимом качестве.

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

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

Промежуточное финансирование

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

Собирать данные

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

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

Строительные модели

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

Развертывание

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

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

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

Объедините свои проекты ИИ

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

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

бизнес-культура ИИ

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

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

Доходная сторона

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

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

Кого ты пытаешься победить?

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

Презентация вашего бизнес-кейса

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