Автоматизация без дураков
Александра Гнатуш, журнал "IT Manager" #14(2)/2004
Автоматизация бизнес-процессов – термин, который на слуху уже не первый год. Обещая баснословную прибыль, многочисленные «автоматизаторы» внедряют под знаменем новейших технологий разнообразные решения, призванные повысить эффективность бизнеса своего клиента. И часто это происходит так, что клиент слабо ориентируется, как же происходит процесс внедрения, а фирмы, осуществляющие внедрение, не утруждают себя, чтобы сделать автоматизацию хоть сколько-нибудь прозрачной. Данный материал поможет устранить некоторые пробелы в понимании того, что же скрывается за словами «процесс внедрения АСУ».
Итак, вы решили внедрить на своем предприятии систему автоматизации бизнес-процессов. Прежде чем искать исполнителя, нужно уяснить некоторые принципиальные моменты. Главный из них – внедрение должно быть действительно необходимо, то есть иметь экономическое обоснование. При этом речь может идти об автоматизации бизнес-процессов, тогда его цель — повышение надежности и оперативности предоставления информации и выделение большего времени сотрудников на ее анализ, а не на обработку. Кроме того, цель автоматизации может состоять в реорганизации бизнес-процессов. В любом случае стоимость внедрения достигает 1-2% от месячного оборота компании (разумеется, речь идет о комплексной автоматизации). Если же бизнес-цели не ясны или бюджет вашего предприятия просто не выдержит рыночной цены внедрения, то лучший выход — отложить подобное мероприятие.
Следует понимать, что внедрение не сводится к покупке коробки. Любое программное обеспечение требует поддержки, и деловое – в особенности. Обновления, связанные с изменениями законодательства, корректировка отдельных моментов учета или кардинальная перестройка процессов, вызванная ростом или реорганизацией предприятия, – все это должно входить в услугу поддержки и сопровождения внедряемого решения.
Важный момент состоит в том, что самостоятельное внедрение так же эффективно, как и самолечение. Простых областей учета и управления нет. На изучение и кодирование потребуются месяцы и годы работы. Так что уж лучше сразу решить, что эффективнее - доверить внедрение опытному «врачу», или путем собственных проб и ошибок добиваться призрачных целей. Кроме того, вам нужны не контрагенты, а союзники. Организация, осуществляющая внедрение, должна быть не только безукоризненна в профессиональном отношении, вы, прежде всего, должны доверять ей. Речь идет не только о той информации о вашей компании, которая станет доступной данной организации в процессе внедрения. Во внедрение обязательно будут вовлечены руководство и предметные специалисты, обязательно появятся разного рода проблемы, поэтому вам необходима уверенность, что вас не обманут.
Фаза анализа
Для начала попытаемся разобраться, зачем вообще нужна фаза анализа. Здесь все достаточно просто: нам необходимо понять, достигнута ли цель, и выявить факторы, способствующие или препятствующие этому. Анализ нужен, чтобы определить сильные/слабые стороны бизнеса. Причем следует помнить как о субъективных, так и об объективных факторах.
Любой бизнес имеет бюджетную и операциональную составляющие. Бюджетный план и план мероприятий нельзя однозначно выразить друг через друга, но система управления должна учитывать это. В обязательном порядке анализу подлежат как бюджетная, так и операциональная составляющая бизнеса. Ошибка на данном этапе приводит к неправильным (недостижимым) целям на следующем витке цикла. В лучшем случае — потеря денег, в худшем — потеря клиента.
Для того чтобы все вышесказанное обобщить, рассмотрим два конкретных примера.
1. Компания Y занималась крупной оптово-розничной торговлей товарами определенной группы. Перед топ-менеджерами была поставлена задача увеличения прибыли. Топ-менеджеры решили выяснить, какие товарные позиции приносят большую прибыль. Через месяц они это выяснили и решили убрать плохо продающиеся товары. Затем они выбрали несколько самых ходовых позиций и увеличили по ним закупки, а от остальных отказались. В результате компания осталась без ассортиментных позиций. При отсутствии ассортиментного минимума резко снизились продажи и самых ходовых товаров — их стали покупать у конкурентов.
2. Компания Z занималась крупной оптово-розничной торговлей товарами, импортируемыми из-за границы. Так же, как и в предыдущем примере, перед топ-менеджерами была поставлена задача увеличения прибыли. Рынок к этому моменту уже устоялся, и топ-менеджеры решили, что единственная возможность качественного улучшения ситуации находится не на уровне бюджетных решений (увеличение числа и пропускной способности каналов поставок, конкурентное снижение отпускных цен и т. д.). Следующим их шагом был анализ выполнения всей логистической цепочки доставки товара:
Определение и согласование параметров заказываемого товара с продающими филиалами. Заказ товара у поставщика. Отправка заказанного товара поставщиком. Прибытие товара на таможню. Доставка до центрального склада. Контроль качества и определение условий хранения. Доставка до филиала или местного склада. Продажа.
В результате анализа деятельности предприятия за предыдущий период выяснилось следующее: периодически возникала ситуация, когда закупаемый товар по своим характеристикам (номенклатура, размер и проч.) существенно отличался от заказываемого филиалами. Это приводило к серьезным проблемам и потерям в сбыте.
Было решено ввести еще один этап (между этапами 2 и 3). Этим новым звеном стал этап Согласования. Появились две новые должности:
1) менеджер, отвечающий за согласование отклонений с поставщиком. Он несет ответственность за то, что поступит именно согласованный товар;
2) менеджер, отвечающий за то, что согласованный товар будет востребован и продан филиалом.
Этого оказалось достаточно для существенного сокращения потерь.
Фаза контроля
Контроль является выбором системы стандартов и нормативов. Он определяет возможности анализа и тем самым становится формальным языком, описывающим цели, которые мы реально можем достичь. Несмотря на то, что по времени этап контроля следует после фазы целеполагания, дело должно происходить следующим образом: одновременно с выбором (определением) цели необходимо выбрать систему показателей. Во время выполнения этапа контроля как такового надо лишь измерять ситуацию строго в этой системе показателей.
Фаза планирования
Процесс составления планов есть коллективный процесс работы менеджеров, в течение которого планы обсуждаются, корректируются, утверждаются. Рассмотрим этот процесс на примере планирования постоянных расходов.
1. Финансовый директор делает в системе пометку о начале планирования.
2. Автоматически всем пользователям системы рассылается сообщение о начале планирования следующего периода, его сроках и deadline предоставления плана.
3. IT-менеджер, в числе прочих ответственных, получает указанное сообщение и начинает планировать, допустим, следующий месяц.
4. Он указывает номер декады (недели, точную дату — все зависит от выбранной модели), статью расхода и сумму. Причем заранее составлена проекция менеджеров, участвующих в планировании, на статьи затрат. Это значит, что IT-менеджер никак не сможет планировать налоги или зарплату основного производственного персонала, поскольку ему это запрещено. Но выбрать статью — оргтехника и провести по ней $600 (поддержание и текущий ремонт) он сможет.
5. Завершив планирование, менеджер оценивает свои планы, что-то меняет и ставит отметку.
6. Автоматически система формирует сообщение, что тогда-то такой-то IT-менеджер предоставил все планы.
7. Финансовый директор, таким образом, получает консолидированную информацию от всех отделов.
8. Затем, как правило, полученные планы не удовлетворяют финансового директора (а может, генерального директора или акционеров). Финансовый директор или дает задания подразделениям что-то изменить, или в пределах дозволенного меняет сам. Но с автоматическим предупреждением всех заинтересованных лиц.
9. В результате в системе формируются приемлемые для всех сторон (естественно, с учетом их веса) бюджеты расходов и платежей.
10. Финансовый директор закрывает указанный период для планирования, после чего всем автоматически рассылаются оповещения об утверждении (невозможности дальнейшего изменения) бюджетов.
В результате сформированы четкие планы расходов и выплат предприятия на предстоящий период. На практике процедура разработки и утверждения подобных планов занимает от 3 до 10 дней в зависимости от сложности бизнеса и скорости принятия решений. Учитывая требования конкретного менеджмента, указанная процедура может быть проще или сложнее. Например, возможно лимитирование определенных статей (в абсолютных величинах или в процентах от других статей) — на рекламу нельзя тратить более 6% всех поступлений от продаж и т. д.
Фаза выполнения
Прежде всего, нужно понять, что фаза выполнения ни в коем случае не ограничивается только лишь учетом – бухгалтерским или управленческим. Эта фаза включает в себя так же управление персоналом, маркетинг и т.п.
Если продолжить пример с описывающий фазу планирования, то автоматизированный процесс фазы выполнения выглядел бы примерно так:
1. Подчиненный IT-менеджера (или он сам) вводит в систему заявку на выплату, допустим, $630, указать статью — поддержание оргтехники, и способ оплаты — безналичный. По плану же на данную статью полагалось $600.
2. Менеджер видит перерасход — $30 (в общем случае — величину неизрасходованного остатка по статье) и отсылает такую заявку финансовому директору.
3. Финансовый директор получает сообщение о новой заявке от IT-менеджера, видит перерасход по ней и текущий остаток денежных средств на том счете, с которого она будет уплачена.
4. Если финансовый директор согласен, он утверждает заявку и продолжает ее движение по маршруту. Если не согласен — отклоняет, что означает возврат заявки к ее отправителю с указанием причины отвода.
5. В случае утверждения заявка попадает к бухгалтеру, который, после получения необходимых документов (счета, акта, счета-фактуры и т.д.), ставит свою визу — «проведено».
6. Дальше бухгалтер по банку одним движением на основании заявки печатает платежное поручение. Заявка получает статус — «удовлетворена».
Надо отметить то, что необходимым элементом документооборота является доступность ответственным лицам информации о том, кто и как долго обрабатывал заявку, и в какой стадии она в данный момент находится. Естественно, на практике было много нюансов. Например, если заявка удовлетворяла плану, то этап 3 мог и отсутствовать.
Экипировка
С тем, как строить маршрут, разобрались. Но важен не только маршрут, но и экипировка. Итак, есть сложная, но результативная последовательность этапов. Каждый этап должен быть задокументирован и утвержден заказчиком. Первый документ этапа - план его выполнения. Второй - план-факт исполнения работ. Третий - собственно результат этапа: «Отчет о постановке задачи», «Схемы автоматизируемых бизнес-процессов», «Техническое задание», «Должностные инструкции».
У фирмы-внедренца должны быть стандарты на эти документы, причем в таком виде, чтобы потенциальные клиенты всегда могли с ними ознакомиться. Нет единого стандарта? Внедренец готов работать по любой предложенной заказчиком форме? Значит, это плохой внедренец. Нельзя плясать под дудку заказчика, ведь он не профессионал. Только представьте - приходите вы к врачу, а он вас спрашивает: «Как будем лечиться?». То есть нужен еще один документ. В начале каждого этапа заказчик должен утвердить формат документа результата по данному этапу. Хорошо, если этот формат будет совпадать/коррелировать с общепринятыми — ГОСТ, IDEF. Цель - предсказуемость результата.
Таким образом, только ознакомившись с форматами документов, сопровождающих работу внедряющей компании, не потратив ни единого у. е., вы сможете оценить потенциальных внедренцев именно по качеству работ, а не по субъективному восприятию. Опасно опираться на мнение знакомого главного бухгалтера, мол, их автоматизировала фирма, и результат очень хороший. Часто результатом для главного бухгалтера будет увеличение его авторитета, влияния, количества подчиненных, что вряд ли совпадает с оценкой результата внедрения для фирмы в целом. И наоборот, если вам говорят, будто кто-то недоволен результатом внедрения, это может означать обратное. Например, вряд ли результатом проекта по автоматизации крупной фирмы останется доволен уволенный (ставший лишним) восемнадцатый бухгалтер или менеджер по продажам, не добившийся успеха.
Коэффициент автоматизации
Автоматизация нужна для повышения эффективности бизнеса. Каким образом?
Допустим, существует сотрудник, должностные обязанности которого достаточно формализованы (регламентированы). Если они не сложны и нагрузка не велика, то нет проблем. Но что происходит на практике при увеличении нагрузки, причем нагрузка здесь — не обязательно в увеличении операций, это может быть повышение цены принимаемых решений, нервная нагрузка и прочие факторы. А происходит следующее: количество выполняемых за единицу времени производственных операций уменьшается, зато вероятность технологических ошибок увеличивается. Поэтому замена алгоритмизируемых человеческих операций на машинные совершенно формально приводит к увеличению эффективности и надежности всей системы. Именно в этом и состоит задача автоматизации. Из этого же следует критерий оценки автоматизированной системы:
Коэффициент автоматизации (AQ) обратно пропорционален количеству алгоритмизируемых, но не автоматизированных операций.
То есть чем больше осталось ручной, рутинной работы, тем он ниже. Плохо автоматизированная система в предельном случае является просто хранилищем информации, в которое кто угодно или что угодно просто вводит данные, потом эти данные, как правило, массой выбрасываются пользователю, который волен поступать с ними, как хочет.
Поэтому существует опасность недоавтоматизации. Предположим, на некотором предприятии в системе была реализована поддержка планов, учета, планирования и контроля. Вроде бы хорошо. В числе прочих составлялся бюджет выплат. Но на самом деле учет выполнения планов велся без предварительного контроля, т. е. при плане выплат в 100 единиц сотрудник мог сделать платеж на 500, и на следующий день менеджер видел результаты контроля — отклонение — 400. Правда, было уже поздно, так как отменить действие невозможно. Поэтому перед любым платежом сотруднику приходилось сопоставлять план выплат, произведенные выплаты и намеченную выплату, а хранились они в разных подсистемах и т. д. и т. п. В итоге – затрачено лишнее время, появляется раздражение и ошибки.
А достаточно было просто проработать механизм лимитирования, и при попытке превышения лимита оператор получал бы соответствующее уведомление и рекомендацию отправить заявку на согласование и утверждение. То есть система с необходимой степенью гибкости реагировала бы, и больше того — регламентировала бы деятельность оператора.
Но существует и другая опасность - опасность переавтоматизации. Предприятие купило престижную информационную систему (западного производства), вложив в нее сотни тысяч долларов. Номенклатура товаров — около 10 000, поставок — до 500 в день. И вместо обычных кладовщиков предприятие вынуждено взять на работу квалифицированных программистов для ввода накладных и подготовки отчетности. А все потому, что в этой КИС товар представлялся двенадцатизначным кодом, и пользователю каждый раз требовалось набирать в документах эти цифры, специальным образом ежедневно расшифровывать из данных штрих кодового оборудования, копировать и импортировать файлы, и снова преобразовывать коды в отчетах. И любая ошибка или несвоевременное выполнение операций приводили к серьезным проблемам. То есть оперативность и достоверность информации, которую предоставляла информационная система, зависела от такого числа человеческих факторов, что сбои фактически были запланированы.
Получается интересный вывод, указывающий на близость IQ (коэффициент интеллекта) и AQ. Знаменитый закон Тейлора гласит: «Из двух кандидатов, одинаково пригодных для работы, следует выбрать более глупого». То же и с компьютерными информационными системами — из двух систем, одинаково пригодных для автоматизации вашего предприятия, следует выбрать ту, у которой AQ ниже (более глупую). По крайней мере, будет экономия денег.
Маршрут правильного движения
Единственный, но зато гарантированный способ сохранить здоровье при движении по незнакомой, сильно пересеченной местности — это, как известно любому альпинисту, точный маршрут и соответствующая экипировка. Процесс внедрения не менее запутан и сложен, чем маршрут по горам, и имеет те же свойства. Подобно любому маршруту, внедрение должно быть ограничено как в пространстве — иметь конечную цель, так и во времени. Нечеткость в этих вопросах приводит к тому, что блуждания становятся бесконечными, а цель — недостижимой. Сложный маршрут (а простых внедрений не бывает) всегда состоит из этапов. В случае автоматизации эти этапы можно выделить следующим образом.
Этап 1. Стратегическое планирование. Топ-менеджеры компании должны сформулировать бизнес-цели и стратегию на ближайшие год-два. Это задачи именно высшего руководства. Как правило, цели впервые ясно формулируются как раз в результате этого этапа.
Этап 2. Формализация бизнес-процессов. После понимания задач можно переходить к следующему этапу — постановке задач на автоматизацию. Кратко - какие задачи будут автоматизированы и как. В ходе данного этапа составляются схемы движения информации (по одной на функциональную область — планирование продаж, закупка, хранение и т. д). На этом этапе в работе принимают участие топ-менеджеры, ведущие специалисты, начальники подразделений подготовки и IT-менеджеры. В результате данного этапа цели руководства будут сформулированы на языке конкретных функций и задач всех подразделений компании. Таким образом, это фактически этап постановки задачи.
Этап 3. Оптимизация бизнес-процессов. Первое системное и реальное представление о целях и бизнес-процессах, подлежащих автоматизации, полученное в результате второго этапа, почти всегда неоптимальное. Поэтому для повышения эффективности они должны быть оптимизированы. Обычно в результате оптимизации происходит реорганизация либо структуры предприятия, либо бизнес-процессов — реструктуризация и реинжиниринг соответственно.
Этап 4. Техническое задание.
Опираясь на утвержденную постановку, можно разрабатывать ТЗ. Иными словами, постановка задачи отвечает на вопрос: «Что надо автоматизировать?», а ТЗ — «Как конкретно надо автоматизировать?». ТЗ составляется с IT-менеджерами и начальниками отделов — «собственниками бизнес-процессов». В задании детально описываются все объекты информационной системы, их поведение и т. д. И чем подробнее будет ТЗ, тем лучше. На этом этапе очень важен процесс документирования, чтобы потом не возникали проблемы расхождения взглядов компании-клиента и внедряющей стороны.
Этап 5. Кодирование. После утверждения ТЗ можно приступать к кодированию. Это дело внедряющей организации.
Этап 6. Разработка должностных инструкций. Создание должностных инструкций – этап, часто игнорируемый заказчиками, которые требуют переходить сразу к обучению персонала. Но именно должностные инструкции облегчат в дальнейшем и обучение, и опытную эксплуатацию – меньше придется волноваться и заказчикам, и внедренцам. Опыт показывает, что этапы кодирования и разработки должностных инструкций могут проходить параллельно.
Этап 7. Обучение пользователей. В результате внедрения практически всегда происходит реинжиниринг и реструктуризация. Это означает, что сотрудники предприятия будут вынуждены работать по-новому. И проблема состоит не только в том, что их нужно известить о грядущих изменениях и научить работать в новых условиях. Основное, пожалуй, в том, чтобы преодолеть психологическое сопротивление переменам, позитивно настроить коллектив. Другими словами, нужно учесть и человеческий фактор.
Этап 8. Опытная эксплуатация. Этап, на котором можно объективно оценить все сделанное ранее. Система начинает работать не на бумаге и показывать свою эффективность/неэффективность.
На сегодняшний день, как во
На сегодняшний день, как во всем мире, так и в России существуют разнообразные решения на различных платформах, призванные в максимально короткие сроки автоматизировать деятельность предприятий. Это различные MRP, ERP, а также довольно распространенные в странах СНГ системы на базе «1С:Предприятие». Но в любом случае, абсолютно готовых к употреблению решений не бывает - каждое предприятие имеет свои особенности, которые нельзя первоначально учесть в универсальном пакете. Более того, при внедрении западных систем надо быть всегда готовым к тому, что они не очень-то рассчитаны на специфику деятельности на российских просторах, и это может увеличить время внедрения.
Но, тем не менее, эффективность автоматизации бизнес-процессов давно доказана, и единственным препятствием на пути внедрения является непонимание его сути заказчиками и непрофессионализм исполнителей. Хотя уже сегодня в России ощущается значительный прогресс в данном направлении, что не может не внушать оптимизм.
Сроки
На сакраментальный вопрос: «Я хочу автоматизировать то-то и то-то, как быстро вы мне это сделаете?», как правило, следует сакраментальный ответ: «Давайте, уточним, что именно вам нужно. Ответ будет зависеть от этого». Вопрос - правильный. Ответ - нет. На самом деле, сроки внедрения в первую очередь определяются не сложностью задачи. Сроки внедрения определяются скоростью принятия решения заказчиком (при профессионализме внедренца, разумеется).
Пример. Допустим, есть некто, желающий вылечиться от некой болезни, лечение которой связано с операцией (предположим, это аппендицит). Время работы специалиста (врача) — один-три часа операции плюс минут двадцать в день на обход и около часа-двух на процедуры. Просуммируйте и сравните с общим временем нахождения больного в клинике (недели две, если все в порядке, а если и нет, то время, которое тратят на больного врачи, относительно времени его пребывания в стационаре почти не увеличивается - просто больной не выписывается, а процедуры не прекращаются). То есть для конкретно взятой болезни, при конкретном медколлективе, время выздоровления может измениться в несколько раз, в зависимости от пациента. В итоге время выздоровления определяется, в первую очередь, состоянием больного, которого лечат, а не тем временем, которое уделили больному врачи.
Теперь об автоматизации. Постановка задачи на автоматизацию в значительной степени зависит от той среды, в которой произойдет автоматизация, и определяется тем средством, которое будет выбрано для решения. Ставить задачу будет руководство предприятия и предметные специалисты. Какое представление они имеют о средствах, с помощью которых будет решена задача? Вопрос риторический. В процессе внедрения заказчикам придется узнать гораздо больше нового, чем специалистам внедряющей фирмы. То есть время, затраченное специалистами и руководством предприятия заказчика на выбор оптимальной схемы информационных потоков и бизнес-процессов (ведь решение принимать им, а не внедренцу), существенно больше того времени, в течение которого специалистам внедряющей фирмы придется разбираться в нюансах бизнес-процессов конкретного предприятия, подготовить варианты этих схем.
Иными словами, хорошая внедряющая фирма должна, как минимум, «не тормозить» процесс автоматизации больше, чем сам заказчик. Аналогичная формулировка в медицине может звучать примерно так - хороший врач, как минимум, не должен «тормозить» процесс выздоровления больного. Если же вернуться к вопросу, с которого начали, - «сколько времени займет внедрение?», то после двух-четырех встреч с руководством фирмы-заказчика, каждая продолжительностью около часа, время внедрения можно будет оценить с погрешностью примерно 40%. На этом этапе уже станет ясна и примерная сложность задачи, и то, с какой скоростью заказчик реагирует на предложения и вопросы, сколько у него ответственных, существует ли четкий механизм принятия решения и т. д. Продолжая медицинские аналогии, серия этих встреч — не что иное, как бесплатное предгоспитализационное обследование (общий диагноз, выявление всяких аллергий, противопоказаний и проч.).
Стоимость
Сколько стоит внедрение? Автоматизация - это бизнес. Значит, определение стоимости процесса описывается общими экономическими законами. Труд среднего специалиста средней внедряющей фирмы объективно определяется временем его работы. Поэтому у каждой внедряющей фирмы единица трудозатрат определяется квалификацией персонала — эта единица является базой для расчета. А как на практике устанавливается стоимость внедрения? Известно три способа договорного определения стоимости внедрения.
Способ 1. Авантюрный. Внедрение всегда производится с целью оптимизации бизнеса, и результатом внедрения будет увеличение прибыли автоматизируемого предприятия либо за счет расширения бизнеса, либо за счет сокращения потерь, либо за счет и того и другого. Вот на некоторую долю прироста прибыли, полученного в результате автоматизации, стороны и договариваются. Этот способ достаточно редок. Солидная внедряющая фирма на это никогда не пойдет по следующей причине - нести прямые затраты ей придется сейчас (время, потраченное на внедрение специалистами компании), а окупятся они в будущем или нет, будет зависеть от персонала заказчика. То ест, проконтролировать этот процесс нельзя. Риск огромен.
Способ 2. Проектный. Способ, любимый руководством автоматизируемых предприятий за кажущуюся простоту и ясность. Способ действительно ясный, но вот последствий этой ясности заказчик себе, как правило, не представляет. И это может привести к серьезным проблемам. В таком случае стороны четко оговаривают, что, в какие сроки и за какие деньги будет сделано. Серьезная внедряющая фирма формализует это в договорных документах следующим способом: Постановка задачи определяет, что именно должно быть сделано; ТЗ определяет, как должно быть сделано то и только то, что определено в Постановке; Кодирование — кодируется то и только то, что определено в ТЗ. Такая система позволяет внедряющей фирме точно определить себестоимость и стоимость проекта, а также планировать ресурсы. Но что произойдет, если после подписания договора и постановки задачи заказчик вдруг обнаружит, что по какой-либо причине стоящие задачи изменились и часть заявленных в постановке задач в том виде, в каком они утверждены внедренцем, ему уже не нужна? Внедряющая фирма на основании подписанных простых и ясных документов имеет полное право сделать ненужную работу и добиться оплаты ее договорной цены.
Кроме того, коль скоро сроки работ определены, внедряющей фирме не выгодно их растягивать — норма прибыли уменьшается, и она обязательно будет использовать подписанные документы с оговоренными сроками для того, чтобы не дать заказчику затянуть сроки (увеличить скорость принятия решения заказчиком). Иными словами, при проектном способе реальную ответственность берут на себя обе стороны, но одна из сторон редко отдает себе в этом отчет.
Способ 3. Рамочный договор о сотрудничестве. Жизненность этого способа определяется его гибкостью. В отличие от проектного способа стороны констатируют общее видение предполагаемых задач, сроков и стоимости, но фиксируют лишь те задачи и этапы работ, которые им ясны на 100% (принимая на себя двустороннюю ответственность), и договариваются, что новые задачи можно формулировать и выполнять оговоренным способом, по мере их прояснения. И так до тех пор, пока окончательная цель не будет достигнута. Меньшая жесткость - меньший риск. Возможность внесения оперативных корректировок гарантирует меньший расход ресурсов (они не тратятся на выполнение ненужной работы), а значит, гарантирует лучшее, по сравнению с проектным способом, соотношение результат/цена.
Управление
Процесс управления практически любым объектом можно представить циклом (рисунок). Если, скажем, мы управляем кораблем, то Целеполагание — это принятие решения доплыть, например, из Ливерпульской гавани в Бразилию; Планирование — это решение о том, что для пополнения запаса горючего нам необходимо зайти в промежуточный порт, например, на Кубу; Исполнение — это собственно плавание; Контроль — это необходимость прочитать название порта и убедиться, что попали именно на Кубу, а не в Каир; Анализ — соотнесение желаемого местонахождения с действительным; Формирование управленческого воздействия — оргвыводы и приказ заменить проштрафившегося штурмана; Корректировка — изменение планов или целей в зависимости от величины промаха, ну и так далее. Более того – каждая фаза в отдельности должна быть тоже управляема, а значит, и иметь свои целеполагание, планирование, исполнение, контроль и анализ.
Автоматизированная система управления в общем случае должна автоматизировать именно этот цикл, так как именно он является определением термина «управление». Вопрос в том, какие фазы управленческого цикла подлежат автоматизации? Достаточно очевидно, что не целеполагание и корректировка, которые пока являются прерогативой человека, поскольку на этих этапах разрабатывается/корректируется миссия, стратегия предприятия, его глобальные планы (имеющие в основном качественную оценку) или производится изменение плана — процесс, тоже не подлежащий алгоритмизации. На всех же остальных стадиях автоматизация весьма и весьма уместна. В любом случае сбои на любой стадии управления приводят к тому, что объект становится плохо или вовсе неуправляемым.
Итак, при автоматизации системы управления предприятием автоматизировать нужно фазы планирования, исполнения, контроля и анализа. Все четыре. А если к вам приходит фирма-автоматизатор и утверждает, что после проведенной ею автоматизации, скажем, бухучета, наступит полный порядок, то вряд ли им можно доверять. Бухучет принадлежит фазе контроля. Допустим, вы знаете месячный объем продаж. Но его не с чем сравнивать, следовательно, непонятно, как регулировать этот объем. А если бы у предприятия существовал план по объему продаж, то каждый день менеджер получал бы информацию: укладывается он в план или нет, и в результате чего возникло отклонение. Согласны, что в этом случае менеджер действительно владеет информацией и является именно менеджером, а не бухгалтером или секретарем?
Разберем фазы, подлежащие автоматизации, подробнее.
IT консалтинг - статьи
Автоматизация: от идеи до утилизации
Наталья Дубова
27.06.2003
Открытые системы, #06/2003
По данным аналитиков, рынок PLM-решений ожидает ежегодный рост на 11%, — несмотря на проблемы, которые продолжает испытывать мировая экономика, стабильное увеличение числа инсталляций систем PLM не вызывает сомнений. В основе развития этого рынка лежат новые задачи, которые необходимо решать производственным компаниям в условиях усиливающейся конкуренции.
Что есть PLM
Главная цель любого производителя — качество выпускаемой продукции, однако одной из основных тенденций сегодня является необходимость сокращения времени выхода новых изделий на рынок при одновременном удовлетворении специфических потребностей заказчиков (от модели массового производства компании переходят к разработке и сборке на заказ). При этом компании не могут позволить себе повышать стоимость процессов проектирования новых изделий. Одновременно с этим в процесс создания продукции вовлекаются сегодня многочисленные внешние участники — от поставщиков комплектующих, которые должны иметь возможность оперативно реагировать на изменения в требованиях к конечному продукту, до самих заказчиков, которые хотят получить доступ к процессам формирования этих требований. Для многих крупных производителей «виртуальное предприятие» становится реальностью — они выносят за скобки собственного производственного процесса разработку и выпуск комплектующих, а подчас и собственно сборку готового изделия, оставляя за собой базовые операции выработки концепции и проектирования продукции. Передача части своих функций на аутсорсинг не отменяет необходимости контролировать и интегрировать все процессы. Для того чтобы виртуализация производства происходила не в ущерб конечному результату и с максимальной экономической отдачей, компаниям необходимы технологии, объединяющие и автоматизирующие все разрозненные этапы жизненного цикла изделия, создающие интегрированную среду коллективной работы, где каждый участник производственной цепочки имеет в реальном времени доступ к нужной ему информации по изделию.
Первоначально такие технологии приобрели известность под названием Collaborative Product Commerce (СРС), однако термин PLM (Product Lifecycle Management) точнее отражает суть. PLM — это набор взаимосвязанных прикладных решений, включающий необходимые программные компоненты обеспечения коммуникаций, интеграции модулей, автоматизированного проектирования и визуализации и других решений, охватывающих полный жизненный цикл продукта — от идеи до утилизации.
PLM расширяет возможности автоматизированного контроля над изделием за рамки инженерных лабораторий и конструкторских бюро, которые были основными пользователями предшественников РLM-технологий — CAD/CAM и систем PDM. Решения класса PLM призваны объединить всех участников жизненного цикла, как внутри предприятия-производителя, так и вне его, в том числе поставщиков, заказчиков и организации, занятые послепродажным обслуживанием продукции.
Система PLM охватывает все этапы жизненного цикла изделия (рис. 1).
 |
Рис. 1. Этапы жизненного цикла изделия |
Анализ требований рынка. Производитель должен понять, насколько востребован рынком новый продукт, и оценить выполнимость этих требований. На этом этапе система PLM используется для извлечения данных из различных информационных систем, которые могут способствовать получению более точной картины.
Проектирование. Конструкторы создают проект нового изделия — соответствующие САПР и PDM-решения являются интегральной частью PLM-решения. При проектировании используется вся необходимая дополнительная информация, поставщиком которой являются PLM-модули, включая факторы, связанные с послепродажным обслуживанием изделия, информация о предпочтениях заказчика, данные о производственных возможностях и т.д.
Определение источников поставок (PLM-sourcing). Отдел закупок должен провести предварительную работу по поиску источников приобретения необходимых для производства изделия деталей, материалов, компонентов, оборудования и т.д. Задача систем PLM — предоставить достоверные данные о доступности тех или иных деталей/компонентов/материалов, их стоимости, потенциальных поставщиках и возможных альтернативных источниках.
Производство. В соответствии с определенными на этапе проектирования спецификациями и с использованием полученных на этапе поставок деталей и материалов производится продукт. Реализованные в PLM специальные методы контроля качества позволяют гарантировать соответствие производимого изделия заданным спецификациям.
Дистрибуция. Готовое изделие поставляется либо дистрибутору, который размещает его на своем складе до поступления соответствующего заказа, либо непосредственно заказчику. Полученные из системы PLM исторические данные о потребностях рынка помогают производителю свести к минимуму число уровней инвентаризации готовой продукции.
Послепродажное обслуживание. На этом этапе выполняются техническое сопровождение, обслуживание и ремонт — в течение гарантийного срока или как дополнительно оплачиваемый сервис. PLM позволяет учесть различную информацию об изделии, поступающую на этом этапе жизненного цикла, при разработке последующих проектов и тем самым способствует повышению привлекательности продукции для клиентов.
Возможность извлечь из одного источника не только все накопленные на данном проекте знания, но и исторические данные, имеет ключевое значение для повышения эффективности проектирования новой продукции и усовершенствования существующей номенклатуры изделий с целью максимального удовлетворения потребностей заказчиков. Репозиторий PLM позволяет производителю не растерять ценный опыт, накопленный на предыдущих проектах. Возможность не изобретать в очередной раз велосипед крайне важна для производственных предприятий, поскольку, как показывает практика, большинство проектов не несут в себе какой-то исключительной новизны, а являются усовершенствованиями предыдущих разработок.
При наличии централизованного репозитория значительно упрощается контроль за актуальностью информации — PLM становится для компании единственным источником достоверных данных по продукту. Чем раньше будут идентифицированы ошибки или ограничения проекта, которые могут повлиять на конечные характеристики разрабатываемого изделия или просто усложнить процесс его производства, тем меньше затрат понадобится на их устранение.
Перепроектирование, а тем более, дополнительное тестирование, переделка или, того хуже, полная отбраковка готовой продукции всегда обходятся изготовителю недешево. Pешения категории PLM позволяют свести к минимуму или полностью избежать подобных расходов, а если учесть, что, по оценкам Aberdeen, не менее 70% затрат на производство и сопровождение продукции приходится на этап проектирования, можно сделать вывод, что PLM обеспечивают не только повышение качества и оптимизацию разработки изделия, но и способствуют снижению затрат на поддержку его жизненного цикла. По данным IBM в сотрудничестве с компанией Dassault Systemes, предлагающей свой РLM-пакет ENOVIA, с применением возможностей PLM экономия затрат на разработку и выпуск продукции у ее клиентов достигает 1 млрд. долл., при этом цикл вывода нового изделия на рынок сокращается с 72 до 16 недель.
В PLM доступ к данным организован на ролевой основе. Система позволяет предоставлять пользователю информацию в форме, соответствующей выполняемым им функциям в жизненном цикле изделия: трехмерные модели, схематические диаграммы, инженерные спецификации (bill of materials, BOM), календарные планы или прогнозы на основе анализа требований рынка. Конструктор будет работать в привычной ему среде САПР, а сотрудник маркетингового подразделения сможет получить из системы представление трехмерной сборки, пригодное для размещения в рекламной брошюре.
Системы CAD/САМ, нашедшие широкое применение в производственных компаниях, повышали эффективность и упрощали работу проектировщиков и технологов, но были слабо интегрированы между собой, а другие подразделения и партнеры компании практически не могли повлиять на процессы разработки и производства изделия, поскольку не имели доступа к таким системам. После последовательного проведения нескольких итераций разработки проект попадал к технологам и в отдел закупок, которые уже никак не могли повлиять на него и подчас были вынуждены идти на неоправданно дорогие траты или поиск дефицитных материалов и деталей и производство изделия на неподходящем оборудовании.
Система PLM, объединяющая все структурные подразделения предприятия, позволяет уже на этапе проектирования вносить изменения с учетом проблем, которые могут возникнуть как при производстве, так и при выборе поставщиков комплектующих. В результате не возникнет ситуации, когда невозможность увязать проект со сложностями производственного цикла и задачами закупок приводит к повышению цены и одновременно снижению качества продукции.
С помощью информации, которую интегрирует система PLM, даже не обладая специальными техническими знаниями, сотрудники отдела закупок смогут заниматься поиском нужных деталей и выбором оптимальных каналов поставки непосредственно по данным, поступающим из конструкторских подразделений. По мере развития технологии электронного представления компонентов (component supplier management, CMS) и появления у поставщиков возможностей параметрического поиска, которые будут интегрироваться в PLM, сами конструкторы уже на этапе проектирования получат возможность выбирать подходящие компоненты. По данным Aberdeen, привлечение поставщиков на этапах формирования концепции и проектирования изделия обеспечивает 20% экономии средств на разработку. Кроме того, они все чаще выступают в роли проектировщиков определенных компонентов изделия. Бумажные формы обмена информацией с внешними котрагентами компании-производителя существенно снижают эффективность работы над изделием, поскольку время обнаружения ошибок в проекте влияет на его стоимость и на сроки вывода качественного продукта на рынок. Предположим, производитель автомобилей отдает на аутсорсинг разработку переднего амортизатора. В ходе проектирования корпуса может измениться спецификация для амортизатора — длина, вес или степень упругости. Эти изменения сразу должны быть учтены в проекте, который разрабатывает смежник, что и позволяет сделать среда PLM через механизмы разделения данных для разных участников жизненного цикла изделия.
Если идея интеграции поставщиков комплектующих в процессы проектирования на самых ранних стадиях для ряда производителей, например, в автомобильной отрасли, уже давно перешла в практику, то возможность включения в информационное пространство изделия подразделения и внешние организации, которые занимаются послепродажным обслуживанием, можно считать «ноу-хау» PLM-решений.
Знания о том, какие проблемы вызывает техническое сопровождение готовой продукции, ее гарантийное или платное обслуживание, может серьезно повлиять на последующие проекты компании. Если производитель имеет возможность получить такие данные, проанализировать их и реализовать в следующих проектах те характеристики, которые позволят избежать аналогичных проблем для нового изделия, он не только сэкономит свои затраты на послепродажное обслуживание, а сделает продукт, который лучше удовлетворит запросы клиента. А это уже влияеет на имидж и конкурентоспособность производителя.
С помощью PLM заказчики получают возможность декларировать свои требования по улучшению продукта или претензии, связанные с ремонтом, которые будут непосредственно учтены конструкторами при проектировании следующей версии изделия. Таким образом, система PLM обеспечивает всем участникам жизненного цикла, включая и внешних, доступ к данным в реальном времени, реализуя сквозное распространение изменений, внесенных на одном из этапов, на все этапы жизненного цикла. Например, по требованию заказчика одна из деталей изделия будет крепиться в четырех точках вместо трех. Это требование повлечет изменения в спецификации детали и в настройке технологического процесса у поставщика для производства этой детали. В общей спецификации изделия изменится число болтов, необходимых для крепления такой детали, а это в свою очередь повлечет за собой изменения в заказе на закупку и т.д.
В целом, преимущества, которые дает PLM-решение, можно сформулировать следующим образом:
ускорение вывода новой продукции на рынок, благодаря привлечению к процессам проектирования в реальном времени всех заинтересованных участников, включая внешних поставщиков и заказчиков; совершенствование характеристик разрабатываемой продукции и повышение качества, обнаружение недостатков и ограничений проекта на самых ранних стадиях; увязка проектирования и производственных процессов: инженеры-технологи становятся интегральной частью команды проектировщиков, благодаря чему проект сразу создается с учетом специфики производственного процесса, включая тестирование, контроль качества и т.д.; учет и использование опыта других проектов; реализация новой бизнес-модели «виртуального предприятия» — к процессу проектирования и производства привлекаются поставщики, либо работы определенного этапа жизненного цикла продукции передаются на аутсорсинг внешним компаниям.
Что влияет на темпы распространения PLM-решений
Несомненно, залогом успешного развития и роста рынка PLM является оздоровление глобальной экономической ситуации, которое будет способствовать появлению у предприятий более широких возможностей для инвестиций в перспективные технологии. Аналитики выделяют еще несколько важных факторов, которые оказывают влияние на темпы адаптации PLM-решений клиентами.
Проблема руководства. Полномасштабная инсталляция PLM охватывает практически все подразделения предприятия — конструкторское, инженерное, производственное, отдел закупок, службу контроля качества, маркетинг и продажи, техническое обслуживание. Только руководители верхнего звена имеют достаточные полномочия, чтобы осуществить проект, затрагивающий интересы фактически всех сотрудников организации, однако пока общепринятая практика — возлагать эту задачу на менеджеров инженерных подразделений.
Необходимость преодолевать общекультурные сложности. PLM ставит в центр всех процессов на производственном предприятии создаваемый продукт (вместо бухгалтерских документов, например) и позволяет разделять данные об изделии специалистам разного уровня и квалификации. Возможно, кто-то из сотрудников потеряет осознание собственного исключительного положения, поскольку теперь владение информацией по проекту — не только его привилегия. Несмотря на то что в соответствии с философией PLM процесс проектирования ставится во главу угла в бизнесе производственной компании, нередко приходится сталкиваться с негативным отношением к PLM именно со стороны конструкторских отделов. Благодаря PLM проект становится открытым для других функциональных подразделений и внешних партнеров, и этот факт вызывает у создателей проекта в лучшем случае скептицизм, в худшем — явное неприятие.
Проблемы интеграции. Решения PLM должны сосуществовать с различными корпоративными системами, а также поддерживать интеграцию с решениями компаний-поставщиков и заказчиков предприятия.
Формирование надежных механизмов для разделения интеллектуального капитала. Информация, которая должна быть доступна всем пользователям интегрированной среды PLM, в том числе проектные данные, данные анализа рынка, инновационные прогнозы, уникальные клиентские требования к разрабатываемому изделию являются интеллектуальной собственностью компании.
Поэтому в рамках проекта PLM равно необходимы как средства защиты на уровне технологий, так и способы установления доверительных отношений между партнерами.
Формирование репозитория PLM как основного источника достоверных данных о продукте для всех категорий пользователей. Большинство преимуществ использования PLM вытекает из кумулятивных возможностей, которые предоставляют эти системы. При создании общекорпоративного репозитория необходимо обеспечить соответствующие функции электронного хранилища, реализовать средства каталогизации, поиска, разделения данных и визуализации, причем так, чтобы они удовлетворяли разные категории пользователей. Время и усилия потребуются не только для того, чтобы решить эти задачи, но и чтобы довести их преимущества до тех, кому они предназначены.
Стандартизация. В области PLM стандартизация необходима как в сфере представления данных частными САПР и PDM-системами, так и для создания общего синтаксиса для совместного использования данных модулями разных РLM и другими корпоративными системами. Эволюция и адаптация стандартов в этой области, как и в любой другой, требует времени.
Общекорпоративный масштаб PLM-решений (в идеале) ставит и серьезные проблемы их внедрения. Поставщики и консультанты по PLM сегодня стремятся избежать неприятностей, которые почти обязательно сопровождают развертывание решений аналогичной сложности, например, ERP: затягивание сроков проекта, постоянный рост расходов на реализацию и неудовлетворенность заказчика темпами возврата инвестиций. Поэтапная реализация PLM-проектов помогает ускорить окупаемость и получать реальный эффект от внедрения уже через полгода с начала реализации.
Но, несмотря на все трудности, современные производственные компании понимают, что необходимое условие для стабилизации и развития бизнеса — совершенствование всех процессов, связанных с созданием продукции. Чтобы стать известным или удержать репутацию своей марки, надо обеспечивать высокое качество проектирования и производства. А сложные экономические условия подчас только подстегивают: клиенты в это время становятся более разборчивыми.
Потребители
 | |
|
Рис. 2. Распределение прибыли от PLM-решений по функциональности систем |
Решения РLM выросли на почве создания расширений к существующим САПР для построения сред совместной работы проектировщиков, поэтому сегодня наибольший процент использования возможностей PLM принадлежит инженерной сфере (рис. 2). Около 75% рынка PLM в 2002 году приходилось на предприятия автомобильной промышленности, ИТ-индустрию, самолетостроение и машиностроение. Эти дискретные производства имеют опыт не одного десятилетия по использованию САПР и PDM-систем, и потому вполне логичен их интерес к новому поколению решений по управлению данными об изделии. Кроме того, эти четыре отрасли в мире представляют уже вполне зрелые рынки, на которых необходимо искать особые пути выделить себя среди конкурентов. Они уже миновали стадию ценовых войн, и теперь на первый план выходят такие параметры, как качество выпускаемой продукции, качество и высокий темп инноваций, эффективность поддержки полного жизненного цикла продукта. Но вслед за ними преимущества PLM-решений начинают по достоинству оценивать и другие отрасли, где необходимо серьезное внимание к стадии проектирования и поддержка достаточно длительного жизненного цикла производимой продукции: производство потребительских товаров и бытовой электроники, строительство, фармацевтика. При этом более 80% рынка PLM остается за дискретными производствами.
Первыми пользователями решений PLM были крупные компании (более 5 тыс. сотрудников) — одной из основных причин является накопленный опыт работы в среде САПР/PDM, ну и, конечно, материальные возможности. Именно их вложения позволяют рынку PLM-решений развиваться в сторону создания готовых пакетов PLM-приложений и постепенного снижения цен, что открывает перспективы использования PLM для средних (от 500 до 5 тыс. сотрудников) и небольших (от 20 до 500 сотрудников) компаний. За повышением интереса к PLM со стороны предприятий этого уровня лежат определенные тенденции в современном производственном бизнесе. Как правило, большинство таких предприятий являются поставщиками для крупных производителей, и потому нуждаются в механизмах увязки своих процессов проектирования и производства компонентов с теми целями, которые ставит «старший» партнер. Более того, основной производитель все чаще передает на аутсорсинг те или иные операции по разработке и сборке компонентов или даже сборке целого изделия. Такая бизнес-модель «виртуального» предприятия требует эффективной автоматизированной среды совместной работы, которую и обеспечивают системы PLM. Однако эта новая категория клиентов более сдержана в своих расходах и более подвержена влиянию экономической нестабильности, поэтому, чтобы иметь успех в этом сегменте рынка, поставщикам потребуется приложить больше усилий по формированию предложений, в которых будет найдено оптимальное для средних предприятий сочетание цены, функциональности, возможностей быстрой инсталляции и простоты в использовании.
Производители
В центре объединения различных этапов жизненного цикла, которое реализует система PLM, пока остается ключевой для производства процесс проектирования, поэтому легко объясним тот факт, что первопроходцами современного рынка РLM стали производители САПР и систем PDM: РТС, EDS/SDRC, IBM/Dassault Systems [2]. Аналитики AMR Research выделяют эти компании в группу так называемых САПР-центричных поставщиков решений класса PLM [3]. Другая категория поставщиков в классификации AМR — это производители ERP-систем, такие как SAP, Oracle, Baan. Осознав стратегическое значение для своих заказчиков интеграции всех процессов по выпуску продукции на базе мощной информационной системы, эти компании стали активно предлагать собственные PLM-решения.
Технологические корни систем представителей этих двух групп определяют и основные различия между ними. «САПР-центричные» компании сильны в обеспечении наиболее неформальной, творческой части жизненного цикла изделия — многоитерационного проектирования в среде совместной работы над неструктурированными данными различной степени сложности. На базе этого ядра строятся взаимосвязи остальных этапов жизненного цикла с центральным процессом проектирования, позволяющие понять, какое влияние оказывает проект на производство, определение требований к поставщикам, анализ предпочтений клиента, послепродажное обслуживание, и вывести обратные зависимости. Производства, где быстрые и эффективные модификации и создание новых изделий имеют критическое значение, такие как автомобильная промышленность и авиастроение, составляют основную клиентскую базу поставщиков PLM-решений из этой группы.
Традиционная сфера применения ERP-систем — бизнес-транзакции над структурированными данными, планирование ресурсов, контроль финансовых потоков, управление поставками, обеспечение информации для поддержки управленческих решений, контроль за выполнением плана. Свои PLM-решения компании «ERP-центричной» группы в основном строят вокруг структурированной спецификации изделия (ВОМ), на основе которой интегрируются процессы управления проектами, контроля за конфигурацией изделия, документооборота, управления потоком работ, управления цепочками поставок и взаимоотношениями с клиентами.
Получающие сейчас распространение в ряде производственных компаний процессы разработки на заказ (engineer-to-order, ETO) и конфигурирования на заказ (configure-to-order, CTO), которые требуют управления структурой и конфигурацией изделия на протяжении всего жизненного цикла — оптимальная сфера применения таких PLM-систем.
AMR выделяет еще одну группу игроков на рынке РLМ — независимые компании, не имеющие серьезного «веса» ни в сфере САПР, ни в области автоматизации общего управления корпоративными ресурсами — это Agile Software, MatrixOne, Eigner. Их решения имеют развитую функциональность для различных стадий жизненного цикла изделия за рамками трехмерного проектирования, включая поддержку взаимосвязей с внешними партнерами, и интерфейсы для интеграции в среду PLM необходимых САПР и ERP-приложений.
Задачи интеграции разных систем вообще актуальны для современного рынка PLM. На больших проектах может понадобиться комбинация возможностей, как это произошло, например, при реализации программы по созданию аэробуса А380 в компании Airbus, где решения SAP используются совместно с функциональностью систем РТС и IBM/Dassault. У производителя и поставщика могут уже быть установлены модули, на базе которых возможно построение общей PLM-среды. Другой вариант — производитель хочет дополнить имеющиеся у него модули автоматизированного проектирования и управления данными об изделии функциями управления взаимоотношениями с поставщиками и заказчиками, обратясь к решениям другого поставщика. Кроме того, на западном рынке есть целый ряд небольших компаний, производящих продукты, реализующие отдельные функции для управления жизненным циклом изделия, такие как моделирование материалов, 3-D анимация, управление технологическими процессами, поддержка среды совместной работы проектировщиков, тестирование готового изделия, автоматизация закупок, управление инженерными проектами, поддержка технического обслуживания и т.д. Они привлекательны для многих клиентов, поскольку приобретение полномасштабной платформы PLM требует первоначальных затрат в несколько миллионов евро, поэтому компании часто предпочитают «кусочную» автоматизацию, постепенно объединяя модули, приобретенные для решения частных задач.Одна из важных проблем формирующейся индустрии PLM — это стандартизация, возможно, создание в стеке программного обеспечения PLM общего уровня взаимодействия, позволяющего клиентам интегрировать на некую единую платформу оптимальные для себя решения по поддержке разных стадий жизненного цикла продукта.
Сложность PLM-решений как таковых, а также необходимость их интеграции в корпоративную информационную среду клиента, которая может включать самые разные системы — от собственных разработок и унаследованных приложений до последних новинок в области SCM и CRM, объясняет динамику развития профессионального сервиса на рынке РLM.
