Monthly Archives: July 2010

Analysts, Schmanalysts

According to Gartner’s latest blog post (in Thursday’s thoughts), the super secret formula to gaining information about a vendor’s product is the “scripted demo”.

Here’s the Big Idea: you ask the vendor how to accomplish the “applicable tasks you do most often”, and then you ask the vendor to demonstrate, step by step, how to do them.

Well, that’s a terrific idea if the vendor has nothing new or innovative to show you, and if both of you are as dull as dishwater. If all you want the vendor to do is show you how to accomplish some mundane  business task that you already do every day, then you’ll never see anything the least bit interesting or innovative. Plus, given time, the vendor will “polish” that part of the demo so it looks much more impressive than it really is.

Here’s some free advice to business and technology analysts who have to evaluate products:

  1. DON’T ask the vendor to do ordinary things.Ask the vendor to show you extraordinary things. Sometimes those extraordinary things can be quite ordinary on the surface, like making it possible for ordinary users to employ highly complex technology successfully and usefully. Problem is, you actually have to understand what’s going on under the covers to figure out whether it’s extraordinary, or just something that’s actually quite simple, or even something that’s just plain technically impossible, and therefore a load of bull (see point 3, below). If all you have is an MBA, chances are that you can’t make that evaluation.
  2. DON’T count mouse clicks.Count innovations that could really make a difference for your clients and their businesses.
  3. DON’T assume that you know anything about technology.Instead, hire (or rent) someone who does, to save you from drawing uninformed conclusions about stuff you don’t (and might never) understand. If you bring someone to the party who can’t be buffaloed by technobabble and a pretty UI, then you don’t have to worry about “scripted” or “unscripted” demos.
  4. DON’T test for “100 features and often many more — up to 500 features” to finalize a rating.That’s just “checklist testing”, and it’s not very useful. Fact is, only a few features matter; the rest are bells and whistles that nobody cares about. You need to do a deep dive on what’s important, not worry about who has the longest checklist. It’s exactly this “please the reviewer” attitude that contributed to bloatware like Microsoft Word — a product that, after years of introducing new whiz-bang features that only ever half-worked, still couldn’t get basic bulleted lists to function properly as late as Word 2003.

The other Big Idea in the Gartner article is References. Well, references are a slippery slope. Does the reference customer understand the technology? Probably not. Does he understand what else is out there? Almost certainly not. Does he think his (pick one: RFx engine, spend analysis tool, contracts management system, etc.) is the greatest thing since sliced bread? Maybe, but who cares? He could be using a crappy tool of marginal value in comparison to what he could be using and have no clue. You could interview him until the cows come home, and not learn a thing, except that he’s a happy lemming with no idea he’s about to run off a cliff.

Fact is, the old model of analysts running around interviewing and briefing the vendors that pay them, and then running off to interview the customers that the paying vendor has teed up, and therefore thinking that they’re somehow “getting a feel for what’s out there and what’s good”, is so … over. All you end up creating for your final report is an unappetizing mashup of the marketing nonsense of all the big vendors.

No wonder everyone is running to the web for guidance. Or running for the hills.

Share This on Linked In

Good Supplier Performance Management Starts With Performance Analysis

As per a recent article over on ChainLink Research, a diversified international manufacturer discovered that real improvements happened once it made performance information available quickly and easily to both buyers and suppliers, and then based buying decisions on that data. This was accomplished through a centralized tool that supported real data analysis. Every week the tool pulls all of the relevant data from the manufacturer’s various systems (ERP, MRP, factory management, etc.) into a single repository where it is mapped against a common data structure that can be sliced and diced as required by a commodity manager that needs to see productivity, quality, delivery performance, and spend data for the supplier by site, part number, or business unit, etc. This allows the commodity managers to see if they have been rewarding suppliers who were easy to work with but performed below par, or not rewarding suppliers who were perceived as not being easy to work with, but performing above par. As a result, behaviour changed quickly.

And once you have all of the relevant data available in an analysis tool, you can find unconventional uses that can benefit the organization. One example given in the article is when the CEO of the diversified manufacturer was negotiating with a senator. The tool allowed the CEO to quickly find out how much business was being done in the senator’s state and put together an argument regarding the firm’s contribution to the economy and local business. This is powerful information when lobbying for loans, tax breaks, or other economic incentives, which are often necessary when trying to expand the business in a rough economy.

A Hitchhiker’s Guide to e-Procurement: Requisitions, Part I

Mostly Harmless, Part II

Previous Post

A requisition is a request for a product or service in a written form. With respect to e-Procurement, it is generally an electronic request for a product or service in a standard form, which may or may not use standard product or service codes from either the organization’s ERP/MRP systems or the supplier’s (e-)catalog.

While the concept is simple, the reality can be quite complex, especially if the requisition is for a large BOM (Bill of Materials) that requires multiple products and services from multiple suppliers, as different types of identifying information and specifications can be required for each line item.

The requisition needs to be able to capture a significant amount of information. In addition to the following core information:

  • requisitioner
  • department, division, and/or organization
  • request date
  • requested delivery date
  • delivery location
  • line items, each of which requires:
    • organizational product/service code
    • supplier product/service code
    • quantity
    • price (from the contract, schedule, or catalog)
  • etc.

The requisition may also need to capture:

  • supervisor
  • budget manager(s)
  • AP contact
  • delivery contact
  • product description(s)
  • itemized Statements of Work (for services)
  • etc.

As a result, the requisition needs to be very flexible and capable of being augmented by the buying organization as needed. Furthermore, it needs to be able to extract information from the organization’s ERP/MRP system, vendor master, contract system, and catalog(s), punch-out(s), and/or marketplace(s). As a result, it must either support easy integration with these systems, or (one or more) standard XML input and output streams (and cache commonly used codes if the updates aren’t near real-time).

In addition, it has to be integrated into the workflow management system that handles approvals, m-way matching (against goods receipts, invoices, etc.) during reconciliation, and the data store(s) used by the analysis and BI tools.

When evaluating the requisition capability of an e-Procurement system, one should keep in mind the associated challenges of the requisitioning process, keep an eye out for best practice support, and insure that the solution will deliver the intended benefits, which is the subject of the next post.

Next Post: Requisitions, Part II

Share This on Linked In

United Breaks Guitars (The Trilogy): 10 Million Views, All Thanks To You!

Last week, and three weeks ago, I reminded you that the one year anniversary of the first video release was this week (on Tuesday, July 6), that Dave was closing fast on 10,000,000 views, and that with your support we could get him there and send airlines everywhere a strong message.

I’m happy to report that, thanks to the international date line, Dave made it. (When the editor checked Tuesday night in his time zone, Dave was just views away, crossing it the next morning in the editor’s time zone, when it was still Tuesday in Samoa). Moreover, the counters are still climbing, which is very important as it seems that, as a whole, the airlines really haven’t gotten the message. (Delta is smashing bicycles of volunteers who TriAndGiveADam and who are working hard to make sure children in Africa have clean drinking water, and refusing to even refund the $200 “we’ll keep your luggage safe” fee.)

 

As of today, we’re at:

United Breaks Guitars Views (June 29, 2010)
Song 1  8,791,174
Song 2  1,044,613
Song 3  180,778
TOTAL  10,016,565

 

I encourage you to revisit these videos and share the links regularly. They’re good songs, even if they’re not your musical style, they’re a rallying point for the bad customer service we continuously get from the airlines (as echoed by Brian Sommer in his post on Eat that Cookie!), and I’m sure not enough people have enjoyed song 3, which is every bit as good as song 1 both in lyrics and video production quality (it’s funny!).

If You Really Want Communities to Work, Encourage Them!

The Harvard Business Review recently ran a well written and well argued article on how to “harness your staff’s informal networks” (subscription or purchase required) that was thought provoking, but a little too involved for my liking. While the methodology may be appropriate for many organizations, it violates the KISS principle. You don’t need an eight (plus) pronged methodology to make communities work. It can be as simple as one-two-three.

  1. Provide a home for the community.If you’re a multinational, make sure the participants have the online tools and technologies they need to meet and collaborate. If you’re a small company in a single building, make sure there are rooms available on a regular basis. There’s no one-size-fits-all home, so it’s important that you buy the right one for the community you want to create.
  2. Enable participation.Don’t just encourage participation, enable participation. Make sure your people have the time to contribute. Take a lesson from Google, and make sure your employees have 10% to 20% of their time free to focus on community projects and initiatives. That’s how you create communities that innovate and generate real results.
  3. Recognize and reward contribution.Recognize those who maximize their community contributions and those who go beyond the required commitment levels, regardless of whether their contributions get used or not. The true value of a community materializes over time as it’s collective knowledge, and knowledge base, enables and inspires others to greater heights. Even an almost-there solution has value, especially if it contains a distinct idea or process that can be applied to a similar problem that arises down the road.

That’s all there is to it. Really.

Share This on Linked In