Реструктуризация c DIRECTUM – это просто

Опубликовано:
21 июня в 07:34
  • 2

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

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


 

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

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

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

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

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

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

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

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

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

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

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

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


 

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

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

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

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

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

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

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

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

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

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

Казалось бы, импорт выполнен, функционал работает, заказчики уведомлены, все проверено — проект закончен. Абсолютно неверно! Пока мы занимались объединением, базы активно использовались, а значит, есть текущие задачи, недосогласованные документы и т.д. И все это в совокупности означает, что мы должны выполнить следующий пул работ:

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

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

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

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

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

 

11
Подписаться

Комментарии

Подскажите, какие еще были варианты слияния двух баз? Почему выбрали именно ваш вариант? Вы же его защищали, какие аргументы приводили?

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

Как Заказчик принимал вашу миграцию данных из одной базы в другую? Были тест планы, какие то отчеты или что то другое? Очевидно, все данные невозможно было проверить.

P.S. Что за приложение с диаграммой Ганта используете у себя? На Проджект не похоже

 

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

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

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

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

Авторизуйтесь, чтобы написать комментарий