لطفا منتظر باشید ...
A.1 Introduction
More and more companies today are attempting to improve their business by engaging in some form of business process redesign (BPR). BPR focuses on a 'process view'of a business and attempts to identify and describe an organization's business processes; evaluate the processes to identify problem areas; select or design new processes, possibly radically different from those currently in place; predict the effects of proposed process changes; define additional processes that will allow the organization to more readily measure its own effectiveness; and enact, manage, and monitor the new processes. The goal is a leaner, more effective organization that has better insight into how it does business and how its business processes affect the organization's health. Successful BPR projects involve the cooperation of many people over extended time periods, including workplace analysts, systems engineers, and workers at all levels of the organization.Computer applications that support one or more aspects of BPR are becoming increasingly common. Such applications include:
Modeling tools that help a workplace analyst identify and describe an organization's processes
Process editors and planning aids to synthesize new processes or to modify existing processes
Process library browsers that help organizations find new processes that might better meet their needs
Process animators and simulators that help organizations visualize the effects of existing processes or potential new processes
Work flow–management tools that help workers follow business processes
Outcomes analysis tools that help organizations monitor the effectiveness of their processes
No single application supports all aspects of a BPR engagement, nor is it likely that such an application will ever exist. Furthermore applications that do support more than one aspect rarely do them all well. For example, a work flow tool may also provide some process simulation capabilities, but those additional capabilities are unlikely to be on par with the best dedicated simulation applications. This is to be expected—building an application that supports even one of these aspects well requires a great deal of specialized knowledge and experience.
Ideally, then, a BPR team would be able to pick a set of BPR-support applications that best suits their needs: a process modeling tool from one vendor, a simulator from another, a work flow manager from another, and so forth. Unfortunately, these applications currently have no way to interoperate. Each application typically has its own process representation (often undocumented), and many applications do not provide interfaces that would allow them to be easily integrated with other tools.Our goal with the PIF project is to support the exchange of process descriptions among different process representations. The PIF project supports sharing process descriptions through a description format called PIF (Process Interchange Format) that provides a bridge across different process representations. Tools interoperate by translating between their native format and PIF.[1]
Any process description format, including PIF, is unlikely to ever completely suit the needs of all applications that make use of business process descriptions. Therefore, in addition to the PIF format, we have defined a framework around PIF that accommodates extensions to the standard PIF description classes. The framework includes a translation scheme called Partially Shared Views that attempts to maximize information sharing among groups that have extended PIF in different ways.The PIF framework aims to support process translation such that:
Process descriptions can be automatically translated back and forth between PIF and other process representations with as little loss of meaning as possible. If translation cannot be done fully automatically, the human efforts needed to assist the translation should be minimized.
If a translator cannot translate part of a PIF process description to its target format, it should:
Translate as much of the description as possible (e.g., and not simply issue an error message and give up)
Represent any untranslatable parts as such and present them in a way that lets a person understand the problem and complete the translation manually if desired
Preserve any uninterpretable parts so that the translator can add them back to the process description when it is translated back into PIF
These requirements on the translators are very important. We believe that a completely standardized process description format is premature and unrealistic at this point. Therefore, as mentioned earlier, we have provided ways for groups to extend PIF to better meet their individual needs. As a result we expect that PIF translators will often encounter process descriptions written in PIF variants that they can only partially interpret. Translators must adopt conventions that ensure that items they cannot interpret are available for human inspection and are preserved for later use by other tools that are able to interpret them. Section A.6 describes PIF's Partially Shared Views translation scheme, which we believe will greatly increase the degree to which PIF process descriptions can be shared.[1]A process specification in PIF is utilized in the context in which it is passed to a person, tool, or system in such a way that the task to be performed on it is understood (e.g., analyze the specifications for certain features, perform a simulation using the specification, execute a process that meets the specification, avoid executing any process that meets the specification, etc.). This imperative information about the task to be performed with a PIF process specification is not represented in the specification itself, but should be considered as the context within which the specification is used.
