Patent Application
20140157150
Most business tasks require interaction or collaboration between employees, e.g., for clarifying queries. The employees interact through various channels of communication such as mails, cell phones, social networking sites, communicators, etc. Usually, the communication channels are separated from a business system where the business task is performed. Therefore, the employee, performing the task, need to switch between the business system and the communication channels to refer to relevant communications related to the task or to clarify queries. However, it might be inconvenient and distracting to switch between the communication channels and business system while performing task. Further, switching between the communication channels and business system consumes time and affects productivity. Also, if a business task is associated with other business tasks then it might be required to aggregate relevant communications related to other business tasks as well, which again is a time consuming and tiring task.
The claims set forth the embodiments with particularity. 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, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for contextual collaboration 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.
A business object (130) describes a structure and behavior of a real-world object used during the transaction of business. For example, a business object may represent a business document such as a sales order, a purchase order, or an invoice. In one embodiment, the business object may represent items such as a product, a business partner, or a piece of equipment. Typically, a business object includes data and functions along with the data.
A business process may be a structure of functions or a series of activities that produce a specific result (e.g. a service or a product). In one embodiment, the series of activities may be a sequence of activities with interleaving decision points and may be visualized with a flowchart. In one embodiment, the series of activities may be executed simultaneously. In one embodiment, one or more business rules are associated with corresponding business processes. Typically, a business process is executed based upon the business rules to produce the specific result.
A business task may he a single action with a measurable result within a business process. Therefore, a business task is a subset of the business process. For example, if the business process is ‘change of working time’ then various business tasks associated with it may be ‘request for approving the change of working time’ (human task), ‘approve the change’ (human task), ‘verify the company policies and update a system based upon the change’ (human task), and ‘inform the employee and a manager about the changes’ (system task).
Business instance 120 may be any one of the business object, the business process, or the business task. For example, the business instance 120 may be the business object, e.g., ‘employee,’ as shown in
Referring to
The communication tool also includes a ‘search and add participant’ option 530. Using the ‘search and add participant’ option 530, the user can search and add one or more employees or participants for discussion. Typically, the user can send them invitation to join the discussion and once they accept the invitation, they are included in the discussion. In one embodiment, the communication tool 110 auto suggests various names of participants relevant for the discussion. The users can select the participants of their choice. The communication tool 110 retrieves and displays context specific information (e.g., relevant participants, relevant document, etc) related to the business object 500. The user can select the context specific information. The selected context specific information is integrated or associated with the business object 500. The communication tool 110 also includes a ‘new thread’ option 540. Using the ‘new thread’ option 540, the user can create a new sub topic of discussion under an already created discussion.
In one embodiment, as shown in
In one embodiment, the communication tool 110 integrated with the business object 500 identifies the business processes 700 and 720 associated with the business object 500. In one embodiment, the communication tool 110 identifies the business processes 700 and 720 associated with the business object 500 from metadata of the business object 500. Once the business processes 700 and 720 are identified, the communication tool 110 retrieves and displays the conversation data 710 and 730 along with the business object 500, as shown in
Although some features of the communication tool 110 are described above, it should be understood that other features can be easily adopted. Any new feature related to communication may he easily configured within the communication tool 110.
Embodiments described above provide a context-based collaboration. In context-based collaboration, a communication tool is integrated within each business instance itself. For example, the communication tool may be integrated within a business object, a business process, or a business task itself. Therefore, a user while working on the business instance can simultaneously collaborate or clarify queries related to the business instance. Further, all prior communications or conversations related to the business instance are also displayed on the communication tool. Therefore, the user while working on the business instance can easily, conveniently, and efficiently refer to all the relevant communications related to the business instance. It also helps user to focus on the business task without being distracted or switching to various communication channels. Further, it saves time that might get wasted in referring to and aggregating relevant information from various communication channels.
Also, the communication tool automatically suggests relevant information (e.g., relevant participants, relevant documents, etc.) related to the business instance. Therefore, the user can easily refer to or selects the relevant information and can perform the business task efficiently. For example, a human resource (HR) user, performing the business task related to hiring, is automatically suggested the names of relevant consulting agencies to efficiently execute hiring process or to initiate onboarding services. Further, the embodiments also enable auto aggregation of context based information. In auto aggregation of context based information, the communications related to other business instances which are associated with an activated business instance is automatically displayed along with the activated business instance.
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” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any 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 any of the methods or process steps described, represented, or illustrated herein. Examples of 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 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 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 are to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
