Business Modeling

1. Business Modeling Lesson №5

2. Structural analysis is the method of studying the system, which begins with its general review, and then in detail, gaining a hierarchical structure with an increasing number of levels. For such methods is characterized by: • decomposition into levels of abstraction with a limited number of elements (from 3 to 7); • limited context that includes only the essential details of each level; • use strict formal rules of writing; • successive approximation to the result. Structural analysis is based on two basic principles - the "divide and conquer" principle and the hierarchical ordering. Solution of difficult problems through their decomposition into many small independent tasks (black boxes) and the organization of these problems into tree hierarchies greatly enhance understanding of complex systems.

3. Key concepts of structural analysis • Operation - an elementary (indivisible) action performed on a single workplace. • Function - a set of operations grouped by certain characteristics. • Business process - related to the collection of of functions in the course of which certain resources are consumed and created a product ( goods, services, scientific discovery , the idea),that represents the value for the consumer. • Subprocess - it is a business process is a structural element of a business process, and valuable to consumers. • Business model - structured graphic description of the network of processes and operations associated with data, documents, organizational units, and other objects that reflect the existing or proposed activities of the company.

4. Methodology - a set or system of methods, principles, and rules for regulating a given discipline, as in the arts or sciences, defines the steps of their sequence (ARIS, SADT) • Notation - a system of graphic symbols for a specialized use, other than ordinary writing (IDEF0, EPC, UML). • Tools support users work to design/edit graphical project (ARIS, Business Studio, Rational Rose). • The term "computer-aided software engineering" (CASE) can refer to the software used for the automated development of systems software, i.e., computer code. The CASE functions include analysis, design, and programming. CASE tools automate methods for designing, documenting, and producing structured computer code in the desired programming language. • CASE software supports the software process activities such as requirement engineering, design, program development and testing. Therefore, CASE tools include design editors, data dictionaries, compilers, debuggers, system building tools, etc. • CASE also refers to the methods dedicated to an engineering discipline for the development of information system using automated tools. • CASE is mainly used for the development of quality software which will perform effectively.

5. Workbenches integrate several CASE tools into one application to support specific software-process activities: • a homogeneous and consistent interface (presentation integration). • easy invocation of tools and tool chains (control integration). • access to a common data set managed in a centralized way (data integration). • CASE workbenches can be further classified into following 8 classes: • Business planning and modeling • Analysis and design • User-interface development • Programming • Verification and validation • Maintenance and reverse engineering • Configuration management • Project management

6. Methodologies of structural modeling domain Business modeling can be achieved through various techniques, differing views on the organization of methods can be divided into objective and functional (structural), each of the presented approach has its advantages. • Objective methods (ARIS) are considering the simulated organization as a collection of interacting objects - production units. The object is defined as a tangible reality - an object or a phenomenon with clearly defined behavior. The aim of this methodology is the selection of objects that make up the organization and distribution of responsibilities between them for the actions taken. This approach allows us to construct a more robust to changes in the system, corresponds better to the existing structure of the organization. • Functional methodology (SADT) considers the organization as a set of functions that converts the incoming flow of information to the output stream. The process of converting information consumes certain resources. The main difference from the object methodology is clear separation of functions (data processing) from the data. If the organizational structure is in the process of changing or even poorly framed, functional methods are right. This approach of the duties performed intuitively better understood upon receipt of their information about their current work. Currently, this approach is the basis for business modeling.

7. SADT-methodology of structural modeling domain Structured Analysis and Design Technique (SADT) was designed specifically to help people describe and understand systems. It offers building blocks to represent entities and activities, and a variety of arrows to relate boxes. These boxes and arrows have an associated informal semantics. SADT can be used as a functional analysis tool of a given process, using successive levels of details. The SADT method allows to define user needs for IT developments, which is very used in the industrial Information Systems, but also to explain and to present an activity’s manufacturing processes, procedures. The SADT supplies a specific functional view of any enterprise by describing the functions and their relationships in a company. These functions fulfill the objectives of a company, such as sales, order planning, product design, part manufacturing, and human resource management. The SADT can depict simple functional relationships here and can reflect data and control flow relationships between different functions.

8. The aim of business modeling is to provide the complete and thorough knowledge base of all project participants for its use in determining the architecture and implementation plan. There are 2 steps of business modeling: • construction of the provisional business model - a preliminary business model identifies the functions, gives their descriptions and identifies the organizational units - performers functions. Pre-Business Modeling "requires 25-30% of total labor costs for simulation; • construction of a complete business model, which provides answers to these questions : • What information is used in performing the functions? • When the function is executed? • Where and by whom the function is executed? • How often is a function carried out? • What improvements are possible?

9. 3 steps of preliminary business modeling 1. Documentation of organizational structure: • formation (edit) organizational charts; • identification of activities in the context of the organizational units - departments, officers, definition of roles; • generate reports on the results obtained. 2. structuring the business model - identification and definition of business functions, each of which has an output of at least one organizational unit: : • determining the basic directions of activity and categories of business processes;functional decomposition processes; • functional decomposition processes; • development of functional decomposition to the level of business operations; • construction of a functional hierarchy tree; • detalization’s quality evaluation and its improvement; • mapping functions and executing their organizational units, the construction of the matrix of responsibility. 3.documenting business model and its dissemination to verify. • generate reports on the business model; • dissemination of reports and conduct presentations; • collect comments and suggestions • .

10. Popular business modeling methodologies • IDEF– methodologies from ICAM (Integrated Computer-Aided Manufacturing) family for solving complex systems modeling, you can display and analyze the business model of a wide spectrum. Depth examination of processes in the system defined by the developer that does not disturb the excess data to create a model; • DFD(Data Flow Diagrams) — graphical methodology of structural analysis, which describes the external to the system data sources and destinations, logical functions, data flows and data stores, are being accessed. • ARIS(Architecture of Integrated Information Systems) — methodology and a software product of IDS Scheer to model business processes. • Workfow - modeling methodology that uses a graphic description of information flows, the relationship between information processing and facilities that are part of these processes.

11. Popular business modeling notations • IDEF0 – construction of functional circuits of the system, describing all the necessary processes with an accuracy sufficient for an unambiguous modeling of the system. • IDEF3 (workflow) — this method with the main objective to enable analysts to describe a situation where the processes are performed in sequence, and describe objects, participating together in a single process. • DFD(Data Flow Diagramming) - presence in the diagrams DFD elements to describe the sources, receivers and data warehousing allows for more efficient and clearly describe the process workflow. • EPC (Event-Driven Process Chain) used to describe the lower level - an ordered combination of events and functions. For each function can be determined by the initial and final event, the participants, performers, and documentary material flows, accompanying her, and conducted decomposition at lower levels.

12. IDEF0 is the development of graphic language descriptions of functional systems SADT (Structured Analysis and Design Technique). Historically IDEF0 as a standard was developed in 1981 in an extensive automation of industrial enterprises - ICAM (Integrated Computer Aided Manufacturing). IDEF family of standards has inherited his designation from the name of the program (IDEF = Icam DEFinition), and its last edition was released in December 1993 by the National Institute of Standards and Technology (NIST). • IDEF0 – graphical modeling notation used to create a functional model that displays the structure and function of the system, as well as flows of information and material objects relating these functions. Notation of IDEF0 is one of the most popular notations Business Process Modeling. • The aim of IDEF0 is construction of functional circuits of the system, describing all the necessary processes with an accuracy sufficient for an unambiguous modeling of the system.

13. IDEF0 Context diagram – the initial, top level simulation in which the object represented by a single block with boundary arrows. This chart is called A-0 (A minus zero). The arrows on this diagram show the connection object modeling environment. Diagram A-0 sets the region of simulation and its boundary.

14. IDEF0 basic concepts • Context diagram - original unit that encapsulates all the analyzed object - a "black box". • Support for decomposition - to the required level of detail. Daughter chart covers the same area as the parent process, but describes it in more detail. When decomposing hands of the parent process are transferred to a subsidiary figure in the form of the boundary arrows. • Domination - power to noncontext IDEF0 diagram should be placed on the diagonal - from the top left corner of the diagram to the lower right in numerical order of numbers. Blocks on the chart located at the top left, "dominant" over the blocks, located at the bottom right. "Domination" is understood as the influence that the unit has on other components of the diagram. Arrangement of blocks on the chart sheet reflects the author's understanding of dominance. Thus, the topology of the diagram shows, which features a greater impact on the rest. • 4 types of arrows - input, output, mechanism, management.

15. IDEF0 basic concepts 4 types of arrows - input, output, mechanism, management. Inputs are transformed or consumed process to create what appears on its output. Control determine the conditions necessary process to produce the correct output. Output - data or material objects produced by the process. Mechanisms identify the means supporting the implementation process. Thus, a block IDEF0 shows the transformation of inputs into outputs through mechanisms based controls.

16. IDEF0 diagram’s graphic symbols

17. IDEF0 diagram’s graphic symbols

19. Process is the sequence of actions

21. IDEF3 (workflow) is the method for describing a logical sequence of processes / functions, including related objects (documents, performers). • Workflow diagrams can be used in the modeling of business processes to analyze the completion of procedures for processing information. Workflow diagrams can be used to describe the action scripting employees, for example, the sequence of order processing, or events to be processed within a finite time. Each scenario is accompanied by a description of the process and can be used to document each function. • IDEF3 is part of the structural analysis, but has flexible rules of syntax, which can lead to incomplete or inconsistent models. IDEF3 complements IDEF0 and contains everything needed to build models that can later be used for simulation analysis. • IDEF3 is modeling methodology and standard documentation processes occurring in the system. The method of documenting the process provided a mechanism to document and gather information about processes

22. IDEF3 (workflow) • IDEF3 shows causal links between situations and events in an understandable form, using the structural method of expressing knowledge about how the operating system, process or facility. The system is described as an ordered sequence of events with simultaneous description of objects relevant to the simulated process. • Each work in IDEF3 describes a scenario of a business process and may be part of another job. Because the script describes the purpose and scope of the model, it is important to work were called verbal noun denoting a process of action, or a phrase containing a noun. • IDEF3 is the standard documentation of information, technological and other processes occurring in the enterprise, and provides the tools for visual exploration and modeling of their scripts. Scenario is the sequence of changes in properties of the object, in the framework of this process (for example, the sequence of stages of processing parts in the shop and change its properties after the passage of each stage). • Execution of each scenario is accompanied by relevant information flows, for example, in the form of documents. An industrial enterprise document production process consists of two main streams: documents defining the structure and sequence of the process (process instructions, descriptions, standards, etc.), and documents that show its progress (the results of tests and examinations, reports of marriage, and etc.).

23. IDEF3 (workflow) To effectively manage anything, you must have a detailed picture of his scripts and the structure of the accompanying documentation. Tools for documenting and modeling IDEF3 allow you to perform the following tasks: • Document the available data on the process technology identified in the process of pre-poll survey by competent staff in charge of organizing this process. Identify and analyze the point of fusion and separation of information flows. Identify situations that require decisions affecting the life cycle process. Facilitate optimal decision-making during the reorganization process. Develop process models on an "AS IS, IF ...“ • IDEF3 has a direct relationship with the methodology - each function (functional unit IDEF0) can be represented as a separate process by means of IDEF3. IDEF3 consists of two methods: • Process Flow Description (PFD) - description of the process, with an indication of what is happening at each stage of the process. • Object State Transition Description (OSTD) - description of the transition states of objects, indicating which there are intermediate states that objects in the simulated system PFDD-charts display process "From the standpoint of an observer", the OSTN can be considered the same process of "From the perspective of an object"

25. IDEF3 (PFDD) • Rectangles on the chart PFDD called work, functional elements, or elements of behavior (Unit of Behavior, UOB) and represent the event, the stage of the process or decision. Each UOB has its name displayed in the verbal mood, and a unique number. Arrows or lines are displaying moving parts between UOB-blocks in the process. • The object, designated J1 - called the Junction, they are used to display the logic of interaction between the arrows (flows) at the confluence and branching or to display a set of events that may or must be completed before the next job. There are junctions for fusion (Fan-in Junction) and branching (Fan-out Junction) arrows. Junctions can not be used for merging and branching.

26. IDEF3 (OSTN) Object state and state change are key concepts OSTN diagram. State of the object are displayed by circles, and they changing the direction of the lines. Each line has a reference to the corresponding functional unit UOB, resulted in the display change to her state of the object. OSTN diagrams capture object-centered views of processes which cut across the process diagrams and summarize the allowable transitions.

27. IDEF3: example Parts enter the shop ready for the primer coat to be applied. We apply one very heavy coat of primer paint at a very high temperature. The paint is allowed to dry in a bake oven after which a paint coverage test is performed on the part. If the test reveals that not enough primer paint has been sprayed on the surface of the part, the part is re-routed through the paint shop again. If the part passes the inspection, it is routed to the next stop in the process. Note the activities described in the scenario are clearly identified and appear as labeled boxes in The IDEF3 term for elements represented by boxes is a Unit Of Behavior (UOB). The arrows (links) tie the boxes (activities) together and define the logical flows. The smaller boxes define junctions that provide a mechanism for introducing logic to the flows. Each UOB can have associated with it both "descriptions in terms of other UOBs" and a "description in terms of a set of participating objects and their relations." We refer to the former as decompositions of a UOB and the latter as an elaboration of a UOB. Intuitively, a decomposition is a closer look at some given UOB within a larger diagram. A decomposition is a diagram, and may be a decomposition of some UOB in the scenario (top level) diagram or it may be the decomposition of a UOB in a decomposition. More precisely, a decomposition of a given UOB is a more fine grained IDEF3 representation of that UOB. Multiple views (decompositions) are allowed in IDEF3 primarily because it is meant to be used as a description capture method. Experience with related modeling methods has demonstrated the need to capture different views of the same activity. IDEF3 provides this capacity by allowing multiple decomposition of the same UOB.

28. IDEF3: example

29. IDEF3: example

30. DFD(DataFlowDiagramming) • Data flow diagrams are the primary means of modeling the functional requirements for the projected system. Requirements are represented as a hierarchy of processes related to data streams. Data flow diagrams show how each process converts its input into the weekend, and identify relationships between these processes. • DFD-diagrams have been used successfully as an adjunct to the IDEF0 model to describe the workflow and information processing. Like IDEF0, DFD represents the simulated system as a network of related works. The main components of DFD (as mentioned above) - or work processes, external entities, data flows, data storage devices (storage). • In contrast to the shooter IDEF0, which are hard links, DFD arrows show how the objects (including data) are moving from one job to another.This view flows, together with data warehouses and external entities in DFD model makes more like the physical characteristics of the system - the movement of objects, storage facilities, supply and distribution facilities.

31. DFD(DataFlowDiagramming)

32. DFD(DataFlowDiagramming) • Unlike IDEF0, where the system is viewed as interrelated work, DFD considers the system as a collection of objects. Context diagram often includes works and external links. Work is usually referred to by the name of the system, such as "Information Processing System. “Inclusion of external links in the context diagram does not negate the requirements of the methodology to clearly define the purpose, scope, and a unified view of the simulated system. • DFD diagrams can be built using traditional structural analysis, similar to how we construct the diagram IDEF0. • In DFD number of each work may include the prefix (A), number of parental work and the object number. Object number - a unique job number on the chart. For example, the work may have a number A.12.4. A unique number has a data warehouse and external entities, regardless of their location on the chart. Each data store has a prefix of D and a unique number, such as D5. Each external entity has a prefix of E and a unique number, such as E5. • The presence in the diagrams DFD elements to indicate the sources, receivers and data warehousing allows for more efficient and clearly describe the process workflow.

33. DFD(DataFlowDiagramming) • In the DFD operation (processes) are functions of the system that convert inputs into outputs. Although the works are represented by rectangles with rounded corners, their meaning is identical with the sense of IDEF0 and IDEF3. As well as processes IDEF3, they have inputs and outputs, but do not support the control and mechanisms such as IDEF0 (Blocks "Check and make customers ", "Making Order"). • External entities represent entries into the system and / or outputs from the system as a rectangle with a shadow and is usually located on thethe edges of the of the diagram ( blockcalls from our clients ).A foreign entity can be used repeatedly on one or more charts .Usually this technique is used to do not draw too long and confusing arrows. • In DFD shooters can merge and fork, which allows to describe the decomposition of the shooter. Each new segment merging or branching arrows may have its own name.

34. DFD(DataFlowDiagramming) • Workflows are represented by arrows and describe the motion of objects from one part to another. Since the DFD every aspect of the work has no clear purpose, as in IDEF0, the arrows can come in and out of any face of the rectangle. In the DFD are also used bi-directional arrows to describe the conversations of the type "command-response" between jobs, between work and an external entity, and between external entities. • in contrast to the arrows that describe the objects in motion, data warehouse depict objects at rest. • in physical systems, data warehouses are depicted, where objects are awaiting processing, for example in the queue. In data processing systems data warehouse is a mechanism that allows you to save data for subsequent processes.

35. Other popular notations of busines modeling • Process and Procedure notations can be used to model the individual processes of the company, as well as on the lower level business process models created in the notation of IDEF0. Process and Procedure notations are used for the presentation of the algorithm (the script) of a process and allow you to specify causal relationships and temporal sequence of action process. Support decomposition on subprocesses as IDEF0. The difference between the notations Process and Procedure is that, in addition to the graphic elements used in the process notation, Procedure has swim lines, indicating the organizational unit – executors of procesess’ actions. This allows us to increase the visibility of the diagram.

36. Process

37. Procedure

38. Нотации Процесс и Процедура

41. Notation EPC EPC (Event-Driven Process Chain) is used to describe the lower level.Process diagram notation in EPC, is an orderly combination of events and functions. For each function can be determined by the initial and final event, the participants, performers, and documentary material flows, accompanying her, and conducted decomposition at lower levels.

45. Rules for modeling processes in the EPC • Diagram of EPC must start with at least one start event (start event can follow the process interface) and completed at least one final event (the final event can be preceded by an interface process); • Events and functions in the course of a process must alternate. Decisions on further progress in the implementation process adopted functions; • Recommended number of functions on the chart - no more than 20. If the number of features of the diagram is much higher than 20, then the possibility exists that correctly identified the processes at the top level and must make an adjustment model; • Events and functions should contain only one at the incoming and one outgoing communication, reflecting the progress of the of the; • The diagram need not be present objects without a single connection; • If the operator has an incoming link from an element "event", then it must have outgoing calls to an element of "function " and vice versa. • Events and statements surrounding the function on the overlying diagram should be the initial / Result events and operators in the diagram decomposition of the function

46. Rules for modeling processes in the EPC Every operator of a merger must have at least two incoming connections and only one output, the operator of the branch - just one incoming link and at least two outgoing. Operators can not have both multiple incoming and outgoing communications. • For a single event should not follow the operators OR/XOR. • Operators can combine or branching only functions or events only. Simultaneous association / branch functions and events can not be. • Operator, branching twigs, and the operator that combines these branches should be the same. Also allowed a situation where the operator of the branch "AND" operator association - "OR".

47. EPC

48. ARIS-methodology

49. ARIS-methodology • ARIS (Architecture of Integrated Information Systems) is an approach to enterprise modeling. It offers methods for analyzing processes and taking a holistic view of process design, management, work flow, and application processing. • The ARIS-approach not only provides a generic and well documented methodological framework but also a powerful business process modeling tool. • ARIS started as the academic research of Prof August-Wilhelm Scheer in the 1990s. It has an industrial background, and has sold very well, and in this way widespread. • On the other hand, based on the conceptual description, ARIS can model and structure Business Process Models. • Furthermore, ARIS House has been developed to implement business models in IS. • As one of the Enterprise Modeling methods, "Architecture of Integrated Information Systems" ARIS provides four different aspects of applications: • The ARIS concept is the architecture for describing business processes. • The ARIS concept provides modelling methods, the meta structures of which are comprised in information models. • The ARIS concept is the foundation for the ARIS Toolset software system for the support of modeling. The ARIS house of Business Engineering represents a concept for comprehensive computer-aided Business Process Management.

50. ARIS-methodology Organization in ARIS is considered from four perspectives: • Organizational structure, • Functional structure, • Data structures • Process structure. Each of these points of view shared by all three sublevels: a description of the requirements, a description of the specification, description of implementation. To describe the business processes are encouraged to use about 80 types of models, each of which belongs to one or another aspect. ARIS has representative powerful graphics, which makes the model particularly useful and illustrative.