Моделирование бизнес-процессов. Лекция 2

1. Моделирование бизнес-процессов
Технология моделирования
бизнес-процессов
Лекция 2
Захарова О.В. , к. э. н.
доц. каф. экономической кибернетики
Харьков
6 марта 2014

2. Тема 2. Технология
моделирования бизнес-процессов
2.1 Основы бизнес-моделирования
2.2 Методики получения и способы
представления бизнес-информации
2.3 Роль бизнес-аналитика

3. 2.1 Основы
бизнес-моделирования

4. Основные элементы системы
управления
Система целей и
показателей
Модель бизнеспроцессов
Организационная
структура

5. Разработка системы
управления
1. Формулирование наивысшей цели организации
2. Разработка стратегии
3. Формирование верхнего уровня системы целей и
показателей
4. Определение объектов управления
5. Разработка модели бизнес-процессов, формирование
нижнего уровня системы целей и показателей
6. Проектирование организационной структуры
7. Формирование регламентирующей и методической
документации
8. Автоматизация системы управления (при необходимости)

6. Объекты управления
1. Собственник
2. Потребитель
3. Продукт
4. Техпроцесс (производственный процесс, процесс
оказания услуги)
5. Поставщик
6. Производственно-технологическое оборудование
7. Инженерно-техническая инфраструктура
8. Рабочая сила (персонал)
9. Капитал

7. Задачи управления
№
Объект управления
1.
2.
3.
Собственник
Потребитель
Продукт
4.
Техпроцесс
(производственный процесс,
процесс оказания услуги)
Поставщик
Производственнотехнологическое
оборудование
Инженерно-техническая
инфраструктура
Рабочая сила (персонал)
Капитал (в процессе
деятельности меняет свою
форму)
5.
6.
7.
8.
9.
Начальное
Конечное состояние
состояние
Неудовлетворенный Удовлетворенный
Потенциальный
Удовлетворенный
Отсутствует
Удовлетворяющий
потребности потребителя
Отсутствует
Соответствует технологии
Потенциальный
Работоспособное
Удовлетворивший нас
Работоспособное (в цикле)
Работоспособное
Работоспособное (в цикле)
Работоспособное
Достаточный для
осуществления
деятельности
Работоспособное (в цикле)
Достаточный для
осуществления
деятельности

8. До начала моделирования
необходимо…
1. Установить цели моделирования бизнес-процессов
2. Установить границы процессов
3. Установить стандарты содержания, трактования и
других видов восприятия
4. Определить уровень необходимой детализации
процессов
5. Сколько и каких данных необходимо собрать, кроме
как данных о потоке и последовательности работ
6. Определить методы сбора информации
7. Определить подходы для документирования процессов

9. Описание бизнес-процессов

10. Уровни моделирования

11. Разработка модели окружения

12. Окружение и границы бизнеспроцесса

13. Окружение бизнес-процесса

14. Дерево процессов банка

15. Разработка дерева процессов
верхнего уровня

16. Разработка организационной
структуры

17. Управление организацией

18. Участники системы
управления бизнес-процессом

19. Матрица ответственности

20. Матрица бизнес-процессов

21. Заинтересованные лица
5 групп заинтересованных лиц:
1. Собственники (инвесторы)
2. Клиенты (потребители)
3. Поставщики
4. Сотрудники
5. Общество

22. Связи с внешней средой

23. Входящие потоки

24. Описание деятельности

25. Процессы в организации

26. 2.2 Методики получения и
способы представления
бизнес-информации

27. 2.3 Роль бизнес-аналитика

28. What Is Analyst?

29. Analyst Definition
• a person who analyses or
is skilled in analysis;
• a person who reviews and
examines data or information
for a specific area;
• can fulfill a variety of roles.

30. Analyst Common Roles
•
Business Process
Analyst
analyzes, documents, and improves
business processes
•
Business Analyst
gathers, documents, analysis business
needs and requirements
•
Product Manager
guides the features and direction of a given
product from a high-level perspective
•
Systems Analyst
designs the functional behavior of the
system as well as designs and documents
the logical components of the system and
creates functional specifications
•
Designer/Architect
designs and architects the physical
components of the system to be
implemented by the development team

31. Modern Analyst

32. Must understand
•
“The Business”
must have an intimate knowledge of
the business processes and needs of
the organization they are working for.
•
The challenges of
technology and the
needs of the
development team
has to realize that technology, while a
great advent, it’s not easy to employ –
and it requires highly specialized
technical skills and resources.

33. Finance
•
Accounting Analyst evaluates and interprets public
company financial statements
•
Cost Analyst analyzes business operations to
determine which courses of action are most efficacious
in business
•
Financial Analyst analyzes securities and business
equity in economics and finance
•
Quantitative Analyst applies mathematical techniques
to investment banking, especially in the fields of risk
management, trading and financial derivatives

34. Business&Marketing
•
Business Analyst examines the needs and concerns of
clients and stakeholders to determine where potential
problems and opportunities lie (Business Systems
Analyst)
•
Industry Analyst performs market research on segments
of specific industries toward the identification of trends in
business and finance
•
Marketing Analyst analyzes price, customer, competitor
and economic data to help companies

35. IT&Software Development
•
Systems Analyst or Information
Analyst analyzes technical design
and functional design for software
development
•
Usability or UX (User eXperience)
Analyst are involved in the
interface design or UX for software
applications and websites
•
Web Metrics Analyst examines
trends and patterns in the use and
expansion of the World Wide Web
in webometrics

36. Business Analysts Roles/Titles
• Business Analyst
• Business Process
Analyst
• Business Systems
Analyst
• Systems Analyst
• IT Business Analyst
• Data Analyst
• Requirements
Engineer/Analyst
• Functional Architect
• Usability/UX Analyst

37. Процессный подход
Основные правила процессного подхода:
– наличие моделей (описаний) процессов;
– наличие ответственного за весь процесс и
его результат;
– наличие требований к выходам процедур
внутри процесса и к продукту (результату)
всего процесса.

38. Требование – это …
Требование – это:
– возможность, которой система должна
обладать и ограничение, которому система
должна удовлетворять;
– документированное представление
условий/возможностей.

39. Роль требований
Строжайшее и единственное правило построения систем –
решить точно, что же строить.
Никакая другая часть концептуальной работы не является
такой трудной, как выяснение деталей требований, в том
числе и взаимодействие с людьми, с механизмами и с
иными системами.
Никакая другая часть работы так не портит результат,
если она выполнена плохо. Ошибки никакого другого
этапа работы не исправляются так трудно.
Никаких предположений в требованиях. Периодически
спрашивайте: «Что мы предполагаем?», чтобы постараться
извлечь на поверхность эти спрятанные мысли.

40. Ошибки в требованиях

41. Выявление требований
Время, которое тратится на выяснение потребностей –
высокоэффективная инвестиция в успех проекта.
Если невозможно полностью определить требования до
предварительного конструирования – действуют итеративно.
Итерации при реализации стоят гораздо дороже, чем при разработке
концепций.
Самое трудное – выявить требования. Написание требований –
процесс выяснения, разработки и расшифровки данных. Четкое
понимание требований дает уверенность, что будут найдены лучшие
решения для определенных проблем.
Требования позволяют расставить приоритеты и оценить ресурсы
для их реализации, а также определить момент окончания проекта,
установить, достигнуты ли цели, или выбрать компромиссное
решение, когда придется сужать границы проекта.

42. Разделение областей

43. Разработка требований
Процесс разработки требований включает:
1.1 Извлечение – elicitation
1.2 Анализ – analysis
1.3 Документирование – specification
1.4 Утверждение – validation

44. Итеративный процесс

45. Уровни требований
Уровень 1. Бизнес-требования
Уровень 2. Требования пользователей
Уровень 3. Функциональные требования
+ Нефункциональные требования каждого уровня
Условные обозначения:
– типы информации для требований;
– способы хранения информации (документы,
диаграммы, базы данных).

46. Типы требований

47. Типы требований
Функциональные:
Нефункциональные:
Уровень 1.
1.1 Бизнес-требования
Уровень 2.
2.1 Требования
пользователей
2.2 Бизнес-правила
2.3 Атрибуты качества
Уровень 3.
3.1 Системные требования
3.2 Функциональные
требования
3.3 Внешний интерфейс
3.4 Ограничения

48. 1.1 Бизнес-требования
Функциональные
Бизнес-требования – business requirements –
высокоуровневые цели, зачем нужен продукт.
Документы:
– об образе и границах проекта или устав
проекта (project charter);
– рыночные требования (market requirements
document).
Первый этап управления проблемой расползания границ.

49. 2.1 Требования пользователей
Функциональные
Требования пользователей – user
requirements – цели и задачи, которые
пользователям позволит решить продукт.
Документы:
– варианты использования (use cases);
– сценарии (scenario);
– таблицы «событие – отклик».
Пример: «Сделать заказ» билетов через интернет.

50. 2.2 Бизнес-правила
Нефункциональные
Бизнес-правила – business rules –
корпоративные политики, стандарты,
алгоритмы.
Не являются требованиями к ПО, т.к.
находятся снаружи границ любой системы, но
налагают ограничения, а иногда становятся
источником атрибутов качества, которые
реализуются в функциональности.

51. 2.3 Атрибуты качества
Нефункциональные
Атрибуты качества – quality attributes –
дополнительное описание функций продукта,
выраженное через описание его важных
характеристик.
Примеры характеристик:
– легкость и простота использования (usability);
– легкость перемещения;
– целостность;
– эффективность и устойчивость к сбоям.

52. 3.1 Системные требования
Функциональные
Системные требования – system requirements –
высокоуровневые требования к продукту.
Относятся к:
– программному обеспечению (ПО);
– подсистемам ПО;
– оборудованию;
– людям.

53. 3.2 Функциональные требования
Функциональные требования – functional
requirements – или требования поведения –
behavioral requirements – определяют
функциональность, которую необходимо
создать, чтобы пользователи смогли
выполнить свои задачи в рамках бизнестребований.
Содержат положения с традиционным «должен».
Описывают, что необходимо реализовать.

54. 3.2 Функциональные требования
Документируются в виде спецификации
требований – software requirements
specification, SRS – техническое задание –
описывают ожидаемое поведение системы,
требования к продукту.
SRS также включает:
– цели атрибуты качества;
– внешние взаимодействия между системой и внешним
миром (внешний интерфейс);
– ограничения дизайна и реализации (constrains).

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

56. Поток требований
1. Бизнес-требование определяется необходимостью
работать эффективнее и успешно конкурировать на рынке.
2. Каждое требование пользователя сопоставляется
бизнес-требованию.
3. На основе требований пользователя определяются
функции, которые позволят пользователям выполнять их
задачи.
4. Функциональные и нефункциональные требования
необходимы для создания решений с желаемой
функциональностью, определенным качеством и
требуемыми рабочими характеристиками, не выходя за
рамки налагаемых ограничений.

57. Спецификации требований
Недостаточно получить прекрасные
отдельные положения.
Набор требований, составляющих
спецификацию, должен отвечать
определенным характеристикам.

58. Baseline
Концепция создания базовой или основной
версии – baseline – моментальный снимок
документа на определенный момент времени.
Подпись под требованиями – завершение
оперделенного этапа проекта.

59. Образ продукта и границы проекта
Образ продукта –product vision –описывает, что продукт
представляет собой сейчас и каким он станет впоследствии.
Границы проекта –project scope – показывают, к какой области
конечного долгосрочного образа продукта будет направлен
текущий проект; определяют черту между тем, что входит в проект
и тем, что остается вовне.
Образ – весь продукт, который будет изменяться относительно
медленно.
Границы относятся к определенному проекту или его итерации и
более динамичны, т.к. проект изменяется в соответствии с
графиком, бюджетом, ресурсами и ограничениями качества.
Задача планирования заключается в управлении границами
определенного проекта (разрабатываемого или расширяемого), как
определенным подмножеством большого стратегического образа.

60. Распространение информации

61. Источники получения информации
1. Опросы заинтересованных лиц и дискуссии
2. Документы, в которых описан работающий продукт
3. Спецификации требований к системе
4. Отчеты об ошибках и претензии к возможностям
работающей системы
5. Исследования
6. Наблюдение на рабочих местах
7. Сценарий анализа задач заинтересованных лиц
8. События и реакция на них

62. Классификация требований

63. Аналитик требований
Аналитик (бизнес-аналитик, системный аналитик,
инженер по требованиям, менеджер по требованиям,
менеджер по продукту, специалист отдела маркетинга) –
это основное лицо, отвечающее за сбор, анализ,
документирование и проверку требований к проекту.
Это основной коммуникативный канал между группой
клиентов и командой разработчиков.
Аналитик обучает, задает вопросы, слушает, организует и
учится. Это сложная работа.
Аналитик отвечает за сбор и распространение
информации о продукте, а менеджер проекта – за обмен
информацией о проекте.

64. Роль аналитика

65. Задачи аналитика
1. Определить бизнес-требования.
2. Определить заинтересованных лиц и классифицировать их.
3. Выявить требования с помощью интервью, семинаров, анализа
документов, опросов, посещения рабочих мест, анализа существующих
бизнес-процессов, анализа документооборота и задач, списка событий,
исследования существующих систем, ретроспективы развития
предыдущего проекта.
4. Анализировать требования.
5. Создавать спецификации с требованиями.
6. Моделировать требования.
7. Управлять проверкой требований.
8. Обеспечить расстановку приоритетов требований.
9. Управлять требованиями.

66. Навыки, необходимые аналитику
1. Умение слушать.
2. Умение опрашивать и задавать вопросы.
3. Навыки анализа.
4. Навыки создания комфортных условий общения.
5. Умение наблюдать.
6. Навыки написания документации.
7. Организационные навыки.
8. Навыки моделирования: блок-схемы, структурированные модели
анализа (диаграммы потоков информации, диаграммы «сущность –
связь» и т.д.), UML – Unified Modeling Language.
9. Навыки межличностного общения.
10 Творческий подход.

67. E-mail: harizmalife@gmail.com
Skype: harizmalife
Phone: +38 050 401 33 35
Захарова Ольга Владимировна
к. э. н., доц. каф. эконом. кибернетики