Detail: Define Business Process
Integrating applications and business processes to streamline resources or enhance your business capabilities is an exciting challenge. Using a variety of techniques to define optimal processes also allows you to discover new features needed in existing or to-be-built applications. Use the links below for an overview. For details about a role, activity, or artifact in the diagram, click on its icon.
Click the icons for definition
The purpose of this workflow detail is to:
- Define the scope of the business process modeling effort
- Define business processes based on agreed to priorities
- Explore where software can automate, enable, or enhance business processes and understand at a high level how new systems could relate to existing systems and technical infrastructure
- Review and refine resulting business operations design
- Describe existing business processes
- Design new business processes that incrementally change existing processes
- Radically transform the existing processes
The project's larger purpose directs the business process modeling scope, completeness, and participants. For example, a business re-engineering project means significant changes to business processes and organizational structure. Such a project defines business processes by performing Activity: Find Business Actors and Use Cases and producing the initial Artifact: Business Use Case Model. The Role: Business Process Analyst performs parts of the Activity: Define Business Operations. The Role: Business Designer follows, performing Activity: Detail a Business Use Case for each high priority business use case. After several business use cases are detailed, the team may require Activity: Structure the Business Use Case Model to improve the model based on their increased understanding of the business processes. If business actors or business use cases are missing, then the Activity: Find Business Actors and Use Cases would be performed again to improve the business use case model. As business use case drafts are produced, the Role: Requirements Analyst performs Activity: Explore Software Support. The Role: Business Process Analyst continues Activity: Define Business Operations.
Any project intending significant change should increase time and effort in Activity: Define Business Operations and Activity: Detail a Business Use Case. These projects will likely produce Artifact: Business Use Case and Artifact: Business Use Case Realizations, in addition to the Artifact: Business Use Case Model.
Each Artifact: Business Use Case captures a business process textually or graphically. Each Artifact: Business Use Case Realization demonstrates process implementation by modeling the dynamic interactions between roles and business entities. A business use case realization reveals more detail through a clear box view, compared to the business use case's black box view. Defining business processes is closely related to the oranization's design. The business use case realizations bring together business processes, roles, and the organizational design needed to implement these processes. The Artifact: Business Operations Plan presents a cohesive description of the business processes and suggestions for effectiveness.
In refining business processes, you will discover and seek out opportunities for systems to support or radically change the business processes. Capture this information in the sketch of the Artifact: Use Case Model, Artifact: Supplementary Specifications, and Artifact: Software Architecture Document, as necessary. This allows you to identify existing systems needing modification, new systems to support the business processes and strategy, and define approximate boundaries of new systems. These decisions provide input necessary to begin defining the requirements and the broader user experiences of each new system.
People fulfilling the Role: Business Process Analyst, Role: Business Designer and optionally, the lead Role: Business Strategist, act as a business process modeling team. The business process modeling team works with stakeholders, subject matter experts, customers, end users, and any others needed to perform the activities. These supporting roles may be part of the business modeling team on some projects. Participants should have excellent domain knowledge, understand the current processes, and be prepared to share that knowledge. The Business Process Analysts and Business Designers must understand business use case modeling techniques. Several team members need strong facilitation skills.
The Role: Requirements Analyst works closely with the Business Process Analysts and Business Designers to understand business operations. The Business Strategists must ensure the Requirements Analyst understands the business strategy as it affects system development decisions. The Role: Software Architect may assist the Requirements Analyst in investigating new technologies and potential impacts on existing systems. Ideally, at least one person fulfilling the Requirements Analyst role will participate during the lifetime of the project.