Mom and Dad`s Misery

1. Проклятое место

Когда вся мировая IT-индустрия из года в год не может справиться с задачей создания искусственного интеллекта, то это можно понять. Искусственный интеллект – это запредельно сложно. С освоением Марса – та же история. А вот когда всё никак не получается найти хорошее решение простой задачи, которую, казалось бы, нужно просто взять и аккуратно решить, нам становится удивительно, когда это никак не получается сделать: «Наверно, место проклятое», – говорим мы.

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

Общим местом в дискуссиях о проблемах, связанных с низким качеством НСИ, является утверждение о том, что внедрение НСИ является не столько технической задачей, сколько организационной. Конечно же, это правда, но корень проблем лежит намного глубже, и бывает так, что до конца погасить пожар не удаётся ни самыми передовыми технологиями, ни щедрыми капиталовложениями, ни привлечением лучших специалистов, ни мощнейшей организационной поддержкой.

Если совсем кратко, то настоящей причиной проблем и неудач проектов НСИ являются следующие фундаментальные факторы:

1. Сама идея создания единого классификатора предполагает, что относительно перечня представленных в нём объектов объективно существует единственно правильная версия «правды». Но в подавляющем большинстве случаев ни о каком объективном существовании «правды» говорить нельзя.
2. Теория дискретных множеств, лежащая в основе технологии хранения структурированных данных, зачастую является слишком грубым упрощением, не адекватным сложности автоматизируемых процессов.
3. Централизованное управление может быть результативно в гораздо меньшем числе ситуаций, чем принято считать.

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

1.1. Неустранимая погрешность объективации

Имя, которое может быть названо, не есть постоянное имя.

Лао-цзы

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

Объективация всегда субъектно-зависима, и можно только надеяться на то, что два разных субъекта в одной и той же ситуации объективируют одно и то же. Более того, объективация всегда контекстно-зависима. Попросив принести стакан воды, мы рассчитываем на то, что будет принесён стеклянный предмет, наполненный H2O, а когда этот стакан воды мы выпиваем, то вовнутрь употребляем только воду. Не прошло и минуты, как объективация предмета изменилась, но это нас ни удивляет, ни расстраивает. Мы всё время так живём.

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

Например, решили мы составить список контрагентов, то есть субъектов хозяйственной деятельности, с которыми мы ведём дела. Концепция списка подразумевает, что мир субъектов хозяйственной деятельности может быть однозначно поделён на отдельные объекты. Но это, конечно, не совсем так. В некоторых случаях контрагентом является холдинг, в другом – его дочернее общество, в третьем – филиал дочернего общества. В принципе, некоторыми свойствами субъекта хозяйственной деятельности обладают даже структурные подразделения. В зависимости как от точки зрения (субъектная зависимость), так и от ситуации (контекстная зависимость), иногда бывает необходимо сначала отразить в информационной системе факт взаимодействия как с большой транснациональной корпорацией, так и со складом готовой продукции, связь которого с этой корпорацией очень косвенная и многоступенчатая, а потом иметь возможность понимать, что эти субъекты – суть один и тот же субъект. Просто решить для себя, что список контрагентов – это список обладателей уникальных сочетаний ИНН и КПП (то есть делегировать функцию объективации субъектов хозяйственной деятельности налоговой службе государства) – значит пойти на столь сильное упрощение, что это может оказаться не полезно для бизнеса. Государство ведёт учёт хозяйствующих субъектов для целей налогообложения, а партнёры – для совсем других целей. Разница в целях учёта неизбежно сказывается на разнице в подходах к решению задачи. Договоры заключаются и исполняются людьми и коллективами, а налоги платятся юридическими и физическими лицами. Точное соответствие между реально существующими и действующими субъектами и записями в государственном реестре желательно (потому что удобно), но не обязательно. Вопрос «На кого оформить договор?» – обычное дело между деловыми партнёрами.

С проблемой однозначности объективации можно столкнуться, даже когда речь идёт о пообъектном учёте дискретных твёрдых материальных предметов. Например, компьютер. На что нужно наклеивать инвентарный номер? Логично предположить, что системный блок, а монитор, клавиатуру и мышку следует снабдить отдельными инвентарными номерами, чтобы была возможность заменить, например, мышку, не проводя по учётной системе сложные операции разукомплектации/комплектации основного средства. Но используемым предметом является весь комплекс, а системный блок – всего лишь одна из его составных частей, самостоятельного применения по своему прямому назначению почти не имеющая. Точно так же, как и сам системный блок – это тоже комплекс, состоящий из отдельных деталей. В поисках глубинной сущности компьютера можно дойти до того, что самой его центральной частью является центральный процессор, и даже может возникнуть соблазн наклеить инвентарный номер на процессор. Но, как легко догадаться, это не правильно, так как сгоревший процессор можно поменять, и эта операция не превратит компьютер в другой компьютер.

1.2. Идентичность

Если в компьютере заменить процессор, в результате будет тот же самый компьютер. Если потом поменять жёсткий диск, компьютер останется тем же самым, даже если со старого диска не переносить информацию. Потом материнскую плату. Потом видеокарту. Потом корпус с блоком питания. В конечном итоге от старого компьютера ничего в новом не осталось, но это тот же самый компьютер. Или уже другой? С точки зрения бухгалтерии, если со старого корпуса переклеили на новый бумажечку с инвентарным номером, то это тот же самый компьютер, но только прошедший ряд ремонтов и модернизаций. С точки зрения пользователя компьютер стал другим уже при замене жёсткого диска, так как ему пришлось заново перенастраивать под себя систему. Можно было бы махнуть на эту неопределённость рукой (пусть философы упражняются на эту тему в остроумии в минуты праздности), если бы и в повседневной жизни, и при работе информационных систем понятие идентичности предметов не было столь важно. Применительно к теме управления нормативно справочной информацией тема идентичности интересна хотя бы потому, что любая система управления НСИ есть не что иное, как система управления идентичностями информационных объектов.

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

Идентичность – способность предметов быть тождественно равными самим себе. Часто путается с тождественностью свойств, из-за чего возникает масса недоразумений и философских псевдопроблем. Идентичность и тождественность свойств – совсем разные вещи. Идентичность обозначается словосочетанием «тот же», а тождественность свойств – «такой же». «Тот же» предмет может поменять все свои свойства, но остаться самим собой, а «такой же» при всём своём старании никогда не станет «тем же».

«Купи тех же помидоров, что и вчера» – это не правильно. «Тех же» купить невозможно, потому что «те же» уже один раз куплены, съедены и уже даже перестали быть помидорами. Надо говорить «купи таких же».

«Положи зарплату в такую же коробочку, что и аванс» – не правильно. Если зарплата будет положена в точно такую же (но другую) коробочку, то найти её потом, возможно, будет затруднительно. Надо говорить «в ту же».

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

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

В информационных системах идентичность реализуется идентификаторами, основных требований к которым всего три:

1. Уникальность (два разных объекта не могут иметь один и тот же идентификатор). Свойство уникальности вытекает из сути идентичности. Если два объекта имеют одну и ту же идентичность, то это никакие не два объекта, а один и тот же объект.
2. Неизменность. Тоже следует из сущности идентичности. У объекта может поменяться всё, что угодно, кроме его «самости».
3. Внутренняя пустота. Поскольку путаница между «тот же» и «такой же» является обычной логической ошибкой, это требование часто нарушается. В частности, ИНН задумывался как уникальный идентификатор, но авторы нововведения не удержались и включили в него код субъекта РФ и номер налоговой инспекции, в результате чего иногда возникают разнообразные недоразумения. В частности, расширение бизнеса может вызвать острое желание сменить свой старый провинциальный ИНН на красивый столичный. Приходится это делать через серию фиктивных реорганизаций, от чего возникает множество неудобств.

Сочетание фамилии, имени, отчества и даты рождения не может быть идентификатором человека, потому что нарушаются требования уникальности (1) (известен случай, когда человек имел массу проблем в частности, со Сбербанком, от того, что у него есть «дубль» по этим параметрам) и неизменности (2) (эти параметры иногда меняются). Номер паспорта тоже не может быть идентификатором, потому что при смене паспорта меняется и номер (нарушено требование неизменности (2)).

Два объекта обладать одной и той же идентичностью не могут (т.к. тогда это один и тот же объект), но может ли один и тот же объект обладать несколькими идентичностями? К сожалению, да, потому что есть описанная выше неустранимая погрешность объективации. Например, текст «Войны и мира» на китайском языке – это с одной точки зрения такая же «Война и мир», как и все остальные, но с другой точки зрения – принципиально другой объект. Один и тот же объект может иметь отдельные «точки» в разных виртуальных пространствах. При этом, естественно, многочисленные варианты «самости» объекта невозможно отранжировать ни по какому критерию, так как в разных контекстах разные варианты являются единственно правильными и единственно применимыми.

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

1.3. О том, как виртуальные пространства идентичностей реализованы в ваших (и наших) базах данных

В первом приближении можно сказать, что когда мы смотрим на схему базы данных, выраженную в нотации «сущность-связь», то объектные таблицы, хранящие в себе списки сущностей  – это и есть виртуальные пространства идентичностей, к которым потом через внешние ключи подвязываются другие факты, хранимые в базе данных. На самом деле, конечно, это не совсем так. Объектные таблицы – это два в одном. С одной стороны, они, конечно, реализуют пространства идентичностей, но с другой стороны, они хранят двухместные предикаты. Рассмотрим, например, такую таблицу:

Таблица Person

Пространство идентичностей – это множество значений колонки ID, как фактически введённых в таблицу, так и потенциальных (в теоретической литературе по базам данных используется термин «домен»). Все остальные колонки реализуют хранение предикатов. В нашем примере, вот таких:

Person_FName(233422, «Иван») ≡ 1
Person_MName(233422, «Иванович») ≡ 1
Person_LName(233422, «Иванов») ≡ 1
Person_BirthDate(233422, 01.04.1980) ≡ 1

То есть в данной таблице реализована идентичность и хранение четырёх видов фактов. Можно было бы держать идентичности отдельно от фактов, но это, как правило, контрпродуктивно с точки зрения эффективности. Хотя, конечно, не нужно забывать, что поддержание идентичности и хранение фактов – это логически разные задачи.

Те таблицы базы данных, которые не являются объектными таблицами, хранят только факты:

Таблица Salary

В нотации исчисления предикатов:

Salary_Total(233422, 01.01.2024, 100500.00) ≡ 1
Salary_Bonus(233422, 01.01.2024, 0.00) ≡ 1
Salary_Comment(233422, 01.01.2024, «Не заработал премию») ≡ 1

Ваша корпоративная система хранит в себе набор фактов. Пользователи, открывая формочки и заполняя поля, сообщают системе факты. Всё, что потом система выдаёт на выход в виде печатных форм, отчётов, аналитики и оповещений – это факты, собранные системой и обработанные по заданным правилам.

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

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

Математика, лежащая глубоко в основе информационных технологий, начинается с того, что нам уже каким-то чудесным образом «даны» дискретные множества, на которых мы выстраиваем системы предикатов, функций и всего остального, что потом через загадочный процесс разработки информационной системы материализуется в формочки, кнопочки, распечатанные отчёты и красивую инфографику в PowerPoint. Но суровая правда жизни заключается в том, что дискретные множества, используемые информационными системами – это почти всегда чудовищная условность и плод ряда допущений, на которые пришлось закрыть глаза. В любом случае, они ни в коем случае никогда не бывают «даны».

Итак, на данный момент мы имеем следующее:

1. Факты в информационных системах формулируются на базе дискретных множеств объектов.
2. В реальном мире никаких объектов не существует, и уж тем более не существует дискретных их множеств. Все дискретные множества объектов являются результатом субъектно- и контекстно-зависимых процессов объективации.
3. Но мы вынуждены идти на все допущения и пользоваться тем, что есть, потому что у нас нет альтернативы.

Мы должны понимать, что окончательного решения проблемы не существует, и должны быть готовы к сюрпризам. Дольше всех проживёт тот, кто окажется гибче.

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

1.4. Драма мудреца на горе

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

Лао-цзы

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

• Максимум полномочий – в центр, к руководству под крылышко.
• Собрать в центр самых толковых специалистов.
• Свободу манёвра на местах ограничить, втиснув в максимально жёсткие рамки запретов.

Применительно к управлению НСИ рецепт выглядит следующим образом:

• Внесение изменений в классификатор – только руками специально назначенных ответственных сотрудников (так называемая «служба НСИ»).
• Собрать в службу НСИ лучших специалистов (для целей данной задачи).
• Внесение изменений в классификатор пользователям запретить. Пусть пишут заявки в службу НСИ.

Решение выглядит логичным, правильным, желанным. Да что там говорить, решение это выглядит просто безальтернативным.

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

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

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

Управление – это принятие решений. При любом централизованном управлении организуется чудовищный дисбаланс между «низами», обладающими максимумом данных для принятия решений (разумеется, речь не о глобальной стратегии, а о решении локальных операционных задач в конкретный момент времени), но минимумом возможностей, и «верхами», обладающими максимумом полномочий, но минимумом исходных данных. И чем больше уровней иерархии добавляется, тем точка принятия решений оказывается дальше и от исходных данных, и от исполнения решений, и от последствий. Чудовищное лавинообразное разрастание управляющих структур, которое мы имеем возможность наблюдать, есть не что иное, как попытка привести разнообразие управляющей системы в соответствие разнообразию системы управляемой. Но поскольку управляющая система также оказывается состоящей из управляемых подсистем, получается, что в данном случае имеет место попытка тушения пожара бензином.

2. Так что же делать-то?

2.1. Рецепт первый. Децентрализация.

Высшая добродетель подобна воде. Вода приносит пользу всем существам и не борется с ними.

Лао-цзы

Если посмотреть на классическую схему взаимодействия управляющей и управляемой систем, то при желании можно заметить, что она симметрична, что можно проиллюстрировать такой картинкой:

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

Грань между хищничеством и паразитизмом тонка. Тонка и грань между паразитизмом и симбиозом. Поэтому, начав с позиции хищника («я начальник, ты дурак», «ты – моя собственность», «никуда не денешься»), можно перейти к паразитизму («я тобой пользуюсь, но это для тебя не смертельно»), а потом и к симбиозу («мы – единое целое, и можем выжить только вместе»).

Применительно к теме НСИ, децентрализация должна выражаться в том, что система управления НСИ должна перестать рассматриваться как дубина, при помощи которой железной рукой наводится порядок. Инфраструктура НСИ (уже не система управления, а именно инфраструктура) должна рассматриваться как полезный сервис, упрощающий функционирование других элементов информационной инфраструктуры. Что существенно важно, упрощаться жизнь должна не только «вверху», но и везде (колесо управления круглое, у него нет ни верха, ни низа). Если поставлена задача внедрить НСИ только для целей подготовки отчётности перед акционерами (или перед государством), то за эту задачу даже нет смысла браться.

2.2. Рецепт второй. Не верить в магию.

Верные слова не изящны. Красивые слова не заслуживают доверия. Добрый не красноречив. Красноречивый не может быть добрым.

Лао-цзы

 «НСИ» (MDM) – это одно из тех трёхбуквенных модных слов (buzzwords), при помощи которых уже не первое десятилетие экономика информационных технологий паразитирует (грань между паразитизмом и симбиозом тонка) на экономике реального сектора.

Если кто-то в рекламе обещает вылечить все болезни, быстро и качественно внедрив систему управления НСИ, не верьте. Это ловушка. Тем более не верьте, если кто-то предлагает купить систему управления НСИ. НСИ – это не предмет, а процесс, и поэтому НСИ невозможно ни купить, ни продать. Предложение купить систему НСИ – это обман. Если в перечне функций приобретаемой информационной системы значится «управление НСИ», этот пункт следует читать максимум, как «инструмент для выстраивания НСИ» (мы же не думаем всерьез, приобретая excel, что это система управления планированием и бюджетированием, хотя для экономистов этот продукт часто становится удобным инструментом для решения их задач).

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

2.3. Рецепт третий. Идти от потребностей.

Совершенномудрый стремится к тому, чтобы сделать жизнь сытой, а не к тому, чтобы иметь красивые вещи

Лао-цзы

Нет и не может быть такой потребности, как «иметь систему управления НСИ». Но, возможно, у вас или ваших клиентов есть ряд потребностей, в удовлетворении которых инфраструктура НСИ могла бы оказаться небесполезной. Давайте рассмотрим эти потребности:

1. Минимизация ошибок ввода данных.
2. Идентификация объектов при информационном взаимодействии.
3. Коммуникационная среда распространения основных данных между информационными системами.
4. Коммуникационная среда между людьми, полезная при принятии совместных решений о внесении изменений в основные данные.
5. Инструментарий выявления и устранения ошибок идентификации.
6. Инструментарий выявления и устранения противоречий в хранимых в системах фактах.
7. Упорядочивание развития информационных систем.

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

2.3.1. Минимизация ошибок ввода

Существует два основных подхода к решению задачи наведения порядка – «злой» и «добрый». «Злые» способы реализуются через запреты поступать неправильно. «Добрые» – через обеспечение дополнительных удобств при выполнении правильных действий. Для того чтобы люди не топтали газон, можно воспользоваться «злым» подходом и поставить забор, а можно сделать по-доброму, и проложить дорожки. Чтобы люди не сорили, можно поручить полиции штрафовать за брошенную бумажку, а можно поставить урны. Можно запретить пользователям заводить новые элементы классификатора (пусть пишут заявки в равную богам по мудрости и прозорливости службу НСИ), а можно сделать удобный сервис поиска существующих элементов и ввода новых. Можно запретить пользователям сохранять недозаполненные карточки, а можно наладить процесс постобработки (нормализации и гармонизации) введённых данных.

При этом и документооборот заявок в службу НСИ, и сервис поиска, и система запретов, и инструментарий нормализации/гармонизации – всё это может быть реализовано под обобщающим понятием «инфраструктура НСИ».

Что интересно, в теме «НСИ», как и в реальной жизни, невозможно утверждать, что «добрый» подход всегда лучше «злого». Как и в реальной жизни, нужно соблюдать баланс, трезво оценивая каждую конкретную ситуацию. Например, очень «добрый» сервис, позволяющий по одному только ИНН подтянуть в систему «из облака» все параметры карточки юридического лица приведёт к тому, что пользователи расслабятся, и закончится всё плохо. Психологически очень трудно перехватить на себя инициативу (и ответственность) поддержания в актуальном состоянии данных, изначально получаемых «свыше» из волшебного «облака», даже не смотря на наличие всех необходимых регламентов и инструкций.

Хорошая инфраструктура НСИ должна иметь возможность гибко управлять и расстановкой «заборчиков», и прокладкой «дорожек». Притом, что важно, система принятия решений о том, что следует запретить, а что упростить, должна быть устроена так, чтобы точка принятия решения максимально совпадала с местом возникновения последствий в случае, если решение принято не правильно.

2.3.2. Идентификация объектов при информационном взаимодействии

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

Когда речь заходит о месте системы НСИ в информационной инфраструктуре предприятия, обычно утверждается, что НСИ всегда должна быть в самом центре. Но сам факт наличия функции «переводчик» говорит нам о том, что в этом утверждении лишь половина правды. НСИ – не в центре, а между системами, и это «между» – совсем не обязательно центр. Если две взаимодействующие системы находятся на периферии информационного контура, то совсем не обязательно, чтобы переводчик находился в центре. Если все дороги проходят через центр города, ничем хорошим это не заканчивается. Более того, переводчик бывает полезен не только при взаимодействии собственных систем предприятия. Он также бывает полезен при электронном взаимодействии с поставщиками и покупателями, и тогда возникает вопрос: где тот центр, в котором должна быть реализована эта функция инфраструктуры НСИ? Делегировать функцию НСИ третьей стороне (государству, оператору информационного обмена и т.п.)? Иногда можно, но чаще лучше не нужно. Вот и получается, что место инфраструктуры НСИ – не в центре, а везде, где возникает потребность в управлении идентичностями.

2.3.3. Коммуникационная среда распространения основных данных между информационными системами

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

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

Выше говорилось о том, что функция инфраструктуры НСИ – это управление идентичностями. Если же мы реализуем распространение основных данных, то НСИ начинает также хранить факты. Это не очень хорошо, поскольку хранение фактов – это задача, реализуемая обслуживаемыми системами. Они для этого лучше приспособлены, каждая под свою специфику. Безусловно, внутри НСИ нужно хранить факты (например, наименование объекта – это тоже факт об этом объекте), но по возможности в НСИ нужно хранить только те факты, которые помогают идентифицировать объекты.

2.3.4. Коммуникационная среда между людьми

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

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

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

2.3.5. Выявление и устранение ошибок идентификации

Типичные ошибки идентификации:

1. Дублирующиеся объекты. Один и тот же объект представлен двумя идентичностями в одном и том же пространстве идентичностей. Некоторые информационные системы позволяют выполнить операцию объединения дублей, но иногда бывает разумным оставить дублирующиеся элементы, запомнив этот факт и реализовав в логике информационной системы механизмы, позволяющие не испытывать при наличии дублирования никаких существенных неудобств. Объединение дублей – это, как правило, билет в одну сторону, и если потом вдруг оказывается, что элементы были объединены зря, то получаем гораздо более противную проблему «слипшихся» объектов.
2. «Слипшиеся» объекты. Два разных объекта представлены одной идентичностью. Шок. Паника. Валерьянка. Создаём новый элемент и аккуратно переносим со «слипшегося» объекта на новый все факты, которые к нему относятся. Хорошо, когда информационная система позволяет проделать такую операцию, хотя бы даже под правами суперпользователя.
3. Ошибка объективации. В системе хранятся факты по объекту, который не должен был стать объектом, по которому в системе хранятся факты. Например, к учёту принято основное средство «компьютер», в состав которого включён и монитор, и клавиатура, и мышь, тогда как по-хорошему системный блок и монитор должны были быть приняты к учёту по отдельности, а клавиатура с мышкой должны были списаться в инвентарь.

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

2.3.6. Выявление и устранение противоречий в хранимых в системах фактах

Если одни и те же факты по одним и тем же объектам могут вноситься независимо в разных системах, то наличие «переводчика», реализуемого инфраструктурой НСИ даёт возможность реализовать механизмы обнаружения расхождений и автоматизировать «выравнивание» данных, тем самым повышая и качество, и полноту.

2.3.7. Упорядочивание развития информационных систем

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

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

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

2.4. Несколько полезных советов

Мои слова легко понять и легко осуществить. Но люди не могут понять и не могут осуществлять.

Лао-цзы

2.4.1. Бойтесь иерархических классификаторов

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

2.4.2. Помните об изменчивости

Любой статический факт, сохранённый в системе (например, то, что Иванов Иван Иванович имеет имя «Иван») рано или поздно может перестать быть правдой. Просто поменять значение – не проблема, но, скорее всего, пользователи захотят в отчётности за прошлые периоды видеть старое значение. Если делаете централизованное ведение классификатора, лучше заранее подумайте над тем, по каким атрибутам может понадобиться история значений.

2.4.3. Помните о том, что идентификатор – только для идентификации, и ни для чего больше

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

2.4.4. Помните о неустранимой погрешности объективации

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

2.4.5. Помните, что НСИ – это не только для крупных компаний и масштабных проектов

Даже просто ведя в своём телефоне список контактов, вы уже имеете кусочек своего личного НСИ и, соответственно, большинство из характерных для НСИ проблем.

2.4.6. Не бойтесь

Да, НСИ – это очень сложно и очень страшно. Жить вообще сложно и страшно, но приходится. Если сохранять позитивный настрой и, умея отличать главное от второстепенного, не гоняться за миражами, то всё обычно получается. В главном.

Александр Масляев
Начальник отдела разработки
информационых систем, компания Infosuite