Patent Application
20220230121
One embodiment is directed generally to a computer system, and in particular to modeling expectation mismatches with a computer system.
A performance appraisal, also referred to as a performance review, performance evaluation, or employee appraisal, is a method by which the job performance of an employee is documented and evaluated. Performance appraisals are a part of career development and consist of regular reviews of employee performance within organizations.
Performance appraisals are most often conducted by an immediate manager/supervisor, such as line managers or front-line managers. While assessment can be performed along reporting relationships (usually top-down), net assessment can include peer and self-assessment. Peer assessment is when assessment is performed by colleagues along both horizontal (similar function) and vertical (different function) relationships. Self-assessments are when individuals evaluate themselves.
Peer assessments and self-assessments are increasingly popular and are typically combined as a “360-degree feedback” (also known as multi-rater feedback, multi source feedback, or multi source assessment). 360-degree feedback is a process through which feedback from an employee's subordinates, colleagues, and supervisor(s), as well as a self-evaluation by the employee themselves is gathered. Such feedback can also include, when relevant, feedback from external sources who interact with the employee, such as customers and suppliers or other interested stakeholders. 360-degree feedback is so named because it solicits feedback regarding an employee's behavior from a variety of points of view (subordinate, lateral, and supervisory). It therefore may be contrasted with “downward feedback” (traditional feedback on work behavior and performance delivered to subordinates by supervisory or management employees only), or “upward feedback” delivered to supervisory or management employees by subordinates only.
Organizations have most commonly utilized 360-degree feedback for developmental purposes, providing it to employees to assist them in developing work skills and behaviors. However, organizations are increasingly using 360-degree feedback in performance evaluations and employment decisions (e.g., pay decisions, promotions, etc.). When 360-degree feedback is used for performance evaluation purposes, it is sometimes called a “360-degree review”.
However, due to complexities in modeling and data analysis, most organizations rely primarily on or heavily emphasize the supervisor's evaluation over all of the evaluations. Enterprise-wide Human Capital Management systems in general fail to model or perform data analytics on the other sources of evaluations.
Embodiments of the invention determine mismatches in evaluations. Embodiments receive a first evaluation of an employee from a supervisor of the employee, the first evaluation including supervisor comment ratings and supervisor numerical ratings, each of the supervisor comment ratings and supervisor numerical ratings corresponding to an evaluation category. Embodiments receive a second evaluation of the employee from the employee, the second evaluation including employee comment ratings and employee numerical ratings, each of the employee comment ratings and employee numerical ratings corresponding to the evaluation category. Embodiments determine first sentiment polarity scores of the supervisor comment ratings and second sentiment polarity scores of the employee comment ratings. Embodiments determine polarity mismatch scores based on the first sentiment polarity scores and the second sentiment polarity scores and determine average differential ratings based on the supervisor numerical ratings and the employee numerical ratings. Embodiments then combine the polarity mismatch scores and the average differential ratings to generate a final expectations mismatch score for the employee.
Embodiments receive evaluations in numerical and textual form from both a supervisor and respective employee via a self-assessment or a 360-degree review, as discussed above. Embodiments use data analysis and natural language processing to quantify and model expectation “mismatches” between employees and supervisors, and uses the mismatches as an added tool in the evaluation.
Often in Human Capital Management (“HCM”) in any organization there are mismatches in expectations between employees and their supervisors. This generally remains unnoticed in known HCM business intelligence analysis/reporting systems because, as discussed above, the emphasis is typically on how the supervisor is rating the employees. The employee's perspective is rarely taken into consideration, even if the evaluation system receives this information. Therefore, if not identified early, mismatched expectations may lead to abrupt attritions or terminations. Still further, mismatched expectations impacts employee productivity and thus the organization itself.
Reference will now be made in detail to the embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to one of ordinary skill in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Wherever possible, like reference numbers will be used for like elements.
In one embodiment, system 100 is a computing/data processing system including an application or collection of distributed applications for enterprise organizations. The applications and computing system 100 may be configured to operate with or be implemented as a cloud-based networking system, a software-as-a-service (“SaaS”) architecture, or other type of computing solution.
In one embodiment, mismatched expectations modeling tool 110 is implemented on computing device 105 and includes logics or modules for implementing various functional aspects of mismatched expectations modeling tool 110. In one embodiment, mismatched expectations modeling tool 110 includes a visual user interface logic/module 120, an artificial intelligence (“AI”) based text sentiment analyzer logic/module 130, an expectations mismatch scoring logic/module 140, and an expectations mismatch analytics logic/module 150.
Other embodiments may provide different logics or combinations of logics that provide the same or similar functionality as mismatched expectations modeling tool 110 of
Computer system 100 also includes a display screen 24 operably connected to computing device 105. In accordance with one embodiment, display screen 24 is implemented to display views of and facilitate user interaction with a graphical user interface (“GUI”) generated by visual user interface logic 120 for viewing and updating information associated with mismatched expectations (i.e., input ratings and comments, output rankings, analytical graphs, etc.). The graphical user interface may be associated with a mismatch expectations analytics and visual user interface logic 120 may be configured to generate the graphical user interface.
In one embodiment, computer system 100 is a centralized server-side application that provides at least the functions disclosed herein and that is accessed by many users via computing devices/terminals communicating with the computer system 100 (functioning as the server) over a computer network. Therefore, display screen 24 may represent multiple computing devices/terminals that allow users to access and receive services from mismatched expectations modeling tool 110 via networked computer communications.
In one embodiment, computer system 100 further includes at least one database 17 operably connected to computing device 105 and/or a network interface to access database 17 via a network connection. For example, in one embodiment, database 17 is operably connected to visual user interface logic 120. In accordance with one embodiment, database 17 is configured to store and manage data structures associated with mismatched expectations modeling tool 110 in a database system.
In one embodiment, visual user interface logic 120 is configured to generate a graphical user interface (“GUI”) to facilitate user interaction with mismatched expectations modeling tool 110. For example, visual user interface logic 120 includes program code that generates and causes the graphical user interface to be displayed based on an implemented graphical design of the interface. In response to user actions and selections via the GUI, associated aspects of generating mismatched expectations analytics and modeling may be generated.
In one embodiment, artificial intelligence based text sentiment analyzer logic/module 130 is configured to use artificial intelligence (“AI”) (e.g., a neural network) in certain embodiments to generate a sentiment and the polarity of the sentiment from comments by supervisors and employees, as disclosed below.
In one embodiment, expectations mismatch scoring logic/module 140 is configured to generate scoring from the sentiment generated by logic 130 as well as evaluation numeric ratings. In one embodiment, expectations mismatch analytics logic/module 150 is configured to generate analytics and modeling from the scoring generated by logic 140, including rankings and graphical interpretations of the mismatches.
In embodiments, the expectations mismatch scoring is generated as a specialized data structure that includes attributes of each of the employees and supervisors. In embodiments, the specialized data structure is in the form of an electronic document (e.g., an XML document) and is stored in database 17. A “data structure,” as used herein, is an organization of data in a computing system that is stored in a memory, a storage device, or other computerized system. A data structure may be any one of, for example, a data field, a data file, a data array, a data record, a database, a data table, a graph, a tree, a linked list, and so on. A data structure may be formed from and contain many other data structures (e.g., a database includes many data records). Other examples of data structures are possible as well, in accordance with other embodiments.
System 100 includes a bus 12 or other communication mechanism for communicating information, and a processor 22 coupled to bus 12 for processing information. Processor 22 may be any type of general or specific purpose processor. System 100 further includes a memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of computer readable media. System 100 further includes a communication device 20, such as a network interface card, to provide access to a network. Therefore, a user may interface with system 100 directly, or remotely through a network, or any other method.
Computer readable media may be any available media that can be accessed by processor 22 and includes both volatile and nonvolatile media, removable and non-removable media, and communication media. Communication media may include computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media.
Processor 22 is further coupled via bus 12 to display 24, such as a Liquid Crystal Display (“LCD”). A keyboard 26 and a cursor control device 28, such as a computer mouse, are further coupled to bus 12 to enable a user to interface with system 100.
In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. The modules include an operating system 15 that provides operating system functionality for system 100. The modules further include an expectations mismatch modeling module 16 that implements one or more of modules 120, 130, 140, 150, and all other functionality disclosed herein. System 100 can be part of a larger system. Therefore, system 100 can include one or more additional functional modules 18 to include the additional functionality, such as an HCM enterprise application (e.g., the “Oracle Cloud Human Capital Management” from Oracle Corp.). Database 17 is coupled to bus 12 to provide centralized storage for modules 16 and 18 and store employee evaluation information, corporate hierarchies, etc. In one embodiment, database 17 is a relational database management system (“RDBMS”) that can use Structured Query Language (“SQL”) to manage the stored data.
In one embodiment, particularly when there are a large number supervisors and employees, database 17 is implemented as an in-memory database (“IMDB”). An IMDB is a database management system that primarily relies on main memory for computer data storage. It is contrasted with database management systems that employ a disk storage mechanism. Main memory databases are faster than disk-optimized databases because disk access is slower than memory access, the internal optimization algorithms are simpler and execute fewer CPU instructions. Accessing data in memory eliminates seek time when querying the data, which provides faster and more predictable performance than disk.
In one embodiment, database 17, when implemented as a IMDB, is implemented based on a distributed data grid. A distributed data grid is a system in which a collection of computer servers work together in one or more clusters to manage information and related operations, such as computations, within a distributed or clustered environment. A distributed data grid can be used to manage application objects and data that are shared across the servers. A distributed data grid provides low response time, high throughput, predictable scalability, continuous availability, and information reliability. In particular examples, distributed data grids, such as, e.g., the “Oracle Coherence” data grid from Oracle Corp., store information in-memory to achieve higher performance, and employ redundancy in keeping copies of that information synchronized across multiple servers, thus ensuring resiliency of the system and continued availability of the data in the event of failure of a server.
In one embodiment, system 100 is a computing/data processing system including an application or collection of distributed applications for enterprise organizations, and may also implement logistics, manufacturing, and inventory management functionality. The applications and computing system 100 may be configured to operate with or be implemented as a cloud-based networking system, a software-as-a-service (“SaaS”) architecture, or other type of computing solution.
At 302, embodiments fetch/retrieve input evaluation data, including both employee comments and ratings, and supervisor comments and ratings as part of a peer assessment, self-assessment or 360-degree review process. In embodiments, this data is retrieved from an HCM. Table 1 below illustrates some example input data:
The data includes in Table 1 includes the following
Table 2 below is an expanded version of Table 1 in that it includes multiple evaluation categories (shown in the “Evaluation Category ID” column as 1231, 1232, 1233, etc.). For example, for single employee/supervisor pairings, evaluation categories may include “leadership”, “communication”, “attendance”, “problem-solving”, etc.
After 302, the evaluation data in embodiments includes at least employee comments, supervisor comments, employee self-evaluation rating, supervisor rating, and employee and supervisor descriptive attributes (e.g., name, department and other details).
At 304, text analytics is performed on the comments received at 302. The textual analytics of the textual comments provided by both employees and supervisors are used to generate a sentiment polarity of each comment. In one embodiment, the lexicon based “TextBlob” python library is used to determine the polarity for employee and supervisor comments. The TextBlob library is a lexicon and rule-based sentiment analysis library. For lexicon-based approaches, a sentiment is defined by its semantic orientation and the intensity of each word in the sentence. Based on the polarity and subjectivity, it is determined whether it is a positive text or negative or neutral. For TextBlob, if the polarity is >0, it is considered positive, <0 is considered negative, and =0 is considered neutral.
In other embodiments, an artificial neural network or other type of artificial intelligence is used to perform the textual analytics, including sentiment analysis and polarity determination, at 304. In embodiments, the neural network is trained by processing examples, each of which contains a known “input” and “result,” forming probability-weighted associations between the two, which are stored within the data structure of the net itself. The training of the neural network from a given example is conducted by determining the difference between the processed output of the network (often a prediction) and a target output, which is the “error”. The network then adjusts its weighted associations according to a learning rule and using this error value. Successive adjustments cause the neural network to produce output which is increasingly similar to the target output. After a sufficient number of these adjustments the training is terminated based upon certain criteria, known as “supervised learning.”
Further details on using a neural network or other AI type implementation to perform the textual analytics at 304 of semantic analysis and polarity assignment is disclosed, for example, in U.S. Pat. Pub. Nos. 2020/0394478, the disclosure of which is incorporated by reference. In this embodiment, a word embedding model including a first plurality of features is generated. A value indicating sentiment for the words in the first data set can be determined using a convolutional neural network (“CNN”). A second plurality of features are generated based on bigrams identified in the data set. The bigrams can be generated using a co-occurrence graph. The model is updated to include the second plurality of features, and sentiment analysis can be performed on a second data set using the updated model. In other embodiments, other techniques for using a neural network for semantic analysis and polarity assignment, such as disclosed in U.S. Pat. Pub. Nos. 2017/0249389 and 2020/0286000, are implemented. In other embodiments, any other text based sentiment analysis method to generate the sentiments polarity of any comment, including machine learning-based, lexicon-based or a hybrid approach or any other known form of Natural Language Processing (“NLP”) can be used at 304.
Table 3 below illustrates some example polarity calculations at 304 in example embodiments.
At 306, embodiments determine a mismatch “score” that quantifies the mismatch between the comments from the employee and the supervisor. Any comment that the employee gives is as per his/her expectation. Comments provided by the supervisor is the actual values from the perspective of any organization. Keeping this in perspective, the employee's expectation mismatch is determined as follows: (1) Determine the difference between the employee comment polarity and the supervisor comment polarity for each evaluation item; (2) Determine the square of the difference in polarity for each evaluation item; (3) Determine the summation of the square of the difference grouped by employee; (4) Count the number of evaluation items for each employee on which the person has been rated; (5) Divide the summation by the number of evaluation items for each employee; and (6) Determine the square root of the division output to get the final value of aggregated polarity mismatch score for each employee. Pseudo-code for performing this functionality is as follows:
Table 4 below illustrates some example polarity mismatch scores between employee and supervisor as determined above:
Embodiments then rescale the score to a 0-1 scale. The above polarity range is within −1 to 1, and embodiments convert the polarity values on a scale of 0 to 1. This allows it to be comparable with the numerical rating scores, calculated below, so they can be merged together. Pseudocode for comments rescaling is as follows:
Polarity_Scaled_Score=Polarity_Mismatch_Score/range of polarity Range of polarity in current example is 2 (between 1 and −1).
Table 5 below illustrates some example scaled polarity mismatch scores between employee and supervisor as determined above:
At 308, embodiments implement numerical ratings analytics of the numerical ratings provided by the employees and supervisors. As input are the numerical ratings from the employee and supervisor—a self-rating that the employee gives which reflects the employee's expectation and the ratings given by the employee's supervisor that is the actual rating from the perspective of the organization. Embodiments perform analytics to determine if there is a mismatch against the employee.
For each employee, embodiments check and store the average difference in the employee and supervisor ratings. If the average difference is positive, this means it is not as per the employee's expectation. If the average is negative it denotes a hand-in-hand scenario (i.e., some kind of unethical understanding to favor an employee/supervisor). Pseudocode for the ratings analytics is as follows:
Difference_in_Rating=Employee_Rating−Supervisor_Rating Avg_Diff_Rating=Mean(Difference In Rating)
Table 6 below illustrates some example rating differentials between employee and supervisor as determined above:
Next, for each employee, embodiments determine a mismatch score based on the expected versus actual numerical appraisal ratings. Embodiments determine the mismatch score as follows: (1) Determine the difference between the employee rating and the supervisor rating for each item/category; (2) Determine the square of the difference in rating for each item; (3) Determine the summation of the square of the difference grouped by employee; (4) Count the number of items for each employee; (5) Divide the summation by the number of items for each employee; and (6) Determine the square root of the division output to get the final value of aggregated rating mismatch score for each employee. Pseudocode for determining the numerical rating mismatch score is as follows:
Table 7 below illustrates some example numerical rating mismatch score differentials between an employee and supervisor as determined above:
Embodiments then re-scale the score on a 0-1 scale because the rating range depends on the minimum and maximum values of the rating model. This is so the numerical rating scores are comparable with the comments polarity scores. In examples, the rating scale is 1-5 and therefore the maximum difference can be 4. Different scales can be used in other embodiments. Pseudocode for numerical ratings rescaling is as follows:
Rating_Scaled_Score=Rating_Mismatch_Score/Range of rating difference Range of rating difference in current example is 4 (for rating on a scale of 1-5).
Table 8 below illustrates some example scaled numerical rating mismatch scores between employee and supervisor as determined above:
At 310, the comment based scaled scores from 306 and the numerical rating based scaled scores from 308 are combined to generate what is referred to as the final expectation mismatch score (“FEMS”). Because text/comment based polarity scores are more error prone as it has various dependencies, embodiments individually weight each of the scores to generate a final score. In one example, the following weighting is used:
The weighting can be changed based on the accuracy of the text analysis model or based on other factors. Pseudocode for score weighting is as follows:
For each employee:
Final_Expectation_Mismatch_Score (FEMS)=Polarity_Scaled_Score*Weight_Comments+Rating_Scaled_Score*Weight_Rating*Weight_Comments−0.4, Weight_Rating−0.6
Table 9 below illustrates some example final expectation mismatch scores (“FEMS”) as determined above:
At 312, embodiments rank the scores and create visualization of the scores for additional analytic insight. Embodiments divide the scoring into two categories: (1) General cases; and (2) Exception cases where an employee's average self-rating is lower (i.e., worse) than the supervisor rating. These cases are identified on the basis of the “Avg_Diff_Rating”determined above. If the Avg_Diff_Rating for an employee is negative, it is considered as an exception. Otherwise, it is a general case.
Using the above example, the general cases and exception case is shown in the tables below:
The mismatch scores generated by embodiments are at a per-employee level and can be determined for any evaluation cycle. The scores can be used as an independent variable in various analysis, such as determining attrition (i.e., determine employees most likely to leave) or for any employee-based recommendations where a training or a promotion or transfer can be proposed to retain the employee.
Further, the scores can be input into a dashboard application for people such as chief human resource officer (“CHRO”), executives, etc., as it can easily be sliced and diced at Manager Hierarchies to find top unsatisfied employees or a count of unsatisfied employees.
These scores pull out and summarize only meaningful data from the less important data on any dashboard specifically designed for CHRO or executives to provide a fine grain analysis using dimensions. For example,
As disclosed, embodiments, leverage multiple aspects of appraisal evaluations in one single frame to provide a holistic understanding of employee-supervisor relations. Embodiments provide a holistic approach by including the employee's perspective along with the supervisor's perspective, which includes comments from various participants as well as their numerical ratings. Embodiments combine employee-supervisor sentiment mismatch with employee-supervisor rating mismatch on the evaluations done by managers to judge an overall mismatch in expectation in terms of a scored (i.e., the FEMS).
Embodiments can be re-used with many other models on various use cases such as attrition or recommendations on employees in HCM and can be used in systems such as talent management, global human resources, performance management, etc. Embodiments can be used with dimensional querying to provide a list of Supervisors/Managers for whom the overall satisfaction scores are either high or low and take necessary actions. Embodiments can also be used to provide information such as mismatch on performance goals, mismatch on development goals etc.
Embodiments provide a novel perspective to employee satisfaction under a manager hierarchy, a new metric which compares the comments of all the participants and the corresponding ratings in one single analysis and provides a consolidated score on expectation mismatch of employee. Because the generated scores are at the employee level, a dashboard application can be used to slice and dice the data at manager hierarchies to find top unsatisfied employees or generate a count of unsatisfied employees. The scoring can also be sliced on evaluation item types, such as development goals or performance goals. Each type either can be scored together or separately, thus providing a novel metric in HCM that enhances attritions or terminations models and can also be used in various recommendation model on employee or managers. Embodiments help in early diagnosis of Employee-Supervisor relations and as a result helps in increasing productivity and job satisfaction. In embodiments where there is no text analytics support, the ranking can be performed using only the numeric rating model.
Several embodiments are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the disclosed embodiments are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
