Следующий ключевой результат этапа 1 "Обследование и анализ" - формализованное описание данных к первоначальной загрузке и требования к механизмам загрузки.

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

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

Далее - "разобрать по косточкам" каждый объект ИС, в который планируется загружать данные:

- архитектура уровня бизнес-логики может не совпадать с архитектурой хранилища данных (например, в ИС вы видите 1 таблицу, а в хранилище - это 2 таблицы со связью "1-1");

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

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

По результатам должно быть:

- таблицы с полями;

- информация о привязке таблиц к объектам ИС;

- порядок загрузки каждой из таблиц.

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

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

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

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

Общий перечень ключевых результатов (а заодно и план будущих публикаций) находится в этой статье.