Business & Technology Nexus

Dave Stephens on technology and business trends

That Darned Item Category

leave a comment »

A comment on an old post on Procurement Intelligence got me thinking again about Item Categories and the classification problem that Oracle and SAP face. Other Procurement vendors face the same problem, but if you don't have Manufacturing or an Item Master or GL or Payables it's probably not as severe.

Let me help you see my pain by giving you a (somewhat accurate) historical account of how Oracle dealt with categories.

First, know that Oracle ships a product with 0 categories. So as a customer you are completely on your own. The thought behind this (and it applies to UOM and a bunch of other stuff) is that Oracle won't guess b/c they'd probably be wrong and you'd be mad. Flawed logic to be sure but logic nonetheless.

What customers start with is a construct from the Manufacturing space called a "Category Set". The "Purchasing Category Set" serves "core purchasing", the base module. And there are other category sets for other products.

It looks and feels like it was invented in the 70's – real green screen stuff. Of course Oracle is working on a better architecture nowadays – but don't hold your breath. Your kids will be all grown up before it sees light of day. :) But I digress.

When we first introduced iProcurement (the employee self-service requisitioning tool) we had to figure out how to categorize catalog content. And the first and most obvious choice was the Purchasing Category Set – after all, iProcurement was an add-on. Customers presumably had already set up their purchasing categories so why not use them.

Well, it was a horrible fit. You see, the Purchasing Category Set was designed & used mainly for reporting. It did things like drive Accounting. So customers had implemented it with no hint or care of intuitiveness or usability. Some customers had made some really strange choices, effectively making it infathomable for use via self-service. My favorite mistake was Oracle's internal implementation, where Purchasing categories read something like "North America – GL 123 – Martha Stewart" (hunh!?). But Oracle wasn't an outlier, it was in the majority.

Of course we did what we had to – we added a browsing categorization scheme for local catalog content specific to iProcurement. But while necessary, it really messed up the cost of ownership proposition. Suddenly customers had to set up 2 categorization schemes and map between them. And when a mapping failed, users were told at checkout "You can't buy that item". Yuck. Over time we added reasonable capabilities to make things easier, such as giving customers the choice of re-engineering their Purchasing categories and having the system do a 1:1 map.

But I never thought we got it right.

On the one hand, every data cleansing discussion I've ever been involved with has me standing firmly in the corner of "why the heck can't you get the data right on the way in?"

But on the other, I've always questioned the value of formal, normalized categorization for content (and by extension, for buying). And what I mean by that is I'm against any effort (translation: money) being required to get the contracts and content locked and loaded and the system operational. Formal, normalized classification costs you again and again, too. The big payoff, supposedly, is reporting. But I imagine better ways to get great, accurate reporting than a fat tax as data enters the system.

You see, most systems assume UNSPSC or some other classficiation scheme. And this makes sense. But when catalog content comes in, suppliers may not have made the same assumptions. Mapping is evil, it's costly, and too often it's required. And even if you're smart and avoiding local content, you still get the mapping problem on bringing the shopping cart back from a punch-out.

Problem is you can't truly fix the problem without fixing the source of the problem – which seems to me is Purchasing. Reason being the Requisition eventually does need to become a PO, and PO lines require the category (you know, for things like accounting). Which leads to waiting on Oracle or SAP. Which seems to be a colossal waste of time.

I had my chance to fix it. Just didn't get it done.

As you can guess, I wish we would have punted on rationalizing categorization on the front-end and figured out how to drive reporting, accounting, and a whole host of other capabilities from a more flexible map. I think that would have worked a whole lot better.

Procurement systems (and ERP in general) needs to be more flexible and adaptable. This is a classic example where the customer's cost of doing the right thing nearly outweighs its value. Customers shouldn't have to make choices like those with their Procurement implementations.


Written by Dave Stephens

03/29/06 8:05 PM at 8:05 pm

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: