Боль планирования в 1С

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

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

Статья написана, в основном, про УПП. Часть проблем удалось снять в ERP (заодно добавив новых), но боль осталась и по сей день.

Итак, поехали.

Обеспеченность

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

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

Я, как наверняка и вы, такой отчет делал. Для грубого ответа на поставленный вопрос отчет вполне сгодится, но кому нужен грубый ответ? У людей же бизнес, от ответа на вопрос зависит расход денег, неликвиды, кассовые разрывы, отношения с покупателями.

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

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

Потом происходит очередной кошмар – меняется бизнес-процесс, заодно и штатная структура, подразделения перемешиваются, складов становится вдвое больше, появляются планы производства, придумывается новый документ типа «Заявка покупателя», который предшествует заказу покупателя и т.д. Короче, причин для смерти Отчета становится столько, что он перестает сопротивляться.

Помощник планирования

Часть вопросов расчета обеспеченности в УПП решает «Помощник планирования». Я раньше очень любил этот инструмент, в него заложены классные идеи и подходы. Но, увы, он так и остался прототипом для решения реальных задач бизнеса. Долго рассказывать по дедушку-помощника не буду, при желании вы без труда найдете массу информации про его ограничения (бутылочное горлышко, например).

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

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

Резервирование и размещение

В определенный момент я обратил внимание на резервирование (на складах) и размещение (в заказах поставщикам и внутренних заказах). Вот оно, казалось бы, то что мне и надо! Резервирование дает однозначный ответ на главный вопрос – за счет чего обеспечена потребность. Там прям написано – железяку с этого склада возьми и иди с миром, а деревяшка приедет через неделю от поставщика по заказу № 23123.

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

Мелькнула надежда в виде документа «Резервирование товаров» - он ведь позволяет за один присест провести корректировку всех резервов. Освободить, перенести, занять более актуальные ресурсы – т.е. нивелирует все недостатки, описанные выше

Надежда продержалась долго, даже переросла в несколько проектов. Я, а наверняка и вы, делали такие штуковины, типа автопересчета резервов или большого АРМ по управлению резервами, чтобы Большой Диспетчер мог перекидывать резервы туда-сюда, снимать и ставить, учитывая потребности и все изменения реальной жизни. Манипуляции этого человека легко укладываются в документ «Резервирование товаров», с  точки зрения программиста он просто прекрасен – почти прямая запись в регистры идет.

Но и тут не все гладко. Проблемы с последовательностью остались на месте, т.к. изменение документа потребности или резерва задним числом точно также может увести регистр резервов в минус. Большой Диспетчер уже не может полагаться на данные, которые постоянно меняются. Он только что распределил резервы, через минуту заходит в свой АРМ, и видит, что раздал несуществующие ресурсы (а по наивности еще и позвонил людям и чего-то наобещал).

Плюс тот же недостаток, что и в помощнике планирования – резервированием, в т.ч. АРМом, нужно постоянно пользоваться. Заходить в него, следить за ним, чего-то нажимать. Большой Диспетчер, опять же, нужен.

Самое поганое, что резервирование, как таковое, мне не было нужно. Я просто хотел узнать, что у меня обеспечено, чем оно обеспечено, а чего мне не хватает. А резервирование – это «мое, не трогать!», т.е. целый бизнес-процесс. Который, к тому же, на производственных предприятиях любят нарушать ребята на складе (где нет крутых WMS-систем). Был такой один, душой болел за производство, и при поступлении дефицитных деталей просто прятал их в уголок, «чтобы треклятые продавцы не забрали». Какое уж тут резервирование.

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

А ведь я просто хочу узнать, что у меня обеспечено, чем обеспечено, и что надо купить.

Аналоги

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

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

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

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

В реальной жизни учет аналогов, конечно, сложнее.

Например, заменяемость может зависеть от клиента – одному подходит разная сталь, другому кровь из носу надо 40Х. Одному подходит сделанная в Китае, другой – патриот.

Но и это все – простые случаи, когда аналоги связаны один к одному.

Бывает и сложнее. Например, когда делают упаковку полимерную, берут пленку подходящей ширины. Если клиент заказал рулон упаковки шириной 1000 мм, мы берем ширину 1100 мм, срезаем по краям по 50 мм (чтоб ровненько было), и все счастливы. Но сложилась ситуация, когда у нас нет пленки шириной 1100, а есть 1105 мм. Мы, конечно, не паримся и берем ее – просто отходов будет чуть больше. А можем взять 1110 мм, можем 1115 мм, можем даже 1300 взять, если горящий заказ и клиент из любимых.

Получается сложносочиненная формула расчета аналога. Каждая пленка – отдельная номенклатура, т.е. сочетаний для каждой пленки будут десятки. Но применимость сочетаний аналогов зависит от контекста – ширины изделия, которую нам надо получить. Добавим сюда, что пленки одной ширины бывают разными по своим свойствам, но могут заменять друг друга при определенных условиях. А еще рулон шириной 1000 мм можно разрезать пополам, чтобы выполнить заказ, где требуется ширина 450 мм. А еще его на три части можно порезать, и не обязательно одинаковые.

Короче, ад адский. А хочется, чтобы это как-то учитывалось, и ответ на вопрос «обеспечены мы или нет?» система дала.

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

Гибкость

Точнее, не гибкость, а ее отсутствие. Я, наверное как и вы, много раз слышал фразу – надо не 1С подстраивать под свои процессы, а свои процессы под 1С. Когда работал во франче, сам любил этот лозунг повторять клиентам.

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

Я к УПП очень хорошо отношусь, но решение для планирования выбирать-то в ней особо не из чего. Это даже не гибкость, а Великое Ничто, вакуум, поле чистое. Можно же утверждать, что Ничто – гибкое? Конечно. В этом и прелесть УПП, за это его и люблю, особенно в части планирования – делай что хочешь, хуже не будет.

Например, приделать к УПП закуп по методу ББВ (барабан-буфер-веревка) – задача несложная, даже обычным программированием, безо всяких там универсальных инструментов. И ничего в системе испортить невозможно своими доработками, т.к. работа-то в Великом Ничто делается. Это как ядерную бомбу на полпути от Марса до Венеры взорвать – солнечная система ничего не заметит.

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

Тем не менее, начинание полезное, есть из чего выбрать. Я пообщался с разработчиками, задал им вопросы о своей боли, получил неутешительные ответы – боль этой таблеткой не лечится. Отчета по обеспеченности нет, аналогов нет, добавлять или изменять способы обеспечения – только через конфигуратор, учесть в схемах обеспечения свои объекты метаданных не получится.

Не знаю, как вам, а мне в таком сравнении ближе Великое Ничто.

Свои объекты метаданных

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

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

Если добавлен не прям объект, а реквизит, например, то еще куда ни шло – он хотя бы в отборе помощника планирования появится.

В контексте самодельных объектов даже хорошо, что в 1С такое планирование. Представьте себе, было бы оно как РАУЗ – цельное, проверенное, работающее, самодостаточное. Многие из нас рисковали жизнью, добавляя вообще совершенно новый документ движения товаров, и включали его во все цепочки РАУЗ? Или добавляли реквизиты в номенклатуру, которые бы влияли на решение СЛАУ? А планирование не такое – ему без разницы, что вы куда добавили, все равно мимо пройдет.

Резюме

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

После этой фразы я полюбил планирование, как класс задач.

С одной стороны, фраза избавляет 1С (и вообще любого разработчика) от необходимости изготавливать типовое решение.

С другой стороны, фраза окрылят внедренца – давай, действуй, на этом поле нет законов, правил, правильных и не правильных решений! Твори!

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

И все из-за этой фразы. Твори, каждый раз твори, потому что типового решения нет.

Потом только дошло, что фраза неправильная, недосказанная, упущено в ней что-то.

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

Но не пользователями едиными внедрения богаты, там есть еще и программисты 1С. Пользователь – он же только на кнопки нажимать умеет, да и то ошибается все время. Программист же – и код напишет, и схему компоновки, и схемы хранения данных знает, и метаданные видит, и цель планирования знает, и процессы знает… Понимаете?

Типового решения задачи планирования для пользователя – нет, а для программиста – есть. Должно быть типовое решение задачи планирования для программиста. Инструмент,

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

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

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

Конвертация почти полностью удовлетворяет критериям, которые я предъявил системе планирования:

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

* - вот только тут неправда, программировать в конвертации обычно приходится. Но есть и масса примеров, когда не приходится.

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

Еще стоит упомянуть Бюджетирование в УПП. Это система, позволяющая собрать любые данные из системы с помощью запросов, и построить из них бюджетное планирование. Прямо из коробки обычно не работает, но если посадить программиста за настройку, то позитивный результат можно получить достаточно быстро.

Вдогонку упомяну инструмент, который лично мне показался правильным – Монитор ERP. Цель инструмента многогранна, но в то же время очень проста – дать информацию о бизнесе в правильном виде. Главное – в мониторе ERP можно писать схемы компоновки, определять свои показатели, правила их расчета и контроля. Разумеется, этого не сделает пользователь, хотя попытка сделать интерфейс настройки для пользователя предпринята – есть предопределенные показатели, стратегии, цели. Посади программиста с правильной постановкой задачи – он сделает шикарную систему контроллинга для предприятия.

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

Типовые конфигурации 1С – они, вроде, для «учета и управления». Основа управления – план и контроллинг. Контроллинг худо-бедно построить можно. Построить правильное, современное планирование, умеющее быстро реагировать на изменение среды, учитывающее особенности российского подхода к учету,  – практически невозможно.

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

Все изложенное является личным мнением автора, разумеется.

P.S. Ну и от себя спрошу, очень интересно, может знаете – а кто принимал решения, как инструмент в УПП или ERP делать правильным, а какой – неправильным? Почему бюджетирование – правильное, а планирование – неправильное