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

26.10.17

Функциональные - Бюджетирование и планирование

Что не так с планированием в 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 делать правильным, а какой – неправильным? Почему бюджетирование – правильное, а планирование – неправильное

См. также

SALE! 20%

Автоматический заказ поставщику в 1С: загрузка прайсов и анализ цен поставщиков для УТ 10.3, УТ 11, КА2, УНФ, УПП, ERP, Розница 2

Бюджетирование и планирование Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Анализ продаж Платформа 1С v7.7 Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

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

28500 22800 руб.

21.04.2017    90178    105    39    

190

ФинОфис - контроль и управление финансами

Бюджетирование и планирование Управляемые формы Конфигурации 1cv8 Россия Управленческий учет Платные (руб)

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

20000 руб.

20.12.2017    49528    14    7    

85

ФинОфис (модуль Казначей)

Бюджетирование и планирование Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

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

25000 руб.

10.04.2020    21186    10    12    

35

ФинОфис (модуль Табула)

Бюджетирование и планирование Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

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

25000 руб.

26.02.2019    96789    84    106    

217

ФинОфис (модуль Консолидатор)

Бюджетирование и планирование Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

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

25000 руб.

19.11.2019    25355    16    2    

38

ФинОфис (модуль Процессы)

Управление бизнес-процессами (BPMS) Бюджетирование и планирование Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Процессы – это конструктор бизнес-процессов и маршрутов согласования. Модуль встраивается в конфигурации 1С.

25000 руб.

10.04.2020    27044    3    4    

22

Вебинар-практикум "Управление IT-бюджетом" 27 марта 2024 г.

Бюджетирование и планирование Управление проектами Управление ИТ-департаментом Платные (руб)

Рассмотрим полный жизненный цикл IT-бюджета в компании, от планирования до анализа исполнения и корректировки бюджета. Дадим готовые шаблоны, которые помогут контролировать и оценивать бюджет на IT-проекты.

7400 руб.

06.03.2024    610    1    0    

1
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
153. 1c-intelligence 12771 19.11.17 22:55 Сейчас в теме
(150) экстраполировать как раз получилось, на тысячу лет назад, когда в центральной Америке жили индейцы языковой группы "нахуа".
Несложно инженера нагрузить такой проблемой - придумай систему, которая будет высчитывать, какой заказ выгоднее взять, от какого отказаться, ну и т.д. В 2006 году, как помню, такую делал - типа составление производственной программы в условиях дефицита мощностей, с оптимизацией по прибыли, загрузке и выручке. Даже ссылку нашел, ищите по словосочетанию "Конструктор планов".
Но это все не то, по крайней мере в рамках ТОС. Это не правильный вопрос, который порождает неправильный ответ. Пока мы думаем, от какого заказа отказываться и как это вычислить, мы не думаем, как сделать так, чтобы делать все заказы.
156. genayo 20.11.17 07:50 Сейчас в теме
(153) Чтобы делать все заказы, нужно:

а) Чтобы все заказы на входе были выгодны финансово.
б) На производстве все оборудование с бесконечным ресурсом.

Вы явно не это имели в виду, а что тогда, поясните?
158. 1c-intelligence 12771 20.11.17 08:13 Сейчас в теме
(156) я имел в виду, что прежде, чем заняться интересной инженерной задачей, надо задуматься - нафига ее решать.
Потому что инженеров мало, времени у них мало, и грузить их бесполезными задачами - вредно. Потому что они полезными не будут заниматься.

Решать задачу "как в текущих условиях, ничего не меняя, манипулировать заказами (какие брать, какие не брать, как их передвигать)" - вредно.

Решать задачу "как изменить текущие условия, чтобы не надо было манипулировать заказами" - полезно.

Вот что я имел в виду.

Инженерный, или программистский ум, к сожалению, больше любит задачи наподобие приведенной вами. Понять контекст, и внутри контекста что-нибудь замутить. Но не выходит за рамки контекста. Вероятно, это из-за платформы 1С, которая живет своей жизнью и задает контекст.
159. genayo 20.11.17 08:33 Сейчас в теме
(158) Непонятно, почему вы противопоставляете эти задачи. На мой взгляд, эти задачи взаимосвязаны, и одну без другой решить не получится.
161. 1c-intelligence 12771 20.11.17 21:19 Сейчас в теме
(159) они взаимосвязаны умозрительно. Нам хочется, чтобы они были взаимосвязаны, чтобы не казалось, что мы ерундой занимаемся.

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

Задача - это когда кто-то сказал "надо сделать вот так". Она должна проистекать из цели, вы это знаете - это называется декомпозиция. В скраме, например, такой декомпозицией занимается владелец продукта.

Если вы - владелец продукта, то ок. Вы решили, что надо возиться с выбором заказов, и это приведет к цели. Это ваша ответственность. И спрашивать вас будут не за решение задачи, а за достижение цели. Тут все понятно, можно развлекаться, пока не выгонят.

Если вы - исполнитель, то тоже ок. Вы просто делаете, что вам сказали. Ваша ответственность - исполнение. Достигнута цель или нет - вас не касается, на то есть владелец продукта.

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

Поэтому противопоставляю. Мне интереснее цель, а не задача.
163. genayo 20.11.17 21:44 Сейчас в теме
(161) А кто сказал, что этими задачами должны заниматься одни и те-же люди? Или мы рассматриваем предприятия, где ровно 1 постановщик задач и 1 программист?
164. 1c-intelligence 12771 20.11.17 21:47 Сейчас в теме
(163) я говорю конкретно про вас и меня. Остальные - абстракция в нашем разговоре. Ну и вряд ли от них толк будет в постановке задач подобного рода.
166. genayo 20.11.17 21:54 Сейчас в теме
(164) Утерял мысль. Вроде, тема была о том, на какие вопросы должен давать ответы качественный инструмент планирования. Если же ваша тема в том, что традиционное планирование не нужно, тогда о чем статья с примером про обеспечение?
168. 1c-intelligence 12771 20.11.17 22:37 Сейчас в теме
(166) разговор можем прекратить в любой момент, когда надоест.
Обеспечение - это базовая задача планирования, и она не решена. Вот о чем статья.
А тот пример "традиционного планирования", который вы привели - да, на мой взгляд, он не нужен.
Но, разумеется, если уж кто-то поставил такую задачу, и отказаться нельзя, то решать ее будет интересно. Хотя бы для саморазвития.
172. genayo 21.11.17 07:53 Сейчас в теме
(168) Так обеспеченность часть задачи планирования из моего примера, знаем обеспеченность (как материалами, так и ресурсами, в том числе и финансовыми) - можем оценить выгодность и возможность исполнения дополнительного заказа.
174. 1c-intelligence 12771 21.11.17 08:32 Сейчас в теме
(172) чтобы ответить на ваш вопрос, мне уже придется часть следующей статьи рассказать. Давайте продолжим диалог после ее публикации. Ок?
167. genayo 20.11.17 21:59 Сейчас в теме
Что касается конкретики - я сейчас занимаюсь всего лишь снижением уровня потерь склада с 0,1 до 0,05 процентов от оборота, не стратегическое планирование, да...
169. 1c-intelligence 12771 20.11.17 22:38 Сейчас в теме
171. genayo 21.11.17 07:50 Сейчас в теме
(169) Как внутренних - излишки, недостачи, брак, так и внешних - потери от отказа клиентов от товара по вине склада.
173. 1c-intelligence 12771 21.11.17 08:32 Сейчас в теме
(171) какого рода товары? Какова доля в потерях от излишков и недостач?
175. genayo 21.11.17 08:38 Сейчас в теме
(173) Товары - продукты питания, доля в потерях где-то около 0,01%
140. 1c-intelligence 12771 17.11.17 06:47 Сейчас в теме
(138) но вообще ТОС быстрее в торговле приносит результат, об этом сам Голдратт писал в книге "Выбор". Он говорил, что Goldratt Group в первую очередь работает с ритейлерами, менее охотно связывается с производством, и совсем неохотно - с проектами.
143. genayo 17.11.17 07:53 Сейчас в теме
(140) Если брать ритейл, то в Российских реалиях не все так просто. На одной из конференций имел на эту тему небольшой разговор с Еленой Федурко, она высказала мысль, что применение ТОС без участия опытных консультантов может привести совсем к обратным последствиям...
147. 1c-intelligence 12771 19.11.17 21:33 Сейчас в теме
(143)
с Еленой Федурко, она высказала мысль, что применение ТОС без участия опытных консультантов может привести совсем к обратным последствиям...

Какой консультант не скажет, что без консультантов результат будет плохой.
151. genayo 19.11.17 22:03 Сейчас в теме
(147) Не в консультанте дело, а в специфике Российского ритейла, особенно в области продуктов питания... То, что ТОС будет работать и в этом случае, никто сомнению не подвергает, но стандартные подходы ТОС скорее всего не сработают без корректировки на специфику.
154. 1c-intelligence 12771 19.11.17 22:56 Сейчас в теме
(151) да, об этом и Голдратт говорит. Это один из его основных постулатов - нехер лепить стандартную методику в каждую ситуацию. Надо думать, соображать и корректировать. Базовыми остаются только принципы.
31. rovenko.n 01.11.17 12:39 Сейчас в теме
(19) Как раз в ЕРП есть отчет, в котором отображаются резервы, и даты прихода. Если создать "Заказ поставщику", цифра напишется в плановую дату как приход, а "Заказ клиента" запишет плановую дату как минус. Так что в ЕРП проблему "сколько пропадает и сколько придет" уже решили. Ну и про то, что нужно планирование делать под каждый отдельный объект - так это правда. Я сейчас на внедрении вижу такую схему, которую не видел НИКОГДА до этого.
35. 1c-intelligence 12771 01.11.17 16:24 Сейчас в теме
(31) в ЕРП есть отчет, который покажет обеспеченность заказов клиента без использования резервирования?
40. rovenko.n 01.11.17 17:58 Сейчас в теме
(35) Нет. Потому что именно резервирование указывает что мы отправим клиенту. Больше того, как мы можем рассчитать обеспеченность, если у нас на складе лежит 10 штук и есть три заказа по 5 штук? Считать все три обеспеченными на 66%? Или да по 100%, а третий - 0%? Я прочел вашу статью от корки до корки и понял, что основная проблема - вы слишком много просите как от УПП, так и от ЕРП. Вопросы логистики, вопросы обеспечения заказов - специфика по каждому предприятию и универсальный механизм в рамках 1С сделать вряд ли возможно. Потому что проблемы такого типа решаются через графы и поиск оптимального решения, а не с помощью четырех операндов арифметики.
41. 1c-intelligence 12771 01.11.17 18:17 Сейчас в теме
(40)
как мы можем рассчитать обеспеченность, если у нас на складе лежит 10 штук и есть три заказа по 5 штук? Считать все три обеспеченными на 66%? Или да по 100%, а третий - 0%?

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

мое мнение, резервирование - это слишком тяжелое решение для таких задач. И в использовании, и в сопровождении. В статье написал об этом.
вы слишком много просите как от УПП, так и от ЕРП

не, ничего не прошу. Просто сокрушаюсь, что этого нет.
Проще у кошки или собаки абстрактный механизм планирования попросить, чем у УПП или ERP.
43. rovenko.n 01.11.17 19:22 Сейчас в теме
(41)А вот и не хватит тумблера. Потому что есть еще вариант "Отправить этим 80%, а этим по 90%". Во-вторых, когда заказ поступает в систему человек работает с ним. И если заказы поступают по очереди первый заказчик получит всё. Если же одновременно - включается мозг пользователя (да, да, есть моменты, которые легче оставить на пользователе, чем записывать в системных настройках). Как пример - ресурсные спецификации. Там такой вкусный инструментарий, просто ляля. Я не видел еще ни одного пользователя, который бы настроил оптимизацию и сделал бы по-нормальному. Легче зафигачить 50 спецификаций копированием. Пользователи будут эти настройки делать? Нет. А если через время поменяется что-то? Вы этот вопрос, кстати, поднимали. Звонить поддержке и спрашивать?
45. genayo 01.11.17 19:41 Сейчас в теме
(43) Одна из самых больших ошибок делать полностью автоматические системы "планирования", это гарантировано не взлетает. Тут как с ТОС, первое желание у начинающих ее постигать - сделать полностью автоматическую систему, что на самом деле верный путь к провалу...
rovenko.n; +1 Ответить
49. 1c-intelligence 12771 02.11.17 05:28 Сейчас в теме
(45) сам не видел, но коллеги видели почти полностью автоматизированный закуп по ТОС. Предприятие - крупный дистрибьютор фурнитуры мебельной. Закупом делает одна девочка. Размеры буферов корректируются автоматически, по времени нахождения статуса буфера в зоне. Собственник иногда меняет буферы вручную.
50. genayo 02.11.17 06:42 Сейчас в теме
(49) Не зная подробностей внедрения нельзя судить, насколько оно автоматическое и насколько оно ТОС. И в общем закуп без производства это слишком простой частный случай планирования...
51. TODD22 18 02.11.17 06:47 Сейчас в теме
(50)
сам не видел, но коллеги видели

Слухами земля полнится.....
53. 1c-intelligence 12771 02.11.17 07:57 Сейчас в теме
(51) да, особенно благодаря таким, как вы.
54. TODD22 18 02.11.17 08:02 Сейчас в теме
(53)А я что какие то слухи распространяю?
55. 1c-intelligence 12771 02.11.17 08:03 Сейчас в теме
(54) нет, не распространяете.
56. TODD22 18 02.11.17 08:03 Сейчас в теме
(55)Тогда поясните что вы имеете ввиду в (53)
61. 1c-intelligence 12771 02.11.17 08:17 Сейчас в теме
(56) я думал, мы просто бессмысленными фразами обмениваемся.
59. genayo 02.11.17 08:11 Сейчас в теме
(51) На самом деле для такого товара, как мебельная фурнитура вполне можно сделать автоматического закупщика, даже без ТОС. Вот по продуктам питания, например, все на порядок сложнее...
52. 1c-intelligence 12771 02.11.17 07:56 Сейчас в теме
(50) вам знаком Виктор Вальчук?
57. genayo 02.11.17 08:08 Сейчас в теме
(52)Да, читал некоторые статьи...
58. 1c-intelligence 12771 02.11.17 08:09 Сейчас в теме
(57) как думаете, его можно считать человеком, правильно понимающим и внедряющим ТОС?
60. genayo 02.11.17 08:14 Сейчас в теме
(58) Не настолько глубоко понимаю ТОС, чтобы оценивать практикующих специалистов. Он где-то говорит о необходимости полностью автоматических инструментов при внедрении ТОС?
62. 1c-intelligence 12771 02.11.17 08:19 Сейчас в теме
(60) он руководил одним из проектов внедрения ТОС, я занимался автоматизацией. Автоматизация была почти полная.
Но вообще я спросил про него на тот случай, если вы его знаете и считаете авторитетом, тогда не пришлось бы доказывать что-то от своего имени, воспользовался бы его мнением.
63. genayo 02.11.17 08:25 Сейчас в теме
(62) Есть ссылка или из личных разговоров? Делитесь...
64. 1c-intelligence 12771 02.11.17 08:33 Сейчас в теме
(63) из личных, увы, с Вальчуком и его ребятами.
Весь ТОС нельзя автоматизировать, это философия.
Но такие вещи, как ББВ, сам Бог велел.
65. genayo 02.11.17 08:49 Сейчас в теме
(64) И автоматически размеры буферов менять без участия пользователя? Или это только после определенного периода внедрения и опытной эксплуатации?
66. 1c-intelligence 12771 02.11.17 08:53 Сейчас в теме
(65) а с этим сложности есть? Алгоритм вроде известен.
Разумеется, ручная корректировка поверх автоматической тоже нужна, если информация в голове человека опережает фактический расход, например есть договоренность на увеличение поставок, еще никак не зафиксированная в системе.
47. 1c-intelligence 12771 02.11.17 05:23 Сейчас в теме
(43) по моему опыту, определенными усилиями воли можно выработать и соблюдать правила распределения, при неравномерном спросе.

Важнее, конечно, над предотвращением дефицитов работать, чем над сложным алгоритмом их распределения.
11. genayo 26.10.17 21:51 Сейчас в теме
Описание проблемы в целом совпадает с практическим опытом, только фраза "бюджетирование правильное, а планирование нет" непонятна, в УПП и то, и другое далеко не идеально, и без допила не взлетает на чуть более сложном, чем отверточная сборка производственном предприятии.
А вот какое решение предлагается не очень понятно, если честно, ждал в конце статьи интересных ссылок :))
12. 1c-intelligence 12771 26.10.17 21:53 Сейчас в теме
(11) разница в том, что бюджетирование содержит инструменты для допиливания внутри себя. А планирование - нет.
Ссылки будут.
13. genayo 26.10.17 21:59 Сейчас в теме
(12) Не соглашусь, ну да ладно, тема не об этом в общем...
14. 1c-intelligence 12771 26.10.17 22:03 Сейчас в теме
(13) это нормально, мы с вами обычно не соглашаемся друг с другом :)
Но за внимание и интерес к статье - спасибо.
16. guevara74 27.10.17 03:26 Сейчас в теме
Иван, если честно, то не совсем понял для чего статья.
Имхо про УПП можно вообще не стоит говорить : Это система для "посмертного учета". Кроме того, в ней никогда не было заложено ВНЯТНОЙ методологии планирования. Всегда все забивали на эту подсистему и писали свое, практически с нуля.

Про ERP ты же как то мимоходом совсем обмолвился. А ведь это система с ПРАВИЛЬНОЙ и ВНЯТНОЙ методологией : два уровня производственного планирования (глобальный и локальный диспечера), способы и схемы обеспечения и т.д. Понятно, что хочется большего, но и то что есть ОЧЕНЬ достойно
17. 1c-intelligence 12771 27.10.17 06:40 Сейчас в теме
(16) Охренеть, Дима Шилин. Рад приветствовать, спасибо что зашел!

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


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

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

А в ERP сразу встали на неправильный путь - реализовали свою методику. Проблема в том, что сейчас им уже не повернуть назад - это ж признание ошибки будет. Поэтому правильного планирования раньше чем лет через 10 от 1С ждать не стоит, увы.
van_za; genayo; guevara74; Infactum; +4 Ответить
22. guevara74 27.10.17 10:17 Сейчас в теме
(17)Иван, слушай, тут вспомнил, ты же что то для 1С писал в УПП по планированию (вроде посменному). Не обманывает меня память?
(18)
23. 1c-intelligence 12771 27.10.17 11:04 Сейчас в теме
(22) да, было дело. И для помощника планирования тоже.
32. rovenko.n 01.11.17 12:43 Сейчас в теме
(17) то есть по сути вы говорите "Планирование нельзя сделать универсальным". А в ЕРП реализовали свою методику, попытавшись сделать его универсальным? А вам не кажется, что вы сами себе противоречите?
36. 1c-intelligence 12771 01.11.17 16:26 Сейчас в теме
(32)
то есть по сути вы говорите "Планирование нельзя сделать универсальным"

я такое говорил?
В ЕРП сделали не универсальную методику, а решение с заложенной методикой. Это ж разные вещи.
В УПП нет методики, есть заготовки универсальных инструментов.
39. rovenko.n 01.11.17 17:48 Сейчас в теме
(36)стоп-стоп, в ЕРП есть возможность делать планирование на основании источников. В источники можно вытянуть почти всё, начиная от остатков за позапрошлый год и заканчивая сезонностью продаж номенклатуры.
42. 1c-intelligence 12771 01.11.17 18:21 Сейчас в теме
(39) так это вроде помощник планирования в чистом виде, там тоже есть возможность тянуть что угодно из произвольных отчетов.
Но это только один, маленький кусочек - определение потребностей, по которому особо вопросов-то нет.
44. rovenko.n 01.11.17 19:23 Сейчас в теме
(42) я в УПП не видел таких настроек. С тем же рейтингом контрагентов и продаж.
48. 1c-intelligence 12771 02.11.17 05:26 Сейчас в теме
(44) это стратегия расчета количества "Заполнить данными отчета (настройка не выбрана)". Выбирается сохраненная настройка из справочника "Сохраненные настройки" (кажется), а откуда данные - не важно, может быть и произвольный отчет. А раз произвольный отчет, то любые данные.
Вроде, ей надо, чтобы были поля Номенклатура и Количество.
Туда можно и рейтинг заложить, наверное.
133. Denium79 14 14.11.17 19:29 Сейчас в теме
(17) почему не повернули? С 2.1 на 2.4 же ушли. А это как раз поворот к старым добрым маршрутным картам и MRP 2. Видимо не взлетела на старых советских гигантах типа Мотовилихи TOC. А жаль...
18. pm74 199 27.10.17 06:42 Сейчас в теме
(16) Дима привет. не ожидал тебя тут увидеть
24. IvanovAV 132 27.10.17 15:44 Сейчас в теме
Как-то копался я в планировании в УТ 11. И ничего хорошего не накопал, какие-то бредовые нагромажденные универсальные механизмы, непонятно для кого и зачем написаны. Плюнул и написал планы и факты, через свои отдельные простые документы и свой регистр плана, и пару отчетов на СКД. На все про все ушло неделя вместе с отладкой и тестовой эксплуатацией. Клиенты до сих пор пользуются, все просто и понятно. Не знаю как, теперь эту подсистему выклянчить из типовой конфы, чтобы выложить на инфостарт, чтобы типовые справочники и регистры не задеть, но и ссылки на них остались. И при объединении с типовым СФ-ником база не посыпалась. Может у кого есть опыт или статьи на эту тему? (Через расширение не получится, т.к. объекты добавлены)
25. Сурикат 393 27.10.17 16:57 Сейчас в теме
(24)
Переделать на определяемые типы?
27. kote 536 29.10.17 15:56 Сейчас в теме
(24)
Через расширение не получится, т.к. объекты добавлены

подождите, релиза 8.3.11 - там должно появиться это
Snitkovski; IvanovAV; +2 Ответить
26. van_za 243 28.10.17 08:04 Сейчас в теме
Отличная статья, и название подходящее:)

Пытался для производства плёнок и пакетов настроить еrp, не прокатило.

Остались в упп наполнять великую пустоту.
1c-intelligence; +1 Ответить
33. rovenko.n 01.11.17 12:45 Сейчас в теме
(26) Можно более детально? Схемы обеспечения делали? Настройки передачи? Автовыбор материалов в спецификациях? Планирование по источникам? Просто в ЕРП планирование - очень гибкий инструмент. Далеко неидеальный, но туда можно очень много впихнуть
37. van_za 243 01.11.17 16:48 Сейчас в теме
Я думаю что ERP можно натянуть на сборочное производство где А = Б + С, специфика производства полимерной оболочки, пленки гораздо сложнее.

1. Невозможность вести спецификации.

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

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

3. Требуется инструмент решения задачи раскроя.
есть полуфабрикаты разной ширины требуются продукты, как правильно раскроить их что бы получить минимальные потери и минимальную загрузку рабочих центров.
38. rovenko.n 01.11.17 17:47 Сейчас в теме
(37) а) в спецификациях можно настроить формулы. А ширина - это характеристика. Добавляете условие "> n"
б) то же самое: указываете ширину, высоту, количество ручьев как параметры и вбиваете их при расчете
в) Это да, такого нет. В ЕРП есть время на переналадку, но нет материалов на переналадку.
г) Это не задача ЕРП, это задачи с подбором параметров, потому их универсализировать никто не будет. Вы бы еще про доставку вспомнили: ЕРП НЕ может нарисовать оптимальный маршрут доставки.
46. van_za 243 01.11.17 21:25 Сейчас в теме
вы представляете что проблема в том что бы подобрать номенклатуру я говорю что это не проблема, проблема в том что на момент формирования заданий на пределы вы еще не знаете какие у вас будут остатки полуфабрикатов и какие будут потребности по другим заказам исходя их этого полуфабрикаты будут резаться...
28. Arsen1986 80 01.11.17 08:36 Сейчас в теме
Не согласен с заголовком статьи и направленностью только в 1С, тоже самое можно сказать и про другие ERP
29. 1c-intelligence 12771 01.11.17 08:56 Сейчас в теме
(28) можно, конечно, и про другие ERP так сказать. Напишете статью?
30. Painted 49 01.11.17 10:15 Сейчас в теме
Это как ядерную бомбу на полпути от Марса до Венеры взорвать – солнечная система ничего не заметит

Ничесе, абстрагировались. Где-то между Марсом и Венерой Земля находится, вообще-то.
wolfsoft; rovenko.n; +2 Ответить
34. 1c-intelligence 12771 01.11.17 16:22 Сейчас в теме
(30) с точки зрения ядерного взрыва это вроде не важно, но спасибо, что оценили масштаб абстракции.
123. German_Tagil 42 11.11.17 16:10 Сейчас в теме
Будет ли продолжение и практические примеры?
Заинтриговало...
132. Denium79 14 14.11.17 14:28 Сейчас в теме
Проблемы приоритетов обеспечения на УПП попытался решить следующим образом - АРМ для закупщика отображает расчетный дефицит ТМЦ на текущий момент времени. Каждый отбирает ту номенклатуру за которую отвечает. Список сортирован по дате ближайшего потребления. Соответственно фокус внимания снабженца там же. Внизу таблица расшифровки по заказам (потребности), остаткам и в заказах поставщику. Есть расцветка в зависимости от глубины буфера просрочки.

От резервов отказались по понятным причинам. Расчет динамического дефицита в общих чертах делаю так - вся потребность в разрезе заказов на производство и внутренних заказов сортируется по дате запуска и дате отгрузки для ВЗ. Получается огромная таблица, по которой распределяются остатки ТМЦ на выбранных складах. Если остатка нет, то смотрятся введенные аналоги, сортированные по приоритетам.

Получается в итоге таблица дефицита, сумма которого отображается в АРМ и ставится наименьшая дата необеспеченного заказа.

Есть форма отчета, показывающая процент обеспеченности каждого заказа покупателя. Второй месяц работаем по такому принципу.
176. Sergant 54 30.12.17 18:36 Сейчас в теме
"Это как ядерную бомбу на полпути от Марса до Венеры взорвать – солнечная система ничего не заметит."
Земля на полпути... :(
177. 18101986 42 27.02.18 21:59 Сейчас в теме
Планирование в каждом случае очень индивидуально и нет какого-то общего алгоритма, так, что приходится писать каждый раз по новому...
179. 1c-intelligence 12771 02.03.18 07:54 Сейчас в теме
(177) есть общий алгоритм, точнее несколько.

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

Имея базовые алгоритмы, систему планирования построить несложно.
178. FB_542008832833052 28.02.18 05:28 Сейчас в теме
Уже обсуждались не раз подобные темы здесь http://www.cyberforum.ru/1c/ и подобных тем всегда будет хватать. Пока будет спрос, будут находиться предложения.Без работы никто не останется.
180. 1c-intelligence 12771 06.07.18 09:28 Сейчас в теме
Друзья, прошу прощения за спам - поучаствуйте в голосовании.
181. CheBurator 3119 23.10.19 13:03 Сейчас в теме
а каким боком бардак в работе (постоянная работа задним числом) имеет прямое отношение к планированию? имхо и ежу понятно, что в таких условиях все что напланировались летит к черту, как и сама необходимость и возможность выстраивания планирования...
182. acanta 23.10.19 13:22 Сейчас в теме
Имхо 1с ники как то пришли в тему обьемно-календарного планирования через другие ворота.
Я допускаю, что сложно придумать даже потомственному пекарю в 5 поколении, сколько булочек он будет продавать в течении 3х лет каждый день
Но в 1с, где понятие работы задним числом возникло по причине наличия точки актуальности в регистрах, сложно даже билеты на автобус продать, потому что пассажиров нет на остатке.
А представьте себе производство, где какой-то полуфабрикат сегодня изготавливается в родном цеху, завтра закупается, а послезавтра снова там же, но это уже разные юр.лица.
Оставьте свое сообщение