Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Системный и бизнес-анализ доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
Давайте возьмем для примера торговую сеть. Активная история на рынке, ну скажем, с 2006 года для простоты. 20 лет.
500 магазинов 500..1000 квадратов
4 склада 6-тысячника
FMCG. Активная матрица 10000 sku
Собственный интернет-магазин
Стомость вот этого этапа назовите пожалуйста:
"
Современная практика системного анализа предлагает вместо простого ETL (Extract, Transform, Load — извлечение, преобразование, загрузка) проводить полноценную «инвентаризацию данных» как отдельный этап проекта миграции.
"
Вот эта вот "инвентаризация данных" во что обошлась бы исходя из Вашей практики?.
Эксперно. В FTE и десятках миллионов рублей.
Интересно
Добрый день. Спасибо за комментарий!
1) У меня есть информация что для большой торговой сети это будет стоить заметно ниже "десятков миллинов рублей"
2) Давайте рассмотрим в целом все плюсы такой инвентаризации:
Ускорение работы системы. Меньше записей — быстрее поиск и расчёты.
Точность отчетности. Менеджеры перестанут звонить «мёртвым душам», а аналитика перестанет врать из-за дубликатов.
Экономия на поддержке. Не придётся через год после запуска новой системы нанимать отдельную команду, чтобы разгребать завалы, которые уже переехали.
Возможно Вы не четко выразились, но переносить надо всю информацию иначе через пару лет концов не найдешь что и почему случилось, а так хоть останется возможность разобраться. Про дубликаты - это да, их надо переработать.
Добрый день.
Вы абсолютно правы в том, что история нужна. Без неё действительно через пару лет невозможно будет ответить на вопросы налоговой, аудиторов или понять, почему была принята та или иная коммерческая ставка. Полностью удалять данные — это крайность, которую я не имел в виду.
Давайте разделим понятия «рабочая система» (ERP/CRM, в которой сотрудники работают каждый день) и «архивное хранилище» (историческая витрина или отдельная база данных).
Что я подразумевал под «отсекли» в статье:
Когда мы говорим про 15 000 контрагентов, из которых 12 000 — «мёртвые души», мы предлагаем следующий подход:
В новую рабочую систему (где менеджеры делают отгрузки и звонки) загружаем только 3000 активных. Чтобы интерфейсы не тормозили, а поиск выдавал релевантных клиентов.
В архивное хранилище выгружаем всех 15 000 целиком, со всей историей платежей и отгрузок, но в неизменном, «замороженном» виде.
Зачем так делать?
Если мы загрузим всех 15 000 в новую рабочую систему (как просит бизнес «перенести всё»), мы получим две проблемы:
Менеджер при поиске контрагента «Иванов» будет видеть 50 Ивановых, из которых 40 закрыты 10 лет назад. Эффективность работы упадёт.
Отчёт по дебиторской задолженности будет включать долги компаний, которых уже нет, что исказит картину для финансового директора.
При этом налоговая или аудитор, если им понадобится операция пятилетней давности, смогут получить доступ к архиву. Это не уничтожение данных, а их сегрегация (разделение) по степени актуальности.
Известен показательный кейс: в старой системе крупной торговой компании числилось 15 000 контрагентов. После аудита выяснилось, что реально работают только 3000. Остальные — «мёртвые души»: дубликаты (ООО «Ромашка», ООО «Ромашка» и ИП «Ромашкин»), компании, закрытые 10 лет назад, и индивидуальные предприниматели, давно сменившие статус.
Отсюда следует вопрос: а где именно должны храниться данные о контрагентах?
Представим себе централизованное (по способу управления) хранилище этих самых сведений. О контрагентах. Точнее, общий реестр компаний. Общий для всех этих самых компаний. Изменился статус? Заходим в реестр и проверяем.
А что у компании должно быть в локальной базе данных? Только собственная оперативная деятельность. (Ну, могут быть ещё дополнительные базы данных — аналитическая БД, БД для принятия решений, БДдля отчётов и т.д. и т.п.)
Новую БД надо выстраивать сверху. Сначала построить единый реестр. Потом изготовить для каждой организации свою БД по единой спецификации. А уже затем предоставить конвертер, чтобы, сначала, выложить текущую БД каждого предприятия в некий общий формат, а уже потом начать заполнять новую БД актуальными сведениями, прописывая в неё ссылки на единый реестр.
Добрый день!
Вы абсолютно правы: в идеальном мире новый ландшафт нужно выстраивать сверху вниз:
Почему в статье описан другой путь (очистка на лету, а не создание реестра сначала)?
Потому что статья описывает не идеальный мир, а ту суровую реальность, в которой мы сейчас работаем. И здесь есть несколько ограничений, с которыми сталкиваются системные аналитики:
Хронология проекта. Чаще всего проекты миграции запускаются не с чистого листа, а «вчера уже было надо». Бизнес говорит: «У нас SAP отключают через 6 месяцев, давайте быстро переезжать». В такой парадигме нет времени на предварительное проектирование идеального реестра и перестройку всех процессов вокруг него. Мы вынуждены делать «санацию» (чистку) данных параллельно с миграцией, чтобы успеть.
Отсутствие единого источника. В большинстве российских компаний (особенно в legacy-ландшафте) нет этого единого реестра. Контрагенты живут одновременно в 1С, в CRM для отдела продаж, в Excel у финансистов. Все эти системы противоречат друг другу. Чтобы построить единый реестр, нужно сначала провести ту самую «инвентаризацию данных» и договориться между подразделениями, что считать правдой. А это, как мы знаем из части 3, самая сложная политическая задача.
Ссылочная целостность. Даже если мы создадим идеальный реестр, нам нужно «перешить» все ссылки в миллионах исторических документов (счетов, отгрузок, платежей) с грязных старых записей на новые эталонные. Это нетривиальная техническая задача, которая требует времени и ресурсов.
Ваш подход (сверху вниз) — это цель, к которой нужно стремиться, чтобы данные в принципе перестали быть проблемой. Мой подход (очистка при миграции) — это вынужденная тактика выживания здесь и сейчас, когда у нас нет времени на глобальную перестройку, но мы хотим, чтобы новая система не захлебнулась в грязи.
По сути, мы говорим об одном и том же, просто на разных этапах зрелости компании:
Если у компании есть ресурсы и воля — то сначала делаем реестр (MDM).
Если нужно спасать проект миграции — делаем глубокую инвентаризацию и чистку данных старой системы, чтобы хотя бы не перетащить мусор в новую, и параллельно закладываем фундамент для будущего единого реестра.
Да, конечно, если речь идёт о том, чтобы взять старую систему, то, да, много проблем, больших и маленьких.
Но!
Я о том, что всё можно было бы предусмотреть изначально. Что мы имеем, с архитектурной точки зрения? Есть множество разных компаний, у каждой из которых есть какие-то контрагенты. Но контрагенты — это те же компании. Спрашивается: зачем каждая компания дублирует у себя единую для всех информацию? Была бы эта информация и общей для всех базе данных — не было бы проблем.
Было бы просто здорово, если и вся деятельность велась через единую для всех базу данных.
А для чего, тогда, нужна локальная база данных? Она нужна, чтобы в сжатом виде отразить деятельность отдельного предприятия. Тут, конечно же, будет и список контрагентов, но это должны быть ссылки на единый реестр (общую базу данных). Дублирование информации имеет смысл только для повышения надёжности (если сломалась центральная БД, то делаем опрос целых локальных БД и восстанавливаем утраченную информацию) и повышения производительности (хорошо контролируемая денормализация).
В области баз данных имеется теорема CAP. Наличие единой для всех среды (сетевой инфраструктуры) позволяет обойти ограничения, описываемые теоремой CAP.
Есть ещё и две такие задачи: разделение предприятия на самостоятельные части или слияние различных предприятий в единое целое. Аналогичные проблемы.
Если перенести всё это без очистки, новая система захлебнётся в шумах.
Не захлебнется!
Не уверен, что вы правильно расставляете акценты.
Миграция — это не переезд, а реновация. Нельзя переехать в новую квартиру со старыми тараканами. Задача аналитика — убедить заказчика выкинуть хлам до переезда, а не надеяться, что новая система сама «переварит» мусор.
Похоже, вы сами не занимались переносом данных из одной системы в другую. Слишком уж поверхностные суждения, причем со точки зрения: «советы постороннего».
Хорошо, убедили вы заказчика, разрешил он вам «выкинуть хлам до переезда», а кто всем этим будет заниматься? Именно «очисткой» данных и собственно их «переносом» («миграцией») из одной системы в другую?
Судя по контексту статьи этим должен заниматься «аудит» (т.е., привлечение некой внешней фирмы) и команда программистов, тоже, скорее, внешних, Для «внутренних» программистов, то бишь, сотрудников искомой фирмы, аудит не нужен, они сами в курсе всех проблем по старой системе. Другое дело, если они не знают новую систему, тогда могут не справится. Однако и «внешние» программисты почти наверняка будут не курсе по старой системе, особенно, если она не стандартная, скажем, самописная конфигурация для «1С77», которую надо выгрузить в типовую конфу на «1С8х».
Поэтому, все эти сентенции:
Запустите скрипты
Выгрузите списки «подозрительных» записей и передайте их владельцам данных
Пропишите алгоритмы: как объединять дубликаты
Выгрузка «истории» в «архивное хранилище»
выглядят, скажем мягко, несерьезно.
Во-первых, почему вы решили, что у фирмы есть лишнй бюджет на перевнедрение работающей системы? Если денег много, что проще внедрить новую систему с нуля, т.е., просто ввести туда начальные остатки и актуальные справочники, которые можно распечатать на бумагу в старой системе. А потом, просто вводить текущие документы. Если же, нужно перенести исторические данные, то это всегда отдельный большой вопрос, который нужно решать не так, как вы предлагаете. Попутно возникает вопрос о переобучении персонала.
Во-вторых, почему вы думает, что главное это «лишние» данные, а код для переноса – нечто второстепенное?
На самом деле, всё, как раз, наоборот. «Старые» данные в хорошей базе данных не проблема. А если они не корректны, то виновата сама система, соответственно ее программист, который позволил вводить дубликаты и не использовал надежную валидацию и контроль ошибок. Конечно, в этом случае, исходные данные нужно корректировать в рамках старой системы, безотносительно, от переезда их в новую.
Далее, ключевым моментом в переносе данных являются технология, алгоритмы и инструменты для их миграции. Это самая сложная работа, особенно, для несовместимого программного обеспечения. Всё остальное это «мелочи по сравнению с Мировой Революцией». Причем, настолько, что иной раз дешевле напрячь «девочек», которые введут всю новую информацию с «бумаги» во внедряемую программу.
Для «восьмерки» («1С8х») существует типовая конфигурация «КД» («Конвертация данных»). Она позволяет, более-менее, автоматизировано переносить данные из одной типовой конфы, в другую. Но, если исходная, либо целевая конфигурация не вполне типовая (например, программист «1С» прикасался к ней своими шаловливыми ручками), то сразу же возникнут «нюансы».
Третий момент, нередко, фирмы поручают всю работу одному своему программисту, который «и швец и жнец и на дуде игрец», естественно за одну зарплату.
Например, в свое время, меня взяли в производственную фирму с условием внедрить подходящую систему учета для предприятия. Дали денег, я купил все более-менее подходящие программы учета, которые были на рынке, тогда. Но, ни одна из них не «взлетела». Ибо фирма «1С» вообще ваяет конфы по принципу: «Нам с ними не работать!». Что делать? «Взялся за гуж – не говори, что не дюж!». Пришлось, в срочном порядке, в режиме «нон-стоп» (12 часов в день без выходных и праздников) писать свою конфигурацию. К счастью, на предыдущей работе у меня уже были трехлетние (не законченные) наработки, которые мне очень сильно помогли. Через три месяца первый прототип конфигурации заработал. Там даже нормальных отчетов не было, только генерация текстовой информации вместо них.
Потом встал вопрос о наполнении моей «системы» данными. Данные были в районном вычислительном центре, который вел учет для нас. Работали они тоже на самописке, но на «FoxPro». Причем, наши данные они нам отдавать не хотели, так как лишались клиента. Пришлось напрячь госструктуры – отдали, но, естественно, это были почти бесполезные dbf-файлы с непонятной структурой.
Однако, делать нечего, структуру большей части этих данных я выяснил. Потом, их надо было перенести в мою программу. Написал собственные обработки – перенес. Потом, «вылизывание» этих дынных вместе с девочками-бухгалтерами. Совместно – «вылизали».
Система официально вошла в строй. Районным вычислительным центром мы пользоваться перестали. Однако, еще полгода работал в авральном режиме, все появляющиеся проблемы надо было решать в режиме реального времени. Более-менее, расслабился только через два года. В данном случае это была 100%-но собственная конфигурация по учету и расчету заработной платы плюс собственная система учета рабочего времени на базе нетбуков, китайских считывателей RFID-карт доступа сотрудников и собственного драйвера на С++ для нее.
После чего приступил к разработке собственной конфигурации «Учет ресурсов», которую уже начал внедрять. Однако, пришла новая главбухша и перевнедрила ее на типовую конфигурацию «ПУБ» («Производство, Услуги и Бухгалтерия» для Украины). Просто, она хорошо знала «ПУБ», а мою конфу не знала, хотя типовая была, на мой взгляд, менее удобной. Зато мою «Зарплату» перевнедрить не смогла, даже на ее старом предприятии, три программиста ваяли собственный вариант из «ЗиК» («Зарплата и Кадры»), два года, т.е., типовые «зарплаты» не годились от слова «совсем».
Поскольку я живу в ЛНР, то когда появилась непризнанная Республика, учет весь надо было переделывать и мою «Зарплату» и производственный учет от главбухши.
Однако, самое сложное началось, когда ЛНР вошла в состав России. Поскольку, лишних «денюх» у фирмы не было, нужно было искать самое дешевое решение. С «Зарплатой» проблем не возникло, я довольно быстро адаптировал ее алгоритмы к российскому законодательству. А для производственного учета выбрал конфу «ПУБ» для РФ.
Несмотря, на похожие названия украинская «ПУБ» (относительно просто адаптированная под ЛНР) оказалась слабо совместимой с российской «ПУБ». Прежде всего, из-за разных Планов Счетов. А российского плана счетов у нас никто не знал, даже новый главбух. Вот и как переносить остатки и документы при такой неопределенности?
Я сделал встроенный, в конфигурацию, конвертер, в котором бухгалтера могли устанавливать соответствие между разными Планами Счетов. После чего можно было запустить обработку, которая делает автоматом перегрузку данных из старой конфы в новую. Причем, этот процесс можно было повторять неоднократно, перезаписывая «неправильные» документы «правильными».
Все это, конечно, было очень сложно, но других вариантов у меня не было. Как бы то, ни было, процесс по переходу из одной государственности в другую шел успешно. Жаль только, что на взлете фирму «подстрелили», т.е., ликвидировали по политическим мотивам (вроде, как не слишком выгодной она была).
Т.е., я хочу сказать, что все эти разговоры «вообще»: о «миграции», «скриптах», «дубликатах», «архивах» и тому подобное, выглядят нелепо с точки зрения реального опыта.
Например, данные по заработной плате у меня хранились в рабочей системе более, чем за двадцать лет. И совершенно не мешали! Потому, что были «правильно» организованны. А собственный движок базы данных «1С77» я заменил движком «Visual FoxPro», которые подключался к dbf / cdx-файлам «семерки» напрямую. При этом «1С77» был DDE-сервером, а VFP – DDE-клиентом, что увеличило производительность базы данных в 15 раз, вполне достаточную для предприятия. А сама конфа «крутилась» на терминал-сервере фирмы.
А если бы мы пошли по вашей схеме, то фирму, наверняка, ликвидировали бы значительно раньше.
Ого, это пост, чтобы в комментах ии резвился?
Остальные — «мёртвые души»: дубликаты (ООО «Ромашка», ООО «Ромашка» и ИП «Ромашкин»
Какой-то бред, сами-то читали своей текст? Какие же это дубликаты, это абсолютно разные предприятия!
Еще не могу не добавить к списку причин почему наш бизнес проигрывает "битву за информацию" одну из важнейших - ограничение и замедление этой самой информации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему российский бизнес проигрывает битву за информацию и как это исправить. Введение и Часть 1