I’ve recently been studying what a customer-obsessed operating model means for Purchasing functions and the software they use. I've concluded that Purchasing needs to transform its approach to visibility and control, due to the tradical impact that Mobility has on procure-to-pay (P2P) processes. I've been warning ePurchasing software companies for years about the potential impact of Mobility, but while a few visionaries have heard and acted on the message, most are lagging behind. That may be OK while their customers – mostly Finance and Procurement professionals – are similarly behind the times, but they may be unable to catch up when the market finally starts to demand fully mobile solutions. And customer-obsessed organizations will demand mobile P2P solutions, because they need to enable employees to quickly and easily buy the goods and services they need, so that those employees can get on with their main job, which is winning and serving customers.
What the laggard vendors miss is that Mobility is not about a user interface that works on iOS and Android; its about making the software so smart that it works well in a mobile context. Many product managers tell me proudly “our software works the same on a mobile as it does on a PC”, but that completely misses the point; mobile apps needs to work completely differently from the way traditional PC-based software works.
Take requisition and invoice approval as an example. One leading P2P vendor claims that over 70% of approvals are either performed in its mobile app or via its email response feature. I would argue that few of these approvals are worth the paper on which they are rubber-stamped. A manager can check many aspects of a transaction on a PC because they can see a lot of information on their screen and can drill down to investigate potential problems. They can’t do that on a phone, because:
I have been working on a research document, to be published this quarter, on the impact of 8-socket x86 servers based on Intel’s new Xeon 7500 CPU. In a nutshell, these systems have the performance of the best-of-breed RISC/UNIX systems of three years ago, at a substantially better price, and their overall performance improvement trajectory has been steeper than competing technologies for the past decade.
This is probably not shocking news and is not the subject of this current post, although I would encourage you to read it when it is finally published. During the course of researching this document I spent time trying to prove or disprove my thesis that x86 system performance solidly overlapped that of RISC/UNIX with available benchmark results. The process highlighted for me the limitations of using standardized benchmarks for performance comparisons. There are now so many benchmarks available that system vendors are only performing each benchmark on selected subsets of their product lines, if at all. Additionally, most benchmarks suffer from several common flaws:
They are results from high-end configurations, in many cases far beyond the norm for any normal use cases, but results cannot be interpolated to smaller, more realistic configurations.
They are often the result of teams of very smart experts tuning the system configurations, application and system software parameters for optimal results. For a large benchmark such as SAP or TPC, it is probably reasonable to assume that there are over 1,000 variables involved in the tuning effort. This makes the results very much like EPA mileage figures — the consumer is guaranteed not to exceed these numbers.