Log in Page Discussion History Go to the site toolbox

IESEG2010

From BluWiki



Contents

Page Is Unavailable Due To Site Maintenance, Please Visit Reserve Copy Page


CLICK HERE


YES, YOU ARE IN THE RIGHT PAGE!!

Business Process Modeling

Monday, March 15th

MAIN TOPIC OF THE DAY

DEFINITION

Today we were thinking about the definition of Business Process. We agreed that it is collection, a series of activities and tasks connected to each other, according to time and places constraints, that solve defined problem or lead to achieving particular organizational object.

Alternatively, it can be defined as the activity of representing processes of an enterprise, so that current process may analyzed("as is") and improved in future("to be"). <br> source - http://en.wikipedia.org/wiki/Business_process_modeling

HISTORY OF BUSINESS PROCESS

The term "business process modeling" itself was coined in the 1960s in the field of systems engineering by S. Williams his 1967 article "Business Process Modeling Improves Administrative Control". His idea was that techniques for obtaining a better understanding of physical control systems could be used in a similar way for business processes. (Williams, S. (1967) "Business Process Modeling Improves Administrative Control," In: Automation. December, 1967, pp. 44 - 50.) It can be said that business process as a concept arrived when Frederick Taylor developed theory of scientific management in 1905. In the 1970s many Japanese companies followed Total Quality Management concept coined by W. Edwards Deming. The basis of TQM is to reduce the errors produced during the manufacturing or service process. In the 1990s Michael Hammer and James Champy came up with the concept of Business process re-engineering.Business Process Reengineering (BPR) is a management practice that aims to improve the efficiency of the business process.Ford, P&G, General Motors and Dell are examples of companies who improved their performances by re-engineering their business processes. In the 1990s the term "process" became a new productivity paradigm.(Asbjørn Rolstadås (1995). "Business process modeling and reengineering". in: Performance Management: A Business Process Benchmarking Approach. p. 148-150.) Companies were encouraged to think in processes instead of functions and procedures. Process thinking looks at the chain of events in the company from purchase to supply, from order retrieval to sales etc. The traditional modeling tools were developed to picture time and costs, while modern methods focus on cross-function activities. These cross-functional activities have increased severely in number and importance due to the growth of complexity and dependencies. New methodologies such as business process redesign, business process innovation, business process management, integrated business planning among others all "aiming at improving processes across the traditional functions that comprise a company".In 1990s quality certifications like ISO9001 were introduced which gave a lot of emphasis on processes and defined standards for quality management systems.Concepts like six sigma for quality management were introduced in 2000s which pulled many of previous techniques into a comprehensive framework.

Around 1995 the first visually oriented tools for business process modeling and implementation were being presented.


IMPORTANT ISSUES

When we plan the process, we have to pay attention on these important issues:

- Who? – we have to specify who we are and who the receiver of the process is as it determines the structure of the process.

- Step owner/executor – we have to define who will be doing each step of the process, who is responsible for each particular part.

- Level of details – we will have to decide on how detailed our business process modeling is going to be, when we should stop going deeper. It is necessary that our analysis is coherent with the general goal(every step that we take should be related with this aim) and that means we can stop our analysis if we are sure the precision already applied is enough to illustrate the specific of the process.

- Time constraints – when we work on the business process we ought to be aware that we do not have unlimited time for doing that. There is always time problem as we have deadline for our project and that affects level of details as well.

- Quality measure – if possible it is good to define the way of assessing the quality – it will help us to measure the performance.

- Budget constraints – basically planning the process will be limited to the amount of money available for that specific goal. It is necessary to take into account the costs of the process to fit in the budget.

- Reusing the tasks – try not to duplicate the tasks, if we can reuse the task, we should do it as our process structure will be more efficient.


In addition, according to some article(), tehy present the main BPM issues perceived by the experts against the typical organizational levels. The findings are thus grouped into three categories namely: strarelates to top management support, business and IT alignment, process organisation and governance issues. The tactical level encompasses challenges in efforts such as process modeling, process performance measurement and BPM methodologies. The operational level relates to technological issues in BPM adoption such as technology capability, SOA (Service Oriented Architectures) maturity in the technology landscape, use of XMLtegic level, tactical level, and operational/technical level issues (as shown in Table 1). This approach is used to specify the context of the identified issues and better structure the discussion. From the BPM perspective, the strategic level, which is at the top level of categorisation, standards and so on.

Strategic • Lack of governance • Lack of employee buy in • Lack of common mind share of BPM • Broken link between BPM efforts and organisational strategy

Tactical • Lack of standards • Weaknesses in process specification • Lack of BPM education • Lack of methodology

Operational • Lack of tool support for process visualisation • Perceived gaps between process design and process execution • Miscommunication of tool capabilities

<Major Issues in BPM at Different Organizational Levels, as noted by BPM Experts>

Whenever applicable, direct quotes from the experts are depicted as (‘see quotes in the text’), and when required minor editions are made to these quotes, the quotes are (<indicated thus>). During data analysis, the NVivo tool is used to enable the researchers to keep track of the information collected, the analysis and the original source. However, the original source is not denoted here in this report due to confidentiality agreements with the interviewed experts.

If you want to see more, please refer to http://espace.library.uq.edu.au/eserv/UQ:12295/BPM_issues_expert_study_report.pdf , which is original source of above contents.

BUSINESS PROCESS MATURITY STEPS

AD-hoc step is basicaly the first step in the business process maturity. At this step the process is installed accroding to the corporate needs but people within the organisation as no idea why this process answers to their needs, and they do not know really what are their tasks regarding this process. Moreover they may have some conflict between what they think they do and what they have really to do. Thus a new process can emerge.

Understaning step highligh what the conflict are about and thus we can create some diagrams to define how the process works and try to reduce the conflicts.

Automation step is to reduce the process in simple tasks.

Integration step is to define a more cross-functional process and try to focus more on the general aim of the company.


BUSINESS PROCESS METHODOLOGY (BASIC)

Continuous Improvement – Plan, Do, Check, Act A fundamental principle at the heart of many quality management systems is “Plan – Do – Check – Act”, first championed by Deming in the 1950’s:

PDCA


Plan – design or revise a business process or system or product Do – implement the plan and measure the result Check – evaluate the measurements or results Act – decide if further changes are appropriate and, if so, what these should be; then back again to… Plan – re-design or revise the process, system, product etc. This cyclic feedback process helps you achieve continuous improvement in the way you work, and in many respects it’s pretty obvious.

It’s also a fractal; individual activities within, say, the ‘Do’ phase, can themselves go through the same Plan-Do-Check-Act process in microcosm.

So how do you use it in practice?

In the last article I explained that Quality is about meeting requirements, doing “exactly what is says on the tin”. So an obvious way of applying Plan-Do-Check-Act is to look at how well your processes or procedures or working methods meet their requirements.

To do that, you really need measurements, in other words, objective, numeric Key Performance Indicators (‘KPIs’ – sorry for yet more jargon), then you can take action based on facts and can measure the real effectiveness of the changes you make rather than relying on subjective judgement. And the Key Performance Indicators should also align with the company’s objectives because, if not, how do you know how well you’re meeting your objectives?

So what KPIs do you measure in order to close the Plan-Do-Check-Act loop and achieve Continuous Improvement? Every company is different, but here are some that you could choose from:

Customer

Customer satisfaction monitoring results, complaints, customer support calls, repair or servicing response rates.

Sales

Sales pipeline (weighted according to probability vs. un-weighted), market share, competitive position, repeat sales, bid success rate, marketing campaign response rates.

Operations

Development project timescale or launch date vs. planned, proportion of product requirements met, product costs, production rate, staff productivity, on-time deliveries, supplier performance, stock levels, stock turn rates.

Quality

Reliability (e.g. Mean Time Between Failures or in-warranty returns), rejects / defects, production test yield, inspection levels, rework levels, waste (scrap) levels, ‘Cost Of Quality’, Corrective Action closure rates, internal audit rates and results.

Finance

Turnover, profit, cash in the bank, share value, dividend payments, adherence to budgets (across the whole company).

Human Resources

Staff turnover, headcount, utilisation (especially for service industries), appraisal scores, training, staff satisfaction monitoring results.

In order to manage your company at a detailed level you are probably using many of these measurements already. At the top level that I’m discussing in this article you don’t need to use all of them by any means, it’s better to have just a few and to use them well.

Choose your own KPIs, but always choose ones that are specific to, and key to the success of, your company. You should also have targets for each KPI – what results are you aiming at? (These targets are likely to change as a result of going round the Plan-Do-Check-Act loop).

Once you have the measurements in place, the rest of the Plan-Do-Check-Act process can kick in. This is usually done by reviewing or auditing the company’s processes and systems every few months and comparing the KPI results with their targets.

Reference : http://www.qualityandproducts.com/2009/04/24/continuous-improvement-plan-do-check-act/


BUSINESS PROCESS METHODOLOGY (ASIS/TOBE_GAP)

Gap analysis (also known as "need-gap analysis," "needs analysis" or "needs assessment") is an examination of where your business currently is and where you want your business to be, resulting in an apparent gap between the two. It is an insight into the needs for the improvement of your business and helps you determine what steps to take to attain your business goals.

STEPS

1. List the contributing factors to the current position of your business to answer the question "Where are we?" These factors may include the performance levels of employees, business strengths and weaknesses, results of marketing efforts and other similar measurable attributes.

2. Ask yourself and other executives "Where do we want to be?" List the factors that will contribute to your desired goals, such as more effective advertising, better results from employees and product improvements.

3. Recognize the gaps between the current state of your business and your business goals. In other words, determine how much work is necessary to move to your desired level of success.

4. Implement a strategic approach to lessen the gap. Ansoff's Matrix (see the link in Resources) is an effective way to assess the risks involved with certain strategies and help you decide what is the best way to accomplish your goals.

5. Use an alternative approach and implement tactical strategies to fill the gaps when it comes to the marketing of a product. A great way to determine the right tactics is by using the Marketing Mix and Four Ps analysis (see the link in Resources).

6. Work to eliminate the gaps over time to accomplish your business goals.


Tips & Warnings The gap analysis is not always the best approach in determining the changes you need to make in your business practices. The resulting strategies tend to be stationary in approach, and the vision and goals of your business can evolve, requiring repeated gap analyses.

References http://www.ehow.com/how_5220497_use-gap-analysis.html


In practice, for instance, LG CNS which is serving as IT consulting srvices, show the picture like below.

SS-MS-ME-001.gif

AS-IS analysis client interview, issue analysis, gap analysis, defining requirement

TO-BE analysis Mapping of requirement and functionality, benchmarking, TO-BE process design

Implementation plan ROI analysis, implementation strategy

reference : http://www.lgcns.com/en/services_solutions/manufacturing/manufacturing_execution.aspx

ORGANIZATIONAL PROCESS MODELING

Conceptual modelling means presenting ‘concepts’ and relationships between them. When we think about concepts it means “mental representation of the reality”, created based on main characteristics, features which are specific and crucial for recognition and identification of this reality. Here we have to differentiate concept from instance which is just one, real item from all the elements collected by concept. For example when we think about something to eat for a lunch we mean the concept of something for eating, but when we buy concrete sandwich with chicken, salad, sauce etc. this is the empirical, real instance of the mental concept. The idea of conceptual modelling is to model reality in the way that will be working properly in situation when different instances of the concept occur. (BPM 2010_1, F.Bolici)

Relations.jpg

Vertical relations:

- Decomposing: means being a part of something like each element of the concept is a part it this reality. In example a processor is part of the computer, a wheel is a part of the car, a living room is a part of the house etc.

- Specializing: means being more specified in a thinking of the general concept. For example train is a mean of transport, volleyball is a team game, tiramisu is a dessert etc.

Horizontal relations:

- Similarity: when two concepts have some similar, common features. We can distinguish high level of similarity and low level of similarity when the maximum level means identity. Examples: a notebook and PC, a tulip and a daisy.

- Correlation: when two concepts are connected somehow for example from the specific perspective or in particular environment. Example: the florist’s and the flowers, a dog and a doghouse.


EFFICIENCY AND EFFECTIVENESS

Both concept are most of the time related to each other in research paper, for example we could easily find some sentences like "this solution is both efficient and effective". But according to their definition theses two terms are negatively correlated. In fact, effecient means the amount of output made given a certain amount of input. And the effectiveness is more related to the degree of that we have reach of a specific aim. An industry which is efficient but not effective can not survive anymore.

In addition, when we think aboout more simple way, we can define Effectiveness as ‘Doing the right thing’ and define Efficiency as ‘Doing the thing right’.

This note provides an alternative explanation from Darnton, G. and Darnton, M. (1997)Business Process Analysis, Thomson-Learning. UK. p201-2

You may also want to check my article Defining efficiency and effectiveness for business strategy http://davechaffey.com/E-business/C5-Strategy/why-efficiency-and-effectiveness-measures-are-important-to-strategy/

These authors define efficiency and effectiveness as follows:


Efficiency definition

“Judgements of efficiency are based on some idea of ‘wastage’. A relatively efficient process either requires fewer inputs or produces more outputs compared to a similar process, to achieve the objectives of the process.

The authors refer to this as technical efficiency, which in equation form is:

Technical efficiency = Output quality / Input quantity

Different business units performing the same process can be compared by calculating the efficiency of each unit (giving a set of measures of absolute efficiency) and comparing the results [the relative efficiency].

An important variant of efficiency is Allocative efficiency. This involves weighting the inputs and outputs by their monetary values. Thus:

Allocative efficiency = Value of outputs/Cost of inputs


Effectiveness definition

Effectiveness is very similar to efficiency, but the measure is related to some enterprise objective rather than the technical quality of output. For example, one common indicator of effectiveness is related to customer satisfaction rather than output. Therefore the effectiveness measure of a business process can be indicated by the resource inputs needed to produce a level of an enterprise objective.

A further measure of effectiveness is given by:

Effectiveness = Enterprise objectives/Input Quantity"

ADDITIONAL INFORMATION

As someone has asked about SAP software these are links to basic information about this application SAP and the company SAP AG:

http://www.sap.com/index.epx - the company's website

http://en.wikipedia.org/wiki/SAP_AG - about SAP AG company and their products

http://en.wikipedia.org/wiki/SAP_R/3 - SAP AG main product

http://en.wikipedia.org/wiki/Enterprise_Resource_Planning - system which SAP application is based on

SAP is main basic product of the company, "an enterprise-wide information system designed to coordinate all the resources, information, and activities needed to complete business processes such as order fulfillment or billing" (http://en.wikipedia.org/wiki/SAP_R/3). When the company decides on implementation of such a software, SAP company often prepares special "issue" of the product corresponding to the specific company's requirements. For example SAP Spiridon add-on which is special add-on for the SAP application used by Siemens Company all over the world.


Potential Processes for Changing Business Procedures

The list of potential processes for changing business procedures are a combination of the two lists and include the following five business process evaluation procedures

Business process reengineering.

Radical changes are defined and implemented to achieve major improvements in business processes or to implement a major redirection of the business Processes. New business goals and missions maybe developed. Alternative business processes are usually identified and evaluated to identify the recommended new business processes. Business process modeling is often used to

identify and evaluate the strategic choices and to define the new business processes.

Business process redesign. A major effort redefinition of the business process and workflow is completed to significantly improve the existing business process performance. The changes to the business processes often change the sequence of how work is completed and the resources that are required. Ho wever, the goal and mission of the business are not modified. A business process redesign may include the identification, evaluation, selection, acquisition, and implementation of new business information

management systems. Business process modeling is used to evaluate the existing system and to identify opportunities for improving business processes. The business model could also be used to define the requirement for acquiring new information management technology.

Business process improvements. Incremental and continuous changes to business processes based on the measurement and monitoring of process performance. Business processes are tuned or modified to increase performance. The business process modifications are usually small and incremental. However, the monitoring is continuous and the business process modification should also occur frequently. Business process modeling may be used in conjunction with process measurements to identify potential process improvements and to define the impacts of proposed modifications.

Technology transfer. Existing business processes and data are translated and transferred from the existing business processes environment to a new technology or system. The business processes are modified to effectively use the capabilities and features of the new technology. The new technology must be clearly identified and its capabilities and functions known. This procedure would be used to modify business processes to use a new information management system that resulted from a “Business process reengineering” or a “Business process redesign.”

Process standardization. Business processes are defined and standardized to provide consistent, predictable and repeatable performance. Business processes may be standardized to satisfy legal requirements and to provide documentation for ISO 9000 certification or other certification standards. Business process modeling can be used to identify standardized processes and to document the standardized business processes.

REFERENCE : http://proceedings.esri.com/library/userconf/proc03/p0537.pdf

Tuesday, March 16th

ARIS (Architecture for integrated Information Systems)

It is a software for developing business process and information systems.It has an integrated environment for managing and supporting complex processes.It is based on different modeling methods (EPC, UML, E-R etc. ). ARIS started as the academic research of Prof August-Wilhelm Scheer in the 1990s. It has an industrial background, and has sold very well.The image below shows the ARIS Framework.

ARIS Framework.jpg

BUSINESS PROCESS MODELING TOOLS : http://upload.wikimedia.org/wikipedia/commons/3/36/BPMN-AProcesswithNormalFlow.jpg

Business process modeling tools provide business users with the ability to model their business processes, implement and execute those models, and refine the models based on as-executed data. As a result, business process modeling tools can provide transparency into business processes, as well as the centralization of corporate business process models and execution metrics.


Modeling and simulation

Modeling and simulation functionality allows for pre-execution “what-if” modeling and simulation. Post-execution optimization is available based on the analysis of actual as-performed metrics.

Business process modeling diagrams are:

   * Use case diagrams created by Ivar Jacobson, 1992. Currently integrated in UML
   * Activity diagrams, also currently adopted by UML

Some business process modeling techniques are:

   * Business Process Modeling Notation (BPMN)
   * Cognition enhanced Natural language Information Analysis Method (CogNIAM)
   * Extended Business Modeling Language (xBML)
   * Event-driven process chain (EPC)
   * ICAM DEFinition (IDEF 0)
   * Unified Modeling Language (UML), extensions for business process such as Eriksson-Penker's
Programming languages tools for BPM

BPM suite software provides programming interfaces (web services, application program interfaces (APIs)) which allow enterprise applications to be built to leverage the BPM engine.[9]

Programming languages that are being introduced for BPM include:[1]

   * Architecture of Integrated Information Systems (ARIS) supports EPC,
   * Business Process Execution Language (BPEL),
   * Web Services Choreography Description Language (WS-CDL).
   * XML Process Definition Language (XPDL),
   * Java Process Definition Language (JBPM),

Other technologies related to business process modeling include model-driven architecthttps

Tools for BP modeling

Business Integration Modeler provides business analysts with a tool to model, analyze, simulate, and improve business processes before transforming or exporting them into UML models for Rational XDE or Business Process Execution Language for Web Services (BPEL4WS) for WebSphere Business Integration Server Foundation (Business Integration Server Foundation). We use Business Integration Modeler V5.1 to create BP models and export them to WebShere Studio Application Developer Integration Edition V5.1.1 (Application Developer), as shown in Figure ( click on the link given below.)

https://www.ibm.com/developerworks/library/ws-bpm4analyst/Figure1.gif

(sources : http://en.wikipedia.org/wiki/Business_process_modeling)



workflow  ; A workflow consists of a sequence of connected steps. It is a depiction of a sequence of operations, declared as work of a person, a group of persons,[1] an organization of staff, or one or more simple or complex mechanisms. Workflow may be seen as any abstraction of real work, segregated in workshare, work split or other types of ordering.

Workflow concepts are closely related to other concepts used to describe organizational structure, such as silos, functions, teams, projects, policies and hierarchies. Workflows may be viewed as one primitive building block of organizations. The relationships among these concepts are described later in this entry.


Workflow improvement theories

The key driver to gain benefit from the understanding of the workflow process in a business context is that the throughput of the workstream path is modelled in such a way as to evaluate the efficiency of the flow route through internal silos with a view to increasing discrete control of uniquely identified business attributes and rules and reducing potential low efficiency drivers. Evaluation of resources, both physical and human is essential to evaluate hand-off points and potential to create smoother transitions between tasks. Several workflow improvement theories have been proposed and implemented in the modern workplace. These include:

  1. Six Sigma
  2. Total Quality Management
  3. Business Process Reengineering
  4. Lean systems

As a way of bridging the gap between the two, significant effort is being put into defining workflow patterns that can be used to compare and contrast different workflow engines across both of these domains. [edit] Workflow components

A workflow can usually be described using formal or informal flow diagramming techniques, showing directed flows between processing steps. Single processing steps or components of a workflow can basically be defined by three parameters:

  1. input description: the information, material and energy required to complete the step
  2. transformation rules, algorithms, which may be carried out by associated human roles or machines, or a combination
  3. output description: the information, material and energy produced by the step and provided as input to downstream steps.

Components can only be plugged together if the output of one previous (set of) component(s) is equal to the mandatory input requirements of the following component. Thus, the essential description of a component actually comprises only in- and output that are described fully in terms of data types and their meaning (semantics). The algorithms' or rules' description need only be included when there are several alternative ways to transform one type of input into one type of output – possibly with different accuracy, speed, etc.

When the components are non-local services that are invoked remotely via a computer network, such as Web services, additional descriptors (such as QoS and availability) also must be considered. (sources : http://en.wikipedia.org/wiki/Workflow)

EVENT DRIVEN PROCESS CHAIN

EPC is the center of the House of ARIS and connects all other views, as well as describes the dynamics of the business process.An Event-driven Process Chain (EPC) is a type of flowchart used for business process modelling. EPC's can be used for configuring an enterprise resource planning (ERP) implementation,and for business process improvement.The integration of different perspective viz. organizations structure, ER diagram and EPC into a single diagram is the Extended - Event driven process chain.Businesses use EPC diagrams to lay out business process work flows, originally in conjunction with SAP R/3 modeling, but now more widely.

There are a number of tools for creating EPC diagrams, including ARIS Toolset developed by IDS Scheer AG, ADONIS of BOC Group, Mavim Rules of Mavim BV, Business Process Visual ARCHITECT of Visual Paradigm, Visio of Microsoft Corp., Semtalk of Semtation GmbH, or Bonapart by Pikos GmbH. Some but not all of these tools support the tool-independent EPC Markup Language (EPML) interchange format.(http://en.wikipedia.org/wiki/Event-driven_process_chain) When we are drawing an event process chain and we need a loop in BPM there should be always a point to get out from the loop . because it carries the risk to get stuck in the loop and then we can not reach any solution. also the process that we created should be applicable to other areas(in todays class like in the advertising example)


ER (entity relationship)

The entity relationship modeling was invented by Porf. Peter Chen in the middle of the 1970's. The aim of the ER is to model the data within an entreprise model. It is used to describe the major entities in a business process and the relationship between them. The goal is to understand the principal data sources and data elements of interest to the business or organization, and the relationship between the sources.

[source: "entreprise modeling layout" by Pr. Elias Hadzilias, September 2009]

- Entities: an entity is a thing or object in the real world. It has a set of properties which uniquely identify this specific object. It is represented as a rectangle in ER.
- Attributes: is a descriptive property of an entities. This is represented as an ellipse in ER.
- Relationship: is the link between entities. A relationship is a named association between two or more entities. Such relationship are pondered by a Cardiality. 

The Cardinality of a relationship describes the number of instances of one entity that may be associated with another entity. A relationship may be :

One to one (1:1); A manager is head of at most one department and one department has at most one head manager.
One to many (1:N); A manager may supervise many employee and many employee are supervised by only one manager.
Many to many (N:M); An employee may be assignated to many porject and many project many be assignated to many employee.


Tools - Entity Relationship The (ER) Diagram Generator

Entity Relationship (ER) Diagram Generator helps users achieve a better understanding of their database schema by displaying the structure in a graphical format. Tools - Entity Relationship The (ER) Diagram Generator To view an ER Diagram:

  1. Launch the ER Diagram Generator dialog by:
         * Selecting Tools -> ER Diagram Generator from the Menu Bar OR
         * Selecting Tools -> ER Diagram Generator from the right-click pop-up menu on a database object in the Schema Browser
  2. Select a Database and Schema (or All Schemas)
  3. In the left panel, select one or more types of objects to be scripted (Tables, Views or Both).
     Click the green check button to select all and the red X button to deselect all.
  4. All objects matching the selected schema & object types will appear in the right panel. Select one or more objects to be scripted.
     Click the green check button to select all and the red X button to deselect all.
  5. Click Next to generate the diagram
  6. Once the diagram is generated, the ER Diagram Viewer will open and display the new diagram.
  7. To change the layout of the diagram, select an entry from the Layout dropdown list.
     Supported layouts include:
         * Box
         * Circle
         * Hierarchical
         * Tree
         * Radial Tree
         * Moen
         * Fruchterman-Reingold (FR)
         * Annealing
         * Inverted Self Organising Map (ISOM)
  8. The Entity View drop-down list determines the amount of detail displayed for each entity in the diagram. Select Full to view all attributes or Header to view only the entity name.
  9. To save an image of the current diagram, click Save Image As.
 10. To print a hard-copy of the current diagram, click Print.
 11. Click on an entity to display more column & constraint detail in the lower left panel.

ER Diagram Generator Enhancements:

   * General
         o ER Diagram: Indexed columns are now identified with an icon in the diagram.
         o ER Diagram Generator Dialog - Added "Reverse Selection" to object selection, to reverse the current selection


Aqua Data Studio - ER Diagram Menu ER Diagram Menu Aqua Data Studio - ER Diagram Generator ER Diagram Generator Aqua Data Studio - ER Diagram Window ER Diagram Window

sources : http://docs.aquafold.com/docs-er-diagram.html

More details about ER (entity relationship)

The ability of a database designer to understand and model the information that an organization uses is a critical design skill. Data modelers use a variety of tools and techniques to understand an organization’s data. In order to understand how to properly model data, you must become familiar with a modeling approach known as entity relationship modeling, which is the subject to of this chapter.

Entity-relationship (E-R) modeling is one approach to semantic modeling. When database designers attempt to understand and represent meaning, they are engaged in semantic modeling, which can help in making database design more systematic (Date, 1990). Although a number of approaches to semantic modeling exist, this chapter focuses on entity relationship modeling. More specifically, we use E-R modeling to carry out conceptual data modeling

ER modeling, introduced by Chen (1976) consists of a number of activities that help database designers understand the objects the organization wants to store information about, the important characteristics of these objects and the associations among various objects.

The Entity Relationship Diagram

The end result of E-R modeling is the E-R diagram (ERD), a graphical representation of the logical structure of a database. An ERD serves several purposes. First, the database analyst/designer gains a better understanding of the information to be contained in the database through the process of constructing the ERD. Second, the ERD serves as a documentation tool. Finally, the ERD is used to communicate the logical structure of the database to users. useruser In particular, the ERD effectively communicates the logic of the database to users.


Reference : http://knol.google.com/k/conceptual-database-design#

Entity : ER (entity relationship)

Entities The E-R modeling process identifies three basic elements: entities, attributes and relationships.

An entity is a thing that can be distinctly identified (Chen, 1976). In database design, entities are the “things” about which the database stores information. Entities can include, but are not limited to

· tangible items, such as equipment,

· concepts, such as accounts,

· people, such as employees

· events, such as sales, or

· places, such as business locations.

The term entity type refers to a number of related items, while an entity instance refers to a single occurrence of an entity type. For example, employee number 123-45-6789 refers to a single occurrence, or entity instance, of the entity EMPLOYEE. The term entity refers to entity type. In addition, note that entity occurrence is sometimes used rather than entity instance. In ER diagrams, rectangles represent entities, as shown in Figure 1.


F1.jpg

reference : Vanslyke, Craig. Conceptual database design:Entity relationship modeling http://knol.google.com/k/craig-vanslyke/conceptual-database-design/1fwdlprfh17di/2.

Attributes : ER (entity relationship)

An attribute is a single data value that describes a characteristic of an entity. Other terms such as data item and field, describe the same essential concept.

Each entity has a corresponding set of attributes that represent the information about the entity that the organization is interested in. For example, a university may wish to know the name, address, phone number, and major of each student. Put in database terms, STUDENT is the entity of interest, and NAME, ADDRESS, PHONE, and MAJOR are the attributes of interest.

Attributes are represented by ellipses in the ER diagram. The name of the attribute is shown inside the ellipse and a line is drawn from the attribute to its entity.

Primary Keys Every entity must have a primary key. The primary key is an attribute or combination of attributes that uniquely identifies an instance of the entity. In other words, no two instances of an entity may have the same value for the primary key. Factors database designers must consider when choosing a primary key are discussed later in this chapter.

Sometimes it is useful to use more than one attribute to form a primary key. When a primary key for an entity is made up of more than one attribute the key is called a composite key. The terms composite key and compound key are also used to describe primary keys that contain multiple attributes.

When dealing with a composite primary key it is important to understand that it is the combination of values for all attributes that must be unique. It is not necessary for each attribute in the key to be unique. For example, the entity ENROLLMENT has a composite primary key comprised of the attributes STUDENT_ID and COURSE_ID. Each instance of ENROLLMENT must contain a unique combination of values for StudentID and CourseID. However, there can be duplications of StudentID or CourseID. So, it is possible for many instances of ENROLLMENT to have the value MIS100 for CourseID, but each of those instances must contain different values for StudentID. Figure 2 shows entities with attributes and primary keys indicated.

F2.jpg


reference : Vanslyke, Craig. Conceptual database design:Entity relationship modeling http://knol.google.com/k/craig-vanslyke/conceptual-database-design/1fwdlprfh17di/2.

Relationships : ER (entity relationship)

A relationship is an association among two or more entities. For example, a STUDENTS entity might be related to a COURSES entity, or an EMPLOYEES entity might be related to an OFFICES entity. An ellipse connected by lines to the related entities indicates a relationship in an ERD, as shown in Figure 3. The line connecting the ORDERS and CUSTOMERS entities indicates that these two entities are related to one another.

F3.jpg


Different relationship degrees exist. The degree of a relationship refers to the number of entities involved in the relationship. Although others exist, it is often sufficient to understand the meaning of three relationship degrees, unary, binary and ternary. A unary relationship (also called a recursive relationship) is a relationship involving a single entity. A relationship between two entities is called a binary relationship. When three entities are involved in a relationship, a ternary relationship exists. Relationships that involve more than three entities are referred to as n-ary relationships, where n is the number of entities involved in the relationship. Examples are provided for unary, binary and ternary relationship later in this chapter.

In some cases, attributes may be attached to a relationship, rather than an entity. For example, a GRADE attribute is a function of the combination of STUDENTS and COURSES, but is not strictly a function of either entity by itself. Attaching GRADE to STUDENT would not indicate that a STUDENT has a GRADE for a particular COURSE, while attaching GRADE to COURSES doesn't show that the GRADE is for a particular STUDENT. Attaching the GRADE attribute to the relationship between COURSES and STUDENTS shows that a value of GRADE is dependent on an intersection of COURSES and STUDENTS. A similar argument can be made for TERM. Figure 4 illustrates how to show this on an E-R Diagram.


F4.jpg


reference : Vanslyke, Craig. Conceptual database design:Entity relationship modeling http://knol.google.com/k/craig-vanslyke/conceptual-database-design/1fwdlprfh17di/2.

Cardinality : ER (entity relationship)

Relationships can also differ in terms of their cardinality. Maximum cardinality refers to the maximum number of instances of one entity that can be associated with a single instance of a related entity. Minimum cardinality refers to the minimum number of instances of one entity that must be associated with a single instance of a related entity. The following examples of binary relationships illustrate the concept of maximum cardinality (Fig. 6). Minimum cardinality is discussed in more detail later in the next section. If one CUSTOMER can be related to only one ACCOUNT and one ACCOUNT can be related to only a single CUSTOMER, the cardinality of the CUSTOMER-ACCOUNT relationship is one-to-one (1:1). [Note that each cardinality type is followed by a shorthand notation in parentheses.]

If an ADVISOR can be related to one or more STUDENTS, but a STUDENT can be related to only a single ADVISOR, the cardinality is one-to-many (1:N).

Finally, the cardinality of the relationship is many-to-many (M:N) if a single STUDENT can be related to zero or more COURSES and a single COURSE can be related to zero or more STUDENTS. Further examples are provided later in this chapter.

In E-R diagrams, cardinality is represented by symbols attached to the relationship line. A single vertical line intersecting the relationship line indicates a "one" cardinality. A crowfoot symbol indicates a "many" cardinality. Figure CARDINALITY shows ER diagrams with cardinality symbols. Figure 5(a) shows the E-R diagram for a 1:1 relationship, Figure 5(b) shows a 1:N relationship, and Figure 5(c) shows a M:N relationship. The symbols closest to the entities are the maximum cardinality symbols. We'll cover the symbols for minimum cardinalities later.


F5.jpg

When determining the cardinality of relationships, it is important to remember that cardinality specifies how many instances an entity can be related to a single instance of a related entity. The trick to determining the cardinality of a relationship is to determine the cardinality of one side at a time.

For example, suppose you want to determine the cardinality of the STUDENTS to ADVISORS relationship. The first step is to determine how many STUDENTS one ADVISOR can be related to. One ADVISOR can be related to many STUDENTS. To represent this on an E-R diagram, show the "many" symbol (the crowfoot) next to the STUDENT entity. Next, you need to determine how many ADVISORS one STUDENT can be related to. While this may vary from school to school, in this case the answer is one. To show this on the E-R diagram, put the "one" symbol (vertical line) next to the ADVISOR entity. Figure 6 illustrates the process.

F6.jpg

If you have trouble determining the cardinality of a relationship, the following method may help. Assign a name to the entity instance you want to hold to one. For example, if you were having trouble determining the cardinality of the ADVISOR to STUDENT relationship you could ask yourself, "How many ADVISORS can Jan Smith have?", or "How many STUDENTS can Dr. Smith advise?"


reference : Vanslyke, Craig. Conceptual database design:Entity relationship modeling http://knol.google.com/k/craig-vanslyke/conceptual-database-design/1fwdlprfh17di/2.

Developing an Entity-Relationship Diagram:

There are three basic elements in ER models: Entities are the "things" about which we seek information. Attributes are the data we collect about the entities. Relationships provide the structure needed to draw information from multiple entities. Generally, ERD's look like this:

An example for an ERD.png

Developing an ERD requires an understanding of the system and its components. Before discussing the procedure, let's look at a narrative created by Professor Harman.

Consider a hospital: Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single doctor, but in rare cases they will have two. Healthcare assistants also attend to the patients, a number of these are associated with each ward. Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time. The system must record details concerning patient treatment and staff payment. Some staff are paid part time and doctors and care assistants work varying amounts of overtime at varying rates (subject to grade). The system will also need to track what treatments are required for which patients and when and it should be capable of calculating the cost of treatment per week for each patient (though it is currently unclear to what use this information will be put).


How do we start an ERD? 1. Define Entities: these are usually nouns used in descriptions of the system, in the discussion of business rules, or in documentation; identified in the narrative (see highlighted items above). 2. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules (entity ______ entity); identified in the narrative (see highlighted items above). 3. Add attributes to the relations; these are determined by the queries,and may also suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers.

What questions can we ask? a. Which doctors work in which wards? b. How much will be spent in a ward in a given week? c. How much will a patient cost to treat? d. How much does a doctor cost per week? e. Which assistants can a patient expect to see? f. Which drugs are being used?

4. Add cardinality to the relations Many-to-Many must be resolved to two one-to-manys with an additional entity Usually automatically happens Sometimes involves introduction of a link entity (which will be all foreign key) Examples: Patient-Drug

5. This flexibility allows us to consider a variety of questions such as: a. Which beds are free? b. Which assistants work for Dr. X? c. What is the least expensive prescription? d. How many doctors are there in the hospital? e. Which patients are family related?

Reading an ERD

It takes some practice reading an ERD, but they can be used with clients to discuss business rules. These allow us to represent the information from above such as the E-R Diagram below:

Hospital.png

ERD brings out issues: Many-to-Manys Ambiguities Entities and their relationships What data needs to be stored The Degree of a relationship

Source: http://www.umsl.edu/~sauterv/analysis/er/er_intro.html


VALUE CHAIN

A value chain is a chain of activities for a firm operating in a specific industry. The business unit is the appropriate level for construction of a value chain, not the divisional level or corporate level. Products pass through all activities of the chain in order, and at each activity the product gains some value. The chain of activities gives the products more added value than the sum of added values of all activities.Typically, the described value chain and the documentation of processes, assessment and auditing of adherence to the process routines are at the core of the quality certification of the business, e.g. ISO 9001.(http://en.wikipedia.org/wiki/Value_chain)


SOME ADDITION TO IT.....

To better understand the activities through which a firm develops a competitive advantage and creates shareholder value, it is useful to separate the business system into a series of value-generating activities referred to as the value chain. In his 1985 book Competitive Advantage, Michael Porter introduced a generic value chain model that comprises a sequence of activities found to be common to a wide range of firms. Porter identified primary and support activities as shown in the following diagram:

Porter's Generic Value Chain Inbound Logistics > Operations > Outbound logistic > Marketing & Sales > MARGIN

                   Firm Infrastructure
                   HR Management
                   Technology Development
                   Procurement

goal of this activity is : to offer the customer a level of value that exceeds the cost of the activities, thereby resulting in a profit margin.

The primary value chain activities are:

   * Inbound Logistics: the receiving and warehousing of raw materials, and their distribution to manufacturing as they are required.
   *Operations: the processes of transforming inputs into finished products and services.
   *Outbound Logistics: the warehousing and distribution of finished goods.	
   *Marketing & Sales: the identification of customer needs and the generation of sales.
   *Service: the support of customers after the products and services are sold to them.

These primary activities are supported by:

   *The infrastructure of the firm: organizational structure, control systems, company culture, etc.
   *Human resource management: employee recruiting, hiring, training, development, and compensation.
   * Technology development: technologies to support value-creating activities.
   * Procurement: purchasing inputs such as materials, supplies, and equipment.

The firm's margin or profit then depends on its effectiveness in performing these activities efficiently, so that the amount that the customer is willing to pay for the products exceeds the cost of the activities in the value chain. It is in these activities that a firm has the opportunity to generate superior value. A competitive advantage may be achieved by reconfiguring the value chain to provide lower cost or better differentiation.

The value chain model is a useful analysis tool for defining a firm's core competencies and the activities in which it can pursue a competitive advantage as follows:


   * Cost advantage: by better understanding costs and squeezing them out of the value-adding activities.
     *Differentiation: by focusing on those activities associated with core competencies and capabilities in order to perform them better than do competitors.

(source : http://www.netmba.com/strategy/value-chain/)

ORGANIZATIONAL CHART

Definition

An organizational chart is a diagram that shows the structure of an organization and the relationships and relative ranks of its parts and positions/jobs.An organizational chart of a company usually shows the managers and sub-workers who make up an organization. It also shows the relationships between the organization's staff members which can be one of the following:

Line,it is the category of personnel with direct responsibility for achieving the objectives of the organization.they are involved with activities directly related to the achievement of the department's goal and thay carryout the primary activities of a business and considered essential to the basic part of the organization.(http://www.scribd.com/doc/14167293/Line-Staff-relationships) Lateral, Staff,refers to the category of personnel who help the line to work most effectively in accomplishing objectives.it is a secondary business activity that supports the line functions of a business to achieve the objectives.the nature of this function is advisory. the people belonging to this function investigate, research and give advice to their line managers.(http://www.scribd.com/doc/14167293/Line-Staff-relationships) Functional

Typical organization structures are -

Functional:Employees within the functional divisions of an organization tend to perform a specialized set of tasks, for instance the engineering department would be staffed only with software engineers.This is good when the external environment is stable.We also achieve economies of scale. The problem observed here is a lack of horizontal communication between various functions and transfer of messages from one function to another goes from the top of the organization and takes a lot of time.

Divisional: Also called a "product structure", the divisional structure groups each organizational function into a divisions. Each division within a divisional structure contains all the necessary resources and functions within it. Divisions can be categorized from different points of view. There can be made a distinction on geographical basis (an US division and an EU division) or on product/service basis (different products for different customers: households or companies).

Matrix: The matrix structure groups employees by both function and product. This structure can combine the best of both separate structures. A matrix organization frequently uses teams of employees to accomplish work, in order to take advantage of the strengths, as well as make up for the weaknesses, of functional and decentralized forms.

Hybrid : Organizations that have structures that can not be purely categorized in any of the above categories and are a mixture of these structures. These organizations are said to have hybrid strucuture.

Symbol

This is the common symbol for an Organizational Unit (for example, a Logistic Unit).

Symbol.jpg

Also, the typologies of connections are :

  • is composed by
  • control from a professional point of view
  • coordinate from a professional point of view
  • is responsible
  • is hierarchically leading
   Source : http://areadocenti.eco.unicas.it/bolici/Material/BPM2010/BPM%202010_2.pdf

RULES TO WORK ON ARIS

1) An Event can have only one input and one output.The output can only go to a task. The input can only come from a task.

2) A task can have only one input and one output.The output can only go to an event. The input can only come from an event.

TYPES OF CONNECTORS

Connectors.jpg

Behavior of AND, OR and XOR connectors

OR


LogicGates.jpg

<hr /> <p> <strong>Dummies Guide to making a good EPC Diagram:</strong></p> <ol> <li> <em>Golden Rule</em>: An event is always followed by an activity, and vice-versa. This does not necessarily mean that we should go ahead and make the follow deliberately. This can be greatly useful to analyze what output comes out of which actvity and how it&#39;s utilized in the next step. So, make sure you invest enough thought into plotting every step.</li> <li> <em>Input/Output Arrows</em>: Always one! In order to use the concept of multiple inputs or outputs, we need to use connectors. Be careful while choosing the connector, as that can alter the entire sequence of your flow.</li> <li> <em>Detail</em>: Often neglected, the easiest and simply the most important step in drawing an EPC diagram is to dwell into detail. Think of all possible steps before going ahead with one. Take care of defaults, and exit from loops. Handle each case seperately with the help of connectors. The more detailed analysis you make, the more solid your EPC diagram analysis will be.</li> </ol> <p> Following these 3 simple rules can make all the difference between an &quot;OK&quot; EPC diagram, and a &quot;great&quot; EPC diagram!</p> <p> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Credit: A curious student and a candid professor Francesco Bolici</p> <hr />

Business Analysis and Modeling Approach

There are a number of different approaches and methodologies for developing business process models and completing business analysis and reorganization. The different business analysis approaches can be placed into one of two major categories that include:

· Top-down Methodology · Bottom-up Methodology

Top-down Methodology The Top-down Methodology, as its name implies, starts with the development of a new vision and definition of the business approach by the business leaders and senior management. The key feature of the Top-down Methodology is the initial involvement of the business leaders and senior management. Senior management provides the leadership and resources needed for development and implementation of the new business processes.

Figure 2 – Top-down Business Process Methodology presents the major activities for a top-down business process methodology. The top-down approach starts with the business leadership providing the approval and authority for developing and implementing a new business plan. The business leadership also provides: · New goals and objectives of business, · Definition of a new business concept, · Guidelines for designing and implementing the new business processes, · Metrics for monitoring the new business, and · Selection of business improvement teams and procedures. The business staff has the responsibility for completing the detailed design of the new system within the guidelines established by the business leadership team. The detailed definition of the desired new business processes and workflow is often used to define the system requirements for a new information technology system. Additional business process modifications may be required to align the final business processes with the capabilities of the new information system.

Bottom-up Methodology The Bottom-up Methodology, presented in Figure 3 – Bottom-up Business Process Methodology, usually starts with the identification, by the business staff with approval of the management, of opportunities for improving business processes by reviewing the existing business processes. The initiation of the Bottomup Methodology may also be started by the implementation of new information technologies or new regulations or requirements, which may require modifications of the existing business processes. The Bottom-up Methodology must include developing support of senior management for implementing the new business processes. Obtaining senior management support is often a difficult task and will usually require the staff to develop the information and business cases for justifying the implementation new business processes. The Bottom-up Methodology usually includes the development of two business process models. The first model is a definition of the existing business processes and the identification of opportunities for improving the processes. A second business model is developed to define the new desired business processes and workflows.

Reference : http://proceedings.esri.com/library/userconf/proc03/p0537.pdf


TYPE OF JOB YOU CAN HAVE LINKED TO BUSINESS MODELING:

As everyone writes directly on the content of the class I thought it might be nice to have a quick view of what the content of the class can actually be useful for in real life. Below is a job offer, quite complete in my opinion, from the IT Job Board website (http://www.theitjobboard.com/IT-Job/Business-Analyst-SAP-SD-CRM/7787577/en/?source=Search&SearchTerms=%22business+analyst%22+SAP&LocationSearchTerms=&JobTypeFilter=0&DatePostedFilter=0&Page=1&OrderBy=0&CountryId=0&nocache=1268820000)


This job offer is for a Business Analyst for SAP Sales & Distribution Module:

JOB SCOPE

The Business Analyst – SAP SD (/ CRM) develops and supports business processes and procedures associated with SAP mainly within the area of Sales and Distribution. In 2011 CRM will be implemented and the Business analyst will also be expected to support the Customer Relationship Management module. He/she works under mentorship of the Business Analyst Coordinator on new developments, system enhancements, and support and maintenance tasks.

The Business Analyst – SAP SD (/ CRM) coordinates tasks assigned to him/her by the Business Analyst Coordinator. He/she is responsible for all deliverables and assigned tasks and provides day-to-day direction, leadership, and project management skills. Provide timely and successful completion of business projects. Meet project goals and deadlines by fulfilling daily tasks and activities. Organize, facilitate, and administer the flow of communication, schedules, project requests, and milestones, between participating departments and markets. Act as the central point of contact to team members informing and updating them on project progress within assigned area (SD / CRM).

He/she will be expected to fully understand NSE’s business practices and how these practices are supported through NSE software and the NSE Business Services methodology for documentation, training, and project management. The ability to work collaboratively with end users, business management, and all members of the NSE Business Services teams is critical.

The Business Analyst SD (/ CRM) will closely interact with key end-users in the EMEA region and support them in their advanced SAP challenges. At all times (basic) support tasks can be handed over to the helpdesk team after verifying their knowledge on the subject. The Business Analyst is expected to work as 2nd line support within her/his area. Training of helpdesk staff is part of the Business Analyst role.

Travel domestically and internationally to implement, train/receive training, and support processes and initiatives. The Business Analyst is responsible for the EMEA region (Europe, Middle East, Africa & Russia) with a close link to the corporate headquarters in the USA (Utah).

System and process support is global in nature which requires 24 hours by 7 days on-call schedule. Enhance current and future NSE applications functionality by developing new skills and knowledge in the area of Sales and Distribution and later on Customer Relationship Management in SAP.


ESSENTIAL JOB FUNCTIONS

1. Give accurate advice and provide insight on processes involved in business initiatives and project proposals within the SAP SD and (later on) CRM domains. 2. Manage advanced SAP support and maintenance tasks for the EMEA SD and (later on) CRM environments. 3. Work out touch points with other domains (in cooperation with colleague Business Analysts). 4. Personally handle and/or assist the Business Analyst Coordinator in projects with testing, training, implementation and support of NSE systems, with a focus on SD and (later on) CRM. 5. Document business requests, in cooperation with business partners. 6. Document technology solutions, in cooperation with programmer team. 7. Document testing scenarios for programming changes. 8. Involve end-users in the final testing stages. 9. Look for ways to improve sales, reduce costs, improve processes and simplify business initiatives. Make regular suggestions that help ensuring the EMEA markets reach business goals and complete strategies. 10. Investigate, troubleshoot, resolve and escalate all requests related to his/her domain in conjunction with the appropriate IT personnel. 11. Work cooperatively with team members and other groups providing support and accomplishing assigned tasks. 12. Work and follow up with corporate resources on new developments and support issues. 13. Other tasks assigned by management.


SKILLS AND EXPERIENCE REQUIREMENTS

1. Bachelor degree in related field or equivalent experience. 2. Minimum three years of experience in a comparable position. 3. Minimum five years of experience in process development or documentation. 4. Thorough knowledge of SAP SD. 5. Thorough knowledge of SAP SCM. 6. Thorough knowledge of common Web technologies. Experience with content management systems is considered a plus.

7. Thorough knowledge of desktop software such as MS Application Suite, Visio, email and other applicable software. 8. Knowledge of applicable databases preferred such as 2021 Interactive, Data Warehouse, CRED, Employee database and CREW. 9. Customer relations (internal or external) experience preferred. 10. Excellent English written and verbal communication skills. 11. Ability to assist with and/or conduct end-user process and functionality training. 12. Ability to interact with end-users and management for day-to-day business communication. 13. Ability to plan and work in a team environment. 14. Possess excellent organizational skills and the ability to mentor other business analysts in this skill. 15. Analytical, problem solving and resolution skills. 16. Ability to identify and deliver process and system improvements through detailed analysis. 17. Ability to meet or exceed expectations and deadlines while performing multiple tasks under minimal supervision.

QUALIFICATIONS

1. Bachelor’s degree or comparable professional experience required. 2. Minimum 3 years working experience in similar position required. 3. Thorough knowledge of SAP SD required. 4. Solid foundation in SAP CRM is a very important asset. 5. Knowledge of additional SAP modules are considered important assets. 6. Experienced user of standard IT software (MS office...) 7. Excellent English communication skills, both written and verbal. 8. Ability to interact with end-users and management for day-to-day business communication. 9. Team player. 10. Attention to details required. 11. Business minded, understanding our business and the role our analysis support and reports play in managing our business. 12. Can manage multiple tasks and responsibilities. 13. Able to coordinate time and priorities and handle scheduling conflicts under medium supervision. 14. Analytical, problem solving and resolution skills required. 15. Teaching and training skills and experience are valuable assets. 16. Willingness to work flexible hours as appropriate. 17. Willingness to travel within EMEA and overseas.


Hello everybody! In this class we need to use the system ARIS. I found some series of videos in youtube that are very useful to understand how ARIS works with SAP. I leave the link here of this video http://www.youtube.com/watch?v=EBVDee7nCeE Hope its usefull to everyone!


Hi Im taking an extensive course of Business Model, and here are some notes that i think might be useful

A business model spells out how a company organizes to make money. It draws on a multitude of subjects including entrepeneurship, strategy, finance, marketing and operations. In the most basic sense, a business model is the method of doing business by which a company can sustain itself-that is generate revenues. A business model is the consequence of choices ( in terms of resources and competences to be marketed, value propositions, and internal and external organization) of a firm to sustain itself. BM is a concept that is now crucial for entrepeneurship and that constitute a very promising perspective of strategic management, based on a pragmatic innovative approach.

There is also a webpage that you can visit to find out more about business models www.businessmodelcommunity.com , this page was created by my professor and its quite interesting




The Top Challenges Faced by Business Analysts

Yes, it came in our exam, and it's a very important discussion all of us (especially the ones planning to venture into this field) should know. Here's what I stumbled upon while looking online.

Clip image002 013.png

<p><strong>Challenge #1</strong></p> – Lack of Clarity in the Scope of the Business Functions In the translation of the customer’s needs into the delivered product or service, vague requirements may not be properly understood. The subsequent design documents may, therefore, be poorly defined and documented. Business Analysts recognize their role as one of defining the business solution boundaries– i.e., ensure the project scope definition aligns with the proposed solution to support the business needs. This is then translated into the Business Requirements Document. This BRD is approved and signed off by the customer as an agreement on the requirements. Additional challenges are:

   * Requirements that have not been well documented due to assumptions being made that the requirement is obvious.
   * That detailed documentation is not required because the solution is temporary – i.e., it will work for now.

The challenge here is for the Business Analyst to fully integrate the costs associated with satisfying the requirements with the investment to clarify the Business Function Scope right up front.

Organizational issues add another layer of complexity in the BA’s ability to manage requirements. The pace of change in organizations is indicative of market pressures. Senior management pushes project teams to deliver projects quickly and more efficiently. Changing technology and the complexity of projects are other ongoing challenges.

The BA must work with the Project Manager to reduce the impact of these challenges during the Business Requirements Analysis process. An effective way to do so is to capture challenges and document them in the Project Scope Statement. The resulting document will articulate the full scope requirements as reflected in the BRD and there will be a much greater understanding and clarity of the project’s scope among all stakeholders and business functions.

<p><strong>Challenge #2</strong></p> – Business Requirements Not Well-Managed The customer may not fully understand all of the project’s requirements at the beginning of the project. The customer may use imprecise language such as “ I guess, I want” or “Maybe we should consider” or may not fully articulate what is required. Requirements may be vague, incomplete and may not be specific enough to be measurable. This ambiguity often leads to products or services delivered to the customer that:

   * May be technically sound but fall short by not improving the business process.
   * Does not meet customer expectations
   * Results in increased cost—does not address the needs, so there will be another initiative, and another. (Misunderstandings regarding requirements must be revealed and cleared up as early as possible because the cost of fixing them goes up exponentially as the project progresses.)
   * Result in credibility erosion of the team or the organization.

Requirements can be better managed by:

   * Investing enough time at the beginning of the project to ensure the requirements are understood and documented, in a Business Requirements Document (BRD). The customer group must then sign off the BRD.
   * Creating a checklist template to collect customer requirements. This approach helps the requirements gathering process and reduces the possibility of things being missed during the interview process.
   * Ensuring that the “requirements gathering process” is separated from the “design process.” Understanding the requirements is not the same as determining how to design a solution to address the requirements. The “design process” comes after the requirements gathering process.
   * Involving a customer representative from all of the affected departments or business functions. This involvement should exist throughout the project to increase understanding of the project’s goal and ensure any changes to the requirements are in the best interest of the product or service design requirements.May be technically sound but fall short by not improving the business process.

<p><strong>Challenge #3</strong></p> – Conflict Between Business Groups The BA role can often be referred to as: Systems Analyst, User Support Analyst, Business Systems Specialist, Project Manager, Business Leader, IT Specialist, etc. The BA’s key responsibility is to perform a sequence of analysis techniques in order to obtain customer requirements. For a BA to be effective, the reporting relationships should be clear across various levels within the organization. For example, the BA may be working with administrative staff, examining their requirements for increased productivity and then later in the day working with senior management, analyzing their need for more detailed reports. The BA’s primary role is to elicit, structure, validate and communicate business and user requirements. Essentially, the BA role “bridges the gap” between the customer/user community (high level requirements) and the technical community (technical requirements). As a result, customer acceptance of a final product or service is highly dependant on the BA’s ability to translate those needs into a proposed business solution. The BA must remain sensitive to all customer/user needs and not judge these needs. It therefore becomes apparent that a BA must establish rapport and trust with the customer and with the various business units directly impacted by the project.

<p><strong>Challenge #4</strong></p> – Not Bringing in Business Analysts in Sufficient Time It is important that the roles of Business Analyst and Project Manager are recognized as separate and distinct. However, their ability to work effectively as a team for the sole purpose of ensuring customer satisfaction brings about overall project success. Project Teams work within the framework of a Project Management process, using a methodology for managing projects. This process ultimately defines how the proposed solution will be delivered. The deliverables from the Business Requirements Document are further defined in the Project Scope Statement document. This is approved by the Sponsor and then used for project planning purposes. The Project Team breaks down the deliverables into tasks/activities and documents them into a Work Breakdown Structure (WBS). For this to all work in harmony, the Business Analyst must be brought onto the project team at the very beginning of the project and remain as an integral part of the team until the project is completed and closed. During the Business Requirement Analysis process the BA will help develop the scope statement by identifying the customer requirements. The requirements may have already been identified in a BRD. Then the BA must remain with the team, ensuring that the ever-changing needs of customers are heard and managed. Conclusion

Since the role of Business Analysts is an invaluable asset, there is a real need for organizations to invest in training and development of this role. The results of the survey strongly suggest the need to train Business Analysts on the Business Requirements Analysis Process. This includes how to:

   * Determine, collect, analyze and document the business requirements.
   * Manage on-going stakeholder expectations and business requirements changes.

The Business Analyst role is important for most projects. Business Analysts ensure that the stakeholder needs are identified and fully met throughout the project. This translates into more successful projects because their customer’s expectations are realized. The need for training BAs led BIA to develop and offer a full certificate curriculum for Business Analysts that provides the basics plus more advanced and soft skills training including: Communications Skills, Project Management and Business Process Improvement as well Testing Methodologies for Business Analysts.



Hello :) I found ways to improve a process. I hope it will be helpful to improve your business process modeling.

Areas of Process Innovation When I’m looking at ways to improve a process, I always go back to a book on process innovation written in 1992 by Tom Davenport. Tom Davenport is a professor at Babson College. He writes extensively about process innovation and lately he’s been involved in the Enterprise 2.0 stuff. But I always go back to this book. It isn’t about the technology. It’s about the different ways you can improve your processes. He lists nine different areas in which process innovation can occur. Automational – eliminating human labor b • y automating things. • Informational – capturing process information to understand what’s going on in the process • Sequential – changing the sequence of steps or allowing parallel processes • Tracking – to monitor process status and participants • Analytical – improving the analysis of information, decision making, rules • Geographical – coordinating processes across distances • Integrative – looking at integration between human-facing tasks and system processes • Intellectual – capturing and distributing intellectual assets • Disintermediating – eliminating intermediaries from the process, cutting out the middle man

In my experience, there are three places where you can get the most bang for your buck:

• Automational – improving process efficiency, usually through automating processes • Geographical – looking at different locations, including things like outsourcing parts of your process • Disintermediating – cutting out the middle man, through things like customer selfservice

Let’s look at how each of these three areas can impact process modeling.

IMPROVE EFFICIENCIES

Automational is about improving efficiencies. This is standard business process reengineering. You’re going to automate whatever work steps you can, integrate data between systems, provide monitoring so you can keep an eye on processes as they go BUSINESS PROCESS MODELING 17 along, and gather statistics you can use for analysis. Being able to automate manual work is a place where you’ll see a huge improvement in efficiency. How can you take advantage of a BPM system to improve efficiencies in your organization? Those are some of the things you want to be thinking about when you’re modeling processes.

CUT OUT THE MIDDLE MAN

How can you cut out the middle man? Can you provide some sort of self-service so a customer can come to your website and initiate a process instead of calling or sending a document that somebody keys in? Can you provide visibility to the customer? For example, if they’re applying for insurance coverage, can you provide them with visibility into the progress of their application on the website instead of having them call in and take up the time of customer service rep to find out if a document has been received? There are ways you can disintermediate inside and outside your organization, usually by allowing a customer or a business partner to work directly with your system rather than having them go through someone else to access information or to kick off a process.

LOCATION, LOCATION, LOCATION

Once you are using an automated system to route information, you have flexibility about where work occurs. You can look at routing information to different business units when overloads happen. You can identify redundant processes going on in different business units and look at bringing them together into a single process. You can look at doing remote work. Can you reduce capital costs by having people do the same work from their homes instead of sitting in the office? These are the types of things you want to look at when you’re modeling. Does the work require interaction with a lot of other people? Is it heads-down transactional type of work? Can it be done remotely – at home, in another office, or by outsourcing parts of the business process?

Reference : http://www.tibco.com/multimedia/business-process-modelling_tcm8-2404.pdf


Toyota and it's ERP Model

About Toyota

Toyota Motor Corporation commonly known simply as Toyota, is a multinational corporation headquartered in Japan. At its peak, Toyota employed approximately 320,000 people worldwide. It is the world's largest automaker by sales. The company was founded by Kiichiro Toyoda in 1937 as a spinoff from his father's company Toyota Industries to create automobiles. Three years earlier, in 1934, while still a department of Toyota Industries, it created its first product, the Type A engine, and, in 1936, its first passenger car, the Toyota AA. Toyota also owns and operates Lexus and Scion brands and has a majority shareholding stake in Daihatsu and Hino Motors, and minority shareholdings in Fuji Heavy Industries, Isuzu Motors, Yamaha Motors, and Mitsubishi Aircraft Corporation. The company includes 522 subsidiaries.

Reference : Toyota world.com

Company's ERP Model Change

Problem:

Each year, Toyota offers its worldwide marketing subsidiaries a range of vehicles with some 20 million configuration options. Each subsidiary can additionally market a range of locally fitted options ranging from specialist upholstery and trim through to in-car entertainment and navigation systems. From the options available, Toyota GB must create the range which is most likely to succeed in the UK market. Toyota GB provides a full range of service options, including customisation, which must be supported by a production-like workflow, and the supply of spare parts across the full lifecycle of each model. To operate successfully, the company must be able to understand trends within the marketplace and respond swiftly to opportunities and challenges. The objective was therefore to develop systems which would support the decision-making process by integrating market intelligence, sales (and lost sales) information and service requirements with brand development, range definition and pricing. The complexity is in the sheer number of permutations available.

Such an objective cannot be attained overnight. It is not just a matter of replacing systems; whilst that is not simple, the biggest challenge was in managing the business change which accompanied it.
To meet these challenges, Toyota developed a progressive approach which would allow each major component to be specified, implemented, verified and adopted before moving on to the next. This supported the need for a sound business change strategy, but had significant ramifications for the implementation of the systems themselves as each new or replaced business application had to be absorbed by the user community whilst its predecessor and supporting legacy applications remained operational behind the scenes.  It is vitally important that such an approach is driven by the business architecture so that dependencies between components are recognised by the sequence of implementation. At the core of the Toyota business architecture is the product lifecycle, around which all business critical systems revolve. The development of a product model and support for Product Lifecycle Management (PLM) was therefore the first priority. Having demonstrated the capabilities of both opentaps and its team, 1Tech were engaged to advise on and implement Product Lifecycle Management, working with in-house legacy system teams to develop a homogeneous solution.


Solution:

- Provide Product Lifecycle Management expertise to ensure that the architectural approach will stand the test of time. - Develop a Product Model which is sufficiently flexible to support not only today’s needs but also undefined future product strategies and the potential for ultimate integration with external systems, whether in-house or elsewhere in the supply chain. - Demonstrate the suitability of opentaps as the long term strategic solution in terms of functionality, architecture and development environment. - Understand user requirements in detail and define a software architecture to support them by using standard opentaps entities and services with extensions and customisations where necessary. - Design a user experience model which is intuitive and easy to use despite the underlying complexity of product configuration. - Accurately estimate the costs and effort required to achieve the solution. - Provide project management and architectural expertise to ensure the delivery of a sound solution within budgeted costs and timescales.


Result:

- Tracing of a ‘concrete' product model based on vehicles, engines, colour, trim etc. to a new, abstract, ISO-compliant, recursive product-part structure with the ability to specify configuration ‘rules'. - Construction of a software architecture fully mapped to Toyota's business architecture and legacy data model using UML models. - Construction of a prototype to prove all systems interfaces within the first two weeks of the project. - Implementation of the Product Model in opentaps, using and extending core opentaps entities.

Reference: http://www.1tech.eu

A Comparison of Event-driven Process Chains and UML Activity Diagram for Denoting Business Processes:

The comparison between EPC and UML activity diagrams shows that even if both methods were developed in different contexts, they are usable for modeling business processes. However as we can see from the comparison, the EPC covers more aspects such as a detailed description of business organization units together with their respective functions as well as information and material resources used in each function. These essential relationships are not explicitly shown in activity diagrams. Instead we need to derive from other elements such as object flow or even we need to model these aspects in other diagrams of the UML. However the EPC is sometimes imprecise or even ambiguous when we analyze its process, but this problem has been addressed by utilizing transformation approach to Petri net which can be analyzed to prove the correctness of the EPC.

Based on the comparison we can also see that there are a lot of concepts which are common to both EPC and activity diagrams. These common concepts make it possible to translate both diagrams back and forth between the different notations. Nevertheless there are also some basic different concepts which has no correspondence in the other one. This raises problems such as information loss when translating from EPC to activity diagrams due to less aspects of activity diagrams and loss of details such as iteration and object identity when translating from activity diagrams to EPC. Because of the problems of translating between EPC and activity diagram the two approaches - the object-oriented paradigm which is closer to information technology and the process-oriented one which is closer to business aspects (organization, information and material, function) – need to be brought closer. A semi-formal proposed solution for this is the object-oriented event-driven process chain (EPC). This integrated approach is a promising candidate for solving these aspects in one unified method.

<tt>Source:</tt>Project Work submitted by Ferdian. Information and Communication Systems Masters Program [ferdian@tu-harburg.de]


THIS MIGHT BE USEFUL TO YOU....!!!!

For those interested in understanding and practicing EPC please download a .ppt file form the following link:

<tt>miha.ef.uni-lj.si/_dokumenti3plus2/191209/01-EPCs.ppt</tt>


The correctness of a BPM is critical for the automation of business processes. It should be possible to eliminate errors in a BPM at specification time. Simulation and model checking are two possible techniques that can be used to identify errors. In order to apply these techniques, it is necessary to translate the BPM into the input language of a model checker or simulation tool. Several authors have published algorithms for translating high-level descriptions of BPMs into something that can be understood by model-checkers or simulation tools(usually Petri nets or finite-state automata). For example, the Petri-net based toolWoflan can interface with several workflow management systems and check important properties of workflow models.Matousek translates business process models defined in the XPDL language into the input language of the SPIN model checker. UML activity diagrams are analyzed by Eshuis who uses the model checker NuSMV to verify properties and by Barjis et al. who transform them into a simulation model. Van Dongen et al.Use reduction rules and Petri-Net analysis for verifying event driven process chain-models. All these authors use algorithms for translating BPMs into Petri nets or finite-state automata. These algorithms are intended to translate every BPM that is syntactically correct. In contrast to this, we suggest to check restrictions for ”good modeling style” before starting the translation and disallow models which failed the tests.

Reference:How Style Checking Can Improve Business Process Models(Volker Gruhn and Ralf Laue)


THIS IS AN EXAMPLE OF "Entity Relationship Modelling"; WITH THE DESCRIPTION OF ALL COMPONENTS:

Use Entity-Relationship Modelling to:

• clearly communicate complex data relationships in an organization,

• model the organization and its operations in terms of data types or data groupings that the organization handles and the ways in which these are related,

• represent the logical "what" of the organization's use of data but not the physical "how,"

• obtain detailed data requirements to design a database.

Method

An Entity-Relationship (E-R) Diagram (or E-R Model) visually depicts an organization's entities, the entities' relationships to each other, and the business rules (i.e., cardinality and dependency) associated with the relationships. The E-R Diagram is the picture used to represent and test the knowledge obtained from Data Modelling.

The output of Data Modelling includes:

• E-R Diagram, • descriptions of entities and their relationships, • attributes and their descriptions, • edit rules, • business rules, • volumetrics.

Components of an Entity-Relationship Diagram:

Entities

Attributes

Relationships

Documenting Entities, Attributes, and Relationships

Notation on Entity-Relationship Models

Tips and Hints

Automated CASE tools allow the analyst to create and maintain re-usable and accurate Entity-Relationship Diagrams.

Example

The example Entity-Relationship Diagram depicts some of the entities and their relationships for a university.

 LINK OF WEB SITE:  http://it.toolbox.com/blogs/enterprise-solutions/entityrelationship-modelling-14336


References

Chen, Peter The Entity-Relationship Approach to Logical Database Design. Wellesley: QED Information Sciences Inc.

Martin, James Information Engineering: Book II: Planning and Analysis. Englewood Cliffs: Prentice-Hall.

Shlaer, Sally, and Mellor, Stephen J. Object-Oriented Systems Analysis. Englewood Cliffs: Prentice-Hall.

Event-driven Process Chains - Theory Section General Information Event driven process chains are a method to visualize succeeding events and functions by which the logical timing of a business process is shown. Consequently, event driven process chains are the description method for business processes. Event driven therefore is equivalent to describing the dynamic part of a business process. This means that it is stated in which way and at what time a reaction that causes a change should happen. The static data structure, i.e. the objects involved and their inter-relationship would be modelled using entity relationship models. In the following subsections a descriptive method will be explained and used. Generally, it is very important to decide how detailed a description of a business process should be, as possibilities range from very raw models up to workable functions.

Concerning the practical utilization, it should be mentioned that event-driven process chains play an important role in modelling concepts for business engineering and customizing of SAP R/3 systems Event / Function The ability to distinguish between events and functions is of great importance: Refernce: http://erp.wu-wien.ac.at/eew/epc_theory/epc.php

EVENTS AND TASKS

I, for one, find it a bit of a "task"when it comes to figuring out how to keep switching between events and tasks without coming across as redundant. The models that we had to deal with till now were flexible in terms of allowing us to string together a bunch of tasks together, and being used to that model alternating to an event here does throw us off-track.

Like for example, my group is working on the order entry process in a pizzeria. And when we sat down to map out the EPC for it, we were wondering if we could say Combine ingredients for pizza (task) - pizza ready for baking (event) - bake pizza (task) - pizza baked (event) - put in box (task) - pizza in box (event). I'm exaggerating here, but still confusions pretty much ran along those lines! However, figured out what we think is a feasible chart and have put it together.

Since we're sitting down to do an exam today with a considerable bit of our marks riding on EPC and managing time, I went through a couple of sites to find examples or simulated EPC models so that it would give me an idea on how to go about making sure we were on the right track. One of these had a solution for a problem very similar to the one presented in class -- the one about vehicles and component, except this one is for customers and cars, then there's also one for receiving goods. (The screenshots of the same are small, but can be magnified.)

http://www.ids-scheer.com/en/ARIS/ARIS_Modeling_Standards/EPC/79740.html?mod_dcrt%5Bcaching%5D=293778326

Follow the navigation bar for other ARIS-related questions you may want to look into. And all the best for the exam.


What is common between BPM and Wokflow

The need to automate core processes to eliminate bottlenecks, cut out redundancies, and achieve operational efficiency.

When automating a business process, it is crucial to test your process in a virtual environment to ensure that the activities and tasks you are automating are as efficient as possible and free of bottlenecks. This where a Business Process Management Suite can enhance your workflow automation initiatives as it gives you the ability to investigate and test your processes for inefficiencies. Unfortunately, this is not possible with a simple workflow automation tool.

Consider a case in which you use a workflow automation tool, which is geared specifically to automate and manage business processes. If you do not test or even model your automated business process in a virtual environment, all of the work you do to get to the process automation stage is at serious risk. You will automate a potentially inefficient, untested, and unproven process. The end result of this type of approach is that the bottlenecks in your business processes will be much more of a problem than they were before.

In a Business Process Management Suite (BPMS), you not only have the ability to automate and manage your business processes, but you also can leverage two other vital concepts: modeling and optimization. Modeling allows you to test your process in a virtual environment first (before the automation stage). By mapping out your process, you will be able to determine bottlenecks, inefficiencies, and high resource usage situations in your process. It is a best practice to understand all of the risks associated with the project. In terms of Process Improvement, this is where modeling makes the most sense. By utilizing the modeling capabilities of a BPMS, you will have the ability to measure process effectiveness and identify potential process bottlenecks BEFORE investing deeply in making the automated process “live.” Identifying and resolving these situations in your process first during the modeling stage, and then proceeding with process automation, ensures all the work you have performed to get your process to the automation stage will contribute to your success.

All the information was from the following link, i recommend everyone goes to this website.

Reference http://www.bpmvsworkflow.com/bpm-vs-workflow.html

THE difference between BPM and Workflow!

Workflow is just a subset of BPM. Here are some of the differences between the two

1) Focus: Workflow-> focus is on Task Routing. BPM-> focus is on Process Life Cycle Management.

2) Integration: Workflow-> Tight Coupling between Integrated Applications using custom API supplied by workflow vendor and Third party products. BPM->EAI using standard adaptors and B2B integration using Open standards like HTTP, XML and Web Services.

3) Scope: Workflow -> Application/Department specific. BPM-> Enterprise wide and across the value chain.

4) Process Modeling: Workflow ->Limited. BPM->Advanced Process Modeling with essential features like Collaborative Process Design and process Simulation

5) Reporting: Workflow->Basic Reporting after the Fact. BPM->Process metric reports and dashboard views.

6) Exception management: Workflow->very limited. BPM->Live process update using In-flight process and data update.And also side-by-side process version features. BPM truly creates the agile event driven enterprise business people have been dreaming of. But caution- implementing BPMS is touch and cannot be managed as a typical IT project.

http://it.toolbox.com/blogs/thinking-out-loud/pay-attention-the-difference-between-bpm-and-workflow-2875

ENTITY RELATIONSHIP MODEL:

The ER model is a conceptual data model that views the real world as entities and their relationships.

Advantages • Conceptual simplicity • Visual representation • Effective communication • Integration with the relational database model

Disadvantages • Limited constraint representation • Limited relationship representation • No representation of data manipulation • Loss of information

http://publish.uwo.ca/~craven/558/558era.htm


ER diagramming tools

There are many ER diagramming tools. Some of the proprietary ER diagramming tools are ARIS, Avolution, dbForge Studio for MySQL, DeZign for Databases, ER/Studio, Devgems Data Modeler, ERwin, MEGA International, OmniGraffle, Oracle Designer, PowerDesigner, Rational Rose, Sparx Enterprise Architect, SQLyog, System Architect, Toad Data Modeler, SQL Maestro, Microsoft Visio, Visible Analyst,and Visual Paradigm. A freeware ER tool that can generate database and application layer code (webservices) is the RISE Editor.

Some free software ER diagramming tools that can interpret and generate ER models, SQL and do database analysis are StarUML, and MySQL Workbench.

Some free software diagram tools just draw the shapes without having any knowledge of what they mean, nor do they generate SQL. These include Kivio and Dia. DIA diagrams, however, can be translated with tedia2sql. (source : http://en.wikipedia.org/wiki/Entity-relationship_model)


video for Logic data modeling

http://www.youtube.com/watch?v=q1GaaGHHAqM


R Model to Relational Model Maping http://www.youtube.com/watch?v=qRqzmAwmJwY&feature=related

source : http://www.youtube.com/watch?v=q1GaaGHHAqM

        http://www.youtube.com/watch?v=qRqzmAwmJwY&feature=related

8th INTERNATIONAL CONFERENCE ON BUSINESS PROCESS MANAGEMENGT

PM 2010 is the eighth conference in a series that provides the most distinguished specialized forum for researchers and practitioners in business process management (BPM). The conference has a record of attracting innovative research of highest quality related to all aspects of business process management including theory, frameworks, methods, techniques, architectures, and empirical findings.

In addition to the main research track, BPM 2010 will include an industrial and an educational papers track. The conference encourages practitioners to submit experience and application papers reporting on innovative implementations and applications of Business Process Management with a particular focus on their impact on information technology use and business practice.

BPM 2010 will be held at the Stevens Institute of Technology, in Hoboken, NJ, USA from September 13-16, 2010

http://www.bpm2010.org/registration/

====================================================================

BPM -Business Process Modeling:-

The entire course of Business Process Modeling enriched our knowledge about Organisation Structure, Entity Relationship model and Event driven Process (EPC) modeling.After the course we were successfully able to map different process using the EPC.Let me explain in detail what we learnt about the above specified topics.

Business Process Modeling: BPM is the pictorial representation of the sequence of activities.

Organisation Chart:

Organisation chart is very important for any company.We studied the different types of charts.The 3 types of division being Functional,Divisional and Matrix Chart. Functions are classified based on Similarities of the tasks.

Divisional structure is mainly based on the geographic divisions.

In Matrix structure it is possible to link all the people in an organisation chart.

E-R: Entity Relationships

The last step in creating entity relationship diagrams is the specification of the relationships among the entities. Just as every object in the real world has some kind of relationship to one or more objects so too the entities in a database are related to other entities. The nature of relationships between entities is usually implied in the very definition of the entity. Despite the obviousness of these relationships, it is important to review all entities and specify how they relate to each other. There are at least three types of relationships possible:

One to one, where one entity corresponds to exactly another entity. For example, a table about patient's death has a one to one relationship with the table "Person."

One to many, where one instance of one entity can be repeatedly used by another. For example the look up table Gender may be repeatedly used in the table "Patient."

Many to many where one instance of both entities can be repeatedly used by another. For example, tables "Patient" and "Clinician" have many to many relationships as a clinician may have many patient and a patient may have many clinicians.

Sometimes, the relationship between two entities is not clear. The most common cause is that a third entity is missing. This often occurs when two entity have many to many relationship. For example, the entity Patient and the entity Clinician have, as mentioned earlier, many to many relationship. It is difficult to show these relationships inside a database in a way that can easily be manipulated. An alternative is to show a new table that links these two tables to each other and has one to many relationship to each of the tables. For example, we can make a new table called Visit. Within a visit a patients is diagnosed. Both the patients and the clinicians identity are kept in the visit table. The Visit table has one to many relationship with either patient or clinician table. Sometimes, as we specify the relationships among entities, a new entity must be defined.

Linkages between entities are part of the business rules that databases should capture. In our example, the business rule for the linkage between a Clinician and a Patient is that a clinician may have zero, one, or, more patients. The business rule for the linkage between the Patient and the Clinician is that a patient may have one, or, more clinicians. Note that these are the business rules that someone may have specified. In a different information system someone could decide that a patient can only have one clinician at a time, or that the number of clinicians dealing with a patient must always be 3, or some other similar rule. The important point is that entities can be linked to each other, and that the nature of the linkage is part of the business rules of the system.

To make tracking of information simpler, many modeling languages have standardized how entities and relationships are shown. A common approach is to show entities as boxes with their names as their labels. Inside the entity box the fields are listed. In the Figure below two entities are shown: the Patient and the Clinician entities.


The figure also shows that the two entities are related to each other. The graphical representation of data linkages depends on the modeling language one uses. In IDEF1X, a modeling language, one can represent many to many relationships by using a line with a large black dot at both ends. This icon means that there is a many-to-many linkage between the entities connected. If there is a one to many relationship the large dot is out in the side of entity with many instances.

In Access, a database, The line shows the relationship between the two tables and the shared field shows the nature of the relationship. The arrow shows if the relationship is one to many, with the many side shown by the direction of the arrow.

As with the specification of the entities discussed at the beginning of this lecture, the documentation of the relationships is part of the logical information model. The format for documenting the linkages among entities includes the name of both entities, the verb phrase that describes the semantics of the linkage and the cardinality of the linkage (i.e. whether one to one, one to many or many to many). The statement of the cardinality can be made plain English. All relationships must be documented before proceeding to the physical design of the database.


Reference: http://gunston.gmu.edu/709/datamodelingerdiagram.asp

Entity Relationship is very important in designing a data base.


The followings needs to be done in designing an ER

1.Find the different entities

2.Find out the different attributes for each entity

3.Find out the key attribute of every entity

4.Define the cardinality between the different entities

5.Draw the follow tables

There are 3 different types of entities

a. 1:1 Eg: DNA of human beings

b N:1 Eg: Students and thier ID cards

c N:M Eg: Courses and Students


EPC- Event Driven Process:

It is a pictorial representation of chain of events and activities of logical sequence.We use different types of Gates as connectors in the EPC

The 3 types of gates are

1.OR Gate

2.And Gate

3.XOR Gate

Eg:

1.In the class we started with the process of making a sandwich.Every team cam up with different logical sequences.In real time, Business Analysts conduct interviews to determine the process flows and then mapped into EPC.

2.We also created ER model for the courses and students of IESEG.We created tables and follow tables to retrieve data.All these class works helped us to understand EPC and ER in better ways.


We also studied about "Relationships among concepts"

There are 2 kinds of relations:

Vertical Relations: Hierarchical relation between the concepts

Horizontal Relations: Links two or more concepts on the same hierarchical level





http://www.scribd.com/doc/22375495/Business-Process-Modelling-Why-and-How http://www.scribd.com/doc/7321900/Business-Process-Modelling

Some of the resources I found while searching around on the net.Hope you find them helpful


Also would like to ad my 2 cents on Gap Analysis: It is an analysis tool which serves the purpose of identifying the gap between the current performance and the desiered one.Also in the process we include the identification of the ways to bridge the gap.

Requirements

The most fundamental requirement of gap analysis is consistent, proactive and effective management throughout the planning, implementation and transformation stages of gap analysis. The planning stage and the extensive research required during this stage is the foundation of successful gap analysis. The research needs to focus on both the internal operations of the organization as well as the external business environment. This research provides the necessary knowledge about the current state of internal operations as well as information about aspects, such as market trends, consumer demands and competition, through the process of benchmarking. Benchmarking is a useful business tool used to compare companies similar in nature that provides information and guidelines to what is a realistic desired state.

Types

The two most popular types of gap analysis are product gap and market usage gap. Product gap analysis concentrates on internal improvements and growth limitations due to certain product or service characteristics. Market usage gap analysis focuses on the possibilities of growth by evaluating and comparing the current market size to the potential market size.

References: Ehow.com


An Example:

The Gap Analysis Concept The Gap Analysis Program (GAP) is a nation-wide program currently administered by the Biological Resources Division of the US Geological Survey (BRD-USGS; formerly the National Biological Service [NBS]). The overall goal of Gap Analysis is to identify elements of biodiversity that lack adequate representation in the nation's network of reserves (i.e., areas managed primarily for the protection of biodiversity). Gap Analysis is a coarse-filter approach to biodiversity protection. It provides an overview of the distribution and conservation status of several components of biodiversity, with particular emphasis on vegetation and terrestrial vertebrates. Digital map overlays in a Geographic Information System (GIS) are used to identify vegetation types, individual species, and species-rich areas that are unrepresented or underrepresented in existing biodiversity management areas. Gap Analysis functions as a preliminary step to more detailed studies needed to establish actual boundaries for potential additions to the existing network of reserves.

The primary filter in Gap Analysis is vegetation type (defined by the Washington Gap Analysis Project as the composite of actual vegetation, vegetation zone, and ecoregion). Vegetation types are mapped and their conservation status evaluated based on representation on biodiversity management areas, conversion to human-dominated landscapes, and spatial context. Vegetation is used as the primary filter in Gap Analysis because vegetation patterns are determinants of overall biodiversity patterns (Levin 1981, Noss 1990, Franklin 1993). It is impractical to map the distributions of all plants and animals, but Gap Analysis makes the assumption that if all vegetation types are adequately represented in biodiversity management areas, then most plant and animal species will also be adequately represented. The second major Gap Analysis filter is composed of information on the distribution of individual species. This filter can be used to identify individual species that lack adequate protection and, when individual species maps are overlaid, areas of high species richness. In most states, including Washington, vertebrates are the only taxa mapped because there is relatively little information available for other taxa, and because vertebrates currently command the most attention in conservation issues.

http://wdfw.wa.gov/wlm/gap/dataprod.htm

Site Toolbox:

Personal tools
GNU Free Documentation License 1.2
This page was last modified on 24 November 2010, at 10:03.
Disclaimers - About BluWiki