Автоматизированное управление жизненным циклом продукции

Четвертый этап продаж -  "Работа с возражениями". Этот этап обычно не наступает неожиданно. Он, скорее, плавно вытекает из предыдущего этапа, а может вообще начаться еще на этапе установления контакта. Сюда, помимо самих возражений, можно отнести и вопросы, которые будут задаваться клиентом. Работа с возражениями – это один из ключевых моментов всего процесса продаж. Многие упускают клиента именно на этой стадии.

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

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

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

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

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

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

Далее необходимо построить модели описанных выше бизнес-процессов «как есть».

Выводы к главе 2

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

 

 

 

 

 

 

 

 

 

 

 

 

3 Моделирование бизнес-процессов компании ООО «Джей МКН»

 

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

Система управления процессами компании включает:

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

Основные бизнес-процессы компании можно рассматривать как отдельные предприятия внутри компании.

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

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

Для решения задач моделирования  сложных систем существуют хорошо обкатанные методологии и стандарты. К таким  стандартам относятся методологии  семейства IDEF. С их помощью можно  эффективно отображать и анализировать  модели деятельности широкого спектра  сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными [1].

3.1 Разработка функциональной модели  компании

Успех в бизнесе часто зависит от того, насколько хорошо организованы деловые процессы, отвечающие стратегическим целям предприятия. IDEF0 – это мощное CASE-средство функционального моделирования, которое позволяет описывать, анализировать и совершенствовать сложные деловые процессы. Оно помогает выявить и устранить лишние или неэффективные операции, снизить затраты, повысить производительность.

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

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

Моделирование средствами IDEF0 является первым этапом изучения любой системы. В основе методологии лежат четыре основных понятия.  Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом [2].

С помощью инструментария Bpwin  была разработана структура компании Джей.

3.1.1 Разработка контекстной диаграммы

Модель начинается с представления  системы как единого целого –  одного функционального блока с интерфейсными дугами. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0” (рис. 3.1)

 

Рисунок 3.1 - Контекстная диаграмма компании Джей

Каждая из четырех сторон функционального  блока имеет своё определенное значение (роль), при этом:

- Верхняя сторона имеет значение  «Управление» (Control);

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

- Левая сторона имеет значение  «Вход» (Input);

Входным элементом является заказ  покупателя на сборку персонального  компьютера.

- Правая сторона имеет значение  «Выход» (Output);

На выходе диаграммы мы получаем готовое изделие – системный блок.

- Нижняя сторона имеет значение  «Механизм» (Mechanism).

Механизмами исполнения в данном процессе являются сотрудники (менеджер, техник, кладовщик и кассир) и программный  продукт 1С.

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

3.1.2 Детализация контекстной диаграммы

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

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

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

Рисунок 3.2 - Процесс покупки системного блока

• Подбор конфигурации
• Оформление покупки
• Комплектация на складе
• Сборка ПК
• Демонстрация клиенту

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

• Согласование по совместимости. На этом этапе выясняются потребности клиента, основные требования, предъявляемые к мощности системного блока. После этого подбирается оптимальная конфигурация и проверяется совместимость комплектующих.
• Выбор по дизайну. При продаже системного блока данный этап заключается в выборе корпуса. Основным критерием при выборе является дизайн, но также учитываются габариты и система охлаждения.
• Оформление на ПК. Последним этапом является занесение выбранного товара в программу 1С для создания единого заказа. Затем покупатель оплачивает стоимость готового изделия, а компания начинает сборку и тестирование (см.рис.3.3)

Рисунок  3.3 - Подбор конфигурации системного блока

 

Этапы сборки персонального компьютера (рис.3.4):

• Занесение серийных номеров. Серийные номера с каждой комплектующей сканируются при помощи ручного сканера и заносятся в программу 1С. Затем техником будет создан гарантийный талон.
• Сборка комплектующих в корпус. Последовательность сборки следующая: сначала центральный процессор устанавливается на материнскую плату, сверху на него крепится система охлаждения. Далее материнская плата устанавливается и крепится в корпусе системного блока. Затем добавляются модули оперативной памяти, жесткий диск, оптический привод и видеокарта. Все компоненты соединяются между собой  data-кабелями, и каждая комплектующая подсоединяется к блоку питания.
• Установка тестового программного обеспечения. На готовый системный блок устанавливают тестовую операционную систему Windows 7 и программы для отсеивания заводского брака. Затем протестированный системный блок стикеруется, ему присваивается идентификационный номер, после чего кладовщик транспортирует готовое изделие на склад.

Рисунок 3.4 - Сборка персонального компьютера

Демонстрация системного блока  содержит (рис.3.5):

• Представление системного блока клиенту. Здесь готовый системный блок распаковывают и подключают для проверки на столе выдачи.
• Проверка составляющих согласно паспорту. Техник ОТК демонстрирует покупателю комплектующие ПК, заходя во вкладки операционной системы.
• Подпись гарантийного талона. После успешной проверки подписываются гарантийные обязательства, системный блок отключается от сети и запаковывается в коробку для транспортировки.

Рисунок 3.5 - Демонстрация системного блока клиенту

Для более детального описания процессов, происходящих в компании ООО «Джей  МКН», используем метод сценариев.

3.2 Разработка сценариев

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

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

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

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

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