Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

The purpose of this wiki book

The development of the BPX role has been intertwined with the BPX community from the beginning. So it only seemed natural to Marco ten Vaanholt to include the community as he set out on a project to write a book about how to succeed in adopting the BPX role. Through this wiki the BPX community, experts invited from a wide variety of organizations, and the writing and editing team from Evolved Media will all collaborate to capture ideas and distill them into a useful and easy-to-read narrative.

Your valuable contributions will be mentioned in the community contributors section of the book. Contributing BPX Community Members

Status of the Book

This book (do you like the new title, Process First?) has now been sent to the printer, racing to get to print by TechEd. But because this is a collaborative book and a living book, the work goes on. The canonical version of the book lives on the wiki and is available for comment and improvement - right now, today. If you'd like to download the current version of the book in PDF format, click here. You'll find that the table of contents changed considerably in the process of the revision to the second version. If you'd like to see the older version, click here.


How to get involved

The model for community involvement in the BPX book is the way Chris Anderson, editor of Wired, used his blog in writing his book The Long Tail. Instead of throwing his content on a wiki and just letting anyone change it as they wished, the style that works in Wikipedia, Anderson instead tried out his ideas by presenting them on his blog and then harvesting the feedback, which was then incorporated into his writing process. Anderson did not present the finished text of his book on his blog for comment.

The BPX book project will take from Anderson's model the notion that the finished product should be written by a small collection of talented writers. But the ways for the community to collaborate and contribute in the process will be expanded. Finished content will also be posted on the wiki for comment. Here's how it will work:

  • Outlines and summaries of the content will be posted.
    • These outlines will include research questions that are being asked to those interviewed to provide content to the book.
  • The comments made on the outlines and summaries will then be incorporated into successive versions of the books, which will be posted on the wiki.
  • Any member of the BPX community will be able to comment on the content using the comments portion of the page.
  • If a BPX community member desires to actually write parts of the book, then they should contact Marilyn Pratt ( or Marco ten Vaanholt ( to get appropriate permissions to the wiki.
  • If a BPX community member desires to be interviewed for the book to provide additional ideas, they should contact Sara Kreisman ( who will be organizing a series of conference calls and interviews to extract new content.
  • If a BPX community member or anyone else would like to make a suggestion about the book that will not appear on the site, they can send email to

Recently Updated

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


Please do not hesitate to use icons, add images, etc.. as long as they can graphically depict what you want to be emphasized.

(smile) (sad) (tongue) (big grin) (wink) (thumbs up) (thumbs down) (info) (tick) (error) (warning) (plus) (minus) (question) (lightbulb) (grey lightbulb) (star) (red star) (green star) (blue star) (star)

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.