Друзья, всем привет!
В приближении Нового года захотелось оглянуться на почти прошедший год и оценить, запрос на какие технологии превалировал в 2024 в проектах Rubius. С чем Заказчики обращались чаще всего?
📍Большие языковые модели (LLM)
Глобальный тренд, начавшийся с ChatGPT, не обошёл и меня стороной. Самое большое количество запросов было по ИИ: анализ строительной документации, корпоративный поиск по базе данных, генерация шаблонов документов и многое другое.
Всё больше и больше компаний задумываются об ИИ. Подстегивает их интерес, как мне кажется, то что пионеры этих технологий уже переходят от стадии проработки концепций (PoC) к подсчёту экономических выгод от первого года использования решений. Для многих это важный сигнал к началу внедрения технологий в собственный производственный процесс.
📍Конфигураторы
Почти наравне с LLM оказались запросы на конфигураторы всевозможных изделий, устройств, оборудования. Высокий уровень конкуренции и изменения ландшафта поставщиков подталкивает многие компании к автоматизации.
Продавать нужно быстро, большими объёмами и проверять совместимость компонентов до отправки заказчикам. Компаниям жизненно необходимо обрабатывать всё больше запросов в единицу времени. Поэтому в этом году мы разрабатывали очень разные конфигураторы: от резервуарных парков до насосного оборудования.
📍BI системы
Небывалый рост запросов на BI произошел в 24 году. Все начинают задумываться об эффективности и прозрачном контроле процессов и рациональным образом приходят к BI решениям, при этом кастомным, а не коробочным, чтобы не ломать процессы и интеграции.
Очень разного масштаба проекты (от аналитики процесса возведения одного строительного объекта до контроля показателей эффективности деятельности в 89 регионах страны) показывают на сколько ценной становится информация для бизнеса.
Это были тренды, с которыми наша команда столкнулась в этом году. С нетерпением жду года следующего, чтобы узнать, что нового он готовит в плане технологий. А вам всем хочу пожелать полезных инноваций, эффективного использования современных технологий и, конечно же, успеха во всех начинаниях. С Новым годом!🎉🎄🎅
В приближении Нового года захотелось оглянуться на почти прошедший год и оценить, запрос на какие технологии превалировал в 2024 в проектах Rubius. С чем Заказчики обращались чаще всего?
📍Большие языковые модели (LLM)
Глобальный тренд, начавшийся с ChatGPT, не обошёл и меня стороной. Самое большое количество запросов было по ИИ: анализ строительной документации, корпоративный поиск по базе данных, генерация шаблонов документов и многое другое.
Всё больше и больше компаний задумываются об ИИ. Подстегивает их интерес, как мне кажется, то что пионеры этих технологий уже переходят от стадии проработки концепций (PoC) к подсчёту экономических выгод от первого года использования решений. Для многих это важный сигнал к началу внедрения технологий в собственный производственный процесс.
📍Конфигураторы
Почти наравне с LLM оказались запросы на конфигураторы всевозможных изделий, устройств, оборудования. Высокий уровень конкуренции и изменения ландшафта поставщиков подталкивает многие компании к автоматизации.
Продавать нужно быстро, большими объёмами и проверять совместимость компонентов до отправки заказчикам. Компаниям жизненно необходимо обрабатывать всё больше запросов в единицу времени. Поэтому в этом году мы разрабатывали очень разные конфигураторы: от резервуарных парков до насосного оборудования.
📍BI системы
Небывалый рост запросов на BI произошел в 24 году. Все начинают задумываться об эффективности и прозрачном контроле процессов и рациональным образом приходят к BI решениям, при этом кастомным, а не коробочным, чтобы не ломать процессы и интеграции.
Очень разного масштаба проекты (от аналитики процесса возведения одного строительного объекта до контроля показателей эффективности деятельности в 89 регионах страны) показывают на сколько ценной становится информация для бизнеса.
Это были тренды, с которыми наша команда столкнулась в этом году. С нетерпением жду года следующего, чтобы узнать, что нового он готовит в плане технологий. А вам всем хочу пожелать полезных инноваций, эффективного использования современных технологий и, конечно же, успеха во всех начинаниях. С Новым годом!🎉🎄🎅
Про это как будто бы никто не знает, но мы работаем с логистикой уже около 8 лет. Никогда не ставили себе такой цели, но привыкли честно работать с разными запросами клиентов. В итоге научились управлять заказами и отгрузками, создавать внутренние биржи грузоперевозчиков и даже немного контролировать склады. Чтобы как-то систематизировать свой опыт, последние месяцы много говорим с рынком логистики – DPD, Байкал Сервис, Boxberry и ещё с десяток разных компаний. Для себя и для коллег завели канал, где делимся тем, что узнаём или подтверждаем через интервью. Подписывайтесь - https://t.me/digital_logistics_pro
Telegram
Rubius/Digital логистика
Канал команды цифровизации логистики компании Rubius. Делимся опытом, кейсами и обсуждаем будущее отрасли с диджитал-лидерами со всей России
Когда я только начинал этот канал, я говорил, что буду делиться и своими провалами … сегодня тот самый случай🙂
В процессе рефлексии над причинами провала одного недавнего проекта в голову пришла одна забавная аналогия.
Когда команда только начинает проект, то это как первый запуск старенького мопеда во дворе: все друг друга подбадривают: "Да он мощный, сейчас как попрёт!"… но выясняется, что передачи не переключаются, колёса подспущены, а руль ведёт вправо. И ты едешь на этом мопеде с мыслью: "Ну ладно, главное доехать до воображаемого финиша в конце двора, а проблемы после поправлю". А в реальности — доработки как-то откладываются.
Так и в проекте всё начиналось красиво: проект — важный, срочный, амбициозный. Собрались, обсудили сроки, распределили задачи. На бумаге всё было идеально. Но… только на бумаге.
Во-первых, сильно недооценили, что в проекте так много заинтересованных. Каждый день в проекте появлялся новый отдел, директор или служба, которым тоже очень важны результаты и у всех есть свои требования к проекту. А руководитель проекта, только разводил руками и пояснял: сроки горят, в суматохе забыли про коллег.
Во-вторых, в из-за большого стремления попасть в очень жёсткие сроки при постоянно увеличивающемся объёме задач, мы стали пропорционально быстро наращивать команду. Погружение в проект у каждого нового участника команды стремилось к угрожающему минимум так быстро, что очень скоро получили ситуацию, в которой половина команды не понимала первоначальную цель проекта.
Ну и конечно же — срочность и приоритеты. Давайте будем честны: люди не всегда понимают, зачем и почему срочно. Молодые сотрудники часто считают, что их основная задача заключается лишь в том, чтобы выявить проблему и сообщить о ней руководству. Они полагают, что ответственность за решение автоматически переходит «наверх». С другой стороны, опытные сотрудники склонны видеть причины проблем в изначально неправильном распределении задач и обязанностей. Им кажется, что проблемы могли бы быть предотвращены, если бы руководство уделило больше внимания приоритетам. В итоге никто по-настоящему не бежит тушить пожар. Наверняка на бумаге в проекте всё прекрасно с приоритетами, но без понимания взаимосвязей между результатами — это остаётся просто словами.
В итоге на очередном проектном митинге стало очевидно, что наш проект летит в трубу с огромной скоростью: заказчик не понимает приоритета задач, мы не понимаем для чего мы их делаем. Поэтому с большой болью пришлось остановить все работы и попытаться всё систематизировать. К сожалению, сжатые сроки проекта не позволили заказчику взять паузу на планирование и он принял решения продолжать проект без нас.
Иногда проект пытаются спасать быстрыми решениями. На совещании кто-то резюмирует: "Сделаем как есть, двинемся дальше". И да, это может сработать локально, чтобы избежать катастрофы в моменте, — но становится ли от этого проект лучше или легче? Нет. Эти временные решения, хоть и частично эффективны, но как снежный ком, накапливают новые сложности, которые рано или поздно приведут к нерешаемым проблемам.
Хотите реальной аналогии? Представьте дом, в котором каждую новую трещину на стене заклеивают скотчем. Вначале — немного, потом больше. По итогу дом стоит весь в серебряных полосках, но не потому, что это дизайнерское решение)
Важно не только планировать проект на входе, но и буквально выращивать культуру ответственности:
📍Каждый сотрудник должен видеть, где он в цепочке, понимать, что от него зависят ключевые решения
📍Онбординг в проектах. Без наставничества и должной поддержки новым членам команды сложно вливаться в работу и быстро приносить результаты
📍Приоритеты — это не абстрактные показатели. Нужно в реальном времени доносить изменения на каждом этапе до всех участников
В процессе рефлексии над причинами провала одного недавнего проекта в голову пришла одна забавная аналогия.
Когда команда только начинает проект, то это как первый запуск старенького мопеда во дворе: все друг друга подбадривают: "Да он мощный, сейчас как попрёт!"… но выясняется, что передачи не переключаются, колёса подспущены, а руль ведёт вправо. И ты едешь на этом мопеде с мыслью: "Ну ладно, главное доехать до воображаемого финиша в конце двора, а проблемы после поправлю". А в реальности — доработки как-то откладываются.
Так и в проекте всё начиналось красиво: проект — важный, срочный, амбициозный. Собрались, обсудили сроки, распределили задачи. На бумаге всё было идеально. Но… только на бумаге.
Во-первых, сильно недооценили, что в проекте так много заинтересованных. Каждый день в проекте появлялся новый отдел, директор или служба, которым тоже очень важны результаты и у всех есть свои требования к проекту. А руководитель проекта, только разводил руками и пояснял: сроки горят, в суматохе забыли про коллег.
Во-вторых, в из-за большого стремления попасть в очень жёсткие сроки при постоянно увеличивающемся объёме задач, мы стали пропорционально быстро наращивать команду. Погружение в проект у каждого нового участника команды стремилось к угрожающему минимум так быстро, что очень скоро получили ситуацию, в которой половина команды не понимала первоначальную цель проекта.
Ну и конечно же — срочность и приоритеты. Давайте будем честны: люди не всегда понимают, зачем и почему срочно. Молодые сотрудники часто считают, что их основная задача заключается лишь в том, чтобы выявить проблему и сообщить о ней руководству. Они полагают, что ответственность за решение автоматически переходит «наверх». С другой стороны, опытные сотрудники склонны видеть причины проблем в изначально неправильном распределении задач и обязанностей. Им кажется, что проблемы могли бы быть предотвращены, если бы руководство уделило больше внимания приоритетам. В итоге никто по-настоящему не бежит тушить пожар. Наверняка на бумаге в проекте всё прекрасно с приоритетами, но без понимания взаимосвязей между результатами — это остаётся просто словами.
В итоге на очередном проектном митинге стало очевидно, что наш проект летит в трубу с огромной скоростью: заказчик не понимает приоритета задач, мы не понимаем для чего мы их делаем. Поэтому с большой болью пришлось остановить все работы и попытаться всё систематизировать. К сожалению, сжатые сроки проекта не позволили заказчику взять паузу на планирование и он принял решения продолжать проект без нас.
Иногда проект пытаются спасать быстрыми решениями. На совещании кто-то резюмирует: "Сделаем как есть, двинемся дальше". И да, это может сработать локально, чтобы избежать катастрофы в моменте, — но становится ли от этого проект лучше или легче? Нет. Эти временные решения, хоть и частично эффективны, но как снежный ком, накапливают новые сложности, которые рано или поздно приведут к нерешаемым проблемам.
Хотите реальной аналогии? Представьте дом, в котором каждую новую трещину на стене заклеивают скотчем. Вначале — немного, потом больше. По итогу дом стоит весь в серебряных полосках, но не потому, что это дизайнерское решение)
Важно не только планировать проект на входе, но и буквально выращивать культуру ответственности:
📍Каждый сотрудник должен видеть, где он в цепочке, понимать, что от него зависят ключевые решения
📍Онбординг в проектах. Без наставничества и должной поддержки новым членам команды сложно вливаться в работу и быстро приносить результаты
📍Приоритеты — это не абстрактные показатели. Нужно в реальном времени доносить изменения на каждом этапе до всех участников
На этот раз о тонкостях трансформации мы поговорили с Юлией Савченко, руководителем проектов по цифре завода Электрощит Самара.
Электрощит Самара – высокотехнологичная производственная компания, крупнейший производитель электротехнического оборудования 0,4-220 кВ с российскими цифровыми решениями, которые успешно применяются и эксплуатируются на объектах во всех отраслях энергетики, на рынке более 80 лет.
Электрощит Самара – высокотехнологичная производственная компания, крупнейший производитель электротехнического оборудования 0,4-220 кВ с российскими цифровыми решениями, которые успешно применяются и эксплуатируются на объектах во всех отраслях энергетики, на рынке более 80 лет.
Как правильно организовать выездное обследование на производстве перед разработкой ПО?
80% успеха предпроектного исследования — это грамотная подготовка. Чем точнее собраны данные на старте, тем легче будет внедрить ПО и решить задачу без ненужных доработок.
Проверяйте подрядчиков с помощью нашего чек-листа — он поможет организовать процесс обследования, зафиксировать ключевые параметры и избежать дополнительных изменений.
Сохраняйте и делитесь с командой! 🚀
80% успеха предпроектного исследования — это грамотная подготовка. Чем точнее собраны данные на старте, тем легче будет внедрить ПО и решить задачу без ненужных доработок.
Проверяйте подрядчиков с помощью нашего чек-листа — он поможет организовать процесс обследования, зафиксировать ключевые параметры и избежать дополнительных изменений.
Сохраняйте и делитесь с командой! 🚀
Чек-лист выездного обследования.pdf
5 MB
Чек-лист выездного обследования☑️
Как внедрить MVP в боевой режим за неделю? Правильно, никак.
Представьте, что крупная инжиниринговая компания решает внедрить мобильный BI для просмотра аналитики о ходе выполнения работ непосредственно на объекте. На этапе согласования бюджета принято решение начать с MVP — бюджет сильно ограничен, функциональный заказчик сомневается, будет ли удобно работать через смартфон, сотрудники информационной безопасности не готовы быстро согласовывать схемы интеграции с внутренними системами. Но все хотят попробовать вживую и тогда уже окончательно определиться.
Ситуация рабочая — поехали! Команда быстро создаёт функциональный прототип — симпатичный интерфейс, функциональность ограничена, но базовые идеи демонстрируются идеально. Руководители ходят по объекту со смартфонами — всё прекрасно.
Однако... вместо того, чтобы одобрить доработку и переходить на следующий этап, заказчик вдруг решает, что “всё уже работает” и начинает требовать внедрения системы в “боевом режиме”. Как это получилось? При демонстрации результатов работы ЛПРам руководитель проекта со стороны заказчика не совсем чётко проговорил, что это только MVP, а не полноценное решение😊
Как избежать проблем в такой ситуации?
📍Убедитесь, что вы все понимаете одно и то же под MVP. Перед стартом проекта обсудите и запишите цели MVP: он создаётся не для использования “как есть”, а для проверки гипотез и демонстрации возможностей.
📍Юридическое подкрепление. Пропишите в договор, ТЗ, что разрабатывается всего лишь временный прототип, а не финальное ПО.
📍Зафиксируйте слабые стороны MVP. Иногда стоит даже осознанно не брать в MVP все важные функции, проговаривать, что такой прототип никогда не сможет пройти проверку информационной безопасности и т.д.
📍План перехода. Подготовьте пошаговый план доработки MVP и покажите, какие дополнительные затраты, сроки и ресурсы потребуются для создания полноценного решения.
И обязательно нужно не забыть помочь руководителю проекта подготовить презентацию для ЛПРов о том, какой результат на каждом этапе проекта компания получит и когда будет возможно первое “боевого внедрение”.
Представьте, что крупная инжиниринговая компания решает внедрить мобильный BI для просмотра аналитики о ходе выполнения работ непосредственно на объекте. На этапе согласования бюджета принято решение начать с MVP — бюджет сильно ограничен, функциональный заказчик сомневается, будет ли удобно работать через смартфон, сотрудники информационной безопасности не готовы быстро согласовывать схемы интеграции с внутренними системами. Но все хотят попробовать вживую и тогда уже окончательно определиться.
Ситуация рабочая — поехали! Команда быстро создаёт функциональный прототип — симпатичный интерфейс, функциональность ограничена, но базовые идеи демонстрируются идеально. Руководители ходят по объекту со смартфонами — всё прекрасно.
Однако... вместо того, чтобы одобрить доработку и переходить на следующий этап, заказчик вдруг решает, что “всё уже работает” и начинает требовать внедрения системы в “боевом режиме”. Как это получилось? При демонстрации результатов работы ЛПРам руководитель проекта со стороны заказчика не совсем чётко проговорил, что это только MVP, а не полноценное решение😊
Как избежать проблем в такой ситуации?
📍Убедитесь, что вы все понимаете одно и то же под MVP. Перед стартом проекта обсудите и запишите цели MVP: он создаётся не для использования “как есть”, а для проверки гипотез и демонстрации возможностей.
📍Юридическое подкрепление. Пропишите в договор, ТЗ, что разрабатывается всего лишь временный прототип, а не финальное ПО.
📍Зафиксируйте слабые стороны MVP. Иногда стоит даже осознанно не брать в MVP все важные функции, проговаривать, что такой прототип никогда не сможет пройти проверку информационной безопасности и т.д.
📍План перехода. Подготовьте пошаговый план доработки MVP и покажите, какие дополнительные затраты, сроки и ресурсы потребуются для создания полноценного решения.
И обязательно нужно не забыть помочь руководителю проекта подготовить презентацию для ЛПРов о том, какой результат на каждом этапе проекта компания получит и когда будет возможно первое “боевого внедрение”.
В начале 2025 года многие наши партнёры открыто заявили, что вся цифровизация на этот год только про клиентский сервис. И это те проекты, которые получают быстрое внедрение и быструю оценку эффективности.
Так, в стремлении улучшить клиентский сервис, один производитель промышленного оборудования запустил на своём сайте простой, но удобный конфигуратор. С его помощью клиенты могли настраивать под себя нужное оборудование: выбирать размер, мощность, дополнительную комплектацию. После оформления заказа конфигуратор сохранял данные на сервер в…Excel-файл.
Выбор Excel в качестве базы данных коллеги легко обосновывали: перспективы конфигуратора неопределённые, поэтому вкладывать много ресурсов в базу данных и систему доступа к ней нецелесообразно, менеджерам по продажам легко получить доступ к заказам, да и копировать данные в другие таблички очень удобно.
Сначала всё шло замечательно. Клиентам упростили процесс заказа, а менеджерам обработку заказов. К конфигуратору все привыкли, и он стабильно начал генерировать заказы. Но затем, спустя где-то полгода, новые заказы перестали падать в Excel. Первые дни отдел продаж грустил, а через неделю началась паника после звонков недовольных клиентов с вопросами: “Вы будете обрабатывать наш заказ или нет?”. Оказалось, что заказы через конфигуратор оформляли, но они не приходили в отдел продаж.
Оказалось, что Excel-файл, который использовался для хранения заказов, просто достиг своего максимального размера. Формат, в котором велась запись, поддерживал ограниченное количество строк, и когда этот предел был превышен, конфигуратор продолжал работать, но новые заказы просто не записывались. Сколько заказов было потеряно установить не удалось, но по статистике продажи в эти две недели были на 20 млн рублей меньше, чем в другие недели квартала.
Этот случай демонстрирует то, как недостаток внимания к ИТ-инфраструктуре способен помешать работе даже хорошо отлаженного бизнес-процесса. На самом деле основной причиной провала стал не Excel как инструмент, а отсутствие качественного аудита инфраструктуры и недостаточное внимание к масштабируемости используемых решений.
Какие действия тут могли бы помочь:
📍Оценить границы используемых технологий
Excel — великолепный инструмент для небольших задач, но никогда не был предназначен для работы с большими потоками данных или автоматизации цифровых процессов. Если ваш бизнес растет, изучите возможности других решений: баз данных, облачных платформ, специализированных бизнес-систем.
📍Аудиты ИТ-инфраструктуры должны быть регулярными
Изменения в бизнесе неизбежны. Если вы внедрили какую-либо систему 6 месяцев назад, это не значит, что она до сих пор справляется с поставленной задачей. Регулярный аудит помогает выявлять скрытые проблемы, неисправности или ограничения, которые могут поставить бизнес под угрозу. При этом аудит — это не только техническая проверка оборудования или ПО, но и анализ процессов, которые с помощью них реализуются.
📍Не экономьте на специалистах
Все мы любим экономить, особенно там, где это кажется возможным. Кто-то скажет, что привлекать специалиста для проверки одного конфигуратора на сайте — это излишняя трата. Но давайте будем честными: что стоит дороже — такие "излишние" траты или потерянные заказы и клиенты?
Так, в стремлении улучшить клиентский сервис, один производитель промышленного оборудования запустил на своём сайте простой, но удобный конфигуратор. С его помощью клиенты могли настраивать под себя нужное оборудование: выбирать размер, мощность, дополнительную комплектацию. После оформления заказа конфигуратор сохранял данные на сервер в…
Выбор Excel в качестве базы данных коллеги легко обосновывали: перспективы конфигуратора неопределённые, поэтому вкладывать много ресурсов в базу данных и систему доступа к ней нецелесообразно, менеджерам по продажам легко получить доступ к заказам, да и копировать данные в другие таблички очень удобно.
Сначала всё шло замечательно. Клиентам упростили процесс заказа, а менеджерам обработку заказов. К конфигуратору все привыкли, и он стабильно начал генерировать заказы. Но затем, спустя где-то полгода, новые заказы перестали падать в Excel. Первые дни отдел продаж грустил, а через неделю началась паника после звонков недовольных клиентов с вопросами: “Вы будете обрабатывать наш заказ или нет?”. Оказалось, что заказы через конфигуратор оформляли, но они не приходили в отдел продаж.
Оказалось, что Excel-файл, который использовался для хранения заказов, просто достиг своего максимального размера. Формат, в котором велась запись, поддерживал ограниченное количество строк, и когда этот предел был превышен, конфигуратор продолжал работать, но новые заказы просто не записывались. Сколько заказов было потеряно установить не удалось, но по статистике продажи в эти две недели были на 20 млн рублей меньше, чем в другие недели квартала.
Этот случай демонстрирует то, как недостаток внимания к ИТ-инфраструктуре способен помешать работе даже хорошо отлаженного бизнес-процесса. На самом деле основной причиной провала стал не Excel как инструмент, а отсутствие качественного аудита инфраструктуры и недостаточное внимание к масштабируемости используемых решений.
Какие действия тут могли бы помочь:
📍Оценить границы используемых технологий
Excel — великолепный инструмент для небольших задач, но никогда не был предназначен для работы с большими потоками данных или автоматизации цифровых процессов. Если ваш бизнес растет, изучите возможности других решений: баз данных, облачных платформ, специализированных бизнес-систем.
📍Аудиты ИТ-инфраструктуры должны быть регулярными
Изменения в бизнесе неизбежны. Если вы внедрили какую-либо систему 6 месяцев назад, это не значит, что она до сих пор справляется с поставленной задачей. Регулярный аудит помогает выявлять скрытые проблемы, неисправности или ограничения, которые могут поставить бизнес под угрозу. При этом аудит — это не только техническая проверка оборудования или ПО, но и анализ процессов, которые с помощью них реализуются.
📍Не экономьте на специалистах
Все мы любим экономить, особенно там, где это кажется возможным. Кто-то скажет, что привлекать специалиста для проверки одного конфигуратора на сайте — это излишняя трата. Но давайте будем честными: что стоит дороже — такие "излишние" траты или потерянные заказы и клиенты?