GaryaПо сабжу. Если бы я пытался сделать "киллер 1С", то...

1. Сделал бы нечто масштабируемое до-нельзя, с особым упором на быстродействие.

2. С WEB-интерфейсом, причем как для разработки, так и для приложений. С ориентацией на систему WEB-сервисов.

3. С поддержкой ООП. С возможностью наследования храмых в системе объектов их набора атрибутов, правил их ведения, значений по умолчанию для иерархических и древовидных структур. Предусмотрел бы возможность построения отображений иерархических данных в линейные и наоборот по описываемому набору правил их отображения.

4. С поддержкой слоев, за которые ответственны разные уровни разработчиков и кастомизаторов.

5. С автоматической реализованной на системном уровне версионностью и журнализацией всего и вся (в идеале, в т.ч. и программный код).

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

7. Проработал бы маркетинговую стратегию таким образом, чтобы те, кто решит заниматься кастомизацией на базе моей платформы, могли бы поиметь очень неплохой кусок хлеба с двумя слоями масла.

8. Разработал бы серию готовых отраслевых решений. При этом особе внимание уделил бы вопросам развития и сопровождения этих решений. Создал бы соответствующую инфраструктуру (воспользовавшись лучшими практиками из области развития и сопровождения). предусмотрел бы возможность включения в систему развития и сопровождения новых решений, в том числе сторонних разработчиков, для чего бы разработал стандарты/регламенты и типовые лицензионные соглашения, на основе которых сторонние разработчики могли бы воспользоваться данной инфраструктурой для развития/сопровождения своих разработок. Выступил бы в роли гаранта систем, официально включенных в данную систему развития/сопровождения, так что в случае ликвидации или утери интереса к разработке первоначального стороннего разработчика возложил бы ответственность за сопровождение их систем на себя.

9. Вместо понятия "точка актуальности" использовал бы множество подобных "точек", причем для каждого пользователя ТА могла бы быть своя и имела бы роль не более чем "значения по умолчанию" для точки и интервала учетного времени, на котором производится текущая работа. Реализовал бы "закрытие периода" лишь на уровне контроля доступа.

10. Реализовал бы возможность работы "от проводки", "от документа" и в смешанном режиме.

11. Реализовал бы возможность вести неограниченное количество "видов учета" (БУ, НУ, УУ, МСФО, серый и т.д. и т.п) с единой унифицированной структурой данных для любого их количества. С единообразным унифицированным клиентским интерфейсом для просмотра и изменения учетных данных по любому из видов учета.

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

13. Реализовал бы системные средства поддержки логической целостности информации. Которые предуматривали бы на системном уровне "обратимость" операций при попытке удаления/изменения ранее введенной информации путем разработки правил формирования симметричных (аннулирующих, сторнирующих) записей. Предоставил бы возможность автоматического "сторнирования"/"аннулирования" одних записей другими.

14. Разделил бы объекты по статусам их готовности как минимум на "черновики" (или "заготовки") и "беловики" (для некоторых объектов требуется более сложная система статусов).

15. Включил бы в систему мощную поддержку бизнес-процессов и "длинных транзакций" с возможностью встроенных средств настройки бизнес-процессов, их мониторинга и их изменения "на ходу". Средства версионирования должны обеспечить непротиворечивость структуре данных ранее запущенных "длинных транзакций" (экземпляров событий бизнес-процесса) текущих данных. По возможности попытался бы все это реализовать с поддержкой последних версий стандартов BPEL и BPMN.

15.а. Включил бы в систему средства, использующие последние достижения СМК. А именно, средства математического моделирования закона распределения, выбора статистических данных, определения сигмы процесса (и других важных параметров процесса), возможности реагировать на события выхода процесса за заранее заданные пределы, выявления "особых причин" (факторов), влияющих на управляемость процесса, применения методов Six Sigma. Предоставил бы стандартные средства Lean и TOC для анализа пропускной способности процессов и выработки решений для ее увеличения.

Вот примерно, навскидку, как говорится, без длительных раздумываний. А после некоторого раздумывания, может быть, еще кое-что добавлю.

Осталось только ответить, а зачем все это нужно? Сделать еще одно недоразумение на свою голову и героически с ним бороться? Нет и не будет универсальных средств, да, и кроме бухучета достаточно задач, где не нужно конкурировать с демпинговыми ценами 1С.

Андрей Ж
IV. "Раз пошла такая пьянка..." не проше ли создать язык программирования бизнес процессов с классами "первичный документ", "проводка", "отчёт" и т.д. с неявным обращениям к хранилищам данных (СУБД)... Вроде-бы новые ЯП "клепаются" за 1-2 года одиночками?

Для классов "первичный документ", "проводка", "отчёт" и тд не нужны никакие новые ЯП. Их уже сейчас можно "наклепать" за 1-2 дня в одиночку