Даже маленькая ошибка может
стоить миллионы

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

Пример такого углубленного подхода являет AT&T. Бобу Паутке, управляющему отдела финансирования доступа, поручили проверить счета за некоторые услуги, предоставляемые компании другими телефонными операторами. Команда получила простое по формулировке, но сложное в исполнении задание. Услуги были комплексные, счетов — огромное количество, немало и ошибок. AT&T опасалась, что сильно переплачивает, быть может, десятки миллионов долларов.

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

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

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

Первые два изменения (от XYZ.1234 к XYZ-1234 и от 1 к A) предполагали переформатирование данных на этапе В. Просматривая их, команда обнаружила много таких незначительных изменений. Они удивляли и раздражали, но вроде бы не должны были отражаться на сумме счета. Однако два других изменения оказались более существенными: посреди процесса поменялись номер счета и номер офиса. Это уже вызывало изменение данных и сказывалось на итоговой цифре.

Пока еще метод отслеживания не помог справиться с поставленной задачей — убедиться, что AT&T платит за реальные услуги, но уже появились интересные «камешки», под которые стоило заглянуть. И тем самым изменилась постановка задачи. Вместо «Верен ли этот счет?» и «А если не верен, то насколько завышен?» появились вопросы: «Отлажен ли процесс биллинга? Где он дает сбой?» и «Как его наладить?» Иногда под камушком обнаруживается не ответ, а другой вопрос — получше.

Так Боб и его команда пытались выяснить, насколько часто случаются ошибки и велики ли они по масштабу. Они автоматизировали процесс сбора данных и попытались выявить паттерны.

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

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

Отдельный анализ позволил Бобу и его команде выявить, что основная часть ошибок возникает на стыке интерфейсов источников С и D, а также D и E. Соединив эти данные с полученными прежде сведениями по этапам, они смогли точно определить, где процесс нуждается в улучшении: иными словами, они однозначно обнаружили источник ошибок.

Затем исправлениями занялись специальные команды. После того как они разобрались с проблемами, качество процесса от начала до конца и точность выставления счета заметно улучшились. Теперь Боб мог легко решить первоначальную задачу: ответить на вопрос, не переплачивает ли компания за услуги. А попутно компания — чего и следовало ожидать — сэкономила десятки миллионов долларов.

Вы можете добиться того же в собственной организации, если правильно приметесь за данные.

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

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

Читайте по теме:

• Можно ли верить вашим данным?
• Унификация: и хочется, и колется
• Шесть искусств для бизнеса