Как не сойти с ума, закрывая месяц в ERP

У нас в компании команда in-house, около 20 1С-ников. Внутри мы делимся на команды по конфигурациям. Я в команде ERP и занимаюсь автоматизацией на ERP. Отдельная команда архитектуры работает со всеми конфигурациями и помогает нам оптимизировать работу.

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

Контекст проекта: масштабы и сложность

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

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

Что такое закрытие месяца?

Чтобы мы говорили на одном языке, разберемся, что такое закрытие месяца. Я спросила у ChatGPT, что такое закрытие месяца в принципе, и что такое закрытие месяца для бухгалтера, аналитика и собственника бизнеса.

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

• Для бухгалтера это процесс контроля – проверка данных до и после.

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

• Для собственника – принятие решений на основе полученной в результате закрытия информации.

• Для системы закрытие месяца – это обработка.

Теперь немного погрузимся в то, как это работает в ERP.

Как работает закрытие месяца в ERP

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

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

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

Ключевой фактор: экспертиза

Первое, о чем стоит сказать – волшебной таблетки нет. Главное, что нужно, чтобы не сойти с ума – это экспертиза.

Во-первых, экспертиза в самом программном продукте ERP. Система сложная, механизмы закрытия тоже. Есть особенность: все должно выполняться строго в определенном порядке. В «Бухгалтерии предприятия» можно пропустить какую-то операцию, и бухгалтер с функционалом прекрасно справится. В ERP пропустить ничего нельзя – если появляется ошибка, гарантии получения качественного результата дальше нет.

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

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

Пример экспертизы №1: Учет архитектуры при интеграциях

Первый пример, который хочу привести – это учет особенностей архитектуры при интеграциях.

У нас в компании мастер-системы – внутренние решения. Все команды in-house, IT-дочка, у каждой своя архитектура, а в ERP – своя и довольно сложная.

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

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

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

Пример экспертизы №2: Погружение в предметную область (аренда)

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

Многие сталкивались с ФСБУ 25. В 2022 году было сложно работать с арендой. У нас большие объемы – множество розничных точек и арендованных помещений, поэтому автоматизация этого процесса была необходима. В ERP аренда не была полностью автоматизирована, и нам нужно было разобраться, как она вообще работает: как ведется учет и какой результат нужно получить. Учет оказался достаточно сложным.

Далее нужно было автоматизировать процесс и учесть его при закрытии месяца. Мы сделали это, ориентируясь на обновления 1С: в версии 2.5.15 уже появился рабочий функционал по аренде. Да, нюансы были, но в нашем случае он подошел, и мы проявили экспертизу в том, что, не обновляясь, перенесли этот функционал из 2.5.15 в нашу 2.5.12.

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

Пример экспертизы №3: Расчет себестоимости

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

Рекомендации от команды архитектуры:

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

• Во-вторых, важно рассчитывать итоги – считать текущий месяц уже с учетом рассчитанных итогов по предыдущему.

Что касается результатов, на старте проекта расчет себестоимости занимал около 40 часов, сейчас – 14, при том, что объемы компании растут, а скорость расчета увеличивается.

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

Гибкое закрытие

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

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

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

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

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

Ускорение через APM и удобные рабочие места

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

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

Ускорение через вынос части операций в микросервисы и распознавание

У нас НДС вынесен в отдельную базу. Он рассчитывается в ERP, но все дальнейшие операции с книгами выполняются отдельно. Благодаря этому в пиковые периоды собрать декларацию для бухгалтерии не составляет проблемы – все работает быстро и стабильно, потому что вынесено в отдельный функционал. Рекомендую крупные блоки не оставлять в монолите.

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

Ускорение через взаимодействие с бизнесом

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

Закрытие начинается задолго до обработки и выходит за рамки системы. От того, как мы общаемся и доносим информацию, многое зависит. Чтобы закрываться быстро, важно соблюдать установленные сроки и дедлайны.

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

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

Контрольные точки: чек-листы и проверки

Следующее, про что хотелось бы рассказать, это контрольные точки.

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

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

Как понять, что мы хорошо закрылись? Закрыты затратные счета, закрыты 90-й и 91-й, посчитан налог на прибыль, нет отклонений. Это можно проверить. Но есть и множество других пунктов, которые могут появляться в зависимости от особенностей компании.

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

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

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

Ретроспектива и база знаний

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

Чек-лист 1С не менялся уже около полугода, только немного корректировался. А чек-лист бухгалтерии, наоборот, регулярно обновляется, выстраивается, в него вносятся изменения.

Проверки ведутся отдельно – у нас есть обработка со списком проверок, куда мы постоянно добавляем новые пункты: что нужно посмотреть, что учесть, с чем могли столкнуться и что могло пойти не так. Так мы дополняем первые два пункта – чек-лист и проверки.

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

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

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

Подведем итоги

Волшебной таблетки нет, но есть список того, что поможет сделать следующее закрытие лучше предыдущего:

• Иметь экспертизу, гибкость и опыт – без этого никак. Закрытие месяца в ERP – это не процесс, который можно провести по щелчку пальцев, если только компания не совсем простая.

• Общаться с бизнесом. Коммуникации важны: нужно не только доносить информацию, но и слышать.

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

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

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

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

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