Технология моделирования бизнес процессов
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 557 views

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

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

Statistics

Views

Total Views
557
Views on SlideShare
553
Embed Views
4

Actions

Likes
2
Downloads
30
Comments
1

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Технология (от др.-греч. τέχνη — искусство, мастерство, умение; λόγος — мысль, причина; методика, способ производства) — в широком смысле — совокупность методов, процессов и материалов, используемых в какой-либо отрасли деятельности.

    Информационные технологии — широкий класс дисциплин и областей деятельности, относящихся к технологиям управления, накопления, обработки и передачи информации.

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

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

    Одна из наиболее типичных ошибок состоит в том, что именно на этой стадии реинжиниринговые команды пытаются анализировать бизнес-процессы в мельчайших деталях, вместо того, чтобы постараться постичь его в целом.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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 Захарова Ольга Владимировна к. э. н., доц. каф. эконом. кибернетики