Почему не «взлетают» BI проекты или антология наших факапов

Меня зовут Диана и вот уже почти 5 лет я и моя команда занимаемся внедрением BI решений. Было бы наивно пытаться убеждать, что за историю более нескольких сотен внедренных отчетов в 130+ компаниях у нас не было больших и маленьких провалов. Ошибки были разные – некоторые ошибки новичка неприятно вспоминать, другие помогли научиться новым и крутым вещам. Из каждого пережитого факапа мы делали выводы и учились не проходить снова по этому пути. Бойтесь не тех, кто ошибался и признаёт это, а тех, кто заявляет, что никогда не ошибался и уверен в своей непогрешимости.

Эта заметка писалась в первую очередь для нашей команды, но я уверена, это будет полезное чтение и для IT-директоров, интеграторов различных программных решений, проектных менеджеров, финансовых директоров и всех тех, кто отвечает за цифровизацию в бизнесе. Отдельно хочу отметить тех, кто когда-то обжёгся при внедрении BI, мне хочется попробовать объяснить им, что возможно проблема неудачи была не в самом BI-решении, а в ошибках при реализации.

Крупные неудачи я делю на два типа: те, что напрямую зависят от интегратора, и те, которыми сложно управлять, но можно “скоррить” (оценивать) и управлять рисками «на берегу». Типов неудач из моего опыта могут набраться десятки, но так или иначе они сводятся к основным шести.

Гигиенический минимум ролей в команде: бизнес-аналитик, разработчик и проектный менеджер.

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

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

Проектный менеджер – соблюдение сроков, договоренностей, маневрирование приоритетами и бюджетом.

Вытащите один элемент из этого золотого «трио» и проект сыпется. Мы совершали ошибки, когда запускали в работу проекты с проектным менеджером и разработчиком, и это были провальнейшие истории. Внешне все выглядит как надо: сроки, переписки, задачи, сданный результат. Вроде работа сделана, а решения проблемы нет.

Кстати, знаете кто самый ценный из этой всей схемы? На удивление не разработчик, а бизнес-аналитик. Бизнес-анализ это не хард скиллы, которые нарабатываются курсами и опытом, – это набор навыков, которые воспитываются внутри экспертной команды терпеливым усердием наставников и самого аналитика.

«Мы сделали все по ТЗ заказчика, потратили кучу времени и сил, но ему ничего не нравится, топает ножками и просит все переделать» – частая реплика малышей-интеграторов,фрилансеров и неопытных руководителей проектов.

Написать хорошее ТЗ это почти инженерия. Не надо так переоценивать среднестатистического бизнес-заказчика. Воспринимайте каждое ТЗ как подсказку и точку, от которой стартует ваш проект. Не воспринимайте его как финальный пункт. Маршрут выстраивается только в диалоге с заказчиком. Возможно, не в одном диалоге и не с один заказчиком. Именно поэтому незаменим хороший бизнес-аналитик. (см. выше)

Сбор требований для отчетов, а также финальная постановка задачи для разработчика – это регламентированная методология, а не творчество. Поэтому ответственными за ТЗ должны оставаться специально обученные для этого люди со стороны интегратора.

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

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

И когда спустя 5-6 месяцев долгой и мучительной разработки вы выкатываете «слона», оказывается, что нужен был вообще-то носорог, и вообще-то еще 3 месяца назад. Все недовольны, бюджеты потрачены, отношения испорчены.

MVP и пилотные запуски – это движение итеративно. Я знаю многие бюджетодержатели просят оценивать проект сразу целиком, чтобы примериться потянет ли компания такой проект. Но это не лучший подход. Оптимальнее запустить пилот с небольшим бюджетом и понятным на текущий момент конечным результатом. MVP позволяет присмотреться друг к другу – как интегратор работает, как заказчик дает обратную связь. MVP уже можно продать внутреннему спонсору проекта для того чтобы обосновать дальнейшие инвестиции. MVP – это как съехаться пожить вместе перед свадьбой. Возможность «сыграть» в реальный проект, но без больших рисков.

«Я фанат дашбордов», «хотим красивые графики», «у моего товарища Power BI, и мне нужен» – прекрасный старт для проекта, который имеет высокие шансы на провал. Как правило заказчик в этом случае не имеет конкретной задачи, которую он хочет решить, зато следует неким модным тенденциям цифровизации из блогов и СМИ. Мы смотрим Американские сериалы, а там крутые бизнесмены попивают виски посреди рабочего и задумчиво изучают красивые диаграммы на больших экранах. Не думаю, что для вас это будет откровением – и то и другое далеко от реальной истины. Я не к тому, что в корпорациях не используют дашборды и аналитику. Как раз-таки наоборот. Вот только профессиональная аналитика обычно насыщена информацией и точками принятия решений.

Сами по себе красиво нарисованные графики хороши разве что для антуража. И если заказчик на понимает какую задачу он будет решать этими «графиками», то к такой бесполезной и не дешевой игрушке он быстро потеряет интерес. А соответственно интерес теряет как команда заказчика, так и команда разработки – проект превращается в вялотекущий кисель.

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

Как правило, со стороны заказчика есть несколько задействованных (и очень в разной степени заинтересованных) единиц в проекте – это могут быть внутренние IT, внутренние аналитики или финансисты, руководители подразделений, менеджеры того или иного звена. И вся эта чудесная компания дорогостоящих, занятых, важных ребят ведет себя очень по разному – кто-то диктует свои условия, требования, приоритеты. Кто-то по уши вовлечен в срочные операционные процессы. Кто-то «курит бамбук в стороне». Кто-то скромно пытается внести свои критически важные замечания и его не слышат. И когда над этим «нашим дружным и амбициозным коллективом» нет проектного менеджера внутри заказчика, возникают неприятности в виде растянутых сроков, неправильно выстроенных приоритетов и негатива, который сыпется на интегратора, потому что найти виноватого все-таки нужно.

Проектный менеджер – это человек внутри заказчика, который понимает стратегию компании, цель внедрения, приоритетность внутренних задач. Тот, кто умеет вытащить финансового директора из операционки в нужный момент, сфокусировать внутренний IT на проектных задачах, ускорить тестирование сданных этапов. То, на что у проектного менеджера интегратора нет достаточных полномочий и рычагов. Проектный менеджер со стороны заказчика – это тот элемент, который в итоге может сэкономить немало и денег, и нервов для всех.

Это мое любимое! Здесь много слоев внутри, можно довольно интересно раскрутить это до процессов «управления изменениями» (да-да, частая задача топов по change management), но не будем выходить за рамки основной темы. Под саботажем я понимаю достаточно серьезное внутреннее сопротивление проекту.

Я разделяю саботаж на осознанный и неосознанный.

Осознанный саботаж – это когда человек вполне здраво рассуждает о том, что придут сейчас умники и своим Питоном (это кстати язык программирования, а не метафора) и BI-аем автоматизируют всю ту рутинную долгую работу, за которую, в общем-то, этому сотруднику и платят. И если сотрудник в этот момент оценивает себя как оператора по сбору отчетов и не видит иной ценности, которую может дать бизнесу, то он, очевидно, будет видеть не возможности для себя, а угрозу потери рабочего места. Похожим примером может быть неуверенный в себе IT-директор, который боится что придут профессиональные ребята и на основе их погружения в проект подсветят его некомпетентность в технических вопросах.

Третьей причиной осознанного саботажа может быть менеджер или руководитель, который понимает что благодаря оцифровке и аналитике вся его работа окажется на виду. Например РОП уже не сможет ссылаться на кривые отчеты в CRM и отсутствие инструментов контроля – и тогда придется отвечать за результат.

Неосознанный саботаж – это когда человек в целом не против, у него даже возможно успешность проекта стоит в kpi, однако он недостаточно ленив, и готов продолжать использовать неэффективный подход. Он не понимает глобальной ценности этого проекта для себя и для команды. Наверное это самый сложный типа саботажа – мы встречали такое и даже у меня опускаются руки в таких случаях. Отдельно плохо, когда такой сотрудник стоит где-то вверху проекта и на многое влияет (или должен влиять). При этом подчиненные готовы к изменениям, высшее руководство готово к изменениям, интегратор прекрасно понимает как это реализовать и вся эта кипящая энергия разбивается о неосознанный саботаж одного сотрудника. И что самое главное: открытого саботажа нет – сотрудник же не против.:) Боль-боль.

Мой личный опыт говорит, что сегодня в BI нуждается и средний бизнес, и крупный, и малый. Первый этап, когда это было инновацией и чем-то модным остался позади. Как сегодня странно смотрится человек с кнопочным телефоном вместо современного смартфона, так и бизнесу уже не угнаться за летящим вперед миром без современной, качественной аналитики. Вопрос лишь в том, чтобы приобретённая аналитика выполняла свою главную роль – помогала бизнесу отслеживать важные процессы и находить инсайды. В BI есть свой принцип Парето: 80% усилий при реализации проекта будет затрачено на работу с источниками данных и лишь 20% непосредственно на визуализацию. Но еще до начала непосредственно разработки стоит пройтись по пунктам выше и постараться заранее предупредить возможные в будущем проблемы.