В последние годы тема экономического планирования и анализа становится все более актуальной. Но одновременно становится все более очевидной неэффективность реализации этих функций в дорогих и масштабных ERP-системах, в которых их наличие изначально предполагается (об этом даже говорит буква P «Planning» в аббревиатуре таких систем). Несмотря на огромные бюджеты и титанические усилия по внедрению ERP-систем экономические подразделения средних и крупных предприятий как работали, так и продолжают работать в электронных таблицах, преимущественно MS Excel.
В чем же причина такого положения дел? Неужели все дело в инертности экономистов? Или Microsoft удалось создать действительно уникальный продукт с точки зрения удобства и эффективности его применения в реальной бизнес-среде? Ну и робкий вопрос в конце, вынесенный в заголовок статьи — а есть ли альтернатива Excel?
Чтобы ответить на эти вопросы, прежде необходимо разобраться, в чем же заключается специфика экономического планирования и анализа, монополию на обеспечение которых держит Excel. Коротко ответ на этот вопрос заключается в одном слове – ВРЕМЯ. Это время, которое необходимо руководителям компаний любого уровня для принятия управленческого решения, на которое, в зависимости от масштаба проблемы, отводится от нескольких минут до нескольких дней.
Проще всего данный тезис продемонстрировать на примере процесса разработки и утверждения годового плана (бюджета) на очередной финансовый год. Данный процесс реализован в любой современной компании и предназначен не для угадывания своего будущего (широко распространенное заблуждение), а для контроля высшим руководством за процессом распределения отграниченных ресурсов (инвестиции, штатная численность персонала, лимиты кредитования и т.п.) между линейными и функциональными подразделениями компании в рамках бюджета на очередной финансовый год.
В отличие от регулярных процедур, таких как начисление налогов, выплата заработной платы, формирование финансовой и статистической отчетности, процесс разработки бюджета выполняется один раз в год и жестко ограничен временными рамками. Начало бюджетного процесса обычно начинается в октябре, когда уже доступна информация (хотя бы предварительная) о фактических результатах работы за 9 месяцев текущего года. Типовая схема любой бюджетной таблицы обычно содержит информацию об ожидаемых результатах за текущий год (по схеме факт 9 месяцев + ожидаемое 4 квартала), планируемых результатах на следующий год и отклонениях (абсолютных и относительных) для контроля динамики изменения показателей. В течение октября-ноября подразделения компании разрабатывают собственные бюджеты, а затем в декабре происходит их рассмотрение и утверждение руководством компании или головной организации.
В процессе разработки бюджетов может разрабатываться несколько их вариантов для различных сценариев внешней среды с учетом внутренних целей и задач компании. Тем не менее, в конечном счете выбирается основной (базовый) сценарий, по которому рассчитываются бюджеты всех подразделений. Конечным результатом данного процесса является консолидированный бюджет в целом по компании (группе компаний), в упрощенном виде являющийся суммой бюджетов всех входящих в компанию подразделений.
На практике при разработке бюджета каждое подразделение руководствуется принципом: «Проси больше, получишь в самый раз». Следствием такого принципа является дефицит сводного бюджета, когда планируемых доходов не хватает, чтобы покрыть запланированные расходы. Поэтому в любом бюджетным процессе на заключительном этапе всегда выполняется балансировка бюджета, заключающаяся в установлении более напряженных планов по доходам и срезание отдельных видов расходов тем или иным подразделением и статьям. Естественно, с последующим пересчетов всех планов и формированием консолидированного бюджета. И таких пересчетов с последующей консолидацией может быть столько, сколько нужно для сведения доходов и расходов в ноль.
Но это еще не все. На трудоемкую, но технически решаемую задачу многократного пересчета и консолидации данных накладывается гораздо более сложная задача, связанная с изменением модели данных, по которой происходит перерасчет и консолидация плановых показателей. Например, может быть принято решение о централизации в следующем году продаж основных видов продукции и выводе отдельных производственных процессов на аутсорсинг с созданием новых юридических лиц. И эти решения должны быть не просто описаны в виде текста или схемы, а должны быть внесены изменения во все расчетные документы, связанные с формированием себестоимости и финансовых результатов. Причем такие решения могут возникнуть как на стадии разработки предварительных бюджетов, так и на стадии балансировки сводного бюджета.
С точки зрения программного обеспечения, реализующего поддержку процесса бюджетирования, в вышеописанном процессе ключевым ресурсом становится ВРЕМЯ, в течение которого могут быть внесены изменения в бизнес-модель компании и выполнены расчеты уже по этой новой модели. Очевидно, что в этих условиях Excel находится вне конкуренции, так как позволяет обеспечить минимально возможное время от постановки задачи на изменение бизнес-модели до выдачи пересчитанных значений. ERP-системам остается только обещать учесть принятые решение при формировании бухгалтерской отчетности за 1 квартал следующего финансового года.
Что же позволяет Excel обеспечивать такую эффективность в управлении временем в процессе поддержки принятия управленческих решений? Ответ на этот вопрос также достаточно прост – при использовании Excel в лице каждого его пользователя одновременно сочетаются постановщик задач, бизнес-аналитик, тестировщик и конечный пользователь, функции которых в ERP-системах распределены не только между разными людьми, но и разными подразделениями. И самое главное, если пользователи Excel, даже выполняющие разные функции, говорят между собой на одном, понятном каждому языке, то пользователи ERP-систем (в широком смысле) говорят на множестве языков, требующих либо талантливых «переводчиков» (каких мало), либо строгой формализации процесса общения, который зачастую затягивается на неопределенное время.
Поэтому при всех ограничениях Excel по скорости обработки данных, а также неизбежное наличие процессов, реализуемых частично в ручном режиме, наиболее сложным из которых является процесс бюджетирования, Excel всегда останется вне конкуренции по сравнению с ERP-системами.
Определившись с ключевым преимуществом Excel, связанным с эффективностью его обращения с временным ресурсом, рассмотрим слабые его слабые стороны, которые должны быть реализованы в альтернативном программном обеспечении, чтобы составить ему достойную конкуренцию.
Очевидной слабостью Excel при работе с большими и сложными моделями является файловая модель хранения данных, которая:
Требует взаимодействия в внешними реляционными базами данных для обработки больших объемов данных по нескольким атрибутам;
Чревата трудноуловимыми логическими ошибками при изменении модели данных, состоящей из нескольких связанных файлов или листов.
Эти проблемы достаточно легко решаются путем разработки программных модулей на встроенном языке программирования, либо интеграцией с внешними программными решениями. Но в этом случае Excel лишается своего стратегического преимущества – наличие пользователя, сочетающего в себе одновременно функции постановщика задач, бизнес-аналитика, тестировщика и конечного пользователя. Вместо этого появляется как минимум двое – экономист и программист, говорящие на своих языках, имеющие по одному вышестоящему начальнику. В результате любая простая задача, обычно решаемая в голове одного человека, превращается в долгую бюрократическую процедуру.
Таким образом, любая альтернативная программная система может составить конкуренцию Excel лишь в том случае, если сможет расширить перечень решаемых Excel задач стандартными формулами без дополнительного программирования.
У появившихся в последнее время систем бизнес-аналитики, несмотря на громкие заявления, помимо более гибкой системы построения отчетов, в основе которых лежит модель данных сводных таблиц Excel, по большому счету и нет ничего (сводная таблица Excel упрощенно представляет собой select запрос к одной плоской таблице с разверткой атрибутов и агрегацией данных по нескольким полям по горизонтали и вертикали). Центральным же элементом любого процесса бюджетирования является расчет себестоимости продукции и формирование финансовых результатов, для которых модель данных сводных таблиц практически не применима.
Единственной на сегодня альтернативой Excel является открытая программная платформа моделирования сложных экономических систем JetCalc, исходный код которой доступен на GitHub. Там же содержатся ссылки на документацию, рабочую демо-версию и другие дополнительные ресурсы. Система распространяется по лицензии MIT и открыта к любым предложениям по участию в ее дальнейшем развитии для всех заинтересованных лиц.
Прежде чем перейти к особенностям архитектуры JetCalc, следует сказать, что JetCalc является свободной версией системы, реализованной в экосистеме JavaScript, основанной на архитектуре закрытой системы, реализованной на технологиях Microsoft, которая с 2012 года обеспечивает процессы бюджетирования, экономического анализа и консолидации управленческой и финансовой отчетности, в том числе для составления консолидированной отчетности в соответствии с МСФО, в крупном металлургическом холдинге с годовым оборотом более 10 млрд. $.
В системе JetCalc, как и в Excel, все расчеты выполняются на основе формул, которые разрабатывает и тестирует конечный пользователь. При этом расчетная система JetCalc обладает рядом уникальных свойств, позволяющих легко модифицировать используемые модели данных и формировать сложные консолидированные отчеты в режиме реального времени.
Ключевой особенностью модели данных JetCalc является способ создания формул ячеек. Если в Excel формулы прописываются для каждой ячейки, то в JetCalc формулы пишутся для строки или колонки, а на уровне ячейки формулы формируются системой динамически в контексте открытого документа. Такой подход кардинально сокращает время на изменение формул и полностью исключает появление арифметических ошибок. Более того, отдельные колонки комбинируются в заголовки (шапки) для определенных видов документов, что позволяет в одном месте менять формулы колонок одновременно для нескольких документов.
Другой особенностью JetCalc является наличие специализированного механизма суммирования значений ячеек по строкам документа, в основе которого лежит дерево строк, в котором суммирование производится по дочерним строкам для каждой родительской строки. Поэтому вместо перечисления ячеек в Excel, которые должны войти в качестве аргументов в формулу СУММ(А1; А2;…), в JetCalc достаточно поставить галочку против нужной суммовой строки на веб-интерфейсе. При этом любая строка может быть помечена, как не входящая в сумму, а также как суммируемая с противоположным знаком (то есть вычитаемая). При добавлении новых строк, в отличии от Excel, в JetCalc не нужно изменять никакие настройки, так как в контексте открытого документа формулы ячеек будут переформированы автоматически.
Третьей важной особенностью JetCalc является сбор информации в разрезе объектов учета, организованных в виде дерева, имеющих ряд атрибутов, позволяющих выполнять сложные вычисления по агрегации и фильтрации путем написания простых и понятных формул.
Например, для дивизиона «Металлургические предприятия» (код MET), в который входят АО "Уральский металлургический завод" (код 201) и АО "Уральский прокатный завод" (код 202), для расчета итога по дивизиону формула любой первичной ячейки в контексте документа будет преобразована к виду:
$строка@колонка#201? + $строка@колонка#202?Это же выражение может быть представлено в виде формулы с функцией консолидации, которое автоматически будет расширено при добавлении в группу MET одного или нескольких предприятий:
$строка@колонка<<<(D:MET)?Также в ядро системы JetCalc встроен механизм автопрокачки значений в форме ввода данных, позволяющий существенно сократить нагрузку на расчетную систему путем однократного сохранения в базе данных значений, вычисляемых по формуле, в виде первичных значений в базе данных. В последующем такие сохраненные значения могут многократно использоваться расчетной системой при формировании различных аналитических расчетов. Для настройки автопрокачиваемых значений применяются те же самые формулы, что и для настройки динамически вычисляемых значений.
Выбор между использованием динамических формул и автопрокачиваемых значений полностью определяется пользователем, настраивающим модель предметной области, и заключается в выборе между легкостью администрирования и скоростью расчета показателей документа:
динамические формулы достаточно настроить один раз, но по мере усложнения модели и увеличения количества данных скорость формирования отчетов будет постепенно замедляться;
формулы автопрокачки позволяют заменить вычисляемые значения на первичные, что кардинально увеличивает производительность отчетной системы, но требует большей дисциплины при модификации структуры документа, так как ранее прокачанные значения могут потребовать повторной прокачки после внесения изменений в настройки документа.
Подробнее о расчетной системе JetCalc можно прочитать по адресу.
Еще одним интересным механизмом повышения производительности экономистов в JetCalc является механизм контрольных точек, представляющий собой особый класс формул, также настраиваемых пользователями, которые при правильном вводе первичных данных должны выдавать нулевое значение. При наличии ненулевых значений в контрольных точках документ не может быть заблокирован от ввода данных, а значит официально не может считаться своевременно представленным в вышестоящую организацию. Такой подход позволяет распараллелить работу по выявлению логических ошибок на сотни сотрудников отчитывающихся организаций вместо единичных сотрудников вышестоящей организации.
И конечно же, в системе JetCalc реализованы такие стандартные возможности, как печать документов или сохранение отчетов в файлы PDF, вывод данных отдельных документов в виде графиков, создание предметной документации для каждого документа, и много другое.
Из перспективных вещей, на практике доказавших свою реализуемость, можно выделить возможность распространения однажды созданных моделей неограниченному числу подписчиков через GitHub. Данная возможность основана на хранении создаваемых моделей предметной области в базе данных MongoDB, а значений – в PostgreSQL. Поэтому модель предметной области представляет собой файл в формате JSON, который легко загрузить в базу MongoDB из любого источника.
В заключении хотелось бы сказать, что в настоящее время проект развивается в рамках личной инициативы его участников и готов для применения в реальных «боевых» условиях примерно на 90%. Но эти оставшиеся 10% требуют тщательной доводки системы до коммерческого уровня по всем направлениям – от тестирования скриптов развертывания, доработки функциональности расчетной системы, улучшения эргономики веб-интерфейса до написания документации, создания демо-моделей, разработки форматов сохранения моделей и протоколов обмена данными с внешними системами и многое другое.
Поэтому все заинтересованные в развитии проекта приглашаются к участию в команде разработчиков, на сегодня состоящей из двух человек, работая в которой можно будет найти своих единомышленников, получить уникальные знания по продукту, не имеющему аналогов на рынке, и реализовать свои самые фантастические идеи.
Комментарии (50)
dimoff66
24.08.2018 18:34В 1С давным давно есть готовые и относительно неплохо работающие модули по бюджетированию и планированию.
leossnet Автор
24.08.2018 18:39Ниша 1С — мелкие и средние компании. В этой ниже бюджетирование проще и дешевле реализовывать на Excel и типовых решениях по бюджетированию. JetCalc ориентирован на крупные и очень крупные компании, для которых достаточно высокий порог вхождения на понимание системы в последующем окупается большой гибкостью и производительностью при работе с аналитической информацией.
dimoff66
24.08.2018 20:22Без предметного обоснования того какие недостатки 1С или конретных подсистем бюджетирования и планирования
а) Мешают ей/им быть использованными на т.н. «крупных предприятиях»
б) Не позволяют ей/им быть гибко настраиваемыми
в) Делают неконкурентноспособной производительность
ваше утверждение останется голословным.leossnet Автор
24.08.2018 20:52Вопрос не в достоинствах или недостатках, а сравнительных затратах (денежных, временных, интеллектуальных) по внедрению конкретного решения. Чем крупнее компания, тем больше в ней различных «частных» случаев (а по большому счету бардака), унификация которых имеет не техническое, а политическое решение. Из своего опыта могу сказать, что лично видел достаточно крупную компанию, в которой планирование и учет были реализованы на 1С. Но для него характерно достаточно технологически однородное производство и очень высокий уровень порядка в учете, что встречается достаточно редко. В свою очередь прототип JetCalc изначально был ориентирован на работу в условиях бардака с постепенным наведением порядка в учете (справочники, методики, учетные политики, встречные сверки и т.п).
akryukov
24.08.2018 19:39+3В чем преимущество вашего решения по сравнению с R или Jupiter Notebook?
leossnet Автор
24.08.2018 20:12R и Jupiter Notebook — системы обработки и визуализации имеющихся данных, JetCalc — система создания этих самых данных. Например, с помощью R можно рассчитать отклонение удельной себестоимости различных видов продукции от среднего уровня, с помощью Jupiter Notebook вывести полученные отклонения на график, JetCalc же позволят рассчитать эту самую удельную себестоимость на основе исходных данных об объемах производства, удельных норм, цен на материальные ресурсы, численности и средней заработной платы, налоговых ставок, балансовой стоимости основных средств и норм амортизации и т.п. При этом ничто не мешает в будущем подключить в качестве расширений к JetCalc модули, использующие функционал на R и Jupiter Notebook, если в этом возникнет нужда, либо реализовать механизм экспорта данных в определенном формате.
leossnet Автор
24.08.2018 20:34Подробнее о применении JetCalc при разработки модели расчета себестоимости продукции можно почитать по адресу www.leossnet.ru/?page_id=370
usetester
24.08.2018 20:58Выглядит ооочень интересно. Но возникает сразу несколько вопросов, которые из документации и материалов сайта не очевидны.
У меня управленческий учет организован в соответствии с принципами теории ограничений Голдратта, и например разброса операционных затрат на «себестоимость» мне нужно избежать, но калькуляция прямых затрат по продуктам необходима. Система позволит настроить полностью собственную модель расчета показателей, в том числе выработки (валовая выручка минус прямые затраты на единицу продаж) и чистой прибыли (упрощенно — выработка минус операционные затраты)?
Правильно ли я понял, что я могу вести учет в разных валютах как минимум на уровне отдельных компаний холдинга, а то и на уровне одного документа?
В документации отсутствует раздел про импорт данных, а это критический момент :) Смогу ли я настроить интеграцию с моей самописной системой в реальном времени?
Нет ли часом сборки под Докер? Это не проблема, но если вдруг есть — избавит от занудной возни…leossnet Автор
24.08.2018 21:49По поводу моделей могу сказать, что пока не вижу никаких ограничений, чтобы реализовать любую модель управленческого учета любой степени сложности. Но даже если возникнут ограничения, то их легко можно будет устранить — код ведь под контролем.
Учет первичных данных можно вести в любых валютах, но при условии, что одно предприятие ведется в одной валюте. Отчетных же валют может быть три — по умолчанию (для России это рубли), а также две других произвольных (например, доллары и евро), ну и плюс для каждого предприятия в формах ввода своя собственная валюта (если она отличается от трех отчетных валют).
Если нужен учет в определенных валютах на уровне документа, то необходимо ввести эту валюту в качестве единицы измерения, которую пометить как неденежную, чтобы не пересчитывать по курсу при переключении отчетных валют.
У прототипа JetCalc реализован механизм импорта через прикрепляемые к документу файлы в формате Excel, в которых в первых колонках и строках прописаны коды, по которым нужно импортировать данные. В существующей системе этот механизм не реализован лишь исходя из соображения его низкой приоритетности по сравнению с другими задачами. При необходимости эта задача может быть решена максимум за месяц, причем как посредством файлов, так и непосредственным подключением к внешним источникам данных. Основная проблема будет только в маппинге кодов JetCalc и внешних систем.
Причина низкого приоритета задачи по импорту данных обусловлена личным опытом, который утверждает, что проблема импорта данных на 90% зависит от порядка в первичном учете и на 10% от программных механизмов закачки данных. В своей же практике пока что не встречал разнородное предприятие с высоким уровнем стандартизации и унификации учетных данных и процедур.
Про докер (и все что угодно еще) могу сказать, как только появится реальный заказчик, которому это нужно, так будет реализован нужный функционал. Ну или возможен вариант с Вашим подключением к разработке.usetester
24.08.2018 22:13Можно про импорт чуть подробнее? Поток данных в реальном времени у меня есть, но это просто данные о продажах и расходах в некоторой их части. Не хотелось бы вводить ручками то, что уже есть в том же постгресе. И заливать файлы импорта вручную тоже не хотелось бы, ибо будут данные запаздывать, а это иногда критично. Понятно, что можно хоть на уровне базы обеспечить обмен, но если понимать какой есть план по реализации импорта или какого-то API, было бы проще принимать решение.
Про Докер ясно, чтобы попробовать — все равно придется образ делать, так что подключусь к разработке воленс-ноленс :)leossnet Автор
24.08.2018 22:58Так сейчас происходит закачка данных по продажам в прототипе:
1. В специальной админке маппается справочник предприятий с внешним справочником. Обычно это маппинг один к одному.
2. Далее маппается справочники продукции. Здесь несколько сложнее. В аналитической системе обычно продукция вводится без учета мелких классификаторов, а в учетной системе продукция учитывается с учетом самых мелких спецификаций. Поэтому мапиинг выполняется по схеме один ко многим.
3. Вручную прописывается маппинг колонок на стороне учетной системы.
4. Далее следует развилка. Можно выгружать первичку как есть с последующей группировкой в аналитической системе, либо наоборот, выружать в учетную систему таблицу маппингов, а затем получать уже готовые агрегированные данные с кодами аналитической системы.
5. Данные выгружаются в файл XML или JSON (кто как привык) и складываются в определенную расшаренную папку или настраивается веб-сервис с доступом к выгруженному файлу. Выгрузка в файл необходима, т.к. отчет в учетной системе формируется несколько часов (что поделать — SAP), а процедура импорта — в течение нескольких минут или даже секунд.
6. В отрытой форме ввода по продажам прикрепляется файл (или подключается к сервису доступа), а затем нажимается кнопка импорта, которая по своей сути выполняет эмуляцию ручного ввода, только данные в первичные ячейки заносятся не руками, а машиной из прикрепленного файла (сервиса).
6. Кнопка импорта может быть настроена как на заполнение доступных для ввода ячеек без сохранения, так и с одновременным сохранением в базу данных (дело вкуса).
7. Можно конечно обойтись без кнопки импорта, но тогда теряется контроль над вводом данных, особенно когда находятся ошибки в исходных данных и нужно выполнить повторный импорт. А для варианта импорта без сохранения можно увидеть, какие значения остались неизменными, а какие изменились. Причем история ячеек позволяет посмотреть как ранее введенное значение, так и видимое на экране еще не сохраненное значение.
8. Что касается «запаздывания данных», то хоть убейте, не могу представить себе ситуацию, когда все найденные экономистами косяки исправляются бухгалтерами точно в срок. Обычно после импорта данных «вылезают» контрольные точки с красными значениями, на выявление причин которых требуется время, на порядки превышающее время самой процедуры импорта.usetester
24.08.2018 23:27По п. 8 — нет никаких SAP и бухгалтеров. Небольшие компании, типа ИП на УСН, все оперативно и прозрачно. Нужно чтобы все работало с минимумом человеческого фактора. Людям есть чем по делу заняться, и все что можно получить автоматически — надо получать автоматически и без лишних проверок.
Но для начала если при нажатии на кнопку импорта можно будет обратится к моей системе и получить от нее файл импорта (с этим проблем никаких) — то это вполне решение. Ну если я правильно понял, что так можно.leossnet Автор
25.08.2018 00:26Ситуация понятна. Пока поставил в трекер задачу leossnet.myjetbrains.com/youtrack/issue/JC-454.
Сейчас на повестке поиск достаточно крупного (скорее организационно сложного) заказчика для первого внедрения JetCalc, сверхзадачей которого является доработка кода и формирование сообщества разработчиков и пользователей JetCalc. Как только станут ясны контуры такого сообщества, а код избавится от явных багов, можно будет вернуться к задаче импорта данных. Если же кто из сообщества возьмет на себя такую работу, то эта задача может быть решена быстрее.
stgunholy
25.08.2018 09:37Добрый день! Очень интересная концепция. Возникла пара вопросов:
1. Как выполняется локализация UI?
2. Можно ли справочники замапить из своей системы?
3. White-labeling/или включение как чать своей системы трудно реализовать?leossnet Автор
25.08.2018 10:351. Каждый элемент интерфейса имеет свою метку, к которым затем происходит привязка наименований. Сейчас есть пока только русская локализация, и она устанавливается вручную. Но потом можно вынести на интерфейс переключение между множественными локализациями. Содержимое файла можно посмотреть здесь:
github.com/leossnet/jetcalc/blob/master/install/translate.json
Этот файл при установке копируется в папку /htdocs/jetcalc/static/custom/. Кроме того, этот файл можно редактировать с интерфейса пользователями с соответствующими правами.
2. По справочникам, и вообще по интеграции, изначально принято решение, что в ядро системы входят только универсальные решения, а специфические решение оформляются в виде внешних модулей и разрабатываются сторонними разработчиками. Для взаимодействия этих модулей предполагается разработка API, которого на сегодня нет, т.к. до конца не доработан код ядра, чтобы потом ничего не переделывать. Более того, есть ощущение, что если система пойдет в массы, то часть ядра придется перерабатывать.
3. Условия распространение ядра системы максимально свободные, поэтому нет никаких ограничений на использование JetCalc как часть других систем. С технической точки зрения в ядро системы будут входить только те решения, которые окажутся универсальными для всех. Поэтому если эта тема окажется интересной хотя бы двум независимым заказчикам, то можно будет подумать о разработке специфического API.stgunholy
25.08.2018 10:47Спасибо за подробный ответ!
Было бы здорово если бы систему можно было использовать сразу на нескольких языках.
И вот что было бы совсем замечательно — это возможность «публиковать»/включать/имбеддить отчеты/графики/презентации. Без регистрации и СМС :)… Тогда можно было бы вместо apache zeppelin использоватьleossnet Автор
25.08.2018 11:11Про многоязычный интерфейс дело решенное, вопрос только во времени.
По презентациям немного расскажу здесь, т.к. эта тема еще не доделана (есть только макет презентации и работающий механизм хранимых отчетов):
1. Каждый документ имеет базовое табличное представление.
2. Опционально документ может быть представлен в графическом (уже есть) или текстовом (пока нет) виде.
3. Каждое представление может быть настроено путем фильтрации строк и колонок, которое сохраняется в виде хранимого отчета со своим кодом и наименованием.
4. В рамках презентации могут быть объединены один или несколько ранее настроенных хранимых отчетов из разных документов.
5. При изменении настроек хранимого отчета в рамках документа автоматически изменяются все ссылки на эти хранимые отчеты в различных презентациях.
6. Для построения графиков используется бесплатная библиотека C3, хотя может быть подключена любая другая библиотека (пока в планах).
7. Текстовое представление представляет собой текстовый шаблон, в котором большая часть документа генерируется автоматически путем построения фраз, состоящих из наименований показателей и их значений, представленных в табличной части, объединенных типовыми связками. В прототипе JetCalc этот механизм реализован, но в новой системе он требует переосмысления, поэтому будет реализован не ранее чем через 2-3 года.
mouze1976
25.08.2018 19:55Добрый день! Спасибо за вашу работу.
Установил Jetcalc к себе на ubuntu 16.04 при вводе логина admin пароль admin пишет Пользователь не найден.
В чем может быть проблемма, где хранятся пользователи?
Почему в демо версии на вашем сайте очень тормозит система?
Объемы производства за Январь 2018 — Отчет.leossnet Автор
25.08.2018 20:08По пользователю admin — это ошибка установки. См. задачу: leossnet.myjetbrains.com/youtrack/issue/JC-449.
Просто Вы первый, кто реально развернул у себя систему. Постараемся быстро исправить, о чем можно узнать из трекера.
На тему тормозов прошу уточнить, в чем это выражается. Нормальным считается обновление содержимого документа за 1-3 секунды. По объемам производства — это менее 1 секунды. Возможно проблема в скорости сети или проверке антивирусом скриптов веб-клиента.mouze1976
25.08.2018 21:31На тему тормозов прошу уточнить, в чем это выражается.
Это я ошибся, просто зашел на демку по адресу dev.jetcalc.com, вот там все тормозит.
А тут jetcalc.leossnet.ru работает.
Подскажите а где можно задавать вопросы по вашей программе, что бы хабр незахломлять.
vdshat
26.08.2018 01:19Прям бальзам на душу: 2002 год, а я в банке ваяю подобную аналитическую систему… :) Но все же отличную от описаной.
Честно говоря сразу возник вопрос: а почему изменение модели это проблема? Любая аналитическая система как раз строится на принципах, позволяющих быстро измененять модели данных. Excel или другой табличный процессор для этого не предназначен. Другое дело, что он знаком всем своим интерфейсом.romandubrovsky3
26.08.2018 12:44Простите, а можно полюбопытствовать, зачем именно банку нужная подобная система? Насколько я понимаю, для контроля инвестиционных проектов. И в этом вопрос: насколько глубоко банку интересно этот процесс контролировать? Достаточно ли общих инвестиционных показателей или хотелось бы видеть подробности производственных процессов (предположим, этот было бы просто сделать)?
vdshat
26.08.2018 23:44Банк -урезанное производство. И все, что пресуще производству, все находит оражение и в банке. Конечно не в том, может, объеме, и не с теми сущьностями, но от перестановки мест слагаемых, как говорится…
Прогнозирование и конроль в банке бывает даже жестче. Например, прогноз наличия средств для покупки валюты или игры на бирже нужен в реалтайме с учетом недопулученной прибыли, денег в пути, выплат клиентов и т.п.
На производстве же не настолько быстро обычно, хотя бывали случаи в 90-00х, когда инфляция была дикая и нужно было оООчень быстро реагировать, но объемы, с учетом позиций, могут быть огромные (метизы, например) — та же big data. И тут с Excel'ом или JavaScript делать нечего — вылетаем по памяти :). Нужно работать со столбцами (измерениями) и потоками.
leossnet Автор
26.08.2018 12:59Проблема не в изменении модели, а в скорости такого изменения. Если руководителю нужна информация завтра, а модель может быть изменена послезавтра, то такое изменение никому не нужно — решение будет принято на основе старой модели с некоторыми поправками в голове руководителя.
vdshat
26.08.2018 23:29Так вот если строятся модели на основе не таблиц, а измерений (столбцов, кубов и т.п.), то изменение ничего не стоит — меняешь, а точнее строишь модель на лету. Т.к. одному нужно в одном разрезе, другому в другом, одному консолидировано, а другому в деталях. В аналитике не работают с косными структурами
leossnet Автор
26.08.2018 23:43JetCalc осознанно ушел от модели данных на основе кубов, которая не позволяет выполнять разные хитрые расчеты, например калькуляции основного производства на основе рекурсивно рассчитываемого баланса металлов. Более того, возможность манипулирования кубами нужна очень узкой категории специалистов-аналитиков. Подавляющему же большинству руководителей нужна информация в жестко заданном формате, чтобы каждый раз не тратить время на изучение структуры документа, а можно было лишь взглянуть на документ за очередной отчетный период, чтобы понять текущую ситуацию.
Поэтому JetCalc позиционируется как кибернетическая система управления экономикой сложных хозяйствующих субъектов с элементами контроля исполнительской дисциплины. Аналогом JetCalc в технических системах является киповское оборудование, для которого устанавливаются допустимые диапазоны значений, получаемые с датчиков оборудования, чтобы производить периодический мониторинг работающего оборудования и выдавать сигнал только в случае выхода показаний за допустимые пределы.vdshat
26.08.2018 23:48Вот именно в формате, а вы пытаетесь совместить модельи формат. Никто не говорит, что руководителю нужно каждый раз изобретать модель. Но предоставить возможность работы с сущностями, а все аггрегаторы и калькуляторы для него не должны бытьвидны
leossnet Автор
26.08.2018 23:54Проблема в том, что руководителю всегда нужна информация еще вчера. А крайним, если вдруг окажется ошибка в расчетах, всегда выступает экономист. Поэтому для быстрого реагирования на запросы руководителей и нужна система, позволяющая экономисту быстро учесть новые вводные, чтобы выполнить самые сложные расчеты.
Конечно, можно посчитать и на коленке, но тогда нет никаких гарантий, что до исполнителей в других подразделениях дойдет именно та информация, которая должна дойти по расчетам экономиста.vdshat
27.08.2018 08:07Вы рассматриваете подход, когда документы отчетности живут отдельно от основных данных? У руководителя должен быть АРМ с готовыми отчетами-представлениями всех данных в нужных разрезах. Просить каждый раз экономиста сделать отчет и каждый раз зависить от настроения и точности исполнителя — это даже не анахронизм, извините.
Работая что на производстве, в торговле, что в банке первым делом, при внедрении нового автоматизированного комплекса грамотный руководитель заказывает свои элементы управления. Пока пишется и отлаживается, да, может спрашивать подчиненных предоставлять эти данные. Например, в банке было чуть ли не ежечасно фин. директор прибегал с вопросом: сколько денег на корр. счете. А разработчики посчитали, что эти данные не критичны и не дали интрумент руководителю, чтобы он видел картину в динамике втечении дня, а не только как факт в конце после всех сделок. Поэтому быстро в обход основного ПО пришлось делать все нужные срезы и выжимки, а также получение и агрегацию данных для них, чтобы можно было делать прогноз хотя бы с отставанием до 5 минут.vdshat
27.08.2018 08:19(было физическое ограничение репликации базы данных). Иногда и в стратегии играют роль секунды, а не только в тактике. Например, идут переговоры с крупным клиентом о предоставлении большого кредита. Да, подготавливается пакетдокументов с анализом. Но клиент хочет больше сумму. Т.к. клиент большой отказ может негативно сыграть всем. Банк рискует исходя из оперативной картины, например, заходя деньги другого клиента и можно на них рассчитывать. И не кто не побежит даже к главбуху за этими данными они должны быть перед глазами постоянно в акктуальном состоянии.
leossnet Автор
27.08.2018 09:24Уточню определения. JetCalc позиционируется как система управления экономикой, которая имеет временной лаг длиной в месяц, в течение которого происходит формирование оборотов и остатков по всем счетам в бухгалтерском учете. Причем за отчетный месяц такая работа завершается не ранее, чем через 2-3 недели по окончании этого месяца.
То, что Вы приводите в качестве примера, являются системами управления режима реального времени, типа клиент-банка и диспетчеризации производства. Кому нужно, и так получают доступ к таким системам, и для этого не требуется создание каких-либо дополнительных программных прокладок.
С другой стороны, JetCalc ориентирован на крупные компании, состоящие из десятков предприятий или подразделений. Для таких компаний самый обычный показатель, например, выручка от продаж, умножается на число предприятий компании, например на 100. То есть величина крупной компании принципиально меняет качество работы с экономической информацией. На уровне управляющей компании приоритетом становится распределение ресурсов и контроль за эффективностью отдельных предприятий не реже чем раз в квартал. В вот операционное управление переводится на уровень отдельных предприятий, в том числе ежедневный контроль за расчетным счетом, выпуском продукции, движением по складу и т.п.
По этой причине для головной организации гораздо важнее, чем технологическая скорость получения информации, становится обеспечение синхронности получения данных от отдельных предприятий, сопоставимости однородных показателей по разным предприятиям, а также, самое главное, достоверности получаемой информации. А искажения информации могут возникать совершенно по разным причинам — неправильное отражение первичных документов, расхождения в учетных политиках контрагентов, несвоевременное предоставление первичных документов и т.п. В результате таких ошибок сводные результаты по компании могут стать совершенно не адекватными, следствием чего становятся неверные управленческие решение, ведущие в конечном счете к убыткам.
leossnet Автор
27.08.2018 00:07И еще очень важно замечание. По моему глубокому убеждению, если руководитель любого уровня лично занимается анализом первичных данных, он является некомпетентным в своей сфере и занимает чужое место. Основные функции руководителя — организация и стратегия. И если он занимается первичным анализом, значит он не умеет делегировать полномочия, не доверяет подчиненным, не может четко сформулировать свою мысль и т.п.
Правильное поведение руководителя — найти подходящего специалиста, организовать внедрение JetCalc и создать систему регулярного управления на основе набора документов управленческой отчетности, отражающей все ключевые особенности бизнеса компании.
SergeyGershkovich
26.08.2018 20:12Из Начало работы в JetCalc. Глава 6. Расчетная система
1...., в системе JetCalc используются ячейки вида $f105215@On?, где $f105215 — код строки (строка 215 формы f105), @On — код колонки (остаток на начало),? — завершающий символ.
2. В системе JetCalc каждая ячейка имеет шесть измерений — строка, колонка, год, период, объект учета, валюта — поэтому полный синтаксис ссылки на ячейку, представленной в предыдущем пункте, будет выглядеть следующим образом: $f105215@On.Y2017.P11#210[RUB]?, где .Y2017 — 2017 год, .P11 — период 11 (январь), #210 — предприятие с кодом 210, RUB — код валюты рубль.
— ну, никак не альтернатива для простого экономиста, освоившего =СУММ(A1;A76). Как технологический конкурент для Oracle Hyperion Planning или решениям на 1С вполне допускаю.
Проблема не в изменении модели, а в скорости такого изменения. Если руководителю нужна информация завтра, а модель может быть изменена послезавтра, то такое изменение никому не нужно — решение будет принято на основе старой модели с некоторыми поправками в голове руководителя.
Быстро перекинуть формулы в модели не проблема.
Проблема — это когда на десятки отчетных форм насчитывается тысячи формул, и эти формулы взаимосвязаны. Т.е. поменяешь в одном месте, вылезет в другом — баланс доходов с расходами не сошелся. Пользователи недовольны, разработчики модели плечами пожимают, предлагают снова запустить пересчет, а вдруг все сложится…
Поэтому электронные таблицы вне конкуренции. Экономист подправил без всяких формул итоговую ведомость и положил отчет руководителю, пока разработчики модели курят, на какой формуле они знак перепутали.
И решение этой проблеме давно уже придумали. В экономике закон сохранения стоимости такой же, как в физике закон сохранения энергии: если где-то что-то убавилось, значит куда-то в таком же объеме прибавилось. Правда экономисты от этого бухгалтерского закона, как от огня бегают, поэтому и системы бюджетирования высоко взлетев, часто больно падают.
Мой совет. Присмотритесь к планированию движения стоимости в виде двойной записи — как в бухгалтерии факт учитывается: Дебет-Кредит-Сумма. Чтоб в модели с самого начала баланс был заложен, когда расходы с доходами сходятся. Такого ваши конкуренты пока почему-то не предлагают.leossnet Автор
26.08.2018 21:48Под моделью в JetCalc подразумевается набор связанных формулами документов, каждый из которых отражает аналитику определенного бухгалтерского счета (хотя реализация этого принципа целиком и полностью отдается на откуп профессионализма разработчика модели). Некоторые бухгалтерские счета содержат явно определенные коды бухгалтерских счетов (например, 90-продажи или 43-готовая продукция), некоторые неявно (например, 26-управленческие расходы), а некоторые являются комплексными документами, на которых отражаются остатки и обороты по счету в корреспонденции с другими счетами (например, 20-калькуляции основного производства).
Более того, концепция бухгалтерской проводки (двойной записи) в JetCalc расширена и названа бизнес-транзакция (коротко «бизтран»), которая позволяет оформлять одной проводкой операции между двумя юридическими лицами (например, д-т 10 к-т 90 — поступление продукции на склад предприятия А и продажа продукции с предприятия Б).
Концепция бизтрана позволяет на основе концепции двойной записи настраивать модели с формульными связями между множеством юридических лиц, объединенных в рамках холдинга, что обеспечивает возможность автоматической прокачки данных по приходу у одного юридического лица при вводе данных у другого юридического лица по связанным бизтран-операциям. И конечно же, при добавлении любой аналитики по какому-либо счету (продукция, контрагент, договор, статья договора) автоматически добавляются необходимые записи по всем связанным счетам как самого предприятия, так и его контрагента.
Данный функционал в JetCalc пока не доработан, т.к. не совсем понятен уровень его востребованности у потенциальных пользователей opensource-проекта. Хотя в прототипе JetCalc на основе этого функционала уже давно настроены аналитические документы по встречным сверкам покупок-продаж, дебиторской-кредиторской задолженности и выданных-полученных займов.
leossnet Автор
26.08.2018 23:31Что касается первой части Вашего вопроса, касающейся сложности формул вида $f105215@On.Y2017.P11#210[RUB]?, то данное представление является аналогом байт-кода, удобного для применения расчетной системой JetCalc. На практике формулы обычно представлены в виде @On? — @Ok? (расчет изменения остатков на уровне колонки) или $f120100? — @f120200? (расчет валовой прибыли на уровне строки). Недостающую часть формул расчетчик JetCalc преобразует в контексте документа при его первом открытии, когда становятся известны код объекта учета, код периода и код года, а также код валюты.
Более того, обычные формулы суммирования, которые на практике составляют 80-90% от общего числа формул бухгалтерского документа, вообще не нужно писать — достаточно поставить крыжики в нужных местах.
Поэтому из опыта работы в подобной системе могу сказать, что для настройки даже самой сложной модели приоритетом являются глубокое знание экономистом специфики бизнеса своей компании и понимание логики бухгалтерского учета на уровне главной книги, позволяющей классифицировать любую хозяйственную операцию в виде бухгалтерской проводки. И именно на такого специалиста рассчитана система JetCalc.
Что касается необходимого времени для настройки модели, то приведенный выше пример с настройкой системы калькулирования для черной металлургии занял примерно 3 недели, включая время на изучение методологии расчета. Нудное же заведение различных справочников и статей можно обойти путем простого копирования подготовленной в Excel структуры документа в новый документ JetCalc простым копипастом.
SergeyGershkovich
27.08.2018 09:23… глубокое знание экономистом специфики бизнеса своей компании и понимание логики бухгалтерского учета на уровне главной книги, позволяющей классифицировать любую хозяйственную операцию в виде бухгалтерской проводки. И именно на такого специалиста рассчитана система JetCalc.
Качество работы этих мифических специалистов меня очень сильно и беспокоит.
Более того, концепция бухгалтерской проводки (двойной записи) в JetCalc расширена и названа бизнес-транзакция (коротко «бизтран»)
Ткните меня, пожалуйста, где можно пощупать ваши «бизтран». В описании системы слишком кратко и операции между двумя юридическими лицами пока не интересуют.
Интересует система с возможностью формирования описанных вами отчетов из данных в виде двойной записи (проводок) с индивидуальными наборами аналитики по каждому счету. Я понимаю, что технически это реализуемо в JetCalc. Интересует, существуют ли инструменты удобной работы пользователя с двойной записью, когда проводок >1млн. большая часть будет загружаться из учетной системы, но пользователи должны иметь удобные инструменты корректировки и анализа данных, также важен контроль ввода аналитических признаков по 60 — Контрагенты, договоры, по 10 Номенклатура, по 20 — заказы и т.д…leossnet Автор
27.08.2018 09:35Согласен, качество таких специалистов является критически важным фактором для успешности построения системы управления экономикой. Поэтому на своем сайте считаю необходимым выкладывать материалы методологического плана для этих самых экономистов, а также лично принимать участие в их подготовке.
Что касается бизтранов, то показать могу только при личной встрече, т.к. в демо-версии пока такой функционал не настроен. Либо можно подождать какое-то время для его появления в демо-версии или в документации (что появится раньше). А еще лучше подключайтесь к разработке, и тогда узнаете о еще более масштабных концепциях.
evocatus
Javascript?
>> 0.1 + 0.2
0.30000000000000004
Excel (и LibreOffice Calc) так не делает.
Скажите, пожалуйста, что в этом JetCalc это исправлено.
leossnet Автор
Спасибо за вопрос. Сделал тестовый документ, в котором отладчик показал результат 0.30000000000000004, т.к. расчетчик реализован на JavaScript. Будет исправлено.
evocatus
А как вы это исправлять будете, если в JS все числа это float? Создавать кастомный тип Decimal?
leossnet Автор
примерно как здесь: habr.com/post/159313
раздел «Работа с дробными числами»
gaidukav
Эта ошибка проявляется практически во всех языках.
JS, C, C++, Perl — это до чего прям щас руки дотянулись…
Интересно было бы узнать как они это будут побеждать.
leossnet Автор
По слухам, в последней версии Node.js это вроде поправлено. Но нужно проверять.
TheAthlete
в Perl 6 ошибки нет, т.к. там есть рациональные числа
Iqorek
Не совсем, там все очень сложно, пока числа целые, они могут достигать 2 в 53й степени, при этом работать с ними будет сложно, битовые операции поддерживаются только до 2 в 32й. Поэтому да, для денег лучше использовать одну из реализаций BigDecimal.