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

02.02.22

Управление проектом

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

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

 

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

 

 

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

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

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

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

 

 

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

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

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

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

 

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

 

 

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

 

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

 

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

 

 

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

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

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

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

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

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

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

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

 

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

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

 

10 - 12 октября 2024 года состоится конференция INFOSTART EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Администрирование серверов 1С и СУБД. HighLoad оптимизация
  • Инструментарий разработчика. Приемы и методы разработки 
  • Интеграция и обмен данными 
  • Мобильная разработка и чат-боты 
  • Управление проектом и продуктом 
  • Управление командой 
  • Управление ИТ 
  • Мотивация, лидерство и личная эффективность 
  • Идеи и тренды в разработке

INFOSTART EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также.

Бизнес-анализ Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

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

07.08.2023    5322    0    biimmap    43    

57

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14938    0    ASchekachev    37    

55

Бизнес-анализ Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

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

19.04.2023    4871    0    biimmap    37    

61

Бизнес-анализ Россия Бесплатно (free)

Зачем нужна роботизация при переходе с SAP на 1С. Как мигрировать с SAP с минимальными усилиями и даже без команд поддержки SAP.

09.01.2023    2385    0    comol    9    

7

Бизнес-анализ Системный администратор Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

В связи с обострением вопросов импортозамещения многие задумываются о переходе на системы, позволяющие заменить зарубежные аналоги, или уже его начали. Мы решили поделиться с вами 7-летним опытом установки и эксплуатации системы Linux + PostgreSQL + «1C» на 300 онлайн-пользователей.

16.12.2022    7840    0    1СERP    34    

68

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4522    0    user1576201    10    

17

Бизнес-анализ Бесплатно (free)

В 2022 году с рынка ERP-систем в России ушло сразу несколько крупных игроков. Российские предприятия, которые уже потратили миллионы на внедрение импортных решений, столкнулись с новой проблемой. Как будут развиваться снятые с поддержки решения, можно ли продолжать работу на SAP в таких условиях и сколько это будет стоить? Инфостарт обсудил ситуацию со специалистом по внедрению 1С:ERP Алексеем Булатовым. Поговорили о преимуществах и недостатках обоих решений, трудностях перехода и о том, что мотивирует заказчиков переносить процессы из SAP в 1С на самом деле.

12.09.2022    9253    0    Infostart    16    

61

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    11273    0    biimmap    79    

76
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. chng 02.02.22 18:45 Сейчас в теме
Как из схемы бизнес процесса, получается табличное описание, автоматически или ручками?
2. compaud 03.02.22 09:38 Сейчас в теме
Есть владелец, есть исполнитель, есть результат. Но где же в схеме клиент процесса - тот, для кого все и делалось и кто будет принимать или не принимать результат?
3. MariBond 04.08.22 12:01 Сейчас в теме
Я что-то тоже не поняла, как из схемы получается таблица. Скорее всего автор говорит о том, что нужно делать и то, и то. Но зачем? Можно просто сделать графическое описание БП в виде схем на более нижнем уровне. Посмотрите разницу в + и - на примере https://deep-vision.one/knowledge/opisanie-biznes-processov-tipy-opisaniya/?sphrase_id=4471. По-моему, очевидно, что делать 2 раза одно и то же нецелесообразно, и занимает в 2 раза больше времени.
Оставьте свое сообщение