Как заставить 1С работать хорошо на примере одного кейса.

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

Нас познакомили с этой компанией наши партнеры – компания занимающая  поддержкой IT - инфраструктуры, причем на наш взгляд, довольно качественно. 

Для оперативного учета давно использовалась сильно кастомизированная(измененная еще до нас) 1С УПП.

Нашими задачами являлись: поддержка пользователей, решение всех проблем связанных с 1С, постоянная доработка системы связанная с активным развитием бизнеса, реализация идей топ-менеджеров компании.

Порядка восьмидесяти менеджеров по продажам каждое утро активно оформляют заказы. При оформлении заказа, товар на складе резервируется – это стандартный функционал УПП.

Менеджеры   формируют заказы так: создают новый документ «Заказ покупателя» выбирают там нужного клиента,  созваниваются с клиентом, получают от него информацию о том, что ему нужно, уточняют наличие нужного товара, глядя на  форму подбора заказа, при  отсутствии нужного товара на складе, предлагают аналоги. В конце концов, они нажимают «ОК», заказ проводится и закрывается.

Среднее количество позиций в заказе – около сотни.

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

Вскоре после начала нашей работы с клиентом, нам поступила жалоба, о том, что система «тормозит», причем это происходит уже давно, с этим мирились, но с ростом бизнеса проблема усугубляется. Тормозит, так, что это сильно мешает работе менеджеров по продажам: при каждом изменении заказа, например, добавлении новой позиции,  система зависала секунд на 20 - 30, а то и на несколько минут. При этом клиент висит на телефоне и нервничает (и в итоге  покупает меньше чем мог бы), а менеджер по продажам не может заниматься другими клиентами.

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

Компания, занимающаяся IT-поддержкой, предоставила нам информацию о своих действиях по решению проблемы, из которой было понятно, что все что могли  они сделали и проанализировали. Конфигурация «железа» так же была достаточно адекватной для данных параметров, даже с некоторым запасом, при этом «железо» не очень давно обновляли. Руководство компании в принципе было готово вложиться в более мощное «железо», но ожидало от нас с ITишниками долгосрочного и оптимального решения.

Мы начали анализировать ситуацию со стороны 1С.

Довольно скоро проблемное место было обнаружено: 

Среди прочих изменений типовой конфигурации, которые были сделаны до нас, было следующее:

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

Таким образом, при количестве позиций в заказе – 100, проведение заказа запускается как минимум 100 раз. То есть в сто раз больше чем при типовом поведении программы. А, как мы помним, делают это одновременно 80 человек.

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

Дело в том, что заказ на 100 позиций по телефону принимается достаточно долго. Если использовать типовую версию, менеджер при проведении заказа сталкивается с ситуацией, когда товар, который в момент подбора был в свободном остатке в момент подбора, уже зарезервирован другим менеджером. Это приводит к тому, что заказ нужно формировать заново, причем без каких-либо гарантий успеха.

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

Наша задача состояла в том, чтобы устранить критическую проблему, не создав новых.

И мы с ней успешно справились:

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

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

 

К решению подобных задач необходимо подходить комплексно, задействуя системных администраторов, специалистов по 1С, анализируя бизнес логику. Решения могут быть найдены  с разных сторон, в нашем примере, альтернативы могли бы быть, например, такие:

1.       Со стороны системных администраторов – увеличить производительность «железа», операционных систем и т.п.

2.       Со стороны бизнеса: увеличить запас складских остатков, так чтобы не было дефицита

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

Однако оптимальное решение учитывает все возможности и интересы.

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

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

Матвейчук Константин