Интересны ли подобные публикации на тему ERP?

[ds1678]

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

С вашего позволения:
О правильном использовании заказа на закупку в ERP-системе
Сварочное производство: почему неправильно применять нормы расхода газа при планированиии поставок и списании в производство
Прогнозирование спроса: подробнее — не значит точнее

Испытал затруднение с выбором раздела. Если ошибся, или размещенные статьи вообще не по теме форума, прошу администрацию удалить. Спасибо!

[pitersky]

Денис, тут надо заказчика воспитывать. Они ж все хотят бухучёт "как в 1С")))) поэтому и пляшут от документов
а статьи очень интересные

[mazzy]

Перенес в блоги.
Если приделаете rss, то добавлю автоматический импорт новых статей.

Цитата:

Сообщение от ds1678

Интересует мнение участников форума на предмет актуальности написанного, иными словами, стоит ли продолжать дальше?

Актуально.
Продолжать стоит.

Цитата:

Сообщение от ds1678

от учетных и расчетных функций ERP-систем на управленческие.

Э-э-э... В такой постановке - непонятно. Мне например.

А правильный вопрос содержит половину ответа.
Думаю, что стоит потратить некоторое время на формулировку того, чего хочется.


==============
Про Заказ на закупку.
Проблема не в том, что люди тупые или сознательно фигней страдают.
Проблема в том, что налицо несоответствие терминов.

Если "Purchase Order" не калькировать дословно, а назвать так как он у нас называется "Договор с поставщиком", то люди будут вводить и регулярно, и вовремя . А "Заказ на закупку"... Кому это нужно?

Мне кажется, что проблема во многом в неадекватном переводе.

[JeS]

Продолжать стоит. Интересно

[ds1678]

Спасибо всем за отзывы и проявленный интерес. Планов на будущие публикации - 8 вордовых страниц одних только заголовков. Буду продолжать.

Цитата:

Сообщение от mazzy

Перенес в блоги.
Если приделаете rss, то добавлю автоматический импорт новых статей.

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

Цитата:

Сообщение от mazzy

Э-э-э... В такой постановке - непонятно. Мне например.

А правильный вопрос содержит половину ответа.
Думаю, что стоит потратить некоторое время на формулировку того, чего хочется.

Обязательно. Но потребуется время. У меня слишком много претензий к рынку ERP Надо как-то систематизировать. А представленные статьти - это намерение организовать что-то вроде "Ководства" Темы Лебедева.

Цитата:

Сообщение от mazzy

==============
Про Заказ на закупку.
Проблема не в том, что люди тупые или сознательно фигней страдают.
Проблема в том, что налицо несоответствие терминов.

Если "Purchase Order" не калькировать дословно, а назвать так как он у нас называется "Договор с поставщиком", то люди будут вводить и регулярно, и вовремя . А "Заказ на закупку"... Кому это нужно?

Мне кажется, что проблема во многом в неадекватном переводе.

Не совсем согласен, PurchOrder - это элемент, не имеющий аналога в наших системах управления. Это наше намерение что-то у кого-то приобрести. Во что оно выльется - в общем случае не известно. Мы лишь понимаем, что нам это надо купить и поставить в такие-то сроки и фиксируем это понимание. А договор (контракт) на момент формирования PurchOrder может быть, можеть не быть. Он может быть рамочным или декларировать только, к примеру, цены. Если я правильно понял ваш термин "Договор с поставщиком".

Про Закупку с типом Контракт сейчас не говорим - это немного отдельная тема.

[Vals]

Цитата:

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

Уже много раз обсуждалось: заказы на покупку и продажу могут быть удалены как ручками так и стандартными функциями очистки и удаления (галки в параметрах).
Данные в заказе/ закупке должны изменяться по факту, иначе вы не с сможете распечатать соответствующие документы. Процедура работы и изменения заказов/закупок несколько отличается в версиях 4.0 и 2009.

Плановые данные (чего хотели, как договаривались и т.д. содержатся в проводках по предложениям, подтверждениям, счетам на оплату.

Цитата:

8.
Управляйте отклонениями. Регулярно формируйте список строк заказов на закупку, поставка по которым просрочена и акцентируйте свое внимание на этих заказах. Сопоставляйте плановые и фактические даты поставки, размеры партий для корректировки плановых значений при следующем цикле планирования закупок.

Хз как к этому относиться, вроде в общем всё верно, а применительно к системе раскрыто не до конца. В системе существует процедура обработки перепоставок и недопоставок. Существует соответствующий отчёт, который отображает отклонения.

По моему мнению в тезисах, если они относятся к системе, нужно делать ссылку на соответствующую функциональность системы.
Например:

Цитата:

исполнение платежей в соответствии с условиями оплат по заказам на закупку
на основании условий оплаты, определенных в заказах на закупку, формируются заявки на оплату авансовых платежей и платежей по факту поставки;

- Предложения по платежам.

Цитата:

уведомление о возможных изменениях в поставке
отражение взаимодействия с поставщиком — фиксация изменений в обещанных сроках поставки для оповещения подразделений-потребителей закупаемой продукции;

Где в системе? В данном случае в заказе изменится срок поставки и вы получаете противоречие с пунктом о невозможности редактирования заказа.

Цитата:

Не совсем согласен, PurchOrder - это элемент, не имеющий аналога в наших системах управления. Это наше намерение что-то у кого-то приобрести. Во что оно выльется - в общем случае не известно.

Вопрос интерпретации.

Цитата:

Если "Purchase Order" не калькировать дословно, а назвать так как он у нас называется "Договор с поставщиком", то люди будут вводить и регулярно, и вовремя

В четверёке я бы не согласился. А в 2009, когда предложения вынесли в... - да

Цитата:

Создавая заказ на закупку, расценивайте его, как элемент оперативного плана поставок, а номенклатурный перечень, объем и дату поставки — как плановые (ожидаемые или требуемые) значения, доступные для подразделений, потребность которых вы обеспечиваете.

Что делать со сводным планированием? Типом заказа Предложение? Как только вы создали заказ на покупку , вы получите проводки со статусом Заказано. Сводное этот статус интерпретирует как однозначную поставку. Какой же тут план поставок?

Цитата:

Заказ на закупку должен создаваться раньше или непосредственно перед первым обращением к поставщику. Именно с помощью заказа на закупку готовится Заявка на поставку — документ, который отправляется поставщику для согласования цен, сроков и объемов.

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

На самом деле я подробно этот момент обсосал в видео по тренингу логистика 1 часть. Надо бы выложить, а у большинства партнёров это видео есть.

[mazzy]

Цитата:

Сообщение от ds1678

Не совсем согласен, PurchOrder - это элемент, не имеющий аналога в наших системах управления.

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

У проклятых буржуинов все то же самое. Только называется по-другому.

Цитата:

Сообщение от ds1678

Это наше намерение что-то у кого-то приобрести. Во что оно выльется - в общем случае не известно. Мы лишь понимаем, что нам это надо купить и поставить в такие-то сроки и фиксируем это понимание.

Да, ради бога - неподписанный договор
Подписан юристами - меняется статус у Договора/Purchase Order...

От смены статуса контент не меняется.

Цитата:

Сообщение от ds1678

А договор (контракт) на момент формирования PurchOrder может быть, можеть не быть.

Как это не может быть?

Вы имеете в виду бумагу, на которой написано "Договор"?
Бумаги действительно может и не быть.

А вот договор между заказчиком и поставщиком - будет.
Если хотите точного термина - договоренность.
Если хотите древнего термина - завет.

Надо понимать, что договор имеет несколько статусов и стадий.
Вариант 1:
1.-1. мы испытываем потребность в чем то.
1.0. Мы ищем поставщика.

1.1. мы создаем проект договора (со строками и количеством)
1.2. отправляем поставщику на одобрение
... согласования с поставщиком...
... согласования с юристами... юристы переколбашивают шапку и юридическую часть, при этом не затрагивая суть договора (что именно, сколько и почем)
1.8. договор подписывается (появляется та самая бумажка с заголовком Договор)
1.9. (опционально) аванс
1.10. выполнение договора
1.11. Profit

Вариант 2:
2.-1. мы испытываем потребность в чем то (прогноз/Forecast)
2.0. Поставщик находит нас.

2.1. поставщик создает проект договора (со строками и количеством)
2.2. поставщик отправляет заказчику на одобрение
... (далее полный аналог варианта 1)

Вариант 3:
3.-1. мы испытываем потребность в чем то (прогноз/Forecast)
3.0. Мы находим поставщика или Поставщик находит нас.

3.1. устно договариваемся (создается проект договора со строками и количеством, но с пустой/дефолтной шапкой)
... согласования идут лесом...
... юристы идут лесом...
... бумажки с заголовком Договор идут лесом...
3.8. выписывается счет (это только кажется, что договора нет. А он есть! только неформальный)
3.9. (опционально) аванс
3.10. выполнение договора!!!!
3.11. Profit

===================
так вот.
шаг -1 - это еще не договор (и не Purchase Order) - мы знаем что, но не знаем у кого (это прогноз/Forecast).
начиная с шага 0 появляется договор (и Purchase Order).

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

и то, что еще нет бумажки с названием договор вовсе не означает, что договора нет.

И весь цимус как раз в том, что "намерение что-то у кого-то приобрести" - это Договор в своей начальной стадии (до всех возможных одобрений).
Если бы в системе Purchase Order так и назывался Договор - то его и воспринимали бы соответствующим образом, и заносили на ранних стадиях, и документооборот к нему прикручивали бы, и стадии, и одобрения...

Но раз эта штука называется "Заказ на закупку"... Кого волнует какой-то левый и никому не понятный "Заказ"?

Цитата:

Сообщение от ds1678

Если я правильно понял ваш термин "Договор с поставщиком".

Неправильно поняли.

[mazzy]

Цитата:

Сообщение от Vals

Вопрос интерпретации

И я об этом же

Vals, по-моему автор пока не заглубляется в особенности конкретной системы, а пытается обсуждать в целом системы ERP.

[ds1678]

Цитата:

Сообщение от mazzy

...

И весь цимус как раз в том, что "намерение что-то у кого-то приобрести" - это Договор в своей начальной стадии (до всех возможных одобрений).
Если бы в системе Purchase Order так и назывался Договор - то его и воспринимали бы соответствующим образом, и заносили на ранних стадиях, и документооборот к нему прикручивали бы, и стадии, и одобрения...

Но раз эта штука называется "Заказ на закупку"... Кого волнует какой-то левый и никому не понятный "Заказ"?


Неправильно поняли.

Теперь понял) И даже, не вдаваясь в детали, согласен. Только для этого вам пришлось сделать не меньше объяснений, чем мне. Словосочетание "Договор на поставку" может быть легко и другими людми интерпретировано "классически" - бумага подписями и печатями.

Дмитрий Гаврилов (автор небезызвестной книги по МРП2) в свое время постарался перевести все термины АПИКСа на русский. На мой взгляд, получилось примерно то же, что и в Аксапте - часть терминов даже после перевода все равно стается новой. Без долгих объяснение не обойтись.

Итого, имеем 3 пути - либо испорльзовать терминолуогию системы, либо терминологию стандарта, либы, как это предложили вы - адаптация имеющегося понятия. "Закупка" - термин Аксапта, "Заказ на закупку" - переведенный термин МРП2, "Договор на поставку" - адаптированный термин.

[Zabr]

цитата из первой статьи:

Цитата:

В среде узко-понимающих консультантов, а вслед за ними — у конечных пользователей, бытует мнение, что «Заказ на закупку — это элемент системы, с помощью которого можно отразить приходные документы, счета-фактуры и сформировать задолженность по поставке.»

Хм. наверное, мы с вами в разных каких-то мирах живем. Статья написана так, как будто указанное выше мнение обычно выражают 90% людей. Но мне почему-то такое мнение встречалось как раз крайне редко, как среди консультантов, так и среди пользователей. 90% людей как раз на 90% правильно понимает что такое заказ.

PS догадка: может быть дело в том что я никогда не работал с 1С?

[mazzy]

Цитата:

Сообщение от ds1678

Теперь понял) И даже, не вдаваясь в детали, согласен. Только для этого вам пришлось сделать не меньше объяснений, чем мне. Словосочетание "Договор на поставку" может быть легко и другими людми интерпретировано "классически" - бумага подписями и печатями.

Ок. Пусть будет "Договоренность"
Но это совсем необщеупотребительный термин.

Цитата:

Сообщение от ds1678

Итого, имеем 3 пути - либо испорльзовать терминолуогию системы, либо терминологию стандарта, либы, как это предложили вы - адаптация имеющегося понятия. "Закупка" - термин Аксапта, "Заказ на закупку" - переведенный термин МРП2, "Договор на поставку" - адаптированный термин.

Есть еще один путь - объяснять суть.
То, что пытаетесь делать вы.

Единственное чего ни в коем случае нельзя допускать - это считать что наши люди саботируют эти проклятобуржуйские системы. Тезис "Как угодно, только не в ERP-системе" - категорически неправильный. И вредный для понимания сути, по-моему. Люди просто не понимают как сущности из этих систем-на-три-буквы соотносятся с их повседневной деятельностью. И это проблема не людей, а вендора и внедренцев.

Не стоит также считать, что у нашего учета есть что-то особенное. Не стоит также считать, что у них есть что-то такое, чего у нас нет.

Есть и еще один путь - вводить в употребление правильные термины. Не боги горшки обжигают.
http://multitran.ru/c/m.exe?CL=1&l1=1&s=purchase+order

[mazzy]

Цитата:

Сообщение от ds1678

С вашего позволения:
О правильном использовании заказа на закупку в ERP-системе

С вашего позволения, комментарии к вашим рекомендациям:

Цитата:

Как правильно использовать заказы на закупку в ERP-системе?

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

1.
Создавая заказ на закупку, расценивайте его, как элемент оперативного плана поставок, а номенклатурный перечень, объем и дату поставки — как плановые (ожидаемые или требуемые) значения, доступные для подразделений, потребность которых вы обеспечиваете.

Нет, ни в коем случае не путайте оперативный план (прогноз/Forecast) и заказ.
Оперативный план (прогноз/Forecast) показывает что и когда нам нужно. Но почти никогда он не содержит у кого и почем. Выполнить оперативный план можно не только закупкой, но и перемещением между своими складами, а также производством.

А вот когда мы решили, что оперативный план будет выполняться именно закупкой. А также решили какой поставщик будет, то возникает Договор с поставщиком (Договоренность/Purchase Order).

Этот договор проходит несколько стадий согласования/утверждения перед выполнением.

Важно: Purchase Order - НЕ оперативный план.

Цитата:

2.
Заказ на закупку должен создаваться раньше или непосредственно перед первым обращением к поставщику. Именно с помощью заказа на закупку готовится Заявка на поставку — документ, который отправляется поставщику для согласования цен, сроков и объемов.

ДА!
Заказ на закупку - это договор/договоренность с поставщиком.

Цитата:

3.
Различайте требуемые и согласованные с поставщиком даты поставки. Требуемая дата поставки говорит о том, когда бы нам хотелось привезти товар, чтобы удовлетворить имеющийся спрос вовремя. Согласованная с поставщиком дата поставки — о том, когда это может сделать поставщик.

ДА! одна дата - из оперативного плана. вторая дата - из договоренности с поставщиком.

Цитата:

В заказе на закупку следует отражать обе даты.

Ни в коем случае!
Скорее из строк договоренности с поставщиком должны быть ссылки на строки оперативного плана. Тогда сопоставлять/сравнивать можно будет не только даты, но и массу других параметров.

Цитата:

4.
По возможности указывайте в заказах на закупку условия оплаты, согласованные с поставщиком. Это позволит создавать актуальный платежный календарь и эффективно управлять cash-flow по закупкам.

Воспринимайте Purchase Order как Договор/Договоренность с поставщиком.
Указывайте все параметры Договора/Договоренности в Purchase Order.
Это позволит эффективно управлять ВСЕМ (!), что связано с закупками.

Цитата:

5.
Не корректируйте заказ на закупку на основании приходных документов.

ДА!
Как обычно не корректируется договор (конечно, бывают исключения).
Изменения должны проходить доп.соглашениями/приложениями и т.п.

Цитата:

Помните — в заказе — ваши плановые значения, в приходном документе — фактические.

Тут даже сложнее.
Данные оперативного плана - в прогнозах.
Данные из договоренностей с поставщиками - в Purchase Order.
Фактические данные - в приходных документах.
Все данные можно сравнить и проанализировать.

Цитата:

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

ДА!

Цитата:

7.
Назначьте показатели эффективности

ДА!!!

Цитата:

8.
Управляйте отклонениями.

ДА!!!!!!

[ds1678]

Как уже отметили, это статья, посвящена заказу на закупку, как элементу ERP-, а точнее, MRPII-системы, не вдаваясь в специфику реализации конкретного программного продукта. Однако, в голове у меня, в первую очередь, сидит именно функциональность DAX (отмечу, что так же я неплохо изучил функциональность САП, знаком с ДжиДиЭдвардсом - основы везде одинаковые).Попробую интерпретировать свои тезисы в функциаональность Аксапты, отвечая на ваши реплики...

Цитата:

Сообщение от Vals

Уже много раз обсуждалось: заказы на покупку и продажу могут быть удалены как ручками так и стандартными функциями очистки и удаления (галки в параметрах).

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

Цитата:

Сообщение от Vals

Данные в заказе/ закупке должны изменяться по факту, иначе вы не сможете распечатать соответствующие документы. Процедура работы и изменения заказов/закупок несколько отличается в версиях 4.0 и 2009.

Используем количество к поставке и - вуаля! Если параметры номенклатуры или строк закупки допускают недо-, перепоставку, то вы можете сформировать документы (накладные) как на большее, так и на меньшее количество. Не могу сослаться на тренинг, я все больше изучал Аксапту по апиксовским материалам, по принципу "Описано в MRPII - скорее всего, есть в Аксапте, ищем!".
Если в закупке с недопоставкой приходов больше не ожидается, есть возможность (функция) обнулить оставшееся количество к поставке (закладка Количество), не изменяя количество в закупке. При этом затирается оставшаяся "открытая" проводка по номенклатуре, чтобы сводное планирование не приняло ее за ожидаемый приход.

Цитата:

Сообщение от Vals

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

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

Цитата:

Сообщение от Vals

Где в системе? В данном случае в заказе изменится срок поставки и вы получаете противоречие с пунктом о невозможности редактирования заказа.

Для этого и заведено 2 даты: Дата поставки и Подтверждено. Дату поставки сохраняем неизменной, она фиксирует, когда нам нужна была это строка. Подтверждено – дата поставщика, она может актуализироваться сколь угодно много раз. Если она заполнена, то именно она вместо Даты поставки попадает в строку проводки (в поле Ожидаемая дата) по номенклатуре и все вокруг видят, когда это ожидается к приходу. Через проводки.

Цитата:

Сообщение от Vals

Что делать со сводным планированием? Типом заказа Предложение? Как только вы создали заказ на покупку, вы получите проводки со статусом Заказано. Сводное этот статус интерпретирует как однозначную поставку. Какой же тут план поставок?

Сводное планирование видит проводку по закупке (в статусе Заказано) и резонно ожидает приход. Все верно. Только здесь, часто в условиях нестабильных отношений с поставщиками, начинаются серьезные отклонения. Срывы сроков поставки, брак в поставке, отклонения в количестве. Поэтому закупка – элемент самого нижнего, оперативного плана, и остается таковой до момента закрытия. Уточненная дата Подтверждено даст информацию сводному плану об актуальной ожидаемой дате поставки. На мой взгляд, только с таким подходом, можно выровнять отношения с поставщиками и добиться большей стабильности в поставках. А это залог того, что ваш сводный (MRP, детальный, объемно-календарный) план будет более актуален и стабилен.
А Журнал, Предложение – это некие нюансы реализации. Вы можете использовать черновой вариант, не учитываемый сводным планом вообще, можете использовать статус Предложение для неподтвержденных закупок, и учитывать его в некоторых сценариях планирования, а можете использовать Закупку с механизмом «Обработка – Заявка» для отражения согласования с поставщиком. Я бы рекомендовал использовать Предложение, когда это позволяет делать цикл поставки (время упреждения). А как только наступает дата Х, когда необходимо размещать заказ, чтобы успеть во время, переводил в статус Закупка.

[Atar]

Цитата:

Сообщение от mazzy

Если хотите точного термина - договоренность.
Если хотите древнего термина - завет.

Тогда уж "потребность в поставке" или "требование поставки".
Ибо ни договора, ни договоренности ещё нет, когда нужно "заказ" вводить в систему.

PS. Или вот на multitran.ru интересный перевод: "Закупочная ведомость".

[Vals]

Цитата:

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

Я лишь хотел сказать, что это стандартный отчёт

Цитата:

Для этого и заведено 2 даты: Дата поставки и Подтверждено. Дату поставки сохраняем неизменной, она фиксирует, когда нам нужна была это строка. Подтверждено – дата поставщика, она может актуализироваться сколь угодно много раз.

История изменений где?

На самом деле основной тезис "ЛикБеза" а поддерживаю.

[Atar]

Цитата:

Сообщение от ds1678

Для этого и заведено 2 даты: Дата поставки и Подтверждено. Дату поставки сохраняем неизменной, она фиксирует, когда нам нужна была это строка. Подтверждено – дата поставщика, она может актуализироваться сколь угодно много раз. Если она заполнена, то именно она вместо Даты поставки попадает в строку проводки (в поле Ожидаемая дата) по номенклатуре и все вокруг видят, когда это ожидается к приходу. Через проводки.

Согласен с mazzy, в "Дату поставки" следует заносить не дату потребности (она не имеет отношения к заказу у этого конкретного поставщика), а согласованную (или сначала - согласуемую) дату поставки. А уже при отслеживании сроков поставки можно постоянно актуализировать "Подтвержденную дату поставки" для корректного планирования. Тут как раз и появляется возможность анализа отклонений от договора.

Цитата:

Сообщение от Vals

На самом деле основной тезис "ЛикБеза" а поддерживаю.

Ага, ага!

[ds1678]

Уважаемые коллеги, не ожидал такого бурного обсуждения, честное слово!

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

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

Внимательно читаю все, что вы написали. Спасибо огромное!

[ds1678]

Цитата:

Сообщение от Vals

Я лишь хотел сказать, что это стандартный отчёт

Отчета по работе со всеми 4-мя датами (создание, поставки, обещанная, фактическая), да с у четом времени упреждения, в 3-ке точно нет. Забыл указать важный нюанс: в первое время важно контролировать своевременность создания закупок, чтобы их не открывали только в момент прихода. Все функции по контролю дат объеденены в один общий сборщик данных.

Цитата:

Сообщение от Vals

История изменений где?

История изменений - ИМХО, дело не очень благородное. Достаточно видеть разницу между требуемой и обещанной датой поставки. Это 90% необходимого. А почти все виды историй с огромным массивом данных, это дата-дрочеринг (извините за мой французский). Не поддерживаю.

[Aleck]

Цитата:

Сообщение от ds1678

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

К старым советским учебникам по оперативному планированию и управлению производством. Тогда будет еще больше чудных открытий по терминологии, в частности как еще с 30-х годов прошлого века в этой стране назывался аналог буржуинского MRP.

[ds1678]

Цитата:

Сообщение от Atar

Согласен с mazzy, в "Дату поставки" следует заносить не дату потребности (она не имеет отношения к заказу у этого конкретного поставщика), а согласованную (или сначала - согласуемую) дату поставки. А уже при отслеживании сроков поставки можно постоянно актуализировать "Подтвержденную дату поставки" для корректного планирования. Тут как раз и появляется возможность анализа отклонений от договора.

Правда и моя, и ваша, коллеги. Тут все завит от целей, которые мы преследуем. Совсем недавно ознакомился с одним новым правилом уровня сервиса. Выглядит просто:

90-95-98-95-98

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

Подтвержденная дата поставки при этом используется нами одинаково, разница лишь в том, как интерпретировать Дату поставки.