Документальное оформление бизнес-процессов в проектах по автоматизации

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

Структура проектной документации проекта 1С и место бизнес-процессов в ней

Для начала приведу общие принципы разработки документации

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

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

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

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

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

• Либо на бизнес-процессы – изначально оторванные или частично оторванные от конечного продукта процессы компании.

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

Подходы к декомпозиции бизнес-процессов

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

Первое, что нужно сделать при декомпозиции процессов – это выстроить их структуру.

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

• Самый первый уровень – это группы процессов. Здесь могут быть:

  • либо группы процессов, ориентированные на конкретные виды деятельности;

  • либо группы процессов, ориентированные на управляющую компанию – на управление инвестициями и централизованные контроли.

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

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

Нотации, которые я считаю наиболее эффективными при описании бизнес-процессов.

• Для описания процессов уровня 3 и ниже (для описания подпроцессов конкретных бизнес-функций) я считаю наиболее подходящими нотации BPMN или EPC. Лично я предпочитаю использовать для этой цели BPMN, потому что он достаточно информативный и понятный – его и бизнес понимает, и в принципе, в нем достаточно насыщена логика, чтобы подробно описать бизнес-процесс даже неопытному специалисту. Но это исключительно мое мнение – я знаю, что есть идеологи других нотаций.

• А нотацию IDEF0, я считаю, удобно использовать для верхнеуровневых процессов – для уровня 1 и 2, потому что в том же BPMN не получится отрисовать всю сложность взаимосвязей этих групп процессов, либо придется ее как-то избыточно детализировать, что не приветствуется. А в IDEF можно сделать много стрелок.

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

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

На слайде показан пример, как мы описываем декомпозицию процессов.

А здесь приведена безличная схема описания бизнес-процесса в BPMN.

Подходы к описанию бизнес-процесса

Поговорим про информацию, которая детализирует пояснение к схеме.

Обязательно выделяйте атрибуты бизнес-процесса.

• Цель – я называю цель продуктом бизнес-процесса. Если вы прочитаете книжку про ВкусВилл, там рассказывается о системе взаимоотношений между подразделениями, которые представляются все друг другу поставщиками тех или иных внутренних продуктов. Потому что подразделение представляет собой группу бизнес-процессов, каждый из которых должен рождать свой продукт. Цель бизнес-процесса – это тот продукт, который он реализует. И это очень важно обозначить, потому что это будет давать представление тому, кто будет читать информацию о процессе, и он сразу же будет понимать, зачем этот процесс. Вся последующая информация будет для него более понятна, более целенаправлена.

• Владелец – это какое-то подразделение или даже какая-то роль, если вы описываете бизнес-процесс для конкретной компании.

• Старт – это событие или группа событий, в результате которых процесс запускается.

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

• Окончание – это событие или группа событий, в результате которых процесс завершается, и продукт – готовится или не готовится.

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

Ниже приведена табличка, где указаны возможные атрибуты для шагов процессов – тех самых квадратиков в бизнес-процессе.

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

Также у шага есть атрибуты:

• Описание бизнес-действия;

• Исполнитель – роль, выполняющая действие;

• Входящая информация;

• Исходящая информация;

• Хозяйственная операция;

• Бизнес-требование;

• Функциональные требования;

• Объекты системы;

• Действие в системе;

• Требуемая модификация и т.д.

Это – те атрибуты, с которыми мы работаем. Причем, здесь не весь список.

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

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

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

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

Что дает описание бизнес-процесса

Что дает описанный подход к описанию бизнес-процессов?

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

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

• Матрица прав – составляется на основании бизнес-ролей, приведенных в исполнителях шагов процессов. Мы четко понимаем, какая роль какие действия должна делать в системе и в процессе.

• Перечень объектов системы, их полей и макеты печатных форм – составляется на основании описания действий системы.

• Перечень требуемых модификаций.

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

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

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Бизнес-аналитик. Роль в команде, компетенции, инструментарий".