Разработка модели информационной системы для предприятия путем интегрирования вычислительных модулей в бизнес-модель «Программное обеспечение как услуга»

АО «Казахстанско-Британский технический университет»

По подприоритету: Информационные технологии.

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

На основе формальной модели, разработанной за прошлый год на формальном языке система была полностью проанализирована на предмет ошибок в статике и динамике. В данном отчете описывается подготовка к реализации облачных сервисов на базе полученной формальной модели. Отчет состоит из двух основных частей: 1) описание архитектуры программного обеспечения платформы; описание требований к аппаратно/сетевому комплексу, требования, дизайн и логика приложения на основе собранных требований; 2) детали реализации облачной платформы и в частности облачного сервиса CRM (система управления взаимоотношениями с клиентами, предназначенной для автоматизации стратегий взаимодействия с заказчиками). За период разработки получены следующие результаты: 1) разработано ядро облачной платформы в соответствии с метамоделью; 2) разработана архитектура облачной платформы, проработан дизайн и логика приложения CRM, разработана альфа-версия сервиса; 3) протестирован и разработан прототип приложения CRM. Научные результаты проделанной работы за 2015 г. приняты для публикации с докладом на конференции «5th International Symposium on Business Modeling and Software Design» которая пройдет в Милане (Италия) в период 6 — 8 июля 2015 г. кэш веб интерфейс репликация Ключевые моменты по разработки облачной платформы: 1) использование передовых технологий, протоколов и алгоритмов 2) разработке предшествует детальный анализ, дизайн и метамоделирование системы 3) новейшие методологии и инструменты общения.

В нашей работе использовались такие основные инструменты для разработки, как система контроля версий кода — git. Git поддерживает быстрое разделение и слияние версий кода, включает инструменты для визуализации и навигации для нелинейной истории разработки. Удаленный доступ к репозиторию обеспечивает сервис Bitbucket (bitbucket.org).

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

Основной стэк используемых технологий для реализации облачной платформы представлен в Таблице 1. Разработка логики приложения ведется в среде Django на языке программирования Python. Django был выбрано по нескольким причинам, некоторые из которых перечислены в Таблице 1. Помимо этого на Django позволяет очень удобно и быстро строить тестовую среду (юнит, функциональное тестирование и т. д.), масштабируемость логики на милионы пользователей. Postgres SQL и Memcached вместе организуют полноценное хранилище. Postgres содержит все бизнес сущности системы, а также реализует текстовый и индексированный поиск. Memcached хранит информацию для быстрого доступа: сессия пользователя, счетчики, отчетность за период в прошлом (read-in-the-past). RabbitMQ — шина и стриминг с нелинейной маршрутизацией данных. Архитектура приложения описана на рисунке. Приложение получает запрос от клиента, далее маршрут запрос передается во фронт-уровень — API. API в зависимости от запроса передает данные в соответствующие модели. В зависимости от логики запроса идет запись/запрос в базу данных, инвалидация кэша. В завершении данного процесса, данные публикуются в шину для оффлайн обработки и результат передается обратно клиенту.

Таблица 1. Стэк технологий.

Говоря о топологии сети, важно выделить несколько компонентов системы: 1) репликация базы данных, 2) горизонтальное масштабирование кэша, 3) веб-приложение. Примерная топология сети описана на рисунке. Топология репликации соответствует формату Master-Slave. Данная схема обеспечивает отказоустойчивость базы данных и соответственно приложений. Кэш представляет собой распределенную хэш таблицу и имеет топологию «кольца». Каждый узел знает о состоянии своего следующего и предыдущего соседа-узла. Это также сделано с целью обеспечения отказоустойчивости системы. Последнее веб-приложение проксируемое сервером Nginx соответствует топологии системы, где Nginx является посредником между приложением и клиентом.

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

Сценарий № 1.

Привет. Меня зовут Groot. Я работаю в фармацевтической компании менеджером продаж. Я начинаю работу, просматривая список «холодных» клиентов, среди которых я ищу новых потенциальных клиентов. Кто-то из списка уже обозначен как контакт с высокой вероятностью продажи, кто-то — с низкой, а кто-то вообще не обозначен никак. Я нахожу пару клиентов, которые выглядят наиболее привлекательными и начинаю обзвон. Вот и первый контакт — Jaime Lannister. Он коммерческий директор аптек «Витаминка». Я вижу, что он готов платить за хороший продукт и отличный сервис. Однако — это субъективная информация. Я открываю клиента и вижу его досье:

• ? ФИО, название организации
• ? Контактные данные и email
• ? примерный доход
• ? Статус — «холодный» означает, что я раннее с ним не контактировала.

Позвонив ему, я предложила ему новый продукт P3. Так началось первое взаимодействие с контактом. Ему понравилось предложение и он попросил выслать ему условия и сроки. Я пометила это взаимодействие как нейтрально-позитивное и записала, что клиент заинтересовался. Теперь клиент перешел в статус «лид». Теперь в моей «воронки продаж», я вижу Jaime среди лидов.

Сценарий № 2.

Мой супервайзер по имени Rocket просматривает ежедневно статистику и отчетность работы его отдела. Он постоянно смотрит на обновленную воронку продаж отдельного менеджера (например, меня), так и всего отдела в целом. Он часто поощряет и советует сотрудникам, и в редких случаях критикует работу менеджера. Например: «Отличная работа, Groot! Не забудь выслать клиенту КП.» или «После холодного звонка, отпишитесь контакту по емайлу!».

Сценарий № 3.

Я решила отправить Jaime условия внедрения и сроки, которые он запрашивал раннее. Я зашла в свой почтовый ящик, ввела его адрес и прикрепила соответствующие документы. Процесс завершился нажатием кнопки отправить. Таким образом я начала новое взаимодействие с Jaime, однако реактивного ответа я не получила. Чтобы не забыть вернуться к клиенту, я пометила у себя в календаре «отправила по почте условия. Вернусь через пару дней» и продолжила похожую работу с холодной базой.

Сценарий № 4.

Тем временем совет директоров, управляющий и финансовый директоры, супервайзер отдела продаж разработали план доходов на 5 млн долларов. План на каждый региональный офис поделен примерно поравну. Нам достался план в 300 тыс долларов на 2015;2016 год. Мы успели выполнить его наполовину судя по последнему отчету нашего супервайзера. Таким образом у нас 8 месяцев и каждый планирует свои цели и показатели. Согласно плану, я должна закрывать минимум 5 сделок в неделю. Хммм… неплохо. Теперь каждый день каждый менеджер работает в соотвествие с целями. Все начинают с холодной базы, далее контакт превращается в лида и наконец, он покупает наш продукт. Интересно что последние 2 моих показателя за неделю зашкаливают. В среднем, я закрывала сделку на 40.5 часов, средняя длина «холодного» звонка — 3.5 минут. Отлично!

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

Согласно данным сценариям мы также разработали структуру базы данных представленной на рисунке. Стуктура (схема) состоит из трех взамодействующих друг с другом баз данных: 1) Processing_DB — это база для хранения данных о клиентах, биллинге и историю подключения/отключения сервисов на платформе 2) VCard_DB — это база, хранит все профили пользователей соответствующие стандарту VCard. Бизнес модель позволяет хранить VCard в нашей базе, импортить данные из стандарта VCard (например, контакты Google, IContacts) и экспортировать данные из базы в VCard. Например, профиль всех контактов CRM хранится как отдельных VCard в базе. 3) CRM_DB — это база для хранения всех процессов CRM: взаимодействия, циклы продаж, контакты, тэги. Помимо этого — логи, упоминания и отчетность. На данный момент база немного сложнее, однако вся ключевая структура соответствует рисунку. Так как CRM является отдельным сервисом, мы изначально заложили слабые связи (расцепленные сервисы вокруг ядра, работающие друг с другом за счет обмена сообщениями через шину), чтобы решение масштабировалось за счет интерфейсов быстро и гибко.

Поиск по «холодной» базе контактов.

Профиль контакта и первое взаимодействие с ним.

Планирование и визуализация планов на календаре.

«Воронка продаж» за все время по проектам.

Схема базы данных облачной платформы.