The disconnect between software buyers and vendors – about the role of SIs

In the case studies I wrote for SAP Nation 3.0 I noticed two common threads

A) Customers were using SIs cautiously – the last set of experiences with SIs and outsources has made them wary. A couple even thanked me for writing the first volume and bringing out the massive cost and poor quality of the SI ecosystem. “You opened our eyes” said one.

B) Several insisted I not include the name of their SI in their case study. It’s their prerogative and I did not pry why. It could be for legal reasons, but I got the distinct sense that they did not want to overstate the role of the SI versus that of their own staff.

Both trends are healthy. In contrast, I am seeing software vendors go the other direction. They call SIs “partners”, brag about how big the SI staff counts are around their products forgetting that this is a direct cost to the customer, plus often another 15 to 20% in travel expenses.

Even more I have noticed SIs are being brought it to present to analysts at the events, and in most cases the SI executives are unprepared or unwilling to answer tough questions. These three comments are in the last few months from SI executives at 3 different major vendor events.

“We have 000s of consultants. We wont change overnight. But I can assure you we are not making revenue from what we did a decade ago”.

“We mostly work on large, global projects and those are not really going to be automated”

“Either he leaves or I leave” – by an executive offended by a fellow analyst’s question about failure rates involving his firm

In each case, I should have challenged the SI statement as either inaccurate or too defensive. Instead being there as a guest of the software vendor I just let it pass. And the host in each case also let it pass.

I am seeing some software vendors start to bring improvements to the world of software projects.
In this post, Jerry Foster, CTO at Plex described a machine learning project applied to parameter configuration. No reason other vendors cannot do the same and encourage their SI partners to train machines learn from their own work across 000s of ERP and CRM projects.
Workday has been more diligent about requiring its SI partners to certify their consultants and keep their certificates refreshed. It has also been pushing a series of project checkpoints as part of its Delivery Assurance initiative. Certification by itself is no indication of project success, but it’s a start. If they could enhance certification with customer feedback from each project the consultant has worked on, they could have the makings of a ‘FICO’ score – that could be revolutionary for the industry.
As part of moves to S/4HANA, SAP customers benefit from its ‘Simplification List’ which identifies functionality which has been deprecated to remove redundant code in previous versions and its ‘pre-checks’ which examine customizations which may cause problems during the migration. If they can continue to bring more automation to common steps in every project – in data conversion, testing, testing – they could shrink at least some of the labor intensive tasks.
There’s lots more to do. I can point to hundreds of small and major things software vendors can do to improve their services ecosystems. The question for many is why should we invest? Why aren’t SIs making their own investments? They are, but the business model has not evolved much – it still thrives on labor intensity. And with that comes the costs of staff turnover, travel, inconsistent quality and more.
Somebody has to break the cycle. Buyers increasingly want changes. Software vendors need to help deliver them.

LinkedIn Twitter
CEO of Deal Architect, a top advisory boutique recognized in The Black Book of Outsourcing, author of a widely praised book on technology enabled innovation, The New Polymath, prolific blogger, writing about technology-enabled innovation at New Florence, New Renaissance and about waste in technology at Deal Architect.  Previously Analyst  at Gartner, Partner with PwC Consulting. Keynoted at many business and technology conferences and has been quoted in the Wall Street Journal, BusinessWeek, The Financial Times, CIO Magazine, and other executive and technology publications.

2 responses to “The disconnect between software buyers and vendors – about the role of SIs”

  1. Tom Short

    Great topic – disconnect between software services and buyers. Having worked as a process improvement consultant for Gartner, IBM and various “Big 4” firms, and then as a post-sales support consultant for an enterprise software company, my observation is that there is an even more insidious disconnect in the software industry: the disconnect between the corporate buyers of software and their end users.

    What I saw went like this:
    The product developers at the software houses had to constantly strike a balance between what they could do to make end users happy and what they had to do to stay current as far as the big analyst firms were concerned. Ultimately gaining favor with the analyst firms would trump anything the end users wanted that wasn’t aligned with it. Meanwhile, corporate IT departments are paying close attention to what the analyst firms are saying, and making buying decisions based on rankings and ratings.

    So where does the end user end up in the unholy trinity of software houses, analyst firms, and corporate IT departments? Entirely downstream from the entire decision making process, from decisions about what features, functionality and user experience will or won’t be included; to which software package a company will end up buying.

    As a result we end up with software that checks all the features and functionality boxes, while leaving end users completely vexed and frustrated by software that leaves little to be desired in terms of helping them get their job done.

  2. vinnie mirchandani

    Tom good point – but functionally vendors just aren’t growing. After 20 years of cloud apps, see how little industry or geo functionality is available. Either not enough R&D or poor return on R&D. Not just end users who are unhappy.