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

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

Приведем пример иерархии подразделений:

Из этого примера видно, что производство может быть структурировано до подразделений (участков, секторов, групп, отделений) с любым уровнем вложенности.

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

Перечислим реквизиты производственного подразделения,значения которых необходимо определить в подсистеме «Управление производством».

График работы. Выбирается из справочника «Графики работы».

Элемент этого справочника определяет расписание работы – время начала и окончания работы отдельно на каждый день недели и отдельно – на все предпраздничные дни. Для каждого дня недели можно отдельно указать время начала и окончания работы согласно графику, причем временных отрезков работы может быть несколько на день недели, например, с 8.00 до 13.00 и с 14.00 до 18.00. График работы для подразделения необходим для того, чтобы процедура расчета графика производства могла определить количество часов работы, доступных в подразделении, на каждый календарный день.

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

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

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

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

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

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

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

Варианты:

«Методика ББВ/УББВ». Расписание выполнения МЛ формируется для ключевых РЦ, контроль выполнения МЛ производится по прохождению МЛ предварительного и завершающего буфера.

«Пооперационное планирование». Расписание формируется для всех РЦ и операций маршрутного листа. Дополнительно нужноуточнить «Способ планирования» -«Вперед» или «Назад».

Склады (складские территории)

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

При расчете графика формируется график потребностей на складах в материалах и полуфабрикатах (номенклатура, характеристика, количество, интервал планирования).

Склад, с которого «запитывается» производственное подразделение по умолчанию – определяется реквизитом подразделения.

Но не наоборот: реквизит «Подразделение» в справочнике «Склад» не влияет на планирование (и служит для учетных целей).

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

Бригады и состав бригад

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

Бригада состоит из сотрудников. Состав бригады устанавливается документом «Формирование состава бригады », и действует с даты, указанной в документе.

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

Виды рабочих центров, рабочие центры

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

Вид рабочего центра состоит из конкретных рабочих центров, например, единиц оборудования. Синоним вида рабочих центров – «Группа взаимозаменямых рабочих центров».

Примеры рабочих центров:

- Единица оборудования

- Рабочее место

- Группа рабочих (бригада или объединение по профессиональному признаку)

- Сотрудник

- Единица оснастки

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

Реквизиты вида рабочих центров следующие:

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

Максимальная доступность (час, мин, сек). Определяет максимальную длительность обработки одной партии этапа в интервале подразделения, к которому принадлежит вид РЦ. По одной партии этапа не может быть назначена длительность обработки в интервале большая, чем максимальная доступность.

В текущей версии УП2 настройки видов РЦ, сохранив описанную суть, уже несколько изменились. Теперь флажками можно задать:

- Учитывать ли доступность времени РЦ в составлении графика на верхнем уровне. И если да, то будет ли этот РЦ загружаемым или нет.

- Задействовать ли РЦ в управлении производством по Маршрутным листам на нижнем уровне.

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

Ввод доступного времени рабочих центров

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

Табличная часть документа разворачивается по колонкам - интервалам подразделения (например, дням) в периоде документа.

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

Ресурсные спецификации

Ресурсная спецификация как сетевой график

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

Наиболее общий способ описания процесса изготовления любого изделия – это сетевой график.

Ресурсная спецификация описывает сетевой график изготовления изделия.

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

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

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

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

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

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

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

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

Структура ресурсной спецификации

Структура ресурсной спецификации, как объекта конфигурации, показана на следующей схеме:

Ресурсная спецификация содержит:

Список выходов,

Список материальных входов,

Список трудозатрат (по видам работ),

Список этапов.

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

На входах этапов указываются исходные компоненты (материалы, услуги) поступающие извне в производственный процесс, описываемой спецификацией.

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

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

Такой каскад спецификаций используется при формировании спецификации для конкретной строки заказа на производство. В спецификацию строки заказа копируется весь каскад связанных ресурсных спецификаций.

В реквизите «Оптимальное количество передачи между этапами » можно указать количество партии изделия (результата работ), которое целесообразно передавать между этапами. При расчете графика производства количество этапа разбивается на данные партии, и каждая партия планируется отдельно, исходя из времени доступности загружаемых видов РЦ.

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

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

По каждому виду работ в периодическом регистре сведений «Расценки » можно указать действующую расценку на единицу вида работ.

Этапы ресурсной спецификации

Ресурсная спецификация может быть одноэтапной или многоэтапной.

Если спецификация одноэтапная – реквизиты единственного этапа редактируются непосредственно в форме спецификации. Если спецификация многоэтапная – то спецификация содержит список этапов. Для редактирования реквизитов этапа нужно открыть отдельную форму этапа из списка этапов.

Последовательность выполнения этапов определяется реквизитами этапа: «Номер этапа», «Номер следующего этапа». По номеру этапа иномеру следующего этапа выстраиваются связи между этапами в виде сетевого графика этапов.

Реквизиты этапа определяют основные параметры планирования этапа:

Подразделение, в котором выполняется этап. Для этапа определяется только одно подразделение. Если одни и те же этапы могут выполняться в разных подразделениях – то необходимо создавать разные ресурсные спецификации

Одновременно производимое количество. Р азмер партии или объем работ, для которого нормируется время выполнения этапа. Например, если в реквизите указана единица, то время выполнения этапа нормировано на единицу.

Флаг «Планировать работу видов РЦ» . Определяет способ нормирования длительности этапа.

Флаг включен. В этапе необходимо указать, какие виды РЦ будут загружены этапом и длительность обработки одновременно производимого количества на загружаемом виде рабочего центра. Эти виды РЦ могут оказаться «узкими местами» при выполнении графика производства, поэтому рассчитывается их загрузка в графике. Кроме того, необходимо указать предварительное (до обработки на загружаемом виде РЦ) и завершающее буферное время. Буфера в графике производства занимают отдельные интервалы. Напомним, что если время обработки до загружаемого вида РЦили после намного меньше длительности интервала, то указание буферных времен может привести к неоправданному захвату буферами целых интервалов и соответственно, к неоправданному увеличению длительности этапа в графике производства.

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

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

Если флаг включен – то этап выполняется непрерывно и может располагаться в графике только в соседних интервалах.

Если флаг выключен – то выполнение этапа можно прерывать, т.е. часть этапа повремени можно быть расположена в графике в одном интервале, а часть – в другом,не примыкающим к первому, интервале.

Критерий непрерывности – хоть одна операция внутри этапа является непрерывной и сопоставима с длительностью интервала. К таким операциям относятся, например, термообработка, покраска, сушка и т.д.

Различие между планированием «прерывных» и «непрерывных» этапов показано на следующей схеме:

Занимаясь масштабными проектами автоматизации и создавая новые информационные системы, мы каждый раз сталкивались с необходимостью реализации подсистемы ведения справочников, классификаторов, реестров и других подобных объектов, составляющих нормативно-справочную информацию (НСИ) заказчика. За 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, у них есть определенный стиль, а ваша система в этот стиль не вписывается. Мы ее даже рассматривать не будем».

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

Теги: Добавить метки

Федеральное Государственное Образовательное Учреждение

Высшего Профессионального Образования

Национальный Исследовательский Технологический Университет "МИСиС"

Кафедра автоматизированных систем управления

Курсовая работа по курсу

"Теория систем и системный анализ"

Выполнил : Авдошина Ольга

Группа: МА-10-1/И810-4

Преподаватель : Морозов Е.А.

Москва2014

1.Определение нормативно-справочной информации 3

2.Проблемы и потребности компаний к системе управления НСИ. 3

3.Едина система управления НСИ (ЕС НСИ) 5

4.Создание автоматизированной системы управления НСИ 8

4.1.Анализ НСИ 8

4.2.Выбор архитектуры и оценка стоимости создания автоматизированной системы управления НСИ 10

4.3.Внедрение 15

5.Лица, ответственные за ведение НСИ 16

6.Эффективность внедрения 18

7.Список использованной литературы 20

1. Определение нормативно-справочной информации

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

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

1. Проблемы и потребности компаний к системе управления нси.

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

Дополнительные расходы на независимое ведение одних и тех же справочников;

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

Большая трудоемкость и высокая затратность формирования консолидированной отчетности на основе данных, в которых одни и те же объекты справочных данных (товары, услуги, контрагенты) имеют различные коды и наименования;

Низкое качество нормативно-справочных данных.

Что значит “некачественные” нормативно - справочные данные? Это справочные данные, которые:

Имеют проблемы структуризации МТР по группам;

Дублирующиеся или противоречивые данные справочника материально-технических ресурсов (товары и услуги) в 70 % случаев приводят к значительному увеличению складских запасов предприятия и образованию неликвидов. Например:

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

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

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

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

Дмитрий Гулько
Канд. техн. наук, президент
НЦИТ «Интертех»

Рассматривая проблему НСИ в контексте автоматизации бизнеса, важно понять, что вопреки распростаненному заблуждению НСИ не является частью 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), не задумываясь о том, где и кем обслуживается данный сервис.

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

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

Централизованное управление нормативно-справочной информацией с DATAREON

Специалисты DATAREON имеют значительный опыт систематизации нормативно-справочной информации , разработки единых регламентов использования и ведения НСИ, внедрения специализированных автоматизированных систем управления НСИ на базе MDM-системы «1С:Предприятие 8. MDM Управление НСИ ». В рамках выполненных проектов специалистами DATAREON проводилась экспертная обработка записей справочников МТР, услуг, контрагентов, справочников финансового блока, организационной структуры и управления персоналом.

Успешный опыт работы в области управления НСИ, апробированные на практике эффективные методики и собственная экспертиза позволяют DATAREON оптимизировать использование ресурсов предприятий-клиентов в результате автоматизации управления НСИ.

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

Что такое нормативно-справочная информация (НСИ)?

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

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

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

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

Для чего необходимо централизованное управление НСИ

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