Разработка системы управления персоналом
Оглавление
Глоссарий
Введение
Глава 1.
Обзор литературы и источников
. Обзор
источников
. Выводы
Глава 2.
Подход к разработке системы управления персоналом
.
Используемые методы
. Создание
алгоритма подсчёта мощности
.
Формирование требований к системе, выбор методологии построения системы и
модели жизненного цикла
. Внедрение
системы учета рабочего времени
.
Автоматизация работы алгоритма подсчёта мощности
.
Формализация процесса принятия бизнес-решений на основании разработанного
подхода
Глава 3.
Практическая реализация подхода на примере компании ООО “Новая медицина”
. Описание
компании
.
Формирование текущей модели бизнес-процесса
. Анализ
модели бизнес-процесса
. Создание
алгоритма подсчёта мощности
. Разработка
требований к информационной системе
.1 Общий
взгляд на систему, методологию построения и модель жизненного цикла
.2 Классы и
характеристики пользователей
.3
Операционная среда
.4
Предположения и зависимости
.5 Системные
функции и функциональные требования
.6
Целостность, сохранение и утилизация данных
.7
Бизнес-правила
.8 Атрибуты
качества
.9 Внешние
интерфейсы
. Описание
способа автоматизации бизнес-процесса
. Разработка
моделей TO-BE и внедрение системы
.1 Процесс
планирования графика
.2 Алгоритм
подсчёта мощности
.3 Разработка
интерфейсов для вывода результатов работы алгоритма
.4 Доработка
системы и ее перспективы
.
Формализация процесса принятия бизнес-решений на основании разработанного
подхода
Заключение
Список
использованных материалов
Глоссарий
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. Провести анализ
релевантной научной литературы и источников, освещающих:. Теоретические
подходы к автоматизации бизнес-процессов;. Модель “экономики по требованию”
и гибкие организационные структуры;. Методы учета рабочего времени;. Подходы
к подсчету объема создаваемого предложения и теория систем массового
обслуживания.
. Выявить особенности,
которые необходимо учесть при разработке подхода к управлению объемом
предложения;
. Описать предлагаемый
подход для управления объемом предложения в компаниях с выбранным типом
бизнес-модели;
. Описать технику
внедрения подхода на примере компании.
Объектом данной работы являются бизнес-процессы, связанные с
управлениями операциями, персоналом и объемом создаваемого предложения в
компаниях, обеспечивающих поставку товаров и услуг по запросу.
Предметом исследования является оптимизация бизнес-процессов,
связанных с операционной деятельностью и управлением персоналом, а также
структурирование их и построение системы для их организации.
Методологическую основу данной работы составляют изученные лучшие практики
компаний, обеспечивающих поставку товаров и услуг по запросу, включая
компании-агрегаторы такси (Яндекс.Такси, Uber и прочие). Также в ходе работы
были изучены теоретические подходы к автоматизации бизнес-процессов, включая
методологии построения ИС и формирование функциональных требований, подходы к
учету рабочего времени персонала и определению возможного предложения услуг
компании.
Теоретическая значимость данной работы заключается в построении, реинжиниринге
и описании основных бизнес-процессов и бизнес-процессов управления,
используемых в развивающихся компаниях.
Практическая значимость данной работы состоит в возможном применении
разработанных бизнес-процессов и спроектированной системы в различных
компаниях, поставляющих товары и услуги по запросу. Теоретические изыскания,
описанные в данной работе, являются универсальными и могут быть применены в
компаниях с гибкой организационной структурой и меняющимся количеством
персонала, перед которыми стоит задача удовлетворения входящего спроса
динамическим предложением.
Структура работы включает пять блоков: введение, обзор литературы и
релевантных источников, описание подхода к построению целевой системы
управления предложением и персоналом, пример реализации данного подхода на
практике и заключение. Результатом проделанной работы является продукт,
позволяющий контролировать мощность сервиса как оперативно, так и
стратегически, а также описание кейса пошагового создания и внедрения данного
продукта на примере реальной российской компании.
Ограничения работы состоят в том, что в ней рассматриваются только
компании с гибкой организационной структурой и динамическим количеством
персонала, где существуют работники, которые могут начать обеспечивать клиентов
товарами или услугами в любое время, без жесткого графика.
Глава 1. Обзор литературы и источников
. Обзор источников
Для того, чтобы успешно решить поставленные задачи работы были изучены
материалы, которые освещают следующие темы:
. Модель “экономики по требованию” и гибкие организационные
структуры;
. Теоретические подходы к автоматизации бизнес-процессов;
. Методы учета рабочего времени;
. Подходы к подсчету объема создаваемого предложения и теория
систем массового обслуживания.
Прежде
всего, требуется разобраться с контекстом, в котором изучается проблема и
планируется решить задачу разработки целевого подхода. 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]
. Спиральная модель, которая предполагает допустимость начала
работы над следующим этапом разработки до завершения предыдущего, что позволяет
создавать продукт итерациями, каждый раз улучшая его качество и используя
прототипирование, что выгодно отличает ее от моделей, где результат нельзя
проверить на работоспособность в одной из первых итераций (модель представлена
на рисунке 4).
Рисунок 4 -
Спиральная модель [6]
c. Модель разработки через тестирование, или V-модель, где с течением времени
возрастает степень детализации проекта, а промежуточные результаты проверяются
на ранних стадиях. Такая модель позволяет снизить риски, соотнося итерации
(модель представлена на рисунке 5).
Рисунок
5 - Модель разработки через тестирование [6]
2. Методологии
проектирования ИС подробно описаны в
пособии “Проектирование информационных систем: курс лекций: учебное пособие для
студентов вузов, обучающихся по специальностям в области информ. технологий”
[7]. Авторы подробно рассматривают отличия Agile, SCRUM,
RAD и прочих методологий друг от друга и описывают
принципы использования каждой из методологий, рекомендуя оптимальные варианты
их использования. Данные методологии также были рассмотрены в работе А. Иванова
“Разработка проектного решения по оптимизации логистики стартапа” [8]:
a. Методология Agile
не имеет четких инструкций, взамен она предлагает придерживаться некоторых
базовых правил-приоритетов разработки. Agile качественно адаптируется к изменениям и позволяет
быстро получить работающий продукт. Принципы Agile включают в себя:
· Взаимодействие людей важнее инструментов управления и
процессов;
· Получить рабочий продукт важнее полной документации;
· Сотрудничать с конечным пользователем системы важнее
формальных вопросы;
· Важнее адаптироваться к изменениям, чем следовать
фиксированному плану.. Методология SCRUM сфокусирована на предоставлении рабочего продукта с
новыми возможностями с наивысшим приоритетом пользователю в кратчайший срок.
Работа по данной методологии производится так называемыми спринтами (итерациями
сроком до 6 недель), для которых важно получить заданный результат. Таким
образом, формулируется необходимый функционал для разработки, после чего он
создается в результате спринта.. Методология RAD отличается использованием средств прототипирования
для того, чтобы опробовать основную концепцию системы в кратчайшие сроки, после
чего реализовать ее. Она идеально подходит для систем, условия к которым
уточняются “на ходу” и не являются достаточно четкими с самого начала. Также,
заказчик системы тесно сотрудничает с командой разработки, что позволяет более
качественно формировать требования к ней и быстрее прийти к нужному результату,
однако существует и минус: на первых порах результат может содержать урезанный
функционал, так как разработка происходит по принципам MVP.
3. Методы
описания требований к ИС и методы формирования функциональных требований к ИС подробно описаны в работе K. Wiegers
“Разработка требований к программному обеспечению” [9]. Автор описывает
существующие уровни требований, детализирует каждый уровень и категорию,
связывает различные виды информации для требований между собой, описывает набор
характеристик спецификаций требований, а также разбивает разработку
функциональных требований на этапы и детально описывает каждый из них.
. Согласно
автору, требования состоят из 3 уровней:
· Бизнес-требования, которые объясняют цель разработки системы
и какие задачи она решает;
· Функциональные требования, которые описывают функционал
системы;
· Требования пользователей, которые описывают задачи, которые
пользователь будет решать в системе.
У каждой системы также существует набор нефункциональных требований,
которые включают в себя ряд правил:
· Бизнес-правила;
· Системные требования;
· Ограничения;
· Внешний интерфейс;
· Атрибуты качества системы.
Взаимодействие всех правил показано на рисунке 6:
Рисунок
6 - Взаимодействие требований к системе [9]
Несмотря
на то, что в настоящий момент не существует стандартизированной методологии
автоматизации учета рабочего времени, некоторые источники раскрывают данную
тему, хотя и не вдаваясь в глубоко технические подробности. Вывод, который
можно сделать из изучения материалов, подтверждается в интернет-блоге компании Actitime
[10]: “Ожидаемо, не существует “одного для всех” решения. Определение границ
функциональных требований поможет сузить круг поиска решений.”. В той же статье
рассматривается ряд факторов, которые могут сыграть роль при выборе системы для
автоматизации учета рабочего времени, включая гибкость, опции отслеживания,
возможности интеграции, цену и прочее. Для более детального изучения сферы
автоматизации учета рабочего времени были также изучены лучшие практики российских
и зарубежных компаний, включая проекты по интеграции продуктов компаний 1C,
SAP, схожие системы в компаниях Uber и Яндекс.Такси, а также изучены статьи
компании RTL Services по данной теме, что внесло большой вклад в моделирование
идеального процесса.
Вопрос
соотношения спроса и предложения в бизнесе рассматривает теория систем
массового обслуживания, основываясь на теории вероятности и статистике.
Согласно определению математического энциклопедического словаря, теория систем
массового обслуживания - это один из разделов теории вероятностей, ставящий
целью выбор структуры системы и процесса обслуживания на основании потоков
требований на обслуживание, длительности ожидания и длины очереди [11]. Как
правило, в теории систем массового обслуживания для решения поставленных задач,
а именно оценки свойств и качества работы системы, используются теория очередей
и моделирование, при этом изначально конфигурация системы оценивается при
помощи первого метода, после чего проводится моделирование.
Системы
делятся на открытые, где характеристики потока заявок не зависят от состояния
самой системы и заявки могут приходить извне системы, и закрытые, где такая
зависимость есть, поток заявок ограничен и заявки, ушедшие из системы, могут
вернуться в нее. В контексте систем массового обслуживания работа компании в
рамках экономики по требованию является открытой системой, где дисциплина
обслуживания, то есть алгоритм взаимодействия заявки и исполнителя (так
называемого канала), заключается в том, что в любой момент времени сотрудник
компании может обслуживать не более одной заявки.
Система
имеет в своем составе каналы обслуживания - в рассматриваемом контексте ими
являются сотрудники компании, которые обрабатывают заявки - поступающие заказы.
Заявки
приходят в систему потоком, который является случайным, однако можно оценить
его в общем виде при помощи некоторых параметров, к примеру среднего числа
поступающих заказов в единицу времени. Заказы могут влиять друг на друга, но
как правило они не влияют и являются равноправными - в таком случае, учитывая
что рассматривается только время поступления заявок, их поток называется
однородным и без последствия. Поток, где вероятность появления заявок не
зависит от времени начала интервала, на котором он рассматривается, а зависит
только от длительности этого интервала, называется стационарным. Как правило,
экономика по требованию связана с определенным законом распределения заявок,
которые могут зависеть, к примеру, от времени дня, дня недели или времени года,
таким образом поток заявок нельзя будет считать стационарным. К примеру,
вероятность появления заявки на вызов такси в центре города выше с приближением
полуночи, так как люди разъезжаются по домам из мест, где отдыхали, таким
образом если рассматривать потоки длиной в 1 час, вероятность на потоке
[20:00;21:00] меньше, чем на потоке [23:00;24:00].
Рассматриваемая
в контексте теории систем массового обслуживания деятельность компании имеет
ряд характеристик, которые можно разделить на базовые группы:
1. Показатели
эффективности использования системы. Среднее количество заказов,
обрабатываемых в единицу времени;. Отношение среднего количества
обработанных заказов в единицу времени к среднему количеству поступивших
заказов;. Средняя продолжительность периода занятости системы;. Утилизация
системы.
2. Показатели
качества обслуживания заказов. Среднее
время ожидания заказа;. Среднее время от поступления заказа до его
выполнения;. Вероятность начать выполнять заказ сразу после поступления;. Закон
распределения времени ожидания заказов;. Закон распределения времени от
поступления заказа до его выполнения;. Среднее число заказов в
очереди;. Среднее число заказов в системе.
Данные показатели зависят от
структуры системы и рассчитываются на основании некоторых вводных данных:
· Количество каналов;
· Допустимости отказов заявкам;
· Длины очереди заявок;
· Интенсивности потока заявок;
· Производительности каналов обслуживания.
Хотя теория систем массового
обслуживания хорошо справляется с задачей качественной оценки работы системы и
ее параметров, есть несколько важных причин, по которым для рассматриваемой в
контексте специфической модели бизнеса имеет смысл рассмотреть иной подход к
оценке соотношения спроса и предложения:
. Теория систем
массового обслуживания нацелена больше на оценку качественных показателей
эффективности системы, чем на количественные показатели, в то время как
решаемая проблема заключается в отсутствии подхода к оценке количественного
значения объемов предложения;
. В рассматриваемых
бизнес-моделях часть сотрудников работают по фиксированному графику, в то время
как часть выходит на работу в случайные моменты времени и работает неизвестное
заранее время. Таким образом, они формируют случайный поток работающих каналов
системы, что очень сложно уместить в привычные рамки систем массового
обслуживания с фиксированным количеством каналов, на основании количества
которых определяются показатели эффективности системы;
. Потоки в системах
массового обслуживания оцениваются довольно при помощи сильных аппроксимаций, в
то время, как во многих типах бизнеса важна точность получаемых значений. К
примеру, поток заявок считается однородным с постоянной средней интенсивностью
поступления заявок. В реальной жизни заявки поступают в соответствии с
совершенно различными правилами, для учета которых не предусмотрено
инструментов.
. Количественная
оценка объемов предложения может быть получена при помощи простейших
вычислений, а точность достигнута при помощи использования исторических данных,
что при автоматизации позволит сделать алгоритм подсчета быстро работающим, в
то время как используя формулы теории массового обслуживания алгоритм получится
гораздо более сложным и хуже решающим поставленную задачу.
Несмотря
на вышеуказанные проблемы, часть теории можно использовать для формирования
более простого подхода определения объема создаваемого предложения. Некоторые
ученые и операционные менеджеры также предлагают подсчитывать мощность сервиса
основываясь на статистических данных о процессах обслуживания: к примеру C. Reinboth
в своей работе писал [12]: “мощность может быть подсчитана для любого
бизнес-процесса. Она всегда определяется, как число ресурсов, выделенное под
процесс, деленное на время предоставления сервиса. К примеру, если одному
работнику требуется 40 секунд для приготовления сэндвича, то мощность этого
процесса 1/40 сэндвича в секунду, или 1, 5 сэндвича в минуту. Если одновременно
работают два работника, то мощность увеличивается до 2/40 сэндвича в секунду,
или 3 сэндвича в минуту.”.
Именно
такие простейшие расчёты стоят за подходом для рассматриваемых моделей бизнеса,
результат которого подвергаются сильной доработке при помощи массивов известной
исторической информации.
Подход
теории массового обслуживания при этом является крайне полезным для оценки
качества работы системы, но это не является целью данной работы, из-за чего эта
задача может рассматриваться лишь как одна из доработок системы управления
мощностью и персоналом.
2. Выводы
В данной главе был произведен разбор изученных материалов, освещающий
ключевые релевантные темы для исследования. В ходе разбора информации из
источников были получены новые знания об изучаемых сферах, которые в дальнейшем
были применены в работе.
Также, был изучен альтернативный подход к решению поставленной проблемы,
однако он оказался не в полной мере применим для достижения поставленной цели,
хотя может применяться в дальнейшем для доработки создаваемого подхода.
Глава 2. Подход к разработке системы управления персоналом
. Используемые методы
Для разработки подхода к оценке объемов предложения и системы управления
персоналом используется ряд методов:
. Для того, чтобы описать деятельность компании, предлагается
применить методы наблюдения за реализацией бизнес-процессов в компании, а также
интервьюирование задействованных в данных процессах лиц, после чего собранные
данные были проанализированы. Данные методы дали возможность изучить
деятельность компании и систематизировать знания о ней.
. Те же самые методы предлагается применять для выявления текущих
проблем с управлением предложением - для этого сотрудники, занятые в
бизнес-процессе управления предложением и персоналом должны быть
проинтервьюированы, а также должно быть проведено включенное наблюдение за
реализацией бизнес-процесса, после чего при помощи моделирования в нотации EPC можно систематизировать знания о
бизнес-процессе управления предложением AS-IS. Данная нотация
была выбрана из-за ее простоты, которая, однако, не препятствует полной
систематизации всех необходимых элементов на диаграмме, включая ресурсы,
сотрудников и документы. В качестве программного обеспечения для моделирования
было выбрано решение Edraw Max из-за
доступности и удобного для пользователя интерфейса, а также из-за простоты
установки на современных операционных системах, в отличие от некоторых других
популярных продуктов.
. Для формирования функциональных требований к системе
предлагается применить такие методы, как интервьюирование стейкхолдеров и
анализ результатов интервью с целью выявления потребностей каждой функции, а
также формализацию данных потребностей в едином документе.
. В рамках разработки подхода к управлению предложением, модель AS-IS бизнес-процесса должна быть проаудирована, после чего в
результате анализа выделяются узкие места в процессе. На основании понимания
узких мест, должна быть разработана модель TO-BE идеального
процесса, с подробным пояснением алгоритма работы подхода.
Для решения проблемы неопределенности предложения в компании с гибкой
организационной структуры предлагается использовать идеологию MVP, то есть решать проблему пошагово,
при этом на каждом шаге создавать ценность для потребителей. Конечная цель,
которая достигается при выполнении всех шагов - это модель процесса TO-BE, сформированная заранее.
2. Создание алгоритма подсчёта мощности
Первым шагом является формулирование подхода к численному измерению
мощности сервиса, который позволяет ответить на вопрос: “Сколько раз компания
может оказать сервис сегодня, и что нужно сделать, чтобы изменить эту цифру?”.
Реализация данного алгоритма основывается всего на двух величинах: времени работы
сотрудников и времени, требуемом для оказания сервиса клиенту один раз.
Таким образом, для вычисления мощности на день используется следующая
формула в общем виде:
· x - дата, для которой рассчитывается мощность (может быть
период времени, отличный от одного дня);
· Tworking - общее время работы сотрудников за
день;
· Tper service - время, нужное для однократного
оказания сервиса или услуги.
Таким образом, решается самая базовая проблема: отсутствие понимания о количестве
услуг, которые может оказать компания за период времени. Данный подход уже
позволяет отслеживать мощность сервиса как минимум вручную, без автоматизации.
Несмотря на простоту, он является необходимым шагом к построению целевой
системы.
3. Формирование требований к системе, выбор методологии
построения системы и модели жизненного цикла
Прежде всего требуется выбрать методологию построения системы и модель ее
жизненного цикла, основываясь на принципах сотрудников компании, участвовавших
в проекте, а также принципах подхода MVP. Далее требуется сформировать требования к конечному продукту, то есть
всей системе целиком, которые делятся на три категории:
· Требования пользователей - характеристика задач, которые
будут выполняться пользователями программного обеспечения и которые оно
помогает решать им;
· Бизнес-требования - высокоуровневые требования, которые
объясняют, почему необходима разработка данного программного обеспечения;
· Функциональные требования - требования к функционалу
программного обеспечения, которое будет разрабатываться, который будет
одновременно отвечать требованиям пользователей и бизнес-требованиям.
· Нефункциональные требования - требования, описывающие
характеристики системы в целом, включающие в себя:
o Системные требования
o Бизнес-правила
o Ограничения
o Внешний интерфейс
o Атрибуты качества
Следует отметить, что на каждом отдельном шаге будут выделяться те
требования, которые ему релевантны, так как вся система делится на составные
части, которые разрабатываются по-отдельности.
4. Внедрение системы учета рабочего времени
Так как долгосрочной целью является автоматизация подсчёта мощности,
предварительно требуется внедрить систему отслеживания рабочего времени. Для
этого нужно прежде всего изучить рынок и системы, которые есть на рынке, после
чего принять решение либо о интеграции существующей системы, либо о разработке
собственной. Таким образом, после выделения релевантных данному шагу требований
из заранее подготовленных, возможна подготовка технического задания для отдела
разработки, в соответствии с которым создается необходимый функционал,
позволяющий учитывать рабочее время сотрудников в IT системе компании.
5. Автоматизация работы алгоритма подсчёта мощности
После того, как стало возможным отслеживать рабочее время сотрудников,
требуется автоматизировать подсчёт мощности в соответствии с алгоритмом. На
данном этапе также нужно выделить из уже сформированных требований релевантные
данному шагу требования, а также подготовить модель TO-BE процесса
подсчёта мощности. Одновременно с автоматизацией подсчётов нужно продумать
удобный интерфейс, который может быть использован всеми стейкхолдерами процесса
для оперативного управления мощностью сервиса. После того, как данные документы
подготовлены, техническое задание вместе с ними передается в отдел разработки,
который автоматизирует алгоритм, а также разрабатывают интерфейс для вывода
результатов подсчёта.
6. Формализация процесса принятия бизнес-решений на основании
разработанного подхода
После разработки всей системы, требуется формализовать бизнес-процесс
принятия решений на основании данных системы. Принятие решений можно разделить
на два типа: оперативные, которые принимаются для краткосрочной перспективы, к
примеру в рамках одного дня, и стратегические - долгосрочные, к примеру
формулирование стратегии по системному повышению мощности на период акции
маркетинга. На данном этапе должна быть сформирована модель TO-BE процесса принятия решений, которая будет реализована в
компании.
7. Выводы
В данной главе был описан предлагаемый подход для создания системы
управления персоналом в рассматриваемом типе компаний, которая по сути является
системой управления объемом предложения. На основании предлагаемого подхода в
главе 3 описывается практическая реализация на примере реальной компании с
рассматриваемой бизнес-моделью. Также, в данной главе рассмотрены методы,
необходимые для реализации разрабатываемого подхода, и примененные на практике.
Глава 3. Практическая реализация подхода на примере компании
ООО “Новая медицина”
. Описание компании
В рамках практического примера реализация предложенного подхода к
управлению мощностью сервиса проводилась в компании ООО “Новая медицина” (далее
- 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;
· tend - время конца смены;
· tstart - время начала смены;
· ttravel - среднее время доезда до вызова;
· tvisit - среднее время на вызове.
В знаменателе дроби находится среднее время, требуемое для осуществления
одного вызова, которое состоит из двух частей: доезда до вызова и времени,
проведенного на вызове. В числителе находится сумма рабочего времени
сотрудников, которые находятся в избранный период времени на смене и могут
осуществлять вызовы. Таким образом, можно определить, сколько вызовов могут
сделать все сотрудники, находящиеся на смене.
Уже на данном этапе операторы начали подсчитывать мощность, еще до
автоматизации данного процесса. Для этого был подготовлен специальный файл в Google Sheets, где при помощи формул и таблиц был сформирован
шаблон, используемый каждый день.
Каждое утро операторы заполняли шаблон, вставляя туда фамилии докторов,
начало и конец запланированной смены, при этом формулы в шаблоне подсчитывали
мощность на основании заданных параметров среднего времени доезда и среднего
времени приема, которые в свою очередь были определены на основании статистики
заказов, выгружаемой из IT
системы. Формат шаблона изображен на рисунке 8 (данные заполнены для примера и
не отражают реальный состав смен или мощность сервиса):
Рисунок 8 - шаблон подсчёта мощности в Google Spreadsheet
Данные о сменах врачей могли быть взяты из нескольких источников:
· Из табелей учета рабочего времени, в которых врач должен
расписываться при заходе на смену и уходе с нее
· Из расписания врачей, которое составляется ежемесячно (но в
этом случае в течение дня необходимо проводить периодические проверки, чтобы
убедиться, что все, кто должен был, вышел на смену)
· Из данных IT
системы (когда данный функционал был разработан и внедрен)
5. Разработка требований к
информационной системе
.1 Общий взгляд на систему,
методологию построения и модель жизненного цикла
Разрабатываемая система должна дать возможность врачам самостоятельно
управлять своим графиком, отслеживать все время работы (как планируемое, так и
фактическое), а также на основании этих данных подсчитывать мощность сервиса в
указанный промежуток времени. Предполагается разрабатывать систему в несколько
этапов, постепенно добавляя функционал для различных пользователей. Сама
разрабатываемая система будет являться частью целостной IT системы компании, но для удобства
будем рассматривать часть, отвечающую за управление персоналом и подсчёт
мощности, как отдельную подсистему.
Система разрабатывается, следуя принципам MVP, то есть порциями
разрабатывая критичный функционал, наиболее важный в момент времени - в
соответствии с этой же парадигмой работает методология разработки SCRUM, выбранная для разработки:
· При выборе SCRUM
конечный результат не придется долго ждать;
· После каждого спринта уже будет готов рабочий функционал;
· Основная роль выделена product owner-у, представляющему интересы конечных пользователей.
В качестве модели жизненного цикла была выбрана спиральная модель с целью
постоянной доработки системы в соответствии с желаемыми изменениями, при этом
стейкхолдеры смогут видеть результат работы и помогать формировать видение
дальнейшего развития.
.2 Классы и характеристики пользователей
· Врач-почасовик - это сотрудник компании, который оказывает
услуги клиентам, а именно выезжает на дом к пациентам с целью лечения, при этом
он получает оплату по часам работы и работает в заранее запланированном графике
по сменам.
· Предполагается, что врачи будут использовать систему для
внесения данных о своих запланированных сменах;
· Врач-сдельщик - это сотрудник компании, который оказывает
услуги клиентам, а именно выезжает на дом к пациентам с целью лечения, при этом
он получает оплату по факту выполненных вызовов и работает вне строгого графика.
· Предполагается, что врачи будут использовать систему для
внесения предварительных данных о времени работы;
· Заместитель главного врача (ЗГВ) - это врач, который
занимается административной работой, а именно составляет график выездной службы
своего подответственного отдела на следующий месяц.
· Предполагается, что заместители главного врача будут
использовать систему для подтверждения или внесения изменений в график
врачей-почасовиков;
· Оператор - это сотрудник компании, который является частью
службы поддержки и использует данные о мощности для того, чтобы ориентироваться
на них при приеме вызовов.
· Предполагается, что оператор будет использоваться систему для
управления мощностью;
· Операционный менеджер - это сотрудник компании, который
частично задействован в управлении службой поддержки, а именно координирует их
работу по управлению мощности на горизонте дня, а также производит
стратегический контроль мощности на горизонте недели и месяца. Предполагается,
что операционный менеджер будет использовать систему для управления мощностью.
5.3 Операционная среда
Система должна работать в любом современном интернет-браузере, включая Google Chrome (все версии), Mozilla Firefox (все версии), Apple Safari (все версии), а также Windows Internet Explorer версии 8 и 9. Система должна
являться частью Bitrix и
интегрирована с мессенджером Telegram в целях создания интерфейса контроля мощности.
5.4 Предположения и зависимости
Работа системы зависит от реализации основного бизнес-процесса компании,
то есть вызова врача на дом, а именно в алгоритме подсчёта мощности сервиса
используются исторические данные, которые меняются постоянно, таким образом все
параметры, необходимые для расчётов, пересчитываются с определенной частотой.
5.5 Системные функции и функциональные требования
1. Планирование графика врача-почасовика
.1. Составление плана смен на следующий месяц;
.2. Просмотр плана смен на следующий месяц;
.3. Подача графика смен на следующий месяц на согласование
заместителю главного врача;
.4. Внесение изменений в график смен на следующий месяц, а именно
редактирование и удаление смен;
.5. Получение внесенных заместителем главного врача изменений в
графике на следующий месяц;
.6. Подтверждение графика на следующий месяц;
.7. Передача данных о подтвержденном графике на месяц в общую базу
данных графиков врачей;
.8. Вывод данных из базы данных смен врачей-почасовиков в интерфейс
графиков врачей.
. Планирование графика врача-сдельщика
.1. Добавление смен в план;
.2. Просмотр плановых смен;
.3. Редактирование смен в плане, а именно изменение и удаление;
.4. Передача данных о подтвержденном графике на месяц в общую базу
данных графиков врачей;
.5. Вывод данных из базы данных смен врачей-сдельщиков в интерфейс
графиков врачей.
. Подсчёт мощности сервиса
.1. Реализация алгоритма подсчёта мощности сервиса;
.2. Передача результатов реализации алгоритма во внешние интерфейсы;
.3. Запись результатов реализации алгоритма в базу данных.
. Просмотр результатов работы алгоритма подсчёта мощности в Bitrix
.1. Отображение результатов работы алгоритма подсчёта мощности во
вкладке “Мощность на сегодня”;
.2. Перевод алгоритма в режим работы “высокая загрузка мощности” и
построение карты мощности сервиса;
.3. Фильтрация результатов работы алгоритма по различным параметрам.
. Просмотр результатов работы алгоритма подсчёта мощности в Telegram
.1. Отображение результатов работы алгоритма в соответствии со
спецификациями к командам для Telegram-бота.
. Просмотр результатов работы алгоритма подсчёта мощности в PowerBI
.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 Внешние интерфейсы
Система должна иметь возможность быть интегрирована со сторонними
сервисами - к примеру, данными Яндекс.Транспорт.
6. Описание способа автоматизации бизнес-процесса
Как было написано ранее, очень важно максимально исключить ручной труд
сотрудников для подсчёта мощности.
В соответствии с идеологией MVP, процесс автоматизировался в несколько этапов:
. Внедрение хранения данных о сменах врачей в IT систему - разработка системы учета
рабочего времени персонала, а именно базы данных для хранения информации о
каждом запланированном выходе на работу каждого врача, а также истории всех
прошедших выходов на работу;
. Автоматизация составления расписания врачами - разработка
функционала самостоятельного внесения смен в график для врачей, а также
интерфейса для этого;
. Автоматизация алгоритма подсчёта мощности - формализация,
проектирование и программирование алгоритма для подсчёта мощности;
. Разработка интерфейсов для вывода результатов работы алгоритма -
создание формата для вывода результатов работы алгоритма и разработка данного
функционала;
. Интеграция с существующей системой автодиспетчеризации,
историческими данными и разработка интерфейса оперативного контроля при высокой
загрузке.
7. Разработка моделей TO-BE и внедрение системы
Далее, в соответствии с функциональными блоками, были разработаны
идеальные модели процессов TO-BE.
7.1 Процесс планирования графика
Рисунок 9 - процесс планирование смен TO-BE
Перед тем, как внедрять описанный на рисунке 9 процесс, была разработана
база данных по учету рабочего времени врачей. В не данные о плановых сменах
врачей попадали следующим образом:
· ЗГВ формирует график врачей и передает его операторам службы
поддержки;
· Операторы службы поддержки вручную добавляют информацию в
базу данных.
Такой AS-IS процесс просуществовал недолго, так как был несовершенен и
тратил время операторов службы поддержки.
Данные о факте выхода на смену и окончании смены создавались следующим
образом:
· Врачи-почасовики в мобильном приложении отмечали старт смены
и конец смены, при этом производилась проверка, что такая смена действительно
есть в графике для данного врача;
· Врачи-сдельщики в мобильном приложении отмечали старт смены и
желаемую длительность смены, при этом сдельщику не обязательно было планировать
смену заранее, так как формально он работает без строгого графика.
Как было сказано ранее, для того, чтобы данные о рабочем времени врачей
попадали в базу данных и IT-систему
без участия операторов, требуется автоматизировать процесс их создания и
передачи в базу данных самими врачами, модель TO-BE которого
представлена на рисунке 3.
Данная модель была внедрена в компании и дала возможность перейти к
следующему шагу построения системы - реализации алгоритма подсчёта мощности в IT системе.
.2 Алгоритм подсчёта мощности
Ниже представлены вводные данные по алгоритму:
Тип врача - подразумевается почасовик или сдельщик.
Время работы врача - промежуток времени, в который врач находится на смене.
Время работы врача (смена) ограничена началом смены и концом смены, подход к
определению которых отличается в зависимости от специфики врача и определены
ниже:
· Почасовики
o Плановое:
§ Начало смены - время начала смены, внесенное в Bitrix;
§ Конец смены - время конца смены, внесенное в Bitrix.
o Фактическое:
§ Начало смены - время отметки в приложении о начале смены;
§ Конец смены - время отметки в приложении о конце смены.
· Сдельщики
o Плановое:
§ Глобальное
· Начало смены - время начала смены, внесенное в Bitrix
сдельщиком через web-интерфейс;
· Конец смены - время конца смены, внесенное в Bitrix
сдельщиком через web-интерфейс.
§ Локальное
· Начало смены - время отметки в приложении о начале смены;
· Конец смены - время локального начала смены плюс указанная в
приложении длительность смены (пример: врач в 8 часов утра отметился, что будет
работать 2 часа, значит локальное время конца его смены 8+2=10 часов утра).
o Фактическое
§ Начало смены - время отметки в приложении о начале смены;
§ Конец смены - время отметки в приложении о конце смены (или время
автоматического закрытия смены скриптом при бездействии врача).
Мощность - количество вызовов, которое может выполнить выбранная специальность в
выбранном городе за указанный период времени на основании плановых или
фактических данных о времени работы врачей. Соответственно, основанная на
плановых данных о времени работы врачей мощность называется прогнозной, а
основанная на фактических - фактическая мощность. Исключение составляет только
случай, когда считается фактическая мощность на текущий день - с начала дня до
текущего момента используют фактические данные, а с текущего момента до конца
дня используют прогнозные данные.
Мощность определяется как кусочно заданная функция, которая зависит от 6
переменных и считается по-разному на различных промежутках времени:
Capacity (date_time_from; date_time_to; city; specialization;
t visit; t travel)
· Date_time_from - начало периода времени;
· Date_time_to - конец периода времени;
· City - город;
· Specialization - специальность;
· T visit - время на вызове;
· T travel - время доезда.
Мощность на сегодня - подразумевается функция capacity, где date_time_from =
00:00 текущего дня, а date_time_to = 23:59 текущего дня.
Мощность до конца дня - подразумевается функция capacity, где
date_time_from = текущее время, а date_time_to = 23:59 текущего дня.
Время на вызове - время, которое врач проводит с пациентом. Стандартно
считается 50 минут.
Время доезда - время в пути до пациента. Стандартно считается 60 минут,
но в будущем может быть изменено через специальный интерфейс.
Все константы, указанные в вводных данных, указаны для примера и не
обязаны соответствовать действительности в целях неразглашения конфиденциальной
информации в отчете.
TO-BE модель данного алгоритма изображена
на рисунке 10:
Рисунок 10 - алгоритм расчёта мощности сервиса TO-BE
В результате, данный алгоритм был разработан и внедрен в компании, однако
потребовалось разработать визуализацию результатов работы алгоритма, что было
сделано на следующем шаге.
7.3 Разработка интерфейсов для вывода результатов работы
алгоритма
Для того, чтобы алгоритм приносил пользу в компании, нужно дать
возможность всем заинтересованным лицами пользоваться им, что требует
разработки интерфейса для пользователей.
В процессе внедрения разработанного подхода на практике было разработана
два типа интерфейсов: интерфейс в IT системе для операторов службы поддержки, которые работают в системе, и Telegram-бот для операционных менеджеров, для
которых это программное обеспечение является более удобным.
Интерфейс в IT системе
В ходе работы было написано техническое задание на разработку интерфейса
в IT системе. В интерфейсе Bitrix было предложено создать новую
вкладку “Мощность выездной службы”. В это вкладке должно было содержаться
следующее:
. Выпадающий список “Выбранная специальность” - в данном списке
содержатся все специальности, которые работают в DOC+, при нажатии можно выбрать одну из них.
. Поле “Время доезда (мин)” - можно ввести только цифры. Стандартно стоит
значение, которое установлено для текущей специальности (т.е. для того
специалиста, который выбран в выпадающем списке “Выбранная специальность”).
. Кнопка “Пересчитать мощность” - при нажатии пересчитывается таблица,
описанная ниже, в соответствии с измененными данными по времени доезда, т.е.
пользователь может выбрать специалиста, для которого хочет пересчитать
мощность, после чего установить ему свое время доезда, после чего пересчитать
мощность в соответствии с новыми данными.
. Таблица мощности выездной службы
Данные в таблицу должны подгружаться из разработанной базы данных по
мощности выездной службы.
Выглядеть таблица должна следующим образом (названия заменить на
русские):
Таблица
3 - Макет интерфейса расчета мощности
Столбцы:
. Total supply (“Мощность на сегодня”) - фактическая мощность DOC+ за
промежуток от today 00:00 до today 23:59;
. Current supply left (“Остаток мощности”) - фактическая мощность DOC+ за
промежуток от current time до today 23:59;
. Demand:
.1. Executed (Выполненные вызовы”) - количество выполненных вызовов за
сегодняшний день к моменту последнего обновления таблицы;
.2. Not executed (“Ожидающие вызовы”) - количество ожидающих (“висящих”)
вызовов, назначенных на сегодняшний день к моменту последнего обновления
таблицы.
. Current utilization (“Текущая загрузка”) - загрузка мощностей DOC+ на
момент последнего обновления листа. Технически это число not executed demand, деленное на current capacity left.
Пример:
Current supply left = 20; not executed demand = 40. Current utilization = 40/20=200%.
Строки агрегируют данные по локациям в разбивке по специализации врача.
В финальном варианте реализации было принято решение отказаться от полей
для ввода среднего времени доезда и визита в пользу простоты интерфейса,
заложив эти параметры как константы. Также, мощность была разделена на
“гарантированную” - то есть ту, которая сформирована уже вышедшими сдельщиками и
почасовиками, и “дополнительную” - возможную за счёт не вышедших еще
сдельщиков, запланировавших смену (так как они могут и не выйти на смену).
Такой подход очень сильно помог в ежедневной рутине управления мощностью и
реалистичной оценке ситуации.
Рисунок 11 - разработанный интерфейс расчёта мощности
В целях конфиденциальности реальные расчётные цифры в интерфейсе (рисунок
11) закрыты, а цифры в макете случайны.
Интерфейс в Telegram
Для контроля за мощностью было принято решение разработать команды в Telegram-боте. Это решение связано с
несколькими факторами:
· Менеджеры бизнес-команды используют Telegram как основной мессенджер, из-за этого
проводят в нем очень много времени;
· В Telegram-боте уже
есть большое количество сервисных команд для вывода статистики по компании.
В результате в соответствии с поставленным техническим заданием был
реализован ряд команд (внимание: цифры не соответствуют реальным и приведены
для примера):
1.1. Команда Capacity
.2. Данная команда должна выводить в чат информацию по общей и
оставшейся мощности на день во всех городах в указанном ниже формате.
1.3. Пример:
1.4. Andrey Ivanov: Capacity
.5. 20.10.2016 19:59
.6. Врач - Гарантированная мощность (+ возможная) / (Загруженность)
Можно принять
.7. --
.8. Москва:
.9. Терапевт - 145 (+20) / 50% (10 осталось)
.10. Педиатр - 158 (+50) / 80% (10 осталось)
.11. Медсестра - 40 (+10) / 0% (10 осталось)
.12. Всего Москва - 343 (+80) / 62% (30 осталось)
.13. --
.14. Санкт-Петербург:
.15. Терапевт - 145 (+20) / 50% (10 осталось)
.16. Педиатр - 158 (+50) / 80% (10 осталось)
.17. Медсестра - 40 (+10) / 0% (10 осталось)
.18. Всего Санкт-Петербург - 343 (+80) / 62% (30 осталось)
.19. --
.20. Всего - 686 (+160) / 62% (60 осталось)
1.21. Команда Capacity X
.22. Данная команда должна выводить в чат информацию по общей и
оставшейся на следующие X
часов мощности за день во всех городах в указанном ниже формате.
1.23. Пример:
1.24. Andrey Ivanov: Capacity 2
.25. 20.10.2016 19:59
.26. Врач - Гарантированная мощность (До 21:59) / Загруженность (Можем
принять)
.27. --
.28. Москва:
.29. Терапевт - 145 (20) / 50% (10 осталось)
.30. Педиатр - 158 (50) / 80% (10 осталось)
.31. Медсестра - 40 (10) / 0% (10 осталось)
.32. Всего - 343 (80) / 62% (30 осталось)
.33. --
.34. Санкт-Петербург:
.35. Терапевт - 145 (20) / 50% (10 осталось)
.36. Педиатр - 158 (50) / 80% (10 осталось)
.37. Медсестра - 40 (10) / 0% (10 осталось)
.38. Всего Санкт-Петербург - 343 (80) / 62% (30 осталось)
.39. --
.40. Всего - 686 (160) / 62% (60 осталось)
.41. Опционально - приставка City
.42. Данная приставка к указанным выше командам должна выводить в чат
информацию за день в выбранном городе.
Данный функционал был разработан и успешно функционирует, обеспечивая
операционных менеджеров информацией по запросу (рисунок 12):
Рисунок 12 - команда capacity в telegram-боте
Интерфейс в PowerBI
Для того, чтобы визуализировать данные по мощности и упростить
стратегическое и оперативное управление ей, база данных и алгоритм расчёта были
интегрированы с системой аналитики PowerBI, в результате чего по техническому заданию были сформированы
два дэшборда, позволяющие проводить как оперативный контроль (в текущий день)
так и стратегический (на горизонте недели и месяца). Дэшборды показаны на
рисунках 13 и 14:
Рисунок 13 - динамический дэшборд по мощности
Рисунок 14 - оперативный дэшборд по мощности
Использование интерфейсов для управления мощностью
Таким образом, данные интерфейсы был разработан и сейчас используются по
назначению всеми стейкхолдерами:
· Для оперативного контроля мощности операторы и операционный
менеджер используют разработанную в Bitrix таблицу расчёта мощности, которая обновляется по событию. С ее помощью
можно отследить данные по текущей загрузке и остановить прием вызовов, если
требуется, принять решение о выводе новых почасовиков на смену, а также принять
меры с целью вывести как можно больше сдельщиков на смену (к примеру, сообщить
им в корпоративном чате о том, что вызовов большое количество и есть хорошая
возможность поработать или сделать соответствующую SMS-рассылку);
· Telegram-бот используется для контроля
мощности бизнес-командой, как оперативного, так и стратегического, хотя и в
меньшей степени (из-за возможности посмотреть мощность на будущие даты);
· PowerBI используется для аналитики по проделанным сменам
врачей, а также для стратегического контроля мощности - в нем можно сравнивать
план с фактом, принимая решения и реформировании графика для увеличения или
снижения мощности;
7.4 Доработка системы и ее перспективы
Последнее техническое задание, написанное в ходе работы по внедрению
подхода к управлению предложением, включало в себя доработку системы с целью
интегрировать ее с действующей системой автодиспетчеризации, которая
распределяет заказы автоматически, а также с историческими данными, которых
накопилось немало. У каждого врача в автодиспетчеризации есть свой таймлайн, в
который ему поступают заказы.
Ниже описаны основные тезисы, которые кратко описывают техническое
задание и ключевые отличия новой версии системы от предыдущей:
· Ранее использовалась просто длительность смен для определения
времени работы врачей, теперь используются данные автодиспетчеризации;
· Ранее параметры время доезда и время приема были заданы как
константы, теперь они изменяются в зависимости от текущей ситуации и
исторических данных;
· Теперь алгоритм имеет два режима, один из которых показывает
ситуацию глобально, когда DOC+
справляется с заказами вне зависимости от их расположения, а второй -
рассматривает локальную ситуацию с мощностью в каждом конкретном месте, когда
мощность выездной службы DOC+
подходит к загрузке.
Описание обновленного алгоритма:
1. Каждый день в 00:01 требуется задать массив из 24 элементов:
2. T travel [i] = средневзвешенное время доезда в рамках i-го часа суток за
последние 4 недели для выбранной специализации в выбранном городе, при этом
каждая приближающаяся к текущему дню неделя увеличивает свой вес в общей оценке
на 0, 5 (суммарный вес равен 1+1, 5+2+2, 5=7), то есть:
3. 
Где Avg T [i] - это средневзвешенное
время доезда в аналогичный i-ый час, а цифра при значении - номер недели
относительно текущей недели (т.е. T travel 1 - прошлая, T travel 2 -
позапрошлая и т.д).
На рисунке 15 показано распределение
среднего времени доезда в течение дня для некоторого периода. Выделены часовые
промежутки, для каждого такого промежутка в 00:01 нужно посчитать
средневзвешенное время доезда по историческим данным и использовать этот расчёт
в течение дня.
Рисунок 15 - динамика среднего времени доезда в течение суток
Таким образом, нужно для каждого из 24 часов посчитать средневзвешенное
время доезда, которое будет использоваться в расчёте мощность в течение дня.
Каждый день в 00:01 требуется задать параметр T visit - среднее от
средних значений за каждый день в течение последних 3 месяцев для выбранной
специализации в выбранном городе.
Пример изображен на рисунке 16: нужно взять среднее от средних значений
за последние 3 месяца, которыые отображены точками на графике (единственное
отличие - на рисунке данные агрегированы по неделям, нужно брать среднее не за
неделю, а за каждый день.
Рисунок 16 - динамика времени доезда за 3 месяца
Пункты 1 и 2 выполняются только один раз в день, после чего значения T
travel [i] и значения T visit используются во всех дальнейших расчётах.
Также производится очистка исторических данных от выбросов, удаляя:
· Скорость движения врача меньше 6 км/ч и больше 80 км/ч
· Время доезда больше 4 часов и меньше 8 минут
· Длину пути меньше 1 и больше 115 км
. Определить параметры date_time_from и date_time_to, т.е. границы
периода для определения мощности.
. В зависимости от выбранного периода для подсчета сделать
следующее (если период охватывает несколько вариантов, то сложить каждый из
них, подсчитанный отдельно):
Прогнозная мощность:
1. Для каждого врача на смене в выбранный период для всего
свободного времени в таймлайне автодиспетчеризации определить расчётное T
travel по алгоритму: T travel для свободного промежутка в таймлайне равно
средневзвешенному T travel [i], подсчитанному на основании данных из
подсчитанного в 00:01 массива.
2. Пример:
. У врача есть свободное время в промежутке с 8:30 до 10:30 (т.е.
2 часа).
. В 00:01 были подсчитаны следующие значения:
5. T travel [8] = 60 минут, T travel [9] = 50 минут, T travel [10] = 60 минут.
6. T travel для свободного промежутка [8:30;10:30] = 0, 5/2*60 + 1/2*50
+ 0, 5/2*60 = 55 минут.
. Сложить все свободные промежутки в таймлайне врача, которые
равны сумме (T visit + T travel) или меньше нее не более чем на 10% (при этом
если промежуток длинный и начинается подсчет его “вместимости”, сначала он
заполняется значениями (T visit + T travel), а когда остается последний
промежуток и он меньше этого значения, происходит проверка на отличие в 10%.
. После этого поделить получившееся время на сумму параметров (T
visit + T travel), округлить его в меньшую сторону.
9. Пример:
. T visit + T travel = 60 минут, в таймлайне врача есть один
свободный промежуток длиной 175 минут. В него умещаются три вызова: 60 минут +
60 минут + 55 минут (т.е. 55 отличается от 60 не более, чем на 10%), складываем
и получаем свободное время врача 175 минут.
11. Пример 2:
. T visit + T travel = 60 минут, в таймлайне врача есть два
свободных промежутка: один длиной 54 минуты, другой длиной 110 минут. В первый
помещается 1 вызов, т.к. 54 отличается от 60 ровно на 10%, и во второй тоже
помещается 1 вызов, т.к. 110 - 60 = 50, а 50 отличается от 60 более чем на 10%.
. Сложить все получившиеся значения в каждом таймлайне врача.
. Результат будет являться подсчитанной прогнозной мощностью
Фактическая мощность считается так же, как и в предыдущей версии алгоритма.
Резюмируя, алгоритм следующий:
. Подсчитать ожидаемое время доезда для каждого промежутка в таймлайне
врача;
. Подсчитать, сколько точно вызовов врач сможет сделать за свободное
время в своем таймлайне;
. Сложить все вызовы по всем врачам.
Режимы работы алгоритма:
Режим больших чисел
Это стандартный режим алгоритма - он описан выше. Выход из этого режима
происходит в момент, когда остаток мощности до конца дня [current time; 23:59] становится равен 14 вызовам (переключатель
режима рассчитан при помощи специально разработанной модели). После этого
алгоритм переходит в локальный режим.
Локальный режим
В данном режиме становится активной карта, которая выглядит следующим
образом и доступна во вкладке “Локальный режим мощности” в Bitrix для всех (рисунок 17):
Рисунок 17 - локальный режим контроля мощности
На карте отображаются конечные точки всех докторов, на которых сейчас
есть вызовы в автодиспетчеризации и у которых остается свободное время до конца
смены.
Красная точка на карте - это конечное местоположение доктора,
рассчитанное автодиспетчеризацией (т.е. локация последнего вызова врача).
Вокруг последнего вызова врача рисуется круг радиусом R = время до конца смены врача *
средневзвешенная скорость движения врача до конца смены.
Средневзвешенная скорость считается аналогично средневзвешенному времени
доезда (то есть используются исторические данные по времени доезда и
километражу, скорость - вычисляемых из них параметр L / T travel), она считается средневзвешенной в
период с времени окончания последнего вызова в таймлайне до конца смены.
Таким образом каждый врач имеет радиус, который он сможет покрыть до
конца смены.
Данный режим показывает остаток мощности в плавающем формате “Можем
выполнить ОТ 0 ДО X вызовов”, где X - максимальное число вызовов,
которое можно сделать, если все они попадут в круги на карте.
В таблицах в интерфейсе оператора при работе алгоритма во втором режиме в
графе “Можем принять” должно отображаться плавающее значение количества вызовов.
7.5 Формализация процесса принятия бизнес-решений на
основании разработанного подхода
Для того, чтобы использовать систему управления персоналом, потребовалось
детально прописать регламент принятия решений на основании значения мощности.
Как было сказано ранее, управление предложением бывает двух типов:
· Оперативное - к примеру, если менеджер отдела управления
операциями видит, что выездная служба не справляется с заказами, или если в
конце дня остаток мощности неравномерно распределен по городу и непонятно,
получится ли принять следующий вызов;
· Стратегическое - к примеру, если на еженедельной встрече по
динамике заказов становится понятно, что через неделю количество заказов
превысит запланированные объемы мощности.
В идеальном случае, процесс нужно описывать заранее и внедрять вместе с
разработкой частей системы. Для примера, рассмотрим идеальный TO-BE процесс, подразумевающий реализованными все описанные выше
доработки (рис. 18):
Рисунок 18 - Бизнес-процесс управления мощностью
Выводы
В данной главе подробно описан пример практической реализации
предложенного подхода в реальной компании, относящейся к выбранной
бизнес-модели. В рамках реализации подхода на практике была изучена компания,
ее процессы управления предложения были описаны AS-IS, после чего
сформирован план работ по достижению целевой описанной TO-BE модели, который
пошагово выполнялся. Также, были сформированы рекомендации по дальнейшей
доработке системы и описан бизнес-процесс принятия управленческих решений на
основании разработанного подхода.
Данное описание кейса реализации может быть использовано в компаниях со
схожей бизнес-моделью как материал для изучения, на основании которого возможно
реализовать предложенный подход и в другом проекте.
Заключение
В рамках данной выпускной квалификационной работы были решены все
поставленные задачи, а именно:
. Проведен анализ
релевантной научной литературы и источников, освещающих (глава 1):. Теоретические
подходы к автоматизации бизнес-процессов;. Модель “экономики по требованию”
и гибкие организационные структуры;. Методы учета рабочего времени;. Подходы
к подсчету объема создаваемого предложения и теория систем массового
обслуживания.
. Выявлены
особенности, которые необходимо учесть при разработке подхода к управлению
объемом предложения (глава 1);
. Описан предлагаемый
подход для управления объемом предложения в компаниях с выбранным типом
бизнес-модели (глава 2);
. Описана технику
внедрения подхода на примере компании (глава 3).
В результате выполнения вышеуказанных
задач была решена критическая проблема бизнеса: отсутствие подхода к подсчёту
предложения сервиса, что могло привести к различного рода рискам.
Данная выпускная
квалификационная работа представляет ценность для любой компании, которая
связана с экономикой потребления и работает с клиентом по запросу в связи с
тем, что представляет из себя пошаговое подробное изучение кейса решения
проблемы управления предложением в подобной уберизированной компании. Учитывая
отсутствие устоявшихся методологий в данной сфере и тот факт, что большинство
компаний вынуждены опираться только на собственный опыт в данном вопросе,
данный отчет может помочь формализации и установлению стабильного
бизнес-процесса с нуля.
Разработанная система и
подход, примененные на практике за время существования помогли компании снизить
издержки на персонал, вовремя реагировать на резкие колебания спроса как при
краткосрочном планировании, так и при долгосрочном, и осуществить конечную цель
бизнеса - удовлетворить всех потребителей в каждый момент времени.
Список использованных материалов
Список
использованных материалов отсортирован по появлению в тексте работы.
1. Airbnb [Электронный ресурс]: О нас. - Режим доступа:
свободный <https://www.airbnb.ru/about/about-us> (Дата обращения: 11.04.2017)
2. VentureBeat
[Электронный ресурс]: On heels of new funding and global
expansion, car service Uber launches in D.C. today. - Режим доступа:
свободный <https://venturebeat.com/2011/12/15/uber/> (Дата обращения: 11.04.2017)
3. Блог Яндекса [Электронный
ресурс]: Яндекс.Такси вызывали? - Режим доступа: свободный
<https://yandex.ru/blog/company/40664> (Дата обращения: 11.04.2017)
4. Business
Insider [Электронный ресурс]: The ‘On-Demand Economy' Is
Revolutionizing Consumer Behavior - Here’s How. - Режим доступа:
свободный
<http://www.businessinsider.com/the-on-demand-economy-2014-7> (Дата обращения: 15.05.2017)
. I.
Maselli, K. Lenaerts, M. Beblavý (2016). Five things we need to know about the
on-demand economy. <https://www.ceps.eu/system/files/CEPS%20Essay%20No%2021%20On%20Demand%20Economy.pdf> (Дата обращения: 14.05.2017)
. Зараменских, Е.П.
(2014). Управление жизненным циклом информационных систем: монография.
Новосибирск, ЦРНС.
. Грекул В.И.,
Денищенко Г.Н., Коровкина Н.Л. (2005). Проектирование информационных систем:
курс лекций: учебное пособие для студентов вузов, обучающихся по специальностям
в области информ. технологий. Москва, Интернет-Университет Информационных
технологий.
. Иванов А. (2016).
Разработка проектного решения по оптимизации логистики стартапа. Москва, Курсовая
работа.
. Wiegers, K. (2014)
Разработка требований к программному обеспечению. Москва, Русская редакция.
10. actiTIME.
(2013). Tracking Software: A Brief Guide. Ссылка:
<https://www.actitime.com/time-tracking-software-essay.html>
. Ю.В. Прохоров
(1988). Математический энциклопедический словарь. Москва, Советская
энциклопедия.
12. SAP [Электронный ресурс]:
Operations Management Basics: Capacity, bottleneck, process capacity, flow rate
and utilization. - Режим доступа: свободный
<https://blogs.sap.com/2014/08/28/operations-management-basics-capacity-bottleneck-process-capacity-flow-rate-and-utilization/>
(Дата
обращения: 10.03.2017)
. THE
ON-DEMAND ECONOMY [Электронный ресурс]: Powering the future of the on-demand
economy. - Режим доступа: свободный <https://theondemandeconomy.org/> (Дата обращения: 15.05.2017)
14. Н.Н. Прокимнов (2007).
Учебное пособие по дисциплине “Моделирование систем” Москва.
. С.В. Базилевич, Е.Ю.
Легчилина (2016). Количественные методы в управлении Москва, КНОРУС.