MRP (Material Requirement Planning) – планирование потребностей в материалах и ресурсах

Концепция Material Resource Planning (MRP) (конец 60-х) обеспечивала планирование потребностей предприятий в материалах. Преимущество - минимизация издержек, связанных со складскими запасами сырья, комплектующих, полуфабрикатов и прочего, а также с аналогичными запасами, находящимися на различных участках непосредственно в производстве.

В основе MRP лежит понятие Bill Of Material (BOM), то есть спецификации изделия, которая показывает зависимость внутреннего для предприятия спроса на сырье, комплектующие, полуфабрикаты и т.д. от плана выпуска (бюджета реализации) готовой продукции.

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

   1. логике зависимого спроса, т.е. если есть потребность в конечном изделии, значит есть потребность во всех его компонентах;

   2. обеспечивать требуемые компоненты как можно позднее, чтобы уровень запасов был минимальным.

На практике MRP-система представляет собой компьютерную программу, которая логически может быть представлена при помощи следующей диаграммы:

На приведенной выше диаграмме отображены основные информационные элементы MRP-системы. Итак, опишем основные входные элементы MRP-системы:

1. Описание состояния материалов (Inventory Status File) является основным входным элементом MRP-программы. В нем должна быть отражена максимально полная информация о всех материалах-комплектующих, необходимых для производства конечного продукта. В этом элементе должен быть указан статус каждого материала, определяющий, имеется ли он на руках, на складе, в текущих заказах или его заказ только планируется, а также описания, его запасов, расположения, цены, возможных задержек поставок, реквизитов поставщиков. Информация по всем вышеперечисленным позициям должна быть заложена отдельно по каждому материалу, участвующему в производственном процессе.
2. Программа производства (Master Production Schedule) представляет собой оптимизированный график распределения времени для производства необходимой партии готовой продукции за планируемый период или диапазон периодов. Сначала создается пробная программа производства, впоследствии тестируемая на выполнимость дополнительно прогоном через CRP-систему (Capacity Requirements Planning), которая определяет достаточно ли производственных мощностей для ее осуществления. Если производственная программа признана выполнимой, то она автоматически формируется в основную и становится входным элементом MRP-системы. Это необходимо потому как рамки требований по производственным ресурсам являются прозрачными для MRP-системы, которая формирует на основе производственной программы график возникновения потребностей в материалах. Однако, в случае недоступности ряда материалов, или невозможности выполнить план заказов, необходимый для поддержания реализуемой с точки зрения CPR производственной программы, MRP-система в свою очередь указывает о необходимости внести в нее корректировки.
3. Перечень составляющих конечного продукта (Bills of Material File) -- это список материалов и их количество, требуемое для производства конечного продукта. Таким образом, каждый конечный продукт имеет свой перечень составляющих. Кроме того, здесь содержится описание структуры конечного продукта, т.е. он содержит в себе полную информацию по технологии его сборки. Чрезвычайно важно поддерживать точность всех записей в этом элементе и соответственно корректировать их всякий раз при внесении изменений в структуру и\или технологию производства конечного продукта.
4. План Заказов (Planned Order Schedule) определяет, какое количество каждого материала должно быть заказано в каждый рассматриваемый период времени в течение срока планирования. План заказов является руководством для дальнейшей работы с поставщиками и, в частности, определяет производственную программу для внутреннего производства комплектующих, при наличии такового.
5. Изменения к плану заказов (Changes in planned orders) являются модификациями к ранее спланированным заказам. Ряд заказов могут быть отменены, изменены или задержаны, а также перенесены на другой период.
6. Отчет об "узких местах" планирования (Exception report) предназначен для того, чтобы заблаговременно проинформировать пользователя о промежутках времени в течение срока планирования, которые требуют особого внимания, и в которые может возникнуть необходимость внешнего управленческого вмешательства. Типичными примерами ситуаций, которые должны быть отражены в этом отчете могут быть непредвиденно запоздавшие заказы на комплектующие, избытки комплектующих на складах и т.п.
7. Исполнительный отчет (Performance Report) является основным индикатором правильности работы MRP-системы и имеет целью оповещать пользователя о возникших критических ситуациях в процессе планирования, таких как, например, полное израсходование страховых запасов по отдельным комплектующим, а также о всех возникающих системных ошибках в процессе работы MRP-программы.
8. Отчет о прогнозах (Planning Report) представляет собой информацию, используемую для составления прогнозов о возможном будущем изменении объемов и характеристик выпускаемой продукции, полученную в результате анализа текущего хода производственного процесса и отчетах о продажах. Также отчет о прогнозах может использоваться для долгосрочного планирования потребностей в материалах.

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

На главную

КИС должны отвечать целому набору обязательных требований:

1. Среди них, в первую очередь, стоит отметить использование архитектуры клиент-сервер с возможностью применения большинства промышленных СУБД

2. Поддержку распределенной обработки информации

3. Модульный принцип построения из оперативно-независимых функциональных блоков с расширением за счет открытых стандартов (API, COM+, CORBA и другие)

4. Обеспечивать поддержку технологий Internet/intranet.

5. Гибкость

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

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

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

Вместе с тем возникает риск применения устаревших решений при модернизации системы. Рекомендация в таком случае одна — внимательнее относиться к подбо­ру разработчиков информационных систем.

6. Надежность

Надежность информационной системы подразумевает ее функционирование без искажения информации, потери данных по «техническим причинам». Требование надежности обеспечивается созданием резервных копий хранимой информации, выполнения операций протоколирования, поддержанием качества каналов связи' и физических носителей информации, использованием современных программных и аппаратных средств. Сюда же следует отнести защиту от случайных потерь информации в силу недостаточной квалификации персонала.

7. Эффективность

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

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

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

Активное сотрудничество с заказчиком с ранних этапов проектирования позволяет уточнить потребности заказчика. Часто встречается ситуация, когда заказчик чего-то хочет, но сам не знает чего именно. Чем раньше будут учтены дополнения заказчика, тем с меньшими затратами и в более короткие сроки система будет создана.

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

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

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

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

8. Безопасность

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

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

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

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

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

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

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

И наконец, самый важный фактор, влияющий на процесс разработки, — знания и опыт коллектива разработчиков информационных систем.

На главную

Архитектура КИС

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

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

Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture) (рис. 3.1).

Рисунок 3.1 - Двухуровневая клиент-серверная архитектура

Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей - автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и другие. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает множеством недостатков, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе.

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

Рисунок 3.2 - Трехуровневая клиент-серверная архитектура (Three-tier architecture)

Плюсы данной архитектуры очевидны. Благодаря концентрации бизнес-логики на сервере приложений, стало возможно подключать различные БД. Теперь, сервер базы данных освобожден от задач распараллеливания работы между различными пользователями, что существенно снижает его аппаратные требования. Также снизились требования к клиентским машинам за счет выполнения ресурсоемких операций сервером приложений и решающих теперь только задачи визуализации данных. Именно поэтому такую схему построения информационных систем часто называют архитектурой “тонкого” клиента.

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

Существует еще один важный момент использования систем, построенных на такой архитектуре. Самый верхний уровень (АРМы), в целом обладающий огромной вычислительной мощностью, на самом деле простаивает, занимаясь лишь выводом информации на экран пользователя. Так почему бы не использовать этот потенциал в работе всей системы? Рассмотрим следующую архитектуру(Рис. 3.3) которая позволяет решить эту задачу.

Рисунок 3.3 - Распределенная архитектура системы

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

Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизиться. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.

Каждый АРМ независим, содержит только ту информацию, с которой должен работать, а актуальность данных во всей системе обеспечивается благодаря непрерывному обмену сообщениями с другими АРМами. Обмен сообщениями между АРМами может быть реализован различными способами, от отправки данных по электронной почте до передачи данных по сетям.

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

Такая архитектура системы также позволяет организовать распределенные вычисления между клиентскими машинами. Например, расчет какой-либо задачи, требующей больших вычислений, можно распределить между соседними АРМами благодаря тому, что они, как правило, обладают одной информацией в своих БД и, таким образом, добиться максимальной производительности системы.

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

На главную

MRP II (Manufacturing Resource Planning) – планирование производственных ресурсов

MRPII - Manufacturing Resource Planning (планирование производственных ресурсов) - это специально разработанный набор методов управления бизнесом, которые поддерживаются вычислительными системами.

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

Функции КИС стандарта MRP II:

1. Планирование продаж и производства

2. Управление спросом

3. Составление плана производства

4. Планирование потребностей в материалах

5. Спецификация продуктов

6. Управление складом

7. Плановые поставки

8. Управление на уровне производственного цеха

9. Планирование производственных мощностей

10. Контроль входа/выхода

11. Материально-техническое снабжение

12. Планирование распределения ресурсов

13. Планирование и контроль производственных операций

14. Финансовое планирование

15. Моделирование

16. Оценка результатов деятельности

Обычно MRPII применяется на производственных предприятиях, в чисто коммерческих предприятиях аналогичную функцию выполняют системы DRP (планирование ресурсов для управления коммерческой деятельностью). В общем виде система управления предприятием, построенная в соответствии со стандартом MRPII, имеет следующий вид (рисунок 1):

Бизнес-планирование. 

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

Планирование спроса. 

Процесс прогнозирования (планирования) спроса на определенный период (как правило, на квартал или на год).

Планирование продаж и производства. 

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

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

План-график выпуска продукции. 

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

Планирование потребностей в материальных ресурсах. 

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

Планирование производственных мощностей.

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

Управление заказами клиентов. 

Здесь реальные потребности клиентов сопоставляются с планами выпуска продукции.

Управление на уровне производственного цеха. 

Здесь формируются оперативные планы-графики. В качестве планово-учетных единиц могут выступать детали (партии), сборочные единицы глубокого уровня, детале-(партие) операции и т. п. Длительность планирования невелика (от нескольких дней до месяца).

Оценка исполнения. 

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

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

1. Что необходимо выполнить?

2. Что необходимо для этого?

3. Что есть в наличии?

4. Что необходимо иметь?

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

На главную

CSRP (Customer Synchronized Resource Planning) – планирование ресурсов организации, синхронизированное на потребителя

CSRP - Управление, ориентированное на взаимодействие с клиентами: включает получение заказов, разработку планов, проектов и заданий, техподдержку. Планирование ресурсов, синхронизированное с покупателем. 

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

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

Системы класса CRM зачастую интегрируют с системами управления предприятием (такими как MRPII, ERP), однако даже такое детальное ведение всей маркетинговой информации может не дать того эффекта, который ожидается со стороны топ-менеджмента предприятия.

Более современной концепцией управления ресурсами предприятия является CSRP (customer synchronized resource planning, планирование ресурсов, синхронизированное с клиентом), захватывающая почти весь жизненный цикл товара. Такой подход позволяет на порядок точнее управлять стомостью товара, учитывая производство, продвижение и обслуживание товара данного типа, и учитывать все элементы его функционального жизненного цикла, а не только производства, как во всех стандартных системах предыдущих поколений.

Термин «CSRP» впервые определяется в документах компании SYMIX, которая также первая предложила на рынке комплекс программных продуктов, реализующих уровеньCSRP. 

Сущность концепции CSRP состоит в том, что при планировании и управлении компанией можно и нужно учитывать не только основные производственные и материальные ресурсы предприятия, но и все те, которые обычно рассматриваются как «вспомогательные» или «накладные».

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

CSRP - это первая бизнес методология, которая интегрирует деятельность предприятия, ориентированную на покупателе, в центр системы управления бизнесом.

CSRP устанавливает методологию ведения бизнеса, основанную на текущей информации о покупателе. CSRP сдвигает фокус предприятия с планирования от потребностей производства к планированию от заказов покупателей. Информация о покупателях и услуги вплавляются в основу организации (смотри рисунок D). Деятельность по производственному планированию не просто расширяется, а удаляется и заменяется запросами покупателей, переданными из подразделений организации, ориентированных на работу с покупателями.

CSRP переопределяет практику бизнеса, фокусируя ее на рыночной активности, а не на производственной деятельности. Бизнес-процессы синхронизируются с деятельностью покупателей.

На главную