ВНЕДРЕНИЕ BI – СВОЯ КОМАНДА ИЛИ ПОДРЯДЧИК?
Предпосылки для статьи
Эта статья – результат командного опыта, десятков диалогов с заказчиками и одного небольшого исследования.
Но обо всём по порядку.
Sibedge – ИТ-компания, 18+ лет на рынке, 500+ выполненных проектов.
Последние 5 лет внутри компании активно развивается BI-направление, которое прошло несколько разных стадий. Сначала это была команда на аутсорсе, потом аутсорсная команда влилась в штат, а сейчас мы активно несём этот опыт в рынок в виде отдельного коммерческого направления по внедрению управления на основе данных. Другими словами, Sibedge попробовал разные варианты BI-команд и посмотрел на них с разных сторон.
В процессе общения с разными компаниями родилась гипотеза, которую мы исследовали и ещё продолжаем исследовать. Гипотеза звучит так: «Большинство компаний для внедрения BI предпочтут создать команду внутри, а не обратиться к подрядчику». Часто эти компании потом недовольны результатами, скоростью работы команды, качеством и пр. Но даже в этом моменте они не обращаются к экспертам. Почему? В этом месте, кажется, должна родиться новая гипотеза 😊
В первую очередь мы поставили перед собой задачу проанализировать и понять природу этих явлений. А потом уже решать, как модифицировать наш сервис под запросы рынка.
В статье не будет попыток навязать тот или иной формат команды. Но есть желание показать, как команды работают изнутри и какие задачи перед ними стоят. Возможно, для кого-то эта информация, полученная в правильный момент, окажется очень уместной. Как минимум, чтобы понимать – какие сотрудники нужны для построения внутренней команды, или какие требования предъявлять к подрядчику.
“Круговорот” данных в компании
Для того чтобы разобраться, какие роли должны быть в команде внедрения BI, давайте посмотрим на сам процесс внедрения и его составляющие. Сформулируем условные точки А и Б, чтобы проложить между ними маршрут.
Точка А. Компания работает без BI.
Как это обычно выглядит?
Есть набор информационных систем, в которых отражаются факты деятельности компании: CRM, ERP, ЭДО, ATS и многие другие системы.
Почти в каждой системе есть встроенная аналитика. Минусов у неё, как минимум, два: она ограничена заложенным функционалом и позволяет анализировать данные только одной системы. Чтобы построить сквозной анализ (а чем больше систем в компании, тем выше на это запрос), приходится собирать выгрузки из разных систем в какую-то единую конструкцию. Чаще всего всё собирается в Excel. Ручные выгрузки, ручной тюнинг данных в них, многоэтажные формулы или просто копирование с одного листа на другой. На подобные ручные обработки уходит много времени и сил, они часто не стабильны по времени готовности и многие такие отчёты собираются реже, чем хотелось бы, и часто содержат ошибки.
При такой организации процессов работы с данными тот анализ показателей и бизнес-результатов, который должен выполняться систематически и влиять на деятельность компании - систематически выполняться не может.
По Модели аналитической зрелости Гартнера это примерно первый уровень из пяти. Схематично я это представляю вот так:
Точка Б. Компания успешно прошла комплексное внедрение BI.
Те же самые информационные системы. Но вместо ручного труда сотрудников по сборке и обработке данных - инструменты хранения, обработки и визуализации данных. В качестве таких инструментов может быть разная комбинация BI, DWH, ETL и других систем. Алгоритмы сборки и обработки данных заложены в эти инструменты в соответствии с запросами бизнеса. Данные обновляются по заданному расписанию и визуализируются в интерактивных отчётах с настроенными правами доступа.
Дальше, как в игре, разблокируется следующий уровень - становится возможным регулярный анализ данных и принятие решений на его основе. Да, это частично было и в точке А, но носило несистематический характер и из-за сбоев в ручной обработке не давало системного результата.
Условие успешного функционирования “круговорота” данных заключается в том, что производится анализ данных и принятие решений - эти элементы внедрены в процессы жизнедеятельности компании. Принятые решения влияют на бизнес и через внедрение изменений меняют содержимое, состав или структуру тех данных, которые поступят в BI условно завтра. И в этом условном “завтра” запустится новый круг анализа данных уже немного изменённой компании.
Я называю это “круговоротом” данных в компании. Карл Андерсон в своей книге “Аналитическая культура” называет это цепочкой аналитической ценности.
По Модели аналитической зрелости Гартнера это примерно третий уровень из пяти. На четвёртом и пятом схема круговорота остаётся примерно той же, меняется внутреннее содержимое аналитики и сфера её применения. Но сегодня не об этом.
Стадии проекта по внедрению BI
Из каких же работ должен состоять проект по внедрению BI, чтобы из точки А прийти в точку Б?
С точки зрения блоков работ, их можно разделить на три:
- Непосредственно, отчёты. Сбор, обработка, трансформация и визуализация данных.
- Работа с системами. Доработка, разработка, внедрение информационных систем. Эти работы требуются в тех ситуациях, когда то, что мы хотим видеть в отчётах, строится на данных, которых у нас нет.
- Работа с процессами. Процессы “на входе” в аналитику - те, на данных которых строятся отчёты. И процессы “на выходе” - те, которые используют аналитику, процессы принятия решений.
Тут можно отдельно углубиться в каждый блок и убедиться, что для полноценного внедрения BI с нуля, необходимо глубокое погружение в деятельность компании, в суть бизнеса в целом и отдельных процессов в частности, нужно выстроить плотное взаимодействие между всеми элементами системы. Но оставим это на отдельную статью ;)
Какой должна быть команда
Исходя из того, какие блоки работ мы выделили, аналогично можно выделить и команды, выделив отдельные роли. При комплексном подходе у нас три типа команд, не считая самих заказчиков:
Команда разработки BI:
Руководитель проекта
Бизнес-аналитик
Data-архитектор - закладывает и поддерживает архитектуру решения, участвует в разработке моделей данных
Data-инженер - отвечает за сбор, обработку и трансформацию данных
Data-аналитик - отвечает за логику отчётов, визуал и метрики
DevOps-инженер
Дизайнер
Тестировщик
Команда разработки/доработки ПО (вместо неё может быть команда внедрения):
- Руководитель проекта
- Системный аналитик
- Архитектор
- Разработчики разного профиля
- DevOps-инженер
- Дизайнер
- Тестировщик
Команда внедрения и консалтинга:
- Консультант по управлению и организационному развитию
- Бизнес-аналитики
- Доменные специалисты
Ролей может быть больше или меньше, они могут различаться в некоторой степени по функционалу или названию. Но суть одна - ролей много и спектр задач сильно шире, чем может показаться на первый взгляд. Кроме того, спектр задач команды меняется со временем. Проект по внедрению BI имеет свои стадии развития внутри компании. И задачи на первых стадиях отличаются от задач, с которыми компания столкнётся на стадиях более поздних.
И, безусловно, организация BI-команды что внутри, что снаружи имеет ряд особенностей. И на каждую особенность, конечно же, есть свой способ работы с ней.
Внутренняя команда
При организации внутренней команды характерен дефицит компетенций:
- При не очень большом объёме задач нам придётся выбирать - это будет небольшая команда, где каждый будет нести на себе несколько ролей, или большая команда, где каждый кроме своей роли в BI, будет занят чем-то ещё. В первом случае получим невыраженные роли, во втором - расфокусированную команду.
- Если компания делает ставку на небольшую кросс-функциональную команду, то большой вопрос - где искать таких специалистов. Нужны универсалы, которые сочетают в себе качества двух разных доменов - работа с данными и понимание бизнес-логики. Нанимать таких дорого, обучать - сложно. Выпускники целевых курсов – далеки от реальных проектов, специальность видится как лёгкий вход в ИТ, ожидания по ЗП часто завышены.
- Отсутствие опыта реализации подобных проектов приводит к изобретению велосипедов в плане архитектуры и процессов, отставанию от лучших практик. Стоимость ошибок очень высока. А время, потраченное на обучение команды, может обернуться потерей мотивации к внедрению в принципе.
Внешняя команда
- Внешние исполнители не вовлечены в реалии бизнеса и могут не знать всех нюансов. То, что внутренний сотрудник может знать из контекста работы компании в целом, подрядчик может узнать уже при сдаче работ.
- Анализ данных, как никакой другой блок бизнеса чувствителен к изменениям. И изменения могут быть с разной частотой и разной степени глобальности. Если работа ведётся по ТЗ, нужны механизмы быстрого реагирования на изменения требований как со стороны подрядчика, так и со стороны заказчика.
- Аналитика - это всегда конфиденциально и часто очень лично для компании. И у компаний нередко есть страх раскрытия внутренней информации. Страшно показывать сторонней компании своих «скелетов в шкафу» и страшно, что эта информация будет раскрыта. Доверие, тактичность и конфиденциальность - то, что здесь требуется в первую очередь.
Прежде чем перейти к выводам, посмотрим на результаты опросов - а что считают по этому поводу некоторые сообщества?
Исследование и выводы
Мы провели серию опросов в релевантных телеграм-каналах, чтобы узнать, что думают компании и специалисты BI по поводу внутренних и внешних команд. И потом провели опрос ещё и на секции конференции Город ИТ в Томске. И вот что у нас получилось.
Гипотеза, с которой мы заходили в это исследование, заключалась в том, что большинство компаний, которые используют BI, разрабатывают аналитику силами внутренних команд. Хотелось посмотреть – каково соотношение в предпочтениях.
В исследовании в общей сложности приняли участие около 200 человек. Между вариантами INHOUSE (внутренняя разработка) и OUTSOURCE (внешняя разработка) голоса распределились в соотношении примерно 3 к 1 в пользу внутренней разработки. Но дьявол, как всегда, в деталях. Давайте посмотрим подробнее.
Первое голосование было запущено в канале поддержки Power BI.
- Канал: Power BI Group RU.
- Тематика канала: вопросы поддержки разработки на Power BI.
- Аудитория: в основном специалисты Power BI разного уровня и, в меньшей степени, рекрутёры.
- Вопрос: «В какой вы команде?»
- Распределение: INHOUSE 69,1%; OUTSOURCE 30,9.
Затем мы запустили опрос в канале Data Driven Decisions. Распределение получилось ещё более выраженным.
- Канал: Data Driven Decisions.
- Тематика канала: управление на основе данных, Unit-экономика.
- Аудитория: бизнес, стартапы.
- Вопрос: «Кто в вашей компании/команде отвечает за внедрение?»
- Распределение: INHOUSE 85,2%; OUTSOURCE 14,8%.
Затем мы запустили опрос в канале Data Driven Decisions. Распределение получилось ещё более выраженным.
- Канал: Data Driven Decisions.
- Тематика канала: управление на основе данных, Unit-экономика.
- Аудитория: бизнес, стартапы.
- Вопрос: «Кто в вашей компании/команде отвечает за внедрение?»
- Распределение: INHOUSE 85,2%; OUTSOURCE 14,8%.
И третий опрос – в канале Совет директоров Skillstime. Тут случилось интересное. Опрос был запущен на два варианта ответов. Но уже в процессе голосования от аудитории поступило предложение голосовать за третий вариант – сочетание внутренней и внешней команд.
- Канал: Совет директоров Skillstime.
- Тематика канала: консалтинг, развитие бизнеса.
- Аудитория: бизнес.
- Вопрос: «Какую команду выбрали бы при внедрении BI?»
- Распределение: INHOUSE 41,7%; OUTSOURCE 29,2%; INHOUSE+ OUTSOURCE: 29,2%.
Наконец, на самой секции BI на конференции мы провели голосование среди аудитории. Тут уже изначально было три варианта.
- Канал: секция внедрения BI на ИТ-конференции Город ИТ.
- Тематика канала: варианты внедрения BI.
- Аудитория: бизнес, специалисты BI.
- Вопрос: «Какой вариант BI-команды вам кажется более оптимальным?»
- Распределение: INHOUSE 61,5%; OUTSOURCE 7,7%; INHOUSE+ OUTSOURCE: 30,8%.
Какие выводы напрашиваются из этих результатов?
- Внутренних команд значительно больше, чем подрядчиков. Это прослеживается во всех группах, участвовавших в исследовании.
- Закономерно, что чем ближе компания к ИТ-сфере, тем больше шансов у неё уйти во внедрение собственными силами.
- Откровением был третий опрос. Распределение явно выбивается из общей картинки. Мы предполагаем, причина в том, что аудитория канала знакома с услугами консалтинга. Вероятно, их доверие услугам сторонних организаций выше, чем у остальных групп, участвовавших в исследовании. Но это повод сформулировать новую гипотезу и пойти с ней к аудитории.
Выводы
Какое же оптимальное решение для организации команды? Какую команду выбрать и что учесть, чтобы потом не было мучительно больно и грустно? Безусловно, все варианты развития команд есть и будут. Та идея, которую мне хотелось бы донести и ради которой родилась эта статья - осознанность выбора команды. Итак, что бы мне хотелось здесь сказать в качестве выводов.
Внутренняя команда
- Когда оптимально?
Внутренняя команда однозначно хорошо подходит для ситуаций, когда объём работ достаточно большой и стабильный. В таких ситуациях можно собирать достаточно большую команду, когда на каждой роли будет отдельный сотрудник или даже несколько.
И вторая ситуация, когда имеет смысл собирать внутреннюю команду, когда руководитель осознаёт все аспекты построения такой команды, готов вкладывать ресурсы в обучение и развитие сотрудников. Либо если уже есть высококвалифицированные сотрудники, готовые закрыть несколько ролей в такой команде.
- Что необходимо учитывать?
На первых стадиях проекта лучше подключать высококвалифицированных специалистов, которые заложат правильный фундамент последующих работ и зададут необходимый вектор развития проекта как с технической точки зрения, так и с бизнесовой. Команде будет необходимо постоянное обучение. Должен быть налажен хороший контакт между командой и заказчиками со стороны бизнеса - обмен информацией, нюансами бизнес-логики, техническая поддержка, обучение пользователей и другие важные процессы. Помните, что недостаточно просто собрать отчёты - они должны быть увязаны с процессами и данными с разных сторон.
Внешняя команда
- Когда оптимально?
Внешняя команда кажется оптимальным выбором, когда у вас меняющийся объём работ (небольшие компании, точечные задачи), нет понимания «как надо», нет ресурсов и/или желания на организацию дополнительной команды внутри, нет движущей силы.
- Что необходимо учитывать?
Надёжный компетентный подрядчик, которому вы можете доверять.
Продуманный договор, учитывающий возможные изменения как в перечне работ, так и в приоритетах.
Регулярные (я бы даже сказала - частые) синхронизации по работам. Чтобы как можно быстрее реагировать в случае неверно выбранного направления работ. Чем плотнее и доверительнее команда подрядчика взаимодействует с заказчиком, тем лучше.
И третий вариант: Подрядчик + Внутренняя команда
- Когда оптимально? При внедрении BI с нуля на всю компанию, работы меняются. На первых порах необходимо грамотно заложить архитектуру и основы моделей данных, правила работы с данными и прочие базовые вещи. Через некоторое время, когда бОльшая часть запросов будет реализована, наступит момент некоторой стабилизации уровня работ. Основные трудозатраты будут уходить на корректировку отчётности под изменяющиеся потребности компании и техническую поддержку. Соответственно, снизится необходимый уровень компетенции команды, работы станут более прогнозируемыми и стабильными. Вот в этот момент, при желании, можно сменить команду подрядчика на внутреннюю команду.
Интерактивно результаты опросов можно посмотреть в отчёте.
А что бы выбрали вы? Напишите, пожалуйста, в комментариях, какой вариант BI-команды вам кажется более оптимальным и почему?
Больше публикаций на тему внедрения BI и DDDM - в нашем телеграм-канале. Буду рада видеть вас в числе подписчиков 😉
Мария Дробинская, Руководитель BI-направления Sibedge
Статья интересная, но результаты вполне ожидаемы для стороны инхаус решений. Тут возможно стоит рассматривать в совокупности с затратами, комплаенс процедурами в компаниях и sla. В том числе все хотят перестраховаться с бигдатой, которая может уйти из-за использования аутсорса.