sem2 - stankin/design-part-2 GitHub Wiki

В рамках образовательного процесса имеет смысл раздельно рассматривать процессы общего планирования (А1), диспетчеризации (А2), выполнения (А3) и оценки (А4). При этом следует не забывать о возможности возникновения нештатных ситуаций в каждом из рассматриваемых в диаграмме процессов, порождающих дополнительные потоки обратной связи с необходимостью их специальной обработки (выход А3 --> управление А2; выход А4 --> управление А3), Кроме того, в теории управления считается, что системы без информационных обратных связей от процессов контроля к процессам управления (выход А4 --> вход А1) неработоспособны.

При дальнейшей декомпозиции процессов не следует исключать из модели процессы, связанные с интеллектуальной деятельностью самого исполнителя (понять, оценить, придумать...) и персональным планированием, в т.ч. "в уме". При этом в каждой дочерней диаграмме получаются наборы процессов, вполне аналогичные наборам родительских диаграмм и также включающие процессы планирования (А11), диспетчеризации (А12), выполнения (А13) и оценки (А14). Помимо всего прочего, введение в рассмотрение именно таких, не автоматизированных изначально процессов, дает возможность более точного определения требований к информационным системам исходя из возможностей ИС (средств поддержки) способствовать решению наиболее трудоемких для пользователей операций.

Например, требования к средствам поддержки (механизм А33, А34) можно дополнить требованиями по ведению планов (дополнительный механизм А32) и/или требованиями по обеспечению удобного доступа к источникам и примерам (дополнительный механизм А31). При полном исключении этих процессов из модели (формального рассмотрения) могут быть потеряны наиболее ценные идеи, связанные с совершенствованием процессов за счет применения средств автоматизации.

Задача: В компании необходимо увеличить объемы продаж на 20%, при этом не увеличивая количество сотрудников и не повышая расходы на маркетинг.

Решение задачи при помощи методологии PDCA:

1. Этап Plan(Планирование):

1.1 Выявленные проблемы:

• в компании нет роста объема продаж;

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

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

1.2 Цель: увеличить объемы продаж на 20% за 1 месяц;

1.3 Требования:увеличить объемы продаж необходимо таким образом, чтобы не увеличивать количество сотрудников и не повышать расходы на маркетинг;

1.4 Ожидаемый результат: увеличение объема продаж на 20% за 1 месяц;

1.5 Ресурсы, необходимые для достижения ожидаемого результата: необходима система CRM;

1.6 Процессы (запланированные действия):

1.6.1 Для сотрудников отдела продаж необходимо скорректировать количество звонков с сторону увеличения, перевести весь учет в CRM-систему:

• «холодный» обзвон – увеличить количество звонков с 70 звонков до 100 звонков в день,

• звонки по «теплым лидам» – увеличить количество звонков с 30 до 50 звонков в день.

1.6.2 Все сотрудники отдела продаж делятся на три категории:

первая категория (новички и аутсорсеры);

вторая категория (коммуникабельные и высококвалифицированные сотрудники, хорошо знающие продукцию компании);

третья категория (менеджеры, хорошо работающие с договорами, знают, как вести клиента и решать конфликтные ситуации);

1.6.3 Задачи для каждой категории на каждый день:

• «холодный» обзвон – 100 звонков в день (реализуется массовая продукция),

• звонки по «теплым лидам» – 50 звонков (каждому клиенту нужно уделить 5–10 минут времени),

• все шаги, звонки, результат работы каждого дня фиксировать по каждому сотруднику в CRM-системе,

• задачи выполняются на протяжении 1 месяца.

2. Этап Do(Выполнение):

Сотрудники отдела продаж в течении 1 месяца выполняют поставленные задачи.

3. Этап Check(Проверка):

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

4. Этап Act (Улучшение):

Если запланированные действия начинают выдавать ожидаемый результат (увеличиваются объемы продаж), то модель принимается за основу и внедряется с последующей доработкой.

На следующем цикле (P-D-C-A) уже прорабатывается система мотивации, оптимизация взаимодействия между разными категориями менеджеров.

Задача: Продать как можно больше хлебобулочных изделий.

P (Plan): 1.1. Необходимо продать как можно больше хлебобулочных изделий 1.2. Срок выполнения – 1 месяц. 1.3. Владелец булочной должен продать как можно больше товаров 1.4. Следует выставить на полки как можно больше товаров 1.5. Размещение товара будет происходить с помощью витрины и полок с продукцией

D (Do): 2.1. Происходит снабжение необходимыми хлебобулочными изделиями, полками для изделий 2.2. Владелец заведения распределяет обязанности по продаже товара между всеми сотрудниками заведения 2.3. Владелец заведения осуществляет сбор и накопление результатов продажи продукции 2.4. Владелец заведения осуществляет сбор оперативной информации о ходе продаж и возникающих проблемах

C (Check): 3.1. По истечении 1 месяца проводится оценка результатов 3.2. Владельцу заведения передается результат разработки продукта 3.3. Владелец заведения осуществляет мониторинг продаж продукции измеряет успешность продаж по критериям

A (Act): 4.1. Сравниваются плановые показатели до внедрения новых технологий продаж и после 4.2. Выявляются отклонения от плановых показателей 4.3. Выявляются отклонения фактических продаж (увеличение или уменьшение продаж) от плановых показателей 4.4. Формируются требования по улучшению продаж заведения

На следующем цикле (P-D-C-A) уже прорабатывается система мотивации покупки, оптимизация взаимодействия между заведением и покупателем за счёт разработки и внедрения новых технологий

P (Plan): 1.1. Необходимо разработать программный продукт для увеличения продаж булочной. 1.2. Срок выполнения – 1 месяц. 1.3. Необходимо найти исполнителя, который разработает программный продукт. 1.4. Следует разработать сайт для удобного выбора хлебобулочных изделий по характеристикам. 1.5. Разработка продукта будет происходить на языке Python.

D (Do): 2.1. Происходит снабжение необходимой документацией, инструментами (программный продукт для разработки сайта) 2.2. В команде подготавливаются, организуются и распределяются работы по участникам команды 2.3. Мастер команды осуществляет сбор и накопление результатов разработки программного продукта 2.4. Мастер команды осуществляет сбор оперативной информации о ходе выполнения разработки и возникающих проблемах

C (Check): 3.1. По истечении 1 месяца проводится оценка результатов 3.2. Заказчику передается результат разработки продукта 3.3. Команда исполнителей осуществляет мониторинг использования продукта, измеряет его успешность по критериям

A (Act): 4.1. Сравниваются плановые показатели до внедрения продукта и после 4.2. Выявляется отклонения от плановых показателей 4.3. Выявляются отклонения фактических продаж (увеличение или уменьшение продаж) от плановых показателей 4.4. Формируются требования по улучшению дизайна и оптимизации работы приложения

Изображение 1, изначальный процесс: Изображение 2, КАК БЫЛО: Изображение 3, КАК СТАЛО (добавление станка с ЧПУ):

Тема семинаров (2-4): (Малое-Среднее) Производство пиццы. процессная модель "как было"(1): процессная модель "как будет"(2-3):

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

Контекстная диаграмма декомпозируется на 3 блока. Сначала родитель устно предупреждает ребенка о том, сколько он может поиграть в игру. Затем ребенок начинает играть, и, когда лимит превышается, родителю посылается сообщение об этом. Однако, чтобы послать сообщение, нужно автоматизировать этот процесс. Декомпозируем блок "Превысить лимит времени, проводимого в игре" на еще 2 блока. Во время превышения лимита ПО автоматически будет это фиксировать по заранее полученным к нему требованиям и посылать сообщения родителю.

Миграция данных. "Как было":

"Как стало":

1. Plan (Планирование): -Стратегиия тесирования -При готовом рабочем прототипе -Тестировщик -Ручками тестировщика -С помощью стандартного набора тестов

2. Do (Выполнение)

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

3. Check (Проверка)

• Осуществляется контроль результатов выполнения работ
• Осуществляется передача результтатов работ заказчику (потребителю)
• Осуществляется мониторинг и измерение процессов

4. Act (Коррекировка)

• Сравниваются плановые показатели с данными фактических результатов
• Выявляются отклонения фактических разеультатов от плановых показателей
• Выполняется оценка отколнений фактических результатов от плановых показателей
• Формируются предложения по корректировке планов и других необходимых мерах по улучшению деятельности

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

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

Процесс взятия книги в библиотеке (библиотечная картотека).

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

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

1. Рассматриваемый процесс:

2. Процессная модель "Как было":

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

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

2.2. На этапе выполнения менеджер отправляет сформированный заказ на приготовление;

2.3. На этапе проверки менеджер вручную вносит в отчет информацию о выполненном заказе;

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

3. Процессная модель "Как стало":

Автоматизация процесса управления очередью в ресторане дает массу преимуществ:

• Теперь информация о заказе посетителя с желаемыми позициями автоматически рассылается как менеджерам, так и поварам
• Порядок очереди поддерживается системой, анализирующей заказы и выставляющей приоритеты
• Ускорен подпроцесс составления отчета за счет специальных компонентов, предоставляемых системой

1. Процессная модель "Как было":

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

2.2. На этапе выполнения продавец отправляет сформированный заказ на приготовление;

2.3. На этапе проверки продавец вручную вносит в отчет информацию о выполненном заказе;

2.4. На этапе корректировки продавец обновляет инструкции по приготовлению заказа.

2. Процессная модель "Как стало":

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