gifts2017

Реализация единой учетной системы холдинга (или "Как мы спасали мир")

Опубликовал Сергей Лосников (Lars Ulrich) в раздел Управление - Управление проектом

Проект по переходу с одной учетной системы на другую даже для небольших организаций - достаточно серьезное событие. А как реализовать такой проект для холдинга (50+ юр. лиц)? Про наш опыт проведения именно такого проекта мы и попытаемся Вам рассказать. Детально описать в подобной статье всю реализацию проекта невозможно. Углубляться в технические дебри тоже не хочется, поэтому приводится общее описание проекта "в прозе". Главное, что есть чем поделиться с теми, кто хотел бы узнать общую логику реализации подобного проекта.

Необходимость реализации единой учетной системы назревала давно. Активная фаза планирования и подготовки началась в июле 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+ организациями существенно различаются. Да и ресурсы требуютсся немного другие, но это уже скорее другая тема.


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


См. также

Вознаграждение за ответ
Сумма: 0 $m
Добавили:
Павел Бабинцев (p_tj) (10.00 $m)
Подписаться Добавить вознаграждение

Комментарии

1. Andrey Moskvin (mmoozzgg) 19.10.15 08:55
Познавательно. А сколько "1Сников" участвовало в проекте?
2. Михаил (ILM) 19.10.15 10:12
Можно было после загрузки каждой базы БУХ Корп основные НСИ такие как классификаторы и справочники, поправлять обработкой и грузить следующие. Разные юрлица позволяли бы разделить сразу остатки и временно их не трогать.
3. Илья Козлов (Dem1urg) 19.10.15 12:35
Насколько вообще "стабильна" УХ? Много ли ошибок в "типовом" функционале?
Сами к ней присматриваемся, но пока "боязно" запускать такое в промышленную эксплуатацию.
4. Сергей Лосников (Lars Ulrich) 20.10.15 15:42
(1) mmoozzgg, в проекте участвовало три 1Сника, у каждого из которых была некая "специализация" по реализуемым задачам:
- курирование блока БУ;
- курирование блока УУ;
- ПМ нахлебник;

(2) ILM, да, все верно - эта схема вполне применима, но мы руководствовались следующими соображениями:
- пока ДИТ готовит очередную порцию данных для переноса, ДБУ продолжает работать с уже перенесенными данными (создавать документы, записи справочников), увеличивая объемы последующей "чистки". Нам показалось проще сделать такую предварительную "чистку" по всем возможным данным сразу, т.к. и объемы меньше, и управлять ими в тот момент проще, т.к. мы (ДИТ) имеем к ним неограниченный монопольный доступ до момента загрузки в рабочую базу.
- в рамках предварительных тестовых переносов наша инфраструктура (не будет углубляться, что именно было причиной: платформа, сервера и т.д.) не позволила нам выполнить работу по схеме "сначала все переносим, потом все чистим" - при удалении дублирующихся элементов (читай замене ссылок на эталон) мы неизменно получали крах системы.

(3) Dem1urg, в целом надо сказать, что система достаточно стабильна. В первых релизах действительно сталкивались со сложностями, но либо самостоятельно находили решения/пути обхода до выхода нового релиза, либо получали информацию об устранении ошибок от службы поддержки.
Оговорюсь, что мы пока не на 100% используем функционал системы, но используемые блоки, как уже отметил, стабильны.
5. Кузьмич (Кузьмич) 21.10.15 09:41
Это была реклама конфигурации УХ?
6. Кузьмич (Кузьмич) 21.10.15 09:46
От привлечения сторонних компаний в итоге отказались в первую очередь из-за не устроившей оценочной стоимости проекта

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

Более важно качество работ аутсорса. В 80% случаев (то бишь качество франчайзи) это именно "попадалово на деньги".
7. Павел Бабинцев (p_tj) 21.10.15 10:04
Класс!
Легко и интересно читать, ёмко изложено.
Спасибо, автор!
8. Сергей Пшеничников (Зеленоград) 21.10.15 10:58
Молодцы. Теперь расказывайте статистику ошибок в данных, в программе, различия между плановыми и фактическими трудозатратами.
9. Сергей Пшеничников (Зеленоград) 21.10.15 11:00
Вариант "Сначала синхронизировать и дополнить ключевую НСИ" не применялся? Почему? Это можно было запустить вторым этапом - параллельно в основной работтой пользователей, заодно приучая их к работе в общей БД.
10. Alexey (zarius) 21.10.15 11:53
С точки зрения логичности, прозрачности, стандартности, поддержки и прочее - объединение всех фирм холдинга в одной базе - вопрос нужный и необходимый. Но есть минус, который зачастую сводит на нет все преимущества - когда БД одна, при изъятии соответствующими органами, в их руки попадает цельная картина всего что в холдинге происходит.
11. Игорь Дзеса (Kamikadze) 21.10.15 16:59
Какое количество пользователей одномоментно работает в системе? Проводился ли анализ производительности?
12. Игорь Дзеса (Kamikadze) 21.10.15 17:00
И еще, как вообще конфигурация себе показала с точки зрения формирования отчетности для руководства?
13. Света Смолина (sveta66rss) 22.10.15 08:54
Возможна выгрузка данных для анализа из всех конфигураций? из 7 торговли, 8,2 бух, зуп?
14. Света Смолина (sveta66rss) 22.10.15 08:55
Как часто происходит обновление?
15. Сергей Лосников (Lars Ulrich) 22.10.15 11:08
(5) Кузьмич, если это выглядит как реклама УХ, то подумаем о выставлении счета 1С :)

(6) Кузьмич, условно сравнивая оценочную стоимость проекта со стороны франча и общую сумму затрат по ЗП внутренних участнико проекта за 12 месяцев, получаем положительную разницу минимум в 2 раза. Временные затраты сравнить сложнее, т.к. условия реализации внешнего подрядчика и внутренних исполнителей разные: первые погружены только в проект, вторые параллельно ведут текучку. Так же, возможно, франч и уложился бы в озвученные сроки, но как показывала моя личная практика, озвученное время можно смело умножать на 1.5-2.

(8) Зеленоград, подумаем про статистику :)

(9) Зеленоград, не совсем понял.. речь идет об унификации НСИ еще в исходных базах? если так, то мы не стали этого делать по двум причинам:
- ковырять данные старых баз, где содержались данные БУ за несколько лет не решились, т.к. по ним должны были формировать годовую отчетность, плюс они своего рода эталонные, пусть и проблемные и даже кое где с "хвостами" в учете. В нашей схеме мы имели возможность обратиться к ним и либо что-то восстановить, либо убедиться в корректности переноса данных в общую базу.
- учитывая количество баз мы прикинули, что затратили бы много больше времени на разработку, реализацию и выполнение предварительной унификации НСИ по ним.

(10) zarius, этот минус, исключительно чисто гипотетически, можно решить арендой инфраструктуры и выводом БД за пределы длины рук органов ;)

(11) Kamikadze, количество сеансов не большое - порядка 200. Ни визуально, ни по встроенным замерам APDEX проблем с производительностью нет.

(12) Kamikadze, все довольны :)

(13) sveta66rss, функционал по обменам с внешними системами действительно есть: 7.7, 8.0, 8.1, 8.2, 8.3, ADO. Конфигурация в данном случае вторична, т.к. отражение данных настраивается.

(14) sveta66rss, обновления выходят обычно раз в месяц, реже два.
16. Alexey (zarius) 22.10.15 13:44
(15)
Выносить БД в облако - реально для небольшой организации с небольшой активностью.
Вот в Вашем случае реально было бы увести эту БД в облако?
17. Андрей Оспичев (andrey3d) 22.10.15 18:18
1. Какой релиз УХ в итоге использовали ( бета, 1.0, 1.1 )? По описанию не совсем понятно.
2. Перенос управленческого учета в УХ? А что в проекте считалось управленческим учетом?
3. Функционал "Консодидации" в УХ задействовали?
18. Александр Крынецкий (echo77) 24.10.15 16:44
Не пойму какого черта ДИТ все планировал за всех? Решение о том какую учетную политику вести, как вести справочники тоже ДИТ предлагал?
Кто же выносил предложения и решал какая новая система должна быть?

Я спрашиваю не просто так, нам предстоит объединить две немаленькие организации в результате слияния юр.лиц.
19. Сергей Лосников (Lars Ulrich) 24.10.15 18:59
(16) zarius, скажем так - смею утверждать, что это вполне реально :)

(17) andrey3d,
1. рабочая система прошла все официальные релизы от 1.0 (на нем и стартовали) до 1.1. Бету использовали для первичного ознакомления и тестов.
2. под УУ понимались подсистемы бюджетирования, казначейства и финансовой отчетности (от внутренней до в перспективе МСФО).
3. "внешних" систем пока нет, поэтому функционал не задействовали.

(18) echo77, не совсем так. ДИТ не планировал все за всех, и тем более не определял учетную политику. Характеристики и параметры учета определялись профильными подразделениями. ДИТ перекладывал "хотелки" на рельсы систем 1С.
Например: ФД говорит: "Необходимо, чтобы в новой системе можно было заводить помесячные бюджеты в рамках Проектов и ЦФО"; ДИТ гладит шнурки представляет системы, которые позволяют это сделать, при этом уточняется: с доработками или без, какие ресурсы нужны для реализации и т.д.
Итоговое решение об использовании системы у нас принималось рабочей группой проекта, в которую входили представители всех участников.
20. Aleksey (HitGroove) 26.10.15 10:23
Ни какой конкретики... 50+, 3 месяца... Ни одного слова о количестве работающих пользователей, планировании вычислительных мощностей. Как то не понятно когда закончили, если первые расширения вышли 29.04.15. Сколько человек принимало участие в проекте, сколько программистов, сколько представителей заказчика, какой бюджет проекта, по какой методике велась разработка/доработка, как осуществлялся контроль за выполнением работ. Коль уж "В прозе" тогда надо было бы начать: "Звездное небо медленно качалось над мной, ДБУ что то бормотал рядом, а мои мысли выраженные в переживаниях о скором переходе на новую программу не давали покоя."))
21. Дмитрий Макаров (pro-rok) 09.11.15 07:55
Отличная статья, кратко и информативно.
Есть пара вопросов, была ли рабочая документация по проекту (интересно что в себя включала) или вы этим не заморачивались. И если не секрет сколько франч попросил за подобную работу?
22. Сергей Лосников (Lars Ulrich) 10.11.15 11:01
(20) HitGroove, поработаю над стилем ))

(21) pro-rok, из документации были первичная презентация на тему "как есть и как будет", общий план проекта, детальные поквартальные планы и всякая мелочь, которая в большинстве "размазана" по почтовой переписке. Думаю, можно сказать, что с документацией не заморачивались. По стоимости оценка была около 10 млн. руб.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа