Daily Archives: July 23, 2010

SI’s Policy: No Time Limit and No Fixed Schedule on Briefs

One week ago today, Spend Matters (“SM”) announced that it was limiting briefings to

a one-hour-and-twenty-minute interval on Thursdays and a

two-hour-and-30-minute interval on Fridays. SM stated that

briefings would be limited to 40 minutes, including 10-15 minutes of introduction/background,

the remaining time to be spent on “the presentation or announcement”.  SM further stated that it requires

reference contacts for a follow-up call, and that it is limiting follow-up demos to 30 minutes.

While it is not Sourcing Innovation’s place to comment on the policies of other blogs in the space,

the doctor would like to take this opportunity to make SI’s policies, most of which are very different from the above (and laid out in the FAQ), very clear.

  1. SI will schedule briefs at times of mutual convenience. If this means after hours, that can be arranged.
  2. Although initial demos are usually limited to 60 or 90 minutes, SI does not impose time limits of any kind on briefs. If a brief needs to be continued,

    then it will be, for as long as it takes. SI is interested in your solution. Very interested.

  3. SI is not interested in “announcements” or “presentations.” Rather, SI wants to see your

    solution in action. Plan on a deep dive into your solution, followed

    by an intelligently-written post, assuming that the doctor believes that your solution solves a

    real problem in our space. Note that the doctor is very respectful of any software solution that

    solves a real problem, because he knows what it takes to bring such solutions to market, having

    done it himself on multiple occasions.

  4. SI is generally not interested in making reference calls*, because the doctor doesn’t care about your Marketing department’s ability to find customers who think your solution is the greatest thing since sliced bread. He is interested in your solution, not third-party opinions about your solution. This is not People Magazine or Gartner, so the opinion of a random “celebrity” customer, regardless of how prestigious his or her corporate logo may be, is irrelevant here. Lemmings are plentiful, and they come in all sizes.

Finally, SI sees no issue in trying to “keep up with” vendor products and announcements. Although many vendors make routine “exciting” announcements about new functionality and so forth, in practice these announcements are usually just marketing noise, having little to do with important functionality changes and enhancements. SI is confident of its ability to cover real enhancements and real innovations when they really occur, and can see no immediate danger of running out of cycles to do so.

For vendors who require a Non-Disclosure Agreement (NDA) before providing a demo, SI is not interested in reviewing your solutions. the doctor’s assumption is that organizations requiring an NDA before doing a deep dive for a reviewer are irrationally hiding functionality that is released and in the public domain anyway, so their motives for trying to conceal that functionality are suspect.

Thank you for your attention.

* The exception being when you make a strong claim about savings, ROI, etc. 

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

Mostly Harmless, Part VII

Previous Post

In the last post, the purchase order was defined as well as some of the requirements for its generation. This post will address the challenges associated with purchase order generation, some associated best practices, and the benefits that could be expected from an appropriate e-Procurement solution.

Common Challenges

  • Requisition Partitioning

    A requisition contains requests for multiple goods or services, which are covered by multiple contracts at multiple rates depending on SKU, volume, or other terms. Which contract? Which rate? Which terms?

  • Forward Matching

    How will the purchase order be matched to incoming goods receipts and invoices?

  • Duplicate Detection

    How does one detect if multiple purchase orders contain a requisition for the same good or service? How does one detect if duplicate purchase orders were accidentally cut?

Best Practices

  • Automatic Generation

    The system should automatically generate the necessary purchase orders from approved requisitions.

  • Automatic Price Confirmation

    The system should automatically verify that contract or catalog prices are being adhered to.

  • Automatic Distribution

    An approved purchase order that sits on someone’s desk waiting to be sent can hold up the business or a production line if the parts or services are not delivered on time because the supplier(s) did not get the purchase order on time. Once a requisition is approved, the purchase order should be sent automatically

Potential Benefits

  • Reduced Lag Time

    An e-Procurement system can automatically create and distribute purchase orders as soon as the requisitions are approved.

  • Reduced Overspending

    The system can automatically grab and populate the purchase orders with contract pricing. Some categories, like office supplies or electronics, see a lot of overspending because buyers requisition at catalog, but not contracted, rates or don’t buy in the appropriate quantities (which can be flagged and corrected during the approval process).

  • Reduced Errors

    The system can automatically pull up the right codes, the right templates, and the right prices so that the supplier isn’t sending it back with a request for further explanation, which would only delay the process further.

Once the purchase orders are distributed, the next step is to wait for delivery and issue the goods receipt, which is the subject of the next post.

Next Post: Goods Receipts, Part I

Share This on Linked In