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

Может сложится впечатление, что виновата в такой медлительности платформа 1С Предприятие, либо не достаточно мощный сервер. Это не совсем так, по большей части виновата архитектура используемой конфигурации.

1. Архитектура данных - не продуманная (плохая) архитектура базы данных конфигурации;
2. Ненужная «красота» - использование в интерфейсе не типовых подходов, только ради «красивого» внешнего вида;
3. Одна для всех - попытка разработать универсальную систему учета, со всеми возможными функциями, подходящую всем.

Все это влияет на скорость работы системы, и в конечном итоге тратит не только ресурсы сервера, но и оплачиваемое время работы сотрудников организации.

Складывается впечатление, что это делается намерено, что бы система получилось более тормозной. Иногда другого логического объяснение такой реализации в типовых конфигурациях не возможно найти.

Архитектура базы данных, изначально не продумана, из за чего приходится использовать «костыли» и почти при каждом обновлении конфигурации вызываются тяжелые обработчики по преобразованию таблиц в с данным.

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

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

В итоге в реальных условиях с этим невозможно работать. Особенно сильно этим грешит Управление торговлей + CRM.

Одна и та же информация записывается в базу несколько раз. Особенно много дублирующей информации в регистрах остатков.

Например в Управлении торговлей, информация о складских остатках и заказанных товарах, записывается одновременно в несколько регистров, в разных комбинациях.

Операции записи довольно тяжелые и потребляют значительные ресурсы сервера, и время пользователей на ожидание.

Чем сложнее структура базы данных, тем больше время необходимо на запись данных, и сложнее пользовательский интерфейс.

Если при проектировании, структура данных получается сложной, это признак не правильного решения. Не всегда, но в большинстве случаев.

Например то, что в Управлении торговлей называется «Характеристики номенклатуры», в кавычках потому, что это не характеристики, а по сути отдельные товары, с ценами, остатками и всеми другими свойствами товаров.
Из за них систему пришлось усложнить на столько, что в каждом документы где используются товары пришлось вместо одного делать два поля, Номенклатура + «Характеристика».

Система предназначена в первую очередь для практического применения, поэтому приоритеты следующий:

1. Удобство - интерфейс должен быть удобным для пользователя, что бы сократить время ввода и поиска информации;
2. Скорость - обработка данных, должны быть быстрой, на сколько это возможно, что бы пользователь не терял лишнее время на ожидание;
3. Красивый - по возможности, если это не в ущерб первым двум требованиям.

По какому принципу сделаны типовые конфигурации:

1. Красивый - главное, что бы интерфейс эффектно выглядел, так проще продать систему;
2. Удобство - по возможности, если это в ущерб красоте.

И все! Пункта Скорость нет вообще! Это не учитывается главное, что бы было красиво!

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

В итоге получаем:

1. Нестандартные интерфейсы. Использование не стандартных приемов в пользовательском интерфейсе, ради «красоты»;
2. Перегруженные формы. Формы редактирования справочников, документов и других объектов данных, перегружены дополнительной информацией, которая загружается каждый раз при открытии объекта на редактирование, но в большинстве случаев не нужна пользователю;
3. Использование не по назначению. В систему, цель которой ведение учета на предприятии, добавляют функции, которые реализованы отдельным программным обеспечением, при чем более удобно и функционально.

Платформа 1С Предприятия позволяет генерировать формы динамически, что полезно в некоторых случаях, когда нет другого решения. Но использования ради сомнительной «красоты» не приемлемо, каждый раз при открытии формы какой того объекта на редактирования, вызываются функции генерации интерфейса, которые работают более медленно, чем если бы интерфейс был построен на встроенных функциях платформы.

Местами это доведено до абсурда. Например на форме используются закладки, для чего есть готовые элемент формы, с закладками. Вместо того, что бы использовать готовый, на форме размещают несколько текстовых полей в видел гиперссылок и пишут свой обработчик смены закладок, при чем с обращением к серверу, каждый раз когда пользователь выбирает закладку! Зачем? Суть остается та же, только тратится больше времени на обработку.

Пример в Управлении торговлей зачем то сделали службу чтения RSS новостей. Зачем? Если пользователя понадобится читать новости, он может установить отдельный RSS клиент, а возможно он у него уже есть.

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

Для разработки и поддержки проще создать одну универсальную систему, вместо нескольких более узконаправленных, но плохо для оптимальности работы и для работы пользователей системы. Но проблемы пользователей, это их проблемы, систему уже купили, а альтернативы все равно нет.

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

В итоге получаем:

1. Избыточные данные. Большое количество объектов, предусмотренных в базе данных системы, никогда не используются пользователями;
2. Избыточные функции, отключенные и в большинстве случаев никогда не используются пользователям.