Мир аналитики глазами айтишника
Автор
Александр Башкиров
Казалось бы, такая простая и понятная вещь — аналитика. Это если смотреть поверхностно. А если сделать шаг вглубь, то оказывается, что за «простой и понятной» вещью скрывается огромное количество разного рода нюансов, о которых и поговорим
Казалось бы, такая простая и понятная вещь — аналитика. Это если смотреть поверхностно. А если сделать шаг вглубь, то оказывается, что за «простой и понятной» вещью скрывается огромное количество разного рода нюансов, о которых и поговорим.
Нюанс первый. Цена вопроса и постановка задачи
Давайте посмотрим на мир глазами бизнеса. Вот информационная система. Она автоматизирует некие процессы. Вот данные, которые циркулируют в информационной системе. Пока все спокойно, но в один прекрасный момент бизнес требует построить новый отчет. Который бы показывал чуть больше, чем есть в ИС. Но недостающие данные частично имеются в бухгалтерской системе, частично — в системе CRM. Которые пока не интегрированы. Понимаете, к чему я клоню? Да, к тому, что для получения простого и удобного отчета придется проделать немалую работу на уровне систем, то есть определить технологию, интегрировать, отладить, внедрить, оттестировать... Сколько это займет времени? Зависит от сложности систем, но явно не «завтра». И вообще, стоит ли отчет того, чтобы проводить все эти работы? Не спешите сказать «не стоит» или «стоит». Перед тем как это говорить, нужно обсудить с бизнесом, какие задачи решает отчет, как часто он будет строиться, кем будет востребован. И исходя из полученной информации, принимать решение относительно реализации.
Можно сделать ремарку, что, наверное, если бы система строилась в единой архитектуре, такой отчет получался бы чуть ли не автоматически — «простым сложением столбцов с фильтрацией». Только, как правило, идеальной ситуации не бывает никогда: в том или ином виде присутствует «неидеальность» — покажите мне российское предприятие, где все используемые системы были бы хотя бы от одного вендора, не говоря уже об интеграции «из коробки»... Но даже если она и присутствует, то наверняка «не такая», какая необходима в каждом конкретном случае: ИТ-системы обычно гибко настраиваются, и уже через несколько лет такого развития структура данных системы сильно отличается от изначально заложенной. Что приводит нас к начальному тезису: кому и зачем требуется тот или иной отчет и не проще ли его не делать, чем делать?
Лирическое отступление
Бизнес-аналитика, особенно с позиции оперативного управления, строится на количественных показателях, так или иначе характеризующих состояние объекта наблюдения. Проще говоря, чтобы оценить состояние процесса, склада, движения денег — берем определенные показатели и сводим их в отчеты. Таким образом, грамотно построенная система отчетности — это 50% от системы бизнес-аналитики. Потому что вторые 50% — это люди, то есть те, кто, опираясь на данные, делает вывод и корректирует курс компании, подразделения, проектной группы.
Нюанс второй. О людях
На самом деле в сугубо айтишном мироустройстве люди обычно или не рассматриваются вообще, или рассматриваются только и исключительно с позиции удобства конечного пользовательского интерфейса. А если выйти за пределы этого микромира и посмотреть чуть шире, то картина получается достаточно интересной.
Во-первых, начальные данные в любую информационную систему вводят люди. Да, при этом множество данных вводится однозначным способом, исключающим двоякую трактовку (например, ввод штрихкодов, прямой ввод данных через шины и т. д.). Тем не менее было и остается множество областей, куда данные вводятся только и исключительно вручную. Например, резюме разговора с клиентом в CRM, классификация обращения клиента и т. д. Понятно, что при разработке информационных систем делается все, чтобы свести к минимуму ошибку, но, поверьте, найдется пользователь, который обойдет даже самую умную систему. Естественно, из лучших побуждений. (Сознательное вредительство лежит за рамками статьи.) А если мы имеем дело с системой, где число пользователей, генерирующих входные данные, измеряется сотнями? В этом случае, если делать совсем «по-правильному», то должно быть три барьера:
1) в интерфейс ввода нужно заложить алгоритмы, которые будут страховать пользователя от ошибки (все, что можно реализовать списками с выбором, — реализуется списками с выбором, проверка орфографии, использование шаблонов, масок ввода, подсказок, автозаполнения, алгоритмы определения корректности сочетаний параметров и т. д.);
2) внутри системы должен быть встроен модуль цензуры, который на основе статистических показателей выбирает «подозрительные» записи и отправляет их на рецензирование. Отмечу, что такое делается только в системах, где находятся высококритичные данные: модуль сам по себе может оказаться достаточно сложным к тому же необходимо вводить в штат сотрудников, осуществляющих функцию цензуры (что, по сути, представляет собой дополнительные инвестиции на проект и увеличение текущих затрат — ФОТ, дополнительные рабочие места);
3) персонал, который вводит первичные данные. Порой небольшой грамотный инструктаж с разбором типовых ошибок способен существенно повысить качество данных, попадающих в систему.
Ньюанс третий. Что было раньше: курица или Большой взрыв?
Существуют руководители, считающие (возможно, небезосновательно), что ни одна ИТ-система, генерирующая отчеты, не даст такой же объективной картины, как «живые» отчеты сотрудников. Сложно сказать, насколько это мнение объективно. Одно можно утверждать точно: мнение, не подкрепленное фактами, остается мнением, а не объективной информацией. А что является фактами? Как раз те самые цифры, демонстрирующие состояние объекта автоматизации в отчетах. Зачастую можно услышать, что мнение, которое надо проверить или подтвердить, — это уже недоверие со стороны руководства. Возможно, и так. Но, с другой стороны, руководство имеет все основания требовать подтверждения — хотя бы потому, что цена их ошибки (которая может базироваться на неверных данных), будет значительно выше, чем цена доверия. Разумеется, это не значит, что доверять нельзя никому. Но, например, при проектировании системы, выдающей аналитику, нужно очень аккуратно строить как саму отчетность, так и систему ее проверки — от этого зачастую зависит слишком много.
Кстати, про системы проверки. Хорошая система обязана уметь не только создавать отчеты, но и обеспечивать их достоверность путем встроенных перекрестных проверок. К сожалению, такого рода проверки имеются только в высококритичных системах: цена изменения в системе с перекрестной проверкой превышает цену изменения в обычной системе в несколько раз. Впрочем, если есть система с перекрестной проверкой, мир становится воистину прекрасным. Представьте себе на секунду, что вы построили произвольный отчет, а система сама, на основании заложенных в нее алгоритмов проверки, сообщила, что данные в одном из разрезов могут оказаться неверными. Да еще выведет на экран развернутое описание — почему. Фантастика? А я между тем видел систему, действующую подобным образом, в сфере прогнозирования сбыта достаточно специфической продукции. Точность прогнозов была фантастическая. Точность отчетов тоже впечатляла. Точнее, впечатляло то, что отчеты не содержали ошибок. Вообще не содержали. При том, что пользователи могли задавать свои отчеты, система просто не позволяла вывести не связанные данные и проверяла полученные сведения минимум еще по одному алгоритму. Избыточность, конечно, накладные расходы... но — система работала и работала хорошо.
Нюанс четвертый. Точность и своевременность
Об этом вообще-то странно говорить, по крайней мере на страницах журнала для серьезных людей. Но я все-таки скажу. Вся красота отчетов, лежащих в основе бизнес-аналитики, может просто «не работать», если они несвоевременны или неточны. Неточны в логическом, а не в математическом смысле (слава всем цифровым божествам, с точностью цифр в отчетах научились бороться достаточно давно). А вот с логическими ошибками все не так просто. Я уже говорил, что система должна перекрестно проверять данные в своих отчетах. Ну а если она этого не делает? Есть множество хороших систем, в которых подобные механизмы не заложены, не предусмотрены создателями. Но тем не менее эти системы работают, и работают хорошо. Как так? Да очень просто. Если данные отчета невозможно проверить автоматически, их надо проверить вручную. Кому именно — вопрос отдельный, хотя кандидатур не очень много: заказчик отчета или аналитик службы ИТ (как вариант — финансовый аналитик, бизнес-аналитик). Отчет в таком случае проверяется в течение определенного времени, на реальных и искусственных данных. То есть обыгрывается ситуация, при которой отчет будет «работать».
Несвоевременность отчетов тоже большой вопрос. Как «дорого яичко ко Христову дню», так и отчет дорог к моменту, когда на его основании делаются какие-либо управленческие решения. А если учесть, что ИТ-системы имеют тенденцию «падать» и «виснуть» в самый неподходящий момент... На моей практике прием очень большой части крупного проекта был передвинут примерно на месяц из-за того, что из системы не был выгружен отчет, содержавший данные, необходимые для принятия решения о том, выполняет система свое целевое назначение или нет. Точнее, отчет был выгружен, но через полчаса после начала совещания, на котором и принималось решение. Это не устроило заказчика, и причины его не интересовали, поскольку «нет данных для фактического анализа и признания завершенным этапа ввода системы в эксплуатацию». И все, точка. В том смысле, что ситуация полностью ложилась в канву договора, где предусматривалось, что заказчик мог не принимать систему в случае несвоевременного предоставления данных, необходимых для принятия решения о закрытии. И (согласно тому же договору) новая итерация могла произойти не ранее чем через месяц. А этот месяц — прямые убытки для внедренца: команда работает в счет бюджета незакрытого этапа, уменьшая маржу. Но это так, «мысли вслух».
Реальность же такова, что зачастую оперативное построение отчетов, особенно тех, на основании которых принимаются решения, стоит во главе угла. Пусть в отчете будут не все данные. Пусть сам отчет «неважно выглядит». Но он должен строиться три раза в день и рассылаться всем заинтересованным. Иначе — никак.
Нюанс пятый. Инструменты
Говоря об отчетах в частности и системе аналитики в целом, нельзя не упомянуть такой важный аспект, как инструменты, позволяющие строить аналитические отчеты. Таких интрументов-систем на рынке достаточно много — от простых OpenSource-решений до больших и корпоративных решений Enterprise-уровня, со встроенным OLAP-кубированием, интеграции со всем на свете. При этом невозможно точно сказать, какая именно система подойдет для реализации той или иной задачи. Выбор системы отчетности и аналитики — задача всегда индивидуальная именно в силу того, что одна и та же система может применяться совершенно по-разному на разных предприятиях. Например, кому-то достаточно «плоских» отчетов, но важен бренд производителя системы, а кто-то выбирает под задачи построения многомерного куба данных. И на первое место выходят возможности, а не бренд. В обоих случаях можно использовать одну и ту же систему. Но лишь потому, что разнятся варианты ее использования, работать она будет очень и очень по-разному. Таким образом, выбор системы — задача сугубо индивидуальная, и типового решения здесь просто не существует.
В этом смысле самое «интересное» бывает, когда меняется или ERP/CRM/MRP-система, или же локально только система аналитики и отчетности. «Интересное» — потому, что первое требование от бизнеса в 95% звучит как «сохранитое все как было, а потом посмотрим, что еще можно тут сделать». И ничего не поделать — сохраняют. Ведь заказчик (представитель бизнеса) — всегда прав. Ну или почти всегда. А потом — как в известной поговорке «аппетит приходит во время еды». Приходит, да порой такой, что впору «дать задний ход» и с ностальгией вспоминать то время, когда деревья были большими, а отчеты — простыми.
Однако, с другой стороны, ИТ как раз и выступает катализатором процесса. Само по себе внедрение новой модной системы... да и любой системы, не дает бизнесу ничего. Бизнес должен получить представление о возможностях — и тут уже ИТ вынужденно играет первую скрипку: кто еще, кроме ИТ, знает о том, что на самом деле может система? А это в очередной раз подтверждает одну старую, как windows, мысль: ИТ и бизнес живут в симбиозе, который является основой, смыслом и сутью их сосуществования. Как бы и кто бы не утверждал обратное.
Опубликовано 10.09.2014