Комментарии 52
Интересно было бы провести морфологический разбор (надеюсь правилно применил умное слово) в статьях о разных продуктах, пока мне больше запомнилось что при упоминании 1с - героически, вопреки, подгорает.. :)
при упоминании 1с - героически, вопреки, подгорает
потому что никто не упоминает как подгорает с другими продуктами
я в комментах у прошлой статьи упоминал что при внедрении САП все подгорало точно также, но статей никто не писал на хабре...потому что наверное "божественный сап, это не эта ваша тормозная 1С" хотя я точно помню тормоза по 15 минут при вбивание данных по ремонту тормозов в терминале...и там был САП тогда только только внедренный
p.s. фотки цеха по ремонту автотормозов...ох..прям воспоминания нахлынули...довелось там побывать, не там конечно откуда фотки в статье, но в аналогичном, всё максимально знакомое
Я не уверен, что морфология это именно то слово, которое вы искали. Морфология - раздел грамматики об изменении форм слова.
Тут скорее подойдёт n-грамма или коллокация.
Супер, просто молодцы!
Как же все кошмарно в управлении в крупных компаниях!
Давайте перечислим для краткости:
1) делаете перевод большого производства без пилотного проекта и/или попытки как-то отразить существующие операции за период в новой системе, ну хоть как-то попробовать что "это подходит"
2) не тестируете свои мощности
3) при расчете мощностей используете минимальные требования, хотя явно собираетесь работать с нагруженной операциями/пользователями базой. Или вообще ничего не используете, поэтому часть оборудования конечных компьютеров не подходит.
4) меняете и архитектуру заодно, тоже без учета мощностей
5) очень слабо попадаете в уже используемый функционал (40% - очень мало. И при этом рубильником отключаем старую систему!)
6) переходите с кастомного высокопроизводительного и удобного решения на универсальное и поэтому не особо предназначенное для вас (существенно неудобнее, кушает больше ресурсов, требует куда большего обучения пользователей)
7) ошибаетесь в разы в размере кастомизации и поддержки (отсюда ит отдел сильно вырос)
8) используете оперативную базу заодно и как аналитическую (отсюда "аналитики" - кто выгружает огромные куски данных себе убивает производительность операторам ввода - кто много пишет в данные)
9) используете управленческую базу заодно и как бухгалтерскую (отсюда погоня за обновлениями, невозможность сильной кастомизации, длительное ожидание фиксов от 1с, затраты времени на увлекательную переписку с 1с)
10) вы могли решить проблемы с очисткой и стандартизацией данных заранее, ведь ровно эти же данные были и в прошлой системе. Но почему-то делаете это в момент перехода, в самый неудачный момент.
Эти странные взаимоухудшающие пункты кто-то принял, что именно так и будем делать. А вместе с этим, подозреваю, что вы еще и "критическая инфраструктура", за которую можно и присесть. Извините, я бы тоже сбежал от вас.
P.S. очень посмешил абзац про гарантию от первого подрядчика при том, что систему одновременно изменяют 2 подрядчика. Как вы себе это представляете?
Всё так. Прочитайте первый пост, там рассказ, как мы попали в эту ситуацию. Фактически, был выбор между делать так или просто остаться без ИТ-систем. Конечно, сейчас, если бы мы знали, как это делать правильно, наверное, сделали бы куда лучше, но круто быть умным постфактум.
Ок, давайте вычеркнем 5 и 7 пункты, которые похожи на "постфактум". Осталось то очень немало, это принципиально картину не поменяет.
Прочитал и первый ваш пост и только укрепился в мнении, что в управленцах у вас кошмар. Если максимально обобщить: вы делали автоматизацию без ресурсов: финансовых, человеческих, организационных. И кто-то из вашего руководства принял решение, что вот именно так и надо.
Мне очень слабо верится, что ваш подрядчик не говорил ни о каком из пунктов выше, но он - консультант, а решение то за вашим руководством. И вобщем-то весь остальной движ о том, как героически тушить пожары за этим руководителем.
Вы фио и должность этого руководителя определили (для себя. врятли вы сможете об этом открыто писать)?
ну что вы еще хотите от не-ИТ компании которую насильно вписали в нереальный проект? чтобы они там всем ИТ отделом уволились героически?
у них же был выбор - или перевозить сап на свою площадку или делать всё с нуля... проблема в том что они не осилили посчитать что перевозка сапа выйдет по факту дешевле с учетом тех костылей на которые они попали не пойдя по этому пути..но из-за того что они в этом не компетентны
подрядчик понял задачу не как «Нужно кровь из носу сделать до дедлайна»,
а как «Нужно расписать план работ до дедлайна, а там — как пойдёт».
он всё отлично понял, подрядчик пишет план под бюджет, а не то что у вас там вагоны стоят
я вот совсем недавно был на стороне такого подрядчика, задачи ставились примерно так:
вам 2 недели чтобы написать линукс с нуля, начинайте..подписывая договор о заказной разработке 5 лет назад вы подписались на всё что мы тут вам говорим, по этому мы через 2 недели вам штраф выпишем что вы не справляетесь
и делали именно так ... планируем то что на имеющемся бюджете влезет в дедлайн, а дальше - это ваши проблемы и на нас их не перекидывайте
Там в первом посте вроде было написано про то, почему сап не избавил бы от головняка. Как-то выходит, что собственно и альтернативы-то не было, кроме ЕРП С1. Реально ребята красавцы, что с таким справились
Сразу видно человека с опытом :)
Зрит в корень ошибок.
Да, ребята по наполеоновски ввязались в проект, авось кривая в битве вывезет.
Самое смешное, что при таком подходе внедряемая система ЕРП превращается в еле ворочащийся и никому неизвестно как работающий монолит.
В итоге после "внедрения ЕРП" требуется новое внедрение - сия мысль доходит до многих только в конце проекта.
Мне вообще не понятно зачем втянули 1С ERP в цеха с таким уровнем нетиповых задач. Даже не вдаваясь в детали проекта явно просится какая-то MES система. Но в целом выглядит как подвиг, то ли "Как закалялась сталь", то ли «Через четыре года здесь будет город-сад!».
Судя по тексту, приказ о выборе и внедрении 1С ERP и о сроках и условиях внедрения на лету спушен свыше. Срочные нужды. В тексте также упоминалась SAP, которая явно MES-функции давно уже выполняла. Вот её-то и втупую заменили на ERP. То что им блок "производство" от 1С слишком сложен для их операций вполне разумное предположение. Но ни оценку ни прототипирование видать не разрешили - срочность решает всё.
Отличный рассказ, распечатал и сохранил в отдельной папке! Собраны абсолютно все грабли (подрядчик-теоретик ни разу не зашедший ножками в производство, великий человек, который предложить собирать ключевых сотрудников и их опрашивать, лишь всего через несколько месяцев нашлись люди, переводящие рабочий матерный в красивый русский и прочее, миллионы аналитик в бухгалтерии, из-за которых долго закрывались затратные счета и волевое решение свернуть эти статьи затрат, что означает их практическую ненадобность для дальнейшего анализа себестоимости). Особенно понравилась часть про совпадение добавленных реквизитов с приехавшими с обновления. Неужели никто (подрядчики и работающие прогеры на месте) не догадался как то оформлять свои модули и дописки (не ЗаявкаНаПогрузку, а м_ЗаявкаНаПогрузку)?
Проблема была в том, что при разработке мы для ее упрощения просто переносим часть кода и реквизитов из новых версий 1С ERP в нашу 2.5.6.
Так у нас у ряда документов были реквизиты из версии 2.5.8, а при обновлении на 2.5.7 они впервые появляются. И имя реквизитов одинаковое. А вот ИД при первичном переносе не сохранился, и при сравнении конфигураций 1С решила, что это не обновление реквизита, а удаление и добавление одного и того же.
А так как при обновлении на новую типовую версию у нас сотни новых реквизитов, сразу это не заметили и при тестах тоже упустили, так как реквизиты были не основные.
Не совсем понял раздел конфликт блокировок. Мне казалось, что 1С уже очень давно для отчётов использует версионный режим READ_COMMITED_SNAPSHOT или как-то так он называется. Тогда отчёты не должны вешать транзакции. Потому как если они вешают, то это мрак, и будет вечный забег по граблям.
Конфликт блокировок у нас возникал не на отчетах, а на проведениях\распроведениях документов, в частности: «Этапов производства». Количество большое, а блокировка накладывалась целиком на какой-то из больших регистров. Обошли наложением отбора для блокировок. Отчеты с огромными выборками приводили, да и иногда приводят к деградации системы.
А что тогда означает этот абзац?
С другой стороны, мы знали проблемные отчёты — обычно за большой период. С прошлой системы у людей осталась привычка выгружать вообще все «сырые» данные за период в XLS, а уже затем делать формулами всякие преобразования. Идея, что можно получить агрегат уже из SQL, была для них незнакомой и местами пугающей. В общем, по всей базе они собирали джойн, которым так известен интерфейс 1С, и оставляли его считаться, чтобы получить свои данные. Иногда сборка такого отчёта занимала часы, на которые и блокировались все другие пользователи: они страдали, а работа системы кратно замедлялась. Мы выявляли людей с такими отчётами, били по рукам. Люди плакали, говорили: «Нет, нам нужны данные от момента рождения Вселенной до её тепловой смерти». Просто ограничивали выборку, перенастраивали отчёт.
Но вообще то что 1С не использует версионные СУБД и их принцип работы (с update conflict'ами в частности), а предлагает блокировать все разработчику самому руками - это конечно треш. Что мешало им сделать нормально - загадка.
А если еще учесть, что они даже в типовых по вашим словам блокируют криво (что в общем предсказуемо, с учетом того, что это должен делать разработчик) и нужно все "переблокировать" внедренцы, то вообще слов нет. Только разве сочувствие, что кто-то умудрился выбрать такое решение.
А что тогда означает этот абзац?
То, что не надо делать отчеты на прод сервере кластере. Отчетность необходимо строить на отдельном корпоративном хранилище данных. В крайнем случае хотя бы на standby сервере. Но какое там DWH - хорошо, что проект вообще закончили) Впрочем именно через такие граблепоходы появляется профессионализм и экспертность.
Не понял, а чем мешают отчёты на мастере в версионном режиме. Работают и работают. У нас есть некоторые проекты с объемом и количеством данных больше чем у вас (там терабайтами измеряется объем данных, а логика десятками тысяч событий ) и работают без проблем. Да, что-то отдельно в BI (OLAP) крутится, но и в OLTP более чем много по ряду причин.
Просто не надо блокировочники (пессимистичные блокировки в смысле) использовать в OLTP (что ручные на уровне сервера приложений, что автоматические на уровне СУБД) и будет счастье. А так, мы героически решаем проблемы, которые сами себе создаём.
У нас есть некоторые проекты с объемом и количеством данных больше чем у вас (там терабайтами измеряется
У вас линейка на 2 порядка короче)
Если серьезно, то вы сами привели цитатой выше потребность пользователей выгружать данные «данные от момента рождения Вселенной до её тепловой смерти» и разумеется я отвечал на это. Из любой современной OLTP БД можно выгрузить сферический отчет на полную глубину хранения таблиц фактов на миллиарды строк. Вот только в больших системах источниках редко хранятся данные за 5, а тем более 15 лет, но как правильно все оно выгружается в холодный слой. А DWH (которые вы, если я правильно считал, назвали OLAP) такие данные хранит, обрабатывает и предоставляет любому количеству пользователей за секунды/минуты, но не часы
Просто не надо блокировочники (пессимистичные блокировки в смысле) использовать в OLTP (что ручные на уровне сервера приложений, что автоматические на уровне СУБД) и будет счастье.
Все так, но разбивается это о совсем разные порядки затрат и более быстрый их рост. Разнесение читающей и пишущей нагрузки в разные базы (физические накопители) - это почти полностью решаемо на уровне системного администратора, кроме того является подвидом горизонтального масштабирования и в принципе его можно вширь увеличивать - появилась еще новая читающая неоперативная нагрузка => сделали для нее отдельную базу (условно имеем линейный рост затраты за наращивание). Путь про блокировки - требует уже программистов и тестировщиков (они дороже), мест исправлений много (больше затраты на каждый кейс, больше персонала), и потолок оптимизации гораздо ближе - условно выходит экспоненциальный рост затрат за наращивание.
Думаю, метод с блокировками из-за характера роста затрат подходит либо для совсем точечных оптимизаций, либо на малых по сложности базах (самописных, например).
Вы - большие молодцы. Хорошо, что руки не опустились. Боролись до конца и победили! Только одна ошибочка, но она не ваша, а умного руководства. Не надо было САП трогать. Но тогда бы не было пути настоящего самурая.
Жила была бабушка...
Сама виновата
Может быть, надо было делать системно и с достаточными ресурсами? А на зарубежном ПО, до вашего прихода всё работало на ура? При том, что 1С должен быть дешевле.
Может и надо системно, но у нас было ограничение для ухода из систем старого собственника. Вариантов мять булки у нас не было. Наверное, глядя ретроспективно, что-то можно было сделать иначе, и, например, внедрить простую бухню. Но хотелось параллельно исполнить давние планы по созданию опер. учета на ERP. Тогда мы всего этого не знали. Как говорит мой друг: "Загад не бывает богат".
Зарубежное ПО было только у бухгалтерии, и у них не было вопросов, но вот же самый сок в том, что у нас и бухгалтера после перехода из РЖД к ОМК стали новые. И они переписанный SAP тоже не знали.
В жизни всегда есть место подвигу. Главное - держаться от этого места подальше
Героизм – это всегда чья-то недоработка. В данном случае случае, это проблема ТОП менеджмента, который купил вагоноремонтные депо и совсем не думал, как это будет интегрировано в текущую компанию ОМК. Проблемы интеграции коснулись не только IT, но и финансов и общей организации труда.
Про то, что не имея компетенций, купили сразу 39 ремонтных депо, я вообще молчу. Обычно покупается одна компания\депо, на ней проводится пилотное слияние, изучаются все подводные камни и прочее. После того, как процесс отработан, можно начинать масштабирование и купить ещё несколько депо.
А вы не рассматриваете вариант, что в целом с учётом всех плюсов и минусов решение было принято рационально, и то, что в ИТ будут сложности, сильно перевешивало что-то другое?
Про то, что не имея компетенций, купили сразу 39 ремонтных депо, я
вообще молчу. Обычно покупается одна компания\депо, на ней проводится
пилотное слияние, изучаются все подводные камни и прочее.
вы думаете решения о покупке ЖД депо принимаются просто так как на рынке? это инфраструктура обслуживания монополиста, причем в нашей стране. если подвернулось провести такую сделку - ее надо проводить сразу и целиком даже не вникая в потери, второго шанса не будет никогда.
тут есть еще подводный камень, когда придет время, эти депо или отнимут или настоятельно попросят продать еще комуто
Как будто в 2005 год попал, тогда тоже приходилось тормоза разруливать. Но с тех пор с таким проблемами не сталкивался, а может уже просто знал основные причины и быстро решал.
А перевод всего ремонта из РЖД в отдельную компанию это тоже из 2000х когда каждый начальник зарабатывал на том что выводил часть бизнеса на оутсорс. Оутсор выгоден только тогда когда работник не полностью у тебя занят, а если контора работает только на тебя то это работало когда эта контора не платила налоги и зп серая бвла .
А перевод всего ремонта из РЖД в отдельную компанию это тоже из 2000х
когда каждый начальник зарабатывал на том что выводил часть бизнеса на
оутсорс.
о даа, я помню это, у нас было такое в депо, электронщики и кондиционерщики были отдельными ООО которые платили откат начальнику за право работать в депо (помимо официальных договоров)
===
честно говоря я и тогда и сейчас поддерживаю перевод ремонта из контура РЖД, но не так как это делалось тогда...потому что видел чем занимается ремонт когда он был в РЖД
Вместо того, что бы нанять профессионалов для разработки и внедрения нового решения (для клиента), владельцы решили сэкономить, и повесить все на отдел эникея. Отдел героичесски бился, но по факту проиграл, но сами считают что победили, и сильно собой гордятся.
Вот краткий персказ длинной статьи.
Вы упустили, что этим занималось два профильных подрядчика, каждый из которых даже без наличия ИТ-отдела должен был справиться в одиночку. И ещё пару деталей про то, как же всё-такие действовать в такой ситуации, и что может помочь — этот опыт может быть применим на более простых проектах.
Именно так и это повсеместно в производстве. Такое ощущение , они не понимают или не хотят понимать и живут двухтысячными (как здесь вспоминали)
Интересно, хотябы по 5 окладов премии вам заплатили?
"Проект года" я так понимаю медальку повесил себе подрядчик-вендор? Они это любят
Взгляд со стороны обывателя на прирост вашей базы в 200 Гб/мес вызывает недоумение. Я попытался писать со скоростью 60 символов в минуту и сохранять в юникоде, у меня получилось 2.6 мегабайта текста в месяц при условии что я буду писать с этой скоростью 24/7, не отвлекаясь на еду и сон. как вы умудряетесь это делать, как?!?
Спасибо, автору, статья была увлекательной и занимательной и очень хорошо написана. Спасибо!
Вот возник вопрос:
Напомню, что раньше было две софтины: одна — с привычным и понятным интерфейсом, где мастера в два клика обозначали свои операции.
Как я понял, что у мастеров не так много задач в 1С, показать что делают, статус поставить.
А у вы не рассматривали варианты интеграции с WEB, то есть написать WEB приложение с интеграции с 1С для тех кому все данные из 1С не нужны? А нужно лишь малый набор, это бы и не загружала сервера пользователями, нагрузка была меньше и вероятнее всего не было необходимости обновлять парк ПК, если грамотно подойти к оптимизации WEB проекта.
Охохо, снова героическое внедрение ERP на базе 1С. Последнее время наблюдаю следующее - берут и выдвигают на рукойводителя мальчика и говорят " чтобы завтра внедрили" так по простому по армейски. А потом мальчики понимают что ошиблись, но их не научили признавать ошибки их учили успеху и только успеху и карьерному лифту. А тем временем люди, те кто работал стабильно и до внедрения (рабочие и колхозницы) , начинают увольняться и недоавтоматизация недоучета доводит предприятие "до ручки" , таких примеров множество на зарубежном опыте, но книг мы не читаем по менеджменту.
На распределении запасов еще покушаете вкуснятинки. Так сказать пацанский подгон со стороны 1С.
Есть еще одна проблема, которая меня печалит: это рынок партнеров у 1с (франчайзинга). Они соревнуются друг с другом по количеству внедрений ERP, потому что так придумала 1с.
Пример можно посмотреть тут: https://1c.ru/rus/partners/ckerp.jsp. Обращаем внимание на столбец АРМ в таблице и фильтр "опыт крупных внедрений" над таблицей.
Из-за этого странного соревнования партнеры стремятся всеми правдами и неправдами рейтинг поднять. Поэтому там, где стоило бы на 1000 мест внедрить: ЕРП на 100 мест, бухгалтерию на 50 и какую-то легковесную конфигурацию на 850 - теперь будет гордо ЕРП на 1000. Она будет железных ресурсов жрать раз в 5 больше. В этой ЕРП будут доработаны самые сложные блоки, что партнер тоже запишет себе в плюсы, а у клиента это будут десятикратные затраты. Почти всем пользователям все равно будет неудобно или переусложненно (или оба варианта вместе) - просто потому что сложные интерфейсы простыми не сделать, а также бюджет на внедрение ограничен - если какие-то фичи удалось сделать за десятикратный прайс, то это автоматически выдавило другие фичи, повышающие удобство.
Полная некомпетентность руководства. Сразу "режут глаза" сказки про "кто-то ввёл", миллиарды...
Отличная статья, включая первый пост. Прекрасный материал для обучения студентов или начинающих консультантов. Я бы даже прочел книгу на базе этой истории с большим количеством деталей и кейсов для самостоятельного анализа.
Хорошо бы описать матрицу рисков проекта.
Очень признателен автору за материал!
Всё же остаются вопросы.
1) Сколько стоил весь проект по плану и по факту? Дороже или дешевле SAP вышло?
2) какие альтернативы 1С (кроме SAP) рассматривали перед началом проекта и рассмотрели бы сейчас?
3) если бы поступил подобный запрос сейчас как бы действовали (за исключением уже описанных факапов типа исследования каналов связи и мощностей оборудования, перевода с матерного на русский)? Например, имело бы смысл разделить внедрение 1С бухгалтерии для бух. налогового учёта и внедрение ERP системы (для управленческого учёта операций с вагонами и т.п.)?
4) на ваш взгляд какие альтернативы 1С сейчас существуют для использования в подобных проектах? (в частности интересует платформа Турбо)
Не было мысли на местах создать простые личные кабинеты на веб технологиях?
Ну то есть прям простые формы на любом фреймворке. Да, нужен был бы фронт и бэк (2-3 человека вполне). Дальше там же валидация данных и проксирование "чистых и правильных" данных в 1С. По сути, то, что было у вас раньше - вместо SAP, как понимаю.
По умолчанию, в 1С реально много не нужного и это вызывает много вопросов. Можно, настроить рабочее место сотрудника, но это не решает другие архитектурные особенности 1С. Вы об этом пишите в этом после.
А вот упрощенные ЛК на условном react+back созданные на готовом UI ките, может облегчили бы вам жизнь.
Вспоминая работу на металлургическом комбинате я бы никогда в жизни не дал своего согласие на такие работы без четкого плана, пилотного участка, качественной ОПЭ с визами авторитетных пользователей о реальном успешном запуске и планах раскатки на остальные 665 филиалов.
Отвага и отвага: как мы выбирались из полного абзаца с неработающей ERP на 39 производствах