Почему программа на предприятии умирает после ухода внедренцев

19.06.25

Бизнес-анализ - Внедрение изменений

1С:ERP имеет сложную внутреннюю структуру, но очень слабую «защиту от дурака». Пользователи легко могут совершать ошибки, приводящие к «расползанию» регистров и проводок. Пока проект сопровождают внедренцы, контроль за корректностью ведётся, но как только система передаётся в руки локальной ИТ-службы, начинают появляться проблемы. Новые пользователи могут невнимательно изучать инструкции, некорректно заполнять документы, да и сама программа меняется от версии к версии, что усложняет ситуацию вплоть до того, что количество ошибок и расхождений данных возрастает до уровня «ваша программа вообще не работает». Расскажем о том, как проходит процесс внедрения 1С:ERP, и что происходит после завершения проекта.

Бесплатные

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Бесплатно
Сводные проверки
.xlsx 15,37Kb
40 Скачать бесплатно

Зачастую через 4-5 лет после внедрения некоторые функции в программе «отмирают».

Чаще всего пользователи, которых никто не контролирует, просто перестают вносить нужные данные – в результате ERP-система перестает быть комплексной и теряет свою информативность. С ней «в одиночку сражается бухгалтерия», потому что ей нужно сдавать отчетность, а остальные блоки используются с переменным успехом.

Другой типичный сценарий – нас вызывают на предприятие, потому что не заполняется отчетность. Открываем базу и видим полный хаос. И дело не в доработках, меняющих логику расчета себестоимости, а в том, что регистры с проводками расползлись. Одни и и те же операции проводятся разными документами – не теми, что нужны. И никто за этим не следит. Такая база уже фактически не подлежит восстановлению – проще закрыть, перенести остатки и начать все заново.

Цель статьи – двойная:

  • С точки зрения теории – обсудить типичные ошибки и проанализировать, почему процессы автоматизации могут деградировать

  • С точки зрения практики – показать реальные инструменты контроля, которые без переписывания программы позволят отслеживать возникающие в ней проблемы, проверяя, насколько качественно заполняются все нужные данные.

 

Почему часто программа «деградирует» со временем

 

Попробуем разобраться, как выглядит стандартное типовое внедрение.

Сразу уточню: я говорю не о внутренних проектах, которые реализуются силами собственной ИТ-службы компании, а о проектах, где работают внешние подрядчики – франчайзи. Мы приходим, внедряем, а потом покидаем проект.

Как правило, все начинается с подготовительного этапа, на котором мы занимаемся функциональным моделированием – представители бизнеса, ИТ-специалисты и команда внедрения договариваются о том, какие задачи должна решать система.

На этом этапе мы определяем цели – что должна уметь система и какой результат заказчик должен получить в итоге. Также прописываем взаимодействие между подсистемами. Все это фиксируется в документе, который может называться по-разному: функциональная модель, концептуальный проект и т.д.

Затем при необходимости система дорабатывается, мы переносим остатки, обучаем пользователей и готовимся к запуску.

 

 

Далее начинается, пожалуй, самый сложный этап – опытно-промышленная эксплуатация.

Здесь могут быть вариации, потому что не все фирмы-внедренцы соглашаются проводить опытно-промышленную эксплуатацию. Некоторые заключают договор только на сдачу решения, без ответственности за дальнейший запуск.

Сразу скажу – на такие условия соглашаться ни в коем случае нельзя. Этап опытно-промышленной эксплуатации не менее важен, чем функциональное моделирование, потому что именно на нем вы проверяете, работает ли ваша модель в реальных условиях.

Как бы тщательно вы ни прорабатывали систему заранее, достоверность модели редко превышает 70-80% – всегда найдутся процессы, о которых никто не вспомнил. А какие-то операции по объективным причинам просто не «взлетают».

Это естественный процесс адаптации. Например, если вы запускаете сложный блок планирования закупок с еженедельной актуализацией, то можете столкнуться с тем, что такой частый пересмотр плана предприятию просто не нужен. Он только нагружает пользователей. Тогда принимается решение актуализировать план только раз в месяц или раз в квартал – возможно, именно в таком виде он и нужен конкретному предприятию.

Важно понимать, что фактическая работа системы по результатам опытно-промышленной эксплуатации почти всегда будет отличаться от описания в функциональной модели. Появятся отклонения, корректировки, дополнительные требования. И к этому нужно относиться спокойно.

 

 

Будущее системы во многом зависит от того, на каком этапе к проекту подключается внутренняя ИТ-служба компании.

Если ИТ-служба подключается только тогда, когда проект завершен, и внедренцы уже «собирают вещи», начинается хаос. Бывает, что проект должен завершиться в конце апреля, а представители ИТ за неделю до завершения приходят и начинают интересоваться: «А как у вас тут вообще всё работает?» В такой ситуации им, разумеется, скажут: «Все работает хорошо. Есть документ – функциональная модель, там все описано. Читайте, разбирайтесь, при решении любых вопросов ориентируйтесь на этот документ. Ну, и читайте инструкции».

Это катастрофический вариант для будущего системы.

Хорошие ИТ-службы понимают, что им с этим жить. И они включаются в проект с самого начала – как только начинается функциональное моделирование. Им важно понимать не просто, что тот или иной документ должен быть введен, но и зачем и на что он повлияет.

Здесь главная проблема в том, что с сотрудников ИТ-службы никто не снимает их основных обязанностей. Им просто дают в нагрузку новую программу. А у них и так уже куча звонков, сообщений, срочных задач – они перегружены. И в такой обстановке полноценно участвовать в обсуждении логики системы просто физически невозможно.

Идеальный вариант – когда под проект выделяют одного-двух ИТ-специалистов, не загруженных на других задачах, у которых есть возможность погрузиться в проектирование системы с самого начала. Повторюсь, в функциональной модели часто описано ЧТО делать, но не описано ЗАЧЕМ: например, зачем нужно установить те или иные настройки, указать те или иные значения реквизитов. А без понимания «зачем» сопровождение системы превращается в бесконечный поток вопросов и ошибок.

Если ИТ-служба включается в проект как можно раньше и понимает процесс – система продолжает жить и после внедрения.

А если нет – то сопровождение превращается в постоянную работу нескольких наших консультантов, которые просто заменяют внутреннюю ИТ-службу. Но цель, конечно, не в этом. Мы, как внедренцы, хотим создать такую систему, которая и без нас тоже будет работать.

 

 

Вторая причина – специфика самой программы, в данном случае, 1С:ERP.

Мне кажется, что разработчики уверены, что пользователи – как «ученые коты». Имеют по два высших образования, прекрасно разбираются в структуре регистров, внимательно читают все, что им выдает программа, и осознанно нажимают каждую кнопку.

 

 

Но в реальности мы часто сталкиваемся с другими пользователями – теми, кто игнорирует предупреждения системы и выполняет действия, которые потом приводят к проблемам, например, к необходимости пересчета всех периодов. И даже ограничение прав не всегда помогает.

Конечно, в идеале каждый пользователь должен пройти курсы по ERP, освоить основы программирования, сдать всех «специалистов-консультантов», а уже потом садиться за систему. Но в реальности пользователи бывают разные, и мы их не выбираем.

 

 

Что же делать в такой ситуации?

  • Самый распространенный метод – встроить в программу «защиту от дурака», специальные механизмы, которые не дадут пользователю сделать что-то критически неправильное. Но этот метод, к сожалению, требует кодирования. А те, кто работают с ERP, знают, насколько часто выходят новые редакции с серьезными изменениями прежних механизмов. Поэтому такая «защита от дурака» требует постоянной поддержки: при каждом обновлении ее нужно адаптировать, переписывать – иначе она просто перестанет работать. Без таких механизмов, конечно, не обойтись, но везде ставить «защиту от дурака» просто не имеет смысла – иначе каждое обновление превратится в настоящий ад. К сожалению, чем больше в системе пользователей, тем больше потребуется защиты.

  • Второй вариант – обучить пользователей. Хороший вариант, но тоже, к сожалению, не панацея. Во-первых, не все сотрудники даже после обучения способны правильно работать в программе. Во-вторых, персонал меняется, и как правило, новому сотруднику дают инструкцию, которую писали еще на этапе функционального моделирования. А поскольку в процессе опытно-промышленной эксплуатации модель уже поменялась, то инструкция давно устарела. Да, надо бы ее актуализировать. Но обычно это делать некому и некогда, потому что опытно-промышленная эксплуатация – это всегда сумасшедший, когда нужно быстро решить сотни проблем каждый день. В результате сотрудники читают инструкции, которые уже не отражают реальное состояние системы.

  • Третий вариант – внедрить инструменты контроля, которые позволят вовремя обнаруживать ошибки и отклонения в системе. Именно этим мы сейчас и займемся.

 

 

Но прежде хочу рассказать об организации поддержки пользователей и о том, какие составляющие для этого нужны:

  • Группа поддержки. Крайне желательно, чтобы на стороне заказчика были люди, которые участвовали в создании программы с самого начала, и понимают, что к чему. Либо специалисты, которые пришли в компанию уже после запуска, но имеют глубокие знания по работе с 1С:ERP. Потому что просто посадить человека, пусть даже программиста со знанием 1С, не всегда достаточно – разобраться во всех нюансах программы без контекста бывает сложно.

  • Инструмент для быстрого обращения пользователей в поддержку. Использовать электронную почту или телефон для решения проблем с программой неэффективно. У пользователей должна быть возможность максимально быстро и удобно зафиксировать проблему – без длинных описаний и скриншотов. Нажал кнопку – и запрос сразу отправлен в техподдержку со всеми необходимыми для анализа данными. При этом критически важно, чтобы ответы ИТ-службы на эти обращения кто-то контролировал. Не оставляйте пользователей один на один с ИТ-службой, потому что даже у сильных ИТ-служб коммуникация с пользователями страдает. Например, пользователь пишет, что курсовые разницы в программе рассчитываются неправильно, а ИТ его вместо помощи отправляют читать устаревшую инструкцию с утверждением: «Вы неверно ввели документ. Заявка закрыта». В итоге у бухгалтера, рассчитывающего закрытие месяца, уже не остается времени на переписку, он просто берет свой любимый документ «Ручная операция» и правит проводки так, как ему надо. А потом ИТ-служба обвиняет пользователей, что они все ломают ручными операциями.

  • Инструмент для раннего обнаружения проблем. Ошибки, которые могут повлиять на закрытие месяца, должны выявляться заранее. Потому что если вы за 5 дней до дедлайна обнаружите, что у вас в программе 60 тысяч ошибок, времени на их исправление просто не хватит. Вы просто попросите программиста все убрать корректировками регистров – лишь бы успеть закрыться, а «потом как-нибудь разберемся». Но так не работает. Даже если реально руки дойдут до старых ошибок, то чтобы их исправить, придется вскрывать периоды. И тут уже никто не гарантирует, что новое закрытие даст те же результаты, что и старое.

  • И последнее – инструмент для регулярного контроля. Это когда вы по итогам месяца запускаете определенный комплект отчетов, которые проверяют, что в регистрах все корректно. Таких проверок необязательно должно быть много, но с их помощью вы сможете регулярно отслеживать и устранять отклонения, опираясь на понимание того, как работает система.

 

Инструмент для быстрого обращения в техподдержку

 

Покажу инструмент для быстрого обращения в поддержку. Это не реклама, потому что это не наш инструмент, а просто публикация с Инфостарта. Но мы используем этот инструмент практически во всех наших проектах на этапе опытно-промышленной эксплуатации, а потом оставляем его клиентам – и они дальше продолжают им пользоваться.

 

 

Это расширение, которое устанавливается на любую базу. После установки в каждом документе и справочнике появляется кнопка «Обратиться в техподдержку».

 

 

При возникновении проблемы пользователь может нажать эту кнопку, откроется окно заявки в техподдержку в привязке к тому объекту, в котором возникла проблема, и там можно будет сразу описать свой вопрос.

Во-первых, этот инструмент удобен тем, что обращение автоматически привязывается к нужному объекту.

 

 

Во-вторых, все заявки собираются в одном месте. Ответственный специалист видит, какие запросы поступили, и распределяет их между исполнителями.

Например, руководитель проекта на этапе опытно-промышленной эксплуатации может видеть, сколько вообще у нас вообще заявок в работе, какие они, насколько часто они повторяются.

 

 

Можно назначить нескольких исполнителей – например, мы обычно назначаем исполнителей с нашей стороны и со стороны заказчика, чтобы сразу включить в работу ИТ-службу клиента. Одного из них выбираем основным – того, с которого я, как РП, буду спрашивать, что происходит.

 

 

Еще здесь можно подключить себе уведомления о поступивших заявках себе в мессенджер. Фишка хорошая, но я как РП не рекомендую этого делать, если вы хотите спокойно спать, а не нервничать постоянно из-за того, что происходит.

 

 

У заявок есть статусы, по ним удобно отслеживать прогресс.

 

 

И еще есть специальные отчеты, позволяющие посмотреть, что у нас спрашивали, и что мы на это отвечали. Можно сделать по всем этим вопросам и ответам поиск, и если у нас 15 раз одно и то же спрашивают, написать, наконец, нормальную инструкцию.

Или, если там один и тот же пользователь сто раз задает один и тот же вопрос – мы ему отвечаем, а он не понимает – провести с ним какую-то дополнительную работу.

Конечно, для обращений в техподдержку есть и другие инструменты, но этот удобен именно тем, что все происходит в самой базе. Не нужно переключаться. Мы его сейчас используем на всех проектах, даже на этапах разработки, для того, чтобы вести переписку по ошибкам между аналитиком и программистом.

 

Инструмент для раннего обнаружения проблем

 

А теперь расскажу о нашем инструменте для раннего обнаружения проблем.

 

 

Это расширение, которое выросло у нас на проектах – оно называется «Контрольные отчеты».

Фактически – это набор отчетов, за каждым из которых должен быть закреплен ответственный сотрудник. Даже если сам он не сумеет решить проблему, то хотя бы сможет ее вовремя заметить и сигнализировать тому, кто сопровождает систему.

В состав расширения входит справочник «Запросы к данным» и рабочее место с отчетами по этим запросам.

 

 

Вот так выглядит справочник «Запросы к данным».

 

 

Каждый запрос, который вы здесь пишете, нацелен на выявление конкретного типа ошибок – незаполненные поля, нарушение бизнес-логики, несоответствия и т.п.

 

 

Можно делать запросы к любым объектам. Причем для составления таких запросов необязательно быть программистом, достаточно уметь пользоваться конструктором запросов.

 

 

Сначала создаются запросы, а потом в специальном рабочем месте отображаются результаты проверки: сколько найдено ошибок по каждой проверке, и какие объекты при этом затронуты.

Например, вы проверяете документы реализации – в этом рабочем месте будут выведены проблемные документы реализации. Вы их сможете из этого рабочего места открыть и исправить при необходимости.

Причем вы можете в запросе прописать логику заполнения для поля «Ответственный» и по каждой ошибке назначить ответственного.

В этом инструменте удобно, что все ошибки можно выводить в одном окне. Вам не нужно запускать десятки отчетов вручную и держать при этом в голове, что уже проверено, а что – нет.

Сотрудники ИТ-службы могут раз в неделю проверять проблемные места и рассылать пользователям уведомления. Это особенно актуально при запуске оперативного контура – когда в первые месяцы после внедрения ошибки в документах измеряются тысячами. Если их раз в неделю оперативно не исправлять, то мы просто не дойдем до закрытия периода никогда.

 

 

Еще здесь есть интерфейс взаимодействия. Пользователь может сказать, что исправил свои ошибки, и пометить их зеленым фоном. Вы это в режиме реального времени можете видеть.

 

 

Так как проверок обычно много, то при большом объеме данных они могут выполняться довольно долго. Мы сделали регламентное задание для того, чтобы система собирала данные, например, по ночам. Результаты сохраняются в системе.

 

 

Вы составляете расписание для запуска этого регламентного задания, и оно запускается – тогда, когда вам удобно, чтобы не нагружать базу.

 

 

Можно использовать параметры запроса – например, чтобы программа выбирала не все данные подряд, а в рамках определенного периода.

 

 

В запросе должен быть набор обязательных полей, чтобы вы видели, что это за ошибка и какой это объект:

  • ПроблемныйОбъект: ссылка на документ или справочник, в котором обнаружена проблема. Он будет выводиться в рабочее место для исправления

  • ИнформацияОбОшибке: произвольный текст с описанием ошибки

  • ВидОшибки: Значение перечисления – может быть «Ошибка»; «Предупреждение», «Оповещение».

  • И по желанию, Ответственный: если у вас есть необходимость распределять ошибки между ответственными, можете добавить.

 

Пример 1: Валютный договор без группы финансового учета

 

 

Приведу пример. Стандартная ситуация – человек завел договор в евро или в долларах, но не указал группу финансового учета.

С точки зрения программы это не критично – ей все равно, на каком счете учета вы будете учитывать суммы взаиморасчетов по валютным договорам. Это не такая проблема, которая не позволит вам закрыть период.

Вы спокойно запишете такой договор, у вас нормально закроется месяц – программа вам корректно посчитает и сумму в рублях, и значение курсовых разниц, потому что счета учета не влияют на работу блока взаиморасчетов, они влияют только на бухгалтерский учет.

 

 

Но курсовые разницы в проводках пойдут на 60-й счет – а бухгалтеров такая ситуация обычно шокирует.

 

 

Чтобы выявить эту проблему заранее, можно за две минуты написать запрос, который:

  • отбирает поступления, оформленные по валютным договорам, исключая те, у которых валюта – рубли (в рамках установленного периода);

  • проверяет, указана ли в этих договорах группа финансового учета;

  • возвращает список проблемных договоров с ответственными.

 

 

Вот так будет выглядеть закладка «Условия» в этом запросе.

 

 

Вот так – закладка «Дополнительно».

 

 

А вот так – закладка «Объединения/Псевдонимы».

 

 

Период вы сможете задать прямо в той форме, где выводятся сами ошибки, а здесь вы можете задать дополнительные параметры для этого запроса. Например, здесь я указываю, что нужно отобрать все договоры, оформленные в валюте, отличающейся от рубля.

 

 

Сохраняем этот отчет в списке проверок.

 

 

И в результате программа показывает нам список проблемных договоров и тех, кто за них отвечает – из этого списка при необходимости договор можно открыть и исправить.

 

Пример 2: нарушение логики взаиморасчетов из-за смены направления деятельности в договоре

 

 

Вторая ситуация намного более плохая для программы. И встречается очень часто. Человек при создании договора забыл в нем указать направление деятельности. Спустя какое-то время вспомнил об этом, но идти в ИТ-службу и рассказывать, что ошибся, не хочет.

 

 

Он решил исправить эту проблему вручную через кнопку «Еще» – «Разрешить редактирование реквизитов» и проигнорировал предупреждение системы о том, что хорошо подумать, прежде чем так делать.

 

Он заполнил это поле в договоре и записал изменения.

 

 

Обратите внимание: закрытие месяца никакой проблемы не диагностирует – оно считает, что вы знаете, что делаете.

 

 

Но если у вас на этом договоре была задолженность, и вы после этого проводите по нему списание безналичных денежных средств, программа воспринимает эту сумму как аванс.

 

 

Это можно увидеть только в оборотно-сальдовой ведомости при детализации по всем субсчетам и субконто.

Как видите, здесь все ожидаемо расползлось, потому что для программы задолженность без направления деятельности, и задолженность с направлением деятельности – это два разных объекта, друг с другом мало связанные. Эта оплата воспринимается программой как аванс, хотя мы реально что-то оплачиваем.

 

 

При этом во время закрытия месяца программа все так же будет показывать, что с взаиморасчетами все хорошо – они актуализированы.

 

 

Единственная возможность найти, что есть ошибка – это сформировать развернутую оборотно-сальдовую ведомость и пытаться найти, на каких счетах на конец периода есть сальдо и по дебету, и по кредиту.

 

 

Но возможность вовремя отследить эту проблему есть не всегда, поэтому пишем запрос для проверки.

 

 

Указываем в запросе такие поля и параметры:

  • проверяем данные в виртуальной таблице остатков по регистру «РасчетыСПоставщиками»;

  • и ставим условие, чтобы выводились записи регистра, где направление деятельности в объекте расчетов не совпадает с тем, что указано в договоре.

 

 

И в результате находим – и проблему и человека, который ее создал.

 

Возможные проверки для раздела учета «Производство»

 

Направления деятельности в заказе на производство. Нужно отслеживать документы «Заказ на производство», в которых не заполнено направление деятельности, потому что система это поле автоматически не заполняет.

Несоответствие материалов в ресурсной спецификации и в фактическом выпуске. Часто бывает, что в спецификации на вкладке «Материалы» задаются эталонные компоненты изделия, а в этапах производства пользователи вручную вносят другие позиции. Необходимо найти документы, в которых материалы в этапах не совпадают с материалами, прописанными в ресурсной спецификации.

Уточнение: в ряде производств замена материалов – это нормальная практика. Например, упаковка может закупаться из разных источников, для многих материалов допускается использование аналогов в зависимости от условий. Поэтому такую проверку нужно делать с учетом специфики: Где есть жёсткие спецификации – критично соблюдать точность; В гибких схемах – допустимы отклонения, но тоже желательно фиксировать их через формальные механизмы.

Стоимость побочной продукции превышает основную. Необходимо контролировать случаи, когда стоимость побочного выпуска превышает стоимость основного. Обычно это происходит, когда побочные продукты списываются «в нагрузку» на один документ, и система это «проглатывает». В результате получаем ошибки в себестоимости – она уходит в минус. Такие документы должны отслеживаться и проверяться.

Незакрытые заказы на производство. Часто возникает ситуация, когда все этапы по заказу завершены, но сам заказ не закрыт. Закрытие происходит только вручную, что создаёт риски.

Почему это критично:

  • Пока заказ не закрыт, затраты продолжают «висеть» в незавершёнке. Это мешает корректному распределению затрат и может привести к ошибочному учёту трудозатрат в следующих периодах (например, зарплата в мае упадёт на заказ, закрытый в апреле);

  • Пользователи часто не замечают открытый статус – потому что это не влияет напрямую на их работу, и контроль быстро «отмирает».

Решение: либо автоматическое закрытие заказа при завершении последнего этапа, либо оперативная проверка открытых заказов.

Работы по этапу выполнены, но этап не закрыт. Это особенно критично для предприятий, где используется отчетность в контролирующие органы по каждому этапу производства (например, для Меркурия, Россельхознадзора и др.). Типичная ситуация:

  • Сырьё (например, молоко) прошло переработку – из него получен полуфабрикат (например, сливки), он охлаждён и подготовлен к фасовке.

  • Но если этап переработки не закрыт, система считает, что молоко так и осталось непереработанным. В итоге не удаётся отчитаться перед контролирующими органами, и партия может быть забракована из-за формального нарушения (например, истек срок годности молока).

  • По этапе реально все выпущено. Но если он в статусе «начат», то на него ошибочно могут быть отнесены прямые затраты, потому что при отражении постатейных расходов система разрешает выбирать в качестве аналитики все открытые этапы. При закрытии периода такие расходы просто «зависнут».

Вывод: нужно настраивать своевременные оповещения о незавершённых этапах и отслеживать их закрытие.

 

Возможные проверки для оперативного контура

 

Прослеживаемость движения денежных средств. Необходимо отслеживать полный оборот: поступления, списания, возвраты и НДС.

Корректность заполнения документов. Требуется проверка договора, подразделения и наличия закрывающих документов.

Прослеживаемость товаров. Если в номенклатуре установлен признак прослеживаемости, но в документах по ней не заполнен РНПТ – это ошибка.

Комплектность операций интеркампани. До закрытия месяца важно убедиться, что все перемещения между организациями корректно отражены в учете.

 

Возможные проверки для раздела учета «Затраты»

 

Трудозатраты.

  • В первую очередь, необходимо обеспечить наличие расценок по всем видам операций, используемых в производстве.

  • Кроме этого, если после отражения зарплаты изменяются трудозатраты или выработка по этапам – программа не пересчитывает автоматически и не выдает предупреждений. Предлагается реализовать механизм раннего оповещения о несоответствии, до формирования себестоимости.

  • Также предлагается реализовать план-факт анализ: сравнение планируемых трудозатрат из спецификаций с фактическими, с контролем отклонений в разумных пределах (например, не более определённого процента).

Материальные затраты.

  • Нужна проверка на встречный выпуск – исключение ситуаций, когда номенклатура продукции и материала совпадает и появляется замкнутый цикл (одна и та же позиция в выпуске и потреблении).

  • Нужна проверка на сопоставление статей затрат из ресурсных спецификаций и фактически использованных – статьи в спецификациях должны соответствовать статьям в реальной калькуляции.

Прочие затраты.

  • Необходимо проверять, чтобы все обязательные аналитики (например, направления деятельности, проекты и т.п.) при вводе прочих затрат были указаны.

  • Необходимо контролировать, чтобы в прочих затратах не оставалось никаких расходов текущего периода.

Контроль облагаемых и необлагаемых операций по НДС.

Заполнение весогабаритных характеристик в номенклатуре. При использовании базы распределения по объему (например, в логистике или при расчете косвенных затрат) нужно обязательно проверять, заполнены ли весогабаритные характеристики у номенклатуры, и соответствуют ли они данным, используемым в расчетах. Отсутствие весогабаритных характеристик может привести к ошибкам распределения и дополнительным ручным доработкам.

 

Возможные проверки для раздела «Регламентированный учет»

 

Группа финансового учета (ГФУ). Нужно проверять:

  • заполнена ли ГФУ в карточке номенклатуры,

  • совпадает ли ГФУ с остатками по бухгалтерскому учету: бывает, что в качестве ГФУ указана, например, группа «Материалы», но товар числится на 41 счете. Такие расхождения могут привести к ошибкам в определении вида запасов – требуется ручная корректировка ГФУ и пересчет всех связанных документов.

Сравнение данных регламентированного и оперативного учета. Примеры:

  • Акт сверки по взаиморасчетам с контрагентами формируется с одной суммой, а в бухгалтерском счете отображается другая.

  • Остатки на 20, 23 счетах должны соответствовать остаткам на регистрах затрат по незавершенному производству (Прочие расходы НЗП, Трудозатраты НЗП, Себестоимость товаров, разделы «Производственные затраты», «Незавершенное производство»).

Контроль ручных корректировок. Требуется вывести перечень всех ручных операций и корректировок за период.

Все первичные документы должны быть отражены в учете. Нужна проверка, выводящая непроведенные и неотраженные в учете документы.

Автоматизируйте процесс проверки ведения учета в ПП в два клика

 

Выводы

 

Удобно, когда все нужные проверки включены в комплексное рабочее место для контроля учета. Это позволяет своевременно выявлять отклонения и минимизировать ручной труд в конце отчетного периода.

Для регулярного контроля корректности данных в информационной базе можно использовать расширение «Контрольные отчеты» – оно позволит вам реализовать такие проверки и видеть результаты в удобном виде.

P.S.: Во вложении к публикации вы можете скачать список из еще 59 идей для возможных проверок, автоматизация которых продлит жизнь ваших проектов.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.

См. также

Сопровождение Внедрение изменений Бесплатно (free)

Рост обращений в техподдержку, очереди, перегруженные сотрудники, задержки в ответах на простые вопросы — знакомые реалии для многих компаний. Традиционные решения (базы знаний, контекстные подсказки) часто не справляются с объемом или слишком дороги в разработке и поддержке. К счастью, современные большие языковые модели предлагают мощный инструмент для автоматизации этого пласта работы. Можно ли применить их к специфике платформы 1С? Давайте разберемся.

02.07.2025    785    0    Vaslot    1    

7

Внедрение изменений Россия Бесплатно (free)

Недавно появилась новость "SAP дал сбой. "Сегежа Групп" отсудила 430 млн за цифровую трансформацию - Рамблер/личные финансы”. Очень примечательная, поскольку позволяет на реальном примере увидеть изнанку консалтинга в больших бюджетах: только факты, без слухов, без NDA и неофициальной информации. Мне эта тема особенно близка, поскольку я имею опыт работы в двух мирах — 1С и SAP , “ел устриц” и на kick – off и на разных стадиях проекта. Поэтому пристегивайтесь, вас ждет увлекательный разбор судебного решения А40-299276-2022__20250120. Цель статьи не потоптаться на костях SAP в России, а показать сообществу 1С, что влияет на успех проекта на больших масштабах. И заодно ответить на вопрос — светит ли успех 1С в узком, но богатом сегменте больших корпораций.

30.06.2025    2261    0    1CUnlimited    58    

39

Внедрение изменений Бизнес-аналитик Руководитель проекта 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Даже при хорошем планировании внедрение 1С:ERP часто сопряжено с неожиданными трудностями — прежде всего, из-за перегрузки сотрудников и недооценки организационных рисков. Практические наблюдения о том, что важно предусмотреть заказчику заранее, чтобы проект не зашёл в тупик.

20.06.2025    912    0    Adapta    16    

7

Внедрение изменений Бесплатно (free)

Разберемся, чем отличаются конструкторская, технологическая и производственная спецификации – и почему их путаница приводит к ошибкам. Узнаем, какие бывают виды материалов в спецификациях и почему фраза «НСИ у нас в актуальном состоянии» не гарантирует готовности к работе. А также поразмышляем о том, на какие подводные камни стоит обратить внимание, чтобы избежать срывов сроков и переделок.

19.06.2025    864    0    VeraPikuren    1    

6

Оптимизация бизнес-процессов Проектирование бизнес-процессов Внедрение изменений 1С v8.3 1С:ERP. Управление холдингом Бесплатно (free)

Как создать систему планирования на реальном производстве с нуля, не используя готовые ERP-решения? В этой статье программист делится опытом внедрения собственной системы планирования в условиях крупного производства очистных сооружений. Рассказано о том, как начать с понимания процессов, спроектировать документ «Планирование производства», реализовать механизм распределения задач между бригадами и интегрировать всё с учётом материалов и выпуском продукции. Статья покажет, что даже в сложных условиях можно сделать простое и рабочее решение — без излишней автоматизации, но с фокусом на реальные потребности пользователей.

10.06.2025    758    0    KHoroshulinAV    6    

8

Внедрение изменений Бесплатно (free)

Внедрение ERP на базе 1С требует значительных аппаратных ресурсов и стабильной инфраструктуры, что не всегда доступно небольшим организациям. Одним из вариантов решения этой проблемы может стать облачный сервис 1С:Fresh, который позволяет развернуть ERP-систему без затрат на собственные серверы. Рассмотрим ключевые преимущества и сложности такого подхода, а также определим, каким компаниям облачное решение подойдет лучше, а кому стоит остаться на классическом варианте с локальным развертыванием.

09.06.2025    382    0    amenotori    0    

1

Внедрение изменений Реклама, PR и маркетинг Россия Бесплатно (free)

Нейросети стремительно проникают в маркетинг, но что это значит для 1С-компаний? В статье — 10 ключевых инсайтов из международного (американского) исследования STATE OF MARKETING AI REPORT 2025 и конкретные рекомендации, как можно использовать эти тренды в маркетинговой стратегии 1С-компании: от упаковки решений до построения HR-бренда.

06.06.2025    605    0    Adapta    0    

2

Взгляд со стороны Заказчика Внедрение изменений 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Так случилось, что на один из наших проектов внедрения «1С:ERP» мы пришли после другой команды, проект с которой заказчик завершать не пожелал. К нам предъявили жесткое требование...

27.05.2025    711    0    AiBCifra-1S-ERP-UH    2    

3
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. vadim1980 125 21.06.25 08:19 Сейчас в теме
Практика показала, что самым эффективным является "западный" подход, когда ИТ-специалисты конечного клиента выполняют функции первой линии поддержки + небольшие доработки (новые реквизиты, печатные формы, отчеты). Все остальные работы передаются подрядчику, которого можно при случае поменять
2. KhomE 21.06.25 21:29 Сейчас в теме
Извините, но кто же начинает внедрение с бухгалтерского блока?... Работала на двух крупных внедрениях (оборонное предприятие и химзавод), бух. Блок переезжал тогда, когда все остальное уже встало на колеса и стройно едет, упр учёт легче поправить чем бух учет перевести и пересдать в налоговую..
3. Brawler 461 22.06.25 12:48 Сейчас в теме
(2) все внедреняя, что я делал шли от бухни ибо именно бухня толкает всех и пугает штрафами, отсутствием премий и тд, дисциплинирует народ))) бухня ближе к директору и ему более очевиден результат внедрения
4. KhomE 22.06.25 13:39 Сейчас в теме
(3) поняла. В нашей ситуации после руководства прямого были ещё фин директора, управленцы от торговых участков и прочие, бухгалтерию звали в самом конце уже:) толкали всех руководители, бухгалтерия упиралась сильнее и активнее всех)
5. AlX0id 23.06.25 12:32 Сейчас в теме
(2)
Просто как правило сначала бухгалтерия - единственное подразделение:
- которое в курсе, как ведется учет,
- которое де-факто ведет учет.
Потому по многом им доводится в итоге контролировать результаты внедрения и делать это удобнее привычными для них инструментами (оборотка и т.п.).
6. dnikolaev 168 26.06.25 23:43 Сейчас в теме
Синдром Трампа - выходи и сам себя хвали.
Оставьте свое сообщение