Как стать автором
Обновить

Комментарии 9

Об эффекте такого рода проектов можно и нужно судить еще и по динамике кадров. Если вы реально прикроете лазейку для достаточно массового мошенничества — вы увидите отток сотрудников или перетряску подрядчиков :)
Зарегистрировался даже чтобы комментарий оставить.

Обычно, перед тем как пускаться в собственную разработку, полезно посмотреть, что уже есть на рынке. А оно есть. И международные: РАЗ, ДВА.
У Trimble есть решение, русские решения тоже есть.

Так что инновацией это было лет 7-8 назад. Сейчас за 100 баксов можно себе купить.

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

Так что как импортозамещение — пойдет, но вы велосипед изобретаете.
Ответ от автора поста, Дмитрия Бочарова: Спасибо за комментарий. Разработки других компаний изучали в самом начале. Не вдаваясь в описание плюсов и минусов, достаточно сказать, что подписка действительно стоит 100$ в месяц за пользователя. В масштабах лесозаготовки ГК «Сегежа» это несколько миллионов рублей в месяц. Разработка собственной системы дешевле. Причем в свою мы закладываем необходимые нам инструменты. В частности, фотофиксация древесины, привязанная к делянке, номеру лесовоза, складу, бригаде, дате и пр. Также система будет отслеживать объем древесины в процессе движения: сверять фото в момент загрузки лесовоза в лесу и фото перед разгрузкой древесины на комбинате. Будет сопоставляться количество бревен, диаметры, объем. В случае существенных расхождение система будет направлять предупреждение. Автоматической системы оценки качества древесины действительно еще нет, слишком много тонкостей и нюансов. У нас в планах есть задача по решению данной проблемы.
Да, согласен, система красивая — ВАУ эффект дает. А вот с экономическим не все так радужно… По крайней мере измерить его не так просто — погрешность 5% не равно украдено 5%.
Мы такие смотрели и пробовали для себя — нашли применение только для инвентаризации терминалов — и не из-за точности, а из-за банальной быстроты.
Фиксацию объемов по делянке проще брать с компьютера тех самых харвестеров и накладывать на нее статистику потерь в волока.
Отслеживание воровства при перевозке — контролем GPS трека.
Фиксация загрузки-выгрузки — скорее полезная штука, но обычного фото-видео хватает для разбора одного спорного кейса и раздачи штрафов приемщикам.
А на заводах и давно все сортировочные линии на приемке ставят с лазерным или рентген 3Д-сканированием каждого бревна…

То есть все то же самое можно сделать и без ИИ…

В Сегеже с ее объемами для задач ИИ я бы посоветовал взять биг-дату по отводов, заготовки и приемки и хорошенько ее потрясти — оттуда можно получить интересную аналитику по делянкам и заводам. Вот тут и будет видно кто и на каком этапе ворует…
Ответ Дмитрия Бочарова: Спасибо за комментарий с пониманием специфики и отраслевых проблем. Безусловно, ИИ – не панацея. Мы его так и не рассматриваем. Это отдельный инструмент в Автоматической системе диспетчеризации (АСД) ГК «Сегежа», которая сейчас внедряется. В нее собираются данные харвестеров, GPS-передатчиков и датчиков топлива лесовозов, автоматических систем учета древесины на комбинатах (сканеры, весы), результаты измерения древесины на складах и инвентаризаций. Задача АСД – мониторинг движения древесины, формирование материального баланса, построение аналитики. Описанный в посте инструмент замера древесины является частью этой системы.
Процитирую Морейниса
Внутренние продукты должны стать внешними или убитыми

Полезный вопросник, который следует пройти перед тем, как начать разрабатывать внутренние продукты.

1. Нашей компании нужен этот продукт?
— «Нет». Убить идею сразу. Зачем создавать ненужный продукт?
— «Да». Часто мы останавливаемся здесь. Но лучше перейти к следующему вопросу.

2. Другим компаниям нужен такой продукт?
— «Нет». Мы что — такие уникальные? Вряд ли. Стоит пересмотреть постановку задачи на продукт.
— «Да». Если ряд компаний нуждается в таком продукте, то кто-то что-то подобное уже наверняка сделал.

3. Решает ли существующий продукт нашу проблему?
— «Да». Убить идею создания своего продукта.
— «Нет». Почему не решает? Только потому что мы считаем, что мы сделаем его лучше и удобнее? Или есть существенные проблемы, которые он не решает?

4. У нас есть отличный (от других) способ решения такой существенной проблемы?
— «Да». Давайте опишем это убийственное свойство (killer feature) нашего внутреннего продукта
— «Нет». А зачем нам разрабатывать продукт, если у нас нет убедительного и отличающегося от аналогов способа решения нашей проблемы?

5. Это нужно нашей компании. Это нужно другим компаниям. У нас есть убийственное свойство, которое решает проблему так, как не решает никто другой. Будем инвестировать в разработку такого продукта, чтобы продавать его другим?
— «Нет» или «Да, но…». Значит, мы соврали в ответах на предыдущие вопросы, которые привели нас сюда. Пройдите вопросник еще раз, но честно отвечайте на вопросы.
— «Да». Тогда начинайте разработку и относитесь к разработке внутреннего продукта с тем же усердием, с которым вы разрабатываете продукты для своих пользователей.

6. Мы его разработали, что с продажами?
— «Не продается». А внутри-то им пользуются? Скорее всего, нет. Хороший повод его убить.
— «Продается». Ну что ж, мы превратили расходы на внутренний продукт в инвестиции. Можем себя поздравить.

По мотивам: mdswanson.com/blog/2016/01/25/sell-or-kill.html
Я думаю, иногда возможна вариация когда расходы на создание внутреннего продукта могут окупиться просто за счёт того, что внешний продукт распространяется по подписке и его цена владения за 5 лет преевысит условно говоря, стоимость разработки и поддержания твоего продукта. Пусть даже который не продается наружу.
Вот, в случае с Тимбетером похоже имеем походобную картину. Казалось бы иди и купи — но нет, несколько миллионов в месяц.
Посчитайте риски еще. Обычно история какая — есть 1-2 программиста, которые сделали внутренний продукт. На горизонте пары лет они сваливают и софт как-то работает до первого факапа. Стоимость простоя системы?
Дальше в силу того, что они делают такую штуку в первый раз и в неконкурентной обстановке — то несовершенство математики тоже прощается им. А вот тут уже кроется много потенциальных потерь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий