So you have a requirements plan. You have elicited functional, non-functional, and quality of service requirements. You have validated and verified them, and your stakeholders are satisfied. Now what? The requirements part of a business analysis project answers the questions: "What do we have, and what do we need?" This business process analysis white paper answers those two fundamental questions.
So you have a requirements plan. You have elicited functional, non-functional, and quality of service requirements. You have validated and verified them, and your stakeholders are satisfied. Now what?
I like to think of the requirements part of a business analysis project as the analysis function; that is, to answer the questions "What do we have and what do we need?" The next step is to evaluate and answer the question "Is it any good, and what improvements can be made to the process?"
The overall process may look something like this.
NEED --> REQUIREMENTS --> AS IS --> ANALYSIS --> EVALUATION --> TO BE --> COMMUNICATE --> IMPLEMENT
Business process improvement is based on a model-oriented approach that requires a robust set of tools for a consistent and thorough application.
Commercial modeling and analysis tools are usually designed to be as general-purpose as possible to gain the widest possible base of users. The tools typically focus on specific modeling techniques; but in some cases, the tools may not enforce the modeling syntax and procedures. Enforcement of the appropriated modeling syntax and procedures of these techniques must be a basic requirement for consideration of individual tools.
Note that the same technique can play various roles within the entire improvement program. A repository capability is generally required to integrate the myriad techniques and tools within the context of an overall methodological approach. An example would be a standard requirements document and a list of organization- accepted models.
Tool support for AS-IS modeling needs to facilitate data gathering and synthesis of the model. Once built, the model must be analyzable to identify improvement opportunities. As a minimum, tool support for TO-BE modeling must allow easy modification and reorganization of the AS-IS model to generate the TO-BE model. Ultimately, TO-BE modeling support should allow modeling teams to easily incorporate "best practice" templates. Deriving the TO-BE process model from the AS-IS is a difficult task that must be supported by other techniques.
Business rules define the fundamental structure for business management and are relatively stable when compared to processes. Many different business processes can use the same set of business rules. A change in business rules, however, can facilitate a significant modification of the associated business process. Current business rules, reflected by an AS-IS model, can help define and clarify the basic nature of a business process independent of the current organization and resources. New business rules, depicted by a TO-BE model, define fundamental changes that can lead to significant streamlining of a business process. At a minimum, a modeling tool must support rigorous definition of business rules and facilitate easy modification.
Within an emerging, business process improvement effort, support tools should satisfy the following requirements.
Model Management. Versioning, keeping straight the different versions, and configuration control of models are required to keep track of various iterations of AS-IS and TO-BE models and the interrelationship between the functional focus of various teams.
Model Authoring. Both graphical and natural language facilities are required for the rapid and effective creation of models. Unlike mere drawing tools, modeling semantics and rules must be enforced by the supporting software.
Model Analysis and Validation. An advanced set of functions are needed to validate models for logical consistency and completeness. Once validated, these models must support the analysis to help discover opportunities to improve the overall effectiveness of the business processes.
Model Integration and Mapping. A total enterprise-wide, broad, multiple-organization process model cannot and should not be created as the result of a single project. Instead, specific views should be created and validated and then integrated on an evolutionary basis to create a comprehensive, enterprise-wide definition.
Model Presentation. A comprehensive set of graphing and textual reporting tools are required to facilitate effective presentation of modeling results at both technical and managerial levels. These reporting capabilities should include the ability to generate English-like statements of complex business rules.
Model Transformation. Modeling results need to be fed directly to a variety of tools and other implementation environments through the use of model transformation functions and custom interfaces. Possible transformation capabilities might include the ability to automatically generate relational database structures to support heuristic prototyping of conceptual business rules.
No single modeling tool is currently capable of performing all the types of modeling and analysis needed for business analysis, and new types of analyses will continue to evolve as the business analysis discipline matures. Therefore, an open-tool architecture that allows multiple tools to share model definitions through common languages is required.
No comments:
Post a Comment