An organization (e.g., an enterprise, company, firm, entity, etc.) may perform many different processes in order to carryout the business of the organization. The term business process (or just process) may refer to a collection of related and structured and/or orchestrated activities and/or tasks that serve a particular goal of the organization, for example, to provide a specific service or produce a specific product for a particular customer or customers. A business process may be decomposed into several sub-processes, activities, tasks and the like, which may be performed across different teams, organizations or regions of the world. The organization may prefer to specify best practices for these processes and/or analyze the processes that are in place, for example, to improve the processes. The analysis of a business process typically includes creating a business process model (BPM) that represents the ways in which sub-processes, tasks, operations and the like of the process are carried out to accomplish the intended goal of the organization. A business analyst may analyze and interact with the business process model, for example, to improve process efficiency and quality.
Various tools may be used to model or engineer a business process. Such tools may provide the ability to model a business process, and perhaps implement and execute such a model. Such tools may allow an analyst to refine the model, e.g., based on how the model executes in response to certain data. In other words, such tools may allow for simulation of a business process (e.g., “what-if” analysis). Such tools may provide a graphical user interface (GUI) to users of the tool, and may provide a graphical representation of business process modeling. Example standards include Business Process model and Notation (BPMN), Event-driven Process Chain (EPC) and Unified Modeling Language (UML). Such tools may use a programing language or syntax (called business process modeling language of BPML) to specify actions within the business process and details about such actions. The programming language used may be related to the standard used; however, more than one language may be used for a single standard.
The following detailed description references the drawings, wherein:
As described above, a business process may be decomposed into several sub-processes, activities, tasks and the like, which may be performed across different teams, organizations or regions of the world. For example, an organization (e.g., an enterprise, company, firm, entity, etc.) may have several workers (e.g., human workers, knowledge workers, etc.) performing different portions of a process, perhaps across different teams, organizations or regions of the world. An organization's business process may ideally govern the manner in which these workers perform the process portions, and, as described above, the organization may attempt to specify best practices for these processes. However, with many workers in many different teams, organizations and geographic regions, different workers may perform a process portion in different ways, for example, to accommodate regional/geographic differences, local policies, to cater to specific customer situations, etc. With such diversity, it may be difficult for an analyst to understand the overall (i.e., global) process. In various scenarios, for example, in the case of a large worldwide organization, an analyst may not know significant amounts of information about the organization's business processes that are in place, and may be interested to learn more about a process, for example, to improve it.
It may be difficult for an analyst to learn about how a business process is enacted by various workers in various regions of the world. For many business processes that include tasks performed by workers, the workers are the ones that perform the actual tasks of the process, and they may have the best knowledge about the portion of the process in which they are involved. Therefore, gaining knowledge from these workers may be one of the most useful ways to learn about the process currently in place.
Some approaches to process modeling or engineering include having consultants or business analysts within the organization interview workers of the organization, often only a sample (e.g., a small sample) of the workers. Such consultants or analysts may then manually document or enter (e.g., into a business process modeling tool) the information gained from the workers to detail the overall (i.e., global) process. Such approaches may be a centrally focused (e.g., analyst-centric or analyst-sourced) effort based on the understanding of the consultants/business analysts. In other words, such approaches are implemented in a “top down” manner, meaning that analysts (e.g., a select number of analysts) representing the top organization look down at the departments of the organization, then the teams of workers, then the workers, etc. Using such approaches, important information from the workers may be lost, for example, due to incorrect interpretation by the consultants/analysts or due to the small size of the worker sample group. Such approaches to process modeling or engineering may be labor intensive, tedious, time consuming, costly and error-prone. Once the consultants/analysts interview various workers (e.g., from around the world), the consultants/analysts must review and reconcile (e.g., manually) the results, investigating any discrepancies, so that an overall (i.e., global) business process model can be created. Once such review is done, the resulting business process model likely still does not include all process variations (e.g., across various departments and regions of the world), and is thus, incomplete.
Moreover, business process modeling tools are not designed to be human-friendly, and thus, errors in interpretation by consultants/analysts and incomplete models may not be cured by allowing workers to enter process details directly into a business process modeling tool. Such tools are designed for use by trained and experienced business analysts that understand the complexities of the business process modeling standards and business process modeling languages used. Thus, workers, who know the details of the process work the best, may not understand how to use such tools. For example, the workers may not be familiar with the syntax of the process modeling standard and/or languages. Additional, graphical interfaces of such tools may be confusing and intimidating to workers. Indeed, such process modeling tools and approaches target more specialized and expert business process analysts.
The present disclosure describes distributed worker-sourced process engineering. The present disclosure describes a “bottom up” approach to providing details about a business process, for example, starting with direct input from individual workers, and building up to a complete business process of an organization. The present disclosure allows workers to engage directly with a process engineering system, to provide details about the work the do (e.g., a local process portion), work that is part of an overall or global process. Such a process engineering system may allow such workers to enter details about their work by selecting from a set of defined process statements may be of an easy to understand, human-friendly, textual language (e.g., a language closely resembling natural language). Various portions of an overall or global process may be entered by workers across various teams, departments, and regions of the world. Thus, process portions may be received by the system in a distributed manner. The process engineering system may automatically assemble the process statements into an overall or global process or process portion, considering the variations of the process statements from various workers. The process engineering system may translate the overall/global process/process portion from the human-friendly, textual syntax to a process modeling standard, which may subsequently be verified by a business process model verification service.
The present disclosure may provide benefits over other approaches to process modeling. For example, the present disclosure may allow business analysts to view process information from distributed workers and/or teams of workers across the world. It may also allow an analyst to view how the same process/sub-process is done in different contexts, settings and regions. The present disclosure facilitates the workers in expressing their view of the process and aids the analysts in recording and understanding the whole business process and its variations in different regions, teams, or based on other contextual criteria. Workers may easily and directly interact with the system of the present disclosure and thus the input of many workers may be used to formulate the business process, as opposed to a small sample of workers. Additionally, because workers may enter their information directly into the system, errors may be reduced or eliminated that may occur otherwise due to a consultant or analyst interpreting a worker's response to an interview question.
The term “knowledge worker” or simply “worker” may be used herein to refer to an individual that actually performs a portion of a process and has knowledge about the details of the portion of the process. The term “business analyst” or simply “analyst” may be used herein to refer to an individual (e.g., acting on behalf of an organization) to learn about and improve the business process of the organization. It should be understood that throughout this disclosure, when the term “analyst” is used, the description may also apply to individuals acting outside of the organization, but on behalf of the organization, such as a consultant. The term “business process” or simply “process” may be used herein to refer to a series or chain of related and structured activities, events and/or tasks that serve a particular goal or an organization. For example, a process may provide a specific service or product for a particular customer or customers. Specific examples of business processes, sub-processes, tasks, events and the like may be provided below. The terms “local” and “global” may be used throughout this disclosure as general terms that mean, essentially, “smaller” and “larger.” Thus, a global process or process portion does not necessarily mean a process/process portion that happens all over the globe. Instead, it may mean, generally, a larger process or process portion made up of smaller process portions (e.g., distributed process portions from knowledge workers).
Each user systems 110, 112, 114, 118 may each be any computing device that allows a user (e.g., a worker or analyst) to connect to a remote system or server (e.g., 102) via a network. End user systems 110, 112, 114, 118 may communicate with process engineering system 102 via at least one network (e.g., 120, 122). Networks 120, 122 may be a wired or wireless, and may include any number of hubs, routers, switches or the like. Networks 120, 122 may be, for example, part of the internet, at least one intranet and/or other types(s) of network(s). In some examples, networks 120, 122 may be the same network.
Process engineering system 102 may be implemented as at least one computing device, for example, any computing device accessible to workers and analysis over the internet or some other network. In some examples, process engineering system 102 may be implemented as more than one computing device, for example, computing devices that are in communication with each other (e.g., via a network). In these examples, the computing devices may operate together and provide a unified service to users. In these examples, the computing devices may be separate devices, perhaps geographically separate. The term “system” may be used to refer to a computing environment that includes one computing device or more than one computing device.
Process engineering system 102 may include a process engineering service 130. Process engineering service 130 may further include a worker service 132 and an analyst service 134. Process engineering service 130, worker service 132 and analyst service 134 may include a series of instructions encoded on a machine-readable storage medium and executable by at least one processor (e.g., processor 610 of
Process engineering service 130 may establish a connection with end user systems of workers and analysts (e.g., systems 110, 112, 114, 118), for example, to allow workers to access worker service 132 and analysts to access analyst service 134. Process engineering service 130 may, for example, include a web server that allows web clients of the end user systems to connect to the process engineering service 130.
Worker service 132 may communicate with workers (e.g., via end user systems and a network) to allow workers to, among other things, provide details about process portions that the workers works on. More details of an example worker service may be described below with regard to
Process portion input/modification module 202 may allow a number of workers (e.g., workers 230, 232, 234) to, among other things, provide details about process portions that the workers works on. As described in more detail below, process portion input/modification module 202 may provide workers with an editor where they can select and configure process statement templates, and may, for example, provide assistance by offering guidance with template arguments. Module 202 may include a number of modules, for example, modules 204, 206, 208, 210, 212. In some examples, workers (e.g., workers 230, 232, 234) may provide information to module 202 in response to receiving invitations (e.g., email notifications, pop-up windows or the like) from the worker service 202, for example, via worker invitation module 226, as described in more detail below.
Worker login module 204 may allow workers to log in to the worker service 200, for example, to access worker settings (e.g., 216, 218, 220) that are respectively associated with the workers. For each particular worker, the worker settings (e.g., as shown in worker settings 216) may include profile information about the worker and process statements (and contextual information) associated with the worker. More details about process statements and contextual information may be described below. In an organization, each worker may be involved in performing only a portion of a larger process, and may only know details about the workers process portion or a process portion of the worker's team or location. Thus, it can be said that workers may have “local” knowledge about a “global” process. Workers may not know about other portions or details of the larger process. By logging into the worker service 202 (e.g., via module 204), each worker may only see information (e.g., statements, comments, etc.) that is related to the processes, sub-processes, tasks, etc. that that worker is working on, or that the worker's team is working on.
Process portion input/modification module 202 may provide a graphical user interface to workers (e.g., workers 230, 232, 234). The graphical user interface may be capable of providing various screens or displays that may provide various features and pieces of information to workers. Such screens or displays may be provided to workers via a web server connection, such that the screens or displays appear on end user systems (e.g., 110, 112, 114) associated with the workers. The graphical user interface may also allow workers to submit or enter information, make selections and the like. Workers may perform such operations by interacting with their end user systems. In general, and as described in more detail below, the graphical user interface may allow such workers to enter details about their work by selecting from a set of defined process statements and configuring the selected process statements.
Referring again to
As indicated, process statements and process statement templates may be provided in an easy to understand, human-friendly, textual (e.g., as opposed to code-based) language, for example, a language closely resembling natural language. This may allow workers to understand the process statements even if such workers are not familiar with business process modeling standards or languages. The human-friendly, textual language may include a limited set of process-related vocabulary from process modeling standards or languages) such that the language is structured enough to later be translated into a formal business process modeling standard and/or language. Yet, the language may be close enough to natural language such that workers unfamiliar with business process modeling may quickly learn the language.
The following will describe some example process statements, process statement templates and examples of configuring statement templates by providing arguments. The following will also show an example human-friendly, textual language used for process statements and process statement templates. It should be understood that this is only one example, and other types of statements and/or languages may be used. Table 1 below shows a number of process statement types that may be included in a process statements repository (e.g., 214). A statements repository may have more statement types than those listed below. Each process statement type has an associated process statement template. As described more below, a worker may select a process statement template and configure it to create a process statement. As can be seen in Table 1, each process statement (e.g., the syntax) is expressed in a human-friendly, textual language.
As can be seen in Table 1, the process statement templates may include portions shown in square brackets (“[ ]”) and/or portions shown in curly brackets (“{}”). These portions may be referred to as “arguments” and may be configurable by a worker. Square brackets may indicate optional arguments (e.g., a worker must provide a value for the process statement to be complete) and curly brackets may indicate mandatory arguments (e.g., a worker may or may not provide a value). For example, in the “process” type statement template, “name” is a mandatory argument. As another example, “carried out at {region}” is an optional argument. Additionally, it may be seen that mandatory arguments may be included within optional arguments (and vice versa). For example, if a worker chooses to provide the “carried out at (region)” argument, then the “region” argument is mandatory. Additionally, text in a statement template that is not contained between brackets, (e.g., immediately adjacent brackets) may be a keyword. For example, referring again to the “process” type statement template, “carried out at,” “in” and “for” may all be keywords. Keywords may generally provide a human-friendly, textual indication of the purpose of an argument that may follow.
As can be seen in Table 1, a first type of process statement may be called a “process.” In general, a process indicates the overall (i.e., global) process. For example, a process may be a purchase process, which may include all the steps from the purchase of a good to supplying the good to the purchaser. A worker may configure the various arguments of the “process” type statement template. For example, the worker may configure the name, the region, the industry/segment, and the deal type. It may be described in more detail below how a worker may configure these portions. Another type of process statement may be called a “sub-process.” In general, a sub-process may describe a portion of a process, and may include multiple tasks. For example, a purchase process may include sub-processes such as ordering, payment, shipping, etc. The template of the sub-process statement also includes configurable portions (arguments). Some of these portions (e.g., region) may be auto configured based on the configurations of the parent process.
As can be seen in Table 1, another type of process statement may be called a “task.” In general, a task may describe a smaller unit of work than a sub-process, and may represent the smallest unit of work that a worker can specify. For example, if an example process was a sales process, and the sub-process was a pricing sub-process, then example tasks may include pricing software, pricing hardware, etc. As another example, for a shipping sub-process, example tasks may include packaging, posting, etc. The template of a task statement also includes configurable portions (arguments). For example, a task may be part of a parent process or sub-process. As another example, a task may be assigned to an “actor,” which may indicate, for example, a username associated with a worker or a worker's role.
As can be seen in Table 1, another type of process statement may be called an “event.” In general, an event statement indicates some action that is performed when some trigger occurs (e.g., an external trigger). For example, a worker may specify that whenever a new order arrives (the external trigger), the worker performs some action. Multiple types of event process statements may be used by the system. For example, as shown in Table 1, process statement types of “start event,” “intermediate event,” and “end event” may be used. A start event may indicate some event that causes a process or sub-process to begin. An intermediate event may indicate some trigger that occurs in the middle of a process or sub-process, and how such a trigger is handled. For example, if a customer cancels their order (trigger) in the middle of order processing (task), a worker may refund the customer's money. An end event may describe some action that occurs at the end of a process or sub-process. For example, once an order is processed, the worker may send out a confirmation or denial that the order has been processed successfully. The template of event statements also includes configurable portions (arguments). As one example, the parent process or sub-process of the event may be configured, and may be auto configured by the system based on a previous process or sub-process referred to by the worker.
As can be seen in Table 1, another type of process statement may be called “statement ordering.” In general, statement ordering indicates that one or more process statements occur before one or more other process statements. For example, a statement ordering process statement may indicate that a task of approving an order occurs after the task of checking permits. A statement ordering may indicate that a worker checks that the order is as specified before the worker verifies that a certain process or sub-process is complete. The template of statement ordering statements also includes configurable portions (arguments). Another type of process statement may be called “data association.” In general data association may specify details about the input, output, etc. of a process, sub-process or task. For example, for an order task, a data association process statement may specify details about invoice data. As another example, a data association process may specify that the input to a first task is the output from another task. In this respect, the data of these two tasks are associated, and may later be used to verify process statements.
With the descriptions of example process statements above, and referring again to
Referring to
Once a worker is done configuring all the arguments of the statement template 312, the worker may select a button (e.g., confirm button 316) to indicate that the statement template 312 should be saved for the worker as a process statement that indicates a part of the work the worker performs. Saved process statements for a particular worker may be stored in the workers settings (e.g., 216, 218, 220) for the particular worker. Then, these settings may be accessible by process assembler module 222, as described in more detail below. Workers may be able to access saved statements in their user account. Workers may be able to select saved statements after they are saved and edit those statements, for example, using statement editor 304.
Whether statement editor module 208 and/or statement editor 304 suggests value options for statement template arguments or not, the system may check the correctness of the statement in editor 304, for example, using statement verification module 210. The correctness of the statement may be cheeked after the worker has indicated that the statement should be saved (e.g., by clicking button 316), or at other times. For example, the correctness of the statement may be checked “on the fly” or dynamically whenever a worker selects or enters a new value for an argument of the process statement template 312. Statement verification module 210 and/or statement editor 304 may check the statement in various ways. For example, the statement (e.g., the argument values/inputs and outputs) may be checked for proper statement syntax (e.g., as specified by a human-friendly, textual language used for process statements). Additionally, the statement may be checked for consistency with other process statements, e.g., process statements already saved by the worker and/or other workers (e.g., globally or within the worker's team). When statements are checked, statement verification module 210 and/or statement editor 304 may provide suggestions or options for the worker to use in order to cure any problems with the statement. More details regarding checking for consistency may be provided below with regard to process assembler module 222 and/or statement consistency module 224.
Process assembler module 222 may receive process statements from various workers, for example, all the workers in a particular team or all the workers in the entire organization. As shown in
As described above, the present disclosure describes a “bottom up” approach to process engineering. Process assembler module 222 plays a role in this bottom up approach by receiving process portion information from various workers (e.g., in a distributed manner) and automatically assembling the portions in a larger portion or perhaps a complete process 238). It may also be said that the process portion information from the various workers is provided by the workers and received by module 222 in a “crowdsourcing” manner. In general, the term crowdsourcing may refer to various users acting on their own to provide personal or local information that may then be assembled by a system into a larger or global view. In the context of this disclosure, the term “worker-sourced” or “worker-sourcing” may be used in a manner very similar to crowdsourcing, where various workers may act on their own to provide personal or local information that may then be assembled by a system into a larger, overall or global view.
Process assembler module 222 may analyze the received process statements and attempt to piece them together into a larger process portion, perhaps building up to a complete process. For example, the process statements from one worker may be assembled with the process statements from another worker and so on. Module 222 may then send the larger process portion or full process 238 to an analyst service (e.g., 134 or 400) for analysis, as described in more detail below. Process assembler module 222 may include a statement consistency module 224.
Process assembler module 222 (e.g., via module 224) may detect inconsistencies among various received process statements. Inconsistencies may exist for various reasons, for example, due to an entry error by one or more workers or due to differences in how a process portion is performed due to location, specific clients, etc. As described above, statement verification module 210 may check process statements entered by workers, for example, to check for proper syntax. However, checking a process statement in isolation (e.g., without considering the larger process) may only allow for some errors to be caught. A process statement may appear to be correct when analyzed in isolation, but it may be incorrect or inconsistent when analyzed as it related to various other process statements. For example, if a first statement has output A, and a second statement is supposed to receive output A as an input, then, accidentally specifying that the first statement has output B instead of output A may cause problems, even though the first statement may appear correct in isolation. As another example, module 222 and/or 224 may check whether a statement (e.g., a sub-process statement) is really a child to an indicated process statement, for example, by checking various inputs, outputs, etc.
In some examples, module 222 may detect inconsistencies by detecting that two nearly identical process statements entered by two different workers are essentially detailing the same process step, but are different for some reason (e.g., because of different argument values). In some examples, module 222 may detect inconsistencies by detecting that, for example, a first process statement receives as input, a value that was never generated (e.g., as the output of another process statement). Then, by detecting that another process statement likely was intended to provide the output for the first process statement, process assembler 222 may determine what the input to the first process statement for output from the other process statement) should be in order for the statements to be consistent.
To detect various inconsistencies in process statements received by module 222, process assembler module 222 may use a set of consistency rules. Some consistency rules in the set may check for inconsistencies at the statement level; some may check for consistencies at the sub-process level; and some may check for consistencies at the process level. Process assembler module 222 may apply the various consistency rules via a process, algorithm, logic or the like. As one example, to detect duplicate statements, module 222 may use consistency rules that check at the sub-process or process level. Such roles may check the names of the process statements, and then may track what happens to each argument (e.g., input, output and the like) of each process statement. Two process statements may have similar inputs, outputs and input/output paths, but may have different names. Differences between process statements may be determined to be legitimate or acceptable if the arguments have different values and/or value paths, meaning that in different conditions the statements indicate that different tasks should be performed. Otherwise a warning may be issued to check for duplication. A similar process, algorithm, logic or the like may be used to detect un-used but generated arguments (e.g., inputs, outputs, etc.). For example, some inputs/outputs may be generated by one statement process but not used anywhere and are not input to another process statement.
Process assembler module 222 may provide information to statement verification module 210 in order to provide (e.g., via statement editor 304) inconsistency warnings and/or suggested changes to process statements to the workers that “own” the process statements. The inconsistency warnings and/or suggested changes may be based on inconsistencies detected by module 224) between various process statements and perhaps based on suggested fixes to process statements in order to make the statements consistent. Inconsistency warnings and/or suggested changes may be provided to workers “on the fly” (e.g., as users configure statement templates in editor 304) and/or after workers save their statements (e.g., via confirm button 316). In some situations, workers may receive inconsistency warnings and/or suggested changes as alerts (e.g., email notifications, etc.) later, and the workers may be invited to investigate the inconsistencies and/or make changes to their statements. Thus, it can be seen that either when a worker is configuring a process statement or perhaps later, the worker may be informed that the process statement is not consistent with other process statements of the same worker or other workers (e.g., in the same team and/or in the same organization). Workers can then make changes in order to achieve consistency or indicate or comment about the inconsistencies. Worker service 200 implements a sort of feedback cycle where workers configure process statements (e.g., at module 202), process statements are saved (e.g., at 216, 218, 220) and received by module 222, and inconsistency information is sent back to module 202 to aid in process configuration. Therefore, process assembler module 222 aids in reconciling the statements and inputs of various distributed workers.
Worker service 200 may provide a comment service for workers to comment on (and have conversations about) various items such as process statement templates/types, particular process statements and the like. The commenting service may be implemented in the worker service 200, or in the system (e.g., 102) that includes the worker service, or in an external system, in which case, worker service 200 may access such an external service and integrate it with the worker service to provide the commenting functionality described below. In some situations, various worker comments (e.g., from various workers) may be associated with each statement template/type. In this situation, the comments and/or conversations may be stored in the statements repository 214 or in some other repository of worker service 200. Information may also be stored that associates each comment with one of the workers. Alternatively, the comments may be stored externally, and information to link the comments to statement templates/types and/or workers may be stored in worker service 200. Alternatively, each workers comments may be stored in the worker's settings (e.g., 216, 218, 220), for example, along with information about which statement template/type, particular statement, etc. the comment is associated with.
The commenting service may support various channels or types of communication. e.g., beyond just simple text comments. For example, the commenting service may couple to at least one emailing service such that emails may be sent and receive by workers, where the emails may be related to process statement templates/types, particular process statements and the like. As another example, a worker may be able to record and/or submit a voice or video message or voice or video comment in a similar manner that a worker may submit a textual comment. As another example, multiple workers may record and/or submit a voice or video conversation related to process statement templates/types, particular process statements and the like. Therefore, various descriptions provided herein that refer to comments may be expended to include various other channels or types of communication.
The commenting service may allow workers to provide information about statement templates/types and/or particular statements for various reasons. For example, workers may provide information about how they configured a particular type of process statement template. In order to aid other workers (e.g., workers in the same team) in configuring their own process statements. As another example, workers may provide information about how they had to configure a particular process statement template in order to make it consistent with other process statements. As another example, workers may provide information that specifies that a particular inconsistency in a process statement is due to a particular difference in how the process is implemented (e.g., due to location, clients, etc.) for example, as opposed to an error. In this respect, various workers may indicate and explain (e.g., as an ongoing conversation) inconsistencies in various statements, and comments about inconsistencies may be provided (e.g., as annotations) to process statements, for example, when statements are provided to the analyst service. Additionally, as described more below, comments from various workers may appear, for example, via display 300, such that workers may see a “conversation,” which may allow workers to collaborate about how to use and configure process statements and about why legitimate inconsistencies may exist. In this respect, comments about statement templates/types may be implemented in a social networking or social collaboration manner. Workers within a team or even within an entire organization may discuss (e.g., within a conversation) how to use and configure process statements, perhaps considering various legitimate inconsistencies.
Workers may enter and view comments in various ways, for example, via various screens, displays and/or interfaces provided by process portion input/modification module 202. As one example, and referring to
As another example, workers may view and/or enter comments about a statement template/type by navigating in a “statement page” for a particular statement template/type. As is shown in
Referring to
As can be seen in
Process portion viewer 306 may include a view selector 322. View selector may allow a worker to select various views that may affect which process statements (e.g., 320) appear in viewer 306. For example, a worker may select to view only the worker's statements, in which case statements 320 may include only statements that the worker has selected (e.g., via selector 302) and configured (e.g., via editor 304) and saved. As another example, a worker may select (e.g., via selector 322) to view statements from the worker's team, in which case statements 320 may include statements saved from various workers within the worker's team, including the worker's own statements. In this example, the worker may see the worker's process statements and process statements of other workers as they fit within a global process or process portion. Various other viewing options are possible via selector 322. For example, statements may be filtered by various criteria such as process statement type (e.g., “task,” “event,” etc.), or other contextual information or criteria. Thus, while worker service 200 may allow workers to focus on their own portion of a process, workers may be able to view statements (e.g., reconciled statements) from team members, or perhaps from an entire organization, thereby allowing workers to view an aggregated sub-process or a complete process.
Process assembler module 222 may provide process statements from various workers to an analyst service (e.g., 134 or 400). Such process statements may form a complete or partially complete process 238. For example, if worker service 200 accepts statement inputs from all of the workers in an organization, then process 238 may be a complete process of the organization (assuming all workers entered their process statements). In some examples, a process engineering system (e.g., 102) may include more than one worker service, for example, where each worker service covers a segment (e.g., team, department, or group of teams, departments or the like) of an organization. In these examples, each worker service may include a process statement assembler module (e.g., 222) that outputs reconciled process statements for the group or workers that the worker service accommodates. In such a case, the analyst module may include its own process assembler module (e.g., 402 of
Process assembler module 222 may provide process statements in a dynamic manner, for example, such that an analyst service (e.g., 134 or 400) may continually view the process or process portion as it is built up with more and more input from workers. Alternatively or in addition, process assembler module 222 may notify the analyst service when process statements are ready to view, for example, after process statements provided by workers in response to an invitation are ready. Process assembler module 222 may provide the process statements from various workers as they have been configured by the workers. In other words, information 258 may include process statements and contextual information. Additionally, module 222 may provide at least some of the worker-provided comments and/or annotations regarding various process statements, for example, to aid an analyst and/or the analyst service in constructing the full process. For example, notations associated with particular statements and/or inconsistencies may travel with the statements (e.g., as part of information 238).
Process assembler module 402 may be present in analyst service 400, for example, if a process engineering system (e.g., 102) includes more than one worker service. In these examples, each worker service may output reconciled process statements, each forming a process portion or a partially complete process 414. Process assembler module 402 may assemble the process portions from the various worker services. Process assembler module 402 may operate in a manner similar to process assembler module 222 of
Process assembler module 402 may perform an initial verification (e.g., before the verification performed in process verification module 410). Process assembler module 402 may detect inconsistencies between the process portions 414 from various worker services. Even though each worker service may include a statement inconsistency module that may check for inconsistencies and errors in process statements, some errors may not be apparent when a portion of a process is analyzed in isolation. Process assembler module 402 may detect inconsistencies once the whole process is pieced together. For example, module 402 may detect that an input to one process statement from one worker service should be the same as an input to a process from another worker service. As another example, module 402 may detect that an input to a process statement is not defined. Process assembler module 402 may indicate (e.g., annotate) any inconsistencies that exist before module 402 passes the assembled process on to other modules of the analyst service 400 (e.g. module 404 and/or 408). In this respect, after module 402, a process may include inconsistency annotations that were provided by at least one worker service and/or process assembler module 402. These annotations may assist analyst to determine why process portions may be performed differently in different contexts.
Process definition module 404 may assist an analyst in specifying and defining a type of process that the analyst is interested in analyzing. As described above (e.g., in large entities). There may be many details about a process of the organization that the analyst does not know. Thus, an analyst may specify some pieces of information (i.e., process parameters 405) to indicate the process that the analyst would like to receive/view. For example, an analyst may specify that the analyst wants to see the organization's process (e.g., sales process, shipping process, etc.) for a particular type of sale or deal (e.g., deals of more than $500 million), for a particular region, etc. Example process parameters include type of process (e.g., sales, shipping, etc.), region, total contract value, industry segment, business unit and the like. Many other types of process parameters may be used for various other types of processes.
Process definition module 404 may use the process parameters 405 in various ways to receive and/or view relevant processes and process portions. As one example, analyst 412 may interact with process definition module 404 to enter process parameters 405 to indicate the type of process that analyst 412 is interested in. Then, module 404 (or some other modules of analyst service 400) may send such process parameters 416 to at least one worker service. The worker service (e.g., worker service 200) may then use the process parameters (e.g., shown as 236 in
As another example process definition module 404 may use the process parameters 405 as a filter. In these examples, many processes (and partial processes) (e.g., 414) of the organization may be dynamically or constantly accessible to the analyst service 400. In other words, the various process statements entered by workers of an organization may be constantly updated and accessible to the analyst service as workers enter new statements. Then, when processes or partial processes (e.g., 414) are received by the analyst service (and perhaps pass through module 402),the processes/partial processes may be received by process definition module 404. Then, process definition module 404 may use process parameters 405 to filter out only processes/partial processes that meet the process parameters 405.
In order to filter out processes and/or process parts, process definition module 404 may compare process parameters 405 to the “context” of various process statements. The context of a process statement may be formed based on the values provided by workers for arguments (e.g., as shown in Table 1 above) of various process statements. Additionally, context of process statements may come from other sources such as the related workers profile information. For example context information may come from an LDAP directory or the like, that may provide information about users/workers, such as the workers group, job function, hierarchy, etc. Context information for a process statement may travel along with the process statement from the worker service, for example, as argument values and/or as additional information association with the process statement.
Process analysis/modification module 406 may assist an analyst to learn about a process or process portion and perhaps even discover processes of the organization. Process analysis/modification module 406 may receive at least one process or process portion from module 402 and/or from module 404 (e.g., if process filtering is performed). Once a process is received by module 406, the process may be assembled to form a complete process or a larger portion of a process including multiple related process statements. The process or partial process may have passed through at least one verification stage to check for errors and/or inconsistencies. Thus, at this point, the process or partial process may ideally only include inconsistencies that are legitimate (e.g., due to some actual different in implementation of the process as opposed to an error in entering the process statement). Inconsistencies may have been identified and/or annotated. Thus, analyst may be able to view (e.g., in a graphical and/or textual manner) all the process statements of the process or such inconsistencies. In this respect, the analyst may be able to pin a complete picture of the business process, and the analyst may learn about inconsistencies and determine strategies to manage them.
Process analysis/modification module 406 may allow an analyst to modify the process. Process analysis/modification module 406 may allow an analyst to checking the consistency of the process/process portion from module 404 and/or module 406 and act to fix various process statements, for example. In response to annotations and/or warnings provided by other modules and/or services of the system (e.g., the worker service, module 402, etc.). As one specific example, fixing process statements may entail an iterative process, where the workers provide process portion details, the system (e.g., its various modules and services) check for inconsistencies and errors, and then the analyst modifies the process and/or suggests changes to the process portions. Additionally, module 406 may allow an analyst to provide additional annotations that explain inconsistencies between process statements.
Translation module 408 may receive a process complete or partially complete) from module 406, or perhaps from module 402 or 404. The received process or process portion may be defined in a human-friendly, textual language as entered by the various workers, as described above. Translation module 408 may automatically translate the process from the human-friendly, textual language to a process modeling standard (e.g., BPMN). For example, module 408 may translate the process from the human-friendly, textual language to an XML format (or other markup language) where the data is formatted according to the modeling standard. Thus, at this point, various reconciled process statements provided directly by workers may be translated into a process modeling standard that can then be further analyzed by business process modeling/engineering tools. Using such tools, the data in the process modeling standard format (e.g., XML format) may be represented in multiple ways, for example, graphically, textually, in a particular programming language, etc.
Process verification module 410 may receive at least one process or partial process from translation module 408. Process verification module 410 may use a format process verification tool (e.g., based on Petri Net formalism or the like) to formally verify the correctness of a process. Process verification module 410 may perform formal verification on received processes or process portions that are formatted according to a process modeling standard (e.g., BPMN), as described above. Formal process verification tools may perform verification on executable business process languages, so module 410 may first convert the process from a process modeling standard to a particular process modeling language before performing formal verification. Then, a formal process verification tool may perform extensive analysis of the process or process portion to check for various issues, for example, fragmented process parts, gridlocks or endless loops, etc.
Method 500 may start at step 502 and continue to step 504, where a process engineering system (e.g., 102 of
At step 510 a worker (e.g., worker 230 of
At step 520, the reconciled statements of the worker may be assembled (e.g., via module 222) with statements of other workers to form an overall process or process portion. At step 522 the worker may view (e.g., via module 212 and view 306) completed statements of the workers own and/or of other workers. At step 524, the assembled statements (e.g., from step 520) may be received by the analyst service. As described above, the analyst service may receive specific processes and/or portions that fit the process parameters or the analyst service may filter out various received processes and/or portions to view those that are relevant to the process parameters. At step 526, the system may allow an analyst to analyze the process or portion and/or modify it. At step 528, the system may translate the process statements of the process or portion to a process modeling standard. At step 530, the system may verify the process or portion. This verification may require the process modeling standard to be translated into a particular process modeling language before verification can commence. At step 532, it the process fails to be verified, the analyst may return to step 524 to receive and/or view the process or portion again, ideally an updated process/portion. Method 500 may eventually continue to step 534, where method 500 may stop.
Processor 610 may be one or more central processing units (CPUs), CPU cores, microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in a machine-readable storage medium (e.g., 620). Processor 610 may fetch, decode, and execute instructions (e.g., instructions 622, 624, 626, 628) to, among other things, perform worker-sourced process engineering. With respect to the executable instruction representations (e.g., boxes) shown in
Machine-readable storage medium 620 may be any electronic, magnetic, optical or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 620 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. Machine-readable storage medium 620 may be disposed within a computing device (e.g., 600), as shown in
Process statement providing instructions 622 may allow a worker to directly provide process statements to the system that indicate a process portion that the worker performs. More details regarding providing process statements may be described above, for example, with regard to modules 206 and 208 of
Method 700 may start at step 702 and continue to step 704, where a worker may provide (e.g., via instructions 622) process statements, e.g., directly to a process engineering computing device (e.g., 600) or system. At step 700, the computing device or system may verify (e.g., via instructions 624) the process statements, as described in more detail above. At step 708, the computing device or system may assemble (e.g., via instructions 626) the process statements of the worker and process statements of other workers into an overall process or process portion. At step 710, the process or process portion may be provided via instructions 628) to an analyst for review. Method 700 may eventually continue to step 712, where method 700 may stop.
It will be appreciated that the previous description of the disclosed examples is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these examples will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other examples without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the examples shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US13/45416 | 6/12/2013 | WO | 00 |