Необходимость реализации единой учетной системы назревала давно. Активная фаза планирования и подготовки началась в июле 2014 года.
Постоянными участниками проекта были представители Департамента бухгалтерского учета (ДБУ), Финансовой дирекции (ФД) и (конечно же... фанфары, шарики и конфетти...) Департамента информационных технологий (ДИТ).
Основные задачи участников:
- ДБУ - слушать, спрашивать, беспокоиться и понять "как же дальше жить" с точки зрения ведений бухгалтерского учета; получить представление о том, что нужно сделать/подготовить для реализации проекта, а также как все это сделать;
- ФД - формально - это флагман по организации ВСЕГО учета, поэтому в задачи входило все что касается переноса учета (не в последнюю очередь управленческого), "перенос" бизнес-процессов на новые рельсы, курирование проекта;
- ДИТ (фанфары, шарики и конфетти... ну вы в курсе) - оценка, конусльтирование, планирование всего, что касается инфраструктуры, учета (с точки зрения ведения его в системах 1С) существовавших и "перспективных" учетных систем, ну и, само собой, требуемой разработки;
Что мы имели в начале проекта?
- холдинг, в котором 50+ юридических лиц с различными видмами деятельности (услуги, торговля) и системами налогообложения;
- 50+ отдельных учетных систем бухгалтерии (70% БП3.0; 15% БП 2.0; 5% Аренда на БП 3.0);
- различия в подходах ведения учета и НСИ в различных системах бухгалтерии
- единая для всех юр. лиц учетная система управленческого учета (бюджетирование, казначейство) - собственная разработка на базе типовой БП;
- "разрыв" между бухгалтерским и управленческим учетом, невозможность автоматизации консолидированной отчетности;
- необходимость поддержки 50+ систем 1С;
Вот она, рыба моей мечты!
Изначально под основу для единой учетной системы рассматривались:
- УПП 1.3 - с точки срезния ведения бухгалетрского учета вопросов не было, но сравнивая наработки собственной управленческой системы пришли к выводу, что потребуется слишком много ресурсов для переноса и "заточки под себя"; кроме того, блок производства будет просто балластом (переплачивать, понятно, не хотели);
- ERP 2.0 - опять же, нет вопросов к бухгалтерии; как система для управленческого учета по ряду причин подходила больше, но опять же потребовала бы доработки; производство также было лишним;
- КА - бухгалтерский учет подходил; требовала доработки "под себя", но были озвучены положительные отзывы по использованию в качестве подобной единой системы со стороны участников проекта; первоначально данный вариант лидировал в качестве основы для дальнейшей работы;
Для сторонней оценки проекта, да и в целом как вполне возможный (не наиболее вероятный) вариант его реализации были привлечены сторонние компании, специализирующиеся на проектах внедрения учетных систем на платформе 1С. От привлечения сторонних компаний в итоге отказались в первую очередь из-за не устроившей оценочной стоимости проекта. Надо сказать, что факт отказа от привлечения сторонних компаний не добавил оптимизма внутренним участникам проекта ("говорите за себя, вы - ленивые тыжпрограммисты", сказали бы нам ДБУ и ФД), т.к. перспектива быть не просто неблагодарными зрителями, а самыми что ни на есть активными участниками, слегка пугала удручала.
Но общение со сторонними разработчиками не прошло для нас зря. Нам пытались впендюрить Нам предложили совершенно инновационную, доселе невиданную и, на тот момент не вышедшую даже в виде бета-релиза конфгурацию Управление холдингом. Система позволяет полноценно вести бухгалтерский и управленческий учет практически из коробки - а это то, что нам было нужно. Описывать функционал системы не будем. Важно, что мы выбрали именно ее, хотя и с намерением доработать "под себя".
Первые "кирпичи".
Первая сложность, с которой мы столкнулись - системы Управление Холдингом еще не было, пощупать, покрутить нечего, в наличии только презентация и надежда на светлое будущее. Существенным допущением, было то, что бета-релиз должен был на тот момент выйти через пару месяцев, а рабочий релиз только к концу года (2014). Впрочем, это не помешало бы уволить всех к чертям в случае провала. Поэтому на тот момент основные усилия были направлены на подготовку и планирование объединения данных нескольких десятков несвязанных между собой бухгалтерских систем.
В итоге первый бета-релиз мы получили только через пару месяцев, а первый рабочий релиз вышел еще через 3-4 месяца. Тестовый перевод баз нескольких организаций на бета-релиз УХ заставил понервничать (описание логики перевода приведено ниже), т.к. при "накатывании" новой конфигурации на базу выдавались критичные ошибки, связанные с измененными владельцами справочника "Банковские счета" - формально владельцы не изменились, но, видимо, из-за отличия внутренних идентификаторов метаданных система валилась в ошибки. Хоть на тот момент проблему решили (танцы с бубном, выгрузки/загрузки и т.д.), она не воспроизвелась в первом рабочем релизе, поэтому достаточно гладко отработала схема перехода.
Следующим интересным моментом, который предстояло решить - как модифицировать большую систему, и при этом регулярно и с минимальными трудозатратами ее обновлять на официальные релизы. На помощь, сама того не подозревая, пришла компания 1С, вовремя анонсировавшая Расширения! Опять же решение об их использовании было принято и утверждено ДО публикации релиза платформы с данным функционалом - это второе существенное ограничение по проекту ("ну, теперь точно уволят", подумали мы). Время ожидания нужного релиза платформы, которое к слову составило около 3 месяцев, было потрачено на поиск вариантов доработки типовой конфигурации с минимальным изменением самого типового функционала (для обеспечения простоты дальнейшей поддержки всей системы). Основные принципы, которые используются:
- подписки (спасибо кэп);
- по максимуму консолидация "добавленного" кода в свои общие модули;
- отчеты/обработки/регламентные задания через "Дополнительные отчеты и обработки" БСП;
- при необходимости добавления реквизитов к типовым объектам - хранение значений в регистрах сведений и программный вывод соответствующих элементов в формы через Расширения;
- использовать префиксы для новых объектов, комментировать код;
Безусловно, совсем без доработки типового функционала порой не обойтись. Главное сделать это не только верно с точки зрения работоспособности, но и с точки зрения дальнейшей поддержки.
Сибирский цирюльник. (Н.С. Михалков All Rights Reserved)
Волевым решением постановили, что данные бухгалтерии в новую базу будут переноситься в виде сальдо на начало 2015 года плюс обороты, которые уже успели внести в систему. Т.о. отсекаем лишние данные, учетные косяки прошлых периодов, уменьшаем объем самих данных и без того потенциально громоздкой системы.
Как привести в порядок НСИ? Это надо начинать делать еще в "старых" системах. После слияния данных нескольких баз мы получим дубли почти в каждом справочнике системы. И если в ряде случае ну и хрен бы сним для дальнейшего ведения учета это не имело значения, то в большинстве своем представляло проблему: бардак и дубли по валютам, контрагентам, физлицам, статьям, номенклатуре и т.д. и т.п.. Задача вполне решаема (обработок куча, в т.ч. и типовые), но при условии, что для свертки дублей в данных будут уникальные признаки, по которым эти самые дубли можно идентифицировать и свернуть. Однако, здравствуйте зачастую бухгалтер "в своей зоне ответственности" ведет учет так, как считает правильным. Именно это мы имели на тот момент - массивы "не причесанных" данных. По этому поводу в ДБУ улетела задача "Причесать!". Забегая вперед скажу, что расческа у них была не очень, многое ковыряли по факту.
Примером решения для свертки, которую мы планировали, является то, что за эталон справочника Контрагенты был взят набор данных с заполненными реквизитами ИНН/КПП старой управленческой системы, т.к. операции казначейства охватывали все юр.лица, соответственно информация о плательщиках/получателях там была наиболее полной. Перенос в итоговую систему справочника д.б. выполнен в период первичной подготовки "новой системы" до загрузки бухгалтерских данных. Т.о. после заливки данных бухгалтерии мы могли по контрагентам сразу свернуться на эталонные записи. Все эталоны были предварительно промаркированы спец. тэгом в реквизите доп. информации.
По большинству данных при свертке используется стандартный принцип "на кого больше ссылок, тот и крут";
Мы предполагаем, а...
Общий план работ был примерно следующий:
1. Этап - данные бухгалтерии:
- ДБУ к концу года максимально оперативно закрывает год по юр. лицам (в итоге небольшая часть организаций с малым оборотом была закрыты еще в декабре 2014);
- готовые базы юр.лиц передаются в ДИТ для переноса в новую систему;
- на период переноса работа в этих базах блокируется;
- после переноса данных в новую систему любые изменения закрытого периода по организации ДБУ переносит вручную в виде корректировки операций ввода начальных остатков;
- т.к. баз много, текущая работа должна по максимуму продолжаться , а рук для работы по проекту мало, был расписан итерационный план. В каждой итерации, рассчитанной на неделю, определялось и учитывалось:
- в какие даты уже не нового 2015 года какие организации будут переноситься;
- какое количество этих организаций с учетом специфики учета и объема данных можно перенести за одну итерацию;
- какой минимальный набор технических операции необходимо выполнить, чтобы по перенесенным данным можно было продолжить работу уже в новой системе (н-ер, уже упомянутая выше свертка данных);
- параллельно готовить функционал, необходимый для целей управленческого учета;
2. Этап - управленческий учет:
- переход от "старой" управленческой системы к новой;
- перенос необходимых первичных данных НСИ;
- оперативная корректировка данных/функционала;
3. Этап - поддержка:
- обеспечение параллельной работы ДБУ и ФД;
- по необходимости дальнейшее причесывание данных;
Поехали!!!
В УХе в качестве подсистемы бухгалтерского учета используется БП КОРП, поэтому, как многие уже и без нас догадались, чтобы перенести данные бухгалтерии в УХо нам потребовалось:
- обеспечении соответствия релиза бухгалтерской системы и релиза подсистемы БП в УХе;
- "накатить" на бухгалтерскую систему конфигурацию УХа;
- выполнить минимальный набор технических операций;
- перенести данные через стандартную "Выгрузку/Загрузку данных XML между идентичными конфигурациями" в новую единую систему;
Как было отмечено выше, на период переноса работа в базах соответствующих организаций полностью блокировалась. При этом мы не могли блокировать работу в тех организациях, которые уже успели к этому моменту перенести. Как мы выполняли первичную обработку данных с минимальным временем блокировки рабочей базы:
- по вышеописанной схеме готовились файлы выгрузок по очередной порции организаций;
- затем снималась полная копия рабочей базы, в которую заливались файлы выгрузок и выполнялись технические операции (свертки, сверки, догрузки и т.д.) - данный этап проводился максимально оперативно, чтобы минимизировать "разрыв" между копией и рабочей базой;
- после окончания технических операций готовились файлы выгрузок (только уже по обработанным/свернутым данным);
- теперь-то (никуда не денешься), блокируется рабочая база, и заливаются итоговые данные - данная операция зачастую выполнялась во внерабочее время, поэтому формально общее время простоя рабочей базы было минимальным;
- по результатам сверки данных со стороны ДБУ выполнялись дополнительные корректировки данных;
Конечно, приходилось так же учитывать и различие между конфигурациями БП исходных систем и БП КОРП в УХе. В основном это массовое дозаполнение реквизитов и аналитик учета.
Не подведу - сказал прораб народу, и не подвел, ни свет, ни газ, не воду!!!
Описанные выше планы в итоге были выдержаны практический без изменений. Узкие места, существенные риски и внештатные ситуации были героически преодолены. Общая продолжительность переноса данных составила 3 месяца. Необходимо учитывать, что работы по проекту выполнялись параллельно с обеспечением всей текущей поддержки прочих систем.
В период реализации переносов действовал условный мораторий на разработку крупного дополнительного функционала и серьезных изменений. Однако, были успешно выполнены работы по переносу и частичной разработке "с нуля" функционала из старой управленческой системы в новую в том числе и с использованием Расширений.
На текущий момент система уже давно вышла из стадии постпроектной проработки, и перешла в стадию полноценного рабочего режима. Можно с уверенностью сказать, что подходы к поддержке 50+ отдельных бухгалтерских систем и 1 общей с 50+ организациями существенно различаются. Да и ресурсы требуютсся немного другие, но это уже скорее другая тема.
Спасибо, что ознакомились с нашим опытом. Готовы внести уточнения или более подробно раскрыть моменты, которые будут интересны.
