Дипломная работа (1193007), страница 8

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

Текст из файла (страница 8)

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

– разработка и корректировка сайта;

– разработка дизайна;

– разработка рекламных кампаний в интернете;

– автоматизация процессов в бизнесе заказчика.

Этапы жизненного цикла продукции представлены на рисунке 9.

Рисунок 9 – Этапы жизненного цикла продукта

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

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

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

Есть альтернативное программное обеспечение – «bpsimulator», которое содержит функционал проектирования связей между элементами, каждый из которых несет строго определенную смысловую нагрузку. Этапы жизненного цикла продукции, составленные с помощью этого программного обеспечения выглядят следующим образом как показано на рисунке 10.

Рисунок 10 – Этапы жизненного цикла продукта в «bpsimulator»

«Bpsimulator» – сервис имитационного моделирования бизнес-процессов. Зелеными прямоугольниками в нем обозначены функции. Это ключевые стадии, которые обозначают, что на этом этапе проводится работа. Функцию может выполнять исполнитель или группа исполнителей. Они обозначены желтым прямоугольником. Стрелки от исполнителя к функции означают, что он в данном бизнес-процессе он работает над этой функцией.

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

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

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

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

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

- качество рекламного источника;

- качество работы отдела продаж;

- репутация компании;

- качество продукта.

Блок-схема процесса «Серия касаний с лидом» представлена в Приложении Б. Именно в ней представлено ядро работы отдела маркетинга и полный цикл работы отдела продаж.

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

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

3.5 Требования к функционалу BPM системы

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

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

Общие требования:

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

2. BPM должна иметь уровни пользователей, которые присваиваются сотрудникам в зависимости от занимаемой должности. Уровень пользователя «Директор» имеет полный доступ ко всем подсистемам с правами редактирования. Уровень доступа «Менеджер» имеет доступ к области BPM, связанной с проектами, которыми он руководит. Уровень доступа «Гость» имеет доступ к той части BPM, которая была задана в настройках при создании аккаунта пользователя, без прав на редактирование.

3. BPM должна быть интегрирована с автоматической телефонной станцией (АТС). Все входящие и исходящие звонки должны проводиться через систему BPM. Распределение звонков должно производиться между менеджерами в случайном порядке с учетом графика работы.

4. BPM должна быть интегрирована с электронной почтой на базе почтового сервера от поисковой системы Google. Все исходящие и входящие письма должны фиксироваться в системе.

5. BPM должна быть интегрирована с системами отслеживания аналитики по посещаемости сайта компании Яндекс.Метрика и Google Analytics.

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

7. При заведении нового пользователя, в его профиле указывается имя, фамилия, телефон, должность (при наличии).

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

Требования к функциональной группе «Структура компании»:

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

2. Связи между должностями должны отражать систему подчинения.

3. Логическая информация о системе подчинения должна кодироваться и готовиться к передач в другие функциональные группы.

4. Структура компании должна формироваться произвольно с помощью визуального редактора.

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

Требования к функциональной группе «Постановка задач»:

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

2. При постановке задачи, в ней заполняется информация:

- наименование задачи;

- описание задачи;

- чек-лист по задаче;

- привязка проекта;

- дата начала исполнения задачи;

- крайний срок исполнения;

- соисполнители задачи.

1. BPM система должна хранить хранить задачи по спискам: я поставил задачи, мне поставили задачи, я соисполнитель задач.

2. Задачи должны сортироваться по сроку исполнения и фильтроваться по признаку «просрочено», произвольной дате (выбор периода крайних сроков задач) и по привязке к проекту.

3. Задачи должны быть представлены в двух видах: в виде диаграммы Ганта и в виде списка. Переключение между видами должно производиться пользователем по желанию.

4. Задачи должны иметь возможность выставляться периодически в автоматическом режиме.

Требования к функциональной группе «Проект»:

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

2. Проект включает участников и руководителя проекта. Участники могут приглашаться в проект другими участниками или самостоятельно подавать запрос руководителю проекта на вступление.

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

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

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

6. Проект должен содержать раздел «Аналитические данные», в которых должна быть отражена следующая информация:

- количество участников проекта;

- длительность проекта (считается от старта исполнения первой задачи);

- количество задач;

- среднее время исполнения задачи;

- количество просроченных задач (общее и в разрезе по исполнителям);

- количество фактов сдвига крайнего срока задач (не учитываются сдвиги в течение первых 12 часов после ее создания).

- количество выставленных и оплаченных счетов по проекту (для клиентских проектов);

- количество денег, которые по факту пришли через проект (для клиентских проектов);

- количество заработанных денег каждым участником проекта (для клиентских проектов);

- количество составленных и подписанных договоров (для клиентских проектов).

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

- данные Яндекс.Метрики;

- количество выполненных целей;

- стоимость целей;

- стоимость выполненной (CPO – cost per order);

- список проделанных работ.

8. Клиентский отчет должен иметь возможность видоизменяться менеджером проекта, чтобы иметь согласованный с заказчиком вид. Должна также иметься возможность давать права просмотра отчета на уровне пользователя «Гость» и выводить его на произвольную страницу сайта.

Требования к функциональной группе «База клиентов»:

1. База клиентов включается в себя разделы «Лиды», «Предложения», «Договоры», «Счета».

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

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

- название компании;

- дата добавления в базу (проставляется автоматически);

- сфера деятельности (выбирается из предложенного списка);

Характеристики

Список файлов ВКР