Просмотр исходного текста страницы Описание бизнес-процессов — waste? (Максим Цепков, SPMConf-2011)

<center><big>'''Описание бизнес-процессов — waste?'''</big></center>

 Доклад Максима Цепкова на конференции [http://it-conf.ru/ru/content/403.htm SPM Conf 2011] 26.11.2011
 [http://www.slideshare.net/custisppt/waste-spm-conf-2011custis-tsepkovsp-mconf2011 Презентация на slideshare]
 Видео https://vimeo.com/34369931

= Идея доклада =

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

'''Поэтому в настоящее время тезис о необходимости полных описаний бизнес-процессов представляется спорным'''. 

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

В этих условиях отказ от описаний и регламентов находится в согласии с принципами эффективного производства Lean и Agile.

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

Эта точка зрения будет обоснована в докладе и иллюстрирована примерами, в каких случаях описания бизнес-процессов являются полезными и даже необходимыми, а когда их постоянная актуализация превращается в ненужную трату времени. Мы поговорим также о путях обоснования такой точки зрения при общении с заказчиками.

= Краткое изложение =

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

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

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

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

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

Что касается описаний третьей категории, то они, естественным образом, представляют собой маркетинговые материалы. Они обычно неполны, имеют недостаточную подробность и упускают существенные детали, а в ряде случаев - могут иметь отдаленное отношение к действительности, сильно ее преукрашивая.

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

= Видео =

{{vimeoembed|34369931|720|450}}

= Примечания и отзывы =

<blockquote>
Я тоже выступал на конференции, с достаточно провокационным, как я думал, докладом [[Описание бизнес-процессов — waste? (Максим Цепков, SPMConf-2011)|Описание бизнес-процессов — waste?]] На этой конференции он оказался вовсе не провокационным, потому что большинство участников были уверенны, что главное при применении любых методологий - не переусердствовать. И ничего не делать только потому, что этого требует какая-либо методология. Все это в полной мере относится и к описанию бизнес-процессов. Правда, как практики - они предпочитают не спорить с теоретиками и ограничиваются этой рекомендацией. А я тут осознал что конкретно по этому вопросу - теорию уже можно аргументированно подправлять, убеждая заказчиков и снимая с себя необходимость в описании процессов - о чем и рассказывал.

[http://blogs.uml2.ru/post/Konferenciya-SPM-Conf-2011 ©]
</blockquote>

<blockquote>
Недавно Максим Цепков, технический директор и главный архитектор компании CustIS, прочитал достаточно интересный доклад о необходимости дотошного описания бизнес-процессов в организации. Идея, высказанная докладчиком, показалась мне весьма неожиданной, но совершенно верной. Действительно, описание бизнес-процессов — это как географическая карта, допустим, Google Maps. Если известно, что на данный момент карта не является полной, но у нас небольшой и во всех смыслах ограниченный ресурс на развитие этой системы, то двигаться мы можем в двух принципиально разных направлениях.

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

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

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

… [http://smartsourcing.ru/blogs/teoriya_metodiki_i_standarty/1149 ©]

</blockquote>

= Слайды =
[[Файл:Tsepkov-SPMconf-2011.pdf|left|page=-|256px]]

[[Категория:Люди]][[Категория:Доклады]][[Категория:Agile]][[Категория:Управление проектами]]