Ускорение работы пользователей 1с
Разработки

Практика контроля заказа

В одном проекте один заказчик очень долго разрабатывал систему вместе с разработчиком. Складывался воедино весь функционал. Находились противоречия в формировании прайсов, работы с заказами. В целом, потратили целый год. И вот, когда пришла пора отдавать в работу пользователям, то выяснилось, что система настолько стала громоздкой, что просто нереально объяснить пользователям, как с ней работать.
 
Заранее стало видно, что это не облегчит ведение учета, а только ухудшит в разы. Да, все разрабатывалось во благо. Конечная цель понятна, но чтобы выполнить все требования, то придется увеличивать персонал в два раза (?), чтобы все эти данные в базе были заполнены.
 

Это уже не автоматизация,

а работа ради работы,

процесс ради процесса…

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

«Самый медлительный человек, не теряющий из виду своей цели, все же проворнее того, кто блуждает без цели»
Г. Лессинг

 


Пример из практики

 
 
В одном предприятии производится работа по работе с заказами физических лиц. Материал для изготовления в некоторых случаях отсутствовал на складе исполнителя. Его приходится заказывать у поставщика (распространенный пример) и приходит он в течение от одного дня до месяца. Далее после прихода материала на центральный склад он отправлялся на розничную точку, в ней проверялся и передавался в мастерскую. После изготовления заказ отправлялся вместо выдачи заказов. Происходила выдача заказа. Теперь давайте посмотрим, сколько бизнес-процессов в данном случае возникает.
 
 
 
 Маршрут документов по работе с заказами покупателей: 
  1. Документ «Заказ покупателя»  — формируется количество заказанного товара, предварительно или полностью считается сумма заказа. Принимается предоплата. Заказанный товар, что был в наличии, откладывается в пакет в режим ожидания. Это все отдельный процесс. Все нормально.
  2. На основании заказа покупателя формируется документ «Заказ поставщику». 
  3. На основании «Заказа поставщику» формируется электронное письмо и отправляется поставщику. Происходит все автоматически при нажатии в документе заказа поставщику по гиперссылке. Здесь все правильно  — отправка электронного письма это отдельный документ.
  4. «Поступление товаров от поставщика»  — приходуем товар на центральный склад. Здесь проверяем документы от поставщика, проводим по бухгалтерии, отражаем в управленческом учете. Стандартное действие. Присутствует централизованное поступление товаров от поставщика, когда приходят выполненные заказы поставщикам со всех розничных точек. 
  5. «Перемещение товара» на склады розничных точек – создание группового распределения материалов, с контролем по невыполненным заказам покупателей.
  6. Далее на розничной точке осуществляется приемка и проверка продавцом-консультантом принятого товара, чтобы было все в комплекте в наличии. 
  7. По-существу производится доукомплектация комплекта через документ «Комплектация» принятыми товарами из п.5, а стало быть, товар списывается с розничной точки.
  8. После чего формируется перемещение всего комплекта в мастерскую. 
  9. Выполнена работа мастером. Документ «Акт выполненной работы». Комплект со статусом «изготовлен» перемещается в пункт выдачи заказов.
  10. Документ «Выдача заказа покупателю»  — это отдельный документ, так как разрыв между принятием заказа и выдачей сильно отличается по времени. Если это тот же день, то выдача осуществляется прямо в документе «Заказ покупателя». 



А теперь давайте прорисуем данную схему. У нас получится в цепочке 10 отдельных документов. Десять!

В момент запуска данной системы возникла трудность в освоении данной системы. Трудность в том, что в программе не было четко видно, что зачем идет и на какой точке маршрута находится сейчас данный заказ. Конечно, скажете сейчас, что достаточно сделать отчет «Анализ заказа» и все будет видно. Так-то, оно так. Мы отчет и сделали. Это первое, что пришло в стандартном решении. И это не помогло. Люди не понимали. Ведь им приходилось делать все эти десять документов все равно.

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

В общем целом мы определили некоторую связь между несколькими звеньями. Если бы это были разные люди и сидели поодаль друг от друга, то конечно они бы только работали именно с этими операциями и знали бы конкретный свой участок ответственности. А здесь возникло так, что несколько звеньев (а вернее все!) делает один и тот же человек и он не понимает, почему так усложняется процесс простой работы с заказами?
 

 

 
 

Вот как, скажите на милость, это взять и реализовать типовыми решениями?
 


Как упростить документооборот?

 
Можно было бы конечно создать обработку, где это можно было бы соединить воедино. И это правильно. Мы же решили это сделать так, чтобы пункты 7, 8, 9, 10 делались через один документ, а также пункт 1 и 2 объединить. Правильное ли это решение? По-сути, конфигурация, сильно доработанная, и это было легче сделать, чтобы исключить многие ошибки. Так или иначе, все равно требовалась сильная доработка всех документов по маршруту. 

 


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

Далее по пунктам 7-8-9-10 был создан новый один (!) документ, который стал делать доукомплектацию комплекта, передачу мастеру, возврат готовых заказов от мастера и выдачу заказов покупателю. При этом не забудем упомянуть очень важный момент. Это все делается через один документ за всю смену работы!

По маршруту видно, что нужно делать по каждому заказу в отдельности доукомплектацию, выдачу заказчику. И именно это было камнем преткновения. А теперь все в одном документе. Уменьшение электронного документооборота просто снизился в десятки раз. Если ранее 30-50 заказов доукомплектовывали, 2-10 документов передача-приемка мастеру, 30-50 выдачи заказов. То теперь это 1-2 документа.

 



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

 
 

 

Вывод

 
Главный результат для любого проекта – чтобы разработанный функционал стал работать в руках пользователей. Чтобы это работало!
 
Не всегда нужно именно так поступать, как здесь описано в нашем примере. Нужно весь бизнес-процесс представлять себе в целом, а не только в каждой отдельной цепочке. И уже тем более не ограничивать себя типовым функционалом, который присутствует в конфигурации. Была бы конфигурация управление торговлей 10.3 (УТ) или управление производственным предприятием 1.3 (УПП), то, возможно, мы бы стали использовать стандартные документы и выстраивали взаимосвязь через какую-то обработку. Пришлось бы конечно сильно потрудиться. В целом пришлось бы делать так, чтобы данные вводились в обработке, а сохранялось во множество документов, не заходя в них вовнутрь. Такие варианты работы у нас тоже используются. Но результатом всего этого проекта  — функционал был отдан в руки пользователей и они стали эти процессы вести в программе.
 
Нравится 0 Не нравится
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо зайти на сайт под своим именем.
Добавить комментарий
Ваше имя: *
Ваш e-mail: *
Вопрос: Юзабилити - это удобство работы в программе?
Ответ:
Код: Кликните на изображение чтобы обновить код, если он неразборчив
Введите код: