2 Infinity Creator. Дополнительная информация, которую Вы привели, много что разъяснила. Благодарю за то, что Вы это сделали.
Тем не менее, то, что Вы делаете - это "самописка". Не важно, что Вы используете ПО MS Office. Всё равно это самописка, ориентированная не только на определенную отрасль, но и на вполне определенные задачи и конкретные бизнес-процессы. Если бизнес-процессы окажутся другими, то это еще очень большой вопрос, на что больше уйдет времени - написать собственную самописку или переписывать Вашу.
Вы приводите аргументы, что программистов, способных разобраться в VBA и "докрутить" - много. Но также много хороших программистов под Delphi, C#, C++, X++ и встроенного языка 1С. На каком языке написана самописка - не так уж и важно, если язык достаточно распространен.

Infinity CreatorВ опчем как я делаю вывод из всего услышанного - как коммерческий продукт вы эту систему не видите. Ок. Нас только время сможет рассудить. Но если есть система "Инфин", которую ребята реально умудряются продавать, то думаю своего покупателя мне найти удастся.Вы не прочувствовали маркетинговых преимуществ ИНФИНа, а они весьма существенны.
ИНФИН позволяет заниматься кастомизацией системы в терминах прикладной области (например, бухучета) , а не программирования. Возможность перейти при кастомизации на язык прикладной области - это очень важная особенность, которая существенно ускоряет кастомизацию. Я знаю нескольких бухгалтеров, которые самостоятельно занимались настройками ИНФИНа, при этом не зная ни одного языка программирования и не имея опыта алгоритмического программирования. Наврядли специалисты прикладной области смогут заниматься кастомизацией Вашего продукта - не так ли?

Если говорить конкретно об ИНФИНе... Его преимущество (а не недостаток) как раз в том, что для его кастомизации не требуется использование какого-либо алгоритмического языка программирования, требующего соответствующих айтишных знаний и опыта. В то же время его гибкость в пределах предметной области (!!!) оказывается весьма существенной, потому что он не является также представителем систем, в которых кастомизация производится выборкой неких альтернатив из выбадающих списков, установкой галочек и т.п. (кнопочно-флажочная кастомизация), которые весьма жестко задают правила выбора - все возможные алгоритмы обработки данных для них изначально получаются заложены разработчиком, если разработчик чего-либо забыл или не предусмотрел - приплыли.

ИНФИН предоставляет третью возможность - Excel-подобную концепцию формул и шаблонов. Причем, операнды формул записываются в синтаксисе прикладной области. Поэтому скорость кастомизации в ИНФИНе просто потрясающая, не сравнима ни с одним из известных мне других продуктов. Вы совершенно верно выше расписали преимущества разработки шаблона или формы в кастомизации в Excel. Но дальше в Вашей системе начинается алгоритмическое программирование, а в ИНФИНе всё остается примерно на уровне пользователей Excel, умеющих вписывать формулы в ячейки.

2 человека в ИНФИНе самостоятельно поддерживали 20 совершенно разных (!!!) "конфигураций" (разные планы счетов, разные алгоритмы расчета, расзные структуры и логики, всё разное) для разных юридических лиц, и при этом сами отслеживали все изменения законодательства и соответствующим образом вносили изменения во все 20 конфигураций. Сможете ли Вы водиночку заниматься сопровождением 10 совершенно разных систем, переписанных из одной Вашей, если ежемесячно в них будут вноситься изменения в размере 3-5% общего объема настроек? Подумайте над этим вопросом, прежде чем хаять ИНФИН... :)

Infinity CreatorНасчет поделок 90-х. Возможно это и похоже на них, но тут есть принципиальная разница. Excel выполняет исключительно функции клиента. Данные же крутятся на серваке. Ну да ладно. Все это я уже писал выше.Ну и какое принципиальное отличие от RAD в которых в Excele-подобном режиме создаются формы и отчеты? Если есть проблемы с быстродействием, то это, скорее всего, кривость конкретной реализации. На VBA точно так же можно написать "кривой" код, и быстродействие точно так же пострадает. В конце концов, если речь идет именно о быстродействии, то странно, что выбран интерпретатор в качестве инструментария, а не компилятор.

Общие комментарии.
Судя по всему, Вы решаете задачу формирования итоговых аналитических финансовых данных по некой первичной информации. Но дело в том, что в любом бизнесе обычно это далеко не единственная задача. Вообще, финансовый учет и управленческий учет - это далеко не синонимы. Управленческий учет обычно весьма глубоко интегрируется с оперативным учетом, использует оперативную информацию для принятия решений, существенная часть которой не имеет вообще никакого отношения к финансам, но тесно связана со спецификой конкретных бизнес-процессов. Вообще, задача получения финансовых данных - это одна из последних, которая должна решаться. До ее решения должны быть решены автоматизации оперативного и бухгалтерского учета. Правда, на стадии их решения должны быть заранее проработано дерево формирования финансовых показателей и бизнес-процессы их формирования. Не может в финансовой системе внезапно появиться информация, которую изначально никто не ввел в систему. Если эти задачи решены качественно, формирование финансовых показателей - это уже "дело техники". Остается только настроить отчеты. Если существует проблема в скорости их формирования, тут уже можно задействовать OLAP, специальные приемы, связанные с копированием оперативной информации в хранилище и т.д. и т.п.
Но у меня сосздалось впечатление (не берусь утвержадть, что оно безошибочное), что основная проблема в Вашей компании в том, что телега поставлена впереди лошади. Вы пытаетесь сформировать финансовые показатели при отсутствии автоматизации операционной деятельности.

Ваша разработка, в моем понимании, это "заплатка". Она позволяет решить какую-то часть проблем, пока акцент находится преимущественно на финансовом учете. Но постепенно и у Вас, и у сотрудников других подразделений, и у руководства возникнет яростное желание решать и другие проблемы. И тогда станет ясно, что заниматься VBA-программированием и "рисованием" форм в Excel - занятие странное, если эти же самые формы уже готовы и поставляются вендором или неким центральным сервисом поддержки. И у Вас, как я вижу, технически грамотного IT-специалиста, возникнет понимание, что собственно разработка некоторого приложения, даже гениального, изящного и великолепного, позволяет достичь состояния счастья лишь кратковременно - на тот период, пока не расползутся видения и требования с теми, какими они были на момент разработки. Когда же выяснится, что скорость изменеия требований существенно превышает скорость собственно разработки, тогда возникнет понимание, что для достижения состояния, близкого к счастью, необходимо все свои мысли концентрировать на поддержке и сопровождении - еще до стадии разработки, еще до стадии проектирования... На самой-самой ранней стадии.

Самописки же кажутся простым и легким решением задачи только до тех пор, пока сама задача кажется некой статической картиной, неким конечным результатом, которого достаточно достичь, и все проблемы автоматом будут решены. Проблема лишь в том, что предоставляемая статичность желаемого результата обманчива. Когда достигается понимание этого факта, тогда возникает понимание, что "правильное" стремление - это не стремление к идеальной картинке в конце тунеля. А стремление к скорости реакции на изменение картинки в конце тунеля... Чем она выше, тем выше внутренний комфорт и ощущение приближения к абсолютному счастью... :)

Два слова о стоимости. Всилу специфики решаемой Вами задачи стоимость имеет смысл рассматривать только в ракурсе Ваших бизнес-заказчиков. То есть, только в пределах того предприятия, на которм Вы работаете. Если Ваша система действительно тесно интегрирована с операционной деятельностью, то она сильно-сильно зависит от специфических для каждого предприятия бизнес-процессов. Для предприятий других отраслей она, скорее всего, вообще не подходит, поскольку ее кастомизация под предприятие другой отрасли наврядли вообще имеет смысл. Для того, чтобы говорить о стоимости для других предприятий вашей отрасли, нужно проводить обследование и более детально вникать в различия бизнес-процессов. Чтобы понять, во что обойдется кастомизация, и до какой степени вообще в продукте учтена возможность существования других бизнес-процессов. Может статься, что для конечного потребителя стоимость кастомизации во много раз превзойдет стоимость приобретения собственно продукта. Как специалист в области финансов, Вы должны понимать, что для потребителя важны общие затраты по проекту (который рассматривается как инвестиционный проект), а их разделение на те или иные составляющие большого значения не имеет. Поэтому нужно оценивать стоимость не продукта (системы) а стоимость его внедрения, соотнеся его с деньгами, которые потенциальные клиенты готовы за его внедрение заплатить. Вычтите расходы на кастомизацию, на выпрямление кувалдочкой кривых бизнес-процессов, на унификацию НСИ и т.п. ... и получите стоимость Вашего продукта. Вполне возможно, что она окажется существенно разной для разных потенциальных потребителей. И это - нормально! :)