Mom and Dad`s Misery

Опубликовал Александр (kg_am) в раздел Управление - Теория учета

Попытка разобраться, почему проекты НСИ чаще не получаются, чем получаются

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

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

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

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

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

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

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

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

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

Лао-цзы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица Person

ID

FName

MName

LName

BirthDate

233422

Иван

Иванович

Иванов

01.04.1980

 

 

 

 

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

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

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

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

Таблица Salary

PersonID

Month

Total

Bonus

Comment

233422

01.01.2015

100500.00

0.00

Не заработал премию

 

 

 

 

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

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

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

Факты, фиксируемые в системе, всегда о чём-то. В частности, факт про выплату зарплаты – он и про сотрудника Ивана Ивановича, и про январь 2015 года, и про то, куда делись 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

См. также

Комментарии
1. Сергей (Che) Коцюра (CheBurator) 3370 10.11.15 01:42 Сейчас в теме
Полезная статья.
Нашел для себя интересного, созвучного имеющимся проблемам.
ElizaMilos; Evil Beaver; +2 Ответить 1
2. Александр (kg_am) 74 10.11.15 11:12 Сейчас в теме
(1) CheBurator, Спасибо на добром слове!
3. Программулькин (Программулькин) 259 10.11.15 18:03 Сейчас в теме
ты чё курил? отсыпь, я тоже хочу!
Steelvan; comol; adhocprog; +3 Ответить 1
4. Римма Герасименко (WhiteOwl) 79 10.11.15 18:27 Сейчас в теме
Браво! Чудесный слог))
Aphanas; adhocprog; +2 Ответить
5. Александр (kg_am) 74 10.11.15 23:01 Сейчас в теме
(3) Программулькин,
Не, такой травы не бывает. Такое только под эндорфинами ;)
6. Сергей (Che) Коцюра (CheBurator) 3370 11.11.15 01:11 Сейчас в теме
Мои несогласия с автором заключаются в том, что говорит онто хорошо, но рецептов хоть каких-то нет. Да, централизовать это типо плохо потому что НСИ получится в центре контекстно-зависимое от центра - типа поэтому создадим "облако" НСИ - это зашибись. Осталось определить как НСИ нижнего уровня будут "переводиться" в НСИ более высокого уровня (а по этому кардинальному вопросу - молчок...) - и здесь мы снова попадаем по кругу (тавтология) - снова надо создавать НСИ-переводчик-конектор для трансляции снизу-вверх.... а это вообщем и есть основная задача... Ибо количество связей такого облака с вышестоящей иерархией (и не одной!) будем более чем дофига
ander_; Lapitskiy; hulio; Fabler; +4 Ответить 1
7. Андрей Овсянкин (Evil Beaver) 3790 11.11.15 09:29 Сейчас в теме
Мне нравится Ваш слог. И статья отличная!

P.S.Да, и ник у Вас шикарный просто :)
8. Виктор Захаров (ZVN) 111 11.11.15 11:04 Сейчас в теме
Интересная статья. Кто хотел тот понял очем речь.
Ведь ещё Козьма Прутков сказал "Нельзя объять необъятное"
Лично мне понравилось.
Что касается рецептов для CheBurator то они должны появляться при решении конкретной задачи
Chernik; Nikolas_first; ElizaMilos; +3 Ответить
9. Алексей Владимрович (Fabler) 11.11.15 12:46 Сейчас в теме
Уважаемый Александр Масляев!
Мне глубоко импонирует, что Вы подняли проблему отражения в информационной базе предприятия различий в картинах мира подразделений этого предприятия.
Да такая проблема объективно существует. То что для сбытовика план по выручке (цель), то для снабженца лишь "сырье" для закупки (средство).
Это так называемое структурное противоречие картин мира различных подразделений предприятия. В наиболее острой форме такое противоречие проявляется на крупных предприятиях.

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

Оба эти противоречия Вами отмечены, но как-то не четко. Они не названы своими именами, не разделены, а свалены в одну кучу.

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

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

Но вы ничего не сказали о том каким должен быть следующий шаг развития.
И в связи с этим у меня к Вам возник вопрос:
- О следующем шаге вы умолчали сознательно, что бы сохранить конкурентное преимущество или считаете, что описанных Вами мер, на сегодняшний день достаточно с запасом?
10. Александр (kg_am) 74 11.11.15 12:50 Сейчас в теме
(6) CheBurator,
Совершенно согласен с тем, что предложение задуматься о децентрализации при решении задачи управления НСИ выглядит по меньшей мере парадоксально. Как и, например, предложение присесть чуть пониже, чтобы подпрыгнуть чуть повыше :)

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

Само собой разумеется, что в некоторых простых случаях централизованное ведение и push-распространение - это именно то, о чём следует мечтать. Например, вести децентрализованно справочник валют смысла нет вообще никакого. Нет и не может быть с нашей точки зрения там никакой субъектной и контекстной зависимости. Но когда речь идёт о той же номенклатуре, то напрашивающееся простое "деревянное" решение - это наверняка не то, что "взлетит". В этом случае трезвый взгляд на происходящее и применение инструментального подхода (именно его я проповедую в разделе 2.3) способно дать набор пусть и не идеальных, но вполне жизнеспособных решений.
11. Сергей (ildarovich) 4844 11.11.15 13:23 Сейчас в теме
Согласно закону Эшби для того, чтобы управлять, например, функционированием крупного машиностроительного холдинга, нужно обладать разнообразием не меньшим, чем разнообразие этого холдинга.

Вот здесь написано, что
Видимо, не разобравшись в формальных основаниях З. н. р., С.Бир предложил вовсе неверную формулировку, что сложность управления должна быть не меньше сложности системы (см. статью о Эшби). Формально это допускает, что H(x) < I(u,x), чего не может быть из математических соображений. Сейчас эта ошибочная формулировка самая распространённая в интернете и в среде специалистов, не знакомых с оригинальными работами Эшби.
Evil Beaver; +1 Ответить 1
12. Александр (kg_am) 74 11.11.15 14:12 Сейчас в теме
(9) Fabler,

>> не названы своими именами, не разделены, а свалены в одну кучу
Помилуйте. Если подробно всё расписывать и разделять, то получится текст существенно другого объёма. Здесь я всего лишь обозначил концептуальные проблемы, понимание глубины которых, на мой взгляд, необходимо для того, чтобы вероятность успешного решения задачи управления мастер-данными была отлична от нуля.

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

>> О следующем шаге вы умолчали сознательно, что бы сохранить конкурентное преимущество или считаете, что описанных Вами мер, на сегодняшний день достаточно с запасом?
Нет никакого конкурентного преимущества. Более того, специфика текущего момента такова, что в плане управления НСИ мы имеем огромного масштаба непокрытую потребность, которую на текущем этапе развития информационных технологий не можем покрыть ни я, ни Вы, ни Microsoft, ни IBM, ни SAP, ни Oracle, вообще никто. В силу объективных причин. Говорить в такой ситуации о конкурентном преимуществе просто глупо.

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

Какой должен быть следующий шаг, спрашиваете? Не знаю. Всё зависит от того, куда нужно прийти :)
В любом случае, умение адекватно рассуждать о том, что может встретиться на пути, лишним не будет.
voneska7; Evil Beaver; +2 Ответить
13. Александр (kg_am) 74 11.11.15 14:33 Сейчас в теме
14. Александр (kg_am) 74 11.11.15 14:56 Сейчас в теме
(11) ildarovich,
Ага. Тема энтропии в контексте управления очень интересна. Надо будет над этим хорошенько подумать.

С одной стороны, конечно, управление можно рассматривать как снижение энтропии, когда множество возможных сценариев дальнейшего развития событий сворачивается в один, наиболее предпочтительный. С другой стороны, подход "в лоб" тоже не очень работает, поскольку если мы ставим знак равенства между количеством информации и энтропией, то получается, что максимальное количество информации нам даёт генератор случайных чисел (и наплевать, что семантическая значимость этой "информации" равна нулю).
15. Елена Казьмирук (e9953) 11.11.15 15:03 Сейчас в теме
Статья прекрасная! Прочитала с огромным удовольствием! Помогает по-другому смотреть на многие вещи. Вот как раз вчера вышел с коллегой очередной спор на тему, как нам вести очередной справочник. Теперь могу вооружиться красивыми цитатами. Спасибо!
16. Александр (kg_am) 74 11.11.15 16:22 Сейчас в теме
(15) e9953,
Спасибо на добром слове.
Только, умоляю, имейте в виду, что некоторые понятия за неимением ничего лучше мною здесь введены произвольно (в частности, "неустранимая погрешность объективации"), а некоторые представления (например, колесо управления) весьма далеки от общепринятых. Просто будьте готовы к тому, что иногда потребуются дополнительные пояснения.
17. Ден Вар (vardo) 38 11.11.15 17:01 Сейчас в теме
Этож надо так растечься мыслею по древу! По мне так не надо умножать сущностей сверх необходимого. Используйте бритву Оккама коллега.
18. Ден Вар (vardo) 38 11.11.15 17:03 Сейчас в теме
Но за труды и подход плюс
adhocprog; +1 Ответить
19. Александр (kg_am) 74 11.11.15 17:15 Сейчас в теме
(17) vardo,
В смысле, предлагаете не париться и внедрять типовые?
20. Ден Вар (vardo) 38 11.11.15 18:07 Сейчас в теме
(19) kg_am, Любая система оперирует сущностями объектов НСИ как уникальными единицами, квантами информации. В типовых конфигурациях уникальность определяется строкой записи объекта, если этого не достаточно в конкретном прикладном решении то разрабатывается свои правила уникальности объекта. Иногда на словах иногда кодом. По этому не увидел особой проблемы на такое количество строк текста. Хотя написано красиво.
Возможно тут ключевая фраза: "Мои слова легко понять и легко осуществить. Но люди не могут понять и не могут осуществлять."
21. Александр (kg_am) 74 11.11.15 18:29 Сейчас в теме
(20) vardo,
В том-то и юмор, что обслуживаемые НСИ системы используют в качестве этих самых квантов не объекты НСИ, а свои собственные объекты. Например, УТ записывает в свои регистры значения из своего локального справочника "Номенклатура", БП - из своего. Говорить о том, что системы оперируют объектами НСИ можно было бы только в том случае, если бы мы как-то особо мощно извернулись и сделали так, чтобы системы коннектились онлайн к единому хранилищу сущностей и совместно пользовали физически одни и те же данные. К счастью, до такого диковинного извращения никто не доходит, и поэтому НСИ - это всегда не условное УТ и не условная БП, а нечто третье, которое, возможно и включено в одну из систем, но живущее немножко отдельной жизнью, потому что имеет свои собственные цели и задачи.
22. Владимир Гусев (adhocprog) 1077 11.11.15 19:58 Сейчас в теме
Вспомнил занятия по философии: "Золотых гор не бывает" - неправильно. Правильно: "Не бывает нечто, похожее одновременно и на гору, и на золото" :)
23. Олег Филиппов (comol) 2689 12.11.15 11:47 Сейчас в теме
Что это? О чём это? Самое главное ЗАЧЕМ это? И зачем это тут?
24. Александр (kg_am) 74 12.11.15 11:57 Сейчас в теме
(23) comol,
Сложно объяснить в двух словах.
25. Евгения Карук (ekaruk) 2645 24.11.15 11:51 Сейчас в теме
Вроде очевидные вещи, но отлично сгруппированы и классифицированы.
Ну и сам стиль письма у автора просто великолепный.
Приятно читать.
26. Александр (kg_am) 74 24.11.15 16:17 Сейчас в теме
(25) ekaruk,
Спасибо. Да, естественно, очевидные вещи, но так получилось, что они оказались закопаны под кучу мифов. Всё бы ничего, но иногда такое положение дел начинает сильно мешать.
27. Доминант ГК (ingmar) 26.11.15 11:50 Сейчас в теме
Рецепта нет, есть философия и не более, такая же неприменимая к реальности, как и централизация.
28. Андрей Акулов (DrAku1a) 1188 02.12.15 09:27 Сейчас в теме
Честно, под конец ожидал увидеть подпись - Лао-цзы.
ponaroshku; +1 Ответить 1
29. Александр (kg_am) 74 02.12.15 14:53 Сейчас в теме
(27) ingmar,
На философию не наезжайте, пожалуйста, ведь единственная ей альтернатива - это мифологизированное мышление, на основании которого ничего реально работающего (по крайней мере, в технике) создать невозможно.
30. Александр (kg_am) 74 02.12.15 14:53 Сейчас в теме
(28) DrAku1a,
Не, мне в дурку пока рано :)))