Моделирование информационных систем управления человеческими ресурсами

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

Одним из направлений разрешения этой задачи служит применение CASE-технологий (Computer Aided Software {System) Engineering), представляющих собой совокупность методов и средств для автоматизации разработки информационных систем. Результат применения CASE-технологий — сокращение сроков создания разрабатываемых систем, снижение расходов на разработку, повышение эффективности и снижение вероятности ошибок. Инструментальные средства, поддерживающие CASE-технологии, называются CASEсредствами и характеризуются следующими основными показателями:

• • сквозная поддержка всех этапов разработки системы;
• • поддержка визуальных методов разработки, поскольку используются методологии, которые дают строгое и наглядное описание системы;
• • поддержка единой базы проекта — репозитария. Вся информация о разрабатываемой системе автоматически помещается в единую базу данных проекта. Такая база поддерживает согласованность, непротиворечивость, полноту п минимальную избыточность проекта, а также корректность операций его редактирования;
• • поддержка одновременной работы над моделью группы разработчиков;
• • информационное обеспечение разработчиков. Специалисты получают доступ ко всему проекту. CASE-средство может формировать разнообразные отчеты по проекту в виде экранных или печатных форм;
• • документирование проекта. CASE-средство генерирует документацию, которая в значительной степени готова к использованию;
• • применение CASE-средств основано на парадигме «методология — метод — нотация — средство». Методологии можно разделить на два класса по заложенному в них принципу декомпозиции — деления сложной системы на менее сложные подсистемы:

• — структурные методологии. Сущность структурного подхода к разработке ИС заключается в декомпозиции (разбиении) системы на автоматизируемые функции — система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и т. д.;
• — объектно-ориентированные методологии. Реализуют принципы объектной декомпозиции — система представляет собой совокупность взаимодействующих объектов, которые соответствуют предметной области.

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

• • функции, которые система должна выполнять. Для этого используются диаграммы функциональной декомпозиции FDD (functional decomposition diagrams), представляющие собой граф типа дерева, показывающий разбиение функций и процессов управления высокого уровня на составные части;
• • процессы, обеспечивающие выполнение указанных функций. Здесь применяются диаграммы потоков данных DFD (data flow diagrams), представляющие собой средство описания информационных процессов, протекающих в системе управления, призванное структурировать анализ предметной области при обследовании и моделировании;
• • данные, используемые при выполнении функций, и отношения между этими данными. Диаграммы «сущность — связь» ERD {entity-relationships diagrams) дают возможность выполнить описание предметной области, которое задается в категориях сущностей, их связей, атрибутов сущностей и связей. Такое описание является математически строгим и однозначно соответствует схеме реляционной базы данных. ERD-модель предметной области является СУБД независимой и, следовательно, легко настраиваемой на конкретную базу данных.

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

CASE-средство AllFusion Process Modeler (ранее — BPwin) позволяет создать смешанную модель путем поддержки следующих методологий:

• • методология IDEFO (Icam DEFinition,) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области, которая отображает производимые этим объектом действия и связи между этими действиями;
• • диаграммы потоков данных (DFD) используются для описания функций обработки информации, документов, объектов, а также сотрудников или отделов, которые участвуют в обработке информации. Их можно использовать как самостоятельно, так и в виде дополнения к модели IDEF0 для более наглядного отображения текущих операций документооборота в системах обработки информации;
• • методология IDEF3. Для описания логики взаимодействия информационных потоков более подходит методология IDEF3, называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. С помощью диаграмм workflow можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время;
• • методология стоимостного анализа АВС (activity based costing). Функционально-стоимостной анализ (ФСА — activity based costing,, ABC) — метод определения стоимости и других характеристик изделий, услуг и потребителей, использующих в качестве основы функции и ресурсы, задействованные в производстве, маркетинге, продаже, доставке, технической поддержке, оказании услуг, обслуживании клиентов, а также обеспечении качества.

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

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

Первым из них является понятие функционального блока (iactivity box). Функциональный блок графически изображается в виде прямоугольника (рис. 3.120) и представляет собой некоторую конкретную функцию, работу (activity), которая реализуется системой. По требованиям стандарта именем работы должен быть глагол или глагольная форма (например, «производить услуги», а не «производство услуг»).

Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом верхняя сторона имеет значение «управление» (control), левая — «вход» {input), правая — «выход» {output), нижняя — «механизм» {mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Вторым «китом» методологии IDEF0 является понятие интерфейсной дуги {arrow). Интерфейсные дуги часто называют потоками или стрелками. Они отображают взаимодействие работ с внешним миром и между собой. Стрелки представляют собой некую информацию и именуются существительными. В IDEF0 различают пять типов стрелок.

• 1. Вход — материал или информация, которые используются или преобразовываются работой.
• 2. Управление — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.
• 3. Выход — материал или информация, которая производится работой. Каждая работа должна иметь хотя бы одну стрелку выхода.

Рис. 3.120. Функциональный блок

• 4. Механизм — ресурсы, которые выполняют работу, например персонал предприятия, станки, механизмы и т. д.
• 5. Вызов — специальная стрелка, указывающая на другую модель работы.

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (arrow label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

Третьим основным понятием стандарта IDEF0 является декомпозиция (decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

В процессе декомпозиции функционального блока получившаяся диаграмма следующего уровня называется дочерней (child diagram). В свою очередь функциональный блокпредок называется родительским блоком по отношению к дочерней диаграмме (parent box), а диаграмма, к которой он принадлежит, — родительской диаграммой (parent diagram).

При декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, используются на дочерней диаграмме. Этим достигается структурная целостность IDEFO-модели. Рассмотренный принцип декомпозиции представлен на рис. 3.121. Здесь показана также взаимосвязь нумерации функциональных блоков и диаграмм — каждый блок имеет свой уникальный по;

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

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии или, наоборот, отдельные дуги не имеют практического смысла выше какого-то уровня. Для решения таких задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение туннеля (arrow tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из туннеля) только на этой диаграмме. В свою очередь такое же обозначение вокруг конца стрелки на входе блока означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет.

Последним из понятий IDEF0 является глоссарий (glossary). Для каждого из элементов 1DEF0 (диаграмм, функциональных блоков, интерфейсных дуг) существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т. д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента.

Для того чтобы ограничить перегруженность IDEFO-moдели и сделать ее удобочитаемой, в стандарте приняты ограничения сложности (принципы ограничения сложности IDEFO-диаграмм):

• • количество функциональных блоков на диаграмме от 3 до 6;
• • количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг нс более четырех.

Эти ограничения носят исключительно рекомендательный характер.