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

Пока не поставлена цель моделирования и формализации - затраты на моделирование и формализацию НЕЦЕЛЕСООБРАЗНЫ. Для разных целей придуманы разные инструменты. Самая большая ошибка - пытаться достичь сразу всех целей (особенно когда эти цели вообще не определены). Тогда и возникают вопросы, вроде

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

Цели задач выходят за пределы самих задач, а так же методов их решения. Если Вам понятен только один инструмент, это еще не значит, что он идеален для всех типов задач. Aris - это методика и нотация моделирования ПРОЦЕССОВ. С помощью ARIS конечно же возможно, но крайне непроизводительно, ненаглядно и бессистемно описываются потоки документов (и вообще разнообразные потоки обязательств). Впрочем, не собираюсь тут вступать в религиозные войны, поскольку вполне свободно владею всеми перечисленными инструментами и еще десятком не перечисленных. Если Вы не можете за 5 минут объяснить, как читать диаграмму в той или иной нотации - не беритесь за эту нотацию, Вы ей не владеете. Но это не значит, что никто не сможет этого сделать. Там где Вы пользователей мучаете, другие прекрасно демонстрируют свой профессионализм.

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

Есть разные подходы к моделированию. Если текущая деятельность компании не описана - есть риск никогда вообще не получить достижимую рациональными усилиями модель "как будет". Частные модели "как должно быть" - нередко отражают частную фантазию отдельных руководителей и специалистов, процесс согласования множества диаграмм легко затягивается и приводит к этим самым стихийным изменениям процессов, часто с психозом и уходом реально выполняемых процессов "в тень". Разумеется, есть такая вещь, как "ноу хау", когда приходит руководитель, ясно осознающий во всей полноте процессы, которые необходимо и достаточно внедрить. Тогда ему, в общем-то, все равно "как есть". Но в этой ситуации, как Вы догадываетесь, моделирование ни к чему, только потеря времени и ресурсов. Если Вы не знаете, где находитесь - Вам вероятно все равно, куда идти. Во всех (без исключения) случаях реорганизации процессов, в которых отказывались строить модель "как есть", процесс создания модели "как будет" затягивался в 6-8 раз от нормативов. Просто потому, что в процессе согласований модель "как есть" строилась неформально, без согласований, и некоторые FEO диаграммы пересматриваются по 2-3, а порой и по 10-12 раз. Если в Вашей практике внедрения процессов редакции диаграмм доходят до 7-8 версий, можно смело говорить, что кто-то недопонимает, что на самом деле происходит в процессе, за который он отвечает, и подменяет знания фантазией и общим здравым смыслом. Нормально, когда через все согласования редакции не превышают 3-4 версий. Причем диаграммы нижнего уровня (функций и операций) обычно утверждаются в первой или второй редакции, и лишь укрупненные диаграммы процессов и их оркестровки достигают третьей, реже четвертой.

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

Как я уже писал, это только одна сторона основной проблемы. Если бы все сводилось к инструментарию, проблемы бы не было. Инструментария - что грязи; а счастья - нет.

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

Матрица Захмана - архитектура и методология Модель еТОМ - референтная модель и избыточный справочник Casewise - инструмент, который позволяет не потерять целостность модели (очень мощный но... дорогой и избыточный). Так что с целостностью модели все в порядке. Casewise и еТОМ - это практически стандарты описания БП для международных телеком компаний, а при их международном и взаимосвязанном бизнесе, эти компании нуждаются в унифицированном подходе к БП всех уровней иерархии. С уважением Виталий.

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

Матрица Захмана - архитектура и методология Модель еТОМ - референтная модель и избыточный справочник Casewise - инструмент, который позволяет не потерять целостность модели (очень мощный но... дорогой и избыточный). Так что с целостностью модели все в порядке. Casewise и еТОМ - это практически стандарты описания БП для международных телеком компаний, а при их международном и взаимосвязанном бизнесе, эти компании нуждаются в унифицированном подходе к БП всех уровней иерархии. С уважением Виталий.

Виталий, я в курсе матрицы Захмана и eTOM. с Casewise знаком только по описаниям. Но вы сами говорите об избыточности и высокой стоимости. Проблема с референтными моделями в их референтности. Такие модели (в частности, eTOM), во-первых, достаточно обобщенны, т.е., не содержат конкретики, во-вторых, отражают даже не Best Business Practice, а минимально допустимый уровень, т.е. стандарт. Они применимы с достаточной степенью обусловленности в тех случаях, когда компания даже этого не умеет. Но я плохо представляю компанию, которая откажется от конкурентоспособных процессов ради стандартных. Так сказать дилемма "вечно догоняющего". ИМХО, референтные модели можно использовать для того, чтобы "ничего не упустить", так сказать, напоминалка. Ну очень дорогая напоминалка.

Алексей Кабанов, Там где Вы пользователей мучаете, другие прекрасно демонстрируют свой профессионализм.

Нисколько не хотел принижать ваших проф. достоинств. Алексей, я вполне допускаю, что Вы лучше и быстрее других способны обучать чтению различных нотаций своих пользователей. Это один момент, но меня в большей степени удивляет расточительность времени (да и денег), с которой бизнес-аналитик, решает перечисленные вами задачи с пом. разных нотаций. Козыри использования одной нотации - единый репозиторий модели для проведения различных действий в отношении модели, единый корпоративный язык общения построенный на одной нотации. И кстати в IDEF0 функционально стоимостной анализ проводить можно, но к сожалению там нет возможности привязывать затраты к различным драйверам. Как это можно делать в той же B-Studio, Aris или Elma.

[quote]Есть разные подходы к моделированию. Если текущая деятельность компании не описана - есть риск никогда вообще не получить достижимую рациональными усилиями модель "как будет". [code]

Елена, здравствуйте, Вы еще здесь? Наша дискуссия как в песне Макаревича «и каждый пошел своею дорогой, а поезд пошел своей».Идет полезный обмен опытом и мнениями между спецами , а вот что извлек из дискуссии автор искавший модели решений-неизвестно.

Если вопрос из жизни(я заглянула в Ваш профиль), то трудно представить, что лидер мясопереработки Урала с численностью сотрудников в 850 человек не описал хоть как-то свой бизнес.

В нашей компании была такая ситуация: директор поручил отделу персонала разобраться с накопившимися противоречиями в регламентах и предложить обновленную концепцию «на вырост». К тому времени «Правила игры» уже были достаточно сформированы: существовало хорошо структурированное по типам, темам , отделам, делопроизводство, существовал , известный всем адрес общего доступа, существовали , в виде отчетных форм, форматы обмена данными между отделами. Все это поддерживалось дисциплиной графика стандартных коммуникаций и сквозным внутренним аудитом. Словом , если возникала необходимость исследовать какое-то событие-все было прозрачно. НО…компания выросла с 80 до 300 человек, появились региональные сотрудники в удаленном доступе и все стали замечать, что
-новые сотрудники за месяц испытательного срока «не въезжают»
-информация проходит по цепи команд с искажениями
-возросло количество дорогостоящих ошибок в складской и транспортной логистике
-возник «ничейный» функционал на стыке отделов, вот и появилось предположение, что старое «Руководство по ведению бизнеса» стало тесновато.

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

Очень понятный инструмент исследования реальности схема Исикавы, или ее еще называют «рыбья кость».И для разрешения противоречий тоже есть методы, мне показалось , что их хорошо обобщил Белильцев ВК в своем "ТСМ"

Андрей Курьян пишет: ИМХО, референтные модели можно использовать для того, чтобы "ничего не упустить", так сказать, напоминалка. Ну очень дорогая напоминалка.

Андрей! Я не писал про дорогую референтную модель....

Матрица Захмана - архитектура и методология Модель еТОМ - референтная модель и избыточный справочник Casewise - инструмент, который позволяет не потерять целостность модели (очень мощный но... дорогой и избыточный).

... референтная модель - дешева. А для реализации ее совсем не обязателен Casewise.

Проблема с референтными моделями в их референтности. Такие модели (в частности, eTOM), во-первых, достаточно обобщенны, т.е., не содержат конкретики, во-вторых, отражают даже не Best Business Practice, а минимально допустимый уровень, т.е. стандарт. Они применимы с достаточной степенью обусловленности в тех случаях, когда компания даже этого не умеет. Но я плохо представляю компанию, которая откажется от конкурентоспособных процессов ради стандартных. Так сказать дилемма "вечно догоняющего".

1. Если Вы знакомы с моделью еТОМ, то знаете, что до уровня SID - стандартизованы только названия процессов. 2. Я не понимаю терминов "конкурентные процессы" и "стандартные процессы" - для международной адаптации стандартизованы названия и интерфейсы + метрики. Содержание и организация - могут быть любыми. Модель еТОМ говорит что в телеком-компании должен быть "Биллинг", "Разрешение конфликтов", "Эксплуатация сети" и т.д. - и за все это кто-то должен отвечать. С уважением Виталий.

Жаль что дискуссия перерастает в узкоспециализированное обсуждение, которое инициатор 100% перестал понимать. Жаль, что не обозначаются моменты (+методики), которые по силам штатным сотрудникам, и позволили бы твердо дойти до первого "боль-мень" осязаемого результата, после которого - гендир и консалтеров позвать не прочь будет.

2 Виталий Елиферов

Я не понимаю терминов "конкурентные процессы" и "стандартные процессы"

Я говорил о конкрентоспособных процессах, т.е. процессах, которые обеспечивают конкурентоспособность компании, в отличие от стандартных процессов, которые описаны в стандартах, о которых все все знают, которые по определению, не могут обеспечить конкурентоспособность компании в перспективе. Это одна из проблем бездумного применения референтных моделей, ИМХО. Я не Вас имею ввиду, просто недавно попался один на глаза.

2 Александр Абрамов

Жаль что дискуссия перерастает в узкоспециализированное обсуждение, которое инициатор 100% перестал понимать. Жаль, что не обозначаются моменты (+методики), которые по силам штатным сотрудникам, и позволили бы твердо дойти до первого "боль-мень" осязаемого результата, после которого - гендир и консалтеров позвать не прочь будет.

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

Т е Андрей, верно ли я понимаю, что не существует таких методик, которые бы позволили получить некий компромиссный (пусть где-то ошиблись + где-то получили результат = вышли "в ноль" с точки зрения результата работы компании, но продвинулись методически и более осознанно готовы рассуждать и ставить задачи консалтерам) вариант?
Т е везде нужен консультант, и многочисленные книги "по бизнес-процессам" не работают, т.е. нет возможности в одном абзаце привести некую работающую "боль-мень" выжимку?
С уважением Александр.

Александр Абрамов пишет: Т е Андрей, верно ли я понимаю, что не существует таких методик, которые бы позволили получить некий компромиссный (пусть где-то ошиблись + где-то получили результат = вышли "в ноль" с точки зрения результата работы компании, но продвинулись методически и более осознанно готовы рассуждать и ставить задачи консалтерам) вариант? Т е везде нужен консультант, и многочисленные книги "по бизнес-процессам" не работают, т.е. нет возможности в одном абзаце привести некую работающую "боль-мень" выжимку? С уважением Александр.

Хоть я и не Андрей, но с ним полностью согласен. Таких методик нет!!! Это не пессимизм, а константация факта, что "конкурентную" :D систему менеджмента нельзя создать по инструкции "делай раз, делай два". Надеюсь, что Вы не читаете книжки "Как стать миллионером". Все описанные рецепты действовали: - в конкретное время, - в конкретных условиях, - для конкретной компании, - с конкретным топом. Изменение одного из параметров, каждого из 4 перечисленных пунктов приводит к неработающему рецепту. Совершенно аналогично, - система менеджмента процессов не может быть создана под копирку. Выше уже писал, что еТОМ - "референтная модель и избыточный справочник", но НЕ РУКОВОДСТВО ДЛЯ КОПИРОВАНИЯ. Чтобы система менеджмента была конкурентна, она должно быть уникальна, а вот процессы могут быть и стандартизованы. Так как конкурентные преимущества создают не рутинные процессы, а уникальные проекты и решения.

Жаль, что не обозначаются моменты (+методики), которые по силам штатным сотрудникам, и позволили бы твердо дойти до первого "боль-мень" осязаемого результата, после которого - гендир и консалтеров позвать не прочь будет.

Многолетний опыт и собственая методика оценки "степени управляемости компании и подразделений" говорят, что консультантов зовут, когда компания находится в диапазоне 30-60% от идеального состояния (по этой оценке). Ниже 20%- компания загибается. Выше 60-70% - все может сделать сама, с небольшими консультациями. Если кто-то считает, что "придет консультант и сделает нам красиво" - он глубоко заблуждается. Без нудной и кропотливой работы самих менеджеров и ПЕРВОГО ЛИЦА, самый распрекрасный консультант ничего не сделает. Все останется на бумаге. С уважением Виталий.

Изменение одного из параметров, каждого из 4 перечисленных пунктов приводит к неработающему рецепту.

пожалуй можно согласиться, именно поэтому ELMA, Aris и другие подобные средства моделирования бизнес-процессов не имеют готовых пакетных решений, что и порождает риск неудачного внедрения

Михаил Кузнецов пишет: И кстати в IDEF0 функционально стоимостной анализ проводить можно, но к сожалению там нет возможности привязывать затраты к различным драйверам. Как это можно делать в той же B-Studio, Aris или Elma.

Михаил, насчет ELma Вы не ошибаетесь ли? Можно ссылку?