Спасибо Вам огромное за ваши видео! Так все подробно и понятно. Стараюсь каждое утро смотреть и повторять ваши уроки. Рада, что эти знания легко адаптируются к Power Pivot при работе в экселе. Удачи Вам и Вашему каналу! 🙏🙏🙏
Долго не мог определится (как новичок в BI-аналитике), с чего начать: Tableau или Power BI. Сначала думал первое, но сложилось впечатление, что туда лучше идти хотя бы как мидл, но проблема Power BI, что мало качественных курсов. И вот наконец по Power BI в рунете удалось найти вас, и вы просто бриллиант для джуна, спасибо большое за ролики❤
И что подметил как человек с университетским образованием, вы не пытаетесь урезать теорию там где она действительно нужна, как всякие инфоцыгане. Сказал бы даже наоборот, очень не хватает материала для нас математиков, которые погружаются во всю эту историю, которые за плечами уже имеют знания по той же теории множеств, понимающие, например, термины пересечение, произведение, разность множеств (и тд), но ещё не работавших в BI-аналитике. Складывается ощущение, что вы настоящий университетский преподаватель. Одним словом, спасибо за ваш труд 🙏
Спасибо большое за теплый отзыв! Очень поднимает мотивацию! По поводу стиля изложения - я стараюсь вспоминать себя, когда начинала изучать Power BI, и объяснять как для "себя в прошлом". Это еще и помогает помнить, что все мы были когда-то новичками и нужно не кичиться своими знаниями, а делиться ими😉
Благодарю Вас за информативный цикл практик по Bi. Очень полезно и информативно! Поздравляю Вас с наступающим Новым Годом, желаю процветания Вашему каналу.
Про UX и дизайн интересно и полезно, спасибо! Хотелось бы про дизайн, совместимость и уместность элементов знать побольше, если Вам есть, что еще рассказать по этой тематике, было бы интересно послушать, в т.ч., может, и какие-то истории из жизни))) Ну и с т.зр. техники материал полезный. Некоторые ремарки 1. о первых двух критериях оценки дашборда (корректность и полнота) бессмысленно говорить при отсутствии корпоративного справочника, в котором точно прописана методология управленческого учета и, как следствие, методика расчета показателей (мер) и определение размерностей. Иначе будет неопределенность при толковании, казалось бы, даже самых простых понятий. Например, выручка: она учитывает или не учитывает возвраты покупателю/заказчику? А если учитывает и с момента поступления денег от покупателя/заказчика до момента возврата прошло несколько дней, то вот в эти дни что есть эти денежные средства, которые у нас на счету? А реализация в какой момент сторнируется? И это самое первое, что приходит в голову. 2. Актуальность и безопасность - это вообще не вопрос PBI. Это вопросы регулярности наполнения DWH и политик безопасности/доступа. Те, кто думают, что на PBI делается всё - жестоко ошибаются. Ну т.е. отдельную витрину данных (какая-нибудь рекламная компанию в интернете) проанализировать еще можно, а вот для чего-то более серьезного всё равно придется строить DWH из нескольких источников, и уже поверх него аналитическое хранилище (Multidimensional или Tabular - вопрос философский). На нем и будут работать дашборды на PBI. И от этого слоеного пирога никуда не деться. 3. При построении дашборда/отчета нужно четко понимать, что это за отчет (операционный, аналитический или стратегический) и какие действия его пользователь может предпринимать на его основе. Тогда мы понимаем, что именно в отчете/дашборде должно присутствовать и каков должен быть вид всего этого. Например, для стратегического дашборда дриллдаун и какие-то подробные таблицы нафиг не нужны, а вот операционный отчет скорее уместен в экселе в виде сводных таблиц с нарезкой по размерностям на основе аналитического куба. Это к вопросу применимости таблиц с раскрытием «плюсиками» в PBI.
Добрый день! Спасибо за ваши видео! могли бы выпустить видео по тем формулам которые могут "утяжелять" дашборд? возможно иногда стоит использовать одно, а не другое, зато будет быстрее работать
Мысль интересная) Сейчас я бы сказала, что на "утяжеление дашборда" больше влияет алгоритм расчета (то есть расчет и все примененные функции целиком), а не одна какая-то функция. Подумаю, спасибо)
У меня такая же проблема, очень долго обновляется дашборд и отчёты выполненные в экселе (power query+power pivot). Пока поняла, что лучше по минимуму использовать Power query (особенно группировку и объединение) и делать это через Power Pivot. Также csv файлы работают намного быстрее, чем xlsx
Как точно вы подметили, что пользователи не понимают сколько сил и терпения было вложено в дашборд) Для них это обычная красивая презентация, и им неинтересен процесс расчета и логика.
Спасибо. Подскажите как аналитику понимать какие данные что дают бизнесу и какие данные нужно указывать в отчёте ?? Какие математические формулы нужны или ещё что-то???
Если говорить о разработке отчета в Power BI, то давайте от этого и отталкиваться. Разрабатывать отчет в Power BI может либо собственно разработчик (1), для которого это основная работа и главный скилл, либо аналитик/финансист/продажник (2), в общем любой другой работник, для которого разработка отчета в Power Bi - второстепенный скилл. Соответственно в первом случае, разработчик не обязан знать какие показатели нужны бизнесу. Конечно, сделав хотя бы 3-4 отчета в разных областях или просто погуглив примеры отчетов, разработчик может предложить набор показателей и метрик и даже структурный макет. Но это не его профильный скилл. Я за то, чтобы каждый занимался своим делом. Чтобы стать профессионалом в какой-то области, нужно много времени. Еще больше времени нужно, чтобы стать профессионалом в нескольких областях. Если же отчет разрабатывает отраслевой аналитик, например аналитик продаж, то для аналитика знание своей отрасли, бизнес-процессов и метрик, которые их характеризуют - это его профессиональный основной скилл, который нарабатывался опытом и профильным обучением. Поэтому в идеале для хорошего отчета нужна кооперация разработчика и тех, кто погружен и знает отраслевые бизнес-процессы. Повторюсь - это в идеале. В жизни бывает по разному. Общие правила здесь наверно, это, нарабатывать больше опыта. Больше насмотренности. Разбирайте чужие работы, отмечайте для себя их минусы и плюсы. Развивайте любознательность, чтобы с разных сторон смотреть на свою работу и ее результат. Будьте внимательны к заказчику, к заданиям на разработку, к собственной работе. Может кто-то еще что подскажет?)
Вы настоящий профессионал, впечатляет ваш уровень владения DAX, пожалуй самой сложной частью Power BI. Спасибо, что делитесь своими знаниями!
Спасибо за обратную связь!!
Спасибо Вам огромное за ваши видео! Так все подробно и понятно. Стараюсь каждое утро смотреть и повторять ваши уроки. Рада, что эти знания легко адаптируются к Power Pivot при работе в экселе. Удачи Вам и Вашему каналу! 🙏🙏🙏
Спасибо большое!! Очень приятно знать, что то, что я делаю, помогает другим таким же пользователям Power BI 😀❤️
Мега огромное мега спасибо!
СПАСИБО. ВСЁ ДОСТУПНО. Буду ждать новых публикаций.
Спасибо!
Долго не мог определится (как новичок в BI-аналитике), с чего начать: Tableau или Power BI. Сначала думал первое, но сложилось впечатление, что туда лучше идти хотя бы как мидл, но проблема Power BI, что мало качественных курсов. И вот наконец по Power BI в рунете удалось найти вас, и вы просто бриллиант для джуна, спасибо большое за ролики❤
И что подметил как человек с университетским образованием, вы не пытаетесь урезать теорию там где она действительно нужна, как всякие инфоцыгане. Сказал бы даже наоборот, очень не хватает материала для нас математиков, которые погружаются во всю эту историю, которые за плечами уже имеют знания по той же теории множеств, понимающие, например, термины пересечение, произведение, разность множеств (и тд), но ещё не работавших в BI-аналитике. Складывается ощущение, что вы настоящий университетский преподаватель. Одним словом, спасибо за ваш труд 🙏
Спасибо большое за теплый отзыв! Очень поднимает мотивацию! По поводу стиля изложения - я стараюсь вспоминать себя, когда начинала изучать Power BI, и объяснять как для "себя в прошлом". Это еще и помогает помнить, что все мы были когда-то новичками и нужно не кичиться своими знаниями, а делиться ими😉
Большое спасибо за ваши уроки! Помогают разбираться в теме. Удачи Вам и благополучия в наступившем году!
Спасибо большое! И вас с Новым годом😉
Благодарю Вас за информативный цикл практик по Bi. Очень полезно и информативно! Поздравляю Вас с наступающим Новым Годом, желаю процветания Вашему каналу.
Спасибо большое за теплый отзыв и поздравление! Вас тоже с Новым годом!!!
Интересный урок. Спасибо вам)
Спасибо!
Про UX и дизайн интересно и полезно, спасибо! Хотелось бы про дизайн, совместимость и уместность элементов знать побольше, если Вам есть, что еще рассказать по этой тематике, было бы интересно послушать, в т.ч., может, и какие-то истории из жизни))) Ну и с т.зр. техники материал полезный.
Некоторые ремарки
1. о первых двух критериях оценки дашборда (корректность и полнота) бессмысленно говорить при отсутствии корпоративного справочника, в котором точно прописана методология управленческого учета и, как следствие, методика расчета показателей (мер) и определение размерностей. Иначе будет неопределенность при толковании, казалось бы, даже самых простых понятий. Например, выручка: она учитывает или не учитывает возвраты покупателю/заказчику? А если учитывает и с момента поступления денег от покупателя/заказчика до момента возврата прошло несколько дней, то вот в эти дни что есть эти денежные средства, которые у нас на счету? А реализация в какой момент сторнируется? И это самое первое, что приходит в голову.
2. Актуальность и безопасность - это вообще не вопрос PBI. Это вопросы регулярности наполнения DWH и политик безопасности/доступа. Те, кто думают, что на PBI делается всё - жестоко ошибаются. Ну т.е. отдельную витрину данных (какая-нибудь рекламная компанию в интернете) проанализировать еще можно, а вот для чего-то более серьезного всё равно придется строить DWH из нескольких источников, и уже поверх него аналитическое хранилище (Multidimensional или Tabular - вопрос философский). На нем и будут работать дашборды на PBI. И от этого слоеного пирога никуда не деться.
3. При построении дашборда/отчета нужно четко понимать, что это за отчет (операционный, аналитический или стратегический) и какие действия его пользователь может предпринимать на его основе. Тогда мы понимаем, что именно в отчете/дашборде должно присутствовать и каков должен быть вид всего этого. Например, для стратегического дашборда дриллдаун и какие-то подробные таблицы нафиг не нужны, а вот операционный отчет скорее уместен в экселе в виде сводных таблиц с нарезкой по размерностям на основе аналитического куба. Это к вопросу применимости таблиц с раскрытием «плюсиками» в PBI.
Спасибо! Про "истории из жизни" подумаю)) Спасибо за идею.
Про ваши ремарки - полностью согласна. Спасибо за хорошее дополнение!
Добрый день! Спасибо за ваши видео! могли бы выпустить видео по тем формулам которые могут "утяжелять" дашборд? возможно иногда стоит использовать одно, а не другое, зато будет быстрее работать
Мысль интересная) Сейчас я бы сказала, что на "утяжеление дашборда" больше влияет алгоритм расчета (то есть расчет и все примененные функции целиком), а не одна какая-то функция. Подумаю, спасибо)
У меня такая же проблема, очень долго обновляется дашборд и отчёты выполненные в экселе (power query+power pivot). Пока поняла, что лучше по минимуму использовать Power query (особенно группировку и объединение) и делать это через Power Pivot. Также csv файлы работают намного быстрее, чем xlsx
Как точно вы подметили, что пользователи не понимают сколько сил и терпения было вложено в дашборд) Для них это обычная красивая презентация, и им неинтересен процесс расчета и логика.
Спасибо. Подскажите как аналитику понимать какие данные что дают бизнесу и какие данные нужно указывать в отчёте ?? Какие математические формулы нужны или ещё что-то???
Если говорить о разработке отчета в Power BI, то давайте от этого и отталкиваться. Разрабатывать отчет в Power BI может либо собственно разработчик (1), для которого это основная работа и главный скилл, либо аналитик/финансист/продажник (2), в общем любой другой работник, для которого разработка отчета в Power Bi - второстепенный скилл. Соответственно в первом случае, разработчик не обязан знать какие показатели нужны бизнесу. Конечно, сделав хотя бы 3-4 отчета в разных областях или просто погуглив примеры отчетов, разработчик может предложить набор показателей и метрик и даже структурный макет. Но это не его профильный скилл. Я за то, чтобы каждый занимался своим делом. Чтобы стать профессионалом в какой-то области, нужно много времени. Еще больше времени нужно, чтобы стать профессионалом в нескольких областях.
Если же отчет разрабатывает отраслевой аналитик, например аналитик продаж, то для аналитика знание своей отрасли, бизнес-процессов и метрик, которые их характеризуют - это его профессиональный основной скилл, который нарабатывался опытом и профильным обучением. Поэтому в идеале для хорошего отчета нужна кооперация разработчика и тех, кто погружен и знает отраслевые бизнес-процессы. Повторюсь - это в идеале. В жизни бывает по разному. Общие правила здесь наверно, это, нарабатывать больше опыта. Больше насмотренности. Разбирайте чужие работы, отмечайте для себя их минусы и плюсы. Развивайте любознательность, чтобы с разных сторон смотреть на свою работу и ее результат. Будьте внимательны к заказчику, к заданиям на разработку, к собственной работе. Может кто-то еще что подскажет?)