Главная особенность продаж по телефону состоит в том, что вы не видите собеседника, а следовательно, ваша задача как менеджера по продажам значительно усложняется. Нет врожденных продавцов. Есть люди, которые умеют правильно использовать технологии продаж. Продажи – это приобретенный навык. На сегодняшний день телефонные продажи весьма распространены, а менеджеры, владеющие этим искусством, ценятся на вес золота. Чтобы научиться успешно продавать себя или свой товар, необходимо встраивать продажи в свое общение с внешним миром. Из этой книги вы узнаете о ПЯТИ ОСНОВНЫХ УСЛОВИЯХ, при которых осуществляется телефонная продажа; о ТРЕХ ГЛАВНЫХ ПРАВИЛАХ в телефонных продажах; о ДЕВЯТИ ПРИЕМАХ обработки возражений. Вы получите полную и готовую к применению систему продаж по телефону и скайпу, с помощью которой сможете продавать любые товары или услуги на холодную аудиторию (тем, кто не знает вас и то, что вы продаете, с вами незнакомы), а также программу продаж личного обучения, коучинга или консалтинга, полностью закроете для себя тему дополнительного заработка и перестанете нуждаться в любой дополнительной информации (книги, тренинги, курсы) касательно продаж по телефону и скайпу. В этой книге есть все самое нужное и важное. |
Данную книгу можно назвать практической энциклопедией. В ней дан максимальный охват проблематики обеспечения информационной безопасности, начиная с современных подходов, обзора нормативного обеспечения в мире и в России и заканчивая рассмотрением конкретных направлений обеспечения информационной безопасности (обеспечение ИБ периметра, противодействие атакам, мониторинг ИБ, виртуальные частные сети и многие другие), конкретных аппаратно-программных решений в данной области. Книга будет полезна бизнес-руководителям компаний и тем, в чью компетенцию входит решение технических вопросов обеспечения информационной безопасности. Все права защищены. Никакая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, а также запись в память ЭВМ для частного или публичного использования, без письменного разрешения владельца авторских прав. По вопросу организации доступа к электронной библиотеке издательства обращайтесь по адресу mailto:%[email protected] [email protected] . |
Весь проект разделяется на 4 фазы: анализ, глобальное проектирование (проектирование архитектуры системы), детальное проектирование и реализация (программирование).
На фазе анализа строится модель среды (Environmental Model). Построение модели среды включает:
Назначение ИС определяет соглашение между проектировщиками и заказчиками относительно назначения будущей ИС, общее описание ИС для самих проектировщиков и границы ИС. Назначение фиксируется как текстовый комментарий в "нулевом" процессе контекстной диаграммы.
Например, в данном случае назначение ИС формулируется следующим образом: ведение базы данных о членах библиотеки, фильмах, аренде и поставщиках. При этом руководство библиотеки должно иметь возможность получать различные виды отчетов для выполнения своих задач.
Перед построением контекстной DFD необходимо проанализировать внешние события (внешние объекты), оказывающие влияние на функционирование библиотеки. Эти объекты взаимодействуют с ИС путем информационного обмена с ней.
Из описания предметной области следует, что в процессе работы библиотеки участвуют следующие группы людей: клиенты, поставщики и руководство. Эти группы являются внешними объектами. Они не только взаимодействуют с системой, но также определяют ее границы и изображаются на начальной контекстной DFD как терминаторы (внешние сущности).
Начальная контекстная диаграмма изображена на рисунке 2.42. В отличие от нотации Gane/Sarson внешние сущности обозначаются обычными прямоугольниками, а процессы - окружностями.
Рис. 2.42. Начальная контекстная диаграмма
Список событий строится в виде матрицы (ELM) и описывает различные действия внешних сущностей и реакцию ИС на них. Эти действия представляют собой внешние события, воздействующие на библиотеку. Различают следующие типы событий:
Аббревиатура | Тип |
---|---|
NC | Нормальное управление |
ND | Нормальные данные |
NCD | Нормальное управление/данные |
TC | Временное управление |
TD | Временные данные |
TCD | Временное управление/данные |
Все действия помечаются как нормальные данные. Эти данные являются событиями, которые ИС воспринимает непосредственно, например, изменение адреса клиента, которое должно быть сразу зарегистрировано. Они появляются в DFD в качестве содержимого потоков данных.
Матрица списка событий имеет следующий вид:
№ | Описание | Тип | Реакция |
---|---|---|---|
1 | Клиент желает стать членом библиотеки | ND | Регистрация клиента в качестве члена библиотеки |
2 | Клиент сообщает об изменении адреса | ND | Регистрация измененного адреса клиента |
3 | Клиент запрашивает аренду фильма | ND | Рассмотрение запроса |
4 | Клиент возвращает фильм | ND | Регистрация возврата |
5 | Руководство предоставляет полномочия новому поставщику | ND | Регистрация поставщика |
6 | Поставщик сообщает об изменении адреса | ND | Регистрация измененного адреса поставщика |
7 | Поставщик направляет фильм в библиотеку | ND | Получение нового фильма |
8 | Руководство запрашивает новый отчет | ND | Формирование требуемого отчета для руководства |
Для завершения анализа функционального аспекта поведения системы строится полная контекстная диаграмма, включающая диаграмму нулевого уровня. При этом процесс "библиотека" декомпозируется на 4 процесса, отражающие основные виды административной деятельности библиотеки. Существующие "абстрактные" потоки данных между терминаторами и процессами трансформируются в потоки, представляющие обмен данными на более конкретном уровне. Список событий показывает, какие потоки существуют на этом уровне: каждое событие из списка должно формировать некоторый поток (событие формирует входной поток, реакция - выходной поток). Один "абстрактный" поток может быть разделен на более чем один "конкретный" поток.
Потоки на диаграмме верхнего уровня | Потоки на диаграмме нулевого уровня |
---|---|
Информация от клиента | Данные о клиенте, Запрос об аренде |
Информация для клиента | Членская карточка, Ответ на запрос об аренде |
Информация от руководства | Запрос отчета о новых членах, Новый поставщик, Запрос отчета о поставщиках, Запрос отчета об аренде, Запрос отчета о фильмах |
Информация для руководства | Отчет о новых членах, Отчет о поставщиках, Отчет об аренде, Отчет о фильмах |
Информация от поставщика | Данные о поставщике, Новые фильмы |
На приведенной DFD (рисунок 2.43) накопитель данных "библиотека" является глобальным или абстрактным представлением хранилища данных.
Анализ функционального аспекта поведения системы дает представление об обмене и преобразовании данных в системе. Взаимосвязь между "абстрактными" потоками данных и "конкретными" потоками данных на диаграмме нулевого уровня выражается в диаграммах структур данных (рисунок 2.44).
На фазе анализа строится глобальная модель данных, представляемая в виде диаграммы "сущность-связь" (рисунок 2.45).
Между различными типами диаграмм существуют следующие взаимосвязи:
На фазе проектирования архитектуры строится предметная модель. Процесс построения предметной модели включает в себя:
Рис. 2.43. Контекстная диаграмма
Рис. 2.44. Диаграмма структур данных
Результатами проектирования архитектуры являются:
Рис. 2.45. Диаграмма "сущность-связь"
На фазе детального проектирования строится модульная модель. Под модульной моделью понимается реальная модель проектируемой прикладной системы. Процесс ее построения включает в себя:
Результатами детального проектирования являются:
На фазе реализации строится реализационная модель. Процесс ее построения включает в себя:
На основе анализа потоков данных и взаимодействия процессов с хранилищами данных осуществляется окончательное выделение подсистем (предварительное должно было быть сделано и зафиксировано на этапе формулировки требований в техническом задании). При выделении подсистем необходимо руководствоваться принципом функциональной связанности и принципом минимизации информационной зависимости. Необходимо учитывать, что на основании таких элементов подсистемы как процессы и данные на этапе разработки должно быть создано приложение, способное функционировать самостоятельно. С другой стороны при группировке процессов и данных в подсистемы необходимо учитывать требования к конфигурированию продукта, если они были сформулированы на этапе анализа.
Назад | Содержание | Вперед