УДК 004.37.01

А.Х. Жиляев,
Институт информатики и
проблем регионального управления
КБНЦ РАН, н.с., г.Нальчик.

Введение

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

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

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

Для обозначения подобной справочной информации в англоязычной литературе используется термин Master Data (мастер-данные, основные данные), а задачи управления ею получили название Master Data Management (MDM).. Однако, в русском языке сейчас чаще применяется понятие нормативно-справочная информация (НСИ), которое появилось в дисциплинах, касающихся управления народным хозяйством, еще в докомпьютерные времена. В данном случае определение “нормативная” отражает тот факт, что проблема создания справочников должна решаться с учетом отраслевых, государственных и международных стандартов.

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

Рис. 1 Уровни информационной системы

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

Разработка полноценного программного обеспечения для управления НСИ началась всего несколько лет назад. Ведущие производители программного обеспечения в последнее время уделяют все больше внимания средствам управления НСИ (в англоязычном варианте MDM, Master Data Management – управление основными данными).

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

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

Роль НСИ в информатизации региона

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

Особая роль НСИ отводится также в программах информатизации отраслей и ведомств. Например, в опубликованном 31 марта 2010г. проекте Концепции Информатизации Здравоохранения особо подчеркивается, что информационные системы в здравоохранении должны проектироваться с учетом стандартов и регламентов и базироваться на единой НСИ. (В состав НСИ, применяемой в сфере здравоохранения, социального развития и трудовых отношений Российской Федерации входит всего 163 различных классификаторов и справочников)..

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

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

Примером инициативы в этой области является стандарт e-GMS (UK GoverNmeNt Metadata StaNdard), принятый в Великобритании. . Многие страны взяли за основу, так называемое «Дублинское ядро», включающее 15 элементов описания информации:

• заголовок;
• автор или создатель;
• тема и ключевые слова;
• описание;
• публикатор;
• другие контрибуторы;
• дата;
• тип ресурса;
• формат;
• идентификатор ресурса;
• источник;
• язык;
• связи;
• область (coverage);
• управление правами.

Помимо самих элементов в «Дублинском ядре» имеются, так называемые, уточнения элементов, например: «Дата создания», «Дата публикации», «Дата окончания действия» и пр. Страны могут не только использовать это ядро, но и добавлять к нему любые дополнительные элементы, которые они считают необходимыми. Кроме того, первым инструментом при поиске информации, как правило, является просмотр категорий. Поэтому в рамках инициатив разработки стандартов на государственные метаданные определяются стандарты на список категорий (инструмент первичного поиска без использования ключевых слов).

Выводы

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

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

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

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

• стандарты данных;
• стандарты межведомственного обмена информацией;
• стандарты метаданных (и поиска информации);
• стандарты безопасности.

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

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

Литература:
1. "Стратегия развития информационного общества в Российской Федерации" (утв. Президентом Российской Федерации 07 февраля 2008 г. № Пр-212);
2. Проект постановления Правительства РФ "О порядке формирования и использования базовых классификаторов, справочников и реестров при оказании государственных и муниципальных услуг в электронной форме" от 31.08.2010 г.
3. "Обзор НСИ", Издание Минэкономразвития, 2010г
4. "Концепция создания информационной системы в здравоохранении на период до 2020 года», 2010г.
5. Полотнюк И. "Метаданные как базис интеграции", PC Week/RE (492), 2005г.
6. Ray Wang, Rob Karel. «Trends 2008: Master Data Management» 2008.

Роли конфигурации делятся на следующие группы:
Производство
Торговля и склад
Финансы
Зарплата и управление персоналом
Внеоборотные активы и спецодежда
Анализ и планирование
Регламентированный учет
Настройка НСИ
Торговое оборудование
Административные
Сервисные

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

Финансы

• Банковские операции - предоставляет права на выполнение операций с банковскими документами.
• Ввод заявок на расходование средств - предоставляет права на оформление документов "Заявка на расходование средств" и "Закрытие заявок на расходование средств".
• Выплата зарплаты - роль назначается совместно с ролями "Кассир", "Банковские операции". Роль предоставляет права на оформление документов:
  
  
  • "Приходный кассовый ордер" с видами операций:
    
    
    • Возврат денежных средств работником
  • "Расходный кассовый ордер" с видами операций:
    
    
    • Расчеты по кредитам и займам с работниками
    • Выплата заработной платы по ведомостям
    • Выплата заработной платы работнику
    • Выплата депонированной заработной платы
    • Выдача денежных средств в кассу ККМ
  • "Платежное поручение исходящее" с видами операций:
    
    
    • Расчеты по кредитам и займам с работниками
    • Перечисление заработной платы
• Кассир - предоставляет права на оформление кассовых документов.
• Обмен данными с программами Клиент-банк - назначается пользователю, если ему необходимо иметь возможность использовать обработку "Клиент-банк".
• Подотчетные лица - предоставляет права на оформление документов по подотчетным лицам.
• Согласование заявок на расходование ДС - предоставляет права на согласование заявок.
• Финансист – предоставляет права на отражение операций управления денежными средствами в управленческом учете.

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

• Бюджетирование – предоставляет права для работы с подсистемой бюджетирования.
• Планирование – предоставляет права для работы с подсистемой планирования.
• Учет затрат - предоставляет права к данным учета затрат и себестоимости номенклатуры по управленческому и регламентированному учетам.

• Бухгалтер МСФО – предоставляет права на отражение хозяйственных операций в МСФО.
• Выполнение регламентных операций по регламентированному учету - предоставляет права для проведения регламентных документов по регламентированному учету (БУ и НУ).
• Отражение в регламентированном учете - предоставляет права для проведения документов по бухгалтерскому и налоговому учету, а также права для формирования отчетов подсистемы бухгалтерского и налогового учета.
• Просмотр данных регламентированного учета - предоставляет права для просмотра данных бухгалтерского и налогового учета, а также права для формирования отчетов подсистемы бухгалтерского и налогового учета.
• Регламентированная отчетность - предоставляет права для использования регламентированной отчетности. Роль используется совместно с ролью "Отражение в регламентированном учете".
• Право на защищенный документооборот с налоговыми органами - Роль предоставляет право на использование встроенного механизма информационного взаимодействия с ФНС по каналам связи. Роль назначается совместно с ролью "Регламентированная отчетность".
• Учет НДС - предоставляет права к объектам подсистемы НДС, проведению регламентных операций по НДС и формированию отчетов по НДС.
• Учет РБП - предоставляет права к учету расходов будущих периодов.

• Администратор ККМ - предоставляет права на настройку касс ККМ и закрытие кассовой смены.
• Использование торгового оборудования - назначается пользователю, если ему необходимо иметь возможность использовать торговое оборудование.
• Настройка торгового оборудования - назначается пользователю, если ему необходимо иметь возможность настраивать торговое оборудование.
• Оператор ККМ - предоставляет права на оформление документа по розничным продажам "Чек ККМ".

Административные

• Администратор пользователей - предоставляет права для администрирования пользователей.
• Полные права - предоставляет доступ ко всем объектам конфигурации и предназначена для выполнения сервисных операций:
  
  
  • обновление ИБ
  • удаление помеченных на удаление объектов
  • работа с журналом регистрации
  • и т.п.
  Не рекомендуется работать в системе на постоянной основе под ролью "Полные права", в том числе выполнять бизнес-операции.
• Установка даты запрета изменения данных - назначается пользователю, если ему необходимо иметь возможность устанавливать дату запрета редактирования данных.
• Право администрирования - назначается пользователю, если ему необходимо выполнять административные функции и работать монопольно.

Сервисные

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

Также в конфигурации определена роль "Пользователь ". Эта роль дает доступ на вход в программу и назначается всем пользователям автоматически (при изменении ролей пользователей в режиме предприятия).

Сабир Асадуллаев и Александр Карпов
Опубликовано 09.11.2010

Основные понятия и терминология

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

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

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

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

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

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

При этом НСИ и МД имеют много общего, поэтому в тех случаях, когда рассматриваемые факторы касаются и НСИ, и МД, мы будем упоминать их как «НСИ и МД», например, «система ведения НСИ и МД».

Общие недостатки традиционного ведения НСИ и МД

Наиболее распространенной и очевидной проблемой традиционного ведения НСИ и МД является отсутствие поддержки временных изменений. Адрес, как правило, является одной из важнейших компонент НСИ и МД. К сожалению, адреса меняются. Клиент может переехать, но может «переехать» целый дом и даже улица. Так, в 2009 году адрес комплекса зданий «Башня на набережной» изменился с «Краснопресненская набережная, дом 18» на «Пресненская набережная, дом 10». Таким образом, запрос “Какое количество корреспонденции было доставлено в офис компании, арендующей помещения в «Башне на набережной» в 2009 году?” должен корректно обрабатывать записи о доставках с двумя разными адресами.

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

Таким образом, корпоративное ведение НСИ и МД включает в себя три категории мероприятий:

1. Методологические мероприятия, определяющие методы, регламенты, стандарты, процессы и роли, поддерживающие весь жизненный цикл ведения НСИ и МД
2. Организационные мероприятия, определяющие в соответствии с методологическими требованиями, организационною структуру, функциональные подразделения и их задачи, роли и должностные обязанности сотрудников.
3. Технологические мероприятия, лежащие на уровне ИТ и обеспечивающие исполнение организационных и методологических мероприятий.

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

Технологические недостатки ведения НСИ и МД

Нет единой модели данных НСИ и МД

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

Модель данных является основной и самой важной частью ведения НСИ и МД, отвечая, к примеру, на следующие вопросы:

• что включать в идентифицирующие атрибуты объекта НСИ и МД?
• что из всех атрибутов объекта НСИ и МД хранить в модели данных и отнести к НСИ и МД, а что отнести к операционным данным и оставить в эксплуатируемой информационной системе?
• как провести интеграцию по модели с внешними идентификаторами и классификаторами (ОКПО, ОКУД)?
• дает ли совокупность двух атрибутов из различным ИТ систем третий уникальный и важный с точки зрения бизнеса атрибут?

Нет единого регламента ведения истории и архивации

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

Пример проблем, вызванных отсутствием ведения исторической нормативно-справочной информации приведен в разделе «»

Сложность отождествления объектов НСИ и МД

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

Возникновение дубликатов объектов НСИ и МД

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

Несогласованность метаданных НСИ и МД

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

Ссылочная целостность и синхронизация модели НСИ и МД

В реальной жизни все объекты НСИ и МД, находящиеся в пространстве своей IT системы, содержат в себе не только значения, но и ссылки на другие НСИ и МД, которые могут находиться (и вестись) в отдельных внешних системах. Здесь в полный рост встает проблема синхронизации и поддержки целостности всей модели НСИ и МД организации. Одним из общепринятых путей решения такого рода проблем является переход к использованию НСИ и МД которые ведутся и импортируются в организацию извне (к примеру, справочники КЛАДР, ОКВЭД, ТН ВЭД, ФСКП и ЕКПС).

Рассогласование жизненного цикла объекта НСИ и МД

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

Выработка правил очистки

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

Неверный выбор мастер-системы ведения НСИ и МД

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

Неготовность ИТ систем к интеграции НСИ и МД

Для того, чтобы полноценно внедрить ведение НСИ и МД в существующие ИТ системы предприятия, необходимо провести интеграцию этих систем и, чаще всего, эта интеграция необходима не как единовременный и локализованный акт, а как изменение процессов, живущих внутри ИТ систем. Помимо интеграции для работы в операционном режиме (online), необходимо провести интеграцию для проведения первоначальной пакетной загрузки данных (ETL), а также для проведения процедур ручной сверки (реконсиляции).

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

Примеры проблем традиционного ведения НСИ и МД

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

Паспортные данные как уникальный идентификатор

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

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

Адрес как уникальный идентификатор

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

Необходимость массового переоформления договоров

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

Расхождение согласованных данных

Четвертый пример описывает типичную ситуацию для многих организаций. В результате бурного развития бизнеса предприятия было решено открыть новое направление, поддерживающее работу с клиентами в стиле B2C / B2B через Интернет. Для этого была приобретена новая ИТ система, поддерживающая автоматизацию нового направления бизнеса компании. При развертывании возникла необходимость провести интеграцию с существующими НСИ и мастер-данными предприятия и расширить их специфичными атрибутами, что оказалось не так просто, в первую очередь из-за отсутствия выделенной системы НСИ и МД. В результате НСИ были однократно загружены в новую систему безо всякой обратной связи с существующим ИТ ландшафтом компании, что через некоторое привело к двум независимым версиям клиентских справочников. Поначалу проблема решалась путем ручной обработки клиентских данных в электронных таблицах, однако через некоторое время количество клиентов значительно возросло, справочники «разошлись», и ручная обработка оказалась неэффективной и дорогой. В результате ситуация привела к серьезной эскалации проблемы на уровне бизнес - пользователей, не имеющих общей картины о своих клиентах для проведения маркетинговых акций.

Преимущества корпоративного ведения НСИ и МД

Корпоративное ведение НСИ и МД обеспечивает следующие преимущества:

• Выполнение требований закона и снижение рисков
• Снижение затрат
• Повышение гибкости для поддержки новых бизнес стратегий.

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

Выполнение требований закона и снижение рисков

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

Рост прибылей и удержание клиентов

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

Снижение затрат

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

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

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

Архитектурные принципы системы ведения НСИ и МД

Ресурсы для скачивания

static.content.url=http://www.сайт/developerworks/js/artrating/

Zone=Information Management

ArticleID=577045

ArticleTitle=Ведение НСИ на практических примерах

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

Так что же такое ERP нового поколения? Что нужно понимать сегодня об этом термине? - Вот на что мы хотим обратить ваше внимание.

Еще в 2013 году Gartner вводит новый термин: "постмодерновая ERP ". Которая представляет собой не монолитную систему, как у нас принято воспринимать ERP продукт, а информационное пространство интегрированных приложений, которое развивается и комплектуется по мере роста уровня и потребностей предприятия. Это некий синтез облачных сервисов, приложений на различных платформах, локальных систем и т.д., которые позволяют предприятию быть гибким, быстро внедрять новые продукты, использовать накопленные данные в сквозных процессах, внедрять лучшие предложения от разработчиков, обновлять свой портфель программного обеспечения (быстро менять "старое" на более продвинутый "новый" продукт), автоматизировать процессы пошагово, в соответствии с возможностями и потребностями.

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

Трансформация на ERP нового поколения - вот вызов, который стоит сейчас перед бизнесом и IT компаниями.

Что мы можем предложить?

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

Примеры внешних модулей, интегрируемых через IPaaS :

CRM (Small Business) - система для малого бизнеса. CRM как SaaS-сервис: просто, легко, доступно. MRP (Small Manufacture) - система для автоматизации процессов небольшого производства, работающих "под заказ". Atom.PharmDist: Аналитический сервис для фармацевтических компаний amoCRM - интегрированная CRM система. Эффективный лид менеджмент. Модуль интеграции 1С:Підприємство с Новой Почтой Модуль "Сервисное обслуживание"

Cloud ERP

Облачные ERP-системы позволяют компаниям:

• сократить первоначальные затраты на разработку,
• ускорить время развертываения и масштабирования
• упрощения настроек, соответствующих их уникальным потребностям.

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

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

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

Интеграционная Платформа IPaaS: интеграция приложений c ERP системой.

Документация ERP 2 для Украины (бета-версия)

Официальная документация поставляется только при поставке программного продукта

Концепция и функциональные возможности ERP

Описание блоков функциональных возможностей. Концепция решеня. Функции ERP: описание и сравнительный анализ.

Клиенты

Сегодня в Украине крупные компании внедряют ERP:

Инструкции пользователя для BAS ERP Украина

Документация и пользовательские инструкции к продукту BAS ERP Украина

Инструкции ERP

Описание использование функционала для решения конкретных задач в системе. Пользовательские инструкции и кейсы.

Документация ERP

Официальная документация к продукту от вендора поставляется только при покупке продукта

Дополнительные модули к ERP

Дополнительные готовые модули, расширяющие функционал основного решения 1С:Підприємство ERP

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

Intelligent Enterprise: Каковы были основные цели при внедрении НСИ и на какие основные этапы можно разбить решение этой задачи?

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

И в конце 2014 года мы инициировали проект по оптимизации работы с нормативно-справочной информацией. В его рамках были разработаны методики по нормализации нескольких основных групп справочников — «Номенклатура», «Контрагенты», «Сотрудники», «Финансовые» и «Технологические», - а также методики по их управлению.

В организационные рамки проекта вошло головное предприятие нашей компании, расположенное в городе Колпино, и два филиала - «Петрозаводскмаш» и «Атоммаш» из Волгодонска.

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

В первую очередь речь идет о целом спектре прикладных бизнес-систем универсального назначения. Это два решения по управлению ресурсами предприятия - SAP ERP и «1С:УПП» и два по управлению персоналом - SAP HR и «1С:ЗУП». Сюда же следует отнести электронный документооборот на базе «1С:Документооборота», продукт «1С:Консолидация», а также разработку для учета расходов на мобильную связь «1С:Мобильная связь». Кроме того, контур захватывал специализированные для нашей производственной деятельности продукты: TeamCenter (Siemens PLM Software), ответственный за конструкторскую и технологическую подготовку производства, систему ведения архива технической документации предприятия и управления данными об изделиях Search компании «Интермех», справочно-информационную систему управления базой данных IMBASE того же производителя и систему управления доступом и его контроля Perco. Задействованными оказались и инфраструктурные продукты - контроллер домена ActiveDirectory и корпоративный портал MS SharePoint.

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

Интересно было бы услышать и про методологические акценты в работе с нормативно-справочной информацией…

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

Назову основные цели, к которым мы при этом стремились.

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

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

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

В-четвёртых, в справочнике не должно быть дублирующих записей.

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

Сам процесс нормализации также делится на несколько этапов.

На этапе подготовительных работ проводится настройка классификаторов и определяются правила обработки «сырых» данных.

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

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

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

Формирование эталонной записи: после классификации проводится поиск эталонной записи по значению класса и набору значений характеристик, и если запись найдена, то «сырая» запись относится к ней. Если же эталонная запись не найдена, то она создается с указанным значением класса и характеристик.

Обработка данных МДМ-системы в системе-подписчике - на этом этапе обновляются существующие записи объектов НСИ в системе-подписчике либо добавляются новые.

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

А вот за обмен данными с системами-подписчиками отвечает интеграционная шина, которая связывает объекты в различных системах по кодам МДМ.

Существует ли специфика построения системы управления НСИ для крупных машиностроительных предприятий и в чем она заключается?

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

Каких элементов в данном случае касается выстроенная вами система НСИ - материалов, инструмента, операций, квалификации персонала, поставщиков или других компонентов?

В нашем проекте была разработана методология ведения целого ряда справочников, разбитых на пять групп: номенклатура, контрагенты, сотрудники, финансовые и технологические. Если говорить о составляющих эти группы справочниках, то они действительно описывают те компоненты, о которых вы только что сказали, а также многие другие. К примеру, в разделе «Номенклатура» есть такие справочники, как «Основные материалы», «Инструмент», «Оснастка и инвентарь», «Продукция». В соответствующих группах есть справочники под названием «Контрагенты», «Сотрудники», «Штатные должности», «Рабочие центры» или, скажем, «Статьи движения денежных средств». Словом, справочников у нас более двадцати, и они весьма подробно охватывают все стороны деятельности компании «АЭМ-Технологии», будь то финансовая, производственная активность или же управление персоналом. При этом в случае работы со справочниками номенклатуры - источником данных выступает МДМ-система, а подписчиками - учетные системы и системы проектирования. А вот при работе со справочником «Сотрудники» источником является система управления персоналом, а МДМ-система играет роль системы-подписчика и интеграционной шины для учетных систем.

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

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

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

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

Если о продуктовой и организационной стороне вопроса говорить коротко, то в качестве ключевого продукта ИТ-поддержки у нас выступали «1С:MDM Управление нормативно-справочной информацией», а также Axelot Datareon ESB. Компания Axelot являлась основным партнером по внедрению.

В развитии системы нормативно-справочной информации всегда заинтересованы многие службы компании. Как эту заинтересованность лучше учитывать в структуре управлениЯ проектами?

Особую роль как в проекте внедрения, так и при последующей эксплуатации МДМ-системы выполняют эксперты НСИ. От их лояльности, трудоспособности и профессиональных компетенций на 80% зависит успех проекта. Именно они определяют правила работы с информацией. Причем это сотрудники из различных областей: для группы справочников «Номенклатура» и «Технологические» это техническая дирекция, для группы «Контрагенты» - канцелярия, для справочников «Финансовые» - бухгалтерия и финансисты, для «Сотрудников» - дирекция по управлению персоналом. Роль ИТ-службы в развитии проекта - помочь собрать или сформулировать требования, собранные данные согласовать со всеми участниками бизнес-процесса, обеспечить техническую реализацию и дальнейшее сопровождение инструмента по ведению справочников. А вот владельцем процесса управления НСИ является бизнес, и только от бизнес-заказчиков зависит, будет этот процесс развиваться или нет.

С Олегом Апанасиком беседовал ведущий эксперт Intelligent Enterprise Сергей Костяков