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

Даниил Булычев пишет: Если бы не было противоречия интересов, то и бизнес-аналитики бы не понадобились. Без них бы договорились. В том и искусство бизнес-аналитика, чтобы примирить между собой противоречивые цели. Не все реально, но многое.

Этот вопрос в области определения обязанностей "бизнес-аналитика" :) в моём понимании, это человек, способный в первую очередь, добывать информацию, делать выводы и предлагать решения; и не обязательно примиряющие, а напротив, иногда расстрельные. Способный просигнализировать о противоречии интересов, правильно их донести и выдержать "защиту". О том, чтобы кого-то примирить, или расстрелять, БА, в моём понимании, должен думать в последнюю очередь, т.к. это прерогатива собственника. Возвращаясь к исходному вопросу, нужно определить, смогут ли лица, помимо преподнесения отличного комплекта документов и бизнес-модели (по сути, это всего лишь артефакты решения бизнес-задачи), правильно поставить бизнес-задачу и преподнести её решение в понятных для заказчика терминах: (1) на какие операционные показатели следует обращать внимание ежедневно, еженедельно, чтобы... (2) какой должна быть организационная структура, чтобы... (3) как именно должен быть "размежёваны" ресурсы и ответственность между её элементами, чтобы..., (4) каким, в общих разумеется чертах, должно быть рабочее расписание задействованных в процессе сотрудников, чтобы... (5) какие проекты и доработки должны быть проведены в ИТ-системах, в обучении сотрудников, чтобы... Вот это реальный отчет, который я в настоящее время ваяю :) Диаграмма бизнес-процессов и программный продукт всего лишь помогли ! мне ! понять, что именно войдет в список (1)-(5). Включать диаграмму, упаси б-г, в финальный отчет, наряду с терминами "входы", "выходы", "управление", я не буду :) А уж на основе этого, топ примет решение: кого-то примирить, кого-то застрелить. Не надо никого примирять, дайте деперсонифицированный анализ.

Александр Абрамов пишет: Этот вопрос в области определения обязанностей "бизнес-аналитика"в моём понимании, это человек, способный в первую очередь, добывать информацию, делать выводы и предлагать решения; и не обязательно примиряющие, а напротив, иногда расстрельные. Способный просигнализировать о противоречии интересов, правильно их донести и выдержать "защиту". О том, чтобы кого-то примирить, или расстрелять, БА, в моём понимании, должен думать в последнюю очередь, т.к. это прерогатива собственника.

Противоречие интересов чаще всего не является личностным. как правило они носят системный характер. Личности защищают данные интересы лишь находясь на конкретных позициях. Пример? Клиент хочет много, дешево, разнообразно. Поставщик строго наоборот. Одна и та же личность может одновременно защищать и те и другие интересы, будучи клиентом для одних и поставщиком для других. В задачу аналитика, кроме того что вы написали, входит и разделение противоречий. Где-то они системные - тогда расстрел бесполезен. А где-то субъективны - тогда расстрел ессно благо. Задача по примирению опять же важна. Ибо любой конфликт это трата ресурсов собственника. Системный конфликт - вечная трата. Значит, обнаружить противоречия и найти способ избежать их (или смягчить) - работа БА.

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

В случае, когда описание БП является частью более крупного проекта, конечно да. Одними артефактами уже не обойтись.

Описывал сам. С самого первого проекта в далеком 2000 году. По моему скромному мнению-проще научить своих сотрудников, чем приглашать консультатнтов. И самое главное-пока не ответите на вопрос: ЗАЧЕМ вам это надо, не начинайте работу.

Каждый должен заниматься своим делом: стоит воспользоваться сторонними услугами. Выбор программы предопределяет многое. По сути практически все продукты на этом рынке - это платформы, и все мелочи, детали дорабатываются за отдельную плату. Формализовывать бизнес-процессы нужно в общепринятой нотации. В процессе своего выбора остановился на нотации BPM - есть российский инструмент этого класса: ELMA - но подходит только для исполняемых процессов и еще есть модуль KPI

Иван Чегменцев,

российский инструмент этого класса: ELMA - но подходит только для исполняемых процессов

интересно, а что в понятиях ЭЛМА или в ваших понятиях относится к категории "не исполняемых" процессов?

Анатолий Юмашев пишет: Иван Чегменцев,

российский инструмент этого класса: ELMA - но подходит только для исполняемых процессов

интересно, а что в понятиях ЭЛМА или в ваших понятиях относится к категории "не исполняемых" процессов?

Разные объекты (бизнес-процессы) требуют разного языка и семантики описания. Не сочтите за саморекламу, но может быть коллегам поможет такая классификация бизнес-процессов: http://www.finexpert.ru/view/bor_ba_protsessov_s_biznes_protsessami_eto_bitva_tigra_s_drakonom/719 С уважением Виталий.

в ваших понятиях относится к категории "не исполняемых" процессов?

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

Поправьте меня если я ошибаюсь, но процесс это вид действия, действие или процесс может быть исполнен или не исполнен.
Это значит что процесс он по своей природе исполняемый. Не исполняемых процессов не бывает в природе.

Если говорить о стратегии, как о некой норме поведения, то это норма, а не процесс.
Если говорить о стратегии, как о неком порядке действия для достижения какой либо цели, то это называется "программа действий" если по западном, или просто "программа" если говорить о понятиях в России.

Виталий Елиферов пишет: Разные объекты (бизнес-процессы) требуют разного языка и семантики описания.

Зачем? Любой процесс описывается блок-схемой. Исполнители отдельных этапов могут различаться пониманием блок-схемы (сотрудники, программисты, автоматы). Вот на этом уровне уже нужно детализировать для каждого на своем языке. Но только здесь, а не уровнем выше.

Не сочтите за саморекламу, но может быть коллегам поможет такая классификация бизнес-процессов: http://www.finexpert.ru/view/bor_ba_protsessov_s_biznes_protsessami_eto_bitva_tigra_s_drakonom/719

Буков много - определений мало.

Что такое бизнес-процесс и чем он отличатся от процесса?

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

объекты управления в организации выделяют и описывают не профессиональные менеджеры, а IT-специалисты

Это, конечно, глупость. Как глупостью является и другая крайность - описание процессов теми, кто не умеет описывать. Очевидно, что требуется знание и предметной области и "птичьего языка" одновременно. Неясно, какое отношение это имеет к определению процесса.

нельзя по одним и тем же требованиям создавать модели бизнес-процессов «Бюджетирование» и «Заключение договора» или «Закупки». Слишком это разные процессы

Не настолько разные, чтобы не описать их блок-схемой. Автору это не удалось? Так бы и сказал.

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

Любой процесс деперсонифицирован и описывается при помощи ролей.

1. Бизнес-процессы управления, - описывают управление крупными бизнес-объектами с помощью вертикальных информационных потоков и необходимы для поддержания системы управления (планирование, отчетность и аналитика для поддержки принятия управленческих решений). 2. Бизнес-процессы – технологии, - описывают уникальные технологические цепочки, в которых работают конкретные участники и, иногда могут быть автоматизированы с помощью цепочек workflow или docflow. 3. Бизнес-процессы – процедуры, - по ролевой модели описывают повторяющиеся в различных местах однотипные экземпляры одной процедуры. Этот вид процессов также иногда можно автоматизировать. 4. Исполняемые бизнес-процессы

Автор так и не написал, зачем все это разделять. Только потому, что для некоторых операций исполняемая среда разная? Но этот вопрос решается уровнем ниже, каждому исполнителю информация доводится в приемлемой для него виде. Людям - должностные инструкции. Автоматам - перфокарты. На уровне описания все четыре группы это блок-схемы и роли. Делить надобности нет.

Даниил Булычев пишет: Автор так и не написал, зачем все это разделять. Только потому, что для некоторых операций исполняемая среда разная? Но этот вопрос решается уровнем ниже, каждому исполнителю информация доводится в приемлемой для него виде. Людям - должностные инструкции. Автоматам - перфокарты. На уровне описания все четыре группы это блок-схемы и роли. Делить надобности нет.

1. Правильно ли я понял Вас, что Дж. Захман тоже напрасно делит бизнес-процессы и объекты модели на 5 (пять) уровней иерархии с различными требованиями к объектам модели, а Гради Буч не понимает правил наследования свойств объектов из (в) родительский класс и агрегацию этих свойств и классов, то есть напрасно пишет про "ограниченное количество подсистем", из которых состоят сложные системы? 2. Правильно ли я понял Вас, что Вы готовы описать блок-схемой и ролями деятельность Генерального директора крупной корпорации (холдинга)? С уважением Виталий.

Виталий Елиферов пишет: 1. Правильно ли я понял Вас, что Дж. Захман тоже напрасно делит бизнес-процессы и объекты модели на 5 (пять) уровней иерархии с различными требованиями к объектам модели, а Гради Буч не понимает правил наследования свойств объектов из (в) родительский класс и агрегацию этих свойств и классов, то есть напрасно пишет про "ограниченное количество подсистем", из которых состоят сложные системы?

Гради Буч все правильно понимает. Сила его подхода как раз в том и состоит, что он усиливает функционал "блок-схема и роль" за счет наследования, агрегации и изоляции. Подчеркну, не отменяет, а усиливает. С моделью Захмана на практике не общался. Но, насколько я понимаю, его модель может применяться как методика для построения и группировки того же функционала "блок-схема и роль". Так что у меня с ними никаких противоречий.

2. Правильно ли я понял Вас, что Вы готовы описать блок-схемой и ролями деятельность Генерального директора крупной корпорации (холдинга)?

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

Даниил Булычев пишет: Гради Буч все правильно понимает. Сила его подхода как раз в том и состоит, что он усиливает функционал "блок-схема и роль" за счет наследования, агрегации и изоляции. Подчеркну, не отменяет, а усиливает.

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

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

С матрицей Захмана поработать пришлось много. Даже делал модель для водоканала на базе еТОМ (трубы, поток и биллинг - те же :D ).

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

Да, к бизнес-аналитику - может и не относится, но напрямую относится к консультанту по управлению. Посмотрите еще: http://www.cnews.ru/reviews/ppt/26_06_2009/eliferov.pdf Слайды 7 и 8 - взяты из конкретных проектов и обезличены. Чтобы построить для гендира панель BI (слайд 8) нужно выделить объекты управления верхнего уровня (слайд 7) и ... переписать учетную политику и систему управленческого учета. Этим и занимается управленческий консалтинг. С уважением Виталий.

Виталий Елиферов пишет: Вопрос был другой: 4-й принцип гласит: "Каждая сложная система состоит из ограниченного количества повторяющихся видов подсистем" - не блоков в блок-схеме, а подсистем.

Это уже вопрос терминологии. Если речь идет о повторении, то именно блок-схемы повторяются. Гради Буч называет их подсистемами? Почему бы нет. Точно так же повторяются процедуры в коде, меняются лишь контекст и аргументы. Но независимо от способа деления (по декомпозиции, по предметной области, по иерархии управления итд) вводить новые термины нет смысла. Процесс, исполняемый бизнес-процесс, технологический процесс с точки зрения управленца являются одним и тем же. Меняется только исполняемая среда. Все равно все сводится к тому, что люди и автоматы должны выполнить некую последовательность действий - алгоритм.

http://www.cnews.ru/reviews/ppt/26_06...iferov.pdf Слайды 7 и 8 - взяты из конкретных проектов и обезличены. Чтобы построить для гендира панель BI нужно выделить объекты управления верхнего уровня (слайд 7) и ... переписать учетную политику и систему управленческого учета. Этим и занимается управленческий консалтинг.

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

Даниил Булычев пишет: Это уже вопрос терминологии. Если речь идет о повторении, то именно блок-схемы повторяются. Гради Буч называет их подсистемами? Почему бы нет. Точно так же повторяются процедуры в коде, меняются лишь контекст и аргументы.

Лет 20 назад, я тоже думал, что механистичного IDEF0+IDEF3 вполне достаточно. Мир гораздо сложнее.

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

1. Вы забывает, что руководитель не работает по алгоритму, а принимает решения в ситуации, когда нет алгоритма, да еще и "на ходу" меняя алгоритм. 2. Попробуйте описать алгоритм действий гендиректора (в его стационарной, алгоритмизуемой части) в нотации BPMN или BPEL и дайте ему в руки. :D С уважением Виталий.

Виталий Елиферов пишет: Лет 20 назад, я тоже думал, что механистичного IDEF0+IDEF3 вполне достаточно. Мир гораздо сложнее.

Проще вспомнить про "мысль сказанная есть ложь") Любая нотация это язык, значит издержки вербализации неизбежны. Но повторюсь, там, где цели формализуемы, а действия повторяемы, мне лично блок-схем с ролями хватало. Если у вас есть контрпример, что дайте посмотреть. Гендир тут не подойдет. Его должность изначально подразумевает нестандартные ситуации. Максимум, чем его можно обеспечить, это набор показателей. И вот здесь он опять же захочет на блок-схему посмотреть, ибо должен знать как и откуда эти цифры берутся.