This is care of PMThink:
Bill Gates reflects on the future and sees business process modeling and process change maturing significantly. ...
... "Really modeling the business where you can actually see schema models that really let you understand what's going on in your business and . . . change those models without having to go back and have some two-year IT project to do it, that's probably in the 10-year time frame. " ...
Via Computerworld: Bill Gates Crystal-Ball
Craig:
Thanks for the info! Bill Gates brings up an important point that is infrequently discussed in BA circles: Functional model (which is the same as a business process model) maintainability.
From what I have seen Data Flow Diagrams are truely unique in that they strongly support maintainability. Some examples:
* DFD's have a built-in mechanism that is a lithmus test of completedness (i.e., integration): The data flows themselves. If the model is going to be maintainable - it has to be highly integrated. It is just too much work trying to maintain disjointed models.
* DFD's employ a parent diagram/child diagram scheme where the max number of documented functions per level (diagram) is typcially about seven. Large "big hunker" diagrams are not at all maintainable - trying, for example, to move 30 functions up, or down on the model to squeeze in some additional functions is just too hard.
* Utilize a logical data dictionary so that, a year or so later, we can go back to the model and easily figure it out the specific meanings of inputs and outputs.
I am curious how other modeling techniques simultaneously support the above mentioned maintainability issues?
Tony
I suggest investigating BPM and BPMN - business process modeling and business process modeling notation. This supports business analysis independent of a solution. The idea is to define the business rules and what the goals/processes of the business are. From that you can create solutions for improving and/or implementing these business rules. The solution could be software, in which case you can begin "business systems analysis" where you define the functional requirements/model of a system that will suppport the business rules. This is really the 'Enterprise Analysis' area of the BABOK but I think it is really useful to do this as part of any project - even if you know the solution will be a computer system. That way you know the solution you develop will actually be supporting the business needs.
I do agree that models, including DFDs, that are current are invaluable in knowing what a system does and in identifying where changes in business rules will impact the implemented functionality.
Ginny
brought to you by enabling practitioners & organizations to achieve their goals using: