Patent Publication Number: US-2004054562-A1

Title: Multi-perspective enterprise management tool

Description:
BACKGROUND OF THE INVENTION  
       [0001] 1. Field of the Invention  
       [0002] The present invention relates generally to systems and methods for enterprise management, and more particularly to systems and methods for employee and project management within an enterprise.  
       [0003] 2. Discussion of Background Art  
       [0004] Managers are customarily responsible for not only gathering information about many different projects and reviewing those projects against their original project plans, but also gathering and reviewing information on each project team&#39;s members. To that end, managers must investigate sources of, solicit, compile, and then interpret such employee and project information.  
       [0005] During the investigation stage, a manager must manually identify all outstanding projects as well as those individuals making up each project team. Such investigation often requires that the manager expend a significant amount of effort performing database searches and/or talking to a significant number of employees and project managers, just to get an idea of what everyone is working on.  
       [0006] During the solicitation stage, the manager typically must request a different set of information from each of the team members for each of the projects. These requests are often sent out at differing times and requesting that the information solicited be provided in a variety of different formats. Not only is such a manual procedure laborious for the manager, it is also very time consuming from the point of view of those solicited. For instance, not only must each solicited team member organize the requested information into a variety of different formats, but other such report request contain overlapping fields which the team member must enter again and again into each of the requested reports.  
       [0007] During the compilation stage, the requested information often comes back piecemeal, from differing team members, on differing projects, and over differing work periods. The manager must then spend considerable time collating the information for each project, each employee, and over various time periods. Once collated, the manager must then manually enter the information into one or more reports requested by that manager&#39;s upper management or as individually preferred by that manager for their own use.  
       [0008] Only during the interpretation stage, can the manager finally begin to understand how each project is progressing and how each team member is contributing. While this last stage is the most important, unfortunately most of a manager&#39;s time is spent on the three previous stages. And, by the time this fourth stage is reached collected information may now be outdated.  
       [0009] Due to these latency and other problems, discussed above, individual project team member&#39;s current and future accomplishments, are poorly linked to a project&#39;s overall current and future status. There simply is not an easy and real time way to collect and review both the individual status of a team member concurrent with the global status of a number of projects.  
       [0010] In response to the concerns discussed above, what is needed is a system and method for employee and project management that overcomes the problems of the prior art.  
       SUMMARY OF THE INVENTION  
       [0011] The present invention is a system and method for enterprise management. Within the method of the present invention includes: completing a set of fields within a uniformly formatted employee work record; partitioning the employee work record by project into a set of project specific work records; selecting a subset of the project specific employee work records using a predetermined set of filtering criteria; and generating an enterprise report from the selected subset of work records.  
       [0012] An alternate embodiment of the present invention may include: completing a set of fields within a uniformly formatted project work record having a uniform format; partitioning the project work record by employee into a set of employee specific work records; selecting a subset of the employee specific employee work records using a predetermined set of filtering criteria; and generating an enterprise report from the selected subset of work records.  
       [0013] Other alternate embodiments may include the steps of: selecting a data region within the enterprise report; displaying a subset of work records from the project specific work records which were used to generate the selected data region, in response to the selection, as well as other elements.  
       [0014] The system of the present invention includes all means for effecting the method. These and other aspects of the invention will be recognized by those skilled in the art upon review of the detailed description, drawings, and claims set forth below.  
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0015]FIG. 1 is one embodiment of a method for multi-perspective enterprise management;  
     [0016]FIG. 2 is one embodiment of an overall work record data structure for entering employee work records into an enterprise management tool;  
     [0017]FIG. 3 is one embodiment of a set of project specific work record data structures, partitioned from the overall work record data structure, for organizing work records within the tool;  
     [0018]FIG. 4 is one embodiment of a timeline showing an exemplary set of project specific work records, organized according to their respective date ranges;  
     [0019]FIG. 5 is one embodiment of a project report, generated from the exemplary set of project specific work records;  
     [0020]FIG. 6 is one embodiment of an employee report, generated from the exemplary set of project specific work records; and  
     [0021]FIG. 7 is one embodiment of a budget report, generated from the exemplary set of project specific work records.  
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
     [0022] The present invention provides a system and method for enterprise management, including collecting overall project and individual project team member information using a uniform format for entering work records, which are then compiled into a searchable and filterable time domain database. Results from queries performed on such a work record database can then be displayed to managers using any number of report formats, thus providing managers with multiple perspective views of each project, and each individual team member&#39;s contributions thereto. Using the present invention, a manager can monitor and control activities and costs associated with each team member and project in a much more data and time efficient manner.  
     [0023]FIG. 1 is one embodiment of a method  100  for multi-perspective enterprise management. FIG. 2 is one embodiment of an overall work record data structure  200  for entering employee and/or project work records into a multi-perspective enterprise management tool. FIG. 3 is one embodiment of a set of project specific work record data structures  300 , partitioned from the overall work record data structure, for organizing work records within the enterprise management tool. FIG. 4 is one embodiment of a timeline  400  showing an exemplary set of project specific work records, organized according to their respective date ranges. FIG. 5 is one embodiment of a project report  500 , generated from the exemplary set of project specific work records. FIG. 6 is one embodiment of an employee report  600 , generated from the exemplary set of project specific work records. FIG. 7 is one embodiment of a budget report  700 , generated from the exemplary set of project specific work records. FIGS. 1 through 7 are now discussed together. Note that while the present invention&#39;s example work record data structure is optimized with respect to a set of employee&#39;s entering information on a set of projects which they are currently working on, the present invention&#39;s work record data structure could easily be re-optimized for a program manager entering in information on a set of projects supporting such program, and so on.  
     [0024] The method  100  begins in step  102  where an employee accesses a new uniformly formatted instance of the work record data structure  200 . Uniformly formatted means that the work record format adheres to a consistent format regardless of the employee or project related information entered into the work record. Note, however, that uniformly formatted does not mean that each work record contains an identical set of fields for entering information, rather uniformity is instead tied to a consistent way of entering information into each field which happens to appear in one or more of the work records. The work record data structure  200  may be hosted either by software on the employee&#39;s own computer, or remotely from a network server computer. The work record  200  includes two main sections, a header  202  and a body  204 . In step  104 , the employee identifies themselves within an employee identification field  206 . In the examples to follow, shown in FIGS. 4 through 6, the employee identification field  206  is populated with an employee (A)  404 , an employee (B)  406 , and an employee (C)  408 . Those skilled in the art recognize that in alternate embodiments of the present invention, the employee identification field  206  can be replaced with any type of identification field.  
     [0025] Next in step  106 , the employee enters a starting time and an ending time within a work record date range field  208 . Since, the work records  200  are preferably designed to permit a maximum flexibility for both an employee entering in information, and a manager retrieving the same, the starting and ending time are left to the discretion of the employee. Thus for some employees the date range  208  will be only part of one day, but for others it may be for an entire week. In the FIGS. 4 through 6 examples to follow, the date range field  208  for employee (A)  404  has a starting time (T3) and an ending time of (T6), where T represents an arbitrary time increment. For employee (B)  406 , the date range field  208  for has a starting time (T0) and an ending time of (T8), and for employee (C)  408 , the date range field  208  for has a starting time (T1) and an ending time of (T5).  
     [0026] In step  108 , the employee enters in a project name within a project name field  214  for each project which the employee has worked on during the specified date range  208 . The project name begins with a first project name  210  and may extend to an Nth project name  212 . In the FIGS. 4 through 6 examples to follow, employee (A)  404  has populated the project name field  208  with a project (X)  410  and a project (Y)  412 . Similarly, employee (B)  406  has populated the project name field  208  with project (X)  410 , project (Y)  412 , and a project (Z)  414 . However, employee (C)  408  has populated the project name field  208  with only project (X)  410 .  
     [0027] Next in step  110 , the employee enters in a total time worked, in a time worked field  216 , for each of the projects within the specified date range. For instance, the employee may have worked 2 hours on the first project  210 , and 38 hours on the Nth project  212 . In step  112 , the employee enters in a project status, in a project status field  218 , for each of the projects within the specified date range. For instance, the employee the first project  210  may have a status of “on schedule,” while the Nth project  212  may have a status of “ahead of schedule.” In step  114 , the employee enters in tasks completed, in a tasks completed field  220 , for each of the projects within the specified date range. For instance, tasks completed on the first project  210  may include “preliminary design completed” and “software coding to begin,” while the Nth project  212  has its own set of tasks completed. In step  116 , the employee enters in tasks to be completed, in a tasks to be completed field  220 , for each of the projects within the specified date range. For instance, tasks to be completed on the first project  210  may include “final design signoff” and “initial software testing” and of course the Nth project  212  has its own set of tasks yet to be completed.  
     [0028] In step  118 , each employee&#39;s work record data structure  200  is partitioned by project name. Thus, as shown in FIG. 3, new project specific work record data structures  302  through  304  are created for the first project  210  through the Nth project  212 . Each of the project specific work records  302 ,  304  retain the same header field  202  for that employee. However, the body  204  of each of the project specific work records  302 ,  304  is now associated with only one project name.  
     [0029] The effects steps  106  through  118  are graphically shown using the timeline  400  in FIG. 4. In the figure, employee (A)&#39;s  404  work record for project (X)  410  has been partitioned from the employee (A)&#39;s  404  work record for project (Y)  412 . Note that the partitioned records retain the same date range from (T3) to (T6) as originally entered by employee (A)  404  into the date range field  208 . Similarly, employee (B)&#39;s  406  and employee (C)&#39;s  408  work record partitioning are shown. Next, in step  120 , store each of the project specific employee work records in a predetermined order in a database, such as a time domain database. The records are preferably stored in order of their start time within the date range field  208 . However, the records could alternatively be stored in any other order, such as in order of their project name within the project name field  214 . In the example shown in FIG. 4, employee (B)&#39;s  406  project specific work records are stored in the time domain database first, since their start time is (T0), employee (C)&#39;s  408  project specific work record is stored in the time domain database second, since its start time is (T1), and employee (A)&#39;s  404  project specific work records are store in the time domain database third, since their start time is (T3).  
     [0030] In step  122  a subset of the project specific employee work records are selected using a predetermined set of filtering criteria supplied by the manager, or any other interested party. The filtering criteria can select work records based on any of the data contained in any of the fields  206  through  222 , within the project specific work record.  
     [0031] In step  124 , a predetermined set of reports are generated from the selected subset of work records in a particular format, in response to the manger&#39;s, or another&#39;s, request. Reports may include reports: showing a cumulative time worked by an employee on a predetermined set of projects; showing a cumulative time worked by a set of employees on a predetermined project; comparing a cumulative costs incurred on a project to a cumulative cost budget; and comparing a cumulative cost incurred by an employee on a set of project to a cumulative employee cost budget. In cases where the project specific work records cover a date range longer than a date range increment specified within the particular report format requested, data within the time worked field  216  is averaged/pro-rated based on the requested date range increment.  
     [0032] Examples of some reports that may be generated are shown in FIGS. 5 through 7. In FIG. 5, the project specific work records stored in the time domain database have been selected using “project (X)” and date range increment (T0&gt;T8) filters in order to generate the project report  500 . Thus the project report&#39;s 500 time axis  502  begins at TO, increments by 1, and then ends at T8. A title at the top of the report  500  indicated that the information displayed is for project (X)  410 . A units consumed axis  504  most likely will correspond to either a cumulative “time worked” by all employees, but may also correspond to other units which have meaning to the manager. In the report  500 , since employee (B)  406  work record covered the full T0 through T8 date range, employee (B)&#39;s total time worked in the time worked field  216  is averaged over the entire date range. Thus if employee (B) entered a time worked of 80 hours, then the 80 hours are divided by the eight time increments shown on the time axis  502  and employee (B)&#39;s “time units consumed” is set to 10 hours for each increment. Similar averaging is done for employee (A)&#39;s  404  and employee (C)&#39;s 408 time worked.  
     [0033] In FIG. 6, the project specific work records stored in the time domain database have been selected using “employee (A)” and date range increment (T0&gt;T8) filters in order to generate the employee report  600 . Thus the employee report&#39;s 600 time axis  602  begins at T0, increments by 1, and then ends at T8. A title at the top of the report  600  indicated that the information displayed is for employee (A)  404 . A units consumed axis  504  will typically correspond to the employee&#39;s cumulative time worked on various projects during the date range, which for employee (A)  404 , includes project (X)  410 , project (Y)  412 , and a set of other projects  606 . An expected units consumed indicator  608  helps indicate whether an employee is over-working or under-working. Note, multiple employee reports  600  for different employees may be displayed simultaneously so that the manager can perform “load balancing” throughout the team. In the example shown, employee (A)  404  is neither over-working or under-working since the units consumed during each time period is equal to the expected units consumed indicator  608 .  
     [0034] In FIG. 7, a budget report  700  has been generated using the project specific work records stored in the time domain database which have been filtered using “project (X)” and date range increment (T0&gt;T8) filters. Additional information on project revenue/budget and employee pay rates has also been factored in using known financial analysis equations. Thus, the budget report  700  shows at a glance whether or not a project in within or beyond the revenue received and/or budget allowed.  
     [0035] The budget report  700  can easily be modified to track an individual employee&#39;s costs, as well as for any number of employee work teams. Those skilled in the art will recognize that many different types of reports can also be generated using the employee work record data structure  200 .  
     [0036] In step  126 , the manager selects a particular data region within one of the reports. For example, the manager may use a mouse control to click on employee (A)&#39;s  404  activity on project (X)  410  between times T3 and T4 in FIG. 5, as shown by the shaded parallel vertical lines. In step  128 , a subset of work records from the project specific work records used to generate the selected data region are displayed to the user, in response to the selection step. Thus each region on a report is hyperlinked to a relevant employee work record. In the example shown, the employee&#39;s project specific work record  302  corresponding to project (X)  410  is, or all of the employee&#39;s work records  200  are, presented to the manager.  
     [0037] In this way, the manager can view that employee&#39;s detailed information regarding that work record, and including information within: the time worked field  216 , the project status field  218 , the tasks completed field  220 , and the tasks to be completed field  220 . Those skilled in the art recognize that the present invention&#39;s data structure  100  can be scaled to any number of employees, projects, and/or other information deemed important to a user of the present invention.  
     [0038] While one or more embodiments of the present invention have been described, those skilled in the art will recognize that various modifications may be made. Variations upon and modifications to these embodiments are provided by the present invention, which is limited only by the following claims.