Before modeling the design of the system, a project team typically models the business processes to identify the scope of the planned system and to ensure that any chosen system aligns to the demands of both this business model and business vision.

A variety of possible diagram techniques exist for delivering this business model, as well as possible levels of ambition. With business redesign, a risk occurs of having eyes for nothing else but the modeling and ignoring some real dangers. The hard work isn't about creating a best-of-breed business model; it's about enforcing corporate change within the organization. To remind the reader of these risks, we've made separate box diagrams of the more fancy UML features. Here, lengthy modeling exercises might become a convenient excuse for avoiding challenge and confrontation with the permafrost layers found in many organizations. This challenge and lack of confrontation is a common pitfall in implementing new business practices. Therefore, process innovation methodologies spend little time analyzing the current (as is) processes – often, a quick diagnosis is enough. Instead, we focus on the new business models: the business to be.

Ownership of the business models must remain with the stakeholders and process owners. This avoids the danger of the new processes being seen as the work of the IT department, which can lead to rejection of the models by the process owners. It must be made clear that the IT specialists act only as agents in producing the business models.