Люди,

Есть большая проблема по замене кучи существующих самописных систем, которые не удовлетворяют потребностям бизнес на новые Системы. Системы разработаны для автоматизации деятельности огромного торгового предприятия, у которого есть центральный офис (ЦО) и множество больших магазинов по продаже крупной техники для розничных покупателей. ЦО выдает каталог товаров, назначает цену на продукцию и собирает данные по продажам из Магазинов. Проблема в том, что систем, которые стоят в ЦО и в Магазинах множество, на рисунке показаны только основные системы и основные потоки данных. Еще одна проблема, что заменить ПО сразу во всех магазинах невозможно, т.к. магазинов около 40. Все ПО в центральном офисе сразу также нельзя заменить, т.к. оно повязано м\у собой и еще связано с бухгалтерией.

Единое ПО для Магазинов уже разработано, предполагается его замена.
Новое ПО для центра предолагается заменить и его можно разделить на 4 части:
1. Шина интеграции для всех систем
2. Единые справочники
3. БД всей оперативной информации со всех магазинов
4. Логистика

Можно выбрать 2 стратегии замены:
1. Стратегию последовательной замены ПО в центре, т.е. заменяем сначала Систем1, потом 2, потом 3 и в конце 4. Но встает вопрос об интеграции текущих систем с новой, а уже нет ни спеков ни разработчиков, кот. делали данные Системы. И придется сделать разработку, которую потом можно будет выкинуть.
2. Стратегию единой замены, когда меняем все ПО в центре на новое. Но тут надо будет интегрировать ПО в оставшихся Магазинах с новой Системой и еще есть большой риск оставить центр без нужной отчетности на месяц или 2.

Какую стратегию можно принять для замены ПО в центре?

А почему сразу замена?

В банках, которые являются довольно серьезными организациями, на мой взгляд, в аналогичных ситуациях (при замене АБС, которая является "сердцем" банка) часто идут по пути параллельной работы в двух системах. Основная работа производится в старой системе, при этом в новой системе производят те же действия, частично автоматом (если умеют корректно экспортировать из старой и импортировать в новую систему проведенные за день документы/сделки), частично вручную, силами выделенных для этого сотрудников. И так до тех пор, пока не получат требуемые результаты. Как правило, это соответствие баланса и некоторых отчетов на протяжении нескольких месяцев.


У вас такую стратегию избрать можно?

Плюсы очевидны - постепенное внедрение, уменьшение рисков ошибок при конвертации данных, обучение пользователей на реальных данных без риска их "поломать", обучение айтишников на более глубоком уровне за счет того, что требуется глубокий разбор систем. В конце-концов, воспользовавшись этой ситуацией, вы сможете получить людей, которые будут хорошо понимать ЧТО у вас во всех этих "flow" происходит. И описать эти знания.

Минусы - дорого и долго.

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

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

Вы не поверите, но при прорисовке сущ систем получилось основных около 18 и связей м\у ними более 30

Вы не поверите, но при прорисовке сущ систем получилось основных около 18 и связей м\у ними более 30

Надеюсь, после окончания перехода, число систем уменьшится?

Надеюсь, после окончания перехода, число систем уменьшится?

Станет 5 с шиной интеграцией

Вы уже все решили, я понимаю, но хочу предложить еще один вариант.

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

Ну так это и есть двойной ввод. Но сколько нужно будет сотрудников, чтобы 18 Систем поддерживать в режиме двойного ввода.

Не соглашусь, это не двойной ввод. Задача решаемая двойным вводом в разные системы - достичь идентичных результатов, различным путем.

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

Согласен, по поводу объемных трудозатрат. Вариант - можно сразу поднять 5 систем с шиной, и переход не имитировать, если ресурсы ограничены.

Но вообще я не туда ударился, закругляюсь. К стратегии перехода это отношение имеет отдаленное, больше к тестированию.

474, спасибо за интерес, я думаю мы поняли друг друга

Какую стратегию можно принять для замены ПО в центре?

Оценить и взвесить риски ущерба для бизнеса. Не на пальцах, как сейчас, а с конкретными цифрами – чем чревато отсутствие отчётности в течение месяца? Сколько будет стоит разработка одноразовых адаптеров? И т.д.

Денис, спасибо, согласен, сделаем это.