что значит ошибка клиента в ерп
Ошибки внедрения ERP-систем и как их избежать
Внедрение ERP-системы это сложный и долгий процесс и редко все идет по плану. Некоторые ошибки доставляют небольшие трудности, а другие могут полностью загубить проект. В результате будут потрачены месяцы работы и миллионы рублей впустую.
Некоторые ошибки можно предупредить заранее. Расскажу о самых частых из них и как их избежать. Статья будет полезна топ-менеджерам, потому что все перечисленные проблемы идут «сверху».
Часто руководители не понимает реальную пользу от ERP. Они считают, что система сама решит проблемы компании. Но это не так.
Разработчики всячески заманивают и обещают рост продаж и снижение издержек. Но ERP — это лишь инструмент для планирования и управления ресурсами. Система увеличит возможности анализа, уменьшит вероятность человеческих ошибок и сократит время некоторых бизнес-процессов. Но ничего из этого не принесет прибыли само по себе. Нужно уметь пользоваться системой и понимать, какие проблемы можно решить с ее помощью.
Поэтому внедрение не может быть самоцелью. Бездумная автоматизация редко дает положительные результаты и может даже навредить. После внедрения системы может оказаться, что она вообще была не нужна. В результате затрачены время и деньги на ненужную работу.
Сначала нужно определить глобальные цели, например:
Затем каждую цель нужно уточнить или разбить на более мелкие. Они должны быть четко сформулированы и иметь количественное выражение:
оперативно получать данные для принятия управленческих решений ➝ ежедневно формировать отчет «Укрупненный баланс»
улучшить работу склада и логистики ➝ увеличить скорость отгрузок на 10%
При проектировании системы нужно учитывать планы компании на ближайшие годы. Если этого не сделать, то сразу после внедрения может потребоваться модернизация системы. Придется снова тратить деньги и время на то, что можно было предусмотреть заранее.
Внедрение занимает несколько лет, а ведь система должна еще выполнить свои цели. Поэтому проектировать ее нужно так, чтобы она работала без необходимости изменений минимум 2-3 года.
Естественно, знать все заранее невозможно: новые законы, изменения рынка, значимые события в мире. Но уже известные направления развития нельзя игнорировать.
Несколько примеров изменений, которые нужно учитывать:
Часто руководители считают, что ход внедрения можно алгоритмизировать и подробно расписать. Так появляются огромные ТЗ, на составление которых уходит несколько месяцев.
Но ERP — это сложная система, и невозможно предусмотреть все заранее. Практически в любом внедрении что-то пойдет не так и придется менять начальную постановку.
Например, изначально неверно поняли часть бизнес-процессов. Значит нужно дорабатывать один или несколько модулей. В результате некоторые разделы ТЗ вообще придется менять, а ведь на них потратили деньги и время.
Чаще используется другой подход. Сначала составляется укрупненный план работ, который разбивается на этапы. И по ходу внедрения под каждый этап пишется отдельное ТЗ. Сначала составляют ТЗ для первого этапа, внедряют. Затем с учетом проделанных работ пишут ТЗ для второго этапа, и так далее.
Редкое внедрение идет полностью по плану. Приходится сдвигать сроки, тратить больше денег или отказываться какой-то части системы. Поэтому при планировании сроков и бюджета лучше посчитать их немного с запасом.
Если не уложиться в бюджет, то придется отказаться от некоторых модулей или настройки дополнительного функционала. Либо искать дополнительные деньги.
Если не уложиться в срок, то можно сорвать свои бизнес-планы или подвести заказчика.
Например, мы пообещали заказчикам ускорить отгрузку и выставление счетов до конца года. Они учли наши обещания в своих планах. Если мы не успеем вовремя, то им придется менять свои планы. Это неприятно, отношения испорчены.
Узнать причины неправильного планирования поможет Panorama Consulting. Это консалтинговая компания, которая занимается внедрением ERP. Каждый год она проводит независимое исследование рынка ERP-систем. В свежем отчете есть данные о превышении бюджета и сроков.
Бюджет. В бюджет не вписываются 38% компаний, и превышают его в среднем на 66%.
Сроки. 47% компаний не уложились в сроки, и превышали их в среднем на 11%.
ERP-системы содержат много модулей, и в большинстве компаний используется только часть из них. Если начать внедрять все подряд, то получится большая бесполезная система, которая не принесет нужных результатов.
Сначала чаще всего внедряют модуль финансов, ведь важно не допустить проблем с деньгами. Учет и контроль финансовых потоков — это то, без чего не может обойтись ни одна организация.
Затем рекомендуется внедрить бухгалтерский и налоговый учет. Они могут быть в одном модуле или раздельно. Они важны для отчетов перед государством. Если ошибиться, даже случайно, государство за это накажет. ERP-система уменьшит вероятность ошибок.
Далее модули внедряются в зависимости от основного вида деятельности компании, например:
Топ-менеджеры должны быть заинтересованы в завершении проекта и быть в курсе дел.
Заинтересованность. Внедрение новой системы — это не только установка и настройка программ. Это еще перераспределение полномочий и обязанностей. Сотрудники, которых это касается, могут не захотеть таких изменений и будут «сливать» проект как только могут. Если руководитель вовремя не примет действия — проект может провалиться саботажем.
Контроль. Руководители должны быть в курсе хода внедрения, особенно если возникают проблемы. Если план внедрения сдвинулся хотя бы на день, руководители должны об этом знать, даже если проблема уже решена. Руководители смогут оценить это отставание в масштабах всего процесса и при необходимости скорректировать план. Если накопить много таких «мелких» смещений, можно сильно отстать от графика.
Если внедрением занимаются только ERP-консультанты, то внедрение может полностью провалиться. Заказчик должен понять, что внедрение нужно в первую очередь для него. Поэтому он обязательно должен привлекать своих сотрудников.
Каждая компания индивидуальна: везде свои особенности бизнес-процессов и технологий. Сторонние консультанты не смогут полностью понять все нюансы, даже если они профессионалы с мировым именем.
Сотрудники компании-заказчика знают, как устроена их операционная работа. Они могут рассказать о неочевидных трудностях, о которых руководители даже не догадываются. Также они могут увидеть будущие проблемы, связанных с внедрением.
Например, в компании на одну ночь каждый месяц выключают все системы для профилактики. А в ERP-системе на это же время могут быть запланированы фоновые работы: обмен данными между модулями, расчет бюджета и т.п. В результате на следующий день работа некоторых отделов может просто остановиться.
Даже если руководители знают о таких вещах, для них это покажется мелочью и они не расскажут об этом консультантам. И проблемы начнут всплывать уже после внедрения, а это опять потребует времени и денег на устранение.
Ошибки в ЕРП после перехода с УПП или выгрузки данных из Бухгалтерии предприятия 3.0
Сегодня при работе с 1С ЕРП 2.5.6.124, появилась задача: перенести договора из 1С Бухгалтерия предприятия 3.0 в 1С ЕРП 2.5. Так как настройка синхронизации нам не подходила, решили взять за основу модуль предлагаемый 1С Enterprise20_2_5_6_124_DataUload_BP3.epf (его можно скачать вместе с обновлением). Из данного модуля взяли правила обмена, подредактировали их под свои нужды с помощью КД 2.0, и воспользовались обработкой Универсальный обмен данными, для выгрузки на стороне БП 3.0 и для загрузки на стороне ЕРП 2.5. Вследствие чего получили в базе приемнике, все наши договора и соглашения (на основании этих договоров), согласно предустановленным отборам. Договора появляются в статусе не согласованны. Для использования этих договоров установили статус согласованно и
Основным для нас является то, что договор может стать распоряжением для осуществления операции Приёмки на ордерном складе
Вследствие чего мы столкнулись с такой ошибкой
Поиски по данной ошибке в интернете толком ничего не дали, при анализе ошибки оказалось, что для проведения документа нужен документ «Регистратор договора с поставщиком (соглашения с поставщиком)».
Ранее я с таким документом не сталкивался. Данный документ используется как Измерение регистра Движение товаров, что следует из ошибки выше.
Этот документ создается автоматически при создании нового договора, в нашем случае происходила загрузка по правилам конвертации, и алгоритмы после загрузки отработали некорректно. Для устранения данной ошибки мной был создан простой модуль на основании типовых механизмов 1С УТ (на УТ тестировать проще чем на громоздкой ЕРП), после данный модуль был подкорректирован под ЕРП 2.5.6.124. В результате на все новые договора был создан данный документ и ошибок с проведением документов не наблюдалось. К данной статье прикладываю свой модуль, может, кому-то понадобится. Плюсы приветствуются.
Скачать файлы
Специальные предложения
Обновление 25.05.21 08:00
См. также
Поиск и замена дублей + v0.99 Промо
Обработка позволяет выполнять гибкий поиск, замену и удаление дублирующихся элементов любого справочника или плана видов характеристик.
03.08.2007 83404 7917 tormozit 227
ЗУП 3.1.17.94 и регистр Мероприятия трудовой деятельности переданные
Пользователи программы «1С:Зарплата и управление персоналом 3.1» с 26.02.21 при обновлении на редакцию (3.1.17.94) могут получить ошибку «Запись с такими ключевыми полями существует» и отсылка к регистру «Мероприятия трудовой деятельности переданные». Можно заранее подготовиться и исправить данные регистра, но можно это сделать и в момент обновления. В обоих случаях можно воспользоваться предлагаемой обработкой.
01.03.2021 10183 1430 mos_apit 46
Файл тестов для xUnitFor1C: тестирование проведения документов
Тестирование проведения документов. Проверяется, что: а) документ проводится; б) движения документа после перепроведения не изменились.
30.06.2020 6913 46 q_i 16
Перераспределение уплаченного ПФР в пачке без уволенных.
Перераспределение уплаченного ПФР в пачке без уволенных.
14.04.2011 14607 90 ignor 5
Поиск и замена дублирующихся элементов справочников (для 1С:Бухгалтерия предприятия 8.1 редакция 2.0)
Стандартная обработка из типовой УТ. Теперь и для типовой БП 2.0
24.06.2010 19842 404 Незнайка 12
Перезаписать наборы записей с пустой валютой
Обработка для любой конфигурации, в которой есть регистр бухгалтерии хозрасчетный. Перезаписывает наборы записей с валютой<>неопределено на всех невалютных счетах.
21.09.2009 11714 26 77dream77 2
Поиск задвоенных документов по результатам переносов из других баз.
При переносах из разных баз разными программистами создавались документы с разнотипными номерами, в том числе с префиксами. Встала задача навести порядок. )
27.08.2009 11443 102 elizarovs 1
Редактирование реквизитов в КД
Редактирование реквизитов в Конвертации данных 2.0
28.07.2009 17443 74 acsent 16
Оформление пересортицы в БП
На основании 2х документов списания и оприходования по зачтенным позициям формирует документ «Операция» вида Д43 К43 (или Д41 К41) на перезачитываемые позиции. Счет берется из регистра сведений счет учета номенклатуры.
16.06.2009 13232 95 y22-k 3
Оформление и зачет пересортицы на складе в конфигурациях УТ
16.06.2009 16907 188 y22-k 10
Тестирование производительности 1С Бухгалтерский учет 8.1
14.11.2008 20237 176 capitan 12
Обработка для замены ссылок
05.11.2008 16849 470 ValeriVP 5
Проблемы при обновлении 1С: Комплексная автоматизация до версии 2.5.7.226
Мы же при предварительном тестировании выявили только одну ошибку в коде обновления и с утра обновили рабочую базу и компания перешла в аварийный режим работы.
> Ошибка выполнения обработчика обновления Документы.СверкаВзаиморасчетов.ОбработатьДанныеДляПереходаНаНовуюВерсию:
> Открытая внутри обработчика обновления транзакция осталась активной (не была закрыта или отменена).
Для правки лучше сразу создать расширение и в него добавлять исправления. Указанная ошибка исправляется добавлением в модуль менеджера документа «Сверка взаиморасчётов» в процедуру «ОбработатьДанныеДляПереходаНаНовуюВерсию» между строкой 6865 и 6866 текста: «ЗафиксироватьТранзакцию();»
(1) Верни с архива и разбирайся на копии. Это для начала.
(0) Имело бы смысл указать версию с какой совершили переход.
Будет совсем неудивительно, что приключилась такая вот неудачная попытка перепрыгивания с 2.4 на 2.5
(20) У меня был повод залезть в конфигураторе не по всем подсистемам вообще, но по конкретным отдельным вопросам.
Например, по просмотру документов Производство без заказа в конфигураторе пришел к выводу, что перепахали всю кухню работы с ресурсными спецификациями.
Моего Заказчика это категорически не обрадует.
(21) Относительно подсистемы ЗУП я думаю об этом и готовлю плацдармы 🙂 Начиная с возможностей установки ЗУП в чистом виде. Но имхается, что если сейчас 2.4 соответствует 3.1.18, обновления на 2.4 будут продолжаться в части ЗУП как минимум год (пока 3.1.18 актуальная в виде стабильной версии)
Сейчас проверяю все документы оплаты, везде ли проставилось новое значение.
(34) Представь что автопроизводитель монополист выпускает все новые версии своих глючных авто
И все клиенты как ежики
И вот да ты можешь конечно что то начать им писать, претензии какие то, об ошибках в саппорт и т.д.
В результате возможно через полгода-год тебе и исправят злобную багу в одном авто. Когда ты уже продал его и собрался покупать новый.
(34) Должность у тебя такая что «как конечный потребитель» тебе думать просто нельзя, на шажок вперед хотя бы думать надо
Иначе будешь, каждый раз, иметь коллапсирующую систему и рваный полыхающий пердак
(50) >Склад и продажников пихаем в УГ
Вы в курсе что это называется микросервисная архитектура?
Только обмен извратный вместо http-сервисов между ними или шины/брокера
https://ibb.co/sJH7KYd
На картинке не видно но в окне щелкают счетчики загрузки документов
(62) А если контрагент получив по ЭДО документ его не подписывает? Или с разногласиями?
Каким образом обратно из БП в УТ? И как данные обратно из БП в УТ, ну например клиент-банка где?
И где можно полные отчеты получить например какой менагер сколько реально по оплатам?
>> Имитации работы системы со всеми пользователями ни у кого нет.
Всё никто и не тестирует. Но критический функционал должен тестироваться. В том числе с привлечением пользователей. Как правило, достаточно протестировать
20% функционала, который на среднестатистическом предприятии покрывает до 80% потребностей всего учёта.
(71) Не к тому, чтобы кого-то защищать, но к тому, что ситуация получилась кривая несколько для Поставщика 1С.
Вот смотрим, что там написано на странице релизов. Вот тут https://releases.1c.ru/project/ARAutomation20
Текст копировать не буду, но вроде бы из него очевидно, что операция перехода с 2.4 на 2.5 достаточно ответственная и это именно _переход_, а не очередное _обновление_.
Однако, в строке таблицы указано вот так : 2.5.7.226 29.10.21 2.5.5.104, 2.5.6.291, 2.5.7.211, 2.4.13.281
И это показывает реализованную возможность запуска именно обновлением, а не получением отдельной и сложной процедуры перехода.
Т.е. допустим есть похожая ситуация в конфигурации БП 2 и БП 3, что там переход осуществим через запуск обновления, но не совсем простого, а специально разработанного.
Зачем? Вероятно, чтоб не было ошибки или случайного запуска процесса.
Почему же в случае с конфигурациями КА2.4 и КА2.5 не сделали такого способа? Не очень понятно.
Можно предположить, что это недоразумение исправят. Ну а кто успел заскочить не глядя. Значит влетел.
(71) >> Это только ваше мнение.
Да. Но, по аналогии с известным выражением о том, что пусть первым в меня кинет камнем тот, кто имеет какой-то другой опыт. Покажите мне систему уровня ERP (хоть российскую, хоть зарубежную), где подобные обновления тестировать не нужно. Я лично не знаю ни одной.
Дело не в том, что я лично привык. Дело в том, что так делают все и всегда.
И причина очень проста. Разработчик не может протестировать подобного уровня сложности конфигурацию при всех возможных комбинациях исходных данных. Иначе готовый релиз не будет выпущен никогда.
Даже если говорить о предприятиях, где стоит абсолютно типовая конфигурация без доработок и расширений, то на каждом предприятии есть свой уникальный набор настроек, включенных/выключенных функциональных опций, учётных политик и пр. и пр. Не говоря уже об уникальности бизнес-процессов, методов и способов отражения данных в учёте и т.д.
Да, 1С тестирует конфигурацию в целом и отдельные подсистемы. На каких-то демонстрационных примерах. Протестировать абсолютно всё невозможно физически. Если бы это было возможно, то не было бы никогда ошибок.
Ни разу не претендую на то, что я всё знаю.
Но повторюсь. Через несколько лет Вы сами будете с улыбкой вспоминать свой сегодняшний опыт.
>> почему я должен проверять это всё за производителем?
Частично уже ответил.
Но суть сводится к тому, что производитель не может протестировать конфигурацию на конкретно ваших данных и конкретно ваши бизнес-процессы.
Уверен, что принимая решение о выпуске релиза, 1С-овцы не нашли никаких критических багов. Более того ошибки не выявили и те, кто работал с предварительными тестовыми релизами.
Иначе релиз просто не был бы опубликован. Однако ваш опыт показал, что они (баги) были.
PS Вы думаете 1С просто так со скуки придумала правила о том, что конфигурации уровня ERP продавать и внедрять могут только специализированные центры внедрения, имеющие соответствующие компетенции? Уверяю Вас, нет. Сделано это было исходя из огромного негативного опыта провальных внедрений. Внедрений делавшихся либо самостоятельно, либо «специалистами», которым тупо не хватило опыта, но пожелавших непременно срубить бабла и решивших, что можно вот так тупо поставить типовую конфигурацию и она как-то там сама заработает (ведь разработчик всё «протестировал»).
PPS Не принимайте все мои слова на свой счёт. Ни в коем случае не хочу Вас обидеть или даже как-то задеть. Мы все иногда ошибаемся или заблуждаемся. В этом нет ничего страшного или зазорного. Но реально Ваша позиция (разработчик всё протестировал) видится по-детски наивной.
PPPS И да. Совсем забыл. Ни в коем разе не пытаюсь оправдывать или защищать 1С. Если у кого-то вдруг сложилось такое впечатление.
Качество типовых конфигураций и обновлений, мягко говоря, оставляет желать лучшего. Как и качество предварительного и предрелизного тестирования.
Но справедливости ради нельзя не отметить, что всякие там SAP’ы с их бест практикс (прости, Господи) не многим лучше.
(75) >Разработчик не может протестировать подобного уровня сложности конфигурацию при всех возможных комбинациях исходных данных.
А как он пилить конфу то умудряется тогда?
Тестирование это на порядки проще чем пилить. Есть куча автоматизаций для этого. И тестеры стоят сильно дешевле прогов.
(75) >всякие там SAP’ы с их бест практикс (прости, Господи) не многим лучше.
Это не так.
Точнее в сапах и других подобных там «эталонное» (синоним типовое) решение обычно все супер.
Проблема что любое внедрение там кастомизация и тут начинаются траблы.
(78) >> «эталонное» (синоним типовое) решение обычно все супер.
Ну так и демка от 1С тоже будет супер.
Как правило, до 90% проблем и ошибок на демонстрационной базе не воспроизводится. Чтобы их (ошибки) смоделировать приходится множество настроек выполнить, учетную политику подкрутить, исходные данные в нужном виде завести и сам бизнес-процесс смоделировать от начала до конца.
(76) >> Тестирование это на порядки проще чем пилить. Есть куча автоматизаций для этого. И тестеры стоят сильно дешевле прогов.
Это всё так.
Проблема, как мне кажется, в том, чтобы протестировать на всех возможных вариантах исходных данных со всеми возможными вариантами настроек параметров, опций и НСИ.
По сути 1С отдаёт это на откуп центрам внедрения. Перекладывая на их плечи ответственность и принятие решений об обновлениях.
Практика, наверное, не самая лучшая. Но и SAP никто не внедряет своими силами.
(83) Да не в этом проблема.
Проблема что у 1С слишком много разных конф!
Слишком много в них разных проблем!
И они погрязли в багах.
Короче очередь багов превысила их возможности, для хоть какого то решения проходит от полугода до бесконечности.
(84) И такая проблема тоже имеет место быть.
Но каждую конфу пилит отдельная группа разработчиков (насколько я знаю).
В багах они погрязли, но вряд ли из-за большого разнообразия конфигураций.
Тут что-то может принципиально измениться только при принципиальном изменении подходов к разработке конфигураций.
Например переход на отдельные малосвязанные модули. По аналогии с тем же SAP.
Но подобная смена парадигмы крайне маловероятна в обозримом будущем. Это будет означать необходимость выкинуть тонны кода и написание почти всего и вся с нуля. Не в первый раз (скажет кто-то). Но уж слишком дорого. Да и где найти заказчиков готовых в очередной раз перевнедрять всё заново. Не говоря о том, что никто не даст просто забросить поддержку того, что внедряется сегодня и сейчас.
(86) КА лайт это замена УНФ
Лучше придумайте как ограничить сервер 1С для «типа файловая» и «типа базовая» чтобы ценник другой был
Ошибка при обновлении ERP 2.4
Всем привет. Пытаюсь обновиться на версию 2.4.1.261, сравнение/объединение прошло нормально а вот Отложенное обновление ИБ выдает ошибки
1. Обновление индекса поиска отчетов, предусмотренных в программе, пишет что
Процедура «ВариантыОтчетов.ОтложенноеОбновлениеОбщихДанныхКонфигурацииПолное» обработки данных завершилась с ошибкой:
<ОбщийМодуль.ВариантыОтчетов.Модуль(4985)>: Ошибка при получении значения атрибута контекста (КомпоновщикНастроек)
КомпоновщикНастроекКД = ОтчетОбъект.КомпоновщикНастроек;
по причине:
Ошибка в схеме компоновки данных
по причине:
Ошибка получения информации набора данных
по причине:
Ошибка в запросе набора данных
по причине:
<(68, 34)>: Поле не найдено «СебестоимостьТоваров.ВидЗапасов.Поставщик»
СебестоимостьТоваров.ВидЗапасов. >Поставщик КАК Поставщик,
не пойму куда копать
а вторая ошибка в процедуре
«Заполняет реквизиты «Назначение переработчика», «Тип договора» и «Вариант оформления закупок». Пока обработчик не выполнен, не возможно обособление сырья и материалов в переработке на стороне по договору с переработчиком, а так же оформление документов закупок (при использовании договоров).»
Процедура «Справочники.ДоговорыКонтрагентов.ОбработатьДанныеДляПереходаНаНовуюВерсию» обработки данных завершилась с ошибкой:
<ОбщийМодуль.ОбновлениеИнформационнойБазыСлужебный.Модуль(4323)>: Произошло зацикливание процедуры обработки данных. Выполнение прервано.
ВызватьИсключение ТекстИсключения;