Новый ландшафт систем автоматизации

Наряду с хорошо известными MRP, ERP и им подобными ландшафт средств автоматизации относительно недавно пополнился множеством непривычных аббревиатур. Среди них стали весьма популярны PLM, EAM, SCP, MES, которые весьма активно вытесняют привычные сокращения, образуя совершенно новую синтетическую сущность, которую аналитики все чаще называют ERP II. Попытаемся разобраться в сущности этих понятий и их взаимосвязи, показав образованный ими новый ландшафт интегрированной системы управления, принципиально отличающийся от привычного ландшафта ERP.

примечание:Сергей Колесников
директор по консалтингу компании "Экон-профи" (Москва).
Журнал "Открытые системы", #06, 2003 год

Прежде вспомним историю систем ERP-систем. Они были ориентированы на поддержку функционального управления предприятием - на автоматизацию отдельных процессов производства, финансов, сбыта, продаж, закупок и и.п. В первую очередь, подобные системы были предназначены для решения главной задачи данного функционального блока - планирования производства. Это предполагает, в частности, расчет потребности в материалах (MRP), затем расчет выполнимости производственного плана (CRP), ведение счетов для финансового блока, и так далее. При этом преимущественно предполагалось, что бизнес построен на производстве как на основе, а все остальное в значительной степени является обслуживающими процессами, из которых наиважнейшим является управление финансами. В момент возникновения программных продуктов категории MRP II, что соответствует началу 90-х годов, это предположение было неверно лишь для очень крупных компаний, где логистическое обеспечение продаж давно стало самостоятельной задачей. Однако ввиду уникальности процессов, ныне известных как управление логистическими цепочками, задача эта решалась при помощи столь же уникальных заказных продуктов; многие из них работают до сих пор. Обмен информацией (так называемые "заказы") между функциональными блоками осуществлялся на основе документов ("первичка"), что полностью соответствует стандартной отечественной практике. Соответственно планирование выполнялось, а исполнение реализовывалось только внутри одного блока, хотя бы и очень большого (например, MRP II). При этом существенную проблему представляла, да и представляет до нынешнего дня, интеграция подобных "документоориентированных" систем в единую информационно-аналитическую систему. Одной из существенных причин таких проблем является необходимость поддержки разнообразного документооборота для отдельных типов товарно-материальных ценностей в системах, ориентированных на функциональное управление, особенно в ситуациях, когда необходима "сквозная" поддержка определенных процессов или аналитических "срезов".

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

Целевая интеграция логистических, производственных и других функциональных систем, включая финансы и управление персоналом, сначала получила название COMMS (CSRP), а позднее была названа SCM ("управление логистическими цепочками"), под которым ныне и получила широкую известность (рис. 1). Любопытно, что разделение этих названий связано с разделением непосредственного и косвенного производителя ("брэнда"), так как первые были ориентированы практически только на заказное производство (единичное, в стандартной российской терминологии), а вторые - на любой тип производства, в том числе и на массовые брэнды. Учетной единицей в данных системах является не документ, а транзакция, которая связывает заказ конечного клиента (документ) и процесс его выполнения, глубиной "назад", возможно до заказа поставщику поставщика и глубже и "вперед" - до окончания поставки и/или жизненного цикла изделия. Физическими участниками транзакции могут быть почти исключительно "третьи" компании.

Принципиально важно отличать управление логистическими цепочками, ориентированное на полный сбытовой цикл, и действия, ориентированные на управление ячейками такого цикла. Очень показательный пример - производитель-субподрядчик в составе брэнда. Такого рода логистический менеджмент получил название "взаимодействующий бизнес" (collaborative business), а соответствующая система планирования - collaborative planning, и, наконец, соответствующая такого рода организации бизнеса программная система поддержки логистики - PRM. Типы транзакций в обоих случаях различны. Если в первом управляется "полная транзакция", включающая все операции логистической системы, то во втором - "частичная", но принципиально являющаяся элементом транзакции управляющей "большой" логистической цепочкой компании.

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

Рис. 2. Жизненный цикл изделия в системе качества

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

Следующая задача - это управление активами. Функциональность для управления активами получила название EAM. Задача, решаемая в рамках транзакции "использования актива" в чем-то аналогична транзакции "жизненного цикла", и может быть названа "жизненным циклом актива". Системы PLM и EAM тесно пересекаются, скажем, на уровне цеха, где система управления цеховыми заданиями (или диспетчирования, MES) используя для производства определенной заказом клиента продукции конкретное оборудование, оснастку или инструмент, одновременно дает EAM основания для его амортизации или обслуживания в соответствии по мере использования. EAM, в свою очередь, предоставляет MES график ремонтов или обслуживания в соответствии с сервисным листом. Взаимодействие MES с PLM и SCP достаточно очевидно и хорошо известно. Заметим, что в случае единичного производства, SCP вынуждена для точного определения времени завершения заказа и планирования последующих логистических операций обращаться именно к MES, CRP в этом случае принципиально недостаточно, и в этом случае она, если и применяется, то только для чернового планирования или просчета месячных прогнозов.

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

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

В свою очередь, инструментарий ERP II предназначен для поддержки интегрированной логистической системы, или обособленного элемента такой системы (рис. 1). Типичным покупателем такой системы является компания, продукция которой попадает, по крайней мере, под одно из определений: малое время стадии "нахождение на рынке" - менее одного года; заказной характер производства или закупок; очень высокая дифференциация и высокая чувствительность к "движениям рынка" (малое время реакции логистической системы на изменение потребительских предпочтений).

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

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

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

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

Рис. 4. Транзакционные расширения ERP

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

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

Транзакционный характер планирования и исполнения накладывает существенную специфику на реализацию программного продукта. Практически все подсистемы, кроме интерфейсных, требуют учета уже на стадии разработки специфики конкретного бизнеса, т. е. они должны быть ориентированы на конкретный вертикальный рынок. Что же касается интерфейсных систем, то они, как правило, требуют специфической доработки или настройки под конкретное предприятие, часто являясь полузаказными. Это разрушает иллюзию "универсальности" ERP-системы. Более того, PLM-система должна быть ориентирована на управление жизненным циклом конкретного типа продукции, а не дискретной продукцией вообще, либо должна также подвергаться глубокой настройке. Иначе, в рамках MRP II предприятия одного типа и вида производства имели бы идентичную функциональность и систему планирования. Но с точки зрения управления жизненным циклом они существенно различаются. Управление активами, образующими ИТ-инфраструктуру подразделения крупной компании и дачного поселка, хотя и похожи функционально, но принципиально отличаются с точки зрения EAM - предоставляемые ими услуги и их оценка связаны с совершенно различными процессами.

Опыт внедрения ERP в России полностью подтверждает эту практику, и более того, большинство неудач связано как раз с принципиальными ошибками при выборе "вертикально чувствительного" программного обеспечения, как например, попытки внедрить на непрерывном производстве MRP II. Проблемы, даже не с автоматизацией, а просто с бюджетированием холдингов также связаны с транзакционным характером финансовых и логистических операций в рамках холдинга. Бюджетирование же транзакционной системы, хотя и сходно по функциональной структуре с документоориентированной, но принципиально отличается по процессам и последовательности действий. К сожалению, на отечественном рынке практически не представлены наиболее современные продукты большинства типов транзакционных систем, а в отечественных системах поддержка транзакций, как правило, принципиально невозможна.

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

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

Стандарты ISO 9000:2000 предписывают не только функциональный контроль и "прослеживаемость" на протяжении всего жизненного цикла, но и управление полной себестоимостью продукции, с учетом затрат функционального жизненного цикла. Решения, предназначенные для поддержки функционального жизненного цикла, получили название PLM.

Сокращения