METHOD AND SYSTEM TO FORECAST REPAIR COST FOR ASSETS

Systems and methods of the invention relate to forecasting a projected cost for at least repair associated with one or more assets. Based on evaluation of a portion of historic repair data for the one or more assets, a forecast component can create a projected cost to perform a repair. A cost component can aggregate or receive a portion of historic data related to repair costs previously performed. The cost component can further ascertain a repair cost per duration of time for an asset. Based on at least one of the portion of historic data or the repair cost per duration of time, the forecast component can indicate a projected cost for at least one repair for one or more assets.

DETAILED DESCRIPTION

Embodiments of the invention relate to methods and systems for forecasting a projected cost for at least one repair associated with one or more assets. Based on evaluation of a portion of historic repair data for the one or more assets, a forecast component can create a projected cost to perform a repair. A cost component can aggregate or receive a portion of historic data related to repair costs previously performed. The cost component can further ascertain a repair cost per duration of time for an asset. Based on at least one of the portion of historic data or the repair cost per duration of time, the forecast component can indicate a projected cost for at least one repair for one or more assets.

With reference to the drawings, like reference numerals designate identical or corresponding parts throughout the several views. However, the inclusion of like elements in different views does not mean a given embodiment necessarily includes such elements or that all embodiments of the invention include such elements.

The term “component” as used herein can be defined as a portion of hardware, a portion of software, or a combination thereof. “Hardware” refers to electronic circuits/circuitry, logic circuits/circuitry, and/or one or more processing elements (e.g., microprocessors) that is configured for the carrying out of one or more functions and/or methods (e.g., functions and/or methods as set forth herein), through execution of associated software (stored in a non-transitory electronic-readable medium, which may be part of the hardware), through the arrangement of the circuits/circuitry, and/or otherwise. “Software” refers to instructions that are readable and/or executable by hardware, stored in non-transitory electronic-readable media, which cause the hardware to perform designated functions, designated actions, and/or behave in a desired manner. “Non-transitory electronic-readable media” include, but are not limited to, non-volatile RAM, ROM, PROM, etc., a CD-ROM, a removable flash memory card, a hard disk drive, a magnetic tape, a floppy disk, and/or combinations thereof. The term “client asset” or “asset” as used herein means a fixed asset or a mobile asset that is owned and/or operated by a client entity such as, for example, a railroad, a power generation company, a shipping company (e.g., land, sea, air, and/or an combination thereof), a mining equipment company, an airline, or another asset-owning and/or asset-operating entity. The term “vehicle” as used herein can be defined as an asset that is a mobile machine or a moveable transportation asset that transports at least one of a person, people, or a cargo. For instance, a vehicle can be, but is not limited to being, a rail car, an intermodal container, a locomotive, a marine vessel, mining equipment, a stationary power generation equipment, industrial equipment, construction equipment, and the like. The term “repair facility” as used herein can be defined as a location that evaluates and/or performs a repair on a vehicle or other client asset. The term “Car Repair Billing” (CRB) as used herein can be defined as a computer-implemented system with a portion of software, a portion of hardware, or a combination thereof that facilitates reporting and/or invoicing railroads, car owners, client asset owners, vehicle owners, lessee, lessor, among others. CRB includes Association of American Railroads (AAR) administered as well as contract billing, and another suitable billing for railroads.

The term “Maintenance Management System” (MMS) as used herein can be defined as a computer-implemented system with a portion of software, a portion of hardware, or a combination thereof that facilitates analyzing repairs for a vehicle and/or auditing repairs for a vehicle to railroads, car owners, client asset owners, vehicle owners, lessee, lessor, among others. The MMS can receive repair information from a repair facility. The vehicle owner can use MMS to input repair data received from repair facility and then views, audits, pays, etc. based on the data received. The term “part” as used herein can be defined as a portion of a client asset and/or a portion of a vehicle, wherein the “part” is involved in a repair for at least one of the client asset or the vehicle. The term “ownership” as used herein can be defined as proof of legal claim to property such as a vehicle. The proof can be a title, a lease agreement, a contract, a legal document, a purchase agreement, among others. The term “repair” as used herein can be defined as a service on a vehicle, wherein the service can be a repair of a part, a replacement of a part, a maintenance of a part, a repair of a portion of the vehicle, a replacement of a portion of the vehicle, a maintenance of a portion of the vehicle, and the like. The term “real-time” as used herein can be defined as occurring upon receipt of data or a point later in time from receipt of data.

“Cost” refers to the price paid, or expected to be paid, in exchange for a repair. Cost can refer to all or a part of a transaction, and can be segmented using modifiers such as labor cost, parts costs, rental costs, lost opportunity costs, and the like. The cost can be owed and payable immediately, or can be accrued for later payment. Further, costs may be offset against, for example, credits and may not refer directly to an amount for a single transaction. Even further, discounts for volume, for loyalty programs, and for other aspects may affect a determined cost. Thus, cost should be considered in its broadest reasonable sense as modified by context.

FIG. 1is an illustration of a system100for indicating a projected cost for a repair to be performed on one or more assets. The system includes a cost component110that can be configured to receive or aggregate repair information related to one or more assets. The repair information (e.g., also referred to as a portion of historic data related to a cost of a repair for one or more assets) can relate to a cost of money for a previously performed repair on one or more assets. The system includes a forecast component120that can be configured to generate a projected cost for a repair to be performed on one or more assets based upon the evaluation of the repair information (via the cost component). The cost component can be a stand-alone component (as depicted), incorporated into the forecast component, or a combination thereof. The forecast component can be a stand-alone component (as depicted), incorporated into the cost component, or a combination thereof.

The cost component can receive or collect real-time data associated with a quote for a cost for a repair to perform, wherein the cost can be from a seller. For instance, the cost can include a cost of one or more part(s) used to perform the repair and/or a labor fee related to perform the repair. In another example, the cost component can evaluate a portion of historic data related to the cost of the repair to ascertain a cost fluctuation over a time period. In an embodiment, the forecast component can utilize the ascertained cost fluctuation over the time period to create the projected cost. In another example, a season or timing of a purchase can be utilized to identify pricing patterns for a repair or a part used with a repair. The forecast component can leverage an identified pricing pattern to forecast a projected cost for a repair to be performed on one or more assets.

For instance, a query can be received related to one or more assets in evaluating a cost for maintenance or repairs for a duration of time or a point of time in the future. The system can leverage repair information in order to generate a projected cost for the query for the point of time or the duration of time. In an embodiment, the projected cost can be identified for an amount of repairs that are to be performed (e.g., identification of incoming repairs that are to be performed on one or more assets, among others). In an embodiment, the projected cost can be identified for an amount of repairs that may be performed (e.g., forecasting, projecting, hypothetical situations, among others).

The system (via the cost component and/or the forecast component) can generate a projected cost based on the repair information. In an embodiment, the cost component can evaluate the repair information to identify a cost per a duration of time for each repair previously performed, wherein the forecast component utilizes the cost per the duration of time to generate a projected cost for a query or a repair to perform. For instance, based on repair information, repair A is performed on asset B every two weeks with a cost of C. Based on this example, a cost per a duration of time for repair A on an asset B (or a similar asset) can be C/(two weeks), which can be utilized to generate a projected cost for the repair for a different duration of time and/or a varying number of assets.

In another embodiment, the cost component can calculate an average cost for a repair based on evaluation of historic data related to the repair, wherein the forecast component utilizes the average cost for each repair to generate a projected cost for a query or an identified repair that is to be performed. In another embodiment, a real-time quote aggregator can be utilized. In another embodiment, a combination of the above techniques (e.g., average cost, cost per duration of time, real-time quote, among others) can be utilized to create a projected cost. In an embodiment, the cost component can calculate a transportation cost for delivery of the one or more assets to a repair facility, wherein the forecast component can include the transportation cost with the projected cost (e.g., each repair facility quote for a repair is matched or associated with the respective transportation cost).

FIG. 2is an illustration of a system200for utilizing a portion of repair data or a portion of invoice data to forecast a projected cost for at least one repair. The system can provide a projected cost for a repair to perform on one or more assets based on a portion of repair information collected or received. The projected cost can be for a query based on a hypothetical scenario, financial situation, budget question or concern, or a related cost of repair concern. For instance, a system (not shown) can predict a repair to be performed and the cost component and/or the forecast component can identify a projected cost based on the predicted repair utilizing the repair information. Additionally, the projected cost can be for an identified repair that is to be performed. For instance, the projected cost for a list of repairs that are to be performed on assets can be indicated based on the repair information.

By way of example and not limitation, repair information can be a previous repair on an asset, a part used in a repair on an asset, a date or time a repair was performed on an asset, a repair facility that performed the repair on the asset, repair details (e.g., who performed repair, issues related to performing the repair, duration of time to complete repair, downtime for the asset that received the repair, among others), financial information related to the repair (e.g., cost of repair, cost of part(s) for repair, among others), an invoice for a repair, asset information (e.g., type of asset, use of asset, cargo load of asset, location of asset, conditions of use for asset, owner of asset, pricing contract for repairs to the asset, among others), data related to Maintenance Management System (MMS), data related to Car Repair Billing (CRB), and the like.

The system can be utilized with a suitable Car Repair Billing (CRB), a CRB database210, Maintenance Management System (MMS), and/or a MMS database220, as well as an environment (e.g., user, repair shop, company, entity, corporation, among others) that employs CRB and/or MMS. For instance, the CRB database and/or the MMS database can be utilized by the cost component in order to ascertain at least one of a history of repair(s), repairs performed, duration of repair, frequency of repair, part(s) used for a repair on an asset, cost of a repair, among others.

FIG. 3is an illustration of a system300for managing an inventory of one or more parts utilized in one or more repairs on an asset. The cost component can evaluate a portion of historic data related to a cost of a repair on one or more assets (e.g., also referred to as repair information). Based at least in part upon the evaluation, the forecast component can generate a projected cost related to a repair that is to be performed on one or more assets. By basing the projected cost on historical data, an accurate projection or forecast for repair costs can be budgeted and/or managed effectively.

The system includes an inventory component310that can be configured to manage an inventory of one or more parts used for at least one repair on the one or more assets. The inventory component310can utilize the repair information (e.g., identifying a repair and a part(s) used for completed repairs and/or orders for new/incoming part(s), among others) to maintain an accurate quantity of part(s) within the inventory. For instance, the inventory component can provide automatic generation of purchase orders for one or more part(s), user-controlled generation of purchase orders, automated notification of inventory quantity for each part(s), or a combination thereof. The inventory component can communicate a purchase order to one or more sellers320, where there can be a number of sellers such as seller1to sellerN, where N is a positive integer. For instance, a seller can be a manufacturer, a repair facility, a vendor, a merchant, a manufacturer, among others. In another embodiment, the inventory component can order a part(s) from the one or more sellers. The inventory component can be a stand-alone component (as depicted), incorporated into the cost component, incorporated into the forecast component, or a combination thereof.

The system includes a discount component330that can be configured to identify a discount for a placement of an order for one of a part or a repair. For instance, the discount can be, but is not limited to, a bulk discount, a sale (e.g., buy one, get one free, percentage off, among others), a price discount, among others. The discount component can evaluate a potential purchase of a part (used for a repair or to replenish an inventory) or a potential purchase of a repair to perform, wherein the discount component can utilize historic purchasing information or received/collected discounts to identify discounts that are available for use. For instance, a quantity of a part can yield a discount at a particular seller and the inventory component can order the quantity or wait until the quantity is needed. In another example, a discount can be identified for a quantity of a number of repairs provided at a repair facility (e.g., buy one repair and get one repair free). The discount component can be a stand-alone component (as depicted), incorporated into the cost component, incorporated into the forecast component, incorporated into the inventory component, or a combination thereof.

In an embodiment, the cost component, the forecast component, the inventory component, and/or the discount component stores information related to the systems100,200,300, and/or400with a data store340. The connectivity of between the data store and the component(s) and/or system can be a wireless connection (as depicted), a wired connection, or a combination thereof. The data store can include information such as, but not limited to, an invoice, asset information, repair history for an asset, location for a repair facility, contact information for a seller, contact information for a repair facility, a repair cost, a type of repair, information related to an asset, ownership of an asset, historical data related to an invoice, historical data related to a cost for a repair, information related to a repair facility, address of repair facility, among others, and/or a suitable combination thereof.

It is to be appreciated that the data store can be, for example, either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The data store of the subject systems and methods is intended to comprise, without being limited to, these and other suitable types of memory. In addition, it is to be appreciated that the data store can be a server, a database, a hard drive, a flash drive, an external hard drive, a portable hard drive, a cloud-based storage, and the like.

FIG. 4is an illustration of a system400for evaluating whether to replace a part used in a repair procedure or repair a part used in a repair procedure. The system includes a procedure component410that can be configured to ascertain whether to perform a repair on a part used in a repair or to replace a part used in the repair. The procedure component can identify whether to repair or replace a part based on evaluating a factor, wherein the factor can be at least one of a cost of a part, a cost of labor to repair the part, a duration of downtime for the asset the part is used, an inventory quantity of the part, a difficulty assigned to the repair of the part, among others. The procedure component can include a setting to prioritize (e.g., weighted, among others) each factor to identify a selection of repair or replace. The data store (referenced above) can be leveraged by the procedure component to store the factor(s) and/or access historic data related to factors to provide whether to repair a part or replacement the part. Although depicted as a stand-alone component, the procedure component can be incorporated into the cost component, incorporated into the forecast component, or a suitable combination thereof.

In an embodiment, a system is provided that includes at least one of the following: means for evaluating a portion of historic data related to a cost of a repair on one or more assets (e.g., system100, a controller, a component, cost component, among others); means for identifying at least one repair to perform on the one or more assets (e.g., system100, a controller, a component, cost component, forecast component, among others); and means for forecasting a projected cost to perform the at least one repair on the one or more assets based at least in part upon the evaluated portion of historic data (e.g., system100, a controller, a component, forecast component, among others).

The aforementioned systems, components, (e.g., cost component, forecast component, procedure component, inventory component, among others), and the like have been described with respect to interaction between several components and/or elements. It should be appreciated that such devices and elements can include those elements or sub-elements specified therein, some of the specified elements or sub-elements, and/or additional elements. Further yet, one or more elements and/or sub-elements may be combined into a single component to provide aggregate functionality. The elements may also interact with one or more other elements not specifically described herein.

In view of the exemplary devices and elements described supra, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow chart ofFIG. 5. The methodologies are shown and described as a series of blocks, the claimed subject matter is not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be required to implement the methods described hereinafter. The methodologies can be implemented by a component or a portion of a component that includes at least a processor, a memory, and an instruction stored on the memory for the processor to execute.

FIG. 5illustrates a flow chart of a method500for identifying a projected cost to perform at least one repair on one or more assets. At reference numeral510, a portion of historic data related to a cost of a repair on one or more assets can be evaluated. At reference numeral520, at least one repair to perform on the one or more assets can be identified. At reference numeral530, a projected cost to perform the at least one repair on the one or more assets can be forecasted based at least in part upon the evaluated portion of historic data.

The method can further include aggregating a real-time quote from at least one repair facility to perform the at least one repair on the one or more assets. The method can further include the quote to include a cost for at least one part related to the at least one repair and a cost for a labor fee related to the at least one repair. The method can further include evaluating the portion of historic data related to the cost of the repair to ascertain a cost fluctuation over a time period and utilizing the cost fluctuation over the time period to create the projected cost. The method can further include receiving the portion of historic data from a Maintenance Management System (MMS) database. The method can further include receiving the portion of historic data from a Car Repair Billing (CRB) database.

The method can further include the portion of historic data that is an invoice for the repair on one or more assets. The method can further include calculating a transportation cost for delivery of the one or more assets to a repair facility and including the transportation cost with the projected cost, the transportation cost for the repair facility is associated with a quote from the repair facility. The method can further include evaluating an inventory of one or more parts for the one or more assets and managing a quantity of one or more parts of the inventory based on the evaluation of the inventory and the identification of at least one repair to perform.

The method can further include communicating a purchase order for one or more parts associated with the identification of at least one repair to perform based upon the evaluation of the inventory. The method can further include communicating the purchase order to a seller based on the seller offering a quantity-based discount for the one or more parts. The method can further include ordering one or more parts associated with the identification of at least one repair to perform based on the evaluation of the inventory. The method can further include identifying a frequency of the repair for the one or more assets based on the portion of historic data and generating the projected cost to perform the at least one repair on the one or more assets based on the frequency for a duration of time. The method can further include ascertaining whether to perform a part repair or a part replacement for the at least one repair based on the projected cost.

In the specification and claims, reference will be made to a number of terms that have the following meanings. The singular forms “a”, “an” and “the” include plural referents unless the context clearly dictates otherwise. Approximating language, as used herein throughout the specification and claims, may be applied to modify a quantitative representation that could permissibly vary without resulting in a change in the basic function to which it is related. Accordingly, a value modified by a term such as “about” is not to be limited to the precise value specified. In some instances, the approximating language may correspond to the precision of an instrument for measuring the value. Moreover, unless specifically stated otherwise, a use of the terms “first,” “second,” etc., do not denote an order or importance, but rather the terms “first,” “second,” etc., are used to distinguish one element from another.