Технология моделирования бизнес процессов

Захарова О.В. , к. э. н. доц. каф. экономической кибернетики

Технология моделирования бизнес-процессов

Лекция 2

Харьков 6 марта 2014

Моделирование бизнес-процессов

Тема 2. Технология моделирования бизнес-процессов

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

2.2 Методики получения и способы

представления бизнес-информации

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

2.1 Основы

бизнес-моделирования

Основные элементы системы управления

Система целей и

показателей

Модель бизнес-

процессов

Организационная

структура

Разработка системы управления 1. Формулирование наивысшей цели организации

2. Разработка стратегии

3. Формирование верхнего уровня системы целей и показателей

4. Определение объектов управления

5. Разработка модели бизнес-процессов, формирование нижнего уровня системы целей и показателей

6. Проектирование организационной структуры

7. Формирование регламентирующей и методической документации

8. Автоматизация системы управления (при необходимости)

Объекты управления

1. Собственник

2. Потребитель

3. Продукт

4. Техпроцесс (производственный процесс, процесс оказания услуги)

5. Поставщик

6. Производственно-технологическое оборудование

7. Инженерно-техническая инфраструктура

8. Рабочая сила (персонал)

9. Капитал

Задачи управления

№ Объект управления Начальное состояние

Конечное состояние

1. Собственник Неудовлетворенный Удовлетворенный 2. Потребитель Потенциальный Удовлетворенный 3. Продукт Отсутствует Удовлетворяющий

потребности потребителя 4. Техпроцесс

(производственный процесс, процесс оказания услуги)

Отсутствует Соответствует технологии

5. Поставщик Потенциальный Удовлетворивший нас 6. Производственно-

технологическое оборудование

Работоспособное Работоспособное (в цикле)

7. Инженерно-техническая инфраструктура

Работоспособное Работоспособное (в цикле)

8. Рабочая сила (персонал) Работоспособное Работоспособное (в цикле) 9. Капитал (в процессе

деятельности меняет свою форму)

Достаточный для осуществления деятельности

Достаточный для осуществления деятельности

До начала моделирования необходимо…

1. Установить цели моделирования бизнес-процессов

2. Установить границы процессов

3. Установить стандарты содержания, трактования и других видов восприятия

4. Определить уровень необходимой детализации процессов

5. Сколько и каких данных необходимо собрать, кроме как данных о потоке и последовательности работ

6. Определить методы сбора информации

7. Определить подходы для документирования процессов

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

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

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

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

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

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

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

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

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

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

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

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

Заинтересованные лица

5 групп заинтересованных лиц:

1. Собственники (инвесторы)

2. Клиенты (потребители)

3. Поставщики

4. Сотрудники

5. Общество

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

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

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

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

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

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

What Is Analyst?

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.

Analyst Common Roles

• Business Process Analyst

• Business Analyst

• Product Manager

• Systems Analyst

• Designer/Architect

analyzes, documents, and improves business processes

gathers, documents, analysis business needs and requirements

designs the functional behavior of the system as well as designs and documents the logical components of the system and creates functional specifications

guides the features and direction of a given product from a high-level perspective

designs and architects the physical components of the system to be implemented by the development team

Modern Analyst

Must understand

• “The Business”

• The challenges of technology and the needs of the development team

must have an intimate knowledge of the business processes and needs of the organization they are working for.

has to realize that technology, while a great advent, it’s not easy to employ – and it requires highly specialized technical skills and resources.

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

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

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

Business Analysts Roles/Titles

• Business Analyst

• Business Process Analyst

• IT Business Analyst

• Requirements Engineer/Analyst

• Business Systems Analyst

• Systems Analyst

• Data Analyst

• Functional Architect

• Usability/UX Analyst

Процессный подход

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

Требование – это …

Требование – это:

– возможность, которой система должна обладать и ограничение, которому система должна удовлетворять;

– документированное представление условий/возможностей.

Роль требований Строжайшее и единственное правило построения систем – решить точно, что же строить.

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

Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.

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

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

Выявление требований Время, которое тратится на выяснение потребностей – высокоэффективная инвестиция в успех проекта.

Если невозможно полностью определить требования до предварительного конструирования – действуют итеративно. Итерации при реализации стоят гораздо дороже, чем при разработке концепций.

Самое трудное – выявить требования. Написание требований – процесс выяснения, разработки и расшифровки данных. Четкое понимание требований дает уверенность, что будут найдены лучшие решения для определенных проблем.

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

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

Разработка требований Процесс разработки требований включает:

1.1 Извлечение – elicitation

1.2 Анализ – analysis

1.3 Документирование – specification

1.4 Утверждение – validation

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

Уровни требований Уровень 1. Бизнес-требования Уровень 2. Требования пользователей Уровень 3. Функциональные требования

+ Нефункциональные требования каждого уровня

Условные обозначения:

– типы информации для требований;

– способы хранения информации (документы,

диаграммы, базы данных).

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

Типы требований Функциональные:

1.1 Бизнес-требования

2.1 Требования пользователей

3.1 Системные требования 3.2 Функциональные

требования

Нефункциональные:

2.2 Бизнес-правила 2.3 Атрибуты качества

3.3 Внешний интерфейс 3.4 Ограничения

Уровень 1.

Уровень 3.

Уровень 2.

1.1 Бизнес-требования

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

Функциональные

2.1 Требования пользователей

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

Функциональные

2.2 Бизнес-правила

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

Нефункциональные

2.3 Атрибуты качества

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

Нефункциональные

3.1 Системные требования

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

Функциональные

3.2 Функциональные требования

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

3.2 Функциональные требования

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

Характеристики продукта

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

Поток требований 1. Бизнес-требование определяется необходимостью работать эффективнее и успешно конкурировать на рынке.

2. Каждое требование пользователя сопоставляется бизнес-требованию.

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

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

Спецификации требований

Недостаточно получить прекрасные отдельные положения.

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

Baseline

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

Подпись под требованиями – завершение оперделенного этапа проекта.

Образ продукта и границы проекта

Образ продукта –product vision –описывает, что продукт представляет собой сейчас и каким он станет впоследствии.

Границы проекта –project scope – показывают, к какой области конечного долгосрочного образа продукта будет направлен текущий проект; определяют черту между тем, что входит в проект и тем, что остается вовне.

Образ – весь продукт, который будет изменяться относительно медленно.

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

Задача планирования заключается в управлении границами определенного проекта (разрабатываемого или расширяемого), как определенным подмножеством большого стратегического образа.

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

Источники получения информации

1. Опросы заинтересованных лиц и дискуссии

2. Документы, в которых описан работающий продукт

3. Спецификации требований к системе

4. Отчеты об ошибках и претензии к возможностям работающей системы

5. Исследования

6. Наблюдение на рабочих местах

7. Сценарий анализа задач заинтересованных лиц

8. События и реакция на них

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

Аналитик требований

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

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

Аналитик обучает, задает вопросы, слушает, организует и учится. Это сложная работа.

Аналитик отвечает за сбор и распространение информации о продукте, а менеджер проекта – за обмен информацией о проекте.

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

Задачи аналитика

1. Определить бизнес-требования.

2. Определить заинтересованных лиц и классифицировать их.

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

4. Анализировать требования.

5. Создавать спецификации с требованиями.

6. Моделировать требования.

7. Управлять проверкой требований.

8. Обеспечить расстановку приоритетов требований.

9. Управлять требованиями.

Навыки, необходимые аналитику

1. Умение слушать.

2. Умение опрашивать и задавать вопросы.

3. Навыки анализа.

4. Навыки создания комфортных условий общения.

5. Умение наблюдать.

6. Навыки написания документации.

7. Организационные навыки.

8. Навыки моделирования: блок-схемы, структурированные модели анализа (диаграммы потоков информации, диаграммы «сущность – связь» и т.д.), UML – Unified Modeling Language.

9. Навыки межличностного общения.

10 Творческий подход.

Захарова Ольга Владимировна к. э. н., доц. каф. эконом. кибернетики

E-mail: harizmalife@gmail.com

Skype: harizmalife

Phone: +38 050 401 33 35