Уважаемые, крайне сильно интересует следующие вопросы:
1. Целесообразно ли использование 1с в качестве Ядра для разработки информационно-аналитического модуля (что то типа диспетчерской) ?
2. Имеются ли какие либо подводные камни в данном решениии (особенности проектирования либо реализации) ?

Причины по которой рассматривается данное решение, это особенности (а точнее хреновины, которые наворочены в текущей ИС):
1. Сейчас используем C# + Oracle для подобной задачи - стоимость лицензирования просто не укладываеться в головах у заказчиков - поэтому все пиратское.
2. Система по сути состоит из 40 форм для ввода информации, несколких десятков внешних справочников (dbf до 3 млн. записей), и порядка 100 отчетов.
3. Основное требования - по возможности стандартизированный интерфейс (windows-style) и максимально быстрый отклик на действия пользователя.
4. На оракле крутится БД под 2Gb (+3Gb - загруженные внешние справочники)
5. Ядро на котором идет разработка - является унылым г... разрабатывается крайне не адекватной аутсорсинговой компанией из 2 человек.
6. Очень долго и сложно приходиться писать формы + бд для решения простейших задач (даже delphi по скорости значительно быстрее).

Стоимость лицензий 1с+PostgreSQL вполне бы устроила всех.

PS в 1С до этого ранее не работал, пока купил комплект разработчика, думаю стоит ли более углубленно прорабатывать данный вариант?

Постараюсь ответить развернуто

По поводу программы и ее работы:
1. Сверх сложных отчетов нет (в том смысле что нет динамических OLAP, большинство отчетов идет по фиксированным параметрам, есть около 10 тяжелых (которые формируються порядка суток)). некоторые конкуренты на наших данных самые тяжелые отчеты переписывали и формировали за минуты.
2. По поводу внешних справочников. Для этого надо описать основной бизнес процесс

К диспетчеру обращается потребитель услуги.
У диспетчера есть ИС, через которую он:
1. находит данного потребителя (поиск по фио, время отклика 1 сек) либо его заводит (2 минуты, 40 полей). база потребителей порядка 500 тыс.человек.
1.1 при заведении информации некоторые данные проверяются по информации поступившей из государственных учреждений (информация приходит в виде dbf) - например паспортный стол, кладр, государственный реестр предприятий. (в настоящее время мы информацию заливаем в наш оракл как есть = чтобы просто было удобнее ее искать).
2. диспетчер определяет оборудование, на котором можно выполнить заказ (нужен график работы) и формирует заказ на выполнение услуги.
3. потребитель получает услугу.
4. по факту оказания услуги формируется информация о реальной себестоимости, реальной загрузке оборудования, в общем управленческий учет.

По поводу целей:
1. В настоящее время идет по сути разработка\доработка ИС, которая не будет удовлетворять клиента не по быстродействию, не по скорости реализации хотелок, не по стоимости владения (прежде всего лицензии).
2. Я вижу данную проблему и так как с руководством отношения последнее время напряженные (а в частности увольняюсь в течении 2-х недель) решил посмотреть - каким образом задачу клиентов можно решить гораздо эффективнее (для создания компании-конкурента и захвата рынка).

По нагрузке:
1. диспетчеров на одну базу приходится порядка 15, которые в 70% времени ищут информацию - 30% вносят.
2. есть аналитики - которые формируют отчеты (порядка 4 человек), или перераспределяют нагрузку на оборудование (ручками).
3. отчеты нужны (ежесуточно)
4. первый приоритет - недопущение накладок по графику работы оборудования, второй приоритет - максимально быстрое обслуживание клиента, третий приоритет - верный ввод информации (правила проверки корректируются каждые 2 недели, так как вводятся более глубокие методы контроля частных ситуаций, в основном связанно со спецификой оборудования и проведения работ)- тоесть до конца формализовать информацию не удается.

mista2009
тяжелые отчеты - это просто профуки программистов (как в истории про "банку с краской"), как я уже выше писал - у конкурентов на нашей же базе в делфи отчет формируется в течении минут...

VoditelKobyly
писать пока не пробовал - формализую как могу, повторно перечитываю руководства на текущую систему и систему конкурентов.
паралельно собираю дампы с обьектов (с реальным обьемом информации).
ну и конечно же пролистываю руководства программиста 1с пока без тыканья кнопок (чтобы просто определить основной подход к разработке и пути изучения).