Identification process refers to those management activities that aim to systematically define th...

Get Started. It's Free
or sign up with your email address
Rocket clouds
Identification process refers to those management activities that aim to systematically define the set of business processes of an organization and establish clear criteria for selecting specific processes for improvement by Mind Map: Identification process refers to those management activities that aim to systematically define the set of business processes of an organization and establish clear  criteria for selecting specific processes for improvement

1. The organizations has important procees that must be analyzed

1.1. Few has the resources to analyze the requirements that can be automated

1.2. The others can´t, therefore the requirements can´t be analyze

2. identify process is important in a organization in a economic way, but is not great for all.

2.1. The automatization of process can result in a save of money

2.2. But also in less options to work for the people and that is bad for the economy for the country.

3. How can I decide what is or not a process in my organization and if is important or not?

3.1. Is it a process at all?

3.1.1. Not everything we can observe in a business context is a process. A department, for example, is not a process. Neither is a manager or email. For any proper process it must be possible to identify the main action, which is applied to a category of cases. For example, we can identify the business process approve—leave requests

3.2. Can the process be controlled?

3.2.1. Something that is ongoing or active may resemble a process, while it is not. A proper way of looking at business processes is to see them as a repetitive series of events and activities to execute individually observable cases.

3.3. Is the process important enough to manage?

3.3.1. Some processes do not even reach the minimum threshold to be considered as such

3.4. Is the scope of the process not too big?

3.4.1. Care should be taken that the activities that are considered to be within the scope of the process really contribute to its purpose

3.5. Is the scope of the process not too small?

3.5.1. One can sometimes come across micro business processes, which are not worth managing as processes at all.

4. Process Architecture: The aim of a process architecture is to provide a representation of the processes that exist in an organization. The definition of a process architecture has to face the complexity of the whole organization.

4.1. First differentiate categories of processes.

4.2. Second, we describe different relationships between processes that are important for a process architecture.

4.3. Third, we present a method for defining the process landscape as a top-level representation of the process architecture.

5. Process Categories: If an organization is at the very start of becoming a process-centered organization, the first difficult task it faces is to come up with a meaningful enumeration of its existing processes

5.1. Core processes

5.1.1. Cover the essential value creation of a company, that is the production of goods and services for which customers pay. These include design and development, manufacturing, marketing and sales, delivery, after-sales, and direct procurement

5.2. Support processes

5.2.1. Enable the execution of these core processes. These include indirect procurement (i.e., sourcing of hardware, furniture, stationery, etc.), human resource management, information technology management, accounting, financial management, and legal services.

5.3. Management processes

5.3.1. Provide directions, rules, and practices for the core and support processes. These include strategic planning, budgeting, compliance and risk management, as well as investors, suppliers, and partners management.

6. Relationships Between Processes For a process architecture: we can distinguish three types of relationships between processes: sequence, decomposition, and specialization.

6.1. Sequence

6.1.1. This relationship describes that there is a logical sequence between two processes. Sequence is also referred to as a horizontal relationship.

6.2. Decomposition

6.2.1. This relationship describes that there is a decomposition in which one specific process is described in more detail in one or more subprocesses

6.3. Specialization

6.3.1. This relationship describes that there exist several variants of a generic process. For instance, there might be a generic process for handling job applications in a multi-national company.

7. Reuse of Reference Models

7.1. Often, process analysts find it difficult to identify processes of an organization and the levels of a process architecture. It might be helpful to use reference models as an aid.

8. Process Landscape Model

8.1. The model of the process architecture that covers the processes on Level 1 is known as the process landscape model or simply the process architecture for Level 1. It shows the core processes on a very abstract level. This process divides in:

8.1.1. Clarify terminology

8.1.1.1. The key terms to be used in the process landscape model should be defined. Often, there exists already an organizational glossary, which can be used as a reference.

8.1.2. Identify end-to-end processes

8.1.2.1. End-to-end processes are those processes that interface with customers and suppliers of the organization.

8.1.3. For each end-to-end process, identify its sequential processes

8.1.3.1. It divides in a cicle:

8.1.3.1.1. Product lifecycle: The lifecycle of a product or service includes different states, which can be used to subdivide an end-to-end process.

8.1.3.1.2. Customer relationship: There are also typical stages that a customer relationship goes through. First, leads are generated, then a contract is sealed and services provided. For these, invoices are written.

8.1.3.1.3. Supply chain: Along the supply chain, materials are procured, which are used to produce products. These are checked for quality assurance and delivered to customers.

8.1.3.1.4. Transaction stages: There are different stages that transactions typically go through from initiation to negotiation, execution, and acceptance. Consider, for instance, buying clothes at a fashion retailer.

8.1.3.1.5. Change of business objects: If there are different business objects, the process should be split up into respective business processes. For instance, the transition from a quote to a contract or from an order to a payment mark the boundaries of different processes.

8.1.3.1.6. Separation: Different stages of a process can also be defined by a temporal, spatial, logical, or other type of separation. Often, these separations define handoffs, and major handoffs are suitable points to distinguish sequential processes.

8.1.4. Decompose and specialize business processes

8.1.4.1. Each of the business processes of the process landscape should be further subdivided into an abstract process on Level 2 of the process architecture. Also further subdivision to Level 3 might be appropriate until processes are identified that can be managed autonomously by a single process owner. There are different considerations when this subdivision should stop:

8.1.4.1.1. Manageability: The smaller the number of the identified processes, the bigger their individual scope is. In other words, if only a small number of processes is identified, then each of these will cover numerous operations.

8.1.4.1.2. Impact: A subdivision into only a few large processes will increase the impact of their management. The more operations are considered to be part of a process, the easier it will become, for example, to spot opportunities for efficiency gains by rooting out redundant work.

8.1.5. For each business process, identify its major management and support processes

8.1.5.1. The question for this step is what is required in order to execute the previously identified processes.

8.1.6. Compile process profile

8.1.6.1. Each of the identified processes should not only be modeled, but also described using a process profile.

8.1.7. Check completeness and consistency

8.1.7.1. These checks should build on the following inputs. First, reference models can be used to check whether all major processes that are relevant for the organization are included.

9. SAP’s Process Architecture

9.1. SAP is one of the largest software vendors worldwide. Its ambition is to help its customers to streamline their processes, such that they are able to predict customer trends based on live data. SAP also has an internal unit that is responsible for business process management, organizing the processes in which more than 87,000 employees of SAP work.

10. Process Selection: The aim of process selection is to define criteria for assessing the performance of the identified business processes

10.1. Selection Criteria

10.1.1. As stated before, not all processes are equally important and not all processes can receive the same amount of attention. BPM involves commitment, ownership, investment in performance improvement and redesign. There are several criteria:

10.1.1.1. Strategic Importance: This criterion is concerned with assessing the strategic relevance of each process. The goal is to find out which processes have the greatest impact on the strategic goals of an organization, for example considering profitability, uniqueness, or contribution to competitive advantages.

10.1.1.2. Health: This criterion aims to render a high-level judgement of the health of each process.

10.1.1.3. Feasibility: For each process, it should be determined how susceptible it is to BPM initiatives, either incidental or on a continuous basis.

10.2. Process Performance Measures

10.2.1. For many BPM-related management activities, we need a precise measurement ofthe health of a business process. In this context, we distinguish generic performance dimensions and specific performance measures. Often, four generic dimensions of process performance measures are distinguished: time, cost, quality, and flexibility. Any company would ideally like to make its processes faster, cheaper, and better. Below, we briefly discuss each of the four dimensions and how they are typically refined into specific performance measures:

10.2.1.1. Time: Often the first performance dimension that comes to mind when analyzing processes is time. Specifically, a very common performance measure for processes is cycle time (also called throughput time). We can say that the time can divide in two:

10.2.1.1.1. Processing time (also called service time): the time that resources, such as process participants or software applications invoked by the process, spend on actually handling the case.

10.2.1.1.2. Waiting time: the time that a case spends in idle mode. Waiting time includes queueing time—waiting time due to the fact that no resources are available to handle the case—and other waiting time, for example because synchronization must take place with another process, with other activities, or because an input is expected from a customer or from another external party.

10.2.1.2. Cost: Another common performance dimension when analyzing and redesigning a business process has a financial nature. While we refer to cost here, it would also have been possible to put the emphasis on turnover, yield, or revenue. Obviously, a yield increase may have the same effect on a organization’s profit as a decrease of cost. However, process redesign is more often associated with reducing cost.

10.2.1.3. Quality: The quality of a business process can be viewed from at least two different angles: from the client’s side and from the process participant’s perspective. This is also known as the distinction between external quality and internal quality. Various specific measures are used to capture customer satisfaction:

10.2.1.3.1. Churn rate: In particular for processes that interface with the customer over the Internet, it is important to know how many customers do not complete their interaction successfully

10.2.1.3.2. Net promoter score: This measure is often defined in a range from 1 to 10, and captures how far customers would be willing to recommend a product or service. Specifically for services, it is directly connected with the business process behind it.

10.2.1.4. Flexibility can be defined in general terms as the ability to react to changes. These changes may concern various parts of the business process, for example:

10.2.1.4.1. The ability of resources to execute different tasks within a business process setting;

10.2.1.4.2. The ability of a business process as a whole to handle various cases and changing workloads;

10.2.1.4.3. The ability of the management to change the structure and allocation rules;

10.2.1.4.4. The organization’s ability to change the structure and responsiveness of the business process to wishes of the market and business partners.

11. Sebastián Mesén Arias B74769. Informática aplicada a los negocios.