изменять требования во время разработки на основании опыта
пользователей;
обеспечить большую гибкость в управлении проектом;
увеличить надежность системы, так как найденные ошибки будут
исправляться во время следующей итерации;
уменьшить риски Компании. Компания может в любой момент заморозить
разработку системы на любой итерации. Это полезно в том числе для более
безопасного финансового планирования.
Также мы будем использовать методологию быстрой разработки
приложений (Rapid Appliсation Development, RAD). [17]
RAD-разработка как правило содержит 3 элемента:
маленькую команду до 10 программистов. В нашем случае программист
будет только один;
короткий срок производства (от 1 до 6 месяцев);
повторяющийся цикл, при котором разработчики учитывают требования
заказчика на каждом этапе.
Внедрение системы будет осуществляться своими силами, так как
Компания имеет большой опыт во внедрении систем подобного рода у клиентов.
Так как при спиральной модели жизненного цикла будут создаваться различные
версии программ поэтапно, то сотрудники компании будут успевать освоить
введенный в эксплуатацию функционал и переложить на него некоторые процессы
компании. Что обеспечит логичное и мягкое влияние разработанной системы в
процессы Компании.
Таким образом получается, что процесс работы над каждой итерацией
проекта можно описать в соответствии со схемой, представленной на Рисунке №8:
Рисунок №8. Процесс работы Компании над проектом.
Задача разрабатываемой системы хранить всю историю взаимодействий с
заказчиком на всех этапах проекта. При правильном подходе к использованию
системы, у компании появится единая база данных обо всех процессах
выполнения услуги. Опираясь на информацию этой базы, легко можно будет
отследить эффективность того или иного сотрудника, проанализировать работы,
предложить клиенту другую услугу (или следующий этап этой) и т. п. Таким
образом СRM-система может быть задействована во многих направлениях
деятельности Компании. На Рисунке №9 показана место СRM-системе в
процессах Компании.
Рисунок №9. Место СRM-системы в процессах Компании.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Каждый из описанных в предыдущем параграфе этапов имеет свои риски
и проблемы.
На первом этапе, предпроектном, есть риск сделать неправильный расчет
стоимости или не учесть некоторые существующие решения, что поведет за собой
дополнительные расходы. Так же необходимо тщательно разобраться в
функционале каждого из возможных вариантов, чтобы разрабатываемая СRM-
была точно реализуема в рамках выбранной системы.
На втором этапе необходимо как можно тщательнее проработать все
бизнес-процессы Компании, понять какие из них имеет смысл оптимизировать и
перенести в функционал СRM-системы, а какие не имеет смысла. С какими
сервисами и информационными системами, используемыми Компанией,
необходимо провести интеграцию. Также необходимо разбить разработку на
этапы, чтобы вводить функционал в соответствии с выбранной моделью
жизненного цикла.
Третий этап, как и любая разработка информационных систем, может
затянуться и тогда бюджет, необходимый на реализацию проекта возрастет. Для
того, чтобы избежать этого риска, необходимо тщательно продумать концепцию
проекта на предыдущих этапах.
Последний этап, содержит наибольшее количество рисков. Самый
главный риск, связанный с введением СRM-системы, это то, что после разработки
и внедрения продукта им не станут пользоваться. Если персонал сочтет систему
по каким-то причинам неудобной для себя, не пройдет обучения и не поймет, как
ей правильно пользоваться, а начальство не настоит на обязательном
использовании разработанной системы, то весь проект окажется бессмысленной
тратой денег и времени. Для минимизации этого риска необходимо провести
обучение сотрудников, объяснить им преимущество разработанной системы и
обязать сотрудников использовать функционал системы. Кроме того, поэтапное
введение системы позволит минимизировать этот риск, так как сотрудники смогут
корректировать требования к системе по ходу разработки.
Помимо этого, необходимо заранее разрабатывать систему таким образом,
чтобы она была масштабируема на большее количество людей (так как количество
сотрудников в компании может вырасти) и функциональную расширяемость
системы, так как вместе с ростом компании возникнет потребность в новых
функциях.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для обеспечения безопасности данных системы необходимо разграничить
права доступа для пользователей системы. Для этого в разрабатываемой системе
будет возможность создания отдельных групп пользователей, каждому из которых
будет доступен или не доступен тот или иной модуль с информацией. Такие
группы можно будет создавать новые, но изначально пред настроенные
пользователи с их правами доступа отражены в Таблице №7.
Таблица №7.
Права доступа пользователей.
Администра
тор
Директор
Аккаунт-
менеджер
Менеджер
по
продажам
Технически
й
специалист
Работа с
группа
ми
пользов
ателей
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Запрещен
Запрещен
Запрещен
Работа с
пользов
ателям
и
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Запрещен
Запрещен
Запрещен
Работа с
со
справоч
никами
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние
Чтение/созда
ние
Работа с
клиента
ми
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение
Работа с
текущи
ми
задачам
и
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Рассыл
ка
писем
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение/созда
ние/удаление
Чтение
Послед
няя
активн
ость
Полный
Полный
Ограничен
Ограничен
Ограничен
Таким образом, не все сотрудники Компании будут способны видеть
информацию по клиентам и не касающихся их проектов, а также не смогут
редактировать или удалять имеющуюся информацию.
Также надо учесть вопросы безопасности СRM. Надежность системы
важна для бизнеса, так как бизнес без активной клиентской базы – это мертвый
бизнес. А также с точки зрения защиты персональных данных.[1]
Наша система будет располагаться на выделенном облачном сервере, а
значит такую защиту должен обеспечивать провайдер. В том числе важно
убедиться в надежности нашего провайдера, чтобы система работала постоянно,
а регулярно не «падала» вместе с сервером. Поэтому нужно выбирать надежного
поставщика.
Помимо этого, необходимо минимизировать риски со своей стороны: наша
система должна быстро обновляться при обнаружении малейшей уязвимости, она
должна постоянно быть на последней версии фреймворка.
Никакой сотрудник не должен давать свой пароль и логин посторонним
людям. Информация, доступная сотрудникам, должна быть доступна только им и
никому другому.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
В качестве поступившего обращения от клиента может быть: поступивший
звонок, описание ситуации в личной беседе, сообщение по электронной почте и
т.п. Поступившая заявка может быть либо отклонена, если она не по
специальности Компании или в текущий момент времени нет возможностей для
его решения, либо обработана для дальнейшего решения.
После обработки заявки по всем правилам руководителем или отдоим из
менеджеров Компании начинается формирование ТЗ и определение исполнителя
этого задания, в зависимости от его специальности, опыта работы и общей
занятости в текущий момент.
Обработанная информация об обращении отправляется на дальнейшие
этапы в зависимости от типа необходимых работ – это может быть консультация
пользователей, аналитика, разработка, тестирование и модернизация модулей и
ПО, техническая поддержка, маркетинг и т. п.
Также вносить данные в базу данных системы необходимо для сбора
статистики и накопления опыта работы. Она включает в себя формирование
запроса пользователем на основе информации об обращении, впоследствии чего
формируется и выполняется запрос к базе данных.
Для доступа к базе данных необходима авторизация пользователей по их
личному логину и паролю. Работа по формированию и выполнению запроса
выполняет непосредственно СRM-система.
Информационная модель, представляющая собой схему, отражающую
преобразование информационных реквизитов от источников информации до её
получателей [9] или, иными словами, процесс обработки информации в
информационной системе изображена на Рисунке №10.
Рисунок №10. Информационная модель СRM-системы
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Все данные, которые необходимо вносить в систему представляют собой
текст или цифры и должны быть введены в диалоговом режиме.
Просмотр
задач
Запрос
клиента
Задачи
Инфо о
клиенте
Управление
граппами
Сотрудник
ИС
Администратор
Управление
пользователями
Просмотр
активности
Рассылка
писем
Т Клиенты
Т Филиал
Т Сотрудники клиентов
Т История клиентов
Спр. Атрибуты
Т. Исполнители
Спр. Типы клиентов
Т Связи задача-исп
Т Идеи
Т История рассылок
Т Все письма
Т Шаблоны писем
Т Вопросы
Т. Комментарии
Т Проекты
Т Роли проекта
Т. Этапы
Т Пользователи
Т Группы
Просмотр
обсуждений
Т Шаблоны проектов
Т Роли этапа
Т Этапы шаблона проекта
Т Роли шаблона проекта
Т Активность
Выгрузка в
формате .xls
Сотрудник
Обсуждение
Вопросы
Активность
Письмо
рассылки
Т* Клиенты
Т* Шаблоны писем
Т Категории обсужд
Т* Проекты
Т* Активность
Ф История клиентов
Т* Вопросы
Т Обсуждения
Т* Обсуждения
Ввод этих данных должен быть устроен таким образом, чтобы у
пользователя системы эта процедура занимала минимальное количество времени,
так как иначе эффективность использования системы может быть низкой.
Данные о пользователях, клиентах, новых проектах, всевозможные
справочники и подобная информация должна вноситься в систему в процесс
работы с ней. Причем неважно во время работы с каким модулем были внесены
данные, они должны быть доступны из любого раздела и корректно отображаться
в процессе работы с другими модулями.
1. База данных должна хранить всю информацию, собранную во время
работы с системой.
2. База данных должна обеспечивать доступ ко всей информации в
удобном для пользователя виде.
3. При работе с системой никакие данные не должны быть утеряны и
должны быть доступны из любого раздела, не нуждаясь в повторном вводе.
4. Права пользователей на запись и чтение к информации из базы
данных должны быть разными (это будет обеспечено с помощью MySQL Server).
[11]
При машинной реализации задачи для формирования входного
оперативного файла сданными клиента используются данные из первичного
документа – Заявка на оказание консультационных услуг.
Этот документ не имеет типовой формы и, как правило, оформляется по
усмотрению менеджера.
Он содержит следующую информацию:
название клиента
полное название
адрес клиента
телефон клиента
почтовый адрес клиента
сайт
примечание
контактное лицо
Данный документ используется каждый раз. Когда появляется новый
проект, связанный с новым клиентом.
Экранная форма заполнения входной информации представлена на
рисунке №11.
Рисунок №11. Экранная форма ввода информации о клиенте
При появлении нового проекта, связанного со старым клиентом,
заполняется только информация о составе работ и сроках выполнения, так как вся
информация у клиента уже есть в системе и дублировать ее смысла не имеет.
Помимо этого, необходимы справочники, содержащие общие данные,
которые часто повторяются при вводе данных в систему. Информация о
необходимых справочниках содержится в Таблице №8.