Из-за порога основная масса клиентов не лезет в Python и VBA, хотя достигает высокого профессионализма в Excel — это происходит действительно годами, функция за функцией, начиная от открытия Alt+Enter для переноса строки внутри ячейки (пожалуйста!) и до МДСЧ().
Стащить людей с таким массивным и тяжело добытым пластом знаний куда-то ещё возможно только если у них совсем нет иного выхода.
Я вот не финансист, хотя в экселе и программизме шарю отлично. Несколько лет внедрял решения по финансовым рынкам и рискам, всё в специализированных калькуляторах с выгрузкой в эксель в финале.
С Jupyter-блокнотами, ETL и хадупами работали мои ML-коллеги, и бизнесу это ну никак не заходило. В компании часто было 1-2 чела, кто мог это постичь, но они не могли работать сообща с коллегами, потому что возня с подготовкой инфраструктуры занимает месяцы. Эти месяцы пролетают незаметно для энтузиастов, но простым сотрудникам порог входа высокий и его преодоление не выглядит выгодно.
Пока делал первый проект по модели, не отпускала мысль: почему люди так мучаются? Можно же сделать по-хорошему: период параметром, колонки по периоду, у значения дата вместо места. Звучит настолько естественно, что даже подозрительно.
Это больше вопрос про особенности платформы, но сам по себе он очень острый. Отвечу про пример в Интеграме: пользователь ограничен только теми таблицами, куда у него есть доступ, поэтому запросы на выборку он может делать только к ним. Сами запросы (аналог SQL) тоже с ограниченным доступом: это основано на префиксе (в простых случаях) и на ролях/группах (в более сложных системах).
По производительности у всех стандартно: порог (таймаут) на уровне системы не даст её сколько-нибудь сильно ущемить. SQL-инъекции тоже вещь, защищаемая стандартно, любой конструктор должен иметь блокер на это.
И как этот TCO (совокупная стоимость владения) сравнивается с затратами на внедрение OLAP-куба или Python-решения?
Конструктор как веб-сервис или самодельное приложение с таким подходом сравнимо с одним-двумя месяцами работы внедренцев OLAP-куба или Python-решения, дальше начинается чистая экономия, примерно как стоимость владения экселем — 20-30 тысяч в год в облаке.
В эпоху ИИ визуальные дополнения делаются достаточно легко. Из того, что мы пробовали, хорошо работает формула с именами и сразу подставленными числами, как описано в статье — вот этот сильно помогает. Ещё важна подсветка ошибок, это тоже надо делать в первую очередь. Стрелки на связанные ячейки почти не работают, потому что для простых случаев всё и так очевидно, а для сложных их ещё сложнее отслеживать, чем без них разобраться. Самое, наверное, полезное, это назвать всё человеческими именами — таблицы, поля, периоды — так у человека почти нет шансов запутаться.
Приветствую! Перекидать статьи затрат в новый формат занимает несколько минут на лист, потому что это просто копипаст. Формулы — это тоже минуты. Из практики, самое сложное будет выбить логику из заказчика и продумать архитектуру хранения для первой модели, чтобы она вас устраивала и была расширяема на будущее. Тут можно будет несколько раз сделать с нуля, экспериментировать, тратя на итерацию от получаса до двух часов. Итого: полдня-день на первую модель, ещё 16-40 часов на отладку, потом на остальные по 2-4 часа на перенос с нуля или адаптацию копии — выбор по ситуации.
На сопровождение такой работы — обучение людей, поддержка и перенос их руками — я бы заложил месяц на все 50 штук. Самому браться крайне рискованно.
Настоящая ликвидность параллелится между большой массой народа, с учетом множества факторов. Её нельзя вот так однозначно отобразить, потому что это многомерная штука, включающая как честные факторы (очередность, категорию клиента и др.), так и паразитные (фронт-раннеров).
Даже если это всё честно вывалить, это ничего не исправит — были тут 10 лет назад такие парни GKFX и ещё кто-то, не помню название (найду, если надо), и у них всё было честно и открыто, однако они все расходы на честность возлагали на клиента, и торговать было ОЧЕНЬ дорого.
Наверное, в этом и есть состав претензии. Лучше и естественнее наоборот: не в человеческий текст добавлять ИИ-пассажи, а использовать его как литературного невольника (уж такой эвфемизм, простите), а затем править его косяки и перефразировать.
Статья у вас упускает массу вещей, которые вы просто не можете зарегистрировать вашими скриншотами стакана, и не выводите из опыта, логики и наблюдений. Скажем так, она наивна.
Как эксперт, торговавший публично больше 12 лет, я вам так скажу: ликвидность в таких каналах вы можете видеть только нарисованную, и больше никакую. Нужна честная — ступайте в офлайн-обменник. Потом напишите здесь о разнице в накладных расходах :-)
Сложить все данные в excel можно один раз. и вероятно клод даже позволит решить вашу одну боль в моменте.
В Кейсах на вашем сайте сделано именно это и ничто другое. Разово проанализировали и закрыли проблему. Решения устаревания данных на сайте нет, и оно организационное, вы тут ничем не поможете и инструментов для этого у вас не упомянуто. Пишу это как раз потому, что мы решаем именно эту проблему и очень хорошо в теме.
Как интересно. А что вы продаете? Сейчас каждый сотрудник сам себе литиум, а некоторые ещё бы и вас могли научить много чему новому :-) Модель у кас где - локально или сливаете данные вовне?
Эксель как эксель заменять действительно нет смысла, я им пользуюсь постоянно для разовых задач. Есть смысл вырасти из экселя для рутинных задач, автоматизации и защиты данных, и тогда выбора три: заказная разработка (дорого), самостоятельные поделки на конструкторах (весело) или оставить как есть — не трогать (риски, неудобство).
Я встречался лично с владельцем продукта в РТ, наслушался, как надо делать и как не надо, что есть прошлый век, а что правильно. Тогда стало понятно, почему публике не показывают (и не планируют) живьем их продукт и каково его будущее. Пока люди не отвечают рублём (и шкурой!) за принятые архитектурные решения, а их ЛПР вообще не в курсе происходящего, продукт будет мёртвым, обрастет макросами на JS или Lua и в итоге сгинет.
Вроде они стараются делать так, как хорошо клиентам, а не как правильно с точки зрения архитектора, поэтому чувствуют себя, наверное, лучше, чем аналоги экселя и уж тем более MWS и РТ.
Наверное, это GreenData, Creatium... Навскидку не назову успешных, могу назвать только выживших. У многих, как вот ещё некий AppMaster, есть просто финансовая подушка и вера инвесторов/фаундеров, что всё это не зря. Плюс свои истории успеха греют.
Гнаться за ручным редактированием миллиона строк глупо, это опять же область обработки типа power query, а не ручной работы
У мелких производителей, к которым и мы относимся, как я признаюсь выше, вообще нет лимита на строки, есть свободная архитектура и абсолютная гибкость — как раз чтобы избавить клиентуру от ручной работы по максимуму, в этом шанс выжить у мелкого производителя, в отличие от гигантов с их планами на пятилетку.
Организациям нужно чуть больше, чем просто таблички, и много больше, чем BI. Поэтому с тамким скрипом идет распространение всеобъемлющих отечественных аналогов Excel, а продукты гигантов, кто делает это "по ходу", не пользуются массовым спросом вообще - ведь у частника есть выбор, в отличие от корпов.
Там проблема в том, что требования у одних, опросник готовят другие, а приемку делают третьи люди. В итоге корпорация покупает не то что нужно и разумно, а нечто необычное. Таков корпоративный порядок - логики 0.
Из-за порога основная масса клиентов не лезет в Python и VBA, хотя достигает высокого профессионализма в Excel — это происходит действительно годами, функция за функцией, начиная от открытия Alt+Enter для переноса строки внутри ячейки (пожалуйста!) и до МДСЧ().
Стащить людей с таким массивным и тяжело добытым пластом знаний куда-то ещё возможно только если у них совсем нет иного выхода.
Откуда инфа? Мы пробовали замерять на одном публичном репо, 70% в серой зоне, 0,2% имеют четкий след ИИ.
https://habr.com/ru/articles/1065112/
Я вот не финансист, хотя в экселе и программизме шарю отлично. Несколько лет внедрял решения по финансовым рынкам и рискам, всё в специализированных калькуляторах с выгрузкой в эксель в финале.
С Jupyter-блокнотами, ETL и хадупами работали мои ML-коллеги, и бизнесу это ну никак не заходило. В компании часто было 1-2 чела, кто мог это постичь, но они не могли работать сообща с коллегами, потому что возня с подготовкой инфраструктуры занимает месяцы. Эти месяцы пролетают незаметно для энтузиастов, но простым сотрудникам порог входа высокий и его преодоление не выглядит выгодно.
Пока делал первый проект по модели, не отпускала мысль: почему люди так мучаются? Можно же сделать по-хорошему: период параметром, колонки по периоду, у значения дата вместо места. Звучит настолько естественно, что даже подозрительно.
Это больше вопрос про особенности платформы, но сам по себе он очень острый.
Отвечу про пример в Интеграме: пользователь ограничен только теми таблицами, куда у него есть доступ, поэтому запросы на выборку он может делать только к ним. Сами запросы (аналог SQL) тоже с ограниченным доступом: это основано на префиксе (в простых случаях) и на ролях/группах (в более сложных системах).
По производительности у всех стандартно: порог (таймаут) на уровне системы не даст её сколько-нибудь сильно ущемить. SQL-инъекции тоже вещь, защищаемая стандартно, любой конструктор должен иметь блокер на это.
Конструктор как веб-сервис или самодельное приложение с таким подходом сравнимо с одним-двумя месяцами работы внедренцев OLAP-куба или Python-решения, дальше начинается чистая экономия, примерно как стоимость владения экселем — 20-30 тысяч в год в облаке.
В эпоху ИИ визуальные дополнения делаются достаточно легко. Из того, что мы пробовали, хорошо работает формула с именами и сразу подставленными числами, как описано в статье — вот этот сильно помогает. Ещё важна подсветка ошибок, это тоже надо делать в первую очередь.
Стрелки на связанные ячейки почти не работают, потому что для простых случаев всё и так очевидно, а для сложных их ещё сложнее отслеживать, чем без них разобраться.
Самое, наверное, полезное, это назвать всё человеческими именами — таблицы, поля, периоды — так у человека почти нет шансов запутаться.
Приветствую! Перекидать статьи затрат в новый формат занимает несколько минут на лист, потому что это просто копипаст. Формулы — это тоже минуты.
Из практики, самое сложное будет выбить логику из заказчика и продумать архитектуру хранения для первой модели, чтобы она вас устраивала и была расширяема на будущее. Тут можно будет несколько раз сделать с нуля, экспериментировать, тратя на итерацию от получаса до двух часов.
Итого: полдня-день на первую модель, ещё 16-40 часов на отладку, потом на остальные по 2-4 часа на перенос с нуля или адаптацию копии — выбор по ситуации.
На сопровождение такой работы — обучение людей, поддержка и перенос их руками — я бы заложил месяц на все 50 штук. Самому браться крайне рискованно.
Настоящая ликвидность параллелится между большой массой народа, с учетом множества факторов. Её нельзя вот так однозначно отобразить, потому что это многомерная штука, включающая как честные факторы (очередность, категорию клиента и др.), так и паразитные (фронт-раннеров).
Даже если это всё честно вывалить, это ничего не исправит — были тут 10 лет назад такие парни GKFX и ещё кто-то, не помню название (найду, если надо), и у них всё было честно и открыто, однако они все расходы на честность возлагали на клиента, и торговать было ОЧЕНЬ дорого.
Наверное, в этом и есть состав претензии. Лучше и естественнее наоборот: не в человеческий текст добавлять ИИ-пассажи, а использовать его как литературного невольника (уж такой эвфемизм, простите), а затем править его косяки и перефразировать.
Статья у вас упускает массу вещей, которые вы просто не можете зарегистрировать вашими скриншотами стакана, и не выводите из опыта, логики и наблюдений. Скажем так, она наивна.
Как эксперт, торговавший публично больше 12 лет, я вам так скажу: ликвидность в таких каналах вы можете видеть только нарисованную, и больше никакую. Нужна честная — ступайте в офлайн-обменник. Потом напишите здесь о разнице в накладных расходах :-)
В Кейсах на вашем сайте сделано именно это и ничто другое. Разово проанализировали и закрыли проблему. Решения устаревания данных на сайте нет, и оно организационное, вы тут ничем не поможете и инструментов для этого у вас не упомянуто. Пишу это как раз потому, что мы решаем именно эту проблему и очень хорошо в теме.
Зачем вы в этом контуре? Любой может накидать данные на листы экселя и скормить клоду.
Как интересно. А что вы продаете? Сейчас каждый сотрудник сам себе литиум, а некоторые ещё бы и вас могли научить много чему новому :-)
Модель у кас где - локально или сливаете данные вовне?
Эксель как эксель заменять действительно нет смысла, я им пользуюсь постоянно для разовых задач. Есть смысл вырасти из экселя для рутинных задач, автоматизации и защиты данных, и тогда выбора три: заказная разработка (дорого), самостоятельные поделки на конструкторах (весело) или оставить как есть — не трогать (риски, неудобство).
Да, и вот это тоже уберите и прекратите каждый раз выставлять обратно 100500 галок в Notifications!
Я встречался лично с владельцем продукта в РТ, наслушался, как надо делать и как не надо, что есть прошлый век, а что правильно. Тогда стало понятно, почему публике не показывают (и не планируют) живьем их продукт и каково его будущее. Пока люди не отвечают рублём (и шкурой!) за принятые архитектурные решения, а их ЛПР вообще не в курсе происходящего, продукт будет мёртвым, обрастет макросами на JS или Lua и в итоге сгинет.
Вроде они стараются делать так, как хорошо клиентам, а не как правильно с точки зрения архитектора, поэтому чувствуют себя, наверное, лучше, чем аналоги экселя и уж тем более MWS и РТ.
Наверное, это GreenData, Creatium... Навскидку не назову успешных, могу назвать только выживших. У многих, как вот ещё некий AppMaster, есть просто финансовая подушка и вера инвесторов/фаундеров, что всё это не зря. Плюс свои истории успеха греют.
У мелких производителей, к которым и мы относимся, как я признаюсь выше, вообще нет лимита на строки, есть свободная архитектура и абсолютная гибкость — как раз чтобы избавить клиентуру от ручной работы по максимуму, в этом шанс выжить у мелкого производителя, в отличие от гигантов с их планами на пятилетку.
Организациям нужно чуть больше, чем просто таблички, и много больше, чем BI. Поэтому с тамким скрипом идет распространение всеобъемлющих отечественных аналогов Excel, а продукты гигантов, кто делает это "по ходу", не пользуются массовым спросом вообще - ведь у частника есть выбор, в отличие от корпов.
Там проблема в том, что требования у одних, опросник готовят другие, а приемку делают третьи люди. В итоге корпорация покупает не то что нужно и разумно, а нечто необычное. Таков корпоративный порядок - логики 0.