U.S. patent application number 10/279180 was filed with the patent office on 2003-07-10 for system and method for managing spending.
Invention is credited to Kruk, Jeffrey M., McLemore, Sandy A., Quigney, Peter P., Richards, Paul J., Shaver, Joseph M., Tehrani, Saeid.
Application Number | 20030130878 10/279180 |
Document ID | / |
Family ID | 23350552 |
Filed Date | 2003-07-10 |
United States Patent
Application |
20030130878 |
Kind Code |
A1 |
Kruk, Jeffrey M. ; et
al. |
July 10, 2003 |
System and method for managing spending
Abstract
A method of managing spending is provided. The method includes
collecting procurement data from a plurality of data sources which
may have associated source-specific product catalogs. The method
further includes storing a global catalog specifying mapping
relationships between source-specific product attributes specified
by the source-specific product catalogs and generic attributes
specified by the global catalog. The method further includes
mapping the source-specific attributes associated with particular
products to corresponding generic attributes based on the mapping
relationships. The method further includes analyzing a portion of
the collected procurement data, including identifying information
regarding products associated with the particular procurement
events based on the generic attributes associated with the
products. The method further includes automatically generating a
visual output based on the analysis of the collected procurement
data.
Inventors: |
Kruk, Jeffrey M.; (Macomb,
MI) ; Quigney, Peter P.; (Plano, TX) ;
Tehrani, Saeid; (Farmington, MI) ; Shaver, Joseph
M.; (Ypsilanti, MI) ; McLemore, Sandy A.;
(Frisco, TX) ; Richards, Paul J.; (Clarkston,
MI) |
Correspondence
Address: |
BAKER BOTTS L.L.P.
2001 ROSS AVENUE
SUITE 600
DALLAS
TX
75201-2980
US
|
Family ID: |
23350552 |
Appl. No.: |
10/279180 |
Filed: |
October 23, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60344440 |
Oct 23, 2001 |
|
|
|
Current U.S.
Class: |
705/7.22 ;
707/E17.008 |
Current CPC
Class: |
G06Q 10/10 20130101;
G06Q 10/087 20130101; G06F 40/247 20200101; G06Q 10/06375 20130101;
G06F 16/34 20190101; G06F 40/237 20200101; G06F 16/93 20190101;
G06Q 10/0637 20130101; G06F 40/30 20200101; G06Q 30/06 20130101;
G06Q 10/063 20130101; G06Q 10/06395 20130101; G06Q 10/06 20130101;
G06Q 30/0605 20130101; G06Q 10/06312 20130101; G06Q 10/06313
20130101; G06Q 10/06315 20130101; G06F 2216/03 20130101 |
Class at
Publication: |
705/7 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
1. A method of managing spending, comprising: collecting
procurement data from a plurality of data sources, the procurement
data including information regarding a plurality of procurement
events, one or more of the data sources having an associated
source-specific product catalog; storing a global catalog
specifying, for each of a plurality of products, mapping
relationships between source-specific product attributes specified
by the one or more source-specific product catalogs and one or more
generic attributes specified by the global catalog; mapping the
source-specific attributes associated with products identified by
the collected procurement data to the corresponding generic
attributes based on the mapping relationships; analyzing a portion
of the collected procurement data, including identifying
information regarding particular products based on the generic
attributes associated with the one or more products; and
automatically generating a visual output based on the analysis of
the collected procurement data.
2. The method of claim 1, wherein collecting procurement data from
a plurality of data sources includes collecting information
automatically extracted from a plurality of electronic contracts
based on a set of linguistic rules.
3. The method of claim 1, wherein collecting procurement data from
a plurality of data sources comprises: storing a plurality of
electronic contracts including unstructured textual data;
determining one or more linguistic patterns associated with a
business parameter; generating linguistic rules based on the one or
more linguistic patterns; and using text mining tools to
automatically extract information regarding the business parameter
from the unstructured textual data using one or more of the
linguistic rules; and collecting at least a portion of the
automatically extracted information.
4. The method of claim 1, wherein: the procurement issue concerns
the procurement of a particular product; and the visual output
illustrates one or more details of the procurement of the
particular product.
5. The method of claim 1, wherein: the procurement issue concerns
two or more procurement parameters; and the visual output
illustrates a relationship between at least two of the two or more
procurement parameters.
6. The method of claim 5, wherein the visual output comprises a
three-dimensional visualization illustrating the relationship
between the at least two types of procurement parameters.
7. The method of claim 5, wherein: the procurement issue concerns
the procurement of two or more particular products; and the visual
output illustrates a relationship between the procurement of one of
the particular products and the procurement of another of the
particular products.
8. The method of claim 1, further comprising automatically
identifying one or more business entities associated with each of
the plurality of procurement events; and wherein: the visual output
illustrates one or more details regarding procurement events
associated with at least one of the one or more business
entities.
9. The method of claim 1, further comprising: storing one or more
business relationships among a set of two or more related business
entities; and automatically identifying, for a particular
procurement event associated with a particular business entity of
the set of related business entities, one or more related business
entities based on the stored business relationships; and wherein
the visual output illustrates procurement information regarding at
least two of the set of related business entities.
10. The method of claim 9, wherein: the set of two or more related
business entities comprises two or more business entities having
made procurement purchases; and the visual output illustrates
information regarding procurements made by at least two of the set
of related business entities.
11. The method of claim 9, further comprising automatically
receiving the one or more business relationships from a business
information provider.
12. The method of claim 1, further comprising automatically
determining the one or more procurement events associated with the
particular procurement issue.
13. The method of claim 1, further comprising automatically
classifying each of the plurality of procurement events based on
one or more classification rules;
14. The method of claim 1, wherein the automatically generated
visual output comprises a plurality of visualizations which may be
navigated through using automated navigation tools.
15. The method of claim 1, further comprising: receiving a request
for a business intelligence report, the request being initiated
based on an analysis of the visual output; analyzing at least a
portion of the collected procurement data; and automatically
generating the business intelligence report in response to the
request based on the analysis of the collected procurement
data.
16. The method of claim 1, wherein collecting procurement data from
a plurality of data sources comprises: collecting procurement data
from a plurality of data sources; periodically receiving additional
procurement data from one or more of the plurality of data sources;
and updating the procurement data based on the additional
procurement data.
17. Software for managing spending, the software being embodied in
computer-readable media and when executed operable to: collect
procurement data from a plurality of data sources, the procurement
data including information regarding a plurality of procurement
events, one or more of the data sources having an associated
source-specific product catalog; store a global catalog specifying,
for each of a plurality of products, mapping relationships between
source-specific product attributes specified by the one or more
source-specific product catalogs and one or more generic attributes
specified by the global catalog; map the source-specific attributes
associated with products identified by the collected procurement
data to the corresponding generic attributes based on the mapping
relationships; analyze a portion of the collected procurement data,
including identifying information regarding particular products
based on the generic attributes associated with the one or more
particular products; and generate a visual output based on the
analysis of the collected procurement data.
18. The software of claim 17, wherein collecting procurement data
from a plurality of data sources includes collecting information
automatically extracted from a plurality of electronic contracts
based on a set of linguistic rules.
19. The software of claim 17, wherein collecting procurement data
from a plurality of data sources comprises: storing a plurality of
electronic contracts including unstructured textual data;
determining one or more linguistic patterns associated with a
business parameter; generating linguistic rules based on the one or
more linguistic patterns; and using text mining tools to
automatically extract information regarding the business parameter
from the unstructured textual data using one or more of the
linguistic rules; and collecting at least a portion of the
automatically extracted information.
20. The software of claim 17, wherein: the procurement issue
concerns the procurement of a particular product; and the visual
output illustrates one or more details of the procurement of the
particular product.
21. The software of claim 17, wherein: the procurement issue
concerns two or more procurement parameters; and the visual output
illustrates a relationship between at least two of the two or more
procurement parameters.
22. The software of claim 21, wherein the visual output comprises a
three-dimensional visualization illustrating the relationship
between the at least two procurement parameters.
23. The software of claim 21, wherein: the procurement issue
concerns the procurement of two or more particular products; and
the visual output illustrates a relationship between the
procurement of one of the particular products and the procurement
of another one of the particular products.
24. The software of claim 17, further operable to identify one or
more business entities associated with each of the plurality of
procurement events; and wherein the visual output illustrates one
or more details regarding procurement events associated with at
least one of the one or more business entities.
25. The software of claim 17, further operable to: store one or
more business relationships among a set of two or more related
business entities; and identify, for a particular procurement event
associated with a particular business entity of the set of related
business entities, one or more related business entities based on
the stored business relationships; and wherein the visual output
illustrates procurement information regarding at least two of the
set of related business entities.
26. The software of claim 25, wherein: the set of two or more
related business entities comprises two or more business entities
having made procurement purchases; and the visual output
illustrates information regarding procurements made by at least two
of the set of related business entities.
27. The software of claim 25, further operable to receive the one
or more business relationships from a business information
provider.
28. The software of claim 17, wherein: the visual output comprises
a plurality of visualizations; and the software is further operable
to provide navigation tools for navigating through the plurality of
visualizations.
29. The software of claim 17, further operable to: receive a
request for a business intelligence report, the request being
initiated based on an analysis of the visual output; analyze at
least a portion of the collected procurement data; and generate a
business intelligence report in response to the request based on
the analysis of the collected procurement data.
30. The software of claim 17, wherein collecting procurement data
from a plurality of data sources comprises: collecting procurement
data from a plurality of data sources; periodically receiving
additional procurement data from one or more of the plurality of
data sources; and updating the procurement data based on the
additional procurement data.
31. A system for managing spending, comprising: a data warehouse
operable to collect procurement data from a plurality of data
sources, the procurement data including information regarding a
plurality of procurement events, one or more of the data sources
having an associated source-specific product catalog; a global
catalog module operable to: store a global catalog specifying, for
each of a plurality of products, mapping relationships between
source-specific product attributes specified by the one or more
source-specific product catalogs and one or more generic attributes
specified by the global catalog; and map the source-specific
attributes associated with one or more products identified by the
collected procurement data to the corresponding generic attributes
based on the mapping relationships; a data analysis module operable
to analyze a portion of the collected procurement data, including
identifying information regarding particular products based on the
generic attributes associated with the one or more particular
products; and a data visualization module operable to generate a
visual output based on the analysis of the collected procurement
data.
32. The system of claim 31, wherein collecting procurement data
from a plurality of data sources includes collecting information
automatically extracted from a plurality of electronic contracts
based on a set of linguistic rules.
33. The system of claim 31, further comprising: a contracts
database operable to store a plurality of electronic contracts
including unstructured textual data; a linguistic rule database
operable to store linguistic rules generated based on one or more
linguistic patterns associated with a business parameter; a text
mining module comprising text mining tools operable to
automatically extract particular information regarding the business
parameter from the unstructured textual data using one or more of
the linguistic rules; and wherein collecting procurement data from
a plurality of data sources includes collecting at least a portion
of the extracted information.
34. The system of claim 31, wherein: the procurement issue concerns
the procurement of a particular product; and the visual output
illustrates one or more details of the procurement of the
particular product.
35. The system of claim 31, wherein: the procurement issue concerns
two or more procurement parameters; and the visual output
illustrates a relationship between at least two of the two or more
procurement parameters.
36. The system of claim 35, wherein the visual output comprises a
three-dimensional visualization illustrating the relationship
between the at least two procurement parameters.
37. The system of claim 35, wherein: the procurement issue concerns
the procurement of two or more particular products; and the visual
output illustrates a relationship between the procurement of one of
the particular products and the procurement of another one of the
particular products.
38. The system of claim 31, further comprising: a business entity
identification module operable to identify one or more business
entities associated with each of the plurality of procurement
events; and wherein the visual output illustrates one or more
details regarding procurement events associated with the particular
business entity.
39. The system of claim 31, further comprising: a business entity
relationships database operable to store one or more business
relationships among a set of two or more related business entities;
and a business entity identification module operable to identify,
for a particular procurement event associated with a particular
business entity of the set of related business entities, one or
more related business entities based on the stored business
relationships; and wherein the request concerns procurement events
associated with at least one business entity of the set of related
business entities; and wherein the visual output illustrates
procurement information regarding at least two of the set of
related business entities.
40. The system of claim 39, wherein: the set of two or more related
business entities comprises two or more business entities having
made procurement purchases; and the visual output illustrates
information regarding procurements made by at least two of the set
of related business entities.
41. The system of claim 39, wherein the business entity
identification module is operable to receive the one or more
business relationships from a business information provider.
42. The system of claim 31, wherein: the visual output comprises a
plurality of visualizations; and the data visualization module is
further operable to provide navigation tools for navigating through
the plurality of visualizations.
43. The system of claim 31, further comprising a business
intelligence reporting module operable to: receive a request for a
business intelligence report, the request being initiated based on
an analysis of the visual output; analyze at least a portion of the
collected procurement data; and generate a business intelligence
report in response to the request based on the analysis of the
collected procurement data.
44. The system of claim 31, wherein the data warehouse is operable
to collect procurement data from a plurality of data sources by:
collecting procurement data from a plurality of data sources;
periodically receiving additional procurement data from one or more
of the plurality of data sources; and updating the collected
procurement data based on the additional procurement data.
Description
RELATED APPLICATION
[0001] This application claims the benefit of U.S. Provisional
Patent Application Serial No. 60/344,440, entitled "BANK OF
KNOWLEDGE," filed Oct. 23, 2001, which is hereby incorporated by
reference.
TECHNICAL FIELD OF THE INVENTION
[0002] This invention relates in general to supply chain management
and, more particularly, to a system and method for managing
spending associated with a procurement process.
BACKGROUND OF THE INVENTION
[0003] Financial pressures continue to provide business executives
with opportunities to reduce expenses while generating revenue
growth. Procurement decisions, such as purchasing decisions
regarding particular products, suppliers, and shipping of purchased
products, often have a substantial impact on a business
organization's financial bottom line, providing opportunities for
reducing expenses as well as increasing revenue. In addition, such
procurement decisions often influence the organization's general
operation and the quality of goods or services procured by the
organization.
[0004] Procurement decisions are often complex and involve the
analysis of heterogeneous information, which may be constantly
evolving, over a period of time. For example, such information may
include large volumes of product data, purchaser (or client)
requirements, supplier constraints, legal regulations and
contractual terms and obligations. Contractual terms and
obligations may originate from contracts between the business
organization and its various suppliers. Some business organizations
may deal with hundreds or even thousands of suppliers, and may
therefore have hundreds or thousands of supplier contracts active
at any particular time. These supplier contracts define the
business terms and conditions between the business organization and
the many suppliers.
SUMMARY OF THE INVENTION
[0005] In accordance with the present invention, systems and
methods for managing spending associated with a procurement process
are provided.
[0006] According to one embodiment, a method of managing spending
is provided. The method includes collecting procurement data from a
plurality of data sources. The procurement data includes
information regarding a plurality of procurement events. One or
more of the data sources having an associated source-specific
product catalog. The method further includes storing a global
catalog specifying, for each of a plurality of products, mapping
relationships between source-specific product attributes specified
by the one or more source-specific product catalogs and one or more
generic attributes specified by the global catalog. The method
further includes mapping the source-specific attributes associated
with products identified by the collected procurement data to the
corresponding generic attributes based on the mapping
relationships. The method further includes analyzing a portion of
the collected procurement data, including identifying information
regarding particular products based on the generic attributes
associated with the one or more products. The method further
includes automatically generating a visual output based on the
analysis of the collected procurement data.
[0007] According to another embodiment, a system for managing
spending is provided. The system includes a data warehouse, a
global catalog module, a data analysis module, a data visualization
module. The data warehouse is operable to collect procurement data
from a plurality of data sources. The procurement data includes
information regarding a plurality of procurement events. One or
more of the data sources has an associated source-specific product
catalog. The global catalog module is operable to store a global
catalog specifying, for each of a plurality of products, mapping
relationships between source-specific product attributes specified
by the one or more source-specific product catalogs and one or more
generic attributes specified by the global catalog. The global
catalog module is further operable to map the source-specific
attributes associated with one or more products identified by the
collected procurement data to the corresponding generic attributes
based on the mapping relationships specified by the global catalog.
The data analysis module is operable to analyze a portion of the
collected procurement data regarding one or more procurement events
associated with a procurement issue. The analysis includes
identifying information regarding particular products based on the
generic attributes associated with the one or more particular
products. The data visualization module is operable to generate a
visual output regarding the particular procurement issue based on
the analysis of the collected procurement data regarding the one or
more procurement events.
[0008] Various embodiments of the present invention may benefit
from numerous advantages. It should be noted that one or more
embodiments may benefit from some, none, or all of the advantages
discussed below.
[0009] One advantage is that procurement information may be
automatically collected from a variety of heterogeneous data
sources, such as operational systems and manual data sources (such
as spreadsheet files), for example, into a common procurement data
warehouse. The collected procurement data may then be analyzed to
generate a variety of outputs indicating various details of
particular procurement events or groups of procurement events. In
particular embodiments, various analyses may be performed to
identify, or to allow users to identify (from interpreting output
generated based on such analyses), the effects of particular
procurement events or decisions on other procurement activities or
decisions, or on the total cost of a procurement process or supply
chain. Such analyses may be more effective, accurate, faster and/or
less expensive than traditional methods used to attempt such
complex analyses.
[0010] Another advantage is that a number of source-specific
product catalogs associated with various data sources of the
procurement data may be merged into a common, global product
catalog in order to provide consistent identification of products
and services. Such consistent identification of products and
services may be important for effectively analyzing a set of
procurement data including data received from various different
data sources.
[0011] Yet another advantage is that various business opportunities
may be automatically identified based on the analyses of the
collected procurement data and/or information automatically
extracted from a set of supplier contracts using text mining
techniques. In many cases, such business opportunities would be
extremely difficult to identify by human management of the
procurement data and supplier contracts. Such business
opportunities may include opportunities to reduce costs (such as by
obtaining or enforcing discounts, for example), increase revenue
generation (such as by obtaining or enforcing refunds, rebates or
margins, for example) and reduce legal exposure due to
non-compliance with contractual terms, for example.
[0012] Still another advantage is that individual and corporate
business entities directly associated with various procurement
events may be tracked in the procurement data warehouse. In
addition, related business entities may be identified and
associated with each relevant procurement event. Thus, for example,
purchasing activity regarding a particular supplier or procurement
process may be reported and analyzed at both the parent and
subsidiary level. Such business relationships may be automatically
identified, tracked and updated based on business relationship
information received periodically from a business information
provider, such as DUN & BRADSTREET, for example.
[0013] Other advantages will be readily apparent to one having
ordinary skill in the art from the following figures, descriptions,
and claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] For a more complete understanding of the present invention
and for further features and advantages, reference is now made to
the following description, taken in conjunction with the
accompanying drawings, in which:
[0015] FIG. 1 illustrates an example procurement data management
system in accordance with an embodiment of the present
invention;
[0016] FIG. 2 illustrates an example architecture and operation of
a contracts management component of the procurement data management
system of FIG. 1;
[0017] FIGS. 3A-3B illustrate a display of an example output
generated by the contracts management component of FIG. 2;
[0018] FIG. 4 illustrates an example method of managing contracts
in accordance with an embodiment of the present invention;
[0019] FIG. 5 illustrates an example method of developing, testing
and modifying linguistic rules used to extract information from
electronic contracts in accordance with an embodiment of the
present invention;
[0020] FIG. 6 illustrates an example architecture and operation of
a spend management component of the procurement data management
system of FIG. 1;
[0021] FIG. 7 illustrates an example data analysis module for use
in the spend management component of FIG. 6;
[0022] FIG. 8 illustrates an example method of managing procurement
spending in accordance with an embodiment of the present of the
invention;
[0023] FIG. 9A illustrates a display of an example output generated
by the spend management component of FIG. 6;
[0024] FIG. 9B illustrates an example data visualization generated
by the spend management component of FIG. 6;
[0025] FIG. 10 illustrates an example architecture and operation of
a compliance management component of the procurement data
management system of FIG. 1;
[0026] FIG. 11 illustrates a display of an example output generated
by the compliance management component of FIG. 10;
[0027] FIG. 12 illustrates an example method of managing compliance
with business compliance rules in accordance with an embodiment of
the present invention;
[0028] FIG. 13 illustrates an example architecture and operation of
a supplier intelligence component of the procurement data
management system of FIG. 1;
[0029] FIG. 14 illustrates an example method of managing supplier
intelligence in accordance with an embodiment of the present
invention; and
[0030] FIG. 15 illustrates a display of an example output generated
by the supplier intelligence component of FIG. 13.
DETAILED DESCRIPTION OF THE DRAWINGS
[0031] Example embodiments of the present invention and their
advantages are best understood by referring now to FIGS. 1 through
15 of the drawings, in which like numerals refer to like parts.
[0032] FIG. 1 illustrates an example procurement data management
system 10 in accordance with an embodiment of the present
invention. In general, system 10 is operable to facilitate
procurement decisions by extracting, integrating, analyzing, and
disseminating business-critical information from a variety of
heterogeneous information sources. In particular embodiments,
system 10 is operable to extract procurement information from
multiple sources, collect the data into a common data warehouse,
compare current business events (such as purchases, for example)
with information in the common data warehouse in order to generate
business recommendations or discover business opportunities. In a
particular embodiment, system 10 is operable to extract otherwise
hidden value from both existing, as well as new, businesses. For
example, system 10 may be operable to supply decision-makers with
inferences and information that is otherwise hidden, enabling such
decision-makers to make better procurement decisions based on a
large collection of information.
[0033] As shown in FIG. 1, procurement data management system 10
may include one or more purchasing data sources 12, a procurement
data warehouse 14, an information management system 16, and a
knowledge integration interface 18. Information management system
16 comprises various components, including a contracts management
component 30, a spend management component 32, a compliance
management component 34, and a supplier intelligence component
36.
[0034] Purchasing data sources 12 may be operable to store, or
otherwise have access to, various source data 20 regarding any
number of historical procurement events and/or business entities.
The terms "business entity" and "business organization" as used
throughout this document includes any individual or group of
individuals associated with any type of for-profit or non-profit
business enterprise.
[0035] Purchasing data sources 12 may include operational
applications, manual source data applications (such as spreadsheet
files, for example) and/or various other data sources suitable to
store or have access to information regarding procurement events.
In some embodiments, purchasing data sources 12 may include one or
more databases or applications operable to support operational
systems. For example, a particular purchasing data source 12 may
include an on-line transaction processing (OLTP) system, a
teleprocessing monitor, a data management system (such as a DB2,
ORACLE, or SYBASE system, for example) and may have capabilities
for on-line data entry and batch processing. In particular
embodiments, source data 20 associated with purchasing data sources
12 generally includes structured, as opposed to unstructured, data.
It should be understood that various purchasing data sources 12 may
be physically and geographically distributed.
[0036] Source data 20 may include information from purchase orders
(such as information regarding suppliers, products, prices,
refunds, rebates, margins, and dates, for example), invoices,
general ledger account information (such as general ledger account
codes, for example), a listing of procured products and services,
where such procurements are made, who is responsible for making
such procurements, payment information, and any other type of
information regarding historical procurement events. It should be
understood that the term "products" as used throughout this
document includes both goods and services, whether or not
accompanied by the term "services."
[0037] Procurement data warehouse 14 may include a collection of
procurement data 22, which may include source data 20 received from
one or more purchasing data sources 12. As shown in FIG. 1, one or
more processing tools 24 may be used to facilitate the
transportation of such source data 20 from purchasing data sources
12 to procurement data warehouse 14. Processing tools 24 may
include data extraction, transformation, and loading (ETL) tools
operable to extract source data 20 from purchasing data sources 12,
transform or otherwise process such source data 20, and load such
source data 20 into procurement data warehouse 14. Such ETL tools
are described in greater detail below with reference to ETL tools
220 of FIG. 6. Processing tools 24 may also include one or more
additional tools operable to process source data 20, such as
various data mapping and classification tools, as described in
greater detail below with reference to data processing sub-system
202 of FIG. 6.
[0038] Procurement data 22 may also include data received from
information management system 16. For example, procurement data 22
may include data extracted from electronic procurement contracts by
contracts management component 30 of information management system
16, as discussed below in greater detail. It should be understood
that procurement data warehouse 14 may be operable to exchange
various information with information management system 16 in order
to generate outputs 38 enabling users (such as procurement
decision-makers, for example) to make better purchasing decisions,
indicated by reference numeral 40. It should be understood that the
term "user" as used throughout this document refers to any person
or group of people associated with a procurement process or
business entity, such as business rule experts, subject matter
experts, business analysts, data analysts, managers, system
administrators, purchasing or spending decision-makers, or business
consultants, for example.
[0039] Knowledge integration interface 18 may be operable to bring
together supplier information 26, purchaser information 28, and the
various components of information management system 16 in order for
such information to be processed to generate various outputs 38. In
particular embodiments, knowledge integration interface 18 includes
an interface and a set of utilities and routines that bring
together supplier information 26, purchaser information 28 and the
components of information management system 16. For example,
knowledge integration interface 18 may be operable to receive or
extract particular supplier information 26 and determine where to
route the particular supplier information 26 such that the supplier
information 26 may be presented to a user in a format such that the
user may discover hidden value or particular business
opportunities.
[0040] Supplier information may include various information
regarding any number of suppliers, such as spending patterns with
particular suppliers, information regarding supplier alignment, and
information regarding compliance and/or non-compliance with
agreements made between particular suppliers and the purchasing
organization, for example.
[0041] Purchaser information may include various information
regarding the purchasing business organization, such as information
regarding particular business opportunities, such as information
regarding opportunities for reducing expenses and/or generating
revenue.
[0042] FIG. 2 illustrates an example architecture and operation of
contracts management component 30 of system 10 in accordance with
an embodiment of the present invention. Contracts management
component 30 may include one or more various sub-components. For
example, in the embodiment shown in FIG. 2, contracts management
component 30 includes a document processing sub-component 40, a
data extraction sub-component 42, a linguistic rules development
sub-component 44, and a data processing sub-component 46. Document
processing sub-component 40 may be generally operable to convert
(by digitizing) paper contracts into electronic contracts. Data
extraction sub-component 42 may be generally operable to extract
relevant information from the digitized electronic contracts based
on a set of linguistic rules. Linguistic rules development
sub-component 44 may be generally operable to analyze business
issues to determine such linguistic rules. Data processing
sub-component 46 may be generally operable to analyze information
extracted by data extraction sub-component 42 to generate various
types of output, indicated generally by reference numeral 48.
[0043] Document processing sub-component 40 may include a scanning
module 50, a digital images database 52, and an optical character
recognition module 54. Scanning module 50 may be operable to scan
or otherwise process one or more paper contracts 56 to generate
digital images 58 of the one or more paper contracts 56. Digital
images 58 may be stored in digital images database 52. Paper
contracts 56 may include contracts stored on paper, microfiche,
microfilm, aperture card, or any other format in which the text of
the contracts is not computer-editable. Optical character
recognition module 54 is operable to convert the digital images 58
associated with each paper contract 56 into an electronic contract
58, such that the text of the electronic contract 60 is
computer-editable. For example, optical character recognition
module 54 may convert digital images 58 into electronic contracts
60 based on patterns of pixels in digital images 58. Each
electronic contract 60 may be stored in an electronic contracts
database 62 of data extraction sub-component 42. It should be
understood that electronic contracts 60 comprise computer-editable,
but unstructured, text.
[0044] Data extraction sub-component 42 may include electronic
contracts database 62, a text mining module 64, an extracted
information database 66, a data organization database 68, and a
linguistic rules database 70. As discussed above, electronic
contracts database 62 is operable to store electronic contracts 60
received from document processing sub-component 40. Text mining
module 64 may include text mining tools, or software, 72 and may be
operable to analyze electronic contracts 60 to extract relevant
information 74 based on a set of linguistic rules 76 stored in
linguistic rules database 70. Text mining tools 72 may be operable
to automatically identify, group, and map key concepts within a
large volume of unstructured textual data. Text mining tools 72 may
include lexical processing and information clustering operable to
extract key phrases and identify relevant relationships within
electronic contracts 60.
[0045] In particular embodiments, text mining tools 72 may include
Natural Language Processing (NLP) technologies to extract relevant
information 74. Using NLP technologies, documents may be
transformed into a collection of concepts, described using terms
discovered in the text. Thus, text mining tools 72 may be operable
to extract more information than just picking up keywords from
textual data. For example, text mining tools 72 may be operable to
extract facts, determine their meaning, resolve ambiguities, and
determine an author's intent and expectations.
[0046] In particular embodiments, text mining tools 72 may include
software developed for use in contracts management component 30
and/or may include one or more commercially available software
products, such as text mining software available from CLEARFOREST
CORP. It should be understood that the term "text mining" as used
throughout this document includes both data mining and text mining.
In other words, "text mining" is intended to refer to the
extraction of particular information from both data and
unstructured text (or "free text"). Thus, for example, text mining
module 64 may be operable to extract relevant information 74 from
both data and text.
[0047] Data organization module 68 may be operable to organize
and/or otherwise process extracted information 74 stored in
extracted information database 66. Such organization and/or other
processing may include sorting, categorizing, filtering, cleansing,
merging, or deleting information, for example.
[0048] Extracted information database 66 may also include one or
more contract pointers 76. Each contract pointer 76 may be linked
to one or more particular portions or items of extracted
information 74 and may point to one or more corresponding
electronic contracts 60, or portions of one or more electronic
contracts 60, stored in electronics contracts database 62. For
example, a particular contract pointer 76 may be linked to a
particular contract term included within extracted information 74
and may point to the specific clause in a particular electronic
contract 60 from which the particular contract term was extracted.
In particular embodiments, contract pointers 76 may be generated by
text mining module 64 or data organization module 68.
[0049] Linguistic rules 76 include logical constructs, or
statements, that may be used to analyze textual information, or
data, in natural language format, such as text in English, French
or Japanese, for example. The extraction of relevant information 74
from electronic contracts database 62 using text mining tools 72
may include both syntactic analysis as well as semantic analysis.
Thus, linguistic rules 76 may be provided for performing both
syntactic analysis and semantic analysis.
[0050] Syntactic analysis includes identifying or understanding the
location of particular pieces of information, such as characters or
words, for example. Thus, an example linguistic rule at the
syntactic level may search for blank spaces between characters in
order to locate each word in a group of words. As another example,
syntactic linguistic rules may be used to locate particular parts
of speech, such as verbs, nouns and adjectives, within a group of
words. As yet another example, linguistic rules concerning
syntactic analysis may utilize a dictionary to check and/or correct
spellings of particular words.
[0051] Semantic analysis involves trying to understand the meaning
of a word or group of words, such as a phrase, sentence or
paragraph, for example. Example linguistic rules 76 at the semantic
level may utilize a dictionary to understand the meaning of
particular words. Semantic linguistic rules 76 may also utilize a
thesaurus to look up synonyms to extend the semantic analysis.
[0052] Each linguistic rule 76, including both syntactic and
semantic rules, may perform either shallow parsing or deep parsing.
Shallow parsing involves analysis limited to a single sentence,
while deep parsing involves analysis extending across more than one
sentence or paragraph. Deep parsing may be used to resolve
ambiguities in a particular text. For example, linguistic rules
designed for deep parsing may be able to distinguish between the
use of the word "acquisition" to refer to a business relationship
("company A is in acquisition discussions with company B") or to a
product ("company A manufactures data acquisition systems") by
analyzing one or more prior and/or subsequent statements to resolve
the ambiguity.
[0053] Linguistic rules 76 may be designed to extract one or more
pieces or items of information related to a particular business
issuer or parameter from an electronic contract 60. For example,
one or more linguistic rule 76 may be designed to extract
telephone/fax number information from an electronic contract 60,
which may include information concerning each identified
telephone/fax number, such as the number itself, whether the number
is for a home phone, office phone, cellular phone, mobile phone, or
fax machine, and the name of the person and/or company associated
with the number. First, one or more linguistic rules may be
designed to locate each telephone/fax number within the electronic
contract 60. For example, such linguistic rules 76 may look for any
three consecutive numbers followed by a dash or period and followed
by four consecutive numbers. The linguistic rules 76 may also look
at the text preceding the first three numbers to identify three
additional consecutive numbers that may be located within
parenthesis or followed by a period or hyphen. Such linguistic
rules 76 may be used to extract telephone or fax numbers from
electronic contract 60. One or more additional linguistic rules 76
may then be used to identify the type of each identified telephone
or fax number. For example, one or more linguistic rules 76 may be
designed to search the five words prior and subsequent to each
identified number for words identifying the type of each identified
number, such as "office," "home," "cell," "mobile," "pager," "fax"
or "facsimile," for example. One or more additional linguistic
rules 76 may also be used to identify a person and/or company
associated with each identified number. For example, one or more
linguistic rules 76 may be designed to search the sentence prior to
and subsequent to each identified number for any person or company
name. Thus, such linguistic rules 76 may be used to extract various
information associated with each identified telephone or fax
number. Such information may be linked and/or stored together
within extracted information database 66.
[0054] Automatically extracting relevant information 74 from
electronic contracts database 62 using text mining tools 72 based
on linguistic rules 76 allows the extraction of relevant
information from a large volume of unstructured text and/or data
sources in a relatively small period of time, and avoids the need
to manually search such information to extract the relevant
portions. For example, in particular embodiments, text mining
module 64 may be operable to extract relevant information 74 from
several thousand electronic supplier contracts 60 within a few
hours, based on various factors such as the size of the electronic
contracts 60 as well as the number and complexity of linguistic
rules 76, for example.
[0055] Linguistic rules 76 may be developed or generated by
linguistic rules development sub-component 44. One or more
knowledge acquisition sessions, indicated by reference numeral 80,
may be used to identify one or more business issues, or needs, 82.
Each knowledge acquisition session 80 may include a structured
interview designed to understand a particular business process, as
well as why the particular business process is performed in a
particular manner. For example, a particular knowledge acquisition
session 80 regarding a procurement or supply management process may
include an interview to discern the details of the process, as well
as why the process is performed in a particular manner, in order to
identify a set of relevant business issues 82.
[0056] Business issues 82 may include a variety of issues
associated with a particular business process, which may include a
variety of issues regarding contracts associated with that business
process. For example, in a situation concerning a procurement
process and procurement contracts, business issues 82 may include
issues such as financial obligations, rebate opportunities, refund
opportunities, margin opportunities, type of license (such as
software, for example), volume commitment, warranty period, term of
agreement, transfer of license terms, authorized agency terms,
maintenance notices, pricing, and contract termination
notification, for example.
[0057] One or more relevant business parameters 84 may be
identified for each business issue 82. For example, supposing
margin opportunities is identified as a business issue 82, one or
more parameters relevant to identifying and/or describing
particular margin opportunities associated with a set of contracts
may be identified as relevant parameters 84. Such relevant
parameters 84 may include the name of the supplier, the name of the
product, and the amount of the margin, for example.
[0058] One or more linguistic patterns 86 may then be identified
for each identified relevant parameter 84. For example, supposing
telephone number has been identified as a relevant parameter 84,
the associated linguistic patterns 86 may include the pattern of
three consecutive numbers followed by a hyphen or period and
further followed by four consecutive numbers, as well as the
pattern concerning the presence of particular words such as
"phone," "telephone," "fax," "facsimile," "cell," "mobile,"
"office," and "home" located within a particular number of words
before and/or after a group of consecutive numbers, for
example.
[0059] One or more linguistic rules 76 may then be generated, or
written, for each identified linguistic pattern 86 in order to
extract relevant information 74 regarding each relevant parameter
84 from electronic contracts 60 stored in electronic contracts
database 62. Linguistic rules 76 may be developed, tested, and
revised using an iterative process, such as described in greater
detail below with reference to FIG. 4.
[0060] Data processing sub-component 46 may be operable to process
and/or analyze extracted information 74 in order to generate
various types of output 48. As shown in FIG. 2, data processing
sub-component 46 may include one or more contracts applications
90.
[0061] Contracts applications 90 may be operable to receive
extracted information 74 and/or electronic contracts 62 (or
portions thereof, such as particular sentences, clauses or
paragraphs, for example) from electronic contracts database 62 and
to process such information to generate one or more various outputs
48. In particular embodiments, contracts applications 90 are
operable to generate various outputs 48 based on requests 88
received from users, such as business analysts, for example.
[0062] Contracts applications 90 may also be operable to identify
business opportunities associated with a procurement process. In
particular embodiments, contracts applications 90 may be operable
to analyze particular procurement data 22 with respect to
particular extracted information 74 to determine whether a business
opportunity is available. For example, contracts applications 90
may be operable to compare particular extracted information 74
regarding rebate opportunities from a particular supplier and
particular procurement data 22 regarding purchases made form that
supplier in order to discover potential or existing rebate
opportunities. For example, if a particular supplier, Supplier A,
contract specifies a rebate for spending $20,000 on product X,
contracts applications 90 may be operable to identify, from
analyzing procurement data 22 to determine the amount spent on
product X from Supplier A, whether the rebate opportunity is
available. In a particular embodiment, contracts application 90 may
also be operable to generating a notification if it is determined
that the business opportunity is available, and to communicate the
opportunity notification to appropriate individuals (such as
procurement managers, for example) or business entities.
[0063] In this manner, various business opportunities may be
automatically identified by contracts management component 30 based
on extracted information 74 that may not be efficiently identified
by human management of supplier contracts. Such business
opportunities may include opportunities to reduce costs (such as by
obtaining or enforcing discounts, for example), to increase revenue
generation (such as by obtaining or enforcing refunds, rebates or
margins, for example) and to reduce legal exposure due to
non-compliance with contractual terms, for example.
[0064] As shown in FIG. 2, contracts applications 90 may be
associated with, or coupled to, an output sub-system 92 operable to
generate various types of visual outputs that may be analyzed or
interpreted by users, such as business analysts. In particular
embodiments, output sub-system 92 includes a data visualization
module 94 operable to generate various data visualizations 96 and a
business intelligence reports 98 operable to generate business
intelligence reports 100.
[0065] Data visualizations 96 may include two-dimensional and
three-dimensional visualizations, such those illustrated by FIGS.
3A-3B, 9A, 9B, 11 and 15, and may include a plurality of such
visualizations through which a user may navigate using one or more
navigation tools. Such navigation tools may be provided by
contracts applications 90 or any other suitable application, and
may include on-line browsers and search engines, for example. Data
visualizations 96 may illustrate one or more areas of business
opportunity which may be analyzed by a user, such as a business
analyst, in order to further filter and isolate complex data in a
manner that reveals particular patterns (such as spend patterns,
for example) or business opportunities, such as described above
regarding the rebate opportunity example. For example, a particular
data visualization 96 may include a graph illustrating discount
information regarding procurements from a particular supplier that
may be analyzed by a business analyst to discover potential
discount opportunities.
[0066] Business intelligence reports 100 may include textual
reports (which may include pictorial representations) generated by
business intelligence reporting module 98. In a particular
embodiment, contracts applications 90 are operable to receive a
request 88 from a user based on the user's analysis of a particular
data visualization 96, for example, and to communicate with
business intelligence reporting module 98 to generate an
appropriate business intelligence report 100 based on particular
extracted information 74 and/or electronics contracts 60 (or
portions thereof).
[0067] In particular embodiments, output sub-system 92 is operable
to provide searching or navigation tools allowing users to search
or browse various outputs 48, such as data visualizations 96 and/or
business intelligence reports 100. For example, in particular
embodiments, output sub-system 92 may include a browser and/or a
search engine allowing a user to search for particular contracts or
portions of contracts and to view and navigate through the results
of such searches.
[0068] In some embodiments, contracts applications 90 are operable
to process extracted information 74 associated with a particular
business parameter (such as a particular business issue 82 or
relevant parameter 84, for example) in order to generate one or
more particular outputs 48 (such as a data visualization 96 or
business intelligence report 100) regarding that business
parameter. For example, in a particular embodiment, contracts
applications 90 are operable to receive, process and/or analyze
particular extracted information 74 regarding potential rebates
from a particular supplier in order to generate an output 48 that
may be used to identify a rebate opportunity regarding a particular
product.
[0069] As discussed above, contracts applications 90 may be
operable to include electronic contracts 60 or portions of
electronic contracts 60 (such as particular sentences, clauses or
paragraphs of electronic contract 60a, for example) received from
electronic contracts database 62 within various outputs 48. For
example, as shown in FIG. 2, a particular contract pointer 76a may
be used to point to a particular electronic contract 60 stored in
electronic contracts database 62. The pointed-to electronic
contract, shown as electronic contract 60a, may be forwarded to
contracts applications 90 for processing. Contracts applications 90
may be able to include electronic contract 60a, or portions
thereof, in a particular output 48. For example, contracts
applications 90 may allow a user to browse such electronic
contracts 60, or portions thereof, in order to identify relevant
contract language, for example.
[0070] In addition to the various forms of output generated by
output sub-system 92, contracts application 90 may be operable to
generate output data 102 to be imported into procurement data
warehouse 14. As shown in FIG. 2, procurement data warehouse 14 is
associated with, or utilized by, each of spend management component
32, compliance management component 34 and supplier intelligence
component 36 of system 10. Thus, in particular embodiments, as
discussed below regarding FIGS. 6, 10 and 13, contracts management
component 30 may be operable to extract relevant information 74
from electronic contracts 60 and process such extracted information
74 to generate output data 102 which may be used as an input by
spend management component 32, compliance management component 34
and/or supplier intelligence component 36 of system 10. In an
alternative embodiment, extracted information 74 may be received
directly as input data by spend management component 32, compliance
management component 34 and/or supplier intelligence component 36
of system 10 without being processed by contracts applications
90.
[0071] Contracts applications 90 and output sub-system (or
particular functionalities thereof) may include separate entities
or software modules or may be a collected set of modules, such as
modules or functionalities provided by a particular software
package, for example. For example, in a particular embodiment, data
visualizations module 94 may comprise the software package MINDSET
provided by SILICON GRAPHICS, INC., and contracts applications 90
and business intelligence reporting module 98 may comprise software
modules or functionalities provided by a particular business
intelligence software package provided by MICROSTRATEGY, INC.
[0072] FIGS. 3A-3B illustrate a display 104 of an example output 48
generated by contracts applications 90 and/or output subsystem 92
of contract management component 30 in accordance with an
embodiment of the present invention. Display 104 illustrates a
variety of information regarding procurements and contractual
arrangements between a particular business entity, XYZ Systems,
Inc., from a particular supplier, ABC, Inc. For example, display
104 includes a supplier spend section 106, a supplier contract
documents section 108, and a supplier contracts event section
110.
[0073] As shown in FIG. 3A, supplier spend section 106 may be
operable to display a summary of spending made by purchaser XYZ
Systems, Inc. from supplier ABC, Inc. In particular embodiments,
supplier spend section 106 includes output generated by spend
management component 32 of system 10, as discussed below in greater
detail with reference to FIG. 6.
[0074] Supplier contract documents section 108 may be operable to
display a listing of each contract that defines a contractual
arrangement between XYZ Systems, Inc. and ABC, Inc. In particular
embodiments, such contracts may be identified, based on particular
information 74 extracted from electronic contracts database 62, by
contracts applications 90 and/or by spend management component 32
of system 10, as discussed below in greater detail with reference
to FIG. 6.
[0075] As shown in FIG. 3B, supplier contracts event section 110
may be operable to display relevant portions, or clauses, of the
contracts listed in supplier contract documents section 108. Such
contract portions may specify the relevant terms and conditions of
the contractual arrangement between XYZ Systems, Inc. and ABC, Inc.
In particular embodiments, the contract portions, or clauses, may
be retrieved form electronic contracts database 62 by one or more
contract pointers 76 linked to particular extracted information 74
regarding XYZ Systems, Inc. and/or ABC, Inc.
[0076] Display 104 may be displayed by an interactive user
interface, such as in a WINDOWS environment, for example, such that
a user may navigate through the display and select particular
details for further analysis. In particular embodiments, display
104 is presented by an Internet browser and includes various icons,
pull-down menus and/or hypertext items (which may include
underlined and/or colored text, for example) that may be selected
by a user to retrieve additional information regarding particular
items. For example, as shown in FIG. 3A, a user may select the
hypertext item 112 labeled "Global_Alliance_Agreement.doc" to
retrieve a display of the particular electronic contract 60
associated with that filename such that the user may browse through
the text of that particular electronic contract 60.
[0077] Returning to FIG. 2, in operation, contracts management
component 30 may periodically update its various databases and
modules. It should be understood that events described throughout
this document as occurring "periodically" include events that occur
at regular, irregular or random intervals and/or events that are
triggered by the occurrence of various other events. For example,
electronic contracts module 62 may periodically receive new
electronic contracts 60, such as electronic contracts 60 generated
by document processing sub-component 40. Text mining module 64 may
periodically analyze electronic contracts database 62 to extract
new relevant information 74, to modify, replace, or delete existing
relevant information 74 and/or to generate new or updated contract
pointers 76.
[0078] In particular embodiments, text mining module 64 is operable
to extract relevant information 74 from at least the new electronic
contracts 60 each time one or more new electronic contracts 60 are
added to electronic contracts database 62. In addition, text mining
module 64 may be operable to extract new or updated relevant
information 74 from some or all electronic contracts 60 stored in
electronic contracts database 62 in response to a modification,
addition or deletion of one or more linguistic rules 76 stored in
linguistic rules database 70. Linguistic rules 76 may be added,
deleted or modified periodically, such as when a new business issue
82 is identified, for example. In a particular embodiment, text
mining module 64 is operable to "re-mine," or re-analyze all of the
electronic contracts 60 stored in electronic contracts database 62
to extract a new set of relevant information 74 each time one or
more new electronic contracts 60 are added to electronic contracts
database 62. In this manner, the extracted information may be kept
current and accurate.
[0079] FIG. 4 illustrates an example method of managing contracts
in accordance with an embodiment of the present invention. At step
150, one or more paper contracts are scanned or otherwise processed
to generate digital images of the paper contracts. At step 152, the
digital images may be processed using optical character recognition
(OCR) techniques to generate an electronic contract corresponding
to each paper contract. At step 154, the electronic contracts are
stored in an electronic contracts database.
[0080] At step 156, one or more business issues relevant to a
particular business process are identified from a knowledge
acquisition session. Such business issues may include business
issues relevant to a procurement process, such as margin
opportunities, rebate opportunities or discount opportunities, for
example. At step 158, one or more relevant parameters are
identified for each identified business issue. For example, the
relevant parameters associated with a particular business issue may
include product name, supplier name, price, quantity and relevant
dates.
[0081] At step 160, one or more linguistic patterns are generated
or identified for each identified relevant parameter. Such
linguistic patterns may include textual patterns in the natural
language associated with each relevant parameter. At step 162, one
or more linguistic rules are written or generated based on the
linguistic patterns identified at step 160.
[0082] At step 164, relevant information is extracted from the
electronic contracts stored in the electronic contracts database
based on the linguistic rules generated at step 162. In particular
embodiments, the extracted information may be sorted, organized, or
otherwise processed based on one or more of the linguistic rules.
At step 166, one or more contract pointers may be generated to link
particular pieces or items of the extracted information to
corresponding electronic contracts, or portions of electronic
contracts, stored in the electronic contracts database.
[0083] At step 168, the information stored in the extracted
information database may be updated, which may include adding new
information, updating particular information, removing particular
information and/or replacing particular information, for example.
For example, if new electronic contracts are added to the
electronic contracts database, relevant information may be
extracted from the new electronic contracts using the linguistic
rules, and such extracted relevant information may be added to the
extracted information database. As another example, if new
linguistic rules are added, or if one or more of the existing
linguistic rules are modified or removed, an updated set of
relevant information may be extracted from the electronic contracts
database based on the new or updated linguistic rules. Such
extracted information may then be added to the extracted
information database and/or may replace all or portions of the
extracted information currently stored in the extracted information
database.
[0084] At step 170, some or all of the extracted information stored
in the extracted information database may be processed and/or
analyzed in order to generate a visual output. In particular
embodiments, particular extracted information may be processed in
order to generate a particular visual output. The visual output may
include one or more electronic contracts (or portions thereof)
received from the electronic contracts database that are associated
with the particular extracted information being processed. Such
electronic contracts (or portions thereof) may be identified by one
or more of the contract pointers generated at step 166 which link
such electronic contracts (or portions thereof) with the particular
extracted information being processed.
[0085] At step 172, it may be determined whether a business
opportunity is available based on an analysis of the output
generated at step 170. For example, a business analyst may
determined whether a rebate or discount opportunity is available
based on an analysis of a table, chart, graph or report generated
at step 170. At step 174, a notification regarding an identified
business opportunity may be generated and communicated to one or
more business entities or employees, such as a procurement manager,
for example.
[0086] In particular embodiments, steps 150 through 154 regarding
converting paper contracts into electronic contracts may be
optional. For example, such steps may not be performed if the
electronics contracts database receives contracts from various
sources already in electronic format.
[0087] FIG. 5 illustrates an example method of developing, testing,
and modifying linguistic rules (such as linguistic rules 76, for
example) in accordance with an embodiment of the present invention.
At step 180, a set of sample information, such as a group of
documents, is manually analyzed to identify information within the
scope of a particular parameter. For example, a set of sample
contracts may be manually analyzed to identify the number and
textual locations of telephone numbers, product names, or company
names. At step 182, a baseline may be established based on the
results of the manual analysis performed at step 180, such as the
number and textual location of each identified item of information
falling within the scope of the selected parameter. For example, if
a manual analysis was performed to identify telephone numbers in a
set of sample information, the baseline may specify the number of
manually identified telephone numbers, as well as each actual
telephone number itself.
[0088] At step 184, one or more linguistic rules are developed or
written based on linguistic patterns associated with the selected
parameter in order to automatically identify information following
within the scope of that parameter. In particular embodiments, such
linguistic rules may be developed as described above with reference
to FIGS. 2 and 4.
[0089] At step 186, the set of sample information is analyzed to
automatically extract information regarding the selected parameter
based on the one or more linguistic rules developed at step 184. At
step 188, the results of the analysis performed at step 186 are
analyzed. In particular embodiments, the information extracted at
step 186 is compared with the baseline information determined at
step 182 to determine the quality of the one or more linguistic
rules.
[0090] In a particular embodiment, both the accuracy and the
thoroughness of the automatically extracted information may be
measured. Accuracy, or precision, represents a measurement (such as
a percentage, for example) of the amount of automatically extracted
information that matches the manually identified baseline
information. For example, if ten sample items relating to a
particular business parameter are manually identified and
established as the baseline information, and the information
automatically extracted based on the linguistic rules includes
twelve items, eight of which match the manually identified sample
items and four of which do not match the manually identified sample
items, the accuracy of the automatically extracted information is
8/12, or 66.7%. In contrast, thoroughness is a measure of the
amount of the baseline information that is identified by the
automatic extraction. Thus, in example provided above, since the
automatically extracted information identified eight of the ten
manually identified sample items, the thoroughness of the
automatically extracted information is 8/10, or 80%.
[0091] At step 190, it is determined whether to adjust one or more
of the linguistic rules based on the analysis performed at step
188. In a particular embodiment, such determination may be based at
least in part on the accuracy and thoroughness of the automatically
extracted information determined at step 188.
[0092] If it is determined at step 190 to adjust one or more of the
linguistic rules or to add one or more new linguistic rules, such
linguistic rules may be modified and or added at step 192. At step
194, the set of sample information may be analyzed again, based on
the modified and/or new linguistic rules, to extract information
associated with the relevant parameter, such as described above
with reference to step 186.
[0093] At step 196, the results of the analysis performed at step
194 are analyzed. In some embodiments, such analysis includes
determining the accuracy and thoroughness of the information
extracted using the modified and/or new linguistic rules, such as
described above with respect to step 188. In addition, in a
particular embodiment, the information extracted at step 194 (based
on the modified and/or new linguistic rules) is compared with the
information extracted at step 186 (based on the original linguistic
rules) to determine the effect of the modifications and/or
additions to the linguistic rules performed at step 192. Such
comparison may be performed to determine whether any information
extracted at step 186 and determined at step 188 to be properly
identified information (in other words, automatically extracted
information determined to match manually identified baseline
information) was not extracted at step 194 using the modified
and/or new linguistic rules.
[0094] The method may then return to step 190 to determine whether
to further adjust or add one or more of linguistic rules based on
the results of the analysis performed at step 196. Steps 190
through 196 may be repeated until it is determined that the
linguistic rules are sufficiently accurate and/or thorough.
[0095] It should be understood that in particular embodiments,
contracts management component 30 may include various software
embodied in computer-readable media and operable to perform all or
portions of the functions and/or methods described above with
respect to FIGS. 2-5. Such software may be concentrated in a
particular software package or distributed in any number of
software modules, programs, routines, or other collections of code,
which may or may not be geographically distributed.
[0096] FIG. 6 illustrates an example architecture and operation of
spend management component 32 in accordance with an embodiment of
the present invention. In the embodiment shown in FIG. 6, spend
management component 32 includes a data collection module 200, a
data processing subsystem 202, procurement data warehouse 14, a
data analysis module 206, a data visualization module 208, and a
business intelligence reporting module 210.
[0097] Data collection module 200 may be operable to receive or
extract source data 20 regarding historical procurement events from
a variety of purchasing data sources 12 via a communications
network 218. Data sources 12 may include a variety of heterogeneous
data sources, such as operational applications 212, manual source
data applications 214 (such as spreadsheet files, for example)
and/or other data sources 216 suitable to communicate information
regarding procurement events. In some embodiments, particular
operational applications 212 may include an on-line transaction
processing (OLTP) system, a teleprocessing monitor, a data
management system (such as a DB2, ORACLE, or SYBASE system, for
example), and/or may have capabilities including on-line data entry
and batch processing, for example.
[0098] One or more data sources 12 may be co-located or
geographically distributed. In addition, as shown in FIG. 6, data
sources 12 may be coupled to data collection module 200 via
communications network 218. Communications network 218 may, in
particular embodiments, include one or more local area networks
(LANs), metropolitan area networks (MANs), wide area networks
(WANs), portions of the Internet, or any other appropriate
wireline, optical, wireless, or other links. It should be
understood in particular embodiments, any or all of the various
components of procurement data management system 10 (such as
components, sub-systems, databases, and modules, for example) may
be connected to each other by communications network 218 or any
suitable communications network.
[0099] As discussed above with reference to FIG. 1, source data 20
may include information from purchase orders (such as information
regarding suppliers, products, prices, refunds, rebates, margins,
and dates, for example), general ledger account information (such
as general ledger account codes, for example), a listing of
procured products and services, where such procurements are made,
who is responsible for making such procurements, payment
information, and a variety of other information regarding
historical procurement events.
[0100] Data collection module 200 may also be operable to receive
contracts management output 102 generated from contracts management
component 30. As discussed above, contracts management output 102
may include processed and/or unprocessed extracted information 74
automatically extracted from various electronic contracts 60 (for
reference, see FIG. 2). In this manner, spend management component
32 may use particular output of contracts management component 30
as an input used in generating the output of spend management
component 32.
[0101] Each purchasing data source 12 may have one or more
associated product catalogs 244, each product catalog 244
identifying each of a set of products by one or more
source-specific attributes, such as model and part number, for
example. Thus, a particular product may be referenced by different
purchasing data sources 12 (or even within a particular purchasing
data source 12) using different attributes (such as different part
numbers), depending on the particular source-specific catalogs 244
used by the various purchasing data sources 12 to identify the
product.
[0102] Data collection module 200 may include one or more
processing elements operable to process source data 20 received or
extracted from various purchasing data sources 12. In the
embodiment shown in FIG. 6, data collection module 200 includes
extraction, transformation and loading (ETL) tools 220. ETL tools
220 may be operable to enable the collection of source data 20 from
many purchasing data sources 12 efficiently. In general, ETL tools
220 may include extraction tools, transformation tools, and loading
tools for the extraction, transformation and loading of source data
20. The extraction tools of ETL tools 220 may be operable to
identify purchasing data sources 12, identify source data 20 to be
extracted, schedule the extraction of source data 20, and
facilitate the transportation of the source data 20 to be
extracted.
[0103] The transformation tools of ETL tools 220 may be operable to
perform integration, integration processing data conversion, data
mapping, data cleansing, data quality processing, and/or data
aggregation processing of various source data 20. Integration may
involve eliminating inconsistencies in data received from multiple
sources, converting data into a consistent, standardized format,
and sorting and merging transformed data into a single data set for
loading into procurement data warehouse 14. Integration processing
may include adding time elements and new keys, converting common
data elements into a consistent form, translating dissimilar codes
into a standard code, converting physical data types into formats,
and/or sorting data into a new sequence. Data conversion may
include converting data representations (such as converting data
from EBCDIC to ASCII, for example), converting operating systems
(such as from UNIX to WINDOWS NT), and/or converting the data type.
Data mapping may include mapping data elements from source tables
and files to destinations fact and dimension tables, adding fields
for unique keys and time elements, and/or using default values in
the absences of source data. Data cleansing may include converting
data from different sources into a single consistent data set
operable to be analyzed, adhering to a particular standard for
establishing codes, domains, formats, and naming conventions, and
correcting data errors and filling the missing data values. Data
quality processing may include selecting data from the best of
multiple sources by using a selection criteria to qualify a source
application to ensure that only acceptable data is forwarded to
procurement data warehouse 14. Data aggregations includes
generating summarized data for use in aggregate and dimension
tables. Thus, in particular embodiments, the transformation tools
are operable to generate metadata (in other words, "data about
data") regarding source data 20 received or extracted from various
purchasing data sources 12.
[0104] The loading tools of ETL tools 220 may be operable to load
extracted source data 20 into data processing subsystem 202. In
particular embodiments, the loading tools may utilize structured
query language (SQL) for loading source data 20. In particular
embodiments, ETL tools 220 may be provided in a commercially
available package, such as "POWER MART" provided by INFORMATICA,
"DATA MART BUILDER" provided by ORACLE, "NOMAD" provided by AONIX,
or "SAS DATA WAREHOUSE" provided by SAS INSTITUTE, for example.
[0105] Data processing subsystem 202 may be operable to process
source data 20 collected or extracted by data collection module 200
before or after such source data 20 is loaded into procurement data
warehouse 14 as procurement data 22. In the embodiment shown in
FIG. 6, data processing subsystem 202 includes a classification
module 224, a global catalog module 226, a business entity
identification module 228, and a business entity relationships
database 230.
[0106] Classification module 224 may be operable to categorize
and/or subcategorize each procurement event based on one or more
business rules 232. In particular embodiments, classification model
224 is operable to provide a global procurement classification
system and to classify all procurement events according to the
global classification system regardless of the classification
systems used by each data source 214 and/or 216. Business
classification rules 232 may be based on the product or service
purchased, the business purpose of the transaction, the financial
nature of the transaction, or any other attribute associated with a
transaction. In a particular embodiment, business classification
rules 232 are developed based on a variety of procurement knowledge
234, such as knowledge available to particular system experts or
business analysts regarding a particular business's needs, desires,
or future plans, for example.
[0107] Global catalog module 226 may be operable to store a global
product catalog specifying, for each of a global set of products,
one or more generic attribute fields as well as mapping
relationships between the one or more generic attribute fields and
various source-specific product attributes specified by one or more
source-specific product catalogs 244. For example, for a particular
product, the global catalog may specify a generic part number as
well as mapping relationships between the generic part number and
various part numbers specified for that particular part by various
source-specific product catalogs 244.
[0108] Global catalog module 226 may be operable to utilize the
global product catalog to map the various source-specific
attributes associated with particular products to the generic
attributes specified by the global product catalog for those
products. Thus, in particular embodiments, global catalog module
226 may be essentially operable to merge any number of
source-specific product catalogs 244 to provide consistent
identification of products and services. In addition, the global
product catalog may provide a comprehensive list of all products
and services procured by a particular business entity.
[0109] Business entity identification module 228 may be operable to
identify and track the business entity or entities specified by
each procurement event as well as one or more business entities
having a particular relation to such business entity or entities
specified by each procurement event. For example, business entity
identification module 228 may be operable to identify a particular
supplier specified by a procurement event as well as the corporate
parent and/or subsidiaries of the particular supplier specified by
the procurement event. Business entity relationships database 230
may be operable to store various business relationships among sets
of two or more related business entities, such as business entities
having some type of ownership relationship, for example.
[0110] Thus, for example, business entity relationships database
230 may store business relationships between a parent corporation
and a subsidiary of the parent corporation. Business entity
identification module 228 may be operable to identify a procurement
event specified by procurement data 22 relating to the subsidiary
corporation (such as information regarding a purchase made by the
subsidiary). Business entity identification module 228 may then
identify, based on business relationships stored in database 230,
the parent corporation of the subsidiary, and associate the parent
corporation with the procurement event. If a user then requests
information concerning the procurement event, or the spending
behavior of the subsidiary, spend management component 32 may be
operable to provide such information to the user (such as by
generating a data visualization or report, for example) regarding
both the subsidiary and the parent corporations.
[0111] One or more business relationships stored in business entity
relationships database 230 may be received from a business
information provider 246. For example, in particular embodiments,
business relationships may be received automatically by one or more
on-line business information providers, such as DUN &
BRADSTREET, for example. Business entity identification module 228
may be operable to utilize business entity relationships database
230 to help identify business entities that are directly and/or
indirectly related to particular procurement events. As discussed
below in greater detail, identifying the business entities directly
and/or indirectly related to particular procurement events may
allow a user to obtain a report or data visualization illustrating
particular procurement information regarding two or more related
business entities, such as a parent corporation and its
subsidiaries, for example.
[0112] Procurement data warehouse 14 may be operable to receive
data from data processing subsystem 202 as procurement data 22. In
particular embodiments, new procurement data 22 may be added to
procurement data warehouse 14 and/or some or all of the procurement
data 22 currently stored in procurement data warehouse 14 may be
modified, replaced and/or deleted periodically. For example, in a
particular embodiment, procurement data 22 may be automatically
updated each time source data 20 associated with one or more
purchasing data sources 12 is updated, after such updated source
data 20 is extracted by data collection module 200 and processed by
data processing subsystem 202. Thus, in some embodiments,
procurement data warehouse 14 may provide a comprehensive,
real-time collection of all procurement data associated with a
variety of purchasing data sources 12.
[0113] Data analysis module 206 may be operable to analyze
particular procurement data 22 stored in procurement data warehouse
14 in order to generate various output 250 that may be used by a
user, such as a spending decision-maker, to make effective spending
decisions. Such output may include results of an analyses regarding
various procurement issues, such as spending associated with a
particular procurement process, for example. In particular
embodiments, for example, data analysis module 206 may perform an
analysis and generate an associated output regarding a particular
procurement process, the procurement of particular products or
services, purchases made by particular business entities (or
particular divisions thereof) and purchases made from particular
suppliers, for example, such as how much is being spent on
particular products or services, how much is being spent by
particular business entities (or particular divisions thereof), in
which geographic areas is the spending occurring, from which
suppliers are particular products or services being purchased, and
who is making and/or authorizing particular spending decisions, for
example.
[0114] In particular embodiments, data analysis module 206 may be
operable to perform both focused spending analyses (such as
evaluating spending by particular divisions or units of a business
entity, spending on particular products or services, or spending
from a particular supplier, for example) as well as global, or
broad, spending analyses (such as evaluating spending by the
overall business entity, spending on all products and services, or
spending from all suppliers, for example).
[0115] In addition, data analysis module 206 may be operable to
perform a variety of analyses periodically in order to track
performance in particular business areas. For example, data
analysis module 206 may be operable to periodically (such as each
time procurement data 22 or extracted information 74 is updated,
for example) compare portions of procurement data 22 with portions
of extracted information 74 to automatically track performance
regarding a particular business opportunity. For example, each time
new procurement data 22 is added to procurement data warehouse 14,
data analysis module 206 may be operable to analyze the current
total spending on a particular product to determine whether a
particular rebate opportunity (as specified by a supplier contract,
for example) is available, or how much additional spending would
trigger such a rebate opportunity. In addition, data analysis
module 206 may be operable to generate a notification regarding the
results of such periodic analyses and communicating such
notifications to particular business entities or individuals
associated with such business entities, such as individuals
responsible for making procurement decisions, for example.
[0116] In addition to the various forms of output generated by
output sub-system 252, data analysis module 206 may also be
operable to generate output data 242 to be imported into
procurement data warehouse 14 and/or used by other components of
procurement data management system 10. For example, as shown in
FIG. 2, procurement data warehouse 14 is associated with, or
utilized by, compliance management component 34 and supplier
intelligence component 36 of system 10. Thus, in particular
embodiments, as discussed below regarding FIGS. 10 and 13, data
analysis module 206 may be operable to generate output data 242
which may be used as an input by compliance management component 34
and/or supplier intelligence component 36 of system 10.
[0117] In some embodiments, data analysis module 206 may also be
operable to determine the effect or influence of particular
procurement activities or decisions on various other procurement
activities or decisions. For example, data analysis module 206 may
be operable to determine the financial effect of purchases made by
one division of a business entity on another division of the
business entity.
[0118] Data analysis module 206 may be operable to identify
business opportunities associated with a procurement process, such
as opportunities to reduce spending, or increase rebates, discounts
or refunds, for example. In particular embodiments, data analysis
module 206 may be operable to compare, contrast, or otherwise
analyze particular procurement data 22 to determine whether a
business opportunity is available. For example, data analysis
module 206 may be operable to compare particular procurement data
22 (such as particular contracts management output 102, for
example) regarding rebate opportunities from a particular supplier
with particular procurement data 22 regarding purchases made form
that supplier in order to discover potential or existing rebate
opportunities, such as described above with reference to contracts
application 90 of contracts management component 30. In addition,
data analysis module 206 may also be operable to generating a
notification if it is determined that the business opportunity is
available, and to communicate the opportunity notification to
appropriate individuals (such as procurement managers, for example)
or business entities. In particular embodiments, the various types
of analyses that may be performed by data analysis module 206 may
be more effective, accurate, faster and/or less expensive than
traditional methods used to attempt such complex analyses.
[0119] In analyzing procurement data 22, data analysis module 206
may be operable to identify information regarding particular
products or services based on the generic attributes associated
with, or mapped to, the products according to global catalog module
226, as discussed above. For example, data analysis module 206 may
be operable to identify all procurement data 22 related to a
particular product using the generic attributes associated with, or
mapped to, that product by global catalog module 226.
[0120] In addition, data analysis module 206 may be operable to
perform various analyses and generate various outputs 250 based on
information requests 248 made by users, such as system
administrators or spending decision-makers, for example. For
example, a user may communicate an information requests 248 to data
analysis module 206 requesting a summary of spending on hardware by
each division in a business entity from each of a number of
suppliers. Data analysis module 206 may be operable to receive the
request 248, analyze procurement data 22 relevant to the request,
generate a visual output, such as a three-dimensional graph or a
report illustrating the requested spending summary, and communicate
the visual output to the requesting user.
[0121] Data analysis module 206 may include a variety of analytical
tools operable to perform a variety of data analysis, such as the
types of analysis described above, for example. For example, in the
embodiment shown in FIG. 7, data analysis module 206 includes one
or more optimization tools 270, one or more simulation tools 272,
forecasting and trends analysis tools 274, and one or more
statistical tools 276. Optimization tools 270 may be operable to
optimize a particular parameter based on a variety of inputs. For
example, optimization tools 270 may be operable to determine how to
optimize the total cost associated with a procurement process based
on a variety of different spending decisions, such as which
products and/or services to purchase from which suppliers, for
example.
[0122] Simulation tools 272 may be operable to perform various
simulations (such as "what if" analyses and alternative-decisions
analyses, for example) based on a set of assumed procurement
decisions. For example, simulation tools 272 may be operable to
select a set of hypothetical procurement decisions regarding a
procurement process or event, and analyzing the financial effects
of such hypothetical procurement decisions. Simulation tools 272
may also be operable to determine the total cost associated with
the procurement process or event based on the set of hypothetical
procurement decisions, which may be then used by optimization tools
270 and/or forecasting and trends analysis tools 274.
[0123] Forecasting and trends analysis tools 274 may be operable to
analyze particular trends in procurement data 22, such as trends
regarding spending decisions, and to make forecasts based on such
trends. For example, forecasting and trends analysis tools 274 may
be operable to forecast spending on particular products or services
from particular suppliers based on historical procurement data.
Forecasting and trends analysis tools 274 may cooperate with
optimization tools 270, simulation tools 272 and/or statistical
tools 276 in order to generate forecasts.
[0124] Statistical tools 276 may provide statistical analysis of
procurement data, which may be used by optimization tools 270,
simulation tools 272 and/or forecasting and trends analysis tools
274. In a particular embodiment, statistical tools 276 include
tools operable to identify aggressions 282, trends 284, forecasts
286, and clustering of data 288.
[0125] Data analysis module 206 may include separate entities or
software modules or may be a collected set of modules, such as
modules or functionalities provided by a particular software
package, for example. For example, in a particular embodiment, data
analysis module 206 may include business intelligence software
provided by MICROSTRATEGY, INC.
[0126] Referring again to FIG. 6, output subsystem 252 may be
operable to generate human-readable output 250 illustrating the
results of various analyses generated by data analysis module 206.
For example, output subsystem 252 may be operable to generate
human-readable output illustrating a summary of spending on
hardware by each division in a business entity from each of a
number of suppliers.
[0127] In the embodiment shown in FIG. 6, output subsystem 252
includes a data visualization module 256 and a business
intelligence reporting module 254. Data visualization module 256
may be the same as or similar to data visualization module 94
discussed above with respect to contracts management component 30
shown in FIG. 2. For example, data visualization module 256 may be
operable to generate a variety of data visualizations 260, such as
advanced graphics, charting and three-dimensional images, for
example, that may help users (such as business analysts or
procurement decision-makers, for example) identify key factors
affecting spending. In particular embodiments, data visualization
module 256 may also provide various tools allowing the user to
manipulate and navigate through the various data visualizations
260, such as described above regarding output subsystem 92 shown in
FIG. 2.
[0128] Business intelligence reporting module 254 may be the same
as or similar to business intelligence reporting module 98.
Business intelligence reporting module 254 may be operable to
generate a variety of business intelligence reports 258 regarding
compliance and/or non-compliance impacts determined by data
analysis module 206. In a particular embodiment, data
visualizations module 256 may comprise the software package MINDSET
provided by SILICON GRAPHICS, INC., and business intelligence
reporting module 254 may comprise a business intelligence software
package provided by MICROSTRATEGY, INC.
[0129] FIG. 8 illustrates an example method of managing procurement
spending in accordance with an embodiment of the present of the
invention. At step 262, various source data regarding historical
procurement events may be extracted or collected from a variety of
data sources. The data sources may be heterogeneous, and may
include operational applications, manual source data applications
(such as spreadsheet files, for example), as well as information
automatically extracted from a set of electronic contracts (such as
extracted information 74 discussed above with reference to FIG. 2).
In particular embodiments, one or more of the data sources may have
an associated source-specific product catalog, each identifying a
set of products by one or more source-specific attributes, such as
part number for example. The source data may be collected using one
or more data collection tools, such as a set of extraction,
transformation and loading (ETL) tools.
[0130] At step 264, a set of business classification rules operable
to categorize and/or sub-categorize particular procurement events
may be generated and/or stored. The set of business rules may be
developed based on the procurement knowledge of one or more
business rules experts, for example.
[0131] At step 266, a global product catalog may be generated
and/or stored. In particular embodiments, the global product
catalog may specify generic attribute fields for each of a global
set of products, as well as mapping relationships between the
generic attribute fields and various source-specific product
attributes specified by the source-specific product catalogs
discussed above.
[0132] At step 268, a set of business entity relationships may be
identified, stored and/or tracked. Such business entity
relationships may include ownership or other defined business
relationships, such as a parent-subsidiary or joint venture
relationship, for example. In particular embodiments, some or all
of the business entity relationships may be automatically received
from a business information provider, such as DUN & BRADSTREET,
for example. At step 270, the source data collected at step 262 may
be processed according to various business classification rules,
product attribute mapping relationships, and/or business entity
relationships generated and/or stored at steps 264, 266 and 268.
For example, the source data may be classified by the set of
business classification rules regardless of various classification
systems used by the various data sources. In addition, the
source-specific attributes associated with particular products
specified by the source data may be mapped to the generic
attributes specified by the global product catalog in order to
provide consistent identification of products and/or services. In
addition, business entities directly and/or indirectly related to
particular source data may be identified based on the business
entity relationships. For example, procurement data regarding a
particular supplier may be organized together and linked to
procurement data regarding various other suppliers or other
business entities determined to be related to the particular
supplier based on the business entity relationships.
[0133] At step 272, the source data processed at step 270 may be
stored as procurement data in a procurement data warehouse. At step
274, at least a portion of the procurement data may be analyzed to
generate a variety of outputs regarding procurement spending. In
particular embodiments, such outputs may include one or more data
visualizations and/or business intelligence reports which may be
used by a user, such as a spending decision-maker, to make
effective spending decisions. In a particular embodiment, a user
may identify, based on an analysis of a particular data
visualization, a particular factor or parameter of interest, and
generate an information request for additional information
regarding the factor or parameter of interest. Information
regarding the factor or parameter of interest may be collected from
the procurement data warehouse and included in an business
intelligence report communicated to the requesting user.
[0134] In particular embodiments, the various output generated at
step 274 may also include analysis results operable to be used by
one or more other components of procurement data management system
10, such as compliant management component 34 and/or supplier
intelligence component 36. In this manner, various output of spend
management component 32 may be used as input by one or more other
components of system 10.
[0135] At step 276, the procurement data stored in the procurement
data warehouse may be periodically modified and/or new procurement
data may be periodically added. For example, in particular
embodiments, the procurement data may be modified based on a
modification or addition to the collected source data, one or more
of the business classification rules, the global product catalog,
or the business entity relationships. In particular embodiments,
the procurement data stored in the procurement data warehouse may
be modified automatically and in real time. The method may then
return to step 274 to analyze the new and/or modified procurement
data. In this manner, spending analyses may be performed
periodically and in real time based on the procurement data
currently stored in the procurement data warehouse.
[0136] It should be understood that in particular embodiments,
spend management component 32 may include various software embodied
in computer-readable media and operable to perform all or portions
of the functions and/or methods described above with respect to
FIGS. 6-8. Such software may be concentrated in a particular
software package or distributed in any number of software modules,
programs, routines, or other collections of code, which may or may
not be geographically distributed.
[0137] FIG. 9A illustrates a display 290 of an example output 250
generated by data analysis module 206 and/or output subsystem 252
of spend management component 32 in accordance with an embodiment
of the present invention. Display 290 illustrates a variety of
information regarding patterns and behavior of spending on products
and/or services from a particular supplier, Company A. For example,
display 104 includes a spending summary section 292 operable to
display the results of a spending analysis performed by data
analysis module 206. Spending summary section 292 may indicate
particular spending behaviors broken down by any of a variety of
parameters. For example, as shown in FIG. 9A, spending summary
section 292 indicates annual spending by a particular business
entity, broken down by master supplier (Company A) and further by
each supplier associated with the master supplier or by divisions
(Divisions A, B, C and D) of the master supplier.
[0138] Like display 104, display 290 may be displayed by an
interactive user interface, such as in a WINDOWS environment, for
example, such that a user may navigate through the display and
select particular details for further analysis. In particular
embodiments, display 290 is presented by an Internet browser and
includes various icons, pull-down menus and/or hypertext items
(which may include underlined and/or colored text, for example)
that may be selected by a user to retrieve additional information
regarding particular items.
[0139] For example, as shown in FIG. 9A, a user may select any of a
variety of parameters from a pull-down menu 294 to retrieve a
display of information relevant to the selected parameter. Thus, a
user may select "Location" from pull-down menu 294 to retrieve a
display of particular spending information broken down by
geographic location. As another example, a user may select the
hypertext item 296 labeled "Company A, Division A" to retrieve a
more detailed display of purchases made from Division A of Company
A.
[0140] FIG. 9B illustrates an example data visualization 400
generated by output subsystem 252 of spend management component 32
in accordance with an embodiment of the present invention. In
general, data visualization 400 illustrates amounts spent on
hardware products from each of a number of suppliers by each of a
number of organizational divisions, or levels, of a purchasing
organization.
[0141] Data visualization 400 includes a three-dimensional graphic
402 and a data point detail 404. Three-dimensional graphic 402
comprises a scatter chart having a number of business divisions
(US-Southwest, Japan, etc.) along a first axis, a number of
suppliers (Supplier A, Supplier B, etc.) along a second axis, and a
number of data bars extending along a third axis at various
intersections of business divisions and suppliers. The height of a
data bar located at the intersection of a particular business
divisions and a particular supplier is proportional to the amount
spent by the particular business divisions on products and/or
services from the particular supplier. For example, the height of
data bar 406 is proportional to the amount spent by the US-Midwest
division of the purchasing organization on products and/or services
from Supplier K.
[0142] Graphic 402 may also indicate whether particular
expenditures are approved or non-approved, or compliant or
non-compliant. For example, all data bars related to non-approved
or non-compliant expenditures may be shaded or colored differently
than approved or compliant expenditures, which may be indicated by
a key or legend 408. Thus, a user may imply from graphic 402 shown
in FIG. 9B that all procurements made from Suppler F are
non-approved procurements.
[0143] In a particular embodiment, data point detail 404 may
display various information, such as a numerical quantity,
associated with a particular selected data bar. For example, as
shown in FIG. 9B, if a user positions a cursor or pointer over data
bar 406, data point detail 404 may display information regarding
data bar 406, such as the name of the business divisions and
supplier corresponding with data bar 406, and the numerical amount
of money represented by data bar 406.
[0144] Like display 104, data visualization 400 may be displayed by
an interactive user interface, such as in a WINDOWS environment,
for example, such that a user may navigate through the display and
select particular details for further analysis. In particular
embodiments, data visualization 400 is presented by an Internet
browser and includes various icons, pull-down menus and/or
hypertext items (which may include underlined and/or colored text,
for example) that may be selected by a user to retrieve additional
information regarding particular items.
[0145] FIG. 10 illustrates an example architecture and operation of
compliance management component 34 of system 10 in accordance with
an embodiment of the present invention. Compliance management
component 34 is generally operable to monitor compliance with a set
of strategic business rules regarding the procurement of particular
products and services. In particular embodiments, compliance
management component 34 is operable to access large amounts of
heterogeneous data from multiple sources to identify the who, what,
where, when and why of non-compliance, quantify the impact of such
non-compliance, and communicate such information to business
decision-makers who may have the knowledge and/or authority to
correct the non-compliance. In addition, compliance management
component 34 may be operable to monitor the effectiveness of the
business rules themselves and to modify such business rules in
response to changes in the business climate and supplier community
in order to maximize business opportunities.
[0146] In a particular embodiment, compliance management component
34 may include procurement data warehouse 14 including various
procurement data 22, a compliance analysis module 304, a compliance
impacts model 306 and an output subsystem 308. As discussed above
with reference to FIG. 6, procurement data warehouse 14 may include
a variety of procurement data 22, which may include source data 20
received from one or more purchasing data sources 12.
[0147] Procurement data warehouse 14 may also be operable to
receive contracts management output 102 generated by contracts
management component 30. As discussed above, contracts management
output 102 may include information 74 automatically extracted from
various electronic contracts 60 (see FIG. 2 for reference). In this
manner, compliance management component 34 may use particular
output of contracts management component 30 as an input for
performing analyses and/or generating outputs associated with
compliance management component 34.
[0148] In addition, procurement data warehouse 14 may be operable
to receive spend management output 242 generated by spend
management component 32. As discussed above, spend management
output 242 may include results of procurement or spending analyses
performed by data analysis module 206 of spend management component
32. In this manner, compliance management component 34 may use
particular output of spend management component 32 as an input for
performing analyses and/or generating outputs associated with
compliance management component 34.
[0149] Compliance rules database 302 is operable to store a set of
compliance rules, or business compliance rules, 310 that specify
specific attributes and values of procurement events that must be
achieved in order for a particular procurement event to be
considered compliant. In particular embodiments, compliance rules
310 also specify how to calculate the financial impact of
non-compliance with particular compliance rules 310.
[0150] Compliance rules 310 may be developed or written by business
rules experts and/or subject matter experts based on a set of
procurement knowledge 312 available to such business rules experts
and/or subject matter experts. Procurement knowledge 312 may
include a set of requirements regarding which suppliers to buy
goods or services from based on a number of various factors,
forecasted conditions, current and historical performance
measurements, subject matter expert (SME) intelligence about
businesses or industries, and current economic conditions, for
example. In a particular embodiment, business rules experts and/or
subject matter experts may use such procurement knowledge 312 to
develop compliance rules 310 operable to determine whether a
purchaser is buying goods or services from approved or non-approved
suppliers.
[0151] Compliance analysis module 304 may be operable to
automatically analyze procurement data 22 regarding one or more
particular procurement events to determine whether the one or more
procurement events are compliant or non-compliant according to one
or more compliance rules 310. For example, compliance analysis
module 304 may be operable to determine whether particular
procurements were made from approved or non-approved suppliers
based on one or more compliance rules 310. Compliance analysis
module 304 may also be operable to determine the financial impact
314 of compliance and/or non-compliance with particular compliance
rules 310. For example, for procurement events (such as particular
purchases from a particular supplier, for example) determined to be
non-compliant, compliance analysis module 304 may determine the
financial impact 314 of such non-compliance based on one or more
compliance rules 310.
[0152] The financial impact 314 of compliance or non-compliance of
a particular procurement event, as determined by compliance
analysis module 304, may be stored in procurement data warehouse 14
as an additional attribute associated with the particular
procurement event. As shown in FIG. 10, compliance analysis module
304 may also be able to generate business rule feedback 316 and
user feedback 318 based on an analysis of particular procurement
data 22 according to one or more compliance rules 310. Business
rule feedback 316 provides various feedback regarding the
effectiveness of particular compliance rules 310. For example,
business rule feedback 316 may include feedback regarding
situations in which non-compliance procurement events actually
provide a financial advantage, as well as feedback regarding
particular procurement events that are not covered by the set of
compliance rules 310. Business rule feedback 316 may allow a user
or system administrator to easily monitor the effectiveness of
particular compliance rules 310 and to adjust or fine tune them
accordingly.
[0153] User feedback 318 may include reasons for non-compliance of
a particular procurement event as well as recommendations regarding
actions to be taken to correct the non-compliance situation. Thus,
user feedback 318 may assist a user or a system administrator in
understanding the nature of a particular non-compliant procurement
event. In particular embodiments, user feedback 318, including
reasons for non-compliance as well as information necessary or
helpful to correct the situation, may be communicated throughout an
organization, or at least relevant parts of an organization. For
example, in a particular embodiment, user feedback 318 may be
communicated to all procurement decision-makers within an
organization by an automatically-generated e-mail notification or
report.
[0154] Compliance analysis module 304 may include a variety of
analytical tools operable to perform various compliance analyses.
For example, compliance analysis module 304 may include some or all
of the analytical tools discussed above with reference to data
analysis module 206 shown in FIGS. 6 and 7. Thus, in particular
embodiments, compliance analysis module 304 may include one or more
optimization tools, simulation tools, forecasting and trends
analysis tools, and statistical tools.
[0155] Output subsystem 308 may be operable to generate output
regarding the compliance and/or non-compliance of particular
procurement events. In particular embodiments, output subsystem 308
may be operable to generate output in response to a user request
328 for particular compliance information. For example, output
subsystem 308 may be operable to generate human-readable output
indicating whether particular procurement events are compliant or
non-compliant, the financial impact (both positive and negative) of
such compliance or non-compliance, as well as particular business
rule feedback 316 and user feedback 318 generated by compliance
analysis module 304.
[0156] In the embodiment shown in FIG. 10, output subsystem 308
includes a data visualization module 320 and a business
intelligence reporting module 322. Data visualization module 320
may be the same as or similar to data visualization module 94
discussed above with respect to contracts management component 30
shown in FIG. 2. For example, data visualization module 320 may be
operable to generate a variety of data visualizations 324, such as
advanced graphics, charting and three-dimensional images, for
example, that may help users (such as business analysts or
procurement decision-makers, for example) identify key factors
affecting compliance and non-compliance. In particular embodiments,
data visualization module 320 may also provide various tools
allowing the user to manipulate and navigate through the various
data visualizations 324, such as described above regarding output
subsystem 92 shown in FIG. 2.
[0157] Business intelligence reporting module 322 may be the same
as or similar to business intelligence reporting module 98.
Business intelligence reporting module 322 may be operable to
generate a variety of business intelligence reports 326 regarding
compliance and/or non-compliance impacts determined by compliance
analysis module 304.
[0158] FIG. 11 illustrates a display 430 of an example output
generated by output subsystem 308 of compliance management
component 34 in accordance with an embodiment of the present
invention. Display 430 illustrates a variety of information
regarding compliance and non-compliance with particular labor
contracts. For example, display 430 includes a compliance analysis
table 432 and a number of interactive tools 434.
[0159] As shown in FIG. 11, compliance analysis table 432 displays
a summary of compliance information regarding an organization,
broken down by line of business of the organization. For example,
compliance analysis table 432 displays a summary of various
compliance metrics (such as "Addressable Spend YTD ($K),"
"Compliance % YTD," "Savings Realized YTD ($K)," and "Est. Savings
Lost YTD ($K)") for each line of business of an organization. In a
particular embodiment, information displayed under the heading
"Addressable Spend YTD ($K)" may be determined by spend management
component 32, and information provided under the heading
"Compliance % YTD" may be determined based on contracts management
output 102. Thus, compliance analysis table 432 may provide an
example of the interrelations between the various components of
procurement data management system 10.
[0160] Display 430 may be displayed by an interactive user
interface, such as in a WINDOWS environment, for example, such that
a user may navigate through the display and request additional
analyses using interactive tools 434. In particular embodiments,
display 430 is presented by an Internet browser and includes
various icons, pull-down menus and/or hypertext items (which may
include underlined and/or colored text, for example) that may be
selected by a user to retrieve additional information regarding
particular items.
[0161] FIG. 12 illustrates an example method of managing compliance
with business compliance rules in accordance with an embodiment of
the present invention. At step 350, one or more compliance rules
are developed or written based on a set of procurement knowledge,
which may include knowledge regarding particular suppliers from
which to purchase particular goods and services based on a variety
of factors. At step 352, the compliance rules may be stored in a
compliance rules database.
[0162] At step 354, contracts management output may be generated
including, or at least based on, relevant information automatically
extracted from a set of electronic contracts, such as extracted
information 74 discussed above with respect to FIG. 2. At step 356,
a variety of procurement data may be stored in a procurement data
warehouse. In particular embodiments, the procurement data includes
at least a portion of the contracts management outputs generated at
step 354. The procurement data may include various information
regarding any number or procurement events, such as purchase order
information and invoice information, for example.
[0163] At step 358, procurement data regarding one or more
particular procurement events may be analyzed to determine the
compliance or non-compliance of one or more particular procurement
events based on one or more of the compliance rules developed at
step 350. At step 360, various financial impacts (both positive and
negative) of the compliance and/or non-compliance of the particular
procurement events may be determined. In a particular embodiment,
such financial impacts are stored in the procurement data warehouse
as an additional attribute associated with the particular
procurement events.
[0164] At step 362, business rule feedback may be generated
according to the analysis performed at step 358. Such business rule
feedback may include feedback regarding situations in which
non-compliance procurement events actually have a positive
financial impact, as well as identifying procurement events that
are not covered by the set of compliance rules developed at step
350. As discussed below with regard to step 372, the business rule
feedback may allow an administrator or business rules expert to
monitor the effectiveness of particular compliance rules and modify
or add particular compliance rules accordingly. At step 364, user
feedback may be generated based on the analysis performed at step
358. In particular embodiments, the user feedback indicates reasons
for non-compliance of particular procurement events and provides
recommendations for correcting such non-compliance situation.
[0165] At step 366, one or more data visualizations may be
generated based on the results of the analysis performed at step
358. For example, such data visualizations may indicate whether
their particular procurement events are compliant or non-compliant,
the financial impacts determined at step 360 of such compliance
and/or non-compliance, particular business rule feedback generated
at step 362 and/or particular user feedback generated at step
364.
[0166] At step 368, a user, such as a business analyst, may
identify, based on an analysis of particular data visualizations, a
particular factor or parameter affecting compliance or
non-compliance, and generate a user request for more information
regarding that factor or parameter. At step 370, information
regarding the identified factor or parameter may be collected from
the procurement data warehouse and included in a business
intelligence report communicated to the requesting user. In this
manner, a user may identify an interesting aspect of a data
visualization, request additional information regarding the
identified aspect, and receive an automatically generated business
intelligence report including the requested information.
[0167] At step 372, one or more of the compliance rules developed
or written at step 350 may be modified based on particular business
rule feedback generated at step 362. For example, a subject matter
expert may receive a data visualization at step 368 indicating,
based on business rule feedback generated at step 362, that a
particular compliance rule is ineffective. The subject matter
expert may then provide instructions or requirements to a system
administrator or business rules expert for adjusting the
ineffective compliance rule accordingly. As another example, a
subject matter expert may receive a data visualization indicating,
based on business rule feedback generated at step 362, that a
particular procurement event is not covered by any of the
compliance rules stored in the compliance rules database. The
subject matter expert may then provide instructions or requirements
to a system administrator or business rules expert for adding one
or more new compliance rules to cover such procurement events in
the future.
[0168] At step 374, the procurement data stored in the procurement
data warehouse may be periodically modified and/or new procurement
data may be periodically added. For example, in particular
embodiments, the procurement data may be modified each time source
data and/or contracts management output is added and/or modified,
such as described above with reference to FIG. 6. At step 376, a
new or updated analysis regarding the compliance or non-compliance
of particular procurement events may be performed based on new or
updated procurement data regarding such procurement events and/or
based on new or updated compliance rules. In a particular
embodiment, the new analysis regarding the compliance or
non-compliance of particular procurement events is performed each
time the procurement data or compliance rules related to such
procurement events is modified.
[0169] After the addition or modification of the procurement data
at step 374, the method may then return to step 360 to generate the
various outputs associated with the compliance analysis performed
at step 376. In this manner, compliance analyses may be performed
periodically and in real time based on the procurement data
currently stored in the procurement data warehouse.
[0170] It should be understood that in particular embodiments,
compliance management component 34 may include various software
embodied in computer-readable media and operable to perform all or
portions of the functions and/or methods described above with
respect to FIGS. 10-12. Such software may be concentrated in a
particular software package or distributed in any number of
software modules, programs, routines, or other collections of code,
which may or may not be geographically distributed.
[0171] FIG. 13 illustrates an example architecture and operation of
supplier intelligence component 36 of system 10 in accordance with
an embodiment of the present invention. In general, supplier
intelligence component 36 allows a user to manage a large volume of
supplier management information, including information regarding
multiple suppliers, contractual issues, international regulations,
new products and services, particular business needs and human
elements, for example, to assist the user in making supplier
management decisions. In particular embodiments, supplier
intelligence component 36 is operable to analyze a large volume of
information, such as products, prices, multiple purchase orders,
geography, inventory and shipping costs, for example, to optimize
supplier management decisions in real time according to a set of
heuristics and business rules. For example, supplier intelligence
component 36 may be operable to analyze the effects that decisions
made by particular spend categories or divisions of a business
entity have on each other based on a total-cost-of-ownership view.
In this matter, supplier intelligence component 36 may be operable
to analyze a supply chain more effectively than previous or
existing systems.
[0172] Supplier intelligence component 36 may include procurement
data warehouse 14, a supplier intelligence analysis module 500, a
supplier intelligence business rules database 518, and an output
subsystem 502. As discussed above with reference to FIG. 6,
procurement data warehouse 14 may include a variety of procurement
data 22, including a variety of source data 20 from a number of
data sources 12, as well as a set of contracts management output
102, which may include information automatically extracted from a
set of electronic contracts, as discussed above with reference to
FIG. 2. Source data 20 and contracts management output 102 may be
collected and processed by data collection module 200 and data
processing subsystem 202, as discussed above with reference to FIG.
6, and stored in procurement data warehouse 14 as procurement data
22.
[0173] Procurement data 22 may include spending information
regarding a number of divisions, or silos, of a business
organization. For example, as shown in FIG. 13, procurement data 22
may include spending data associated with a hardware spend silo
504, a software spend silo 506, a telecommunications spend silo
508, a shipping spend silo 510, an administrative services spend
silo 512, and a contract labor spend silo 514. Within a particular
procurement process, or supply chain, hardware spend silo 504 may
be responsible for purchasing hardware, software spend silo 506 may
be responsible for purchasing software, telecommunications spend
silo 508 may be responsible for procuring and/or otherwise managing
telecommunications, shipping spend silo 510 may be responsible for
managing shipping of procured products, administrative services
spend silo 512 may be responsible for procuring and/or otherwise
managing various administrative services, and contract labor spend
silo 514 may be responsible for purchasing and/or otherwise
managing contract labor.
[0174] Particular procurement data may be categorized into one or
more spend silos 504 through 514 based on a set of business
classification rules, such as business classification rules 232
discussed above with reference to FIG. 6, for example. In a
particular embodiment, each spend silo 504 through 514 includes
information regarding each purchase of products and/or services
made by that spend silo. In some embodiments, particular
procurement data 22 regarding one or more of the spend silos 504
through 514 may be generated and/or categorized according to
particular spend management output 261 generated by data analysis
module 206 of spend management component 32. For example, spend
management output 261 may include results of an analysis regarding
procurements made by particular divisions of a business
organization, such as spend silos 504 through 514. In this manner,
spend management output 261 generated by spend management component
32 may be used as an input by supplier intelligence component
36.
[0175] Procurement data warehouse 14 may also include a set of
supplier portfolios 516, each including information regarding a
particular supplier, such as information regarding spending by line
of business, savings by geography, supplier alignment information,
and compliance by sourcing engagements associated with the
supplier, for example.
[0176] Supplier intelligence analysis 500 may be operable to
analyze particular procurement data 22 stored in procurement data
warehouse 14 in order to optimize particular supplier management
decisions based on a set of supplier intelligence business rules
520. The set of supplier intelligence business rules 520 may be
generated or written based on a variety of business rules input 522
and procurement knowledge 524. Supplier intelligence business rules
520 may be stored in supplier intelligence business rules database
518.
[0177] Business rules input 522 may include one or more supplier
requirements 526, customer requirements 528, contract analysis 530,
business requirements 532, and silo spend formulas 533. Supplier
requirements 526 may include information regarding pricing of
products, sourcing terms and conditions, and spend information, for
example. Customer requirements 528 may include information such as
performance metrics for delivery of goods (such as a requirement
for on-time delivery) and performance requirements regarding
pricing, for example. Contract analysis 530 may include information
such as contract terms and conditions, and payment terms, for
example. Business requirements 532 may include information such as
strategic sourcing rules and terms agreed upon by particular
suppliers, for example. Silo spend formulas 533 may include
formulas regarding each particular division or silo of a business
organization for determining spending associated with that division
or silo. Silo spend formulas 533 may be generated by business rules
experts or subject matter experts, for example, based on a variety
of procurement knowledge and historical procurement information.
Procurement knowledge 524 may include forecasted conditions,
current and historical performance measurements, subject matter
expert (SME) intelligence about businesses or industries, and
current economic conditions, for example.
[0178] In particular embodiments, supplier intelligence business
rules 520 may interrelate various silo spend formulas 533
associated with any number of divisions, or silos, of the business
organization. For example, a particular supplier intelligence
business rule 520 may interrelate at least one silo spend formula
533 associated with first business division with at least one spend
formula 533 associated with a second business division. Thus,
supplier intelligence business rules 520 may be used by supplier
intelligence analysis module 500 to identify the financial effects
of procurement decisions made by one division of a business entity
on one or more other divisions of the same business entity.
[0179] Supplier intelligence analysis module 500 may be operable to
analyze procurement data regarding each spend silo 504 through 514
based on one or more supplier intelligence business rules 520 in
order to generate a variety of outputs 534. For example, supplier
intelligence analysis module 500 may be operable to analyze a
complete procurement process, or supply chain, including the
spending behaviors of each spend silo 504 through 514. In addition,
supplier intelligence analysis module 500 may be operable to
determine the financial effects of decisions made by particular
spend silos on each other, based on procurement data 22 and
supplier intelligence business rules 520. For example, suppose
shipping spend silo 510 negotiates a free shipping arrangement with
a particular supplier. In response, the supplier may increase its
price for particular products or services in order to account for
the absorbed shipping costs. The price increases on such products
may be included within the price for the products or services
negotiated by hardware spend silo 504 with the supplier. In some
situations, the increase in spending by hardware spend silo 504 due
to the price increases made by the supplier is greater than the
amount saved by shipping spend silo 510 from the negotiated free
shipping. Thus, the negotiated free shipping may actually increase
the total-cost-of-ownership of the overall procurement process, or
supply chain.
[0180] In this manner, particular divisions or silos of a business
organization often make decisions that are financially advantageous
to that division or silo, without realizing various disadvantageous
financial effects on other divisions or silos of the business
entity, or on the total cost associated with the procurement
process or supply chain. By analyzing the total-cost-of-ownership
associated with a procurement process or supply chain, supplier
intelligence analysis module 500 is operable to identify such
financial relationships between particular divisions or silos of
the business organization and to suggest particular procurement
decisions accordingly.
[0181] In particular embodiments, supplier intelligence analysis
modules 500 may include a variety of analytical tools operable to
perform various supplier intelligence analyses. For example,
supplier intelligence analysis module 500 may include some or all
of the analytical tools discussed above with reference to data
analysis module 206 shown in FIGS. 6 and 7. Thus, in particular
embodiments, supplier intelligence analysis module 500 may include
one or more optimization tools, simulation tools, forecasting and
trends analysis tools, and statistical tools, for example.
[0182] For example, supplier intelligence analysis module 500 may
be operable to performing simulations based on a set of
hypothetical procurement decisions. A particular simulation may
include selecting a set of hypothetical procurement decisions
regarding a procurement process (such as selecting particular
products to purchase, from particular suppliers, and using
particular types of shipping, for example) and determining various
costs associated with the procurement process, as well as savings
or losses as compared with simulations performed based on various
other hypothetical procurement decisions. For example, supplier
intelligence analysis module 500 may be operable to determining a
total cost associated with the procurement process based on each
simulation.
[0183] Output subsystem 502 may be operable to generate a variety
of outputs 534 operable to assist decision-makers in making
procurement decisions based on a total-cost-of-ownership view. For
example, output subsystem 502 may be operable to generate various
outputs 534 illustrating the effect of particular procurement
decisions on the total cost associated with the procurement
process, or supply chain.
[0184] In particular embodiments, output subsystem 502 is the same
as or similar to output subsystem 252 of spend management component
32 or output subsystem 308 of compliance management component 34.
For example, output subsystem 502 may include a data visualization
module operable to generate various data visualizations 536 and a
business intelligence reporting module operable to generate various
business intelligence reports 538 including results of analyses
performed by supplier intelligence analysis module 500.
[0185] FIG. 14 illustrates an example method of managing supplier
intelligence in accordance with an embodiment of the present
invention. At step 550, a variety of procurement data may be
collected in a procurement data warehouse. The procurement data may
include procurement source data collected from a variety of
heterogeneous data sources, as well as particular output from
contracts management component 30 and/or spend management component
32 of system 10. The contracts management output may include, or be
based on, relevant information automatically extracted from a set
of electronic contracts, such as described above with respect to
FIG. 2. The output from spend management component 32 may include
results of one or more spending analysis performed by spend
management component 32, as described above with respect to FIG.
6.
[0186] At step 552, some or all of the procurement data may be
categorized according to one or more divisions, or silos, of a
business organization with which the procurement data is
associated. The procurement data may be categorized by one or more
business classification rules and/or may include particular output
from spend management component 32 regarding particular analysis of
spending or procurements made by one or more of the divisions or
silos. In particular embodiments, each division or silo is
responsible for managing the spending or procurements made by that
division or silo. At step 553, one or more silo spend formulas may
be generated and/or stored. Each silo spend formulas may include
formulas relating to each division or silo of a business
organization for determining spending associated with that
particular division or silo.
[0187] At step 554, a set of supplier intelligence business rules
may be generated based on a variety of business rules input and/or
procurement knowledge. In a particular embodiment, the variety of
business rules input includes supplier requirements, customer
requirements, business requirements, and contract analysis. The
business rules may be designed to optimize particular decisions
within a procurement process, or supply chain, based on a large
volume of information regarding the spending or procurement
behavior of each of the business organization divisions or silos.
In particular embodiments, the supplier intelligence business rules
may be generated such that they interrelate various silo spend
formulas (generated and/or stored at step 553) associated with any
number of divisions, or silos, of the business organization. For
example, a particular supplier intelligence business rule may
interrelate at least one silo spend formula associated with a first
business division with at least one spend formula associated with a
second business division.
[0188] At step 556, the procurement data regarding some or all of
the business organization divisions or silos may be analyzed based
on the supplier intelligence business rules to generate various
outputs that may be used to make efficient spending or procurement
decisions based on a total-cost-of-ownership perspective. For
example, a portion of the procurement data may be analyzed to
determine the effect of decisions made by one spending division or
silo on one or more other spending divisions or silos of the same
business organization, based on a total-cost-of-ownership
perspective.
[0189] At step 558, one or more visual outputs may be generated
based on the analysis performed at step 556. Such visual outputs
may include a variety of data visualization and/or business
intelligence reports, such as described above with respect to FIGS.
6 and 10.
[0190] At step 560, the procurement data stored in the procurement
data warehouse may be periodically modified and/or new procurement
data may be periodically added. For example, in particular
embodiments, the procurement data may be modified based on a
modification or addition to the collected source data, contracts
management output, spend management output, or one or more of the
supplier intelligence business rules. In particular embodiments,
the procurement data stored in the procurement data warehouse may
be modified automatically and in real time. The method may then
return to step 556 to analyze the new and/or modified procurement
data. In this manner, supplier intelligence analysis may be
performed periodically and in real time based on the procurement
data currently stored in the procurement data warehouse.
[0191] It should be understood that in particular embodiments,
supplier intelligence component 34 may include various software
embodied in computer-readable media and operable to perform all or
portions of the functions and/or methods described above with
respect to FIGS. 13-14. Such software may be concentrated in a
particular software package or distributed in any number of
software modules, programs, routines, or other collections of code,
which may or may not be geographically distributed.
[0192] FIG. 15 illustrates a display 600 of an example output 534
generated by supplier intelligence analysis module 500 in
accordance with an embodiment of the present invention. Display 600
illustrates the financial savings and/or losses associated with
free shipping of hardware provided by a number of different
suppliers, based on a total-cost-of-ownership analysis of a supply
chain.
[0193] Display 600 may include a supplier intelligence table 602
and a number of interactive tools 604. In the example shown in FIG.
15, supplier intelligence table 602 includes a list of suppliers
606 providing free shipping for hardware OEM (original equipment
manufacturer) products procured by a purchasing business
organization, as well as a number of metrics indicating savings and
losses associated with such free shipping. Such metrics may be
determined by supplier intelligence analysis module 500 based on an
analysis of procurement data regarding each spend silo 504 through
514 according to the set of supplier intelligence business rules
520. Column 608 indicates financial losses incurred by the
purchasing business organization as a result of the free shipping
provided by each supplier 606. For example, column 608 may indicate
financial losses due to free shipping as compared to a total supply
chain cost determined without free shipping. Such losses may be
attributed to the supplier 606 increasing prices or reducing
discounts associated with particular products in order to
compensate for providing free shipping, for example. Thus, such
losses may be realized by one or more spend silos 504 through 514,
such as hardware spend silo 504, for example.
[0194] Column 610 indicates the amounts of saving associated with
the free shipping provided by each supplier 606, without accounting
for various financial losses resulting from the free shipping, such
as the losses identified in column 608. For example, column 610 may
indicate savings incurred by shipping spend silo 510 as a result of
the free shipping, without accounting for losses incurred by
hardware spend silo 504 due to increased prices or reduced
discounts, for example. Column 612 indicates the total amount spent
by the purchasing business organization on hardware OEM from each
supplier 606. Column 614 indicates a percentage savings of the
total amount spent from each supplier 606 (as indicated by column
612) due to savings realized by the free shipping provided by each
supplier 606 (as indicated in column 610).
[0195] Display 600 may be displayed by an interactive user
interface, such as in a WINDOWS environment, for example, such that
a user may navigate through the display and request additional
analysis using interactive tools 604. In particular embodiments,
display 600 is presented by an Internet browser and includes
various icons, pull-down menus and/or hypertext items that may be
selected by a user to retrieve additional information regarding
particular items or analysis.
[0196] Output 534 generated by supplier intelligence analysis
module 500, such as the output displayed in supplier intelligence
table 602, for example, may be used to make efficient spending or
procurement decisions based on a total-cost-of-ownership, or a
complete supply chain, perspective. For example, individuals
responsible for making procurement decisions for a particular
division or silo of the business organization may be able to make
optimized decisions based on the total cost of a procurement
process or supply chain, including realizing the effects of
procurement decisions made regarding that division or silo on
various other divisions or silos within the business
organization.
[0197] Although an embodiment of the invention and its advantages
are described in detail, a person skilled in the art could make
various alternations, additions, and omissions without departing
from the spirit and scope of the present invention as defined by
the appended claims.
* * * * *