Автоматизация процессов управления человеческими ресурсами в компании

Автоматизация процессов управления человеческими ресурсами в компании ХХХ.

Размещено на http://www.allbest.ru/

32

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет Бизнеса и менеджмента

Выпускная квалификационная работа

Автоматизация процессов управления человеческими ресурсами в компании

по направлению подготовки Бизнес информатика

образовательная программа «Бизнес-информатика»

Красногорская Полина Андреевна

Рецензент к.т.н, проф. В.И. Грекул

Научный руководитель

доцент Н.Л. Коровкина

Москва 2016



Содержание

Ключевые слова

Введение

Глава 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.2 Настройка системы ETWeb для автоматизации процесса «Управление результативностью»

3.3 Настройка системы ETWeb для автоматизации участка процесса «Управление обучением и развитием»

3.4 Результаты внедрения системы

Выводы третьей главы

Заключение

Библиография

Приложение



АРМ - автоматизированное рабочее место

АС - автоматизированная система

АСУП - Автоматическая система управления персоналом

ВК - Вычислительный комплекс

ИС - Информационная система

ПО - Программное обеспечение

СУБД - Система управления базой данных

HRIS - Human recourses information system

HRM - Human recourses management

Ключевые слова

Автоматизация процессов управления человеческими ресурсами, Human Resources Information System (HRIS), настройка системы ETWeb, этапы жизненного цикла ИС, усовершенствование HR-процессов путем автоматизации.



Введение

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

Компания ХХХ является одной из крупнейших сетей розничной торговли в Росси, наряду с такими компаниями как «Перекресток», «Карусель», «ОКЕЙ» и другими. Данная компания нацелена на доставку потребителям качественной продукции по низким ценам, о чем говорит ее миссия.

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

Согласно исследованию Global Productivity Report [1] компании теряют более полутора дней в неделю (в расчете на одного линейного руководителя) на оформление бумажной отчетности и принятие решений в области управления персоналом. А по данным СedarCrestone [1] автоматизация HR-процессов позволяет сократить материальные издержки на 48-52%, временные - на 40-62%, и повысить уровень удовлетворенности сотрудников на 50%. Именно эти факторы делают автоматизацию процессов управления человеческими ресурсами актуальной, так как снижение издержек является основной задачей любого бизнеса.

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

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

Итак, объектом исследования в данной работе являются процессы управления человеческими ресурсами торговой компании «ХХХ», а предметом исследования - средства автоматизации HR-процессов.

Целью данной работы является усовершенствование процессов управления персоналом путем их автоматизации.

Данная цель подразумевает ряд задач, которые должны быть решены для ее достижения:

· Анализ процессов управления человеческими ресурсами компании, ее деятельности и внутренней документации;

· Моделирование процессов управления человеческими ресурсами компании ХХХ.

· Формирование требований к автоматизации;

· Настройка системы для автоматизации ключевых процессов;

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

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

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



Глава 1. Анализ этапов создания автоматизированной системы

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

Жизненный цикл является одним из основных понятий, на которых основывается работа c информационными системами. ЖЦ представляет собой «ряд событий, происходящих с системой в процессе ее создания и использования» [2]. Этот процесс состоит из определенных этапов, и начинается с решения о создании системы и заканчивается ее выводом из эксплуатации.

Существует несколько моделей жизненного цикла ИС, которые используются в настоящее время [2]:

· Каскадная модель;

· Поэтапная модель;

· Спиральная модель.

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

Жизненный цикл системы регламентируется несколькими стандартами, наиболее известными из которых являются ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [3], ISO/IEC 12207: 2008 «Информационные технологии. Процессы жизненного цикла программного обеспечения» [4] и ISO/IEC 15288 «Системотехника. Процессы жизненного цикла системы» [5].

ISO/IEC 12207 и ISO/IEC 15288 стандарты, разработанные международной организацией по стандартизации. Эти документы описывают процессы и организацию жизненного цикла ИС, разделяя их на три категории: основные, вспомогательные и организационные. Данные стандарты устанавливают структуру процессов ЖЦ, а также определяют задачи и работы по каждому из них.

Главным отличием стандарта ISO/IEC 15288 от ISO/IEC 12207, является наличие в нем стадий жизненного цикла с их кратким обзором, целями и результатами, которые должны быть получены.

Российскими аналогами данных стандарта является ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» [6] и ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем» [7], который также содержат описание процессов жизненного цикла ИС. Стандарты были призваны унифицировать задачи, возникающие в ходе работ над созданием и внедрением системы, однако стандарт 2005 года предполагает соответствие задач, целей и результатов определенным работам, из которых состоят процессы ЖЦ, допуская при этом адаптацию процессов к специфике организации.

ГОСТ 34.601-90 полностью регламентирует стадии создания автоматизированной системы и этапы работ на каждой стадии жизненного цикла. Данный стандарт также описывает содержание работ (включая документацию и отчетность по этапам) на каждом этапе для общего случая. В документе приведены 8 стадий создания системы [3]:

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

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

· Техническое задание - стадия создания системы, в ходе которой исполнитель разрабатывает и утверждает у заказчика ТЗ на разработку АС.

· Эскизный проект - стадия создания системы, во время которой проектной командой выполняется разработка предварительных решений (эскизов) системы или ее частей и документации по ним.

· Технический проект - стадия создания системы, которая включает разработку исполнителями готовых проектных решений АС и её частей, документации по данным проектным решениям, а также документации на поставку или разработку комплектующих АС.

· Рабочая документация - стадия создания системы, в ходе которой исполнитель занимается разработкой рабочей документации, содержащей сведения по работам над вводом в эксплуатацию и поддержанием функционирования АС. Вид и содержание документов утверждены по ГОСТ 34.201-89 [8].

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

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

Согласно ГОСТ 34.601-90 каждая стадия содержит в себя несколько этапов работ, некоторые из которых будут подробно рассмотрены в данной работе.

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

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

На каждой стадии и этапе создания системы по ГОСТ 34.601-90 используются различные методики и инструменты, наиболее подходящие из которых подбираются для каждого конкретного случая исходя из ситуации.

Для выполнения работ по сбору информации об объекте автоматизации для этапа «Формирование требований к АС» используются такие методы как:

· Интервьюирование;

· Анализ внутренней документации;

· Экспресс-обследование компании;

· Информационное обследование компании.

Наиболее подходящий метод или инструмент выбирается в зависимости от требуемого объема информации,

На этом же этапе для формирования требований пользователя к системе используются следующие методики:

· Методика Карла Виргеса

· FURPS

· FURPS+

· SWEBOK

На этапе «Разработка концепции ИС» формируются модели бизнес-процессов, для этого определятся подход к моделированию (объектный или функциональный) и выбирается нотация (как правило используются нотации eECP или BPMN).

При документирования требований, в России как правило используются корпоративные стандарты, основанные на ГОСТ 34.602-89 [9] «Техническое задание на создание информационной системы» или сам этот стандарт, который подробно будет рассмотрен в рамках данной работы.

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

И на последнем рассмотренном в работе этапе - «Подготовка объекта автоматизации» будут рассмотрены подходы к настройке системы.

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

1.1 Формирование требований к автоматизированной системе

Формирование требований к системе начинается со сбора необходимой для этого информации. На первом этапе работ проводится обследование компании, которое необходимо для формирования представлений о компании, ее целях, задачах и автоматизируемых бизнес-процессах. Также необходимо описать информационный ландшафт компании, чтобы определить в нем место для внедряемого решения. Существует несколько различных подходов к обследованию объекта автоматизации: экспресс-обследование и информационное обследование [10].

Экспресс-обследование компании

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

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

· Краткое описание компании: виды деятельности, организационную и функциональную структуры.

· Описание основных бизнес-процессов компании (as is - как есть).

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

· Описание проблем, выявленных в компании.

· Пожелания заказчика и варианты решения, концепцию будущей системы, с помощью которой будут совершенствоваться процессы (to be - как будет).

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

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

Информационное обследование компании

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

· Сбор информации о компании (документации, анкет, интервью и т.д.).

· Анализ и систематизация данных, полученных в ходе первого этапа.

· Представление результатов для согласования с заказчиком.

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

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

· Анкеты для топ-руководителей;

· Анкеты для линейных руководителей;

· Анкеты для линейного персонала.

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

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

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

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

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

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

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

Требования по методике Карла Виргеса

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

Функциональные требования:

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

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

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

Нефункциональные требования:

· Бизнес-правила не являются требованиями в общепринятом смысле, но они являются источниками для требований к ИС. Бизнес-правилами могут быть политики, стандарты, регламенты и предписания, которые ограничивают или определяют ход бизнес-процессов.

· Атрибуты качества - это требования, которые являются дополнительным описанием функций системы или ее производительности. Такими требованиями могут быть простота использования, логичность, отказоустойчивость, устойчивость к сбоям и прочие.

· Ограничения - технические ограничения на разработку вида и структуры продукта.

· Внешние интерфейсы - требования, описывающие взаимодействие меду системой и пользователем или другим ПО.

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

FURPS и FURPS+

Данная методика позволяет охватить все аспекты системы и является более широким представлением методики FURPS. Обе методики основаны на методике Карла Виргеса и делят требования на функциональные и нефункциональные, однако далее имеют немного отличающуюся логику деления. Название методики является аббревиатурой [12]:

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

· Usability (Удобство использования) - это требования, основанные на человеческом факторе. То есть субъективные пожелания пользователей системы. В данные требования могут быть включены требования к интерфейсу (его интуитивная понятность, эстетичность, логичность), к эксплуатационной документации (ее полнота и понятность), а также к защите от ошибок.

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

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

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

В методике FURPS+ помимо требований первоначального стандарта, были добавлены некоторые ограничения:

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

· Ограничения разработки - это ограничения, которые задают необходимые стандарты кодирования: язык программирования, стандарты, инструменты или платформы.

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

· Физические ограничения - это ограничения, которые оказывают влияние на аппаратную часть системы (размер, вес, условия работы и т.д)

SWEBOK

Как и FURPS, SWEBOK является аббревиатурой (Software Engineering Body of Knowledge). Это документ призванный объединить в себе знания по разработке программного обеспечения и содержащий 10 различных областей знаний, первой из которых является инженерия требований.

Согласно данному документу работа над формированием требований должна проходить в несколько этапов: определение, анализ, спецификация, проверка и управление, а область знаний «Требования к программному обеспечению» состоит из 6 разделов [13]:

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

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

· Анализ требований - процесс во время которого исследуются потребности и цели пользователей, которые сопоставляются с требованиями к системе для устранения конфликтов между требованиями, формирования границ системы и выявления приоритетов. На данном этапе требования разделяются на функциональные и нефункциональные.

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

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

· Управление требованиями - процесс внедрения требований во все этапы жизненного цикла, контроля реализации требований и корректировка требований при необходимости.

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

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 является очень трудоемким, а модели, как правило, получаются очень громоздкими, ввиду чего их неудобно читать и документировать.

1.3 Документирование требований к информационной системе

Следуя стандартам, требования могут быть задокументированы по ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Данный документ содержит 9 разделов [9]:

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

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

· Характеристика объектов автоматизации - раздел, в котором представлена информация об объекте автоматизации, его условиях эксплуатации и характеристиках внешней среды.

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

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

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

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

· Требования к документированию - раздел, который включает перечень документов, необходимых для разработки в рамках создания системы. Перечень и вид документов регламентируется ГОСТ 34.201-89.

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

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

ГОСТ 34.602-89 является наиболее популярным стандартом серии. В крупных компаниях частного сектора, а также почти во всех государственных компаниях при разработке ТЗ на создание АС данный стандарт используется в обязательном порядке. Подробное описание требований к системе, формируемой в ходе ее создания документации, составу работ и порядку контроля позволяет компаниям обезопасить себя от многих проектных рисков, о которых на ранних этапах многие даже не подозревают.

1.4 Разработка проектного решения

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

Подходы к автоматизации

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

Рисунок 1. Подходы к построению информационных систем

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

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

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

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

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

Второй метод заключается во внедрении уже существующих решений: «коробочных» и адаптируемых систем.

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

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

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

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

Функциональность и уровень автоматизации процессов

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

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

Согласно общепринятой методологии, системы класса HRIS делятся по уровню автоматизации на три типа [17]:

· Автоматизация расчета зарплаты;

· Автоматизация кадрового учета;

· Автоматизация управления трудовыми ресурсами.

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

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

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

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

В исследовании компанией «Forrester Research» было выделено шесть основных функциональных блоков HRM-систем, которые группируются в три уровня пользования системой [18]:

1. Пользовательский уровень

1.1 Средства пользовательского взаимодействия

1.2 Процессы пользователя;

1.1.1 Процессы менеджера;

1.1.2 Процессы наемного (временного) сотрудника;

1.1.3 Контент и коммуникации;

1.1.4 Аналитика и отчетность.

2. Уровень развития персонала

2.1 Управление эффективностью и талантами

2.1.1 Управление эффективностью сотрудников;

2.1.2 Планирование успеха;

2.1.3 Управление компетенциями;

2.1.4 Управление обучением;

2.1.5 Управление карьерным продвижением.

2.2 Управление компенсациями и льготами

2.2.1 Структурирование заработной платы;

2.2.2 Формирование не денежных компенсаций;

2.2.3 Выплаты бонусов.

2.3 Управление рекрутинговым процессом

2.3.1 Планирование найма персонала;

2.3.2 Выставление вакансий;

2.3.3 Обработка заявок претендентов;

2.3.4 Адаптация новых сотрудников.

3. Уровень базовых операций

3.1 Управление человеческими ресурсами

3.1.1 Контроль рабочего времени;

3.1.2 Анализ рабочего времени;

3.1.3 Подсчет сверхурочных.

3.2 Базовые транзакции

3.2.1 Запись и хранение данных о сотрудниках;

3.2.2 Управление выгодами;

3.2.3 Расчет заработной платы;

3.2.4 Управление позициями;

3.2.5 Соблюдение законодательных и регулятивных норм.

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

1.5. Подготовка объекта к автоматизации процессов

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

Настройка системы производится несколькими способами [10]:

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

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

· Настройка полей и создание библиотек

· Настройка бизнес-логики

· Интерфейс пользователя, расположение элементов на вкладках

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

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

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

...