Mom and Dad`s Misery

Публикация № 416675

Управление - Управленческий учет (прочее)

НСИ

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

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. CheBurator 3440 10.11.15 01:42 Сейчас в теме
Полезная статья.
Нашел для себя интересного, созвучного имеющимся проблемам.
ElizaMilos; Evil Beaver; +2 Ответить
2. kg_am 137 10.11.15 11:12 Сейчас в теме
(1) CheBurator, Спасибо на добром слове!
3. Программулькин 294 10.11.15 18:03 Сейчас в теме
ты чё курил? отсыпь, я тоже хочу!
Steelvan; comol; adhocprog; +3 Ответить
5. kg_am 137 10.11.15 23:01 Сейчас в теме
(3) Программулькин,
Не, такой травы не бывает. Такое только под эндорфинами ;)
4. WhiteOwl 363 10.11.15 18:27 Сейчас в теме
Браво! Чудесный слог))
pbabincev; Aphanas; adhocprog; +3 Ответить
6. CheBurator 3440 11.11.15 01:11 Сейчас в теме
Мои несогласия с автором заключаются в том, что говорит онто хорошо, но рецептов хоть каких-то нет. Да, централизовать это типо плохо потому что НСИ получится в центре контекстно-зависимое от центра - типа поэтому создадим "облако" НСИ - это зашибись. Осталось определить как НСИ нижнего уровня будут "переводиться" в НСИ более высокого уровня (а по этому кардинальному вопросу - молчок...) - и здесь мы снова попадаем по кругу (тавтология) - снова надо создавать НСИ-переводчик-конектор для трансляции снизу-вверх.... а это вообщем и есть основная задача... Ибо количество связей такого облака с вышестоящей иерархией (и не одной!) будем более чем дофига
Sei Souma; ivan_luzinov; ander_; Lapitskiy; charushkin; Fabler; +6 Ответить
10. kg_am 137 11.11.15 12:50 Сейчас в теме
(6) CheBurator,
Совершенно согласен с тем, что предложение задуматься о децентрализации при решении задачи управления НСИ выглядит по меньшей мере парадоксально. Как и, например, предложение присесть чуть пониже, чтобы подпрыгнуть чуть повыше :)

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

Само собой разумеется, что в некоторых простых случаях централизованное ведение и push-распространение - это именно то, о чём следует мечтать. Например, вести децентрализованно справочник валют смысла нет вообще никакого. Нет и не может быть с нашей точки зрения там никакой субъектной и контекстной зависимости. Но когда речь идёт о той же номенклатуре, то напрашивающееся простое "деревянное" решение - это наверняка не то, что "взлетит". В этом случае трезвый взгляд на происходящее и применение инструментального подхода (именно его я проповедую в разделе 2.3) способно дать набор пусть и не идеальных, но вполне жизнеспособных решений.
7. Evil Beaver 6960 11.11.15 09:29 Сейчас в теме
Мне нравится Ваш слог. И статья отличная!

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

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

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

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

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

Но вы ничего не сказали о том каким должен быть следующий шаг развития.
И в связи с этим у меня к Вам возник вопрос:
- О следующем шаге вы умолчали сознательно, что бы сохранить конкурентное преимущество или считаете, что описанных Вами мер, на сегодняшний день достаточно с запасом?
12. kg_am 137 11.11.15 14:12 Сейчас в теме
(9) Fabler,

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

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

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

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

Какой должен быть следующий шаг, спрашиваете? Не знаю. Всё зависит от того, куда нужно прийти :)
В любом случае, умение адекватно рассуждать о том, что может встретиться на пути, лишним не будет.
mvxyz; DDA4746; voneska7; Evil Beaver; +4 Ответить
11. ildarovich 7201 11.11.15 13:23 Сейчас в теме
Согласно закону Эшби для того, чтобы управлять, например, функционированием крупного машиностроительного холдинга, нужно обладать разнообразием не меньшим, чем разнообразие этого холдинга.

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

С одной стороны, конечно, управление можно рассматривать как снижение энтропии, когда множество возможных сценариев дальнейшего развития событий сворачивается в один, наиболее предпочтительный. С другой стороны, подход "в лоб" тоже не очень работает, поскольку если мы ставим знак равенства между количеством информации и энтропией, то получается, что максимальное количество информации нам даёт генератор случайных чисел (и наплевать, что семантическая значимость этой "информации" равна нулю).
15. e9953 11.11.15 15:03 Сейчас в теме
Статья прекрасная! Прочитала с огромным удовольствием! Помогает по-другому смотреть на многие вещи. Вот как раз вчера вышел с коллегой очередной спор на тему, как нам вести очередной справочник. Теперь могу вооружиться красивыми цитатами. Спасибо!
16. kg_am 137 11.11.15 16:22 Сейчас в теме
(15) e9953,
Спасибо на добром слове.
Только, умоляю, имейте в виду, что некоторые понятия за неимением ничего лучше мною здесь введены произвольно (в частности, "неустранимая погрешность объективации"), а некоторые представления (например, колесо управления) весьма далеки от общепринятых. Просто будьте готовы к тому, что иногда потребуются дополнительные пояснения.
17. vardo 53 11.11.15 17:01 Сейчас в теме
Этож надо так растечься мыслею по древу! По мне так не надо умножать сущностей сверх необходимого. Используйте бритву Оккама коллега.
19. kg_am 137 11.11.15 17:15 Сейчас в теме
(17) vardo,
В смысле, предлагаете не париться и внедрять типовые?
20. vardo 53 11.11.15 18:07 Сейчас в теме
(19) Любая система оперирует сущностями объектов НСИ как уникальными единицами, квантами информации. В типовых конфигурациях уникальность определяется строкой записи объекта, если этого не достаточно в конкретном прикладном решении то разрабатывается свои правила уникальности объекта. Иногда на словах иногда кодом. По этому не увидел особой проблемы на такое количество строк текста. Хотя написано красиво.
Возможно тут ключевая фраза: "Мои слова легко понять и легко осуществить. Но люди не могут понять и не могут осуществлять."
21. kg_am 137 11.11.15 18:29 Сейчас в теме
(20) vardo,
В том-то и юмор, что обслуживаемые НСИ системы используют в качестве этих самых квантов не объекты НСИ, а свои собственные объекты. Например, УТ записывает в свои регистры значения из своего локального справочника "Номенклатура", БП - из своего. Говорить о том, что системы оперируют объектами НСИ можно было бы только в том случае, если бы мы как-то особо мощно извернулись и сделали так, чтобы системы коннектились онлайн к единому хранилищу сущностей и совместно пользовали физически одни и те же данные. К счастью, до такого диковинного извращения никто не доходит, и поэтому НСИ - это всегда не условное УТ и не условная БП, а нечто третье, которое, возможно и включено в одну из систем, но живущее немножко отдельной жизнью, потому что имеет свои собственные цели и задачи.
18. vardo 53 11.11.15 17:03 Сейчас в теме
Но за труды и подход плюс
adhocprog; +1 Ответить
22. adhocprog 1196 11.11.15 19:58 Сейчас в теме
Вспомнил занятия по философии: "Золотых гор не бывает" - неправильно. Правильно: "Не бывает нечто, похожее одновременно и на гору, и на золото" :)
23. comol 4496 12.11.15 11:47 Сейчас в теме
Что это? О чём это? Самое главное ЗАЧЕМ это? И зачем это тут?
24. kg_am 137 12.11.15 11:57 Сейчас в теме
(23) comol,
Сложно объяснить в двух словах.
25. ekaruk 5338 24.11.15 11:51 Сейчас в теме
Вроде очевидные вещи, но отлично сгруппированы и классифицированы.
Ну и сам стиль письма у автора просто великолепный.
Приятно читать.
burmsergey; +1 Ответить
26. kg_am 137 24.11.15 16:17 Сейчас в теме
(25) ekaruk,
Спасибо. Да, естественно, очевидные вещи, но так получилось, что они оказались закопаны под кучу мифов. Всё бы ничего, но иногда такое положение дел начинает сильно мешать.
27. ingmar 26.11.15 11:50 Сейчас в теме
Рецепта нет, есть философия и не более, такая же неприменимая к реальности, как и централизация.
29. kg_am 137 02.12.15 14:53 Сейчас в теме
(27) ingmar,
На философию не наезжайте, пожалуйста, ведь единственная ей альтернатива - это мифологизированное мышление, на основании которого ничего реально работающего (по крайней мере, в технике) создать невозможно.
28. DrAku1a 1419 02.12.15 09:27 Сейчас в теме
Честно, под конец ожидал увидеть подпись - Лао-цзы.
ponaroshku; +1 Ответить
30. kg_am 137 02.12.15 14:53 Сейчас в теме
(28) DrAku1a,
Не, мне в дурку пока рано :)))
37. burmsergey 10 27.11.20 09:44 Сейчас в теме
(28) Никакую другую подпись увидеть я не ожидал, но ассоциация у меня сформировалась: Карл Маркс.
31. mmo_repr 02.11.19 12:01 Сейчас в теме
Пример сбалансированного ведения НСИ: Элементы НСИ вводятся в подразделениях, но проходят модерацию группой экспертов в центре.
32. Sintson 381 11.12.19 17:56 Сейчас в теме
Спасибо, пару советов взял на заметку.
33. herfis 404 11.12.19 18:53 Сейчас в теме
Респект. Почти монография.
34. duhin 26.04.20 11:30 Сейчас в теме
Прекрасная статья, сформулированы мысли, которые понимал, но так литературно сформулировать не мог.
Вскользь затронута тема доброго и злого способа наведения порядка, если бы раскрыли поподробнее было бы страшно интересно. Ключевая проблема разработки, с которой сталкиваюсь каждый день. Считаю что для адекватной злой нужны космические затраты, нереальные в обычном энтерпрайзе, поэтому топлю за добрую. Не преуспеваю, поскольку думать надо больше, чем при наивной злой. "Но люди не могут понять".
Не понял заголовка(
35. herfis 404 27.04.20 14:41 Сейчас в теме
(34)
Не понял заголовка(

Я бы перевел как "родительская безысходность". Отражение того, что как не рожай и не воспитывай, но невпихуемое все равно не впихнешь и идеала не получится. Так и с НСИ. Слишком много многогранных требований, которые невозможно все удовлетворить и можно лишь балансировать между приоритетами. Ну, я это так понял.
36. duhin 27.04.20 16:43 Сейчас в теме
(35) Т.е. родители это мы, а чадо- это наша система учета НСИ. Спасибо, похоже. А то я вообще ничего не понял, прямо по Лао Цзы))
Оставьте свое сообщение

См. также

Принципы учета номенклатуры в конфигурациях УТ11 и ERP. Ошибки расчета себестоимости Промо

Управленческий учет (прочее) Бухгалтерский учет Оптовая торговля Учет ТМЦ Оптовая торговля Учет ТМЦ v8 ERP2 УТ11 КА2 УУ Бесплатно (free)

Основные регистры, используемые для учета номенклатуры в конфигурациях УТ11, КА2, ERP. Для чего используются все эти регистры, какие из них основные и какие вспомогательные. Основные ошибки в учете товаров и расчет себестоимости. Как проще находить и исправлять ошибки в учете.

06.01.2016    159674    ekaruk    80    

Рекомендации по внедрению параллельного учета РСБУ+МСФО на платформе 1С

Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) МСФО (GAAP) Управленческий учет (прочее) v8 v8::БУ ERP2 БП3.0 УХ Россия БУ Госбюджет УУ Бесплатно (free)

Анонсируется подход, единый при внедрении любой программы параллельного учета, будь то разработки фирмы 1С (ERP, УХ, ERP УХ, БП КОРП МСФО) или разработки фирм-франчайзи (БИТ, ФинПроСофт (ИТАН), Рарус и др.).

04.01.2020    6242    RayCon    10    

Учет по направлениям деятельности в конфигурациях УТ 11.4, КА 2.4, ЕРП 2.4

Управленческий учет (прочее) v8 v8::DataMining ERP2 УТ11 КА2 Россия УУ Бесплатно (free)

Как мне кажется, эта тема недостаточно освещена, и есть ряд недопониманий. Отсюда результат - неиспользование всех ее возможностей или неиспользование подсистемы целиком. В статье рассмотрены возможности по учету и анализу данных в разрезе направлений деятельности в управленческом учете. Приведены различия в данном механизме между конфигурациями УТ 11.4 и КА 2.4 (ЕРП 2.4).

13.11.2019    34422    ids79    58    

Информационные системы в оптовой торговле. Часть 5. Казначейский учет

Управленческий учет (прочее) Банковские операции Финансовый учет и бюджетирование (FRP) Дебиторская и кредиторская задолженность Кассовые операции Оптовая торговля Банковские операции Финансовый учет и бюджетирование (FRP) Дебиторская и кредиторская задолженность Кассовые операции Оптовая торговля Россия БУ УУ Бесплатно (free)

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

09.09.2019    4226    Ликреонский    12    

Иерархия IT-систем и выбор программного обеспечения для организации труда Промо

Управленческий учет (прочее) Бесплатно (free)

IT-системы плотно вошли в нашу жизнь. Мощные и сложные программные продукты используются в самых разных сферах. При этом многие забывают, что появились IT-системы не просто так, как программные продукты, которые нужно продавать и внедрять, а как инструменты организации и автоматизации труда.И очень важно помнить при выборе и внедрении IT-систем, что первичен здесь — труд, а не программное решение. Я не единожды сталкивался с тем, что люди выбирали программу просто потому, что: “она понравилась”. В результате появляются попытки “натянуть” процессное производство, например, работу молокозавода, на ERP-систему, предназначенную для дискретного производства (сборка изделий). 

23.03.2018    12109    raiml    16    

Коротко об основах бюджетного учета

Управленческий учет (прочее) Бухгалтерский учет v8::БУ БГУ Россия Госбюджет Бесплатно (free)

Основные принципы составления проводок в бюджетных организациях.

30.07.2019    20895    bpark21    9    

Виды задач, решаемых на Графах затрат (ч.4). Популярно о встречных затратах

Управленческий учет (прочее) Закрытие периода Производство готовой продукции (работ, услуг) Закрытие периода Производство готовой продукции (работ, услуг) Бесплатно (free)

Рассмотрены причины появления встречных затрат в модели для расчета себестоимости, а также рассмотрена ситуация, при которой появляются «очень» большие стоимости встречных затрат

20.05.2019    5332    Polav62    0    

Подробное описание работы механизма расчета себестоимости в программах начиная с версии ERP 2.1.3 (и соответствующих ей версий КА и УТ) Промо

Управленческий учет (прочее) Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) v8 ERP2 УТ11 КА2 БУ УУ Бесплатно (free)

Зачастую, когда встаёт вопрос о валовой прибыли предприятия, то большой проблемой становится корректная оценка себестоимости товаров. Для того, чтобы программисту было понятно, как программа рассчитывает себестоимость, нужно понимать алгоритмы, которых придерживались разработчики. Данная статья описывает, как это работает в актуальных (начиная с версии ERP 2.1.3 (и соответствующих ей версий КА и УТ)) версиях программы, и наиболее полезна для программиста. Данные алгоритмы описаны разработчиками в комментариях расчета себестоимости.

03.08.2017    51197    feva    17    

Безопасные вычеты по НДС

Управленческий учет (прочее) Россия БУ НДС Бесплатно (free)

Как определить безопасную долю вычетов по НДС

22.04.2019    3453    Ярина    0    

Виды задач, решаемых на Графах затрат (ч.2)

Управленческий учет (прочее) Закрытие периода Производство готовой продукции (работ, услуг) Закрытие периода Производство готовой продукции (работ, услуг) Бесплатно (free)

Рассмотрена задача расчета себестоимости в разрезе элементов затрат с помощью модели в виде Графа затрат.

21.04.2019    5050    Polav62    2    

Виды задач, решаемых на Графах затрат (ч.1)

Управленческий учет (прочее) Закрытие периода Закрытие периода Бесплатно (free)

Рассмотрена задача расчета прогнозных значений себестоимости с помощью модели в виде Графа затрат.

15.04.2019    5780    Polav62    1    

Математизация бухгалтерского учета. Графы затрат

Управленческий учет (прочее) Закрытие периода Закрытие периода Бесплатно (free)

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

11.04.2019    5895    Polav62    0    

Матричная форма записи СЛАУ для Графа затрат

Управленческий учет (прочее) Закрытие периода Закрытие периода Бесплатно (free)

СЛАУ для расчета себестоимости на Графе затрат записана в матричной форме. Рассмотрены другие полезные матрицы для работы с Графами затрат

24.03.2019    6759    Polav62    12    

Балансовые уравнения в Графе затрат

Управленческий учет (прочее) Закрытие периода Закрытие периода БУ Бесплатно (free)

Рассмотрен процесс составления балансовых уравнений - уравнений баланса затрат для Графа затрат.

18.03.2019    5348    Polav62    0    

Управление производством с 1С:ERP Промо

Производство готовой продукции (работ, услуг) Управленческий учет (прочее) Бухгалтерский учет Производство готовой продукции (работ, услуг) v8::ОУ v8::Бизнес-процессы ERP2 Россия БУ УУ Бесплатно (free)

Внедренческий центр "Раздолье" подготовил цикл учебных курсов по конфигурации "1С:ERP". Мы планируем постепенно выкладывать эти материалы на сайт Инфостарт. Это первая глава из курса по управлению производством в "1С:ERP".

30.11.2016    25460    1СERP    8    

Граф предприятия и Граф затрат

Управленческий учет (прочее) Бесплатно (free)

В статье рассмотрены математические модели хозяйственной деятельности предприятий в виде Графа предприятия и Графа затрат

10.03.2019    7120    Polav62    8    

Бухгалтерский учет и теория графов

Управленческий учет (прочее) Бесплатно (free)

В статье показано, что в основе математической модели любой системы бухгалтерского учета, использующей двойную запись, лежат абстрактные комбинаторные объекты, называемые графами

10.03.2019    7060    Polav62    4    

Криптовалюты в терминах 1С. Продолжение

Управленческий учет (прочее) Бесплатно (free)

Продолжение рассказа о криптовалютах в терминах 1С.

05.02.2019    5584    mkalimulin    18    

ERP Управление Предприятием 2.0. Сдельная оплата Промо

Управленческий учет (прочее) Бухгалтерский учет Зарплата Зарплата v8 УПП1 ERP2 БУ УУ Бесплатно (free)

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

24.11.2014    40346    PAVI    6    

Варианты развития систем бюджетирования

Финансовый учет и бюджетирование (FRP) Управленческий учет (прочее) Финансовый учет и бюджетирование (FRP) Россия УУ Бесплатно (free)

Современные системы бюджетирования достигли больших высот. Сложно представить сценарий, который нельзя было бы реализовать с помощью современных систем. Я давно занимаюсь бюджетированием, и уже больше года мы выполняем проекты автоматизации как команда Naumov.pro. Это статья - размышление на тему: куда могут развиваться системы бюджетирования в будущем. Делитесь в комментариях Вашими мыслями!

14.01.2019    5462    SergeyN    0    

Сложные схемы поступления товаров в УТ 11.4, КА 2.4, ЕРП 2.4

Бухгалтерский учет Учет ТМЦ Управленческий учет (прочее) Учет ТМЦ v8 v8::УФ ERP2 УТ11 КА2 БУ УУ Бесплатно (free)

Поступление товаров по схеме «Товары в пути», поступление неотфактурованного товара, настройки системы учета, новые объекты конфигурации, последовательность ввода документов, движения по регистрам накопления

31.12.2018    42105    ids79    41    

Обязательная маркировка товара в 2019 году. Порядок проведения

Управленческий учет (прочее) Оптовая торговля Розничная торговля Оптовая торговля Розничная торговля Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

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

12.12.2018    15638    alis112358    25    

1С Бухгалтерия 8. Часть 1: Настройка параметров учета Промо

Управленческий учет (прочее) v8 БП2.0 Россия БУ Бесплатно (free)

Залогом правильного ведения бухгалтерского и налогового учета в программе 1С Бухгалтерия 8 является правильная настройка параметров учета и учетной политики. Разработчики 1С постарались, чтобы эти настройки были простыми и понятными. Тем не менее, есть ряд подводных камней, о которые могут спотыкаться даже опытные пользователи.

05.11.2011    226018    vdi1950    124    

Партионный учет товаров в конфигурациях УТ, КА, ЕРП

Управленческий учет (прочее) Бухгалтерский учет Учет ТМЦ Учет ТМЦ v8 v8::УФ ERP2 УТ11 КА2 Россия УУ Бесплатно (free)

История развития, особенности реализации в текущих версиях ЕРП 2.4, КА 2.4, УТ 11.4, методы оценки стоимости запасов, примеры расчета стоимости списания

08.12.2018    58363    ids79    63    

Учет товаров по сериям в типовых конфигурациях УТ 11.4, КА 2.4, ЕРП 2.4

Бухгалтерский учет Учет ТМЦ Управленческий учет (прочее) Учет ТМЦ v8 v8::УФ ERP2 УТ11 КА2 Россия УУ Бесплатно (free)

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

02.12.2018    67430    ids79    153    

Интеркампани, особенности учета в конфигурациях УТ 11.4, КА 2.4, ЕРП 2.4

Бухгалтерский учет Учет ТМЦ Управленческий учет (прочее) Учет ТМЦ v8 v8::УФ ERP2 УТ11 КА2 Россия УУ Бесплатно (free)

Старая и новая методики учета «Интеркампани», недостатки применения старой методики, преимущества и особенности новой, выявленные нюансы.

21.11.2018    42122    ids79    88    

РАУЗ: составление уравнений для расчета себестоимости товаров в программе 1С:Управление торговлей, редакция 11 Промо

Управленческий учет (прочее) v8 УТ11 УУ Бесплатно (free)

Главная цель статьи - показать, как и какую систему линейных уравнений в рамках технологии РАУЗ составляет программа ут11 для расчета себестоимости товаров.

11.04.2013    79602    vdi1950    30    

Новая концепция учета по видам запасов в типовых конфигурациях 1С УТ 11.4, ЕРП 2.4

Учет ТМЦ Управленческий учет (прочее) Учет ТМЦ v8 ERP2 УТ11 Россия УУ Бесплатно (free)

О том, что предложили разработчики в конфигурациях ЕРП 2.4, УТ 11.4 для решения проблем с вариативностью видов запасов

18.11.2018    31233    ids79    22    

Контроль отрицательных остатков в конфигурациях: УТ 11.4, КА 2.4, ЕРП 2.4

Бухгалтерский учет Учет ТМЦ Управленческий учет (прочее) Учет ТМЦ v8 v8::УФ ERP2 УТ11 КА2 Россия УУ Бесплатно (free)

Подробный разбор всех присутствующих в конфигурациях УТ 11, КА 2, ЕРП 2 вариантов контроля отрицательных остатков: по организациям, складам, оперативный контроль

08.11.2018    66851    ids79    85    

Перевыставление услуг (приобретение агентом услуг для принципала). Агентский договор

Пользователю системы Управленческий учет (прочее) Бухгалтерский учет Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) v8 УПП1 БП3.0 Россия БУ НДС Бесплатно (free)

Множество компаний сталкивается с вопросом учета арендных отношений, а также коммунальных платежей, таких как электроэнергия, вода, теплоэнергия и прочих, связанных с арендуемыми помещениями. Данный вопрос особенно сложен в части налогообложения по НДС. Цель данной статьи - рассмотреть схему учета перевыставляемых услуг в УПП 1.3 в сравнении с БП 3.0, в которой данный функционал уже реализован.

05.10.2018    40641    el-le    6    

Распутывая узлы интеграции: Построение архитектуры слабосвязанных систем, или Кролики наступают

Интеграция Бесплатно (free)

Речь пойдет об интеграции систем. Кому вообще стоит обратить внимание на эту статью? Если у вас всего лишь две типовые конфигурации, то вам, наверное, эта тема будет не очень интересна – у вас нет тех проблем, с которыми сталкиваются люди, имеющие три системы и более. Но если у вас есть больше двух систем, а особенно, если есть веб-сайт, который обменивается с 1С, вам точно стоит это прочитать.

28.05.2018    24050    Evil Beaver    25    

Способы распределения затрат - прямой, пошаговый и с помощью СЛАУ

Закрытие периода Производство готовой продукции (работ, услуг) Управленческий учет (прочее) Закрытие периода Производство готовой продукции (работ, услуг) БУ УУ Бесплатно (free)

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

22.01.2018    17304    Polav62    10    

Локализация 1С приложений (адаптация продуктов под другие рынки)

Управленческий учет (прочее) Бесплатно (free)

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

19.01.2018    21196    ekaruk    28    

Как появляются встречные затраты

Управленческий учет (прочее) Бухгалтерский учет Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) БУ НУ УУ Бесплатно (free)

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

22.12.2017    12019    Polav62    5    

Статьи затрат и элементы затрат (часть 2)

Управленческий учет (прочее) Бухгалтерский учет Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) Россия БУ НУ УУ Бесплатно (free)

Как правильно применять статьи затрат и элементы затрат? Чем статьи затрат и элементы затрат отличаются друг от друга? Затраты и расходы предприятия

03.12.2017    19013    Polav62    8    

Статьи затрат и элементы затрат (часть 1)

Управленческий учет (прочее) Бухгалтерский учет Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) БУ НУ УУ Бесплатно (free)

Как правильно применять статьи затрат и элементы затрат? Чем статьи затрат и элементы затрат отличаются друг от друга? Затраты и расходы предприятия

25.11.2017    24681    Polav62    45    

1C:ERP, РАУЗ и встречный выпуск

Производство готовой продукции (работ, услуг) Управленческий учет (прочее) Производство готовой продукции (работ, услуг) v8 ERP2 УУ Бесплатно (free)

В статье рассматривается пример расчета себестоимости продукции и работ встречного выпуска применительно к 1С:ERP Управление предприятием 2.

15.11.2017    18873    ERP-master    9    

Система автоматизации управленческого учета как эффективный инструмент управления бизнесом

Управление бизнес-процессами (BPM) Управление проектом Управленческий учет (прочее) Россия УУ Бесплатно (free)

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

05.10.2017    10350    POPOK.BIZ    10    

Автоматизация учета по МСФО: выбор оптимального продукта на платформе 1С: Предприятие

Управленческий учет (прочее) Бесплатно (free)

Если Ваша компания собирается приступить к подготовке отчетности по международным стандартам или уже готовит при помощи трансформации средствами MS Excel, при этом менеджмент осознает трудоемкость данного процесса, возникает вопрос: «Какой информационный продукт лучше выбрать для автоматизации учета по МСФО?» В данной статье рассмотрены аргументы «за» и «против» линейки продуктов на платформе 1С:Предприятие.8, а именно «1С:Управление производственным предприятием» (1С:УПП), 1С:ERP, «1С:Управление корпоративными финансами» (1С:УКФ), БИТ.Финанс МСФО, «1С:Управление холдингом» (1С:УХ).

04.09.2017    15426    user821329    9    

Экспертная оценка: учет отложенных расходов в бюджете

Управленческий учет (прочее) Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) v8 Госбюджет Бесплатно (free)

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

21.07.2017    12717    Silenser    41    

Ведение взаиморасчетов в конфигурациях «Комплексная автоматизация 1.1» и «Управление производственным предприятием 1.3» - часть 2

Пользователю системы Управленческий учет (прочее) Бухгалтерский учет Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8 КА1 УПП1 Россия БУ УУ Бесплатно (free)

Детализация и порядок ведения взаиморасчетов с контрагентами в конфигурациях «Комплексная автоматизация 1.1» и «Управление производственным предприятием 1.3», типичные причины ошибок, их поиск и устранение. Часть 2.

22.06.2017    31612    stvorl    20