Умелое описание бизнес-процессов — залог успешной автоматизации

• Доклад посвящен описанию бизнес-процессов для автоматизации.  

• Опыт автора включает как проекты автоматизации, так и вне проектов.  

• Доклад состоит из нескольких частей.  

• Автор является тренером Luxoft и участвовал в конференции по разработке DEF LAPS.  

• Занимается системным и бизнес-анализом более десяти лет.  

• В 2009 году перешел в управленческий консалтинг, а в 2011 году провел первый тренинг по системному и бизнес-анализу.  

• Вопрос моделирования бизнес-процессов для всех заинтересованных сторон.  

• Важно корректно описать процессы для широкого круга читателей.  

• Вопрос выбора языка для описания бизнес-процессов.  

• Предприятия можно рассматривать как системы.  

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

• Архитектура процессов верхнего и среднего уровня.  

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

• Описание архитектуры предприятия может быть выполнено на естественном языке или формальных диаграммах.  

• Выбор языка зависит от возможностей и пожеланий заказчика.  

• Архитектура предприятия должна быть описана и понятна читателям.  

• Бизнес-моделирование является ключевым этапом в успешном проекте автоматизации.  

• Архитектура системы может существовать без конкретного описания.  

• Описание системы может быть не единственным и не полным.  

• Примеры: интернет, предприятие.  

• Системы можно описывать с разных точек зрения: взаимодействие, финансовые потоки, материальные потоки и т.д.  

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

• Коммуникационное описание предприятия полезно для управленческого консалтинга и реинжиниринга бизнес-процессов.  

• Предприятие рассматривается как преобразование входов в выходы.  

• Важно, чтобы преобразование было предсказуемым, документированным и имело ресурсы для выполнения.  

• Бизнес-процессы выполняются людьми и автоматизируются, что требует понимания границ автоматизации.  

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

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

• Методологии описания процессов, такие как IDEF0 и IDEF3, имеют свои ограничения.  

• Блок-схемы и потоковые диаграммы не всегда подходят для описания бизнес-процессов.  

• Современные требования к моделированию процессов требуют более сложных подходов.  

• ARIS и UML имеют свои преимущества и недостатки.  

• ARIS позволяет моделировать процессы для выполнения, но имеет ограничения в плотности информации.  

• UML, разработанный Пенкаром и Эриксоном, остается популярным среди бизнес-аналитиков.  

• Обсуждение необходимости нового языка для описания бизнес-процессов.  

• Решение использовать BPMN для описания деятельности и ролевых моделей.  

• BPMN как рабочий язык для методологии.  

• BPMN как нотация с умеренной плотностью подачи информации.  

• Легкость компоновки и формальной валидации.  

• Возможность адаптации для различных языков.  

• BPMN как открытый стандарт, поддерживаемый OMG.  

• Возможность переноса моделей между редакторами.  

• Широкая целевая аудитория: бизнес-аналитики, системные аналитики и другие.  

• Примеры частных и открытых процессов.  

• Описание процессов, инкапсулированных в организацию.  

• Примеры открытых процессов, таких как заказ и доставка пиццы.  

• Возможность регулирования уровня сложности диаграмм.  

• Советы по адаптации диаграмм для различных заинтересованных сторон.  

• Завершение доклада и ожидание вопросов от участников.  

• Переход к точкам зрения и их переложение на модель описания бизнес-процессов.  

• Модель является частью методологии многоуровневой детализации процессов.  

• Обсуждение заимствований и использования модели.  

• Современное состояние программной инженерии требует унифицированного понимания понятий системы и архитектуры.  

• Заинтересованная сторона определяется наличием интереса к системе.  

• Интерес может быть технологическим, правовым или пассивным.  

• Влияние может быть технологическим, правовым или пассивным.  

• Примеры влияния: разработчики, регуляторы, пользователи.  

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

• Контекст включает точки зрения, глубину и широту описания.  

• Глубина описания процесса для бизнес-заказчика и ИТ-службы может различаться.  

• Бизнес-заказчик инициирует проект, финансирует и контролирует его исполнение.  

• Пользователи играют важную роль в поддержке проекта.  

• Разработчики имеют технологический интерес к системе.  

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

• Основные группы: бизнес-заказчик, пользователи, разработчики, разработчик номер два.  

• Регуляторы, население и конкуренты также могут быть заинтересованы, но менее важны.  

• Модель состоит из трех уровней: процессы, пользователи, информационные системы.  

• Модель заимствована из методологии компании Oracle.  

• Обсуждение уровней и их названий, которые были додуманы автором.  

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

• Процессы могут выполняться без автоматизации или с использованием новых средств.  

• Успешный процесс имеет наиболее эффективный путь и минимальные затраты ресурсов.  

• Ура-сценарий - это успешный сценарий, который не учитывает ошибки, исключения и повторы.  

• Он предназначен для согласования с бизнес-заказчиком.  

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

• Обязательные элементы: начало и конец процесса, функции, задачи, активности.  

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

• Важно обобщать элементы для лучшего понимания бизнес-стейкхолдерами.  

• BPMN позволяет добавлять собственные артефакты, такие как объекты данных и информационные системы.  

• Комментарии помогают сделать модели понятными для большинства представителей бизнеса.  

• Второй уровень взаимодействия с пользователями и разработчиками.  

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

• Моделирование с точки зрения пользователя помогает быть понятыми пользователями.  

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

• Уровень информационной системы ориентирован на архитекторов и разработчиков.  

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

• Акцент на программную поддержку бизнес-процессов.  

• Три задачи пользователя: открыть страницу, проверить фишинг, ввести логин и пароль.  

• Эти задачи могут быть упрощены или регламентированы.  

• Система видит эти действия как одно, что снижает сложность модели.  

• Важно учитывать возможные ошибки и исключения.  

• Пример из проекта: документ может быть не выгружен или не создан в системе.  

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

• Задачи делятся на ручные, пользовательские, автоматические и бизнес-правила.  

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

• Вопросы об ошибках, исключениях и компенсациях важны для этих задач.  

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

• Декомпозиция диаграмм помогает упростить восприятие и анализ.  

• Именование и нумерация диаграмм должны соответствовать иерархии процессов.  

• Существует простой и технологичный подход к моделированию бизнес-процессов.  

• Можно легко адаптировать методологию BPMN для разных целевых групп.  

• Подход используется автором на протяжении нескольких лет без значительного сопротивления со стороны заказчиков.  

• Подготовка требует времени и усилий, так как нужно создать несколько подходов к одному и тому же процессу.  

• Ускорение на этом этапе может не принести пользы.  

• Ошибки в требованиях могут привести к значительным финансовым потерям.  

• Представлены документы и литература по BPMN.  

• Русскоязычной литературы по BPMN пока нет.  

• Автор готов перейти к обсуждению вопросов.  

• События в BPMN включают начальные, заключительные и промежуточные события.  

• Рекомендуется использовать события по таймеру и сообщения для коммуникации с заказчиками.  

• Подход автора аналогичен подходу Брюса Сильвера.  

• Сильвер выделяет описательное, аналитическое и исполняемое моделирование.  

• Описательное моделирование позволяет пренебречь строгостью нотации.  

• Аналитическое моделирование требует строгого следования нотации.  

• Исполняемое моделирование предназначено для BPM-систем.  

• Важно учитывать целевую аудиторию и уровень детализации.  

• Подход автора помогает адаптировать модели для разных аудиторий.  

• Представлен учебник Федорова по моделированию бизнес-процессов в BPMN.  

• Вопрос о тираже книги и возможности ее приобретения.  

• Важно адаптировать технические моменты для разных аудиторий.  

• ARIS и BPMN конкурируют за внимание.  

• ARIS предназначен для моделирования социотехнических систем.  

• BPMN остается актуальным и живым языком моделирования.  

• Автор делится своим опытом и знаниями.  

• Призывает обращаться за помощью и задавать вопросы.  

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