MAPPING ENGINE CONFIGURATIONS WITH TASK MANAGED WORKFLOWS AND GRID USER INTERFACES

Abstract

Systems and methods are related to maintaining a workflow of tasks in conjunction with data of the workflow. For example, a method includes generating a budget plan for a plurality of budgets using a template. The method includes generating a plurality of tasks for a plurality of budget owners. Each task is associated with a respective budget and each task is assigned to a respective budget owner. The plurality of tasks are each used to manage progress towards approving the budget plan and to organize work associated with each of the budget owners. The method includes submitting one or more budgets of the plurality of budgets in the budget plan for approval, receiving approval, and displaying a summary based at least in part on the budgets.

Description

BACKGROUND

This section is intended to introduce the reader to various aspects of art that may be related to aspects of the present disclosure, which are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.

Many organizations allocate resources, including financial assets, using spreadsheets. For example, budgets may provide an estimate of how resources are allocated in an organization. As organizations get bigger, spreadsheets developed for such purposes may become larger and more complex. For example, additional tabs may be used for different parts of the aspects of resource allocation. Further, due to the complexity of the spreadsheets, the spreadsheets may be prone to errors and/or difficult to update.

SUMMARY

A summary of certain embodiments disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects that may not be set forth below.

Systems and methods described below are related to a collaboration system that maintains data while facilitating communication and completion of tasks related to the data. For example, in an asset management context such spreadsheets may be prone to errors due to their size and complexity. The present the collaboration system may provide a way to maintain data in a way that reduces errors while providing way to manage tasks within a collaborative process, such as a budgeting processes.

In some embodiments, a processor is operatively coupled to a memory. The processor may carry out instructions stored in the memory. In one example of a useful implementation, the processor may execute instructions stored in the memory to generate, using a supervising account, an primary plan that affects or controls aspects of other subordinate plane, such as budget plan for one or more budgets. In such an example, the budget plan may be a template that defines one or more parameters of each of the budgets, such as budget organization, estimate totals associated with the budgets, costs of items associated with the budgets, or any other relevant budget data for each given budget. The template may describe a plan of how each budget of the budget plan is to be organized. For example, the template may set default budget amounts for each of the plurality of budgets. For instance, if a budget owner has a budget for a software that has licenses that cost a certain amount per year, the budget template can provide an entry for the software licenses and an expected cost associated with the license. As another example, if an hourly or daily service is associated with a given budget, an item that has an hourly or daily entry for charges may be included to allow the budgeter to estimate a number of hours for the service to be charged. If less is known than specific items, the template may include item fields for certain budgets to allow additional budget information to be entered, as well as cost for each of those line items. The supervising account may refer to an account that manages the budget plan overall.

The processor may generate a task for each budget, assigned to each budget owner, in the budget plan. The tasks are used to manage progress towards approving the budgets and to organize work associated with each of the budget owners. Upon generating the tasks, the processor may submit a budget to the supervising account.

By assigning a task to each respective budget owner, the task may be included in a general list of tasks not specific to budgeting. That is, a budget owner may, in addition to the task to complete the budget, perform other tasks from the list of tasks. Upon generating the tasks for each of the budgets, the budget owner may prepare the budget based on where the budgeting task is prioritized in the general list of tasks.

Further, the tasks generated for each of the budgets may be used to track and manage progress of the budget plan. For example, the collaboration system may display progression of each budget as the budgets are rejected, revised, and approved. That is, each budget owner may submit a respective budget to the supervising account. Upon receiving the submitted budget, the supervising account may approve, reject, request clarification regarding the budget, or the like. Upon approval of budgets in the budget plan, the collaboration system may generate a financial summary based on the approved budgets.

Additionally and/or alternatively, the collaboration system allows for forecasting of data. For example, the collaboration system may use a cost model to forecast budget data for future years based on prior forecasts and/or prior budget results. For instance, if a particular budget typically comes in underestimating a certain cost and the budgeter provides similar cost estimates each year, the forecast may predict further underestimation of the cost.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of this disclosure may be better understood upon reading the following detailed description and upon reference to the drawings in which:

FIG. 1 is a block diagram of a distributed computing system used in performing a release, in accordance with aspects of the present disclosure;

FIG. 2 is a block diagram of a computing device in the distributed computing system of FIG. 1, in accordance with aspects of the present disclosure;

FIG. 3 is a flow diagram of a method to maintain a budget plan performed by one or more computing devices in the distributed computing system of FIG. 1, in accordance with aspects of the present disclosure;

FIG. 4 is an example of a screenshot displaying a user interface that shows a list of tasks associated with the budget plan, in accordance with aspects of the present disclosure;

FIG. 5 is an example of a screenshot displaying a user interface that shows progression of tasks to complete in the budget plan, in accordance with aspects of the present disclosure;

FIG. 6 is an example of a flow diagram of a method to forecast budget information based on previous budgets, in accordance with aspects of the present disclosure; and

FIG. 7 is an example of a screenshot displaying a user interface that shows a financial summary based on the budget plan, in accordance with aspects of the present disclosure.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

One or more specific embodiments will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.

By way of introduction FIG. 1 is a block diagram of a system 100 that utilizes a distributed computing framework, which may perform one or more of the techniques described herein. As illustrated in FIG. 1, a client 102 communicates with a cloud service 104 over a communication channel 106. The client 102 may include any suitable computing system. For instance, the client 102 may include one or more computing devices, such as a mobile phone, a tablet computer, a laptop computer, a notebook computer, a desktop computer, or any other suitable computing device or combination of computing devices. The client 102 may include client application programs running on the computing devices. The client 102 can be implemented using a single physical unit or a combination of physical units (e.g., distributed computing) running one or more client application programs. Furthermore, in some embodiments, a single physical unit (e.g., server) may run multiple client application programs simultaneously.

The cloud service 104 may include any suitable number of computing devices (e.g., computers) in one or more locations that are connected together using one or more networks. For instance, the cloud service 104 may include various computers acting as servers in datacenters at one or more geographic locations where the computers communicate using network and/or Internet connections. The communication channel 106 may include any suitable communication mechanism for electronic communication between the client 102 and the cloud service 104. The communication channel 106 may incorporate local area networks (LANs), wide area networks (WANs), virtual private networks (VPNs), cellular networks (e.g., long term evolution networks), and/or other network types for transferring data between the client 102 and the cloud service 104. For example, the communication channel 106 may include an Internet connection when the client 102 is not on a local network common with the cloud service 104. Additionally or alternatively, the communication channel 106 may include network connection sections when the client and the cloud service 104 are on different networks or entirely using network connections when the client 102 and the cloud service 104 share a common network. Although only a single client 102 is shown connected to the cloud service 104, it should be noted that cloud service 104 may connect to multiple clients (e.g., tens, hundreds, or thousands of clients).

Through the cloud service 104, the client 102 may connect to various devices with various functionality, such as gateways, routers, load balancers, databases, application servers running application programs on one or more nodes, or other devices that may be accessed via the cloud service 104. For example, the client 102 may connect to an application server 107A and/or one or more databases 108A via the cloud service 104. The application server 107A may include any computing system, such as a desktop computer, laptop computer, server computer, and/or any other computing device capable of providing functionality from an application program to the client 102. The application server 107A may include one or more application nodes running application programs whose functionality is provided to the client via the cloud service 104. The application nodes may be implemented using processing threads, virtual machine instantiations, or other computing features of the application server 107A. Moreover, the application nodes may store, evaluate, or retrieve data from the databases 108A and/or a database server.

The databases 108A may contain a series of tables or records containing information about assets and services controlled by a client 102 and the configurations of these assets and services. The assets and services include may include hardware resources (such as server computing devices, client computing devices, processors, memory, storage devices, networking devices, or power supplies); software resources (such as instructions executable by the hardware resources including application software or firmware); virtual resources (such as virtual machines or virtual storage devices); and/or storage constructs (such as data files, data directories, or storage models).

In some embodiments, the databases 108A, whether in the cloud or at a client site accessible via the cloud or other network interconnection, may include information related to activity sets for certain personnel to perform. The databases 108A may each be associated with one or more departments of an enterprise. That is, an enterprise or organization may include a number of different departments that perform different operations for the overall enterprise. For instance, an IT department may assist in connecting information technology (IT) devices, software or applications, or virtualized environments for a member (e.g., employee) of the enterprise, human resources department may assist in hiring the member, and a facilities department may assist in providing access to various building associated with the member.

In addition to the databases 108A, the cloud service 104 may include one or more other database servers. The database servers are configured to store, manage, or otherwise provide data for delivering services to the client 102 over the communication channel 106. The database server may include one or more additional databases that are accessible by the application server 107A, the client 102, and/or other devices external to the additional databases. By way of example, the additional databases may include information related to member or assets of the enterprise. In some embodiments, the information regarding each member may be organized or stored a respective database of the databases 108A based on a department in which the member is assigned to. The information may include data regarding the member such as skill set, education background, role, job function, assigned activities or tasks, location, demographic information, and the like.

In the depicted topology, access to non-cloud resources, such as database 108B and/or application server 107B, from the cloud service 104 is enabled via a management, instrumentation, and discovery (MID) server 126 via an External Communications Channel (ECC) Queue 128. The MID server 126 may include an application program (e.g., Java application) that runs as a service (e.g., Windows service or UNIX daemon) that facilitates communication and movement of data between the cloud service 104 and external applications, data sources, and/or services. The MID service 126 may be executed using a computing device (e.g., server or computer) on the network 112 that communicates with the cloud service 104.

The ECC queue 128 may be a database table that is typically queried, updated, and inserted into by other systems. Each record in the ECC queue 128 is a message from an instance in the cloud service 104 to a system (e.g., MID server 126) external to the cloud service 104 that connects to the cloud service 104 or a specific instance running in the cloud service 104 or a message to the instance from the external system. The fields of an ECC queue 128 record include various data about the external system or the message in the record.

Although the system 100 is described as having the application servers 107A, the databases 108A, the ECC queue 128, the MID server 126, and the like, it should be noted that the embodiments disclosed herein are not limited to the components described as being part of the system 100. Indeed, the components depicted in FIG. 1 are merely provided as example components and the system 100 should not be limited to the components described herein. Instead, it should be noted that other types of server systems may communicate with the cloud service 104 in addition to the MID server 126.

Further, it should be noted that server systems described herein may communicate with each other via a number of suitable communication protocols, such as via wired communication networks, wireless communication networks, and the like. In the same manner, the client 102 may communicate with a number of server systems via a suitable communication network without interfacing its communication via the cloud service 104.

In addition, methods for populating the databases 108A may include directly importing data or entries from an external source, manual import by users entering or updating data entries via a user interface, and the like. Moreover, it should be understood that the embodiments described herein should not be limited to being performed with respect to a particular database or type of stored data. Instead, the present systems and techniques described herein may be implemented with any suitable database.

In any case, to perform one or more of the operations described herein, the client 102, the application server 107A, the MID server 126, and other server or computing system described herein may include one or more of the computer components depicted in FIG. 2. FIG. 2 generally illustrates a block diagram of example components of a computing device 200 and their potential interconnections or communication paths, such as along one or more busses. As briefly mentioned above, the computing device 200 may be an embodiment of the client 102, the application server 107A, a database server (e.g., databases 108A), other servers or processor-based hardware devices present in the cloud service 104 (e.g., server hosting the ECC queue 128) or at a local or remote client site, a device running the MID server 126, and so forth. As previously noted, these devices may include a computing system that includes multiple computing devices and/or a single computing device, such as a mobile phone, a tablet computer, a laptop computer, a notebook computer, a desktop computer, a server computer, and/or other suitable computing devices.

As illustrated, the computing device 200 may include various hardware components. For example, the device includes one or more processors 202, one or more busses 204, memory 206, input structures 208, a power source 210, a network interface 212, a user interface 214, and/or other computer components useful in performing the functions described herein.

The one or more processors 202 may include processor capable of performing instructions stored in the memory 206. For example, the one or more processors may include microprocessors, system on a chips (SoCs), or any other performing functions by executing instructions stored in the memory 206. Additionally or alternatively, the one or more processors 202 may include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or other devices designed to perform some or all of the functions discussed herein without calling instructions from the memory 206. Moreover, the functions of the one or more processors 202 may be distributed across multiple processors in a single physical device or in multiple processors in more than one physical device. The one or more processors 202 may also include specialized processors, such as a graphics-processing unit (GPU).

The one or more busses 204 include suitable electrical channels to provide data and/or power between the various components of the computing device. For example, the one or more busses 204 may include a power bus from the power source 210 to the various components of the computing device. Additionally, in some embodiments, the one or more busses 204 may include a dedicated bus among the one or more processors 202 and/or the memory 206.

The memory 206 may include any tangible, non-transitory, and computer-readable storage media. For example, the memory 206 may include volatile memory, non-volatile memory, or any combination thereof. For instance, the memory 206 may include read-only memory (ROM), randomly accessible memory (RAM), disk drives, solid state drives, external flash memory, or any combination thereof. Although shown as a single block in FIG. 2, the memory 206 can be implemented using multiple physical units in one or more physical locations. The one or more processor 202 accesses data in the memory 206 via the one or more busses 204.

The input structures 208 provide structures to input data and/or commands to the one or more processor 202. For example, the input structures 208 include a positional input device, such as a mouse, touchpad, touchscreen, and/or the like. The input structures 208 may also include a manual input, such as a keyboard and the like. These input structures 208 may be used to input data and/or commands to the one or more processors 202 via the one or more busses 204. The input structures 208 may alternative or additionally include other input devices.

The power source 210 can be any suitable source for power of the various components of the computing device 200. For example, the power source 210 may include line power and/or a battery source to provide power to the various components of the computing device 200 via the one or more busses 204.

The network interface 212 is also coupled to the processor 202 via the one or more busses 204. The network interface 212 includes one or more transceivers capable of communicating with other devices over one or more networks (e.g., the communication channel 106). The network interface may provide a wired network interface, such as Ethernet, or a wireless network interface, such an 802.11, Bluetooth, cellular (e.g., LTE), or other wireless connections. Moreover, the computing device 200 may communicate with other devices via the network interface 212 using one or more network protocols, such as Transmission Control Protocol/Internet Protocol (TCP/IP), power line communication (PLC), Wi-Fi, infrared, and/or other suitable protocols.

A user interface 214 may include a display that is configured to display images transferred to it from the one or more processors 202. In addition and/or alternative to the display, the user interface 214 may include other devices for interfacing with a user. For example, the user interface 214 may include lights (e.g., LEDs), speakers, and the like.

The systems and methods below may be performed on the one or more processors 202 of one or more computing devices 200 of the client 102, the platform 104, or any suitable combination. As mentioned above, spreadsheet applications have frequently been used to apply various formulas and to organize data, such as financial data. However, these spreadsheet applications do not easily allow for cooperation between different users, tend to be error-prone, and do not provide a way to manage the workflow to complete the spreadsheet. As such, a collaboration system that provides users a task managed workflow to maintain data is described below. While financial processes are used as an example below, the collaboration system may be used in any suitable context in which data manipulation also involves a workflow. Workflow refers to a sequence of steps that work passes through. For example, some organizations have budget owners who pass work, such as a budget, to an IT finance group for approval or rejection. If the budget is approved, then IT finance incorporates the budget into the results, and if the budget is rejected, then the work passes back to the budget owner. Due to passing work back and forth, it is desirable to maintain the workflow of tasks to be accomplished to complete the budget as well as the data included in each budget. By controlling both the workflow and the data, the processor 202 may reduce errors in updating the data and passing the data throughout the workflow.

FIG. 3 is a flow diagram of a streamlined process 300 performed by the processor 202 between two users of the collaboration system that reduces the difficulties related to using spreadsheets. In the illustrated embodiment, the processor 202 controls the workflow of the streamlined process 202 between IT finance 302 (e.g., a supervising account), and one or more budget owners 304 (e.g., secondary accounts). For example, the processor 202 may receive a design template from IT finance 302 that outlines a plan of goals for each of the one or more budget owners 304 (block 306). In some embodiments, the design template may provide general guidance, such as amounts for each of the budget owners 304 to plan around, or more specific guidance, such as line items expected to be included in budgets.

The processor 202 may then generate a task for each budget owner 304. A task may refer to work for the budget owner 304 to complete. For instance, the processor 202 may generate a task indicating work to be done on a budget associated with the budget owner 304.

The processor 202 may send each task to each respective budget owner 304 (diamond 308). For example, the processor 202 may notify the budget owner 304 of the task via email, text message, a pop-up notification, or the like. The task may then be included a list of tasks associated with the budget owner 304. For example, tasks may be any sort of work to be done by budget owners 304, such as creating plans, completing various budgets, or the like. The processor 202 may maintain a status associated with the task of whether the budget is drafted, published, pending, revised, or approved. Further, the processor 202 may maintain the list of tasks associated with the budget owner 304. That is, the status of each task may be used to manage progress towards approving the budget and to organize work associated with the budget owner 304.

The budget owner 304 may receive the budget based on the budget plan from the template (block 310). The processor 202 may receive inputs from the budget owner 304 to enter budget information for the budget. The budget information may include various financial data to be entered by the budget owner 304. For example, the budget owner 304 may provide inputs to indicate that the budget owner 304 anticipates costs of a certain amount for a software license. The processor 202 may then submit the budget based on the inputs provided by the budget owner 304 (block 314). IT finance 302 may then approve or reject the budget (block 316). The processor 202 may update the status associated with the task based on whether the budget is approved or rejected. If IT finance 302 determines that revisions are desired, the processor 202 may send a notification to the budget owner 304 to make the desired revisions. Accordingly, the budget owner 304 may then revise and update the budget (block 318).

FIG. 4 is an example of a screenshot of a user interface 350 of a list 352 of tasks being monitored by the processor 202. The list 352 includes each task that was created according to a budget template. In the illustrated embodiment, each task is assigned to a respective task owner and assigned a status of “draft”. Further, the budget template includes an amount of expected costs associated with each respective budget. For example, upon selection of a budget template, the processor 202 may generate the list 352 of tasks and assign a first task 354 to a first budget owner at a first amount. The processor 202 may assign a second task 356 to a second budget owner at a second amount. Further, IT finance 302 may make adjustments to each of the budgets from the budget template such that the list 352 of tasks matches the desired characteristics of the budget plan. That is, the processor 202 may generate tasks according to the budget template and allow IT finance 302 to make adjustments to the tasks prior to pushing each task to the respective budget owner 304 (e.g., changing the status of the task from “draft” to “pending”. By allowing adjustments to the tasks, each budget plan may be customized based on seasonal, yearly, or other market data. Upon receiving an input 358 from IT finance 302, the processor 202 may publish, send, or otherwise push each of the tasks in the list 352 to the respective budget owners 304.

FIG. 5 is an example of a screenshot of a user interface 380 that includes a grid view 372 of each of the tasks as the budget progresses. The processor 202 may display the grid view 372 with tasks according to the status of the task. For example, the processor 202 may display tasks in a published column 374, pending column 376, revised column 378, and approved column 380 depending on the status of the task. In some embodiments, a column of drafts may be included as well. As the status of each task changes, the processor 202 may maintain the list to allow IT finance 302 to track progress of the tasks throughout completion of the budget. For example, the processor 202 may display a task in the published column 374 when the tasks are initially sent to the budget owners 304. The processor 202 may then move the task to the pending column 376 when the budget owner 304 completes the budget and the budget owner 304 is awaiting for approval or rejection of the budget. If the budget is rejected, the processor 202 may display the task in the revise column 378, and if the budget is approved, the processor 202 may display the task in the approved column 380.

As mentioned above, in an organization, there may be a technical problem associated with using multiple spreadsheets to maintain and share data. For example, using multiple spreadsheets across multiple users may cause errors or increase complexity of completing aspects in a workflow. These technical problems are addressed by tracking both the data as well as the tasks associated with the users of the data through the workflow. By generating and maintaining the status of each of the tasks associated with the users as well as by maintaining the data, the likelihood of errors is reduced and the complexity of maintaining the data is reduced. In the illustrated example, the processor 202 may track the tasks of the budget as time progresses as well as maintain the budget data. Tracking the tasks may allow IT finance 302 to notify appropriate parties (e.g., late budget owners) of potential delays in forming the budget. Further, the processor 202 may also limit control (e.g., permissions) of a budget owner 304 to edit his/her respective budget, thereby reducing potential errors caused by the budget owner 304 editing the budget of another budget owner. Moreover, by tracking the data over several periods, the processor 202 may provide forecasting regarding the data. With respect to budgeting, for example, the processor 202 may provide forecasts regarding future budgets based on previous budgets.

FIG. 6 is a flow diagram of a process 400 performed by the processor 202 to generate forecast information based on previous budget information. The processor 202 may receive data regarding one or more previous budgets (block 402). For example, over time, the processor 202 may track budgets as the budgets are entered into the system. The processor 202 may then determine forecast information of a new budget based on the previous budgets (block 404). For instance, the processor 202 may determine that a particular budget owner 304 has certain entries within his or her budget which tend to be underestimated, then the processor 202 may predict that these entries are underestimated and forecast a higher amount for the entries. In some embodiments, the forecast may be generated using machine learning, a cost model or mapping engine, or the like. The processor 202 may utilize one or more sets of equations, seasonal information, yearly information, previous budget information, budget owner information, or any other suitable information to determine the forecast. The processor 202 may then provide the forecast information regarding the new budget (block 406). By the processor 202 providing forecasting information regarding new budgets, IT finance 302 may adjust the budget plan to account for variations that may not be otherwise discernable to IT finance 302.

The processor 202 may display a summary based at least in part upon the budgets. FIG. 7 is an example of a screenshot of a user interface 410 of a financial summary based on previous budgets and each of the approved and/or pending budgets. In the illustrated embodiment, the processor 202 may display a first column 412 related to previous spending and current spending, a second column 414 related to changes between each year, and a third column 416 of approved budgets compared to pending budgets. While the three columns are shown in FIG. 7, these are meant to be illustrative, and any suitable summary information may be shown. Further, the summary information may be customizable based on the organization and preferences.

The specific embodiments described above have been shown by way of example, and it should be understood that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.

The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function] . . . ” or “step for [perform]ing [a function] . . . ”, it is intended that such elements are to be interpreted under 35 U.S.C. 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. 112(f).

Claims

1. A system, comprising: a non-transitory memory;one or more hardware processors configured to execute instructions from the non-transitory memory to cause the system to perform operations comprising:generating a budget plan for a plurality of budgets;generating a plurality of tasks for a plurality of budget owners, wherein each task is associated with a respective budget and each task is assigned to a respective budget owner, wherein the plurality of tasks are each used to manage progress towards approving the budget plan and to organize work associated with each of the budget owners;submitting one or more budgets in the budget plan;receiving approval one or more budgets in the budget plan; anddisplaying a summary based at least in part upon each budget of the plurality of budgets.

2. The system of claim 1, wherein the one or more hardware processors is configured to execute instructions from the non-transitory memory to perform operations comprising generating the budget plan via a first device, and displaying the summary via a second device, wherein the first device comprises a mid server and the second device comprises a local computing device.

3. The system of claim 1, wherein the one or more hardware processors is configured to execute instructions from the non-transitory memory to perform operations comprising forecasting financial information based on each approved budget of the plurality of budget accounts.

4. The system of claim 1, wherein the one or more hardware processors is configured to execute instructions from the non-transitory memory to perform operations comprising maintaining a status of each task of the budget plan.

5. The system of claim 4, wherein the status comprises a published state, a pending state, a revised state, and an approved state.

6. The system of claim 4, wherein the one or more hardware processors is configured to execute instructions from the non-transitory memory to perform operations comprising updating the status upon submitting the respective budget, updating the status upon approving the respective budget, updating the status upon rejecting the respective budget, or any combination thereof.

7. The system of claim 1, wherein each budget comprises at least one entry of data to include in the budget plan.

8. The system of claim 1, wherein the one or more hardware processors is configured to execute instructions from the non-transitory memory to perform operations comprising providing the task to the budget owner in a general list of tasks.

9. The system of claim 1, wherein the one or more hardware processors is configured to execute instructions from the non-transitory memory to perform operations comprising notifying the budget owner of the task upon publishing the task.

10. The system of claim 1, wherein the summary comprises at least one of a comparison of the budget over a present time period and another budget over a previous time period, variance in spending on specific items in the budget for the present time period compared to the previous time period, and an amount of budgets that have been approved compared to budgets that are still pending.

11. A non-transitory, computer readable medium comprising instructions, wherein the instructions are configured to be executed by a processor to perform operations comprising: generating a budget plan for a plurality of budgets;generating a plurality of tasks for a plurality of budget owners, wherein each task is associated with a respective budget and each task is assigned to a respective budget owner, wherein the plurality of tasks are each used to manage progress towards approving the budget plan and to organize work associated with each of the budget owners;submitting one or more budgets in the budget plan for approval;receiving approval of the one or more budgets in the budget plan; anddisplaying a summary based at least in part upon each budget of the plurality of budgets.

12. The non-transitory, computer readable medium of claim 11, wherein the instructions are configured to be executed by a processor to perform operations comprising forecasting the budget plan based on previous budgets using neural networks, a model, or any combination thereof.

13. The non-transitory, computer readable medium of claim 11, wherein the instructions are configured to be executed by a processor to perform operations comprising forecasting the budget plan based on

14. The non-transitory, computer readable medium of claim 11, wherein generating a budget plan for a plurality of budgets comprises generating a template to be used with the budget plan.

15. The non-transitory, computer readable medium of claim 11, wherein the instructions are configured to be executed by a processor to perform operations comprising maintaining a status of each task of the budget plan.

16. A method, comprising: generating a budget plan for a plurality of budgets using a template;generating a plurality of tasks for a plurality of budget owners, wherein each task is associated with a respective budget and each task is assigned to a respective budget owner, wherein the plurality of tasks are each used to manage progress towards approving the budget plan and to organize work associated with each of the budget owners;submitting one or more budgets of the plurality of budgets in the budget plan for approval;receiving approval of the one or more budgets in the budget plan; anddisplaying a summary based at least in part upon each budget of the plurality of budgets.

17. The method of claim 16, comprising updating a status associated with a respective task of a respective budget upon submitting the one or more budgets in the budget plan, updating the status upon receiving approval of the respective budget, or both.

18. The method of claim 16, comprising notifying the budget owner of the task upon publishing the task.

19. The method of claim 16, comprising: receiving rejection of the one or more budgets in the budget plan; andupdating the respective tasks of the one or more budgets based upon the rejection.

20. The method of claim 19, wherein the summary comprises at least one of a comparison of the budget over a present time period and another budget over a previous time period, variance in spending on specific items in the budget for the present time period compared to the previous time period, and an amount of budgets that have been approved compared to budgets that are still pending.