Embodiments of the present invention relate to enterprise applications, and more particularly relate to techniques for supporting shared procurement services in an enterprise application.
In recent years, many enterprises have moved toward a shared services model for structuring their business operations. In a shared services model, one or more business operations (e.g., payables payments, payroll processing, procurement, etc.) are consolidated in specific business units in an enterprise. The business units may then expose these consolidated business functions as services that are provisioned to (and thus shared by) other business units in the enterprise. For example, an enterprise comprising a “US Administration” business unit and a “US Commercial” business unit may be structured such that all payroll processing is consolidated in the US Administration business unit. In this scenario, an outsourcing relationship may be created between the two business units that enables the US Administration business unit (known as a service provider) to perform the payroll processing business function on behalf of the US Commercial business unit (known as a client). By implementing a shared services model, enterprises can achieve higher economies of scale and greater business unit specialization, thereby improving operational efficiency and realization of business objectives.
Procurement is an example of a business operation that is well-suited to consolidation per a shared services model. As used herein, procurement refers to the acquisition of goods and/or services for the benefit of or use by entities in an enterprise. Procurement requisitions (e.g., requests to purchase raw materials, office supplies, capital equipment, etc.) are typically generated by many business units in an enterprise. However, the end-to-end procurement business process comprises a number of tasks that are difficult or inefficient to duplicate in each business unit. Accordingly, it is advantageous to establish procurement service providers (e.g., procurement business units) in an enterprise that are specifically adapted to perform some or all of these procurement tasks on behalf of procurement clients (e.g., requisition-generating, or “requisitioning,” business units) in the enterprise.
One challenge with implementing shared procurement services is that existing enterprise applications in the procurement field are not designed to support a shared services model. For example, while existing enterprise applications are capable of modeling an enterprise as a collection of business units, they generally cannot model the various outsourcing relationships that may exist between procurement service providers and procurement clients. As a result, existing enterprise applications cannot leverage these outsourcing relationships to streamline or otherwise facilitate the procurement process.
Embodiments of the present invention provide techniques for supporting shared procurement services in an enterprise application. According to one set of embodiments, associations between procurement service providers and procurement clients are stored, where the associations represent outsourcing relationships between these entities in the operational structure of an enterprise. The associations are then used by the application to facilitate the management of procurement-related content and the processing of procurement transactions. In one embodiment, the associations enable procurement-related content to be created/managed centrally by a procurement service provider and then made accessible to procurement clients serviced by the procurement service provider. In another embodiment, a rules-driven mechanism is provided for routing procurement requisitions from procurement clients to associated procurement service providers for processing.
According to one embodiment of the present invention, a method for filtering procurement requisitions is provided. The method comprises storing, by a computer system, an association between a first entity and a second entity in an enterprise, where the association indicates that the first entity is configured to process procurement requisitions generated by the second entity. The method further comprises storing, by the computer system, a plurality of procurement requisitions generated by one or more entities in the enterprise, where the plurality of procurement requisitions include a first subset of procurement requisitions generated by the second entity. A second subset of procurement requisitions from the first subset is then selected by the computer system for processing by the first entity based on a procurement specialization of the first entity.
In one embodiment, the method above further comprises storing, by the computer system, an association between a third entity and the second entity in the enterprise, where the association between the third entity and the second entity indicates that the third entity is configured to process procurement requisitions generated by the second entity. A third subset of procurement requisitions from the first subset is then selected by the computer system for processing by the third entity based on a procurement specialization of the third entity.
In one embodiment, selecting a second subset of procurement requisitions from the first subset for processing by the first entity based on a procurement specialization of the first entity comprises comparing one or more attributes of each procurement requisition in the first subset to one or more keywords related to the procurement specialization of the first entity.
In one embodiment, the procurement specialization corresponds to a specialization for procuring a specific type of commodity. In another embodiment, the procurement specialization corresponds to a specialization for procuring goods in a specific geographic region.
In one embodiment, the one or more attributes of the procurement requisition include one or more of: requisition type, ship from location, and ship to location.
In one embodiment, the plurality of procurement requisitions are stored in a common pool, and wherein the second subset of procurement requisitions is removed from the common pool when selected for processing by the first entity.
In one embodiment, the selecting is performed for the first entity at predetermined time intervals. In another embodiment, the selecting is performed for the first entity by a batch program executed by the computer system.
According to another embodiment of the present invention, a system for filtering procurement requisitions is provided. The system comprises a memory component configured to store an association between a first entity and a second entity in an enterprise, where the association indicates that the first entity is configured to process procurement requisitions generated by the second entity, and store a plurality of procurement requisitions generated by one or more entities in the enterprise, where the plurality of procurement requisitions include a first subset of procurement requisitions generated by the second entity. The system further comprises a processing component in communication with the memory component, the processing component being configured to select a second subset of procurement requisitions from the first subset for processing by the first entity based on a procurement specialization of the first entity.
According to another embodiment of the present invention, a machine-readable storage medium having stored thereon program code executable by a processing component of a computer system is provided. The program code comprises code that causes the processing component to store an association between a first entity and a second entity in an enterprise, where the association indicates that the first entity is configured to process procurement requisitions generated by the second entity; code that causes the processing component to store a plurality of procurement requisitions generated by one or more entities in the enterprise, where the plurality of procurement requisitions include a first subset of procurement requisitions generated by the second entity; and code that causes the processing component to select a second subset of procurement requisitions from the first subset for processing by the first entity based on a procurement specialization of the first entity.
A further understanding of the nature and advantages of the embodiments disclosed herein may be realized by reference to the remaining portions of the specification and the attached drawings.
In the following description, for the purposes of explanation, numerous details are set forth in order to provide an understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these details.
Embodiments of the present invention provide a framework that enables an enterprise application to support shared procurement services. As used herein, an enterprise application is a software application that is used by an enterprise to automate or facilitate its business operations.
In one set of embodiments, the techniques described herein allow for the creation of associations between procurement service providers (e.g., procurement business units) and procurement clients (e.g., requisitioning business units) that model outsourcing relationships between these entities in the operational structure of an enterprise. An outsourcing relationship is a relationship in which a first entity (i.e, a service provider) provisions services to a second entity (i.e., a client) distinct from the first entity. In the context of a shared procurement model, a procurement service provider is configured to provision procurement services to (i.e., perform procurement tasks on behalf of) a procurement client.
The associations may then be used by the application to facilitate the management of procurement-related content and the processing of procurement transactions. In one embodiment, procurement-related content (i.e., data that is relevant to the procurement business process) may be created/managed centrally by a procurement service provider and then shared with one or more procurement clients serviced by the procurement service provider. In another embodiment, procurement requisitions generated by procurement clients may be automatically filtered based on the associations and a set of business rules to determine which procurement service providers should process the requisitions.
By way of definition, supply base management refers to the process of identifying new suppliers of goods and/or services, evaluating existing suppliers, and running initiatives to improve supplier performance in a proactive way. Sourcing refers to the process of identifying an optimum source for goods/services from a supply base. This typically involves asking for proposals from potential suppliers, evaluating the bids, and then placing awards for orders or agreements based on the evaluation. Purchase order administration refers to the process of raising purchase orders for suppliers in response to requisitions for goods/services, communicating orders to the suppliers, ensuring their acknowledgment, handling queries on the orders from suppliers and requesters, and ensuring satisfactory fulfillment of the orders and their timely settlement. Catalog content management refers to creating and managing electronic catalogs based on pre-negotiated pricing agreements. The electronic catalogs are used by requisitioning business units to select requisition items. And agreement/contract management refers to the process of authoring and maintaining purchase agreements with suppliers with pre-negotiated terms and conditions including pricing of goods and/or services to be acquired over the period of the agreement.
The arrows in
In one set of embodiments, procurement business units 106, 108 may each have a procurement specialization. When a procurement service provider is said to have a procurement specialization, that procurement service provider is particularly adapted to procure goods and/or services with respect to a specific domain, such as a specific commodity, a specific geographic region, etc. Examples of different commodities include office supplies, computer equipment, and the like. Examples of different geographic regions include North America, Canada, Mexico, Asia/Pacific, and the like. In the example of
As shown, enterprise 100 may also include one or more hybrid business units 110. For the purposes of the present disclosure, a hybrid business unit is an entity in an enterprise that is configured to act as both a procurement service provider and a procurement client. For example, in
At step 202, a first set of business units in an enterprise are designated as procurement business units within the application. Generally speaking, the first set of business units will comprise one or more business units that perform (or are intended to perform) procurement tasks in the operational structure of the enterprise. For example, the first set of business units may comprise procurement business units 106, 108 in enterprise 100 of
At step 204, a second set of business units in the enterprise are designated as requisitioning business units within the application. Generally speaking, the second set of business units will comprise one or more business units that generate (or are intended to generate) procurement requisitions in the operational structure of the enterprise. For example, the second set of business units may comprise requisitioning business units 102, 104 in enterprise 100 of
Although not shown in flowchart 200, in some embodiments a third set of business units in the enterprise may be designated as both procurement and requisitioning business units within the application. For example, the third set of business units may comprise a hybrid business unit such as hybrid business unit 110 of
In one set of embodiments, designating a business unit as a procurement business unit or a requisitioning business unit per steps 202 and 204 comprises assigning a procurement business function or a requisitioning business function to the business unit via a user interface of the application. An example of such a user interface 400 is depicted in
For example, if the US001 NE Operations business unit is configured to perform procurement tasks in the operational structure of an enterprise, procurement business function 420 may be selected and assigned to US001 NE Operations. Alternatively, if US001 NE Operations is configured to generate procurement requisitions in the operational structure of the enterprise, requisitioning business function 440 may be selected and assigned to US001 NE Operations. In cases where US001 NE Operations is configured to act as both a procurement and a requisitioning business unit (e.g., hybrid business unit 110 of
Returning to
In one set of embodiments, the associations created at step 206 may comprise many-to-many mappings between procurement clients and procurement service providers. For example table 300 includes associations mapping requisitioning business unit 102 (procurement client) to procurement business units 106, 108 and hybrid business unit 110 (procurement service providers). Similarly, table 300 includes associations mapping procurement business unit 106 (procurement service provider) to requisitioning/hybrid business units 102, 104 and hybrid business unit 110 (procurement clients). Accordingly, embodiments of the present invention are capable of modeling operational structures in which one-to-many, many-to-one, or many-to-many outsourcing relationships exist between clients and service providers. This scenario is common in the shared procurement services context, since one procurement client may rely on a number of different specialized procurement service providers (e.g., service provider for office supplies, service provider for raw materials, etc.) to satisfy its procurement needs.
Once associations have been created and stored per step 206 of
To enable the authoring of procurement-related content by a procurement service provider per step 208, one or more user interfaces may be generated and presented to end-users in the procurement service provider. For example,
As shown, user interface 600 includes a table 620 referred to as “Business Unit Access.” Table 620 identifies which procurement clients associated with the current procurement service provider (per the associations created at step 206) will be able to access the purchase agreement being defined (e.g., purchase agreement “8560”). Thus, by adding or removing rows from table 620, the procurement service provider may control how purchase agreement 8560 is shared with its associated client base. In the example of
Although not shown in
To enable the viewing of procurement-related content by a procurement client per step 210 of
As another example,
Returning to
In a further set of embodiments, this determination may also be based on a set of business rules that take into consideration the procurement specializations of various procurement service providers. For example, in enterprise 100 of
It should be appreciated that the specific steps illustrated in
At step 902, procurement requisitions generated by procurement clients in an enterprise are stored in a common pool. In various embodiments, the procurement clients are business units in the enterprise that have been associated with procurement service providers per step 206 of
At step 904, an iterative process is initiated to determine, for each procurement service provider in the enterprise, whether the common pool includes any procurement requisitions that should be processed by that service provider. For example, at step 906, the common pool is analyzed to identify a first subset of requisitions in the pool that originate from (e.g., were generated by) procurement clients associated with a current procurement service provider. If such a first subset is found, the first subset is then analyzed to identify a second subset of requisitions (in the first subset) that match a procurement specialization of the current service provider (step 908).
In one set of embodiments, the processing of step 908 is based on a set of business rules that is defined for each procurement service provider and that matches keywords or key values relevant to the service provider's procurement specialization to attributes in a procurement requisition. For example, if a procurement service provider is specialized to procure office supplies, the set of business rules defined for that service provider might include a rule that looks for the term “office supplies” in a “requisition type” attribute of a procurement requisition. As another example, if a procurement service provider is specialized to procure items in the United States, the set of business rules defined for that service provider might include a rule that looks for a U.S. zip code in a “ship-to location” or “ship-from location” attribute of a procurement requisition. If a match is found, the requisition is selected for processing by the procurement service provider at step 910. In this manner, procurement requisitions can be automatically routed to the most appropriate procurement service providers based on their respective specializations.
In one set of embodiments, the business rules for a procurement service provider may be defined declaratively (rather than programmatically) and stored as metadata. Thus, the business rules may be created and modified by business analysts in the enterprise that may not have programming expertise.
Once procurement requisitions have been selected for processing by a current procurement service provider at step 910, the selected requisitions may be removed from the common pool (step 912). The iterative process then restarts at step 904 for additional procurement service providers in the enterprise. Although steps 906-910 are shown in
In some situations, one or more procurement requisitions in the common pool may not be selected by any procurement service provider per steps 906-910. In these cases, the unselected requisitions may be assigned to a default service provider for processing. In one set of embodiments, a default service provider may be identified for each requisitioning business unit, where the default service provider is selected from the group of service providers associated with that requisitioning business unit. In other embodiments, a single default service provider may be identified that applies to all requisitioning business units.
It should be appreciated that the specific steps illustrated in
Client computing devices 1002, 1004, 1006, 1008 may be general purpose personal computers (including, e.g., personal computers and/or laptop computers running various versions of Microsoft Windows and/or Apple Macintosh operating systems), cell phones or PDAs (running software such as Microsoft Windows Mobile and being Internet, e-mail, SMS, Blackberry, or other communication protocol enabled), 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). Alternatively, client computing devices 1002, 1004, 1006, 1008 may be any other electronic device capable of communicating over a network (e.g., network 1010 described below). Although system environment 1000 is shown with four client computing devices, any number of client computing devices may be supported.
In most embodiments, system environment 1000 includes a network 1010. Network 1010 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example, network 1010 can be a local area network (LAN), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (VPN); the Internet; an intranet; an extranet; a public switched telephone network (PSTN); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks.
System environment 1000 also includes one or more server computers 1012 which may be general purpose computers, specialized server computers (including, merely by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. In various embodiments, server 1002 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, in one embodiment, server 1012 may act as an enterprise application server configured to execute an enterprise application or one or more other software applications performing the steps of
Server 1012 may run an operating system including any of those discussed above, as well as any commercially available server operating system. Server 1012 may also run any of a variety of additional server applications and/or mid-tier applications, including web servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include without limitation those commercially available from Oracle, Microsoft, Sybase, IBM and the like.
System environment 1000 may also include one or more databases 1014. Databases 1014 may be configured to store setup data such as business function assignments, service provider-client associations, and procurement-related content, transactional data such as procurement requisitions, and any other type of data described in this disclosure. Databases 1014 may reside in a variety of locations. By way of example, one or more of databases 1014 may reside on a storage medium local to (and/or resident in) one or more of the computers 1002, 1004, 1006, 1008, 1012. Alternatively, databases 1014 may be remote from any or all of the computers 1002, 1004, 1006, 1008, 1012, and/or in communication (e.g., via network 1110) with one or more of these. In one set of embodiments, databases 1014 may 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 computers 1002, 1004, 1006, 1008, 1012 may be stored locally on the respective computer and/or remotely, as appropriate. In one set of embodiments, databases 1014 may include relational databases, such as Oracle 10g, that are adapted to store, update, and retrieve data in response to SQL-formatted commands.
Computer system 1100 may additionally include a computer-readable storage media reader 1112, a communications subsystem 1114 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory 1118, which may include RAM and ROM devices as described above. In some embodiments, computer system 1100 may also include a processing acceleration unit 1116, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.
Computer-readable storage media reader 1112 can further be connected to a computer-readable storage medium 1110, together (and, optionally, in combination with storage device(s) 1108) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. Communications system 1114 may permit data to be exchanged with network 1010 and/or any other computer described above with respect to system environment 1000.
Computer system 1100 may also comprise software elements, shown as being currently located within working memory 1118, including an operating system 1120 and/or other code 1122, such as an application program (which may be a client application, Web browser, mid-tier application, RDBMS, etc.). It should be appreciated that alternative embodiments of computer system 1100 may 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.
Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium which can be used to store or transmit the desired information and which can be accessed by a computer.
Although specific embodiments of the present invention have been described, various modifications, alterations, alternative constructions, and equivalents are within the scope of the invention. For example, embodiments of the present invention are not restricted to operation within certain specific data processing environments, but are free to operate within a plurality of data processing environments. Additionally, although embodiments of the present invention have been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present invention is not limited to the described series of transactions and steps.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
The present application is related to commonly-owned U.S. patent application Ser. No. ______ (Attorney Docket No. 021756-060000US), filed concurrently with the present application and entitled “FRAMEWORK FOR SHARED PROCUREMENT SERVICES,” the entire contents of which are incorporated herein by reference for all purposes.