«Дорога в тысячу ли начинается с первого шага», — гласит китайская мудрость. Простые, правильные и понятные модели бизнес-процессов — своеобразный «знак качества», скреплять которым свою работу мечтает каждый профессионал-аналитик. Однако достижение нужного качества моделей у многих занимает годы непрерывной работы, а такой запас времени — непозволительная роскошь в стремительно развивающемся мире ИТ- и управленческого консалтинга. Многим не добавляет оптимизма и общепризнанный на сегодня открытый международный стандарт BPMN 2.0, допускающий чересчур много равновозможных решений одной и той же задачи в области моделирования.
В ходе общения с аудиторией на дискуссионном онлайн-семинаре Сообщества аналитиков UML2.Ru мы представили ряд простых способов повышения качества BPMN-моделей бизнес-процессов. Придерживаясь этих рекомендаций, вы вместе с участниками семинара сможете:
* унифицировать личную и командную технику моделирования процессов;
* добиться однозначного толкования моделей различными заинтересованными сторонами;
* преодолевать самые известные ограничения BPMN, не нарушая стандарт OMG и не выходя за рамки возможностей промышленных инструментов;
* заложить основу корпоративного соглашения о моделировании на описательном и аналитическом уровне.
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
Архитектура предприятия как системы охватывает такие области, как информационно-технологическая и бизнес-архитектура. В свою очередь, одним из компонентов бизнес-архитектуры, заслуженно привлекающим первоочередное внимание и требующим пристального рассмотрения в контексте реализации самых разнообразных бизнес-инициатив, является процессная архитектура.
Грамотно передать суть и содержание бизнес-процессов современного предприятия не так просто, как может показаться на первый взгляд. Растущая сложность внутри- и межкорпоративных взаимодействий является одной из основных причин того, что на сегодняшний день мы наблюдаем быструю смену целых поколений языков описания бизнес-процессов. Действительно, языки, востребованные в 1990-х – 2000-х гг., стремительно уступают место новым нотациям моделирования, сложность которых поначалу ставит в тупик даже опытных аналитиков. Одним из ярких примеров таких сложных, но актуальных нотаций является язык BPMN 2.0.
Наконец, дисциплина бизнес-моделирования становится по-настоящему значимой только в контексте коммуникации как практики передачи знания о процессной архитектуре предприятия от человека к человеку или от человека — к машине; а коммуникации процессной архитектуры, как и любой другой, нужно последовательно учиться.
В лекциях для студентов ИГХТУ (Иваново) и БГУИР (Минск) проанализирован и обобщен практический опыт применения моделей бизнес-процессов для описания текущих и целевых состояний процессной архитектуры предприятий, подведен теоретический базис под современные представления о подходах к решению задач коммуникации архитектуры, приведен ряд примеров
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...Alex V. Petrov
Системная инженерия, известная еще с советских времен как «системотехника», в последние десятилетия претерпела серьезные трансформации не только в России, но и за рубежом. Достаточно сказать, что на английском языке эта междисциплинарная область знаний приобрела в своем названии новый смысл: «инжиниринг системы» (англ. System Engineering) сменил «инжиниринг систем» (англ. Systems Engineering). Отечественные вузы, по объективным причинам утратившие за последние 20 лет экспертизу в области преподавания системотехники, сегодня оказались неспособны предлагать рынку выпускников, готовых, умеющих, а главное — знающих, как браться за разработку сложных систем и доводить ее до конца, отвечать за основополагающие принципы создания и функционирования таких систем, иными словами — архитектуру.
Между тем, системная инженерия возвращается в учебные планы программ подготовки магистров по таким направлениям, как «Информатика и вычислительная техника». Впрочем, строчка в учебном плане — еще не гарантия успеха в преподавании.
В своем докладе мы поделимся личным опытом преподавания системной инженерии в ведущих технических вузах столиц России: Московском государственном техническом университете (МГТУ) им. Н.Э. Баумана и Санкт-Петербургском государственном электротехническом университете «ЛЭТИ» им. В.И. Ульянова (Ленина) (СПбГЭТУ ЛЭТИ), — расскажем о контексте, в котором велась подготовка авторских учебных программ, лекционных и практических материалов, проблемах, которые возникали в ходе образовательного процесса.
Говоря о результатах, которых удалось достичь авторам с 2013/2014 уч. года и по сей день, мы остановимся на двух главных. Пер�
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
ITGM #5. What Is Enterprise Architecture [1.0, RUS]Alex V. Petrov
«Экономический дарвинизм» XXI в. делает предприятия все более уязвимыми в жесткой конкурентной борьбе. Сегодня мы наблюдаем радикальную трансформацию даже самых консервативных отраслей, не говоря уже о «новой экономике» и высокотехнологичных сферах. Бизнес стремительно осваивает принципиально иные средства производства, каналы коммуникаций, виды инфраструктуры и постоянно перевооружается в попытке опередить соперников по борьбе за клиента. И не всегда удачно.
В этих условиях вопросы эффективного проектирования корпоративной архитектуры (англ. Enterprise Architecture, EA) приобретают все большую актуальность. Из чего складывается такая архитектура и в чем ее отличие от ИТ- и бизнес-архитектуры? Какая она бывает? Как правильно ее создавать? Актуальна ли проблематика корпоративной архитектуры для малого и среднего бизнеса и возможно ли «масштабирование вниз» классических архитектурных подходов?
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
Архитектура предприятия как системы охватывает такие области, как информационно-технологическая и бизнес-архитектура. В свою очередь, одним из компонентов бизнес-архитектуры, заслуженно привлекающим первоочередное внимание и требующим пристального рассмотрения в контексте реализации самых разнообразных бизнес-инициатив, является процессная архитектура.
Грамотно передать суть и содержание бизнес-процессов современного предприятия не так просто, как может показаться на первый взгляд. Растущая сложность внутри- и межкорпоративных взаимодействий является одной из основных причин того, что на сегодняшний день мы наблюдаем быструю смену целых поколений языков описания бизнес-процессов. Действительно, языки, востребованные в 1990-х – 2000-х гг., стремительно уступают место новым нотациям моделирования, сложность которых поначалу ставит в тупик даже опытных аналитиков. Одним из ярких примеров таких сложных, но актуальных нотаций является язык BPMN 2.0.
Наконец, дисциплина бизнес-моделирования становится по-настоящему значимой только в контексте коммуникации как практики передачи знания о процессной архитектуре предприятия от человека к человеку или от человека — к машине; а коммуникации процессной архитектуры, как и любой другой, нужно последовательно учиться.
В лекциях для студентов ИГХТУ (Иваново) и БГУИР (Минск) проанализирован и обобщен практический опыт применения моделей бизнес-процессов для описания текущих и целевых состояний процессной архитектуры предприятий, подведен теоретический базис под современные представления о подходах к решению задач коммуникации архитектуры, приведен ряд примеров
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...Alex V. Petrov
Системная инженерия, известная еще с советских времен как «системотехника», в последние десятилетия претерпела серьезные трансформации не только в России, но и за рубежом. Достаточно сказать, что на английском языке эта междисциплинарная область знаний приобрела в своем названии новый смысл: «инжиниринг системы» (англ. System Engineering) сменил «инжиниринг систем» (англ. Systems Engineering). Отечественные вузы, по объективным причинам утратившие за последние 20 лет экспертизу в области преподавания системотехники, сегодня оказались неспособны предлагать рынку выпускников, готовых, умеющих, а главное — знающих, как браться за разработку сложных систем и доводить ее до конца, отвечать за основополагающие принципы создания и функционирования таких систем, иными словами — архитектуру.
Между тем, системная инженерия возвращается в учебные планы программ подготовки магистров по таким направлениям, как «Информатика и вычислительная техника». Впрочем, строчка в учебном плане — еще не гарантия успеха в преподавании.
В своем докладе мы поделимся личным опытом преподавания системной инженерии в ведущих технических вузах столиц России: Московском государственном техническом университете (МГТУ) им. Н.Э. Баумана и Санкт-Петербургском государственном электротехническом университете «ЛЭТИ» им. В.И. Ульянова (Ленина) (СПбГЭТУ ЛЭТИ), — расскажем о контексте, в котором велась подготовка авторских учебных программ, лекционных и практических материалов, проблемах, которые возникали в ходе образовательного процесса.
Говоря о результатах, которых удалось достичь авторам с 2013/2014 уч. года и по сей день, мы остановимся на двух главных. Пер�
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
ITGM #5. What Is Enterprise Architecture [1.0, RUS]Alex V. Petrov
«Экономический дарвинизм» XXI в. делает предприятия все более уязвимыми в жесткой конкурентной борьбе. Сегодня мы наблюдаем радикальную трансформацию даже самых консервативных отраслей, не говоря уже о «новой экономике» и высокотехнологичных сферах. Бизнес стремительно осваивает принципиально иные средства производства, каналы коммуникаций, виды инфраструктуры и постоянно перевооружается в попытке опередить соперников по борьбе за клиента. И не всегда удачно.
В этих условиях вопросы эффективного проектирования корпоративной архитектуры (англ. Enterprise Architecture, EA) приобретают все большую актуальность. Из чего складывается такая архитектура и в чем ее отличие от ИТ- и бизнес-архитектуры? Какая она бывает? Как правильно ее создавать? Актуальна ли проблематика корпоративной архитектуры для малого и среднего бизнеса и возможно ли «масштабирование вниз» классических архитектурных подходов?
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...Alex V. Petrov
На примере одной специализированной, но значимой для большинства высокопроизводительных систем точки оптимизации исходного кода — работы с кэш-памятью — доклад «Достижима ли в C++ эффективность языка "среднего уровня"?», сделанный на DEV Labs 2013, показывает, какими несложными приемами и техниками можно достичь желаемого уровня эффективности объектно-ориентированного кода, и развеивает миф о языке C++ как языке «архитектурной астронавтики», предлагая аудитории ряд действенных рецептов повышения производительности исходного кода.
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]Alex V. Petrov
Управление заинтересованными сторонами — одна из ключевых техник бизнес-анализа, которая обсуждалась на «Вечере системного и бизнес-анализа» в С.-Петербурге 06 июня 2015 г. Ключевые вопросы: заинтересованные стороны и их интересы, точки зрения и представления; основные шаги управления заинтересованными сторонами, шаблон карты заинтересованных сторон по TOGAF9.
Практический анализ и визуальное моделирование на UMLNikolai Kireev
Презентация курса online-тренингов, проводимых совместно Школой Системного Анализа г. Москва и IT-Студией WebMax.BY г. Минск.
Запись на курс по ссылке: http://school.system-analysis.ru/uml-online/
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...DEVTYPE
Основы современной методологии объектно-ориентированного анализа и проектирования. Особенности визуального моделирования информационных систем. Базовые семантические конструкции языка UML 2 и их описание с помощью специальных обозначений. Основные элементы нотации языка UML 2 и их отличие от языка UML 1. Особенности моделей представления структуры и поведения в проектах разработки сложных программных систем и бизнес-процессов. Канонические диаграммы языка UML 2 и их общая характеристика. Механизмы расширения языка UML 2.
Понятия технологии разработки объектно-ориентированных информационных систем ...Aimurat Adilbekov
ПЛАН:
1. Причины неудачных проектов
2. Отсутствие моделей при разработке ПО
3. Лучшие практики разработки ПО
4. Что такое визуальное моделирование?
5. Основные понятия визуального моделирования
6. Классификация проектов по сложности
7. Основные понятия ООП
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...Alex V. Petrov
На примере одной специализированной, но значимой для большинства высокопроизводительных систем точки оптимизации исходного кода — работы с кэш-памятью — доклад «Достижима ли в C++ эффективность языка "среднего уровня"?», сделанный на DEV Labs 2013, показывает, какими несложными приемами и техниками можно достичь желаемого уровня эффективности объектно-ориентированного кода, и развеивает миф о языке C++ как языке «архитектурной астронавтики», предлагая аудитории ряд действенных рецептов повышения производительности исходного кода.
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]Alex V. Petrov
Управление заинтересованными сторонами — одна из ключевых техник бизнес-анализа, которая обсуждалась на «Вечере системного и бизнес-анализа» в С.-Петербурге 06 июня 2015 г. Ключевые вопросы: заинтересованные стороны и их интересы, точки зрения и представления; основные шаги управления заинтересованными сторонами, шаблон карты заинтересованных сторон по TOGAF9.
Практический анализ и визуальное моделирование на UMLNikolai Kireev
Презентация курса online-тренингов, проводимых совместно Школой Системного Анализа г. Москва и IT-Студией WebMax.BY г. Минск.
Запись на курс по ссылке: http://school.system-analysis.ru/uml-online/
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...DEVTYPE
Основы современной методологии объектно-ориентированного анализа и проектирования. Особенности визуального моделирования информационных систем. Базовые семантические конструкции языка UML 2 и их описание с помощью специальных обозначений. Основные элементы нотации языка UML 2 и их отличие от языка UML 1. Особенности моделей представления структуры и поведения в проектах разработки сложных программных систем и бизнес-процессов. Канонические диаграммы языка UML 2 и их общая характеристика. Механизмы расширения языка UML 2.
Понятия технологии разработки объектно-ориентированных информационных систем ...Aimurat Adilbekov
ПЛАН:
1. Причины неудачных проектов
2. Отсутствие моделей при разработке ПО
3. Лучшие практики разработки ПО
4. Что такое визуальное моделирование?
5. Основные понятия визуального моделирования
6. Классификация проектов по сложности
7. Основные понятия ООП
IT CAMPUS. How to Stop Worrying and Clear Your Technical Debt [RUS]Alex V. Petrov
В конференционном блоке слета IT Campus 2014 (Калужская обл., 25 – 27 июля 2014 г.) состоялся доклад Алексея Петрова на тему «Как перестать беспокоиться и погасить технический долг?». Из него слушатели узнали, что такое «технический долг» проекта и почему разработчики — не единственные, кто должен про него знать; что нужно для выплаты долга, в чём состоят «техническая инфляция» и «техническое банкротство»; когда можно принимать «технический долг» и чего следует опасаться; как оценить «технический долг» и как его правильно погашать. Завершило дискуссию обсуждение мифов и заблуждений, сопровождающих метафору «технического долга», и рассмотрение личного опыта докладчика и участников слета.
В данном докладе мы рассмотрим пять основных принципов дизайна классов в объектно-ориентированном проектировании, которые известны, как принципы SOLID. А также как обеспечить достаточный уровень гибкости, связанности, управляемости, стабильности и понятности кода.
Блок-схема - это графическое отображение процесса, которое четко показывает, как протекает процесс. Блок-схема показывает систематическую последовательность этапов выполнения работы и то, какие ресурсы (люди, материал, машины…) вовлечены в процесс.
Скачать презентацию Вы можете перейдя по ссылке: http://sixsigmaonline.ru/load/16-1-0-4
Объединение систем моделирования и исполнения бизнес-процессов в единой инфор...Andrey Shumakov
15 апреля 2014 года Андрей Шумаков директор по ИТ LifeNet прочитал семинар в Высшей школе бизнес информатики по теме: «Объединение систем моделирования и исполнения бизнес-процессов в единой информационной среде».
На семинаре ведущий рассказал о важности нового процессного подхода, в котором сочетается как моделирование, так и исполнение процессов в рамках единой среды. Было рассказано о тренде развития информационных систем – появление BPM систем. В рамках выступления было обозначено несколько ключевых вопросов.
Выступление началось с рассказа о важности процессного мышления в бизнесе.
Была обозначена связь и отличия «данных» от «процессов».
Внимательно были рассмотрены различия в традиционном процессном подходе от подхода, применяемого в системах BPM.
Освещена тема важности моделирования и исполнения процессов, которые не видны методом прямого структурного анализа экспертам в бизнес-аналитике.
Поднят важный вопрос о способах моделирования и запуска новой деятельности в рамках исполнения на информационных системах. Данная тема вызвала большой интерес аудитории, было задано много вопросов рамках конструктивной дискуссии.
Семинар положил основу для дальнейшего цикла семинаров с освещением важных тем в области бизнес-информатики и процессного подхода.
Построение систем автоматического протоколирования Си/Си++ кодаTatyanazaxarova
Иногда единственным методом отладки является использование протоколирования событий приложения. К недостаткам протоколирования (логирования) можно отнести большой объем кода, который приходится писать вручную для сохранения всей необходимой информации. В статье рассматривается методика, позволяющая построить систему автоматического протоколирования кода на языке Си/Си++.
UML2. Eleven Trivial Tips for BPMN Modellers [1.01, RUS]
1.
2. РАЗРЕШИТЕ ПРЕДСТАВИТЬСЯ
АЛЕКСЕЙ ПЕТРОВ
тренер и консультант, эксперт-практик в области анализа и
моделирования бизнес-процессов, системного анализа,
архитектуры ПО, системной и программной инженерии
2013 – 2014:
докладчик конференций Stratoplan TECH & BUSINESS Summit 2013
(поток «Проектирование и анализ»), Luxoft DEV Labs C++ 2013,
Luxoft REQ Labs 2014 и слета IT Campus 2014. Модератор
X Международной конференции CEE-SECR 2014
2012 — наст. вр.:
преподаватель НИУ МГТУ им. Н.Э. Баумана и совместного проекта
НИУ МГТУ им. Н.Э. Баумана и Mail.Ru Group «Технопарк@Mail.Ru»
2013 — наст. вр.:
автор и ведущий тренингов по BPMN 2.0 в Беларуси, Казахстане,
Литве, России
2011 — наст. вр.:
автор и ведущий серии курсов по описанию бизнес- и
программной архитектуры и постановке внутренней разработки
2004 — наст. вр.:
участник более 10 проектов внедрения корпоративных ИС,
моделирования бизнес-процессов и ИТ-аудита организаций
2
3. МЕТОДИЧЕСКИЕ
И ОРГАНИЗАЦИОННЫЕ ПОЛОЖЕНИЯ
1
2
3
Цели семинара
Представить аудитории ряд простых способов повышения качества
моделей бизнес-процессов (БП) в нотации BPMN 2.0,
проиллюстрировав каждую из рекомендаций примером БП на
описательном или аналитическом уровне
Предварительная подготовка
Уверенное владение основными элементами нотации BPMN 2.0 не
обязательно для участия, но настоятельно рекомендуется для
успешного восприятия и самостоятельной проработки материала
Перспективы
Придерживаясь данных рекомендаций, каждый участник сможет:
унифицировать личную и командную технику;
добиться однозначной интерпретации моделей;
преодолевать самые известные ограничения BPMN 2.0;
заложить основу корпоративного соглашения о BPMN-
моделировании на описательном и аналитическом уровне
3
4. О ЧЕМ ПОЙДЕТ РЕЧЬ?
1
2
3
«Фишки» грамматики
#1. «Есть у революции начало…»: исполняем обязательные
элементы
#2. «Успешный путь»: слалом — не наш вид спорта
#3. «Правило 2С»: действуем структурно и симметрично
«Фишки» семантики
#4. «Лёд и пламень»: надо ли совмещать несовместное?
#5. «Человек и машина»: доверяем компьютеру
#6. «Сто мелочей»: наши маленькие помощники
#7. «Ручная работа»: какая она бывает?
«Фишки» прагматики
#8. «Как вы лодку назовете…»: естественный язык — в действии
#9. «Бритва Оккама»: можно ли сократить… модель?
#10. «Кому это выгодно?»: нет — механистическому подходу!
#11. «Бездна премудрости»: используем BPMN-шаблоны
4
6. ТРИ УРОВНЯ ПРИМЕНЕНИЯ BPMN
ПО Б. СИЛЬВЕРУ
6
Наименование
уровня
Набор
символов
Цели
Целевая
аудитория
Соотв.
стандарту
Сложность
Описательный
Ограничен
ный
Документирование
действий
Бизнес Условное Умеренная
Аналитический Полный
Документирование
событий и
исключений
Бизнес, ИТ
Вполне
строгое
Высокая
Исполняемый Полный
Исполнение
процессов
(сервисы,
сообщения и пр.)
ИТ, BPMS Строгое Высокая
7. «Есть у революции начало…»:
исполняем обязательные
элементы
«Успешный путь»: слалом — не наш
вид спорта
«Правило 2С»: действуем структурно
и симметрично
7
8. #1. «ЕСТЬ У РЕВОЛЮЦИИ НАЧАЛО…»:
ИСПОЛНЯЕМ ОБЯЗАТЕЛЬНЫЕ ЭЛЕМЕНТЫ
Описание
Стандарт OMG не требует наличия на диаграмме начальных
[“Start Event is OPTIONAL”] и заключительных событий , однако
их присутствие существенно упрощает чтение, повышая
наглядность модели в целом
NB: Стандарт требует наличия хотя бы одного начального события,
если на диаграмме имеется заключительное, а также не
рекомендует использовать более одного начального события
8
В ДАЛЬНЕЙШЕМ ПУЛЫ И ДОРОЖКИ БУДУТ ПРЕДСТАВЛЕНЫ ИСКЛЮЧИТЕЛЬНО
НА МОДЕЛЯХ, ГДЕ ОНИ ЯВЛЯЮТСЯ ПРЕДМЕТОМ ОТДЕЛЬНОГО РАССМОТРЕНИЯ
9. #2. «УСПЕШНЫЙ ПУТЬ»:
СЛАЛОМ — НЕ НАШ ВИД СПОРТА
9
Описание
Основной успешный сценарий (англ. “happy path”) БП ведет к
достижению желаемого (наблюдаемого) результата наиболее
эффективным способом и обязательно формирует ценность
для бенефициара БП
NB: Многократное отклонение успешного сценария от основной
линии взгляда (см. рис.) ведет к созданию «слалом»-диаграмм
Подробности
Сильнее всего чтение диаграмм ухудшают длинные и
пересекающиеся линии, а также их перегибы, переходы
вперед и назад по подразумеваемой оси времени,
смешение основного
и дополнительных
сценариев
10. #3. «ПРАВИЛО 2С»:
ДЕЙСТВУЕМ СТРУКТУРНО И СИММЕТРИЧНО
Описание
Модель структурна и симметрична, если любому шлюзу
с разветвлением потоков соответствует шлюз с объединением
потоков того же вида.
NB: Соответствие шлюзов формирует простую для понимания и
анализа блочную структуру модели, а также снижает
вероятность возникновения тупиков (англ. livelocks, deadlocks)
10
11. ДОПОЛНИТЕЛЬНЫЕ СОВЕТЫ
ПО ИСПОЛЬЗОВАНИЮ ШЛЮЗОВ (1 / 2)
Отображение маркера “X”
Отображение на шлюзе «исключающее ИЛИ»
явного маркера упрощает его восприятие
неподготовленными читателями
NB: Маркер “X” должен присутствовать всюду на
диаграмме или отсутствовать везде
Ограничения по входам/выходам
Один и тот же шлюз не должен использоваться для слияния и
разделения последовательных потоков (единственная «лучшая
практика», приведенная в стандарте OMG, причем дважды!)
Суммарное количество используемых входов и выходов шлюза
не должно превышать четырех, а линии потока управления
должны начинаться или заканчиваться строго на вершинах
фигуры (но не на ее сторонах, хотя это также разрешено!)
11
Недопущение останова процесса
Условия на исходящих потоках шлюза «ИЛИ» на разветвление
должны быть заданы так, чтобы не допустить ситуации, в которой
все эти условия ложны. Среди прочего в этих целях могут
использоваться потоки по умолчанию
12. ДОПОЛНИТЕЛЬНЫЕ СОВЕТЫ
ПО ИСПОЛЬЗОВАНИЮ ШЛЮЗОВ (2 / 2)
Отказ от подразумеваемых шлюзов
Подразумеваемые шлюзы на входе и выходе деятельностей
различаются: на входе подразумевается «исключающее ИЛИ»,
на выходе подразумевается «И», — что не способствует
улучшению восприятия всей модели
12
13. «Лёд и пламень»: надо ли совмещать
несовместное?
«Человек и машина»: доверяем
компьютеру
«Сто мелочей»: наши маленькие
помощники
«Ручная работа»: какая она бывает?
13
14. #4. «ЛЁД И ПЛАМЕНЬ»:
НАДО ЛИ СОВМЕЩАТЬ НЕСОВМЕСТНОЕ?
Описание
Заключительные события с различной смысловой нагрузкой
не следует объединять , обосновывая такое решение
удобством чтения, простотой размещения элементов или
иными соображениями
14
15. #5. «ЧЕЛОВЕК И МАШИНА»:
ДОВЕРЯЕМ КОМПЬЮТЕРУ
Описание
При моделировании автоматически выполняемых операций
конкретной ИС (или их совокупности) можно выделить
отдельную дорожку в рамках пула БП
NB: Содержимое выделенной дорожки, строго говоря, могут
составлять только задачи-сервисы (Service Tasks) или задачи-
сценарии (Script Tasks), если соответствующие действия
поддержаны скриптами BPMS
15
16. #6. «СТО МЕЛОЧЕЙ»:
НАШИ МАЛЕНЬКИЕ ПОМОЩНИКИ
Описание
Наряду с текстовыми аннотациями (суть артефактами)
существенную пользу — в условиях отсутствия соответствующих
выразительных средств — приносит использование в BPMN 2.0
• объектов данных, удобных для представления бизнес-
сущностей и их инфологического представления в ИС;
• хранилищ данных, пригодных для моделирования самих ИС
16
17. #7. «РУЧНАЯ РАБОТА»: КАКАЯ ОНА БЫВАЕТ?
Описание
Стандарт OMG определяет
• пользовательскую задачу (User Task) как типовую часть потока
работ, выполняемую при помощи ПО и планируемую
посредством какого-либо инструментария управления;
• ручную задачу (Manual Task) как задачу, исполнение которой,
как ожидается, происходит без помощи ядра исполнения БП
или какого бы то ни было приложения
17
Рекомендуемая семантика
Наш опыт показывает, что под ручной задачей,
при описании БП с точки зрения пользователей
ИС 𝒜 или самой ИС 𝒜, целесообразно
понимать операцию, выполняемую вручную или
в любой сторонней системе ℬ ≠ 𝒜.
Аналогично, под пользовательской задачей
следует понимать операцию, выполняемую в
моделируемой ИС при участии оператора
NB: К ручным и пользовательским задачам
относятся и задачи, поддержанные тем или
иным бизнес-правилом, не имеющим
реализации в ядре исполнения БП
18. «Как вы лодку назовете…»:
естественный язык — в
действии
«Бритва Оккама»: можно ли
сократить… модель?
«Кому это выгодно?»: нет —
механистическому подходу!
«Бездна премудрости»: используем
BPMN-шаблоны
18
19. #8. «КАК ВЫ ЛОДКУ НАЗОВЕТЕ…»:
ЕСТЕСТВЕННЫЙ ЯЗЫК — В ДЕЙСТВИИ
Описание
Входящие в состав диаграммы элементы различных типов
должны подчиняться различным правилам, определяющим
порядок именования
19
20. #9. «БРИТВА ОККАМА»:
МОЖНО ЛИ СОКРАТИТЬ… МОДЕЛЬ?
Описание
Каждый элемент диаграммы должен включаться в нее только
в случае реальной необходимости и увеличивать ее ценность
Элементы диаграммы, не добавляющие
ценность модели, должны отбрасываться
в пользу документирования
20
Подробности
В BPMN-сообществе доминируют
два подхода к оценке субъективной
сложности диаграмм
Уильям
Оккам
10 …
… 15
максимальное число
деятельностей на
одной диаграмме
30 …
… 50
максимальное
число элементов
любого рода
23. #10. «КОМУ ЭТО ВЫГОДНО?»:
НЕТ — МЕХАНИСТИЧЕСКОМУ ПОДХОДУ!
Описание
Декомпозиция БП как способ снижения сложности их моделей
не должна сводиться с формальному «разрезанию» процесса
на две или более части
Выделяемый из БП фрагмент должен иметь наблюдаемый
результат, формировать ценность и иметь бенефициара
Если такая фрагментация БП не представляется возможной,
процесс должен «разрезаться» на несколько секций внутри
одной диаграммы, например, при помощи Link Event
23
24. #11. «БЕЗДНА ПРЕМУДРОСТИ»:
ИСПОЛЬЗУЕМ BPMN-ШАБЛОНЫ
Описание
Стандартные решения типовых задач BPMN-моделирования
можно «очищать» от исходного контекста, каталогизировать и
многократно использовать аналогично шаблонам Enterprise
Data / Integration Patterns или шаблонам GRASP
24
26. НАШИ ПАРТНЕРЫ: ОБУЧЕНИЕ В ОБЛАСТИ
BA/SA И КОРПОРАТИВНОЙ АРХИТЕКТУРЫ
26
Учебный центр Level UP
Один из ведущих центров России в области обучения и
консалтинга по направлениям:
• архитектура (вкл. EA), проектирование и тестирование ПО;
• BA/SA и управление проектами;
• разработка (Web, mobile) и администрирование.
Преимущества УЦ Level UP:
• коллектив «играющих тренеров»;
• адаптируемые практико-ориентированные программы и
ускоренные методики обучения (в т.ч. онлайн-обучение);
• закрытая база вакансий для лучших выпускников.
Ближайшие тренинги
01 – 05 июня 2015 г. — «Системный и бизнес-анализ в
разработке ПО» (С.-Петербург, очно / удаленно)
08 – 09 июня 2015 г. — «Моделирование бизнес-процессов
диаграммами BPMN 2.0» (С.-Петербург, очно / удаленно)
НЕ ЗАБУДЬТЕ ПОЛУЧИТЬ ПРОМОКОД,
ДАЮЩИЙ ПРАВО НА ПОЛУЧЕНИЕ СКИДКИ В РАЗМЕРЕ 10%!
27. НАШИ ПАРТНЕРЫ: АВТОМАТИЗАЦИЯ
УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССАМИ
27
Внедренческая компания «Оптима-Софт»
Основана в 2010 г. в С.-Петербурге и обладает большим опытом
работы на рынке интеллектуальных услуг. Специализируется на
выпуске собственных решений и автоматизации бизнеса на
платформе 1С
BPM-система «ОптимаСофт:Менеджер
процессов»
Отечественная система для управления бизнес-процессами на
платформе «1С:Предприятие», полностью интегрируемая с
действующим ИТ-ландшафтом компании.
Преимущества BPMS «ОптимаСофт:Менеджер процессов»
• Поддержка нотаций IDEF0, ARIS eEPC, языка блок-схем и BPMN
• Выполнение моделей в нотации BPMN
• Поддержка KPI и стратегических карт
• Бесплатная работа до 10 пользователей
• Открытый код системы
• Возможности расширения кодом 1С
28. БЛИЖАЙШИЕ ВЫСТУПЛЕНИЯ (1 / 3)
28
❶ IT Global Meetup #5
Место, дата: Санкт-Петербург, 06 июня 2015 г.
Тема #1: «Дуализм систем и его практическая польза
для аналитика»
Тема #2: уточняется
• корпоративная архитектура / TOGAF9 vs.
количественные метрики в ОО-архитектуре;
• «технический долг» и человеческий фактор vs.
тенденции в C++ vs. антишаблоны ОО-
проектирования
29. БЛИЖАЙШИЕ ВЫСТУПЛЕНИЯ (2 / 3)
29
❷ Вечер системного и БА
Место, дата: Санкт-Петербург, 06 июня 2015 г.
Тема #1: «Управление заинтересованными
сторонами»
Управление заинтересованными сторонами (ЗС) —
одна из ключевых техник бизнес-анализа,
которую мы обсудим в первой практической
части встречи. В нашей повестке: ЗС, интересы,
точки зрения и представления; основные шаги
управления ЗС; шаблон карты ЗС
Тема #2: «Шаблоны BPMN-моделирования»
В ходе решения задач моделирования процессной
архитектуры предприятий нередко возникают
типовые задачи, предполагающие стандартные
решения. В ходе второй практической части
встречи мы вкратце обсудим несколько ярких и
интересных шаблонов BPMN-моделирования
разного уровня сложности
30. БЛИЖАЙШИЕ ВЫСТУПЛЕНИЯ (3 / 3)
30
❸ Мастер-класс на ЛАФ-2015
Место, дата: Иваново, 20 июня 2015 г.
Тема: «Личная эффективность системного аналитика»
• На мастер-классе наше внимание будет
сосредоточено на эффективной коммуникации.
В ходе 90-минутной сессии мы поделимся
личными секретами мастерства, заглянем в те
области человеческой деятельности, где во главе
угла также стоит общение, и уясним, что ценного
для ежедневной практики системного
и бизнес-анализа можно в них почерпнуть
• Голосование за включение мастер-класса в
программу ЛАФ-2015 завершится 01.06.2015.
• Количество мест ограничено!
❹ Тренинги в Санкт-Петербурге
• Системный и бизнес-анализ в разработке ПО
• Моделирование БП диаграммами BPMN 2.0
31. БЛАГОДАРНОСТИ
Автор и ведущий семинара выражает свою
искреннюю признательность за содействие и
помощь в организации мероприятия:
• «Сообществу аналитиков» UML2.Ru
и лично г-ну Григорию Печёнкину;
• учебному центру Level UP (г. Санкт-Петербург)
и лично г-ну Алексею Ханько;
• а также всем участникам тренингов
по BPMN 2.0, предшествовавших данному
семинару, за обширный фактический
материал и предложенные к разбору
многочисленные примеры реальных БП
31
32. СПАСИБО ЗА ВНИМАНИЕ!
❶ Собственные источники
В ходе подготовки семинара использовались
материалы авторского тренинга А.В. Петрова
«Моделирование БП диаграммами BPMN 2.0»
(2013 – наст. вр.)
❷ Контакты
32
«Сообщество
аналитиков»
Профиль ведущего
в сети LinkedIn
34. ЧТО ИЗУЧИТЬ? (1 / 2)
Allweyer, T. Human-Readable BPMN Diagrams (Ver. 1.1, 2010).
BPMN 2.0 Poster (Berliner BPM-Offensive). URL:
http://www.bpmb.de/index.php/BPMNPoster
BPMN 2.0 by Example: non-normative OMG document with BPMN
2.0 examples (2010). URL: http://www.omg.org/cgi-
bin/doc?dtc/10-06-02
BPMS Watch: Ten Tips for Effective Process Modeling. URL:
http://www.bpminstitute.org/resources/articles/bpms-watch-ten-
tips-effective-process-modeling
Business Process Model and Notation. Ver. 2.0. URL:
www.omg.org/spec/BPMN/2.0/
Debevoise, T., Geneva, R. The Microguide to Process Modeling in
BPMN 2.0 (Advanced Component Research, 2011)
34
35. ЧТО ИЗУЧИТЬ? (2 / 2)
Efficient BPMN: from Anti-Patterns to Best Practices. URL:
http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/
2438/Efficient-BPMN-from-Anti-Patterns-to-Best-Practices.aspx
Freund, J., Rucker, B. Real-Life BPMN: Using BPMN 2.0 to Analyze,
Improve, and Automate Processes in Your Company (2012).
Object Management Group Business Process Model and Notation. URL:
http://www.bpmn.org/
Shapiro, R., et al. BPMN 2.0 Handbook (Future Strategies, 2011).
Šilingas, D..Improving Process Models for Better Understanding and
Analysis. URL: http://www.slideshare.net/ICV_eV/5-211011darius-
silingasimprovingprocessmodelsforbetterunderstandingandanalysis
Федоров И. Моделирование бизнес-процессов в нотации BPMN 2.0 /
Научно-практическое издание. — М: МЭСИ, 2013. — 264 с.
35