Наверх

Реструктуризация и поглощения компаний и объединение корпоративного контента

Время чтения: 6 минут
2
Реструктуризация и поглощения компаний и объединение корпоративного контента

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

Хадиева Юлия, бизнес-аналитик отдела консалтинга и внедрения компания «МайТэк», генеральный партнер DIRECTUM

Динамичность бизнеса в условиях современной экономики зачастую требует реструктуризации организации. При объединении компаний часто возникает потребность в совмещении бизнес-процессов параллельно работающих СЭД.

И хотя задача технически не простая, и даже, откровенно говоря, немного пугающая, — всё реализуемо!

В этой статье я на личном опыте ведения проектов в «МайТэк» покажу, как без ущерба для пользователей (что самое главное), остановки бизнес-процессов и с оптимальным использованием ресурсов объединить работу СЭД DIRECTUM двух компаний.

«Не так страшен…», или План – уже половина успеха

С чего начать, когда заказчик приходит с конкретной задачей – объединить две СЭД? Мы начали с плана. План был представлен в двух форматах.

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

До составления плана были выполнены следующие этапы:

1.      Первичный аудит, после этого был выбран вариант объединения баз посредством пополнения большей базы данными меньшей;

2.      Экспресс-анализ компонент меньшей из баз для определения основных этапов и видов работ;

3.      Исследование наличия дублирующих компонент (полных дублей базовых справочников системы: «Организации», «Работники», «Пользователи» и т.д., идентичных компонент, имеющих разное наполнение и т.д.);

В итоге родился скелет плана с последовательностью действий.

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

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

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

«Примерка» плана

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

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

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

На старт, внимание, марш…

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

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

Наступила следующая фаза — перенос на тестовую базу Заказчика. Провели комплексное тестирование: сначала сами, затем подключили заказчика, с трепетом ожидая обратной связи. К обоюдному удовольствию, внешний тест прошел без единого нарекания.

Финишная прямая

Проделанные ранее итерации переноса были повторены на рабочей базе. К элементам разработки основной (большей) базы были добавлены компоненты базы упраздняемой.

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

В тексте рассылки мы указали:

●   сроки, когда создание новых документов, задач на ранее используемой базе станет невозможным;

●   где будет располагаться вся информация после импорта;

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

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

Долгожданный финал

Казалось бы, импорт выполнен, функционал работает, заказчики уведомлены, все проверено — проект закончен. В нашем случае нет.

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

1.   закрыть возможность создания новых документов и записей справочника на «старой» базе, которая «переезжала» в новую объединенную.

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

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

* * *

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

Резюмируя, хотела бы подчеркнуть, что при рациональном подходе, заинтересованности сторон в успехе, даже такая нетривиальная задача, как объединение динамичных, крупных баз СЭД DIRECTUM, вполне реализуема! Технические детали реализации проекта описаны в материале Экспорт–импорт документов при миграции баз СЭД DIRECTUM.

Успехов всем и больше интересных задач для помощи в развитии бизнеса наших Заказчиков!

Источник: DIRECTUM Club

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 2

Яков Зорин 31 июля 2019

Юлия, добрый день.

Возник такой вопрос. А как решали ситуацию с отличием типовых маршрутов в двух системах? Оставили типовые маршруты только одной системы и не возникло ли сложностей/негатива у пользователей, которым пришлось перестраиваться? Или ТМы двух систем совпадали по схожим процессам и их слияние не вызвало трудностей?

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

Чтобы прокомментировать, или зарегистрируйтесь