Нормативно-Справочная информация - условно-постоянный компонент корпоративной информации, являющийся основой для унификации и нормализации данных, сопровождающих протекающие бизнес-процессы, а также регламентацию деятельности организации. Другими словами, нормативно-справочная информация – это информационный ресурс компании, формируемый внутри и получаемый, как правило, извне. Она содержит стандарты, требования, правила, положения и прочую информацию, нормирующую и систематизирующую деятельность компании.
Требование обеспечения взаимодействия и унификации различных прикладных систем бизнес-процессов протекающих на http://en.wikipedia.org/wiki/Service_oriented_architecture предприятиях и в различных организациях, консолидации отчетной документации, приводит к необходимости построения системы нормативно-справочной информации. Систему нормативной справочной информации образуют группы объектов, построенных на общероссийских, отраслевых и корпоративных (внутренних) [классификаторах] и справочниках.
Основные проблемы НСИ в корпоративных информационных системах:
- Не в полном объеме используются Общероссийские классификаторы и справочники, разработанные государственными службами и утвержденные на федеральном уровне, предназначенные для актуального содержания информации с регулярным ее обновлением и выверкой:
- Общероссийские классификаторы, частично представленные в системах, не актуализируются и не нормализуются;
- Информация, в совокупности представляющая собой единое целое, разбита на несколько частей, собрана в отдельные справочники;
- Справочники систем дублируются по содержанию информации и функциональному использованию;
- Основной объем данных справочников не нормализован, ведение нормативно-справочной информации не регламентировано, в результате чего происходит дублирование информации при пополнении справочников. Отсутствует достаточность информации в записях справочников (записи не полно описаны);
- Основная доля представленных в системах классификаторов, имеет слабую структуру по признакам группировки информации, и является одноуровневой, что не обеспечивается гибкостью и информативностью классификации.
Информационные системы Нормативно-Справочной Информации .
Корпоративная система НСИ обеспечивает хранение , обработку и предоставление постоянной и условно-постоянной информации пользователям системы.
Системы НСИ предназначены для поддержания корпоративных данных в актуальном состоянии, обеспечению полноты, устранению ошибок, контролю целостности и непротиворечивости данных.
Модификация хранимых в системе НСИ данных и их структуры допускается только экспертами системы. Все действия по модификации данных строго регламентируются. Пользователями информации выступают прочие ИС предприятия, получающие данные через заранее определенные интерфейсы.
Такой подход обеспечивает корректность данных внутри предприятия вне зависимости от количества и разнообразия используемых ИС, устраняя дублирование информации разными подразделениями и упрощая построение сводных отчетов.
Термин НСИ имеет советское происхождение, хотя чёткого определения в СССР введено не было. На западе более подходящим аналогом НСИ является Master Data или Master Referenced Data, сутью которых является не-транзакционная нормализованная справочная информация (каталоги) и классификаторы (иерархии). Таким образом Master Data (Мастер данные) можно рассматривать только как подмножество понятия НСИ.
Системы Управления Справочниками можно приравнять к международному понятию Master Data Management (MDM), которые могут рассматриваться как часть Service-Oriented Аrchitecture (SOA).
Принципиальным является, что словари, стандарты, правила, нормативы, которые обыкновенно включают в понятие НСИ, не являются объектами систем MDM.
См. также
- Блог по НСИ Сабира Асадуллаева
- SAP Master Data Management
Ссылки
Wikimedia Foundation . 2010 .
Смотреть что такое "НСИ" в других словарях:
НСИ - несанкционированный съём информации Источник: http://www.energosys.ru/?nav=entr&id=6105 НСИ нормативно справочная информация; нормативная справочная информация юр. НСИ нашлемная система индикации в маркировке …
НСИ - нормативно справочная информация … Словарь сокращений русского языка
НСИ Банк - Банк Невастройинвест http://nsvbank.ru/ банк., организация, Санкт Петербург … Словарь сокращений и аббревиатур
НСИ Рунавик Полное название Nes Sóknar Ítróttarfelag Runavík Основан 1957 Стадион Рунавик … Википедия
Полное название Nes Sóknar Ítróttarfelag Runavík Основан 1957 Стадион Рунавик … Википедия
НСИ Рунавик Полное название … Википедия
Нескл., мн. (ед. манси, нескл., м. и ж.). Народ, составляющий коренное население Ханты Мансийского автономного округа РСФСР, а также лица, относящиеся к этому народу … Малый академический словарь
И грунши, груси, нескл., м. и ж … Русское словесное ударение
Манси, нескл., м. и ж. (народ) … Русское словесное ударение
ЕОС НСИ - единая отраслевая система управления нормативно справочной информацией Источник: rosatom.ru … Словарь сокращений и аббревиатур
Книги
- Интегрированные системы проектирования и управления. SCADA. Учебное пособие , Кузяков Олег Николаевич , Мартынюк Роман Васильевич , Музипов Халим Назипович , Хохрин Сергей Александрович , Чащина Маргарита Викторовна , В учебном пособии рассмотрены основные сведения о программах системы реального времени "Сириус-SCADA". Описана программа "Редактор БД НСИ", предназначенная для создания баз данных… Категория: Автоматика. Вычислительная техника Серия: Учебники для вузов. Специальная литература Издатель: Лань ,
- Интегрированные системы проектирования и управления. SCADA , Музипов Х.Н. , Рекомендовано Региональным отделением УрФО УМО вузов РФ по образованию в области радиотехники, электроники, биомедицинской техники и автоматизации в качестве учебного пособия для студентов… Категория:
Когда речь заходит о масштабах и сложности тех или иных информационных систем, обычно приводятся такие характеристики, как число рабочих мест и потоков обрабатываемых документов, общий объем баз данных. Однако в последнее время в качестве интегральной характеристики все чаще упоминают количество и размеры справочников. Несведущим людям это не очень понятно, но специалистам такие сведения говорят о многом. Ведь именно справочные данные (номенклатура товаров и изделий, реквизиты партнеров, поставщиков и клиентов, описание структуры организации и пр.) являются по сути информационным ядром системы управления предприятием, включающей учетные задачи, планирование ресурсов, , САПР и т. д.; они обеспечивают согласованность и консолидацию данных, устраняют избыточность информации и оптимизируют поиск нужных сведений. Кроме того, справочники объединяют все остальные документы системы - счета, договора, приказы и пр. - на протяжении всего ее жизненного цикла.
В настоящее время одна из наиболее важных проблем развития информационных технологий корпоративного уровня - интеграция данных. Довольно часто она понимается как умение работать с различными форматами данных из разных физических источников (в том числе и преобразовывать их из одного формата в другой). Но такое представление - по крайней мере поверхностно. На самом деле согласование и правильное понимание информации невозможно без ее содержательного осмысления с использованием единых справочников.
Рис. 1. Организация работы централизованной службы НСИ
Данная проблема актуальна во всем мире, но ее значение особенно велико для России, и тут можно выделить два момента:
Автоматизация отечественных компаний, как правило, развивалась снизу вверх, путем постепенной компьютеризации отдельных участков и подразделений. Помимо использования различных программно-аппаратных платформ в них применялись и локальные справочники, объединить которые - задача не из простых;
На современном этапе формирования рыночной экономики в нашей стране идут активные процессы слияния, поглощения, формирования холдинговых структур и т. д. В этом случае встают сложные задачи объединения информационных ресурсов, но зачастую уже на уровне законченных систем управления предприятиями.
Мы выделили эти два пункта, чтобы отметить принципиальные различия стоящих за ними ситуаций. В первом случае в общем-то можно говорить просто об ошибках при создании системы - нужно было изначально создавать единую справочную систему предприятия, реализуя методологию проектирования сверху вниз. При объединении же разных предприятий положение намного сложнее, ведь речь здесь идет о независимых компаниях.
Рис. 2. С помощью технологии Ontologic 5.0 можно создать единую систему управления НСИ
Но подобные внутренние проблемы организаций - это лишь надводная часть айсберга! В эпоху глобализации экономики и электронного бизнеса информационные системы предприятий должны общаться с информационными системами партнеров, поставщиков, клиентов. И говорить они должны на понятном друг другу языке. Далее можно было бы перейти и к вопросам государственного управления...
Для иллюстрации значимости справочной информации приведем только два примера.
1. Как известно, около года назад была создана англо-российская компания ТНК-ВР, которая образовалась в результате череды предварительных слияний крупных промышленных компаний (ОНАКО, СИДАНКО, ТНК). Одной из первых задач, поставленных руководством новой компании, была организация единого корпоративного справочника-классификатора материально-технических ресурсов. Это требовалось выполнить еще до определения других направлений разработки интеграционных решений и систем управления. Более того, именно совместная нормативная база должна была помочь формированию единого корпоративного англо-русского менталитета (в компании работают специалисты российской ТНК и английской ВР) и общему пониманию ведения бизнеса.
2. В конце второй мировой войны президент США Рузвельт поставил задачу разобраться в причинах проблем с поставками запчастей на фронт. Проведя необходимые исследования, американцы пришли к выводу, что запасные части в войска отправлялись в количестве, в несколько раз превышающем потребность в них. При этом запчастей по-прежнему не хватало из-за того, что на складах скапливались одни и те же изделия, но обозначенные по-разному и носившие разные названия. В итоге президент издал директиву о создании единой федеральной системы каталогизации предметов снабжения для государственных нужд, и в первую очередь для нужд обороны и безопасности. В последние двадцать лет США ежегодно вкладывали от 2 до 4 млрд. долл. только в реализацию программ стандартизации с использованием модульных структур (аналогов продукции), позволяющих сократить номенклатуру предметов снабжения министерства обороны приблизительно в три раза.
Управление нормативно-справочной информацией
Для обозначения подобной справочной информации в автоматизированных системах управления предприятиями на Западе используется термин Master Data (мастер-данные, основные данные), а задачи управления ею получили название Master Data Management (MDM). Однако в русском языке сейчас чаще применяется понятие нормативно-справочная информация (НСИ), которое появилось в дисциплинах, касающихся управления народным хозяйством еще в докомпьютерные времена. В данном случае определение "нормативная" отражает то факт, что проблема создания справочников корпоративного уровня выходит далеко за пределы собственно предприятия, она должна решаться с учетом отраслевых, государственных и международных стандартов.
Можно дать такое определение: НСИ - это условно-постоянная часть всей корпоративной (учрежденческой) информации, в отличие от текущей информации, формируемой непосредственно в процессе деятельности организации. В состав НСИ входят словари, справочники и классификаторы, данные из которых (например, термины, единицы измерения, коды, наименования материалов, контрагентов и т. п.) используются при формировании текущих документов. Так, при формировании в компьютере счета-фактуры наименования материалов, единицы измерения, наименование предприятия-получателя (контрагента), его реквизиты и ряд других полей, как правило, выбираются из справочников, встроенных в систему, а не вводятся вручную.
Чтобы оценить масштабы задач MDM, можно привести такие данные. Для крупных компаний нефтегазового сектора размеры справочников материалов составляют от 100 до 250 тыс. позиций, а по контрагентам - от 3 до 12 тыс. записей.
Вполне очевидно, что вопросы создания и поддержки в актуальном состоянии НСИ выделяются в разряд самостоятельных задач в системе управления предприятием в целом, этим зачастую занимается отдельная служба компании.
По оценкам экспертов, в нашей стране стоимость обработки одной записи НСИ составляет 2-5 долл. (за рубежом - 10-20 долл.). Соответственно стоимость одного проекта по формированию НСИ крупного предприятия можно оценить в 400-1000 тыс. долл. (включая стоимость ПО, консалтинга по внедрению и сопровождения).
Первыми к пониманию необходимости выполнения работ по НСИ как самостоятельной части создания системы управления организацией подошли нефтегазовая отрасль, а также ряд государственных и региональных структур. Сейчас в России выполняется примерно 10-15 крупных проектов по этой тематике, при этом аналитики отмечают быстрое повышение интереса к данным работам со стороны как корпоративного, так и государственного секторов. Для удовлетворения растущих потребностей клиентов нужна выверенная методология реализации подобных проектов.
Проблема создания корпоративной системы НСИ заключается как раз в том, что она не имеет простого решения. Казалось бы, самый разумный способ - использовать готовый набор справочников (международных, государственных, отраслевых). Но дело в том, что пользоваться им конкретному предприятию будет крайне неудобно (они слишком избыточны и не учитывают специфики организации), к тому же создать такую глобальную систему НСИ в полном объеме просто невозможно (подробнее на эту тему см. статью Дмитрия Гулько "Как избежать типовых ошибок при построении корпоративных и отраслевых систем нормативно-справочной информации", PC Week/RE, N 18/2004, c. 35).
Решение задачи возможно только в виде создания специализированной системы ведения НСИ с применением соответствующих стандартов, методик и программных средств. Фактически в этой работе должны соединяться усилия трех сторон:
Создателей нормативов и стандартов (как государственных, так и отраслевых);
Поставщиков базового ПО;
Системных интеграторов и консультантов, которые все это могут реализовать с учетом отраслевой практики, национальной специфики и т. д.
В советские времена государственные органы очень активно занимались вопросами нормативного регулирования. С началом перестройки произошел провал в этой деятельности, и лишь 5-7 лет назад правительственные структуры опять взялись за эту работу. Уже принято несколько законов и постановлений по данной тематике, и в настоящее время действует несколько государственных стандартных систем классификации продукции и видов деятельности (ОКП, ОКВЭД, ОКДП, ТН ВЭД, ЕКПС). Однако каждая из них имеет свое специализированное назначение и не пригодна для использования в чистом виде в отраслевых или корпоративных системах. Западные же системы классификации невозможно применять у нас в силу значительной национальной специфики нашей экономики. В целом нужно отметить, что для упорядочивания ситуации в области корпоративной НСИ желательно более активное участие государственных органов, но при этом не переходящее грань разумного регулирования.
Рис.3. Функциональная схема системы ведения НСИ
Вопросы Master Data Management находятся в поле внимания и поставщиков базового ПО. При этом они подходят к их решению с разных направлений. В первую очередь, естественно, этими задачами занимаются производители ERP-решений, и лидером тут является SAP. Другой пример - разработчики инфраструктурного интеграционного ПО. Тут следует назвать корпорацию IBM - недавнее приобретение ею компании Ascential Software во многом объясняется именно намерением корпорации усилить направление MDM (см. PC Week/RE, N 10/2005, с. 12). И, наконец, нужно сказать о поставщиках систем управления документами (например, Hummingbird). Их присутствие в сегменте MDM объясняется, с одной стороны, опытом решения задач интеграции данных, а с другой - необходимостью использования для управления НСИ интеллектуальных технологий обработки неструктурированной информации.
Что касается системных интеграторов и консалтинговых компаний, то вопросами MDM занимаются в той или иной степени все фирмы, выполняющие крупные проекты по созданию систем управления предприятиями. Некоторые из них ("Интертех", ЛАНИТ, IBS, "Юнит Спейс", "Каталит") имеют специализированные наработки в этой области. Далее мы кратко расскажем о предложениях по построению корпоративных систем НСИ фирмы "Интертех", которая за последние годы приобрела солидный опыт внедрения подобных решений в таких компаниях, как ТНК-ВР, "Татнефть", СИБУР, а также в различных федеральных ведомствах, департаментах правительства Москвы и т. д. Недавно она заключила соглашение о сотрудничестве в сфере MDM с корпорацией SAP (см. PC Week/RE, N 13/2005, с. 49).
Технология построения НСИ от компании "Интертех"
Методология, предлагаемая "Интертех", подразумевает создание единой системы ведения НСИ, увязывающей в общекорпоративное информационное пространство всю нормативно-справочную информацию подразделений, дочерних предприятий и партнеров компании (рис. 1).
Ее реализация требует прежде всего разработки и принятия набора стандартов и регламентов ведения НСИ предприятия. В качестве технологической основы построения систем НСИ используется онтологическая модель классификации и кодирования - формального описания объектов учета, основанная на выделении их существенных свойств (рис. 2). Такой подход обеспечивает накопление любого количества непротиворечивой информации и сочетает в себе достоинства иерархической, фасетной, адаптивной и ссылочной систем классификации. В целом данная методика позволяет стандартизировать действия специалистов-экспертов при осуществлении ими операций по классификации и кодированию групп (классов) объектов учета, определению свойств (признаков) классов и их значений, построению навигационных иерархий. Она также включает описание типовых пользовательских запросов, разбитых на группы по степени неопределенности и неточности формулировок, и рекомендации специалистам (экспертам) службы поддержки.
Рис. 4. Основные этапы работ по созданию единой системы ведения НСИ
Собственно система ведения НСИ реализована в виде программно-аппаратного комплекса (рис. 3), в состав которого входят инструменты ведения справочников и классификаторов, средства поиска объектов учета, модули обмена информацией между экспертами и пользователями, механизмы интеграции с внешними приложениями. Его основными интегрированными между собой функциональными подсистемами ПО являются "АРМ пользователя", "АРМ эксперта" и "АРМ администратора". Система в стандартной конфигурации базируется на технологиях Microsoft (ОС - Windows, Web-сервер - IIS, СУБД - SQL Server), но в ней предусмотрена и возможность использования других программных платформ.
Компания "Интертех" разработала также поэтапную методику внедрения системы НСИ предприятия (рис. 4). Лежащий в ее основе подход опирается на ряд основных принципов.
Эволюционность развития системы предполагает пошаговый переход к современным методам ведения и сопровождения корпоративной НСИ. Общая схема такого подхода выглядит следующим образом: старое -> старое + новое -> новое; на промежуточных этапах допускается параллельное существование старой и новой систем.
Адаптивность системы НСИ к специфике и ландшафтам существующих прикладных систем (в том числе системы ERP-класса) и к различным системам классификации и кодирования предполагает ее способность интегрироваться с внешними системами.
Преемственность позволяет сохранить все лучшее и ценное, что наработано годами и десятилетиями. Это касается использования потенциала специалистов НСИ, стабильного функционирования действующих прикладных систем, возможностей миграции и преобразования накопленных информационных массивов.
Стандартизация и унификация регламентов и методики использования и сопровождения корпоративной НСИ, систем классификации и кодирования позволяют обеспечивать постоянную актуальность и доступность НСИ в масштабах всей компании.
Учет человеческого фактора подразумевает возможность работы в системе различных категорий пользователей, с разными навыками и степенью "продвинутости" в области информационных технологий, эргономичность дизайна и "дружественность" системных интерфейсов.
Рис. 5. Функциональная модель процесса использования и ведения единой базы НСИ
Для эффективного функционирования единой системы ведения НСИ должен быть разработан комплекс организационно-управленческих решений, предусматривающий четкое разделение ответственности и функциональных обязанностей в соответствии с компетенциями групп персонала компании (рис. 5):
Пользователи - сотрудники компании, использующие те или иные данные из базы НСИ при формировании рабочих документов;
Эксперты - специалисты группы НСИ, отвечающие за формирование и изменение данных в базе НСИ;
Профильные специалисты, хорошо разбирающиеся в отдельных аспектах той или иной нормативно-справочной информации, входящей в их компетенцию по основной профессиональной деятельности. Они участвуют в процедуре согласования добавляемых или изменяемых данных по представлению специалиста-эксперта группы НСИ;
Специалисты технической поддержки - персонал службы автоматизации и ИТ, обеспечивающий обслуживание программно-технических средств системы.
В целом внедрение единой системы ведения НСИ позволяет заказчику решить следующие основные задачи, способствующие повышению эффективности работы всего предприятия:
Создать централизованное хранилище НСИ, функционирующее в рамках единого информационного пространства компании и включающее всю номенклатуру материально-технических ресурсов и других объектов учета;
Централизовать функции ведения НСИ на основе разработанных корпоративных стандартов классификации и кодирования;
Создать единые регламент и технологическую среду для доступа пользователей к НСИ, ведения экспертами классификаторов и справочников и технической поддержки системы администраторами;
Использовать встроенные в систему программные средства, поддерживающие необходимый уровень безопасности данных и постоянную их актуализацию, исключающие хранение дублированной, ошибочной или устаревшей информации;
Выполнить внедрение классификаторов и справочников НСИ в действующие управленческие, бухгалтерские и другие системы, позволяющее упорядочить и сократить расходы на ведение нормативно-справочной информации;
Оперативно представлять руководству компании информацию, необходимую для принятия эффективных решений.
УДК 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.
Дмитрий Гулько
Канд. техн. наук, президент
НЦИТ «Интертех»
Рассматривая проблему НСИ в контексте автоматизации бизнеса, важно понять, что вопреки распростаненному заблуждению НСИ не является частью ERP-системы: система НСИ предоставляет необходимый сервис всем бизнес- приложениям. А коль скоро это так, то известная концепция сервисно-ориентированной архитектуры оказывается очень плодотворной, когда речь идет о технологиях доступа к НСИ как со стороны различных бизнес-систем, так и состороны их пользователей.
«На данный момент в нашей компании существует столько-то разнородных информационных систем. Все они должны быть информационно связаны друг с другом, однако никак не решена проблема их интеграции. Мы пришли к выводу, что ключевая задача, которую необходимо решить для интеграции систем в единое информационное пространство, состоит в том, чтобы привести в порядок используемые справочники, прежде всего - справочник материалов...» Примерно так говорят практически все заказчики, обращаясь в НЦИТ «Интертех». В целом картина состояния нормативно-справочной информации (НСИ) на российских предприятиях выглядит печально (см. врезку «Проблемы сегодняшнего состояния НСИ»).
Одно из характерных заблуждений состоит в том, что система НСИ рассматривается не как самостоятельный надструктурный ИТ-компонент, а как «придаток» к той или иной ERP-системе. Вот и получается - сколько прикладных систем, столько и «придатков». На одном из крупнейших российских предприятий нефтехимического профиля при проведении обследования было обнаружено более 25 не связанных (!) справочников товарно-материальных ценностей (ТМЦ) и сырья. О какой консолидации информации, о каком мониторинге и оптимальном планировании может в этом случае идти речь?
На наш взгляд компаниям пора понять, что НСИ - не элемент ERP-системы, а часть общекорпоративной ИТ-инфраструктуры. От качества и надежности основных данных (т. е. НСИ) во многом зависит и качество собственно управленческой информации. Ведь никто пока не отменял принципа GIGO (garbage in - garbage out, что в смысловом переводе означает: «Если информационный мусор на входе, то такой же мусор и на выходе»).
Если не часть ERP, то что же?
Нормативно-справочная информация - это прежде всего информационный ресурс компании,
формируемый внутри и получаемый, как правило, извне, содержащий стандарты, требования,
правила, положения и прочую информацию, нормирующую и систематизирующую деятельность
предприятия.
Более узко - в ИТ-системах нормативно-справочная информация (основные, или мастер-данные)
определяется как совокупность условно-постоянных данных, на которых базируются
процессы формирования учетных документов в компании (учреждении). В отличие
от текущей информации, относящейся лишь к конкретному документу, НСИ, как правило,
используется в разных документах, имеющих отношение к различным бизнес-процессам.
В ИТ-системах НСИ обычно бывает представлена набором справочников и классификаторов
(см. врезку «Состав системы НСИ»).
Не следует забывать, что наряду с информацией как таковой система НСИ включает комплекс средств её поиска, хранения, обработки и распределения, методов ведения, поддержания в актуальном состоянии, а также совокупность организационно-распорядительных документов и регламентов, регулирующих использование и ведение данных НСИ.
Рис. 1 . Схема единой системы НСИ
Единая система НСИ
В настоящее время вполне можно говорить о том, что понятие системы НСИ в современном
прочтении характеризуется централизованным хранением соответствующих данных
в репозитарии, наличием корпоративных стандартов ведения и использования НСИ,
постоянной актуализацией данных службой НСИ и конечно же автоматизированным
процессом ведения данных и обслуживания запросов пользователей. Общая схема
единой системы (ЕС) НСИ приведена на рис. 1.
И раз уж мы ведем речь об автоматизации, то свойством, тесно сопряженным с обслуживанием
запросов пользователей, является обеспечение «информационными услугами» ERP-систем,
как, впрочем, и других бизнес-приложений. Сервис, предоставляемый со стороны
ЕС НСИ пользователям и ERP-приложениям, можно классифицировать следующим образом:
- доступ и многофункциональный поиск основных (мастер-) данных;
- запросы в службу ведения НСИ на изменение/добавление данных;
- запросы в службу ведения НСИ на установление ссылок или переходных ключей;
- функции ведения данных НСИ (корректировки и добавления), доступные экспертам - специалистам службы НСИ;
- доставка (репликация) данных НСИ в прикладные системы - потребители мастер-данных по запросу или по событию.
Подчеркнем также: взаимоотношения между ЕС НСИ и локальной системой разумно устанавливать именно по модели предоставления услуг, а это еще раз свидетельствует о том, что НСИ не является частью ERP-системы. При этом важно, что реализация данного механизма предоставления информационных сервисов со стороны НСИ никак не может носить частного, локального характера. В каждой компании необходимо обеспечить использование всеми её службами и подразделениями единой унифицированной системы НСИ, оптимизированной с учетом реальных требований бизнес-процессов.
| Проблемы сегодняшнего состояния НСИ |
|
|
Опрос, проведенный «Интертех» в одной из крупнейших российских компаний, показал весьма характерную картину сегодняшнего состояния НСИ, свойственную практически всем предприятиям с масштабным бизнесом. Целью опроса было выявление основных проблем и недостатков текущего состояния НСИ и методов ее поддержки «как есть», т. е. до начала проекта внедрения ЕС НСИ. В скобках приводится процент опрошенных, отметивших тот или иной недостаток. Недостатки контента НСИ:
Недостатки процесса ведения НСИ:
|
Требования и принципы построения
единой системы НСИ
С целью обеспечения использования всеми службами и подразделениями компании унифицированной системы НСИ следует учесть четыре группы требований.
Методологические - к разработке и внедрению эффективной методологии ведения справочников и классификаторов в рамках единой системы НСИ, к поддержанию данных в актуальном состоянии, обеспечению полноты, устранению ошибок, контролю целостности и непротиворечивости данных.
Организационные - к единому регламенту использования справочников системы НСИ всеми службами и подразделениями компании и его сопровождения на основе уточненных требований к составу и структуре информации в справочниках.
Информационные - к составу и структуре информации в системе НСИ, а также к технологии ее ведения (вычистке, пополнению, корректировке).
Технические - к среде доступа пользователей к НСИ и работы экспертов службы ведения НСИ, к требуемому набору функций и информационных возможностей.
По сути всё вышеперечисленное является не чем иным, как требованиями к единой системе НСИ, но помимо этого можно говорить и о требованиях к данным этой системы. В таком случае очень важную роль играют критерии, которые на сегодня универсальны для любых типов корпоративных данных. Однако относительно к данным НСИ, жизненный цикл которых по определению превышает аналогичный цикл для оперативных данных, они имеют еще большее значение. Речь идет о полноте, непротиворечивости, корректности и актуальности. Вместе с тем помимо этих классических критериев (реализация которых на сегодня обеспечивается вполне отработанными методиками проектирования данных и надежными программными продуктами) существуют и более специфические, характерные именно для НСИ.
Это идентифицируемость и уникальность , которые обеспечивают однозначную и уникальную идентификацию данных, что необходимо для установления ссылок на них из других элементов НСИ и прикладных документов. Унификация позволяет применять единообразные правила написания/описания элементов НСИ, например, наименования материалов в справочнике ТМЦ, пользоваться унифицированным справочником единиц измерения (а не текстовыми полями в том же справочнике ТМЦ), использовать наименования контрагентов в соответствующем справочнике и т. п.
И, наконец, структуризация необходима для громоздких, многочисленных элементов/записей и информационных массивов, например справочника материально-технических ресурсов (МТР).
| Состав системы НСИ | |
|
При рассмотрении структуры НСИ принято выделять следующие основные группы
справочников. |
Целесообразно также выделить принципы построения единой системы НСИ.
Корпоративность предусматривает необходимость использования ЕС НСИ в масштабе всей компании, ее структурных подразделений и предприятий.
Многоцелевое использование - система НСИ должна удовлетворять информационные потребности каждой функциональной группы пользователей, представляя ей индивидуально ориентированные срезы данных.
Полнофункциональность - ЕС НСИ должна компенсировать те или иные функциональные недостатки ERP- и других имеющихся в компании прикладных систем, связанные с поиском, обработкой и использованием НСИ.
Централизация функций хранения эталонного массива данных НСИ, ведения, создания новых и внесения изменений в существующие эталонные данные.
Адаптивность и масштабируемость системы по мере возникновения новых требований к составу и структуре данных НСИ с учётом организационных изменений в компании, изменений программно-технического ландшафта, увеличения нагрузки на информационную систему и числа пользователей.
Интегрируемость ЕС НСИ с существующими ERP- и другими корпоративными информационными системами.
Стандартизация и унификация форматов данных НСИ, способов их формирования и изменения на основе корпоративных организационно-распорядительных документов.
Преемственность - при первичном наполнении системы НСИ за основу берутся используемые в компании справочники и классификаторы, которые после консолидации и нормализации становятся её частью. Вновь создаваемые «эталонные» данные постепенно замещают старые.
Рис. 2. Этапы создания единой системы НСИ
Построение системы НСИ осуществляется поэтапно. В этой связи можно выделить консолидацию данных из прикладных систем, их гармонизацию, предусматривающую приведение данных к характерной для НСИ иерархической структуре с адекватной классификацией, а также переход на централизованное использование и ведение справочников, где задействуется служба НСИ. На рис. 2 показано три ключевых этапа построения системы НСИ.
Сервисно-ориентированная архитектура
Крупные компании (причём не только в России, но и в передовых странах по внедрению ИТ-приложений, таких как США, европейские государства и др.) по мере роста бизнеса, его диверсификации или перепрофилирования, укрупнения за счет слияний и поглощений сталкиваются с одними и теми же проблемами: в первую очередь это разноплатформенный (гетерогенный) ИТ-ландшафт, порождающий несогласованность информации в различных разобщенных корпоративных приложениях. Очень важно понять следующее: проблемы гетерогенного ИТ-ландшафта - это не только «историческое наследие». Это возможный путь развития .
Строить ли новую одноплатформенную универсальную суперсистему или пытаться использовать существующие ИТ-приложения, если они хоть в какой-то мере удовлетворяют потребностям бизнеса? Как построить корпоративную ИТ-стратегию, чтобы, с одной стороны, ИТ-обеспечение не отставало от растущего бизнеса компании, пополнялось новыми эффективными решениями, а с другой - сохранялись уже сделанные в ИТ-инфраструктуру инвестиции? Таковы извечные вопросы ИТ-директора.
Безусловно, отсутствие в крупных компаниях, на фоне гетерогенного ИТ-ландшафта,
эффективной системы поддержки единой унифицированной НСИ - ключевая проблема
автоматизации учетно-управленческих задач. Другая проблема - обеспечение взаимодействия
эксплуатируемых систем. Третья - упорядочение, унификация функций (сервисов)
в масштабе компании, устранение функционального дублирования. И, наконец, четвертая
- возможность модульного наращивания ИТ-ландшафта «по кирпичикам».
Одним из подходов, дающих внятное решение упомянутых проблем, является сервисно-ориентированная
архитектура (service-oriented architecture, SOA). При этом надо понимать, что
SOA - это не какая-либо конкретная технология, а именно подход, концепция. Используемые
в Web-сервисах технологии, стандарты и протоколы (SOAP, WSDL, UDDI и др.) нередко
служат технологической основой SOA.
Еще в 2003 году в одном из отчетов Gartner было предсказано, что «...в 2008-м SOA станет превалирующим подходом в инженерии ПО, прекращающим 40-летнее доминирование монолитной ПО-архитектуры». В конце 2003-го журнал CIO Magazine провел опрос, в котором более 50% респондентов отметили, что они в той или иной степени заняты разработкой SOA. В марте 2004-го Smith Barney (аналитическое подразделение Citigroup), опросив сто ведущих CIO, выяснило, что SOA является главным приоритетом в области новых технологий. Основной целью перехода на SOA безусловно является сохранение инвестиций, вложенных и вкладываемых в существующий ИТ-ландшафт, а также:
- пошаговое, эволюционное наращивание сервисов (приложений) по мере роста бизнеса и увеличения потребностей в ИТ-обеспечении, модульный принцип построения;
- сшивка разноплатформенных приложений в единую информационно-управленческую среду;
- платформенная толерантность, возможность сохранения существующих, в том числе устаревших, систем и платформ и включения в общекорпоративный ИТ-ландшафт разноплатформенных приложений «best-in-class» независимо от их платформы;
- органичность, простота и надежность использования внешних сервисов (т. е. сервисов, предоставляемых внешними организациями на условиях аутсорсинга);
- устойчивость, работоспособность системы в целом и других компонентов ИТ-инфраструктуры при сбое одной из систем.
Проблемы НСИ в интерьере SOA
Основу SOA составляет понятие сервисов, к которым принято относить отдельные законченные функции программного обеспечения, корпоративных приложений и систем (например, формирование заявки на приобретение материала, запрос информации об остатке материала на складе и т. п.). Сервисы составляют «кирпичики» всего ИТ-ландшафта. Важным требованием SOA является отсутствие жестких связей между модулями-«сервисами», что позволяет получить модульность программного обеспечения, возможность замены и совершенствования одних «сервисов» без изменения других. Все связи между ними, называемые «слабыми» (loosely coupled), сводятся к простым командам вызова одних сервисов другими, причем формат и синтаксис таких команд заранее предопределен. Однако необходимо иметь в виду, что подобное «слабое» взаимодействие между различными системами и сервисами достижимо только при условии, что все они используют единые унифицированные мастер-данные (НСИ), единые коды и т. п. Если такой унификации нет, соблюдение принципа «слабых» взаимодействий между «сервисами» невозможно.
Иными словами, унификация сервисов (функций) подразумевает унификацию основных данных (НСИ). Так, если сервис «формирование заявки на приобретение материала» поддерживается модулем «Заявочная кампания», написанным местным разработчиком ПО, а сервис «запрос информации об остатке материала на складе» - ERP-системой на платформе SAP R/3, то для учета остатков при планировании потребности (т. е. для смежной работы двух сервисов в одном бизнес-процессе) нужно, чтобы оба сервиса работали с единым справочником материалов (или, что по сути то же самое, со справочниками, полностью увязанными между собой посредством переходных ключей).
Рис. 3. Схема-фрагмент СОА
Еще одной важнейшей особенностью SOA является то, что «сервисы» могут быть доступны из любой точки корпоративной сети независимо от ее расположения - достаточно лишь иметь доступ к сети. Для хранения спецификаций и описаний «сервисов» в SOA предусмотрен так называемый регистр и репозитарий сервисов (РРС), где хранятся адреса доступа к каждому зарегистрированному «сервису», данные о его расположении в сети, описание правил вызова, регламенты его предоставления и т. п. Помимо собственно сервисов и информационной шины обмена запросами и данными, о чем очень часто говорят при обсуждении SOA, важнейшим компонентом этой архитектуры является портал, который значительно реже упоминается именно в контексте SOA.
Для примера на рис. 3 показана схема-фрагмент сервисно-ориентированной архитектуры приложений, участвующих в бизнес-процессе «Заявочная кампания»; здесь как раз можно видеть важнейшие компоненты SOA, в том числе РРС и портал. Кроме того, из этого рисунка понятна очевидная востребованность сервисов ЕС НСИ (компонент Master Data Managment, MDM) на протяжении всего процесса. При этом на схеме наглядно продемонстрирован механизм вызова сервисов и взаимодействия приложений в SOA.
Важно отметить, что одним из основных требований, определяющих SOA-подход, является возможность подключения всех корпоративных приложений, рассматриваемых как элементы SOA, к шине обмена. При описании же НСИ мы говорили о том, что между ЕС НСИ и ERP-системой устанавливаются отношения именно в форме предоставления информационных сервисов.
Рис. 4.
Уровни ИТ-инфраструктуры
в сервисно-ориентированной
архитектуре
Интересным на наш взгляд является выделение уровней ИТ-инфраструктуры в сервисной архитектуре. На рис. 4 показаны семь уровней, определяющих структуру «вглубь». Показательно, что данные НСИ составляют нижний уровень - «информационный фундамент» всей ИТ-инфраструктуры. Система управления НСИ (через MDM) может строиться на самостоятельной независимой платформе, состоять из нескольких бизнес-приложений (в том числе АРМ пользователя, АРМ эксперта, АРМ администратора) и предоставлять сервисы, доступные из корпоративной сети. Особо следует отметить, что такая сервисно-ориентированная архитектура весьма удобна при аутсорсинговой организации процесса ведения данных НСИ. При этом сотрудники компании, используя сервисы доступа к НСИ и обращаясь с запросами в службу ведения НСИ, получают требуемый уровень обслуживания (закрепленный в SLA-SLR), не задумываясь о том, где и кем обслуживается данный сервис.
Занимаясь масштабными проектами автоматизации и создавая новые информационные системы, мы каждый раз сталкивались с необходимостью реализации подсистемы ведения справочников, классификаторов, реестров и других подобных объектов, составляющих нормативно-справочную информацию (НСИ) заказчика. За 15 лет работы в ЛАНИТ с системами управления НСИ жизнь подкидывала нам клиентов с самыми различными требованиями. И, конечно, на этих проектах возникали разные ситуации. Я расскажу о нескольких поучительных историях, которые с нами произошли. В статье вы найдете примеры, которые будут полезны многим, кто занимается разработкой программного обеспечения. Ну, а тем, кто работает непосредственно с НСИ, будет еще интереснее – своя рубашка ближе к телу.
За иллюстрации отдельное спасибо замечательному художнику Васе Ложкину .
Случай первый. Как загрузить вагон и маленькую тележку
Создание единой системы управления контрагентами для крупной производственной компании со множеством заводов по всей стране и за рубежом.Цель проекта – создать единую базу контрагентов для всех подразделений. Ведение контрагентов осуществляется на основе заявок, которым присваиваются приоритеты от низкого до срочного. Срочная заявка должна быть обработана экспертами НСИ за 2 часа вне зависимости от разницы во времени между подразделениями.
Живая история
Проект был согласован со всеми заинтересованными сторонами (в этом нас убедило руководство заказчика) и разработан в заданные сроки в соответствии с утвержденными требованиями.
Презентация созданной системы управления контрагентами проходила гладко, пока не встала одна видная женщина – руководитель сибирского филиала – и весьма энергично, с использованием русских идиоматических выражений, довела до сведения собравшихся, что когда к ней приходит железнодорожный вагон под погрузку готовой продукции, она не будет ждать 2 часа, пока кто-то там в Москве рассмотрит заявку на добавление покупателя.
Она не собирается оплачивать простой вагона, пока происходит утверждение заявки, а заведет данные покупателя в систему как есть и отгрузит товар, а московские товарищи могут разбираться потом с информацией о покупателе сколько угодно.
Это заявление было поддержано еще несколькими руководителями филиалов компании, что практически полностью разрушило централизованную методологию ведения единого справочника контрагентов на основе заявок.
В итоге проект был видоизменен таким образом, чтобы все филиалы имели доступ к базе данных контрагентов и могли вносить в нее изменения напрямую, но при этом выполнялся автоматический поиск схожих записей, которые отображались сотруднику филиала, и он принимал решение о необходимости корректировки данных, которые позднее проверялись экспертной группой.
Что мы запомнили: не доверяйте словам руководителей и ответственных лиц со стороны заказчика, что все решения согласованы, все в теме и возражений нет. Выявляйте все заинтересованные стороны проекта и старайтесь выяснить требования к системе и ограничения непосредственно у них.
Случай второй. Как хотим, так и используем
Создание централизованной системы управления клиентами для страховой компании с большим числом филиалов и агентов по всей стране.Цель проекта – создание сводной клиентской базы для использования в аналитических приложениях. База данных собиралась со всех филиалов, данные выверялись, дополнялись, дублирующиеся объекты устранялись. Количество клиентов в одном филиале – от тысячи до нескольких миллионов. При этом, пересечений по клиентам между филиалами практически нет.
Живая история
После создания сводной клиентской базы она должна была периодически сравниваться с базами данных филиалов для выявления различий, их последующей обработки и загрузки изменений в сводную базу. Прирост клиентской базы между сверками составлял несколько тысяч записей.
Для выполнения сверки был создан специальный модуль, архитектура которого была спроектирована исходя из того, что он должен быстро сравнивать большое количество записей и формировать относительно небольшой XML-файл с изменениями для загрузки. Формат XML был выбран заказчиком.
После внедрения системы мы получили от заказчика сообщение, что модуль сверки работает крайне медленно и формирует для загрузки в сводную базу файл огромного размера, который они ничем не могут открыть.
Что же выяснилось? Заказчик производил начальную загрузку данных из филиалов в сводный справочник. Экспертам эта работа показалась нудной и трудоемкой, и они просто взяли модуль сверки и подсунули ему полные данные нового филиала, которые еще не разу не загружались в сводный справочник.
Модуль сверки, который в соответствии с ТЗ должен был формировать сведения о различиях в количестве нескольких тысяч записей, получил на вход два миллиона записей, и все они в сводном справочнике отсутствовали.
В результате, за несколько часов нечеловеческих усилий модуль сверки все-таки сформировал файл для загрузки, в который вошли все данные филиала. И, да, этот файл был огромным.
Модуль сверки был использован заказчиком не по назначению, но сам факт, что сверка позволяет выполнять начальную загрузку данных, заказчику понравился, и он собирался и дальше работать именно таким образом, только просил значительно ускорить работу модуля и что-нибудь сделать с создаваемым файлом, чтобы его можно было открывать в текстовом редакторе.
На наши возражения, что модуль сверки не предназначен для начальной загрузки данных, заказчик радостно показал ТЗ и спросил, а где это тут написано? Как хотим, так и используем!
В результате нам пришлось вносить изменения в архитектуру модуля сверки с целью обработки больших массивов данных и формирования выходного файла в формате CSV, так как заказчик решительно не захотел отказываться от такого удобного инструмента.
Что мы запомнили: всегда включайте в ТЗ описание ограничений – что ваша система делать не должна. Ну, или создавайте решения, которые учитывают все возможные сценарии использования, что сильно дороже.
Случай третий. Не слонёнок, а слон, да еще и должен летать
Создание централизованной системы ведения НСИ для финансовой организации.Цель проекта - создание централизованной системы ведения справочников и классификаторов с рассылкой изменений в заинтересованные системы и базы данных. Предоставление доступа внешним системам к справочникам через веб-сервисы нашей системы.
Обычно у заказчиков среднее количество записей на один справочник составляет от нескольких сотен до нескольких тысяч. Наш недавний рекордсмен – справочник, в котором было 11 млн. записей. Но этот заказчик преподнес нам сюрприз. В его справочнике оказалось свыше 100 млн. записей. Загружали мы его больше суток, т.к. при начальной загрузке выполнялось множество проверок данных. Это не было бы большой проблемой, но заказчик потребовал, чтобы справочник загружался за несколько минут.
В результате нам пришлось сильно изменить порядок работы системы с этим справочником. Фактически, его ведение осуществляется за пределами системы, а мы только предоставляем интерфейс для его использования. Сейчас мы разрабатываем для нашей системы новые способы работы с очень большими справочниками. Надеемся, что заказчику понравится.
Что мы запомнили: в современном мире данных становится все больше, и темпы их роста постоянно увеличиваются. Система должна быть готова к высоким нагрузкам даже там, где они изначально не предполагались. Мы постоянно развиваем наше решение с учетом современных тенденций роста данных и повышения требований к скорости их обработки.
Случай четвертый. Сложный фокус с файлами
Создание централизованной системы ведения НСИ в крупном банке.Цель проекта – создание централизованной системы ведения справочников и классификаторов с рассылкой изменений в заинтересованные системы и базы данных. Особенность проекта – весьма непростые процессы распространения изменений, затрагивающие множество систем.
Поскольку в дальнейшем мне придется упомянуть наше собственное решение для управления НСИ, позволю себе небольшое лирическое отступление.
Подробнее о системе NORMA.
Задачи наших заказчиков во многом схожи, и мы решили снизить затраты на программные разработки и сократить время проектов, создав собственную универсальную платформу для ведения НСИ и основных данных (Reference Data Management & Master Data Management). Система существует уже более 10 лет, и все эти годы мы в ЛАНИТ ее активно развиваем.
NORMA поддерживает централизованное и распределенное ведение НСИ. Все данные и метаинформация ведутся с учетом истории изменений и система позволяет просматривать и изменять весь массив НСИ на произвольную дату в прошлом или будущем. Для справочников могут быть настроены процессы согласования и утверждения изменений. В состав системы входит выделенный сервер распространения изменений, который позволяет взаимодействовать с внешними системам через различные интерфейсы и создавать достаточно сложные интеграционные бизнес-процессы (этакий мини BizTalk Server). У нас есть пакеты экспорта/импорта данных, которые умеют выгружать/загружать данные справочников в базы данных и файлы различных форматов. Поддерживается ведение перекодировочных таблиц для внешних систем.
NORMA включает графический построитель запросов и дизайнер отчетов. Кроме работы с собственными справочниками, система позволяет через свой интерфейс просматривать и изменять справочники, которые находятся во внешних, по отношению к ней, базах данных, а также использовать эти справочники в построителе запросов и пакетах экспорта/импорта.
В ответ на возникновение различных событий в системе, например, события внесения изменений в справочник, могут запускаться подключаемые программные компоненты, написанные на C#, которые могут как проверять данные, так и взаимодействовать с внешними системами и, собственно, самой системой NORMA. Практически все функции системы доступны через веб-сервисы.
Система может масштабироваться как вертикально, путем увеличения мощности сервера приложений и базы данных, так и горизонтально за счет использования многоузлового сервера приложений, в котором каждый узел или группа узлов отвечает за выполнение отдельной функции. Для хранения НСИ система может использовать Microsoft SQL Server, Oracle или PostgreSQL.
Обычно при создании справочников и процессов распространения изменений заказчик консультируется с нашими аналитиками, какой инструмент или набор инструментов, предоставляемых системой, лучше использовать для конкретной задачи. В этот раз заказчик сказал, что будет создавать справочники и процессы самостоятельно.
Через некоторое время к нам обратился один из специалистов заказчика с жалобой, что у него не загружаются данные в систему. В подтверждение нам прислали пакет импорта данных, исходный файл с загружаемыми записями и сообщение об ошибке, в котором говорилось, что загружаемые данные имеют неверный тип.
Начинаем разбираться. Крутим пакет и так, и этак, пробуем разные варианты представления исходных данных, но ошибку повторить не можем. Обращаемся к заказчику с вопросами, может быть, у пакета импорта есть подключенные программные компоненты, может быть на справочник наложены какие-то дополнительные ограничения, может быть данные не от этого процесса? На все получаем ответ - ничего такого нет, все должно легко загружаться и раньше работало.
Оказывается, этот пакет импорта был только вершина айсберга. Если кратко и сильно упрощенно, то происходило следующее. Процедура импорта загружала правильные данные из исходного файла в справочник. Исходный файл удалялся. Затем наша система выполняла распространение изменений в несколько баз данных, в одной из которых производилось сравнение собственных данных с нашими изменениями и формировался файл с расхождениями, который возвращался в нашу систему для загрузки. Причем для загрузки этого файла заказчик использовал ту же процедуру импорта, что и для исходного файла. И вот именно в этом файле, сформированном внешней системой, были данные неверного типа. Очевидно, что при анализе исходного файла мы никаких ошибок найти не могли, а про второй файл и развесистый процесс распространения изменений нам ничего не сообщили.
Что мы запомнили: Всегда проверяйте полученную информацию даже если вам говорят, что у нас тут маленькая проблемка, и она вот именно в этом месте, мамой клянусь! Анализируйте проблему в контексте.
Случай пятый. Я привыкаю к несовпадениям
Создание системы управления НСИ в производственной компании.Цель проекта – создание системы ведения НСИ в управляющей компании со множеством филиалов, заводов и конструкторских подразделений.
В этот раз мы дальше нескольких презентаций не продвинулись. Наша система NORMA очень понравилась технарям. Она закрывала все их существующие проблемы. Дальше пришла очередь показывать систему руководству, и вот тут произошел облом десятилетия. Высокий руководитель посмотрел, послушал и сказал: «Мы тут все работаем на продуктах Apple, у них есть определенный стиль, а ваша система в этот стиль не вписывается. Мы ее даже рассматривать не будем».
Что мы запомнили: заказчики бывают разные, и некоторым вы просто не подходите. Стиль другой.
Подобные истории случаются в различных проектах. Что интересного было в вашей проектной жизни? Что стало для вас неожиданным уроком? Делитесь в комментариях.
Теги: Добавить метки
