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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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