Актуальность темы исследования

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

Таблица 2 Функции отдела разработки

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

Таблица 3 Функции департамента развития продуктов и технологий

Департамент коммерции состоит из двух отделов: отдел продаж и отдел сверок и расчётов. Основной задачей отдела продаж является нахождение новых клиентов компании. Также отдел продаж занимается ведением клиента на протяжении всего времени взаимодействия с компанией: от звонка до «боевого» подключения и дальнейшей поддержки клиента. Всем процессом юридической интеграции также занимается отдел продаж, сотрудники отдела помогают клиенту получить и оформить необходимые документы и согласовать их с внешними партнерами компании. Функции отдела продаж приведены в таблицах ниже:

Таблица 4 Функции отдела продаж

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

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

1.2 Анализ функций участников автоматизируемых процессов

В автоматизируемых процессах участвуют сотрудники департамента IT и департамента коммерции. Процесс направлен на внедрение платежной системы клиенту.

Участники процесса со стороны департамента коммерции:

· Менеджер по продажам

· Аккаунт менеджер

· Специалист по источникам денег

Участники процесса со стороны департамента ИТ:

· Специалист технической поддержки

· Старший разработчик

· Разработчик ПО

· Инженер тестирования

Рассмотрим функции участников процесса по отдельности:

Менеджер по продажам (МПП)

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

Таблица 8 Функции менеджера по продажам

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

Таблица 9 Функции аккаунт менеджера

Специалист по источникам денег заводит в систему новые товары и сервисы, попутно проверяя их контент на допустимость (соответствие законодательству РФ). После заведения товары и сервисы отправляются на согласование с банком. Результат согласования СИД передает аккаунт менеджеру. Функции СИДа описаны в таблице ниже:

Таблица 10 Функции специалиста по источникам денег

Специалист технической поддержки (СТП)

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

Таблица 11 Функции специалиста тех. Поддержки

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

Таблица 12 Функции старшего разработчика

Разработчик ПО непосредственно занимается разработкой новых платежных модулей и доработкой и настройкой текущих платежных модулей под руководством старшего разработчика. Функции разработчика ПО описаны в таблице ниже:

Таблица 13 Функции разработчика ПО

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

Таблица 14 Функции инженера тестирования

2. Формирование функциональных требований к информационной системе

Карта процессов отображает порядок выполнения подпроцессов и их взаимодействие и помогает определить связь процессов. В данной работе автоматизируется взаимодействие бизнес-процессов коммерческого и ИТ департаментов в рамках бизнес-процесса внедрения платежной системы. Бизнес-процесс внедрения состоит из двух параллельных подпроцессов: юридической и технической интеграции. Юридическая интеграция состоит из трех подпроцессов:

· Привлечение клиента и загрузка документов

· Получение клиентом ЭЦП и одобрения банком

· Заведение товаров и сервисов клиента в систему

Техническая интеграция состоит из двух подпроцессов:

· Разработка платежного модуля

· Настройка товаров и тестирование модуля

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

Моделирование процесса юридической интеграции

Юридическая интеграция состоит из нескольких подпроцессов:

1. От знакомства с клиентом до загрузки документов в личный кабинет

2. Получение ЭЦП (Электронно-цифровой подписи) и одобрение банка

3. Заведение товаров и сервисов клиента в систему

Рассмотрим подробнее каждый из подпроцессов:

Подпроцесс 1. Привлечение клиента и загрузка документов в ЛКТ

Участники процесса со стороны ИнПлат:

· Менеджер по продажам

· Аккаунт менеджер

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

1. Произошел первый контакт с потенциальным клиентом

a. Менеджер по продажам (МПП) звонит потенциальному клиенту

b. МПП написал письмо потенциальному клиенту

c. Потенциальный клиент сам вышел на контакт

2. В случае если оборот клиента особо крупный (более 30 млн. рублей в месяц) МПП проводит личную встречу с клиентом для обсуждения деталей условий работы

3. МПП документирует информацию о клиенте (занесение в общий Excel файл)

4. МПП уведомляет по эл. почте специалиста технической поддержки (СТП) и аккаунт менеджера (АМ) о начале интеграции с новым клиентом

5. Клиент загружает документы необходимые для юр. интеграции в личный кабинет ИнПлат

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

7. Документы приняты. Сценарий первого подпроцесса завершается

Рисунок 8 Юридическая интеграция. Подпроцесс 1

Подпроцесс 2. Получение ЭЦП (Электронно-цифровой подписи) и одобрение банком

· Менеджер по продажам

· Аккаунт менеджер

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

1. Менеджер по продажам (МПП) устанавливает контакт между клиентом и курьерской службой доставки

2. МПП согласовывает с клиентом даты доставки документов

3. Запускается внешний процесс получения ЭЦП. Со стороны Инплат происходит ожидания получения клиентом ЭЦП. После получения клиентом ЭЦП сценарий продолжается.

4. МПП устанавливает контакт между клиентом и аккаунт менеджером (АМ)

5. Клиент подписывает необходимые юридические документы в личном кабинете с помощью ЭЦП

6. АМ передает подписанные документы в банк

7. В течение суток банк одобряет подписанные документы. Сценарий второго подпроцесса завершается

Рисунок 9 Юридическая интеграция. Подпроцесс 2

Подпроцесс 3. Заведение товаров и сервисов клиента в систему

Участники процесса со стороны ИнПлат:

· Аккаунт менеджер

· Специалист по источникам денег

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

1. Аккаунт менеджер (АМ) уведомляет по почте специалиста по источникам денег (СИД) о необходимости заведения товаров клиенту

2. СИД заводит товары

3. СИД согласовывает товары и комиссию по товарам с банком Раунд

4. АМ уведомляет по почте специалиста технической поддержки (СТП) о необходимости настройки товаров

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

6. АМ получает уведомление по почте от СТП о завершении технической интеграции

7. АМ уведомляет по почте СТП о готовности запуска клиента в коммерцию (полноценному началу работы системы ИнПлат на стороне клиента)

8. Система ИнПлат внедрена. Завершение сценария

Рисунок 10 Юридическая интеграция. Подпроцесс 3

Моделирование процесса технической интеграции

· Разработка\доработка платежного модуля

· Проведение тестирование и настройка модуля на стороне клиента

Процессы технической интеграции смоделированы согласно нотации, описанной в таблице 15.

Подпроцесс 1. Разработка\настройка платежного модуля

Участники подпроцесса разработки\доработки платежного модуля:

· Специалист технической поддержки (СТП)

· Старший разработчик

· Разработчик ПО

Данный подпроцесс начинается после завершения первого подпроцесса юридической интеграции и выполняется параллельно с получением клиентом ЭЦП и одобрения банком. На вход подпроцесс получает уведомление о начале работы с клиентом от подпроцесса привлечения клиентов и загрузки документов. На выход подпроцесс выдает программную документацию готового платежного модуля. Сценарий смоделированного подпроцесса разработки\доработки платежного модуля:

1. Получено уведомление о начале работы с клиентом

2. Специалист технической поддержки собирает сценарии работы клиента

3. Старший разработчик анализирует полученные сценарии и создает документ с задачами на доработку\разработку платежного модуля

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

5. Разработчик ПО разрабатывает новый платежный модуль\дорабатывает существующий платежный модуль

6. Разработчик документирует новый модуль\документирует изменения в дорабатываемом платежном модуле

7. Старший разработчик выполняет ревью кода

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

9. Сценарий подпроцесса завершается

Рисунок 11 Техническая интеграция. Подпроцесс 1

Подпроцесс 2. Настройка товаров и тестирование модуля

· Специалист технической поддержки (СТП)

· Инженер тестирования

· Старший разработчик

Данный подпроцесс начинается после завершения разработки платежного модуля. На вход в процесс поступает программная документация разработанного платежного модуля. Также для настройки товаров необходима информация о товарах, получаемая из процесса заведения товаров и сервисов клиента в систему (юридическая интеграция). Настройка товаров и тестирование модуля происходит параллельно с получением ЭЦП клиентом и одобрения банком, а также параллельно с согласованием товаров и сервисов с банком. Подпроцесс завершается за день до завершения юридической интеграции. Сценарий процесса:

1. Специалист технической поддержки (СТП) отправляет коды доступа к тестовому модулю клиенту по эл. почте

2. Инженер тестирования подготавливает план тестирования

3. Инженер тестирования проводит тестирование платежного модуля

4. Старший разработчик проводит ревью результатов тестирования

5. СТП настраивает товары согласно списку полученных товаров от специалиста по источникам денег

6. СТП отправляет коды доступа к итоговому платежному модулю клиенту по эл. почте

7. СТП отправляет уведомление аккаунт-менеджеру по эл. Почте о завершении тех. интеграции. Сценарий завершается

Рисунок 12 Техническая интеграция. Подпроцесс 2

2.2 Анализ проблемных зон взаимодействия подпроцессов

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

· Создание общей информационной базы с информацией о клиентах

· Создание единой системы коммуникации, как между департаментами, так и внутри департамента

Рассмотрим точки взаимодействия между подпроцессами:

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

· Подпроцесс получения ЭЦП и одобрения банком начинается после одобрения документов, загруженных клиентом. Фактически аккаунт менеджер лично уведомляет менеджера по продажам о начале подпроцесса

· Подпроцесс заведения товаров и сервисов клиента в систему начинается после одобрения клиентом банком. Фактически аккаунт менеджер отправляет электронное письмо специалисту по источникам денег со списком товаров для их заведения в систему

· В подпроцессе заведения товаров и сервисов клиента в систему аккаунт менеджер уведомляет специалиста технической поддержки по эл. почте о необходимости настройки товаров

· Подпроцесс разработки\настройки платежного модуля начинается с получения уведомления от менеджера по продажам по эл. почте.

· Старший разработчик в процессе настройки\разработки платежного модуля отправляет письмо в коммерческий департамент о готовности платежного модуля

· Подпроцесс настройки товаров и тестирования модуля начинается после завершения разработки\настройки платежного модуля. Фактический старший разработчик уведомляет лично специалиста тех. поддержки о начале проведения тестирования

· В подпроцессе настройки товаров и тестирования модуля специалист тех. поддержки получает письмо со списком товаров для настройки от специалиста по источникам денег по эл. почте

· В подпроцессе настройки товаров и тестирования модуля специалист тех. поддержки уведомляет департамент коммерции о завершении тех. интеграции по эл. почте

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

· Сложность контролирования текущего статуса подключения конкретного клиента

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

· Потеря очередности выполнения функций сотрудника из-за неконтролируемого объема скопившихся уведомлений на почте и отсутствия единой системы ведения клиента

· Временные задержки выполнения функций внутри отдела из-за потери очередности подключения клиентов

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

· Потеря очередности подключения клиентов, в результате некоторые клиенты проходят подключение быстрее тех, которые подали заявку на подключение ранее

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

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

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

2.3 Моделирование бизнес-процесса внедрения платежной системы с участием информационной системы

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

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

Подпроцесс 1.Разработка/доработка платежного модуля (TO-BE)

Участники подпроцесса разработки\доработки платежного модуля:

· Специалист технической поддержки (СТП)

· Старший разработчик

· Разработчик ПО

Автоматизация процесса не затронула добавление новых функций участникам процесса, однако изменила сценарий взаимодействия между ними. Рассмотрим сценарий выполнения подпроцесса:

1. Информационная система выдала уведомление о начале работы с новым клиентом

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

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

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

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

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

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

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

9. Сценарий подпроцесса завершается

Рисунок 13 Техническая интеграция. Подпроцесс 1 TO-BE

Подпроцесс 2. Настройка товаров и тестирование модуля (TO-BE)

· Специалист технической поддержки (СТП)

· Инженер тестирования

· Старший разработчик

Автоматизация процесса не затронула добавление новых функций участникам процесса, однако изменила сценарий взаимодействия между ними. Рассмотрим сценарий выполнения подпроцесса:

1. Специалист технической поддержки (СТП) отправляет коды доступа к тестовому модулю клиенту по эл. почте

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

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

4. Старший разработчик проводит ревью результатов тестирования в информационной системе

5. СТП настраивает товары согласно списку товаров прикрепленных к клиенту в информационной системе

6. СТП отправляет коды доступа к итоговому платежному модулю клиенту по эл. почте

7. СТП изменяет статус технический интеграции клиента в информационной системе. Сценарий завершается

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

Рисунок 14 Техническая интеграция. Подпроцесс 2 (TO-BE)

Моделирование процессов юридической интеграции (TO-BE)

Подпроцесс 1. Привлечение клиента и загрузка документов в ЛК

Участники процесса со стороны ИнПлат:

· Менеджер по продажам

· Аккаунт менеджер

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

1. Произошел первый контакт с потенциальным клиентом

a. Менеджер по продажам (МПП) звонит потенциальному клиенту и фиксирует записи о клиенте в информационной системе

b. МПП написал письмо потенциальному клиенту

c. Потенциальный клиент сам вышел на контакт

2. В случае если оборот клиента особо крупный (более 30 млн. рублей в месяц) МПП проводит личную встречу с клиентом для обсуждения деталей условий работы и заносит протокол встречи в информационную систему

3. МПП документирует информацию о клиенте в карточке клиента в информационной системе

4. МПП изменяет статус клиента в информационной системе. Система уведомляет специалиста технической поддержки (СТП) и аккаунт менеджера (АМ) о начале интеграции с новым клиентом

5. Клиент загружает документы необходимые для юр. интеграции в личный кабинет ИнПлат

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

7. Документы приняты. Сценарий первого подпроцесса завершается

Рисунок 15 Юридическая интеграция. Подпроцесс 1 (TO-BE)

Подпроцесс 2. Получение ЭЦП (Электронно-цифровой подписи) и одобрение банком (TO-BE)

Участники процесса со стороны ИнПлат:

· Менеджер по продажам

· Аккаунт менеджер

Внедрение информационной системы не затронуло порядок выполнения функций подпроцесса. Основным и единственным изменением является изменение статусов клиента в информационной системе по мере выполнения функций подпроцесса. Рассмотрим основной сценарий:

1. Менеджер по продажам (МПП) устанавливает контакт между клиентом и курьерской службой доставки, обновляет текущий статус клиента в инф. системе

2. МПП согласовывает с клиентом даты доставки документов

3. Запускается внешний процесс получения ЭЦП. Со стороны Инплат происходит ожидания получения клиентом ЭЦП. После получения клиентом ЭЦП сценарий продолжается.

4. МПП устанавливает контакт между клиентом и аккаунт менеджером (АМ)

5. Клиент подписывает необходимые юридические документы в личном кабинете с помощью ЭЦП

6. АМ передает подписанные документы в банк, обновляет текущий статус клиента в инф. системе

7. В течение суток банк одобряет подписанные документы. Сценарий второго подпроцесса завершается

Рисунок 16 Юридическая интеграция. Подпроцесс 2(TO-BE)

Подпроцесс 3. Заведение товаров и сервисов клиента в систему

· Аккаунт менеджер

· Специалист по источникам денег

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

1. Аккаунт менеджер (АМ) ставит задачу в системе на специалиста по источникам денег (СИД) о необходимости заведения товаров клиенту

2. СИД заводит товары, руководствуясь полученной задачей из информационной системы

3. СИД согласовывает товары и комиссию по товарам с банком Раунд

4. АМ ставит задачу в системе на специалиста технической поддержки (СТП) о необходимости настройки товаров

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

6. АМ получает уведомление в инф. Системе о завершении технической интеграции

7. АМ изменяет статус клиента в инф. системе на готовность к запуску клиента в коммерцию (полноценное начало работы системы ИнПлат на стороне клиента)

8. Система ИнПлат внедрена. Завершение сценария

Рисунок 17 Юридическая интеграция. Подпроцесс 3 (TO-BE)

2.4 Документирование функциональных требований к информационной системе

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

Таблица 15 Нотация матрицы операций

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

Ниже приведена матрица операций сотрудников департамента ИТ, взаимодействующих с внедряемой информационной системой:

Таблица 16 Матрица операций сотрудников департамента ИТ

Код	Операция	Рабочее место	Вход	Выход
ОП-1	Получение сценариев работы клиента	Специалист тех. поддержки (СТП)	Контактная информация клиента	Сценарий работы клиента
ОП-2	Ознакомление со сценарием и постановка задач	Старший разработчик	Сценарий работы клиента	Задача на доработку\ разработку
ОП-3	Разработка нового модуля	Разработчик ПО	Задача на разработку	Код продукта
ОП-4	Документирование нового модуля	Разработчик ПО	Код продукта	Программная документация
ОП-5	Доработка платежного модуля	Разработчик ПО	Задача на доработку	Код продукта

Таблица 17 Матрица операций сотрудников департамента ИТ

Код	Операция	Рабочее место	Вход	Выход
ОП-6	Документирование модуля	Разработчик ПО	Код продукта	Программная документация
ОП-7	Ревью кода	Старший разработчик	Программная документация	Комментарии по документации
ОП-8	Подтверждение о готовности платежного модуля	Старший разработчик	Комментарии по документации	Смена статуса клиента
ОП-9	Подготовка плана тестирования	Инженер тестирования	Программная документация	План тестирования
ОП-10	Проведения тестирования платежного модуля	Инженер тестирования	План тестирования	Результаты тестирования
ОП-11	Ревью результатов тестирования	Старший разработчик	Результаты тестирования	Комментарии результатов
ОП-12	Настройка товаров	СТП	Список товаров	Комментарий о завершении настройки
ОП-13	Уведомление Аккаунт менеджера о завершении тех. интеграции	СТП	Комментарий о завершении настройки	Смена статуса клиента

Ниже приведена матрица операций сотрудников департамента коммерции, взаимодействующих с внедряемой информационной системой:

Таблица 18 Матрица сотрудников департамента коммерции

Код	Операция	Рабочее место	Вход	Выход
ОП-14	Звонок потенциальному клиенту	Менеджер по продажам (МПП)	Контактная информация клиента	Запись о клиенте
ОП-15	Проведение встречи с клиентом	МПП	Запись о клиенте	Протокол интервью
ОП-16	Документирование информации о клиенте	МПП	Запись о клиенте; Протокол интервью	Карточка клиента
ОП-17	Уведомление АМ и СТП о начале работы с клиентом	МПП	Письмо о регистрации в личном кабинете	Письмо о начале работы с клиентом
ОП-18	Установление контакта клиента с курьерской службой	МПП	Письмо о принятии документов	Письмо в курьерскую службу
ОП-19	Передача документов в банк	АМ	Подписанные документы	Письмо клиенту
ОП-20	Уведомление СИДа о необходимости заведения товаров	АМ	Письмо из банка о подтверждении клиента	Задача на заведение товаров
ОП-21	Заведение товаров	СИД	Задача на заведение товаров	Письмо АМ о заведении товаров
ОП-22	Уведомление СТП о необходимости настройки товаров	АМ	Письмо от СИДА о заведении товаров	Задача на настройку товаров
ОП-23	Уведомление СТП о готовности запуска клиента в коммерцию	АМ	Письмо о завершении тех. интеграции	Письмо о готовности запуска

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

Таблица 19 Нотация описания требований

Поле	Описание
Код	Номер требования
Описание	Описание требования
Операция	Код соответствующей операции из матрицы операций

Документирование требований выполняется по ГОСТ-34[22].

Ниже приведена таблица разработанных функциональных требований к системе:

Таблица 20 Функциональные требования к системе

Код	Описание	Операция
ФТ-1	Система должна хранить записи о клиенте и позволять их добавлять\изменять\удалять	ОП-14, ОП-15, ОП-16
ФТ-2	Система должна позволять отслеживать статус клиента	ОП-17, ОП-18, ОП-19, ОП-23,
ФТ-3	Система должна позволять создавать задачи, привязанные к клиенту и сотруднику, выполняющему задачу	ОП-20, ОП-21, ОП-22, ОП-2, ОП-3, ОП-5
ФТ-4	Система должна позволять обеспечивать обмен документами через прикрепление документа к записям о клиенте	ОП-1, ОП-2, ОП-4

Таблица 21 Функциональные требования к системе

Код	Описание	Операция
ФТ-5	Система должна позволять отслеживать статус выполнения задачи, с распределением прав доступа к просмотру задач (Статус выполнения задачи должен видеть только исполнитель и автор задачи, а также прикрепленные наблюдатели)	ОП-20, ОП-21, ОП-22, ОП-2, ОП-3, ОП-5
ФТ-6	Система должна уведомлять участников процесса о смене статуса клиента	ОП-13, ОП-22, ОП-23,
ФТ-7	Система должна позволять оставлять комментарии к задачам и клиентам	ОП-14, ОП-15, ОП-20, ОП-21, ОП-22, ОП-2, ОП-3, ОП-5
ФТ-8	Система должна выставлять порядок выполнения задач сотрудника учитывая приоритет и дату создания задачи	ОП-20, ОП-21, ОП-22, ОП-2, ОП-3, ОП-5



3. Обоснование выбора информационной системы

3.1 Формирование критериев выбора системы

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

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

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

Также в компании до момента внедрения информационной системе введена и настроена вики-система хранения информации Confluence. Система предназначена для структурирования информации, обмена файлами и является главным источником знаний в компании. Одним из важнейших критериев выбора информационной системы является поддержка интеграции системы с Confluence.

Ниже приведена таблица критериев выбора системы с проставленными весами по шкале от 1 до 3, где 1- критерий имеет низкую важность, 2- критерий имеет средний приоритет, 3- критерий является критическим при выборе системы. Оценку приоритета критериев провела совместно проектная команда по внедрению информационной системы.

Таблица 22 Критерии выбора информационной системы

Код	Критерий	Значимость
К-1	Стоимость лицензии системы ниже 80000р.\мес.	2
К-2	Хранение записей на локальном сервере	3
К-3	Возможность интеграции с системой confluence	3
К-4	Возможность ведения более 40 учетных записей	3
К-5	Хранение записей о клиентах	3
К-6	Отслеживание статуса клиента	3
К-7	Возможность создания комментариев к задаче\записи клиента	1
К-8	Управление задачами	3
К-9	Ведение связи клиент-задача	2

3.2 Сравнение информационных систем по сформированным критериям

Исходя из финансовых и временных сроков, руководство компании приняло решение о выборе между следующими информационными системами:

· FlexbbyCRM

· JIRA

· Salesforce CRM

· Insightly

· Bitrix24

Произведен сравнительный анализ данных систем в таблице, приведенной ниже. Анализ произведен на основе информации о системах портала Startpack.ru [23]. Таблица содержит код критерия и его соответствие ему («+» - соответствует, «-» - не соответствует):

Таблица 23 Сравнительный анализ систем

Критерий	FlexbbyCRM	JIRA	SalesforceCRM	Insightly	Bitrix
К-1	+	+	+	+	-
К-2	+	+	-	-	+
К-3	-	+	-	+	-
К-4	+	+	+	+	+
К-5	+	+	+	+	+
К-6	+	+	+	+	+
К-7	-	+	+	+	-
К-8	-	+	-	-	-
К-9	-	+	-	-	-

Как видно из приведенной таблицы, информационная система JIRA соответствует всем сформированным критериям. Ближайшая система, подходящая по критериям - Insightly.

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

3.3 Оценка качества выбранной системы

Для оценки качества системы JIRA будем использовать набор критериев, предлагаемых ГОСТ Р ИСО/МЭК 9126-93 [23]. Для оценки будем использовать следующую шкалу: 0 - отсутствие критерия; 1 - низко выражен; 2 - средне выражен; 3 - ярко выражен. Максимально возможный балл - 60



Таблица 24 Оценка качества системы

Критерий

Страница:

•  1 
•  2 

дипломная работа "Автоматизация взаимодействия бизнес-процессов коммерческого и IT департаментов компании ИнПлат" скачать

Подобные документы

• Организация внедрения информационной системы ООО "MensFormat"

  Анализ организационной структуры и деятельности предприятия. Разработка диаграмм бизнес-процессов AS-IS, TO-BE. Характеристика этапов пакетов работ для внедрения автоматизированной информационной системы. Определение состава участников проекта и их задач.
  
  курсовая работа [3,3 M], добавлен 21.01.2015
  

• Автоматизация бизнес-процессов транспортной компании ООО "Сильные Машины"

  Описание бизнес-процессов транспортной компании ООО "Сильные машины". Построение модели "AS-IS" использования действующей информационной системы при работе с заявкой заказчика. Расчет совокупных доходов от владения выбранной информационной системой.
  
  дипломная работа [4,5 M], добавлен 09.06.2017
  

• Проектирование информационной системы для автоматизации деятельности предприятия сферы общественного питания

  Анализ существующих информационных систем для автоматизации деятельности предприятий общественного питания. Моделирование основных бизнес-процессов, выполняемых в автоматизированной информационной системе. Этапы разработки информационной системы.
  
  дипломная работа [1,8 M], добавлен 14.11.2017
  

• Моделирование бизнес-процессов ООО "СтильДент"

  Архитектура интегрированных информационных систем ARIS как методология моделирования бизнес-процессов, преимущества и недостатки использования. Выбор бизнес-процесса для моделирования и его содержательное описание, табличный формат его описания.
  
  курсовая работа [2,2 M], добавлен 19.06.2015
  

• Проектное решение информационной системы

  Особенности информационного взаимодействия в органах государственной власти. Организация информационных потоков в системе профессионального образования региона. Моделирование бизнес-процесса с использованием нотации BPMN. Социологическое исследование.
  
  дипломная работа [760,9 K], добавлен 03.09.2017
  

• Виды моделей и методы моделирования бизнес-процессов

  Моделирование бизнес-процессов как средство поиска путей оптимизации деятельности компании. Методология SADT (структурный анализ и проектирование), семейство стандартов IDEF и алгоритмические языки в основе методологий моделирования бизнес-процессов.
  
  реферат [21,7 K], добавлен 14.12.2011
  

• Моделирование бизнес-процессов на предприятии (на примере ООО "СемьСот" г. Владивосток)

  Анализ деятельности предприятия и моделирование основных бизнес-процессов. Моделирование бизнес-процессов при помощи CASE-средства Rational Rose. Получение прибыли путем расширения рынка товаров и услуг. Бизнес-процесс "Заказ и закупка товара".
  
  дипломная работа [1,2 M], добавлен 31.07.2012
  

• Автоматизация бизнес-процесса информационной поддержки клиентов консалтинговой фирмы посредством интернет-представительства

  Анализ средств информации консалтингового бизнеса: обзор языков программирования и программных средств для создания сайтов, информационных систем и сайтов консалтинговых фирм. Моделирование бизнес-процессов. Разработка интернет-представительства.
  
  дипломная работа [2,9 M], добавлен 11.04.2012
  

• Автоматизация комплекса задач менеджера отдела продаж торговой организации

  Анализ деятельности компании в целом и отдела продаж в частности. Описание состояния информационной системы предприятия. Декомпозиция бизнес-процессов, протекающих в отделе продаж. Проектирование информационной системы, ее программное обеспечение.
  
  дипломная работа [2,4 M], добавлен 29.08.2014
  

• Информационная система регистратуры гостиницы "Бастион"

  Сравнительный анализ гостиничных информационных систем. Анализ и выбор CASE-средств для моделирования бизнес-процессов. Визуальная и математическая модели предметной области, выбор архитектуры и платформы информационной системы, построение базы данных.
  
  дипломная работа [1,4 M], добавлен 20.07.2014
  

Другие документы, подобные "Автоматизация взаимодействия бизнес-процессов коммерческого и IT департаментов компании ИнПлат"

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам