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

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

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

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

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

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

В буквальном переводе с английского термин walk-through testing означает «тестирование путем прохождения сквозь». Суть такого тестирования заключается в том, что аудитор пытается найти достаточно подтверждений тому, что структура и содержание описанной системы соответствует ее структуре и содержанию на практике.

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

Будем рассматривать в дальнейшем данный вид тестирования применительно к описанию процесса, поскольку чаще всего именно такое сочетание встречается на практике.

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

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

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

Подробно остановимся на ключевых принципах проведения сквозного тестирования процесса.

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