Если обозначать именно такой состав MVP, то тогда следует дораскрыть именно заголовок статьи. Ведь в своей сути, по сегменту МСБ мы имеем подавляющее число компаний (как по количеству, так и по качественным метрикам), у которых не более 2 data-колодцев. И, зачастую, даже не намеренно в них есть суррогатные индексы, уникальные, подходящие для мэтчинга всех категорий затрат с итоговой выручкой. Даже не берем digital. Просто ID партии есть, ещё выпустил такой то бригадир/начальник смены, рабочие часы работников пробиты, ФОТ есть, стоимость производства , грубо по всем видам затрат расписана до себестоимости единиц по каждой номенклатуре , по поставке данные накладных внесены , связаны с ID партии, по ID накладных идёт поставка в ритейл (далее опускаем доп. данные, которые тоже есть) , всё это выгружается в формализованном виде, остается смэтчить с отчётом от ритейлеров. По сути , вечерок, Excel+VBA (прости хоспади) или пару дней и php+MySQL, и всё, базовая аналитика и в разрезе эффективности продаж на уровне ритейлера, и по типам выкладки внутри ритейлеров, и по гео, да много почему - накидано в объёме, достаточном для длительного пользования среднестатистическим представителем сегмента МСБ. По-моему так.
Но это частенько даже слишком для нижней части МСБ сегмента. Взять, к примеру, омю троюродную тётушку, реализующую товары не собственного производства через озон и wb. Именно аналитики с площадок + excel (даже без VBA) ей более чем достаточно.
Соответственно , хорошо бы в статье с таким заманчивымтзаголовком и дать +/- понятный алгоритм, по которому владелец бизнеса (не знаем какого масштаба) поймёт , нужно ли вкладываться в аналитику и что для него MVP.
Так то , это многим сейчас нужно. А то из каждого подвала сначала слышится "у нас кризис роста, мы внедряем современные подходы" , а потом мебель и оргтехнику за долги выносят ;)
Не понял чем MVP аналитика из статьи отличается от просто аналитики. Тут ведь просто про построение воронки продаж от лида до прибыли. То есть, как будто накинул метки на лидогенерацию (для digital канала - utm, собственно как в статье) и сиди считай ROI, ROMI , чего душе угодно.
Ну да, так все и делают. А скидывать цифры в кучу, что-то на что-то делить это как бы не аналитика и не дорого. В чем тут какое-то ноу-хау? Потом заходит речь про какую-то эволюцию, которая не бьётся с вышеперечисленными тезисами (выращивание аналитика это долго, дорого и до момента его становления компания не будет иметь готовой аналитики).
Другой вопрос про стек и подход. Облако, pgsql, общеизвестные bi программы для визуализации дашиков.
Ну во-первых стек шире, значительно, есть вполне дифференцированные подходы для разного бизнеса (от размера зависит и ещё от ряда факторов).
То есть, если повторить, ничего нового я не вижу, тема MVP так вовсе не раскрыта.
К слову, в одной из известных мне маленьких компаний, так уж сложилось что помощник директора знал php и mysql поверхностно. MVP заключался в построении аналитики по принципу: данные из Excel в csv - csv в сервис на apache (громно сказано, Denver просто развернули) - оттуда выгрузка CSV и в Excel, где графики настроены. Но это они никто VBA не знал. А знал бы помощник VBA, то и промежуточные манипуляции с apache не потребовались бы. Вот это - MVP с минимальными затратами, из того что есть и соразмерно целям и ценностям.
Ближе к владельцу, но дальше от IT . Для многих it-шиков hr , к слову , за компанию с "маркетосами" - ось зла. Это так, лирика, конечно. Я в it около 20 лет и только 1 год наблюдал то, о чем Вы говорите, и хорошего там мало. Так что это, наверное к счастью, скорее исключение чем правило.
Замахиваться на Excel я бы не стал. На Google таблицы , ещё можно. Но до Excel вам со своим решением далековато (именно , до табличного процессора, коим Excel является).
Серьёзно, просто давайте набор встроенных функций смэтчим, или вот, на убой, а извольте предъявить свой VBA??? Давеча водил родственницу к психиатру , а у него там макросы накодены в полный рост, я через плечо глянул , там и формы и range обрабатывает, то есть реальный серьёзный обработчик ручками написан.
Зачем это всё. Есть бинарная логика: сделано/ не сделано.
Хотите аналитику? Хотите знать где сломалось? Самое простое - scrum. И не важно где вы будете задачи вести. Есть другие хорошие методологии.
Но важно. Задачи ставить и оценивать должен тот, кто знает как и какими ресурсами они будут выполняться. Везде критична правильно выстроенная функциональная иерархия.
Если простыми словами: руководитель должен в деталях понимать то , что делают его непосредственные подчиненные, вплоть до того, что может у себя в голове мультик нарисовать, да так, что если, например , в любой момент заглянет подчиненному через плечо, то увидит там то, что у подчиненного в мониторе / на станке / в обработке.
Во многом согласен, но сама формулировка "ничего не делает руками" сильно напрягает.
Контроль - одна из важнейших функций руководителя! Например, если в интеграционных проектах он не способен верифицировать спеку и диаграмму последовательности UML от аналитика/архитектора (нижний и средний уровень руководства) или понять отчёт QA (читать ПМИ, отчёты, это если руководитель уровнем повыше), то грошь цена такому руководителю. А это сразу говорит о неких необходимых компетенциях в части (уметь делать руками), хотя бы на верхнем или абстрактном уровне. И это легко проверить.
За одно всплывут факты по практическим кейсам, хороший руководитель не упустит возможности похвастаться своим опытом.
Если обозначать именно такой состав MVP, то тогда следует дораскрыть именно заголовок статьи. Ведь в своей сути, по сегменту МСБ мы имеем подавляющее число компаний (как по количеству, так и по качественным метрикам), у которых не более 2 data-колодцев. И, зачастую, даже не намеренно в них есть суррогатные индексы, уникальные, подходящие для мэтчинга всех категорий затрат с итоговой выручкой. Даже не берем digital. Просто ID партии есть, ещё выпустил такой то бригадир/начальник смены, рабочие часы работников пробиты, ФОТ есть, стоимость производства , грубо по всем видам затрат расписана до себестоимости единиц по каждой номенклатуре , по поставке данные накладных внесены , связаны с ID партии, по ID накладных идёт поставка в ритейл (далее опускаем доп. данные, которые тоже есть) , всё это выгружается в формализованном виде, остается смэтчить с отчётом от ритейлеров. По сути , вечерок, Excel+VBA (прости хоспади) или пару дней и php+MySQL, и всё, базовая аналитика и в разрезе эффективности продаж на уровне ритейлера, и по типам выкладки внутри ритейлеров, и по гео, да много почему - накидано в объёме, достаточном для длительного пользования среднестатистическим представителем сегмента МСБ. По-моему так.
Но это частенько даже слишком для нижней части МСБ сегмента. Взять, к примеру, омю троюродную тётушку, реализующую товары не собственного производства через озон и wb. Именно аналитики с площадок + excel (даже без VBA) ей более чем достаточно.
Соответственно , хорошо бы в статье с таким заманчивымтзаголовком и дать +/- понятный алгоритм, по которому владелец бизнеса (не знаем какого масштаба) поймёт , нужно ли вкладываться в аналитику и что для него MVP.
Так то , это многим сейчас нужно. А то из каждого подвала сначала слышится "у нас кризис роста, мы внедряем современные подходы" , а потом мебель и оргтехнику за долги выносят ;)
Не понял чем MVP аналитика из статьи отличается от просто аналитики. Тут ведь просто про построение воронки продаж от лида до прибыли. То есть, как будто накинул метки на лидогенерацию (для digital канала - utm, собственно как в статье) и сиди считай ROI, ROMI , чего душе угодно.
Ну да, так все и делают. А скидывать цифры в кучу, что-то на что-то делить это как бы не аналитика и не дорого. В чем тут какое-то ноу-хау? Потом заходит речь про какую-то эволюцию, которая не бьётся с вышеперечисленными тезисами (выращивание аналитика это долго, дорого и до момента его становления компания не будет иметь готовой аналитики).
Другой вопрос про стек и подход. Облако, pgsql, общеизвестные bi программы для визуализации дашиков.
Ну во-первых стек шире, значительно, есть вполне дифференцированные подходы для разного бизнеса (от размера зависит и ещё от ряда факторов).
То есть, если повторить, ничего нового я не вижу, тема MVP так вовсе не раскрыта.
К слову, в одной из известных мне маленьких компаний, так уж сложилось что помощник директора знал php и mysql поверхностно. MVP заключался в построении аналитики по принципу: данные из Excel в csv - csv в сервис на apache (громно сказано, Denver просто развернули) - оттуда выгрузка CSV и в Excel, где графики настроены. Но это они никто VBA не знал. А знал бы помощник VBA, то и промежуточные манипуляции с apache не потребовались бы. Вот это - MVP с минимальными затратами, из того что есть и соразмерно целям и ценностям.
Ближе к владельцу, но дальше от IT . Для многих it-шиков hr , к слову , за компанию с "маркетосами" - ось зла. Это так, лирика, конечно. Я в it около 20 лет и только 1 год наблюдал то, о чем Вы говорите, и хорошего там мало. Так что это, наверное к счастью, скорее исключение чем правило.
Замахиваться на Excel я бы не стал. На Google таблицы , ещё можно. Но до Excel вам со своим решением далековато (именно , до табличного процессора, коим Excel является).
Серьёзно, просто давайте набор встроенных функций смэтчим, или вот, на убой, а извольте предъявить свой VBA??? Давеча водил родственницу к психиатру , а у него там макросы накодены в полный рост, я через плечо глянул , там и формы и range обрабатывает, то есть реальный серьёзный обработчик ручками написан.
А у вас оно где???
Зачем это всё. Есть бинарная логика: сделано/ не сделано.
Хотите аналитику? Хотите знать где сломалось? Самое простое - scrum. И не важно где вы будете задачи вести. Есть другие хорошие методологии.
Но важно. Задачи ставить и оценивать должен тот, кто знает как и какими ресурсами они будут выполняться. Везде критична правильно выстроенная функциональная иерархия.
Если простыми словами: руководитель должен в деталях понимать то , что делают его непосредственные подчиненные, вплоть до того, что может у себя в голове мультик нарисовать, да так, что если, например , в любой момент заглянет подчиненному через плечо, то увидит там то, что у подчиненного в мониторе / на станке / в обработке.
Во многом согласен, но сама формулировка "ничего не делает руками" сильно напрягает.
Контроль - одна из важнейших функций руководителя! Например, если в интеграционных проектах он не способен верифицировать спеку и диаграмму последовательности UML от аналитика/архитектора (нижний и средний уровень руководства) или понять отчёт QA (читать ПМИ, отчёты, это если руководитель уровнем повыше), то грошь цена такому руководителю. А это сразу говорит о неких необходимых компетенциях в части (уметь делать руками), хотя бы на верхнем или абстрактном уровне. И это легко проверить.
За одно всплывут факты по практическим кейсам, хороший руководитель не упустит возможности похвастаться своим опытом.