Динамичность бизнеса в условиях современной экономики зачастую требует реструктуризации организации. При объединении компаний часто возникает потребность в совмещении бизнес-процессов параллельно работающих СЭД. Хотя задача амбициозна и даже, откровенно говоря, немного пугающа, — всё реализуемо!
В этой статье я на личном опыте ведения проектов в «МайТэк» покажу, как без ущерба для пользователей (что самое главное), остановки бизнес-процессов и с оптимальным использованием ресурсов объединить работу СЭД двух компаний.
С чего начать, когда заказчик приходит с конкретной задачей – объединить две СЭД? Мы начали с плана.
Были подготовлены 2 варианта. Первый вариант представлял собой сводный эксель-файл для четкого планирования трудоемкости при обсуждении реализации. Второй — диаграмма Ганта для удобства мониторинга за ходом реализации, учета согласованности выполнения работ участниками со стороны исполнителя и заказчика.
До составления плана были выполнены следующие этапы:
В итоге родился скелет плана с последовательностью действий.
Затем были проведены внутренние технические совещания и защита реализации проекта. В ходе защиты мы описали коллегам наш порядок действий, пояснили почему выбран вариант перемещения компонент меньшей базы к большей, а также зафиксировали обсужденные точки улучшения плана для применения в ходе исполнения проекта.
По итогу всей предварительной работы была произведена оценка трудоемкости и сроков исполнения каждого этапа с учетом выбранного предпочтительного варианта реализации.
Продуманный и подготовленный план был предоставлен заказчику. На обсуждении освещен вариант реализации, обработаны риски и волнения, высказанные принимающей стороной. По итогам встречи план был согласован — подготовительная фаза проекта завершилась.
После утверждения следовало наложить план реализации на реалии с загрузкой сотрудников с обеих сторон: учесть финансовые планы и дедлайн проекта. Опираясь на полученные в ходе встречи данные, мы получили плановую дату начала реализации проекта и подготовили диаграмму Ганта.
Для того, чтобы максимально сократить сроки проекта, при составлении диаграммы многие виды работ закладывалось с учетом параллельного исполнения. Предложенный план-график согласовывался с заказчиком на предмет удобства выбранных дат для тестирования и приемки работ. После отработки волнений клиента по этапам работ и опасений касательно проекта в целом, план был готов полностью.
Таким образом, пугающая, и, на первый взгляд, необъятная задача трансформировалась в четкий набор мелких задач с закрепленными ответственными, сроками и ресурсами.
Итак, приступаем к реализации. Первая фаза проекта началась с разработки вспомогательных сценариев и соответствующих прикладных отчетов, которые были необходимы для реализации намеченного. В данном блоке зафиксировали с помощью меппинга необходимые данные, сопоставили их. Затем проверили работу сценариев экспорта, импорта данных справочников и связывания документов.
Далее был выполнен экспорт/импорт элементов разработки на отдельную копию базы, проведены работы по синхронизации справочников, созданию и заполнению папок, выдаче прав, загрузке и связыванию документов (с сохранением версионности).
Наступила следующая фаза — перенос на тестовую базу заказчика. Провели комплексное тестирование: сначала сами, затем подключили заказчика, с трепетом ожидая обратной связи. К обоюдному удовольствию, внешний тест прошел без единого нарекания.
Проделанные ранее итерации переноса были повторены на рабочей базе. К элементам разработки основной (большей) базы были добавлены компоненты базы упраздняемой. Параллельно с выполнением технических работ осуществили совместно с руководителем проекта от Заказчика информационную рассылку. Информацию до целевых пользователей обязательно нужно довести заблаговременно, чтобы все успели задать вопросы и свыкнуться с мыслью об изменениях. В тексте рассылки мы указали:
Тем самым, пока разработчики финализировали работы по переносу данных, аналитическая группа команды проекта работала с заказчиками, повышая уровень комфорта работы в системе.
Казалось бы, импорт выполнен, функционал работает, заказчики уведомлены, все проверено — проект закончен. Абсолютно неверно! Пока мы занимались объединением, базы активно использовались, а значит, есть текущие задачи, недосогласованные документы и т.д. И все это в совокупности означает, что мы должны выполнить следующий пул работ:
В итоге мы имеем сокращение расходов на администрирование двух баз, полный архив всех процессов в рамках единой базы, достаточно бескровный этап адаптации с возможностью для сотрудников заглянуть на архивную базу и рассеять свои сомнения касательно идентичности данных в новой и архивной базах.
Резюмируя, хотела бы подчеркнуть, что при рациональном подходе и заинтересованности сторон в успехе, даже такая нетривиальная задача, как объединение динамичных, крупных баз СЭД DIRECTUM, вполне реализуема!
Успехов всем, и больше интересных задач для помощи в развитии бизнеса наших заказчиков!
P.S. Для тех, кому мой рассказ показался полезным, сделаю небольшой анонс: скоро подготовим технические детали реализации проекта.
Подскажите, какие еще были варианты слияния двух баз? Почему выбрали именно ваш вариант? Вы же его защищали, какие аргументы приводили?
Почему не остановили обе базы на время слияния, чтобы потом не домигрировать хвосты?
Как Заказчик принимал вашу миграцию данных из одной базы в другую? Были тест планы, какие то отчеты или что то другое? Очевидно, все данные невозможно было проверить.
P.S. Что за приложение с диаграммой Ганта используете у себя? На Проджект не похоже
Андрей, добрый день, прошу прощения, за задержку с ответом. Изложенный в статье вариант для текущего набора вводных был единственно верным, обсуждалась и защищалась, скорее, детализация вариантов проведения самих работ (технические детали).
Остановить работу основной базы не представлялось возможным, т.к. миграция осуществлялась в основную базу системы, кроме того, бизнес-процессы заказчика не могут быть остановлены без риска для основной деятельности. После готовности новой базы, исходная была закрыта, тем самым работа над задачами для заказчика не останавливалась.
Для данной базы заказчик принимал на тестовых мощностях наличие всего функционала в неизменном виде, тестирование и проверку наличия исторических данных в соответствии с регламентами работ. Мы со своей стороны вспомогательными отчетами контролировали полноту переноса данных ( компонент, файлов, данных системы). В будущем планируется миграция значительно более насыщенной базы, в этом случае действительно предусмотрена разработка вспомогательных отчетов, которые помогут заказчику мониторить данные.
Что касается приложения: на скрине отображена визуализация из онлайн платформы Smartsheet, в которой мы работаем с заказчикjм для обеспечения удаленного доступа сторон к материалам, исходный файл готовился в проджект и загружался в используемое приложение.
Подскажите во время слияния двух баз выполнялась ли перегенерация новых пользователей при импорте в большую базу из меньшей (случай когда имена пользователей совпадают) ? Были ли импортированы задачи и задания ?
Спасибо.
Авторизуйтесь, чтобы написать комментарий