gifts2017

Универсальная система планирования ресурсов, URP

Опубликовал Дмитрий Воронцов (informa1555) в раздел Отраслевые решения - Производство

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

Часть 1. Немного теории.

Наиболее близкой по функционалу является класс APS систем, которые позволяют планировать производственные запасы и составлять расписания для цехов, оборудования и т.д. У меня были предпосылки для расширения области планирования – требовалось иметь систему, во-первых, охватывающую больше, чем производственные подразделения, во-вторых, получить более реальное операционное планирование бюджетов на основе реальных графиков ресурсов, а также систему, которая могла бы осуществлять консолидированное планирование нескольких бизнесов. В принципе ничего революционного -  я просто использую методики, которые применялись к производственным процессам, к более широкому кругу процессов и ресурсов предприятий, и ставлю более сложные задачи перед системой – моделирование себестоимости и т.д. Для краткости я использую рабочее название URP (universal resource planning)

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

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

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

Из таких "кирпичиков" состоит вся цепочка планирования. Т.е. нажатием одной кнопки в системе происходит планирование сразу всех процессов, а каждый процесс отражается сразу во всех разделах учета. Вот и все принципы. Теперь о реализации.

Часть 2. Система

Система состоит из одного основного справочника ("Спецификация процесса") и одного документа ("Планирование процессов"), из которых и создается вся нужная схема планирования. 

То, что я так легко валю в одну кучу разные ресурсы, которые в 1С привыкли разносить по разным справочникам «Номенклатура», «Технологические операции» и т.д. – нет ничего удивительного: я использую для ресурсов один справочник «Ресурсы», который я уже использовал в Универсальной учетной системе, а сама система – внешняя, аналогично APS – т.е. является надстройкой над транзакционными ERP.

Вот пример описания процесса в системе

 

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

Далее на примерах расскажу, что умеет сейчас система:

1) Ресурсы могут как иметь свое расписание – как, например, рабочие центры, так и не иметь.

Если требуется запланировать расписание для ресурса, то указывается единица времени и количество времени на операцию. Планирование расписания осуществляется по простому принципу – как рассаживание людей в зрительном зале: сначала создаются «кресла» - т.е. промежутки времени = единице времени – это может быть для одного ресурса «Час», для другого «Смена», для третьего «15 минут». Согласно расписанию т.е. с учетом выходных и т.д. Это создается отдельной обработкой. Потом по этим «креслам» рассаживаются ресурсы – естественно, если оно уже занято, то туда никто не «сядет». Я такой подход применил для быстроты перепланирования – легко можно запросом получить все свободные «кресла» (промежутки времени) и отсортировать по времени в ту или иную сторону. Графики для ресурсов создаются специальной обработкой, ниже показан результат - регистр сведений Доступность ресусов по времени - те витуальные "кресла", которые будут занимать процессы:

 

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

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

3)Использовать замены для планирования расписаний. Если не хватает времени у одного ресурса, то, если есть замена, будет задействован второй. Вот, например:

4)Планировать процессы партиями – т.е. использовать ограничение на максимальный размер партии. Для этого надо задать реквизит "Ресурс планирования расписания партий", его Единицу времени и поставить Максимальная партия в единицу времени. У "Ресурса плантирования" будет свое расписание. Например, в базе-примере у ресурса планирования единица времени "Смена", и он планируется только на незанятые смены. Для моделирования я пользуюсь этим механизмом и делаю единицы времени, например, "Месяц" и ставлю расчетную проиводительность цеха в месяц в "Максимальная партия в единицу времени"

5)Использовать подбор спецификаций по определённым принципам – например, поставщика по самой низкой цене. При этом уже доступные ресурсы  (в регистре Доступные ресурсы) имеют наивысший приоритет. Тут я несколько не доделал – задумка была более глобальная подбирать процессы с наименьшей себестоимостью в цикле планирования. Себестоимость считается на последнем переделе, а цена пока нет. Например, задача такая – подобрать автоматом закупку товара у того или иного поставщика с учетом а)цены у разных поставщиков б)стоимости и времени доставки в)себестоимости хранения на промежуточных складах. Это все частично работает, но в конечном виде не вошло в первую редакцию системы.

6)Вычислять на выходе планирования возможный объем запланированного с учетом различных ограничений и сумму затрат/ себестоимость - выводится в табличной части документа "Планирование процессов": "Запланированное количество" - это именно то, что удалось запланировать, "Цена, Сумма план" - это сумма затрат.

7)Использование различных единиц. Тут единицы как таковые не используются, а подразумеваются. Например, нам надо перевозить производимые стулья. Я делаю процесс «Грузовой автомобиль» и говорю, что на выходе у него 5000. 5000 чего? В данном случае кг. А один стул для этого процесса – 10. 10 кг. Соответственно система знает, что для 500 стульев надо 1 машину, а для 600 уже 2.

Что выдает система на выходе?

1)графики ресурсов – тут все просто. Это календарные графики.

2)Расписание ресурсов. Это и расписание потребностей, и расписание выхода процессов (производства). Так как в системе используются разделы, то расписание удобно смотреть по разделам. Например, раздел «Денежные средства» - это готовый платежный календарь, а раздел «Остатки товаров» - план закупок.

 3) ну и, собственно, эти же данные присутствуют в регистрах и предназначены для экспорта в ERP систему в виде соответствующих документов.

Процесс работы и интеграции. Консолидация.

В спецификациях указывается то, что было описано выше, вносятся, если есть ограничения, в регистр «Ограничения» и, если есть доступные на начало планирования ресурсы, в регистр «Доступные ресурсы». Кроме того, с помощью обработки или вручную создаются заранее графики ресурсов, для которых надо планировать расписание.

В регистр «Доступные ресурсы» как вносятся записи вручную (или переносятся из ERP системы), так и вносятся записи документами «Планирование процессов». В транзакционных системах остатки накапливаются в регистрах накопления, тут я использую другой подход – остатки просто указываются на какую-то дату – на начало планирования, после планирования или в процессе.

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

Система стоит отдельной базой, в которой происходит все планирование. Перед началом в URP закачиваются остатки и спецификации (техкарты), а также вносятся  другие данные. После планирования данные можно передавать в ERP системы. Переносы можно делать на конвертациях через «Универсальный обмен XML» или еще каким то способом.

Систему можно использовать для консолидации из разных баз/ разных бизнесов для сквозного планирования. Именно для этого она первоначально создавалась. Справочник Ресурсы - это общий классификатор различных ресурсов разных баз. Например, есть 7ка с одним справочником «Номенклатура», 8ки с другими справочниками «Номенклатура», в итоге они сливаются в 1 справочник «Ресурсы» через таблицы соответствия в своих базах и переносятся конвертацией.

Ограничения текущего релиза

1)      Используется только планирование JIT «точно к сроку». В принципе, у меня это просто сортировка в одном запросе «Убыв» - поменять ее несложно. Просто пока не сделал.

2)      Оптимизация ужасная – я планирую часть процессов перевести на прямую работу с SQL, т.к. нужна работа с очень большими объемами.

3)      Подбор ресурсов пока только «по минимальной стоимости», и сама стоимость производства процесса считается только для конечного процесса (т.е. считается-то она для всех, но подбор по "минимальной себестоимости" не реализован)

Скачать файлы

Наименование Файл Версия Размер
ИБ с примером 39
.dt 232,91Kb
25.11.15
39
.dt 232,91Kb Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Александр Пузаков (puzakov) 20.12.15 13:18
Есть такой анекдот. Идеальный мужчина: не пьёт, не курит, в карты не играет, никогда не изменяет и не существует. Что-то подобное можно сказать и про организацию, в которой можно использовать Вашу систему:) Уж больно идеальное планирование в идеальной организации должно быть, чтобы его можно было вот так просто автоматизировать. Но за старания плюс.
informa1555; +1 Ответить 1
2. Дмитрий Воронцов (informa1555) 20.12.15 14:48
(1) puzakov, Смотря с какой стороны на это смотреть. Если планирование и бюджетирование использовать только для целей "План-факт", мотивации и финансовой ответственности, как некоторые используют то да, объемно календарного хватит. А если использовать планирование как инструмент с помощью которого можно получить максимальную рентабельность - т.е. рассчитать что делать чтобы получить максимальную прибыль, то никакая точность лишней не будет. К сожалению, 1С этим не особо заморачивается в отличии от западных erp систем. Но тучные годы прошли, может сейчас это станет актуально.
3. Игорь Герман (German_Tagil) 05.01.16 15:13
Вопрос - (может кто-то подскажет). В нашей организации конструируется и производится НСО - причем все заказы договора разные не повторяющиеся. Для планирования закупок и отслежевания работ мы используем спецификации - и я уже год хожу и думаю как приспособить 1С к нашим потребностям - хотелось бы видеть картинку в целом а не по ее отдельным частям . Работаю начальником отдела снабжения поэтому в первую очередь интересует процесс закупок и склад исходя из спецификации.
Буду благодарен если кто-то отклкнется
По крайней мере данная статья это-то о чем я думал
germanigor@rambler.ru
informa1555; +1 Ответить 1
4. Дмитрий Воронцов (informa1555) 09.01.16 11:45
(3) German_Tagil, Вообще довольно стандартная ситуация для таких производств как окна пвх например, мебель, малые архитектурные формы и т.д. - там также каждый заказ индивидуальный. Непонятно в чем трудность? Для планирования запасов в типовых конфах есть разные стратегии - под планы производства или продаж, страховые запасы или на худой конец под заказы на пр-во если не угадали и не успели закупить все заранее.
5. Rom Shpakoff (Lancelot-2M) 19.01.16 00:02
Прикольно, но приблизительно очень, как я понял - классический жадный алгоритм? У меня был некоторый опыт в разработке оперативного планирования для машиностроения - и, я считаю, фиаско связанное с недостаточной производительностью платформы. Тестировал прямую запись в базу скула, в таблицы нужных регистров сведений - и результаты меня разочаровали, потребные объемы "насквозь" оказалось нереально планировать даже так. Плюс еще есть такая специфика, как уменьшение времени переналадки оборудования - которую или долго-долго планировать или регулировать условно - той самой минимальной партией. Плюс "кресла" я еще и на "стульчики" делил из-за очень большого разброса во времени выполнения операций. Может быть для некоторых производств и подойдет - но для некоторых.
informa1555; +1 Ответить 1
6. Дмитрий Воронцов (informa1555) 19.01.16 16:05
(5) Lancelot-2M, Я тоже тестировал прямую запись в обычный MS SQL (не 2014) и производительность перепланирования достаточно хорошая, но нужно лучше. НО! дело в том что 1С и MS SQL это транзакционные системы а не OLAP и не системы, которые обрабатываются транзации в оперативке. У меня было 2 пути как решить проблему : 1) использовать OLAP или что то подобное 2)использовать сервер, который работает целиком в оперативке. Раньше я слышал только о SAP Hana и ещ ео чем то подобном у оракла, НО в MS SQL 2014 появилась технология Hekaton и это решило в пользу MS. Сейчас разбираюсь с этим, думаю позже по мере свобожного времени запилю статью на ИС.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа