Product lifecycle что это
Хочу стать программистом: на примере PLM
Такое можно услышать от многих молодых и взрослых людей. Однако после недолгого гугления выясняется, что понятие «программист» такое же огромное как «доктор». Все сразу и одновременно охватить невозможно, поэтому давайте разберемся в основных направлениях по которым можно развиваться.
Если говорить в-кратце, то программирование это написание программ (ваш кэп). Эти программы нужны для того, чтобы автоматизировать какую-либо деятельность или для развлечения. Например, программы управления станками на заводе, автопилот в самолете, браузер в интернете, операционная система, программы управления бухгалтерией, программы для создания 3D моделей, игры, видео, проведение научных экспериментов, распространение информации… В общем, практически во всех видах деятельности человека присутствует программирование.
Правильнее говорить разработка программного обеспечения (ПО). Я, например, занимаюсь разработкой ПО для автоматизации инженерных и производственных процессов. Все, чем вы пользуетесь, скорее всего было создано на какой-либо фабрике или заводе. Изделия могут быть совершенно разными: смартфон, автомобиль, шампунь, пакетик чипсов, самолет, куртка, велосипед, телевизор и т.д. Практически все изделия производятся массово, хотя возможны некоторые изменения под конкретных людей или некоторые требования.
Так устроена производственная компания
Например, чтобы создать автомобиль, для начала надо придумать концепт и желательно показать его работоспособность и преимущества перед уже существующими аналогами (Research, Proof of Concept). Дальше этот концепт начинают прорабатывать, если изделие состоит из множества сложных компонентов, то разрабатываются технических требования на эти компоненты (Requirement Decomposition), в сложных система используется системное моделирование (Systems Modeling). Далее начинается процесс проектирования: создаются 3D модели на компьютере (Computer Aided Design); эти модели рассчитывают на различные характеристики (Computer Aided Engineering), чтобы изделие и его компоненты не сломались при первом же использовании (а сломались ровно после гарантийного срока и не позже :)), и, наконец, создаются технологические процессы для производства всего этого (Computer Aided Manufacturing), чтобы потом произвести на заводах и собрать (Planning and Execution). Как известно, в автомобиле есть огромное количество различных компонентов (деталей). И на каждую деталь существует документация: виртуальные модели, расчеты, производственные процессы. А еще надо не забывать, что не все получается с первого раза, и в процессе проектирования возникают корректировки, новые решения (Revision Management). В этих процессах участвуют огромное количество людей. И всеми этими данными, процессами и людьми надо управлять, и все это надо хранить. Для этого существуют системы управления данными (Product Data Management), системы планирования производства и системы управления производством (Manufacturing Execution System). А все вместе это называется управление жизненным циклом изделия (Product Lifecycle Management). И это я еще не касался управлением самой компанией, бизнесом, бухгалтерией, поставками и продажами клиентам (Enterprise Resource Planning).
А как же компании, которые занимаются разработкой ПО, ведь у них продукт — это ПО? Да, и для этого есть свой мир управления жизненным циклом приложений (Application Lifecycle Management, ALM). Здесь применение средств автоматизации процессов еще более необходимо, так как наплодить кучу файлов куда проще чем кучу бумаги. Про ALM многие знают, и, чтобы не раздувать статью, я отправлю вас по ссылке за знаниями.
Ну, так вот, о чем это я. Ах да, разработка ПО. Как видно, систем много, и они, мягко говоря, не особо понятны. Но без них вы бы вряд ли сейчас вообще читали эту статью, так как читать ее было бы не с чего.
Итак ПО — это целая система, которая состоит из отдельных модулей, которые отвечают за разные функции системы.
Для того, чтобы создать ПО, надо вначале понять, что вообще должно делать это ваше ПО. Практически все программы состоят из различных модулей, которые отвечают за те или иные функции системы. Например, на любимом вашем смартфоне есть модуль для вывода картинки на экран, есть модуль для пересылки файлов, для передачи и получения данных по интернету, для распараллеливания задач и о-о-чень много чего еще.
Понять, как различные компоненты должны взаимодействовать, — это важнейшая задача, и она называется проектирование архитектуры ПО. Это самое главное! Причем архитектура есть как у всей системы, так и у отдельной маленькой программы. Например, какой вид обхода графа вы создадите и как будете обрабатывать информацию его узлов (последовательная обработка на лету, раскидывание по потокам, колбэк функции и т.д.). Любой разработчик ПО обязан это понимать. Если он это не понимает, то он еще не разработчик ПО.
Но и это еще не все. Как можно понять, какая архитектура будет лучше, если не понимаешь, какие задачи должно решать это ПО? Например, создание 3D моделей состоит не просто в создании точек, линий и поверхностей. Все эти объекты должны быть связаны между собой. Даже простейший кубик: если я изменю координаты одной точки, то должны измениться также связанные с ней кривые и поверхности. Если для создания скругления между двумя поверхностями пользователь должен вырисовывать каждую поверхность скругления вручную, то он просто ахренеет и пошлет все это дело. Он хочет просто выделить поверхности, между которыми надо сделать скругление и задать радиус (в простейшем случае). Также пользователь хочет иметь возможность изменять значения радиуса в будущем, чтобы при этом не разрушались ассоциативные связи в моделе.
Note: В компьютерной графике можно выделить 3 основных вида моделей геометрии: полигональная модель, математическая модель и параметрическая модель. Чтобы было понятно я приведу примеры, как выглядит модель, состоящая из нескольких поверхностей:
Все это требует от разработчика ПО знание области, которую он автоматизирует. В случае с созданием 3D моделей для инженеров — он должен понимать принципы проектирования (mechanical engineering) и производства (manufacturing engineering). То есть он должен думать и как инженер и как разработчик ПО.
А не дохрена ли навесили на разработчика ПО? — спросите вы. Действительно, не мало. Однако есть и приятные моменты — фреймворки. Это такие, уже запрограммированные шаблоны архитектур, абстрактные реализации. Не стоит путать их с библиотеками. Библиотеки — это наборы не связанных или мало связанных между собой функций или объектов. Например: библиотека для работы с матричным представлением данных в python — NumPy; фреймворка OpenCASCADE — для параметрического 3D моделирования.
И тут мы подходим к двум важным понятиям: разработчик ПО и программист. В русском языке нет устоявшейся разницы между этими понятиями. В цивилизованном же мире она давно известна: разработчик ПО — Software Engineer, программист — Software Developer.
Если в кратце, то Software Engineer — это тот, кто придумывает, как должно работать ПО в целом, как оно решает поставленные проблемы, продумывает архитектуру на верхнем уровне и создает задачи по реализации компонентов для Software Developer’ов, а в определенных случаях сам же их и реализовывает. Также существуют другие роли: project manager, team lead, software architect, database administrator, devops, qa engineer, reliability engineer и можно напридумывать еще много кого. Основная причина разделения — это большой объем работ по конкретным задачам. Например, если есть несколько баз данных, и их надо администрировать и следить за их безотказностью, или компания разрабатывает и поддерживает несколько версий продукта, который состоит из нескольких больших модулей (разработка операционной системы, системы автоматизированного проектирования о которых я писал выше и т.п.).
Казалось бы, что Software Engineer на много круче, но это не правильно вот так вот разделять. Да, у него больше знаний из различных дисциплин и больше ответственности. Задача Software Developer’а написать быстро работающий код, отладить его, покрыть его тестами и уложиться в сроки. Я бы сравнил это с управленцами и исполнителями — и те и те не могут существовать по одиночке.
В заключении хочу отметить, что основная проблема в автоматизации — это человек. Человеку свойственно совершать ошибки, у него бывает разное настроение, разные физические и умственные возможности, разный менталитет. Это главная причина по которой в бизнесс процессах происходят сбои и задержки. Однако, существуют фундаментальные ограничения из-за которых невозможно создать полностью автоматизированный процесс разработки изделий. Например постановки задачи оптимизации или упрощение 3D модели для гидрогазодинамического конечно-объемного расчета. А связано это с фундаментальными проблемами алгоритмов, которые невозможно распараллелить, либо вообще алгоритмы, которые невозможно завершить в общем случае за полиноменальное время (NP-класс). И я не говорю к сожалению это или к счастью, потому что если искусственный интеллект сможет создавать себе подобные машины будет совсем другое время. Но это уже рассуждения для другой статьи..
Product Lifecycle Management. Популярно о процессах управления жизненным циклом телекоммуникационных услуг
Все мы пользуеся услугами связи для самых разных целей: получить доуступ к любимым сайтам и блогам, пообщаться с любимыми, друзьями и коллегами, провести переговоры, посмотреть любимые телепередачи или онлайн трансляции, отправить почтовые сообщения. Эра телеккомуникаций подарила нам невообразимые возможности и огромный спектр новейших товаров и услуг. Одними из ключевых услуг являются непосредственно телекоммуникационные: доступ в интернет, голосовая связь, телевидение и могие другие. Я работаю в сфере телекоммуникаций и хотел бы рассказать как рождаются телекоммуникационные услуги, как они развиваются и обслуживаются и как умирают.
Наверное, следует начать с терминологии. Под услугой мы понимаем коммерческий продукт (product), который предоставляется конечному пользователю, имеет стоимость и условия обслуживания, подразумевает наличие договора на его предоставление. Вы можете видеть, что на рынке представлено множество телекоммуникационных услуг по самым разным ценам и на самых разных условиях, но все они обеспечиваются узким спектром телекоммуникационных сервисов (service). Сервисы могут быть базовыми и дополнительными, и все они обеспечиваются стеком информационных систем и телекоммуникационного оборудования. Чтобы лучше понять различия между продуктом и сервисом можно привести пример: доступ в интернет является сервисом, а доступ в интернет со скоростью 10Mbps по цене 600р в месяц является продуктом.
Так как сервисы являются основой бизнеса предприятий связи, обеспечение процессов управления их жизненным циклом является очень важной функцией. Построение PLM (product lifecycle management) процессов всегда начинается с разработки модели сервисов. Существует множество методологий, но самой распространенной является модель TMForum SID (Shared Information Data). Я хочу на примере этой модели рассказать как появляются сервисы. Начать следует с метамодели, которая в упрощенном виде выглядит следующим образом:
В модели представлены три класса сущностей. Сущность класса Customer Facing Service (CFS) это сервис, который непосредственно использует конечный пользователь, например пресловутый доступ в интернет. Сервис CFS является минимальной атомарной единицей для создания коммерческого продукта. Сущность класса Resource Facing Service (RFS) это сервис, который предоставляется телекоммуникационным оборудованием или информационной системой и обспечивает существование сервиса CFS, например одним из таких сервисов для обеспечения доступа в интернет является авторизационный сервис AAA сервера. Как правило, конечный пользователь ничего не знает о сервисе RFS. Сущность класса Resource это спецификаци телекоммуникационного оборудования или информационной системы, обеспечивающей сервис RFS. Важно отметить, что структура сервисов может быть иерархичной и иметь множественную вложенность.
Управление моделью сревисов и их жизненным циклом осуществляется в информационной системе с неожиданным названием сервисный каталог (service catalogue), так же её называют технологический каталог. Сервисный каталог, неспроста, занимает центральное место в стеке систем сервисного уровня информационных систем предприятия по TMForum TAM (Telecomm Application Map), так как он является именно тем стыком между технологиями и коммерцией. На базе моделей и спецификаций сервисов, заложенных в каталоге, работают такие информационные системы сервсиного стека, как Service Order Management, Service Inventory, Service Provisioning, Service Assurance и другие. Важно понимать, что когда я говорю о системах, я подразумеваю роли. Зачастую, одна промышленная информационныя система может исполнять сразу несколько ролей. Такие системы предлагают многие производители решений для телекоммуникаций, как Oracle, Amdocs, Comptel, HP и другие.
На этом закончим с теорией и перейдем к практике – попробуем построить модель сервисов. Давайте представим, что мы установили новый сетевой элемент и опубликовали его спецификацию. Для примера я выбрал SIP сервер, который может быть, как отдельностоящей системой, так и частью, например, IMS. SIP сервер предоставляет голосовую связь по IP каналам. SIP телефония имеет огромные преимущества перед аналоговой или цифровой, т.к. может полноценно использоваться в облаках. Другими словами, мы можем позволить абоненту воспользоваться сервисом из дома (имея нашу локальную сеть), мобильного телефона (по локальной сети мобильного оператора или с использованием GPRS/LTE), из любой точки мира по IP каналу (например, WiFi в Starbucks где-нибудь в Лондоне). В общем и целом сервис сугубо облачный и конвергентный.
Получив спецификацию SIP сервера мы, в первую очередь, должны выяснить какие сервисы RFS он предоставляет, чаще всего это:
Далее следует определить сервис CFS, который потом ляжет в основу множества коммерческих продуктов с различными опциями и условиями предоставления. В качестве примера, можно все пять сервисов RFS объединить в один сервис CFS с опциями:
Важно понимать, что не только сервис CFS может иметь опции, но и сервисы RFS также.
Все опции и параметры сервиса составляют его спецификацию. В спецификации также описываются зависимости, взаимоисключения, кардинальность и функции по управлению сервисом (как правило по CRUD – create, read, update, delete). В результате мы построили полноценную сервисную модель с определенными упрощениями.
Теперь стоит остановиться на функциях управления, которые на общепринятом языке называются Fulfillment Functions. Для сервиса каждая функция описывает, как минимум правила его дизайна, активации на сети, сохранения в системе инвентаризации и постановку на мониторинг. За последовательность и корректность исполнения всех функций отвечает система Service Order Management, а непосредственно сущность, которой она управляет это сервисный заказ или Service Order. Существует базовая методология описания функций управления: design, assign, activate.
В следующей статье, я попробую, также кратко, осветить процесс создания коммерческих продуктов на базе созданной сервисной модели.
product life cycle
Полезное
Смотреть что такое «product life cycle» в других словарях:
product life cycle — UK US noun [S] (also product cycle, product s life cycle, ABBREVIATION plc) MARKETING, COMMERCE ► the stages in a particular product s existence: introduction, growth or increasing sales, maturity (= slow or no increase in sales), and decline or… … Financial and business terms
product life cycle — noun The four stages in the economic evolution of a product, ie introduction, growth, maturity and decline • • • Main Entry: ↑produce … Useful english dictionary
product life cycle — The course of a product s sales and profitability over its lifetime. The model describes five stages, each of which represents a different opportunity for the marketer. A new product starts in the development stage, during which the original idea … Big dictionary of business and management
product life cycle — /ˌprɒdʌkt laɪf ˌsaɪk(ə)l/ noun stages in the life of a product in terms of sales and profitability, from its launch to its decline ● Growth is the first stage in the product life cycle. ● The machine has reached a point in its product life cycle… … Marketing dictionary in english
Product Life Cycle — The period of time over which an item is developed, brought to market and eventually removed from the market. First, the idea for a product undergoes research and development. If the idea is determined to be feasible and potentially profitable,… … Investment dictionary
Product life cycle — Der Produktlebenszyklus ist ein Konzept der Betriebswirtschaftslehre und beschreibt den Prozess zwischen der Markteinführung bzw. Fertigstellung eines marktfähigen Gutes und seiner Herausnahme aus dem Markt. Dabei wird die „Lebensdauer“ eines… … Deutsch Wikipedia
product life cycle — (PLC) Stages a product goes through in the marketplace, including introduction, growth, maturity, and decline. PLC was once used exclusively among marketers, but in the 1990s it is used by accountants and finance managers concerned with whether… … American business jargon
Product life cycle management — is the succession of strategies used by management as a product goes through its product life cycle. The conditions in which a product is sold changes over time and must be managed as it moves through its succession of stages. Product life… … Wikipedia
product life cycle management — ➔ management * * * product life cycle management UK US noun [U] (also PLM) MARKETING, COMMERCE ► decisions that are made about a product s appearance, price, advertising, etc. to suit each stage in the product life cycle: »Toyota is one of many… … Financial and business terms
Product life-cycle theory — The product life cycle theory is an economic theory that was developed by Raymond Vernon in response to the failure of the Heckscher Ohlin model to explain the observed pattern of international trade. The theory suggests that early in a product s … Wikipedia
Product Life Cycle Management — The observation of an item as it moves through the typical stages of development, growth, maturity and decline. Effective product life cycle management brings together the many companies, departments and employees involved with the product s… … Investment dictionary
Product lifecycle что это
Концепция «Product Life Cycle» (PLM, Жизненный цикл товара) – концепция жизни продукта (и управления им), проходящего через стадии жизни, возникла е ще в 1931 году. Otto Kleppner (Отто Клеппнер) стал предшественником того, что мы теперь понимаем под базовым жизненным циклом продукта. В своем классическом тексте «Advertising Procedure» он утверждал, что большинство продуктов проходит через стадии: «новаторства», «конкуренции» и «в памяти» (Kleppner 1931, p. 5).
Howard (1981, стр. 237) сообщает, что известный австрийский экономист Joseph Schumpter (1939), похоже, ясно признавал явление, подобное жизненному циклу продукта, в своей теории экономического развития. Но в течение большей части 1930-х, 40-х и 50-х годов маркетинговая мысль была направлена на понимание товарного, институционального и функционального подходов к маркетингу.
Joel Dean (1950, 1951) часто приписывают то, что он был пионером этой концепции, хотя он явно не обозначал эту концепцию.
Muhs (1985) обнаружил, что первое упоминание, которое фактически обозначило концепцию как «жизненный цикл продукта», появилось в 1957 году. После анализа данных более 300 клиентов, компанией «Booz, Allen и Hamilton», был проведен обширный обзор литературы и новых данных о продуктах. Затем Jones, менеджер по планированию новых продуктов в «Booz, Allen и Hamilton», сделал следующее наблюдение:
В этом же году Kotler (1965) публикует работу «Отказ от слабых продуктов».
Хофер (1975) утверждал, что «самый фундаментальный переменной в определении соответствующей бизнес-стратегии является концепция этапов жизненного цикла продукта «. Аналогично, Biggadike (1981) определил жизненный цикл продукта как один из пяти основных вкладов, который маркетинг внес в стратегическое управление.
Одним из первых зарегистрированных практических применений PLM считается реализация концепции в American Motors Corporation (AMC) в 1985 году. Чтобы лучше конкурировать с более крупными компаниями, при отсутствии больших бюджетов, AMC решила сделать упор на поддержку жизненного цикла джипов. Следуя этой стратегии, представив свой компактный Jeep Cherokee, как современный спортивный внедорожник, AMC начал разработку новой модели, которая в конечном итоге дебютировала как Jeep Grand Cherokee.
Сегодня концепция «Product Life Cycle» спользуется руководством и специалистами по маркетингу как инструмент-индикатор, определяющий необходимость увеличения рекламы, снижения цен, выхода на новые рынки или изменения дизайна упаковки. Процесс выработки путей непрерывной поддержки продукта называется управлением жизненным циклом продукта.
Product Lifecycle Management
Product Lifecycle Management (PLM) — жизненный цикл продукта, изделия. Здесь продразумевается совокупность процессов, выполняемые от момента выявления потребностей общества в определенном продукте до утилизации изделия после его использования. Понятие применимо для любого изделия сферы информационных технологий и не только.
Содержание
При современном подходе можно выделить 11 этапов ЖЦ изделия:
Развитие PLM
Сам термин «управление жизненным циклом изделия» появился как результат почти двадцатилетней эволюции соответствующих рынков и технологий. Для середины начала 1990-х гг. единого мнения относительно того, что именно следует относить к категории информация об изделии, (особенно в смысле инженерных данных) попросту не существовало. Постепенно эти данные стали конкретизироваться, как данные об изделии. Именно в это время появился термин «управление данными об изделии» (PDM). Последние несколько лет внесли окончательную ясность: отрасль сформировалась и постоянно расширяется как по степени охвата, так и по мощности предлагаемых решений, благодаря чему, собственно, и был принят термин PLM. Этот термин ныне используется для описания бизнес-подходов к:
В ходе развития PLM менялись и подходы к определению жизненного цикла изделия. Так, если двадцать лет назад под жизненным циклом понимались, как правило, проектные и конструкторские работы, поскольку инструментальные средства были сосредоточены прежде всего на автоматизированном проектировании при управлении данными, то в конце 1980-х подход включил уже и поток операций, и процессы, происходящие при развитии жизненного цикла изделия. Таким образом, имеет место обмен информацией и процессами между различными направлениями опытно-конструкторских работ.
Применение PLM
Область применения PLM-систем растет быстрыми темпами. Она интегрирует такие сферы деятельности, в которых использование интеллектуальных активов, связанных с изделием и обмен такими активами обеспечивают заметное увеличение ценности. Использование таких систем дает предприятиям возможность производить продукцию необходимого качества и обеспечивает заказчикам и пользователям наилучшие преимущества в работе с конкретными видами продуктов. Сращивание PLM с другими областями приносит новые возможности и открывает такие сферы, где потенциал связанного с изделием интеллектуального капитала реализуется внутри расширенного предприятия. Сейчас PLM применяют в следующих областях:
Основные задачи PLM
Принято выделять шесть основных ключевых задач работы PLM в рамках ведения продукта от разработки до утилизации:
Управление данными о продукте
Данные о продукте занимают значительную часть в общем объеме информации, используемой на протяжении жизненного цикла изделия. На основе этих данных решаются задачи производства, материально-технического снабжения, сбыта, эксплуатации и ремонта. Как видно из практики, даже частичное электронное представление сокращает сроки производства изделия в полтора раза и приводит к уменьшению затрат на 50-80%. Согласно ключевому стандарту CALS-технологий ISO 10303 необходима гармонизация терминологии, типов, видов документов, форматов их электронного представления, протоколов работы с ними, средств защиты от несанкционированного доступа.
Управление жизненным циклом оборудования
PLM-решение помогает предприятиям при планировании, эксплуатации, техническом обслуживании и замене оборудования, обеспечивая им возможность достижения более высокого уровня контроля и точности работы оборудования. Управление жизненным циклом оборудования подразумевает целый ряд функций, направленных на улучшение работы в целом, обеспечение бесперебойного цикла производства и т.д.
Программно-проектное управление
Данная функциональная область предоставляет информацию для принятия стратегического решения по производимой продукции. Для эффективного управления проект должен быть хорошо структурирован – разбит на увязанные между собой пакеты работ, что позволяет контролировать бюджет изделия, планировать необходимые мощности, управлять коммуникационными потоками.
Поддежка взаимодействия
Увеличение эффективности разработки продукта позволяет значительно сократить его себестоимость, и, тем самым, повысить конкурентоспособность. Тесная интеграция процессов проектирования, производства, сбыта и обслуживания повышает эффективность вывода нового продукта на рынок за счет обеспечения незамедлительной и непрерывной обратной связи на протяжении всех этапов разработки.
Управление качеством
Возросшая конкуренция привела к заметному ужесточению требований, предъявляемых потребителем к качеству продукции. Чтобы сохранить конкурентоспособность и вести экономическую деятельность без убытков, необходимо применять эффективные и результативные системы контроля качества на всех этапах жизненного цикла продукта. Этот аспект достаточно широк, он включает в себя маркетинг, проектирование и разработку технических условий, материально-техническое снабжение и закупку, разработку производственных процессов, собственно производство, контроль испытаний, сертификацию, монтаж, эксплуатацию, техобслуживание и утилизацию. PLM-системы помогают решать задачи такого рода с большим эффектом.
Соблюдение требований охраны природы
PLM-системы, помимо всего прочего, должны включать в ссебя компоненты, призванные снизить затраты, минимизировать риски и учесть требования регулирующего законодательства, что способствует сохранению положительной репутации компании в глазах общественности, расширяет возможности по повышению квалификации персонала за счет поддержки обмена информацией в рамках всей организации. Кроме того, применение таких приложений в системе PLM-решения значительно снижает время на заполнение бланков предписаний по технике безопасности.