|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Есть много разных процессов подготовки отчетности. Например: Маша получила доступ к внешнему реестру клиентов, и выгружает оттуда клиентов, далее рассылает по почте реестр своим коллегам: Пете, Васе, Коле и т.д. Дальше Петя грузит реестр клиентов к себе в БД MSSQL, Вася себе Оракл, а Коля живет в Excel, ему не нужны БД. В итоге, когда готовится финальная отчетность, оказываются у всех разные списки по реестру (не бьются друг с другом на 100%). Филосовский вопрос, как поставить на корпоративные рельсы такие процессы ? Хотелось бы услышать какие-то идеи по организации работы и контролю таких процессов, особенно в Банках. Должен ли быть некий отдел, отвечающий за загрузку данных в БД/Хранилище ? Если есть бизнес подразделение по подготовке данных, то где должен быть этот отдел, внутри бизнес подразделения или внешний ? Вообще бы хотелось жить в рамках некоторой парадигмы, где бы возникновения нового источника данных не вызывало сложности работы у пользователей и источник бы жил в рамках некоторого жизненного цикла. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2018, 15:10 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Коноплио, Сделать единую эко-систему, выделить мастер-базу данных, от которой все пляшут. Какие ещё могут быть варианты? А тут больше играет человеческий фактор, нежели технический. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2018, 16:30 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Коноплиовнешнему реестру клиентов А можно поинтересоваться что это за зверь такой?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2018, 16:47 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Коноплио, читайте про MDM системы КоноплиоМаша получила доступ к внешнему реестру клиентов, и выгружает оттуда клиентов, далее рассылает по почте реестр своим коллегам: Пете, Васе, Коле и т.д. Дальше Петя грузит реестр клиентов к себе в БД MSSQL, Вася себе Оракл, а Коля живет в Excel, ему не нужны БД. В итоге, когда готовится финальная отчетность, оказываются у всех разные списки по реестру (не бьются друг с другом на 100%).можно уточнить как один набор клиентов разнесённый по разным коллегам перестал вдруг "биться"? если вы их сводите по ФИО (ну, например) почему эти Васи\Пети имеют право (если уж не техническое ограничение, то хотя бы бумага с запретом за подписью самого главного чувака и прописанными карами если что) менять ФИО клиента (бизнес ключ)? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2018, 16:58 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
У любых данных должен быть owner, и, соответственно, срез данных этого owner'а (вместе со всеми ключами, etc/)- это golden source. Те кто берет данные не у owner'а (откуда-то извне, ведут свою копию, ...) - сами себе злобные бакланы и виноваты во всех возможных нестыковках. Если все берут данные owner'а , но все равно получаются нестыковки - виноват owner. У разных данных, естественно, могут быть разные owner'ы, поэтому единый на организацию отдел по загрузке данных - на мой взгляд, утопия, которая может существовать только в очень тепличных условиях. P.S. вообще вопрос скорее для "Разработки информационных систем", нежели для "Проектирования БД" ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2018, 18:30 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Все правильно сказали, это MDM-системы. Единый реестр клиентов, продуктов, справочники, т.п. Все остальные обращаются к MDM ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2018, 19:07 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Есть такая проблема - синхронизация справочников в различных системах. По ряду абсолютно объективных причин они могут быть неодинаковы. И не всегда есть возможность запихнуть их в одну экосистему. Н-р к-либо из них ведутся независимо и при этом в некот. случаях более полны, чем некий мастер-справочник. Н-р справочник коллцентра (заполняемый на слух на лету как попало) может быть значительно больше, чем корпоративный с-к клиентов. Процедура синхронизации - штука непростая. Нужно буквально каждой записи дать точное соответствие в другом справочнике. Как ни крути, это ручная работа, кот. надо проводить постоянно и при участии экспертов (н-р менеджеров). кароч это 50% техн.вопросы (обмен, взаимодействие, регламенты) 50% орг.вопросы (дисциплина, компетенция, командная работа) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2018, 21:21 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
LSV50% техн.вопросы (обмен, взаимодействие, регламенты) 50% орг.вопросы (дисциплина, компетенция, командная работа) 5% техн. вопросы 95% орг. вопросы технически объём работы конечно большой, но выработать решение можно, и не одно. адекватный специалист это может спроектировать, команда, в которой больше людей с мозгами, чем бездельников, это сможет за определённое время выполнить. но всё это не имеет никакого смысла, если на орг. уровне проблема не может быть решена. типа один отдел не хочет зависеть от другого. проблема «кто главней» и общий уровень долпоепизма, который может иметь зашкаливающие показатели, не дадут и шагу сделать в нужном направлении. по личному опыту, это всё выполнимо, просто нужно иметь смелость принимать радикальные решения, и слать всех неандертальцев в лес. либо делается корпоративное НСИ, либо не делается. всё эти «сводить жопу с ручкой» усилиями экспертов должны быть одноразовыми, но никак не постоянными. никто не захочет постоянно сверять одно и то же перманентно, тупая обезьянья работа нинужна никому. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 00:27 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
И всё же мне кажется, что "внешние данные" сначала должны быть централизованно обработаны/согласованны в рамках внутренней БД, а потом уже "распространяться" по пользователям. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 05:57 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
КоноплиоДальше Петя грузит реестр клиентов к себе в БД MSSQL, Вася себе Оракл, а Коля живет в Excel, ему не нужны БД. В итоге, когда готовится финальная отчетность, оказываются у всех разные списки по реестру (не бьются друг с другом на 100%). Прежде всего, надо точно понять, почему "не бьются". Какие причины? Например: 1. Маша получает реестр каждый день, и каждый день он чуть отличается. И у Пети с Васей оказались реестры за разные дни. Вася болел, пропустил загрузку. 2. У Пети в MS SQL настроен констрейнт, чтобы Отчество было обязательно заполнено. В результате у него при загрузке отсеялись люди без отчеств. 3. Все реестры загрузились, но сверка их идет по ФИО, а в таблице по ФИО есть дубликаты. В итоге в разных программах разная логика цепляет одни платежи к разным людям. 4. У Васи в Оракле редактирование ФИО открыто для операторов, и девочка-перфекционистка исправила ряд явных опечаток в ФИО клиентов - ей рассылку делать, не отсылать же "Уважаемый Перт Пертович". Или что еще? Без осознания причин, любые промежуточные базы, выговоры Маше и прочие меры результатов не дадут. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 09:57 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Cane Cat FisherКоноплиоДальше Петя грузит реестр клиентов к себе в БД MSSQL, Вася себе Оракл, а Коля живет в Excel, ему не нужны БД. В итоге, когда готовится финальная отчетность, оказываются у всех разные списки по реестру (не бьются друг с другом на 100%). Прежде всего, надо точно понять, почему "не бьются". Какие причины? Например: 1. Маша получает реестр каждый день, и каждый день он чуть отличается. И у Пети с Васей оказались реестры за разные дни. Вася болел, пропустил загрузку. 2. У Пети в MS SQL настроен констрейнт, чтобы Отчество было обязательно заполнено. В результате у него при загрузке отсеялись люди без отчеств. 3. Все реестры загрузились, но сверка их идет по ФИО, а в таблице по ФИО есть дубликаты. В итоге в разных программах разная логика цепляет одни платежи к разным людям. 4. У Васи в Оракле редактирование ФИО открыто для операторов, и девочка-перфекционистка исправила ряд явных опечаток в ФИО клиентов - ей рассылку делать, не отсылать же "Уважаемый Перт Пертович". Или что еще? Без осознания причин, любые промежуточные базы, выговоры Маше и прочие меры результатов не дадут. Я бы сказал наоборот - без использования единой мастер-базы разбирательство в конкретных причинах - мартышкин труд, который надо будет проделывать снова и снова, а при использовании часть этих причин автоматически исчезнет, а другая - автоматически же, без специальных усилий, проявится. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 10:33 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Кот МатроскинЯ бы сказал наоборот - без использования единой мастер-базы разбирательство в конкретных причинах - мартышкин труд, который надо будет проделывать снова и снова, а при использовании часть этих причин автоматически исчезнет, а другая - автоматически же, без специальных усилий, проявится. Самые продуманные обезьянки должны вломить самому умному, чтобы не отнимал у них работу ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 11:17 |
|
Как организовать процесс распространения данных в компании?
|
|||
---|---|---|---|
#18+
Коноплио, Для вашего примера: Машу заменить, на сервис чтения реестра клиентов + БД. А Пете, Васе, Коле и т.д. дать доступ к БД на чтение. Если они не хотят работать с единой БД. То для каждой ИС создается сервисы интеграции. Тут может появиться ESB, но это сейчас не модно, поэтому пусть будут микросервисы. Ну а дальше микросервисы, для работы с микросервисами и все заврте... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2018, 05:52 |
|
|
start [/forum/topic.php?fid=32&msg=39600300&tid=1540078]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
161ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 239ms |
total: | 496ms |
0 / 0 |