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

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 позволяет добавить к любой надписи на схеме гиперссылку, по которой можно перейти к тексту самой инструкции. Таким образом, графическое описание предназначено для руководства, которое должно контролировать бизнес-процессы в целом, а рабочие инструкции, где все расписывается подробно, по шагам, – для рядовых сотрудников. Описания бизнес-процессов также должны храниться на файл-сервере.

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

8.4. Основные требования к правильной настройке бухгалтерской программы

Сейчас уже сложно представить, что всего несколько десятилетий назад вся бухгалтерская работа производилась на счетах и арифмометрах. Даже калькуляторов не было. Мой сын, когда ему было восемь лет, спросил: «Папа, а ты в детстве в какие компьютерные игры играл?» Я ответил: «Тема, я в детстве в компьютерные игры не играл, потому что домашних компьютеров еще не было». Он очень удивился.

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

В одной компании бухгалтер по учету основных средств запускает перед обедом процедуру начисления амортизации, и в течение обеденного перерыва амортизация начисляется более чем по 10 000 объектов. В другой компании, где 3500 основных средств, бухгалтер запускает автоматическую процедуру на ночь и отчаянно надеется, что к утру ничего не зависнет и все проводки будут выполнены. Или, проводя каждую накладную по отдельности, бухгалтер всякий раз несколько минут ждет, когда документ проведется. При этом работать параллельно в другом окне нельзя, так как опять-таки все может зависнуть.

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

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

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

Второй пример – расчет заработной платы. Допустим, в компании работают 1000 человек и существует 10 начислений и удержаний. Автоматическую процедуру можно настроить двумя способами: проверить фамилию сотрудника по всему списку начислений и удержаний, затем проверить второго сотрудника, третьего… и так тысячу раз. А можно взять начисление или удержание и по нему обработать все фамилии, затем взять второе удержание и точно так же его обработать. В этом случае автоматическая процедура будет выполняться существенно быстрее.

Подобных примеров очень много. И если программист говорит, что ничего сделать нельзя, то либо он недостаточно профессионален, либо ленится.

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

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

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

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

Отдельное внимание следует уделить удобству визуального интерфейса. К счастью, бухгалтерские программы нового поколения обладают в этом отношении бóльшими возможностями, чем предыдущее поколение (например, версия 1С 8.0 по сравнению с 1С 7.7). В частности, кнопки на экране можно увеличить, поменять местами, раскрасить. И это не праздное развлечение – чем удобнее интерфейс программы, тем быстрее и качественнее работает бухгалтер.

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

8.5. Как наладить эффективное взаимодействие с программистами

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

Наиболее популярных вопросов по большому счету всего три:

1. Кто должен писать техническое задание на доработку – бухгалтер или программист?

2. Как бороться со срывом сроков? Переходим, переходим на новую версию, а перейти все никак не можем.

3. Что лучше – держать в штате собственных программистов или нанимать сторонние компании? От кого больше проку?

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

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

Для его ведения можно использовать MS Excel или специализированное программное обеспечение, предназначенное для осуществления технической поддержки пользователей (системы Help Desk).

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

Все запросы делятся на три группы:

1. Требования к результату (например, исправить что-то в алгоритме расчета НДС в соответствии с изменениями в законодательстве).

2. Требования к интерфейсу (например, сделать так, чтобы кнопка «Провести документ» была в два раза больше по размеру и в нижнем углу экрана).

3. Требования к процессу (например, время формирования отчета по дебиторской задолженности сократить в два раза).

Реестр запросов должен быть размещен на общем сервере, к которому имеют доступ и бухгалтеры, и программисты. Переписка в этом реестре ведется в режиме реального времени – ставятся новые задачи, задаются уточняющие вопросы, сообщается о готовности к тестированию. Пример такого реестра приведен в табл. 8.2.

Таблица 8.2. Реестр запросов на доработку бухгалтерской программы

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

Что же касается проволочек, то приведу показательный пример. На одном предприятии собственные программисты в течение нескольких лет внедряли «восьмерку» и никак не могли закончить внедрение. Потом они вдруг неожиданно сказали, что эта программа для компании не подходит и нужно переходить на «Галактику». Представляете себе состояние главного бухгалтера? Она уже несколько лет промучилась, живя в этом переходном периоде, а теперь оказывается, что все зря. Я ей посоветовал «ложиться на рельсы» и не допустить еще одного долгостроя. Пусть доделывают то, что начали. Ведь проблема не в информационной системе, а в программистах.

Девять из 10 резюме программистов написаны в формате «что делал», а не «что сделал». Поиграли с 1С:8.0 – надоело, теперь хочется поиграть с «Галактикой». И никакой ответственности за результат. Не мучайтесь с плохими программистами – ищите хороших. Их мало, но они есть. Те самые, которые «один из десяти».

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

Почему так происходит? Все очень просто. Тем, кто ратует за своих, посчастливилось заполучить в штат хорошего программиста. Или, что более вероятно, не повезло со сторонними. И наоборот тот, кому повезло со сторонней фирмой, а не со штатными программистами, – активный поборник аутсорсинга.

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

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