Archive for the ‘Applications’ Category

h1

Marketplace Content Structure Rules

October 25, 2009

By Scott Walls

Marketplace content structure rules are a set of rules governing the content within organizational marketplaces.  They are created by the providers of marketplace content in an effort to clearly indicate to all marketplace participants what content is in the marketplace, how content is located, and how that content is to be used.  Directly, or indirectly, the underlying principle in most, if not all content structure rules, is to make the presentation and utilization of purchasable content by the most novice of consumers as intuitive as possible.    The goal of marketplace content structuring is to increase the organizational adoption of the marketplace while simultaneously decreasing the organizational support required for the marketplace’s transactions. 

The organizational value of a marketplace increases along with the amount of purchasable content in that marketplace (higher spend on contract, larger rebates, one-stop shopping, etc.).  Unfortunately, so does the acquisition diversity (acquisition diversity = content complexity).  The diversity of items being acquired (on contract vs. off-contract, req vs. no req, fixed vs. variable pricing, lease vs. purchase, static item vs. dynamic item pricing or configuration) increases the need for clear and well communicated set of content rules allowing the consumer of content to intuitively locate and purchase the right goods and services for the right price. 

While each marketplace’s content differs according to the culture, needs, and size of the organization, all marketplace content structure rules fall into one of four categories.  Those categories are as follows:

  1. Scope – scope-related rules articulate the business definition of the content within the marketplace.  Is the marketplace’s scope limited to a functional area (i.e. the scope is technology goods and services); limited to pre-sourced or org-wide contracted content (i.e. the scope is goods and services pre-negotiated as part of statewide contracts for all state-agencies); or simply wide-open (i.e. if the organization can link to a good or service electronically, it is in the marketplace).  Some scopes are easier for the most novice of requesters to intuitively understand.  The goal of the scope, as with all structure rules, is to make locating and using marketplace items as intuitive as possible for the most novice of requesters. 
  2. Organization – organization-related rules define the data elements used within the marketplace as well as how those data elements related with one another.  In a technical sense, this could specify the data elements being used to represent marketplace content; supplier, contract, catalogs (marketplace, remote, proxy, instructional), item or form.  Or, in a functional sense, this could specify the relationship between those data elements; all goods and services must belong to a contract and a supplier, but a supplier can have multiple contracts.  Organization rules help the provider of content understand how they are going to represent content within the marketplace (which has also been conceived in a way that supports the most novice of requester).
  3. Presentation – presentation-related rules define how the marketplace’s content will be presented to the party inquiring regardless of the method (window shopper or via a third party application such as PeopleSoft, Oracle, SAP).  Most requesters of marketplace content are familiar with Amazon-like purchases (type in text, search for item, select item, check-out), hence many successful marketplaces strive to present content in this fashion (starting with the known).  When this is not a possibility (i.e. non-requisitionable items such as a rental cars or temporary staffing), both the presentation rules and the utilization rules (see below) take on added importance.  Organization rules are solely based on the consumer experience and making complex goods and services as intuitive as possible.
  4. Utilization – utilization-related rules define how a consumer will use the content being presented.  More specifically, if a consumer/requester searches for an item and receives a link to a punch-out, do they understand how to use this link, what a punch-out is?  Do they know they now need to access the supplier’s site, potentially re-search, load a cart on the supplier’s site, check-out back to the marketplace (and possibly back to the SRM application)?  As the scope of marketplace content is increased, the number of acquisition instructions increases, are these instructions being stored at the right place in the transaction…at all?  Utilization rules govern the methods in which consumers of content will quickly and easily understand or learn how to acquire all items that are not intuitive.  An example of a good utilization rule would is adding a “How to Purchase” link at the item level that is returned along with the item search.  Hence, when a requester searches for a rental car (something not usually purchased via a requisition or using a marketplace…but could be considered in-scope if it is on a statewide contract), they would also receive detailed purchase instructions for this non-standard type if purchase.  Utilization rules, like presentation rules, are solely focused on the consumer experience.

 In short, a marketplace could have the best content in the world, but if the providers of content cannot design, deploy, and articulate clear, intuitive marketplace content structure rules, then all participants will struggle with the content in the marketplace and how to correctly use it.  This marketplace is likely to underwhelm the organization, either because it offers too little content or because the content it offers is too complex for the infrequent or novice consumer; both issues limit the overall adoption of the marketplace.  Well designed marketplace structures maximize comfortable, successful adoption well beyond the purchasing savvy and/or F&A consumers, this achieving the marketplace content structure goal.

* To understand how to use content structures and content structure rules within an overall marketplace strategy, see Marketplace Content Strategy

 

About SRM Plus

SRM+ is a boutique procurement business consulting firm.  We provide procuring organizations with the strategic and tactical consulting services required to dramatically reduce operational expenses, create revenue streams (1 million per every 200 million in spend), and decrease their Cost Of Goods Purchased (COGP).  Whether defining a strategy, creating measurable objectives, designing / deploying solutions, or creating a continual improvement framework, SRM+ wants to turn your cost centers into cash centers.  Visit us at www.srm-plus.com.

h1

Marketplace Content Structures

October 25, 2009

By Scott Walls

Marketplace content structures are the data elements used represent purchasable content within an organizational marketplace.  This BLOG highlights the common content structures found in most marketplaces.  Where relevant, examples of how marketplace content structures can be governed by marketplace content structure rules is provided (marketplace content structure rules transform marketplace content structures into an intuitive, functioning marketplace).  For more information on marketplace content structure rules, read the BLOG entitled Marketplace Content Structure Rules.

The most common marketplace content structures are as follows:

Items – this content structure represents the goods and services being presented within the marketplace.  The item description is one of the few data points that all participants know and most good searches are based on this variable.  Content structure rules related to scope help consumers understand what items can be found within a marketplace, rules related to presentation help consumers understand how to search through those items and rules related to utilization help consumers understand how to purchase those items once they have been found.

Forms – this content structure allows requesters to request items that can’t be represented within a marketplace by entering free form text into a predetermined set of fields (description, qty, rate, etc.).  When an item’s basic element(s) prevent it from being represented within the marketplace (variable pricing component – lease pricing depending on term, RFQ pricing, or highly configurable product not supported by a supplier’s site/remote catalog), forms are the vehicle for creating requisitions.  Content structure rules related to scope help consumers understand what forms can be found within a marketplace, rules related to presentation help consumers understand how to access the right form and rules related to utilization help consumers understand how to purchase items using a form.

Catalogs – this content structure represents supplier-specific (sometimes even contract-specific) groupings of items.  The scope of catalogs is wholly dependent on the scope of the items within the marketplace.  There are 4 different types of catalogs, each type is examined below: 

  • Marketplace Catalogs – these catalogs reside within the marketplace and contain product details and pricing information.  These catalogs cannot be updated without the permission of the procuring organization.
  • Supplier Catalogs – these catalogs reside in the supplier’s marketplace and contain product details and pricing information.  However, due to their dynamic nature (either price volatility or configuration required to obtain pricing) price cannot be stored in the organization’s marketplace.  The marketplace holds the link to the supplier’s version of the organization’s catalog.  These catalogs can be updated by the supplier at any time and require some level of pricing auditing in order to ensure compliance.  These items DO NOT show up automatically in a marketplace search, they require a “proxy catalog” to be loaded and maintained within the marketplace. 
  • Proxy Catalogs – these are not complete catalogs, they serve more as product “pointers”.  Proxy catalogs contain only product details, no pricing information.  Instead of pricing information, they point to a supplier catalog (they can be set up to make a call to the supplier’s site, but that has not been done at the time of this writing).  When linking to a supplier’s site, they can access the supplier’s content at various levels (store level, item type level, or at the various item…again, anything other than store level had not been set up at the time of this writing).  These catalogs require manual updating from the marketplace providers of content.  The more detailed they are (PC 8126…) the more often they come up in product searches, but the more often they require review and updating from the providers of content.
  • Instructional Catalogs – these are not “real” catalogs, they too serve as “pointers”.  However, these pointers point to purchase instructions for items not available within the marketplace.  Most often these would be for items whose purchase does not require a requisition, but they must be represented within the marketplace.  For example, a sourcing specialist negotiates a contract with a rental car provider and the marketplace content structure rules dictate that the marketplace is supposed to provide product, pricing, and purchase instructions for all items negotiated as part of organizational contracts.  An instructional item would created (a fake item linking to detailed purchase instructions for the rental car, including the reservation web site) and loaded into a catalog for the rental car vendor even though a requisition is not used.  Instructional catalogs/items allow marketplaces to expand their scope rules beyond requisitionable content when necessary.

Contracts – this content structure represents a sub-grouping of items/catalogs for a given supplier.  Contracts are supplier-specific.  This can be helpful when attempting to isolate market-baskets (market-baskets allow procuring orgs to continually evaluate the value of content to itself).  Contracts are also very helpful when rolling up spend across sub-procuring-organizations.  Most marketplaces allow contracts can be negotiated at the parent organization or sub-procuring-organization level.  As with catalogs, the scope of catalogs is wholly dependent on the scope of the items within the marketplace.

Suppliers – this content structure represents the highest level in the item hierarchy.  All other content structures (items, catalogs, and contracts) are subordinate to suppliers.  Suppliers represent the actual supplier of the goods and services.  Marketplaces need to have at least one supplier for every item within the marketplace.  The level of data stored for each supplier depends on the extent of use for the marketplace vs other related applications (i.e. is the order transmission information stored within the marketplace or within an SRM/ERP application).

Procuring Organizations – this content structure represents the organization or sub-procuring-organization doing the purchasing.  This could be one, high-level organization or multiple sub-procuring-organizations depending on the business.  In a shared marketplace model, the high level organization negotiates contracts, leveraging spend across sub-organizations, and shares the items negotiated with multiple sub-orgs by deploying a shared marketplace model (multiple procuring organizations linking to the same marketplace). For example, the State of Georgia contracts with many suppliers on behalf of its 123 sub-agencies (corrections, transportation, juvenile justice, education, etc.).  It then uses its shared Team Georgia Marketplace to broadcast all items to its 123 sub-procuring-organizations.

Providers of Content – this content structure represents the marketplace participants responsible for creating the content within the marketplace; most typically the sourcing function (see also, trans-organizational sourcing functions).

Consumers of Content – this content structure represents the marketplace participants responsible for utilizing the content to order goods and services.  They are typically referred to as “requesters”.

 

* To understand how to use content structures and content structure rules within an overall marketplace strategy, see Marketplace Content Strategy

h1

Shared Marketplaces Increase Procurement Power

August 21, 2009

By Scott Walls

Organizational marketplaces are either dedicated or shared.  Dedicated marketplaces provide purchasable content to one SRM application, whereas shared marketplaces provide the same purchasable content to multiple SRM applications (regardless of vendor – SAP, Oracle, PeopleSoft, etc.).  Dedicated marketplaces have long been the standard, but newer, shared marketplaces are allowing consolidated purchasing organizations to negotiate cross-organizational purchasing content and broadcast that pre-negotiated content to all sub-organizations simultaneously.  For example, the State of Georgia negotiates contracts at the state level and uses SciQuest’s Spend Director to broadcast that content to its 123 agencies across many different applications and instances (4 major instances of PeopleSoft alone).

 

Dedicated Marketplaces

Organizational marketplaces being accessed by a single SRM application are referred to as “dedicated marketplaces”.  In fact, the term “organizational marketplace” implies a one-to-one relationship between the marketplace and the SRM application accessing it. 

All dedicated marketplaces share the following characteristics:

  • Instances – accessed by one SRM instance/application.
  • Data Mappings – one-to-one mappings of shiptos, suppliers, and contracts between the marketplace and the SRM application.
  • Reporting – detailed acquisition reporting comes from SRM application.
  • Order Transmission – supplier details stored in SRM application and orders transmitted from SRM application.

  

Shared Marketplaces

Organizational marketplaces being accessed by multiple SRM applications are referred to as “share marketplaces” (i.e. the marketplace is being shared by multiple SRM applications).  Shared marketplaces are a new, more complicated, marketplace model due to the content being synchronized across multiple applications (multiple mappings for suppliers, shiptos, contracts, etc.).  This model has been created to support the aggregation of purchasing power across multiple sub-oragnizations.  Shared marketplaces allow multiple SRM applications, regardless of vendor, to access the same purchasable content (see Figure 1 below).  Best of breed procuring organizations are using shared marketplaces to aggregate/leverage spend across organizations/firms/agencies in an effort to gain dramatic efficiencies.  

All dedicated marketplace share the following characteristics:

  • Instances – accessed by multiple SRM instances/applications.
  • Data Mappings – one-to-many mappings of shiptos, suppliers, and contracts between the marketplace and the SRM applications.
  • Reporting – detailed acquisition reporting comes from the marketplace (serves as consolidated view across SRM instances/applications).
  • Order Transmission – supplier details stored in marketplace and orders transmitted from marketplace.

NOTE: smaller organizations/agencies who do not have traditional, open architecture SRM applications may view the purchasable content via the marketplace’s “window shopper” mode.

Figure 1  Shared Marketplace Model

One Virtual Marketplace Being Shared by Multiple=

One Virtual Marketplace Being Shared by Multiple SRM Applications

 

 

About SRM Plus

SRM+ is a boutique procurement business consulting firm.  We provide procuring organizations with the strategic and tactical consulting services required to dramatically reduce operational expenses, create revenue streams (1 million per every 200 million in spend), and decrease their Cost Of Goods Purchased (COGP).  Whether defining a strategy, creating measurable objectives, designing / deploying solutions, or creating a continual improvement framework, SRM+ wants to turn your cost centers into cash centers.  Visit us at www.srm-plus.com.

h1

Supply Integration Solutions & How They Add Dramatic Value

August 19, 2009

By Scott Walls

Supply Integration Solutions refer to best of breed, niche, third party tools, applications and services (think content management, esettlement, etc.).  These solutions provide dramatic value enhancements for procuring organizations (and often their supplying organizations) when integrated with traditional SRM applications (SAP, PeopleSoft, and Oracle).  SI solutions have been created to address some of the natural limitations with traditional SRM applications and/or the application provider’s business model. 

This BLOG post provides brief explanations of both the SRM limitations and the related SI solutions.

SI tools are mini-apps (pages and/or process) deployed within the traditional SRM application toolset or using SOA technology.  One size fits all SRM applications can make simple processes appear complex for smaller volume clients.  These “mini-apps” reduce that complexity.  For example, the different cataloging methods within the traditional SRM applications’ requisition process (internal item master, external hosted catalogs, external punch-out catalogs, etc.) confuses the non-procurement savvy requester.  Multiple third-party tool providers have created mini-apps that present one, simplified requester interface, allowing the requester to locate product based on description, without even understanding what an item catalog is.  Because these mini-apps reduce the cataloging complexity, they increase the number of cataloging options available to procurement, increase the amount of content being displayed, and increase the request adoption of the traditional SRM application.

SI applications are external applications that integrate with the traditional SRM application; usually via XML or another standard protocol.  The best of these applications tend to be micro-focused (think external marketplace/item repositories).  They often provide additional, more mature functionality then their traditional SRM counterparts.  In some cases, they also allow multiple SRM applications to access the same functionality/data simultaneously.  For example, content repositories (AKA organizational marketplaces) allow procurement the ability to source purchasable content and make that content available to one or more organizations/SRM applications simultaneously (see Organizational Marketplaces – Shared Vs. Dedicated).  In addition, the content management tools within these third-party applications far exceed their traditional SRM counterparts.  These applications and tools not only allow for better content and easier content management, they pave the way for outsourcing the content management process all together (see the services section below).

SI services, also referred to as “managed services”, are external services that integrate with the traditional SRM both technically and functionally.  These managed services allow procuring orgs to leverage assets they could not create organically (i.e. the Visa settlement infrastructure) or share the management of costly setup/transaction value maintenance (content management/invoice entry).  For example, traditional SRM applications require procurement organizations to setup, test, and maintain all internal item catalogs, external item catalog URL connections, and forms.  Multiple third-party service providers offer external organizational marketplaces procuring organizations can connect to once and the third-party will not only create and manage their content (the “you source, we enable” model), they will work with all potential suppliers from B2B concept initiation through content sunset.  This allows the procuring organization to completely outsource the creation and management of purchasable content at a fraction of the cost of employing the resources.

NOTE: For more information related to Supply Integration, see BLOG posts Supply Integration and Supply Integration Touch-Points.

About SRM Plus

SRM+ is a boutique procurement business consulting firm.  We provide procuring organizations with the strategic and tactical consulting services required to dramatically reduce operational expenses, create revenue streams (1 million per every 200 million in spend), and decrease their Cost Of Goods Purchased (COGP).  Whether defining a strategy, creating measurable objectives, designing / deploying solutions, or creating a continual improvement framework, SRM+ wants to turn your cost centers into cash centers.  Visit us at www.srm-plus.com.

h1

Organizational Marketplaces

August 19, 2009

By Scott Walls

Organizational Marketplaces are centralized, web-based content repositories where the providers of organizational purchasing content (buyers, sourcing specialists, deal managers) make their content available to consumers of organizational purchasing content (employees, temps, requesters).  Most often, purchasable content has been pre-negotiated by the providers, on behalf of the organization, for the benefit of the consumers.   Providing pre-negotiated purchasable content lowers an organization’s overall costs of goods.

Organizational marketplaces can be dedicated or shared.  Marketplaces accessed by one SRM application are referred to as Dedicated Marketplaces whereas marketplaces accessed by multiple SRM applications are referred to as Shared Marketplaces (for more on dedicated vs. shared marketplaces, see the BLOG entitled Organizational Marketplaces – Shared Vs. Dedicated).

 

About SRM Plus

SRM+ is a boutique procurement business consulting firm.  We provide procuring organizations with the strategic and tactical consulting services required to dramatically reduce operational expenses, create revenue streams (1 million per every 200 million in spend), and decrease their Cost Of Goods Purchased (COGP).  Whether defining a strategy, creating measurable objectives, designing / deploying solutions, or creating a continual improvement framework, SRM+ wants to turn your cost centers into cash centers.  Visit us at www.srm-plus.com.

Follow

Get every new post delivered to your Inbox.