Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Обоснование и разработка ИТ-решения

Обоснование и разработка ИТ-решения

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 11.08.2017
Размер файла 2,7 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

Рисунок 2.1 Универсальная иерархическая структура по МАИ [6].

На практике МАИ чаще всего применяется для решения задач многокритериального выбора. В этом случае цель, расположенная на вершине иерархии, имеет несколько альтернативных способов ее достижения, которые занимают самый низкий уровень иерархии. Для определения наиболее эффективного решения среди существующих альтернатив используются критерии выбора, причем критерии второго уровня при необходимости могут быть декомпозированы на подкритерии следующего уровня неограниченное количество раз [7]. Чтобы применить этот метод для решения задачи ранжирования целей, необходимо немного модифицировать исходную концепцию. Нижний уровень нашей иерархии будет представлен ИТ-целями. Они не являются альтернативами по отношению друг к другу, однако, в разной степени влияют на достижение главной стратегической цели компании. Их весовые коэффициенты будут определены не для того, чтобы сделать выбор в пользу какой-то одной цели, а для того, чтобы проранжировать их в порядке приоритета. Алгоритм расчета весовых коэффициентов ИТ-целей, расположенных на нижнем уровне, по методу анализа иерархий состоит из нескольких этапов:

1. Сначала сравниваются бизнес-цели по степени своей значимости для достижения главной стратегической цели. Поскольку значимость цели не является количественной характеристикой, используется метод попарных сравнений на основе специальной “шкалы относительной важности” (рисунок 2.2) [8]. Эксперты коллегиально дают оценку относительной значимости для каждой уникальной пары бизнес-целей, после чего на основе полученных оценок заполняется матрица размерностью N на N, где N равно количеству бизнес-целей иерархии. Предположим, что цель №2 по степени своего влияния на достижение главной стратегической цели имеет значительное превосходство над целью №4, тогда на месте пересечения 2-ой строки и 4-ого столбца, ставим значение 5, а на месте пересечения 4-ой строки и 2-ого столбца ставим значение, обратное 5-ти - 1/5. Диагональ матрицы всегда состоит из единиц, так как каждая цель относительно себя имеет равную значимость. Из описания алгоритма заполнения матрицы вытекает, что она обратно-симметрична.

Рисунок 2.2 Шкала относительной важности элементов иерархии МАИ [9].

2. По такому же принципу строятся матрицы размерностью M на M для каждой бизнес-цели, где M - количество ИТ-целей иерархии. То есть на этом этапе эксперты, используя ту же шкалу, сравнивают между собой ИТ-цели по степени их влияния на достижение каждой бизнес-цели. Таким образом, мы получаем еще N матриц, где N - количество бизнес-целей.

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

4. Следующий этап состоит в определении для каждой матрицы такого показателя, как отношение согласованности (ОС), который отражает степень взаимосогласованности экспертных оценок. Полученные оценки считаются непротиворечивыми и адекватными, если ОС матрицы меньше 10%. По усмотрению автора исследования, пороговое значение может быть увеличено до 20%, однако, мы остановимся на общепринятом. Если ОС не входит в допустимые границы, оценки должны быть повторно пересмотрены экспертами. Чтобы рассчитать показатель ОС, необходимо предварительно вычислить индекс согласованности (ИС) и определить случайную согласованность (СС) матрицы. Значение СС зависит только от размерности матрицы и устанавливается по таблице, которая представлена в книге Т. Саати (таблица 2.1).

Таблица 2.1 Таблица соответствия размерности матрицы значению СС [10].

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

0,00

0,00

0,58

0,90

1,12

1,24

1,32

1,41

1,45

1,49

1,51

1,48

1,56

1,57

1,59

Индекс согласованности вычисляется по формуле: ИС = (лmax - N) / (N - 1), где лmax - максимальное собственное значение матрицы, N - ее размерность. лmax, в свою очередь, рассчитывается путем умножения сумм экспертных оценок по каждой цели на их локальные весовые коэффициенты и последующего сложения полученных произведений.

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

6. Финальным шагом приоритизации ИТ-целей является констатация обобщенной согласованности экспертных оценок (ООС). Показатель ООС рассчитывается путем деления общего показателя случайной согласованности (ОПСС), равного случайной согласованности матриц попарного сравнения ИТ-целей, на общий индекс согласования (ОИС). Значение ОИС равно сумме произведений ОС на локальные весовые коэффициенты каждой бизнес-цели. Чтобы результаты можно было признать достоверными, показатель ООС должен быть меньше 10-15%.

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

Рисунок 2.3 Матрица попарных сравнений бизнес-целей относительно главной стратегической цели.

Как видно из рисунка, после нормирования собственного вектора матрицы, оказалось, что наиболее значимой бизнес-целью является оптимизация функциональности бизнес-процессов. Стопроцентное достижение этой цели гарантирует 50% успеха в достижении главной стратегической цели. Второй по приоритетности бизнес-целью является операционная производительность персонала, однако, ее степень важности составляет всего 27%. Всего на 10% улучшение управления компанией зависит от достижения цели по оптимизации затрат бизнес-процессов. Самыми малозначимыми бизнес-целями оказались отдача от инвестиций и клиентоориентированная сервисная культура.

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

Таблица 2.2 Показатели согласованности экспертных суждений для бизнес-целей.

Случайная согласованность

1,12

Собственное значение (лmax)

5,346899187

Индекс согласования (ИС)

0,086724797

Отношение согласованности (ОС)

7,74%

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

Рисунок 2.4 Матрица попарных сравнений ИТ-целей относительно оптимизации бизнес-процессов.

В данном случае наиболее значимой целью оказалось обеспечение работы и поддержка бизнес-процессов, путем интеграции приложений и технологий в бизнес-процессы, её вес составил 38%. Приблизительно на одном уровне по значимости (около 23%) находятся такие цели, как предоставление ИТ-услуг в соответствии с бизнес требованиями и адекватное использование приложений, информации и технических решений. Малозначимыми оказались цели, связанные с прозрачностью ИТ-затрат и получение выгод от инвестиций в ИТ, что вполне рационально, так как функциональность бизнес-процессов слабо зависит от качества управления ИТ-инвестициями. Соответствие бизнес - и ИТ-стратегий также имеет не очень большой вес в этом распределении - около 10%.

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

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

Случайная согласованность

1,24

Собственное значение (лmax)

6,340252291

Индекс согласования (ИС)

0,068050458

Отношение согласованности (ОС)

5,49%

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

Рисунок 2.5 Определение глобальных приоритетов для ИТ-целей.

Предварительно убедимся, что общее отношение согласованности для полученных результатов удовлетворяет заданному диапазону (меньше 10-15%). Из таблицы 2.3 видно, что показатель ООС не превышает пороговое значение, из чего можно сделать вывод об адекватности полученных результатов.

Таблица 2.3 Показатели общей согласованности экспертных суждений.

Общий показатель случайной согласованности (ОПСС)

1,24

Общий индекс согласования (ОИС)

0,083301705

Общее отношение согласованности (ООС)

6,72%

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

? соответствие между ИТ - и бизнес-стратегиями;

? получение выгод от инвестиций с использованием ИТ и портфеля услуг;

? прозрачность ИТ-затрат, выгод и рисков.

Есть все основания на текущий момент оставить эти цели за пределами фокуса и сконцентрироваться на следующих трех:

? обеспечение работы и поддержка бизнес-процессов, путем интеграции приложений и технологий в бизнес-процессы;

? адекватное использование приложений, информации и технических решений;

? предоставление ИТ-услуг в соответствии с бизнес-требованиями.

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

2.2 Моделирование бизнес-процессов и проектирование информационной системы для управления партнерской программой

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

? процесс регистрации партнера;

? процесс обучения и сертификации партнера;

? процесс заключения договора с партнером;

? процесс публикации партнера на сайте;

? процесс оплаты клиентских лицензий;

? процесс передачи лидов из отдела продаж партнерам.

Также будет внедрен один новый процесс по управлению клиентскими аккаунтами в личном кабинете партнера.

В этом параграфе будут графически построены модели данных процессов AS-IS и TO-BE в нотации eEPC. Для моделирования бизнес-процессов будет использоваться программное обеспечение ARIS [11]. Также в рамках данного параграфа будут разработаны функциональные требования для облачной информационной системы управления партнерской программой.

Прежде чем приступить непосредственно к моделированию процессов и разработке требований, важно пояснить значения некоторых элементов, которые будут использоваться в блок-схемах. В таблице 2.4 представлены элементы, разработанные с учетом специфики ИТ-инфраструктуры компании amoCRM. Для автоматизации множества процессов управления партнерской программой будут необходима интеграция проектируемой системы с уже существующим программным обеспечением компании. В связи с этим в рамках ИТ-проекта по внедрению информационной системы будут также реализованы некоторые доработки или кастомные настройки в существующих системах, таких как ПО сайта amoCRM, CMS 1C Bitrix и CRM-система.

Таблица 2.4 Нотация eEPC.

Официальный сайт компании amoCRM сделан на базе CMS 1C Bitrix. В частности внутри него находятся форма для регистрации партнеров и список существующих партнеров с детальной веб-страницей по каждому из них.

CMS 1C Bitrix - система управления сайтом. Позволяет редактировать некоторый контент сайта amoCRM через административную панель. Например, с помощью неё осуществляется публикация партнера на сайте.

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

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

Центральная база данных, в которой хранится вся информация о клиентах, их аккаунтах, заказах и т.д.

Аккаунт CRM-системы, в котором ведется база партнеров amoCRM.

Аккаунт CRM-системы, в котором ведется база клиентов amoCRM.

Важно отметить, что информационная система будет являться обособленным модулем внутри основного сайта amoCRM и будет также разработана на базе CMS 1C Bitrix [12]. Все данные о партнерах, их договорах будут хранится в ЦБД вместе с клиентскими данными. Такое решение было принято в связи с тем, что проектируемая информационная система требует доступ на чтение и запись данных о заказах, оплатах и аккаунтах клиентов [13]. Определим конкретнее, какие из существующих в ЦБД сущностей будут представлять интерес в рамках данного ИТ-проекта:

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

? Сущность “Аккаунт”: аккаунт CRM-системы, в котором компания-клиент ведет свою клиентскую базу. В ней задаются тарифный план подписки, триальный и платный периоды и прочее.

? Сущность “Права пользователей" связывает сущность “Пользователь" с сущностью “Аккаунт”. В ней задаются права пользователя на чтение, редактирование, удаление данных аккаунта.

? Сущность “Заказ”. В ней задаются идентификатор аккаунта, опции, создатель, сумма и статус заказа.

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

2.2.1 Бизнес-процесс регистрации партнера

На рисунке 2.6 представлена модель процесса регистрации партнера “AS IS”, а на рисунке 2.7 модель “TO BE”. Из блок-схем видно, что в рамках ИТ-проекта по внедрению информационной системы должны произойти два изменения в процессе регистрации:

? ПО сайта amoCRM должно заносить данные партнера не только в базу партнеров в CRM, но и в ЦБД.

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

Рисунок 2.6 Модель процесса регистрации партнера AS IS.

Рисунок 2.7 Модель процесса регистрации партнера TO BE.

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

? ФИО (обязательное);

? телефон (обязательное);

? email (обязательное);

? название компании (опциональное).

В таблице 2.5 представлены функциональные требования к программному обеспечению сайта amoCRM [14].

Таблица 2.4 Функциональные требования для автоматизации процесса регистрации партнера.

Код

Функция процесса

Описание требования

ФТ 1.1

Регистрация партнера

При заполнении формы регистрации партнера ПО сайта amoCRM должно проверять существует ли в ЦБД сущность “Пользователь" с указанным email-адресом.

ФТ 1.2

Регистрация партнера

Если сущность “Пользователь" с указанным email-адресом есть в ЦБД, то ПО сайта amoCRM должно открыть данному пользователя доступ в личный кабинет партнера. Пользователь должен увидеть сообщение: “Мы подключили вас к партнерской программе amoCRM. Для входа в Личный кабинет партнера пройдите по ссылке XXX и авторизуйтесь под своими данными”.

ФТ 1.3

Регистрация партнера

Если сущности “Пользователь" с указанным email-адресом нет в ЦБД, то ПО сайта amoCRM должно создавать нового пользователя с доступом в личный кабинет партнера и новый аккаунт в CRM-системе, связанный с этим пользователем.

ФТ 1.4

Регистрация партнера

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

2.2.2 Бизнес-процесс обучения и сертификации партнера

На рисунке 2.8 изображена модель процесса обучения партнера “AS IS”, а на рисунке 2.9 модель “TO BE”. В результате автоматизации данного процесса:

? Менеджер по работе с партнерами будет полностью исключен их цепочки процесса.

? Появится возможность мониторинга активности партнеров в обучении.

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

Рисунок 2.8 Модель процесса обучения и сертификации партнера AS IS.

Рисунок 2.9 Модель процесса обучения и сертификации партнера TO BE.

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

Таблица 2.6 Функциональные требования для автоматизации процесса обучения и сертификации партнера.

Код

Функция процесса

Описание требования

ФТ 2.1

Обучение партнера

Система должна иметь раздел “Обучение”, включающий обучающий видео-, аудио-, графический и текстовый контент, а также ссылки на сторонние ресурсы и скачивание документов.

ФТ 2.2

Смена статуса карточки партнера в CRM на “Изучает продукт”

Если партнер переходит по ссылке в разделе “Обучение" на любой документ, система должна по API обращаться к карточке этого партнера в CRM и изменять ей статус на “Изучает продукт”.

ФТ 2.3

Смена статуса карточки партнера в CRM на “Изучает продукт”

Если партнер посмотрел любой обучающий ролик на 50% и более, система должна по API обращаться к карточке этого партнера в CRM и изменять ей статус на “Изучает продукт”.

ФТ 2.4

Прохождение онлайн-тестирования

Система должна иметь раздел “Аттестация”, в котором партнер должен иметь возможность пройти тестирование.

ФТ 2.5

Прохождение онлайн-тестирования

Если партнер проходит тестирование с результатом ниже 100 баллов, система должна выдавать уведомление с результатом теста и кнопкой “Пройти еще раз”.

ФТ 2.6

Прохождение онлайн-тестирования

Если партнер проходит тестирование с результатом 100 или более баллов, система должна выдавать уведомление об успешном прохождении тестирования и ссылкой на раздел “Сертификат”.

ФТ 2.7

Прохождение онлайн-тестирования

В разделе “Аттестация" должен отображаться лучший результат партнера, если он уже проходил тест.

ФТ 2.8

Смена статуса карточки партнера в CRM на “Попытки пройти аттестацию”

Если партнер проходит тестирование с результатом ниже 100 баллов, система должна по API обращаться к карточке этого партнера в CRM, изменять ей статус на “Попытки пройти аттестацию” и добавлять комментарий с датой и количеством набранных баллов.

ФТ 2.9

Сертификация партнера

Если партнер проходит тестирование с результатом 100 или более баллов, система должна по API обращаться к карточке этого партнера в CRM, изменять ей статус на “Получил сертификат” и добавлять комментарий с датой и количеством набранных баллов.

ФТ 2.10

Сертификация партнера

Если лучший результат партнера 100 или более баллов, в системе должен открываться новый раздел “Сертификат”.

ФТ 2.11

Сертификация партнера

В разделе сертификат должно отображаться превью сертификата и ссылка на скачивание сертификата в формате png.

2.2.3 Бизнес-процесс заключения договора с партнером

Данный процесс условно можно разделить на два этапа:

? составление договора (занесение реквизитов партнера в шаблон договора);

? подпись и обмен оригиналами.

В рамках ИТ-проекта нас будет интересовать только первый этап процесса, так как второй этап автоматизации не подвергается. Кроме того, в ходе обсуждения процессов с представителями компании было принято решение изменить форму юридических взаимоотношений с партнерами. В новой концепции отношения будут регулироваться универсальным лицензионным соглашением, опубликованном на главном сайте amoCRM. Данное изменение говорит о том, что индивидуальные договоры с партнерами больше не нужны компании с юридической точки зрения. Однако, как показывает практика, клиенты часто запрашивают у партнеров подобные договоры перед оплатой в качестве гарантии безопасной сделки. В связи с этим, было решено реализовать в системе функционал, который позволит партнерам создавать и скачивать типовые договора со сканом печати и подписи компании amoCRM. Также важно отметить, что функционал будет доступен партнеру только после сертификации, что нацелено на снижения риска оказания услуг некомпетентными лицами от имени бренда компании. Что касается обмена оригиналами договоров, он будет происходить только в исключительных случаях по запросу партнера.

На рисунке 2.9 изображена модель процесса создания договора “AS IS”, на рисунке 2.10 модель “TO BE”. В результате автоматизации данного этапа процесса:

? Менеджер по работе с партнерами будет полностью исключен их цепочки процесса.

? Реквизиты партнера и его скидка будут хранится в ЦБД.

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

Рисунок 2.9 Модель процесса создания договора с партнером партнера AS IS.

Рисунок 2.10. Модель процесса создания договора с партнером партнера TO BE.

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

Таблица 2.7 Функциональные требования для автоматизации процесса создания договора с партнером.

Код

Функция процесса

Описание требования

ФТ 3.1

Занесение реквизитов в систему

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

ФТ 3.2

Занесение реквизитов в систему

В разделе “Договор” партнер должен иметь возможность создать новый договор.

ФТ 3.3

Занесение реквизитов в систему

Форма для отправки реквизитов должна содержать следующие поля:

Наименование юридического лица или ИП (обязательное)

ФИО генерального директора (обязательное)

ИНН (обязательное)

КПП (обязательное для юридических лиц)

Юридический адрес (обязательное)

Фактический адрес (опционально)

ФТ 3.4

Занесение реквизитов в систему

В полях “Наименование юридического лица или ИП” и “ИНН” должны всплывать автоподсказки (интеграция с сервисом DaData). При выборе одного и вариантов все реквизиты автоматически все поля формы, кроме фактическ

ФТ 3.5

Занесение реквизитов в систему

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

ФТ 3.6

Занесение реквизитов в систему

При попытке партнером отправить форму система должна проверять, что поля “ИНН” и “КПП”, если указано, имеют необходимое количество символов и состоят только из цифр.

ФТ 3.7

Занесение реквизитов в систему

При попытке партнером отправить форму система должна проверять корректность ИНН, вычисляя контрольные числа.

ФТ 3.8

Занесение реквизитов в систему

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

ФТ 3.9

Занесение реквизитов в систему

Если проверка прошла успешно, данные должны записаться в ЦБД (создается новая сущность “Договор”), в карточку партнера в CRM должен добавиться комментарий с реквизитами партнера.

ФТ 3.10

Занесение реквизитов в систему

В разделе “Договор” в личном кабинете партнера должны отображаться все договоры партнера в виде таблицы из трех столбцов:

номер договора;

наименование юридического лица или ИП;

ссылка на скачивание договора ва pdf.

ФТ 3.11

Занесение реквизитов в систему

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

ФТ 3.12

Занесение реквизитов в систему

В детальная карточке договора должны отображаться все указанные реквизиты и ссылка для скачивания договора в pdf.

2.2.4 Бизнес-процесс публикации партнера на сайте

На рисунке 2.11 изображена модель процесса публикации партнера на сайте “AS IS”, а на рисунке 2.12 модель “TO BE”. В результате автоматизации данного этапа процесса:

? Менеджер по работе с партнерами будет освобожден от отправки партнерам шаблонных писем с запросом данных для публикации.

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

? Процедура публикации партнера на сайте для менеджера будет сведена к нажатию одной кнопки.

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

? Заполненные партнером данные будут храниться в ЦБД.

Рисунок 2.11. Модель процесса публикации партнера на сайте AS IS.

Рисунок 2.12. Модель процесса публикации партнера на сайте TO BE.

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

Таблица 2.8 Функциональные требования для автоматизации процесса публикации партнера на сайте.

Код

Функция процесса

Описание требования

ФТ 4.1

Заявка на публикацию на сайте

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

ФТ 4.2

Заявка на публикацию на сайте

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

ФТ 4.3

Заявка на публикацию на сайте

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

сайт (обязательное)

публичный e-mail (обязательное)

публичный телефон (обязательное)

город (список, обязательное)

логотип (обязательное)

краткое описание деятельности компании (обязательное)

география деятельности (список, обязательное)

специализации (мультисписок, обязательное)

ФТ 4.4

Заявка на публикацию на сайте

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

сайт и e-mail должны соответствовать стандартным маскам

телефон должен состоять только из цифр

логотип должен быть в формате png, jpg, bmp или giff, иметь ширину 131 см и высоту 102 см

краткое описание деятельности компании должно содержать от 100 до 200 символов

ФТ 4.5

Заявка на публикацию на сайте

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

ФТ 4.6

Заявка на публикацию на сайте

Если проверка прошла успешно, данные должны записаться в ЦБД и в карточку партнера в CRM в соответствующие поля (кроме логотипа). В карточке партнера также должен измениться статус на “Заявка на размещение на сайте”.

ФТ 4.7

Заявка на публикацию на сайте

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

ФТ 4.8

Модерация заявки партнера на публикацию

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

ФТ 4.9

Модерация заявки партнера на публикацию

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

идентификатор партнера

ФИО партнера

статус заявки (на модерации / отклонена / принята)

ФТ 4.10

Модерация заявки партнера на публикацию

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

ФТ 4.11

Модерация заявки партнера на публикацию

В детальная карточке заявки на публикацию должны отображаться все указанные данные партнера, кнопка “Отклонить” и кнопка “Опубликовать”.

ФТ 4.12

Возврат заявки партнеру

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

ФТ 4.13

Возврат заявки партнеру

При нажатии кнопки “Отправить отказ" партнеру должно уходить письмо с причиной отказа в публикации, в ЦБД должна записываться информация о статусе заявки на публикацию.

ФТ 4.14

Заявка на публикацию на сайте

Если заявка на публикацию была возвращена партнеру, в Личном кабинете партнера в разделе “Заявка на размещение на сайте" снова должна появиться возможность редактирования данных и отправки заявки на модерацию.

2.2.5 Бизнес-процесс оплаты клиентских лицензий партнером

Данный процесс AS IS условно можно разбить на два этапа:

1) создание заказа и корректировка суммы;

2) перенос опций заказа с аккаунта партнера на аккаунт клиента.

Так как процесс достаточно сложный, опишем его двумя моделями в соответствии с выделенными этапами (Рисунки 2.13 и 2.14). На рисунке 2.15 изображена модель процесса “TO BE”. Как видно из моделей, процесс будет значительно упрощен за счет внедрения информационной системы для управления партнерской программой. Изменения главным образом будут заключаться в следующем:

? Сотрудник технической поддержки будет полностью исключен из цепочки процесса.

? Сотруднику технической поддержки больше не будет нужен доступ к базу партнеров в CRM.

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

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

? Партнер сможет видеть в своем личном кабинете данные по всем когда-либо созданным им заказам.

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

Рисунок 2.13. Модель подпроцесса оплаты клиентских лицензий партнером AS IS (создание заказа и корректировка суммы).

Рисунок 2.14. Модель подпроцесса оплаты клиентских лицензий партнером AS IS (перенос опций заказа с аккаунта партнера на аккаунт клиента).

Рисунок 2.15. Модель процесса оплаты клиентских лицензий партнером TO BE.

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

? Если выбран способ оплаты “Электронная оплата”, то статус должен меняться автоматически по событию успешной оплаты, поступившему от сервиса Яндекс Касса.

? Если выбран способ оплаты “Счет" или “Квитанция”, то статус меняется вручную секретарем. На ежедневной основе из 1C бухгалтерии выгружается выписка оплат, поступивших на счет организации. Данная выписка передается секретарю, который через CMS 1C Bitrix отмечает оплаты (меняет статусы заказов на “Оплачен”).

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

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

Код

Функция процесса

Описание требования

ФТ 5.1

Оформление заказа

Раздел “Магазин” должен быть отображаться в личном кабинете партнера только в том случае, если он сертифицирован.

ФТ 5.2

Оформление заказа

В разделе “Магазин” партнер должен иметь возможность создать новый заказ.

ФТ 5.3

Оформление заказа

Форма создания заказа должна содержать кнопку “Оформить заказ" и следующие обязательные для заполнения поля:

идентификатор аккаунта клиента;

тарифный план (список);

период оплаты (список);

способ оплаты (Счет / Квитанция / Электронная оплата).

ФТ 5.4

Оформление заказа

Способ оплаты “Счет" должен быть доступен для выбора только партнерам, у которых есть хотя бы один договор.

ФТ 5.5

Оформление заказа

Если партнер выбирает способ оплаты “Счет”, на форме должно появляться обязательное для заполнения поле “Договор” со списком всех договоров партнера.

ФТ 5.6

Оформление заказа

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

ФТ 5.7

Оформление заказа

При отправке формы создания заказа информационная система должна проверять, что аккаунт с указанным идентификатором существует в ЦБД.

ФТ 5.8

Оформление заказа

Если при отправке формы создания заказа проверка данных не прошла успешно, партнер должен увидеть сообщение об ошибке.

ФТ 5.9

Оформление заказа

Если проверка данных прошла успешно:

Данные, включая данные выбранного договора (только при выборе оплаты по счету), должны записаться в ЦБД (создается сущность “Заказ”).

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

ФТ 5.10

Оформление заказа

Если выбран способ оплаты ”Электронная оплата”, при нажатии на кнопку “Оформить заказ" должен происходить редирект на страницу оплаты через Яндекс Кассу (интеграция с сервисом).

ФТ 5.11

Оформление заказа

Если выбран способ оплаты ”Счет" или “Квитанция”, при нажатии на кнопку “Оформить заказ" должен происходить редирект на детальную страницу созданного заказа.

ФТ 5.12

Оплата заказа

При получении триггера success от сервиса Яндекс Касса статус заказа должен меняться на “Оплачен”.

ФТ 5.13

-

В разделе “Заказы" должна отображаться таблица со всеми заказами партнера, состоящая из следующих столбцов:

номер заказа;

идентификатор аккаунта;

сумма заказа;

статус (в ожидании / оплачено);

счет / квитанция;

УПД.

ФТ 5.14

-

У заказов со способом оплаты “Счет" в столбце “Счет / квитанция" должна быть ссылка на скачивание счета.

ФТ 5.15

-

У заказов со способом оплаты “Квитанция” в столбце “Счет / квитанция" должна быть ссылка на скачивание квитанции.

ФТ 5.16

-

У оплаченных заказов со способом оплаты “Счет" в столбце “УПД” должна быть ссылка на скачивание УПД (закрывающий документ).

ФТ 5.17

-

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

ФТ 5.18

-

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

номер заказа;

идентификатор аккаунта;

сумма заказа;

способ оплаты;

тарифный план;

период оплаты;

статус заказа (в ожидании / оплачено);

ФТ 5.19

-

В детальной карточке заказа со способом оплаты “Счет" дополнительно должны отображаться:

ссылка на скачивание счета;

ссылка на скачивание УПД (если заказ оплачен);

наименование юридического лица;

ИНН;

КПП;

юридический адрес.

ФТ 5.20

-

В детальной карточке заказа со способом оплаты “Квитанция” дополнительно должна отображаться ссылка на скачивание квитанции.

ФТ 5.21

-

В детальной карточке заказа со способом оплаты “Электронная оплата” дополнительно должна отображаться кнопка “Оплатить заказ”, при клике на которую должен происходить редирект на страницу оплаты сервиса Яндекс Касса.

2.2.6 Бизнес-процесс передачи лидов из отдела продаж партнерам

На рисунке 2.16 изображена модель процесса передачи лидов из отдела продаж партнерам “AS IS”, а на рисунке 2.17 модель “TO BE”. В результате автоматизации данного процесса:

? Менеджер по работе с партнерами будет полностью исключен из цепочки процесса.

? Клиентские заявки будут хранится в ЦБД, что позволит при необходимости использовать подробную статистику.

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

? За счет введения суточного лимита на принятие заявок партнером, распределение заявок между партнерами станет более равномерным.

Отдельно важно пояснить, как будет изменена процедура передачи клиентской заявки в отдел по работе с партнерами. В модели процесса AS IS менеджер по работе с клиентами, получив соответствующий запрос от клиента, использует функционал CRM-системы по отправке писем, чтобы направить запрос в отдел по работе с партнерами. В частности он заполняет шаблон передачи клиентской заявки контактными данными клиента из его карточки в CRM и деталями запроса на партнерские услуги. После отправки письмо автоматически подгружается в историю карточки клиента. В модели процесса TO BE данная процедура выполняется менеджером с помощью специального виджета. Виджет должен позволять создать новую заявку и автоматически подгружать в форму создания контактные данные клиента из карточки. После отправки формы данные об отправленной заявке должны прикрепиться к карточке клиента в виде системного (не редактируемого) комментария.

Рисунок 2.16. Модель процесса передачи лидов из отдела продаж партнерам AS IS.

Рисунок 2.17. Модель процесса передачи лидов из отдела продаж партнерам TO BE.

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

? Менеджеру по работе с клиентами эффективнее по времени открыть форму прямо из аккаунта CRM, чем искать специальную ссылку, открывать ее в браузере.

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

Таблица 2.10. Функциональные требования для автоматизации процесса передачи лидов из отдела продаж партнерам.

Код

Функция процесса

Описание требования

ФТ 6.1

Передача клиентской заявки в отдел по работе с партнерами

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

ФТ 6.2

Передача клиентской заявки в отдел по работе с партнерами

На форме создания заявки должны быть кнопка “Отправить заявку” и два блока с полями для заполнения: “Данные клиента" и “Бриф”. Первый блок должен содержать следующие обязательные для заполнения поля:

идентификатор аккаунта клиента;

ФИО клиента

email клиента;

телефон клиента;

название компании клиента;

Второй блок должен содержать следующие обязательные для заполнения поля:

специализация;

ориентировочный бюджет;

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

город;

необходимые компетенции (мультисписок);

комментарий (опционально).

ФТ 6.3

Передача клиентской заявки в отдел по работе с партнерами

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

идентификатор аккаунта клиента состоит только из цифр;

email клиента соответствует стандартной маске;

телефон клиента состоит только из цифр;

ориентировочный бюджет состоит только из цифр.

ФТ 6.4

Передача клиентской заявки в отдел по работе с партнерами

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

ФТ 6.5

Передача клиентской заявки в отдел по работе с партнерами

Если проверка данных прошла успешно:

Данные должны записаться в ЦБД (создается сущность “Заявка”).

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

ФТ 6.6

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

Раздел “Входящие заявки” должен отображаться в личном кабинете партнера только в том случае, если он опубликован на главном сайте amoCRM.

ФТ 6.7

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

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

номер заявки;

специализация;

бюджет;

город;

тип заявки;

дата создания;

статус заявки (новая / принята);

идентификатор аккаунта клиента (только для принятых).

ФТ 6.8

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

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

ФТ 6.9

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

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

номер заявки;

статус заявки;

дата и время создания;

специализация;

бюджет;

тип заявки;

город;

необходимые компетенции;

комментарий.

ФТ 6.10

Партнер отправляет запрос на принятие заявки

При клике на кнопку “Принять” система должна проверять соблюдение суточного лимита по принятию заявок одним партнером (не более двух).

ФТ 6.11

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

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

ФТ 6.12

Перевод заявки в статус "Принята" партнером

Если лимит по принятым заявкам не исчерпан, то система должна изменить статус заявки в ЦБД.

ФТ 6.13

-

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

идентификатор аккаунта клиента;

ФИО клиента

email клиента;

телефон клиента;

название компании клиента;

номер заявки;

статус заявки;

дата и время создания;

специализация;

бюджет;

тип заявки;

город;

необходимые компетенции;

комментарий.

ФТ 6.14

-

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

2.2.7 Бизнес-процесс по управлению клиентскими аккаунтами

Данный процесс ранее не существовал, поэтому модели AS IS у него нет. Иными словами, партнеры не имели возможности самостоятельно создавать аккаунты для клиентов и управлять ими. Ключевым подпроцессом управления аккаунтами является их создание. На рисунке 2.18 представлена модель этого подпроцесса. Как видно из модели, создание будет инициироваться партнером и происходить полностью в автоматическом режиме на базе информационной системы. Также важно отметить, что клиентские аккаунты, созданные партнером, будут связаны с ним по идентификатору в ЦБД. Это даст руководителям возможность при необходимости отделить клиентов, которых партнер привел самостоятельно, от клиентов, которые были переданы ему отделом продаж. В перспективе руководство компании amoCRM планирует внедрить разные мотивационные схемы для этих двух типов продаж.

Рисунок 2.18. Модель подпроцесса создания аккаунта для партнера.

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

Рисунок 2.19. Модель подпроцесса продления триального периода для клиентских аккаунтов.

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

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

Таблица 2.11. Функциональные требования для автоматизации процесса передачи лидов из отдела продаж партнерам.

Код

Функция процесса

Описание требования

ФТ 7.1

-

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

ФТ 7.2

Создание аккаунта для клиента

В разделе “Аккаунты клиентов” партнер должен иметь возможность создать новый аккаунт.

ФТ 7.3

Создание аккаунта для клиента

Форма создания аккаунта для клиента должна содержать кнопку “Создать аккаунт" и следующие обязательные для заполнения поля:

email клиента;

ФИО клиента;

телефон.

ФТ 7.4

Создание аккаунта для клиента

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

email клиента должен соответствовать стандартной маске;

телефон клиента должен состоять только из цифр.

ФТ 7.5

Создание аккаунта для клиента

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

ФТ 7.6

Создание аккаунта для клиента

Если проверка данных прошла успешно:

Данные должны записаться в ЦБД (создаются сущности таблиц “Аккаунты”, “Пользователи" и “Права пользователей”).

На указанный email клиента должно отправиться приветственное письмо с данными для авторизации в системе.

ФТ 7.7

-

В разделе “Аккаунты" клиентов должна отображаться таблица со всеми созданными партнером аккаунтами, состоящая из следующих столбцов:

идентификатор аккаунта;

субдомен аккаунта;

статус подписки (триальный период / платный период / приостановлен);

email клиента, указанный при создании аккаунта.

ФТ 7.8

-

Идентификатор аккаунта в списке должен являться ссылочным элементом, который ведет на детальную карточку аккаунта.

ФТ 7.9

-

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

идентификатор аккаунта;

субдомен аккаунта;

статус подписки (триальный период / платный период / приостановлен);

email клиента, указанный при создании аккаунта;

часовой пояс;

количество сделок в аккаунте;

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

количество форм.

ФТ 7.10

-

В детальной карточке аккаунта со статусами подписки “Триальный период” и “Приостановлен” дополнительно должен отображаться “Триальный период”.

ФТ 7.11

-

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

тарифный план;

платный период;

автоплатеж (да / нет).

ФТ 7.12

Продление триального периода для аккаунта клиента

В детальной карточке аккаунта со статусами подписки “Триальный период” и “Приостановлен” справа от информативного поля “Триальный период” должна быть кнопка “Продлить”.

ФТ 7.13

Продление триального периода для аккаунта клиента

При клике на кнопку “Продлить" в ЦБД у соответствующего аккаунта должно изменяться дата в поле “Дата окончания триального периода" на дату, равную текущей плюс 14 дней. Партнер должен получать уведомление об успешном продлении периода.

Итак, в данном параграфе в нотации eEPC были построены “AS IS” и “TO BE” модели бизнес-процессов, отобранных под автоматизацию в рамках ИТ-проекта по внедрению облачной информационной системы для управления партнерской программой. Было приведено описание ожидаемых результатов от оптимизации каждого из процессов. На основе моделей “TO BE” были разработаны функциональные требования к модулям проектируемой информационной системы. Таким образом, итоги проектирования заключаются в разработке требований для 7 модулей системы, каждый из которых будет поддерживать определенный бизнес-процесс.

2.3 Обоснование ИТ-проекта по внедрению информационной системы для управления партнерской программой

В первом параграфе были проранжированы ИТ-цели компании amoCRM по своей значимости для достижения главной стратегической цели и выделены три наиболее приоритетные из них:

? обеспечение работы и поддержка бизнес-процессов, путем интеграции приложений и технологий в бизнес-процессы;

? адекватное использование приложений, информации и технических решений;

? предоставление ИТ-услуг в соответствии с бизнес-требованиями.

Во втором параграфе были формализованно описаны 7 бизнес-процессов управления партнерской программой компании amoCRM “AS IS” и “TO BE”, а также перечислены эффекты, ожидаемые от внедрения информационной системы, по каждому из процессов. Опираясь на эти результаты исследования, попробуем выяснить, насколько ожидаемые эффекты от внедрения системы соответствуют ключевым ИТ-целям компании.

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

? процесс обучения и сертификации партнера;

? процесс создания договора;

? процесс оплаты клиентских лицензий партнером;

? процесс передачи лидов из отдела продаж партнерам.

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

Страница:


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

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2025, ООО «Олбест» Все наилучшее для вас