Catalog performance and integrity analysis

Embodiments of the invention provide systems and methods for managing catalog information that can include tracking and reporting search terms used for catalog items searches. According to one embodiment, a procurement application can maintain a log of unique search phrases which returned no search results. For example, the log can maintain records from a specific time period. A count can be maintained to capture how many times a phrase was used for search within the specific time period, and used to rank the frequency of the search phrases. Search phrases that exceed that time period may be purged. The accumulated counts and associated search terms can be provided to the managers periodically and/or upon request in the form of a summary or other graphical and/or textual report or presentation.

BACKGROUND OF THE INVENTION

Embodiments of the present invention relate generally to methods and systems for managing catalog information in a procurement system and more particularly to tracking and reporting search terms used for catalog items searches for managing performance and integrity of catalog information.

Given the large number of products and services that can be requested via an Enterprise Procurement Requisitioning application, it is challenging for the catalog managers to ensure that the content available via catalog search or catalog browse functions can be easily located by the requesters. Catalog managers also face the challenge of ensuring that the catalog content stays relevant and current as products and services change and the needs of the requesters evolve. By understanding what requesters are searching for, the catalog administrators can better manage their catalog content and also reduce overhead in managing non-catalog requests and support calls as a result of requesters not locating their desired products and services.

Currently, there is no easy way for the catalog managers to have a consolidated view of what requesters are searching for, especially for products and services that they could not find when submitting a request. Rather, managers manually review non-catalog requests or support tickets, which may not always be indicative of what requesters are searching for. Hence, there is a need for improved methods and systems for tracking and reporting search terms used for catalog items searches.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the invention provide systems and methods for managing catalog information that can include tracking and reporting search terms used for catalog items searches for managing performance and integrity of catalog information. According to one embodiment, managing performance and integrity of catalog information can comprise searching the index of the externally hosted catalog and/or the one or more internal records. Managing performance and integrity of catalog information can further comprises determining whether one or more results of said search are found. In response to determining if one or more results of said searching are not found, a further determination can be made as to whether terms for said searching (i.e., the failed search terms) are unique relative to a list of failed previous search terms. In response to determining the failed search terms are not unique relative to the list of failed previous search terms, a count can be incremented for an entry in the list of failed previous search terms matching the terms for said searching. In response to determining the terms for said searching are unique relative to the list of failed previous search terms, the terms for said searching can be added to the list of failed previous search terms.

In some cases, the list of failed previous search terms can be ranked based on the count of each entry of the list. The list of failed previous search terms can be presented to an administrator or other user. The presented list can be ordered, for example, based on said ranking. In some cases, one or more entries of the list of failed previous search terms can be expired based on a pre-determined time period or otherwise periodically cleaned or purged.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention provide systems and methods for managing catalog information that can include onsite as well as externally hosted product or service information. Generally speaking, customers can create externally hosted catalogs for each supplier, and set up high level keywords so that a link to the externally hosted catalog information can be returned if requesters execute a search using these keywords. The source of where the product or service comes from does not result in issues for the requesters when trying to locate an item. Rather, the enterprise procurement application can guide the requesters to the items they are looking for regardless of the source.

Embodiments of the present invention provide for allowing catalog managers to upload externally hosted catalog item level details, such as item description, manufacturer and manufacturer part number to an externally hosted catalog and/or an index thereof. This item level information can be stored in a search index, which will allow procurement application requesters to search against individual items that reside in externally hosted catalogs without having to navigate to the external site first. Requesters can perform one search query against products and services from both local and external sources. If the search query matches items from the externally hosted catalog search index, links to the externally hosted catalog search items can be returned in the search results together with the content from the internal sources. Requester can see that the item he is looking for is on an externally hosted catalog, and can then access the externally hosted catalog to complete the requisition creation. In some cases, before going to the external catalog, the items can be evaluated more thoroughly using requester analytics and compare functionality. Various additional details of embodiments of the present invention will be described below with reference to the figures.

FIG. 1is a block diagram illustrating components of an exemplary operating environment in which various embodiments of the present invention may be implemented. The system100can include one or more user computers105,110, which may be used to operate a client, whether a dedicate application, web browser, etc. The user computers105,110can be general purpose personal computers (including, merely by way of example, personal computers and/or laptop computers running various versions of Microsoft Corp.'s Windows and/or Apple Corp.'s Macintosh operating systems) and/or workstation computers running any of a variety of commercially-available UNIX or UNIX-like operating systems (including without limitation, the variety of GNU/Linux operating systems). These user computers105,110may also have any of a variety of applications, including one or more development systems, database client and/or server applications, and web browser applications. Alternatively, the user computers105,110may be any other electronic device, such as a thin-client computer, Internet-enabled mobile telephone, and/or personal digital assistant, capable of communicating via a network (e.g., the network115described below) and/or displaying and navigating web pages or other types of electronic documents. Although the exemplary system100is shown with two user computers, any number of user computers may be supported.

The system may also include one or more server computers120,125,130which can be general purpose computers and/or specialized server computers (including, merely by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers rack-mounted servers, etc.). One or more of the servers (e.g.,130) may be dedicated to running applications, such as a business application, a web server, application server, etc. Such servers may be used to process requests from user computers105,110. The applications can also include any number of applications for controlling access to resources of the servers120,125,130.

In some embodiments, an application server may create web pages dynamically for displaying on an end-user (client) system. The web pages created by the web application server may be forwarded to a user computer105via a web server. Similarly, the web server can receive web page requests and/or input data from a user computer and can forward the web page requests and/or input data to an application and/or a database server. Those skilled in the art will recognize that the functions described with respect to various types of servers may be performed by a single server and/or a plurality of specialized servers, depending on implementation-specific needs and parameters.

The system100may also include one or more databases135. The database(s)135may reside in a variety of locations. By way of example, a database135may reside on a storage medium local to (and/or resident in) one or more of the computers105,110,115,125,130. Alternatively, it may be remote from any or all of the computers105,110,115,125,130, and/or in communication (e.g., via the network120) with one or more of these. In a particular set of embodiments, the database135may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers105,110,115,125,130may be stored locally on the respective computer and/or remotely, as appropriate. In one set of embodiments, the database135may be a relational database, such as Oracle 10 g, that is adapted to store, update, and retrieve data in response to SQL-formatted commands.

FIG. 2illustrates an exemplary computer system200, in which various embodiments of the present invention may be implemented. The system200may be used to implement any of the computer systems described above. The computer system200is shown comprising hardware elements that may be electrically coupled via a bus255. The hardware elements may include one or more central processing units (CPUs)205, one or more input devices210(e.g., a mouse, a keyboard, etc.), and one or more output devices215(e.g., a display device, a printer, etc.). The computer system200may also include one or more storage device220. By way of example, storage device(s)220may be disk drives, optical storage devices, solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable and/or the like.

The computer system200may additionally include a computer-readable storage media reader225a, a communications system230(e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory240, which may include RAM and ROM devices as described above. In some embodiments, the computer system200may also include a processing acceleration unit235, which can include a DSP, a special-purpose processor and/or the like.

The computer-readable storage media reader225acan further be connected to a computer-readable storage medium225b, together (and, optionally, in combination with storage device(s)220) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system230may permit data to be exchanged with the network220and/or any other computer described above with respect to the system200.

The computer system200may also comprise software elements, shown as being currently located within a working memory240, including an operating system245and/or other code250, such as an application program (which may be a client application, web browser, mid-tier application, RDBMS, etc.). It should be appreciated that alternate embodiments of a computer system200may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed. Software of computer system200may include code250for implementing embodiments of the present invention as described herein.

FIG. 3is a block diagram illustrating, at a high-level, functional components of a system for managing catalog information according to one embodiment of the present invention. As illustrated in this example, the system300can include a procurement system305such as any of the computer systems described above executing a procurement application such as an enterprise procurement application. As noted above, the procurement system can provide for managing catalog information335that can include onsite340, i.e., for which records are maintained by the procurement system, as well as external product or service information345, i.e., for which records are maintained by a system other than the procurement system such as a system of or operated by a supplier.

Generally speaking, an operator of the procurement system, such as an administrator accessing the procurement system305through an on-site catalog administrator user interface355to interact with a catalog generation and maintenance module310of the procurement system305, can create externally hosted catalogs and links thereto for each externally hosted catalog supplier, and set up high level keywords so that information from the externally hosted catalogs can be returned, e.g., through a catalog user interface365, if requesters execute a search using these keywords. For example, catalog managers can upload or assign through the on-site catalog administrator user interface355externally hosted catalog item level details, such as item description, manufacturer and manufacturer part number to an externally hosted catalog. On-site catalog information340can be stored in a set of catalog information335maintained by the procurement system305.

For external items, i.e., catalog items for which records storing the item level information is maintained by the supplier or on another system other than the procurement system, a search index350can be generated by the catalog indexing module315and stored in the catalog information335of the procurement system305. The index350can allow procurement application requesters to search for individual items that reside in an external catalog data345without having to navigate to, or access an external site, e.g., the site of the supplier, first. Therefore, requesters can, for example through the catalog user interface365, perform one search query against products and services from both local and external sources, i.e., search on the internal records of the on-site catalog data340and on the index350for external records of the external catalog data345. If the search query matches items from the externally hosted catalog search index350, the externally hosted catalog search items can be returned in the catalog user interface365in the search results together with the content from the internal sources. Requester can see that the item he is looking for is on an externally hosted catalog, and can then access, e.g., be redirected to the system380hosting the external records345, to complete the requisition creation. In some cases, externally hosted catalog search items can be added to a user's personal list (e.g., a favorites list). In such cases, the user can see this item in his list when he returns to the procurement system.

Stated another way, managing catalog information335in a procurement system305can begin with creating a catalog comprising records of a plurality of items. The records can comprise one or more internal records340maintained by the procurement system305as well as one or more external records345maintained by a system other than the procurement system305. Information corresponding to each of the one or more external records can be stored in an index350of the externally hosted catalog. For example, the index can contain attributes for an item, such as but not limited to the description of the item, category, supplier, supplier item number, manufacturer, manufacturer part number. If a user searches in the procurement system with a search phrase that matches any of these attributes in the index, the item can be displayed to the user.

As the catalog is used by one or more users, for example through the catalog user interface365, search terms for items of the externally hosted catalog can be received by the system305. In response, a search can be performed by the search engine320of the procurement system305on the index350of the externally hosted catalog and the one or more internal records340to identify items of the plurality of items matching the search terms. Records corresponding to the identified items can be returned by the search engine320through the catalog user interface365based on searching the index350of the externally hosted catalog and the one or more internal records340for the search terms. For example, a list can be provided in the catalog user interface365of the returned records corresponding to the identified items. Depending upon the search results, the returned records can include external and internal records for items of the catalog. Upon selection of the at least one external record from the list through the catalog user interface365, the selected external record345can be retrieved by the procurement system305from the supplier or other system or the user may be directed to the external system, e.g., by a link to the external record, and the item corresponding to the selected record can be added to a requisition by the procurement system305.

According to one embodiment, the procurement system305can also provide an external catalog administrator user interface360. Generally speaking, through the catalog administrator user interface360the procurement system305can allow suppliers to maintain the externally hosted catalog search items for an externally hosted catalog. By delegating the maintenance of the externally hosted catalog search items to the supplier, the buying organization will be able to specify if the supplier on an externally hosted catalog can perform uploads for that catalog, receive notifications when a supplier had performed an upload for an externally hosted catalog, review the content/updates uploaded by the supplier, approve/reject the updates from the supplier before changes take effect. This can provide for maintaining the integrity of the search index.

More specifically, after the buying organization and the supplier agree on the list of externally hosted catalog items and prices, the catalog administrator, through the on-site catalog administrator user interface355can create an externally hosted catalog containing information as described above. The catalog administrator can also enable the externally hosted catalog for the supplier to update the externally hosted catalog search items, i.e., external records represented in the index350, through the external catalog administrator user interface360. Using this interface360, the supplier can access the list of externally hosted catalog catalogs that have been enabled for him to maintain indexed externally hosted catalog search items. The supplier can choose to upload search information and, after submitting an upload job, the catalog administrators can view, through the on-site catalog administrator user interface355the upload status to determine if the externally hosted catalog search items have been successfully loaded or if there are errors that need to be fixed. Validation can be performed on the items in an upload file to ensure data integrity. Uploaded data may also be transformed using supplier map sets that are predefined in the application, if applicable. The existing functionality, supplier map sets, is used to map supplier, supplier site, UOM and category values used externally to values that are used internally in the procurement system305.

After errors are addressed, the supplier can submit the changes for the buying organization to review. The catalog administrator can receive a notification through the on-site catalog administrator user interface355indicating that an externally hosted catalog has been updated by the supplier. Through this interface, the catalog administrator can view new items added, items removed, items updated, etc. The catalog administrator can then approve/reject the changes through the on-site catalog administrator user interface355. If approved, the changes can take effect and requestors with access to the catalog can see the changes when searching for items in the externally hosted catalog through the catalog user interface365.

Stated another way, managing catalog information in a procurement system305can begin with an administrator interacting with the catalog generation and maintenance module310through the on-site catalog administrator user interface355to create a externally hosted catalog comprising records of a plurality of items. The records can comprise one or more internal records340maintained by the procurement system305as well as one or more external records345maintained by a system other than the procurement system305. Information corresponding to each of the one or more external records345can be stored in an index350of the externally hosted catalog information350.

After the externally hosted catalog has been established, an update can be received, for example through the external catalog administrator user interface360, for one or more of the external records345. A summary can be provided to the administrator through the on-site catalog administrator user interface355of a difference between the index information350and the update of the external record345. This update of the external record345can be validated or not by the administrator through the on-site catalog administrator user interface355. In response to unsuccessfully validating the update of the external record345, the update of the external record345can be provided through the external catalog administrator user interface360for correction. In response to successfully validating the update of the external record345, the index350of the externally hosted catalog information335can be updated accordingly to reflect the update of the external record345.

As noted above, the procurement application of the procurement system305can support multiple sources of products and services available for users to create requisitions. These include products and services from internal sources or external sources. Processes and policies can be enforced systematically to enforce negotiated pricings for products and services from internal sources. However, the source of where the product or service comes from should not deter the users or administrators of the procurement system305from applying standards and processes to enforce negotiated prices. Rather, the source should be transparent, and customers can rely on the procurement enterprise application to perform price audits.

According to one embodiment, discrepancies in the negotiated price can be reported through on-site catalog administrator user interface355when an externally sourced externally hosted catalog item is added to a requisition. For example, the list of externally hosted catalog items and prices negotiated with a supplier can be maintained by way of the search index350. As noted above, the index350information can be uploaded and maintained by the catalog administrator through on-site catalog administrator user interface355. If pricing information is uploaded and the catalog administrator indicated that price audit checks should be performed, then prices returned from the externally hosted catalog supplier can be verified through variance analyzer module325. The catalog administrator can also specify a price tolerance to determine when a price variance is considered an audit failure.

A price variance between the negotiated price (on the externally hosted catalog search index) and the price returned by the externally hosted catalog supplier can be indicated and stored. Storing the price difference captures the variance at the point when the price audit is performed. When the catalog administrator next logs into the on-site catalog administrator user interface355, they can be presented with analytics such as the number of requisition lines with price audit failures by supplier and/or the total amount of price audit failures by supplier. For example, a total variance amount for a supplier can be determined as:
Σn=1n=k(Quantityn*Price Variancen)
Where k is the total number of requisition lines with failed price audit checks. These two pieces of information can provide the catalog administrator with a picture of the external supplier's performance in terms of honoring the negotiated prices. The catalog administrator through the on-site catalog administrator user interface355can drill down on these analytics to view detailed requisition line level information, such as the item and the price variance.

Stated another way, a negotiated price can be received for each item stored in an external record345and a tolerance for a difference between the negotiated price for the item and an actual price of the item. The negotiated price for each item can be stored, for example in index350. At a later point, for example during the adding to a requisition of an external item as described above, an actual price for an item stored in an external record345can be received. A price variance of the item from the negotiated price can be calculated by the variance analyzer module325and a determination can be made by the variance analyzer module325as to whether the price variance is within a predefined tolerance. The tolerance can be, for example, set for a particular catalog or all catalogs. In some cases, the tolerance can be zero. In response to determining that the price variance is not within the tolerance, the price variance amount can be stored in the requisition by the variance analyzer module325, analytics for the price variance can be presented, for example in an overview page of the on-site catalog administrator user interface355, and a follow-up with a supplier can be initiated by the variance analyzer module325. For example, a message can be provided to an administrator to follow up with a supplier, a message can be sent to the supplier, a workflow can be started, etc.

Given the large number of products and services that can be requested via an enterprise procurement application, it is challenging for the catalog managers to ensure that the content available via a catalog search or catalog browse can be easily located by the requesters. Catalog managers also face the challenge of ensuring that the catalog content stays relevant and current as products and services change and the needs of the requesters evolve. By understanding what requesters are searching for and not finding, the catalog administrator can better manage their catalog content and also reduce overhead in managing requests and support calls as a result of requesters not locating their desired products and services.

According to one embodiment, to help catalog managers understand the search trends and what requesters are searching for, a list370of search phrases that returned no results can be maintained, for example by performance and integrity management module330, and made available to the catalog managers, for example through on-site catalog administrator user interface355. Administrators can review this information for each search request and decide if the catalog content needs to be modified either by adding new items or by updating existing item attributes to improve discoverability of the items. Therefore, a log or list370of unique search phrases in shopping pages, which returned no search result can be maintained by the performance and integrity management module330. A count can be maintained to capture how many times a particular phrase was used for search within a specific time period. This count can be used to rank the frequency of the search phrases when presented in the on-site catalog administrator user interface355. Search phrases that exceed a pre-defined time period can be purged.

Stated another way, searching the index350of the externally hosted catalog and/or the one or more internal records340by the performance and integrity management module330can further comprise determining whether one or more results of said searching are found. In response to determining one or more results of said searching are not found, a further determination can be made as to whether terms for said searching are unique relative to a list370of failed previous search terms. In response to determining the terms for said searching are not unique relative to the list370of failed previous search terms, a count can be incremented for an entry in the list370of failed previous search terms matching the terms for said searching. In response to determining the terms for said searching are unique relative to the list370of failed previous search terms, the terms for said searching can be added to the list370of failed previous search terms.

In some cases, the list370of failed previous search terms can be ranked based on the count of each entry of the list370. The list370of failed previous search terms can be presented to an administrator or other user, for example through the on-site catalog administrator user interface355. The presented list can be ordered, for example, based on said ranking. In some cases, one or more entries of the list370of failed previous search terms can be expired based on a pre-determined time period or otherwise periodically cleaned or purged.

FIG. 4is a flowchart illustrating a process for managing catalog information according to one embodiment of the present invention. In this example, managing catalog information in a procurement system can begin with creating405a catalog comprising records of a plurality of items. The records can comprise one or more internal records maintained by the procurement system as well as one or more external records maintained by a system other than the procurement system. Information corresponding to each of the one or more external records can be stored410in an index of the externally hosted catalog.

As the catalog is used by one or more users, search terms for items of the catalog can be received415. In response, a search420can be performed on the index of the externally hosted catalog and the one or more internal records to identify items of the plurality of items matching the search terms. A list can be provided430of the returned records corresponding to the identified items. Depending upon the search results, the returned records can include external and internal records for items of the catalog.

Upon selection435of the at least one external record from the list, a determination438can be made as to whether the selected435record is an internal record or an external record. If the selected435record is an external record, the user can be redirected442to the system hosting the external record. If the selected435record is an internal record, the selected external record can be retrieved440from the system external to the procurement system and information from the retrieved external record can be presented445to the user. Upon a selection450of a record of the returned records, the item corresponding to the selected record can be added455to a requisition.

FIG. 5is a flowchart illustrating a process for managing catalog information according to one embodiment of the present invention. In this example, managing catalog information in a procurement system can begin with creating505a catalog comprising records of a plurality of items. The records can comprise one or more internal records maintained by the procurement system as well as one or more external records maintained by a system other than the procurement system. Information corresponding to each of the one or more external records can be stored510in an index of the externally hosted catalog.

After the externally hosted catalog has been established, an update can be received515for one or more of the external records. A summary can be provided520of a difference between the external record and the update of the external record. This update of the external record can be validated525. In response to unsuccessfully validating525the update of the external record, the update of the external record can be provided for correction. In response to successfully validating525the update of the external record, the externally hosted catalog can be updated535with the update of the external record.

As the catalog is used by one or more users, search terms for items of the externally hosted catalog can be received540. In response, a search545can be performed on the index of the externally hosted catalog and the one or more internal records to identify items of the plurality of items matching the search terms. A list can be provided555of the returned records corresponding to the identified items. Depending upon the search results, the returned records can include external and internal records for items of the catalog. Upon selection560of the at least one external record from the list, the selected external record can be retrieved565from the system external to the procurement system and information from the retrieved external record can be presented570to the user. Upon a selection575of a record of the returned records, the item corresponding to the selected record can be added580to a requisition.

FIG. 6is a flowchart illustrating a process for performing variance analysis of catalog information according to one embodiment of the present invention. For example, a negotiated price can be receiving605for each item stored in an external record and a tolerance for a difference between the negotiated price for the item and an actual price of the item. The negotiated price and the tolerance for each item can be stored610. At a later point, for example during an update of an external item as described above, an actual price for an item stored in an external record can be received615. A price variance of the item from the negotiated price can be calculated620and a determination622can be made as to whether there is a variance. In response to determining622there is a variance, a determination625can be made as to whether the price variance is within the tolerance. In response to determining625that the price variance is not within the tolerance, the price variance amount can be stored635, analytics for the price variance can be presented640, for example in an overview page, and a follow-up with a supplier can be initiated645. However, in response to determining622there is no variance or determining625that the variance is within the tolerance, a price audit failure indication can be set to a false condition.

FIG. 7is a flowchart illustrating a process for managing performance and integrity of catalog information according to one embodiment of the present invention. For example, searching705the index of the externally hosted catalog and/or the one or more internal records can further comprises determining710whether one or more results of said search are found. In response to determining710if one or more results of said searching are not found, a further determination715can be made as to whether terms for said searching (i.e., the failed search terms) are unique relative to a list of failed previous search terms. In response to determining715the failed search terms are not unique relative to the list of failed previous search terms, a count can be incremented725for an entry in the list of failed previous search terms matching the terms for said searching. In response to determining715the terms for said searching are unique relative to the list of failed previous search terms, the terms for said searching can be added720to the list of failed previous search terms.

In some cases, the list of failed previous search terms can be ranked730based on the count of each entry of the list. The list of failed previous search terms can be presented735to an administrator or other user. The presented list can be ordered, for example, based on said ranking. In some cases, one or more entries of the list of failed previous search terms can be expired based on a pre-determined time period or otherwise periodically cleaned or purged.