One embodiment is directed generally to Enterprise Application Systems (“EASs”), and in particular to the creation of relationship maps from EAS data.
Enterprise Application Systems are typically integrated software applications that perform business functions such as accounting, production scheduling, customer information management, human capital management, etc. They are frequently implemented on servers and simultaneously provide services to a large number of users, typically over a computer network. These systems are in contrast to the more common single-user software applications which run on a user's own local computer and serve only one user at a time. Typically, the Enterprise Application System (“EAS”) is implemented as a group of software modules sharing a common database. Examples of an EAS include a Customer Relations Management (“CRM”) system, a Manufacturing Resource Planning (“MRP”) system, and an Enterprise Resource Planning (“ERP”) system.
Enterprise Resource Planning is an industry term for integrated, multi-module application software packages that are designed to serve and support multiple business functions. An ERP system can include software for manufacturing, order entry, accounts receivable and payable, general ledger, purchasing, warehousing, transportation and human resources. Evolving out of the manufacturing industry, ERP implies the use of packaged software rather than proprietary software written by or for one customer. ERP modules may be able to interface with an organization's own software with varying degrees of effort, and, depending on the software, ERP modules may be alterable via the vendor's proprietary tools as well as proprietary or standard programming languages.
Often it is important to find out information about an employee, such as who they work with or what kind of work they do. This information can be recorded in an ERP system, but often that information is not up to date, because it is quite onerous for a line manager or human resources professional to keep that up to date in a rapidly changing work environment.
One embodiment is a method for creating a relationship map using enterprise application system (EAS) data. The method comprises automatically collecting relationship data from at least one EAS module and generating a relationship map from the collected relationship data.
An embodiment is a method for creating a relationship map from EAS data in. In one embodiment, the EAS data and contact information are stored on an ERP server.
In one embodiment, ERP server 100 is implemented as part of the Oracle® E-Business Suite. ERP server 100 includes a processor (not shown) for executing instructions and a memory (not shown) for storing an operating system and software modules executable by the processor. ERP server 100 is accessible by at least one administrator 120 and at least one employee 130 via, for example, network 140. Administrator 120, employee 130, and other entities not shown may communicate with each other using email server 150. ERP server 100 also communicates with email server 150. ERP server 100 includes a plurality of modules 102-108 and a central database 110 including data collected, utilized and reported by modules 102-108. Manufacturing module 102 collects, utilizes and reports data relating to manufacturing engineering, bills of material, scheduling, capacity, workflow management, quality control, cost management, manufacturing process, manufacturing projects, and manufacturing flow, among other aspects. Supply Chain Management module 103 collects, utilizes and reports data relating to inventory, order entry, purchasing, supply chain planning, supplier scheduling, inspection of goods, claim processing, and commission calculation, among other aspects. Financials module 104 collects, utilizes and reports data relating to general ledgers, cash management, accounts payable, accounts receivable, and assets, among other aspects. Projects module 105 collects, utilizes and reports data relating to costing, billing, and time and expenses of projects, employee activity on a project, among other aspects. Customer Relationships Management module 106 collects, utilizes and reports data relating to sales and marketing, commissions, service, customer contact, and call center support, among other aspects. Data Warehouse module 107 includes interfaces for suppliers, customers, and employees to access a data warehouse. Human Resources module 108 collects, utilizes and reports data relating to position management, performance review, applicant tracking, payroll, training, time and attendance, and benefits, among other aspects. Human Resources module 108 is described in greater detail below.
Human Resources module 108 further includes Relationship Management module 208. Relationship Management 208 module collects, utilizes and reports data relating to the relationships among employees in an organization. This relationship data is acquired, either dynamically or periodically, from other ERP modules and submodules in ERP Server 101, as well as from Email Server 150. One or ordinary skill in the art will recognize that there are other possible sources for relationship data. In one embodiment, relationship data describes an instance of a relationship between two or more employees in the organization. These instances are collected and stored in database 110 for utilization by Relationship Management module 108.
For example, Relationship Management module 108 collects relationship data from Email Server 150. This relationship data may include instances of emails between two employees, or the frequency with which they exchange emails. Relationship data may further include instances where two employees are on the same distribution list, or are invited to the same meetings. Furthermore, relationship data may be asymmetric; for example, employee A emails employee B frequently, whereas employee B emails employee A hardly at all. Relationship data may further include instances where an employee is in the contact list of another.
Relationship Management module 208 also collects relationship data from other HR modules. For example, Relationship Management module 208 collects relationship data from Position Management module 201 regarding employees who work together. This relationship data for an employee may include the employee's supervisor(s) and department heads, coworkers within the employee's department, and people supervised by the employee. The relationship data may further include other employees having the same rank or title. Relationship Management module 208 may further record instances of the employee's former relationships with other employees in similar capacities.
In another example, Relationship Management module 208 collects relationship data from Training module 205. Instances of relationship data here may include employees who have completed the same training course, or who are registered to take the same training course. In yet another example, Relationship Management module 208 collects relationship data from Applicant Tracking module 201. Instances of relationship data here may include employees who started on the same day, in the same time period, or in the same department within some time period.
Relationship Management module 208 also collects relationship data from other ERP modules. For example, Relationship Management module 208 collects relationship data from CRM module 106 relating to employees who share the same customers. Relationship Management module 208 may also collect relationship data from Projects module 105 relating to employees who are on or who have worked on the same project. One of ordinary skill in the art will recognize that relationship data may be collected from a multitude of sources in addition to what is disclosed herein, both within and outside of the ERP server 101. Using the relationship data collected, Relationship Management module 208 builds a relationship map of the employees in the organization and stores this map in database 110.
In one embodiment, Relationship Management module 208 further may apply a rules set to assign weights to the relationships among employees. These weights may be based on the source of the relationship data, for example, relationship data from Position Management module 201 may carry more weight the relationship data from Training module 205. These weights may also be based on the frequency of the relationship data. For example, employees who email each other frequently will have a stronger weight in their relationship link than employees who email each other infrequently; employees who work on the same projects frequently will have a stronger weight in their relationship link than employees who work on the same projects infrequently. Like the relationships, these weights may be asymmetric in that they may be stronger in one direction than in the other. One of ordinary skill in the art will recognize that there are numerous algorithms for assigning weights, each preferred depending on their intended purpose. The administrator 120 may configure the rules set to apply weights in a manner most advantageous to the intended purpose of the relationship map.
In another embodiment, Relationship Management module 208 generates and displays a visual representation of the relationship map to an employee 130.
In yet another embodiment, administrator 120 or employee 130 may manually create relationships using Relationship Management module 208. For example, employee 130 may be friends with another coworker, but this information is not apparent from ERP data. The employee manually creates a relationship instance to that coworker using Relationship Management module 208. The employee may further manually assign a weight to that relationship.
Thus, Relationship Management module 208 automatically and collaboratively build a representation of formal and informal working relationships among employees in an organization, where such relationship data was previously too onerous to capture manually. Further, this representation may be visually illustrated to a user, enabling the user to navigate among the relationships of their fellow coworkers.
Some embodiments of the invention have been described as computer-implemented processes. It is important to note, however, that those skilled in the art will appreciate that the mechanisms of the invention are capable of being distributed as a program product in a variety of forms. The foregoing description of example embodiments is provided for the purpose of illustrating the principles of the invention, and not in limitation thereof, since the scope of the invention is defined solely by the appended claims.