Let us consider a simplified example of an editorial office at a scientific Journal. Assume that you have been recently assigned as the new Editor-in-Chief of this Journal. Obviously, you have to understand how the editorial office functions. Using GRADE, you might proceed in the following way to define how the office functions:

	first, the structure of the editorial office should be modeled either via an ORG diagram or via a CO diagram If the structure of an enterprise is complicated enough or we want to supply more detailed data on the components, such as Competences, Availability etc., then the ORG diagram is preferable for structure modeling. In some cases it is better to start with CO's in the sense that they have associated IT tables (not displayed in this example) where messages circulating between the objects of the CO diagram are specified.The CO diagram will also help focus on defining what is within the editorial office, and who in the office communicates with in the outside world.
	further, the business processes performed by the editorial office must be modeled. We will demonstrate only one of the processes, namely, the Processing of Submitted Papers The business process is represented by a BP diagram.
	Most of the tasks contained in the business process are self-explanatory (such tasks are called elementary tasks). One of the tasks that requires further detailing is the task Reviewing Process. It has been further refined via the following BP diagram : The other task requiring a further refinement is Prepare Paper for Publishing Thus we have built a business model of the existing system, an overview of which is represented by the model tree Diagrams that contain information in the model have small grey circles beside the corresponding boxes. Business Process Reengineering    The detailed business model is sufficient for starting system analysis and Business Process Reengineering for our Journal. When analysing the business process Processing of Submitted Papers we see that in the existing model("as-is" model) the Editor-in-Chief performs several tasks (Receive Submitted Paper, Register Paper and Author) which could be performed by the Manuscript Assistant as well. Now let us consider the task Reviewing Process. We see that some important process information has been omitted, namely: it has not been determined how long a review from a reviewer should be waited for, until a new reviewer is assigned the maximum number of different reviewers for a paper is not specified (in the current model version an unlimited number of reviewers may be involved) the issue of what should be done when an author withdraws a paper has not been dealt with at all If we consider the refinement of the task Prepare Paper for Publishing we see that no check is performed to ensure that the author has taken into account the Notes from reviewers in his Camera Ready Paper. As at matter of fact, the Editor-in-Chief should have checked that the Author has abided by the reviewer requirements before the Manuscript Assistant checks conformance to style requirements. Let us assume that the other aspects of the business process Processing of Submitted Papers are satisfactory. As a result we have a new version of the business process Processing of Submitted Papers : In this version the modified task Reviewing Process happens to require another type of refinement, than the original one. In general, two types of task refinement are available in GRADE : via a subordinated BP diagram via a PD diagram In most cases, this detailing is done via a subordinated BP diagram (as we have seen in the previous example). However, if a task contains a complicated dialogue (as it is in the modified Reviewing Process), refining it via a PD diagram may be preferable: A PD diagram, in contrast to a BP diagram, can describe a task from the viewpoint of one performer only (the Manuscript Assistant, in this case). The task Prepare Paper for Publishing also needs a new refinement We see that in this case a subordinate BP diagram is well suited for detailing and there is no need for a PD. In general, refining via BP is preferable due to better readability. As a result, we have built the new reengineered model (the "to be" model) of our Journal. Next Step    The next step could be the development of precise instructions for each member of the Editorial Staff. Instructions for the Manuscript Assistant which conform to the improved business process could be described by a following PD diagram : The best form for such an instruction is, namely, a PD diagram. If in the future there is the desire to automate the tasks performed by the Manuscript Assistant with a software system, then such instructions could serve as a high-level specifications for this software. The Example 2 demonstrates in a more realistic situation the aspects related to software design.