Бухгалтерия без авралов и проблем. Руководство для главного бухгалтера

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

В результате лучшее, что можно сделать с такими документами, – красиво переплести и поставить на полку в шкаф.

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

На рис. 8.1 приведен пример такого описания.

Рис. 8.1. Пример схематичного описания бизнес-процессов (как не надо)

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

Одного взгляда на эту схему достаточно, чтобы понять, что ничего не понятно. Чего стоит одна только логика, согласно которой процессы, которые воспринимаются как что-то протекающее, «закупорены» в прямоугольники? А активы (например, сопроводительные документы на ТМЦ), которые имеют вполне материальное обличие, наоборот, «размазаны» по стрелкам? То есть все перевернуто с ног на голову.

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

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

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

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

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

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

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

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

Что же делать? Неужели все так плохо и нет никакого выхода? К счастью, выход есть. Я ругал модные методологии не из желания просто поумничать, а чтобы вы очень хорошо почувствовали огромную разницу между ними и тем, что сейчас покажу.

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

На рис. 8.2 приведен пример описания бизнес-процессов методом технологических карт.

Рис. 8.2. Пример описания документооборота методом технологических карт

1. Используемые символы (нотация)

2. Пример графика