Category Archives: RFX

Intengo – Doing the e-Sourcing Tango in Turkey

Intengo is a relatively new provider of e-Sourcing/e-Negotiation solutions that first appeared on the scene in it’s Native Turkey in 2006, after being founded in 2005. Like b-pack in France, it’s just starting to expand internationally, focussing on Europe first with translations to Spanish, French, and German (in addition to its native Turkish and new English language support) currently in the works.

Intengo provides an on-demand e-Negotiation platform built around (multi-round) e-RFX and e-Auction with a sprinkling of supplier information management (SIM) and catalog management thrown in. Their tool allows you to mix and match RFX and Auctions in successive rounds as you see fit. You can start with a baseline RFP, invite qualifying suppliers to an (English, Dutch, or Japanese) auction (with more variants in the pipeline), then return to a sealed bid RFP with the winners in a final negotiation around*1. It’s quite flexible and allows the organization to tailor the e-Negotiation event to their way of conducting negotiations.

It is extremely quick and easy to set up a new event, or “project”, in the system as the process is wizard-driven. It’s literally as easy as:

  1. define the basic informationevent name, details, manager, dates, and type
  2. define what the bidders can and cannot seecompetitors names, prices, ranks, etc.
  3. define the basic information and the ruleswhich can be from a template or custom defined
  4. define the itemswhich can be selected from the hierarchical catalog or defined on the spot
  5. select the supplierswhich can be selected from the supplier master or defined newly for the event
  6. define boundary parameters and extension rules (for auctions) min and max bid increments, reserve prices, etc.

One of the jewels of this solution is that the auction dashboard is jam-packed with information but yet designed in such a way that it doesn’t look the least bid cluttered. The buyer (and the bidders, with appropriate permissions) can see full event configuration details (starting, ending, extensions & rules, whether or not names and prices are hidden, etc.), current supplier rankings and percentage changes for each bid (in each lot), all bids for each item (with the lowest bid highlighted in green, and the changes from the last bid highlighted in yellow), the countdown clock, and a progress / trend graph. The bidder can also easily access the configuration screen through the management tab to extend the auction and the entire bid history through the bid list tab.

Other hidden jewels are the calendar view, which integrates with outlook and hot-links to all of the relevant screens in the relevant projects, item level multi-currency support, where the buyer can choose to define the currency or leave it open for the bidder to choose and where the buyer can choose to accept the default rates from the central bank or override with manual rates, smart unit support, fine grained access control for corporations or governments that need to limit who can see what, and the ability to easily do bulk updates on (filtered) lots so that a bid decrement (fixed or decrement) can be applied to all bids in the lot. (In comparison, many of the “commodity” auction tools don’t have fine-grained multi-currency control, automatic unit conversions, or such granular access control.)

And while the SIM and Catalog Management is basic, the user can define custom hierarchies and include supplier ratings, which is more than sufficient for many mid-market companies that still haven’t even touched modern e-Sourcing platforms. The major weakness, which is common to many of these platforms, is the lack of a custom report builder. There are built-in reports, and Intengo can build custom reports for any company that wants them, but no ability for a customer to build her own report. However, they do have Excel integration and a buyer can dump all of the information to Excel and construct her own reports which is a decent workaround if the user knows how to build a good template (where it’s just a matter of importing the exported data as needed).

They also have integrated messaging (and the ability to send e-mails), reasonable attachment management capabilities, and a moderately powerful administration section where a user can update the company profile, update their personal profile, define display settings, manage users, add and update templates for RFXs/Auctions/Projects, define additional units, input custom exchange rates, and modify the configuration profiles. All in all, it’s a solid tool for the mid-market, and one that they can offer at an affordable price-point as they are a SaaS solution. If you’re a mid-market company in Europe who is looking for a solid e-Negotiation platform to get started on the e-Sourcing path, you should definitely consider inviting Intengo to the table.

*1 If you take this approach, be sure to remember your auction ethics where you tell your suppliers up front that the winner of the auction doesn’t necessarily get the award as the auction will be followed by a final negotiation round with the top X suppliers. In addition, this strategy should only be employed in categories where you intend to split the award between two or more suppliers from the get go for risk mitigation.

Share This on Linked In

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

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

Mostly Harmless, Part VI

Previous Post

Formally, a purchase order is a commercial document issued by a buyer to a seller that indicates the type, quantity, and agreed upon prices for one or more products or services that the buyer is offering to buy from the seller. Once the seller accepts the purchase order, it forms a (one-off) contract between the buyer and seller, who will deliver goods and services at the agreed upon prices, in the agreed upon timeframes, to the buyer who must then, upon receipt of the agreed upon goods, in the agreed upon condition, make payment to the seller for the agreed upon amount.

A purchase order is the result of an approved requisition, but the relationship is not necessarily one to one. One requisition can generate multiple purchase orders, and this will commonly happen when a purchase order contains requisitions for goods and services from multiple suppliers. And while normally there will be one purchase order per supplier, if the goods and/or services are coming from multiple locations, there might be multiple purchase orders per supplier. In addition, a purchase order might be associated with more than one requisition, as requisitions from multiple buyers for similar goods to a similar location may be bundled into a single Purchase Order to save delivery and processing costs. As a result, the e-Procurement system must be capable of handling the many-to-many relationship between requisitions and purchase orders (and suppliers).

In addition to all of the information tracked on the requisition, the purchase order must also track approval information, delivery information, payment terms, and any other specific information required by the supplier. It must support attachments and include any attachments, schedules, or statements of work that are specified as necessary in any contracts that are in effect.

Furthermore, since the delivery of goods and services will generally result in the production of goods receipts and invoices, the e-Procurement system must support the association of purchase orders with the corresponding goods receipts and invoices, which, like the purchase order and requisition relationship, can be many to many. If the order is large, or if some items are not immediately available, a supplier may ship the order in multiple shipments, which would result in multiple goods receipts and which may be accompanied by multiple invoices.

In addition to tracking all of the relevant information, the system must be capable of translating the purchase orders in the standard EDI and XML formats that are used by the primary suppliers and electronically delivering them to those suppliers who have networks, marketplaces, or another on-line presence capable of automatically receiving an electronic purchase order.

When evaluating the purchase order capability of an e-Procurement system, which should support tight integration with the invoicing module, one should keep in mind the associated challenges of purchase order management, keep an eye out for best practice support, and insure that the solution will deliver the intended benefits. These topics will be addressed in the next post.

Next Post: Purchase Orders, Part I

Share This on Linked In

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

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