`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Дмитрий Луговой

Финансовые выгоды от внедрения систем управления метаданными

+44
голоса

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

Безусловно, основным преимуществом управления метаданными является улучшение обмена информацией. Метаданные служат связующим звеном между различными подразделениями и процессами компании, что и подтверждает статистика, приведенная на следующей иллюстрации:

Финансовые выгоды от внедрения систем управления метаданными

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

(T1-T2)*C*B*A — Экономия средств благодаря управлению метаданными

Т1 — количество часов, затрачиваемое сотрудниками на сбор и изучение информации из системы-источника, а также документирование результатов;

Т2 — количество часов, затрачиваемое на получение соответствующей информации с использованием решения по управлению метаданными;

С — количество сотрудников, которые принимают участие в процессе изучения систем-источников информации;

В — средняя зарплата сотрудника в час;

А — количество приложений или проектов, внедряемых в компании за год, которые так или иначе требуют изучения уже существующих источников информации в компании.

Для понимания данной формулы приведем следующий пример:

120 часов (или три рабочих недели) — примерно столько необходимо специалисту, чтобы изучить и задокументировать несколько небольших по масштабу источников. Включая переписку с сотрудниками других подразделений, организацию встреч для обсуждения информации, согласование терминологии и т.д.

24 часа — столько времени понадобится специалисту, чтобы найти уже существующую информацию в системе управления метаданными и адаптировать ее для своих целей.

10 человек — среднее количество специалистов, задействованных в проекте.

50 гривен в час — средняя зарплата опытного специалиста (отталкиваясь от среднемесячной зарплаты в 1000 долларов).

10 проектов — количество проектов, которые внедряются в компании за год, выполнение которых так или иначе требует изучения уже существующих источников информации в компании.

В таком случае экономия средств, благодаря управлению метаданными, составит:

(120 - 24) * 10 * 50 * 10 = 480 000 гривен

Экономия почти полмиллиона гривен фонда заработной платы компании в год, безусловно, является преимуществом, однако это ли главный «плюс» и главная выгода от управления метаданными? Нет, в большинстве случаев основным преимуществом управления метаданными является повышение эффективности работы сотрудников, а значит и эффективности компании, что неизбежно влечет за собой рост ее прибыли!

Компания Intel, ведущий производитель электронных чипов в мире, подсчитала, что каждый доллар, потраченный на управление метаданными, позволяет компании сэкономить 6 долларов в год!

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+44
голоса

Напечатать Отправить другу

Читайте также

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

Интересные расчеты ;-) Только для того, что бы экономия получилась вы должны или людей уволить или количество проектов увеличить...

А вот в реальной жизни можно ли вместо "10" человек оставить "два" или реализовать "50 проектов" - вопрос однако.

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

И да, безусловно, данные расчеты дают лишь приблизительную оценку и подсчитывать ROI на их основе весьма сомнительное занятие. Однако они дают общую картину того, как именно управление метаданными позволяет экономить средства.

Крупные компании уже определились с тем, что процессы управления информацией это инвестиции которые не дают прямой и видимой прибыли. Однако ведь в конечном итоге именно благодаря качественной информации бизнес процветает :)

Экономия возможна при определенном масштабе затрат. То есть стоимость внедрения технологии не должна превышать 20-40% от годовой экономии. Иначе невыгодно и рискованно.

Стоимость скорости реакции на изменение информации успешно рассчитывается уже не одну тысячу лет, поэтому все страны мира имеют разведки.

С друго стороны - реально очень мало технологий, которые на самом деле позволяют не меньше тратить а больше зарабатывать. Обработка метаданных к таким технологиям не относится. Поймите - это просто рассекреченная техника автоматизированного анализа примерно 20-летней давности. Но этих кошек нужно уметь готовить. А вот с этим всегда была проблема...

Полностью согласен! Если вести расчеты отталкиваясь от реальной экономии, то 20-40% это вполне честные цифры.
Однако экономия это не совсем та основная цель, ради которой мы начинаем заниматься метаданными. Первая и главная задача метаданных - дать четкое понимание всем имеющимся информационным активам в компании, и как следствие устранить рассогласованность между сотрудниками, особенно между ИТ и Бизнес подразделениями. А если ИТ и Бизнес будет на 100% понимать друг друга, если они будут говорить на одном языке тогда удастся избежать огромного количества ошибок, которые возникают из-за непонимания.
Кроме того, если Вы будете четко понимать какой информацией Вы владеете, в каком она состоянии, насколько она полна и т.д. Вы сможете более эффективно принимать решения.
Чтобы понять как и где метаданные могут помочь нам в бизнесе, в следующих материалах я буду приводить реальные кейсы, как метаданные помогли преодолеть некоторые проблемы, которые довольно часто встречаются у современных компаний.

Дмитрий, а могли бы Вы привести конкретные примеры метаданных, которые помогли Бизнесу и ИТ перейти на разговор на "одном языке"?

Приведу пример из области телекомов.
"Трафик разговора" для технических специалистов это в первую очередь занятость канала, т.е. время с того момента как пользователь нажал на кнопку вызова и начал дозвон и до того момента как он положил трубку. Специалисты маркетинга подразумевают под этим понятием исключительно финансовый аспект, т.е. то время, которое абонент разговаривает и приносит деньги компании.
Если нет системы
, в которой будет четко описано какой именно смысл необходимо вкладывать в понятие "Трафик разговора", то не исключены конфликты из-за этого непонимания. К примеру отчеты "Объем трафика за месяц" из двух департаментов могут отличаться в разы.
Система управления метаданными позволяет задать и закрепить четкие определения для всех объектов в компании, как бизнес так и технических.

"Объем трафика за месяц" из двух департаментов могут отличаться в разы." - Почему?

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

Разный взгляд на вещи: "Объем трафика" для ИТ может составлять несколько минут, пока один абонент дозванивался другому, но не дозвонился. А для Бизнеса "Объем трафика" будет равен нулю, так как второй абонент не принял звонок, а значит денег не заплатил, а значит считать нечего :)
- это все очень обобщенно конечно же

Я привел пример не решения, а проблемы, т.е. именно непонимания, которое часто возникает из-за разных взглядов ИТ и Бизнеса на одни и те же вещи.

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

Хмм, а при чем здесь, не понимание "ИТ и Бизнеса"?

В приведенном пояснении, никто никого не поймет... Если каждое подразделение само придумывает себе "метрики" (например, KPI) да еще и не заботится о "уникальности" названия, то естественно, что это может приводить к "разночтению"...

А при чем здесь "методанные"? Почему именно этот термин используется?

PS:

"Я привел пример не решения, а проблемы, т.е. именно непонимания, которое часто возникает из-за разных взглядов ИТ и Бизнеса на одни и те же вещи."

Упомянутые "вещи" разные, просто названы одинаково

"Упомянутые "вещи" разные, просто названы одинаково"
Вот именно из-за этого бывают проблемы и конфликты :) хоть и редко. Это опять же всего лишь один из преимуществ управления метаданными

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

Ну и конечно же плюс системы, что по связям которые описаны для каждого объекта Вы можете посмотреть в каких отчетах, к примеру, используется тот или иной показатель. Т.е. если сотруднику необходимо построить новый отчет с использованием показателя А и Б, то он может найти в системе данные показатели и посмотреть в каких отчетах они уже использовались, возможно данный отчет уже был кем-то построен, тогда использовав URL пользователь может сразу перейти в тот же Business Object. Данная ситуация может показаться надуманной, однако как показывает практика количество отчетов-дублей порой достигает 50%

О, теперь начинаю понимать... :)
А зачем порождать такую сущность как "метаданные"? В чем необходимость? Мне кажется она уводит от понимания написанного.

Мало того, что на разных уровнях иерархии модели данных может по разному трактоваться, но самое неприятное, что один и тот же уровень, но в разных моделях может видоизменяться: данные, мета-данные, мета-мета-данные...

ИМХО: плохой термин ;-)

К сожалению, ни одна система, основанная на метаданных не позволяет научить общему языку. И происходит от того, что в 8 случаях из 10 развитие ИТ никак не связано с реальными потребностями бизнеса. Да, будет достигнута полнота... никому не нужной информации. А нужной - просто не будет, потому что задачу на ее сбор должен дать бизнес, но этому он, бизнес, часто бывает просто не научен. И будет отполировано глюкало, на которое смотрят раз в год и то - из любопытства.

К сожалению, сейчас бытует зачастую ложное представление о ценности информационного ресурса, без учета реальных бизнес-процессов, реального менеджмента и реального производства товаров и услуг. Да, и без учета роли реальных людей. Говорю так, поскольку наболело. Поскольку никто не учит ИТ-специалистов основам бизнеса, в котором они ведут свою деятельность.

Бывают редкие исключения - но они все поголовно связаны с сутью офлайнового бизнеса. Логистика, дистрибьюция, организация подготовки производства (в том числе цепочки поставок), строительство, банковское дело - вот где метаданные (и BigData) рулят. Но опять же - все зависит от масштабов. И от систем принятия решений. НО вот что-то автоматизированных систем принятия решений, несмотря на почти полувековые разговоры, как не было, так и нет в промышленной реализации. Только в виде суперсекретных спецсистем. И то - которые ошибаются в 10-15 раз чаще, чем человек, имеющий минимальную специальную подготовку.

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

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

А про распределение ролей и тех людей, которые должны поддерживать метаданные в компании я также буду писать в следующих материалах.

ВОт тут-то и упираемся в главное противоречие - задачу должны поставить бизнесмены, но они не знают, что же им нужно на самом деле. Тут на свет выползают монструозные отчеты на стопиццот страниц от именитых консалтеров, которые никак не могут быть использованы для постановки информационных задач. И это - проблема абсолютная и общая. Общение с зарубежными коллегами и публикации в различных изданиях это подтверждают. И разворачиваются SAP-кластеры, вокруг кормятся все те же консалтеры, но желаемого эффекта почти не происходит. Временная мобилизация вокруг внедрения очередного супер-пупер-мега-информационного проекта проходит и конечная эффективность внедренного решения через 2-3 года начинает стремиться к минус бесконечности. Этим пользуются нишевые игроки, которые внедряют легкие, мобильные и _дешевые_ системы, которые реально ускоряют процесс принятия решений. Но таких - меньшинство :(

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

"...а тому, кому она могла бы быть нужна - просто не могут сказать, что же им на самом деле нужно для дела." - а можно примерчик? Че то туплю и не могу поймать фишку, сорри

Отвечу вопросом на вопрос :)

Не доводилось сталкиваться с запросами от отдела продаж, когда запрашивается только статистика по оказанным услугам, но не запрашивается информация по отказам от услуг?

Какая разница, что будет ответом: "Да" или "Нет"? ;)

ИМХО: здесь вопрос в "умении" человека.

Каждый владелец бизнес процесса должен ЗНАТЬ, что у него должно быть "на входе", какой "ресурс" и "управляющее воздействие" ему необходимо обеспечить, что бы получить планируемый "выход".

Данные ЗНАНИЯ могут быть сгенерированы им самим (он сам разработал БП) или ему спущена сверху "инструкция". Ни в первом ни во втором случае не возникает "пробелов": Если ему для оптимизации помогла бы инфа по "отказам", то он бы знал, что ее надо запросить, но если он не знает, что она ему нужна, что толку, что ее дадут?

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

А вот то что здесь написано, понять пока не смог, надо что-то подучить...
Конечно, я должен был в начале спросить: "что понимается под метаданными?", но я даже боюсь спрашивать, потому как это такая скользкая "сущность" ИМХО ;-)

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

О, еще немного - и мы таки придем к контекстной зависимости метаданных от текущих контекстов владельца, обработчика и хранителя :))

В других технологиях это уже называется полиморфизм, контекстная инкапсуляция и еще много каких названий.

И, почему-то никто не вспомнил, откуда взялся XML :))

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

Как-то мы проводили эксперимент, в одной из компаний раздали бумажки и попросили написать на них определение "Контрагента". Из присутствующих 15 человек, или около того, никто не дал четкого определения, все было рядом да около. Если нет четкого понимания даже таких вещей, то это уже тревожный звоночек.

Спасибо. Теперь то я понял о каких таких "метаданных" идет речь... А я то думал...

хвост виляет собакой

приведенная в качестве примера в последнем абзаце компания интел стала успешной и продолжает удерживать лидерство в отрасли благодаря своим инженерам. а управление метаданными по степени важности для интела стоит на почетном шестнадцатом месте.

Мы не говорим о том, что их продукция стала быстрее работать благодаря метаданным :) В данном случае это ROI. Достигнув определенного уровня зрелости, компания Intel занялась построением внутренних процессов управления информацией, они инвестируют в управление метаданными и получают от этого ощутимую выгоду :)

Нагородили разного-всякого. Есть такое понятие как глоссарий базы. Если один и тот же термин разные департаменты трактуют по разному - сверяемся с глоссарием б/д. Если один и тот же параметр используется с разными характеристиками в разных матрицах б/д - значит есть "столбики/строчки" которые влияют на эти характеристики. Обычный скрипт может парсить и "поправлять" ошибочно введённые или созданные автоматически "метаданные" - согласно, всё того же глоссария. Или Вы никогда не приводили в порядок тэговую аннотацию в огромной коллекции "МР3-шечек"? Это же метаданные?

Именно. Просто придумали новый маркетинговый термин - его и продают под видом откровения.

+100500

... сведя проблему _взаимопонимания_ между ИТ и Бизнесом к чисто "лингвистической" :(

Продаю услуги перевода с русского на русский...

Что касается бизнес-метаданных:
Метаданные это не просто описание определений и атрибутов того или иного объекта. Это составленные иерархии, таксономии, связеи с описанием зависимостей и т.д. К примеру таксономия для участников:
Party > Customer > Person ...
В этой таксономии между объектами наследуются свойства и заданные характеристики.
Также между всеми этими объектами строятся связи и зависимости. И в случае изменения формулы расчета показателя пользователь сразу может оценить, в том числе и визуально, на какое количество отчетов это повлияет.
Кроме того, как уже упоминалось ранее, качественные бизнес-метаданные это в первую очередь должно интересовать бизнес подразделения, а как известно сотрудники бизнес подразделений не будут лезть в базу данных и писать SQL и скрипты для поиска интересующей их информации :)
Кроме того, согласование какого-либо бизнес определения может потребовать участие нескольких человек, в таком случае необходим реализованный бизнес-процесс который позволит удобно обсуждать, согласовывать и утверждать такие бизнес определения, опять же сотрудникам бизнес подразделений.

Что касается технических метаданных:
благодаря так называемой Lineage диаграмме, можно увидеть все информационные потоки в компании. Можно проследить путь информации от первоисточника и до поля в отчете. Вплоть до того, что можно увидеть данные из какого поля, какой таблицы, какой БД используются для построения отчета и каким изменениям и трансформация эти данные подвергаются
Не знаю получится ли вставить картинку:
http://radikal.ua/data/upload/ba193/c2184/69c164b3a4.png

Ну вот теперь все совсем ясно. Принцип Оккама в бездействии!
(Хинт: таксономия ==упорядочение :)

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

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

Опупеть. 40 строчек на Paskal`e. Ну,"дорисовать" гуй в "буилдере".

З.Ы.

Это я утрирую, конечно, но сложность поставленной задачи, мне кажется, - передал точно.

Я абсолютно не сомневаюсь в Вашем профессионализме и возможностях, однако современные ПО по управлению метаданными, от таких компаний как Informatica, IBM, Terradata и SAP, тяжело назвать маленькими. Функционал реализованный в этих решениях значительно выходит за рамки управления плоским списком и связями между объектами.
Самое "Легкое" решение и обладающее, наверное, наибольшим функционалом на данный момент является Data Governance Center от компании Collibra:
http://www.collibra.com/products/business-semantics-glossary
В нем присутствует и создание маппинга между информацией, и снепшоты, и workflow и т.д.
Посмотрите, если будет свободные 5-10 минут. У них на сайте можно найти и кейсы и видео работы и многое другое.

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

Ну где-то так и есть :)
Действительно, критичная необходимость в управлении метаданными появляется при наличии достаточно объема и большого разнообразия информации плюс разветвленная орг. структура в компании. Особенно это важно когда в компаниях начинают появляться DWH и BI, именно при их построении злую шутку играют несогласованность требований, отсутствие единого бизнес-языка, отсутствие единого понимания бизнес-терминов и методик расчета показателей.
Или еще кейс, к примеру альянс или поглощение компаний, когда две абсолютно разные компании должны научиться говорить на одном языке, а у них 100% будут разные взгляды на некоторые бизнес-объекты...

P.S. Big Data эта тема без метаданных вообще не должна рассматриваться, есть куча хороших статей на тему Big Data= Big Metadata. Но это уже совсем другая история :)

Ну ё-моё, за рыбу деньги... Опять по кругу. Если существуют несколько баз сходных по структуре данных и эти базы отличаются расположением типичных объектов в базе и/или их описаниями в этих же базах или описаниями которые наследуются/импортируются из внешнего источника - всё решается стандартной оптимизацией базы, точно такой же как подготовка базы к полному импорту данных из базы. Как я и говорил выше - определяются типы данных, затем определяются классы данных и их описания внутри этой базы,определяется какой тип экспорта/импорта данных лучше описывает данную конкретную базу, сравниваете с тем типом данных экспорта/импорта которые хотите использовать вы. Например, вы решили использовать XML - проводится стандартизация классов их описаний для экспорта/импорта. Делается експорт - смотрим на тот ужас который получился и находим - в чём особенность нашей конкретной базы. После этого принимаем решение по компании: либо определить спорные/непонятные/смешанные классы данных - в отдельные, либо - изменить их классы и описания - для всех подразделений и баз компании. После принятия этого решения - рисуем узер и админ нтерфейсы и начинаем экспортировать/импортировать базы. Туда-сюда,сюда-туда,сюда-сюда и туда-туда... и тудой-сюдой - тоже.

Почему Вы склонны считать, что вся информация имеющаяся у компании хранится в базах? На базах свет клином не сошелся. Достаточно большое количество информации существует только на бумаге или, что еще хуже, исключительно в головах некоторых специалистов. Бумажные носители информации имеют свойство устаревать, так как их мало кто актуализирует, а специалисты частенько меняют свое место работы, передав только 10% знаний своим преемникам. Именно поэтому многие процессы часто приходится разрабатывать заново, заново строить уже ранее построенные отчеты, эмпирическим путем докапываться до смысла формулы расчета показателя и т.д. Построив процессы управления информацией, в частности метаданными, компания сможет избежать таких проблем.
Хорошо было бы, если бы все специалисты всю информацию заносили в базы данных и неустанно ее актуализировали, но посмотрим правде в глаза такого не бывает. Пока не будет централизованной системы для сбора информации и построенных бизнес-процессов для ее актуализации, в компаниях по прежнему будет преобладать информационных хаос. И по прежнему для того чтобы что-то узнать нужно будет знать человека к кому обратиться, вместо того чтобы зайти в систему и быстро найти интересующее.

Мне очень хочется донести до Вас то, что попытка решить фундаментальные задачи кибернетики косметическими средствами управления информацией - порочна изначально. Еще лет 10 назад под теми же знаменами проходило "управление знаниями", потом - оркестрация, потом - сервисная модель, теперь - BigData. И все упирается в то, что основной мотив развития в этом направлении - выведение человека из информационного управления.

Да, а каких-то 25 лет назад все поголовно занимались "искусственным интеллектом". Но наткнувшись на иррационально-размерные задачи моделирования фрактальных структур Prolog, SmallTalk, Lisp, нейрокомпьютеры - заняли свои узенькие ниши, почти не выдав на гора ничего существенного. Ах да,- в шахматы научились играть да лица распознавать.

На моей памяти ни одна система, пытающаяся решить фундаментальные проблемы кибернетики, не была доведена до промышленного использования, занимая свои узкие ниши и используемая только узкими специалистами.

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

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

А, забыл. "Метаданные", в таком варианте, можно определить как класс и равное ему описание. То есть - точно такие же данные как и всё остальное. И ничем они - не особенные. Стандартизируются и проверяются на грамматику/валидность в любой момент (рекомендуется - по ночам или во время минимальной загрузки сервера обслуживающего базу). Зачем нужны всякие монструозные роботы - непонятно. Хотя... Чего только люди не покупают за деньги, а за большие деньги - ещё больше чего.

Сударь, не путайте данные (Big Data в частоности) и базы данных. Есть такой вид данных как процес (flow) и способ обработки - оркестрация/аранжировка (orchestration), которые ну никак не связаны с конкретными БД. И в принципе - не являются реляционными и(о ужас) даже могут не иметь предикативного представления. И существуют только в виде UML моделей или BP нотации.

Виктор, если Вы считаете, что Бигдатовая реальность существует отдельно от обычных баз данных, то, я спорить с Вами не буду.

"Обычные" базы данных - это где-то 20-30% от того, что называют BigData.
Хочу посмотреть, как вы будете запихивать в базы данных программы на Коболе, а между прочим - именно с них идет начало проблемы BigData :)

О, специально для Вас я нашел очень хороший пример повседневной проблематики bigData - бухгалтерские системы 1С. Когда одни и те же данные в зависимости от учетного периода и изменения в налоговом законодательстве интерпретируются абсолютно по-разному.

Ну, так это вопрос актуальной выборки из базы, а причём здесь сама база? Закон, как известно - обратной силы не имеет. К тому же, обсуждаемая тема - это просто комментарии к данным. "Кошка - останется кошкой, даже если её перекрасить в другой цвет"©

Какой же вы наивный...

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT