В этой статье я хочу поделиться своими личными наблюдениями за этим процессом.
Как компании проходят путь от пункта «Нам достаточно стандартных отчетов в корпоративной системе учета» к «Подготовка отчетов требует много времени и ресурсов.
Пришло время все автоматизировать!» Я надеюсь, что следующее поможет кому-то избежать некоторых ошибок и выбрать правильное решение для бизнес-аналитики (платформу BI).
Первый этап .
Прелюдия.
У руководства компании возникает потребность в регулярной отчетности (о реализации, план-факт, финансовое состояние и т.п.
).
Отчетность готовят специалисты соответствующих бизнес-подразделений (финансового блока, коммерческой службы, логистики и т.д.).
В этих отделах люди вынуждены совмещать свои основные обязанности (ведение учета, ведение договоров и т. д.) и подготовку отчетов.
В их инструментарий входят стандартные отчеты в учетной системе и Excel. Более того, при использовании Excel у них обычно не все в порядке.
Второй этап .
Возбуждение.
Потом аппетиты менеджеров растут (растет компания, растет количество менеджеров, менеджеры приходят с новым взглядом на бизнес и т. д.), и они начинают запрашивать все больше и больше разовых отчетов, чтобы посмотреть на бизнес со стороны.
разные углы.
По мере роста компании таких отчетов становится все больше, некоторые из них становятся регулярными, и у специалистов бизнеса возникают проблемы с подготовкой всего этого многообразия вовремя.
В поисках спасения они начинают требовать, чтобы ИТ взяло на себя часть работы, а именно просят различные загрузки из базы данных учетной системы (АС) и все чаще просят разрабатывать новые отчеты в МС.
Этап третий .
Зачатие (? эмбрион).
После всех этих процессов в компании начинает формироваться направление под названием «аналитический бизнес».
Итак, в компании может быть SQL-разработчик (с этого я начинал) и специалист/вы, умеющий пользоваться Excel и другими программами из пакета Office. Развитие на этом этапе может происходить по-разному.
Я лично видел, что со временем количество аналитиков может стать довольно большим (каждое подразделение приобретает по 1-2 специалиста или в компании формируется отдельное подразделение).
Я, кстати, мог бы оказаться на этой должности, но мне повезло, что в университете меня не учили Excel, и на первом же собеседовании дама из отдела кадров сказала «а-а-а».
Мои уверения в ее адрес, что я быстро (за пару недель) освою это изделие, скорее всего, породили в ней мысль: «Очевидно передо мной самоуверенная идиотка, ведь у нас здесь есть другие женщины, которые были много лет работаю за компьютерами и до сих пор боюсь этого зверя, и так говорит этот наглый негодяй».
Лично мне быстро надоело создавать разные загрузки, и я начал интересоваться, что же есть подходящего на рынке.
Но в 2006 году я еще даже не знал термина BI, поэтому поиск был недолгим.
В результате я остановился на технологии OLAP.
Четвертый этап .
Избавление от ИТ от ad-hoc или рождение OLAP. Старт BI-проекта.
Мне кажется, что OLAP — это уже достаточно распространенная вещь, и с большой долей вероятности в компании появляются люди, работавшие с OLAP-кубами в качестве пользователей или разработчиков.
Они сеют идею, что внедрение кубов избавит от многих проблем и облегчит жизнь большому количеству сотрудников.
Или у этого человека был опыт работы с определенной BI-системой.
Поскольку сейчас речь, скорее всего, идет не о крупнейших компаниях, люди, предлагающие что-то из SAP Business Objects, IBM Cognos, Oracle BI, перестанут слушать, когда увидят ценник.
У крупных компаний уже давно что-то есть, хотя бы Microsoft BI (SQL Analysis Services and Reporting Services).
«Как минимум» здесь не является пренебрежением, просто это вполне распространенные решения, поскольку они поставляются в комплекте с сервером базы данных, что часто приводит к выбору именно этой платформы.
Поскольку мы все хотим, чтобы наш проект вырос хорошим, добрым, сильным и здоровым, важно не совершить ряд распространенных ошибок.
Ошибка первая .
Спонтанный выбор системы.
Как это произошло? Поскольку этим человеком может быть как высокопоставленный человек, так и очень активный ИТ-специалист, отдающий предпочтение определенному продукту, то время на выбор системы не выделяется, а просто покупает то, что эти люди пролоббировали.
Это может привести к тому, что выбранный продукт толком не приживется в компании и, решив одни проблемы, заменит их другими.
Я думаю, что прежде чем сделать выбор, следует ответить хотя бы на следующие несколько вопросов (подробнее об этом я писал в последняя статья ):
- Для кого предназначена система (кто является основным потребителем)?
- Каковы предпочтения компании в способах доставки данных потребителю?
- С каким объемом данных вам придется иметь дело?
- Сколько компания готова платить за все это и тратить на дальнейшее развитие и обслуживание?
- Насколько система может разделить функционал между ИТ-специалистами и аналитиками, отвечающими за подготовку презентаций, аналитических записок и т. д.
В некоторых системах можно довольно просто разделить функции следующим образом: ИТ-специалисты отвечают за разработку моделей данных, а аналитики занимаются информационными панелями, формами отчетности — тем, что видят конечные бизнес-пользователи.
Почему это? Требования к внешнему виду отчетов чаще всего меняются.
Плюс по сути один и тот же отчет (набор данных) может существовать в нескольких вариациях для разных клиентов.
Кроме того, в дизайне по-прежнему важна эстетика, на которую у ИТ-специалистов не всегда хватает времени; их работа — заставить все это работать.
Это особенно важно, если у вас есть хорошие разработчики с БОЛЬШИМИ зарплатами.
Чтобы избежать проблемы, терапию необходимо начать своевременно.
Хорошо, если на 2-3 этапах ИТ систематизирует потребности, ответив на первый вопрос и подтолкнет бизнес к вопросу внедрения BI. На этих этапах заказчики полны энтузиазма и готовы обсуждать разные варианты, а главное формулировать свои требования, что, на мой взгляд, является основной задачей бизнес-пользователей в этом проекте (опять же см.
предыдущую статью).
Ошибка вторая .
СХД или ее отсутствие.
Бывает, что до внедрения собственно автоматизированной системы отчетности никто не заморачивался тем, что еще неплохо бы иметь хранилище данных (СХД).
В результате это приводит к тому, что OLAP или отчеты обращаются к большому количеству источников данных, различных витрин, которые были сформированы на 3-м этапе.
Отсюда происходит хаос.
Развивать и поддерживать систему после этого становится крайне сложно, и может оказаться, что все придется строить заново.
Выбору системы для СХД тоже нужно уделить особое время, но зачастую это та же СУБД, на которой работает учетная система (УС).
Такой подход вполне оправдан, поскольку в компании уже есть специалисты по продукту и можно сэкономить на лицензиях.
Конечно, это не относится к случаю, когда в системе накапливается много данных (большое количество транзакций и СУБД выбрана специально для этой цели) и лучше поискать другую СУБД, более подходящую для задачи аналитики (есть механизмы хранения столбцов, размещения таблиц в оперативной памяти и т.п.
).
Также возможна интеграция учетной системы с определенным BI-инструментом (видел предложения 1С+QlikView от некоторых интеграторов), но здесь я не совсем в курсе, как все работает. Буду рад, если кто-нибудь напишет об этом в комментариях или в личном сообщении.
Ошибка третья .
Игнорируя тот факт, что проект должен был начаться уже давно.
Зачастую компании надолго застревают на втором этапе и это приводит к появлению множества различных витрин данных, кучи Excel-файлов с макросами для обработки данных и, естественно, это никто никак не систематизирует и не описывает. Когда вы в конечном итоге начнете BI-проект, вы потратите гораздо больше времени на организацию требований и вам придется столкнуться с некоторым сопротивлением со стороны пользователей, которые уже давно привыкли к тому, что там есть.
Например, они не захотят работать с кубами самостоятельно, потому что Вася из ИТ всегда сам делал для них необходимые загрузки, тем самым сильно их портя.
Все должно быть вовремя!
Нижняя граница.
В заключение, приятно иметь возможность потратить время на встречи с интеграторами для ознакомления с различными системами, но я видел это только в очень крупной компании, где стоимость проекта DWH+BI оценивалась в сотни тысяч долларов.
долларов.
Была как заинтересованность руководства (ответственность за бюджет), так и заинтересованность исполнителей (крупный заказ).
И все это длилось целый год. В небольших компаниях это просто невозможно.
К сожалению, я не встретил интеграторов (возможно, плохо искал), которые бы предоставляли широкую экспертизу.
Обычно они концентрируются на 1-2 продуктах.
Я лично общался с 10 компаниями-интеграторами примерно со следующей ситуацией: 2 занимаются Microsoft BI, 2 QlikView, 3 Cognos BI, 1 Tableau, 1 Cognos и Microsoft, 1 QlikView и Tableau. В общем, будьте готовы к тому, что ответственность за выбор и дальнейшую судьбу проекта понесете вы, читатели этой статьи, которая, надеюсь, хоть как-то вам поможет. Теги: #BI #olap #бизнес-аналитика #бизнес-аналитика #би-система #BI-платформа #Управление проектами
-
Экспоненциальный Рост В Сфере 3D-Печати
19 Oct, 24 -
Ты Удивил Меня.
19 Oct, 24 -
Минимальный Размер Контента В Сетке Css
19 Oct, 24
