Про это как будто бы никто не знает, но мы работаем с логистикой уже около 8 лет. Никогда не ставили себе такой цели, но привыкли честно работать с разными запросами клиентов. В итоге научились управлять заказами и отгрузками, создавать внутренние биржи грузоперевозчиков и даже немного контролировать склады. Чтобы как-то систематизировать свой опыт, последние месяцы много говорим с рынком логистики – DPD, Байкал Сервис, Boxberry и ещё с десяток разных компаний. Для себя и для коллег завели канал, где делимся тем, что узнаём или подтверждаем через интервью. Подписывайтесь - https://yangx.top/digital_logistics_pro
Telegram
Rubius/Digital логистика
Канал команды цифровизации логистики компании Rubius. Делимся опытом, кейсами и обсуждаем будущее отрасли с диджитал-лидерами со всей России
🔥7👍1
Когда я только начинал этот канал, я говорил, что буду делиться и своими провалами … сегодня тот самый случай🙂
В процессе рефлексии над причинами провала одного недавнего проекта в голову пришла одна забавная аналогия.
Когда команда только начинает проект, то это как первый запуск старенького мопеда во дворе: все друг друга подбадривают: "Да он мощный, сейчас как попрёт!"… но выясняется, что передачи не переключаются, колёса подспущены, а руль ведёт вправо. И ты едешь на этом мопеде с мыслью: "Ну ладно, главное доехать до воображаемого финиша в конце двора, а проблемы после поправлю". А в реальности — доработки как-то откладываются.
Так и в проекте всё начиналось красиво: проект — важный, срочный, амбициозный. Собрались, обсудили сроки, распределили задачи. На бумаге всё было идеально. Но… только на бумаге.
Во-первых, сильно недооценили, что в проекте так много заинтересованных. Каждый день в проекте появлялся новый отдел, директор или служба, которым тоже очень важны результаты и у всех есть свои требования к проекту. А руководитель проекта, только разводил руками и пояснял: сроки горят, в суматохе забыли про коллег.
Во-вторых, в из-за большого стремления попасть в очень жёсткие сроки при постоянно увеличивающемся объёме задач, мы стали пропорционально быстро наращивать команду. Погружение в проект у каждого нового участника команды стремилось к угрожающему минимум так быстро, что очень скоро получили ситуацию, в которой половина команды не понимала первоначальную цель проекта.
Ну и конечно же — срочность и приоритеты. Давайте будем честны: люди не всегда понимают, зачем и почему срочно. Молодые сотрудники часто считают, что их основная задача заключается лишь в том, чтобы выявить проблему и сообщить о ней руководству. Они полагают, что ответственность за решение автоматически переходит «наверх». С другой стороны, опытные сотрудники склонны видеть причины проблем в изначально неправильном распределении задач и обязанностей. Им кажется, что проблемы могли бы быть предотвращены, если бы руководство уделило больше внимания приоритетам. В итоге никто по-настоящему не бежит тушить пожар. Наверняка на бумаге в проекте всё прекрасно с приоритетами, но без понимания взаимосвязей между результатами — это остаётся просто словами.
В итоге на очередном проектном митинге стало очевидно, что наш проект летит в трубу с огромной скоростью: заказчик не понимает приоритета задач, мы не понимаем для чего мы их делаем. Поэтому с большой болью пришлось остановить все работы и попытаться всё систематизировать. К сожалению, сжатые сроки проекта не позволили заказчику взять паузу на планирование и он принял решения продолжать проект без нас.
Иногда проект пытаются спасать быстрыми решениями. На совещании кто-то резюмирует: "Сделаем как есть, двинемся дальше". И да, это может сработать локально, чтобы избежать катастрофы в моменте, — но становится ли от этого проект лучше или легче? Нет. Эти временные решения, хоть и частично эффективны, но как снежный ком, накапливают новые сложности, которые рано или поздно приведут к нерешаемым проблемам.
Хотите реальной аналогии? Представьте дом, в котором каждую новую трещину на стене заклеивают скотчем. Вначале — немного, потом больше. По итогу дом стоит весь в серебряных полосках, но не потому, что это дизайнерское решение)
Важно не только планировать проект на входе, но и буквально выращивать культуру ответственности:
📍Каждый сотрудник должен видеть, где он в цепочке, понимать, что от него зависят ключевые решения
📍Онбординг в проектах. Без наставничества и должной поддержки новым членам команды сложно вливаться в работу и быстро приносить результаты
📍Приоритеты — это не абстрактные показатели. Нужно в реальном времени доносить изменения на каждом этапе до всех участников
В процессе рефлексии над причинами провала одного недавнего проекта в голову пришла одна забавная аналогия.
Когда команда только начинает проект, то это как первый запуск старенького мопеда во дворе: все друг друга подбадривают: "Да он мощный, сейчас как попрёт!"… но выясняется, что передачи не переключаются, колёса подспущены, а руль ведёт вправо. И ты едешь на этом мопеде с мыслью: "Ну ладно, главное доехать до воображаемого финиша в конце двора, а проблемы после поправлю". А в реальности — доработки как-то откладываются.
Так и в проекте всё начиналось красиво: проект — важный, срочный, амбициозный. Собрались, обсудили сроки, распределили задачи. На бумаге всё было идеально. Но… только на бумаге.
Во-первых, сильно недооценили, что в проекте так много заинтересованных. Каждый день в проекте появлялся новый отдел, директор или служба, которым тоже очень важны результаты и у всех есть свои требования к проекту. А руководитель проекта, только разводил руками и пояснял: сроки горят, в суматохе забыли про коллег.
Во-вторых, в из-за большого стремления попасть в очень жёсткие сроки при постоянно увеличивающемся объёме задач, мы стали пропорционально быстро наращивать команду. Погружение в проект у каждого нового участника команды стремилось к угрожающему минимум так быстро, что очень скоро получили ситуацию, в которой половина команды не понимала первоначальную цель проекта.
Ну и конечно же — срочность и приоритеты. Давайте будем честны: люди не всегда понимают, зачем и почему срочно. Молодые сотрудники часто считают, что их основная задача заключается лишь в том, чтобы выявить проблему и сообщить о ней руководству. Они полагают, что ответственность за решение автоматически переходит «наверх». С другой стороны, опытные сотрудники склонны видеть причины проблем в изначально неправильном распределении задач и обязанностей. Им кажется, что проблемы могли бы быть предотвращены, если бы руководство уделило больше внимания приоритетам. В итоге никто по-настоящему не бежит тушить пожар. Наверняка на бумаге в проекте всё прекрасно с приоритетами, но без понимания взаимосвязей между результатами — это остаётся просто словами.
В итоге на очередном проектном митинге стало очевидно, что наш проект летит в трубу с огромной скоростью: заказчик не понимает приоритета задач, мы не понимаем для чего мы их делаем. Поэтому с большой болью пришлось остановить все работы и попытаться всё систематизировать. К сожалению, сжатые сроки проекта не позволили заказчику взять паузу на планирование и он принял решения продолжать проект без нас.
Иногда проект пытаются спасать быстрыми решениями. На совещании кто-то резюмирует: "Сделаем как есть, двинемся дальше". И да, это может сработать локально, чтобы избежать катастрофы в моменте, — но становится ли от этого проект лучше или легче? Нет. Эти временные решения, хоть и частично эффективны, но как снежный ком, накапливают новые сложности, которые рано или поздно приведут к нерешаемым проблемам.
Хотите реальной аналогии? Представьте дом, в котором каждую новую трещину на стене заклеивают скотчем. Вначале — немного, потом больше. По итогу дом стоит весь в серебряных полосках, но не потому, что это дизайнерское решение)
Важно не только планировать проект на входе, но и буквально выращивать культуру ответственности:
📍Каждый сотрудник должен видеть, где он в цепочке, понимать, что от него зависят ключевые решения
📍Онбординг в проектах. Без наставничества и должной поддержки новым членам команды сложно вливаться в работу и быстро приносить результаты
📍Приоритеты — это не абстрактные показатели. Нужно в реальном времени доносить изменения на каждом этапе до всех участников
👍10👏1
На этот раз о тонкостях трансформации мы поговорили с Юлией Савченко, руководителем проектов по цифре завода Электрощит Самара.
Электрощит Самара – высокотехнологичная производственная компания, крупнейший производитель электротехнического оборудования 0,4-220 кВ с российскими цифровыми решениями, которые успешно применяются и эксплуатируются на объектах во всех отраслях энергетики, на рынке более 80 лет.
Электрощит Самара – высокотехнологичная производственная компания, крупнейший производитель электротехнического оборудования 0,4-220 кВ с российскими цифровыми решениями, которые успешно применяются и эксплуатируются на объектах во всех отраслях энергетики, на рынке более 80 лет.
👍10
Как правильно организовать выездное обследование на производстве перед разработкой ПО?
80% успеха предпроектного исследования — это грамотная подготовка. Чем точнее собраны данные на старте, тем легче будет внедрить ПО и решить задачу без ненужных доработок.
Проверяйте подрядчиков с помощью нашего чек-листа — он поможет организовать процесс обследования, зафиксировать ключевые параметры и избежать дополнительных изменений.
Сохраняйте и делитесь с командой! 🚀
80% успеха предпроектного исследования — это грамотная подготовка. Чем точнее собраны данные на старте, тем легче будет внедрить ПО и решить задачу без ненужных доработок.
Проверяйте подрядчиков с помощью нашего чек-листа — он поможет организовать процесс обследования, зафиксировать ключевые параметры и избежать дополнительных изменений.
Сохраняйте и делитесь с командой! 🚀
👍10
Как внедрить MVP в боевой режим за неделю? Правильно, никак.
Представьте, что крупная инжиниринговая компания решает внедрить мобильный BI для просмотра аналитики о ходе выполнения работ непосредственно на объекте. На этапе согласования бюджета принято решение начать с MVP — бюджет сильно ограничен, функциональный заказчик сомневается, будет ли удобно работать через смартфон, сотрудники информационной безопасности не готовы быстро согласовывать схемы интеграции с внутренними системами. Но все хотят попробовать вживую и тогда уже окончательно определиться.
Ситуация рабочая — поехали! Команда быстро создаёт функциональный прототип — симпатичный интерфейс, функциональность ограничена, но базовые идеи демонстрируются идеально. Руководители ходят по объекту со смартфонами — всё прекрасно.
Однако... вместо того, чтобы одобрить доработку и переходить на следующий этап, заказчик вдруг решает, что “всё уже работает” и начинает требовать внедрения системы в “боевом режиме”. Как это получилось? При демонстрации результатов работы ЛПРам руководитель проекта со стороны заказчика не совсем чётко проговорил, что это только MVP, а не полноценное решение😊
Как избежать проблем в такой ситуации?
📍Убедитесь, что вы все понимаете одно и то же под MVP. Перед стартом проекта обсудите и запишите цели MVP: он создаётся не для использования “как есть”, а для проверки гипотез и демонстрации возможностей.
📍Юридическое подкрепление. Пропишите в договор, ТЗ, что разрабатывается всего лишь временный прототип, а не финальное ПО.
📍Зафиксируйте слабые стороны MVP. Иногда стоит даже осознанно не брать в MVP все важные функции, проговаривать, что такой прототип никогда не сможет пройти проверку информационной безопасности и т.д.
📍План перехода. Подготовьте пошаговый план доработки MVP и покажите, какие дополнительные затраты, сроки и ресурсы потребуются для создания полноценного решения.
И обязательно нужно не забыть помочь руководителю проекта подготовить презентацию для ЛПРов о том, какой результат на каждом этапе проекта компания получит и когда будет возможно первое “боевого внедрение”.
Представьте, что крупная инжиниринговая компания решает внедрить мобильный BI для просмотра аналитики о ходе выполнения работ непосредственно на объекте. На этапе согласования бюджета принято решение начать с MVP — бюджет сильно ограничен, функциональный заказчик сомневается, будет ли удобно работать через смартфон, сотрудники информационной безопасности не готовы быстро согласовывать схемы интеграции с внутренними системами. Но все хотят попробовать вживую и тогда уже окончательно определиться.
Ситуация рабочая — поехали! Команда быстро создаёт функциональный прототип — симпатичный интерфейс, функциональность ограничена, но базовые идеи демонстрируются идеально. Руководители ходят по объекту со смартфонами — всё прекрасно.
Однако... вместо того, чтобы одобрить доработку и переходить на следующий этап, заказчик вдруг решает, что “всё уже работает” и начинает требовать внедрения системы в “боевом режиме”. Как это получилось? При демонстрации результатов работы ЛПРам руководитель проекта со стороны заказчика не совсем чётко проговорил, что это только MVP, а не полноценное решение😊
Как избежать проблем в такой ситуации?
📍Убедитесь, что вы все понимаете одно и то же под MVP. Перед стартом проекта обсудите и запишите цели MVP: он создаётся не для использования “как есть”, а для проверки гипотез и демонстрации возможностей.
📍Юридическое подкрепление. Пропишите в договор, ТЗ, что разрабатывается всего лишь временный прототип, а не финальное ПО.
📍Зафиксируйте слабые стороны MVP. Иногда стоит даже осознанно не брать в MVP все важные функции, проговаривать, что такой прототип никогда не сможет пройти проверку информационной безопасности и т.д.
📍План перехода. Подготовьте пошаговый план доработки MVP и покажите, какие дополнительные затраты, сроки и ресурсы потребуются для создания полноценного решения.
И обязательно нужно не забыть помочь руководителю проекта подготовить презентацию для ЛПРов о том, какой результат на каждом этапе проекта компания получит и когда будет возможно первое “боевого внедрение”.
👍8🔥3
В начале 2025 года многие наши партнёры открыто заявили, что вся цифровизация на этот год только про клиентский сервис. И это те проекты, которые получают быстрое внедрение и быструю оценку эффективности.
Так, в стремлении улучшить клиентский сервис, один производитель промышленного оборудования запустил на своём сайте простой, но удобный конфигуратор. С его помощью клиенты могли настраивать под себя нужное оборудование: выбирать размер, мощность, дополнительную комплектацию. После оформления заказа конфигуратор сохранял данные на сервер в…Excel-файл.
Выбор Excel в качестве базы данных коллеги легко обосновывали: перспективы конфигуратора неопределённые, поэтому вкладывать много ресурсов в базу данных и систему доступа к ней нецелесообразно, менеджерам по продажам легко получить доступ к заказам, да и копировать данные в другие таблички очень удобно.
Сначала всё шло замечательно. Клиентам упростили процесс заказа, а менеджерам обработку заказов. К конфигуратору все привыкли, и он стабильно начал генерировать заказы. Но затем, спустя где-то полгода, новые заказы перестали падать в Excel. Первые дни отдел продаж грустил, а через неделю началась паника после звонков недовольных клиентов с вопросами: “Вы будете обрабатывать наш заказ или нет?”. Оказалось, что заказы через конфигуратор оформляли, но они не приходили в отдел продаж.
Оказалось, что Excel-файл, который использовался для хранения заказов, просто достиг своего максимального размера. Формат, в котором велась запись, поддерживал ограниченное количество строк, и когда этот предел был превышен, конфигуратор продолжал работать, но новые заказы просто не записывались. Сколько заказов было потеряно установить не удалось, но по статистике продажи в эти две недели были на 20 млн рублей меньше, чем в другие недели квартала.
Этот случай демонстрирует то, как недостаток внимания к ИТ-инфраструктуре способен помешать работе даже хорошо отлаженного бизнес-процесса. На самом деле основной причиной провала стал не Excel как инструмент, а отсутствие качественного аудита инфраструктуры и недостаточное внимание к масштабируемости используемых решений.
Какие действия тут могли бы помочь:
📍Оценить границы используемых технологий
Excel — великолепный инструмент для небольших задач, но никогда не был предназначен для работы с большими потоками данных или автоматизации цифровых процессов. Если ваш бизнес растет, изучите возможности других решений: баз данных, облачных платформ, специализированных бизнес-систем.
📍Аудиты ИТ-инфраструктуры должны быть регулярными
Изменения в бизнесе неизбежны. Если вы внедрили какую-либо систему 6 месяцев назад, это не значит, что она до сих пор справляется с поставленной задачей. Регулярный аудит помогает выявлять скрытые проблемы, неисправности или ограничения, которые могут поставить бизнес под угрозу. При этом аудит — это не только техническая проверка оборудования или ПО, но и анализ процессов, которые с помощью них реализуются.
📍Не экономьте на специалистах
Все мы любим экономить, особенно там, где это кажется возможным. Кто-то скажет, что привлекать специалиста для проверки одного конфигуратора на сайте — это излишняя трата. Но давайте будем честными: что стоит дороже — такие "излишние" траты или потерянные заказы и клиенты?
Так, в стремлении улучшить клиентский сервис, один производитель промышленного оборудования запустил на своём сайте простой, но удобный конфигуратор. С его помощью клиенты могли настраивать под себя нужное оборудование: выбирать размер, мощность, дополнительную комплектацию. После оформления заказа конфигуратор сохранял данные на сервер в…
Выбор Excel в качестве базы данных коллеги легко обосновывали: перспективы конфигуратора неопределённые, поэтому вкладывать много ресурсов в базу данных и систему доступа к ней нецелесообразно, менеджерам по продажам легко получить доступ к заказам, да и копировать данные в другие таблички очень удобно.
Сначала всё шло замечательно. Клиентам упростили процесс заказа, а менеджерам обработку заказов. К конфигуратору все привыкли, и он стабильно начал генерировать заказы. Но затем, спустя где-то полгода, новые заказы перестали падать в Excel. Первые дни отдел продаж грустил, а через неделю началась паника после звонков недовольных клиентов с вопросами: “Вы будете обрабатывать наш заказ или нет?”. Оказалось, что заказы через конфигуратор оформляли, но они не приходили в отдел продаж.
Оказалось, что Excel-файл, который использовался для хранения заказов, просто достиг своего максимального размера. Формат, в котором велась запись, поддерживал ограниченное количество строк, и когда этот предел был превышен, конфигуратор продолжал работать, но новые заказы просто не записывались. Сколько заказов было потеряно установить не удалось, но по статистике продажи в эти две недели были на 20 млн рублей меньше, чем в другие недели квартала.
Этот случай демонстрирует то, как недостаток внимания к ИТ-инфраструктуре способен помешать работе даже хорошо отлаженного бизнес-процесса. На самом деле основной причиной провала стал не Excel как инструмент, а отсутствие качественного аудита инфраструктуры и недостаточное внимание к масштабируемости используемых решений.
Какие действия тут могли бы помочь:
📍Оценить границы используемых технологий
Excel — великолепный инструмент для небольших задач, но никогда не был предназначен для работы с большими потоками данных или автоматизации цифровых процессов. Если ваш бизнес растет, изучите возможности других решений: баз данных, облачных платформ, специализированных бизнес-систем.
📍Аудиты ИТ-инфраструктуры должны быть регулярными
Изменения в бизнесе неизбежны. Если вы внедрили какую-либо систему 6 месяцев назад, это не значит, что она до сих пор справляется с поставленной задачей. Регулярный аудит помогает выявлять скрытые проблемы, неисправности или ограничения, которые могут поставить бизнес под угрозу. При этом аудит — это не только техническая проверка оборудования или ПО, но и анализ процессов, которые с помощью них реализуются.
📍Не экономьте на специалистах
Все мы любим экономить, особенно там, где это кажется возможным. Кто-то скажет, что привлекать специалиста для проверки одного конфигуратора на сайте — это излишняя трата. Но давайте будем честными: что стоит дороже — такие "излишние" траты или потерянные заказы и клиенты?
👍5👏2🙏1
Цифровая катастрофа на Уолл-Стрит или как за 45 минут "умный" алгоритм убил компанию с 90-летней историей (и что делать, чтобы не повторить это с вашим ИИ)
Представьте: компания внедряет "революционный" ИИ для автоматизации ключевого бизнес процесса. Все в восторге, топы ждут рекордной прибыли… но алгоритм за первые 45 минут работы сжигает годовой бюджет компании. Фантастика? Увы, это реальность. 1 августа 2012 года (в мой день рождения) автоматизированная система одного из крупнейших финансовых игроков Америки Knight Capital Group совершила миллионы ошибочных сделок. Компания потеряла $440 миллионов. Это не "баг", это провал в управлении внедрения инноваций.
И уроки Knight Capital очень актуальны сейчас, когда ИИ рвётся во все бизнес-процессы.
❓Что случилось?
На 8 из 30 серверов при обновлении забыли удалить старый модуль. При запуске системы он начал генерировать ошибочные ордера на покупку/продажу акций, не учитывая реальную рыночную ситуацию. Это вызвало эффект домино: ордера сбивали цены, другие алгоритмы воспринимали их как реальные изменения и также выставляли ордера. Без защитных механизмов ошибки повторялись, что привело к 4 миллионам сделок и банкротству.
Главная причина случившегося — игнорирование рисков ИТ проекта и промышленных подходов к разработке. А главное – не соблюдение базовых процессов: тестирование, контроль версий, механизмы защиты данных и предотвращения сбоев.
💡Как нам избежать своей "Knight-катастрофы"?
📍Переход на язык денег и рисков
Не “Система может сломаться”, а “Если наш ИИ-модуль даст сбой, то это может привести к перепроизводству/недопоставкам на сумму ХХ миллионов в месяц”
Риски — это конкретные цифры. Управление ими это защита денег компании.
Используйте экономические расчёты для оценки того, сколько компания может потерять в час/день/месяц в случае сбоя ИИ-модуля. Какой потолок допустимых потерь для компании?
📍Не делаем “всё и сразу”, а разбиваем проект на этапы
Сначала за месяц разрабатываем PoC для одного показателя, чтобы на исторических данных вручную проверить и утвердить подход. Цель этого этапа – показать решаемость задачи и сделать прогноз о точности работы.
Затем этап для второго, третьего параметра и т.д. Этот подход снижает риски (риски одного этапа меньше рисков всего проекта), даёт быстрые победы и доказывает ценность.
📍Всегда есть место для MVP
Типовая задача: бизнес хочет “полностью автоматизированную систему без участия человека”. В запросе видно очень много рисков. Что делать?
Найти MVP, который даст пользу для бизнеса, но при этом не остановит весь процесс в случае проблем.
Вместо “полной автономности” согласуйте MVP, где ИИ выдаёт рекомендации, а окончательное решение принимает человек. Или где ИИ обрабатывает только низкорисковые, стандартные кейсы, а сложные передаёт человеку. Это снижает риск катастрофы, но уже дает значительную часть экономии.
Кейс Knight Capital — не древняя история. Современные ИИ-системы сложнее, автономнее и быстрее старых алгоритмов. Мощь ИИ лишь подчёркивает важность человеческого надзора и строгого управления рисками.
Главное не пугать бизнес "багами", а стать его стратегическим партнёром в цифровизации, используя язык денег, поэтапные победы и разумные MVP. Потому что настоящая "магия" ИИ проявляется, когда он работает надежно, предсказуемо и приносит прибыль.
Представьте: компания внедряет "революционный" ИИ для автоматизации ключевого бизнес процесса. Все в восторге, топы ждут рекордной прибыли… но алгоритм за первые 45 минут работы сжигает годовой бюджет компании. Фантастика? Увы, это реальность. 1 августа 2012 года (в мой день рождения) автоматизированная система одного из крупнейших финансовых игроков Америки Knight Capital Group совершила миллионы ошибочных сделок. Компания потеряла $440 миллионов. Это не "баг", это провал в управлении внедрения инноваций.
И уроки Knight Capital очень актуальны сейчас, когда ИИ рвётся во все бизнес-процессы.
❓Что случилось?
На 8 из 30 серверов при обновлении забыли удалить старый модуль. При запуске системы он начал генерировать ошибочные ордера на покупку/продажу акций, не учитывая реальную рыночную ситуацию. Это вызвало эффект домино: ордера сбивали цены, другие алгоритмы воспринимали их как реальные изменения и также выставляли ордера. Без защитных механизмов ошибки повторялись, что привело к 4 миллионам сделок и банкротству.
Главная причина случившегося — игнорирование рисков ИТ проекта и промышленных подходов к разработке. А главное – не соблюдение базовых процессов: тестирование, контроль версий, механизмы защиты данных и предотвращения сбоев.
💡Как нам избежать своей "Knight-катастрофы"?
📍Переход на язык денег и рисков
Не “Система может сломаться”, а “Если наш ИИ-модуль даст сбой, то это может привести к перепроизводству/недопоставкам на сумму ХХ миллионов в месяц”
Риски — это конкретные цифры. Управление ими это защита денег компании.
Используйте экономические расчёты для оценки того, сколько компания может потерять в час/день/месяц в случае сбоя ИИ-модуля. Какой потолок допустимых потерь для компании?
📍Не делаем “всё и сразу”, а разбиваем проект на этапы
Сначала за месяц разрабатываем PoC для одного показателя, чтобы на исторических данных вручную проверить и утвердить подход. Цель этого этапа – показать решаемость задачи и сделать прогноз о точности работы.
Затем этап для второго, третьего параметра и т.д. Этот подход снижает риски (риски одного этапа меньше рисков всего проекта), даёт быстрые победы и доказывает ценность.
📍Всегда есть место для MVP
Типовая задача: бизнес хочет “полностью автоматизированную систему без участия человека”. В запросе видно очень много рисков. Что делать?
Найти MVP, который даст пользу для бизнеса, но при этом не остановит весь процесс в случае проблем.
Вместо “полной автономности” согласуйте MVP, где ИИ выдаёт рекомендации, а окончательное решение принимает человек. Или где ИИ обрабатывает только низкорисковые, стандартные кейсы, а сложные передаёт человеку. Это снижает риск катастрофы, но уже дает значительную часть экономии.
Кейс Knight Capital — не древняя история. Современные ИИ-системы сложнее, автономнее и быстрее старых алгоритмов. Мощь ИИ лишь подчёркивает важность человеческого надзора и строгого управления рисками.
Главное не пугать бизнес "багами", а стать его стратегическим партнёром в цифровизации, используя язык денег, поэтапные победы и разумные MVP. Потому что настоящая "магия" ИИ проявляется, когда он работает надежно, предсказуемо и приносит прибыль.
🔥8❤1