В предыдущей статье мы рассказали почему 1С может тормозить. А сейчас хотим поделиться с вами интересным случаем, с которым столкнулись на практике.
О клиенте
- Компания занимается оптовой торговлей;
- Работает в УПП (1С:Управление производственным предприятием);
- Программа была сильно доработана другими специалистами 1С до нас;
- В наши обязанности входило: поддержка пользователей, регулярная доработка программы в связи с активным развитием бизнеса, реализация идей руководства компании;
Проблема
Спустя некоторое время, после начала сотрудничества с клиентом, нам поступила жалоба, о том, что 1С «тормозит», причем, проблема существует уже давно, с ней мирились, но с ростом бизнеса ситуация усугубилась.
Работа менеджеров по продажам, которые принимают заказы у клиентов, бала фактически парализована из-за медленной работы программы. Как вы сами понимаете: нет продаж - нет прибыли. Поэтому вопрос о решении проблемы стоял весьма остро.
Кстати, о менеджерах...
Каждое утро около восьмидесяти менеджеров по продажам активно оформляют заказы. При оформлении заказа, товар на складе резервируется. Популярный товар обычно в дефиците, поэтому менеджеры конкурируют за него между собой .
Менеджеры оформляют заказы следующим образом:
- Создают в 1С новый документ «Заказ покупателя» и выбирают там клиента.
- Созваниваются с ним.
- По телефону получают информацию о том, что ему нужно.
- Уточняют наличие нужного товара, глядя на форму подбора заказа.
- При отсутствии нужного товара на складе, предлагают аналоги.
- Нажимают «ОК», заказ проводится и закрывается.
- Прощаются с клиентом.
Вернемся к нашей проблеме.
При каждом изменении заказа, например, добавлении новой позиции, программа зависала секунд на 30, а то и больше. Среднее количество позиций в заказе – около сотни. Клиент висит на проводе и нервничает (и в итоге покупает меньше чем мог бы), а менеджер по продажам не может заниматься другими клиентами.
Может нужно проапгрейдить сервер?
Компания, занимающаяся IT-поддержкой, рассказала нам о своих действиях по решению этой проблемы.
Стало понятно, они сделали все, что смогли. Конфигурация «железа» была адекватной, был даже некоторый "запас", при этом, «железо» недавно обновляли.
Несмотря на это, руководство компании было готово вложиться в более мощное «железо», но ожидало от нас с ITшниками долгосрочного и оптимального решения.
Корень всех бед найден!
Мы обратили внимание на любопытную доработку в 1С:
При каждом добавлении или изменении какой-либо позиции в документе «Заказ покупателя» , он автоматически проводился.
Важно понимать, что проведение заказа покупателя – это тяжеловесная процедура, при ней происходит анализ остатков, резервов, заказов, взаиморасчетов с клиентом, запись в десяток таблиц в режиме блокировки.
Если количестве позиций в заказе – 100, проведение заказа запускается как минимум 100 раз. То есть в сто раз больше чем при типовом поведении программы. А теперь представьте, что это делают одновременно 80 человек.
Как делать не надо.
Первая мысль, которая приходить в голову в этой ситуации – отключить этот код и вернуть поведение программы к типовому варианту.
Наша работа во многом похожа на работу врача. Один из главных принципов - "помоги и не навреди". Поэтому вот так "рубить с плеча" - неправильно. Сперва нужно выяснить для чего вообще сделали такую доработку.
«Это ж-ж-ж неспроста»
Все оказалось просто - заказ на 100 позиций долго принимается по телефону.
Если использовать типовую версию программы (без доработки), то менеджер может столкнуться с тем, что товар, который в момент подбора был в свободном остатке, уже зарезервирован другим менеджером.
А из-за этого приходится формировать заказ заново. Причем, не факт, что ситуация не повторится.
Доработка, обнаруженная нами, решала задачу быстро и дешево. Возможно, что в то время когда ее только сделали, это было адекватным решением (заказы были меньше, менеджеров было немного).
При решении бизнес задач, архитектор 1С должен думать наперед, предугадывать возможные варианты развития событий и возможные проблемы.
К сожалению, выбранное "нашими предшественниками" решение привело к серьезным проблемам с производительностью в будущем.
Решение
Мы реализовали механизм, формирующий записи в нужный регистр без проведения документов и удаляющий их при закрытии формы заказа, а также регламентно, на случай аварийного закрытия программы.
Таким образом, мы сократили количество тяжеловесных проведений заказов примерно в сто раз, и проблема с производительностью была решена, сохранив, при этом, функциональность программы.
P.S.
К решению подобных задач необходимо подходить комплексно: привлекать специалистов 1С, системных администраторов, анализировать бизнес-логику.
Что интересно - решения могут быть найдены с разных сторон, например:
- Со стороны системных администраторов – увеличить производительность «железа», операционных систем и т.д.
- Со стороны бизнеса - увеличить запас складских остатков, так чтобы не было дефицита
- Со стороны отдела продаж - разбивать заказы на более мелкие, поделить товары между менеджерами так, чтобы только несколько менеджеров занималось конкретной позицией.
Однако, оптимальное решение учитывает все возможности и интересы.