it402 /business process management

information technology question and need an explanation and answer to help me learn.

please use your keyboard (Don’t use handwriting) Thank you
I need new unique answers ,please (use your own words , don’t copy and paste) the citation is important
I want ANSWER with APA reference
Requirements: good | .doc file
Question One
Explain the System requirements categories in a brief manner. Explain each category with the help of example/s.
Question Two:
Quality attributes can be described in a variety of ways. Discuss in detail any two groups supported with examples.
Question Three
How many types of Enterprise modeling representations. Explain each of them in detail.

Question Four:
Explain the life cycle for Business process and Elaborate steps involved in Businsess process.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 1 Week 6 Process Architecture 2.2.2 The Control-flow View • An Activity element is the base class for other elements such as Sequence, Flow, and Switch. • Sequence: An activity is only enabled after the completion of another activity in the same sequence structure. • Flow: All activities of a flow structure are executed in parallel. • Switch: Only one of many alternative paths of control inside a switch structure is enabled according to a condition value. • A SimpleActivity element represents a concrete action such as a service invocation, a data processing task, and so on. • The StructuredActivity element is an abstract representation of a group of related activities. 2.2.3 The Collaboration View • The collaboration view extends the relationship between Process and Service elements in the core view. • The Service element from the core view is extended by a specific Service element that exposes a number of Interfaces. • An Operation represents an action that might need some inputs and produces some outputs via correspondent Channels. • A Channel only holds a reference to a Message entity. • The ability and the responsibility of an interaction partner are modeled by the Role element. • These concepts are captured by using the PartnerLink and the PartnerLinkType elements, as are their relationships with the Role element. • An interaction between the process and one of its partners is represented by the Interaction element that associates with a particular PartnerLink. 2.2 The Control-flow (a) vs. Collaboration View (b)
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 2 2.2.4 The Information View • Involves the representation of data object flows inside the process and message objects traveling back and forth between the process and the external world. • Consists of a number of BusinessObjects elements. • Data flowing inside the process might go through some transformations that convert existing data to form new pieces of data. • The transformations are performed inside a DataHandling object. • The source or the target of a certain transformation is an ObjectReference entity that holds a reference to a particular BusinessObject 2.2.5 The Human View • The Human view defines human roles and their relationships to the respective process and tasks. • It Process elements that require human interactions are called as Tasks. • It establishes a role-based abstraction. • This role-based abstraction can be used for role-based access control. • Role-based access control is administered through roles and role hierarchies that mirror an enterprise’s job positions and organizational structure. • Users are assigned membership into roles consistent with their duties, competency, and responsibility. 2.2 The Information (a) vs. Human (b) View
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 3 3. Reference Process Architecture: Workflow Systems • Workflows are useful for the coordination of interrelated activities carriedout by organization members in order to execute a business process. • A WfMS defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines. • Workflow is defined, according to the WfMC, as the automation of a business process, in which documents, information, or tasks move from one participant to another in order to perform some actions in accordance with a set of procedure rules. • A distributed workflow is executed across an extended enterprise, in which different individuals participate in order to reach global objectives. • Collaborative process planning can be considered as a business process that can be managed using distributed workflows. 3.1 Basic Workflow Components / Basic Components of Workflow • Activity: A description of a piece of work that forms one logical step within a process. • Participant: A resource that performs the work represented by a workflow activity instance. • Role: A mechanism that associates participants to a collection of workflow activities. • Routing: A route defines the sequence of the steps that information must follow within a workflow. • Transition rule: A transition rule is a logic expression that determines what actions need to be carried out, depending on the value of logic operators. • Event: An occurrence of a particular condition that causes the workflow management software to take one or more actions. • Deadline: A time-based scheduling constraint, which requires that a certain activity work be completed by a certain time. 3.2 Types of Workflow 1. Administrative workflow: used to perform workflow processes with defined procedures, though not as structured as in the case of Production workflow, as each instance of the workflow can have a different amount of work associated with it. 2. Production workflow: consists of highly automated workflow processes—the goal of a Production workflow is to automate the process as much as possible. 3. Ad hoc workflow: implemented by a user to perform a string of actions that arise for a business scenario. 4. Collaborative workflow: involves a team of people working together. 3.4 Workflow Perspectives 1. Data or Informational Perspective: • Consists of data flow between workflow activities. • Each activity is assigned a set of input and a set of output parameters. • The transfer of data between workflow activities is known as data flow. • The modeling of data is required to permit workflow management systems to control the transfer of workflow relevant data as generated by workflow activities during workflow executions. • By providing graphic language constructs to represent data flow between activities, the informational perspective can be visualized and used to validate and optimize application processes.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 4 2. Context of Organizational Perspective: • WfMS requires information on the context that is organizational as well as on the technical environment in which the workflows will be executed. • Atomic workflows can be either automatic or manual. • Manual atomic workflows are executed by persons who may use application programs to do so. • automatic atomic workflows are executed by software systems without human involvement. • The role concept is defined dependent on the structure of an organization in which the workflow is executed. • When an activity is about to start, the system uses predefined role information to select people to perform the requested activity. 3. Interaction or Operational Perspective: 1. When persons are selected by role resolution to perform workflow activities. 2. When a person chooses to perform an activity, then the defined application program is started and the input data as specified in the workflow model are transferred to that application program. 3. When the person completes that activity, the output data generated by that activity are collected in the output parameters of the activity to be transferred by the WfMS to the next workflow activity, as specified in the respective workflow model 4. Processing or Functional and Behavioral Perspective: • The processing perspective covers the functional decomposition of activities as present in application processes. • It specifies which activities have to be executed within a workflow. • Workflows have a tree structure, where root node represents the toplevel workflow, inner nodes represent other complex workflows, and leaf nodes represent bottom-level atomic activities. • The controlled execution of a complex workflow by a WfMS has to take into account interrelationships of the subworkflows covered in the subordinate behavioral perspective. 4. Workflow Reference Model • The WRM divides the workflow system into five components: 1. Process definition tool 2. Workflow engine 3. Workflow client application 4. Invoked application 5. Administration and monitoring tool • The WRM provides the following guidelines: • Common terminology for the workflow product category • WRM is the functional components necessary in a WfMS. • Interfaces that connect the various functional components
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 5 4. WRM Components and Interfaces 4.1 Workflow Process Definition Tool • The process definition tool is a design tool that allows the workflow designer to design and model the workflow process. • It provides a graphical interface for the process designer to graphically design the business process. • The result of the design activity is a workflow process model. • Once the workflow process model has been designed, the process definition tool creates an output of the model using a process definition language. • The workflow process that is included in the calling workflow process is called a subprocess and can be nested further. • An activity is work performed by a specific resource. • The participants in a workflow process could be an explicitly named human user, a role defined in an organizational structure, a position that is part of the organizational unit, or an information system. • There are four generic flow control mechanisms: sequential, parallel, iteration, and nesting. • Transition defines the criteria for moving to the next activity and it is usually represented as a line from one activity to the next in the graphical workflow process model. • Transition can be of two types: conditional and unconditional. 4.2 Workflow Client Application • Workflow client application is an application that requests services from the workflow engine including the retrieval of a worklist generated by the workflow engine for participants to execute. • The workflow engine generates the work items assigned to specific users, which are retrieved by the workplace portal and then displayed to each user for action. • The workflow client application would need to instantiate a workflow process instance, execute a work item, and update the worklist in the workflow engine as to the status of a particular work item.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 6 4.3 Workflow Engine • The workflow engine is the runtime environment of the WfMS. • It creates process instances of the workflow process based on a trigger event for the creation of a workflow process instance. • An event is a predefined circumstance the workflow engine is listening for. • The trigger could be some status change of an application transaction. • When a workflow process instance is created, the workflow engine manages workflow relevant data throughout the life cycle of the workflow process instance. 4.4 Invoked Application • The workflow engine to perform work calls the invoked application. • The invoked application is the backend application that creates business transactions. • It is a system participant that usually performs a transaction as a result of the workflow process. • An example is the purchasing requisition process; an online request form completed by a human participant might trigger the process. • Once the workflow engine has received the purchase request form, the next activity in the workflow process is to create a purchase requisition in the backend ERP system. 4.5 Administration and Monitoring Tool • Allows system administrators to manage the WfMS users, roles, and resources. • Provides functions such as audit reporting, querying of process status, and updating active process instances. • Workflow engines store events and record updates to process instances in workflow logs. • The administration and monitoring tool retrieves workflow logs for process instances that have completed and instances that are still in progress. • These statistics provide data for process analysis, which lead to process improvements. 4.6 Workflow Reference Model Interfaces 1. Interface 1 links the workflow process definition tool to the workflow engine. 2. Interface 2 links the workflow client application to the workflow engine. 3. Interface 3 connects the workflow engine to the business applications invoked during the processing of the workflow model. 4. Interface 4 enables integration between heterogeneous workflow engines by providing a set of APIs that one WfMS can invoke on another. 5. Interface 5 enables integration between workflow engines with the administration and monitoring tool.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 7 Week 6 – Enterprise and Process Modeling Contents 1. Model and Types of Models 2. Modeling and Modeling Ontology 3. Requirements of Modeling 4. Enterprise Modeling 5. Process Modeling 6. Process Description for Storing Business Process Models Introduction: Enterprise Modeling • Implementing process-oriented architectures has proven to be difficult for many companies. • Implementing process concepts within organizations is only one step toward achieving an enterprise-wide focus on processes. • Process management deals with the efficient and effective execution of business processes. • It consists of the planning, implementation, enactment, and controlling of processes and forms a life cycle that leads to continuous process improvement. • There is a gap between approaches for modeling business processes and those for modeling information systems. • There is a strong need for a methodology for creating a supporting information system that is based on the process architecture of an organization. 1. Model • A model is a form of representing something: it is not a replication but rather an intentional selective construction of a new thing or system that has the purpose of representing another thing or system. • No model is unique or exclusive, as there can be a multitude of them; furthermore, models are generally not correct or incorrect—it is only what it is with reference to the defining purpose of the respective model. 1.Characteristics of a model
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 8 1.1 Types of Models 1. Descriptive: A descriptive model is used to describe or mimic a realworld phenomenon or system. With a descriptive model, one can reason about the properties or the behavior of the system. 2. Prescriptive: A prescriptive model is used to define how a yet-to-bebuilt system is supposed to be. Prescriptive models are adopted as part of so-called forward engineering. 3. Structural: A structural model is focused on the static aspects of a system. These models are used for describing the components or modules that are part of the system, so they serve for conceptualizing the system architecture. 4. Behavioral: A behavioral model emphasizes the dynamic, functional, and temporal aspects of the system. 5. Symbolic: These models are much more easily changed in comparison with physical models. By manipulating and changing the mathematical relationships, one can see how the model reacts and consequently how the system would react. The creation of a symbolic model requires: • A set of signs (or symbols) • A set of rules to operate on those signs 6. Physical: Typically, a physical model is a smaller representation of the original object but, sometimes, it can be larger if the original object is too small for humans. 2. Modelling • Modeling is the process of identifying adequate concepts and selecting adequate abstractions to construct a model that reflects a given universe of discourse appropriately. • Modeling permits the cost-effective use of the model in place of the real-world object or process for some purpose, such as simulation, construction effort estimation, and so on. 2.1 Modelling Ontology • An ontology is an explicit representation of a shared understanding of the important concepts in some domain of interest. • Ontologies are represented by conceptual maps that constitute a simple and well-known form of organizational knowledge.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 9 • This ontology considers two different separate perspectives: • Reverse engineering employs descriptive models to model an existing system. Reverse engineering is a process of analysis in which the system is seen by means of a model. • Forward engineering employs prescriptive models for modeling the envisaged system. Forward engineering is a process of synthesis wherein the system is developed starting from a model. 3. Requirements of Modelling 3.1 Domain Models • A domain model constitutes a description of the common properties and variables of the domain related to the system that is being developed. • This model represents the things (entities or events) that exist in that domain; that is, it is a conceptual reference of the problem domain. • The domain model expresses enduring truths about the universe that is relevant to the system at hand, including: • A definition of the scope of that domain, providing examples of systems or generic rules of inclusion • A vocabulary of the domain (i.e., the glossary with the principal terms) • A model of concepts that identifies and relates the concepts of that domain 3.2 Use Case Models • A use case model defines the boundaries of the system within the environment and specifies the functionalities provided by the system. • A use case model is related to one or more requirements: the most complex use cases are associated with many requirements, whilst the simplest ones are related to fewer numbers of requirements. • Use case models are represented by use case diagrams consisting of: • Use cases (represented by ellipses) • Actors (represented by stylized human figures) 3.3 Class Models • Class models are an essential part of the object-oriented paradigm; class models are necessary to indicate the existing classes and their relations. • Each class is divided into three parts: • The top part is used to indicate the class name • The central part indicates the class attributes • The bottom part lists the class operations • The name is mandatory, but the other parts can be omitted. • UML basically considers four types of relations between objects that can be shown between the classes in the respective diagrams. 3.4 Interaction Models • An interaction model is used for representing an instance of a use case. • Interaction models describe how a group of objects communicate. • one of interaction models to be represented here is a sequence diagram. • Sequence models are used to describe the behavior of the system.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 10 • The principal elements of sequence diagrams are: • As indicated by the temporal axis, the diagram is read from top to bottom • Textual annotations are located on the left side of the diagram to identify initial conditions, actions, and activities. • Event identifiers: Near a message • For real-time systems that are conscious of time restrictions, timing marks can be used, with the available options • State marks: These can be added to the sequence diagrams 3.5 State Models • State diagrams can be used for defining the (dynamic, temporal) behavior of a class (i.e., its instances). • state differs from other states in the following: • The events it accepts • The transitions it takes as a result of the accepted events • The actions it performs • A transition is a response to an event that causes a state change. • State machines are used when a transition between states occurs, mainly as an answer to significant events. • State machines extend the most conventional diagrams along three axes related to hierarchy, concurrency, and communication. 3.6 Activity Models • Activity models are useful to relate the control flow among the activities of a given business process. • These models address behavioral aspects of the systems or entities under consideration. • These models are appropriate when the behavior change occurs, mainly due to the end of the action/activity executed and not to the occurrence of events, as is the case with state models. 4. Enterprise Modelling • Enterprise modeling is the process of creating an integrated enterprise model that captures the aspects of the enterprise required for the modeling purpose at hand. • Enterprise modeling can be represented by: • Textual representation • Spreadsheet representation • Graphic representation without the use of a specific notation • Graphic representation with the use of a specific notation 4.1 Enterprise Model Components • A visual model consists of symbols in the form of geometric shapes such as rectangles and ellipses and the lines connecting them (e.g., arrows). • The symbols are referred to as model components and the connections as relationships. • Many modeling languages support views and levels to enable reduction of the complexity of the representation. 4.2 Enterprise Knowledge Development • An enterprise model consists of a number of related “submodels,” each describing the enterprise from a particular perspective.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 11 • Enterprise knowledge development is an example of a typical enterprise modeling that includes an overall model composed of inter-related submodels for integrating different views of the organization. • Enterprise knowledge development is composed of six integrated submodels focusing on a different aspect of the enterprise. 5. Process Modelling • A business process model is the result of mapping a business process. • This business process can be either a real-world business process as perceived by a modeler or a conceptualized business process. • Business process modeling is the human activity of creating a business process model. • Business process modeling involves an abstraction from the realworld business process because it serves a certain modeling purpose. • A business process modeling language can be specified using a metamodel. 5.1 Process Modelling Languages Event-Driven Process Chains (EPC) • EPC was developed by August-Wilhelm Scheer as part of the Architecture of Integrated Information Systems framework. • An EPC model describes a business process in terms of a series of functionbased transformations between a set of input events and a set of output events. • An EPC model takes the form of a directed graph, which always starts and ends with events. • For the definition of complex routing rules, there are three kinds of connector types: AND (symbol ∧), OR (symbol ∨), and XOR (symbol ×) 5.2 Business Process Modelling Notation • BPMN is an Extensible Markup Language-based language for defining business processes with a formal metamodel and an associated graphical notation.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 12 BPMN version 2.0.2 is designed to be utilized as: • High-level, graphical business modeling language (with a limited range of modelling constructs). • Detailed graphical modeling language (with a comprehensive range of modelling constructs). • Executable business process language, capturing sufficient details about the control-flow, data, and resource aspects of a business process so that it can be directly executed by a business process engine 6. Process Description for Storing Business Process Models • Modeling of processes is a complex and time-consuming task that can be simplified by the reuse of process models. • A repository is, therefore, necessary to store and manage process models. • In the Universal Process Repository, process definitions exist at two levels: the user level and the repository level. • At this level, a business process is modeled by using graphical constructs of a process modeling language such as BPMN or EPC. • There are several process modeling languages (e.g., EPC and BPMN) that can be used for modeling business processes. • In order to provide support for different modeling languages in the Universal Process Repository, a common format for storing and sharing process models is needed, wherein the common format only stores fundamental elements of process models. The concrete elements are obtained by employing the following four perspectives: • Functional perspective • Behavioral perspective • Organizational perspective • Informational perspective Summary • A model represents in a simplified way the reality for a given purpose, emphasizing some elements and ignoring others. • Models can be characterized according to three dimensions: representativeness (e.g., prescriptive, descriptive); perspective (e.g., behavioral, structural); and form (e.g., symbolic, physical). • An ontology that introduces relevant concepts related to modeling and permits one to distinguish and associate concepts like model, specification, description, diagram, language, and notation. • Several frequently-used business process modeling languages including EPCs and BPMN.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 1 Week 8 – Business Process Management Systems Contents 1. Process-Oriented Enterprise 2. History of Business Process Management 3. Business Process Life Cycle 4. Concept of Business Process Management 5. Business Process Management 6. Management by Collaboration 7. Business Process Maturity Model, 8. Business Process Management Systems 9. Enterprise Process Management Systems Introduction: Business Process Management Systems • Information technology can fulfill its role as a strategic differentiator only if it can provide enterprises with a mechanism to enable sustainable competitive advantage for the ability to change business processes in sync with changes in the business environment and at optimum costs. • The services support a layer of agile and flexible business processes that can be easily changed to provide new products and services to keep ahead of the competition. 1. Process-Oriented Enterprise Enterprise systems (ES) enable an organization to truly function as an integrated enterprise, with integration occurring across all functions or segments of the traditional value chain, for example • Sales • Production • Inventory • Purchasing • finance and accounting • Personnel and administration. • Collaborations or relationships manifest themselves through the various organizational and interorganizational processes. • A process may be generally defined as the set of resources and activities necessary and sufficient to convert some form of input into some form of output. • Processes are internal, external, or a combination of both. They have cross functional boundaries, starting and ending points, and they exist at all levels within the enterprise. Value-Added Driven Enterprise • Business processes can be seen as the very basis of the value addition within an enterprise that was traditionally attributed to various functions or divisions in an enterprise.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 2 • The understanding of value-adding and non-value-adding processes is a significant factor in the analysis, design, benchmarking, and optimization of business processes leading to business process management (BPM) in the companies. • BPM provides an environment for analyzing and optimizing business processes. Values are characterized by value determinants, for example: • Time (cycle time and so on) • Flexibility (options, customization, composition, and so on) • Responsiveness (lead time, number of hand-offs, and so on) • Quality (rework, rejects, yield, and so on) • Price (discounts, rebates, coupons, incentives, and so on) The effect of cost is truly a result of a host of value determinants such as time, flexibility, and responsiveness. • The nature and extent of a value addition to a product or service is the best measure of that addition’s contribution to the company’s overall goal for competitiveness. Such value expectations are dependent on the following: • The customer’s experience of similar product(s) and/or service(s) • The value delivered by the competitors • The capabilities and limitations of locking into the base technological platform 2. History of Business Process Management • First-Wave Business Process Management—Process Improvement (1970s–1980s) • Second-Wave Business Process Management—Process Redesign and Reengineering (1990s) • Third-Wave Business Process Management—Processes in Constant Change (2000s) • Fourth-Wave Business Process Management—Process-Based Competitive Advantage (2010s) • Fifth-Wave Business Process Management—Process-Driven Strategy (2020s) 3. Business Process Life Cycle
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 3 Design: This phase typically involves capturing the operational details of the process using some form of modeling notation. Ideally, sufficient details of the process are recorded to facilitate its direct enactment; however, this relies on the use of an executable modeling formalism, such as that provided by a workflow offering. • Generally, the design is captured using notations such as BPMN, event-driven process chains, or Unified Modeling Language activity diagrams, and it takes the form of a conceptual process model. • The business process life cycle commences with the Design phase, in which surveys on the business processes and their organizational and technical environments are conducted. • Business process modeling techniques as well as validation, simulation, and verification techniques are used during this phase. • Business processes involving multiple participants play an increasing role to foster the collaboration between enterprises. Configuration: Once the business process model is designed and verified, the business process needs to be implemented. • For this, the system needs to be configured according to the organizational environment of the enterprise and the business processes whose enactment it should control. • This configuration includes the interactions of the employees with the system as well as the integration of the existing software systems with the BPMS. • The business process can be implemented via: • A set of policies and procedures that the employees of the enterprise need to comply with. In this case, a business process can be realized without any support by a dedicated BPMS. • A dedicated software system. The business process model is enhanced with technical information that facilitates the enactment of the process by the BPMS. • The standard architecture for a BPMS consists of two main parts: • A BPMS engine, which handles the execution of a business process on a centralized basis and manages the current process state, working data, work distribution, and so on for each process instance that is initiated. • A worklist handler for each user who is involved in a process, which advises them of the work that needs to be undertaken and provides them with the opportunity to interact with the BPMS engine for advisement of their work preferences and management of the scheduling and completion of work to which they have committed. • Enactment: Once the system configuration phase is completed, business process instances are ready to be enacted. Business process instances are initiated to fulfill the business goals of a company and typically follow a defined event—for instance, the receipt of an order sent by a customer. • Monitoring and evaluation: This phase uses the information available to monitor, evaluate, and improve business process models and their implementation. Execution logs are evaluated using business activity monitoring and process mining techniques.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 4 4. Concept of Business Process Management BPM addresses the following two important issues for an enterprise: • The strategic long-term positioning of the business with respect to both current and envisaged customers, which will ensure that the enterprise will be competitively and financially successful both locally and globally. • The enterprise’s capability/capacity, which is the totality of all of the internal processes that dynamically realize this positioning of the business. Traditionally, positioning has been considered as an independent set of functional tasks split within the marketing, finance, and strategic planning functions. The traditional management structures condition managers to put functional needs above those of the multifunctional processes to which their functions contribute. This results in the following: • Various departments competing for resources • Collective failure in meeting or exceeding customers’ expectations • An inability to coordinate and collaborate on multifunctional, customercentric processes that would truly provide competitive differentiation in future markets The traditional mass-marketing type of organization works well for researching market opportunities, planning the offering(s), and scheduling all of the steps required to produce and distribute the offering(s) to the marketplace. Positioning leads to higher levels of revenue through increasing the size of the market, retaining first-time customers, increasing the size of the wallet share, and so on. Positioning has to do with factors such as: • Comprehending customer needs • Understanding competitor initiatives • Determining the business’ financial needs • Conforming with legal and regulatory requirements • Heeding environmental constraints The capability/capacity has to be aligned with the positioning or else it has to be changed to deliver the positioning. Capability/capacity has to do with internal factors, including: • Key business processes • Procedures and systems • Competencies, skills, training, and education A business process is typically a coordinated and logically sequenced set of work activities and associated resources that produce something of value to a customer
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 5 5. Business Process Management BPM refers to activities performed by enterprises to: • design (capture processes and document their design in terms of process maps) • model (define business processes in a computer language) • execute (develop software that enables the process) • monitor (track individual processes for performance measurement) • optimize (retrieve process performance for improvement) BPM approaches based on IT enable support or automate business processes, in whole or in part, by providing computer-based systems support. Scenarios suitable for considering the application of BPM within various areas include the following: • Management • Customers/suppliers/partners • Product and services • Organization Business processes may become candidates for BPM because of thefollowing: • Lack of process standardization • Lack of clear process goals or objectives 6. Management by Collaboration (MBC) • Companies have learned to effectively reengineer themselves into flatter organizations, with closer integration across the traditional functional boundaries of the enterprise. • The dominant theme of this new system of management with significant implications on organizational development is collaboration. • ES, especially BPM systems, are major instruments for realizing MBCdriven enterprises. • MBC is an approach to management primarily focused on relationships. Relationships by their very nature are not static and are constantly in evolution. • MBC provides a framework for dealing effectively with the issues of performance improvement, capability development, and adaptation to the changing environment. • The beauty and essence of MBC are that it incorporates in its very fabric the basic urge of humans for a purpose in life; for mutually beneficial relationships; for mutual commitment; and for being helpful to other beings—that is, for collaborating. • Because of the enhanced role played by the individual members of an enterprise in any relationship or process, MBC promotes not only their motivation and competence but also develops the competitiveness and capability of the enterprises as a whole. • People in teams, representing different functional units, are motivated to work within the constraints of time and resources to achieve a defined goal. • Increasingly, companies are populated with worker-teams that have special skills, operate semiautonomously, and are answerable directly to peers and to the end customers. • Consequently, in the past few years, a new type of nonhierarchical network organization with distributed intelligence and decentralized decisionmaking powers has been evolving.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 6 7. Business Process Maturity Model • In modern enterprises, the implementation of process management involves the description, regulation, updating, and improvement of business process systems and the organizational structure in order to ensure the stability and reproducibility of the results. • Assessments depict how the organization compares itself to its competitors or other organizations; such also helps to manage an organization and evolve it towards higher competence. Almost all maturity models define five levels of increasing maturity, as follows: • Level 1: Initial Organizations (Undisciplined, Individualistic, Inconsistent, Inefficient, and Stagnant) • Level 2: Managed Organizations (Committed, Proactive, Managed, Repeatable, Responsible) • Level 3: Standardized Organizations (Organizational, Established, Adaptable, Leveraged, and Professional) • Level 4: Predictable Organizations (Quantitative, Stable, Empowered, Multifunctional, and Predictable) • Level 5: Optimizing Organizations (Proactive, Systematic, Continual, Aligned, and Preventive) 8. Business Process Management Systems • BPMS technology allows the business analyst to collaborate more closely with IT people in implementing projects. • The various tools BPMS offer provide a new paradigm for how solutions can be implemented. • Organizations are no longer tied to the business processes ingrained in their business applications.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 7 • One of the major advantages of BPMS over traditional IT-enabled business process improvement efforts is that BPMS brings IT closer to the business process owners. • BPMS is able to bridge the gap by allowing business process owners to be directly involved in designing the IT solution. • BPMS typically include a graphical process designer tool that enables the design of processes by process owners and business analysts. • To help the business process owners and business analysts in the process design, BPMS include process simulation and modeling functionality. • BMPS enable the application of predictive and prescriptive analytics. Simulation plays a large role as the supervisory systems that oversee the business processes once they have been implemented. • BPMS give organizations the ability to implement real-time process improvement without the extensive process conversion effort. BPMS Products Example: • Cordys BPMS: Cordys BPMS was developed by Cordys, which was a Dutch vendor who specialized in BPM. Cordys BPMS was taken over by OpenText (Waterloo, Canada) and is now called OpenText Process suite. • Oracle BPM Suite: Oracle BPM Suite is developed by Oracle (Redwood City, CA, USA), who was originally a databases developer. Oracle entered the BPM market after the acquisition of BEA. • IBM WebSphere BPM Suite: The IBM WebSphere BPM suite is developed by IBM Corporation (Armonk, NY, USA), which is originally a computer manufacturer with a long tradition in the servers market.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 8 9. Enterprise Process Management Systems • EPMS promote a world-view of process-driven or process-centric systems supported by a portfolio of systems like process bases, process warehouses, process intelligence, and process analytics. • Thus, instead of the functional-oriented modules of the traditional IT systems, the enterprise systems should be replaced with information system process bases (PBMS) that manage business processes by enabling. Summary • The chapter started with recapitulating the concept of processoriented enterprise and introduced a snapshot of the history of BPM. • It then discussed the business process life cycle constituting of design, configuration, enactment and monitoring, and evaluation. • Distinguishing between BPM as a business program and BPMS as its subset realization into a software application, the chapter introduces the concept of BPM and its characteristics. • BPMS enable the reconciled i.e., collaborative working of different cross-company stakeholders of any business process, activity, or decision in compliance with its strategy, policy, and procedures. After introducing the concept of BPM, the chapter described the BPM methodology in detail. • The chapter looked at MBC as a unifying framework in the context of the customer-centric and customer-responsive enterprise. After presenting the Process Maturity Model, it then explains the concept of BPMS and their variation, EPMS.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 1 Week 9 Business Process Modeling and Notation – part 1 Contents 1. Business Process Modeling and Notation Core Elements 2. Exception Handling 3. Transactions Introduction: Business Process Modeling and Notation • Business Process Modeling and Notation (BPMN version 1.0) was proposed in May 2004 and adopted by the Object Management Group (Needham, MA) for ratification in February 2006. • The current version is BPMN 2.0. BPMN is based on the revision of other notations and methodologies, especially Unified Modeling Language (UML) Activity Diagram, UML EDOC Business Process, IDEF, ebXML BPSS, Activity-Decision Flow Diagram, RosettaNet, LOVeM, and Eventdriven Process Chains. The primary goal of BPMN was to provide a notation • that is readily understandable by all business users, • from the business analysts who create the initial draft of the processes to the technical developers responsible for implementing the technology that will support the execution and performance of those processes and, • finally, to the business people who will manage and monitor those processes. BPMN standardizes the notation used by business experts on the one hand and information technology specialists on the other, thus finally bridging the gap between them. 1. Business Process Modeling and Notation Core Elements • Process diagrams, also called business process diagrams, are at the core of BPMN modeling. BPMN has five core element categories for implementing the properties of business process diagrams; these are: 1. Flow objects 2. Data, or information 3. Connecting objects 4. Swim lanes 5. Artifacts 1. Flow objects, which are the main graphical elements of BPMN and define the behavior of a process. There are three separate types of flow objects: • Event (displayed as a circle) • Activity (displayed as a rectangle with rounded corners), which can be further subdivided into tasks and subprocesses • Gateway (displayed as a diamond)
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 2 2. Data, or information that is either processed within a process or exchanged between different processes. This comprises the following five BPMN elements: • Data object • Data input • Data output • Data store • Message 3. Connecting objects, which allow an individual to connect flow objects to one another or to connect to supplementary information. There are three different types of connecting objects: • Sequence flow • Message flow • Association
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 3 4. Swim lanes, which are used to group the primary modeling elements mentioned earlier. There are two types of grouping in BPMN: • Pools • (Swim) lanes 5. Artifacts, which are used to provide additional information about the process. There are two types of artifacts: • Group • Text annotation Table 11.2: (b) Swim-Lane Object Types Table 11.2: (c) Artefact Types 1.1 Events • The most common types of events are start and end events, which are used in top-level processes. • Start events: There are several start event types dependent on how such events can be triggered. The start event with a message trigger is probably the most common way of marking the beginning of a BPMN process.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 4 The various types of triggers are: • A message trigger • A timer trigger • A condition trigger • A signal trigger is similar to a message trigger • Multiple and parallel multiple triggers • End events: End events represent the different results that a process may produce. Typically, the type of end event is the logical counterpart of the corresponding type of start event The various types of results are: • Message result • Signal result • Multiple results 1.2 Activities A process is comprised of several subprocesses and activities. BPMN 2.0 defines several kinds of activities: • Service task • Send task • Receive task • Instantiating receive task • Manual task • User task • Script task • Business rule task 1.3 Subprocesses Another interesting possibility is to define an activity as a subprocess. This means that an activity becomes a placeholder for some process logic that one may want to insert at that point in the process. Subprocesses are of two forms: • If collapsed, the subprocess looks like a regular activity except for the plus sign (i.e., “C”) indicating that it contains additional process logic. • If expanded, the subprocess shows the logic that is contained inside it. Such logic must follow the same design principles as a top-level process, so, usually, it contains a start event, a sequence of activities, and an end event. It is only when the subprocess reaches its end event that the parent process can proceed to the next activity. 1.4 Gateways Gateways are used to represent decisions. Gateways are of several types; however, regardless of the type of gateway that is being used, each gateway that splits the flow in multiple paths is matched by another gateway of the same type that merges those paths back into the main flow.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 5 BPMN 2.0 defines several kinds of gateways: • exclusive gateway • parallel gateway • inclusive gateway • complex gateway 1.5 Looping A process represents a sequence of activities where each activity is executed before moving on to the next one. • In particular, each activity is executed at most once. However, in practice, there may be scenarios where a single activity has to be run multiple times. • BPMN enables a user to specify if an activity is to be executed multiple times. • In some cases, the activity will be executed a number of times until a certain condition is true. • The loop activity, on the other hand, is a means to keep an activity running until some condition is true. Table 11.3: Looping 1.6 Intermediate Events Intermediate events are events that occur somewhere along the flow of the process. • In BPMN, an intermediate event that waits for some input is said to be “catching,” while an intermediate event that produces some output is said to be “throwing.” BPMN 2.0 defines several kinds of intermediate events, as follows: • A timer event is an intermediate event that waits until a certain deadline has been reached or until a certain amount of time has passed. • A condition event waits until a certain condition is true. • A signal event waits for a certain signal. • A multiple event can wait for multiple things to happen (e.g., a message and acondition, a message a timer, etc.).
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 6 1.7 Event-Based Gateway The event-based gateway is similar to an intermediate event with multiple triggers. • The event that occurs first will determine the branch to be followed, and the remaining branches will be skipped. • BPMN 2.0 enables either exclusive or parallel versions of an eventbased gateway being the first element in a process (or subprocess). The first event to occur instantiates the process, determines the branch to be executed, and ensures all other branches are skipped. In the latter case, the first event to occur instantiates the process, but the remaining branches will be kept alive and listening for their respective events; in this case, the process will be complete when all branches have been executed. Naturally, only the first event instantiates the process—the remaining events will just trigger additional branches within the same process instance. • BPMN 2.0 Poster: http://www.bpmb.de/images/BPMN2_0_Poster_EN.pdf http://www.bpmb.de/index.php/BPMNPoster 2. Exception Handling In BPMN, there are several different ways to represent exceptions and to include behavior that is specifically targeted at handling those exceptions. BPMN 2.0 language provides several constructs to represent exception handling in business processes: • Error events • Intermediate events • Escalation events • Event subprocesses Error events • These are the traditional solution to the problem of representing exceptions in BPMN. • The error event is a special kind of event that can take the form of an intermediate event (if the error is being caught) or an end event (if the error is being thrown). • In the former case, the error event acts as an intermediate (catching) event attached to the boundary of an activity. • In the latter case, the activity throws an error by means of an end event. Intermediate events • These are attached to the boundary of activities are the most commonly used constructs to represent exceptions. • The attached events are interrupting events in the sense that their occurrence interrupts the execution of the activity they are attached to.
IT402 INTEGRATED ENTERPRISE SYSTEMS HESSAH AL HAROON 7 • However, BPMN also enables noninterrupting attached events; for instance, when someone sends an inquiry while the activity is running, the use of a noninterrupting message event allows the inquiry to be handled and a response to be returned without interrupting the activity. Escalation events • These are a variation on the error events, with the main purpose of alerting someone else particularly, someone who is above in the hierarchical structure of the organization—of some problematic situation that occurs in the business process. • In particular, an escalation event means that someone with higher responsibility (e.g., a supervisor) will be called to intervene, or at least will be notified. • A significant difference between error events and escalation events is that escalation events may be thrown by intermediate events and may also be caught by noninterrupting attached events. Event subprocesses • This can be triggered by an event occurring in parallel with the main process flow. • This event may occur at any point during the process, and the subprocess will be run immediately as a reaction to that event. • Because an event subprocess is able to keep listening for events during the entire duration of a process, it has some advantages when compared with the intermediate events that cease to listen for the event trigger once the activity or subprocess is completed. 3. Transactions • In business processes, transactions work in a different way from the traditional transactions in database systems. • In particular, in a business process, there are long-running transactions, where work is committed in a stepwise fashion instead of being held until the very end of the transaction. • The BPMN language provides several constructs to represent transactions and compensation in business processes. The BPMN language provides several constructs to represent transactions and compensation in business processes, as follows: • Compensation handlers: There is an association between task A and task B and, in particular, this association means that task B is the compensation handler for task A. • Transactional subprocesses: The transactional subprocess can be regarded as a transactional concept that serves as a container for other activities or subprocesses. • Compensation events: Compensation handlers can also be triggered explicitly through the use of compensation events. Summary • BPMN is a graphical notation for modeling business processes. • This chapter explored the wide range of elements that BPMN provides to create business process models. • The notation of BPMN is sufficiently clear so as to describe process behavior in a way that can be translated into an executable form.

Place this order or similar order and get an amazing discount. USE Discount code “GET20” for 20% discount