Централизация бухгалтерии в холдинге

Конкретно, что дано.

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

Различия технические.

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

Например, при централизации бухгалтерского учета Холдинга А были: 1С: Бухгалтерия Птицефабрики,   1С: УПП, Бухгалтерия предприятия, Управление торговлей, Бухгалтерия 7.7 и вездесущие таблицы Ексель, в которых велось все, что не помещалось в 1С.

Такое разнообразие объяснялось различными видами деятельности предприятий, входящих в холдинг:

• инкубация и выращивание птицы;
• производство продуктов питания из мяса птицы;
• производство яйца;
• производство комбикормов;
• выращивание с/х продукции;
• оптовая и розничная торговля собственной продукцией.

Кроме того, существующие системы обменивались данными с 1С:ERP (оперативный учет производства), 1С:Управление торговлей (розница), БИТ-финанс,  зарплатными системами и др.

Деятельность Холдинга В была гораздо более однородная, тем не менее в проекте централизации участвовали 1С: Бухгалтерия 7.7 и 1С: УПП.

Методологические.

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

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

В нашем случае помимо «исторических» причин присутствовали совершенно оправданные, например, разные ставки налога на прибыль из-за различных видов деятельности, применение ЕСХН в ряде организаций и прочие.

Административные.

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

Так, филиалы Холдинга А находились в 6 регионах России. А филиалы Холдинга В – в семи. При этом необходимо учесть, что проекты делались в «доковидную эпоху», когда встречи по скайпу и онлайн конференции были еще экзотическими видами связи.

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

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

Что с этим можно сделать. Варианты решения.

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

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

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

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

При централизации бухгалтерии в Холдинге А был выбран вариант с единой базой для всех.

По пути ведения учета в разных базах и слияния данных пошли при централизации бухгалтерского учета в Холдинге В.

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

Выбор программного продукта.

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

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

Сохраним функциональность для всех-всех-всех – потеряем в деньгах на доработках и во времени/деньгах на обновлении полученного монстра.

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

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

В случае Холдинга А была выбрана – Бухгалтерия сельскохозяйственного предприятия.

Да, те, кто переходил с 1С:УПП (производство комбикормов),  потеряли ряд функций.

Да, те, кто переходил с 1С:Бухгалтерия птицефабрики, также лишились ряда удобных специфичных документов.

Да, в ходе проекта часть функционала пришлось заново кодировать в 1С:БСХП.

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

Методология учета.

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

Централизация подразумевает единые нормы и методологии учета. Продолжать вести учет «по-своему», но в общей куче? А зачем? С таким же успехом можно было оставаться в своих программах, не теряя привычной функциональности.

Отдельной большой задачей является синхронизации и централизация НСИ.

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

Например, при объединении филиалов Холдинга В был разработан помощник, который находил дубли в наименовании номенклатуры методом триангулярного поиска. Это был 2007 год и подобных обработок в типовых конфигурациях  не было.

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

Сложность при централизации данных справочников заключается в том, что они в известной степени определяются учетной политикой организации. Например, состав статей затрат зависит от того, применяется ли ПБУ 18 (различные статьи для принимаемых и непринимаемых по НУ затрат).

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

А теперь плавно подходим к вариативности бухгалтерского учета.

Спецодежда могла списываться линейно, а могла передаваться сразу. Учет ТМЦ мог вестись по средней, а мог по ФИФО. Общехозяйственные расходы могли входить в стоимость себестоимости, а могли списываться сразу на расходы и т.д. и т.п.

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

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

Сложности в процессе.

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

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

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

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

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

Прочие сложные моменты (выбор структуры, выбор ПП, обеспечение единых НСИ, норм и методик) были описаны выше.

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

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

Чаще всего обменные процессы приходится выстраивать заново. И главное – не забыть об этом в пылу объединения.

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

Полученные эффекты.

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

Здесь хочется привести отзыв от сотрудника Холдинга А:

В результате реализации проекта Заказчик получил:

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

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

Полученное решение легко масштабируется на предприятия холдинга. И кроме этого произошла минимизация количества ресурсов на администрирование:

Сокращены затраты на обслуживание информационных баз

Унифицированы бизнес - процессы и ведение нормативно – справочной информации

Сокращен нетиповой функционал, при этом учитывается специфика деятельности.

Итого.

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

Каким именно будет ваш переезд, по какому пути решения конфликтов пойди. Через поиск компромиссов, через управление «жесткой рукой» — это только ваш выбор. Успеха можно достичь и в том, и в другом случае.

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

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

Удачи!