Michael Andersson of Ericsson presented a breakout session on their BPM framework for product development in a global environment. Although many people are familiar with them as a handset manufacturer, Ericsson’s biggest business is to create and service communication networks that provide the infrastructure for telecom operators (their customers), and provide solutions to the telecom operators to pass on to the end consumers. With 100,000 employees and several product development locations around the world, they are actually the 5th-largest software development company in the world (by sales) as well as providing hardware solutions.
Their classical way of working, which is the same in many large-scale project-driven development efforts, was very waterfall-like: long release cycles based on static requirements, requiring extensive testing and very inflexible to change requests. They are moving to a more agile approach with frequent small deliverables, which is easier to test and deploy, and allows for more customer interaction during development.
The interesting part is that they’re using BPM for their product development cycle, which is not an application that I see very often: they have created a BPM framework within their product development ecosystem, which acts as a toolbox for managing and collaborating on requirements and the product development lifecycle. The ecosystem provides different perspectives to allow the different types of stakeholders to see a view of product development that is meaningful to them.
He walked through each of the perspectives (what I would consider tools or capabilities, not perspectives in the EA sense) and explained the use and audience for each; they all center around the product development framework portal. This framework provides guidance for different product development practices, and contains all knowledge for how they operate when developing products: product development principles; directives and guidelines (rules and policies); process flows (value chains); process components (procedural processes); performance measurements; and enabling resources in terms of information, IT and organization. Although most of this is provided top-down on an organizational basis, the process components (processes) are provided by the operational units doing product development in a more socially collaborative way.
A big benefit of the framework is to provide context for the engineers working in product development who might previously have only considered their own processes, and not how those relate to value chains, which in turn is a representation of the customer requirements. It also provides the platform for collaboration and sharing with other engineers in other geographic locations and business areas, or provides an interface to collaboration tools that are already in use.
This was really about BPM as a methodology, not a tool or system to be implemented; as Andersson said in his summary, you probably want to do BPM, but you may not want to call it BPM.