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

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

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

В соответствии с идеологией MVP, процесс автоматизировался в несколько этапов:

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

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

3. Автоматизация алгоритма подсчёта мощности - формализация, проектирование и программирование алгоритма для подсчёта мощности;

4. Разработка интерфейсов для вывода результатов работы алгоритма - создание формата для вывода результатов работы алгоритма и разработка данного функционала;

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



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

Далее, в соответствии с функциональными блоками, были разработаны идеальные модели процессов TO-BE.

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

Рисунок 9 - процесс планирование смен TO-BE

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

· ЗГВ формирует график врачей и передает его операторам службы поддержки;

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

Такой AS-IS процесс просуществовал недолго, так как был несовершенен и тратил время операторов службы поддержки.

Данные о факте выхода на смену и окончании смены создавались следующим образом:

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

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

Как было сказано ранее, для того, чтобы данные о рабочем времени врачей попадали в базу данных и IT-систему без участия операторов, требуется автоматизировать процесс их создания и передачи в базу данных самими врачами, модель TO-BE которого представлена на рисунке 3.

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

7.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 было предложено создать новую вкладку “Мощность выездной службы”. В это вкладке должно было содержаться следующее:

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

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

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

4. Таблица мощности выездной службы

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

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

Выглядеть таблица должна следующим образом (названия заменить на русские):

Таблица 3 - Макет интерфейса расчета мощности

Столбцы:

1. Total supply (“Мощность на сегодня”) - фактическая мощность DOC+ за промежуток от today 00:00 до today 23:59;

2. Current supply left (“Остаток мощности”) - фактическая мощность DOC+ за промежуток от current time до today 23:59;

3. Demand:

3.1. Executed (Выполненные вызовы”) - количество выполненных вызовов за сегодняшний день к моменту последнего обновления таблицы;

3.2. Not executed (“Ожидающие вызовы”) - количество ожидающих (“висящих”) вызовов, назначенных на сегодняшний день к моменту последнего обновления таблицы.

4. 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

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

1.3. Пример:

1.4. Andrey Ivanov: Capacity

1.5. 20.10.2016 19:59

1.6. Врач - Гарантированная мощность (+ возможная) / (Загруженность) Можно принять

1.7. --

1.8. Москва:

1.9. Терапевт - 145 (+20) / 50% (10 осталось)

1.10. Педиатр - 158 (+50) / 80% (10 осталось)

1.11. Медсестра - 40 (+10) / 0% (10 осталось)

1.12. Всего Москва - 343 (+80) / 62% (30 осталось)

1.13. --

1.14. Санкт-Петербург:

1.15. Терапевт - 145 (+20) / 50% (10 осталось)

1.16. Педиатр - 158 (+50) / 80% (10 осталось)

1.17. Медсестра - 40 (+10) / 0% (10 осталось)

1.18. Всего Санкт-Петербург - 343 (+80) / 62% (30 осталось)

1.19. --

1.20. Всего - 686 (+160) / 62% (60 осталось)

1.21. Команда Capacity X

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

1.23. Пример:

1.24. Andrey Ivanov: Capacity 2

1.25. 20.10.2016 19:59

1.26. Врач - Гарантированная мощность (До 21:59) / Загруженность (Можем принять)

1.27. --

1.28. Москва:

1.29. Терапевт - 145 (20) / 50% (10 осталось)

1.30. Педиатр - 158 (50) / 80% (10 осталось)

1.31. Медсестра - 40 (10) / 0% (10 осталось)

1.32. Всего - 343 (80) / 62% (30 осталось)

1.33. --

1.34. Санкт-Петербург:

1.35. Терапевт - 145 (20) / 50% (10 осталось)

1.36. Педиатр - 158 (50) / 80% (10 осталось)

1.37. Медсестра - 40 (10) / 0% (10 осталось)

1.38. Всего Санкт-Петербург - 343 (80) / 62% (30 осталось)

1.39. --

1.40. Всего - 686 (160) / 62% (60 осталось)

1.41. Опционально - приставка City

1.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 км

4. Определить параметры date_time_from и date_time_to, т.е. границы периода для определения мощности.

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

Прогнозная мощность:

1. Для каждого врача на смене в выбранный период для всего свободного времени в таймлайне автодиспетчеризации определить расчётное T travel по алгоритму: T travel для свободного промежутка в таймлайне равно средневзвешенному T travel [i], подсчитанному на основании данных из подсчитанного в 00:01 массива.

2. Пример:

3. У врача есть свободное время в промежутке с 8:30 до 10:30 (т.е. 2 часа).

4. В 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 минут.

7. Сложить все свободные промежутки в таймлайне врача, которые равны сумме (T visit + T travel) или меньше нее не более чем на 10% (при этом если промежуток длинный и начинается подсчет его “вместимости”, сначала он заполняется значениями (T visit + T travel), а когда остается последний промежуток и он меньше этого значения, происходит проверка на отличие в 10%.

8. После этого поделить получившееся время на сумму параметров (T visit + T travel), округлить его в меньшую сторону.

9. Пример:

10. T visit + T travel = 60 минут, в таймлайне врача есть один свободный промежуток длиной 175 минут. В него умещаются три вызова: 60 минут + 60 минут + 55 минут (т.е. 55 отличается от 60 не более, чем на 10%), складываем и получаем свободное время врача 175 минут.

11. Пример 2:

12. T visit + T travel = 60 минут, в таймлайне врача есть два свободных промежутка: один длиной 54 минуты, другой длиной 110 минут. В первый помещается 1 вызов, т.к. 54 отличается от 60 ровно на 10%, и во второй тоже помещается 1 вызов, т.к. 110 - 60 = 50, а 50 отличается от 60 более чем на 10%.

13. Сложить все получившиеся значения в каждом таймлайне врача.

14. Результат будет являться подсчитанной прогнозной мощностью

Фактическая мощность считается так же, как и в предыдущей версии алгоритма.

Резюмируя, алгоритм следующий:

1. Подсчитать ожидаемое время доезда для каждого промежутка в таймлайне врача;

2. Подсчитать, сколько точно вызовов врач сможет сделать за свободное время в своем таймлайне;

3. Сложить все вызовы по всем врачам.

Режимы работы алгоритма:

Режим больших чисел

Это стандартный режим алгоритма - он описан выше. Выход из этого режима происходит в момент, когда остаток мощности до конца дня [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):

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

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

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

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

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

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

4. Описана технику внедрения подхода на примере компании (глава 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)

5. 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)

6. Зараменских, Е.П. (2014). Управление жизненным циклом информационных систем: монография. Новосибирск, ЦРНС.

7. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. (2005). Проектирование информационных систем: курс лекций: учебное пособие для студентов вузов, обучающихся по специальностям в области информ. технологий. Москва, Интернет-Университет Информационных технологий.

8. Иванов А. (2016). Разработка проектного решения по оптимизации логистики стартапа. Москва, Курсовая работа.

9. Wiegers, K. (2014) Разработка требований к программному обеспечению. Москва, Русская редакция.

10. actiTIME. (2013). Tracking Software: A Brief Guide. Ссылка: https://www.actitime.com/time-tracking-software-essay.html

11. Ю.В. Прохоров (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)

13. THE ON-DEMAND ECONOMY [Электронный ресурс]: Powering the future of the on-demand economy. - Режим доступа: свободный https://theondemandeconomy.org/ (Дата обращения: 15.05.2017)

14. Н.Н. Прокимнов (2007). Учебное пособие по дисциплине “Моделирование систем” Москва.

15. С.В. Базилевич, Е.Ю. Легчилина (2016). Количественные методы в управлении Москва, КНОРУС.

Размещено на Allbest.ru