Формирование требований к информационной системе управления call-центром

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

Формирование требований к информационной системе управления call-центром



Оглавление

Глоссарий

Введение

1. Описание работы call-центра

1.1 Текстовое описание бизнес-процессов call-центра

1.2 Моделирование процессов call-центра

1.3 Постановка проблемы

2. Функциональные требования ИС

2.1 Обоснование необходимости разработки требований к ИС

2.2 Описание и выбор классификации требований

2.3 Характеристики требований

2.4 Этапы разработки требований

2.5 Заинтересованные лица

2.6 Разработка требований

3. Разработка IT инфраструктуры call-центра

3.1 Описание технических средств call-центра

3.2 Описание ПО call-центра

3.3 Подбор системы

Заключение

Список литературы



Глоссарий

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

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

Клиент - заказчик call-центра.

Респондент - лицо, отвечающее на исходящие вызовы оператора, либо совершающее вызов.

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



Введение

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

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

Цели исследования

Сформировать требования к информационной системе управления call-центром.

Задачи исследования

· Изучить предметную область

· Рассмотреть и формализовать существующие бизнес- процессы

· Разработать требования к ИС в соответствии с выбранной методологией

· Разработать IT инфраструктуру call-центра

· Подобрать ИС, удовлетворяющую разработанным требованиям

Данная работа состоит из 3 отдельных глав.

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

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

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



1. Описание работы call-центра

1.1 Текстовое описание бизнес-процессов call-центра

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

Первый уровень - операторы, регистрирующие, принимающие вызовы и решающие информационные задачи.

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

Третий уровень - руководитель call-центра. Руководителя определяет и ставит задачи для супервайзера исходя из требований клиента.

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

1. На третьем уровне находится руководитель call-центра. Он ставит задачу супервайзеру, формируя список задач call-центра.

2. На втором уровне находится супервайзер. Супервайзер совершает следующие операции:

2.1 Формирует журнал задач оператора, основываясь на списке задач call-центра.

2.2 Формирует скрипт разговора для операторов.

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

2.4 Производит контроль качества работы оператора. Составляет отчет качества работы оператора и передает его руководителю call-центра.

3. На первом уровне находится оператор. Он совершает операции:

3.1 Принимает входящие вызовы:

3.1.1 Определяет тип обращения (первичный/вторичный).

3.1.2 Непосредственно обрабатывает вызов.

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

3.1.4 Делает запись о результате обработки вызова в ежедневном отчете для клиента.

3.1.5 Передает внутренний отчет супервайзеру.

3.1.6 Передает ежедневный отчет клиенту.

3.2 Осуществляет исходящие вызовы:

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

3.2.2 Совершает вызов.

3.2.3 Обрабатывает вызов.

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

3.2.5 Делает запись о результате обработки вызова в ежедневном отчете для клиента.

3.2.6 Передает внутренний отчет супервайзеру.

3.2.7 Передает ежедневный отчет клиенту.

1.2 Моделирование процессов call-центра

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

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

Первым этапом в построении модели в IDEF0 является создание контекстной диаграммы - диаграммы, содержащей в себе описание объекта моделирования в целом. На рис.1 приведена контекстная диаграмма, описывающая деятельность call-центра.

Рис.1 Контекстная диаграмма

На входе в диаграмме (Рис.1) мы имеем требования клиента и входящие вызовы. Механизмом является персонал call-центра. Функции выполняется под управлением норм этикета и должностных инструкций. Результатом работы call-центра являются отчеты, предоставляемые клиенту.

После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией. На Рис.2 представлена диаграмма декомпозиции первого уровня.

Рис.2 Декомпозиция первого уровня

Диаграмма (Рис.2) содержит 3 функциональных блока.

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

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

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

На втором уровне декомпозиции находятся две диаграммы, подробно описывающие функции второго (Рис.3) и третьего (Рис.4) блоков.

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

Рис.4 Декомпозиция функционального блока "Прием и совершение звонков"

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

Блок "Прием входящих вызовов" распадается на 4 функциональных блока.

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

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

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

Рис.6 Декомпозиция функционального блока "Осуществление исходящих вызовов"

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

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

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

Таблица 1

Таблица операций

Операция	Исполнитель	Как часто	Входящие документы (документы-основания)	Исходящий документ (составляемый документ)
Формирование задач call-центра	Руководитель call-центра	Эпизодически	Требования клиента	Список задач call-центра
Формирование журнала задач оператора	Супервайзер	Еженедельно	Список задач call-центра, внутренний отчет о проделанной работе	Журнал задач оператора
Формирование скрипта разговора	Супервайзер	Эпизодически	Список задач call-центра	Скрипт разговора
Формирование еженедельного отчета	Супервайзер	Еженедельно	Внутренний отчет о проделанной работе	Еженедельный отчет для клиента
Контроль качества работы оператора	Супервайзер	Еженедельно	Внутренний отчет о проделанной работе	Отчет качества работы оператора
Определение первичности/ вторичности обращения	Оператор	Каждый вызов	Входящий вызов	Тип обращения
Обработка входящего вызова	Оператор	Каждый вызов	Журнал задач оператора	Результат обработки вызова
Формирование внутреннего отчета	Оператор	Ежедневно	Результат обработки вызова (запись во внутреннем и ежедневном отчетах)	Внутренний отчет о проделанной работе
Формирование ежедневного отчета для клиента	Оператор	Ежедневно	Результат обработки вызова (запись во внутреннем и ежедневном отчетах)	Ежедневный отчет для клиента
Определение цели осуществления вызова	Оператор	Каждый вызов	Журнал задач оператора	Записанная в журнал цель вызова
Совершение исходящего вызова	Оператор	Каждый вызов	Записанная в журнал цель вызова, журнал задач оператора	Исходящий вызов
Обработка исходящего вызова	Оператор	Каждый вызов	Исходящий вызов	Результат обработки вызова (запись во внутреннем и ежедневном отчетах)

Таблица 2

Таблица документов

Составляемый документ (исходящий документ)	Операция	Кто составляет (исполнитель)	Как часто	Документы-основания (входящие документы)
Список задач call-центра	Формирование задач call-центра	Руководитель call-центра	Эпизоди-чески	Требования клиента, отчет качества работы оператора
Журнал задач оператора	Формирование журнала задач оператора	Супервайзер	Еженеде-льно	Список задач call-центра, внутренний отчет о проделанной работе
Скрипт разговора	Формирование скрипта разговора	Супервайзер	Эпизоди-чески	Список задач call-центра
Еженедельный отчет для клиента	Формирование еженедельного отчета	Супервайзер	Еженеде-льно	Внутренний отчет о проделанной работе
Отчет качества работы оператора	Контроль качества работы оператора	Супервайзер	Еженеде-льно	Внутренний отчет о проделанной работе
Составляемый документ (исходящий документ)	Операция	Кто составляет (исполнитель)	Как часто	Документы-основания (входящие документы)
Результат обработки вызова (запись во внутреннем и ежедневном отчетах)	Обработка входящего вызова	Оператор	Каждый вызов	Входящий вызов, журнал задач оператора, тип обращения
Результат обработки вызова (запись во внутреннем и ежедневном отчетах)	Обработка исходящего вызова	Оператор	Каждый вызов	Журнал задач оператора, Записанная в журнал цель вызова
Внутренний отчет о проделанной работе	Формирование внутреннего отчета о проделанной работе	Оператор	Ежедне-вно	Результат обработки вызова (запись во внутреннем и ежедневном отчетах)
Ежедневный отчет для клиента	Формирование ежедневного отчета для клиента	Оператор	Ежедне-вно	Результат обработки вызова (запись во внутреннем и ежедневном отчетах)

1.3 Постановка проблемы

Функционирование call-центра без информационной системы приводит к возникновению следующих проблем:

Со стороны супервайзера:

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

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

Со стороны оператора:

1. При обработке входящих вызовов, оператору необходимо каждый раз обращаться к внутреннему отчету для определения типа обращения (первичный/вторичный) и понимания результатов предыдущих вызов, в случае если вызов повторный.

2. Необходимость во внутреннем и ежедневном отчетах вручную фиксировать данные вызова, которые могут фиксироваться автоматически. (дата и время вызова).

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

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



2. Функциональные требования ИС

2.1 Обоснование необходимости разработки требований к ИС

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

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

· Системный подход к разработке требований;

· Достоверное понимание всех желаний заказчика;

· Уменьшение количества доработок, возникающих в будущем;

· Уменьшение затрат на поддержку и обслуживание;

· Точное следование расписанию внедрения проекта;

· Повышение качества итогового проекта;

· Повышение скорости разработки.

2.2 Описание и выбор классификации требований

Одной из классификаций требований является классификация по Карлу Вигерсу. Она делит требования на уровни:

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

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

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

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

· Нефункциональные требования определяют атрибуты качества разрабатываемой системы. Нефункциональные требования описывают характеристики конечной системы, важные для пользователей. К ним могут относиться такие атрибуты, как производительность, простота использования, минимальное количество сбоев, надежность и т.д. [2]

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

Рис.7 Взаимосвязь уровней требований к ИС[2]

Альтернативный вариант классификации требований, который широко используется на практике, был разработан Робертом Грэйди из Hewlett-Packard. Он имеет название "FURPS+". Эта аббревиатура расшифровывается следующим образом:

· Functionality, функциональность

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

· Usability, удобство использования

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

· Reliability, надежность

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

· Performance, производительность

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

· Supportability, поддерживаемость

Например, локализация, совместимость с другими системами, ремонтопригодность и конфигурироемость.

· "+" возможные дополнительные ограничения:

o проектирования;

o разработки;

o на интерфейсы;

o физические. [3]



2.3 Характеристики требований

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

1. Атомарность - разбить конкретное требование на более мелкие невозможно. Четкость (краткость)

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

3. Необходимость - требование отражает только действительно важный функционал.

4. Осуществимость - возможность реализации требования в ограниченных условиях.

5. Точность

6. Недвусмысленность - интерпретация требований должна быть единичной.

7. Независимость

Помимо определения характеристик требований также необходимо определить характеристики спецификаций требований:

1. Полнота - весь будущий функционал покрыт описанием требований.

2. Согласованность - требования согласованы со всеми заинтересованными лицами.

3. Возможность внесения изменений.

4. Трассируемость - возможность проверки корректности требований.



2.4 Этапы разработки требований

Разработка требований состоит из 4 поочередных этапов. На рисунке 8 показана их последовательность.

Рис.8 Этапы разработки требований

Рассмотрим эти этапы поподробнее:

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

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

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

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

2.5 Заинтересованные лица

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

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

1. Руководство Компании - руководитель call-центра. Руководитель call-центра определяет бизнес-требования.

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

3. Клиенты компании.

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

4. Компания разработчик.

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

5. IT-службы предприятия.

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

6.Компании, отвечающие за смежные системы.

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

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

2.6 Разработка требований

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

Разработка бизнес-требований

Первоначально конкретизируем высокоуровневые цели call-центра. Основные бизнес-цели call-центра:

· Наличие оперативного доступа к данным вызовов;

· Повышение эффективности обработки вызовов;

· Повышение контроля над бизнес-процессом;

· Формализация процесса обработки вызовов;

· Сокращение ручной обработки информации до минимума.

Разработка требований безопасности

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

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

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

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

· Назначение каждому пользователю определенной роли. Роль определяет уровень доступа к документам.

· Создание новых ролей и прав доступа (Руководитель, Супервайзер, Оператор).

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

· Возможность модификации существующих ролей и уровней доступа.

· Контроль доступа.

· Статистический учет времени работы пользователей в системе.

· Регистрация действий пользователей по их логину.

Разработка требований пользователей

Ключевыми требованиями пользователей к ИС автоматизации процессов call-центра являются:

· Простота и скорость обучения работе с программным продуктом.

· Стабильность системы, отсутствие зависаний.

· Дружелюбный пользовательский интерфейс.

· Юзабилити.

Разработка функциональных требований

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

· Интеграция информационной системы с телефонным модулем.

· Возможность оперативной передачи данных в ИС клиентов.

· Фиксация всех происходящих событий, полный сбор и сохранение статистики.

· Наличие базы данных, хранение всех документов и отчетов с функцией поиска по названию документа, по атрибутам документов (Тип задачи, Дата начала выполнения задачи, Дата окончания задачи, Клиент, Оператор). Возможность фильтрации поиска по атрибутам документов.

Функциональные требования процесса "Формирование Задач Call-центра":

В учетной записи "Администратор":

1. Система должна иметь возможность создания, редактирования и удаления документа "Список задач call-центра". При создании документа ему присваиваются атрибут по типу задачи (Прием/Совершение вызовов) и атрибут "Клиент". Независимо от типа задачи устанавливаются атрибуты документа "Дата начала выполнения задачи" и "Дата окончания выполнения задачи".

2. Документ "Список задач call-центра" с атрибутом "Совершение вызов" должен содержать в себе строки: 1. ФИО респондента 2. Телефонный номер респондента.

3. Документ "Список задач call-центра" с атрибутом "Прием вызов" должен содержать в себе строки: 1. Обрабатываемый телефонный номер.

4. Система должна давать возможность просматривать документ "Отчет качества работы оператора".

Функциональные требования процесса "Постановка задачи и контроль оператора":

В учетной записи "Супервайзер":

1. Система должна иметь возможность просматривать документы "Список задач call-центра", "Внутренний отчет о проделанной работе".

2. Система должна иметь возможность создания, редактирования и удаления документа "Журнал задач оператора". При создании документа ему присваиваются атрибут по типу задачи (Прием/Совершение вызовов), атрибуты "Клиент" и "Оператор". Независимо от типа задачи устанавливаются атрибуты документа "Дата начала выполнения задачи" и "Дата окончания выполнения задачи".

3. Система должна иметь возможность создания, редактирования и удаления документа "Скрипт разговора".

4. Документ "Журнал задач оператора" с атрибутом "Совершение вызовов" должен содержать в себе следующие строки: 1. ФИО респондента 2. Телефонный номер респондента. 3. Скрипт разговора. Формат строки №3 Скрипт разговора должен быть представлен в формате выпадающего списка, предлагающего выбор имеющихся в базе готовых документов данного типа.

5. Документ "Журнал задач оператора" с атрибутом "Прием вызовов" должен содержать в себе следующие строки: 1. Обрабатываемый телефонный номер. 2. Скрипт разговора.

6. Система должна иметь возможность создания документа "Журнал задач оператора" как вручную, так и автоматически. При автоматическом создании данные должны импортироваться из документа "Список задач call-центра".

7. Система должна иметь возможность создания, редактирования и удаления документа "Еженедельный отчет для клиента". Для документов с атрибутом "Совершение вызова" данный документ должен содержать следующую информацию: 1. Процент обработанных респондентов от их общего числа. 2. Процент успешно закрытых сделок от числа обработанных. 3. Статистика, показывающая зависимость временной шкалы от процента успешно закрытых сделок. Для документов с атрибутом "Прием вызовов" документ должен содержать следующую информацию: 1. Количество обработанных вызовов. 2. Процент успешно закрытых сделок от числа обработанных вызовов. 3. Статистика, показывающая зависимость временной шкалы от процента успешно закрытых сделок.

8. Система должна иметь возможность создания, редактирования и удаления документа "Отчет качества работы оператора" по каждому оператору. Данный документ должен содержать статистическую информацию о работе оператора, а именно: 1. Количество обработанных вызовов по типу. 2. Среднее время обработки вызова по типу. 3. Процент успешно закрытых сделок от общего числа обработанных вызовов.

Функциональные требования процесса "Прием и совершение звонков":

В учетной записи "Оператор":

1. Документ "Журнал задач оператора", сформированный супервайзером, должен поступать на АРМ оператора.

2. При работе по документу "Журнал задач оператора" с атрибутом "Прием вызовов" на экране оператора должен отображаться скрипт разговора из данного документа.

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

4. При завершении входящего обработки вызова должно открываться окно для записи результата. Данное окно должно содержать автоматически собранную информацию о дате, времени и продолжительности вызова. Также должна производиться запись разговора. Оператор вручную вводит информацию об итоге вызова в окно записи результата и сохраняет его. Система должна не разрешать возможность оставить окно незаполненным. При отсутствии заполнения система должна выдать ошибку. Результат обработки вызова вместе со статистическими данными должен автоматически подгружаться в документы "Внутренний отчет о проделанной работе" и "Ежедневный отчет для клиента". В документ "Внутренний отчет о проделанной работе" также должна загружаться запись разговора. Тип связи для документов "Журнал задач оператора" и "Внутренний отчет о проделанной работе" / "Ежедневный отчет для клиента" один к одному. Если данных документов на момент записи строки результата обработки вызова не обнаружено, они должны создаваться автоматически.

5. При работе по документу "Журнал задач оператора" с атрибутом "Совершение вызовов" на экране оператора должен отображаться скрипт разговора из данного документа и строки с ФИО и телефонными номерами респондентов.

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

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

8. При завершении обработки исходящего вызова должно открываться окно для записи результата. Данное окно должно содержать автоматически собранную информацию о дате, времени и продолжительности вызова. Также должна производиться запись разговора. Оператор вручную вводит информацию об итоге вызова в окно записи результата. Если оператор не дозвонился до респондента или необходимо совершить повторный вызов по другой причине, он указывает в качестве результата обработки причину необходимости повторного вызова и выбирает дату и время для повторной связи. В этом случае строка с данным респондентом должна перезаписываться в "Журнал задач оператора" с соответствующей информацией, и по достижению необходимого времени система должна автоматически инициировать повторный вызов. Система должна не разрешать возможность оставить окно незаполненным. Результат обработки вызова вместе со статистическими данными должен автоматически подгружаться в документы "Внутренний отчет о проделанной работе" и "Ежедневный отчет для клиента". В документ "Внутренний отчет о проделанной работе" также должна загружаться запись разговора. Тип связи для документов "Журнал задач оператора" и "Внутренний отчет о проделанной работе" / "Ежедневный отчет для клиента" один к одному. Если данных документов на момент записи строки результата обработки вызова не обнаружено, они должны создаваться автоматически.

9. Каждая записанная строка в документе "Ежедневный отчет для клиента" в режиме реального времени должна автоматически передаваться в систему клиента.

Разработка нефункциональных требований

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

· Соответствие стандартам

· Адаптируемость

· Документируемость

· Простота сопровождения

· Защищенность

· Надежность

· Отказоустойчивость

· Работоспособность

· Удобство использования

· Переносимость



3. Разработка IT инфраструктуры call-центра

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

3.1 Описание технических средств call-центра

На рисунке 8 представлена модель технических средств call-центра.

Рис.8 Модель технических средств call-центра

УАТС - учрежденческая автоматическая телефонная станция, которая подключается к общей телефонной сети.

CTI Link - блок сопряжения с компьютерной сетью, обеспечивает обмен между телефоном и компьютером.

IVR - устройство интерактивного речевого обмена, которое соединяется с УАТС и компьютерной системой по стандартным протоколам.

ПО телефонного центра устанавливается в сервере Call-Центра.

3.2 Описание ПО call-центра

Дать однозначную характеристику программному обеспечению такой сложной системы как call-центр довольно-таки трудно. Объясняется это большим разнообразием методов при ее производстве. Цель его использования и габариты центра безусловно играют значительную роль во всей структуре и возможностях ПО, которое всегда состоит из логически и функционально завершенных блоков, изображенных на Рисунке 9. Все блоки собраны по схеме "клиент-сервер" и связаны с помощью протокола TCP/IP.

Рис.9 Модель ПО call-центра

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

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

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

Основываясь на команде модуля ICR, Т-сервер отправляет на УАТС приказ на маршрутизацию поступившего по телефону запроса от заданного агента или блока IVR. Вместе с тем сервер запускает API, который выводит на монитор оператора изображения с данными, которые вырабатываются модулем Desktop Tool Kit. Все эти модули можно совместить в одной клиент-серверной программе, а можно оставить как несколько самостоятельных единиц, все зависит от целей использования. В арендных call-центрах особенно часто используются прикладные 3-rd Party API.

Одна из самых важных ролей отводится блоку сервера базы данных (DB Server), благодаря ему другие модули могут связываться с базами. И, соответственно, он тоже считается основным.

Оперторам call-центра, занимающимся обзвоном клиентов, для организации исходящих вызовов необходимо в набор программ включить модуль Campaign Manager. Все номера телефонов, на которые осуществляется дозвон (а так же данные факсов, электронной почты или сайтов), сохраняются общей БД, а команда на звонок по телефонному номеру отдается модулем Dialer. Сами процедуры дозвона по телефонам, а также последовательность дозвонов могут быть назначены по-разному, все зависит от цели каждой отдельно взятой кампании, которая может быть посвящена и опросам, и рекламным акциям, и даже передаче "тревожного" сообщения (к примеру, о приближающемся урагане) и пр.

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

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

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

Модуль Call Center Reg отвечает за регистрацию и вывод на монитор информации, актуальной для супервайзера. Она поступает в виде изображений, графика или таблицы и отражает активность call-центра за истекший заданный период, например, 10 минут, 30 минут и т. д. Так же отчет содержит информацию о количестве занятых операторов, о видах запросов (входящие или исходящие), о количестве звонков и т. д. Вся эта информация дает супервайзеру возможность своевременно регулировать процесс и контролировать работу всего центра, к примеру, убирать или добавлять операторов, менять им задачу и т. д., и при всем этом система дает супервайзеру свободу передвижения и дает возможность находиться в любом месте - даже дома. Главное, чтобы канал связи мог передать желаемый объем статистики. инфраструктура программный бизнес call

Система так же может содержать модули интерфейсов для взаимодействия с Интернетом (Web Server, Web Browser, E-mail Server), цель их использования очевидна. [4]

3.3 Подбор системы

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

3.3.1 Описание существующих решений

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

Сall-центр Oktell представляет собой широкий набор функциональных возможностей автоматизации бизнес-процессов call-центра. Данная система используется в офисах и в крупных call-центрах. Оперативное решение задач и быстрая адаптация платформы под специфические бизнес-задачи достигается путем наличия служебных сценариев, унифицированных компонентов графического редактора, собственных интеграционных библиотек и событийной модели работы. На АРМ оператора устанавливается приложение Oktell, через которое происходит процесс приема и совершения вызовов. Оно также позволяет прослушивать записи телефонных разговоров. Работа оператора полностью автоматизирована, во время звонка на экран оператора выводится вся информация о клиента. [5]

Коммуникационная платформа Infinity создана компания Inteltelecom - лидером среди разработчиков решений в сфере автоматизации операторской деятельности. Infinity удовлетворяет всем потребностям современных call-центров и реализует такие функции, как:

· Автоматизированное определение клиента при звонке

· Мониторинг работы операторов в режиме онлайн, система многомерной аналитики

· Запись телефонных вызовов

· Интеллектуальная маршрутизация входящих вызовов

· Автоматические массовые обзвоны

· Интеграция с IT-системами [6]

3.3.2 Выбор системы

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

· 0 баллов - система не удовлетворяет функциональному требованию;

· 1 балл - система частично удовлетворяет функциональному требованию;

· 2 балла - система полностью удовлетворяет функциональному требованию.

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

В системе Infinity отсутствует возможность присвоения документу атрибута "Клиент". Данная функция реализована как создание документа в группе документов по данному клиенту.

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

Таблица 3

Таблица соответствия систем требованиям руководителя call-центра

Требования Руководителя	Баллы соответствия
	Oktell	Infinity
Система должна иметь возможность создания, редактирования и удаления документа "Список задач call-центра". При создании документа ему присваиваются атрибут по типу задачи (Прием/Совершение вызовов) и атрибут "Клиент". Независимо от типа задачи устанавливаются атрибуты документа "Дата начала выполнения задачи" и "Дата окончания выполнения задачи".	2	1
Документ "Список задач call-центра" с атрибутом "Совершение вызов" должен содержать в себе строки: 1. ФИО респондента 2. Телефонный номер респондента.	2	2
Документ "Список задач call-центра" с атрибутом "Прием вызов" должен содержать в себе строки: 1. Обрабатываемый телефонный номер.	2	2
Система должна давать возможность просматривать документ "Отчет качества работы оператора".	2	2
ИТОГ:	8 баллов	7 баллов



Таблица 4

Таблица соответствия систем требованиям супервайзера

Требования супервайзера	Баллы соответствия
	Oktell	Infinity
Система должна иметь возможность просматривать документы "Список задач call-центра", "Внутренний отчет о проделанной работе".	2	2
Система должна иметь возможность создания, редактирования и удаления документа "Журнал задач оператора". При создании документа ему присваиваются атрибут по типу задачи (Прием/Совершение вызовов), атрибуты "Клиент" и "Оператор". Независимо от типа задачи устанавливаются атрибуты документа "Дата начала выполнения задачи" и "Дата окончания выполнения задачи".	2	0
Система должна иметь возможность создания, редактирования и удаления документа "Скрипт разговора".	1	2
Документ "Журнал задач оператора" с атрибутом "Совершение вызовов" должен содержать в себе следующие строки: 1. ФИО респондента 2. Телефонный номер респондента. 3. Скрипт разговора. Формат строки №3 Скрипт разговора должен быть представлен в формате выпадающего списка, предлагающего выбор имеющихся в базе готовых документов данного типа.	1	2
	Oktell	Infinity
Документ "Журнал задач оператора" с атрибутом "Прием вызовов" должен содержать в себе следующие строки: 1. Обрабатываемый телефонный номер. 2. Скрипт разговора.	2	2
Система должна иметь возможность создания документа "Журнал задач оператора" как вручную, так и автоматически. При автоматическом создании данные должны импортироваться из документа "Список задач call-центра".	2	2
Система должна иметь возможность создания, редактирования и удаления документа "Еженедельный отчет для клиента". Для документов с атрибутом "Совершение вызова" данный документ должен содержать следующую информацию: 1. Процент обработанных респондентов от их общего числа. 2. Процент успешно закрытых сделок от числа обработанных. 3. Статистика, показывающая зависимость временной шкалы от процента успешно закрытых сделок. Для документов с атрибутом "Прием вызовов" документ должен содержать следующую информацию: 1. Количество обработанных вызовов. 2. Процент успешно закрытых сделок от числа обработанных вызовов. 3. Статистика, показывающая зависимость временной шкалы от процента успешно закрытых сделок.	2	2
Система должна иметь возможность создания, редактирования и удаления документа "Отчет качества работы оператора" по каждому оператору. Данный документ должен содержать статистическую информацию о работе оператора, а именно: 1. Количество обработанных вызовов по типу. 2. Среднее время обработки вызова по типу. 3. Процент успешно закрытых сделок от общего числа обработанных вызовов.	2	1
ИТОГ:	14 баллов	13 баллов

Система Oktell не позволяет создавать документ "Скрипт разговора". Соответственно отсутствует возможность присвоить документ "Скрипт разговора" документу "Журнал задач оператора". Данная функция в системе реализована как атрибут документа.

В системе Infinity отсутствует возможность разделения документов по типу работы (Входящие/исходящие вызовы). Таким образом, отсутствует возможность выведения статистики по типу работы.

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

Таблица 5

Таблица соответствия систем требованиям оператора

Требования оператора	Баллы соответствия
	Oktell	Infinity
Документ "Журнал задач оператора", сформированный супервайзером, должен поступать на АРМ оператора.	2	2
При работе по документу "Журнал задач оператора" с атрибутом "Прием вызовов" на экране оператора должен отображаться скрипт разговора из данного документа.	2	2
При обработке входящего вызова, непосредственно в момент установления соединения, на экран оператора должна выводиться информация с номером телефона, типом вызова (первичный/повторный), результатом предыдущих обращений для повторных вызов.	2	2
При завершении входящего обработки вызова должно открываться окно для записи результата. Данное окно должно содержать автоматически собранную информацию о дате, времени и продолжительности вызова. Также должна производиться запись разговора. Оператор вручную вводит информацию об итоге вызова в окно записи результата и сохраняет его. Система должна не разрешать возможность оставить окно незаполненным. При отсутствии заполнения система должна выдать ошибку. Результат обработки вызова вместе со статистическими данными должен автоматически подгружаться в документы "Внутренний отчет о проделанной работе" и "Ежедневный отчет для клиента". В документ "Внутренний отчет о проделанной работе" также должна загружаться запись разговора. Тип связи для документов "Журнал задач оператора" и "Внутренний отчет о проделанной работе" / "Ежедневный отчет для клиента" один к одному. Если данных документов на момент записи строки результата обработки вызова не обнаружено, они должны создаваться автоматически.	0	2
	Oktell	Infinity
При работе по документу "Журнал задач оператора" с атрибутом "Совершение вызовов" на экране оператора должен отображаться скрипт разговора из данного документа и строки с ФИО и телефонными номерами респондентов.	2	2
Набор телефонного номера каждой строки документа должен происходить автоматически после инициации оператором вызова. (нажатия установленной клавиши).	2	2
Если вызов данному респонденту повторный, при установлении соединения на экран оператора должна выводиться информация с результатом, датой и временем предыдущего вызова.	2	2
	Oktell	Infinity
При завершении обработки исходящего вызова должно открываться окно для записи результата. Данное окно должно содержать автоматически собранную информацию о дате, времени и продолжительности вызова. Также должна производиться запись разговора. Оператор вручную вводит информацию об итоге вызова в окно записи результата. Если оператор не дозвонился до респондента или необходимо совершить повторный вызов по другой причине, он указывает в качестве результата обработки причину необходимости повторного вызова и выбирает дату и время для повторной связи. В этом случае строка с данным респондентом должна перезаписываться в "Журнал задач оператора" с соответствующей информацией, и по достижению необходимого времени система должна автоматически инициировать повторный вызов. Система должна не разрешать возможность оставить окно незаполненным. Результат обработки вызова вместе со статистическими данными должен автоматически подгружаться в документы "Внутренний отчет о проделанной работе" и "Ежедневный отчет для клиента". В документ "Внутренний отчет о проделанной работе" также должна загружаться запись разговора. Тип связи для документов "Журнал задач оператора" и "Внутренний отчет о проделанной работе" / "Ежедневный отчет для клиента" один к одному. Если данных документов на момент записи строки результата обработки вызова не обнаружено, они должны создаваться автоматически.	0	1
Каждая записанная строка в документе "Ежедневный отчет для клиента" в режиме реального времени должна автоматически передаваться в систему клиента.	2	2
ИТОГ:	14 баллов	17 баллов

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

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

...