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

Оглавление

Глоссарий

Введение

Глава 1. Обзор литературы и источников

1. Обзор источников

2. Выводы

Глава 2. Подход к разработке системы управления персоналом

1. Используемые методы

2. Создание алгоритма подсчёта мощности

3. Формирование требований к системе, выбор методологии построения системы и модели жизненного цикла

4. Внедрение системы учета рабочего времени

5. Автоматизация работы алгоритма подсчёта мощности

6. Формализация процесса принятия бизнес-решений на основании разработанного подхода

Глава 3. Практическая реализация подхода на примере компании ООО “Новая медицина”

1. Описание компании

2. Формирование текущей модели бизнес-процесса

3. Анализ модели бизнес-процесса

4. Создание алгоритма подсчёта мощности

5. Разработка требований к информационной системе

5.1 Общий взгляд на систему, методологию построения и модель жизненного цикла

5.2 Классы и характеристики пользователей

5.3 Операционная среда

5.4 Предположения и зависимости

5.5 Системные функции и функциональные требования

5.6 Целостность, сохранение и утилизация данных

5.7 Бизнес-правила

5.8 Атрибуты качества

5.9 Внешние интерфейсы

6. Описание способа автоматизации бизнес-процесса

7. Разработка моделей TO-BE и внедрение системы

7.1 Процесс планирования графика

7.2 Алгоритм подсчёта мощности

7.3 Разработка интерфейсов для вывода результатов работы алгоритма

7.4 Доработка системы и ее перспективы

7. Формализация процесса принятия бизнес-решений на основании разработанного подхода

Заключение

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



Глоссарий

API (Application Programming Interface) - готовый набор функционала, который предоставляется для использования во внешних приложениях;

EPC (Event-driven process chain) - используемый для моделирования бизнес-процессов тип блок-схемы;

MVP (minimal viable product) - минимальный полезный продукт, который приносит какую-либо ценность потребителю;

Бизнес-процесс - совокупность мероприятий, цель которых - создать продукт или услугу для клиента;

Маркетплейс - электронная торговая площадка, агрегирующая поставщиков;

Модель AS-IS - модель текущего состояния организации;

Модель TO-BE - модель идеального состояния организации, которая

Мощность - максимально возможный объем предложения в момент времени;

Стейкхолдер - заинтересованная сторона, имеющая интересы относительно системы или ее свойств;

Убер-модель - бизнес-модель компании, обеспечивающей поставку товаров или услуг клиентов по запросу, то есть работающей в рамках экономики по требованию;

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



Введение

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

Данная модель бизнеса, некогда получившая широко распространенное название “Uber-модель” и основанная на экономике по требованию, на данный момент используется в очень широком спектре отраслей - начиная от агрегаторов такси и заканчивая гостиничным бизнесом (Airbnb - запуск в 2008 [1], Uber - запуск в 2009[2], Yandex.Taxi - запуск в 2011[3]).

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

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

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

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

1. Провести анализ релевантной научной литературы и источников, освещающих:

a. Теоретические подходы к автоматизации бизнес-процессов;

b. Модель “экономики по требованию” и гибкие организационные структуры;

c. Методы учета рабочего времени;

d. Подходы к подсчету объема создаваемого предложения и теория систем массового обслуживания.

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

3. Описать предлагаемый подход для управления объемом предложения в компаниях с выбранным типом бизнес-модели;

4. Описать технику внедрения подхода на примере компании.

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

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

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

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

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

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

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



Глава 1. Обзор литературы и источников

1. Обзор источников

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

1. Модель “экономики по требованию” и гибкие организационные структуры;

2. Теоретические подходы к автоматизации бизнес-процессов;

3. Методы учета рабочего времени;

4. Подходы к подсчету объема создаваемого предложения и теория систем массового обслуживания.

Прежде всего, требуется разобраться с контекстом, в котором изучается проблема и планируется решить задачу разработки целевого подхода. Mike Jaconi [4] в Business Insider писал, что экономика по требованию создается технологичными компаниями, обеспечивающими потребности клиентов по их запросу без задержки. Он считает, что ее популярность обусловлена тем, что поведение клиентов поменялось под воздействием интернета: они привыкли получать желаемое гораздо более простым путем, чем раньше, а удовлетворять свои потребности по требованию - удобно. Удобство обеспечивается при помощи двух главных факторов: простоты использования и скорости получения желаемого. Поведение покупателей стало зависеть от удобства, что можно увидеть в исследовании, проведенном на группе из 250 покупателей “Whole Foods and Trader Joe”[5] (рис. 5):



Рисунок 1 - Исследование причин онлайн-покупок [5]

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

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

Как правило, в экономике по требованию задействованы контрактные рабочие, которые получают оплату за каждую оказанную услугу или сервис для клиента, однако не существует единой организационной структуры для компаний, использующих бизнес-модель, связанную с экономикой потребления. В 2015 году Huws [5] провел исследование 7 различных компаний, предоставляющих услуги по запросу, в результате чего стало понятно, что каждая компания использует свою организационную модель, отличающуюся по ряду критериев (таблица 1):



Таблица 1- Исследование организационных моделей 7 on-demand компаний [5]

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

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

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

1. Модели жизненного цикла ИС подробно описаны в работе “Управление жизненным циклом информационных систем: монография” [6] где описываны основные модели, сходства и различия между ними, таким образом появляется возможность выбрать наиболее подходящую модель для конкретной ситуации на основании описанных характеристик. Согласно определению, модель жизненного цикла - это комбинация этапов жизненного цикла системы и комбинирующиеся переходы между ними, которые должны привести к успешной реализации разработки системы. Е.П. Зараменских в своей работе упоминает четыре основных типа моделей жизненного цикла:

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

Рисунок 2 - Каскадная модель [6]

a. Каскадная модель с промежуточным контролем, где возможен возврат к предыдущим этапам, что с одной стороны снижает риски получения неудовлетворительного продукта в конце разработки, однако увеличивает срок разработки. Также, как и модель водопада, используя данную модель результаты проверяются только в конце разработки, что создает высокий риск продукта, который “отстал” от потребностей (модель представлена на рисунке 3).

Рисунок 3 - Каскадная модель с промежуточным контролем [6]

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

Рисунок 4 - Спиральная модель [6]

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

Рисунок 5 - Модель разработки через тестирование [6]

2. Методологии проектирования ИС подробно описаны в пособии “Проектирование информационных систем: курс лекций: учебное пособие для студентов вузов, обучающихся по специальностям в области информ. технологий” [7]. Авторы подробно рассматривают отличия Agile, SCRUM, RAD и прочих методологий друг от друга и описывают принципы использования каждой из методологий, рекомендуя оптимальные варианты их использования. Данные методологии также были рассмотрены в работе А. Иванова “Разработка проектного решения по оптимизации логистики стартапа” [8]:

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

· Взаимодействие людей важнее инструментов управления и процессов;

· Получить рабочий продукт важнее полной документации;

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

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

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

c. Методология RAD отличается использованием средств прототипирования для того, чтобы опробовать основную концепцию системы в кратчайшие сроки, после чего реализовать ее. Она идеально подходит для систем, условия к которым уточняются “на ходу” и не являются достаточно четкими с самого начала. Также, заказчик системы тесно сотрудничает с командой разработки, что позволяет более качественно формировать требования к ней и быстрее прийти к нужному результату, однако существует и минус: на первых порах результат может содержать урезанный функционал, так как разработка происходит по принципам MVP.

3. Методы описания требований к ИС и методы формирования функциональных требований к ИС подробно описаны в работе K. Wiegers “Разработка требований к программному обеспечению” [9]. Автор описывает существующие уровни требований, детализирует каждый уровень и категорию, связывает различные виды информации для требований между собой, описывает набор характеристик спецификаций требований, а также разбивает разработку функциональных требований на этапы и детально описывает каждый из них.

4. Согласно автору, требования состоят из 3 уровней:

· Бизнес-требования, которые объясняют цель разработки системы и какие задачи она решает;

· Функциональные требования, которые описывают функционал системы;

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

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

· Бизнес-правила;

· Системные требования;

· Ограничения;

· Внешний интерфейс;

· Атрибуты качества системы.

Взаимодействие всех правил показано на рисунке 6:



Рисунок 6 - Взаимодействие требований к системе [9]

Несмотря на то, что в настоящий момент не существует стандартизированной методологии автоматизации учета рабочего времени, некоторые источники раскрывают данную тему, хотя и не вдаваясь в глубоко технические подробности. Вывод, который можно сделать из изучения материалов, подтверждается в интернет-блоге компании Actitime [10]: “Ожидаемо, не существует “одного для всех” решения. Определение границ функциональных требований поможет сузить круг поиска решений.”. В той же статье рассматривается ряд факторов, которые могут сыграть роль при выборе системы для автоматизации учета рабочего времени, включая гибкость, опции отслеживания, возможности интеграции, цену и прочее. Для более детального изучения сферы автоматизации учета рабочего времени были также изучены лучшие практики российских и зарубежных компаний, включая проекты по интеграции продуктов компаний 1C, SAP, схожие системы в компаниях Uber и Яндекс.Такси, а также изучены статьи компании RTL Services по данной теме, что внесло большой вклад в моделирование идеального процесса.

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

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

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

Заявки приходят в систему потоком, который является случайным, однако можно оценить его в общем виде при помощи некоторых параметров, к примеру среднего числа поступающих заказов в единицу времени. Заказы могут влиять друг на друга, но как правило они не влияют и являются равноправными - в таком случае, учитывая что рассматривается только время поступления заявок, их поток называется однородным и без последствия. Поток, где вероятность появления заявок не зависит от времени начала интервала, на котором он рассматривается, а зависит только от длительности этого интервала, называется стационарным. Как правило, экономика по требованию связана с определенным законом распределения заявок, которые могут зависеть, к примеру, от времени дня, дня недели или времени года, таким образом поток заявок нельзя будет считать стационарным. К примеру, вероятность появления заявки на вызов такси в центре города выше с приближением полуночи, так как люди разъезжаются по домам из мест, где отдыхали, таким образом если рассматривать потоки длиной в 1 час, вероятность на потоке [20:00;21:00] меньше, чем на потоке [23:00;24:00].

Рассматриваемая в контексте теории систем массового обслуживания деятельность компании имеет ряд характеристик, которые можно разделить на базовые группы:

1. Показатели эффективности использования системы

a. Среднее количество заказов, обрабатываемых в единицу времени;

b. Отношение среднего количества обработанных заказов в единицу времени к среднему количеству поступивших заказов;

c. Средняя продолжительность периода занятости системы;

d. Утилизация системы.

2. Показатели качества обслуживания заказов

a. Среднее время ожидания заказа;

b. Среднее время от поступления заказа до его выполнения;

c. Вероятность начать выполнять заказ сразу после поступления;

d. Закон распределения времени ожидания заказов;

e. Закон распределения времени от поступления заказа до его выполнения;

f. Среднее число заказов в очереди;

g. Среднее число заказов в системе.

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

· Количество каналов;

· Допустимости отказов заявкам;

· Длины очереди заявок;

· Интенсивности потока заявок;

· Производительности каналов обслуживания.

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

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

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

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

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

Несмотря на вышеуказанные проблемы, часть теории можно использовать для формирования более простого подхода определения объема создаваемого предложения. Некоторые ученые и операционные менеджеры также предлагают подсчитывать мощность сервиса основываясь на статистических данных о процессах обслуживания: к примеру C. Reinboth в своей работе писал [12]: “мощность может быть подсчитана для любого бизнес-процесса. Она всегда определяется, как число ресурсов, выделенное под процесс, деленное на время предоставления сервиса. К примеру, если одному работнику требуется 40 секунд для приготовления сэндвича, то мощность этого процесса 1/40 сэндвича в секунду, или 1, 5 сэндвича в минуту. Если одновременно работают два работника, то мощность увеличивается до 2/40 сэндвича в секунду, или 3 сэндвича в минуту.”.

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

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



2. Выводы

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

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



Глава 2. Подход к разработке системы управления персоналом

1. Используемые методы

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

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

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

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

4. В рамках разработки подхода к управлению предложением, модель AS-IS бизнес-процесса должна быть проаудирована, после чего в результате анализа выделяются узкие места в процессе. На основании понимания узких мест, должна быть разработана модель TO-BE идеального процесса, с подробным пояснением алгоритма работы подхода.

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

2. Создание алгоритма подсчёта мощности

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

Таким образом, для вычисления мощности на день используется следующая формула в общем виде:

· x - дата, для которой рассчитывается мощность (может быть период времени, отличный от одного дня);

· T_working - общее время работы сотрудников за день;

· T_{per service} - время, нужное для однократного оказания сервиса или услуги.

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

3. Формирование требований к системе, выбор методологии построения системы и модели жизненного цикла

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

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

· Бизнес-требования - высокоуровневые требования, которые объясняют, почему необходима разработка данного программного обеспечения;

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

· Нефункциональные требования - требования, описывающие характеристики системы в целом, включающие в себя:

o Системные требования

o Бизнес-правила

o Ограничения

o Внешний интерфейс

o Атрибуты качества

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

4. Внедрение системы учета рабочего времени

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

5. Автоматизация работы алгоритма подсчёта мощности

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

6. Формализация процесса принятия бизнес-решений на основании разработанного подхода

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

7. Выводы

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



Глава 3. Практическая реализация подхода на примере компании ООО “Новая медицина”

1. Описание компании

В рамках практического примера реализация предложенного подхода к управлению мощностью сервиса проводилась в компании ООО “Новая медицина” (далее - DOC+). Сейчас DOC+ - самая крупная и единственная в России мобильная клиника. Проект начался с идеи современного сервиса вызова врача на дом: первым появился сайт, затем мобильное приложение, и постепенно DOC+ развился в мобильную клинику с докторами, анализами, удаленными консультациями и медицинской документаций.

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

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

2. Формирование текущей модели бизнес-процесса

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

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

· Включенное наблюдение

· Изучение документов

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

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

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

· Аудит процесса управления мощностью проходил во “внесезонное” время, когда заболеваемость ниже обычного и риск получить большое количество заказов, с которым не удастся справиться, сравнительно низок;

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

Рисунок 7 - процесс управления мощностью AS-IS

В результате аудита была сформирована модель AS-IS (рисунок 7), которая описывала текущее состояние процесса управления мощностью.

3. Анализ модели бизнес-процесса

При анализе модели AS-IS был выявлен ряд узких мест, которые создавали для компании большое количество издержек и рисков, а именно:

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

· Выполнение алгоритмов при помощи ручного труда оператора службы поддержки, что приводит к лишним временным затратам, а также паузам в разговорах с клиентами, что негативно сказывается как на финансовых издержках на зарплату сотрудников, так и на качестве клиентского сервиса;

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

· Отсутствие формализованного алгоритма оперативного контроля мощности, что выражается в неспособности оператора службы поддержки в любой момент времени дать ответ на вопрос: “сколько вызовов можно принять с Х часов по Y часов?”;

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

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

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

4. Создание алгоритма подсчёта мощности

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

Для вычисления мощности на день использовалась следующая формула, описанная в общем виде во второй главе:

· x - дата, для которой рассчитывается мощность;

· N - общее количество врачей, которые работают в день X;

· t_end - время конца смены;

· t_start - время начала смены;

· t_travel - среднее время доезда до вызова;

· t_visit - среднее время на вызове.

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

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

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

Рисунок 8 - шаблон подсчёта мощности в Google Spreadsheet

Данные о сменах врачей могли быть взяты из нескольких источников:

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

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

· Из данных IT системы (когда данный функционал был разработан и внедрен)

5. Разработка требований к информационной системе

5.1 Общий взгляд на систему, методологию построения и модель жизненного цикла

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

Система разрабатывается, следуя принципам MVP, то есть порциями разрабатывая критичный функционал, наиболее важный в момент времени - в соответствии с этой же парадигмой работает методология разработки SCRUM, выбранная для разработки:

· При выборе SCRUM конечный результат не придется долго ждать;

· После каждого спринта уже будет готов рабочий функционал;

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

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

5.2 Классы и характеристики пользователей

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

· Предполагается, что врачи будут использовать систему для внесения данных о своих запланированных сменах;

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

· Предполагается, что врачи будут использовать систему для внесения предварительных данных о времени работы;

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

· Предполагается, что заместители главного врача будут использовать систему для подтверждения или внесения изменений в график врачей-почасовиков;

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

· Предполагается, что оператор будет использоваться систему для управления мощностью;

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

5.3 Операционная среда

Система должна работать в любом современном интернет-браузере, включая Google Chrome (все версии), Mozilla Firefox (все версии), Apple Safari (все версии), а также Windows Internet Explorer версии 8 и 9. Система должна являться частью Bitrix и интегрирована с мессенджером Telegram в целях создания интерфейса контроля мощности.

5.4 Предположения и зависимости

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

5.5 Системные функции и функциональные требования

1. Планирование графика врача-почасовика

1.1. Составление плана смен на следующий месяц;

1.2. Просмотр плана смен на следующий месяц;

1.3. Подача графика смен на следующий месяц на согласование заместителю главного врача;

1.4. Внесение изменений в график смен на следующий месяц, а именно редактирование и удаление смен;

1.5. Получение внесенных заместителем главного врача изменений в графике на следующий месяц;

1.6. Подтверждение графика на следующий месяц;

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

1.8. Вывод данных из базы данных смен врачей-почасовиков в интерфейс графиков врачей.

2. Планирование графика врача-сдельщика

2.1. Добавление смен в план;

2.2. Просмотр плановых смен;

2.3. Редактирование смен в плане, а именно изменение и удаление;

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

2.5. Вывод данных из базы данных смен врачей-сдельщиков в интерфейс графиков врачей.

3. Подсчёт мощности сервиса

3.1. Реализация алгоритма подсчёта мощности сервиса;

3.2. Передача результатов реализации алгоритма во внешние интерфейсы;

3.3. Запись результатов реализации алгоритма в базу данных.

4. Просмотр результатов работы алгоритма подсчёта мощности в Bitrix

4.1. Отображение результатов работы алгоритма подсчёта мощности во вкладке “Мощность на сегодня”;

4.2. Перевод алгоритма в режим работы “высокая загрузка мощности” и построение карты мощности сервиса;

4.3. Фильтрация результатов работы алгоритма по различным параметрам.

5. Просмотр результатов работы алгоритма подсчёта мощности в Telegram

5.1. Отображение результатов работы алгоритма в соответствии со спецификациями к командам для Telegram-бота.

6. Просмотр результатов работы алгоритма подсчёта мощности в PowerBI

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

5.6 Целостность, сохранение и утилизация данных

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



5.7 Бизнес-правила

Таблица 2 - Бизнес-правила системы

Определение правила	Тип правила	Источник правила
График смен врача-почасовика должен подаваться максимум за 5 дней до конца месяца	Ограничение	Заместитель главного врача
Запись данных о фактической мощности за день в базу данных происходит ежедневно в 23:59	Факт	Операционный менеджер
Система должна разрабатываться на основе платформы Bitrix, так как вся инфраструктура IT системы DOC+ построена на ней.	Ограничение	Операционный менеджер
Врачи, отмеченные в IT системе как стажеры, в расчете мощности не должны участвовать (т.к. стажер ездит с куратором и обучается);	Ограничение	Операционный менеджер
Врачи, которые создали через приложение пересекающиеся смены (пример: врач начал смену в 8:00 на 4 часа, после чего передумал и в 8:02 начал еще одну смену на 6 часов - 3 часа 58 минут часа дублируются), должны учитываться в мощности при помощи только непересекающихся промежутков рабочего времени	Ограничение	Операционный менеджер
Врачи, отмеченные в графике как “в офисе”, в расчете мощности не должны участвовать	Ограничение	Операционный менеджер

5.8 Атрибуты качества

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

· Система должна поддерживать интеграцию с другими элементами IT инфраструктуры DOC+;

· Система должна работать быстро, производить все необходимые математические операции за несколько секунд;

· Система должна быть надежной: сбой может случаться не более, чем в 0, 1% подсчётов.

5.9 Внешние интерфейсы