HK1182203B - Techniques to provide enterprise resource planning functions from a customer relations management client application - Google Patents

Description

Techniques for providing enterprise resource planning functionality from a customer relationship management client application

Technical Field

The present invention relates to enterprise resource planning, and more particularly to techniques for providing enterprise resource planning functionality from a customer relationship management client application.

Background

Many entities, such as businesses, have provisioning relationships with other entities. That is, many entities operate at least in part by purchasing products and services from and selling products or services to other entities. Some entities manage their provisioning relationships by using an Electronic Data Interchange (EDI) system to exchange business information from one computer system at one entity to another computer system at another entity. EDI systems can be expensive, complex and slow to implement. Some entities avoid EDI systems by exchanging information via telephone, fax or mail. It is with respect to these and other considerations that the improvements of the present invention are needed.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Embodiments are generally directed to techniques to provide access to functionality of an Enterprise Resource Planning (ERP) application via add-ons attached to an existing Customer Relationship Management (CRM) application used by a client. Some embodiments are particularly directed to techniques for providing access to an ERP system using a cloud computing model. Embodiments may provide access to an ERP system from client application plug-ins without using an Electronic Data Interchange (EDI) system. For example, in one embodiment, an apparatus may include a processing unit and a client CRM application executing on the processing unit. The apparatus may further include a plug-in application installed on the client CRM application. The plug-in client is operable to receive ERP actions from an ERP system via a provisioning hub (supply hub); performing an action on the ERP action with a second ERP action; and sending the second ERP action to the ERP system via the supply hub. Other embodiments are also described and claimed.

These and other features and advantages will become apparent upon reading the following detailed description and upon reference to the accompanying drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive of aspects as claimed.

Drawings

FIG. 1 illustrates an embodiment of a first system that provides ERP functionality from a CRM client application.

FIG. 2 illustrates an embodiment of a second system that provides ERP functionality from a CRM client application.

FIG. 3 illustrates an embodiment of a supply hub.

FIG. 4 illustrates an embodiment of a client system.

FIG. 5 illustrates a sequence diagram of ERP-client interaction.

FIG. 6 illustrates a first user interface of a plug-in application.

Fig. 7 shows a second user interface of the plug-in application.

FIG. 8 illustrates a third user interface of a plug-in application.

FIG. 9 illustrates an embodiment of a logic flow for providing ERP functionality from a CRM client application.

FIG. 10 illustrates an embodiment of a computing architecture.

Fig. 11 illustrates an embodiment of a communication architecture.

Detailed Description

Embodiments are directed to systems and techniques to electronically and automatically manage provisioning relationships. One entity (e.g., a customer) may operate an Enterprise Resource Planning (ERP) system. The entity can provide a plug-in client application that can be installed as a component to an existing Customer Relationship Management (CRM) application at a client (e.g., vendor). The vendor does not need to purchase additional software or set up and maintain an Electronic Data Interchange (EDI) system with the customer. The client may interact with the ERP system through plug-in application functionality within an existing CRM application, for example, receiving and confirming orders. An embodiment allows Key Performance Indicators (KPIs) and Vendor Managed Inventory (VMIs) to be tracked and viewed. As a result, embodiments may improve affordability, scalability, modularity, extendibility, or interoperability for an operator, device, or network.

Fig. 1 illustrates a block diagram of a system 100 for providing access to an enterprise resource planning application from a client system. In one embodiment, for example, the system 100 may include a computer-implemented system 100 having a plurality of components (such as an ERP system 110 and client systems 120-1, 120-a, where a is a positive integer). As used herein, the terms "system" and "component" are intended to refer to a computer-related entity, comprising either hardware, a combination of hardware and software, or software in execution. For example, a component may be implemented as a process running on a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers as desired for a given implementation. The embodiments are not limited in this context.

In the illustrated embodiment shown in FIG. 1, system 100 may be implemented with one or more electronic devices. Examples of electronic devices may include, but are not limited to: mobile device, personal digital assistant, mobile computing device, smartphone, cellular telephone, handset, one-way pager, two-way pager, messaging device, computer, Personal Computer (PC), desktop computer, laptop computer, notebook computer, handheld computer, tablet computer, server array or server farm, web server, network server, internet server, workstation, minicomputer, mainframe computer, supercomputer, network device, web appliance, distributed computing system, multiprocessor system, processor-based system, consumer electronics, programmable consumer electronics, television, digital television, set top box, wireless access point, base station, subscriber station, mobile subscriber center, radio network controller, router, hub, gateway, bridge, or the like, A switch, a machine, or a combination thereof. Although the system 100 shown in fig. 1 has a limited number of elements in a certain topology, it may be appreciated that the system 100 may include more or less elements in alternate topologies as desired for a given implementation.

In various embodiments, the system 100 may include an Enterprise Resource Planning (ERP) system 110. In an embodiment, the ERP system 110 may be owned by an ERP entity 102 (such as an enterprise or government agency) and may include one or more ERP applications 112 operating on one or more electronic devices (e.g., servers). The ERP application 112 may include programming instructions that, when executed on a logic device or processing unit, perform functions that help a business entity manage aspects of a business. For example, the ERP application 112 may manage inventory, receive orders for products in inventory from customers, fulfill orders by placing ordered products to customers, receive payment from customers, manage employee schedules, order products from vendors, pay vendors for received products, and so forth. The embodiments are not limited to these examples.

The ERP application 112 may implement various business processes within the entity and during business with outside parties (such as vendors and customers). For example, a business process may specify what information in an order is necessary. The ERP application 112 may also provide project planning and management functions, human resources management, customer relationship management, and the like. Examples of ERP applications 112 include, but are not limited to: MICRO from MICROSOFT CORPORATIONSOFT DYNAMICSFromSAP BUSINESSAnd fromORACLE E-BUSINESS

The ERP application 112 may receive and respond to control instructions from the ERP entity 102, such as input from an input device that causes the ERP application 112 to perform an ERP action, via a suitable GUI and various input/output (I/O) devices.

In embodiments, ERP system 110 may also include client accounts 114. The client account 114 may include information associated with a client entity, such as a particular vendor or customer. The client account 114 may include, for example, identifying information for the client, such as a name, address, telephone number, unique client identifier, and the like. The client accounts 114 may also include access credentials used by clients in accessing the ERP system 110 from client systems (e.g., client system 120-1). The client accounts 114 may also include information describing the system that the client is using to access the ERP system 110, e.g., what application, platform, version number, operating system, etc. to use.

In embodiments, system 100 may include one or more client systems, such as client systems 120-1 through 120-a, where a represents a positive integer. The client system 120 may include one or more electronic devices owned by a client entity 104 (such as a vendor, purchaser, customer, government agency, etc.). The client entity 104 may have repeated or ongoing interactions and/or services with the ERP entity 102. An example of client system 120 is further described with reference to fig. 4. Client system 120 may receive and respond to control instructions from client entity 104, such as input from an input device, via a suitable GUI and various input/output (I/O) devices, that cause client system 120 to perform an ERP action.

In an embodiment, client system 120 may be communicatively coupled to ERP system 110, for example, over a network (not shown), such as, but not limited to, the internet. The ERP system 110 may provide a network address to the client system 120 for connecting to and interacting with the ERP system 110. The embodiments are not limited to these examples.

Fig. 2 illustrates a block diagram of a system 200 for providing access to an enterprise resource planning application from a client system. System 200 may be similar to system 100 in that ERP systems 210-1 and 210-b (where b represents a positive integer) may be representative embodiments of ERP system 110, while client system 220 may be representative embodiments of client system 120. The ERP application 212 and the client account 214 may be representative embodiments of the ERP application 112 and the client account 114, respectively. The client entity 204 may represent the client entity 104.

System 200 may further include a supply hub 230. The supply hub 230 may represent a logical construct in communication with the ERP system 210 and the client systems 220 that is capable of sending, receiving and operating on ERP-related data. The provisioning hub 230 may include, for example, a server and a data store. The supply hub 230 may be owned by the supply hub entity 206 and operate on behalf of another entity, such as the ERP entity 202.

System 200 may further include multiple ERP systems, such as ERP system 210-1 and ERP system 210-b. In an embodiment, the multiple ERP systems 210 may be owned by the same entity (e.g., ERP entity 202), but may be located at different physical locations. In such embodiments, the multiple ERP systems 210 may interact with the same ERP data on the supply hub 230.

In an embodiment, the multiple ERP systems 210 may be owned and operated by different entities. For example, ERP entity 202 may own ERP system 210-1, while company B (not shown) may own ERP system 210-B. In such embodiments, the supply hub 230 may still be owned and operated by the supply hub entity 206, but may be structured to provide two distinctly separate supply hubs, one for each ERP system 210. However, the separation may be a logical construct rather than a physical construct, where ERP system 210 has access to only certain servers, certain portions of servers, and/or certain data stores within supply hub 230. Supply hub 230 is described below with reference to FIG. 3.

FIG. 3 illustrates a block diagram of a provisioning hub 300. Supply hub 300 may be a representative embodiment of supply hub 230. In an embodiment, provisioning hub 300 may be implemented with a cloud computing model. In the cloud computing model, applications and services can be provided as if the applications and data were on a local device without requiring the installation of applications and/or storage of data on a local computer. However, the application and/or data store may be implemented across many devices, servers, and data stores accessible from a local server through a network interface. In a cloud computing model, the provisioning hub 300 may be physically implemented on one or more servers and in one or more physical sites. Regardless of the physical configuration, provisioning hub 340 may logically appear as one device or system to external entities, such as to ERP system 210 and client system 220.

In an embodiment, supply hub 300 may include ERP application 310. In an embodiment, ERP application 310 may be a representative embodiment of ERP application 212. Alternatively, supply hub 300 may include ERP application support 320. The ERP application support 320 may perform various functions as a component of an ERP application rather than as a separate ERP application. For example, ERP application support 320 may update data in a database, perform calculations, convert data from one format to another, and so forth.

In an embodiment, provisioning hub 300 may include a client account 330. Client account 330 may be a representative embodiment of client account 214. When client account 330 is present on supply hub 300, client account 214 may be omitted from ERP system 210. Storing client accounts 330 on provisioning hub 300 may provide client accounts 330 with global access to multiple ERP systems 210 of an entity.

In an embodiment, the supply hub 300 may store ERP data 340. ERP data 340 may be any data used or generated by an ERP application, such as ERP application 310, ERP application 212, or ERP application support 320. ERP data 340 may include, but is not limited to: inventory data, personal data, client data, product data, project data, order data, invoice data, Key Performance Indicator (KPI) data, Vendor Managed Inventory (VMI) data, and the like. The ERP data 340 may be stored in one or more data stores and in various formats, such as databases, text files, spreadsheets, and so forth.

In an embodiment, the supply hub 300 may include a business process checker 350 and a business process 360. In an embodiment, business process checker 350 may be a component of ERP application 310 or ERP application support 320. Business process 360 can be a component of ERP data 340.

Business process checker 350 may check for ERP actions occurring on an ERP system or between ERP system 210 and clients to determine whether the ERP actions conform to business process 360. ERP actions for customer and vendor supply relationships may include, for example, but are not limited to: checking the order; placing an order; receiving an order; rejecting the order; changing the order; confirming the order; conditionally confirming the order; receiving an invoice; checking the invoice; sending an invoice; confirming delivery; checking key performance indexes; checking the inventory managed by the manufacturer; and view the status of the ERP action.

When the ERP action does not conform to the business process, the business process checker 350 can generate an exception (exception). For example, the business process checker 350 may compare the original order with a confirmation of the order from the vendor to determine that the confirmed order is the same as the original order. If the original order and the confirmed order are different, for example, if the vendor changed the price of an item, business process checker 350 may generate an exception. This exception may prevent the order from being confirmed in this example and may prompt the customer placing the order to review the confirmed order to approve or reject the change. The embodiments are not limited to these examples.

The components of provisioning center 300, such as ERP application 310 or ERP application support 320, client accounts 330, ERP data 340, business process checker 350, and business processes 360, may be distributed across multiple devices and/or physical locations. The components may be communicatively coupled via various types of communications media. The components may coordinate operations between each other. The coordination may involve a one-way or two-way exchange of information. For example, a component may communicate information in the form of signals communicated over the communications media. This information may be implemented as signals assigned to the respective signal lines. In these allocations, each message is a signal. However, other embodiments may alternatively employ data messages. These data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

Fig. 4 shows a block diagram of a client system 400. Client system 400 may represent client system 120 or 220. Client system 400 may represent one of a plurality of electronic devices owned by or operated on behalf of a client entity (e.g., client entity 204).

Client system 400 may include client application 410. The client application 410 may be a software application including executable program instructions. In an embodiment, the client application 410 may have primary functionality unrelated to ERP applications. For example, client application 410 may be a Customer Relationship Management (CRM) application, such as but not limited to: MICROSOFT DYNAMICSCRM applications generally provide managementThe business entity and its customers, sales, marketing, and service interactions between customers and potential customers. Client application 410 may generally be an application that a client entity installs on client system 400 for a primary purpose other than performing ERP actions.

In an embodiment, client system 400 may include a plug-in application 412. The plug-in application 412 may be installed to add ERP functionality to the existing client application 410. The plug-in application 412 may work within the user interface of the existing client application 410 to present the ability to perform ERP actions. In an embodiment, the plug-in application 412 may verify that the ERP actions received from the ERP system conform to the business process. The business process may be a business process local to the entity operating client system 400 or may be business process 360. When the ERP action does not conform to the business process, the plug-in application 412 can generate a notification that an exception has occurred when the ERP action occurs and send the notification to the ERP system.

In an embodiment, when an ERP-owning entity is forming a partnership with a client entity, ERP system 110, 210 may request information from the client entity regarding what client applications 410 client system 400 already has. The request may include a specific list of client applications 410 for which the ERP system 110, 210 has a plug-in application. When a client entity selects an existing client application 410, the ERP system 110, 210 may send a plug-in application 412 for the selected client application 410 to the client system 400. Client system 400 may then install plug-in application 412. Providing the plug-in application 412 to the client system 400 provides the ability for the client system to interact with the ERP system 110, 210 electronically using existing applications without the expense and time of having to set up the EDI system.

Fig. 5 shows a sequence diagram 500. Sequence diagram 500 illustrates an example of a set of ERP actions that may be taken in system 200 among ERP application 212, provisioning hub 230, and plug-in application 412. In sequence diagram 500, time begins at the top of the diagram and increases from the top of the diagram toward the bottom of the diagram. In the illustrated example, the ERP application 212 is operated by a purchasing entity (customer), while the plug-in application 412 is operated by a vendor entity (vendor). The supply hub 230 may be operated by the customer or by a third party on behalf of the customer.

ERP application 212 performs an ERP action that creates the purchase order (510). For example, a user may create a new purchase order object using an interface of ERP application 212 and may assign new values within the purchase order object, such as the selected vendor, the item to be ordered, the quantity to be ordered, the price of the item, and the desired delivery date. When the purchase order is complete, it may be sent as transmission 512 to the supply hub 230. Sending the purchase order may include sending the purchase order object to the supply hub 230 or may include sending the assigned value to the supply hub 230.

Supply hub 230 may receive transmission 512 and may look up (520) information about the client (selected vendor) if needed. For example, the provisioning hub 230 may find what type of client application 410 is being used by the vendor and, by extension, what plug-in application 412 is being used. If desired, supply hub 230 may format the purchase order according to the plug-in application used. For example, if the purchase order is in a tabular format, provisioning hub 230 may convert the tabular format to an extensible markup language (XML) formatted document. In an embodiment, the purchase order may be stored on supply hub 230 as part of ERP data 340 (e.g., as a purchase order object or database entry). The embodiments are not limited to these examples.

The supply hub 230 may then send the purchase order as a transmission 522 to the plug-in application 412. In an embodiment, the purchase order itself or the purchase order as formatted by the supply hub 230 may be sent. In another embodiment, a link to a purchase order stored on supply hub 230 may be sent. In another embodiment, the purchase order may be taken from the supply hub 230 by the plug-in application 412 upon accessing the CRM functionality.

A user at client system 220 may view the order using plug-in application 412 (530). In an embodiment, when the plug-in application 412 is added to the CRM client application, the purchase order may appear in an open order list in the supply hub portion within the CRM application. The plug-in application 412 may also include a user interface area in which received purchase orders may be viewed.

Actions may be performed 540 on the purchase order by the plug-in application 412. The action on the purchase order may include performing another ERP action. For example, the purchase order may be accepted or confirmed, rejected, or modified and accepted in a modified form. If, for example, the vendor does not have enough of the ordered items to satisfy the purchase order, the vendor may change the ordered quantity to reflect the quantity of the available items and then accept the purchase order with the modified quantity. When the action on the order (530) is complete, the plug-in application 412 can send the action, or the order for which the action was performed, back to the supply hub 230 in transmission 542.

Supply hub 230 may receive the action and may check the action against the business process (550). For example, the business process checker 350 may determine whether the order has been accepted, rejected, or modified. When the order has been modified, business process 360 may specify that the purchase order cannot be automatically confirmed, but instead needs to be approved by the customer. If the purchase order is modified, supply hub 230 may generate an exception and may send the action back to the ERP application in transmission 552 for review by the customer.

The ERP application 212 may receive the action as a conditional confirmation and may prompt the user to accept or reject the conditional confirmation. The user may confirm or deny the action using the ERP application 212 (560). The confirmation/denial may be sent to the provisioning hub 230 in transmission 562. If the conditional confirmation is accepted, supply hub 230 may remove the exception and may update ERP system 210 and/or ERP data 340 to modify the purchase order and indicate that the purchase order was accepted.

The purchase hub 230 may send the confirmation/denial to the plug-in application 412 in transmission 564. The plug-in application 412 may receive the confirm/decline transmission 564 and may proceed to complete the purchase order.

Sequence diagram 500 represents one of many possible interactions between the ERP application and the client plug-in application via the provisioning hub. The embodiments are not limited to the examples shown.

Fig. 6 illustrates an embodiment of a user interface 600. User interface 600 may comprise a portion of the user interface of client application 410 with one or more additional components added by plug-in application 412. In the illustrated example, the User Interface (UI) 600 is for a CRM application.

The UI 600 may arrange the functionality of the client application 410 into tabs, such as a files tab 602, a views tab 604, and a charts tab 606. The plug-in application 412 may add a tab, such as a pending order tab 610, that permits access to ERP functions within the client application 410. In FIG. 6, pending order tab 610 is selected and UI 600 shows the pending orders section.

UI 600 may provide access points to various ERP functions. For example, in the pending orders section of the UI 600, the selection pane 612 may provide an option to select a sale. When a sale is selected in the selection pane 612, a sub-pane 614 with sales related options may be shown. When pending order 616 is selected, a list of outstanding orders may be shown in view pane 620.

The view pane 620 may show pending orders, for example, as a table 622. Table 622 may have one row for each outstanding order. Each row may include relevant information about an order, including, for example: the order ID, the customer making the order, the requested delivery date, the order date, and the status of the order. Additional or alternative information may be shown.

In one embodiment, a particular pending order may be selected, for example, by using an input device, e.g., clicking on a row with a mouse, or by selecting a check box (not shown) next to an order row. The pending order may be opened for viewing by selecting the pending order and selecting an "open" option from a menu, by double-clicking on the pending order, or the like. The list of pending orders may be displayed in other formats, and embodiments are not limited to this example.

UI 600 may provide selectable buttons in the pending orders section for confirming orders 630, rejecting orders 631, scheduling shipments of orders 632, generating invoices for orders 633, viewing Vendor Managed Inventory (VMI) 634, and viewing Key Performance Indicators (KPIs) 635. When an order is selected in the view pane 620, selection of the button 630 for confirming the order may confirm the order. Selecting a button for viewing VMI634 or KPI 635 may open a UI view associated with the button. In one embodiment, the buttons associated with a particular order, for example, buttons 630, 631, 632, and 633, may be inactive until an order is selected.

Fig. 7 illustrates an embodiment of a User Interface (UI) 700. UI700 may be a view of a pending order in view pane 620 in UI 600. UI700 may provide an order view pane 710. Order view pane 710 may be a pane within UI700 or may be a separate object, such as a window displayed before UI 700.

Order pane 710 may show summary information about the purchase order in order information area 720. Order information area 720 may show, for example, an order ID, a customer name, an order date, a status, and a requested delivery date. Additional or alternative information may be shown. The information in order information area 720 may also be presented in other formats, such as in a row, separate fields, and so forth.

Order pane 710 may show details of the purchase order in table 722. In an embodiment, some of the data fields in table 722 may be editable by the vendor. For example, the confirmed number of the product "LCD TV" may be changed from 1 to another number. Likewise, the confirmed price per unit may be changed from 1000 to another number. In one embodiment, each row of items may be selected and opened in a new view in which changes to quantity and price may be made. The purchase order may be shown in other forms, such as a form, a text document, a web page, and so forth.

When the vendor has completed viewing and possibly modifying the purchase order, selecting the save button 730 may save the changes and close the order pane 710, returning to the view of the pending orders in the view pane 620. From the view pane 620, the saved order can then be confirmed (e.g., with a confirm order button 630). The confirmed purchase order may be sent to the supply hub 230 for review against the business process 360 and distribution to the ERP system of the customer. Alternatively, if the decline order button 631 is selected, the plug-in application 412 may send a message to the supply hub 230 that the order is declined. The supply hub 230 may then notify the customer's ERP system that the order was rejected.

Fig. 8 illustrates an embodiment of a User Interface (UI) 800. UI 800 may be a view of UI 600 when KPI button 635 is selected. The UI 800 may provide a KPI view pane 810. The KPI view pane 810 may be a pane within the UI 800, or may be a separate object, such as a window, that is displayed before the UI 800.

The KPI view pane 810 may graphically illustrate various Key Performance Indicators (KPIs). For example, KPI view pane 810 may show a bar graph displaying the following percentages: orders arriving on time to the customer (column 812), orders confirmed on time (column 814), and orders delivered on time (column 816). Other examples of KPIs related to supply relationships that may be shown include fully confirmed orders, matched deliveries, matched shipments, and so forth.

In an embodiment, a bar (e.g., bar 812) in KPI view pane 810 may be selected. When selected, the KPI view pane 810 may change to show another graph, or a new KPI view pane may be opened, which shows the KPI of the selected bar in more detail, e.g., the percentage of orders that arrive on time separated by month. The columns for a particular month may be selected to obtain KPI data for each week in the selected month. KPI data may be presented in other forms not limited to this example, such as with line graphs, histograms, pie charts, and so forth.

In an embodiment, KPI data may be stored at the supply hub 230. When the KPI button 635 is selected, the plug-in application 412 can retrieve KPI data.

The operations of the above embodiments may be further described with reference to one or more logic flows. It can be appreciated that the representative logic flows do not necessarily have to be executed in the order presented, or in any particular order, unless otherwise indicated. Also, various activities described with respect to the logic flows can be executed in serial or parallel fashion. The logic flows may be implemented using one or more hardware elements and/or software elements of the described embodiments or alternative elements as desired for a given set of design and performance constraints. For example, the logic flows may be implemented as logic (e.g., computer program instructions) for execution by a logic device (e.g., a general-purpose or special-purpose computer).

Fig. 9 illustrates one embodiment of a logic flow 900. Logic flow 900 may be representative of some or all of the operations executed by one or more embodiments described herein. The logic flow 900 may be performed by various systems and/or devices and may be implemented as hardware, software, and/or any combination thereof, as desired for a given set of design parameters or performance constraints. For example, the logic flow 900 may be implemented by logic device (e.g., a processor) and/or logic (e.g., threaded logic) comprising instructions, data, and/or code executed by the logic device. For purposes of illustration, and not limitation, the logic flow 900 is described with reference to fig. 1-4. The embodiments are not limited in this context.

In the illustrated embodiment shown in FIG. 9, the logic flow 900 may receive a request to select an existing application from an ERP system and respond to the request at block 902. For example, the ERP system 110, 210 may request that the client system 120, 220 select an application that has been installed on the client system 120, 220. In one embodiment, the request may have specified an application to select from, and the response may include a selection of one or more of the applications that the client system 120, 220 has installed. In another embodiment, the client system 120, 220 may respond with one or more applications installed without selecting from the list. In an embodiment, the selected existing application may be a CRM application. The ERP system 110, 210 may use the response to select the plug-in application 412 to send to the client system 120, 220.

The logic flow 900 may receive a plug-in application and install the plug-in application to the selected CRM application at block 904. For example, the ERP system 110, 210 may send a plug-in application 412 for the selected CRM application. In an embodiment, the plug-in application 412 may be sent as an executable application that, when executed, performs an installation onto the existing CRM application 410.

The logic flow 900 may connect to the ERP system at block 906. For example, the client application 410 may connect to the ERP system 110, 210 using the plug-in application 412. The connection may be through a network, such as the internet. In an embodiment, logic flow 900 may connect from plug-in application 412 to a provisioning hub, such as provisioning hubs 230, 300. In an embodiment, the connection may allow data exchange between the ERP system 110, 210 and the client system 120, 220.

The logic flow 900 may perform an ERP action at the plug-in application at block 908. ERP actions may include, for example and without limitation: placing an order; receiving an order; rejecting the order; modifying an order, confirming an order, conditionally confirming an order, receiving an invoice; sending an invoice; confirming delivery; checking key performance indexes; checking the inventory managed by the manufacturer; and view the status of the ERP action. The plug-in application 412 may add a user interface to the client application 410 or use an existing user interface to present access points within the client application 410 to perform ERP actions. In an embodiment, the ERP actions performed in block 908 may be in response to ERP actions received from the ERP system. For example, if a purchase order is received by a client system 120, 220, the ERP actions performed at the plug-in application 412 may include rejecting the purchase order, confirming the order, or modifying the order.

The logic flow 900 may update the ERP system with ERP actions from the plug-in application at block 910. For example, if the plug-in application 412 modifies the ERP data (e.g., alters the order), or moves the provisioning relationship process to the next step (e.g., confirms the order), the ERP system 110, 210 will receive an update resulting from this ERP action at the plug-in application 412. In an embodiment, the actions performed at the plug-in application 412 may be sent to the supply hub 230, 300, which may then update the ERP system 110, 210.

FIG. 10 illustrates an embodiment of an exemplary computing architecture 1000 suitable for implementing the various embodiments described above. The computing architecture 1000 includes various common computing elements, such as one or more processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, and so forth. The embodiments, however, are not limited to implementation by the computing architecture 1000.

As shown in FIG. 10, the computing architecture 1000 includes a processing unit 1004, a system memory 1006, and a system bus 1008. The processing unit 1004 can be any of various commercially available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 1004. The system bus 1008 provides an interface for system components including, but not limited to, the system memory 1006 to the processing unit 1004. The system bus 1008 can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures.

For example, the system memory 1006 may include various types of memory units, such as Read Only Memory (ROM), Random Access Memory (RAM), dynamic RAM (dram), double data rate dram (ddram), synchronous dram (sdram), static RAM (sram), programmable ROM (prom), erasable programmable ROM (eprom), electrically erasable programmable ROM (eeprom), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, or any other type of media suitable for storing information. In the illustrated embodiment shown in FIG. 10, the system memory 1006 can include non-volatile memory 1010 and/or volatile memory 1012. A basic input/output system (BIOS) may be stored in the non-volatile memory 1010.

The computer 1002 may include various types of computer-readable storage media, including an internal Hard Disk Drive (HDD) 1014, a magnetic Floppy Disk Drive (FDD) 1016 to read from or write to a removable magnetic disk 1018, and an optical disk drive 1020 to read from or write to a removable optical disk 1022 (e.g., a CD-ROM or DVD). The HDD 1014, FDD 1016 and optical disk drive 1020 can be connected to the system bus 1008 by a HDD interface 1024, an FDD interface 1026 and an optical drive interface 1028, respectively. The HDD interface 1024 for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units 1010, 1012, including an operating system 1030, one or more application programs 1032, other program modules 1034 and program data 1036. The one or more application programs 1032, other program modules 1034, and program data 1036 can include, for example, the ERP application 112, the business process checker 150, the client application 410, and the plug-in application 412.

A user can enter commands and information into the computer 1002 through one or more wired/wireless input devices, e.g., a keyboard 1038 and a pointing device, such as a mouse 1040. Other input devices may include a microphone, an Infrared (IR) remote control, a joystick, a game pad, a stylus pen, touch screen, or the like. These and other input devices are often connected to the processing unit 1004 through an input device interface 1042 that is coupled to the system bus 1008, but can be connected by other interfaces, such as a parallel port, IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

A monitor 1044 or other type of display device is also connected to the system bus 1008 via an interface, such as a video adapter 1046. In addition to the monitor 1044, a computer typically includes other peripheral output devices, such as speakers, printers, etc.

The computer 1002 may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s) 1048. The remote computer 1048 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 1002, although, for purposes of brevity, only a memory/storage device 1050 is illustrated. The logical connections depicted include wired/wireless connectivity to a Local Area Network (LAN) 1052 and/or larger networks, e.g., a Wide Area Network (WAN) 1054. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, e.g., the Internet.

When used in a LAN networking environment, the computer 1002 is connected to the LAN 1052 through a wire and/or wireless communication network interface or adapter 1056. The adaptor 1056 may facilitate wire and/or wireless communication to the LAN 1052, which may also include a wireless access point disposed thereon for communicating using the wireless functionality of the adaptor 1056.

When used in a WAN networking environment, the computer 1002 can include a modem 1058, or is connected to a communications server on the WAN1054, or has other means for establishing communications over the WAN1054, such as by way of the Internet. The modem 1058, which can be internal or external and a wire and/or wireless device, is connected to the system bus 1008 via the input device interface 1042. In a networked environment, program modules depicted relative to the computer 1002, or portions thereof, can be stored in the remote memory/storage device 1050. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

The computer 1002 is operable to communicate with wire and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE 802.7 over-the-air modulation techniques) with, for example, a printer, scanner, desktop and/or portable computer, Personal Digital Assistant (PDA), communications satellite, any piece of equipment or location associated with a wirelessly detectable tag (e.g., a kiosk, news stand, restroom), and telephone. This includes at least Wi-Fi (i.e., Wireless Fidelity), WiMax, and Bluetooth^TMWireless technology. Thus, the communication may be a predefined structure as for a conventional network, or simply an ad hoc (ad hoc) communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.7x (a, b, g, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3-related media and functions).

Fig. 11 illustrates a block diagram of an exemplary communication architecture 1100 suitable for implementing various embodiments described above. The communications architecture 1100 includes various common communications elements, such as a transmitter, receiver, transceiver, radio, network interface, baseband processor, antenna, amplifiers, filters, and so forth. Embodiments, however, are not limited to implementation by communication architecture 1100.

As shown in fig. 11, the communications architecture 1100 includes one or more clients 1102 and servers 1104. Client 1102 may implement client systems 120, 220, 400. The server 1104 may implement the server ERP system 110, 210 and the supply hub 230, 300. The clients 1102 and servers 1104 are operatively connected to one or more respective client data store(s) 1108 and server data store(s) 1110 that can be employed to store information local to the respective clients 1102 and servers 1104, such as cookies and/or associated contextual information.

The clients 1102 and the servers 1104 can communicate information between each other using a communication framework 1106. The communications framework 1106 may implement any well-known communications techniques, such as techniques suitable for use with packet-switched networks (e.g., public networks such as the Internet, private networks such as an enterprise intranet, and so forth), circuit-switched networks (e.g., the public switched telephone network), or a combination of packet-switched networks and circuit-switched networks (using suitable gateways and translators). The clients 1102 and the servers 1104 may include various types of standard communication elements designed to be interoperable with the communication framework 1106, such as one or more communication interfaces, Network Interface Cards (NICs), radios, wireless transmitters/receivers (transceivers), wired and/or wireless communication media, physical connectors, and so forth. By way of example, and not limitation, communication media includes wired communication media and wireless communication media. Examples of wired communications media may include a wire, cable, wire, Printed Circuit Board (PCB), backplane, switch fabric, semiconductor material, twisted-pair wire, co-axial cable, fiber optics, a propagated signal, and so forth. Examples of wireless communication media may include acoustic, Radio Frequency (RF) spectrum, infrared and other wireless media. One possible communication between a client 1102 and a server 1104 can be in the form of a data packet adapted to be transmitted between two or more computer processes. For example, the data packet may include a cookie and/or associated contextual information.

Embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, Application Specific Integrated Circuits (ASIC), Programmable Logic Devices (PLD), Digital Signal Processors (DSP), Field Programmable Gate Array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, Application Program Interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

Some embodiments may comprise an article. An article of manufacture may comprise a storage medium to store logic. Examples of a storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, Application Program Interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. For example, in one embodiment, an article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform a method and/or operations in accordance with the described embodiments. The executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The executable computer program instructions may be implemented according to a predefined computer language, manner or syntax, for instructing a computer to perform a certain function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and/or interpreted programming language.

Some embodiments may be described using the expression "one embodiment" and "an embodiment" along with their derivatives. The terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

Some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and/or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. The term "coupled," however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

It is emphasized that this abstract of the disclosure is provided to comply with the 37c.f.r.1.72(b) abstract, which requires a quick determination of the characteristics of the technical disclosure by the reader. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "characterized by". Moreover, the terms "first," "second," "third," and the like are used merely as labels, and are not intended to impose numerical requirements on their objects.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (9)

1. A computer-implemented method, comprising:

receiving a request for a selection of an existing communication application from the ERP system;

providing the ERP system with a selection of an existing Customer Relationship Management (CRM) application;

receiving a plug-in application for the selected existing CRM application from the ERP system;

installing the plug-in application to an existing CRM application on a client, wherein a primary purpose of the existing CRM application is not to perform an ERP action, wherein the plug-in application adds Enterprise Resource Planning (ERP) functionality to the existing CRM application without using an Electronic Data Interchange (EDI) system;

establishing connection between the existing CRM application and an ERP system by using the plug-in application;

sending an ERP action from the ERP system to the plug-in application; and

performing a second ERP action, the second ERP action based on a response to the ERP action from the plug-in application.

2. The method of claim 1, wherein the ERP action comprises at least one of:

placing an order;

receiving an order;

rejecting the order;

changing the order;

confirming the order;

conditionally confirming the order;

receiving an invoice;

sending an invoice;

confirming delivery;

checking key performance indexes;

checking the inventory managed by the manufacturer; and

and checking the state of the ERP action.

3. The method of claim 1, further comprising:

receiving a notification from the ERP system at the plug-in application when an exception occurs to the ERP action performed at the plug-in application.

4. The method of claim 1, further comprising:

connecting to a supply hub in communication with the ERP system;

communicating ERP actions to the supply hub; and

receiving an ERP action from the ERP system via the provisioning hub.

5. The method of claim 1, further comprising:

verifying whether the ERP actions received from the ERP system conform to a business process;

generating a notification that an exception has occurred when the ERP action does not conform to the business process; and

sending the notification to the ERP system.

6. A computer-implemented system, comprising:

means for receiving a request for selection of an existing communication application from an enterprise resource planning, ERP, system;

means for providing the ERP system with a selection of an existing Customer Relationship Management (CRM) application;

means for receiving a plug-in application for the selected existing CRM application from the ERP system;

means for installing the plug-in application to an existing CRM application on a client, wherein a primary purpose of the existing CRM application is not to perform an ERP action, wherein the plug-in application adds ERP functionality to the existing CRM application without using an Electronic Data Interchange (EDI) system;

means for establishing a connection between the existing CRM application and an ERP system with the plug-in application;

means for sending an ERP action from the ERP system to the plug-in application; and

means for performing a second ERP action, the second ERP action based on a response to the ERP action from the plug-in application.

7. An apparatus, comprising:

a processing unit;

a client customer relationship management, CRM, application executing on the processing unit, wherein a primary purpose of the client CRM application is not to perform enterprise resource planning, ERP, actions;

a plug-in application installed on the client CRM application, wherein the plug-in application adds ERP functionality to the client CRM application without using an Electronic Data Interchange (EDI) system, for:

receiving an ERP action from the ERP system via the supply hub;

performing an action on the ERP action with a second ERP action; and

sending the second ERP action to the ERP system via the supply hub.

8. The apparatus of claim 7, wherein the plug-in application is further to:

verifying that ERP actions received from the ERP system via the supply hub are in compliance with a business process;

generating a notification that an exception has occurred when the ERP action does not conform to the business process; and

sending the notification to the ERP system via the provisioning hub.

9. The apparatus of claim 7, wherein the plug-in application is further to:

displaying ERP data in a user interface of the client CRM application;

modifying the ERP data at the plug-in application;

performing an ERP action at the plug-in application; and

updating the ERP system with ERP actions from the plug-in application.