serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Классифицируй это
serge_gorshkov
За последние два года у меня сложился довольно разносторонний опыт работы с каталогами и классификаторами в самых разных отраслях: от нефтегазовой промышленности до продуктового или модного ритейла. Может показаться удивительным, но специалисты этих областей совершают похожие ошибки при работе с данными. Легче извинить человеческий разум, пасующий перед сложностью проблем с классификаторами в промышленности, где приходится иметь дело с миллионами единиц номенклатуры, классифицируемой по абсолютно разным основаниям. В этом случае можно понять, что приводит к выбору простых, но вопиюще неэффективных способов классификации. Сложнее найти оправдание нежеланию конструктивно разобраться в вопросе, когда речь идет о предметной области, на определенном уровне понятной и не специалисту - например, о классификациях одежды в модном магазине.

Итак, начнем с классификации товаров в магазине одежды (мы рассматриваем универмаг, а не бутик). Очевидны следующие факты:
 - существует множество оснований классификации одежды: пол (м/ж), возраст (младенцы, дети, подростки, взрослые), стиль (casual / спорт и т.д.), бренд, применимость к части тела (верх, низ, обувь, головной убор), тип ткани (джинсы, вязание), и т.д., и т.п.
 - среди этих классификаций нельзя выбрать более или менее важные. В контексте зонирования магазина важны одни разрезы классификации, в контексте закупок и логистики - на первый план выходят другие, а при навигации по интернет-магазину, скорее всего, потребуются все.

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

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

Перейдем к промышленности. В инженерных науках составители классификаторов догадываются о том, что каждый вид товаров нужно классифицировать по разным основаниям (фасет), но часто реализуют это самым плачевным образом. Например, подшипники можно классифицировать по материалу, внутреннему и наружному диаметру, применимости и др. параметрам. Составителям классификатора кажется хорошей идеей создать позиционный код, в котором значения различных параметров будут занимать определенные знакоместа. Например, код может иметь вид XX.A.XX, где A - цифра, соответствующая материалу подшипника. Поскольку место под эту цифру предусмотрено только одно, получается, что при помощи такого кода можно описать не более чем 10 вариантов материала. Если появится 11-й вариант, его нельзя будет внести в классификатор, поскольку это разрушит позиционную структуру кода. Значит, подшипники из этого нового материала придется искусственно относить к одной из уже известных категорий, то есть, снова - совершать неправомерное допущение, которое существенно снижает практическую ценность классификатора.

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

Как же нужно строить каталоги и классификаторы, чтобы не разменивать сиюминутное "облегчение" труда на глобальные негативные последствия?

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

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

  • В-третьих, взаимосвязанные основания классификации можно объединить в иерархию. Недопустимо фиксировать "этажность" иерархии, или использовать на разных "этажах" не связанные друг с другом основания классификации.

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

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


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

  • 1
Вот я нифига не понял, как мне жить дальше и как создавать классификаторы, кроме того что я делаю это не правильно. В принципе я допускаю, что тупица и даже знаю об этом, но как, Холмс?(с)
Вот понятнее нифига не стало лично мне, а уж как донести это до рядового состава - совсем беда.

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

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

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



Несмотря, что многобукв, тема совсем не раскрыта...
Вот делят, классифицируют, определяют.... Делают это неправильно, создают себе дополнительные проблемы. Причем вы описали только одну проблему: появился классификатор, появилась проблема затолкать товар в классификатор (1)... "Если у вас нету дома, пожары ему не страшны".

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

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

Я бы предложил другой порядок:

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

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

И мне тоже в личку пришлите пожалуйста, будет интересно почитать.

Со всем написанным согласен.
Когда несколько подразделений начинают разговор о вводе какого-нибудь общего классификатора, цель обычно формулируется так: "для обмена информацией". Подразумевается, что всем подразделениям нужен один и тот же *код* каждой сущности некоторого списка (например, клиентов), чтобы на него ссылаться.

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

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

Здесь бы еще один тезис все-таки добавить:
- обязательное наличие эталонных классификаторов (их легитимного состояния во времени) для каждого классификационного основания (цели). Необходимо для обеспечения целостности предприятия и/или его части/аспекта

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

Вопросов еще больше. Кто должен разрабатывать классификации для предприятия и как валидировать качество классификации?

Ну, да, можно какие-то классификаторы считать эталонными. Но опять же, возникает вопрос гибкости. Пользователям хочется иметь эти классификаторы неизменными во времени, чтобы, например, получать аналитику в разрезе этих классификаторов из года в год (по одним и тем же группам товара, например). И для связности с другими субъектами бизнеса, да, проще иметь статичные классификаторы.

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

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

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

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

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

  • 1
?

Log in

No account? Create an account