В марте прошлого года аспирант Дмитрий принес мне аналитическую главу диссертации. Тема касалась оптимизации логистических затрат в среднем бизнесе – в этом сегменте у меня достаточно практического опыта, чтобы оценить и расчет, и логику за ним. Работа выглядела зрело: структура выстроена, библиография объемная, расчетная модель оформлена аккуратно. Я просмотрел ключевые выводы, сверил методологию с заявленной целью исследования, задал несколько уточняющих вопросов и дал добро на переход к следующему этапу – подготовке к предварительной защите.
Почему важно проверять первоисточник
Через два месяца, уже при подготовке презентации для комиссии, мы обнаружили, что одна из базовых цифр (средний процент логистических издержек в выручке исследуемых компаний) была взята из источника, который ссылался на другой источник, а тот цитировал отраслевой отчет десятилетней давности. Мы нашли первоисточник и сравнили. Актуальное значение отличалось почти вдвое. Рынок за десять лет изменился, структура затрат сместилась, а цифра осталась жить в цепочке цитирования, как музейный экспонат.
Эта цифра стояла в основании всей расчетной модели. Дальнейшие выводы, таблицы, сценарные расчеты и практические рекомендации строились на ней. Она задавала точку отсчета, от которой зависели пороговые значения и граничные условия каждого сценария.
Почему важно отслеживать актуальность данных
Когда научный руководитель получает аналитический отчет от компетентного исполнителя, он проверяет логику, методологию, связность аргументации, внутреннюю непротиворечивость выводов. Он не пересчитывает каждую цифру в каждой таблице. Это рациональное распределение внимания: руководитель доверяет, что данные верифицированы на предыдущем этапе, а сам сосредотачивается на том, что только он может оценить.
Проблема начинается, когда этого предыдущего этапа верификации данных не существует. Нет протокола, нет чек-листа, нет ответственного за проверку первичных источников. Есть только негласное ожидание, что кто-то уже проверил. Любой руководитель, управляющий группой аналитиков, маркетологов, финансистов или консультантов, узнает эту ситуацию.
В случае с Дмитрием я исходил из того, что он как экономист понимает необходимость актуальных данных. Он, в свою очередь, исходил из того, что источник с индексом РИНЦ, на который он ссылается, уже прошел рецензирование и, следовательно, надежен. Рецензирование источника действительно проверяет методологию автора, но не обновляет устаревшие цифры. Получилась классическая ситуация: каждый участник выполнил свою часть работы корректно, но точка ответственности за актуальность данных осталась ничейной.
Сколько стоит каскадный пересчет
Когда ошибку обнаружили, первая реакция была простой: заменить цифру и пересчитать модель. На практике все оказалось значительно сложнее. Изменился базовый коэффициент, а значит, изменились все производные: пороговые значения по каждому из трех сценариев, граничные условия для рекомендаций, интерпретация чувствительности модели. Три из четырех практических рекомендаций, сформулированных Дмитрием, оказались некорректными – потому что логика строилась на искаженном фундаменте.
Дмитрий потратил около трех месяцев на переделку аналитической главы. Сдвинулся срок предзащиты на осень. Параллельно пришлось переписывать значительную часть методологического раздела, потому что обоснование выбора конкретного инструментария тоже опиралось на пропорцию затрат из того же устаревшего источника. Была затронута даже формулировка одной из гипотез.
Три месяца – это время Дмитрия. Мои издержки: внеплановые консультации, повторные проверки пересчитанных разделов, координация с рецензентом, который уже видел предыдущую версию. В пересчете на рабочие часы это минимум 15-20 часов моего времени, которые можно было бы распределить между другими аспирантами.
Как проверять первичные данные
Это не уникальная ситуация. За годы работы я видел похожие каскады минимум четыре раза, и каждый раз механизм был одинаков. Различался масштаб потерь, но структура проблемы повторялась: непроверенное входное значение проникает в фундамент работы, и его обнаружение на поздних стадиях стоит в разы больше, чем проверка на ранних.
Руководитель, который читает итоговый отчет, проверяет качество мышления, а не качество данных. Это два разных навыка, два разных процесса и, что важно, две разных зоны ответственности. Ожидать, что один человек одновременно оценит архитектуру аргументации и проверит каждый первичный источник, нереалистично.
В корпоративной аналитике это понимают: у данных есть стюарды, у моделей – валидаторы, у отчетов – рецензенты. В экспертной, консалтинговой и исследовательской работе эта граница часто размыта. Человек, который делает расчет, и человек, который проверяет результат, – одно и то же лицо. Или, как в нашем случае, проверки первичных данных нет вовсе.
Как своевременно обнаружить устаревшие данные
После случая с Дмитрием я ввел правило, которое теперь применяю ко всем проектам:
- Каждая ключевая цифра в аналитическом отчете получает карточку: источник, дата публикации источника, цепочка цитирования, если источник вторичный, дата верификации.
- Если цепочка длиннее двух звеньев, автор обязан дойти до первоисточника.
- Ключевое число не считается проверенным, пока исполнитель не зафиксировал первоисточник и дату верификации.
- Ключевыми считаются цифры, на которых строится расчетная модель: базовые коэффициенты, нормативные значения, средние показатели рынка и отрасли, пороговые границы. Не каждое число в работе, а именно те, от которых зависит архитектура выводов.
Правило неудобное. Оно замедляет работу на начальном этапе примерно на неделю. Аспиранты жалуются, что это избыточная бюрократия и что другие руководители такого не требуют. Замечание справедливое: большинство коллег этого действительно не требуют. Но я помню три месяца потерянного времени.
За полтора года после внедрения этого протокола у меня не было ни одного каскадного пересчета. Было несколько случаев, когда находили устаревший или некорректный источник до того, как цифра попала в расчетную модель. Самое раннее обнаружение сэкономило около двух месяцев работы, которые ушли бы на пересборку всей аналитической части. Стоимость ранней проверки – несколько часов. Стоимость позднего обнаружения – месяцы.
Когда протокол проверки данных не сработает
- Правило работает только для ключевых цифр, и определение того, какая цифра ключевая, остается за экспертным суждением руководителя. Если руководитель неверно оценил значимость числа, оно не пройдет проверку. Полностью исключить человеческий фактор этот инструмент не может. Он уменьшает зону неконтролируемого риска, но не ликвидирует ее.
- Протокол требует дисциплины и от самого руководителя. Нужно просматривать карточки и реагировать на красные флаги, а не просто принимать наличие карточки как доказательство проверки. Один раз я поймал себя на том, что просмотрел карточки формально, не вчитавшись. Инструмент без внимания к нему превращается в ритуал.
Выводы
Любая экспертная команда, будь то аналитический отдел, консалтинговая группа, проектный офис или исследовательская лаборатория, работает с данными, которые кто-то собрал и кто-то передал. Каждая передача – точка потенциальной ошибки. Каждое неявное допущение о надежности источника – невидимый риск, который накапливается.
Разделяйте проверку логики и проверку данных. Не ожидайте, что человек, оценивающий качество мышления в вашем отчете, одновременно верифицирует входные данные. Создайте для этого отдельный, пусть и простой, протокол с конкретным ответственным.
Если в вашей команде нет ответа на вопрос «кто проверил эту цифру до того, как она попала в расчет», значит, ее никто не проверил. И это вопрос не к аналитику. Это вопрос к руководителю, который не выстроил процесс.
Также читайте:
Мы как-то в Правительстве {название субъекта опустим} реализовали систему бюджетирования с аналитическим модулем, в основу ТЗ была положена методичка, напечатанная в виде брошюры силами отдельного института при этом правительстве.
Так вот, при пробном расчете одного из показателей, он принял значение, теоретически невозможное (уж не помню, то ли отрицательное, до ли за пределами своего диапазона адекватности).
Оказалось, в важной формуле из этой методички содержится серьезная ошибка, и ее потребовалось на ходу устранять.
Вопрос, как по ней работали годами люди, сдавая отчеты, считая их на коленке, риторический. Очевидно, как водится у продвинутых пользователей Excel, хорошим тоном считается добавить строку подгонки, написать "чтобы сумма сходилась", и скрыть ее, поставив высоту строки 0, и на голубом глазу отправить аудитору из "Большой Четверки". ).
Вопрос в том, кто тестирует, и какие заранее сценарии исключаются из рассмотрения.
Да. Это было поучительно.
Конечно. Те же сомнения уже звучали выше в ветке. Что именно сломало логику и выводы, если модель была правильна, пока нам не сказали. А если модель правильной не была, или допущения и предположения не оправдались, то это пример уже на другую тему.
За всех, конечно, сказать не смогу, но из личного опыта: тестирует сам исследователь/разработчик моделей.
Сначала отсеиваются явно ошибочные вводные (например, цена нефти зависит от курса доллара), затем исключаются явно нереалистичные сценарии (например, компания планово работает годами в убыток), из оставшегося выбираются варианты, которые наиболее хорошо вписываются в актуальную статистику по рынку.
Если в получаемых результатах не оказывается приемлемого решения, круг гипотез и условий изменяют и повторяют процесс. Здесь мы говорим о классическом итерационном поиске устойчивого в рамках заданных параметров решения, поэтому и метод поиска наиболее приближен к классическим научным подходам.
Поскольку я не в курсе системы учёта и бюджетного процесса в госучреждениях, то у меня возникли вопросы (чисто из любопытства):
1. Вы пишите, что реализовали систему бюджетирования, в основе которой был заложен аналитический модуль, согласно разработанной методичке. Правильно я понимаю, что речь идёт об отчетах по бюджету, а не по финотчетности?
2. Каким образом отчёты по бюджету в формате excel имеют отношение к аудиторам в этом вопросе?
У этой методички есть авторы? Если да, то им сообщили об ошибке в важной формуле?
Видимо аудиторы и сообщили о серьезной ошибке, которая закралась между строк.
Почему между строк, если это ошибка в важной формуле?
Реверс к моему вопросу пункт 2: а причем тут аудиторы из биг4?
Возвращаясь к самому вопросу статьи: у меня тоже был такой опыт, я проверяла чужую финмодель, и не только формулы и логику финансовых показателей.
Т.к. финмодель была отнесена к проекту, к которому меня и моего коллегу хотели подключить, то я не только задала вопросы к источникам происхождения исходных данных, но и проверила их на релевантность у знакомых, которые непосредственно имели значительный опыт в этой сфере.
Я модифицировала финмодель в экономическую модель, заложив в основу не только логику аудитора (прим.: я - не аудитор), который проверяет, как написал Никита Андреев, на предмет того, что может быть внутри "зашито" между строк и в формулах, чтобы финрез вдруг у всех участников проекта сошелся в плюсе.
В итоге я вышла на совершенно другую картину по цифрам, которую мне подтвердил своими данными мой бывший коллега, выйдя в это время на "собеседования" с участниками этого рынка: даже на верхнем уровне расчетов, без дисконтов и бета-рисков, проект бы не пошел. Потратили вместе время, но зато не зашли в ненужный проект.
Так что в статье правильно отмечено: "разделяйте проверку логики и проверку данных", - при написании научного труда - это вопрос трудозатрат, в реальном бизнесе - все ресурсы.
Для научных работ критериев больше, но очевидно, что логика проверяется, данные собираются и дополнительно проверяются, если нет 100% доверия к источнику.
У бизнеса могут быть другие требования, включая критерий приемлемости результата.
Но ошибки в формулах в обоих случаях сводят ценность работы к нулю, если их вовремя не найти и не исправить.
Не просто сводят ценность работы к нулю.
В случае, котором я описала выше, из своей практики - это было сведение к нулю доверия к тем, кто изначально предлагал подключиться мне и моему коллеге к бизнес-проекту.
Главное было не в ошибках в формулах бизнес-плана, финмодели и неверных исходных данных. В моей практике в лизинге много проходило через мою группу экспертиз бизнес-моделей и ТЭО проектов, поэтому, такие рабочие моменты встречались.
Главное, что когда ткнули пальцем, вместо того, чтобы скорректировать поведение: давайте пересматриваем бизнес-модель или признаем, что "плохо подготовились", закрываем инициацию этого проекта и расходимся, просто ретировались в закат.