
- •Глава 1. Анализ этапов создания автоматизированной системы. 6
- •Глава 2. Формирование требований к автоматизации процессов управления человеческими ресурсами в компании ххх 28
- •Глава 3. Автоматизация процессов управления человеческими ресурсами 51
- •Ключевые слова
- •Введение
- •Глава 1. Анализ этапов создания автоматизированной системы.
- •1.1. Формирование требований к автоматизированной системе
- •1.2. Разработка концепции информационной системы
- •1.3. Документирование требований к информационной системе
- •1.4. Разработка проектного решения
- •1.5. Подготовка объекта к автоматизации процессов
- •Выводы по первой главе
- •Глава 2. Формирование требований к автоматизации процессов управления человеческими ресурсами в компании ххх
- •2.1. Сбор информации по процессам
- •2.3. Моделирование процессов управления человеческими ресурсами
- •2.3. Обоснование необходимости автоматизации
- •2.4. Формирование функциональных требований к автоматизации процессов управления персоналом
- •2.5. Формирование нефункциональных требований к автоматизации процессов управления персоналом
- •Выводы по второй главе
- •Глава 3. Автоматизация процессов управления человеческими ресурсами
- •3.1. Организация процесса настройки системы
- •3.3. Настройка системы etWeb для автоматизации процесса «Управление результативностью»
- •3.3. Настройка системы etWeb для автоматизации участка процесса «Управление обучением и развитием»
- •3.4. Результаты внедрения системы
- •Выводы третьей главы
- •Заключение
- •Библиография
1.2. Разработка концепции информационной системы
На данном этапе идет более углубленное изучение объекта автоматизации компанией-заказчиком, итогом которого должны стать модели бизнес-процессов, которые будут в дальнейшем автоматизированы.
Под бизнес-процессом понимается «совокупность различных видов деятельности, которые создают результат, имеющий ценность для потребителя» [14]. Таким образом бизнес-процесс представляет собой последовательность функций или работ в результате которых будет получен продукт или услуга.
Основываясь на построенных бизнес-процессах и выявленных «узких» местах, исполнители могут предложить заказчикам варианты решений проблем и концепции создания АС. Также на основании выявленных проблем строится обоснование необходимости автоматизации.
Существует два подхода к построению процессов: объектный и функциональный [14]:
Объектно-ориентированные методики представляют компанию как набор различных объектов или производственных единиц, которые взаимодействуют между собой. Данный подход позволяет выделить объекты, составляющие организацию, и распределить между ними ответственность за их действия.
Функциональные методики представляют компанию как набор функций, который превращает входные данные в выходные.
Данные методики имеют свои преимущества: модель, построенная с помощью объектного подхода лучше соответствует существующей структуре компании и является более устойчивой к изменениям, в то время как функциональная модель более понятна исполнителям процесса и больше подходит в ситуациях, когда организационная структура компании находится на стадии разработки или изменений.
Наиболее популярной методологией объектного подхода является UML (Unified modeling language), которая представляет собой набор диаграмм, необходимых для разработки информационной системы [15]:
Диаграмма вариантов использования – диаграмма, отображающая отношение между действующими лицами (акторами) и возможными вариантами использования системы. Варианты использования представляют собой способы применения системы пользователем, то есть ее функционал применительно к определенному лицу или предмету, но без указания специфики его реализации.
Диаграмма классов – это диаграмма, являющаяся логическим представлением системы и отображающая отношения между статическими элементами модели (классами).
Диаграмма кооперации – диаграмма, предназначенная для демонстрации работы системы на уровне действующих лиц, которые определенным образом взаимодействуют между собой для осуществления вариантов использования.
Диаграмма последовательности – диаграмма, отображающая упорядоченные во времени взаимодействия объектов.
Диаграмма состояний – диаграмма, представляющая собой все состояния объекта, которые описывают его реакцию на воздействие внешних факторов, действия объекта и изменение его свойств.
Диаграмма деятельности – частный случай диаграммы состояний, который предназначен для моделирования поведения информационной системы.
Диаграмма компонентов – это диаграмма, позволяющая изобразить архитектуру будущей информационной системы: ее компоненты (модули) и связи между ними.
Диаграмма развертывания – диаграмма, предназначенная для физического представления информационной системы: ее вычислительных ресурсов, технических устройств и связей между ними.
В рамках данной методологии диаграммы чаще всего представлены в виде графов, вершинами которых являются сущности или объекты, а ребрами – отношения между ними.
Для построения функциональной модели организации существует ряд стандартов семейства IDEF, наиболее распространенными из которых являются стандарты IDEF0 и IDEF3 [14].
Стандарт IDEF0 представляет процесс в виде последовательности функциональных блоков - функций, рассматриваемых в рамках системы. Стороны функционального блока имеют своё значение: левая – вход (детали, материалы, документы), правая – выход (аналогично со входом это могут быть детали, материалы и документы), верхняя – управление (регламенты, распоряжения, стандарты), нижняя – механизмы (человеческие, информационные, технологические и прочие ресурсы).
В рамках методологии в стороны функционального блока входят так называемые интерфейсные дуги, которые отображают элементы системы, преобразовывающиеся функциональным блоком или оказывающие на него влияние. По требованию стандарта у функционального блока должно быть как минимум по одной управляющей и исходящей дуге, что объясняется необходимостью выполнения функции по правилам и получения каких-либо результатов по окончанию ее выполнения, иначе этот подпроцесс не будет иметь смысла [14].
С помощью данного стандарта описываются не только бизнес-процессы компании, но и ее деятельность в целом. Однако система функциональных блоков не всегда в полной мере отражает суть процесса. Поэтому для более детализированного и структурированного изображения процессов используется стандарт IDEF3, отображающий последовательность функций и их ветвления/слияния.
Функциональный и объектный подходы имеют собственные преимущества и недостатки. Так, например, неоспоримым достоинством функциональных методик является то, что их реализация может проходить по принципу декомпозиции, то есть функциональный блок может делиться на множество подфункций, что позволяет выявить необходимые модули будущей информационной системы. В то же время согласно функциональному подходу нет однозначной связи между процессами и данными, они как бы существуют отдельно в виде функциональной диаграммы и структуры данных. Также непрозрачны условия обработки информации в связи с их динамическими изменениями.
Все указанные недостатки функционального подхода ликвидируются в объектном подходе, в рамках которого главной структурной единицей является класс объектов, обладающий определенным набором функций, которые могут обращаться к атрибутам класса [14].
Для моделирования процессов согласно данным подходам выбираются определенные нотации, самыми популярными из которых являются BPMN и EEPС [9].
BPMN (Business Process Modeling Notation)
В основе данной нотации лежит идея, что стратегия управления полагается на три методологии: моделирование, анализ и оптимизацию бизнес-процессов. BPMN была создана с целью объединения различных точек зрения на бизнес процесс, что позволило стандартизировать модель. Эта нотация подходит для использования любыми пользователями начиная профессиональными бизнес-аналитиками и заканчивая рядовыми сотрудниками компании.
Основными объектами нотации являются [10]:
Действия – объекты, с помощью которых описываются основные задачи процесса. Это могут быть бизнес-правила, сценарии или задачи любого типа. Затем задачи детализируются с помощью формирования сценариев и определения порядка и условия действий. Изображаются в виде прямоугольников с закругленными углами.
События – объекты, являющиеся показателем необходимости участия пользователя. Такими объектами могут быть сигналы, ошибки, отправка и получение сообщений и другие. Изображаются в виде окружности.
Логические операторы – объекты, определяющие порядок наступления различных событий при ветвлении или слиянии, точки принятия решений. Изображаются в виде ромбов.
Данные – объекты, которые могут быть использованы в рамках различных действий.
Хореография – объекты, отражающие задачи взаимодействия между группой участников.
Диалоги – объекты, определяющие характер информационного взаимодействия, которые отличаются от хореографии выделением нескольких пулов и детальном их описании.
Роли – объекты, с помощью которых определяются обязанности участников БП и принципы информационного взаимодействия между ними.
eEPC (Extended Event Driven Process Chain)
Нотация eEPC представляет процесс в виде алгоритма действий, которые производятся отдельными организационными или персональными единицами. Таким образом формируется сценарий процесса, который представляет собой пошаговую последовательность событий и функций, изображенных вертикально и соединенных связями.
Основными объектами нотации являются [10]:
Функция – отображение выполняемой работы.
Событие – это элемент нотации, описывающий состояние процесса, влияющее и управляющее функциями.
Логический оператор (правило) – это отображение правила или условия выполнения функции и наступления события.
Организационная единица – это элемент нотации, изображающий исполнителей или участников функций. Под организационными единицами могут подразумеваться подразделения, должности или роли.
Нотация eEPC называется расширенной, так как содержит множество дополнительных объектов, таких как документы, товарно-материальные ценности, базы данных, места, продукты и другие.
Данная нотация имеет свои достоинства и недостатки. Так например её важными преимуществами является то, что при формировании модели процесса выдерживается строгая логика и события, которые возникают в ходе процесса четко определены. Однако модели, изображенные в нотации eEPC тяжелы для восприятия и требуют определенных знаний для их прочтения, в отличие от моделей BPMN. Также изображение процессов в нотации eECP является очень трудоемким, а модели, как правило, получаются очень громоздкими, ввиду чего их неудобно читать и документировать.