8.3. Как формализовать внутренние бизнес-процессы и документооборот бухгалтерии

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

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

Самый распространенный, но далеко не лучший способ – описание в текстовом виде, в формате MS Word. Берется процесс (например, «учет товарно-материальных ценностей»), после чего каждый начинает творить все, что ему вздумается. Кто-то описывает его конспективно, а кто-то умудряется создать чуть ли не второй вариант «Войны и мира». И во всех случаях много времени тратится на подбор красивых формулировок, затейливых фраз (иначе несолидно!), разработку структуры документа (как описывать – разделяя по подпроцессам или по участвующим в них подразделениям?). А тут еще текучка отвлекает. И поэтому пишется такой документ не один месяц.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Примеры текстового описания операции (пример рабочей инструкции)

Пункт 3.5.2.1. Ежедневное отслеживание приходов-уходов сотрудников

Сотрудник административно-хозяйственного отдела (АХО) ежедневно в течение рабочего дня фиксирует в MS Excel время прихода и ухода сотрудников компании.

Пункт 3.5.2.5. Уточнение неявок

Ежедневно, после 11:00 менеджер отдела кадров (ОК) на основании данных, фиксируемых сотрудником АХО, уточняет у руководителей подразделений причину неявок сотрудников за текущий день, а также ранних уходов сотрудников за предыдущий день. После уточнения выполняет записи по сотрудникам в 1С: Зарплата и Кадры.

В рамках этого метода нужно понять всего четыре определения:

1. Очерченная область. Это субъект, в качестве которого может выступать как конкретный сотрудник, так и целый отдел, а при необходимости и вся компания.

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

3. Актив. Это ресурс, используемый для осуществления операции, или ее результат.

4. Стрелка. Это просто стрелка, она показывает связь между операциями и активами.

Существуют также два несложных правила, которые нужно соблюдать при описании бизнес-процессов.

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

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

Теперь вернемся к схеме, представленной на рис. 8.2. Схема, размещенная на одном листе, описывает весь процесс кадрового учета в компании. В этом процессе задействовано четыре подразделения, начиная с административно-хозяйственного отдела. Сотрудник АХО фиксирует время приходов-уходов сотрудников в таблице MS Excel, а затем этим файлом пользуется отдел кадров, внося данные в табель в 1С. В табель попадает и другая информация – отпуска, командировки и т. д. Сформированный табель передается в бухгалтерию для расчета заработной платы. Передача осуществляется не в традиционном бумажном виде, а в электронном – в 1С. Но это не значит, что актива нет. Он существует в виде пополненной базы данных в информационной системе.

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

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

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

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

Упомяну еще одно важное свойство метода технологических карт. Описание бизнес-процессов можно достаточно просто и гармонично состыковать с инструкциями на рабочие места. На рис. 8.2 все процессы имеют собственный номер, например «3.5.1. Прием сотрудника на работу». Это не что иное, как заголовок к соответствующей инструкции. Программа MS Visio позволяет добавить к любой надписи на схеме гиперссылку, по которой можно перейти к тексту самой инструкции. Таким образом, графическое описание предназначено для руководства, которое должно контролировать бизнес-процессы в целом, а рабочие инструкции, где все расписывается подробно, по шагам, – для рядовых сотрудников. Описания бизнес-процессов также должны храниться на файл-сервере.

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