Patent Application
20190019123
“Deployable process” also termed as “work process” refers to a sequence of tasks or steps to produce a service or product. For example, a work process ‘article creation’ may comprise sequence of steps (e.g., article request created, goods receipt, dispatch, etc.) for procuring an article or a product. Using the work process ‘article creation’ a user, e.g., a store manager, can procure a product. The work process is required to be monitored for proper functioning of a task within an enterprise. Some work processes might be critical and may be required to be monitored continuously in real-time (e.g., flight tracking), while other, less critical work processes, may be required to be monitored periodically at regular time intervals (e.g., machine performance tracking, contract renewal, etc.). An error, fault, expiry, and/or failure at a step of the work process may be detected and notified so that a proper action may be initiated on time for successful execution of the tasks.
Usually, the work process is monitored manually and when an event occurs (e.g., in case of a failure), an action (e.g., recovery action) is initiated manually (e.g., by one or more users) which may be an error prone, costly, and an arduous task. Further, if there is a human error or negligence there may be a delay in initiating recovery action which may be dangerous for critical work processes such as flight tracking. Now-a-days, monitoring work processes, triggering events (e.g., in case of failure), and initiating actions may be automated for efficient execution of work processes. However, developing an application to automatically monitor a work process, trigger events, and initiate corresponding actions may be a time-consuming, costly, and arduous task. It may be required to determine various objects within the work process, analyze the behavior of the objects, and analyze the relationships between the objects, etc., to develop such application. Further, if any change is required within the work process (e.g., addition of new object, deletion of an object, editing an object, etc.), then the application may have to be modified (edited) accordingly. Moreover, until the application is modified, the monitoring of the updated work process might get interrupted and there might be delay in initiating recovery actions, which may put the execution of the tasks or work process at risk.
The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for self-sustainable objects within work processes are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”. “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
“Work process” refers to a sequence of tasks or steps to produce a service or product. For example, a work process ‘data mining’ may comprise sequence of steps (process steps) to fetch relevant or desired data. The work process ‘data mining’ may comprise sequence of steps including data retrieval, data filtering, and data clustering. The process step ‘data retrieval’ may be used to retrieve data from a data repository, the process step ‘data filtering’ may be used to filter the retrieved data (e.g., based upon some parameter such as product identifier or ID) and the process step ‘data clustering’ may be used to cluster (group) the filtered data into different groups or clusters. For example, in an embodiment, the process step ‘data retrieval’ may be configured to retrieve ‘employee attendance’ data from the data repository, the process step ‘data filtering’ may be configured to filter the retrieved ‘employee attendance’ data based upon a parameter (e.g., employee ID), and the process step ‘data clustering’ may be configured to cluster filtered data (attendance data of employee) based upon, e.g., day, month, etc. Another example of a work process may be ‘contract management’ which comprise sequence of steps (process steps) including contract creation and contract renewal for managing contracts. The process step “contract creation” may be used to create contract and the process step “contract renewal” may be used to renew the contract to enable continuous procurement of product or service. The process step “contract renewal” may comprise sub-process steps (a) request for quotation (RFQ) sent to a supplier to invite the supplier to bid on particular product or service (e.g., price per item or product (i.e., target price), timeframe or validity period for which the price quotation may be valid, and target quantity of product to be purchased within the specified timeframe); (b) receipt of quotation from the supplier; (c) generation of purchase request or purchase requisition (PR) to notify a purchasing department about the product it needs to order, the target quantity, and the timeframe for order fulfillment; and (d) creation of purchase order (PO) to buy the item or product. Alternately, the work process “contract management” may comprise process steps namely (i) contract creation; (ii) request for quotation (RFQ); (iii) receipt of quotation; (iv) generation of purchase request or purchase requisition (PR); and (v) creation of PO. Using the work process ‘contract management’ a user, e.g., a store manager, can manage contracts and can procure or buy a product from a supplier at a definite price for a specified timeframe. A process step (e.g., contract renewal) may be monitored regularly for proper functioning of a task. e.g., renewing the contract to continue procuring or buying the product from the supplier. An instance of the work process (e.g., contract management) may be created for managing specific contract and producing or procuring respective service or product. The “work process” may also be referred as “deployable process.”
“Object” refers to a logical unit or a software model (including logic and data) representing real-world or virtual entities. For example, an object may represent a document such as a sales order (SO), a purchase order (PO), an invoice, a product, a piece of equipment, etc. An object may have one or more attributes or parameters, e.g., the object PO may include parameters such as contract identifier (ID), supplier name, price, requested delivery date, and quantity, etc. Typically, an object comprises logic and/or data. The data refers to values of various parameters of the object. For example, for the object “contract” the data may be values of parameters contract ID, expiry date, validity period, quantity, price, etc. A process step or a sub-process step may involve one or more objects. In an embodiment, a process step or a sub-process step may be realized as an object. For example, the process step “generation of PR” may be realized as object “purchase requisition (PR)” which may include: (i) logic for generating PR; and (ii) data such as target price, timeframe or validity period, and target quantity.
“Self-sustainable object” refers to an object configured to monitor or examine itself (e.g., monitor or examine its data) and trigger or initiate an action, if required (e.g., based upon the monitored data). In an embodiment, an action may be triggered or initiated, e.g., based upon a predefined condition, a failure, etc. For example, a self-sustainable object “data filter” may monitor data such as filtering parameter (e.g., name or ID of a row or column of a database table) and when no filtering parameter is provided or when wrong filtering parameter is provided, the self-sustainable object “data filter” may itself send a message to a user to provide correct filtering parameter. Another self-sustainable object “data cluster” may monitor its data such as clustering parameter (e.g., region, day, month, etc.) and when no clustering parameter is provided or wrong clustering parameter is provided, the self-sustainable object “data cluster” may itself send a message to the user to provide correct clustering parameter. Similarly, a self-sustainable object “contract” may monitor its data such as timeframe or validity period (i.e., the period for which the contract is valid) and when the validity period expires, it may itself send a request for quote (RFQ) to the supplier to renew the contract (e.g., to renew itself). Therefore, the self-sustainable object monitors its state or its lifecycle (whether it is active (alive: within validity period) or deactivated (invalid)) and initiates required action to keep itself alive or active. Process step(s) including self-sustainable object(s) may be termed as “self-sustainable process step(s).”
“Internet of Objects” or IoO refers to a network of objects and/or self-sustainable objects communicatively connected to collect and/or exchange data. In an embodiment, the objects or the self-sustainable objects may be communicatively connected to clients, servers, various devices that are on-premise and/or cloud based, to collect and/or exchange data. The IoO enables transfer or exchange of data over a network or among objects or self-sustainable objects without requiring human-to-human interaction. For example, a self-sustainable object “data retrieval” may collect data (e.g., employee attendance database table) from another self-sustainable object “data repository.” Another self-sustainable object “purchase order (PO)” may collect data (e.g., price per product, requested delivery date for which the price quotation is valid, and quantity of the product to be purchased within the specified timeframe, etc.) from another self-sustainable object “purchase requisition (PR).”
“Event” refers to an occurrence of a condition. For example, the occurrence of a condition: “when the target quantity is reached” is an event. The condition may also be formed by a combination of one or more constraints on values of data. For example, a condition including a combination of constraints may be “when the target quantity is reached or exceeded AND/OR the validity period is expired.” The occurrence of these conditions trigger an event. Based upon the event, certain action (e.g., remedial action) may be initiated. For example, an inspection or a repair workflow may be initiated by a self-sustainable object. The remedial action may help to perform predictive maintenance, avoid accidents such as expiration of a contract, keep objects alive, etc. An event may be defined or configured for a self-sustainable object, based upon requirement(s). For example, a self-sustainable object “contract” having data such as price per product (target price), timeframe or validity period, and target quantity may include an event “when the target quantity is reached or exceeded AND/OR the validity period of the contract is expired”, or “if the contract is not used since dd.mm.yy (date format in day, month, year)” based on a requirement. Once any of the conditions is met (event occurred), the contract has to be renewed. The self-sustainable object may trigger or initiate an action (remedial action), based upon the event. For example, when the event “if the contract is not used since dd.mm.yy” is met, the self-sustainable object may initiate contract renewal process or may turn its status to inactive and/or send a request to purchasing department or to a concerned person to provide approval to the self-sustainable object to be deleted, archived, or deactivated. In an embodiment, the self-sustainable object may be configured combining both the event and the remedial action, e.g., “generate RFQ when the target quantity is reached or exceeded AND/OR the validity period of contract is expired.” The object monitors and collects data related to the configured event to determine the occurrence of the event. Based upon the triggered event, the object can initiate the remedial action.
“In-memory” database refers to a database that relies on main memory for computer data storage. In some examples, the in-memory database includes a combination of main memory and disk storage. Also, the in-memory database may implement analytics and transactional processing including replication and aggregation techniques to be performed real-time or near real-time. Also, within the in-memory database environment, calculation logic may be pushed down into the database layer (as opposed to residing in the application layer) such that the processing time for querying and manipulating the data within the database may be reduced as compared with conventional relational databases. In some examples, the in-memory database may be HANA® Enterprise 1.0 (or other versions). However, the techniques described herein may be applied to any type of relational database as well.
Embodiments provide self-sustainable objects within work processes. As explained, self-sustainable objects refer to objects which can monitor themselves, e.g., to determine whether they are functioning properly, getting expired, etc., and based upon a determination, promptly take remedial action(s) if required, e.g., to keep itself active or alive. Thus, the lifecycle or validity of such objects may be enhanced. Further, as self-sustainable object can examine or monitor itself, there is no requirement to develop a separate monitoring application to monitor the object. Further, the object itself can trigger or initiate the required remedial action in case of any failure. Therefore, the self-sustainable object can manage itself. A work process including self-sustainable objects becomes self-sustainable as the included self-sustainable objects can manage themselves. Further, if any change is required within the work process (e.g., addition of a new object, deletion of an object, editing an object, etc.), the object(s) may be added, deleted, or edited without the need to redundantly apply these changes to a separate application (e.g., monitoring application), which saves time and resources. Moreover, as the self-sustainable objects can monitor themselves, the monitoring process may not get interrupted and/or delayed, e.g., due to some bug in the monitoring application. Typically, the monitoring of one object may not be delayed, disturbed, or affected by change(s) in another object. Also, as the self-sustainable objects themselves can initiate recovery action(s) on time, the critical work processes may be performed with less disturbances or delays. Additionally, since self-sustainable objects are self-monitoring, there are potentially fewer management programs that need to be running in the backend consuming processor resources, therefore, the computer itself potentially runs faster with self-monitoring objects. Thus, self-monitoring objects make the computer technically superior.
It may be noted that the work processes described in the below paragraphs are for exemplary purpose and the embodiments may not be restricted to that. The work process may include a number of process steps which may involve one or more self-sustainable objects. Such process steps may be referred to as self-sustainable process steps.
In an exemplarily embodiment, the work process 100 may be “contract management” including the following self-sustainable process steps:
Self-sustainable object “contract” OBJ1 may include master data related to the contract, e.g., supplier name, product name, product ID, contract ID, and contract details such as timeframe for which the contract is valid or applicable (e.g., validity or contract period), price per product (i.e., price valid within the contract period or target price), and target quantity (quantity of the product to be purchased within the specified timeframe), etc. The “contract” OBJ1 may be referred for buying the product from the supplier or vendor. The OBJ1 monitors itself or it's data to determine if a contract is still valid. The OBJ1 may monitor its data through the monitoring logic MLT1 at regular time intervals, e.g., every day or 24 hrs. Based upon the monitored data, the OBJ1 determines (e.g., through the event detection logic EDT1) whether a predefined event is triggered. The event may be defined to determine the validity of the corresponding contract (e.g., if the validity period has expired, if the purchased product quantity is more than the target quantity, etc.). When the OBJ1 determines that the event is triggered (e.g., through the event detection logic EDT1) indicating invalid contract, the OBJ1 may perform (e.g., using the action initiating logic ACTL1) one or more of, but not limited to: (i) change contract status to inactive; (ii) prepare RFQ and send it to the supplier; (iii) send a message to a user that contract validity has expired; (iv) send a message to purchasing department or concerned person to ask if a new RFQ is to be prepared and upon receiving the approval from the purchasing department or concerned person, prepare the RFQ and send to the supplier; and (v) trigger the process step 120 (e.g., send request to the process step 120) for initiating contract renewal process.
Self-sustainable object “request for quote (RFQ)” OBJ2 creates RFQ and sends it to the supplier. In an embodiment, upon receiving request from the OBJ1 or another object, the OBJ2 prepares the RFQ and sends it to the supplier. In one embodiment, the OBJ2 may itself regularly monitor the validity period or date of a contract (e.g., through the monitoring logic MLG2). In an embodiment, the MLG2 monitors or verifies the validity date of the contract, e.g., from the OBJ1 or from an internal or external data repository maintaining contract data. If it is determined or detected (e.g., through the event detection logic EDT2) that the validity date has expired, the OBJ2 may perform (e.g., using the action initiating logic ACTL2) one or more of, but not limited to: (i) automatically prepare the RFQ and send it to the supplier; (ii) send a message to purchasing department or concerned person about expiry of contract and to inquire if a new RFQ is to be prepared; and (iii) upon receiving the approval from the purchasing department or concerned person, prepares the RFQ and sends to the supplier. In another embodiment, the RFQ could check if the supplier is due to send a quote and trigger a reminder for the supplier.
Self-sustainable object “Quote” OBJ3 represents quotes received from a supplier. Once a quote is received from a supplier, the OBJ3 triggers the OBJ4 to prepare purchase request or requisition based upon the received quote. In an embodiment, the OBJ3 monitors itself, e.g., monitors quote validity date (e.g., through the monitoring logic MLG3). When the monitored quote validity date expires (e.g., detected through the event detection logic EDT3), the OBJ3 may send a message to the purchasing department or the OBJ2 for creating/requesting new quotation from the supplier (e.g., using the action initiating logic ACTL3).
Self-sustainable object “purchase requisition (PR)” OBJ4 prepares purchase requisition (PR), based upon a quote received from a supplier, e.g., through OBJ3. In an embodiment, the OBJ4 may regularly ping OBJ3 (e.g., through the monitoring logic MLG4) to determine if a new quote is received from the supplier. When the new quote is received from the supplier (e.g., detected through the event detection logic EDT4), the OBJ4 may perform (e.g., using the action initiating logic ACTL4) one or more of, but not limited to: (i) send PR to the purchasing department or concerned user to proceed further with PO and purchasing, and (ii) send PR to other object (e.g., OBJ5) to prepare PO corresponding to the PR and proceed with purchasing. In an embodiment, when the OBJ4 sends the PR to the purchasing department or the concerned person, the OBJ4 also triggers the OBJ5 that a new PR is sent to the purchasing department or the concerned person so that the OBJ5 may inquire the purchasing department or the concerned person about preparing PO. In an embodiment, Self-sustainable object “purchase requisition (PR)” OBJ4 prepares purchase requisition (PR) based upon another process like production or maintenance process. A product or service request is triggered or generated by these processes. When the PR is generated, it is determined with MLG4 whether a valid contract exists. The EDT4 may detect whether a contract is already referenced within the PR and whether it may copy the relevant data from the contract (e.g., the OBJ1). When the PR data is completed, the ACTL4 triggers the creation of a PO.
Self-sustainable object “purchase order (PO)” OBJ5 generates POs. In an embodiment, the OBJ5 generates a PO upon receiving a request from at least one of the OBJ4, the purchasing department, and a concerned person. In an embodiment, the OBJ5 may itself regularly monitor (e.g., through the monitoring logic MLG5) the validity date of a contract. The validity date may be monitored, e.g., by referring to the OBJ1 or an internal or external data repository maintaining the contract data. When the validity date expires (e.g., detected through the event detection logic EDT5), the OBJ5 may inquire (e.g., using the action initiating logic ACTL5) the purchasing department or the concerned person whether the PO is to be generated, e.g., even if the contract is not valid. In an embodiment, the OBJ5 inquires the purchasing department or the concerned person, e.g., when triggered by the OBJ4 or by monitoring OBJ4 and detecting that new PR is generated by the OBJ4. Upon receiving approval for generating PO, the OBJ5 generates the PO, e.g., by reading PR information from the OBJ4. The PO may include the official purchase order with product, price, quantity and delivery date. The OBJ5 sends the PO to the supplier. The PO is the basis for the delivery and invoice. In an embodiment, upon receiving the triggering (e.g., receiving a message) from the OBJ4 about the new PR, the OBJ5 generates the PO corresponding to the new PR and sends it to the supplier. In an embodiment, once the PO is generated, the OBJ5 may trigger the OBJ1 “contract” to update its data. In another embodiment, the OBJ1 may regularly monitor or request the OBJ5 for the PO data, and update its data accordingly. In an embodiment, if no contract is existing to procure a product or service, the OBJ5 could determine if there are other POs without an existing contract reference and initiate to create a contract for procurement of this product or service e.g. by triggering an RFQ.
The events for self-sustainable objects may be defined or updated through rule engine. The events may be defined or updated during design-time (e.g., while defining the object) and/or runtime (e.g., when the work process is executed).
In an embodiment, there may be a central event repository for maintaining events and rules related to all the self-sustainable objects of a work process.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” includes a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” includes physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs. DVDs and holographic indicator devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java. C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open Database Connectivity (ODBC), produced by an underlying software system, e.g., an enterprise resource planning (ERP) system, and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the one or more embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the embodiment are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the embodiments, as those skilled in the relevant art will recognize. These modifications can be made to the embodiments in light of the above detailed description. Rather, the scope of the one or more embodiments is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
