00:00 Добрый день. Как у вас настроение? Уже прошло полдня. Как с энергией там? Все хорошо? Воспользуюсь ситуацией. Скажите, пожалуйста, мы где-нибудь, может, скорее всего, виделись на других конференциях? Покажите рукой, знаете меня? Не знаете. Хорошо. Значит, будем знакомиться. Начнем с того, что надо представиться. Меня зовут Артем Сусеков. Начал как разработчик.

00:27 Занимался этим 8 лет, потом начал заниматься управлением разработкой: как руководитель проектов, как руководитель разработки в заказной разработке, в продуктовой разработке. Четыре года из этих 13 работал в «Мире» как менеджер разработки. Сейчас как Agile-практик работаю в ЛАНИТ, занимаюсь тем, что улучшаю практики в ЛАНИТ. Знаю много про Agile, про OKR, Scrum, Kanban и так далее. Готов об этом поговорить.

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

01:24 Не у всех даже. Это же такая тема модная. [неразборчиво] и у вас нет пилотов. Я думаю, будут все. Хорошо. Из тех, кто показал мне, что есть пилоты, кто из вас может сказать, сколько этот пилот, внедрение, система дает выигрыша, экономии? В общем, про деньги можно сказать? Сколько вы сэкономили, заработали?

01:47 Не «внедрили и улучшили процесс, автоматизировали процесс, улучшили опыт». Про деньги можете сказать? Я понял. Как бы рук существенно, я бы сказал, меньше. В общем, давайте так: сегодня как раз поговорим про этот вот gap между «используем, пытаемся использовать ИИ» и «можем посчитать по деньгам». Сегодня буду говорить не про те истории, когда мы, допустим, купили подписку на корпоративный ChatGPT и назвали это ИИ-трансформацией или, допустим,

02:16 насыпали ИИ в какую-нибудь систему, и тоже у нас как будто бы что-то есть с ИИ. Нет, будем говорить сегодня про те случаи, когда вы подошли серьезно: выбрали вендора, выбрали платформу, обучили команду, провели пилот. В общем-то, все сделали правильно. Но вместе с тем почему-то эффекта какого-то такого, как вы ожидали, вероятнее всего, нету.

02:46 Об этом поговорим. И давайте, наверное, начнем с того… Давайте посмотрим, какие есть причины того, что ИИ не окупается. Есть несколько причин. Хотелось бы поговорить именно про эти. Как правило, когда спрашивают, почему, на ваш взгляд, ИИ у вас не окупается, как правило, называют первую причину.

03:17 Это данные. То есть данные плохие, данных мало, нужно больше данных, нужно их разметить, очистить. В общем, если бы у нас были хорошие данные, у нас бы и все было хорошо, он бы меньше галлюцинировал, в общем, все было бы гораздо-гораздо лучше. Ну, правильно, отчасти это, конечно, так, данные, конечно же, важны, и, безусловно, это тоже есть причина. Но видите, здесь у нас 20%, то есть это явно не все, как вы понимаете, потому что тоже по опыту

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

04:11 ситуация эта кардинально, бывает, и не улучшается. То есть данные это далеко не все. Хотя об этом, безусловно, нужно говорить. Это то, что, как правило, вспоминают в первую очередь. Но это не единственное. Потому что есть, как ни странно, вторая причина. Об этом редко говорят. Это операционная модель. Операционная модель, ну, допустим, как это выглядит. Мы внедрили, допустим, ИИ куда? В отдел продаж.

04:40 Отдел продаж. Что рекомендует система? И как она используется? Ну, что-то система рекомендует. И дальше вопрос, каким образом это использует человек, который системой пользуется. И я буду сейчас про это поговорить побольше, но…

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

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

05:51 мы не зарабатываем, как должны были. Либо как будто системой не пользуются. Почему? Потому что если система не вызывает доверия у конкретных исполнителей, линейного персонала, которые пользуются системой, то, скажем так, все деньги, потраченные на нее, на разработку, на пилоты, на обучение, на все-все-все, просто обнуляются. Потому что системой не пользуются, ей не доверяют, и у вас, получается, рядом существует просто отдельно система

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

06:45 Но зачастую данными фактически оправдывают то, почему система не взлетела, скажем так. То есть это не причина, на самом деле, почему система не заработала. Точнее так: далеко не единственная и даже не основная, скорее всего. Это, скажем так, алиби. Мы подкладываем под себя, в общем, обоснование, почему не получилось. Ну да, можно сказать так. Давайте теперь посмотрим поподробнее по каждому из этих пунктов. Про данные

07:14 я, пожалуй, не буду говорить, потому что это та проблема, когда, на самом деле, мы наймем дата-инженеров, мы, в принципе, наймем подрядчиков, данные можем почистить. Это, скажем так, проблема, которая решается на уровне нескольких, пускай, спринтов, кварталов. То есть это процесс, который можно за достаточно ограниченное время хорошо потянуть. А вот остальное… Традиционная модель, назовем так, обычная модель работы, модель курильщика, как выглядит?

07:43 Без ИИ. Значит, у нас есть какой-то бизнес-процесс, где человек, сотрудник, принимает решение. И когда решение принимается, естественно, мы получаем какой-то результат этого решения. Пускай это будет служба поддержки, отдел продаж.

07:57 Это может быть где-то что-то с консультацией. Что-нибудь, и человек принимает решение и получает результат. Естественно, это влияет на KPI сотрудника. И важно, каким образом мы считаем KPI. Но, как правило, сотрудник оптимизирует свои решения под тот KPI, который на него выкладывается. Все очень просто. Есть решение,

08:16 есть результат, есть KPI. Вопрос возникает еще: где в этом случае ИИ, где в этом случае владелец этой самой ИИ-модели, где управление этими моделями, всем процессом, и где цикл обратной связи, чтобы можно было улучшать то, каким образом работает ИИ в компании. Теперь посмотрим на то, каким образом операционная модель может выглядеть, точнее даже не может выглядеть, а желательно, чтобы она так выглядела.

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

09:10 И важно, чтобы KPI был не у операционного сотрудника, а именно про то, каким образом использование этой системы с ИИ влияет на бизнес. Какой бизнес-эффект? Ну, это выглядит гораздо более разумно. Но есть еще один нюанс, точнее даже четыре. Рекомендация. Кто в итоге владеет моделью,

09:39 которая дает рекомендации? Кто это? Как правило, это IT, департаменты технологий, айтишники, в общем, не бизнес, как правило. То есть это вопрос, кто владеет моделью и кто решает: пора обновлять модель, пора ее переобучить, потому что уже не то, какие-то рекомендации не такие точные,

10:02 пора вообще это решение, которое работало, все, оно себя изжило, пора отключать. Это очень сложное решение, которое дается, как правило, гораздо сложнее, чем «давайте запустим новую систему или что-нибудь обновим». Следующее: когда мы принимаем решение, кто отвечает за это решение? То есть если есть сотрудник, у него есть система, которая дает ему какую-то подсказку, например, и он может ей воспользоваться и следовать подсказке,

10:32 а может игнорировать. Где политика, в каком случае это можно? Это обязательно, не обязательно? Какие последствия? Кто это определяет? Что будет ему за то, что он послушался и получилось плохо? Или, допустим, не послушался и получилось плохо? Какая политика использования? Без этого получается такая дихотомия: если я воспользовался системой, я просто соглашаюсь, и это все,

10:57 то получается, у меня нет мотивации. Я чувствую себя со временем просто ненужной частью. Я просто на все соглашаюсь. Если я могу легко, без всяких последствий игнорировать, то она что есть, что нет. Я имею в виду эту рекомендацию. Ну и все.

11:17 Здесь важно, чтобы была сформулирована четкая политика, каким образом мы работаем с информацией системы. Дальше. Цикл обратной связи, я об этом сказал. Все последствия решений обязательно нужно заводить на вход модели, чтобы можно было обучать. Потому что как выглядит чаще всего?

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

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

12:29 был явный KPI не у линейного сотрудника, а у директора, ну, не директора, а департамента именно из бизнеса, кто отвечает за деньги, кто отвечает за финансовый результат. Потому что, чаще всего так и есть, за эксплуатацию решения в компании отвечает IT-департамент. И в этом случае, как правило, KPI IT-департамента это про что? Это про uptime,

12:56 все работает, точность предсказаний, какие-то метрики, как правило, более технические, потому что подписываться IT-департаменту под бизнес-эффект, ну какой резон? IT-департамент бизнесом не рулит. Если есть KPI, допустим, у директора по продажам, например, по развитию, коммерческого директора,

13:19 который отвечает за финансовый результат, и у него в KPI зафиксировано, сколько мы планируем сэкономить, например, сколько ставок, допустим, или сколько денег мы хотим сэкономить, потому что мы, допустим, сократим цикл сделки, и мы знаем, какой у нас процент конверсии сделок, мы явно можем посчитать, предположить гипотезу, каким образом мы сэкономим. И это именно про деньги, и именно про то,

13:47 что этот KPI должен быть на уровне бизнеса, не IT. Вот это тоже можно как раз сфотографировать, все вместе, слева и справа. Это модель курильщика и модель здорового человека. Здесь все вместе, чтобы было удобно. В общем, мы видим другую, скажем так, модель, другой флоу работы, и обязательно вот эти все

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

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

15:13 А доверие к системе это не… Когда мы говорим про доверие, как правило, возникает соблазн подумать, что, чтобы системе доверяли и пользовались, нужно провести обучение, поработать с сопротивлением, рассказать, обучить, вовлечь, какой-то engagement как-то, в общем, сделать. Но если в систему это не встроено на уровне архитектуры, это все будет, как называется,

15:42 мертвому припарки, потому что, чтобы системой реально пользовались, в ней должна быть архитектура, которая позволяет ей доверять. Что это такое? Первое. Это именно воспроизводимость результата, что особенно важно в случае больших языковых моделей, потому что есть некая недетерминированность. Но именно воспроизводимость это очень важно, потому что если система сегодня

16:04 мне на мой обычный вопрос ответила одно, а через несколько дней ответила другое, и я не понимаю почему, у меня возникает вопрос: оно вообще работает? Могу ли я доверять? Я не понимаю, как это вообще. Если я не понимаю, как я и сказал, я могу либо просто соглашаться, либо… Если не понимаю, лучше я буду как привык.

16:30 Это очень важно, потому что если нет, вот такой есть мыслительный паттерн: сегодня одно, завтра другое, как этому можно доверять? Следующее это объяснимость. Что это такое? Когда система не просто что-то рекомендует, но еще и можно посмотреть, почему именно. Почему такая рекомендация? На основании чего? Какая уверенность, на каких данных? Какие критерии? Что сработало, что не сработало?

16:58 Почему именно так? Потому что если нет, тогда система для меня черный ящик. Оно как-то работает, как-то лампочками мигает. Ну и уже возникает вопрос: могу ли я такому доверять? Непонятно. Как бы непонятно. И третье из архитектурных свойств системы. Это, наверное, важно в большей степени, скажем так, для госа, для корпоративных, где сильный compliance.

17:28 Что это такое? Когда рекомендация, которая была дана, и решение, которое принято, все это зафиксировано: на каких данных, почему, с какой уверенностью. В общем, почему это важно? Потому что если этого нет, нельзя при необходимости провести полный разбор, почему такое решение было принято, на основании чего, почему и как, какие у вас тогда были данные. Тогда это получается как? Есть человек, который принял решение,

17:57 с него весь спрос. А как там система работала, не работала, это меня как проверяющего вообще не касается. Есть человек, он отвечает. И без этого… Я как человек, которого будут проверять, мне сильно важно, чтобы я мог потом, когда я забуду, все это при необходимости поднять и показать: вот были такие рекомендации, и вот почему я принял такое решение. Потому что если этого нету, это больше про

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

18:47 Теперь есть ответ, что нужно делать. Расскажу очень коротко. Первое, что нужно делать: чтобы владелец системы был именно со стороны бизнеса. То есть, еще раз подчеркну, обычно это IT. Но для успешного внедрения, использования важно, чтобы это было на бизнесе,

19:16 то есть было конкретное имя, у кого есть KPI именно в деньгах: сколько мы заработали, сэкономили. В общем, какая-то конвертация в финансовый результат. Второе. Важно не просто добавить в процесс, а именно встроить. Что это такое? Это когда без использования системы получается объективно дольше, дороже, менее комфортно. Как проверить? Если мы выключим, насколько, в общем, станет больно.

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

20:10 Как раз было до этого, за несколько слотов до меня, выступление как раз про экономику [ИИ-проектов]. Нужно считать в деньгах. Это сложно делать, но это крайне важно. Потому что с первого дня, с пилота, надо это делать именно не в точности модели, не в accuracy, не в дрифте модели, не во всем этом, а именно в деньгах. Именно до запуска.

20:37 Потому что если мы не можем сказать: мы ожидаем сэкономить, заработать там то-то, то-то, в деньгах столько-то. Второй вопрос: у меня такой-то сейчас бейзлайн. Я сейчас вот таким-то образом… допустим, цикл сделки, вот он так выглядит, бейзлайн. И третье: через сколько месяцев мы будем мерить, что получилось в деньгах. Если мы не знаем, не имеем понимания, сколько мы собираемся заработать,

21:03 реально заработать, как мы можем оценить успешный или неуспешный результат? Согласитесь. Хорошая есть новость по этому поводу: эти решения принимает именно бизнес, а не IT. И это хорошо. Для того чтобы все заработало, не нужно нового вендора, не нужно нового технического решения, нужно, чтобы было принято решение на уровне бизнеса. Важно, что

21:32 это решение не является сильно дорогостоящим, это больше управленческое решение. На опыте внедрения LANDEV AI мы этим занимаемся, помогаем бизнесу пройти через все эти этапы, чтобы было не просто добавление, а именно внедрение с пониманием, каким образом меняется бизнес-процесс, и каким образом считать все самое финансовое до старта. Наверное, на этом могу сказать, что ИИ все-таки, на мой взгляд, окупается.

22:01 Важно, когда компания готова к изменениям. И возникает вопрос, открытый к вам, не чтобы прямо сейчас ответили мне, хотя это было бы здорово: а готовы ли вы со своей стороны к таким изменениям? Что думаете? Спасибо большое. В общем, вот контакты мои. Можно показать демонстрацию. Спасибо большое.

22:30 Вопрос из зала: Да, про операционную модель. Соответственно, они вот пришли в такую историю: [неразборчиво] бардак получили, и бардак. То есть это у вас там сидит, по идее? Прежде чем что-то делать, соответственно, нужно оптимизировать сам процесс, посмотреть входы-выходы, нет ли петель там и так далее, потому что ИИшка это усугубит, это там сразу бывает.

22:49 Артем Сусеков: Это в целом общее место для любой автоматизации. То есть если мы бардак автоматизируем, мы получаем высокоэффективный бардак.

23:00 Вопрос из зала: Высокоскоростной бардак.

23:01 Артем Сусеков: Все правильно. Это в том числе там, конечно же. Но это опять-таки вопрос не технический, согласитесь. Это вопрос именно организационный.

23:09 Вопрос из зала: Просто, собственно, окупаемость. То есть иногда есть иллюзия того, что сейчас мы на наших процессах сделаем эффект сжатого времени, и все будет окупаться. А если у нас там, грубо говоря, все [неразборчиво], то мы сожмем время, сделаем бесконечные циклы, и у нас…

23:25 Артем Сусеков: Все верно, все верно, да. Мы просто будем тратить больше денег на неэффективные работы. Знаете, мне нравится такое выражение, что такое суетиться: делать медленные движения без паузы между ними. То есть вот здесь, получается, наоборот: мы делаем много лишних движений и делаем их еще сильно быстро.

23:49 Спасибо большое.