Patent Application
20170161809
In many businesses, procurement of products and/or services may require a lengthy process involving many different parties. A typical procurement involves a requester who orders the items for the business. The requester may find the particular items in a catalog, and then passes along the request to a buyer group. Often, there is no pre-existing relationship between the requester and the buyer group, and as such, the requester has no information as to the reliability of the buyer, and therefore has little control after the request leaves the requester. Then the buyer secures a supplier for the procurement request. Thus, the requester loses another degree of control with the procurement. Further, because of the exchanging of the request between multiple parties, there often tends to be latency in the order being fulfilled.
Therefore, there exists a need for a procurement recommendation system by which a requester can have some level of control throughout the procurement process, including being able to tailor the buyer and the supplier to the requester's particular needs and demands, while also streamlining the process to reduce any latency issues.
Generally, procuring items and/or services, for example for an office space or workstation, may involve communication between many different parties, thereby resulting in potential latency with the requests and therefore delay in ultimately procuring the items and/or services. In addition, there may be uncertainty as to which buyers to use to procure the items and/or services and/or which suppliers may be most reliable or may best fit the needs of the particular procurement. To address these and other issues, an exemplary procurement system may include at least one server in communication with a computing device over a communication network. The at least one server may be configured to receive from the computing device identification of at least one desired product or service to procure, and then generate an RFx, which may include, but is not limited to, a request for information (RFI), request for proposal (RFP), or a request for quotation (RFQ) for the at least one desired product or service. The at least one server may also be configured to determine at least one of at least one recommended buyer to procure the desired at least one product or service, and at least one recommended supplier of the desired at least one product or service. The at least one server may further be configured to generate on the graphical user interface of the computing device at least one of a list of the at least one recommended buyer, and a list of the at least one recommended supplier.
Referring now to the figures,
The system 100 may also include a procure-to-pay (P2P) engine 104 that may include an application server 106 and a database server 108. While
The system 100 further may include a primacy engine 110 that may include an application server 112 and a database server 114. While
Referring now to
In general, computing systems and/or devices, such as the requester 102, the application server 106 and database server 108 of the P2P engine 104, and the application server 112 and the database server 114 of the primacy engine 110, may include at least one memory and at least one processor. Moreover, they may employ any of a number of computer operating systems, including, but not limited to, versions and/or varieties of the Microsoft Windows® operating system, the Unix operating system (e.g., the Solaris® operating system distributed by Oracle Corporation of Redwood Shores, Calif.), CentOS, the AIX UNIX operating system distributed by International Business Machines of Armonk, N.Y., the Linux operating system, the Mac OS X and iOS operating systems distributed by Apple Inc. of Cupertino, Calif., the BlackBerry OS distributed by Research In Motion of Waterloo, Canada, and the Android operating system developed by the Open Handset Alliance. Further, the computing Examples of computing devices include, without limitation, a computer workstation, a server, a desktop, a notebook, a laptop, a handheld computer, a smartphone, a tablet, or some other computing system and/or device.
Such computing devices generally include computer-executable instructions, where the instructions may be executable by one or more computing devices such as those listed above. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java™, C, C++, C#, Objective C, Visual Basic, Java Script, Perl, Tomcat, representational state transfer (REST), etc. In general, the processor (e.g., a microprocessor) receives instructions, e.g., from the memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media.
A computer-readable medium (also referred to as a processor-readable medium) includes any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instruction) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including, but not limited to, non-volatile media and volatile media. Non-volatile media may include, for example, optical or magnetic disks and other persistent memory. Volatile media may include, for example, dynamic random access memory (DRAM), which typically constitutes a main memory. Such instructions may be transmitted by one or more transmission media, including, but not limited to, coaxial cables, copper wire, and fiber optics, including the wires that comprise a system bus coupled to a processor of a computer. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
Databases, data repositories or other data stores, such as included with the database servers 106 and 114, may include various kinds of mechanisms for storing, accessing, and retrieving various kinds of data, including a hierarchical database, a set of files in a file system, an application database in a proprietary format, a relational database management system (RDBMS), etc. Each such data store is generally included within a computing device employing a computer operating system such as one of those mentioned above, and are accessed via a network in any one or more of a variety of manners. A file system may be accessible from a computer operating system, and may include files stored in various formats. An RDBMS generally employs the Structured Query Language (SQL) in addition to a language for creating, storing, editing, and executing stored procedures, such as the PL/SQL language mentioned above.
In some examples, system elements may be implemented as computer-readable instructions (e.g., software) on one or more computing devices (e.g., servers, personal computers, etc.), stored on computer readable media associated therewith (e.g., disks, memories, etc.). A computer program product may comprise such instructions stored on computer readable media for carrying out the functions described herein. Alternatively, the application software product may be provided as hardware or firmware, or combinations of software, hardware, and/or firmware.
Referring now to
After block 205, process 200 may proceed to block 210 in which the P2P engine 104 may provide a catalog of items, i.e., products and/or services, from which the requester 102 may choose to procure and add to a virtual shopping cart. The selected item(s) may be subject to an active price agreement, an expired price agreement, or not subject to a previous price agreement, or the catalog may not have the desired item(s). For scenarios in which the item(s) may be subject to an active price agreement, process 200 may proceed to block 215 in which the requester 102 may choose to checkout with the selected item(s). Then at block 220, system 100 may create a requisition and submit it for approval, after which process 200 may end. Thus, generally if the item(s) is subject to a price agreement, the primacy engine 110 may play no role, as no buyer or supplier needs to be recommended, as these parties are already set according to the active price agreement. The existence and status of the price agreement generally may be stored in any database, including the P2P database server 108.
For scenarios in which the item(s) may be subject to an expired price agreement or not subject to a price agreement at all, process 200 may proceed to block 230 in which the requester 102 may choose to checkout with the selected item(s). For scenarios in which the desired item(s) are not in the catalog, process 200 may first proceed to block 225 in which the P2P engine 104 may provide the requester 102 with a form or other entry fields, for example, by generating the form on the graphical user interface of the requester 102. The requester 102 may then input information relating to the desired item(s), including but not limited to, name, category, unit price, and the like. The provided information may allow the P2P engine 104 to identify and look up the item(s) in the database server 108 or any other source accessible over the communications network. After block 225, process 200 may proceed to block 230 in which the requester 102 may choose to checkout with the desired item(s). During checkout, the requester 102 may provide additional information, including, but not limited to, shipping address, which may be inputted in an entry field or may be selected from a list of previously established addresses that may be associated with the account of the requester 102, a “Required by” date by which the requester 102 may require the item(s), additional comments and/or instructions that may be provided to a buyer and/or a supplier, and the like. When this is complete, the P2P engine 104 may generate an RFx, and may provide transactional information to the requester 102, such as an RFx number and/or a cart ID.
Buyer Recommendation/Selection
At block 235, a buyer may be determined. The buyer may have different roles in the procurement process depending upon selections received from the requester 102, for example, via the configuration screen in
Referring now to
At block 420, the requester 102 may select a buyer from the list of recommended buyers for each item. If the requester 102 does not select a buyer, process 400 may proceed to block 425 in which the P2P engine 104 or the primacy engine 110 may select the highest ranking buyer. The ranking may be determined based on the buyer information, for example, a weighing of the different factors, the importance of which may be set by the requester 102. At block 430, the RFx may then be assigned to the selected buyer. Where different items, for example, Item_1 and Item_2 in
At block 440, prior to the RFx being inserted into the buyer's queue, the primacy engine 110 may assign a priority index to the RFx based on different parameters, including, but not limited to, the total value of the RFx, the type of request, e.g., service or material, a category of the item(s), the requesters, and the due date. Thus, when the RFx is inserted into the buyer's queue, it may be prioritized with other RFx's in the queue. Any one of these parameters may be set in the system 100 as a default for sorting the RFx's in the buyer's queue, and the default may be changed by the requester 102. In addition or alternatively, a primacy index of the RFx may be calculated, for example using a weighted arithmetic mean method. The primacy index may then be compared with the primacy indices of other RFx's in the queue, and inserted into the queue according to its priority at block 445. Process 400 may end thereafter.
Supplier Recommendation/Selection
Referring back to
Quality of the supplier may be based on such sub-parameters as subscription status, amount achieved in the previous quarter, and number of returns due to bad quality. Performance of the supplier may be based on such sub-parameters as on-time delivery, late delivery, and actual versus quoted lead time. The primacy engine 110 may determine whether past deliveries were on-time or late by obtaining purchase order information from the P2P database server 108, and comparing a delivery due date and an actual receipt date. The cost of using the supplier may be based on such sub-parameters as payment terms, payment methods, freight terms, and total cost variation. The primacy engine 110 may again obtain purchase order information from the P2P database server 108 and calculate the number of times the supplier maintained default payment terms and/or freight terms. The responsiveness of the supplier may be based on such sub-parameters as number of emergency quotes, order processing, and compliance to payment terms. With respect to emergency quotes, the primacy engine 110 may obtain RFx response data and may calculate the response time by the supplier. With respect to order processing, the primacy engine 110 may obtain purchase order information, and may calculate the average time taken by the supplier to process an order. With respect to compliance with payment terms, the primacy engine 110 may obtain purchase order information, and may calculate the number of purchase orders with exception payment terms for emergency orders. The risk of using the suppliers may be based on such sub-parameters as supplier location, product availability, non-conformance incidents, and a Dun & Bradstreet rating for that supplier. The primacy engine 110 may obtain this information from the market place 118. Internal review may be based on such sub-parameters as a supplier survey and a cost of poor quality. The supplier review may be based on feedback, such as a rating, provided by the requesters 102 and buyers once the transaction is completed. It should be appreciated that there may be any number of parameters and sub-parameters.
Referring now to
For each supplier, based on the supplier base data obtained from the market place 118, the primacy engine 110 may determine within which range, and therefore which level, the supplier falls. Using a weighted arithmetic mean method based on the priorities established by the requester 102, the primacy engine 110 may then calculate a primacy index number for each supplier. The primacy engine 110 may then rank the suppliers based on their primacy index numbers.
New suppliers generally may provide information to create a scorecard. The information may include, but is not limited to, the following categories: (1) payment terms; (2) freight terms; (3) category (filter criteria); (4) favorite supplier (filter criteria); (5) location of supplier (distance from source); (6) payment methods; (7) willingness to use the system; (8) online supplier survey; (9) DB rating. The requester 102 may similarly select and/or apply a rank of the different categories. Each category may have a range and a level of importance. The primacy engine 110 may calculate a primacy index number for each supplier, also using a weighted arithmetic mean method based on the priorities established by the requester 102, and then rank the new suppliers based on the their primacy index numbers.
At block 610, the primacy engine 110 may recommend a set number of existing suppliers with the highest primacy index numbers and/or a set number of new suppliers with the highest primacy index numbers. The number of recommended existing and new suppliers may be configurable by the requester 102. A list of the recommended existing and/or new suppliers may be generated on the graphic user display of the requester 102. At block 615, the P2P engine 104 may then assign the RFx to the recommended suppliers, including a date by which a quote is due.
At block 620, the P2P engine 104 may receive quotes from the suppliers. If the quotes are not received by the quote due date, the P2P engine 104 may be configured to extend the due date by a set number of days configurable by the requester 102, and may also add a set number of the next suppliers in the rankings that were not previously recommended. The P2P engine 104 may then provide the quotes to the primacy engine 110 to be evaluated. At block 625, the primacy engine 110 may select a quote to whom to award the requisition for the item(s). In doing so, the primacy engine 110 may evaluate such parameters as price and/or lead time. The parameters may be configurable by the requester 102. For each parameter, the primacy engine 110 may be configured to determine if the variance between the minimum quoted value and the maximum quoted value is within a configurable variance. For example, if the price variance between the lowest quoted price and the highest quoted price is less than 10%, then the primacy engine 110 may be configured to assign the RFx back to the buyer to negotiate further on the RFx with the suppliers. If the variance is 10% or above, the primacy engine 110 may award the requisition to the best quote, e.g., lowest price. Process 600 may end thereafter.
Approval Chain
Referring back to
The primacy engine 110 may obtain the approver data based on the selected buyer and/or the category of the procured item(s), and may provide a recommended approval chain along with such information as the average wait time and the approval probability, as seen in the exemplary screenshot 800 in
With regard to the processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claims.
Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent upon reading the above description. The scope should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the application is capable of modification and variation.
All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those knowledgeable in the technologies described herein unless an explicit indication to the contrary is made herein. In particular, use of the singular articles such as “a,” “the,” “said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.
The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. 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 various embodiments 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 separately claimed subject matter.
