Разработка регламента вполнения процесса

Содержание:

Введение

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

В данном случае основные задачи отдела кадров по управлению персоналом представлены следующим списком:

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

Цель данной работы – разработка модели бизнес-процесса «Управление персоналом»…

1 Описание предметной области

Отдел кадров является подразделением организации. Функции отдела кадров по управлению персоналом приведены в следующем списке:

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

2. Разработка функциональной модели (IDEF0)

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

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

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

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

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

Цель моделирования (Purpose). Модель должна строиться при ясном осознании объекта и целей моделирования. Выбранное определение цели моделирования должно отвечать на следующие вопросы:

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

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

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

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

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

Действия. Действие, обычно в IDEF0 называемое функцией, обрабатывает или переводит входные параметры (сырье, информацию и т.п.) в выходные. Поскольку модели IDEF0 представляют систему как множество иерархических (вложенных) функций, в первую очередь должна быть определена функция, описывающая систему в целом - контекстная функция. Функции изображаются на диаграммах как поименованные прямоугольники, или функциональные блоки (Activity Box). Функциональный блок графически изображается в виде прямоугольника (рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть отглагольным существительным (например, "производить услуги", а не "производство услуг"). Важно подбирать имена таким образом, чтобы они отражали систему так, как если бы она обозревалась с точки зрения, выбранной для моделирования. Каждая из четырех сторон функционального блока имеет своё определенное значение (роль).

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

Левая сторона имеет значение "Вход" (Input) - стрелки слева, означающие данные или объекты, потребляемые или изменяемые процессом

Правая сторона имеет значение "Выход" (Output) - стрелки справа, означающие основные результаты деятельности процесса, конечные продукты.

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

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

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

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

Бизнес-процесс «Управление персоналом» содержит входы:

• Информация, предоставляемая сотрудником.
• Запросы от руководителей СП.
• Распоряжение руководителей организации.
• Запросы от внешних организаций и ведомств.
• Открытые вакансии в организации.
• Резюме соискателей.

Бизнес-процесс «Управление персоналом» содержит выходы:

• Информация в трудовой книге.
• Информация для расчётного отдела.
• Отчёт о проведённых мероприятиях.

Бизнес-процесс «Управление персоналом» содержит следующих исполнителей:

• Специалист по подбору персонала.
• Специалист по кадровому учёту.
• Табельщик.
• Специалист по работе с персоналом.

Бизнес-процесс «Управление персоналом» содержит следующие управления:

• ТК РФ и прочие НПА.
• Внутренний регламент работы.
• Устав организации.

Рис. 1. Диаграмма бизнес-процесса работы отдела кадров.

Бизнес-процесс «Управление персоналом» содержит следующие процессы декомпозиции:

• Подбор персонала.
• Кадровый учёт.
• Табельный учёт.
• Работа с персоналом.

Декомпозиция бизнес-процесса «Управление персоналом» изображена на рис. 2.

Рис. 2. Декомпозиция бизнес-процесса работы отдела кадров.

Бизнес-процесс «Подбор персонала» содержит входы:

• Открытые вакансии в организации.
• Резюме соискателей.

Бизнес-процесс «Подбор персонала» содержит выходы:

• Рекомендация о принятии на работу.

Бизнес-процесс «Подбор персонала» содержит следующих исполнителей:

• Специалист по подбору персонала.

Бизнес-процесс «Подбор персонала» содержит следующие управления:

• Рекомендация о принятии на работу.

Бизнес-процесс «Кадровый учёт» содержит входы:

• Рекомендация о принятии на работу.
• Информация, предоставляемая сотрудником.
• Запросы от руководителей СП.

Бизнес-процесс «Кадровый учёт» содержит выходы:

• Информация в трудовой книге.
• Информация по сотрудникам.
• Информация для расчётного отдела.
• Статус сотрудника.

Бизнес-процесс «Кадровый учёт» содержит следующих исполнителей:

• Специалист по кадровому учёту.

Бизнес-процесс «Кадровый учёт» содержит следующие управления:

• ТК РФ и прочие НПА.

Бизнес-процесс «Табельный учёт» содержит входы:

• Статус сотрудника.
• Запросы от руководителей СП.

Бизнес-процесс «Табельный учёт» содержит выходы:

• Информация для расчётного отдела.

Бизнес-процесс «Табельный учёт» содержит следующих исполнителей:

• Табельщик.

Бизнес-процесс «Табельный учёт» содержит следующие управления:

• ТК РФ и прочие НПА.
• Распоряжение руководителей организации.

Бизнес-процесс «Работа с персоналом» содержит входы:

• Информация по сотрудникам.

Бизнес-процесс «Работа с персоналом» содержит выходы:

• Отчёт о проведённых мероприятиях.

Бизнес-процесс «Работа с персоналом» содержит следующих исполнителей:

• Специалист по работе с персоналом.

Бизнес-процесс «Работа с персоналом» содержит следующие управления:

• Устав организации.

Диаграммы декомпозиции бизнес-процессов «Подбор персонала», «Кадровый учёт», «Табельный учёт», «Работа с персоналом» изображены на рис. 3,4,5,6.

Рис. 3. Декомпозиция бизнес-процесса «Подбор персонала».

Рис. 4. Декомпозиция бизнес-процесса «Кадровый учёт».

Рис. 5. Декомпозиция бизнес-процесса «Кадровый учёт».

Рис. 6. Декомпозиция бизнес-процесса «Работа с персоналом».

3 Разработка модели документооборота DFD

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

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

Основными компонентами контекстных диаграмм являются:

• системы/подсистемы;
• внешние сущности;
• потоки данных;
• процессы (преобразователи, активности);
• накопители данных.

Процессы и накопители данных в данной лабораторной работе не рассматриваются. Опишем подробнее компоненты контекстных диаграмм.

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

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

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

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

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

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

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

Для данной модели были составлении декомпозиции в формате DFD для следующих процессов:

• Принятие сотрудника.
• Увольнение сотрудника.
• Организация отпусков.
• Учёт выходов на работу.
• Учёт больничных листов.
• Учёт замещений, сверхурочных и т.д..

Для данной модели использованы следующие объекты:

• Внешняя сущность «Сотрудник».
• Хранилище данных «Журнал учёта отпусков».
• Хранилище данных «Журнал-табель».
• Хранилище данных «Справочник сотрудников».

Диаграммы изображены на рис. 6-11.

Рис. 6. Декомпозиция бизнес-процесса «Принятие сотрудника».

Рис. 7. Декомпозиция бизнес-процесса «Увольнение сотрудника».

Рис. 8. Декомпозиция бизнес-процесса «Организация отпусков».

Рис. 9. Декомпозиция бизнес-процесса «Учёт выходов на работу».

Рис. 10. Декомпозиция бизнес-процесса «Учёт больничных листов».

Рис. 11. Декомпозиция бизнес-процесса «Учёт замещений и сверхурочных».

4 Разработка модели логики взаимодействия информационных потоков (IDEF3)

В отличие от IDEF0, представляющего моделируемую систему как совокупность видов деятельности, IDEF3 представляет собой технику моделирования деятельности как последовательности событий, а также участвующих в этих событиях объектов. В этом смысле IDEF3 похож на стандарт eEPC в ARIS. IDEF3 удобен для подробного моделирования деятельности отдельных подразделений, сотрудников, описания техпроцессов и т.д. Формат листа диаграммы IDEF3 аналогичен IDEF0. В IDEF3 используются следующие типы объектов:

• работа (Unit of Work, Activity).
• стрелка (Arrow).
• перекресток, или коннектор (Junction).
• ссылочный объект (Referent).

Принципы IDEF3. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа. IDEF3 - это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе. Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей. Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное. Диаграмма является основной единицей описания в IDEF3.
Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор).
Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо.

В IDEF3 различают три типа стрелок, изображающих связи: Старшая- сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Отношения- пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.

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

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

Всё перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.     Новый раздел Работы рисуются в виде прямоугольников, в нижней части которых выделены два равных поля, и именуются аналогично работам в IDEF0. Стрелки в IDEF3 могут быть четырех типов:

• Прецедент (temporal precedence) - обозначение того, что работа, из которой выходит стрелка, предшествует предыдущей.
• Поток объектов (object flow) - обозначение потока материальных объектов.
• Ссылка (referent) - обозначение связи данной работы с материальным объектом, участвующим в этой деятельности (referent).
• Отношение (relational) - обозначение какого-либо другого влияния одной работы на другую, не обязательно. Стрелка типа "Отношение" обязательно должна быть именована для его разъяснения.

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

На рис.12 изображена информационная система в нотации DFD.

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

Рис. 12. Диаграмма работы информационной системы.

Заключение

В результате проделанной работы была изучена предметная область – структурное подразделение организации «Отдел кадров». В рамках анализа предметной области были составлены модели бизнес-процессов, функциональные модели и модели потоков данных с помощью BP Win Process Modeler. На основе проведённого анализа бала разработана модель базы данных с помощью ER Win Data Modeler и реализована сама БД в СУБД MS Access. При помощи интегрированной среды Delphi 7 Studio был разработан исполнимый интерфейсный модуль приложения.

Литература

1. В. Дубейковский, «Эффективное моделирование с CA ERwin Process Modeler (BPwin; AllFusion Process Modeler)», изд.: Диалог-МИФИ, 384с., 2009 г.
2. Емельянова Н. З., Партыка Т. Л., И. И. Попов, Проектирование информационных систем, М, Издательство: Форум, 2009 г., 432 стр.
3. Информационные технологии управления: Учебное пособие / ВЗФЭИ; Под ред. Г.А.Титоренко. - М.: ЮНИТИ, 2002, 2003.
4. Колбанев М.О., Яковлев С.А.Модели и методы оценки характеристик обработки информации в интеллектуальных сетях связи. СПб.: изд-во СПбГУ, 2002.
5. Методология IDEF0. Стандарт. Русская версия: Пер. с англ. М.: МетаТехнология, 1993. 117 с.
6. Создание IDEF-моделей: Методические указания к практическим занятиям / Рязан. гос. радиотехн. акад.; Сост.: В.Е. Борзых, А.В. Борзых. Рязань, 1999. 12 с.