Comments 52
Посмотрите продут Dream Report он предназначен для бесшовной склейки производственных процессов(plant level) и бизнес аналитики. Больше заточен для применения в промышленной автоматизации, но имеет массу возможностей которые позволяют закрыть именно тот уровень про который вы пишете.
Доброе утро. Посомтрел презентации, смутило то что он предлагает импортировать в CSV. Надо его изучить более детально, они все в каком-то виде импортируют, но основной упор делается на отображение данных в Web. Я об этом и пишу — в Web все красиво, а как только начинаешь по серьезному экспортировать всё это в Excel начинаются проблемы. Возможно Dream Report доработал эту возможность
Основной вид отчетов — PDF, WEB отчеты больше предназначены для интерактивного режима. Также есть экспорт прямо в Excel. Сам продукт представляет из себя несколько компонентов — студия, для разработки отчетов, рантайм который предназначен для логирования данных, генерирования отчетов по расписанию, и обработку запросов от интерактивных отчетов поступающих из веба, доступ к рантайму осуществляется либо через веб либо через управляющую консоль. Вот здесь вы можете посмотреть на Веб портал в живую, и поиграться как с интерактивными отчетами так и PDF и Excel.
Все что вы видите в Веб портале — это построено динамически, на основе созданного в студии проекта. Ни единой строчки кода (кроме отчетов которые используют Lua скрипты) не написано.
Все что вы видите в Веб портале — это построено динамически, на основе созданного в студии проекта. Ни единой строчки кода (кроме отчетов которые используют Lua скрипты) не написано.
Меня заинтересовал продукт. Хочу узнать:
А в Excel с формулами может экспортировать?
И если данных много (очень много), либо время выполнения отчета несколько часов, он это сомжет сделать, без отложенных загрузок и снап шотов?
А в Excel с формулами может экспортировать?
И если данных много (очень много), либо время выполнения отчета несколько часов, он это сомжет сделать, без отложенных загрузок и снап шотов?
Формулы — нет. Экспорт в Excel — в простейшем виде — в указанные ячейки экспортируются данные из таблиц отчета или единичных элементов рассчитанных в процессе построения отчета. Суть в том что большинство расчетов которые обычно перекладывают Excel на может делать сам продукт, большинство графических элементов, и много того чего в Excel нет в принципе — реализовано внутри.
Что касается длительности построения отчетов — оно не ограниченно. Если вам интересно — могу дать контакт нашего представителя который занимается внедрением проектов и поддержкой больших, сложных проектов.
Что касается длительности построения отчетов — оно не ограниченно. Если вам интересно — могу дать контакт нашего представителя который занимается внедрением проектов и поддержкой больших, сложных проектов.
Т.е. выходит, что основная задача — это построить отчет в Web, а Excel — как дополнение?
Web или PDF. Вообще изначально — основная задача была построить отчет в PDF — веб делался уже для создания интерактивных очетов -например для выбора периода времени для построения отчета, или для дрилл-даун отчета — когда каждый следующий отчет строится на основе данных пришедших в предыдущий, итд…
Я просто рассмотрел систему, которая выгружает в Excel, а далее уже вступают в дело инструменты Power BI и т.п… Отчетных систем, которые строят в Web довольно много. Отсюда интересна работа с формулами, шаблонами Excel, выгрузка большого объема информации и т.п… Я посмотрю Вашу систему, её надо погонять на определенных задачах, чтобы понять насколько она удобна.
Я обычно использовал связку SSAS + Excel. Например, для медицинского центра было всего-навсего 3 куба (поликлиника, стационар, диспансеризация) и полсотни сводных таблиц в Excel на основе этих кубов. Они покрывали процентов 90 всей отчетности. Единственное что не удобно — это смотреть в Excel на основе каких первичных данных основаны значения показателей (drill down).
Analysis Services очень сильная вешь. Я сам её активно использую. Минус в том что кубы строятся на стороне сервера, соответсвенно бизнес-аналитики зависят от того кто строит куб. Что не во всех случаях удобно. А так OLAP, с точки зрения аггрегации данных, наиболее сильная штука. Плюс, когда в Excel работаешь с ним можно получить out of memory, когда данных слишком много и клиент не справляется с таким объемом, но это зависит от того кто делал куб и того кто им пользуется.
Спасибо, я все же исправлю, нельзя давить на больное.
В сторону Tableua уже смотрел. Организационные проблемы, они везде, работа с бизнес аналитиками мне тоже знакома. Скажем так, я написал о том что смог улучшить.
«пограммистами баз данных» — не исправляйте, уж больно вкусная опечатка :)
ЭХХХХ… alex_29. Это не проблема BI решения или инструментов.
1.Проблема, много пользователей тягают OLTP базу Firebird, Она не очень хорошо работает с расчетами.
DWH нужна чтобы разгрузить OLTP.
2.Обычно в OLTP системе нет такого понятия как предметная область. Кубы помогают решить частично проблему, накидываем меры и измерения и Вуааляяя…
3.OLAP кубы аггрегируются что снижает нагрузку на вычисление (Column store index)
4.Данные заливаются после 8 вечера когда никто не работает с БД OLTP.
5.Excel и Power BI не очень то и хороши. Посмотрите в сторону Коммерческого решения Tableua. Этот Bi занимает лидирующее положение.
Главная проблема это сбор требований для того что нужно а что нет, и как в итоге Бизнес аналитики себе это нафантазируют.
1.Проблема, много пользователей тягают OLTP базу Firebird, Она не очень хорошо работает с расчетами.
DWH нужна чтобы разгрузить OLTP.
2.Обычно в OLTP системе нет такого понятия как предметная область. Кубы помогают решить частично проблему, накидываем меры и измерения и Вуааляяя…
3.OLAP кубы аггрегируются что снижает нагрузку на вычисление (Column store index)
4.Данные заливаются после 8 вечера когда никто не работает с БД OLTP.
5.Excel и Power BI не очень то и хороши. Посмотрите в сторону Коммерческого решения Tableua. Этот Bi занимает лидирующее положение.
Главная проблема это сбор требований для того что нужно а что нет, и как в итоге Бизнес аналитики себе это нафантазируют.
Рассмотрю места, где не бьют :)
UFO just landed and posted this here
Вам смешно, а мне среди них больно :)
мы сейчас пробуем Spark + PowerBi
У нас есть hadoop кластер на котором бежит Spark
Данные загружаем туда 3мя способами:
Streaming — Spark подсоединен к Azure Event Hub, получает данные в real-time и сохраняет в памяти/hive
Sqoop — утилитка, которая умеет тянуть данные из SQL Server и сохранять в hive
Spark Batch Application — програмка на Scala, которая собирает json файлы из разных мест, проводит всякие манипуляции и сохраняет в тот же hive.
Sqoop и Batch запускаются раз в день с помощью Oozie workflow manager
Таким образом hive становится обьединеным местом (single source of truth), где хранятся все данные (warehouse). Хранятся они в колоночном формате parquet в файлах hdfs
Чтоб посмотреть на эти данные, то можно подсоединить Spark к PowerBi. PowerBi подсоединяется к Spark через ODBC driver, видит все hive таблицы, посылает SQL запросы и полученные данные показывает как умеет (графики, таблицы и т.д.)
Если данных мало, или памяти много, то данные находятся в памяти, и запросы возвращаются очень быстро
Пока что тестируем, но оптимизма много
Другая альтернатива это использовать SSAS,Microsoft Tabular service. Нам она не понравилась, в основном из-за цены и уж слишком майкрософности :)
Данные загружаем туда 3мя способами:
Streaming — Spark подсоединен к Azure Event Hub, получает данные в real-time и сохраняет в памяти/hive
Sqoop — утилитка, которая умеет тянуть данные из SQL Server и сохранять в hive
Spark Batch Application — програмка на Scala, которая собирает json файлы из разных мест, проводит всякие манипуляции и сохраняет в тот же hive.
Sqoop и Batch запускаются раз в день с помощью Oozie workflow manager
Таким образом hive становится обьединеным местом (single source of truth), где хранятся все данные (warehouse). Хранятся они в колоночном формате parquet в файлах hdfs
Чтоб посмотреть на эти данные, то можно подсоединить Spark к PowerBi. PowerBi подсоединяется к Spark через ODBC driver, видит все hive таблицы, посылает SQL запросы и полученные данные показывает как умеет (графики, таблицы и т.д.)
Если данных мало, или памяти много, то данные находятся в памяти, и запросы возвращаются очень быстро
Пока что тестируем, но оптимизма много
Другая альтернатива это использовать SSAS,Microsoft Tabular service. Нам она не понравилась, в основном из-за цены и уж слишком майкрософности :)
Рад буду помочь, если будет нужно.
Если Вы сами будете это анализировать, то ок, а вот если это аналитикам отдавать, то возможно упретесь в различные подводные камни. Бизнес-аналитики должны уметь писать либо SQL запосы, либо им надо что-то вменяемое на сервере построить. Я б SSAS попробовал, из-за его майкрософтности. Excel с Power BI тоже микрософт, остюда проблем с интеграцией меньше. Хотя если данных мало и памяти много, то можно и проще сделать.
Основным показателем успешности внедрения BI является частичный или полный отказ от работы в Excel.
Пользователи не должны тратить времени на построение формул и редактирование данных.
Информация для аналитики должна предоставляться им для аналитике в уже готовой для просмотра форме. Иначе зачем покупать BI, платить за ее внедрение… Такие программные продукты, как QlikView, OracleBI, Битрикс позволяют в полной мере охватить процесс аналитики и наконец забыть об Excel. Говорить о каких то «мостиках» с ними не приходится.
Пользователи не должны тратить времени на построение формул и редактирование данных.
Информация для аналитики должна предоставляться им для аналитике в уже готовой для просмотра форме. Иначе зачем покупать BI, платить за ее внедрение… Такие программные продукты, как QlikView, OracleBI, Битрикс позволяют в полной мере охватить процесс аналитики и наконец забыть об Excel. Говорить о каких то «мостиках» с ними не приходится.
Я стесняюсь спросить, но вот пользователь Qlik'а, он, что, магическим образом освобождается от необходимости «построения формул»? Или все-таки не освобождается, но тогда он и не «пользователь»? В Qlik'е, Tableau и иже с ними там как-то сами собой вычисляются нужные меры? Я уже не говорю про загрузку данных и построение моделей. Если это некое отраслевое решение, то возможно. А если вот посадили «программиста» и с нуля надо работать с данными, то какая принципиальная разница между SSAS, Qlik'ом, Tableau и т.д.? Также садится человек и грузит данные, устанавливает связи, добавляет вычисления-меры, чтобы потом предоставить куб/модель/whatever пользователю для построения визуализаций. Я просто честно не могу понять, где, на каком этапе возникает в не-MS BI-продуктах эта «магия», когда пользователя не волнует «построение» формул и он с необычайной легкостью в считанные мгновения готовит отчет, оставляя далеко позади фанатов йокселя?
Это мы все проходили. Не первый день в BI. Давайте вообще выбросим Excel, не нужен он людям, пусть к примеру в QlikView (или чем-то похожем) работают и платят нормальные деньги хорошим людям.
Маленькие компании могут за QlikView денег не платить, используя Desktop версию. Битрикс тоже предоставляет базовый пакет бесплатно. Про OracleBI не знаю. Ну а компаниям большим, хотят они этого или нет, рано или поздно все-равно придется переходить на автоматизированные решения.
А зачем нужна Desktop версия Qlik'а (файл от которой, кстати, на другой машине уже не откроешь), если ту же in-memory модель данных можно построить в Excel Standalone за 80 долларов, которым уже можно делиться с коллегами? Загрузка данных в Qlik'е выполнена достаточно хорошо, но Power Query, думаю, легко ее «уделает», учитывая богатую практику использования этого языка и количество наработанных скриптов для импорта данных из разных сервисов, готовых как раз для использования на пользовательском уровне. ИМХО мощь Qlik'а как раз в больших копроративных средах. Которая и может отвалить за него конских денег. А десктопный Qlik — это даже не developer edition, это просто игрушка для отработки самой технологии. Побаловаться с импортом данных, покрутить их, восхититься богатством настроек диаграмм и т.д.
Кроме того, «выростя из коротких штанишек», вы можете все свои созданные в Excel'евском Power Pivot модели вместе с выстраданными в DAX measures импортировать в уже «взрослый» SSAS Tabular. А там уже настраивать доступы к модели и т.д. Для того же, чтобы начать шарить результаты своей работы в десктопном Qlik'е, нужно будет потратить какие-то вообще невменяемые деньги на Qlik'овский сервер. Хотя таки да, дашборды у них великолепные получаются (не такие нарядные как у Tableau, конечно, но зато именно «корпоративные»:), дрил-даун восхитительный и т.д. Но это уже эмоции :)
Кроме того, «выростя из коротких штанишек», вы можете все свои созданные в Excel'евском Power Pivot модели вместе с выстраданными в DAX measures импортировать в уже «взрослый» SSAS Tabular. А там уже настраивать доступы к модели и т.д. Для того же, чтобы начать шарить результаты своей работы в десктопном Qlik'е, нужно будет потратить какие-то вообще невменяемые деньги на Qlik'овский сервер. Хотя таки да, дашборды у них великолепные получаются (не такие нарядные как у Tableau, конечно, но зато именно «корпоративные»:), дрил-даун восхитительный и т.д. Но это уже эмоции :)
У каждого свой путь. Тот кто считает, что надо отказаться от Excel путь от него отказывается, я не против.
А я бы ещё добавил qlik.sense — один раз указал что и откуда грузить и пусть пользователи сами себе рисуют что хотят для своей работы
Читайте внимательно статью, не рекламируйте, пожалуйста, QlickView и QlickSense.
1
А чем это отличается от «построил SSAS модель и пусть пользователи рисуют себе в Excel или Power BI что хотят для своей работы»?
Этого не всегда достаточно. SSAS модель это очень круто, но возникают ситуации когда этого не достаточно. Куб надо ещё построить и потом его поддерживать, а это специалист по кубам и более тесное взаимодействие между аналитиками и программистами Баз Данных, отсюда дополнительные ресурсы. (В разделе «Что хочет пользователь» я написал о том, что тоже их использую.) С другой стороны, если есть возможность получить данные с сервера в виде отчета, то Power Pivot в Excel может построить какой угодно куб на стороне клиента и уже аналитик может его строить и вертеть как ему вздумается, а в этом случае можно обойтись без SSAS прослойки.
Спасибо за ответ! Но я вопрос задавал uinx. Я-то как раз с Вашей позицией согласен :)
А зачем в таком случае загружать данные в Excel с его ограничениями на 1 миллион записей/sheet? Проще загрузить прямо в PowerPivot Data Model, используя Power Query.
Ограничение на страничку в Excel. Страничек может быть много и на каждый по миллиону строк. Суть моего предложения в том, что программист Баз Данных один раз формирует запрос, с возможностью задавать параметры пользователем и пользователи далее им пользуются сколько угодно раз не вникая в тонкости SQL. Отчет, также, централизованно хранится на сервере и его можно всегда скачать пользователю, либо поменять программисту. Прямого доступа к объектам в базе пользователи не имеют, что тоже более предпочтительно
А не подскажите, почему был выбран именно OpenXML SDK для разработки? И рассматривали ли вы другие альтернативы для своего инструмента?
Я об этом писал в другой статье более детально — https://habrahabr.ru/post/235903/
В общем, нужно было писать в excel файл методом SAX, чтобы обеспечить быстродействие и минимизировать занимаемую оперативную память сервера. Я посчитал OpenXML самой низкоуровневой оберткой для C# и взял её. Хотя DevExp вроде как тоже в своих последних релизах поддерживает работу с excel с помощью SAX, но я предпочёл сделать это без посредников. Справедливости ради, работа с DOM моделью в DevExp удобнее.
В общем, нужно было писать в excel файл методом SAX, чтобы обеспечить быстродействие и минимизировать занимаемую оперативную память сервера. Я посчитал OpenXML самой низкоуровневой оберткой для C# и взял её. Хотя DevExp вроде как тоже в своих последних релизах поддерживает работу с excel с помощью SAX, но я предпочёл сделать это без посредников. Справедливости ради, работа с DOM моделью в DevExp удобнее.
1.
Я мож чего не понял, но если пользователям нужны на выходе raw-данные, чего бы им просто ETL-ем их не выгрузить?
Ну если разово нужны, то может быть и имеет смысл ETL, а если ежедневно и пользователи по всей стране сидят, то думаю, что ETL не очень удобно будет. Плюс выгрузок в реальности много и все разные. Так же ETL создавать надо, опять таки — это ресурсы дополнительные. У нас были Inforamtic и SSIS, если что-то в них ломалось, то разобраться не всегда было просто. ETL использовались для передачи данных между ИТ специалистами, а не для выгрузок простым пользователям.
Так же помимо raw-данных в эксель можно выгружать с помощью шаблонов, в которых сразу прописать формулы и графики.
Я теперь перечитал всё на этой странице. Резюмирую.
Нет, подождите, вы что, действительно не хотите заставить пользователей отказаться от Excel'a?
На моём опыте, в разных компаниях, в разных отделах, чуть ли не каждый отдельный сотрудник свои данные считает так как ему удобно.
Даже если вы ему дадите «преднастроенные» шаблоны формул и готовые данные, то что ему запретит их изменить скопировав в другую Excel книгу в виде текста и там придумать новые формулы и то что ему еще взбредет в голову, для того чтобы «правильно» отчитаться перед руководством. Ничто ему не помешает.
-> ТС. Посмотрев ваше видео, выгрузки таблиц из базы данных, в миллионы строк в Excel — зачем это? Для чего файл в 40 мегабайт? Что пользователь будет делать с х-ю листами по ххххххх строк?
Сводные таблицы — ок, удобно. В любом случае для пользователей вы будете создавать модель данных — и тут в сравнении с BI-софтом дело лишь квалификации разработчика, и того, кто придет после вас на вашу должность
У меня тут вопрос возник: Можно ли построить модель в 20-30 связанных таблиц в Excel со строками чеков по продажам товаров в розничном магазине(скажем в 1000 кв/м) со всеми вытекающими справочниками; где около 500 чеков в день, 1000 товаров ассортимента + связать со всеми справочниками которые у вас будут в учетной изначальной системе: поставщики, производители, товары новинки, построить полочное пространство с оборачиваемостью, учесть затраты по налогам, зарплате и всему остальному… и так далее.
Итого у вас будет примерно за 1 год работы — около 1,8млн. строк чеков (при обороте средней продаже 10ти товаров в одном чеке).
И всё это путем использования ПО — которое не нужно покупать. т.е. ограничимся в покупке SQL Server + Win Server + ФронтОфис и БэкОфис.
Вот просто скажите мне, сколько времени у вас займет такая разработка?
Чтобы в конечном счете дать пользователю Excel-лист со сводной таблицей.
+ Потребление памяти когда он откроет этот лист
+ Сколько он будет открываться
+ Загрузку проца в моменты, когда пользователь будет двигать измерения в том виде в котором ему надо
+ Самое главное, сколько по времени будет ждать пользователь когда у него построится готовая таблица, и если он захочет сделать таблицу в другом виде — сколько тут еще пользователю ждать нужно будет?
Как вы уже догадались я разработчик QlikView, и не хочу сейчас никаких холиваров в данном направлении — тем более что 100% пользователей которые используют Excel заминусуют мой пост в минус тыщу.
Мне просто для себя, для общего развития так сказать. Можно в личку, готов туда переместится без проблем…
И далее: ок, вопрос для бизнес-аналитиков мы решили, а что делать с другими должностями в компаниях? что нужно бухгалтерам — оборотная ведомость, тоже в Excel? что нужно финансистам — контроль бюджета и платежный календарь — тоже в Excel? Ген. директора какой нибудь компании у которого Mac + iPad + iPhone — тоже будете заставлять покупать пакет Excel для Mac?
Что это, блин, я не могу понять, у меня не укладывается в голове, повторю вопрос — вы что, действительно не хотите заставить пользователей отказаться от Excel'a?
Да добавлю про Qlik — это не сложно, пилотный проект в среднем 2 недели. Построение отчетов/графиков — за 5 секунд на этапе отображения информации пользователям (негласное правило разработчиков Qlik)
Базы данных — нет, я их не использую, мне достаточно использовать сжатые QVD (QlikView data files) для хранения информации. Да, я выгружал регистр накопления из 1С в 600млн строк, который в виде таблицы в SQL занимает 120гиг (там около 20 полей, без индексов) и сохранял эти данные в QVD и получал файл в 8 гиг; причем загрузка из SQL (без каких либо условий, тупо select * ) — 3 часа (локально грузил с БД на сервере) и из QVD-файла — 8 минут (так же локально) [Замеры производились в выходной день, когда с базой никто не работал]
… всё, отпустило, потом перечитаю то что написал…
Нет, подождите, вы что, действительно не хотите заставить пользователей отказаться от Excel'a?
На моём опыте, в разных компаниях, в разных отделах, чуть ли не каждый отдельный сотрудник свои данные считает так как ему удобно.
Даже если вы ему дадите «преднастроенные» шаблоны формул и готовые данные, то что ему запретит их изменить скопировав в другую Excel книгу в виде текста и там придумать новые формулы и то что ему еще взбредет в голову, для того чтобы «правильно» отчитаться перед руководством. Ничто ему не помешает.
-> ТС. Посмотрев ваше видео, выгрузки таблиц из базы данных, в миллионы строк в Excel — зачем это? Для чего файл в 40 мегабайт? Что пользователь будет делать с х-ю листами по ххххххх строк?
Сводные таблицы — ок, удобно. В любом случае для пользователей вы будете создавать модель данных — и тут в сравнении с BI-софтом дело лишь квалификации разработчика, и того, кто придет после вас на вашу должность
У меня тут вопрос возник: Можно ли построить модель в 20-30 связанных таблиц в Excel со строками чеков по продажам товаров в розничном магазине(скажем в 1000 кв/м) со всеми вытекающими справочниками; где около 500 чеков в день, 1000 товаров ассортимента + связать со всеми справочниками которые у вас будут в учетной изначальной системе: поставщики, производители, товары новинки, построить полочное пространство с оборачиваемостью, учесть затраты по налогам, зарплате и всему остальному… и так далее.
Итого у вас будет примерно за 1 год работы — около 1,8млн. строк чеков (при обороте средней продаже 10ти товаров в одном чеке).
И всё это путем использования ПО — которое не нужно покупать. т.е. ограничимся в покупке SQL Server + Win Server + ФронтОфис и БэкОфис.
Вот просто скажите мне, сколько времени у вас займет такая разработка?
Чтобы в конечном счете дать пользователю Excel-лист со сводной таблицей.
+ Потребление памяти когда он откроет этот лист
+ Сколько он будет открываться
+ Загрузку проца в моменты, когда пользователь будет двигать измерения в том виде в котором ему надо
+ Самое главное, сколько по времени будет ждать пользователь когда у него построится готовая таблица, и если он захочет сделать таблицу в другом виде — сколько тут еще пользователю ждать нужно будет?
Как вы уже догадались я разработчик QlikView, и не хочу сейчас никаких холиваров в данном направлении — тем более что 100% пользователей которые используют Excel заминусуют мой пост в минус тыщу.
Мне просто для себя, для общего развития так сказать. Можно в личку, готов туда переместится без проблем…
И далее: ок, вопрос для бизнес-аналитиков мы решили, а что делать с другими должностями в компаниях? что нужно бухгалтерам — оборотная ведомость, тоже в Excel? что нужно финансистам — контроль бюджета и платежный календарь — тоже в Excel? Ген. директора какой нибудь компании у которого Mac + iPad + iPhone — тоже будете заставлять покупать пакет Excel для Mac?
Что это, блин, я не могу понять, у меня не укладывается в голове, повторю вопрос — вы что, действительно не хотите заставить пользователей отказаться от Excel'a?
Да добавлю про Qlik — это не сложно, пилотный проект в среднем 2 недели. Построение отчетов/графиков — за 5 секунд на этапе отображения информации пользователям (негласное правило разработчиков Qlik)
Базы данных — нет, я их не использую, мне достаточно использовать сжатые QVD (QlikView data files) для хранения информации. Да, я выгружал регистр накопления из 1С в 600млн строк, который в виде таблицы в SQL занимает 120гиг (там около 20 полей, без индексов) и сохранял эти данные в QVD и получал файл в 8 гиг; причем загрузка из SQL (без каких либо условий, тупо select * ) — 3 часа (локально грузил с БД на сервере) и из QVD-файла — 8 минут (так же локально) [Замеры производились в выходной день, когда с базой никто не работал]
… всё, отпустило, потом перечитаю то что написал…
Я прекрасно знаю как работают продукты Qlick. Та же я в курсе — что такое OLAP, SAP BO, Oracle BI, Tabular и т.д… И я не считаю Excel плохим продуктом. Если людям удобно с чем-то работать, то зачем заставлять их от этого отказываться. Сделайте что-то лучше чем Excel и люди сами начнут его использовать вместо Excel. Я не сторонник запретов и отказов, я просто говорю о том, что можно никого не переучивая, не нанимая, не обучая и ничего не покупая, удовлетворить потребности как бизнес аналитиков так и программистов Баз Данных. И заметьте — мне есть что сказать про Qlick, но я не считаю должным выяснять отношения здесь.
Более того — я вынужден был сделать этот пример, после того, как все вышеперечисленные продукты не удовлетворили пользователей. Большие выгрузки делаются пользователями не так уж редко. Можно запретить это делать, но я не сторонник запретов. Отучить от Excel людей — это не так просто и нужно ли? Если они справляются со своей работой, то зачем запрещать им этим пользоваться?
Для компаний малых размеров вполне хватает и Excel. Особенно, если штатные программисты не на мотивации, а только на ставке.
И если компания состоит из трех человек (образно), а бизнес-процесс можно описать в блокноте двумя-тремя предложениями (образно), то использовать Qlik — как стрелять из пушки по воробьям — только замедлит и утяжелит работу сотрудников. Другое дело, если бизнес-процессы компании настолько запутанные, что без специализированного софта не обойтись. Хочет бабуля-бухгалтер этого или нет, а ей придется отвыкать от Excel.
И если компания состоит из трех человек (образно), а бизнес-процесс можно описать в блокноте двумя-тремя предложениями (образно), то использовать Qlik — как стрелять из пушки по воробьям — только замедлит и утяжелит работу сотрудников. Другое дело, если бизнес-процессы компании настолько запутанные, что без специализированного софта не обойтись. Хочет бабуля-бухгалтер этого или нет, а ей придется отвыкать от Excel.
В больших компаниях ещё больше Excel, т.к. народу очень много и на обучение тратиться не будут (из моего опыта). Причем тут бабуля, функционал, который берет на себя эксель очень серьезен. Excel — это ведь не только BI. Алгоритмы расчета премий, рентабельностей и прочие делаются в эксель силами экономистов, без привлечения ИТ. А для этих алгоритмов нужны данные, под алгоритмы держать команду программистов — это расточительно.
P.S. Qlik интересный продукт, но его так пиарят, что он у меня ассоциируется с гербалайфом, причем не из-за качества продукта, а из-за очень агрессивной рекламы. Для своей ниши он хорошо, только у ниши есть глубина и ширина, но это уже не по теме этой статьи.
Ну… на моем опыте скажу, что компания, в которой я работаю, воспользовалась услугами одно аутсорсера. Денег заплатила немного. По сути, те деньги, что ему заплатили, окупились в первом же месяце за счет экономии человекочасов финансистов.
А ведь говоря об автоматизации, речь идет не конкретно о Клике. Вот, к примеру, несколько дней назад Террасофт представил bpm'online 7.8 — там намешано всего-всего, но есть и тот функционал, о котором идет речь выше. И масса других платформ.
А ведь говоря об автоматизации, речь идет не конкретно о Клике. Вот, к примеру, несколько дней назад Террасофт представил bpm'online 7.8 — там намешано всего-всего, но есть и тот функционал, о котором идет речь выше. И масса других платформ.
Ваша фирма правильно сделала, что воспользовалась услугами аутсорсера. Лучше обратиться к тем, кто действительно в теме вопроса, нежели пытаться что-то самим решить. Прежде чем использовать Террасофт, так же советую проконсультироваться с аутсорсером. Платформ много и функционала в них тоже, но вот что подойдёт Вам это надо сомтреть.
бизнес-процессы компании настолько запутанные, что без специализированного софта не обойтись
А что в Qlik'е такого специализированного, если он суть:
- ETL
- Data modeling tool
- In-memory database
- Visualization designer
- Security
Ничего не забыл? Я не шучу. Мне правда интересно, наличие какого функционала профессиональные разработчики Qlik'а подразумевают по «специализированным софтом». И действительно ли такой функционал отсутствует в стеке BI-технологий MS. И настолько ли он (этот функционал) так «отсутствует», что надо срочно все бросать и отучать людей от Excel'я.
Sign up to leave a comment.
Этого не будет в BI (Купив BI tool, вы этого не получите)