что такое ad hoc исследования
Discovered
О финансах и не только…
Ad-hoc исследования
Ad hoc, или Ad-hoc исследования (в переводе с латинского — специальный, для данной цели, для этого случая) — одноразовые исследования по заказу, эксклюзивные последовательские проекты, которые планируются и осуществляются профессионалами с учетом специфики рынка и требований конкретного клиента. Сочетают качественные и количественные методы, что помогает выдвигать гипотезы и проверять их на больших выборках респондентов.
При проведении Ad-hoc исследования в маркетинге наиболее популярны следующие их объекты:
Ad-hoc исследования более популярны среди клиентов, работающих непосредственно с конечными потребителями. На рынке B&B более актуальны услуги консультантов. Существующее сегодня многообразие возможных контекстов и взаимозависимостей приводят к ситуации, когда совокупность рыночных факторов делает почти каждую маркетинговую задачу по-своему уникальной. Это означает возрастающую с каждым годом потребность в Ad-hoc проектах. Подтверждением этой тенденции является быстрый рост Ad-hoc подразделений в исследовательских и консультационных маркетинговых фирмах.
Принимая решение о том, проводить ли исследование своими силами или заказывать у профессиональной исследовательской организации «на стороне», надо принять во внимание семь ключевых моментов:
Чем сложнее исследование, чем больше оно требует специальных навыков, знаний и умений, тем больше оснований для обращения к услугам исследовательской компании. Серьезный мотив для обращения к профессионалам — необходимость использования специального (а зачастую и лицензионного) программного обеспечения, специальных систем для проведения телефонных опросов — СATI, интернет-опросов — CAPI, специальных методик проведения исследований.
Сопоставимые по качеству и объему выполняемых работ исследования, проводящиеся собственными силами сотрудников компании, как правило, занимают существенно больше времени (в полтора-два раза), чем при их заказе специализированной исследовательской компании.
Цена Ad-hoc исследования обычно колеблется в диапазоне от 5 до 20 тыс. долл., но может и превышать эту величину. На первый взгляд кажется, что проведение исследований собственными силами при сопоставимых параметрах сложности и качества должно быть намного дешевле. Но при проведении исследований собственными силами компания не может рассчитывать на эффекты «кривой опыта» или экономии на масштабе. К тому же нужно учитывать, что сотрудники компании, занятые проведением исследований, ничем другим заниматься толком не смогут, а значит, все то время, которое они потратят на проведение исследования, необходимо будет включить в издержки проведения исследования: речь идет не только о заработной плате и налогах на фонд оплаты труда, но и об амортизации оборудования, общих управленческих и накладных расходах.
Качество исследований не зависит от того, было оно по составу команды «внешним» или «внутренним». Это исключительно вопрос квалификации и добросовестности персонала. Допустить ошибку и даже обмануть заказчика могут как сотрудники исследовательской компании, так и штатные работники. А вот система контроля качества исследования у приличной исследовательской компании достаточно отработана. Заказчику же придется выстраивать ее «с нуля».
Если потребность в проведении массового опроса, фокус-групповых или глубинных интервью у вас возникает не чаще одного раза в год, то создавать собственный отдел «маркетинговых исследований» нецелесообразно. Чем эти люди будут заниматься остальные десять месяцев в году?
Ad-hoc исследования также эффективны, если потребность в исследованиях у фирмы возникает раз в квартал. Объективность исследования, без сомнения, будет выше, если заказать проведение маркетинговых исследований специализированной исследовательской компании. Сотрудники компании, работающие в службе маркетинга, в отделе проведения исследований, неизбежно включены в сложную систему внутрифирменных взаимоотношений. К тому же у них велик соблазн представить собственное мнение как мнение клиента, что гораздо реже встречается у профессиональных исследователей. Более того — у высокопоставленных сотрудников других подразделений компании всегда будет труднопреодолимое искушение лично повлиять на результаты исследования штатных сотрудников, а также на стиль, тон, расстановку акцентов при их презентации.
Специалисты рекомендуют при выборе исследовательской компании соблюдать принцип «равных браков». Он состоит в том, что крупные компании-заказчики должны обращаться к услугам крупнейших исследовательских компаний, а средним по размеру организациям следует пользоваться услугами крупных и средних исследовательских фирм. Это нужно для того, чтобы из-за разницы «весовых категорий» исследователи не оказались в критической зависимости от одного-двух заказчиков, по отношению к которым им будет трудно соблюдать объективность. Если же результатам исследования необходимо обеспечить конфиденциальность, то преимущество получает проведение исследований силами собственных сотрудников, что особенно логично, если предполагается участие весьма ограниченного круга респондентов из числа отраслевых экспертов или клиентов компании.
Что такое ad-hoc тестирование?
В этой статье мы разберем, что такое ad-hoc тестирование и какие оно имеет преимущества и недостатки. Также рассмотрим best practices в этом виде тестирования.
Что из себя представляет ad-hoc тестирование?
«Ad hoc» переводится с английского как «случайный, непродуманный, спонтанный». Такое тестирование также называют «случайным тестированием» или «monkey testing» («обезьяньим тестированием»).
Проводя ad-hoc тестирование, тестировщик пытается сломать систему, используя нестандартные методы. Обычно это тестирование не имеет четкого плана, а тестировщики не придерживаются никаких особых методик создания тест-кейсов.
Главная цель ad-hoc тестирования — обнаружить баги при помощи случайных проверок. На каждом шаге тестирования тестировщик импровизирует. Таким образом удается выловить очень специфические и любопытные баги, которые легко пропустить, применяя другие методы.
Самый интересный аспект ad-hoc тестирования — отсутствие каких-либо методик продумывания тестов. Благодаря этому можно найти баги, которые обычно проскакивают незамеченными. Но, вместе с тем, воспроизвести это тестирование сложно, поскольку нет ни написанных тест-кейсов, ни документации.
Успех ad-hoc тестирования полностью зависит от креативности и настойчивости тестировщика, а порой и от чистой удачи.
Виды ad-hoc тестирования
1. Buddy Testing
Суть Buddy Testing в том, что как минимум два «компаньона» (в переводе с английского buddy — приятель, компаньон) одновременно пытаются выявить баги в одном и том же модуле.
Buddy Testing можно считать комбинацией системного и модульного тестирования. Оно проводится после юнит-тестирования модуля.
Компаньонами обычно бывают разработчик и тестировщик. Они вместе работают над модулем для создания валидных тест-кейсов.
2. Monkey Testing
«Обезьянье» тестирование часто применяют при проверке отдельных модулей. Суть его в том, что тестировщики тестируют приложение или продукт случайным образом, без тест-кейсов.
Основная задача тестировщика — проанализировать работу приложения совершенно рандомным образом. Это помогает удостовериться, что система способна выдержать любой сбой.
Тестировщики передают в программу случайные входные данные и наблюдают за результатами. Выходные данные помогают выявить ошибки, несоответствия и сбои в системе.
3. Парное тестирование
Парное тестирование похоже на Buddy Testing, но здесь над модулем работают два тестировщика, а не тестировщик и разработчик. Кроме того, Buddy Testing — комбинация модульного и системного тестирования, а парное тестирование — чисто модульное.
Суть парного тестирования в том, что тестировщики работают вместе на одной машине и при этом делятся идеями и знаниями. Последнее особенно полезно, когда уровень знаний у тестировщиков различается. В таком случае менее опытный может многому научиться у старшего коллеги.
Работая в паре, тестировщики могут распределять роли: скажем, один проводит тесты, а другой делает записи.
Когда стоит проводить ad-hoc тестирование
Ad-hoc testing бывает полезным, когда у вас нет времени на длительный и всеобъемлющий процесс тестирования, требующий подготовки требований и тест-кейсов.
Идеальное время для ad-hoc тестирования — после проведения всех формальных тестов. Но его также можно проводить и в процессе разработки, и после его завершения.
Стоит отметить и пару сценариев, при которых ad-hoc тестирование не рекомендуется:
Преимущества ad-hoc тестирования
Основное преимущество ad-hoc тестирования — возможность выявить баги, которые остались бы незамеченными при других проверках. А поскольку для такого тестирования не нужно ничего планировать и структурировать, оно экономит много времени.
Дополнительный плюс ad-hoc тестирования — тестировщик проводит его в свободной форме, согласно своему пониманию системы. Он может добавлять различные проверки уже по ходу работы, что помогает выявлять ошибки.
Такое тестирование могут проводить и сами разработчики ПО.
Недостатки ad-hoc тестирования
Основной недостаток ad-hoc тестирования состоит в том, что сам процесс тестирования не документируется, поскольку идет не по конкретному набору тест-кейсов. В результате воспроизвести замеченную ошибку сложнее. Для этого тестировщику приходится вспоминать, какие шаги привели его к нужной точке.
Кроме того, если у тестировщика нет предварительных знаний о функционале тестируемого приложения, ad-hoc тестирование будет бесполезным, оно не выявит никаких ошибок.
Также ad-hoc тестирование не гарантирует, что все ошибки будут найдены. Успех этого тестирования вообще очень зависит от знаний и навыков тестировщика.
Поскольку такое тестирование предполагает отсутствие заранее подготовленных или задокументированных тест-кейсов, трудно предугадать, сколько сил, времени и ресурсов потребуется на проведение тестов. Чтобы найти одну ошибку, может понадобиться как несколько минут, так и несколько часов.
Best Practices в ad-hoc тестировании
Если тесты проводятся неправильно, время тратится впустую. Поэтому для успешного проведения ad-hoc тестирования важно знать, как оптимизировать процесс.
Следующие best practices гарантируют, что время на тестирование будет потрачено с умом, а шансы на успех будут максимальными.
Ознакомьтесь со спецификацией
QA-специалист, проводящий ad-hoc тестирование, должен хорошо знать тестируемое приложение и его основные функции. Только благодаря этому он сможет «угадывать», где скрываются ошибки и баги.
Определите наиболее «подозрительные» части приложения
Если тестировщик не знаком с приложением, рекомендуется определить области программы, где вероятность ошибок выше всего, и начать тестирование с них.
Функции, к которым имеет доступ конечный пользователь, должны быть в приоритете
Начните тестирование с тех частей приложения, которые чаще всего используются клиентами и конечными пользователями. Таким образом удастся заранее отловить наиболее заметные для пользователей баги.
Сформулируйте план тестирования в свободной форме
Да, ad-hoc тестирование не требует предварительного планирования или составления документации. Тем не менее, будет полезно набросать хоть какой-то план. Сделайте пометки о частях программы, требующих проверки: это поможет покрыть тестами как можно больше и как можно быстрее.
Используйте подходящие инструменты
Очень важно применять правильные инструменты: дебаггеры, профилировщики и т. п. Они помогают тестировщику изолировать ошибки.
Итоги
Ad-hoc тестирование не требует предварительного планирования, документирования и проектирования тест-кейсов. И если такую задачу поручают специалистам, которые отличаются креативностью и хорошим знанием системы, это тестирование может сэкономить много времени и выявить больше багов, чем спланированное.
Как мы автоматизировали выгрузки и другие Ad-hoc задачи аналитика с помощью Zeppelin
На момент написания этой статьи в компании Cardsmobile, которая разрабатывает мобильное приложение «Кошелёк», работает 195 человек: 8 аналитиков и 187 потенциальных заказчиков аналитиков. Мы делаем приложение для конечных пользователей, а также работаем с ритейлом, банками, брендами и другими партнерами. Долгое время работа аналитика в Кошельке состояла не только из исследований поведения пользователя, но и из различных выгрузок, типовых анализов для партнеров и прогнозов для потенциальных клиентов. Конечно, дашборды сильно спасали нам жизнь и позволяли всей компании следить за показателями продукта. Но мы всё ещё тратили время на остальную текучку, и с ростом команды (заказчиков) и бизнеса упёрлись: Ad-hoc задач стало слишком много, а исследования, желание развиваться и светлое будущее простаивали в отсутствие у нас времени.
Так много вокруг классных конференций, интересных статей про различные аналитические исследования, data-science, data-driven, data-счастье. А мы смотрели на всю эту красоту и не знали, где среди всего потока текучки найти время на эксперименты. Многие рассказывают, как сделать классно, но мало кто рассказывает, КАК преодолеть нарастающую текучку и освободить ресурсы для интересных и творческих задач. В этой статье я расскажу про наш опыт выхода в светлое будущее. Дальше будут примеры, как мы автоматизируем Ad-hoc задачи аналитиков в Zeppelin.
Что такое Zeppelin
Zeppelin – это OpenSource Notebook от Apache, который позволяет обращаться к различным БД на разных языках (Python, R, SQL, Spark). Но что делает его особенно кайфовым, так это набор визуальных элементов – dynamic forms.
В одном ноутбуке мы можем извлекать данные по api из Amplitude, быстро считать агрегаты из Clickhouse, дополнять результат данными из MSSQL и обрабатывать все это на Python. А готовые отчеты заворачивать в Excel в удобном заказчику формате и класть в html-ссылку, по которой их можно легко скачать.
Изначально мы начали использовать его просто как notebook, в котором было удобно писать на разных языках. Потом изучили возможности Zeppelin получше, нашли встроенные динамические формы: инбоксы, выпадающие списки и чеклиты – лампочка над головой загорелась! Сразу придумали, сколько всего мы можем автоматизировать. У нас было много типовых задач с готовым кодом, в котором надо было просто менять значения переменных. Мы перенесли весь наш код в Zeppelin, вынесли переменные в динамические формы и дали заказчикам возможность самостоятельно заполнять их и запускать скрипты. Идея понравилась и нам, и всей остальной команде!
Какие динамические формы есть
Input – текстовое поле. Мы используем его, для того чтобы задать временной диапазон для ввода идентификаторов. Другими словами, для всего, вариаций чего бывает много.
Select – выпадающий список. К каждому элементу списка можно прописать сразу готовый кусок кода. Мы предлагаем пользователю выбрать один из нескольких типовых вариантов. Например, одну из метрик для типового отчета.
Checkbox – форма для множественного выбора вариаций. Мы даем его пользователю, чтобы он, к примеру, сам мог выбрать список необходимых полей в выгрузке. Пожалуй, у нас это самый популярный кейс. Или когда мы даем возможность выбрать несколько метрик, сегментов пользователей.
Какие задачи мы автоматизируем в Zeppelin
Выгрузки простые и сложные, с использованием фильтров по дате, партнеру, задавая набор столбцов.
Чаще всего запросы на выгрузки приходят от аккаунт-менеджеров. А еще, с большой вероятностью, они поступают внезапно и срочно. Сами по себе задачи на выгрузку типовые и быстрые в выполнении. Но в действительности они отвлекают от тех самых интересных аналитических исследований, и их число растет по мере роста партнерской сети.
С какими задачами обычно приходят:
Мы создали отчеты для всех частых задач на выгрузки, с которыми к нам обращались. Ускорили процессы наших коллег и высвободили время и внимание для более интересных задач. Теперь только дорабатываем эти отчеты по мере необходимости.
Типовые задачи, в которых надо просто запустить готовый скрипт. Тут тоже применяем фильтры, даём задать значение переменных. Например, пересчет какой-то метрики или отчета, которые используются редко и не хочется ставить их на расписание.
Более изощренный кейс из жизни. Отдел маркетинга совместно с нашими стратегическими партнерами решили провести промо-акцию с определенной механикой. Пользователи нашего приложения должны были совершить цепочку действий, становясь участниками розыгрыша подарков. Раз в неделю мы хотели получать список участников недели, рандомно определять победителей, поздравлять их и отправлять подарки. Аналитик направления создал notebook в Zeppelin, который собирал пользователей, соответствующих условиям участия в розыгрыше за прошедшую календарную неделю. Маркетолог самостоятельно запускал notebook и забирал участников недели.
Подведение итогов А/B-тестов, измерение base-line метрик в тестовой и контрольной группах. Когда мы тестируем новый функционал или триггерную коммуникацию, мы смотрим не только на изменение целевой метрики, но и на то, как в целом меняется поведение пользователя. Мы выделили 4 base-line метрики пользовательского поведения:
Тут Zeppelin дает нам свободу в том, как мы хотим подводить итоги, какие метрики считать, как отрисовывать графики и как объяснять результат тем, кто будет пользоваться этим инструментом.
Собираем базы для коммуникаций и ретаргетинговых кампаний на основе выгружаемой из Amplitude когорты. Когда-то мы отказались от готовых коммуникационных платформ в пользу собственной разработки (возможно, это тема для отдельной статьи, а мы тут не об этом). Наше внутреннее решение было в первую очередь заточено под партнерские рассылки: выбери партнера и отправь сообщение на всю базу. А вот подготовка баз для продуктовых и маркетинговых коммуникаций — то есть собственных коммуникаций Кошелька — легла на плечи аналитиков. Типизировать все запросы от маркетинга и продактов казалось невозможным. Мы все стремились выделить наиболее релевантные сегменты, не ограничивая свои возможности. Например, вымышленный запрос, но запросы аналогичной сложности с нами случались:
Конечно, мы сохраняли код после каждой такой задачи и собирали его в некий монструозный конструктор. Но это все еще было время и внимание аналитика. А ошибка из-за невнимательности могла стоить нам волны негодующих пользователей, которые получили очевидно нерелевантную для них коммуникацию.
И все это так и было, пока один аналитик не обленился достаточно, чтобы не писать код для выборки пользователей в Clickhouse, а собрать когорту в Amplitude и выгрузить ее по api. Что, согласитесь, сильно проще и быстрее. Привычный и уже понятный интерфейс Amplitude, где любой менеджер может самостоятельно собрать когорту со всеми фильтрами из примера выше, проверить ее размер, дополнительно проконтролировать себя и проверить пользователей из когорты, что они попали в нее верно.
Как выглядит механика:
Что происходит в это время:
Я привела пример именно с пуш-рассылками, но у наших коллег быстро возникли идеи, где еще мы можем применять похожий инструмент: любые выгрузки списка пользователей с определенным пользовательским поведением. Сейчас мы используем когорты из Amplitude еще и для запуска ретаргетинговых кампаний. И, думаю, будем использовать и для многих других задач.
Системы мониторинга
Есть еще одна удобная фича, которая правда не относится к динамическим формам и, наверное, не совсем про автоматизацию – запуск по расписанию. Мы используем ее для пересчета дашбордов, запуска разных расчетов. Но самая полезная аналитическая задача, которую мы с ее помощью решаем, это мониторинг. Аномалии в событиях, в поведении метрик, что угодно, за чем должен регулярно следить аналитик, но что тоже хочется автоматизировать. Мы настроили систему алертов в slack и теперь можем вовремя реагировать на изменения, о которых хотим знать:
Success. Победили текучку, освободили время для развития аналитики в компании
Самый приятный абзац этой статьи – наступило светлое будущее! Мы уже автоматизировали большую часть наших Ad-hoc задач. Теперь в спринте их меньше 10%. В освободившееся время мы проводим исследования, выдвигаем и проверяем гипотезы, усложняем наши продукты аналитики и применяем подходы из тех самых статей и выступлений на конференциях. Другими словами, мы наконец занимаемся интересной аналитической работой. А главное, у нас появилось время принимать активное участие в развитии Кошелька.
Совет начинающим автоматизаторам: все частые и типовые куски кода выносите в библиотеки. Это позволит писать быстрее, улучшать качество написания кода всей команды аналитиков и править код в одном месте, а не во всех ноутбуках. И не забывайте, что вы делаете инструмент не для себя, а для своих коллег. А у них разный бэкграунд. Не пугайте их сложными интерфейсами и формулировками, делайте проще и понятнее.
Data-счастье еще впереди, но мы уже сильно воодушевились, ожили и бежим ему навстречу.
Когда пора задуматься о внедерении BI-системы?
В этой статье хочу поделиться личными наблюдениями вот за каким процессом. Как компании проходят путь от пункта «Нам достаточно стандартных отчетов в корпоративной учетной системе » до «Подготовка отчетности требует много времени и ресурсов. Пора все автоматизировать!». Надеюсь, что ниже иложенное поможет кому-то избежать некоторых ошибок и правильно выбрать решение Business Intelligence (BI-платформу).
Стадия первая. Прелюдия.
У руководства компании возникает потребность в регулярной отчетности (продажи, план-факт, финансовое состояние и прочее). Отчетность готовят специалисты соответствующих бизнес-подразделений (финансовый блок, коммерческая служба, логистика и т.д.). В этих подразделениях люди вынуждены совмещать свои основные обязанности (ведение учета, сопровождение договоров и т.п.) и подготовку отчетности. Из инструментов у них типовые отчеты в учетной системе и Excel. Причем с использованием Excel у них обычно не все в порядке.
Стадия вторая. Возбуждение.
Затем у руководителей растут аппетиты (растет компания, растет количество управленцев, приходят руководители с новым взглядом на бизнес и т.д.), и они начинают запрашивать все больше разовых (ad-hoc) отчетов, чтобы взглянуть на бизнес под разными углами. С ростом компании таких отчетов все больше, часть из них переходит в разряд регулярных, и у специалистов от бизнеса возникают проблемы с подготовкой всего этого многообразия в срок. В поисках спасения они начинают требовать от ИТ взять часть работы на себя, а именно, просят различные выгрузки из базы учетной системы (УС) и все чаще обращаются с требованиями разработать в УС новые отчеты.
Стадия третья. Зачатие (Эмбрион).
После всех этих процессов в компании начинает образовываться направление, именуемое бизнесом «аналитики». Так, в компании может появиться SQL-разработчик (с этого я начал путь) и специалист/ты, владеющие Excel и прочими программами из пакета Office. Развитие на этой стадии может проходить по-разному. Я лично видел, что со временем количество аналитиков может стать довольно большим (каждое подразделение обзаводится 1-2 специалистами или же в компании образуется отдельное подразделение). Я, кстати, мог оказаться и в этой роли, но мне повезло, что в университете меня не учили Excel’ю и на первом собеседовании тетенька из отдела HR сказала «ай-ай-ай». Мои уверения её в том, что я быстро (за пару недель) освою сей продукт, скорее всего, породили в ней мысль: «Явно передо мной самоуверенный болван, ибо у нас тут другие тетеньки годами работают на компутере и все еще боятся этого зверя, а этот наглый шкет такое заявляет». Лично мне быстро наскучило создавать разные выгрузки, и я начал интересоваться, а что же есть подходящего на рынке. Но в 2006 году я еще даже не знал термина BI, поэтому поиски были недолгими. Остановился я в результате на технологии OLAP.
Стадия четвертая. Избавление ИТ от ad-hoc или рождение OLAP. Начало проекта BI.
Как мне кажется, OLAP — уже довольно распространенная вещь, и с высокой долей вероятности в компании появляются люди, работавшие с OLAP-кубами как пользователи или разработчики. Они-то и сеят мысль о том, что внедрение кубов станет избавлением от многих проблем и облегчит жизнь большого количества сотрудников. Или же этот человек имел опыт с некой BI-системой. Поскольку сейчас речь скорее не о самых крупных компаниях, то людей, предлагающих что-то из SAP Business Objects, IBM Cognos, Oracle BI перестанут слушать, когда увидят ценник. В крупных же компаниях уже давно что-нибудь да есть, как минимум Microsoft BI (SQL Analysis Services и Reporting Services). «Как минимум» здесь не пренебрежение, просто это довольно распространенные решения, так как поставляются в комплекте в сервером БД, что часто приводит к выбору именно этой платформы.
Поскольку мы все хотим, чтобы наш проект вырос хорошим, добрым, сильным и здоровым, важно не совершить ряд типичных ошибок.
Ошибка первая. Спонтанный выбор системы.
Ошибка вторая. DWH или его отсутствие.
Бывает, что перед внедрением собственно системы подготовки автоматизированной отчетности, никто не озаботился тем, что все-таки было бы неплохо иметь хранилище данных (DWH). В результате, это приводит к тому, что OLAP или отчеты обращаются к большому числу источников данных, различным витринам, которые сформировались на 3-ей стадии. Из этого рождается хаос. Развивать и поддерживать систему после этого становится крайне затруднительно, и может оказаться так, что все придется строить заново.
Выбору системы для DWH тоже нужно уделить отдельное время, но зачастую это та же СУБД, на которой работает учетная система (УС). Такой подход вполне оправдан, так как в компании уже есть специалисты по продукту и может получиться экономия на лицензиях. Конечно, это не относится к случаю, когда в УС копится очень много данных (большое количество транзакций и СУБД выбиралась именно для этого) и лучше поискать другую СУБД, более подходящую для задач аналитики (есть механизмы колоночного хранения, размещение таблиц в оперативной памяти и т.п.).
Еще возможен вариант интеграции учетной системы с неким BI инструментом (видел предложения 1С + QlikView, от некоторых интеграторов), но тут я не совсем в курсе как всё устроено. Буду рад, если кто-то напишет об этом в комментариях или в личку.
Ошибка третья. Игнорирование того факта, что проект уже давно надо было начать.
Часто компании застревают надолго во второй стадии и это приводит к тому, что появляется множество различных витрин данных, кучи Excel-файлов с макросами для обработки данных и, конечно же, никто это никак не систематизирует и не описывает. Начиная в итоге проект BI, вы потратите намного больше времени на систематизацию требований, и придется столкнуться с некоторым сопротивлением со стороны пользователей, которые уже давно привыкли к тому, что есть. Например, они не захотят самостоятельно работать с кубами, потому как Вася из ИТ всегда сам делал им нужные выгрузки, тем самым сильно их избаловав. Все должно быть вовремя!
В общем, будьте готовы к тому, что ответственность за выбор и дальнейшую судьбу проекта будете нести именно Вы — читатели этой статьи, которая, надеюсь, вам хоть как-то поможет.