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

Приветствую, попробую вставить свои пять копеек в спор. Цепочка связанных работ может относиться к процессу только тогда, когда эта цепочка кроме всего прочего устоявшаяся и/или устойчива. Посему всю деятельность в компании и разделяют на проектную, процессную, ad hoc, т.д. Считаю действительно достаточным для описания устойчивых цепочек только блок-схему, ну может с расширениями типа BPMN. Теперь о корректности постановки вопроса: "попробуйте описать деятельность гендира при помощи блок схем". Сама по себе эта изолированная деятельность не есть процесс. Поэтому описание такой изолированной деятельности блок схемами не будет интересно. Да есть БП, в которых участвует гендир. Нарисовав схему именно такого процесса в виде блок схем можно с большой долей вероятности ожидать интереса самого гендира. :D И вообще, самый мой основной посыл: не нужно относить всю деятельность компании к процессной. Есть, например, проектная в противоположность процессной, хотя запуск проекта, его отслеживание, закрытие это уже процесс. Ad hoc деятельность так же ждет своего времени когда ее можно будет описывать как процесс. Регламенты бизнес процессов имеют место быть только там где есть бизнес процесс. Там где процесса нет главную роль должны играть политики (перечень принципов, ограничений). Считаю, что не нужно абсолютно всю деятельность компании впихивать в регламенты БП.

Сергей Ладнич пишет: Цепочка связанных работ может относиться к процессу только тогда, когда эта цепочка кроме всего прочего устоявшаяся и/или устойчива

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

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

Тут, видимо, зависит от того, что понимается под проектом. В моей практике это было нечто вроде "фирма в фирме". Т.е. временное объединение сотрудников для достижения временной же цели. При этом никакой особой "проектной" деятельности не возникало. Это был комплекс из стандартных бизнес-процессов и деятельности Ad hoc. Описывать последнюю, действительно, смысла не было. Ибо не было уверенности в ее повторяемости. Только, может быть, набор целей для нее.

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

Факт. Если целью является не имитация, не набор бумажек, а отлаженное, оптимизированное и актуальное описание БП, то всю деятельность запихивать смысла нет. Иначе это будет сродни торговле карамельками поштучно. Издержек много - толку мало.

Сергей Ладнич пишет: Цепочка связанных работ может относиться к процессу только тогда, когда эта цепочка кроме всего прочего устоявшаяся и/или устойчива.

Дело за малым - дать определение устойчивости/устоявшести.

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

Перепробовал за 20 лет немало разных способов (и для своих бизнес-проектов, и для разнообразных клиентов в разнообразных случаях).

Технически, можно выделить четыре основных методики.
1. Нужно понять, что в действительности происходит в компании - строим формальные диаграммы docflow или workflow
2. Нужно оценить эффективность того, что происходит, проанализировать, какие изменения рациональны, какие нет - строим формальную модель, подходящую для функционально-стоимостного анализа (например SADT методология в нотации IDEF0)
3. Нужно спроектировать процессы, максимально учитывая множество тонкостей и деталей, при этом на выходе получить внятные зоны ответственности, ключевые показатели, необходимые ресурсы - используем процессный подход, определяем основные операции, вспомогательные, формально можно использовать нотацию ARIS, к примеру
4. Нужно тщательно спроектировать регламенты взаимодействия людей (и, возможно, систем) - используем методологию RUP и нотацию UML

Разумеется, количество методик и нотаций существенно больше, в разных случаях это могут быть разные инструменты.

Реально, научить людей разбираться в определенной нотации, читать и анализировать предоставляемые диаграммы можно в течение считанных минут. Но при этом сам цикл анализа и моделирования (синтеза) на предприятии среднего размера (15-20 отделов, 100-200 сотрудников уровня специалиста или руководителя, до 4 уровней подчиненности) в редакции "черновик" появляется при интенсивных усилиях (выделенные аналитики и специалисты по моделированию и ежедневные циклы согласования диаграмм) в течение 6-8 недель, а в вялотекущем режиме (еженедельные совещания с модератором и самостоятельное оформление диаграмм руководителями и специалистами) - до 20-30 недель. В редакции "к публикации" в вялотекущем режиме модель обычно не выходит никогда, в интенсивном режиме есть шансы в течение 4-8 месяцев издать.

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

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

Главная проблема - стихийные изменения.

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

Даниил Булычев пишет: Проще вспомнить про "мысль сказанная есть ложь") Любая нотация это язык, значит издержки вербализации неизбежны.

Я бы сказал точнее: "Под термином "система", мы всегда понимаем модель системы, отражающую существенную для данного обсуждения часть системы. Любая модель отражает только часть объекта."

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

Слайд №7 вышеупомянутой презентациии и его декомпозиция на нижестоящие блоки (без связей и блок-схем). :D

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

1. Почемы Вы удаляете гендира из работы компании? В схему не влезает? 2. Слайд №7 вышеупомянутой презентациии и его декомпозиция на нижестоящие блоки (без связей и блок-схем) + Drill-down слайда №8. (опять без блок-схем). :D - гендирам это нравится.

Сергей Ладнич пишет: Посему всю деятельность в компании и разделяют на проектную, процессную, ad hoc, т.д.

Скажите, пожалуйста, работу бухгалтерии можно считать процессной, так как она весьма стабильна и устоялась? С уважением Виталий.

Алексей Кабанов, 1. Нужно понять, что в действительности происходит в компании - строим формальные диаграммы docflow или workflow 2. Нужно оценить эффективность того, что происходит, проанализировать, какие изменения рациональны, какие нет - строим формальную модель, подходящую для функционально-стоимостного анализа (например SADT методология в нотации IDEF0) 3. Нужно спроектировать процессы, максимально учитывая множество тонкостей и деталей, при этом на выходе получить внятные зоны ответственности, ключевые показатели, необходимые ресурсы - используем процессный подход, определяем основные операции, вспомогательные, формально можно использовать нотацию ARIS, к примеру 4. Нужно тщательно спроектировать регламенты взаимодействия людей (и, возможно, систем) - используем методологию RUP и нотацию UML Разумеется, количество методик и нотаций существенно больше, в разных случаях это могут быть разные инструменты.

Не понимаю - зачем так издеваться над пользователями (заказчиками). Все 4 типа задач, лучше всего решать с пом. одного CASЕ средства, что бы не переучивать бухгалтеров в бизнес-аналитиков. Среда Aris к примеру, вполне с этим справляется.

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

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

Виталий Елиферов пишет: Любая модель отражает только часть объекта ...Почемы Вы удаляете гендира из работы компании? В схему не влезает?

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

Слайд №7 вышеупомянутой презентациии и его декомпозиция на нижестоящие блоки (без связей и блок-схем).

Без связей и блок-схем? Значит это не бизнес-процесс. Только и всего.

(опять без блок-схем).- гендирам это нравится

Гендирам, как и остальным, нравится все, что лишний раз их не грузит) Блок-схема все-таки чересчур детальна. С ней уровнем ниже разбираются.

Не понимаю - зачем так издеваться над пользователями (заказчиками). Все 4 типа задач, лучше всего решать с пом. одного CASЕ средства, что бы не переучивать бухгалтеров в бизнес-аналитиков. Среда Aris к примеру, вполне с этим справляется.

ELMA также имеет подобный функционал. Более того, у программы есть пакетные решения..

Виталий Елиферов пишет: Скажите, пожалуйста, работу бухгалтерии можно считать процессной, так как она весьма стабильна и устоялась?

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

Сергей Ладнич пишет: Цепочка связанных работ может относиться к процессу только тогда, когда эта цепочка кроме всего прочего устоявшаяся и/или устойчива

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

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

А также....

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

Определитесь, пожалуйста, нужна гендиру блок-схема или не нужна. :D

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

Правильно ли я понял, что ребята, у которых я месяц назад смотрел деятельность бухгалтерии описанную и контролируемую в MS Project, поступили неправильно с методической точки зрения? Но... почему-то бухгалтерии нравится это описание (особенно возможность контроля), всех работ и отчетов, предоставлямых смежными подразделениями в строго фиксированные сроки по всему году. :D

У меня такое ощущение, что Вас иногда заносит с процессного на функциональное. Подтверждение - Ваши реплики: раньше - "описать деятельность гендира", сейчас - "описать деятельность бухгалтерии". Где тут процессы?

У руководителей существует очень опасное заблуждение, воспитанное консультантами и бизнес-модельерами: "Достаточно описать бизнес-процессы, заставить подчиненых по ним работать и все станет "в шоколаде". На самом деле Деминг предупреждал, что: "94% проблем носят системный характер - ответственность администрации." То есть самое главное и трудное - перевоспитать руководителей. Если этого не сделать, а только отрегламентировать работу подчиненных, - все действительно будет коричневым и липким, но пахнуть будет совсем не шоколадом. :D :D С уважением Виталий. P.S. Слово "заносит" - мне не нравится, это уже похоже на оценку моей реакции, а не на обсуждение проблемы. :evil:

Виталий Елиферов пишет: Определитесь, пожалуйста, нужна гендиру блок-схема или не нужна

От личности зависит. Мне разные попадались. Кому-то интересно знать, откуда берутся цифры, на которые он смотрит. Кому-то нет. Последнее по-человески понятно (не грузит). Но вообще меня это всегда удивляло. Как можно опираться на цифры, происхождение которых неизвестно? Хозяин-барин.

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

Встречный вопрос: деятельность проводимая в 1С является процессной? Вне зависимости от Вашего ответа еще один вопрос: как возможный ответ поможет ответить на вопрос "

Виталий Елиферов пишет: Скажите, пожалуйста, работу бухгалтерии можно считать процессной, так как она весьма стабильна и устоялась?

" не понимаю логики......

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

Вопрос: с каких моих высказываний Вы сделали такое заключение? Логика? Я говорил и говорю: деятельность гендира или бухгалтерии может входить частично или полностью в какие то БП, причем разные. Ценность бухгалтерии в том числе определяется и тем, что она учавствует как функция в каких то процессах компании. Что я говорю не верно? В дополнение: не считаю описание и принуждение к БП конечным и успешным результатом. Вижу большие перспективы использования компаниями BPMS, АСМ. Туда деятельность гендира или бухгалтерии как один процесс не положишь. Человек, который хотя бы немного интересовался темой BPMS понимает, что значит устоявшиеся БП.

2 Виталий Елиферов
Почитал Вашу статью "про животных" :-) по ссылке.

По сути, основные дискуссии (ваша статья тоже вносит свою лепту) вращаются вокруг нескольких тезисов:
1) Процессы объективно существуют. Часто процессы смешивают с их описаниями. Споры идут вокруг того, какие описания процессов лучше и для чего (кого)?

2) Много споров возникает вокруг противоречия: описания процессов должны быть разными для разных категорий пользователей (от топ-менеджеров до исполнителей), чтобы ими удобно было пользоваться; описания процессов должны быть едиными, чтобы не порождать неадекватностей при создании и понимании описаний. Обсуждаются всевозможные виды компромиссов, а также универсальные подходы (типа ARIS или Захман), в которых оба противоречивых требования согласовываются за счет сложности описаний.

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

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

Андрей Курьян пишет: описания процессов должны быть разными для разных категорий пользователей (от топ-менеджеров до исполнителей)

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