Category Archives: Technology

Why ERP Is Not Enough for Project Based Manufacturing

A recent article over on Industry Week on “5 Critical Issues for ERP in Project-based Manufacturing” outlined why ERP systems alone are not enough for project based manufacturing (and manufacturing in general).

The issues outlined in the article were:

  1. Bidding and Quoting
  2. Project Visibility
  3. Managing Change
  4. Financial Performance Tracking
  5. Rapid Time to Value

A carefully evaluation of many of the ERP tools on the market will reveal that:

  1. They don’t truly support modern e-Negotiation, and the company will also need a modern e-Sourcing tool (which may have to be integrated).
  2. As far as these systems are concerned, user-defined push alerts, flexible automatic notifications, and real-time reporting is still a pipe dream. A real time data analysis tool will be required.
  3. Flexibility is limited. At a a minimum, good processes will be required. A change management add-on may be required as well.
  4. Lots of data is tracked and stored, but financial analysis capabilities are limited. A real time data analysis tool will be required here as well.
  5. Implementation is rarely quick, and payback typically longer than expected. That’s why supplementary Sourcing and Procurement systems are generally required.

In other words, a good ERP system can provide a great foundation, but it will rarely meet all of an organization’s need.

Share This on Linked In

Has Coupa Settled on a Coupe? Part III

In our first post, we discussed how, when Davie ran The Coupa Factory, their strategy was innovation focussed and they were constantly charging ahead in their efforts to bring Procurement Independence to the masses but that, lately, it seems that their strategy has shifted to putting customer acquisition first and building a better platform second. In our last post, we reviewed what they have accomplished over the past eighteen months, which isn’t too shabby to say the least (especially compared to some of their peers which do not appear to have innovated at all), but noted that there’s nothing to really shake your foundations … which is a shame considering that had Coupa taken benchmarking and supplier ratings to the next level, they could have knocked your Procurement socks off. This is the subject of this post.

In order for benchmarks to be useful, they have to be meaningful. In order for a comparison to be meaningful, it has to be against like items. And while you can compare apples to oranges, unless you’re comparing the spectra of dried samples in powdered form, it doesn’t make sense. The reality is that savings, request, order, and invoice metrics only make sense if the comparison is against a similar company of a similar size in a similar vertical buying similar products. Consider free-form requests … depending on company size that’s going to range from hundreds per year to tens of thousands per year. Frequency of self-approval … that’s not only going to depend on corporate policies but the types of goods being purchased. If the system is mainly used to purchase office supplies, who’s going to waste time approving every small order? But if the system is being used to buy high priced electronics, different story. PO value will not only vary widely between companies, but within a company. A purchase order for a weekly office supplies order in a small company will be a fraction of a purchase order for a new set of servers. Active suppliers will vary widely depending upon the size of the company and how many different types of products are being bought. Had Coupa defined appropriate verticals, segmented the verticals into appropriate sizes, and insured that the metrics were meaningful (even if that meant waiting until there were more customers in some verticals), this could have been extremely useful. However, right now, it’s interesting at best, and could be dangerous if misunderstood.

In order for supplier rankings to be useful, they have to be against meaningful metrics, and those rankings need to be defined by a majority of affected users. If they are random rankings defined by random users against random products, they are not very useful, especially if they are done by users who have only used the supplier’s products once and not users who have to work with the supplier and its products every day. In order to truly rank a supplier, a company needs to insure that all of the relevant users who use the supplier’s products or services regularly or who interact with the supplier as part of their role rank the supplier. This means that the buyer needs to send out mandatory surveys to these users. While a buyer can easily send out a survey through your standard SIM or e-Negotiation tool, what a buyer normally can’t do through these tools is figure out which organizational users are in the best position to rate the supplier. However, as Coupa enables all spend related to a supplier to be captured in the system, it’s a pretty easy query to figure out which buyers are the biggest user’s of a supplier’s products and which buyers should be ranking the suppliers. If Coupa had enabled the construction of supplier performance surveys which could be sent to the regular users of the supplier’s products in a single click, and then made it impossible for a buyer to requisition anything until the mandatory survey was completed, think of how useful it could be. However, right now, like benchmarking, it’s interesting, but not very useful.

Hopefully these oversights are just the result of Coupa going through the growing pains associated with a brand new management team and rapid customer acquisition. When you consider that The Coupa Sunflower was only starting to blossom, it would be nice to see Coupa return to the days when its releases were much more than coupacetic. After all, why should they settle for a coupe when they can build a dragster? It only takes a little bit of innovation in the right direction to bring back the excitement to Coupa Time.

Share This on Linked In

Has Coupa Settled on a Coupe? Part II

In our last post we discussed how, when Davie ran The Coupa Factory, their strategy was innovation focussed and they were constantly charging ahead in their efforts to bring Procurement Independence to the masses. However, lately, it seems that Coupa‘s strategy has shifted from “build a better platform and they will come” to “get the customer and then build them a better platform”. While not much of a change, it’s a change nonetheless and it appears to have affected their rate of innovation. Furthermore, it has been accompanied by a shift from groundbreaking new features to even flashier UIs, iPhone apps, and streamlined ERP integration. [Either that, or they’ve been celebrating all those new customer wins with The Coupa Drinking Song. ] While these features are important to the tactical buyer, they don’t add value to the strategic parts of the procurement process.

This isn’t to say that Coupa has stopped developing, or that some of their new features aren’t impressive, especially where the average buyer is concerned, but that their rate of innovation for the last year and a half just doesn’t compare to the Coupa of old. And while it is to be expected that the rate of innovation will drop as a company matures, if the rate drops too fast, the company risks going stagnant, and that would be troubling. However, what is really troublesome is that Coupa hit upon two areas in real need of innovation in their latest release, but appear to have completely missed the point on how to bring that desperately needed innovation to the masses (unless it’s still a work in progress, but why not go for the big win before anyone else beats you to the finish line?). However, that’s the subject of our next post.

For now, let’s review what they have accomplished in their latest release, as a few of the features are quite useful and still unique to the space.

Drag-and-Drop Expense Management

One of the developments Coupa seems quite proud of is the ability to snap a photo of a receipt with your iPhone, e-mail it to your Coupa account, log in to the system, bring up expense reporting, and then drag it to an expense category in an expense report. The receipt is immediately associated with the report and removed from your unprocessed receipt bucket.

Transaction Metadata for OLAP reporting

Coupa has added transaction metadata to each transaction that provides supervisors and CPOs the ability to roll up reports by chart of accounts, reporting hierarchy, and category. They’ve also added more fine grained security to insure that a user can only see spend within her visibility. (Note that they were calling this “data striping“, which, of course has nothing to do with OLAP reporting but data storage on physical mediums as it is the technique, used in RAID, of segmenting logically sequential data across different devices. So if you were confused, this is what they meant.)

Real-time Budget-Based Alerts

Not only does the application allow a user to keep on top of her budget, by way of it’s budget dashboard on the home screen (which is actually useful as most buyers don’t have a clue how much they are spending), but if a requisition puts a user over a certain percentage of her budget too early in the year, the application will alert the user, and the approver before it is approved. It will also let the approver know if the requisition would put the category or department budget over a dangerous (administrator configurable) threshold too early in the year.

iRequest

iRequest is a bookmarklet (bookmark app) that allows the user to add a bookmark to their browser that will bring up a pop-up window that will let them request whatever item is on the page of the external site she is browsing. Not only does it make requesting an item on Amazon.com a breeze, but it eliminates the excuse for out-of-system requisitioning as every item can now be easily requested through the system.

Opt-in Benchmarking

With opt-in benchmarking, a customer can opt-in to sharing benchmarking data anonymously and see how it is performing on a standardized set of benchmarks relative to all of the other customers on the Coupa system. It’s interesting, and could be a powerful tool, but right now, it’s not very useful. More on this in our next post.

Supplier Ratings

With this feature, they’ve essentially added the ratings feature of Amazon.com which allows a buyer to rate the supplier with respect to each purchase, but since the ratings are optional, and since they’re not made against meaningful performance categories, the usefulness of this feature is rather limited.

All-in-all, some useful functionality that I’m sure will go far in convincing the average office manager to accept Coupa with open arms and joy in her heart, but not what Coupa could have delivered to totally knock your Procurement socks off. More on this in our next post.

To be concluded.

Share This on Linked In

Has Coupa Settled on a Coupe? Part I

Has Coupa, which opened the Cabana Cafe a little over four years ago with the goal of enabling Procurement Independence for all with it’s Rails-driven cloud-based EC2 platform, given up its quest for a coupasonic flying car and instead settled for a mini-cooper?

Now, while the original goal of Coupa, that wanted to fill your e-Procurement gas tank, was to bring e-Procurement to the masses, it would seem that they are now content with the fact that you can buy anything you want in The Coupa Store as it would appear that they are no longer charging ahead on the innovation front. While it’s true that they’ve been quite busy ever since they enabled QuickDraw Procurement with QuickStart, what they’ve accomplished since then isn’t all that spectacular compared to their historical rate of innovation … and they’ve missed most of the opportunities for innovation that could take their platform to the next level with their latest release. And while it’s true that you don’t need a very powerful solution if you’re selling fertilizer to farmers (and can get by with a simple cart and a good old-fashioned hoe-down), you’re never going to get the design engineers. (i.e. You’ll get the tactical buyers requisitioning office supplies, but never the strategic buyers trying to order a bill of materials for engineering.)

Basically, besides revamping the UI for the upteenth time (which seems to be a waste of resources to me as it was already [among] the easiest enterprise procurement solution out there and as easy to use as Amazon.com), all Coupa appears to have accomplished in the last eighteen months is:

  • improved ERP integration through upgraded APIs and Boomi,
  • drag-and-drop expense management,
  • transaction metadata for OLAP reporting,
  • a new inline spend dashboard,
  • real-time budget-based alerts during requisitioning,
  • the iPhone app,
  • iRequest,
  • opt-in community benchmarking, and
  • supplier ratings.

Considering that:

  • they’ve had APIs since day one, Boomi handles most of the integration, and ERP integration is always just a matter of time and resources,
  • it’s about data capture (not slick UIs),
  • they’ve had the ability to capture this data since day one,
  • dashboards are dangerous and dysfunctional,
  • they’ve always had alerts and the usefulness of this should have been obvious years ago,
  • if you have an iPhone, you have e-mail, and that’s good enough for approvals,
  • the goal is not to buy outside the system,
  • benchmarks are pointless unless you’re benchmarking against peer data, and
  • optional surveys are about as useful as snowshoes in summer

while it is still forward progress (which is more than a few of their peers can claim these days), it really isn’t much considering their historical rate of innovation. (Of course, that’s when Davie ran The Coupa Factory.) While their new strategy may have enabled their rate of growth to skyrocket, going from a few dozen customers to over one hundred and fifty in under two years, it appears to have put a crimp in their rate of innovation — especially considering the unprecedented power Coupa could have brought to their platform if they had taken the last two features to the next level.

To be continued.

Share This on Linked In

Demos Don’t Teach You Much … Unless … (Part I)

Sheesh is Right! The average analyst doesn’t have a clue how to properly evaluate a technology offering. But what should you expect considering most of these individuals come from a liberal arts background and think “C” is for Cookie? And if you don’t believe me, maybe you should read those tragic quadrants, graves, and benchmarking futiles more carefully … because the reality is that an evaluation scheme based on chicken-with-its-head-cut-off bingo would likely be just as accurate as the rankings in the average analyst report these days.

But back to the point. Recently, over on Spend Matters, Jason Busch decided to tackle the issue of product demonstrations (Part I and Part II). In his first post he said that you should be prescriptive where the demo is concerned and that, except in a few rare cases, you should focus on ease-of-use. I disagree.

In the words of commenter “Sheesh” [italics in the rest of this post], Jason’s points are true if the analyst knows what to ask. If all you do is focus on “usability”, you’ll end up choosing the solution with the most flash. Problem is, there’s always a trade-off between flash and substance. A software company only has so many development hours before it runs out of cash and has to sell something. This means that the more hours it spends on creating a razzle-dazzle UI, the fewer hours it has to spend on actually building useful functionality. Remember, we’re talking about enterprise software, not end user entertainment.

Jason’s followed with a second post where he proposes a series of demonstrations based on specifically prescribed scenarios.

The problem is that, as Sheesh says, you’re not a tech expert and you shouldn’t [even] attend the demo unless you bring one with you. The “business scenario” approach assumes that the ability to address “business scenarios” is a useful measure of anything. Typically “business scenarios” are crafted from melted-down aggregations of vendor marketing messages and feature lists, combined with some business problem that the vendor has already got a pat answer for unless he’s a complete idiot. If he’s on the ball at all, you won’t discover anything interesting; or if you do, it will be something on the order of Debbie Wilson’s mouse clicks. ‘OMG this vendor takes seven mouse clicks and that one takes twelve!!!!!’ Not at all useful!

Sheesh continues, You have to go deeper than chin-stroking about a suite of standard reports and baked in transaction processing flows for “business scenarios.” What’s behind the curtain? What if you want to write your own report, or modify one of theirs? What if you want to change the way the transaction processing works, fundamentally? If you find a solution that’s extensible in those dimensions, then it’s tons better than any canned solution, by definition. Because you can make it do whatever you want it to do.

Furthermore, the software procurement process shouldn’t try to find a “best fit” in a shoe store that doesn’t carry your size. Rather, the software procurement process should focus on finding a solution that can be easily extended and adapted to your needs, on as many dimensions as possible. If the solution can be extended and adapted, it really doesn’t matter what it does out-of-the-box, in terms of canned reports, canned transaction flows, canned sourcing and optimization templates, or canned demos — or what its relative performance might be on business scenarios that encompass what you think you need today, but tomorrow might fail miserably at characterizing your needs. If the solution is extensible, then it can solve a universe of problems rather than a small subset of them.

As the commenter stated, there are lots of such questions that need to be asked, but they need to be asked with the aid of a technical resource.And there’s really no excuse not to have an expert technical resource on hand. Expert advice is cheap, especially compared to what you’d pay to some analyst firm, or waste on some solution that compares well on an analyst checklist, but is actually hopelessly inflexible. In the long run, it’s probably a few tenths of a percentage point of what you’ll spend on the “enterprise” solution (which won’t be a solution at all if it sits there, on the “shelf”, unused).

Share This on Linked In