Patent Application
20150088578
The disclosure relates to the field of enterprise systems and applications and more particularly to techniques for project management alerts using heterogeneous project data.
Day-by-day, business is becoming more and more globalized. Historically, projects (e.g., building projects, defense projects, product development projects, software development projects, etc.) have been performed substantially locally, and project management such as cost accounting has been provided locally as well. Yet, in the globalized economies of today, performance of portions of a project and decision-making pertaining to a project might be performed in various locations, including in different countries. Different countries may use different project management and project accounting techniques (e.g., cost basis, accrual basis, etc.), and/or different measurement units (e.g., kilograms, pounds, etc.), and/or different currency units (e.g., dollars, yen, etc.).
A project manager would want to receive an alert when some threshold or limit has been reached (e.g., dollars expended), or a milestone reached (e.g., number of square feet of foundation poured). Even if the project manager set a limit of $1,000,000 dollars to be spent on capital equipment, and the staff in Germany just spent 733,000 euros on capital equipment, the project manager would still want to receive an alert, even though the number “733,000” is less than “1,000,000”.
Still worse, a particular project might have a large number of accounts (e.g., a capital expense account, depreciation accounts, manpower accounts, bank accounts, etc.), and/or a large number of spending limits to manage which makes the task of managing a portfolio of projects is even more challenging. Especially when a project comprises or touches a large volume of accounts, a project manager needs alerts in order to be able to quickly identify activity affecting an account (e.g., so remedial action can be taken). However, with a large number of accounts, the problem is akin to the task of “finding a needle in a haystack”.
Legacy project management applications, and legacy project accounting software systems fail to account for differing units and/or other disparities in heterogeneous data when calculating alerts and thresholds for alerts. Therefore, there is a need for improvements.
The present disclosure provides an improved method, system, and computer program product suited to address the aforementioned issues with legacy approaches. More specifically, the present disclosure provides a detailed description of techniques used in methods, systems, and computer program products for project management alerts using heterogeneous project data.
Embodiments commence upon identifying a first account ledger of first data items and a second account ledger of second data items, then identifying a first data item that is stored in a first unit of measurement (e.g., US Dollars), and further identifying a second data item that is stored in a second unit of measurement (e.g., Euros). Configuration steps associate relationships or calculations (e.g., sums, maximums, conversions, etc.) between the first data item and the second data item. When the value of the first data item or the value of the second data item is changed (e.g., by a user-changed value or by a calculation affecting the data item), then alert logic is invoked. When the relationship (e.g., sum) between the first data item and the second data item is outside of a pre-calculated range or value (e.g., balance overdrawn), then an alert is raised. The relationship between the first data item and the second data item can comprise any number of alert threshold values. The relationships and/or calculations between the first data item and the second data item can comprise a currency exchange rate.
Further details of aspects, objectives, and advantages of the disclosure are described below and in the detailed description, drawings, and claims. Both the foregoing general description of the background and the following detailed description are exemplary and explanatory, and are not intended to be limiting as to the scope of the claims.
Some embodiments of the present disclosure address problems pertaining to managing multiple activities within a project, and some embodiments are directed to approaches for forming project management alerts. More particularly, disclosed herein and in the accompanying figures are exemplary environments, methods, and systems for project management alerts using heterogeneous project data.
A project manager needs to be able to easily interpret project status, even though the project status might derive from disparate data sources. A technique to receive values from different sources (e.g., in different measurement or reporting units), and to reconcile those differing values is needed. This need becomes exacerbated inasmuch as business continues to become more and more globalized. Historically, projects (e.g., building projects, defense projects, product development projects, software development projects, etc.) have been performed substantially locally, and project management such as cost accounting was provided locally as well. Yet, in the globalized economies of today, performance of portions of a project and decision-making pertaining to a project might be performed in various locations, including in different countries. Different countries may use different project management and project accounting techniques (e.g., cost basis, accrual basis, etc.), and/or different measurement units (e.g., kilograms, pounds, etc.), and/or different currency units (e.g., dollars, yen, etc.). A project manager would want to receive an alert when some threshold or limit has been reached (e.g., dollars expended), or a milestone reached (e.g., number of square feet of foundation poured). If the project manager set a limit of $1,000,000 dollars to be spent on capital equipment, and the staff in Germany just spent 733,000 euros on capital equipment, the project manager would want to receive an alert (even though the number “733,000” is less than the number “1,000,000”). A technique to receive values in different measurement or reporting units, to reconcile those differing values, and to compare the reconciled values (e.g., converted values, normalized values) to a normalized threshold value or alert value is needed.
Indeed, managing a single complex project is a challenge for any project manager. A particular project might have a large number of underlying accounts (e.g., a capital expense account, depreciation accounts, manpower accounts, bank accounts, etc.). The task of managing a portfolio of projects is even more challenging, yet it is essential to be able to understand and assess the state of their business at any point in time. Even when a project comprises or touches a large volume of accounts, a project manager needs alerts in order to be able to quickly identify activity affecting an account (e.g., so remedial action can be taken). However, with a large number of accounts, the problem is akin to the task of “finding a needle in a haystack”.
In addition to the problem caused by the volume of data, the fact that projects are managed in many different measurement units and currencies makes analyzing the amounts at the account level overwhelming to a project manager.
The solutions described herein encompass multiple use models, many different functions, and many different techniques for raising alerts. Strictly as examples of operations over account ledgers (e.g., an account of transactions stored in a data structure):
In exemplary embodiments, the project manager performs some configuration steps, and, once configured, even tens of thousands of accounts (or more), any of which comprise data stored in differing units can be managed, and summarized for ease of identifying accounts that are in need of project management attention. Configuration can comprise identifying ledgers, any of which might comprise data items using disparate units of measurement, and then defining a relationship between a first data item (e.g., in one unit of measurement) and a second data item (e.g., in a second unit of measurement).
Continuously or periodically during progression of the project, alert conditions, possibly including applying thresholds are considered, and if the alert is raised (e.g., when the relationship between the first data item and the second data item is outside of a pre-calculated range or value) then an indication (e.g., a visual indication) is emitted.
Projects can include many geographically distant activities, any activity having many project accounting ledgers; the herein-disclosed systems can nevertheless reconcile differences in measurements and/or currencies. Such projects and systems for project management are further described below and in the accompanying figures.
Some of the terms used in this description are defined below for easy reference. The presented terms and their respective definitions are not rigidly restricted to these definitions—a term may be further defined by the term's use within this disclosure.
Reference is now made in detail to certain embodiments. The disclosed embodiments are not intended to be limiting of the claims.
As shown, a project is organized into a hierarchy having a project level 102, which in turn has several project activities (e.g., activity A 104, activity B 106, activity C 108, etc.). In this illustration, the various project activities are geographically distant. As shown, activity A 104 is centered in the United States of America, activity B 106 is centered in the European Union, and activity C 108 is centered in Japan. Each activity in each geography manages its own set of aspects of the overall project, and a project manager (e.g., PMA 112, PMB 114, PMC 116) assigned to each activity manages its own activities. A local project manager interacts with local project resources (e.g., employees, suppliers, customers, etc.), and data items pertaining to the project are stored (e.g., in dataA 118, dataB 121, dataC 122, etc.). In some cases a local project manager might interact with a localized enterprise application in order to record and otherwise manage the progression of the project. Enterprise applications might include an enterprise resource planning (ERP) application, and/or a budgeting application, and/or an accounts payable application, and/or an accounts receivable application, etc. Data items pertaining to the project (e.g., in dataA 118, dataB 121, dataC 122, etc.) can be stored in accounts (e.g., account A 124, account B 126, account C 128, etc.), which in turn can be represented in data structures such as arrays, and/or relations (e.g., in a relational database), and/or as tables (as shown), and an account representation can include a ledger, which in turn can include a ledger balance.
A local project manager might want to monitor the progression of the project using the stored data items. For example, a local project manager (e.g., a local project manager situated in Seattle, Wash.) might want to know how many project dollars have been spent on “consulting services” and/or might want to know how many pounds of “powdered magnesium” have been consumed on-site since the beginning of the year. Similarly, a local project manager (e.g., a local project manager situated in Toulouse, France) might want to know how many euros have been spent on “consulting services” and/or might want to know how many kilograms of “powdered magnesium” have been consumed on-site since the beginning of the year. Similarly, a local project manager (e.g., a local project manager situated in Tokyo, Japan) might want to know how many yen have been spent on “consulting services” and/or might want to know how many kilograms of “powdered magnesium” have been consumed since the beginning of the year. As can now be noted, each activity might manage and store data items in units that are convenient for that locale (e.g., dollars, euros, yen, pounds, kilograms, etc.).
Also shown in
Any of the aforementioned applications can be implemented in an application server. An illustrative environment includes multiple application servers, a database server, and middleware to host interfaces (e.g., web servers) situated between a user and applications.
As shown, environment 1B00 comprises an application server 1510 that hosts any number of applications (e.g., enterprise application 1520, project management application 154, etc.). The application server 1510 stores data to a database (e.g., in a database server 160) which in turn stores data that is represented in data structures such as arrays and/or relations and/or as tables (e.g., table A and table B). Other application servers can access the database server 160. For example application server 151G1 might be installed in Seattle, and application server 151G2 might be installed in Tokyo, and both can access the database server 160. Moreover an application server can host any number of enterprise applications (e.g., enterprise application 1520, enterprise application 1521, enterprise application 1522, project management application 154, etc.).
To facilitate user interaction, middleware components may be provided in any geography (e.g., web server 1530, web server 153G1, web server 153G2, etc.). In particular, a project management application 154 can be deployed in any geography and/or run on any application server, and interface with any middleware component. Similarly, project accounts and any constituent data items stored in database server 160 can be shared (e.g., for READ, WRITE and/or other accesses) by any application. Such a sharing mechanism, and other exemplary sharing configurations across multiple enterprise applications, are later discussed in
As shown, the flow commences when a user associates an alert with a user-defined basis amount or logical outcome such as an account basis value (see operation 181). Having such a user-defined basis value, the user can associate any number of threshold values with the user-defined basis value or logical outcome (see operation 183). An alert is raised if the For example, if the basis value comprising the sum of the cost (e.g., recorded in euros) of a daily material use by the German team and the costs of the daily material use by the Chinese (e.g., recorded in RMB) team exceeds a threshold of $20,000 USD (the basis value), then raise an alert.
A particular alert might be configured to apply to multiple accounts, and/or to a range of accounts. Accordingly a user might identify an account or range of accounts to which the alert applies (see operation 185). Processing continues when the system evaluates the account or range of accounts to which the alert applies (see operation 187), and a GUI or other human interface displays a visual indicator for accounts that are in an alert state. In addition to a visual alert and/or an audio alert, (see operation 188) some situations admit propagation of a visual alert and/or an audio alert to be emitted upon user navigation to an account summary (see operation 189). In some cases, the summary display might comprise a display of multiple accounts in an alert state. Visual alert indications can be applied to multiple accounts in a summary screen, or can be applied to multiple rows in an account display. In this manner, even projects that comprise thousands of accounts can be managed inasmuch as the summary screen can show only accounts that need attention (e.g., accounts that are in an alert state).
As shown, enterprise applications take in inputs 202 (e.g., purchase events, payment events, invoices, etc.) and performs one or more processing steps on the inputs (e.g., see account transaction 204) and produces outputs 206, which can be stored in appropriate accounts 232. An enterprise application may include facilities to display account data in account views (e.g., account view A, account view B, etc.), and may further comprise facilities to present reports (e.g., see enterprise application reports 240).
The data items stored by the enterprise applications can be accessed by a project management application 104, which in turn comprises an alert processor 210 and alert logic 132. Alert logic 132 can access configuration data (e.g., config 1401) and can process data items and raise alerts in accordance with the configuration data. A project management application may include facilities to display project management data in account views (e.g., account view A, account view B, etc.) and/or a summary view (e.g., summary 130), and may further comprise facilities to present reports (e.g., see project management reports 230).
The aforementioned project management reports can be configured to alert the user when any data item in the project reaches or exceeds a given value (e.g., a threshold value). And/or project management reports can be configured to alert the user when any combination of data items in the project reaches or exceeds a given value. When a combination is used, the local units used for the stored data item value can be normalized to account for differences in the local units.
Returning to the example of
The foregoing describes techniques to calculate and trigger an alert. Additional techniques can be employed, including techniques to raise an alert and display or otherwise indicate that a project-wise data item value or threshold has been reached or surpassed. Such additional techniques are shown and described as pertaining to
As shown, the flow commences upon configuration of alerts to be considered as the project progresses (see operation 302). Then, in a loop, an alert processor accesses constituent data tables and pre-processes data used for calculating and raising alerts (see operation 304). For example, a currency data item in an account might need to be converted into a normalized currency (e.g., YEN to DOLLAR). For each account in the summary configuration, the flow processes each row in the account and calculates an alert or the fact that there is no alert (see operation 306). An alert can be raised at that moment in time, or a set of alerts can be held until such a time as the alerts can be categorized. The shown operation 308 serves to summarize alerts by category based on a summary screen configuration. Such a configuration may include alert levels such as “critical”, “urgent”, “warning”, etc. (see operation 310) and the level of any given alert can be presented using a visual indication in a summary screen.
If there are more accounts in a project, or more projects to summarize, decision 312 is taken to path 313, and the flow from operation 304 to operation 310 executes again. In some cases, a user might want to change configuration settings, and in such a case decision 314 is taken to again perform configuration steps (see operation 302). Such configuration can include specification of a common currency, and/or currency rate tables, and/or currency thresholds. In some cases, a data item (e.g., a column in a table) can be regarded as a currency or can be treated “as if” it is a currency (e.g., observing conversion rules and conversion table). Such cases are presently discussed.
The operation flow 3B00 commences upon receipt of an indication of a column to be used in forming an alert (see operation 318). Such an indication can arise from a user or from configuration data (e.g., see config 140). Decision 320 determines if the column indicated is a currency value (or if it is intended to be treated as a currency value). If so, a corresponding threshold is retrieved (e.g., from a user or from configuration data) and decision 322 determines if the threshold is based on a currency. If so, processing continues to operation 324 to reconcile threshold values to match units of the received columns. Once reconciled, the threshold is stored (see operation 326) and the alert logic will raise an alert when the threshold is reached or surpassed.
In other cases, the alert is to be raised when a data item value is found to be outside of a given range. Some examples of range processing are included in the discussion of
The flow receives a set of tables or accounts, comprising heterogeneous project data, and portion of the flow is iterated over a set of tables or accounts. As shown in loop 336, for each of a set of given accounts, processing is performed over all rows of the account until done. While there remain more rows to process, the operation 341 determines if there is an alert on a column or cell, and if so, selects the alert and corresponding value before proceeding to decision 338. Decision 338 determines if the alert should be processed against a named range of accounts. In the situation as shown, the determination as to if the alert and value should be processed against a range specification can be determined based on the existence of a pre-configured range name. If the alert does have a range name, then the account identification is compared with the bounds as described by the pre-configured named range, and if the account identification outside of the bounds of the range (see operation 340), then the selected alert does not apply (see operation 348). Otherwise, the selected value and alert basis considered (see operation 342), and compared using thresholds (see operation 344) to determine if the value surpasses the threshold (see operation 346), and if so, an alert is raised for this value and the flow returns TRUE (see operation 350). There are many situations when a value is subjected to multiple thresholds, yet there is a basis or reasoning why an alert is not raised. Examples include situations where a first-tested value (e.g., an instantaneous value) surpasses a first threshold, yet a second tested value (e.g., a daily limit) is not surpassed. Such situations can be captured in an alert basis column.
An alert can be created to evaluate against not only a single value (e.g., a value from a single account ledger balance), but also, an alert can fire based on evaluation of user-defined formulas which operate over values retrieved from or derived from multiple account ledgers and/or based on other numeric or logical factors.
In any of the aforementioned cases, an alert basis column value is compared to its corresponding threshold or thresholds (see operation 344), and when the compared value surpasses one or more of its corresponding thresholds (see decision 346) then the flow returns TRUE (see operation 350). In some cases surpassing a threshold and raising an alert occurs when a value exceeds a threshold (e.g., in the case of a maximum spending limit). In other cases surpassing a threshold and raising an alert occurs when a value is smaller than a threshold (e.g., in the case of a minimum amount of materiel remaining). In some cases, a threshold is based on account or ledger or value being denominated in a particular currency.
Such cases of a minimum threshold or a maximum threshold or range bound can be configured and stored in configuration data. Illustrative embodiments of a configuration flow are presently discussed.
As shown, the configuration flow 400 commences when a user or system associates a data item with an alert (see operation 420). An alert can comprise many characteristics, some of which are described in
When an alert value is deemed to be outside of a range, or the alert value is deemed to have surpassed a threshold, then an alert is triggered, and the triggering event can be associated with additional actions (see operation 440). As earlier discussed, some data item values are deemed to be currency or to be handled “as if” they are currency. As such, configuration flow 400 supports the specification of a normalization function (see operation 450). Any of the aforementioned thresholds or range bounds can be associated with an alert level (see operation 460). For example, if a spending limit exceeds a low threshold, then a warning alert is raised. However, if a spending limit exceeds a high threshold, then an urgent or critical alert is raised.
The configuration flow 400 also supports specification of how to present an alert. For example, a warning alert might be color coded as yellow, or an urgent or critical alert might be color coded as red. In some cases the event of raising an alert is accompanied with an emitted audio signal, e.g., a beep or screech, etc. (see operation 470).
Many presentation techniques are possible, and a sample of such techniques are shown and discussed in the following
As shown, a screen display 500 includes a project management console comprising a listing of a large number of accounts. Some of the highlighted rows 502 include visual indicators in the form of icons 504 in a variance alert column 506. Some embodiments support an alert summary screen such that a user can view a summary of alerts, and can drill-down into detail of any selected alert. An example is presented in
As shown, the screen display 600 presents a summary of alerts, each alert with a corresponding checkbox. A user can click the checkbox to retrieve alert details for any of the alerts. Alternatively, and as shown, a user might indicate (e.g., using a pointing device over the label of an alert or its checkbox) a desire to see detail of the alert (e.g., thresholds), and a pop-up window 622 presents such alert details (see operation 620).
According to one embodiment of the disclosure, computer system 900 performs specific operations by processor 907 executing one or more sequences of one or more instructions contained in system memory 908. Such instructions may be read into system memory 908 from another computer readable/usable medium, such as a static storage device or a disk drive 910. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the disclosure. Thus, embodiments of the disclosure are not limited to any specific combination of hardware circuitry and/or software. In one embodiment, the term “logic” shall mean any combination of software or hardware that is used to implement all or part of the disclosure.
The term “computer readable medium” or “computer usable medium” as used herein refers to any medium that participates in providing instructions to processor 907 for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as disk drive 910. Volatile media includes dynamic memory, such as system memory 908.
Common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, or any other magnetic medium; CD-ROM or any other optical medium; punch cards, paper tape, or any other physical medium with patterns of holes; RAM, PROM, EPROM, FLASH-EPROM, or any other memory chip or cartridge, or any other non-transitory medium from which a computer can read data.
In an embodiment of the disclosure, execution of the sequences of instructions to practice the disclosure is performed by a single instance of the computer system 900. According to certain embodiments of the disclosure, two or more computer systems 900 coupled by a communications link 915 (e.g., LAN, PTSN, or wireless network) may perform the sequence of instructions required to practice the disclosure in coordination with one another.
Computer system 900 may transmit and receive messages, data, and instructions, including programs (e.g., application code), through communications link 915 and communication interface 914. Received program code may be executed by processor 907 as it is received, and/or stored in disk drive 910 or other non-volatile storage for later execution. Computer system 900 may communicate through a data interface 933 to a database 932 on an external data repository 931. A module as used herein can be implemented using any mix of any portions of the system memory 908, and any extent of hard-wired circuitry including hard-wired circuitry embodied as a processor 907.
In the foregoing specification, the disclosure has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure. For example, the above-described process flows are described with reference to a particular ordering of process actions. However, the ordering of many of the described process actions may be changed without affecting the scope or operation of the disclosure. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than restrictive sense.
The present application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 61/880,741, entitled “PROJECT MANAGEMENT ALERTS USING HETEROGENEOUS PROJECT DATA” (Attorney Docket No. ORA140361-US-PSP), filed Sep. 20, 2013, which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61880741 | Sep 2013 | US |
