От Хозрасчета к ЕПСБУ⁠⁠

Введение

Есть указ президента Российской Федерации «О реорганизации некоторых федеральных государственных унитарных предприятий и внесении изменений в перечень стратегических предприятий и стратегических акционерных обществ».

Что он означает с точки зрения автоматизации учета? Все очень просто: раньше предприятие вело учет в рамках хозрасчетного (коммерческого) плана счетов, теперь оно должно отчитываться перед государством в рамках ЕПСБУ (государственного плана счетов).

Исполнение данного указа президента неизбежно влечет за собой модернизацию цифрового контура в части управленческой информационной системы. Иными словами ERP (а кое-где и УПП) должна быть модернизирована (заменена или дополнена другими программными продуктами).

Контракт на подобный комплекс мероприятий получила наша компания...

Исходные данные

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

Технологический стек — платформа 1С и пять здоровенными баз УПП к ней.

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

Задача – привести управленческий учет к стандартам ЕПСБУ, то есть стандартам единого государственного плана счетов.

Перед участием в конкурсе

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

Потенциально возможные варианты реализации:

1. Попытаться реализовать в УПП (на обычных формах!) стандарты ЕПСБУ. Если говорить проще, то взять 1С:Бухгалтерия государственного учреждения 2 (1С:БГУ 2) и попытаться передрать оттуда и адаптировать целевой функционал. Туда же докинуть то, что требуется из 1С:Зарплата и кадры государственного учреждения 3 (1С:ЗКГУ 3) – здесь существенно меньше.

2. Перевести заказчика на ERP 2, заимствуя все необходимое из тех же 1С:БГУ 2 и 1С:ЗКГУ 3.

3. Написать нечто напоминающее интеграционную шину, которая будет обмениваться учетными данными с 1С:БГУ 2 и 1С:ЗКГУ 3. Последние две конфигурации в рамках такой схемы, очевидно, еще нужно внедрить.

4. Дописать производственный блок и все остальное в рамках 1С:БГУ 2 и перевести заказчика на 1С:БГУ 2 и 1С:ЗКГУ 3.

Первые два варианта кажутся наименее рабочими. Почему?

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

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

• Объем работы представляется наиболее масштабным по сравнению с остальными вариантами. По крайней мере на текущий момент...

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

Таким образом, остаются варианты 3 и 4. На мой взгляд, наиболее привлекательным является третий вариант. Его единственная, но серьезная уязвимость — большое количество обменов. В рамках этого варианта мы получим набор программных продуктов, непрерывно обменивающихся данными: 1С: УПП — 1С: БГУ 2, 1С: УПП — 1С: ЗКГУ 3, 1С: БГУ 2 — 1С: ЗКГУ 3. Заказчики обычно относятся скептически к таким сложным и тонким обменам.

Четвертый вариант уступает третьему практически всем, за исключением обменов. Здесь он только один – стандартный (ну или почти стандартный в нашем случае) обмен между 1С:БГУ 2 и 1С:ЗКГУ 3.

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

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

К чему это все?

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

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