Monthly Archives: July 2010

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

Mostly Harmless, Part III

Previous Post

An introduction to requisitioning.

In the last post, the requisition was defined as well as the information requirements that were associated with the requisition. This post will address some of the associated challenges of the requisitioning process, some associated best practices, and the benefits that could be expected from an appropriate e-Procurement solution.

Common Challenges

  • Creation Time

    It can take a considerable amount of time to create a multiple line item requisition when a user has to manually look up vendor codes, ERP/MRP codes, product codes, prices, etc.

  • Statement(s) of Work

    If the requisition is for temporary / contract labor, it can be a time-consuming and challenging process to construct the right SOW that will enable the vendor to identify the right resource.

  • Routing

    If the correct department / budget / product codes aren’t used, it can be difficult to route the requisition to the appropriate approvers.

Best Practices

  • Integration with core data systems

    ERP, Vendor Master, Catalogs, Punch-Outs, Marketplaces, and Networks.

  • Templates

    For standard BOMs, SOWs, and other regular purchases that can be quickly completed simply by filling in quantities, hours, and the few bits of information that vary from order to order.

  • Budget-Based Approval Process

    Requisitions are automatically routed to the appropriate budget manager if the request is beyond or outside of the budget.

Potential Benefits

  • Reduced Man-Hours

    Which frees up buyers to focus on more strategic cost-reduction tasks.

  • Faster Processing

    The right information not only gets the requisition to the right approver faster, but provides the approver with all of the information she needs to make a decision the first time.

  • Better Specifications and Statements of Work

    The use of templates written by experts will standardize and improve the requisitioning process.

Once the requisition is finalized, it begins the approval process, which is the subject of the next post.

Next Post: Approvals, Part I

Share This on Linked In

Done Innovating? No Problem. You can still succeed!

And you don’t have to go waiving NDAs around either. You can stop pretending that you’re still innovating when we all know discovery ended long ago. Thanks to the breadth of today’s marketplace, you have options beyond selling out to a bottom feeder who’ll amalgamate your technology with five other dying products, cross-sell existing product lines, and then milk the maintenance dry.

You can instead choose a strategic “bold retreat”. So if you lack the finances, necessary capabilities, or simply the drive to transition to new technologies and invent new solutions, you can choose to retreat to a defensible niche where your old technology conveys a decisive advantage. Just like Linjett continues to succeed in the leisure sailboat market by focussing on the enthusiast, like Continental continues to succeed with piston engines by focussing on small private aircraft, and like StorageTek continues to sell magnetic tape drives (yes, magnetic tape drives) by focussing on large scale data archives, you can succeed too!

Haven’t upgraded your e-Negotiation platform in five years? No problem! Just ditch the Fortune 500 market and focus on the mid-market where most companies still haven’t adopted a solution. It’ll be new to them for five more years!

Haven’t upgraded your BI tool in five years? No problem! Streamline your integration with the big ERP tools that your average Fortune 500 can’t get rid off. Become the BI tool of choice in that market and continue to rake in recurring maintenance fees at 22% year after year.

Haven’t upgraded your catalog-based e-Marketplace in five years? No problem! Follow the crowd and rebrand it as a “supplier network”. Now it’s new for five more years!

In other words, you can fail at modern technology but still win if you’re bold about it! (Of course, whether or not your customers win is a completely different story.)

Share This on Linked In

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