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

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

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

Контрольная работа

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

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

На основе формальной модели, разработанной за прошлый год на формальном языке система была полностью проанализирована на предмет ошибок в статике и динамике. В данном отчете описывается подготовка к реализации облачных сервисов на базе полученной формальной модели. Отчет состоит из двух основных частей: 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 является отдельным сервисом, мы изначально заложили слабые связи (расцепленные сервисы вокруг ядра, работающие друг с другом за счет обмена сообщениями через шину), чтобы решение масштабировалось за счет интерфейсов быстро и гибко.

Поиск по “холодной” базе контактов

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

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

“Воронка продаж” за все время по проектам

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

Размещено на Allbest.ru