А. А. Платонов, доцент кафедры прикладной математики и вычислительной техники Волгоградского государственного архитектурностроительного университета
 Скачать 3.99 Mb.
|
|
5.2. Описание бизнес-процесса «Планирование закупок и размещение заказов поставщикам» Опишем бизнес-процесс «Планирование закупок и размещение заказов поставщикам» с использование вышеописанных методик. Предприятие планирует закупки медикаментов. Планирование закупок осуществляется в Департаменте маркетинга, в группе маркетинга и планиро- вания. Планирование закупок осуществляется следующим образом: 1. Менеджер группы планирования и маркетинга ежесуточно получает от контрагентов данные внешней и внутренней статистики продаж медикамен- тов в виде отчетов продаж. 2. Для планирования закупок медикаментов менеджер группы планиро- вания и маркетинга еженедельно на основании статистики продаж осущест- вляется расчет потребности в товаре. В результате расчета формируется таблица потребностей в товаре. 3. Определив количество и номенклатуру заказываемых товаров, менед- жер отдела закупок приступает к анализу предложений поставщиков. Дан- ный процесс осуществляется ежемесячно или по мере необходимости. Вы- бираются наиболее выгодные условия поставки. Для этого сравниваются це- ны поставщиков. Данные сведения берутся из прайс-листа для закупок. При выборе поставщика важно учесть предоставляемую отсрочку платежа. Дан- ные сведения берутся из контрактов, отмеченных как приоритетные (дейст- вующие). В результате формируется список поставщиков, каждой позиции присваивается признак основного и запасных поставщиков в порядке убыва- ния приоритета. 4. Менеджер отдела закупок ежемесячно на основании таблицы потреб- ностей в товаре и списка выбранных поставщиков формирует графики по- ставок с указанием сроков и периодичности, но без количества поставки. 5. Ежемесячно после определения потребности в товаре менеджер груп- пы логистики рассчитывает необходимое количество закупок. Необходимое количество закупок рассчитывается на основании фактических запасов на складе, необходимого минимального и максимального уровня запасов. Нор- мы минимального и максимального количества запасов устанавливаются в днях. При расчете необходимого количества закупки учитывается также время товара в пути. Таким образом, данный расчет должен обеспечить воз- можность бесперебойного наличия товара на складе. По результату расчетов формируется план заявок на месяц. 6. Затем в группе логистики ежедневно по плану заявок, графику поста- вок, прайс-листам поставщиков формируются заказы поставщикам. 7. Если предстоит сделать заказ импортному поставщику, то менеджер группы логистики рассчитывает затраты на сертификацию, создается отчет о затратах на сертификацию. Затраты на сертификацию проверяются на со- ответствие внутрифирменным нормам. Данная операция производится по мере необходимости. 39 8. Если затраты на сертификацию превышают внутрифирменные нормы, то менеджер группы логистики повторяет процесс формирования заказов поставщикам. Формируются новые заказы. 9. Ежедневно подготовленный заказ поставщику акцептуется, заказ дол- жен подписать менеджер по логистике и директор Департамента маркетинга и управления товарными запасами. 10. Ежедневно менеджер группы логистики направляет заказ в отдел за- купок. Менеджер отдела закупок направляет заказ поставщику. Ниже проведены результаты моделирования этого бизнес-процесса с ис- пользованием вышеприведенных методологий. На основании приведенного описания предметной области, используя методологию IDEF0, можно построить функциональную модель, описы- вающую основные бизнес-процессы. Построение модели IDEF0 всегда начинается с построения контекстной диаграммой, представленной на рис. 9. Далее произведено выделение подпроцессов. Получившаяся диаграмма второго уровня, содержащая функциональные блоки, отображающие глав- ные подфункции функционального блока контекстной диаграммы представ- лена на рис. 10. Далее были детализирована подфункции дочерней диаграммы. Результа- ты детализации представлены на рис. 11, 12, 13. Для выполнения моделирования бизнес-процесса с использованием язы- ка UML необходимо выполнить следующие действия: выявить действующие лица и варианты использования разрабатываемой системы; построить диаграмму вариантов использования; написать сценарии реализации вариантов использования и/или построить диаграмму деятельности. Анализ бизнес-процесса «Планирование закупок и размещение заказов поставщикам» позволяет выделить следующие действующие лица, взаимо- действующие с системой: менеджер группы планирования; менеджер отдела закупок; менеджер группы логистики. Далее определяем варианты использования, т. е. множества возможных последовательностей действий (событий), приводящих к значимому для дей- ствующего лица результату: определение потребности в товаре; анализ поставщиков; формирование заказа поставщику; направление заказа поставщику; Установив ассоциации между действующими лицами и вариантами ис- пользования, получим диаграмму вариантов использования представленную на рис. 14. 40 41 40 Рис. 9. Контекстная диаграмма бизнес-процесса «Планирование закупок и размещение заказов поставщикам» 40 41 41 Рис. 10. Диаграмма декомпозиции бизнес-процесса «Планирование закупок и размещение заказов поставщикам» 42 43 42 Рис. 11. Диаграмма декомпозиции бизнес-процесса «Определение потребности в товаре» 42 43 43 Рис.12. Диаграмма декомпозиции бизнес-процесса «Анализ поставщиков» 44 45 44 Рис. 13. Диаграмма декомпозиции бизнес-процесса «Формирование заказа поставщику» 45 Рис. 14. Диаграмма вариантов использования в бизнес-процессе «Планирование заку- пок и размещение заказов поставщикам» Поскольку в нашем учебном примере описание бизнес-процесса уже раз- бито на шаги, то написание сценариев для каждого из вариантов использова- ния не представляет труда. Достаточно разбить общее описание процесса на этапы, соответствующие вариантам использования. В реальных проектах процесс написания сценариев для вариантов использования является более сложным трудоемким. Для бизнес-процесса «Планирование закупок и размещение заказов по- ставщикам» могут быть написаны следующие сценарии: Сценарий варианта использования: «Определение потребности в товаре»: 1. Менеджер группы планирования и маркетинга ежесуточно получает от контрагентов данные внешней и внутренней статистики продаж медикамен- тов в виде отчетов продаж. 2. Для планирования закупок медикаментов менеджер группы планиро- вания и маркетинга еженедельно на основании статистики продаж осущест- вляется расчет потребности в товаре. В результате расчета формируется таблица потребностей в товаре. Сценарий варианта использования: «Анализ поставщиков»: 1. Определив количество и номенклатуру заказываемых товаров, менед- жер отдела закупок приступает к анализу предложений поставщиков. Дан- ный процесс осуществляется ежемесячно или по мере необходимости. Вы- бираются наиболее выгодные условия поставки. Для этого сравниваются це- 46 ны поставщиков. Данные сведения берутся из прайс-листа для закупок. При выборе поставщика важно учесть предоставляемую отсрочку платежа. Дан- ные сведения берутся из контрактов, отмеченных как приоритетные (дейст- вующие). В результате, формируется список поставщиков, каждой позиции присваивается признак основного и запасных поставщиков в порядке убыва- ния приоритета. 2. Менеджер отдела закупок ежемесячно на основании таблицы потреб- ностей в товаре и списка выбранных поставщиков формирует графики по- ставок с указанием сроков и периодичности, но без количества поставки. Сценарий варианта использования: «Формирование заказа поставщику»: 1. Ежемесячно после определения потребности в товаре менеджер груп- пы логистики рассчитывает необходимое количество закупок. Необходимое количество закупок рассчитывается на основании фактических запасов на складе, необходимого минимального и максимального уровня запасов. Нор- мы минимального и максимального количества запасов устанавливаются в днях. При расчете необходимого количества закупки учитывается также время товара в пути. Таким образом, данный расчет должен обеспечить воз- можность бесперебойного наличия товара на складе. По результату расчетов формируется план заявок на месяц. 2. Затем в группе логистики ежедневно по плану заявок, графику поста- вок, прайс-листам поставщиков формируются заказы поставщикам. 3. Если предстоит сделать заказ импортному поставщику, то менеджер группы логистики рассчитывает затраты на сертификацию, создается отчет о затратах на сертификацию. Затраты на сертификацию проверяются на со- ответствие внутрифирменным нормам. Данная операция производится по мере необходимости. 4. Если затраты на сертификацию превышают внутрифирменные нормы, то менеджер группы логистики повторяет процесс формирования заказов поставщикам. Формируются новые заказы. 5. Ежедневно подготовленный заказ поставщику акцептуется, заказ дол- жен подписать менеджер по логистике и директор Департамента маркетинга и управления товарными запасами. 6. Ежедневно менеджер группы логистики направляет заказ в отдел за- купок. Сценарий варианта использования: «Направление заказа поставщику»: Менеджер отдела закупок направляет заказ поставщику. Диаграмма деятельности, описывающая полный сценарий работы, пред- ставлена на рис. 15. Рассмотрим теперь описание того же бизнес-процесса с использованием языка ДРАКОН. Для описания входов, выходов и участников бизнес-процесса будем до- полнительно использовать язык ГНОМ (Графический Наглядный Очень Ма- ленький язык). Подробное его описание приведено в [6]. 47 Рис. 15. Диаграмма деятельности бизнес-процесса «Планирование закупок и размещение заказов поставщикам» В указатели поместим названия основных подпроцессов, а в мнемобло- ки — их описание (участников, входы и выходы). ГНОМ-схема бизнес- процесса «Планирование закупок и размещение заказов поставщикам» пока- зана на рис. 16. Далее построим ДРАКОН-схему бизнес-процесса. Ветки ДРАКОН- схемы — это основные подпроцессы моделируемого бизнес-процесса «Пла- нирование закупок и размещение заказов поставщикам». Икону «Ввод» ис- пользуем для описания входной информации (от кого и какие документы поступили). Для описания выходной информации используется икона «Вывод». Операции, выполняемые при реализации подпроцесса, описываем с по- мощью иконы «Полка». В верхней части иконы помещаем название испол- нителя, а в нижней — название операции. 48 Если требуется указать периодичность операции, то используем правый комментарий. Для указания дополнительных источников информации ис- пользуем левый комментарий. Результат построения ДРАКОН-схемы бизнес-процесса «Планирование закупок и размещение заказов поставщикам» представлен на рис. 17. Рис. 16. ГНОМ-схема бизнес-процесса «Планирование закупок и размещение заказов поставщикам» Сравнение трех вариантов описания бизнес-процесса «Планирование за- купок и размещение заказов поставщикам» позволяет сделать некоторые вы- воды об удобстве их использования. Наиболее неудобной является методология IDEF0, поскольку в ней от- сутствует ветвление. Использование диаграмм деятельности UML и ДРАКОН-схем позволяет избавиться от этого недостатка. Сравнивая диаграммы деятельности и ДРАКОН-схемы, следует отме- тить, что в первых выделяются действия отдельного исполнителя, а во вто- рых — подпроцессы. Второй подход позволяет добиться максимальной на- глядности графического описания бизнес-процесса. 48 49 49 Рис. 17. ДРАКОН-схема бизнес-процесса «Планирование закупок и размещение заказов поставщикам» 50 Контрольные вопросы 1. В чем преимущество качественных исследований? 2. Какие основные вопросы позволяют раскрыть качественные исследования? 3. Назовите основные виды качественных исследований. 4. Какими недостатками обладает анкетирование? 5. Назовите преимущества и недостатки совместных семинаров. 51 6. МЕТОД ПЕРСОНАЖЕЙ 6.1. Кто такие персонажи? Поскольку мы проектируем для пользователей, важно суметь понять и визуализировать характерные аспекты их отношений друг с другом, соци- альной и физической средой и, конечно, продуктом, который мы намерева- емся спроектировать. Проектировщики должны создавать модели пользователей на основе дан- ных наблюдений за их поведением, интуитивно выявляя общие зависимости. Лишь после формализации найденных зависимостей можно надеяться на систематическое конструирование таких шаблонов взаимодействия пользо- вателя с продуктом, которые будут хорошо соответствовать поведению, ментальным моделям и целям пользователей. Такую формализацию обеспе- чивают персонажи. Логика может подсказать, что для создания продукта, который призван удовлетворить самую большую аудиторию пользователей, нужно сделать его функциональность как можно более широкой, чтобы приспособить про- дукт к нуждам людей. Однако эта логика порочна. Лучший способ успешно удовлетворить потребности широкой аудитории — проектировать для кон- кретных типов людей с конкретными потребностями. Решение состоит в том, чтобы сначала правильно выбрать представите- лей, чьи потребности лучше всего отражают интересы большей части инте- ресующей нас аудитории, а затем назначить приоритеты этим представите- лям так, чтобы учет потребностей самых важных пользователей не приносил существенных неудобств второстепенным. Персонажи представляют собой мощный инструмент для обсуждения различных типов пользователей и их потребностей, а также для выбора наиболее важных пользователей, на кото- рых следует ориентироваться при проектировании функциональности и по- ведения продукта. Персонажи — действенное и универсальное средство проектирования, способствующее преодолению ряда проблем, которые в настоящее время не- отступно преследуют разработчиков цифровых продуктов. Персонажи помо- гают проектировщикам определять, что должен делать продукт и каким 52 должно быть его поведение; общаться с заинтересованными лицами, разра- ботчиками и другими проектировщиками; оценивать эффективность решений. Кроме того, персонажи позволяют решить три ключевые проблемы про- ектирования, возникающие при разработке продукта. Как любая модель, персонажи должны основываться на наблюдениях за реальностью. Основным источником данных при синтезе персонажей служат интервью, контекстное исследование либо другие формы обсуждений с дей- ствительными и потенциальными пользователями, а также наблюдения за ними. Качество данных, собранных в ходе этого процесса напрямую опреде- ляет действенность персонажей как средства, позволяющего упростить и на- править процесс проектирования. Прочие данные, способные помочь в про- цессе создания персонажей и уточнить информацию о них, включают в себя (в примерном порядке убывания эффективности): данные интервью с пользователями вне контекста использования; информацию о пользователях, предоставленную заинтересованными ли- цами и экспертами в предметной области (ЭПО); результаты обзора литературы и более ранних исследований. Персонажи — это модели пользователей, представленные в виде конкретных людей. Они не являются реальными людьми, но синтезируются непосредственно по результатам наблюдений за реальными людьми. Успех персонажей как моделей пользователей во многом определяется тем, что персонажи олицетворяют личности. Хотя персонажи изображаются как конкретные личности (поскольку вы- полняют функцию архетипов), каждый из них является представителем класса или типа пользователей конкретного интерактивного продукта. Персонаж вбирает в себя уникальный набор шаблонов поведения, свя- занных с использованием определенного продукта (или с аналогичной дея- тельностью в предметной области, если продукт еще не существует), кото- рые выявляются посредством анализа данных интервью и при необходимо- сти подкрепляются дополнительными количественными данными. Наряду с конкретными мотивами и целями эти шаблоны задают персонажей. Иногда персонажей называют также составными архетипами пользователей, по- скольку они создаются путем группировки родственных шаблонов исполь- зования, наблюдавшихся в ходе фазы исследований у пользователей, иг- рающих сходные роли. 6.2. Разработка персонажей Как уже говорилось ранее, персонажи возникают на основе общих тенден- ций, выявленных в ходе интервью с пользователями и потенциальными поль- зователями (а иногда и покупателями) продукта, а также в процессе наблюде- ний за ними. Пробелы в этих данных восполняются путем дополнительных ис- следований, а также с помощью информации, представленной ЭПО и заинтересованными лицами и почерпнутой из существующей литературы. 53 Создание правдоподобных и действенных персонажей в равной степени требует детального анализа и творческого синтеза. Оба вида деятельности в значительной степени выигрывают от применения стандартизированного процесса. Вот основные шаги процесса: 1. Выявить поведенческие переменные. 2. Сопоставить респондентов с поведенческими переменными. 3. Выявить значимые шаблоны поведения. 4. Синтезировать характеристики и соответствующие им цели. 5. Проверить полноту и выявить избыточность. 6. Расширить описание атрибутов и поведений. 7. Назначить персонажам типы. 8. Рассмотрим каждый из этапов более подробно. Шаг 1. Выявление поведенческих переменных После завершения исследования и проведения предварительной обработки данных необходимо перечислить самостоятельные аспекты наблюдавшихся вариантов поведения, то есть создать набор поведенческих переменных. В общем случае наиболее важные различия между шаблонами поведения определяются при рассмотрении следующих типов переменных: деятельность: чем занят пользователь, частота и объем; взгляды: каким образом пользователь думает о предметной области и технологии продукта; наклонности: каковы образование и подготовка пользователя, его спо- собность обучаться; мотивация: каким образом пользователь вовлечен в предметную область продукта; навыки: умения пользователя, связанные с предметной областью продук- та и используемой технологией. |