Дмитрий Виташов - Бюрократия без боли. Новые практики госуправления

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

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

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

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

Если процесс касается территориальных подразделений, то нужно спросить и их мнение. Хотя бы выборочно узнать, насколько алгоритм понятен и адекватен их практике. Скорее всего, поступит много противоречивых предложений, зато будут выявлены потенциально проблемные вопросы. Принять все позиции нельзя, но можно их учесть, в том числе в обучении: раз есть противоречия, значит, нет единообразного понимания. Аналогично регламенты обеспечивающих процессов должны согласовываться с основными подразделениями, что на практике делается не всегда. Получается, что обеспечивающие подразделения выстраивают процессы максимально удобно для себя, но не для организации в целом.

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

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

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

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

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

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

• не организовало процесс регламентации таким образом, чтобы учитывались интересы всех подразделений (например, за счет согласования с основными подразделениями);

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

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

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