Комментарии 8
Зачем это в хабе Хабр?
Да, когда ещё не было никакого ПГК Диджитал, лет 10-15 назад, коллега из ПГК по "Вагонникам" нелестно проходился. В то время как я понял ПГК самостоятельно организовывала ремонт, были запчасти на вагоны, графики ремонтов и прочее, и всё это в 1C. Соответственно нужно было в 1С свести в одной точке в правильное время вагон с его потребностями в ремонте согласно регламенту и по повреждениям, запчасти и исполнителя ремонта. "Вагонники" понимали в вагонах, запчастях и ремонтах, но в 1С они понимали так себе, косячили и призывали помощь. Приходилось разбираться, что и куда они не так сделали, куда пропали запчасти в 1С, ну и "раз у тебя так всё хорошо получается, давай ты нам ещё сделай ..." - пытались преобразовать техподдержку в оператора 1С, чему техподдержка совершенно не радовалась. :-)
Возможно, что за 10–15 лет сменились или люди, или культура в компании, или формат взаимодействия, но работу с коллегами из ДЭПС (вы называете их «Вагонники») могу охарактеризовать только положительно. Конечно, мы сталкивались с разными трудностями, но в конечном итоге всегда удавалось выстраивать коммуникацию. Однозначно, без их поддержки и участия продукт не смог бы существовать.
Да, на то время в целом коллектив в ПГК был вменяемым, но обычный корпоративный адок присутствовал, как и везде в кровавом энтерпрайзе. Коллега собирался до пенсии доработать, не сманился из ПГК, поскольку ЗП специалиста там была как ЗП начальника на моей работе. Деньги те же, а головная боль в разы меньше. А потом техподдержку ПГК вывели в отдельное юрлицо, работы стало больше, и что там дальше было уже не слышал. Теперь уже и ПГК Диджитал образовался.
Похоже образование цифровых дочек есть нынешняя мода. Есть под это задачи, но задачи-то были всегда. Значит сейчас есть деньги под их решение и руководящая воля, которая их "выделит". Этот вопрос к сожалению в статье не раскрыт, путём каких процессов ПГК решил потратиться и заточить свой бизнес-топор.
Например в РЖД (а когда ПГК образовывали, довольно много работников РЖД стали работать в ПГК) есть свой фирменный способ обоснования и принятия решений по инновациям, по которому даже была выпущена бумажная книжка когда-то давно. Иллюстрацией этого метода является отказ от мышек в кассах РЖД. Они тогда обосновали, что оператору проще без мышки работать в кассовом ПО, и ПО кассы специально пишется под безмышечный интерфейс. Обоснованием была конкретная сумма, и это не были просто затраты по закупке и замене мышек. Там обосновывали потери времени оператора, его трудозатраты, расценивали это всё в деньгах в масштабе всея РЖД...
Спасибо за комментарий. В целом в статье кратко отражена история обоснования части этого проекта в разделе «Наш подход: расчет эффекта до начала разработки». То есть мы взяли факт и написали матмодель, которая распределила вагоны по предприятиям лучше. «Лучше» — это значит, что суммарные затраты оказались по модели существенно ниже, чем фактические. Часть этой суммы пришлось уменьшить по объективным причинам. Оставшаяся сумма была названа эффектом, и следующие кварталы бизнес проверял, насколько в деньгах мы этот эффект приносим компании.
Т.е. вышли с инициативой к бизнесу, "продали" ему гипотезу, бизнес посмотрел - расходов и инвестиций минимум, проверил гипотезу реальностью.
Любопытно, когда инвестиции превышают всякую возможную выгоду от внедрения. Но там должно быть обязательно качественное изменение.
Внедрённое решение количественное, не качественное. Качество осталось прежним, появилась экономия за счёт более оптимальной организации процесса ремонта. Это хорошо. А вот если бы после внедрения решения вагоны вовсе перестали бы ломаться или хотя бы реже ремонтироваться - это уже другое качество. :-) Но конечно это малореально.
Спасибо за вовлечённое обсуждение!
Относительно эффекта — он значимо снижает затраты на ремонт вагонов за счёт повышения качества принятия решений. Это стало «зелёным» светом для старта проекта и его развития.
Мы не можем влиять на эксплуатационные условия и скорость износа вагона. Если из-за работы нашего сервиса вагоны станут ремонтироваться чаще — за это нам тоже «спасибо» не скажут. Поэтому здесь именно качественное, а не количественное изменение — на уровне процесса принятия решений.
По снижению частоты поломок и ремонтов: мы пытались идти в сторону оценки клиентов — того, как часто после операций погрузки и выгрузки вагону требуется текущий ремонт, — а также в сторону оценки ВРП в части качества проведённого у них ремонта. Но оказалось очень сложно изобретать механизмы влияния вне внутреннего контура компании.
Приятно читать, что продукт работает и продолжает развиваться 👍 Привет, всей команде «Цифрового вагона» 🤝
Оптимизация ремонта грузовых вагонов: от мирового опыта к российской практике