Size: a a a

Архитектура ИТ-решений

2020 April 23

DK

Daria Kaftan in Архитектура ИТ-решений
Leonid Vygovskiy
Геннадий, а какие еще инициативы есть?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Leonid Vygovskiy
Геннадий, а какие еще инициативы есть?
Локальные в рамках ведомственных решений
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Понял, спасибо.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
У инициатив по качеству данных есть одно препятствие - должен быть power sponsor. Чтобы найти и вдохновить спонсора, нужны впечатляющие факты
источник

AG

Alex Glazunov in Архитектура ИТ-решений
Есть такая идея - служба тестирования данных (аналог тестирования ПО), KPI которой - количество найденных ошибок в данных. Потому что исполнители (как и разработчики ПО) не сильно заинтересованы повышать качество
источник

GM

Gleb Mekhrenin in Архитектура ИТ-решений
Daria Kaftan
Однако)) интересно, на чьей стороне косяк - ФНС или ФГИСа. Могли при миграции как раз накосячить, фгис как раз вводили в это время.
при миграции что угодно могло произойти в целом, но тут надо понимать что таких манипуляций с данными не производилось, возможно ошибка возникла в дальнейшем при обработке новой системой.
Хотя опять же надо понимать какой это регион и в какое время было, может это из легаси систем данные были вообще на тот момент
источник

GM

Gleb Mekhrenin in Архитектура ИТ-решений
хотя сами по себе данные в старой системе это отдельная тема, там очень много косяков
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alex Glazunov
Есть такая идея - служба тестирования данных (аналог тестирования ПО), KPI которой - количество найденных ошибок в данных. Потому что исполнители (как и разработчики ПО) не сильно заинтересованы повышать качество
Этим и начинают заниматься в локальных решениях. Вопрос, что делать дальше, учитывая особенности межведомственного взаимодействия.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Alex Glazunov
Есть такая идея - служба тестирования данных (аналог тестирования ПО), KPI которой - количество найденных ошибок в данных. Потому что исполнители (как и разработчики ПО) не сильно заинтересованы повышать качество
А как вы глобально оцените качество данных? Ведь оно под каждую систему свое.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Под каждый кейс нужно детальное понимание, какие данные ок, какие не ок и почему.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
А дальше, как и при внедрении хранилищ и озёр данных, есть всего два варианта - должен быть кто-то "сверху", кто примет решение работать над качеством или закрыть на это глаза. Чаще всего - второй вариант.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Daria Kaftan
Под каждый кейс нужно детальное понимание, какие данные ок, какие не ок и почему.
К вам в систему приходят данные извне и вы по каждому кейсу можете оценить качество в рамках доступной вам информации.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Gennadiy Kruglov
Этим и начинают заниматься в локальных решениях. Вопрос, что делать дальше, учитывая особенности межведомственного взаимодействия.
Какой-нибудь ЕСОВД получится. Единая система обработки ведомственных данных
источник

F

Fagor in Архитектура ИТ-решений
А разве данные не должны пройти валидацию ПЕРЕД выгрузкой? После тоже, но после, проверяется другое, ошибки транзакций, cоотвествие с внутренними данными
источник

AG

Alex Glazunov in Архитектура ИТ-решений
Daria Kaftan
А как вы глобально оцените качество данных? Ведь оно под каждую систему свое.
Не надо глобально, баги в системах тоже не глобально ищут, а по одному. Глобальные решения принимаются, когда поток единичных ошибок велик
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Наблюдал такой феномен, после внедрения озера данных его хотели быстренько похоронить, потому что были шокированы качеством данных. Не помню как это точно называется, по-моему кривая обучаемости при внедрении хранилищ, когда в какой-то момент расстаются с иллюзиями по части качества данных
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Это в принципе достаточно забавная штука, когда внедрение определенных методик/решений делает ряд проблем настолько очевидными, что проще списать их на недостатки этой методики/решения, чем признать их наличие и что-то с этим делать.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Daria Kaftan
Это в принципе достаточно забавная штука, когда внедрение определенных методик/решений делает ряд проблем настолько очевидными, что проще списать их на недостатки этой методики/решения, чем признать их наличие и что-то с этим делать.
Да, забавно. Технарям это не нравится, мы ведь за всё хорошее
источник

A

Andrey in Архитектура ИТ-решений
Daria Kaftan
Это в принципе достаточно забавная штука, когда внедрение определенных методик/решений делает ряд проблем настолько очевидными, что проще списать их на недостатки этой методики/решения, чем признать их наличие и что-то с этим делать.
Я 1С постоянно так внедрял😂
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Fagor
А разве данные не должны пройти валидацию ПЕРЕД выгрузкой? После тоже, но после, проверяется другое, ошибки транзакций, cоотвествие с внутренними данными
Валидация позволяет выявить только ряд проблем и то часто технических. Она говорит больше о качестве выгрузки, чем от качестве данных
источник