Comments 57
Когда в следующий раз будете тестировать ERP на вагоноремонтном заводе - не забывайте, что и куда будут возить на отремонтированных вагонах
описываемая ситуация реально не связана с качеством ремонта и вообще с самим ремонтом
p.s. был такой момент когда меня очень усиленно звали в одно депо начальником ИТ и отвечать за внедрение SAP-а тогда...я благоразумно отказался, поскольку видел как оно там устроено
p.p.s.вагоны ремонтируются по техпроцессу который от ИТ практически не зависит, главное чтобы запчасти подвозили, а их подвозить будут и без заявок в ЕРП вплоть до того что сам начальник депо на своем мерседесе будет их возить и покупать за наличку (и такое я видел!)
Работаешь на НПЗ - не забывай, какую технику заправляют соляркой.
Работаешь на автозаводе - не забывай, кто купит белую Ладу.
Работаешь на хлебобулочном - не забывай, кто ест твои галеты.
Работаешь врачом - не забывай, кого ты лечишь.
Платишь налоги - не забывай, на что они идут.
Я тебе и так могу сказать что будут возить и возят в этих вагонах - товары и различные блага по всей стране, железной дорогой обеспечивается значительная часть логистики в нашей стране, чтобы ты и твои дети, если ты конечно живешь в РФ, могли вкусно покушать и чтобы была горячая вода и отопление дома зимой и так далее. Ну а если не живешь, то уж тем более не нужно учить людей как им жить.
У 1С ERP же недостаток в том, что она сделана не для людей.
Типовая 1С ERP не подразумевает работу в учёте низкоквалифицированного персонала.
Где-то брутфорсом перебирали непонятные им поля — результат такой, как будто били кувалдой по клавиатуре.
Пользователи колотили данные от балды, не понимая, что и зачем. Им колесо точить, а не документ делать.
гении. Людей, по-ходу, не обучали? Инструкций со списком полей не было? Я не понимаю такого внедрения, где кто-то не понимает, какие данные куда и зачем колотит.
Добавляют отладочный код. Через три итерации — хлоп, не упала на этом шаге, но упала на следующем. Новый отладочный код. Для поиска каждой ошибки ждём N часов.
Я, конечно, в 1С не писал, но если процесс 60-70 часов и дет и падает без логов, то по всему коду сразу хотя бы флажки расставить, чтобы сузить поле поиска ошибки. Я как-то столкнувшись, что IDE отлаживать позволяет только через задницу, все промежуточные данные и значения выводил с флажками, чтобы не гадать об ошибке.
Про обучение. Людей, конечно, обучали. Реальный мир таков, что когда вы около тысячи рабочих обучаете новой технологии, то из двух вариантов "всё сразу получается по всей стране идеально" или "всё же возможны сюрпризы" вероятность второго сильно выше. Если бы было время, мы бы и корпоративный институт развернули, и интерфейсы бы придумали получше и много чего ещё бы сделали. Собственно, дальше по внедрению и сделали. Напоминаю, нас на старте было 5 человек, и у нас был год.
Про отладку. К сожалению если на каждом шаге натыкать отладочных флажков, то расчет увеличится кратно, так как кроме расчета ему нужно будет выплевыпать по ходу тонны отладочной информации, а объем временных таблиц при расчете систем линейных уровнений в момент себестоимости может кратно превышать объем исходных данных. И каждая строка кода на вывод флажка ещё резко увеличивает вероятность упасть.
Реальный мир таков, что когда вы около тысячи рабочих обучаете новой технологии, то из двух вариантов "всё сразу получается по всей стране идеально" или "всё же возможны сюрпризы" вероятность второго сильно выше.
в реальном мире все зависит от того, КАК обучали. Если обучение только формально и ложится на работника допнагрузкой к рабочим обязанностям - то да, ситуация будет как в вашем реальном мире. А в нашем реальном мире, например, ключевые пользователи процессов отвечали за качество вводимой информации неключевыми пользователями, тесты были развернуты для всех сотрудников за месяц до внедрения, и сотрудников отдельно освобождали для обучения. Но подозреваю, что у компании, отпочковавшейся от РЖД все было очень формально, и обучение легко нагрузкой параллельно с обязанностями (экономия ж). Потому и результат - вместо того чтобы дать человеку поковыряться с тестовыми документами и проводками пару дней, скинули все сразу на людей, и люди сели на задницу, и проект тоже.
а объем временных таблиц при расчете систем линейных уровнений в момент себестоимости может кратно превышать объем исходных данных.
то есть, как всегда, пытались запустить на микрокалькуляторе? ну, объем, и что? ну, валится он куда-то, и больше с ним ничего не происходит. Логи ж 1Ски не убивают напрочь процессы, почему процесс даже в разы проще лога должен все убить?
И каждая строка кода на вывод флажка ещё резко увеличивает вероятность упасть.
я, конечно, конфигураций ваших не видел, но если система падает от простой операции вывода, то можно требовать обратно деньги. Это в принципе достаточно простая и надежная операция в 1С
Желание менеджмента на многом сэкономить за счет работников вижу тут я...
Ну это не так работает.
Точнее, в основном не так.
Любые затраты на не основную деятельность (в том числе ИТ) стараются минимизировать, но, конечно, не в ущерб предприятию в целом. Обычно затраты допускаются когда они либо минимизируют текущие затраты (например, инвест проект по внедрению новой системы позволяет сэкономить что-то или повысить производительность чего-то или увеличить отдачу от чего-то) или же когда минимизируют какие-то риски (например, проект по замене старого оборудования на новое или же покупка тех поддержки) ну либо когда они необходимы с законодательной точки зрения.
И во всех случаях задача директора по ИТ объяснить тем, кто принимает решение о выделении финансирования, зачем нужен тот или иной проект. И если у CIO это не получается, то далеко не всегда это вина глупых менеджеров. Это может быть просто недостаток управленческих компетенций у CIO.
На самом деле отличный пост. Lessons learned по всем классическим ошибкам внедрения ERP - начиная от этапа инициирования и до стабилизации. При, судя по всему, полном отсутствии change management (которое управление организационными изменениями).
Пост очень хороший, потому что даёт возможность тем, кто только начинает, понять как делать не надо и попробовать сделать правильно.
Спасибо - безо всякой иронии.
"Это абзац"(с). Уберите перс. данные (скрины с прода с данными клиентов)
SAP от РЖД - и не САП вовсе, а самописка на бесплатной части САПа, мамкины менеджеры решили, что они самые умные и сэкономить захотели, нагнали кучу разработчиков и сотворили нечто, в итоге на то, что там получилось, только внутри ржд без содрогания и смотрели, стокгольмский синдром наверное 🤔.
Но мне не понятно, у ОМК к тому времени уже было давно внедренное ЕРП, как минимум финансы, производство, учет результатов и логистика, добавить в группу компаний еще одну - операция для консультантов достаточно типовая и не сильно затратная. Ремонты кстати у них тоже были внедрены, насколько помню, но по мелочи и без специфики, тоже не так чтобы сильно дорого получилось бы добавить от себя.
Почему не использовали имеющиеся системы, когда импортозамещение еще не было мейнстримом?
Проводили анализ требований и сравнивали ТСО систем на САП и 1С. В ходе нелегкой гонки выбрали 1С, так как корпоративный САП тоже наложил бы кучу ограничений и потребовал бы много переработок.
Да, и на 1С у нас еще со времен РЖД уже был ряд проработок и задумок в части оперативного контура. Это легло в основу.
Что такое "бесплатная часть” SAPa?
Каналы связи не тянули: если в прошлой архитектуре многое считалось локально, то тут все данные бегали в центральный ЦОД.
Архитектурно старая система нравится больше. Она более модульна, децентрализованее и как следствие устойчивее. Не понимаю этой моды везде засовывать всё на жирный ЦОД, в результате без интернета ни на почте посылку получить, ни в магазине товар в торговой сети не купить. Экономически, конечно, понять можно, но технически сложно) Случить что с ЦОД или каналом с ним - встаёт всё, отказоустойчивать никакая. Да, это было смешно до 2020-го, но в современных реалиях уже и не смешно.
Скажите, какие изменения привели к ускорению расчёта себестоимости с 60-70 часов до 15-20 часов ?
— Увеличили железо, поставили NVMe диски.
— Настроили кластер серверов.
— Распределили нагрузку на сервера через требования назначения функциональности
— Изменили порядок распределения постатейных расходов 23 и 25 счетов – вместо распределения всё на всё, создали агрегирующие статьи 23 и 25 счетов и их 1 раз распределили на 20.
— И ещё много небольшого тюнинга, настроек и корректировок аналитик.
То, что месяцами вводили лажу, и ни один вагон не пострадал, намекает, что у это не ERP, а обыкновенная бух.отчетность. данные собираются, но в них никто не смотрит и нужны только бухгалтеру раз в квартал налоги посчитать.
Ощущение от статьи, что тут классическая ошибка автоматизаторов процессов - их автоматизируют. А надо сначала их улучшить. А в компании ржд - упразднить добрую половину как устаревшие и ненужные. Но ни полномочий, ни ресурсов не дали. Поэтому все изначально обречены на страдания.
Про отчетность, а не ERP: на первом этапе так и было. Все внедрение две очереди:
1) Достаточные аналитики для отчетности,
2) Все плюшки для полноценного оперативного учета и выпуска вагонов.
Выпуск вагонов запускали более плавно и всегда оставляя альтернативу на случай проблем. Во второй части чуть затронем.
намекает, что у это не ERP, а обыкновенная бух.отчетность. данные
собираются, но в них никто не смотрит и нужны только бухгалтеру раз в
квартал налоги посчитать.
а так и есть
я тут выше упоминал что меня звали на внедрение сапа, в одно депо в подмосковье и я видел как оно работает
Контекст:
1) объем ремонта вагонов известен уже лет 50, сами вагоны технически почти не поменялись за эти 50 лет, меняются лишь модели некоторых незначительных деталей
2) количество запчастей и их необходимость известна лет на 5 вперед
Ремонт (как хотели):
1) приходит вагон, его надо занести в терминал, описать неисправные детали, каждый цех свои...ну прям голове кртинка..заезжает вагон и 10 человек представители цехов толпятся у терминала и тыкают маслянными пальцами в клавиатуру....вбивают свои данные
2) зарегистрировать детали которые на вагон установлены как замена, описать какие бракованные
3) приемщик пробежится по списку проверить что все что поставлено-поставлено, что сломано-заменено, тесты на выходе вагона пройдены
4) все счастливы
Как это работает:
1) Вагон приходит как обычно, все берут со склада детали - меняют-ставят, вагон уходит
2) утром в пятницу, матер цеха приходит с огромной пачкой заказ-нарядов и тупо вбивает в терминал весь план по ремонту вагонов на неделю...потому что охренеешь в этот торомозящий терминал вбивать данные в процессе работы который подчинен тактовому таймингу работы цеха...и 15 минут тыкать в терминал на каждой позиции - там не учтено
3) терминалы через год закрыти чехлом, заказ наряды стали отдавать экономистам и там отдельно взятая девочка раз в месяц стала вбивать все эти бумажки
(я был рад что туда не пошел, айтишников всех сократили через год, потому что терминалы стали не нужны, нужна оказалась девочка которая стала бумажки вбивать в компьютер, а техпроцесс как был 50 лет назад так и остался)
Автор, это типичное внедрение 1С. Просто у других времени не нашлось об этом писать, они ещё переходят.
Вы посмотрите, там даже в недоработанной ERP на сайте 1С более 1000 ошибок. ERP система от 1С, которую никому бы не порекомендовал. Кстати, потом выйдет 1С 9.0 и вы ещё столько же потратите на переход. Ну и как минимум был нужен грамотный 1С-ник был внутри, знающий процессы, который бы стучал по рукам, и рулил распилом системы.
Прочел вашу статью, прям появилось желание написать свою. Я так понимаю пятерых айтишников которые поддерживали РЖДшную ЕРП, и на тот момент об 1С ЕРП только слышали что она существует бросили на амбразуру внедрения? Ну очень жестко на мой взгляд. Ну а теперь немного вопросов:
Почему не взяли в штат на момент внедрения специалистов Подрядчика? На каждое направление по одному человеку. Он бы учил работников, контролировал ошибки ввода и допиливал функционал к тому что вам нужно.
Почему решили автоматизировать за столь короткое время все направления. Ну взяли бы те области где 1С работает без доработок - зарплата, кадры, продажи, складской учет, а самое сложное (расчет норм по дефектным ведомостям, планирование работ, дефицит, заказ наряды для сделки) вели бы пока на бумаге или в Эксель. Все равно все что вы там назабивали в 1С в тот период была липа.
Были ли ответственные специалисты на каждом направлении? Например ведущий экономист, бухгалтер, технолог, снабженец, мастер, который прошел обучение своего модуля в 1С ЕРП, получил сертификат и в совершенстве знал функционал. С которых можно было спросить почему твой бухгалтер делает неправильные проводки, почему твои мастера выдают неправильно задания, почему снабженец закупил не то что рекомендует система, почему неверно введена дефектная ведомость и т.п.
Подрядчик 2 выдаёт требования к оборудованию, настройкам кластера, настройке SQL.
Сообщите подробности, пожалуйста.
Я к одинэсам и прочему кровавому энтерпрайзу отношения не имею, мимо проходил. Но мне все же интересно, ЧТО там блин может считаться несколько суток на мощном кластере? Это же не физическая симуляция какая-то, где надо миллион шагов решать кучу сложных уравнений с высшей математикой. Это же просто какие-то одни условные эксельки сложить в другие условные эксельки? Или там все алгоритмы за N^2 написаны и на каждую выборку все базы данных целиком пробегаются?
На одном из заводов расчет зарплаты генерит 60 млн строк (начисления, удержания, перерасчеты для каждого работника). Это за месяц...
вы не представляете каким образом зарплата и налоги считаются ;) например
по каждому сотруднику считается вся годовая зарплата (каждый месяц, потому что налоговый период - год, и из неё вычитается уже уплаченные деньги), вычитаются вся вычеты, учитываются всякие фокусы исчисления налогов типа "в мае у нас поменялась ставка по налогу ФСС... до мая считаем по старому с мая по новому, а в июне некоторые начисления им не облагаются, а в августе разрешили не начислять на другой налог на третий вид начисления, а в декабре сотрудник принес больничный лист который был не закрыт с марта...а еще человек вспомнил что при устройстве на работу не принес справку об уплаченных налогах и нам теперь надо пересчитать весь старый период"
и это всё надо теперь сделать для 5000 человек
И что? У меня в 90-х на самописной программе две ДВК-4 считали зарплату для ~2000 человек за 2 часа и справлялись.
вы зарплату считали вместе с налогами, больничными и всеми и отчетами для всех фондов?
или бухгалтера брали распечатки и на счетах все сводили потом вручную?
это не просто задача сложить все начисления и вычесть все вычеты которые вручную девочки всем сотрудникам вбивают
это не просто задача сложить все начисления и вычесть все вычеты
Так а в чем принципиальное отличие? Пока то что вы описали выше выглядит именно так. Ну окей, на заводе 5-10 тысяч человек, для каждого ежемесячно может быть десяток-другой пунктов начислений (я работаю в университете, у меня в расчетном листке пунктов 15 разных за каждый месяц, те самые доплаты-надбавки-налоги-вычеты). 100 000 чисел, да даже если миллион, сложить-умножить это такая сложная задача что требует суперкомпьютера? Мне понятнее так и не стало.
Я в свое время писал ИТ систему для нигерийской платежной системы. Там клиринг на несколько тысяч пользователей в духе "сложить все транзакции за месяц и посчитать балансы" на Java + MySQL занимал несколько минут на одном не самом мощном сервере, и это потому что я тогда вообще БД делать и оптимизировать не умел (да и сейчас не умею).
Что тут может сутки занимать? Можно какой-то более конкретный пример?
"сложить все транзакции за месяц и посчитать балансы"
там задача сложнее чем просто сложить циферки
циферки в листке это далеко не все цифры по работнику
например сумма больничного, считается как сумма среднего заработка за последние 6 месяцев (причем заработок не та цифра которую вы получили на руки, а из строго определенных видов расчета, причем есть определенные ограничения сверху по этой суммы в зависимости от возраста и стажа работы)
вы можете сказать что надо просто брать цифры, т.е. их посчитать один раз и потом переиспользовать например но по факту каждый цикл расчета надо пересчитывать весь предыдущий период до текущего дня потому что изменения законодательства или налоговые лимиты зависящие от ФОТ могут менять уже посчитанные цифры... и это очень сильно увеличивает операционную сложность самих расчетов и чтобы посчитать одного человека надо вычислять не 15 пунктов 12 раз в год, а каждый месяц пересчитывать часть налогов и зарплаты за прошедший период на каждого человека. целиком
и при объемах больше 1000 человек это превращается уже в существенную вычислительную нагрузку
в текущем законодательстве вручную проверить начисление зарплаты и налогов одного человека - это несколько дней работы
Галактика ERP - даже без паралельного расчётна на разных ПК, по подразделениям, например считает на 3000+- за несколько часов .. сложнейшие наряды\позаказное распределение (8 аналитик) и т.п и уж точно не несколько дней... проблема и выйгрышь 1С в её архитектуре ..
Галактика ERP и Галактика ВУЗ (с чем мне реально приходилось сталкиваться) - жесть еще та! По мне так лучше 1С ERP и 1С Университет. По скорости работы с базой может и побыстрее (не значительно), но с точки зрения настройки функциональности и логики работы - то еще развлечение. На счет скорости расчетов в 1С многое зависит от правильно подобранного железа и оптимизации алгоритмов расчета.
Именно так, с налогами, больничными и все отчеты для фондов делались менее, чем за пол-часа, основное время уходило на печать расчетных листочков на матричном принтере.
сдается мне вы не сталкивались с современным расчетом зарплаты
помнится в начале нулевых часть даже обычной бухгалтерии не имело и трети текущей аналитики просто потому что мощности компов не хватало это переварить
а зарплатные программы современные, это сложнейшие монстры для доработок которых отдельные люди существуют которые специализируются конкретно на зарплате
Начисление зарплаты ныне, это совсем не то, что даже в 10-е годы.
Если просто тупо как у офисного планктона табель 5/2 по 8 часов, да больничный раз в год, то все просто и быстро.
Но когда есть смены, выходы за кого-то, больничные, отзыв из отпуска, или больничный во время отпуска, да все вместе и за прошлые периоды, плюс удержания и возмещния/льготы. И Всю эту красоту умножить на изменения в законодательстве да на несколько тысяч человек.
Самая жуткая жуть из того, что видел это больница, у врачей много разных начислений, совмещение, замещение, регулярно работают несколько по иной должности/специфике (чтобы не терять квалификацию), по одной из ставок могут уйти в отпуск, по другой работать, внутри такого отпуска-работы уйти на больничный, но выходить на работу (ибо надо). вот где треш и угар.
Современный расчет зп это весьма сложный участок расчетов на одного человека может быть очень много, да и сама 1с штука не шустрая.
Вот именно, что в себестоимости сложные системы линейных уравнений. С кучей шагов. Это самый сложный модуль в ERP.
А в каком месте там нужны именно системы линейных уравнений? Я наивно с дивана предполагал, что весь такой учет это именно что сложить-умножить по куче записей в бухгалтерских книгах, и выдать разные циферки для налогов и отчетов.
По большому счету, вы правы, это куча умножений, уравнений там нет, все распределения идут один ко многим по паре аналитик и по коэффициентам, но вот записей действительно генерирует много, может до ярдов доходить, потому что правил для распределения и драйверов тоже могут быть тысячи. Речь идет, как понимаю, в том числе про косвенные затраты
Доброго времени суток .приятно увидеть автоматизацию процессов на предприятии с железом)) а сколько подобная система стоит в деньгах? Если это тайна можете не отвечать ) все понимаю
Я после этой статьи зарегистрировалась !! До этого просто читала, тут очень хочется прокомментировать - подписываюсь под каждым словом, мы с Вами/омк ещё и партнёры, наша специфика - жд перевозки. Каждый этап по внедрению пережит уже не один раз в нескольких организациях и с теми же болячками. Самая большая боль, что для всех кто наблюдает за автоматизацией со стороны ( руководство, линейные исполнители) смысл самого слова "автоматизация" примерно равен -" все само будет правильно работать", а то что это обременяется дисциплиной тех кто должен в системе работать никто не хочет видеть (((. Кто-то про обучение некачественное прокомментировал, но ты хоть рыбкой об лёд бейся , обучай, если исполнитель не видит смысла в этом обучении, то он не будет учится. Коня к водопою можно подвести, а вот заставить напиться - нельзя.
если исполнитель не видит смысла в этом обучении, то он не будет учится
Разве это не должно стать проблемой руководителя этого исполнителя, а не вашей?
А может исполнитель не видит смысла, потому что его нет?
Все именно так!
Таже беда была, внедряли именно оперативный учет и управленку на производстве - вбить нормально данные (реально не много), да даже создать документ, нажать кнопку заполнить, проверить, провести распечатать - проблема!
решили реальным упрощением и сокращением документов (списание, выпуск и прием на склад объединили в один документ), по большей часть создать, нажать кнопку заполнить, провести. распечатать одну общую форму. и вот тогда производственники начали понимать, что польза есть, что система экономит их время, народ перестал воевать против, стали воевать за :) полилась масса хотелок и предложений (весьма часто дельных). а потом уже склад, продажи закуп и прочее пошло на ура, потомучто до людей в целом дошло, что вотэтого лысого бородатого надо слушать, а не слать :)
Людям на местах (склад, упаковка, отгрузка) нарисовали "комиксы" (никто ничего читать и вникать не будет), что-то типа "howto", расклеили возле рабочих мест.
Очень крутая и полезная статья! Читала как книгу — столько в ней саспенса!
И сложнее всего в этом челлендже — убедить пользователей, что новое лучше старого)
Леонид, по вольте вас обнять, друже: я вторую молодость пережил, пока читал Ваш рассказ: это ВСЕ бывает при внедрении ERP, кроме разве что заточенных на определенный процесс решений. Поверьте, со всеми указанными проблемами я и моя команда также столкнулись при внедрении Axapta, правда, в ней велся только управленческий учет, бухгалтерский и налоговый - это тот еще адок, особенно в западных системах. И все прочие консультанты! Так что читаем «Историю одного внедрения», «На обратный билет заработаете, ноутбуки добудете в бою» и ностальгируем 😀
Вам еще повезло, что вы со стороны заказчика: со стороны консалтинга еще добавьте ограничения бюджета и управления хотелками. Добро пожаловать в Консультанты!! Жду продолжения!
С Уважением, Георгий
молодцы!
Отвага и отвага: замена ERP на действующем вагоноремонтном производстве с тестами прямо в бою