Описание бизнес-процессов вместо описания требований

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

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

Уместным еще будет вспомнить про идею архитектуры предприятия (Enterprise architecture), включающую в себя бизнес архитектуру. Если не вдаваться в детали, то суть идеи заключается в том, чтоб разработать матрицу зависимости между подразделениями компании и процессами, в которых они участвуют. Т.е. речь идет не о бумаге, которую каждый проект или каждое подразделение пишет для себя, пишет, причем, каждый раз, когда возникает необходимость в том, чтоб «наконец как следует во всем разобраться», а о едином подходе в рамках всей компании. Говоря еще проще, мы запрещаем подразделениям и проектам заниматься описанием процессов в любимом текстовом редакторе, предоставляем единую модель и инструмент для создания и использования описания процессов, инструкций, руководств и прочих бумаг, регламентирующих деятельность сотрудников.

На мой взгляд, это направление развития бесславно капитулировало, так и не решив поставленных перед собою задач. BPM тусовка переключилась на моделирование этапов отдельного процесса, обсуждение BPMN и возможностей «исполнения» нарисованных в данной нотации процессов. Но, тем не менее, задача сокращения околопроцессных бумаг, согласованности зафиксированных в них утверждений и устранения разрыва между реальностью и моделью может быть решена. Пусть всего лишь в рамках отдельных активностей и проектов.

Надо просто выбросить лишнее.

Описание бизнес-процессов вместо описания требований: 6 комментариев

  1. “На мой взгляд, это направление развития бесславно капитулировало, так и не решив поставленных перед собою задач.” – not at all. This approach is just a bit more complicated because it requires the synergy between previously separated domains such as “management” consulting, EA, BPM, SOA, etc. In particularly, “возможностей «исполнения» нарисованных в данной нотации процессов” is one of the critical issues of that synergy.

    For example — http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html

    In general, you are right — SDLC in the EA+BPM+SOA age is rather different from existing practices.

    Thanks,
    AS

  2. Абалдеть!
    Я вот не знаю этих всех стандартов… но есть опыт…
    1. Меня тошнит от ГОСТа на ТЗ. Я когда что то сложное вижу, меня всегда тошнит.
    2. Мои попытки описать ТЗ и контролировать проекты по этому ГОСТу приводили лишь к огромным временным затратам и при этом не давали помощи в части контроля результатов и рисков. Вероятно этот ГОСТ был актуален в период зарождения компьютеров. Когда было мало готовых элементов для построяения ИТ, а также отсутствовал ITSM.
    3. Но! Один раз увидел красивое ТЗ… в нарушение всеъ этих ГОСТов, но такое простое, понятное и полезное для управления, что с тех пор я начал применять только его. А потом, когда изучил и освоил техники ВИСИ, СПИН, GTD и кучу методик моделирования процессов добавил в него красоты…
    3.1. Нужно фиксировать текущую проблематику… т.е. те характеристики ситуации, которые заставили нас выполнять это изменение.
    3.2. Фиксировать желаемые характеристики ситуации, в которой должны оказаться после выполнения технического задания.
    3.3. И вот зная А и Б, начинаем фиксировать точечно те, важные элементы, которые нам нужны. И ничего лишнего. Как правило в эти элементы входит охватываемая структура процессов по правилу ВИСИ.
    Ссылки на материалы по техникам ВИСИ, СПИН и GTD есть у меня на блоге.

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

  3. Мне кажется, что требования возникли и широко применялись в автоматизации, когда господствовал функциональный взгляд на организацию. С появлением дополнительного процессного взгляда появился термин “бизнес-процесс”, появились описания БП, языки моделирования процессов.

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

  4. «Мне всегда казалось, что хорошее описание бизнес-процессов позволяет отказаться от такого артефакта как требования»

    И до сих пор кажется?

    1. Ключевое слово в этой фразе – хорошее 🙂

      Основной вопрос сообщения в том, как структурировать описание требований. Можно ли использовать для этого модель бизнес-процессов, расширив её описанием предметной области и нефункциональными требованиям? Я считаю, что ответ “да”. Такое описание требований лучше набора несвязных тезисов в стиле “Система должна быть…”, с которым мне на момент написания сообщения приходилось сталкиваться слишком часто

      1. Ну есть же классические (помимо совсем классических, изложенных в IEEE 838) ответы — структурируйте по:
        1) юскейсам (80-90-е годы) или
        2) пользовательским историям (2000-е), а те уже — с помощью User Story Mapping (2010-е).

        В первом случае всё равно считается, что НФТ (атрибуты качества, ограничения, требования к интерфейсам взаимодействия, бизнес-правила) лучше вести отдельно от ФТ. И, соответственно, описаний бизнес-процессов.

        Подход, близкий к тому, о чём ты пишешь, также изложен в книге HEMP: An agile approach to analysis and design:
        http://www.amazon.com/HEMP-agile-approach-analysis-design/dp/148418422X
        http://www.dejc.com/HEMP

        Там автор предлагает использовать Business Process Story (фактически это упрощённые бизнес-юскейсы).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *