Комментарии 28
Модель вычисления можно разложить между эксель и access
эксель может просто хранить данные в удобном виде, в табличке
access, как SQL база, может работать с разными табличками, включая лежащие в excel, в access, csv и др.
Просто главное что я имел ввиду — access и excel это уже продукты в готовом интегрированном виде, и не нужно использовать еще что-либо сверху, если нужно сделать gui
Не совсем понимаю, какая у вашего продукта ЦА.
Я — ЦА, руководитель нескольких проектов. Меня укачивает от обилия ERP/CRM/Task-managment систем. Мечтаю всё в Excel перевести, но останавливали проблемы описанные автором в статье (кнопки, dropdown-меню).
На текущий момент самое близкое решение моих проблем — Notion/Airtable, но на чужих серверах не комфортно.
Очень жаль, что не open source, но хорошо, что On-premise есть.
Ну на самом деле SQL далеко не всегда удобен для анализа. С моей точки зрения даже редко удобен. А продвинутая аналитика, когда Excel уже не хватает — это R+RStudio, либо Python + Jupyter.
Ну а если нужно что-то сделать для себя лично, то тут и так инструментов полно. Можно запустить Джупитер, можно открыть R-Studio, можно тот же Access использовать (хоть и не люблю я его), но это все для себя. А для заказчика: Эксель и желательно без макросов/VBA, без вариантов (хотя вру, есть один клиент, которому принципиально нужно в Таблицах Гугл, потому что они не пользуются продуктами Microsoft).
Возможно вам стоит подумать над тем, чтобы продвигать продукт именно как инструмент расчетов/моделирования данных, который применим в таких-то ситуациях. И в этих ситуациях он круче Excel потому что А, Б, В.
Но если работаешь на заказ, то делаешь так, как хочет заказчик, без вариантов. И тут зависит от того, на каком рынке работаешь. На уровне «бизнес-план/финмодель инвестпроекта» я кроме Экселя и надстроек к нему ничего никогда в требованиях не видел. Наверняка в инвестбанках, хедж-фондах и прочих институтах с серьезной математикой и big-data ситуация другая, но абсолютно уверен, что у них тоже есть свои тулбоксы, который считаются отраслевым стандартом.
В общем, я двумя руками за новые удобные инструменты, но если этот инструмент не сможет сохранить итоговый файл в формате Эксель (в удобном и читабельном виде) чтобы я мог отправить его заказчику, то для меня лично он будет совершенно бесполезен. Увы :(.
Выглядят по-разному. Скажем, прямо сейчас делаю модель инвестпроекта под ГЧП по стандарту одного крупного банка. Там один продукт (точнее услуга), структура файла следующая:
1. Лист «Сценарии». В столбцах G и далее указываются параметры сценариев (наличие/отсутствие господдержки, использование/неиспользование лизинга, форма вклада инвестора в проект и т.д.), в столбце F формулы, которые подтягивают параметры из выбранного сценария (номер указывается в отдельной ячейке). Никаких вычислений на этом листе нет.
2. Лист «Исходные данные». Тут, соответственно, все вводные: капексы, опексы, календарные графики работ, суммы необходимых кредитов, вклада в акционерный капитал, лизинга и т.д. Ну и прогноз выручки. Все это завязано формулами на лист «Сценарии» и должно автоматически пересчитываться при изменении сценария. Все показатели развернуты поквартально на срок реализации проекта плюс 3 года. В общей сложности порядка 500 строк и 150 столбцов.
3. Лист «Расчеты». Основной лист, тут мы считаем детали. Графики начисления и выплаты процентов по кредитам, выплаты по договорам лизинга (все в вариантах диф. платежей и аннуитета, выбор идет в соответствии со сценарием), детальный расчет выручки, расчет налогов, показатели бюджетной и экономической эффективности и т.д. и т.п. Итого 950 строк на те же 150 столбцов.
4. Лист «Финансовая отчетность». Собираем прогнозную финансовую отчетность. Баланс, отчет о прибылях и убытках, отчет о движении денежных средств и т.д. Все так же в поквартальной разбивке на срок реализации проекта + 3 года. Размер 150 строк на 150 столбцов.
5. Последний лист «Контроль». Здесь выводим все контрольки: источники финансирования должны быть равны затратам, остатки денежных средств, посчитанные в отчете о движении денежных средств на листе «Финансовая отчетность» должны быть равны остаткам по каскаду на листе «Расчет», суммы процентов начисленных должны быть равны суммам процентов уплаченных и т.д. и т.п. Если все формулы сделаны правильно, то сходиться должно автоматически, но по факту сразу не сходится никогда, потому что всегда бывают косяки :). Самая маленькая таблица: 30 на 20.
В других случаях используются другие варианты. Скажем, для производственных проектов под бизнес-план как правило самая сложная часть это технологическая модель производства. Например, для рыбоводного предприятия это куча листов с движением стада помесячно, каждый лист — одна порода рыб, в разбивке по зарыблениям. Потом из этого делаем сводные показатели (масса рыб в УЗВ, общий расход кормов по видам корма, объем закупа малька, потребность в рыбоводах, потребность в медикаментах и т.д.) и уже от этих показателей считаем экономику.
А потом идем в банк и тамошний специалист начинает тыкать пальчиком и заявляет, что цены на продукцию завышены и их надо пересчитать, а еще надо посмотреть что будет при удорожании кормов, да и зарплаты у вас как-то низковаты, поднимите до двух минималок… и начинается самое веселье :).
Что-то интересное и перспективно-масштабное в Вашем подходе есть.
Несколько соображений и вопросов:
В целом не опасаетесь ли «каскадных побочных эффектов» из-за того, что множество формул и функций, будут иметь возможность возвращать не только значения, но и что-то еще?
Абзац «Кнопки в ячейках позволяют ....» стимулирует множество вопросов… про связь между кнопкой (ну или расширенно — элементом управления) с ячейкой — это не близкий ли аналог ActiveX-компонентов (флажки, списки....) вытащенных на рабочий лист Excel и связанных с зависимой (взаимо-влияющей) ячейкой (типично для флажков) и «наполняющими» ячейками (откуда берутся значения — типично для списков? Это кстати и про доступ пользователя к кнопке без доступа к ячейке — это аналог защищенного рабочего листа с разлоченными Active-X и защищенными ячейками?
Насчет кнопки, нажатие на которую приводит к копированию данных между листами — параметры процесса копирования — какой исходный диапазон (столбцы, строки, сплошной/несплошной, с возможной фильтрацией....) и куда нужно вставить («верхняя левая» ячейка) на листе-получателе — это все будет описываться свойствами чудо-кнопки? Я просто не могу представить, как это можно сделать иным способом — я знаю 2 — либо пользователь, либо параметризуемый макрос.
Складывается впечатление, что Вы несколько педалируете известные недостатки VLOOKUP (спекулируете на них?). Что вы скажете о полностью замещающей конструкции типа =ИНДЕКС(диапазон1; ПОИСКПОЗ(значение; диапазон2;0); СТОЛБЕЦ(диапазон3)) — доступна начиная с Excel 97, которая полностью исключает проблемы изменений взаимного расположения столбцов — источника ключевых значений, ключей из обрабатываемого списка, извлекаемых значений?
(ссылка на признанного мэтра www.planetaexcel.ru/techniques/2/92 );
ну и что скажете про свежайшее решение проблем VLOOKUPов и ИНДЕКС(ПОИСКПОЗ() — это новая суперфункция, которая (пока?) доступна только в обновляемом по подписке Excel 365 — ХLOOKUP (по русски это ПРОСМОТРикс, а не ПРОСМОТРхэ) — здесь внутри одной встроенной функции наряду с прочим решена и задача возвращения дефолтных значений, если найти значение не удалось.
ссылки по теме
www.planetaexcel.ru/techniques/25/10910
msoffice-prowork.com/ref/excel/excelfunc/lookup-reference/xlookup
support.office.com/ru-ru/article/функция-просмотрx-b7fd680e-6d10-43e6-84f9-88eae8bf5929
иллюстрирует не недостатки традиционных табличных редакторов и потенциальные преимущества перспективных инструментов, а извечную программистскую проблему выбора «хранить или вычислять». Сделайте таблицу со столбцами Страна — КодСтраны — КодВалюты -ТекущийКурс и на один VLOOKUP станет меньше, ну и кстати хранить особо больше не придётся.
сколько еще коллег участвует в мозговых штурмах — проектирует структуру продукта, базовые принципы, какие фичи сейчас какие на потом…? Ограниченным составом, и тем более в одиночку, сложно смотреть на продукт с разных сторон, выбирать баланс противоречивых требований и пожеланий.
На большую часть ваших вопросов есть ответы в документации. Сайт можно найти в Гугле, но я пошлю вам линк личным сообщением (если я правильно понял, публиковать линк я права не имею).
Насчет интерактивности и других функций: мне кажется самое простое, это запустить приложение и поиграться самому. Формулы значения и цвета не зависят друг от друга. Формула заливки, например, должна вернуть строку со спецификацией цвета (например "#FFFFFF"). Разные типы формул рассчитываются независимо друг от друга.
Насчет команды: разрабатываю пока я один. Но роль продукт менеджеров пока играют немногочисленные клиенты. Я стараюсь добавлять универсальные функции, которые решают не только конкретную проблему клиента, но и могут пригодиться в других моделях.
читаю про очередной велосипед, и не понимаю конструкторов таких великов: ну решил автор убить тучу своих человеко- часов без проверки наличия альтернатив на рынке, а зачем? Начиная с Excel 2013 Microsoft уже такого в него повнедрял что вышеупомянутые офисные Access, VBA просто с этим меркнут (а предмет этой статьи просто закапывают в землю).
Пишу про киллер-связку: Power Query (продвинутый low code ETL с горой коннекторов к разным источникам данных и своим языком "M" для замороченных извращенцев которым мышки в нём почему-то не хватило) + Power Pivot с его колоночной аналитической СУБД (в его табулярных моделях кстати схемы "звезда/снежинка" категорически приветсвуются, как и в любых аналитических решениях) и его языком моделирования DAX (любой KPI показатель к вашим услугам). При этом бесшовная совместимость с Excel ибо его родные компоненты а понимание что можешь ворочать внутри оперативной памяти 120 миллионами записей в одной эксель книге — это приятно (хотя в таком случае Analysis Services конечно больше напрашивается)
Access и VBA конечно останутся как узкозаточенные инструменты, но в текущем мире они для решения Эксельных задач уже совершенно не актуальны. Пишу по 10 летнему опыту работы с Access, VBA (и в Эксель и в Access) и 6 летнему опыту работы с Power Query/Power Pivot/Power BI.
Автору конечно желаю коммерческого успеха с его продуктом и какого-либо интереса со стороны бизнеса (чтобы не было больно за потраченное время на разработку всего этого)
Да, пользуюсь. Телефон вообще основной инструмент, а гуглшит — для сопровождения бизнеса. Контролирую развитие и потоки денег в/из пары десятков инвестпроектов, каждый в гуглшите как лист представлен с одними примерно формулами, название листа — проект, плюс есть пивотлист с итогами. Так бы хорошо на ваш механизм проектировалось, но иметь только в компе без телефона — не комильфо. Плюс, на листах проекта ссылки на документы в гугл доках и договора в PDF на гугл диске.
Электронные таблицы как средство разработки бизнес-приложений