Вы упустили, что этим занималось два профильных подрядчика, каждый из которых даже без наличия ИТ-отдела должен был справиться в одиночку. И ещё пару деталей про то, как же всё-такие действовать в такой ситуации, и что может помочь — этот опыт может быть применим на более простых проектах.
К сожалению у нас не было 2-го варианта. Старую систему оставить было нельзя, так как она в ландшафте старого собственника с кучей интеграций с другими системами, и просто так ее даже скопировать нельзя.
Конфликт блокировок у нас возникал не на отчетах, а на проведениях\распроведениях документов, в частности: «Этапов производства». Количество большое, а блокировка накладывалась целиком на какой-то из больших регистров. Обошли наложением отбора для блокировок. Отчеты с огромными выборками приводили, да и иногда приводят к деградации системы.
Может и надо системно, но у нас было ограничение для ухода из систем старого собственника. Вариантов мять булки у нас не было. Наверное, глядя ретроспективно, что-то можно было сделать иначе, и, например, внедрить простую бухню. Но хотелось параллельно исполнить давние планы по созданию опер. учета на ERP. Тогда мы всего этого не знали. Как говорит мой друг: "Загад не бывает богат".
Зарубежное ПО было только у бухгалтерии, и у них не было вопросов, но вот же самый сок в том, что у нас и бухгалтера после перехода из РЖД к ОМК стали новые. И они переписанный SAP тоже не знали.
А вы не рассматриваете вариант, что в целом с учётом всех плюсов и минусов решение было принято рационально, и то, что в ИТ будут сложности, сильно перевешивало что-то другое?
Проблема была в том, что при разработке мы для ее упрощения просто переносим часть кода и реквизитов из новых версий 1С ERP в нашу 2.5.6.
Так у нас у ряда документов были реквизиты из версии 2.5.8, а при обновлении на 2.5.7 они впервые появляются. И имя реквизитов одинаковое. А вот ИД при первичном переносе не сохранился, и при сравнении конфигураций 1С решила, что это не обновление реквизита, а удаление и добавление одного и того же.
А так как при обновлении на новую типовую версию у нас сотни новых реквизитов, сразу это не заметили и при тестах тоже упустили, так как реквизиты были не основные.
Всё так. Прочитайте первый пост, там рассказ, как мы попали в эту ситуацию. Фактически, был выбор между делать так или просто остаться без ИТ-систем. Конечно, сейчас, если бы мы знали, как это делать правильно, наверное, сделали бы куда лучше, но круто быть умным постфактум.
Проводили анализ требований и сравнивали ТСО систем на САП и 1С. В ходе нелегкой гонки выбрали 1С, так как корпоративный САП тоже наложил бы кучу ограничений и потребовал бы много переработок.
Да, и на 1С у нас еще со времен РЖД уже был ряд проработок и задумок в части оперативного контура. Это легло в основу.
— Увеличили железо, поставили NVMe диски. — Настроили кластер серверов. — Распределили нагрузку на сервера через требования назначения функциональности — Изменили порядок распределения постатейных расходов 23 и 25 счетов – вместо распределения всё на всё, создали агрегирующие статьи 23 и 25 счетов и их 1 раз распределили на 20. — И ещё много небольшого тюнинга, настроек и корректировок аналитик.
Про обучение. Людей, конечно, обучали. Реальный мир таков, что когда вы около тысячи рабочих обучаете новой технологии, то из двух вариантов "всё сразу получается по всей стране идеально" или "всё же возможны сюрпризы" вероятность второго сильно выше. Если бы было время, мы бы и корпоративный институт развернули, и интерфейсы бы придумали получше и много чего ещё бы сделали. Собственно, дальше по внедрению и сделали. Напоминаю, нас на старте было 5 человек, и у нас был год.
Про отладку. К сожалению если на каждом шаге натыкать отладочных флажков, то расчет увеличится кратно, так как кроме расчета ему нужно будет выплевыпать по ходу тонны отладочной информации, а объем временных таблиц при расчете систем линейных уровнений в момент себестоимости может кратно превышать объем исходных данных. И каждая строка кода на вывод флажка ещё резко увеличивает вероятность упасть.
Вы упустили, что этим занималось два профильных подрядчика, каждый из которых даже без наличия ИТ-отдела должен был справиться в одиночку. И ещё пару деталей про то, как же всё-такие действовать в такой ситуации, и что может помочь — этот опыт может быть применим на более простых проектах.
К сожалению у нас не было 2-го варианта. Старую систему оставить было нельзя, так как она в ландшафте старого собственника с кучей интеграций с другими системами, и просто так ее даже скопировать нельзя.
Конфликт блокировок у нас возникал не на отчетах, а на проведениях\распроведениях документов, в частности: «Этапов производства». Количество большое, а блокировка накладывалась целиком на какой-то из больших регистров. Обошли наложением отбора для блокировок. Отчеты с огромными выборками приводили, да и иногда приводят к деградации системы.
Может и надо системно, но у нас было ограничение для ухода из систем старого собственника. Вариантов мять булки у нас не было. Наверное, глядя ретроспективно, что-то можно было сделать иначе, и, например, внедрить простую бухню. Но хотелось параллельно исполнить давние планы по созданию опер. учета на ERP. Тогда мы всего этого не знали. Как говорит мой друг: "Загад не бывает богат".
Зарубежное ПО было только у бухгалтерии, и у них не было вопросов, но вот же самый сок в том, что у нас и бухгалтера после перехода из РЖД к ОМК стали новые. И они переписанный SAP тоже не знали.
А вы не рассматриваете вариант, что в целом с учётом всех плюсов и минусов решение было принято рационально, и то, что в ИТ будут сложности, сильно перевешивало что-то другое?
Проблема была в том, что при разработке мы для ее упрощения просто переносим часть кода и реквизитов из новых версий 1С ERP в нашу 2.5.6.
Так у нас у ряда документов были реквизиты из версии 2.5.8, а при обновлении на 2.5.7 они впервые появляются. И имя реквизитов одинаковое. А вот ИД при первичном переносе не сохранился, и при сравнении конфигураций 1С решила, что это не обновление реквизита, а удаление и добавление одного и того же.
А так как при обновлении на новую типовую версию у нас сотни новых реквизитов, сразу это не заметили и при тестах тоже упустили, так как реквизиты были не основные.
Всё так. Прочитайте первый пост, там рассказ, как мы попали в эту ситуацию. Фактически, был выбор между делать так или просто остаться без ИТ-систем. Конечно, сейчас, если бы мы знали, как это делать правильно, наверное, сделали бы куда лучше, но круто быть умным постфактум.
Подождите второй части, всё это сделали.
Проводили анализ требований и сравнивали ТСО систем на САП и 1С. В ходе нелегкой гонки выбрали 1С, так как корпоративный САП тоже наложил бы кучу ограничений и потребовал бы много переработок.
Да, и на 1С у нас еще со времен РЖД уже был ряд проработок и задумок в части оперативного контура. Это легло в основу.
— Увеличили железо, поставили NVMe диски.
— Настроили кластер серверов.
— Распределили нагрузку на сервера через требования назначения функциональности
— Изменили порядок распределения постатейных расходов 23 и 25 счетов – вместо распределения всё на всё, создали агрегирующие статьи 23 и 25 счетов и их 1 раз распределили на 20.
— И ещё много небольшого тюнинга, настроек и корректировок аналитик.
Про отчетность, а не ERP: на первом этапе так и было. Все внедрение две очереди:
1) Достаточные аналитики для отчетности,
2) Все плюшки для полноценного оперативного учета и выпуска вагонов.
Выпуск вагонов запускали более плавно и всегда оставляя альтернативу на случай проблем. Во второй части чуть затронем.
Эх, жалко вас с нами не было!
Про обучение. Людей, конечно, обучали. Реальный мир таков, что когда вы около тысячи рабочих обучаете новой технологии, то из двух вариантов "всё сразу получается по всей стране идеально" или "всё же возможны сюрпризы" вероятность второго сильно выше. Если бы было время, мы бы и корпоративный институт развернули, и интерфейсы бы придумали получше и много чего ещё бы сделали. Собственно, дальше по внедрению и сделали. Напоминаю, нас на старте было 5 человек, и у нас был год.
Про отладку. К сожалению если на каждом шаге натыкать отладочных флажков, то расчет увеличится кратно, так как кроме расчета ему нужно будет выплевыпать по ходу тонны отладочной информации, а объем временных таблиц при расчете систем линейных уровнений в момент себестоимости может кратно превышать объем исходных данных. И каждая строка кода на вывод флажка ещё резко увеличивает вероятность упасть.