Часть 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) Подбор ресурсов пока только «по минимальной стоимости», и сама стоимость производства процесса считается только для конечного процесса (т.е. считается-то она для всех, но подбор по "минимальной себестоимости" не реализован)
