eng
Выпуск #10/2018
Н. Тюльпа
Внедрение PLM: сложности и риски при реализации комплексных проектов
Внедрение PLM: сложности и риски при реализации комплексных проектов
Просмотры: 1716
Результат внедрения системы PLM на предприятии во многом зависит от качества не только используемых ресурсов (ПО, интеграционных взаимосвязей, ИТ-инфраструктуры), но и выполнения соответствующих работ. В статье рассмотрены тонкости внедрения PLM-проекта, о которых не всегда задумываются до начала работ, особенности управления рисками и сложности, которые может таить в себе большой комплексный проект.
УДК 004.4(043) 681.513.2 | ВАК 05.13.00
DOI: 10.22184/1992-4178.2018.181.10.128.131
УДК 004.4(043) 681.513.2 | ВАК 05.13.00
DOI: 10.22184/1992-4178.2018.181.10.128.131
Теги: it infrastructure plm system plm-система project manager selection risk management service provider selection virtualtester выбор поставщика услуг выбор руководителя проекта ит-инфраструктура управление рисками
ОПРЕДЕЛЕНИЕ СТРАТЕГИЧЕСКИХ ЦЕЛЕЙ ПРОЕКТА[1]
Предприятия выстраивают бизнес-стратегию развития в соответствии с запросами рынка, целевыми государственными программами и геополитическими факторами. Проследим влияние этих факторов на реализацию конкретного проекта в сфере ИТ.
В рамках курса на диверсификацию оборонных производств поручением Владимира Путина была установлена доля высокотехнологичной продукции гражданского и двойного назначения от общего объема продукции ОПК: с 16,4% в 2016 году до 17% к 2020-му, до 30% к 2025-му и до 50% к 2030 году. Это заставляет предприятия ОПК выходить на конкурентно-свободный рынок с его жесткими законами. Меняются требования к выпуску продукции, сроки радикально сокращаются, а привлекательность товара и его стоимость зачастую становятся критичными для успешной продажи. При использовании существующих методов разработки и производства изделий обеспечить качественную автоматизацию процессов непросто.
Предстоит менять подходы к разработке и выпуску продукции: высокая вариативность изделий при минимальном наборе уникальных комплектующих диктует необходимость разработки модульных систем; сокращение времени выхода на рынок влечет за собой серьезный пересмотр процессов принятия решений; для управления стоимостью продукции необходимо активно внедрять системы управления производством и предприятием в целом. Таким образом, ИТ-подразделения просто обязаны участвовать в реализации стратегии развития предприятия и использовать современные инструменты для решения перечисленных задач: переход к цифровому предприятию, применение современных САПР и управление электронным макетом изделия, внедрение систем управления данными КТПП, запуск систем управления производством и т. д. Следовательно, внедрение PLM на предприятии – это не попытка «автоматизации ради автоматизации», а жизненно необходимый проект по реализации бизнес-стратегии развития предприятия, требующий пристального внимания и активной поддержки руководством.
КРИТЕРИИ ВЫБОРА ПОСТАВЩИКА РЕШЕНИЙ
На стадии выбора поставщика решений есть смысл учитывать размер и надежность компании-интегратора, период времени работы на рынке услуг, уставной капитал, выручку за год, рентабельность и другие финансово-экономические показатели, определяющие уровень подрядчика на внутреннем рынке. Действительно, имеет ли смысл вкладывать ресурсы в красивый стартап, запущенный энергичным менеджером, если риски для вашей компании слишком велики?
Наличие необходимого штата технических специалистов и консультантов по внедрению также считается неотъемлемой частью работы с поставщиками. Причем знания профессионалов должны быть подтверждены международными стандартами и сертификатами. Важные признаки – прозрачность и общественная доступность таких сведений от независимого источника. Например, сайт VirtualTester предоставляет информацию о поставщиках в конкретном регионе с перечнем сертификатов, подтверждающих компетенции компании по направлениям (рис. 1).
Единый поставщик решений
При создании системы можно на разных этапах привлекать различные фирмы, ориентируясь на минимальную рыночную стоимость, а также выполнять часть работ своими силами. Такой подход предполагает множество рисков: недостаточную квалификацию исполнителей, отсутствие заинтересованности в конечном результате, поскольку существует вероятность переложить ответственность и сложные вопросы на стыках выполняемых работ на смежного исполнителя. Важно взаимодействовать с лицом, с которым можно решить все возникающие вопросы и которое несет ответственность за результат проекта. В этом случае поставщик заинтересован в качественном выполнении каждого этапа внедрения PLM-системы и учитывает стыковки результатов выполнения работ на разных стадиях.
Наличие успешной методики внедрения
Компании, давно занимающиеся реализацией комплексных проектов, используют выработанные годами подходы. Это минимизирует риски мероприятия, денежные затраты и сроки. Если сотрудники компании готовы детально и предельно ясно рассказать, как будет реализован проект, в какие сроки, какие специалисты потребуются со стороны предприятия, это свидетельствует о том, что они знают, что делают. В противном случае есть шанс стать если не жертвой смелого эксперимента, то подопытным кроликом.
В ходе обсуждения проекта у предприятия должна быть возможность не только узнать, какие компания-интегратор предлагает варианты, к чему они приведут, но и получить рекомендации исходя из опыта успешно реализованных проектов. Доверительное общение необходимо при долгосрочных отношениях, в которых заинтересованы обе стороны.
Наличие собственного подразделения разработчиков
Комплексные проекты предусматривают интеграцию с АСУП заказчика, импорт различных справочников или запрос на создание уникальных модулей. Все эти работы требуют разработки технического задания, программирования, тестирования и ввода в эксплуатацию. Тонкий момент, который часто не учитывают при создании модулей, – их поддержка и обновление в дальнейшем. Кто и как будет корректировать код через несколько лет, когда потребуется обновить или модифицировать систему? Если модуль создавали сторонние разработчики, не исключено, что со временем не удастся найти исходную информацию.
КОМПЛЕКСНОСТЬ ПРОЕКТА ВНЕДРЕНИЯ
Использование типовых решений
Возникающие задачи и процессы в отрасли схожи. Предприятию необязательно разрабатывать уникальный дизайн-проект для автоматизации конструкторско-технологической подготовки производства. Имеет смысл обратить внимание на предлагаемые поставщиком варианты реализации системы и ее настроек, на способы организации работ по внедрению, курсы подготовки специалистов и весь спектр наработок по автоматизации бизнес-процессов с учетом портфолио услуг и компетенций исполнителя. Важно отдавать предпочтение не уникальным, а хорошо отработанным решениям, причем как в техническом, так и в организационном плане на стадии внедрения. Бывает, что в системе не предусмотрены настройки под специфический запрос отдельного предприятия. В этом случае необходимо оценить степень его влияния на решаемые проблемы, и если она не существенна, то частично изменить принятый уклад на предприятии и не тратить ресурсы на доработки.
Модификация существующей инфраструктуры
До начала внедрения комплекса PLM необходимо провести аудит и оценить степень соответствия ИТ-ландшафта предприятия требованиям системы:
• производительность компьютеров пользователей;
• соответствие операционных систем;
• наличие сети, ее пропускная способность и стабильность;
• готовность серверов;
• наличие системы резервного копирования;
• наличие защищенных каналов связи.
По результатам этих работ запускается проект по модификации инфраструктуры, который должен быть неотделим от проекта внедрения PLM-комплекса или предшествовать ему. При внедрении PLM-системы необходимо мыслить не структурными подразделениями предприятия, а бизнес-процессами и вовлеченными в них данными. В этом случае выстраивается полная автоматизируемая цепочка и удается избежать разрыва из-за того, что какой-то отдел «не учли при планировании».
ВЫБОР РУКОВОДИТЕЛЯ ПРОЕКТА И ГРУППЫ ВНЕДРЕНИЯ СО СТОРОНЫ ПРЕДПРИЯТИЯ
PLM-проекты готовятся к запуску длительное время. До начала работ необходимо провести ряд мероприятий, помимо обновления компьютеров и инфраструктуры. Если на предприятии отсутствует проектный офис, то выбор руководителя проекта зачастую становится нетривиальной задачей, поскольку нужен специалист по управлению, имеющий достаточные полномочия, разбирающийся в процессах компании и полностью поглощенный данным проектом. Типичные ошибочные шаги по назначению руководителя проекта на предприятии.
• Шаг 1. Назначение ведущего специалиста или начальника бюро, например конструкторского подразделения. Данный специалист хорошо знает предметную область, но не видит бизнес-процесс разработки изделия целиком, кроме того, ему не хватает полномочий для продвижения работ в смежных подразделениях.
• Шаг 2. Руководство проектом передают высокопоставленному лицу, например заместителю генерального директора (главному конструктору, главному технологу, главному инженеру и т. п.). Данный специалист всегда «очень загружен», ему некогда управлять проектом внедрения PLM, особенно если проект не имеет статуса стратегически важного для предприятия.
• Шаг 3. Осознав неправильность предыдущих шагов и потеряв половину выделенного на работу времени, руководство предприятия назначает руководителем специально выделенного человека или специалиста со знаниями и уровнем полномочий заместителя руководителя ИТ-службы.
Таким образом, до начала проекта необходимо определиться с руководителем проекта и при необходимости обеспечить дополнительную подготовку, направив на курсы по управлению проектами (например, PMI) для повышения квалификации. Но в любом случае один руководитель проекта не сможет реализовать все работы по масштабному проекту внедрения PLM-системы. По каждому из направлений (администрирование, ведение справочников, управление пилотным проектом и пр.) потребуются выделенные специалисты – представители предприятия. Полный список ролей с описанием выполняемых действий можно запросить у поставщика решения, поскольку он владеет всей информацией (рис. 2).
РЕАЛИЗАЦИЯ ПРОЕКТА И ЗАВЫШЕННЫЕ ОЖИДАНИЯ
На стадии заключения договора необходимо согласовать и максимально точно зафиксировать договоренности о предстоящих работах, количественных оценках результатов и критериях защиты проекта. Для этого прорабатывается устав проекта, в котором указываются его границы, допущения, ответственность сторон, а также руководитель проекта. В противном случае во время реализации проекта будут постоянно изменяться работы и договоренности, что в результате приведет к искажению первоначально поставленных целей, бюджет и время будут затрачены на несущественные, а, возможно, и просто противоречивые действия.
Кроме того, отсутствие границ и допущений проекта приводит к завышенным ожиданиям – со стороны предприятия и перерасходу ресурсов – со стороны поставщика, при этом цели останутся недостижимы, а специалисты предприятия начнут требовать идеальной «автоматизации всего», не заботясь о решаемых бизнес-задачах. Поэтому для успешного достижения целей проекта необходимо держать в жестких рамках бюджет, запросы на изменения и грамотно управлять требованиями к проекту и конечному продукту.
УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА
В реальной жизни всегда присутствуют неопределенности, а в теории управления проектами этому посвящен целый раздел, но о практическом применении информация крайне скудная. В результате данный инструмент применятся редко, хотя его эффективность может быть высокой. Перед началом работ проводится идентификация и анализ рисков, то есть составляется перечень событий, влияющих на проект: приобретенное серверное оборудование не будет доставлено в срок, не будут готовы учебные классы, данные по пилотному изделию не будут введены в систему, качество справочников для импорта из ERP исключит их импорт в новую систему и пр. (рис. 3). Риски расписываются по всем направлениям работ: персонал, инфраструктура, финансы. Перечень рисков составляется по итогам мозгового штурма команды, ранее реализованных проектов или привлекаются эксперты поставщика решения, имеющие соответствующий опыт в отрасли. Затем для каждого риска на случай его наступления определяется план реагирования.
После такого анализа возникает много вопросов, которые необходимо решить до начала работ (рис. 4). В результате многие риски отпадают, так как будут предотвращены. Для оставшихся рисков будут предусмотрены действия, причем решения будут взвешенные и продуманные, так как принимаются не в цейтноте, когда нет времени разрабатывать и оценивать альтернативы. Количественная оценка стоимости действий на исправление последствий риска позволяет определить его влияние на проект и дополнительные ресурсы, которые могут потребоваться.
ЗАКЛЮЧЕНИЕ
Данная статья – «вершина айсберга», лишь частично раскрывающая неочевидные моменты, которые возникают при внедрении PLM-системы. Можно долго рассуждать о том, внедрять или нет комплексные системы либо обойтись локальными мероприятиями по автоматизации периодически возникающих «узких мест». Как системный интегратор с 20-летним стажем ведения крупных проектов мы говорим, что будут риски и сложности, но мы готовы поделиться опытом, чтобы обеспечить предприятиям возможность повышения конкурентных преимуществ в результате успешной реализации ИТ-проектов. ●
Предприятия выстраивают бизнес-стратегию развития в соответствии с запросами рынка, целевыми государственными программами и геополитическими факторами. Проследим влияние этих факторов на реализацию конкретного проекта в сфере ИТ.
В рамках курса на диверсификацию оборонных производств поручением Владимира Путина была установлена доля высокотехнологичной продукции гражданского и двойного назначения от общего объема продукции ОПК: с 16,4% в 2016 году до 17% к 2020-му, до 30% к 2025-му и до 50% к 2030 году. Это заставляет предприятия ОПК выходить на конкурентно-свободный рынок с его жесткими законами. Меняются требования к выпуску продукции, сроки радикально сокращаются, а привлекательность товара и его стоимость зачастую становятся критичными для успешной продажи. При использовании существующих методов разработки и производства изделий обеспечить качественную автоматизацию процессов непросто.
Предстоит менять подходы к разработке и выпуску продукции: высокая вариативность изделий при минимальном наборе уникальных комплектующих диктует необходимость разработки модульных систем; сокращение времени выхода на рынок влечет за собой серьезный пересмотр процессов принятия решений; для управления стоимостью продукции необходимо активно внедрять системы управления производством и предприятием в целом. Таким образом, ИТ-подразделения просто обязаны участвовать в реализации стратегии развития предприятия и использовать современные инструменты для решения перечисленных задач: переход к цифровому предприятию, применение современных САПР и управление электронным макетом изделия, внедрение систем управления данными КТПП, запуск систем управления производством и т. д. Следовательно, внедрение PLM на предприятии – это не попытка «автоматизации ради автоматизации», а жизненно необходимый проект по реализации бизнес-стратегии развития предприятия, требующий пристального внимания и активной поддержки руководством.
КРИТЕРИИ ВЫБОРА ПОСТАВЩИКА РЕШЕНИЙ
На стадии выбора поставщика решений есть смысл учитывать размер и надежность компании-интегратора, период времени работы на рынке услуг, уставной капитал, выручку за год, рентабельность и другие финансово-экономические показатели, определяющие уровень подрядчика на внутреннем рынке. Действительно, имеет ли смысл вкладывать ресурсы в красивый стартап, запущенный энергичным менеджером, если риски для вашей компании слишком велики?
Наличие необходимого штата технических специалистов и консультантов по внедрению также считается неотъемлемой частью работы с поставщиками. Причем знания профессионалов должны быть подтверждены международными стандартами и сертификатами. Важные признаки – прозрачность и общественная доступность таких сведений от независимого источника. Например, сайт VirtualTester предоставляет информацию о поставщиках в конкретном регионе с перечнем сертификатов, подтверждающих компетенции компании по направлениям (рис. 1).
Единый поставщик решений
При создании системы можно на разных этапах привлекать различные фирмы, ориентируясь на минимальную рыночную стоимость, а также выполнять часть работ своими силами. Такой подход предполагает множество рисков: недостаточную квалификацию исполнителей, отсутствие заинтересованности в конечном результате, поскольку существует вероятность переложить ответственность и сложные вопросы на стыках выполняемых работ на смежного исполнителя. Важно взаимодействовать с лицом, с которым можно решить все возникающие вопросы и которое несет ответственность за результат проекта. В этом случае поставщик заинтересован в качественном выполнении каждого этапа внедрения PLM-системы и учитывает стыковки результатов выполнения работ на разных стадиях.
Наличие успешной методики внедрения
Компании, давно занимающиеся реализацией комплексных проектов, используют выработанные годами подходы. Это минимизирует риски мероприятия, денежные затраты и сроки. Если сотрудники компании готовы детально и предельно ясно рассказать, как будет реализован проект, в какие сроки, какие специалисты потребуются со стороны предприятия, это свидетельствует о том, что они знают, что делают. В противном случае есть шанс стать если не жертвой смелого эксперимента, то подопытным кроликом.
В ходе обсуждения проекта у предприятия должна быть возможность не только узнать, какие компания-интегратор предлагает варианты, к чему они приведут, но и получить рекомендации исходя из опыта успешно реализованных проектов. Доверительное общение необходимо при долгосрочных отношениях, в которых заинтересованы обе стороны.
Наличие собственного подразделения разработчиков
Комплексные проекты предусматривают интеграцию с АСУП заказчика, импорт различных справочников или запрос на создание уникальных модулей. Все эти работы требуют разработки технического задания, программирования, тестирования и ввода в эксплуатацию. Тонкий момент, который часто не учитывают при создании модулей, – их поддержка и обновление в дальнейшем. Кто и как будет корректировать код через несколько лет, когда потребуется обновить или модифицировать систему? Если модуль создавали сторонние разработчики, не исключено, что со временем не удастся найти исходную информацию.
КОМПЛЕКСНОСТЬ ПРОЕКТА ВНЕДРЕНИЯ
Использование типовых решений
Возникающие задачи и процессы в отрасли схожи. Предприятию необязательно разрабатывать уникальный дизайн-проект для автоматизации конструкторско-технологической подготовки производства. Имеет смысл обратить внимание на предлагаемые поставщиком варианты реализации системы и ее настроек, на способы организации работ по внедрению, курсы подготовки специалистов и весь спектр наработок по автоматизации бизнес-процессов с учетом портфолио услуг и компетенций исполнителя. Важно отдавать предпочтение не уникальным, а хорошо отработанным решениям, причем как в техническом, так и в организационном плане на стадии внедрения. Бывает, что в системе не предусмотрены настройки под специфический запрос отдельного предприятия. В этом случае необходимо оценить степень его влияния на решаемые проблемы, и если она не существенна, то частично изменить принятый уклад на предприятии и не тратить ресурсы на доработки.
Модификация существующей инфраструктуры
До начала внедрения комплекса PLM необходимо провести аудит и оценить степень соответствия ИТ-ландшафта предприятия требованиям системы:
• производительность компьютеров пользователей;
• соответствие операционных систем;
• наличие сети, ее пропускная способность и стабильность;
• готовность серверов;
• наличие системы резервного копирования;
• наличие защищенных каналов связи.
По результатам этих работ запускается проект по модификации инфраструктуры, который должен быть неотделим от проекта внедрения PLM-комплекса или предшествовать ему. При внедрении PLM-системы необходимо мыслить не структурными подразделениями предприятия, а бизнес-процессами и вовлеченными в них данными. В этом случае выстраивается полная автоматизируемая цепочка и удается избежать разрыва из-за того, что какой-то отдел «не учли при планировании».
ВЫБОР РУКОВОДИТЕЛЯ ПРОЕКТА И ГРУППЫ ВНЕДРЕНИЯ СО СТОРОНЫ ПРЕДПРИЯТИЯ
PLM-проекты готовятся к запуску длительное время. До начала работ необходимо провести ряд мероприятий, помимо обновления компьютеров и инфраструктуры. Если на предприятии отсутствует проектный офис, то выбор руководителя проекта зачастую становится нетривиальной задачей, поскольку нужен специалист по управлению, имеющий достаточные полномочия, разбирающийся в процессах компании и полностью поглощенный данным проектом. Типичные ошибочные шаги по назначению руководителя проекта на предприятии.
• Шаг 1. Назначение ведущего специалиста или начальника бюро, например конструкторского подразделения. Данный специалист хорошо знает предметную область, но не видит бизнес-процесс разработки изделия целиком, кроме того, ему не хватает полномочий для продвижения работ в смежных подразделениях.
• Шаг 2. Руководство проектом передают высокопоставленному лицу, например заместителю генерального директора (главному конструктору, главному технологу, главному инженеру и т. п.). Данный специалист всегда «очень загружен», ему некогда управлять проектом внедрения PLM, особенно если проект не имеет статуса стратегически важного для предприятия.
• Шаг 3. Осознав неправильность предыдущих шагов и потеряв половину выделенного на работу времени, руководство предприятия назначает руководителем специально выделенного человека или специалиста со знаниями и уровнем полномочий заместителя руководителя ИТ-службы.
Таким образом, до начала проекта необходимо определиться с руководителем проекта и при необходимости обеспечить дополнительную подготовку, направив на курсы по управлению проектами (например, PMI) для повышения квалификации. Но в любом случае один руководитель проекта не сможет реализовать все работы по масштабному проекту внедрения PLM-системы. По каждому из направлений (администрирование, ведение справочников, управление пилотным проектом и пр.) потребуются выделенные специалисты – представители предприятия. Полный список ролей с описанием выполняемых действий можно запросить у поставщика решения, поскольку он владеет всей информацией (рис. 2).
РЕАЛИЗАЦИЯ ПРОЕКТА И ЗАВЫШЕННЫЕ ОЖИДАНИЯ
На стадии заключения договора необходимо согласовать и максимально точно зафиксировать договоренности о предстоящих работах, количественных оценках результатов и критериях защиты проекта. Для этого прорабатывается устав проекта, в котором указываются его границы, допущения, ответственность сторон, а также руководитель проекта. В противном случае во время реализации проекта будут постоянно изменяться работы и договоренности, что в результате приведет к искажению первоначально поставленных целей, бюджет и время будут затрачены на несущественные, а, возможно, и просто противоречивые действия.
Кроме того, отсутствие границ и допущений проекта приводит к завышенным ожиданиям – со стороны предприятия и перерасходу ресурсов – со стороны поставщика, при этом цели останутся недостижимы, а специалисты предприятия начнут требовать идеальной «автоматизации всего», не заботясь о решаемых бизнес-задачах. Поэтому для успешного достижения целей проекта необходимо держать в жестких рамках бюджет, запросы на изменения и грамотно управлять требованиями к проекту и конечному продукту.
УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА
В реальной жизни всегда присутствуют неопределенности, а в теории управления проектами этому посвящен целый раздел, но о практическом применении информация крайне скудная. В результате данный инструмент применятся редко, хотя его эффективность может быть высокой. Перед началом работ проводится идентификация и анализ рисков, то есть составляется перечень событий, влияющих на проект: приобретенное серверное оборудование не будет доставлено в срок, не будут готовы учебные классы, данные по пилотному изделию не будут введены в систему, качество справочников для импорта из ERP исключит их импорт в новую систему и пр. (рис. 3). Риски расписываются по всем направлениям работ: персонал, инфраструктура, финансы. Перечень рисков составляется по итогам мозгового штурма команды, ранее реализованных проектов или привлекаются эксперты поставщика решения, имеющие соответствующий опыт в отрасли. Затем для каждого риска на случай его наступления определяется план реагирования.
После такого анализа возникает много вопросов, которые необходимо решить до начала работ (рис. 4). В результате многие риски отпадают, так как будут предотвращены. Для оставшихся рисков будут предусмотрены действия, причем решения будут взвешенные и продуманные, так как принимаются не в цейтноте, когда нет времени разрабатывать и оценивать альтернативы. Количественная оценка стоимости действий на исправление последствий риска позволяет определить его влияние на проект и дополнительные ресурсы, которые могут потребоваться.
ЗАКЛЮЧЕНИЕ
Данная статья – «вершина айсберга», лишь частично раскрывающая неочевидные моменты, которые возникают при внедрении PLM-системы. Можно долго рассуждать о том, внедрять или нет комплексные системы либо обойтись локальными мероприятиями по автоматизации периодически возникающих «узких мест». Как системный интегратор с 20-летним стажем ведения крупных проектов мы говорим, что будут риски и сложности, но мы готовы поделиться опытом, чтобы обеспечить предприятиям возможность повышения конкурентных преимуществ в результате успешной реализации ИТ-проектов. ●
Отзывы читателей
