What content is needed
By reading the outline below, you will quickly get an idea of the scope and content of the book. There is no limit to community contributions but the writing team is hoping that BPX community members help in the following ways:
- Provide examples that illustrate the points made in the content.
- These examples don't have to be about specific companies, although that's fine if you can get permission to use their names. We are far more interested in explaining the dynamics of real-world situations than in naming specific companies.
- Provide answers to the questions posed in the outlines.
- Suggest additional questions that should be asked.
- Provide suggestions for improvement of the design of the content including:
- Explanatory metaphors
- Stories and analogies
- Information graphics (just a text description or a sketch will do; if you're adventurous, try Gliffy)
- Additional sections or subheads that may be needed
- Sections or subheads that should be shortened or deleted
- Revisions and edits to specific language
- New content in written form
- You can also add sticky notes like below ( just copy and paste )
 | Sticky Note Example a sticky note |
Icons
Please do not hesitate to use icons, add images, etc.. as long as they can graphically depict what you want to be emphasized.

Book Summary
Designing and automating business processes in the modern business world requires two sorts of deep expertise: intimate knowledge of business practices and a wide knowledge of the capabilities of technology.
On the one hand, the way that business gets done has become increasingly complex: outsourcing, business networks, contract manufacturing, and collaborative processes like vendor-managed inventory have blurred the boundaries between what is inside and what is outside the walls of a company. Add to this the new, looser forms of collaboration that fall under the umbrella of Enterprise 2.0, and the number of ways of designing a business process rapidly, multiply.
On the other hand, the ways of automating business processes have also ballooned. Vendor-provided software can be configured to solve problems and then be delivered as installed software, or as a service. Web services are being built on top of enterprise applications and are available from dozens of locations over the web. Service-oriented architecture and business-process modeling have come of age as techniques; as a result, new categories of software such as widget frameworks and mashups offer previously unobtainable solutions. Frequently, programming can be done visually in a simplified manner that clears the skill bottleneck.
To design and automate a business process, then, requires an understanding of what business goals you want to achieve and how available technology can provide a solution. Current methods of buiness case building and solution design frequently enforce a specialization that separates business analysis from technology implementation. A business analyst improves an existing business process or designs a new one on the basis of an often not available business case. A requirements document is created and delivered to technologists who attempt to understand it and then provide a solution. Often there are significant breakdowns in communication; what is delivered is not what is wanted by the end user or line of business manager. There is little room for learning and improving requirements during the process of creating the solution, without delaying a project deadline.
The role of the Business Process Expert (BPX) is a solution to the problems inherent in the business/technology divide. The people who fill this role are called BPXers, and their mission is to solve the communication problem between business and technology by learning to live in both worlds. Empathy is perhaps the defining characteristic of a BPXer, whose mission is based on the premise that success in building solutions is made more likely when one person is sophisticated in both the world of business and technology. The BPXer, however, is not, as we will see, a single role; it is rather a category of roles played by people who bridge the world of business and technology.
The task of designing, improving, and automating business processes includes continual tradeoffs. Sometimes the ideal process cannot be supported by existing systems. To automate it would require extensive custom development. When is it better to adapt the process to a shape that can be automated by existing technology? When is it better to invest in that custom development? In other situations, automation occasionally attempts to solve too much of the problem. Instead of providing information to a worker and letting them figure out the next step, business processes can seek to do everything and take away choice. What is the right balance between brains and automated brawn? The BPXer lives to answer questions such as these.
As such, the BPXer can be a prime mover of growth, driving change and differentiation through optimization and innovation across company silos or even entire ecosystems. BPXers can help your business intensify its competitive edge. The rise of the BPX role brings renewed vitality for companies with the vision to see its enormous value. Why? Because the BPXer's knowledge and skills, both hard and soft, enable him or her to move between business and technological landscapes with facility and ease. As a result, business processes, and thus companies, can become more efficient, adaptable, and innovative.
In this context, Marco ten Vaanholt and other members of the BPX community are coming together to write a book that will explain the roles, skills, and responsibilities that the ideal BPXer will need to succeed. The authors will also discuss the technological environment in which the BPXer can be expected to thrive, the ways in which the BPX role can drive and manage organizational change, and, lastly, patterns of success to look for as a result of deploying BPXers to optimize existing processes and innovate new ones.