Motivation

IBM sees multiple ALM-PLM scenarios of interest such as arising from

1) work with customers on projects to help them improve their processes or optimise their IT enviornment within their prevailing business goals and initiatives like operational excellence or strategic growth

2) helping customers get effective use from IBM products such as Rational, WebSphere? , Lotus, Tivoli, Information Management products, together and in a wider setting, this may be within the objectives of a prevailing customer business cases or an IBM product roadmap

3) product and system lifecycle activities within IBM initernal, which may have business goals like cycle time reduction or expense reduction

4) supporting selected industry initiatives and business partners which are typically linked to strategic segment initiatives or internal cost reduction

5) web and enterprise integration technology research and development which will have typical goals around innovation, re-use and time to market

Approach

IBM is contributing to multiple initiatives which may have relevance to this activity such as around industry standards, open-source and community based specification. In this way IBM has made significant contributions to eclipse and Linux, for example, and more recently been a pioneer with a community based development approach used for the Jazz platform based products. In addition, IBM has pioneer a standards and framework approach to PLM integration through it's Product Development Integration Framework, this has been a multi-year focus across multiple IBM solution service and product lines to help customers address some of these kind of challenges.

As the Rational product portfolio has expanded, more and more based upon the Jazz platform, there are multiple opportunities to leverage new and well proven products, BPM, SOA, Industry frameworks, Jazz, OSLC and Web 2.0 based capability to drive new business value in an enterprise setting. This can help drive the kind of business goals and objectives outlined above.

So here we hope to focus on the application and build out of the OSLC community specs, in doing so to point up opportunities for Rational product roadmaps and enable additional viable options for customers to exploit.

Enterprise, or even Extended-Enterprise Context for PLM

To assist communication, prioritisation and choice of scenarios

Fundamental there appear to be three main dimensions of interest

1. which business values to target ? the business justification
2. where within an operational scope of PLM to focus or what PLM capability to enable or improve? the PLM capability
3. how to realise the PLM capability changes ? the PLM transformation practices

Significant work has been done recently on all of these dimensions which maybe of value to the PLM Workgroup.

Segmentation of ALM and PLM

This topic is developing as a set of concerns related to the management of software applications in the context of a wider system or product lifecycle extended enterprise setting. C/ALM provides a potential starting point for ALM at least and at our opening meeting we identified a number of concerns

1. PLM product or System identities used within the ALM environment such as to name (e.g. identify, classify or associate) activities and artefacts
2. Location of ALM content from a PLM or system context and/or location of relevant PLM content from an ALM or system context
3. ALM deliveries of product or system content (artefacts) into a PLM setting such as part of a release managed by PLM
4. Flows of plans, requirements, quality info and change activities and items between ALM and PLM or System context
5. Analytics, reporting from ALM to PLM, from PLM to ALM or combinations including a System context
6. Organisation, role, approvals and authorities affecting ALM in a PLM setting or System context
7. Establishment, association and maintenance of configurations, variants, options and their effectivity

Approach to scenarios

Recently good use has been achieved by using a user story approach which bridges nicely to PLM capability as it keeps a focus on stakeholder and business outcome, which enables a way to bridge with measured capbility imporvement techniques.

Scenario example

Example #1 Assignment of product identity to incoming customer request

Source: Project to support customer

Situation: Within a company with multiple and changing product lines, which are sold and provided as individual products and in sophisticated combinations including customisation in a B2B? business model. In a Business unit, and thus within organisations responsible for Technical Pre-Sale, Post-Sales, Services Help Desk. Incoming customer requests from major customers are evaluated and then assigned to a relevant product family or product identity. Customer requests can arise at multiple points during Pre-Sales, Implementation or Operation.Customer requests need to be evaluated for example as queries for information, problems, requirements or new sales opportunities or no bid/return.

Problem statement: Delays to handle customer requests and rework due to late or incorrect identification of affected product

Frequency: 10,000 per annum for a significant business unit

Process name: Customer request handling

Process variance: Expect 10-20 ways to process depending. Opportunity to reduce variance tolow (<5 ways)

Business strategy: Improve competitiveness and market share

Business initiative: Improve customer responsiveness

Business objective: Reduce cycle time, reduce operating cost

Operational objective: Cycle time from raising the request to acceptance by Product line (< x days), Allocation rejection rate(<x %)

Sponsor: COO, BU exec,

Stakeholder (Persona): Pre-Sales Technical Specialist

User Story Summary: The BU Pre-Sales Technical Specialist wants to make an initial alignment of the Customer Request to standard products and services so that the request can be accepted by a Product line owner in 1 business day

Primary Business Subject Areas: Customer Request (M), Product (M), Organisation (S), Authorities (S)

PLM capability: Customer request management

ALM-PLM Capabilities:

Potential elements highlightedin italics

1. PLM product or System identities used within the ALM environment such as to name (e.g. identify, classify or associate) activities and artefacts
2. Location of ALM content from a PLM or system context and/or location of relevant PLM content from an ALM or system context
3. ALM deliveries of product or system content (artefacts) into a PLM setting such as part of a release managed by PLM
4. Flows of plans, requirements, quality info and change activities and items between ALM and PLM or System context
5. Analytics, reporting from ALM to PLM, from PLM to ALM or combinations including a System context
6. Organisation, role, approvals and authorities affecting ALM in a PLM setting or System context
7. Establishment, association and maintenance of configurations, variants, options and their effectivity

Pre-condition: Customer request exists with adequate description to enable allocation or discernment of relevant product line or family

Sunny day Post condition Customer request allocated to a product line or family (M) organisation (S) authorised role (C)

Rainy day Post condition Customer request rejected no valid product applicable (S) authorised role (C)

Likely applicable OSLC Specs: CM, RM, Estimation and Measurement

Note above: The priorities refer to a MoSCoW approach - Must, Should, Could, Wont (this time)

Additional examples

For example see the CALM Systems scenarios being built up on jazz.net https://jazz.net/wiki/bin/view/Main/SDwithCALM