Помните рекламу "Сколько вешать в граммах?" про то, что точность никогда не бывает лишней? Согласитесь, фраза не зря стала крылатой🙂 Но если колбасу можно измерить до граммов, то с кучей угля или железной руды на складе ГОКа всё не так просто – на весы не положишь.

Тахеометры дают погрешность в 5-10%. В итоге реальные запасы неминуемо оказываются меньше учётных. Как здесь планировать работу и оптимизировать ресурсы? Больше геодезистов на площадке проблему не решат: люди среди бульдозеров и экскаваторов – это лишние риски травматизма.

Тогда как организовать контроль за запасами и получать стабильный результат измерений независимо от погоды, людей и формы той самой кучи?

Об этом и поговорим на онлайн-встрече об инвентаризации открытых складов ГОКов 28 ноября в 11.00 (МСК). Приглашаем главных инженеров, маркшейдеров, геодезистов и специалистов по охране труда.

Друзья, участие бесплатное. Регистрируйтесь по ссылке и увидимся онлайн!

P.S. Кстати, реклама была совсем не про колбасу🙂

Ссылка на вебинар тут

Совместный проект компании Rubius и федерального застройщика Эталон вошёл в шорт-лист премии "Компания будущего".

Эксперты премии при поддержке Минэкономразвития выбирают проекты и компании, которые задают тренды – как будут развиваться целые отрасли в России. Так, например, Эталон меняет подходы к проектированию зданий.

Команда проекта превратила процесс создания технического задания на проектирование в простую и приятную работу. Эксперты застройщика сформировали базы данных для генерации технических заданий, а аналитики, разработчики и дизайнеры Rubius создали удобный веб-сервис, где даже начинающий специалист легко соберёт ТЗ на проектирование жилого дома в Санкт-Петербурге или Казани.

Уже завтра, 4 декабря, эксперты объявят победителей. А пока ещё есть время – голосуйте за наш сервис "Цифровое техническое задание" на сайте премии. Сдвинув бегунок на отметку 10, приблизим светлое цифровое будущее.

https://special.ko.ru/digital-transformation-2024

Друзья, всем привет!

В приближении Нового года захотелось оглянуться на почти прошедший год и оценить, запрос на какие технологии превалировал в 2024 в проектах Rubius. С чем Заказчики обращались чаще всего?

📍Большие языковые модели (LLM)
Глобальный тренд, начавшийся с ChatGPT, не обошёл и меня стороной. Самое большое количество запросов было по ИИ: анализ строительной документации, корпоративный поиск по базе данных, генерация шаблонов документов и многое другое.

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

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

Продавать нужно быстро, большими объёмами и проверять совместимость компонентов до отправки заказчикам. Компаниям жизненно необходимо обрабатывать всё больше запросов в единицу времени. Поэтому в этом году мы разрабатывали очень разные конфигураторы: от резервуарных парков до насосного оборудования.

📍BI системы
Небывалый рост запросов на BI произошел в 24 году. Все начинают задумываться об эффективности и прозрачном контроле процессов и рациональным образом приходят к BI решениям, при этом кастомным, а не коробочным, чтобы не ломать процессы и интеграции.

Очень разного масштаба проекты (от аналитики процесса возведения одного строительного объекта до контроля показателей эффективности деятельности в 89 регионах страны) показывают на сколько ценной становится информация для бизнеса.

Это были тренды, с которыми наша команда столкнулась в этом году. С нетерпением жду года следующего, чтобы узнать, что нового он готовит в плане технологий. А вам всем хочу пожелать полезных инноваций, эффективного использования современных технологий и, конечно же, успеха во всех начинаниях. С Новым годом!🎉🎄🎅

Про это как будто бы никто не знает, но мы работаем с логистикой уже около 8 лет. Никогда не ставили себе такой цели, но привыкли честно работать с разными запросами клиентов. В итоге научились управлять заказами и отгрузками, создавать внутренние биржи грузоперевозчиков и даже немного контролировать склады. Чтобы как-то систематизировать свой опыт, последние месяцы много говорим с рынком логистики – DPD, Байкал Сервис, Boxberry и ещё с десяток разных компаний. Для себя и для коллег завели канал, где делимся тем, что узнаём или подтверждаем через интервью. Подписывайтесь - https://news.1rj.ru/str/digital_logistics_pro

Когда я только начинал этот канал, я говорил, что буду делиться и своими провалами… сегодня тот самый случай🙂

В процессе рефлексии над причинами провала одного недавнего проекта в голову пришла одна забавная аналогия.

Когда команда только начинает проект, то это как первый запуск старенького мопеда во дворе: все друг друга подбадривают: "Да он мощный, сейчас как попрёт!"… но выясняется, что передачи не переключаются, колёса подспущены, а руль ведёт вправо. И ты едешь на этом мопеде с мыслью: "Ну ладно, главное доехать до воображаемого финиша в конце двора, а проблемы после поправлю". А в реальности — доработки как-то откладываются.

Так и в проекте всё начиналось красиво: проект — важный, срочный, амбициозный. Собрались, обсудили сроки, распределили задачи. На бумаге всё было идеально. Но… только на бумаге.

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

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

Ну и конечно же — срочность и приоритеты. Давайте будем честны: люди не всегда понимают, зачем и почему срочно. Молодые сотрудники часто считают, что их основная задача заключается лишь в том, чтобы выявить проблему и сообщить о ней руководству. Они полагают, что ответственность за решение автоматически переходит «наверх». С другой стороны, опытные сотрудники склонны видеть причины проблем в изначально неправильном распределении задач и обязанностей. Им кажется, что проблемы могли бы быть предотвращены, если бы руководство уделило больше внимания приоритетам. В итоге никто по-настоящему не бежит тушить пожар. Наверняка на бумаге в проекте всё прекрасно с приоритетами, но без понимания взаимосвязей между результатами — это остаётся просто словами.

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

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

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

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

Чек-лист выездного обследования☑️

Как внедрить MVP в боевой режим за неделю? Правильно, никак.

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

Ситуация рабочая — поехали! Команда быстро создаёт функциональный прототип — симпатичный интерфейс, функциональность ограничена, но базовые идеи демонстрируются идеально. Руководители ходят по объекту со смартфонами — всё прекрасно.

Однако... вместо того, чтобы одобрить доработку и переходить на следующий этап, заказчик вдруг решает, что “всё уже работает” и начинает требовать внедрения системы в “боевом режиме”. Как это получилось? При демонстрации результатов работы ЛПРам руководитель проекта со стороны заказчика не совсем чётко проговорил, что это только MVP, а не полноценное решение😊

Как избежать проблем в такой ситуации?

📍Убедитесь, что вы все понимаете одно и то же под MVP. Перед стартом проекта обсудите и запишите цели MVP: он создаётся не для использования “как есть”, а для проверки гипотез и демонстрации возможностей.
📍Юридическое подкрепление. Пропишите в договор, ТЗ, что разрабатывается всего лишь временный прототип, а не финальное ПО.
📍Зафиксируйте слабые стороны MVP. Иногда стоит даже осознанно не брать в MVP все важные функции, проговаривать, что такой прототип никогда не сможет пройти проверку информационной безопасности и т.д.
📍План перехода. Подготовьте пошаговый план доработки MVP и покажите, какие дополнительные затраты, сроки и ресурсы потребуются для создания полноценного решения.

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