Поговорим о развитии производства в Microsoft Axapta

[Vadim Korepin]

Как известно, производственный контур системы в будущей версии 4.0 будет сильно расширен и такая тенденция сохранится и в следующей версии. Причем наметились два основных направления: партнерские вертикальные решения и развитие базовой функциональности. Вследствие чего и интересует мнение сообщества, какие основные моменты базового функционала (производственного) требуют первостепенной доработки(разработки), а также чего не хватает на данный момент партнерам для создания и регистрации вертикальных решений (российских зарегистрированных Add'онов нет)

Что бы хотелось сказать по поводу развития функционала, как я вижу - это прежде всего:

1) развитие производственного планирования в системе (Сводное планирование) - фактически ориентация на APS. Несмотря на великую цель достичь ее не так уж и сложно. Если добавить немного конкретики, то приоритетность в производственных заказов, разделение заданий и т.д.

2) Насыщение конструкторской и технологичекской документации: альтернативные номенклатуры(+), вспомогательные материалы, формульные расчеты, наряды(*) и т.д.

3) Себестоимость. Улучшение механизма распределения косвенных затрат, попроцессный расчет и т.д.

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

[alexbrain]

Для начала:
1. Исправить ошибки в прогнозном и сводном планировании, а не отбрыкиваться от них.
2. Привести методы планирования к устоявшимся представлениям, не хочу употреблять слово "стандартам"
3. Изменить алгоритм планирования простого перебора вариантов, а то уж очень медлееееннно все это функциклирует на реальных данных
4. Разработать много параметрическое планирование
5. Привести в нормальный вид "замечательный" производственный учет, это о проводках :
Кт10 Дт20
а потом
Кт20 Дт10
Бухгалтерия просто плачет.
6. Производственные документы - мы в России живем, есть определенные документы по которым производственные предприятия работают, чего стоит только "отгрузочная накладная", такое ощущение, что ее для ларьков рисовали.
7.
8.
и еще много.......
Ну и конечно, то что сказано вами ))

[komar]

Для начала хотя бы просто распределение косвенных затрат...

[Vadim Korepin]

Что ж ... поговорим подробнее, итак

Цитата:

1. Исправить ошибки в прогнозном и сводном планировании, а не отбрыкиваться от них.

что конкретно имеется ввиду? какие именно ошибки планирования?

Цитата:

2. Привести методы планирования к устоявшимся представлениям, не хочу употреблять слово "стандартам"

Какие именно стандарты, чего не хватает и т.д.

Цитата:

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

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

Цитата:

4. Разработать много параметрическое планирование

С этим пожалуй всё понятно.

Цитата:

5. Привести в нормальный вид "замечательный" производственный учет, это о проводках :
Кт10 Дт20
а потом
Кт20 Дт10
Бухгалтерия просто плачет.

Это я так понимаю при "калькуляции издержек"? Запрос существует и есть подвижки.

Цитата:

6. Производственные документы

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

Цитата:

и еще много.......

И это тоже очень интересует ...

[Valery]

1. Устранить глюк: нельзя работать (расчет цены, контроль цикличности и др. операции) со спецификацией больше 15 уровней.
2. Для проектного производства - необходима связь производственных и проектных модулей. Т.е. если производство является частью проекта (куда еще входят конструкторские работы, испытания и др.), и если сборка отдельных узлов является отдельными работами в проекте, то хотелось бы, чтобы при завершении производственных заказов автоматически менялся статус работ в проекте. Это необходимо для удобства отслеживания хода выполнения проекта.
3. Часто одна и та же деталь может поступать в сборочный цех из разных цехов. Однако склад пополнения можно указать только один
4. Про версии спецификации: хотелось бы, чтобы разные версии могли иметь разный состав компонентов
5. Для многоуровневых спецификаций необходимо доработать механизм зависимостей между выбором компонент в разных местах дерева, а также параметрическое задание количеств компонент в разных местах и уровнях дерева в зависимости от вводимого пользователем параметра. (Может эти проблемы решает Product Builder? Не знаю, конфигурирует ли он сразу многоуровневую спецификацию.)
6. Больше готовых отчетов: красивых и разных. В основном заказчиков волнует два момента: 1) отслеживать прохождение заказов. Т.е. отчет типа изделие-заказ-сколько уже закуплено материалов % - сколько произведено узлов %. 2) Информация в разрезе цехов: квартальные, месячные планы производства, отчеты план-факт по выполнению планов, по затратам.

[alexbrain]

Ох!
1. Глюки, не все, конечно, зарегистрированы, либо отвергнуты MBSом .
Есть их еще не мало.
Давай один посмотрим:

Запускаем производство - отмечаем операцию как законченную, но не последнюю, - Приемки еще нет - переходим в Журнал приемки производства - создаем журнал и........ принимаем ВСЕ!!!!! на склад, и НИКАКИХ предупреждений - НИЧЕГО!!!
Вот так и работаем
А про планирование, вообще......
Спланируй несколько заказов одной номенклатуры производственной, сгруппируй или раздели и посмотрим КАК потребности обновятся, а если еще и мощности не хватает, то ЕЩЕ интересней!!!!

2. Это что за прогнозное планирование!!!
Прогноз ДОЛЖЕН давать информацию о ВОЗМОЖНОСТИ использования ВСЕХ производственных ресурсов!!
Пример:
В маршрутах указаны Группы рабочих центров (ГРЦ) и количество РЦ = 1 (ведь маршрут технологии пишут и они указывают либо не указывают количество центров) , т.е. ГРЦ у меня может быть цех, участок, однотипные производственные мощности, в котором много РЦ - хороших и разных, а ЧТО в конце концов получаем на выходе???

Планирование же происходит ТОЛЬКО по этому ОДНОМУ рабочему центру, а на фиг мне такой прогноз нужен???
Я же ХОЧУ знать могу или не могу выполнить такой прогноз, а если не могу, то каких мощностей мне не хватает, а тут - беда!!!!

А вот Сводное планирование уже мне ДОЛЖНО давать более реалистичную картину, что оно конечно и дает - ИНОГДА , если правильно сделать
3.Ну какой ТЕСТ, какие реальные данные, тут на тестовых то одно изделие с 10 вложениями и с альтернативными центрами планируется - ЧАСЫ!!!!
А что Эвристические методы - СЛАБО MBS использовать???? Мозгов не хватает???
Так можно занять в России

Ну про ;0 счетов я воооообще молчу, у нас его конечно не используют в промышленности

Хватит?

[Vadim Korepin]

Цитата:

Изначально опубликовано Valery
1. Устранить глюк: нельзя работать (расчет цены, контроль цикличности и др. операции) со спецификацией больше 15 уровней.

В SP3 который в скором времени выходит будет до 50 уровней (как обещают)

Цитата:

2. Для проектного производства - необходима связь производственных и проектных модулей. Т.е. если производство является частью проекта (куда еще входят конструкторские работы, испытания и др.), и если сборка отдельных узлов является отдельными работами в проекте, то хотелось бы, чтобы при завершении производственных заказов автоматически менялся статус работ в проекте. Это необходимо для удобства отслеживания хода выполнения проекта.

С этим вроде тоже всё нормально. В 4.0 гарантированно обещают связку производства и проектов.

Цитата:

3. Часто одна и та же деталь может поступать в сборочный цех из разных цехов. Однако склад пополнения можно указать только один

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

Цитата:

4. Про версии спецификации: хотелось бы, чтобы разные версии могли иметь разный состав компонентов

А что мешает просто создать новую спецификацию?

Цитата:

5. Для многоуровневых спецификаций необходимо доработать механизм зависимостей между выбором компонент в разных местах дерева, а также параметрическое задание количеств компонент в разных местах и уровнях дерева в зависимости от вводимого пользователем параметра. (Может эти проблемы решает Product Builder? Не знаю, конфигурирует ли он сразу многоуровневую спецификацию.)

Именно. Product Builder решает. Только что значит "сразу многоуровневую" - ибо включение в спецификацию номенклатуру с типом "спецификация" - ведет к появлению нового уровня вот и всё (кстати соответственно так можно включить в свою очередь моделируемую номенклатуру). Кстати вот не далее как сегодня был тренинг по PB - вроде бы доступно всё рассказал о нём. Коли интересует PB - желательно было бы поприсутствовать - благо что бесплатный.

Цитата:

6. Больше готовых отчетов: красивых и разных. В основном заказчиков волнует два момента: 1) отслеживать прохождение заказов. Т.е. отчет типа изделие-заказ-сколько уже закуплено материалов % - сколько произведено узлов %. 2) Информация в разрезе цехов: квартальные, месячные планы производства, отчеты план-факт по выполнению планов, по затратам.

В разрезе цехов это да вопрос ... а вот прохождение заказа ... частично помогает запрос "Развертывание"

[Тимур]

Меня, как злостного консультанта, не устраивает в Axapta система производственного учета. Предприятиям машиностроительной отрасли просто необходимо постатейное планирование, калькуляция и учет прямых затрат, а также группировка затрат по элементам.
Другая проблема корнями из связки логистики и финансов: учет движения материальных запасов между производстенными участками и цехами.
Что касается реализации процессных производств, то тут просто надо с нуля прорабатывать отраслевые серьезные решения. Хотелось бы не за счет партнеров.
Так сказать пересмотреть структуру распределения средств на развитие продукта и на его продвижение в сторону первого.

[alexbrain]

Цитата:
--------------------------------------------------------------------------------

4. Про версии спецификации: хотелось бы, чтобы разные версии могли иметь разный состав компонентов

--------------------------------------------------------------------------------



А что мешает просто создать новую спецификацию?

---------------------------------------------------------------------------------

А вот ЭТО в корне не верно!!!
В машиностроение спецификация ОДНА, а версий - изменений, исполнений и т.п. может быть десятки!!!
А в Axapte надо номенклатуры новые создавать - какая ж база будет

Нормативная база только под миллион и еще все изменения приплюсуем - УРАГАН!!!

[Vadim Korepin]

Цитата:

Изначально опубликовано alexbrain
Цитата:
А вот ЭТО в корне не верно!!!
В машиностроение спецификация ОДНА, а версий - изменений, исполнений и т.п. может быть десятки!!!
А в Axapte надо номенклатуры новые создавать - какая ж база будет

Нормативная база только под миллион и еще все изменения приплюсуем - УРАГАН!!!

Это понятно. Только в данном случае я вел речь о "версиях спецификаций" не в рамках стандартной терминологии, а в рамках понятий Microsoft Axapta. В данном случае в системе потребуется вводить принципально новую сущность, чтобы отразить указанное.

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

[alexbrain]

Цитата:

Изначально опубликовано Vadim Korepin


Это понятно. Только в данном случае я вел речь о "версиях спецификаций" не в рамках стандартной терминологии, а в рамках понятий Microsoft Axapta. В данном случае в системе потребуется вводить принципально новую сущность, чтобы отразить указанное.

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

-------------------------------------------------------------------------------------------------------------------------

Вообще-то отсутствует сам механизм отслеживания изменений, хотя, например, в машиностроение это все делается через PDM-системы, а вот в пищевке или там где PDM-систем нет это просто необходимо.
Сам функционал Спецификаций беден - отсутствуют справочники, которые должны подключаться на строке спецификации - пример, ну хотя бы взаимозаменяемые материалы , которые присутствуют на производстве ПОВСЕМЕСТНО!
Признаков по строке спецификации должно быть МНОГО.

[Vadim Korepin]

Цитата:

Изначально опубликовано alexbrain

-------------------------------------------------------------------------------------------------------------------------

Вообще-то отсутствует сам механизм отслеживания изменений, хотя, например, в машиностроение это все делается через PDM-системы, а вот в пищевке или там где PDM-систем нет это просто необходимо.
Сам функционал Спецификаций беден - отсутствуют справочники, которые должны подключаться на строке спецификации - пример, ну хотя бы взаимозаменяемые материалы , которые присутствуют на производстве ПОВСЕМЕСТНО!
Признаков по строке спецификации должно быть МНОГО.

Итак, предварительно есть информация о подвижках в сторону PDM в версии 4.0.
Запрос на альтернативные материалы существует и есть достаточно серьезные основания утверждать, что эта доработка будет включена в 4.0.
Какие ещё справочники нужны?

Давайте разбираться в терминологии, что вы понимаете под понятием "признак" - я думаю вы вряд ли удовлетворитесь просто новым полем "Признак №76" и МНОГО - это не дело - должно быть ДОСТАТОЧНО.

[alexbrain]

Цитата:

Изначально опубликовано Vadim Korepin


Итак, предварительно есть информация о подвижках в сторону PDM в версии 4.0.
Запрос на альтернативные материалы существует и есть достаточно серьезные основания утверждать, что эта доработка будет включена в 4.0.
Какие ещё справочники нужны?

Давайте разбираться в терминологии, что вы понимаете под понятием "признак" - я думаю вы вряд ли удовлетворитесь просто новым полем "Признак №76" и МНОГО - это не дело - должно быть ДОСТАТОЧНО.

-----------------------------------------------------------------------------------------------------------------------
Термин ПРИЗНАК - справочник - пример, размеры заготовки (черновые, чистовые), ГОСТы, ТУ, сертификаты и т.п., не говоря о признаках, дополнительной информации, требующейся на каждом конкретном проекте.
Сроки действия сертификатов, их отслеживание ....

Еще в пищевке ВООБЩЕ расчет ингридиентов рецептуры зачастую ведется на основании % соотношения одного компонента от другого - это проблема, однако

[Vadim Korepin]

Цитата:

Изначально опубликовано alexbrain

-----------------------------------------------------------------------------------------------------------------------
Термин ПРИЗНАК - справочник - пример, размеры заготовки (черновые, чистовые), ГОСТы, ТУ, сертификаты и т.п., не говоря о признаках, дополнительной информации, требующейся на каждом конкретном проекте.
Сроки действия сертификатов, их отслеживание ....

Еще в пищевке ВООБЩЕ расчет ингридиентов рецептуры зачастую ведется на основании % соотношения одного компонента от другого - это проблема, однако

Если мне не изменяет память, то в пищевке как раз действительно %, но не в соотношении одного от другого, а в % соотношении в целом на готовый продукт. это несколько иное.

признаки на каждом конкретном проекте - это отдельная вещь и естественно ее не будет - ибо это частности.
А так вы говорите о характеристиках - это стандартная вещь для процессного производства - если 4.0 пойдет по пути реализации основ процессного производства в ней я думаю, это будет сделано. Хотя конечно лишний запрос не помешает. Главное понять, что именно Вы хотите от этих дополнительных признаков:
1. просто дополнительная информация для отчетов
2. контроль характеристик и отслеживание их изменений в течение производственного цикла
3 .... иное?

[AlexR]

Доброго времени суток:
2 Вадим :

Вы пишите: "Себестоимость. Улучшение механизма распределения косвенных затрат, попроцессный расчет и т.д." те Вам понятно как получить прямые затраты труда.
Поясните тогда пжлста возможно ли: используя модуль Shoop Floor Control для регистрации выработки Основных Производственных Рабочих (сдельная, сдельно премиальная, почасовая работа ) и тарификации работы (умножать на денежку) затем регистрировать эти затраты ( в денежном выражении) на счетах ГК, причем отличных от тех что указаны для потребления для группы рабочих центров.
(Пока использую бухгалтерскую разноску номенклатура+рабочие центры)

И не поделитесь ли сокровенным знанием расчета категорий издержек:
Категории длительности настройки
Категории длительности процессов
Количественной категории

Спасибо…

С уважением к Вам, Вашим Знаниям и Опыту

[Тимур]

To Alexbrain:

про версии спецификаций: в машиностроении применяется стандарт ЕСКД, axapta к этому стандарту никакого отношения не имеет, так как не относится к классу продуктов PDM, поэтому глупо требовать от нее того, что она не должна реализовывать. Встречный вопрос Вадиму: ага, пусть будет PDM в Axapta, но на какой стандарт консрукторской документации он будет рассчитан? универсальных систем PDM я не видел (может конечно не туда смотрел)

Теперь про пищевку: не надо путать спецификации и рецептуры. Это совершенно разные вещи. Axapta не поддерживает рецептуры, их можно либо худо-бедно смоделировать, либо дописать в нужном функционале. Так что если кто-то сначала продал Axapta в пищевку, а только потом ознакомился с организацией пищевых производств, то это его проблемы. Ну а клиенту в зависимости от сложности пищевого производства (мясопереработка, производство молочных продуктов, кондитерка, табачка) могу посочувствовать только. Как говорится, сначала надо было прототип системы смотреть, а потом покупать.
Беда продуктов MBS в том, что их двигают сразу во все отрасли, даже не проанализировав реализацию прототипов. А потом партнеры (кто громче кричит) требуют дописывать систему под своих клиентов, при этом не факт что именно это надо дописывать.

[alexbrain]

Цитата:

Изначально опубликовано Тимур
To Alexbrain:

про версии спецификаций: в машиностроении применяется стандарт ЕСКД, axapta к этому стандарту никакого отношения не имеет, так как не относится к классу продуктов PDM, поэтому глупо требовать от нее того, что она не должна реализовывать. Встречный вопрос Вадиму: ага, пусть будет PDM в Axapta, но на какой стандарт консрукторской документации он будет рассчитан? универсальных систем PDM я не видел (может конечно не туда смотрел)

-------------------------------------------------------------------------------------------------------------------------
Так и не нужен в Axapte PDM, нужно совсем немного для того чтобы поддерживать их интеграцию, так же не надо ЕСКД (вообще-то это стандарт для бумажных носителей) из Axaptы надо получить ВСЮ необходимую информацию для передачи в производство, что, из чего, как и когда делать.
-------------------------------------------------------------------------------------------------------------------------


Теперь про пищевку: не надо путать спецификации и рецептуры. Это совершенно разные вещи. Axapta не поддерживает рецептуры, их можно либо худо-бедно смоделировать, либо дописать в нужном функционале. Так что если кто-то сначала продал Axapta в пищевку, а только потом ознакомился с организацией пищевых производств, то это его проблемы. Ну а клиенту в зависимости от сложности пищевого производства (мясопереработка, производство молочных продуктов, кондитерка, табачка) могу посочувствовать только. Как говорится, сначала надо было прототип системы смотреть, а потом покупать.
Беда продуктов MBS в том, что их двигают сразу во все отрасли, даже не проанализировав реализацию прототипов. А потом партнеры (кто громче кричит) требуют дописывать систему под своих клиентов, при этом не факт что именно это надо дописывать.

-----------------------------------------------------------------------------------------------------------------------
А почему не двигать, если приктрутить некие отраслевые особенности, то можно, и такие системы есть - не R3, проще.
А на самом деле поддержание расчета рецептуры не такое уж и сложное дело - всего-то использовать переменные для расчета количества по строкам спецификации.

[Тимур]

Неа.
Не надо сюда PDM
разве что мост стандартный на XML/txt формате.
Никто бумажных чертежей в промышленности не отменял.

Рецептура - это не только долевое соотношение с дальнейшим масштабированием. Читайте Олина Томпсона, www.processerp.com
Вообще это сейлзовые термины "отраслевые особенности", "настройки", "вертикальные решения". Поэтому "прикручивать" можно хоть черта лысового к системе, но применимость ее для конкретного производства не увеличится.
Решения для процессных производств есть не только у SAP, OEBS и Baan, но и средних систем, таких как QAD Appl., iRennesanse.

P.S. Сорри за резкость.

[Vadim Korepin]

Цитата:

Изначально опубликовано AlexR
Доброго времени суток:
2 Вадим :

Вы пишите: "Себестоимость. Улучшение механизма распределения косвенных затрат, попроцессный расчет и т.д." те Вам понятно как получить прямые затраты труда.
Поясните тогда пжлста возможно ли: используя модуль Shoop Floor Control для регистрации выработки Основных Производственных Рабочих (сдельная, сдельно премиальная, почасовая работа ) и тарификации работы (умножать на денежку) затем регистрировать эти затраты ( в денежном выражении) на счетах ГК, причем отличных от тех что указаны для потребления для группы рабочих центров.
(Пока использую бухгалтерскую разноску номенклатура+рабочие центры)

И не поделитесь ли сокровенным знанием расчета категорий издержек:
Категории длительности настройки
Категории длительности процессов
Количественной категории

Спасибо…

С уважением к Вам, Вашим Знаниям и Опыту

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

Далее, расчеты категорий издержек - здесь вообще всё очень просто:

Категория длительности настройки * Часы настройки + Категории длительности процессов * Часы обработки + Количественной категории * Количество по заказу = Себестоимость прямых затрат по маршруту

[Тимур]

Вадим.
Проблема в том, что Axapta не учитывает количественные отклонения отдельно по операционной составляющей и отдельно по материальной составляющей.