1 - 2008

Критерии выбора PLM-решения

Алексей Родионов

Поддержка

Функциональность

Цена

Возможность тиражирования и масштабирования

Интеграция с другими системами

Самостоятельная поддержка и развитие системы

В данной статье речь пойдет об общих критериях выбора решения по управлению предприятием класса PLM (Product Lifecycle Management — системы управления жизненным циклом изделия) и более подробно будет освещен вопрос о том, какие функции должно иметь такое решение, чтобы самостоятельно настраивать и развивать PLM-систему на предприятии, не привязываясь к поставщику решения.

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

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

Сегодня многие средние и крупные быстрорастущие предприятия сталкиваются с проблемой выбора системы PLM. Никто уже не ставит под сомнение, что учетные и производственные задачи требуется тем или иным способом автоматизировать. Подходы выбираются разные. Одни фирмы предпочитают продолжать «лоскутную» автоматизацию, при которой различные направления деятельности компании автоматизируются с помощью нескольких разных программных продуктов. Основные проблемы, с которыми сталкиваются такие предприятия, — значительные затраты на консолидацию информации из разнородных баз. Конечно, для решения подобных задач существуют специализированные продукты, но их приобретение — это дополнительные затраты. Кроме того, использование разнородных источников информации на предприятии приводит к многократному дублированию справочников, которые вообще-то должны храниться централизованно и вводиться однократно. Другие фирмы считают, что необходимо создать единое информационное пространство компании на базе программных продуктов, по возможности от одного производителя. Этот подход тоже имеет свои недостатки. Главный из них — небогатый выбор за разумные деньги.

Как всегда, истина находится где-то посередине. Ответственные за автоматизацию предприятия должны искать решения, которые, с одной стороны, удовлетворяют основные потребности компании в комплексе, а с другой — предполагают возможность поэтапного внедрения с использованием имеющихся наработок. Почему это необходимо? В развивающейся компании, где объем обрабатываемых данных постоянно растет, а схемы бизнес-процессов усложняются, «лоскутная» автоматизация начинает тормозить развитие, поскольку увеличивается количество подразделений предприятия и соответственно количество подразделений, задействованных в различных бизнес-процессах. Поэтому если каждое подразделение (или группа подразделений) имеет собственную систему автоматизации, то прохождение информации между подразделениями и контроль исполнения в таких условиях становится все более сложной задачей. Все это приводит к необходимости внедрения системы документооборота, которая позволила бы автоматизировать основные бизнес-процессы внутри, а частично и вне организации. Но многие процессы оперируют данными, которые находятся внутри прочих систем автоматизации, используемых в подразделениях, — это и первичные документы в бухгалтерии, и акты приемки и отгрузки на складе, и план и бюджет у аналитиков, и проектно-конструкторская документация, и офисная корреспонденция, и многое другое. Можно, конечно, делать ссылки на эти документы, но это позволяют не все программы, да и не всегда можно отслеживать изменения исходных документов, на которые установлены ссылки. Если проблемы возникают «с другого конца» — руководство говорит, что документооборот может подождать и нужно сначала сменить систему, обеспечивающую основную деятельность предприятия, которая и приносит прибыль, например класса ERP (Enterprise Resource Planning — система управления ресурсами предприятия), — то все равно необходимо задуматься о том, как она будет развиваться дальше и как организовать ее взаимодействие с остальными программами компании. Ведь в крупных компаниях программные оболочки меняются нечасто, так как процесс этот крайне непростой и сопряжен с большими финансовыми и моральными потерями. Желательно задуматься при смене системы о том, как она будет развиваться дальше. Какими же критериями имеет смысл руководствоваться при выборе? Попробуем составить перечень, не претендуя, правда, на его полноту:

  • поддержка;
  • функциональность;
  • цена;
  • простота внедрения;
  • опыт использования;
  • возможность тиражирования и масштабирования;
  • самостоятельная поддержка и развитие системы;
  • интеграция с другими системами.

Рассмотрим пункты этого списка более подробно.

Поддержка

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

В начало В начало

Функциональность

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

В начало В начало

Цена

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

Простота внедрения и опыт использования — достаточно понятные пункты для сотрудников компаний, которые задумались о подборе системы PLM.

В начало В начало

Возможность тиражирования и масштабирования

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

В начало В начало

Интеграция с другими системами

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

В начало В начало

Самостоятельная поддержка и развитие системы

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

Стремятся ли разработчики PLM-решений к реализации интеграционных модулей и расширению возможностей настройки своих систем? Как правило — да. Наша компания — «Лоция Софт», российский разработчик одноименного PLM-решения Lotsia PLM, — старается вести разработку таким образом, чтобы клиенты были максимально удовлетворены. И здесь нет никаких противоречий. По всем вышеперечисленным пунктам, кроме последних двух, и так все понятно: чем система проще, функциональнее и дешевле, тем больше шансов, что клиенты выберут именно это решение. Давайте разберемся с последними двумя пунктами. Наша точка зрения такова: чем больше интерфейсов взаимодействия с другими системами будет у нашей программы и чем больше возможностей для самостоятельной ее настройки будет у пользователя, тем лучше. Эта точка зрения не нова, ее придерживаются практически все лидеры мирового рынка ИТ. Очевидно, что те, кто думает иначе, долго на данном рынке не задерживаются. Это тот случай, когда жизнь все расставляет по местам.

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

Возможности настройки системы — другое дело. В некоторых компаниях есть отдел разработки, но в большинстве — только администраторы, то есть люди в компьютерном отношении продвинутые, но программистами не являющиеся. Исходя из этого и нужно оценивать возможности самостоятельной настройки программы. Естественно, что низкоуровневый интерфейс (то есть возможность делать настройки на базе написания программного кода на каком-либо распространенном языке программирования), как правило, дает очень широкие возможности по настройке функциональности системы и даже написанию собственных модулей. Высокоуровневый интерфейс — это либо макроязык, встроенный в систему, либо интерфейсные решения, которые позволяют настроить внешний вид и логику поведения отдельных окон программы. Обычно возможности такого интерфейса конечны и не позволяют решить все поставленные пользователями системы задачи. Где же компромисс? Какими возможностями должна обладать хорошая система? Да всеми! Например, мы в Lotsia PLM поддерживаем возможности настройки каждого отдельного окна для конкретного пользователя, причем администратор системы может делегировать подобные права для каждого пользователя в отдельности или делать настройки самостоятельно для пользователя либо группы пользователей, также можно производить изменение логики работы программы, вставляя в окна программные фрагменты, реализованные на VBScript или на JScript. И конечно, есть API, которое позволяет как получать доступ к нашим программам изнутри других систем, так и работать с данными внутри нашей программы. То есть мы предлагаем полный комплекс средств настройки для клиентов любого уровня подготовки. API пользуются наши партнеры и продвинутые клиенты: они реализуют собственные модули расширения и блоки интеграции со своими специализированными системами. Средствами макроязыка, генератора отчетов и форм, скриптовыми вставками пользуются практически все, так как специфика у каждого своя, а без конца обращаться к разработчику хлопотно.

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

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

В начало В начало

САПР и графика 1`2008