Order tracking and reporting tool

[0001] This application claims priority to Provisional Application 60/404,788 filed Aug. 19, 2002 entitled “Telecom Provisioning Workflow Models” which is incorporated by reference.

[0002] The preferred embodiments of the present invention relate generally to improvements in information technology. More particularly, the preferred embodiments relate to a method and related system for tracking, archiving and reporting information related to a business workflow. More particularly, the preferred embodiments relate to a web-based graphical user interface for tracking, archiving, and reporting information related to a business process object, or order, moving through a workflow.

[0003] A workflow is a largely automated set of relationships between tasks related to the completion of a business process object from start to finish. A business process object is a single instance of a business process (e.g. a customer's order for a product or service). Tasks may be triggered by automated messages or alternately, by manual interaction. Workflow management, which relates to the coordination of business tasks, or processes, is an emerging technology closely associated with corporate streamlining activities. Fundamentally, it is an information technology model for reducing business costs, improving operation efficiency, and facilitating an adaptive business organization.

[0004] In a workflow, business processes (e.g. order processing, product delivery scheduling) are generally defined in such a way that they can be directly interpreted and executed by a workflow manager, which can take the form of one or more central servers. A major inhibitor to the development of workflow is understanding the mechanisms, interactions and inter-relationships of these tasks, as even small businesses may develop hundreds of such tasks as a workflow matures.

[0005] Many customer-oriented businesses rely on largely automated procedures for receiving, tracking and completing a customer order. With large businesses processing hundreds of thousands of orders per month, it is vital to ensure that orders are processed efficiently in order to preserve customer satisfaction. Tracking and reporting data ensures that orders are not accumulating at any one step without any forward progress through the workflow. Identifying congested workflow states, or bottlenecks, that block the forward progress of other orders is important to recognizing workflow areas that need increased headcount or computing capacity. For example, if it is determined that many orders are being received for new telephone service, but only a small percentage are being queued for implementation, steps can be taken to proactively improve order fulfillment. As it would be time-consuming to monitor the status of each individual order, it is desirable to track and archive data that can be analyzed for trends or bottlenecks.

[0006] A key to maintaining customer satisfaction is the ability to query the real-time status of any order and identify its present state within the workflow, so that the status may be reported to the customer on demand. It is also desirable to be able to research all orders for a particular customer, across all processes within the workflow. It is also desirable to record the time it takes for an order to transition from state to state within the workflow. In addition to providing data to analyze for process optimization, historical data could also contribute to more accurate business forecasting by assisting in predicting future peak order periods, for example, so that they may be adequately prepared for. Collecting real-time data as well as historical data may be complicated by the existence of data on multiple systems with differing architectures. Historically, there has been no systematic, efficient way to access the level of order information desired across a multitude of legacy systems. The ability to generate reports on demand, as well as customized reports detailing specific parameters, is also desirable. Many conventional order tracking and reporting databases generate periodic planned reports, but it is further desired to generate customized, ad-hoc reports.

[0007] The problems noted above are solved in large part by a system and related method for tracking, archiving, and reporting information related to a business workflow. More particularly, the preferred embodiments relate to a web-based graphical user interface for tracking, archiving, and reporting information related to a business process object, or order, within a workflow. It is therefore desired to provide a web-based order tracking and reporting tool which allows users to access a variety of order-related details, through many levels of information, to download or print data, and to create customized reports on demand.

[0008] The disclosed devices and methods comprise a combination of features and advantages that enable it to overcome the deficiencies of the prior art. The various characteristics described above, as well as other features, will be readily apparent to those skilled in the art upon reading the following detailed description, and by referring to the accompanying drawings.

[0031] Certain terms are used throughout the following description and claims to refer to particular operations or computing entities. As one skilled in the art will appreciate, information technology companies may refer to computing processes, components, and sub-components by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .”

[0032] The term “computer” is intended to mean a computing entity, which may be a server, terminal, personal or other computer, or a network of computing entities working together as a unit. The term “workflow” refers to a series of operations and the order in which they are performed. The term “server” refers to a computing entity which is generally linked to and performing some service for one or more computing entities. The terms “task” refers to individual operations in the workflow. The term “system” refers to a computing entity designated to perform workflow tasks. The term “workflow manager” refers to one or more servers acting as a central clearinghouse to coordinate the workflow between a plurality of peripheral computing systems. The term “database” refers to a computing entity housing a large collection of data organized for rapid search and retrieval.

[0033] The term “application” refers to an executable software package or program that can be run on a system. The term “interface” refers to a mode of interaction between a user and computer, or alternately, between two computing systems or applications. The term “console” refers to a computing entity with which a user can actively interact. The term “channel” refers to a data structure and associated software processes that together form a communications pathway between different processes and/or different systems. The term “event” refers to a basic messaging unit, sent through a channel, which triggers a workflow operation and/or communicates information between the workflow manager and linked systems. To the extent that any term is not specially defined in this specification, the intent is that the term is to be given its plain and ordinary meaning.

[0034] The preferred embodiments of the present invention disclose a method and related system for tracking, archiving, and reporting information related to a business process object (hereafter, “order”) within a business workflow. The preferred embodiments enable a user to track, archive and report order information through a web-based computer interface. Order processing is generally coordinated between numerous systems by a central workflow manager. Generally, a central workflow manager acts as a central clearinghouse to coordinate messages between numerous individual systems. The workflow manager is linked with each system by one or more “channels,” which are communications pathways for delivering queued event-based messages between the workflow manager and peripheral systems, as well as between different processes within the workflow manager. Typically, the workflow manager will place an event into a channel, where the event will remain until it is retrieved by the target system. The event may have a set expiration period, so that it will not be enacted if not retrieved by a certain deadline, or may alternately be a guaranteed-delivery event, which will not expire.

[0035] After retrieving and acting on an event, a system may insert another event designated for the workflow manager into a return channel. Once the event is retrieved by the workflow manager, the workflow manager may recognize that a certain task has been performed. The workflow manager will then address the next task in the workflow by placing a subsequent event into a channel designated for the next targeted system. Events may pass to or from the workflow manager, depending on the system for which they are targeted. Essentially, the workflow manager follows a set procedure for notifying various systems of tasks to be performed, receiving confirmation that the events reached their destinations and following up with subsequent tasks.

[0036] Referring now to FIG. 1, user interface 10 is linked to central workflow manager 14 by net 12, which is a computing connection that may include an intranet, an interne, local-area network (LAN) or wide-area network (WAN) connection. In one preferred embodiment, interface 10 is a web-based console featuring a graphical user interface, which may communicate information to a user in the form of a web page or a plurality of frames within a web page. However, it will be understood that interface 10 may alternately possess a terminal interface or any number of traditional computing interfaces, such as that of a standard desktop software package. Further, software for the graphical user interfaces of the preferred embodiments may be communicated to a user interface 10 by an information-carrying medium, such as a floppy disk, CD-ROM, or network connection placed in operational relation with a computer.

[0037] Central workflow manager 14 includes one or more servers that receive and send out event-based messages, or “events,” to communicate between internal processes and a multitude of linked systems. Events are associated with transitions of an order from one workflow state to another, marking the progress of the order through the workflow. In the simplified setup shown in FIG. 1, a task such as new order entry may be performed at system 16. An event may then be placed into channel on workflow manager as denoted by arrow 18. The event may remain in the channel for a period of time until it is retrieved or expires. It will be understood that arrows 18, 22, 26 in FIG. 1 represent channels and not physical connections.

[0038] The event in channel 18 is typically retrieved by workflow manager 14, which then recognizes that a certain task has been performed and that a subsequent action (e.g. product shipping) needs to be taken. Assuming that system 20 handles tasks associated with product shipping, an event might be placed into channel 22, where it is retrieved by system 20. This event may trigger an action at system 20, such as a product shipping procedure. System 20 may then recognize that it must confirm completion of this action in order for the next step in the workflow to take place, and consequently places a subsequent event, such as “shipped today,” into channel 22. Once retrieved by workflow manager 14, a follow-up event, such as “order completed,” may then be placed into channel 26 by the workflow manager. System 24 may then retrieve the follow-up event and perform an associated task (e.g. billing).

[0039] FIG. 2 shows a simplified layout of a preferred embodiment of an order reporting and tracking tool linked with a workflow manager. Central workflow manager 14 deposits order state information into tracking database 30, which further comprises a plurality of databases: real-time state transition database 32, state transition replica database 34, real-time order repository database 36, and order repository replica database 38. State and transition information is stored by state transition database 32, while order and customer information is stored within order repository database 36. State transition replica database 34 is downstream from state transition database 32, and is a near-real-time replica of the state transition database. Similarly, order repository replica database 38 is a near-real-time replica downstream from order repository 36. Information from real-time databases 32 and 36 is periodically downloaded into the near-real-time replica databases, 34 and 38, respectively, so that tracking and reporting data can be accessed without impacting the performance of order provisioning, which updating the real-time databases might cause. Data from tracking database 30 can be accessed by a user at tracking user interface 40. Together, real-time databases 32 and 36 contain most of the data about an order.

[0040] Data from tracking database 30 is fed into reporting database 50, which includes data warehouse 52 and several datamarts 54. The datamarts 54 contain data pre-processed into a form convenient to put into a report. Information desired for creating a report that is not contained in the data obtained so far may be provided by one or more supplementary databases 56, which may feed into reporting database 50, either directly or through another database. Data from reporting database 50 can be fashioned into reports at reporting user interface 60. Conventional reports may be generated by reporting tool 58, which allows a user to put retrieved data into an intelligible format. Alternately, customized reports may be created on demand by ad-hoc reporting tool 62, a feature not generally in conventional workflow analysis tools, especially in combination with the other features of the preferred embodiments. The ability to create unplanned reports on data requested by the user is a desired feature of the preferred embodiments, as it can provide timely information targeted towards a specific need, such as a customer inquiry or troubleshooting endeavor. It will be understood that, while shown schematically as two separate entities, tracking user interface 40 and reporting user interface 60 may comprise a single computing entity, such as user interface 10, as shown in FIG. 1.

[0041] FIG. 3 shows welcome screen 64 of a preferred embodiment. From welcome screen 64, a user may select between order tracking 66 or order reporting 68 hyperlinks. Selecting order reporting link 68 transfers the user to screen 70, as shown in FIG. 4, where a plurality of archived links 72 allow the user to view the status of orders at a specific state within the workflow on a specified date. Real-time links 74 also allow the user to view the status of all orders within a specific state, or alternately, every order within the workflow pipeline.

[0042] Referring now to FIG. 5, screen 76 displays a layout of state-specific links 78. It will be understood that each state may be a composite state, i.e. a grouping of multiple workflow states that together represent a stage of the business process. Clicking on a particular state-specific link 78 will display every order within the selected state. Grouped state links 80 also allow a user to view the status of orders within a range of states, as well as scheduled installations or aged pipeline orders. Navigation bar 82 allows a user to scroll through links 78 sequentially by selecting goto option 84, or to alternately select download option 86 or print option 88. Selecting state-specific link 78 will bring up an order state summary report web page 90 as shown in FIG. 6A. A graph of number of time-stamped orders, shown herein as a function of date, allows a user to view orders 92 which transitioned out of the state, as opposed to orders 94 which did not transition to a new state on the particular date. A high occurrence of non-transitioning orders 94 when compared to total orders 96, or all orders in process that day, can alert users to a potential bottleneck. Scrolling down web page 90, as shown in FIG. 6B, non-transitioning orders 94, transitioned orders 96, and total orders 98 are displayed in table 99. Each selectable cell of table 99 links to details of an order category at a certain time or date.

[0043] As an example, if total orders 98 for a specific date are selected, report field web page 100 is displayed, as shown in FIG. 7A, listing parameters and associated details for an order. Any order within total orders 98 can be viewed in web page 100 by entering its sequence number into selection field 102 and clicking goto link 84. Selecting search link 104 brings up search frame 106, as shown in FIG. 7B, which allows a user to search the collection of orders by entering values into fields 108 corresponding with various parameters 110.

[0044] Referring now to FIG. 7C, search result values 112 are displayed in results frame 114, listed under searched parameters 116. As search result values 112 are displayed as selectable links, each value 112 can be selected, allowing a user to further gain details associated with that specific value. For example, if result 112 corresponding with a specific customer name is selected, all orders associated with that particular customer will be displayed. Alternately, if result 112 of a certain customer want date is selected, all orders targeted for implementation by the selected date will be displayed. If download link 86 is selected from navigation bar 82, data displayed can be downloaded to a file for further analysis. As shown in FIG. 8, search result values 112 and associated parameters 116 can be exported to a spreadsheet 118, such as Microsoft Excel, for more custom graphing or mathematical manipulation. The ability to download and import data from the tool of the preferred embodiments allows a user to manipulate the data by statistical analysis software specifically designed for trend analysis or other statistical reporting. Trend analysis is an invaluable tool in crafting business forecasts and alleviating bottlenecks or other potentially troublesome areas within the workflow.

[0045] Referring again briefly to FIG. 3, if order tracking link 66 is selected, search page 120 as shown in FIG. 9 is displayed. Search page 120 includes a number of fields 122 that can be completed, checked, or selected to customize the results of the search. Clicking button 124 executes the search, bringing up results page 130 as shown in FIG. 10. Certain result values 132 may be hyperlinked, meaning they may be clicked for further details associated with the value. Selecting a specific value 132, such as package ID parameter 134, displays process flow screen 140 as shown in FIG. 11. Process flow screen details order information, as well as a flowchart-like process flow 142 including color-coded blocks 144 representing steps not yet started 146, steps in progress 148, steps completed 150 and steps not applicable 152. Referring briefly back to FIG. 10, if order attributes link 154 is selected from results page 130, order attribute report 160, as shown in FIG. 12 is displayed. Order attribute report 160 contains further data on the specific order.

[0046] Referring now to FIG. 13, an order state summary report 90 is shown as an example of how historical data can be used to check for bottlenecks 170 or trends 172. Bottlenecks can be detected by a relatively sudden rise of non-moving orders within a short time period, by a gradual increase in orders within a certain state over a period of time when no such trend is detected for other states, by a marked decrease in order completion, increasing cycle times or a number of other inconsistencies in data. Such effects can be detected graphically both by abrupt and significant changes in data point values or alternatively, by slow and steadily changing values. In addition, such effects can be identified numerically by values, such as moving orders 92 or non-moving orders 94 shown in FIG. 6B, that show sudden or steady changes. Sudden changes may indicate a system failure or failed task or state transition, whereas slow, steady changes over time may indicate order piling up due to insufficient computing capacity or inadequate headcount.

[0047] Referring again to FIG. 13, a date with a significantly higher occurrence of non-moving orders 94 than the prior date could potentially signify an occasion during which more capacity or personnel are needed, especially if a higher-than-normal number of total orders are in process that day. Daily charts of orders at various states (not shown) could also highlight particular states that need attention to prevent future bottlenecks. In addition, trends 172 can be identified by recognizing a plurality of data points 176 that are either increasing or decreasing steadily in value over a period of time. For example, the last several data points 176 in FIG. 13 are increasing for non-moving orders 94 and simultaneously, decreasing for moving orders 92.

[0048] Recognizing such a trend allows a user to note that action needs to be taken or to differently allocate resources to prevent the continuation of such a trend. For example, to improve operations, headcount overseeing a particular task could be increased, new or different automation measures could be implemented, and repairs or upgrades to systems or other equipment could be performed to improve order completion cycle times.

[0049] Referring now to FIG. 14, a flowchart of the order reporting operations of the preferred embodiments is shown. In block 180, the user interface presents a set of selectable links, each associated with a stage in the workflow. (See for example FIG. 5.) When a user selects a link associated with a stage in the workflow, the user interface (in block 182) displays a historical trend of business process objects associated with that workflow stage. This historical trend is preferably shown both as a graph and as a table. (See for example FIGS. 6A and 6B). The table preferably includes selectable cells, each selectable cell having the number of business process objects associated with that workflow stage at a given time interval. This number may be the number of business process objects entering the stage during the time interval, exiting during the time interval, or simply remaining in the stage during the time interval. Other possibilities include the total number of business process objects in the stage at the beginning or end of the time interval. If a user selects a cell, the user interface (in block 184) displays a list of business process objects represented by the number in the cell. (See for example FIG. 7A, which shows the first page of a list). The user interface may display business process objects one to a page, with a page selection field and/or goto link allowing a user to view details for a selected business process object.

[0050] The hyperlinked web pages of the preferred embodiments allow a user to delve deeper into displayed information. Often, nested hyperlinked are used, in which a hyperlink will take a user to a certain page with additional hyperlinks, allowing the user to dig even deeper into the order information. This ability is important to accessing all information desired, which allows a user to provide good customer support in order execution, as well as relay any potentially troublesome data so that a problem can be corrected or averted. In addition, custom searches may be devised instantly, as shown in FIG. 15, by clicking on any report field 200 in report field frame 100. Clicking on report field 200 instantly adds parameter 110 to search frame 106. A user can either enter values to search for into value fields 108, or if desired, leave them blank to display all pertinent results. After a search is completed by clicking on search button 202, search results frame 114, as shown in FIG. 16, displays the pertinent values 112 and associated parameters 116. Selecting analyze results button 204 compiles an ad-hoc report, an example of which is shown in FIG. 17. Analysis results screen 206 includes a selection of graph types in which to display the analyzed data, including tables 210, vertical bar charts 212, horizontal bar charts 214, pie charts 216, and line charts 218. An example of pie chart 216 and vertical bar chart 212 are shown, respectively, in FIGS. 17 and 18.

[0051] The workflow analysis tool of the preferred embodiments has the ability to query the real-time status of any order and identify its present state within the workflow, so that the status may be reported to the customer on demand. Further, the preferred embodiments allow a user to research all orders for a particular customer, across all processes within the workflow. In addition to only providing data in response to a search request, the preferred embodiments allow a user to quickly query even more detailed information, preferably by using hyperlinks within the results. Additionally, the tool of the preferred embodiments archives at least one year of data, so that historical reports can rapidly be generated, to be used to trend analysis, business forecasting or other business need.

[0052] The tool of the preferred embodiments allows a user to access a level of workflow detail comprehensive enough to identify the last transition made by an order, the last event or state associated with an order, as well as other details which could help identify the order status and cause of a delay. The preferred embodiments provide a web-based order tracking and reporting tool which allows users to analyze a workflow, access a variety of order-related data on demand, through many levels of information, to download or print displayed data, and to create custom ad-hoc reports on specified parameters.

[0053] Reducing the cycle time an order spends completing a workflow is significant to raising revenues. Should an order become stalled due to a failure or bottleneck, it is imperative to customer satisfaction and employee productivity that the order status can be accessed rapidly and the problem corrected. It is also desired to obtain a level of workflow detail comprehensive enough to identify the last transition made by the order, as well as any other data which could help identify the order status and cause of the delay. In large corporations, thousands of hours every month may be spent researching order statuses, resulting in lost productivity. In addition, revenue lost due to unsuccessfully completed orders can be significant.

[0054] The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.