Category Archives: Technology

What Makes a Sourcing Suite?

Good question, and one both customers and vendors must answer in the days ahead. Last decade, it was pretty simple. You could claim a sourcing suite if you had decent e-Negotiation support with some document management and reporting. And if, instead of document management, you had contract management and if, instead of reporting you had real spend analysis, then you were best of breed. And if, on top of all of this, you had some basic project management or category guidance, you were awesome.

But that was then, this is now. These days, if you don’t have basic S2C (Analysis, e-Negotiation, Contract Management) with decent Supplier Information Management, you’re not even a contender. Plus, given that many providers are offering some project / workflow management, expert driven category guidance, bill of materials support for direct sourcing, contract analytics (not the same as contract management), deep SRM (Supplier Relationship Management, Performance Management, Compliance Management, Risk Management, Optimization and other unique offerings that they expect to gain them market-share.

So what do you need? Hard to say because the real answer is whatever you need to successfully conduct and monitor a sourcing event that doesn’t belong in the complementary P2P suite. That varies based on the category and the industry you’re in, but there is some commonality. Specifically, while still not a mainstay of sourcing suites, every suite needs project/workflow management, every suite needs some performance tracking and management (as that should influence not only current, but future, events), a minimum of SPM (supplier performance management) and not SIM, some compliance requirement and documentation management, and better than average analytics. And any organization that does a lot of direct sourcing needs Bill of Materials Management, and while most organizations don’t know it, you’ll always find a lower-cost allocation with an optimization-backed sourcing solution. (And going back to Wednesday’s post, this isn’t savings, this is avoidance of unnecessary costs.)

In other words, you need a lot. But, fortunately, you don’t need best of breed for most of this. The only solutions that continually provide year-over-year value of 10% or more (through avoidance of unnecessary costs) are advanced analytics solutions and true optimization solutions. So you need best of breed here.

But not for most of the other components, although certain components should be better than average. The RFX in particular. It should not only be ridiculously easy to create and modify RFXs (which are typically the beginning of every sourcing event) but also to bulk upload attachments (as this can kill days in large projects when you have ten bill of materials with a dozen to a hundred items each and each component needs its own spec document), define a team for collaborative and distributed creation and scoring, and one-click integration into the analytics and optimization modules for detailed analysis.

Another component that needs to be better than average is the Supplier Portal — you need to make it as easy as possible for suppliers to provide information, response to events, create collaborative corrective action plans, offer innovation ideas, and so on. You want your suppliers to work with you and find it at least a reasonable, if not an enjoyable, experience. If the portal, and integration options, are sub-par and painful to use, and leave a bad taste in their mouth, this will eventually sour the relationship.

In other words, while the exact definition of a Sourcing Suite can be a bit nebulous, the requirements it has to fulfill, especially for your organization, are not. And a key requirement is usability and a good user experience for buyers and suppliers alike. Keep this in mind when selecting your new sourcing solution.

OEM Software Maintenance: Should I Stay or Should I Go? Part III

After working your way through Torey’s 2-part series, you have probably figured out that it’s a tough decision. It all comes down to ROI, which is a two part calculation. The first part is what does it cost to stay, and what does it cost to go:

This calculation requires filling out the following table at the very least and getting a good feel for total cost outlay either way:

Provider 3rd Party
Annual Maintenance Cost Usually % of License Often Fixed Amount
Estimated LifeSpan Annual Maintenance Cost * (Years-1) Usually fixed amount, sometimes lower for longer lifespans
Required 3rd Party Software Upgrades Extra Provider Costs Extra Third Party Costs
Forced Provider Upgrades Provider Costs 3rd Party Costs
Extra Training Costs if not included if not included
Extra Customization Costs if not included if not in base support
Grand Total $$$ $$$

If the third party cost is significantly less (at least 20%, preferably more, because there are always unknowns and gotchas and switching costs), then you consider switching. But only if there is also value.

Cost alone should not be a consideration. What sort of value will the new vendor bring with them? Will they bring best-in-class processes? Do they have any needed industry and category expertise? Do they consistently out-perform the vendor in areas of inefficiency in the organization? If they don’t also bring value, the savings will be limited compared to what is expected. But if they bring added value, then it’s a totally different story, and one that needs to be read.

OEM Software Maintenance: Should I Stay or Should I Go? Part II

Today’s guest post is from Torey Guingrich, a Project Manager at Source One Management Services, who focuses on helping global companies drive greater value from their expenditures.

As a strategic sourcing consultant, the very broad category of “software” seems to always be an area in which companies are looking to reduce costs. . But is there an opportunity to substantially reduce maintenance costs if you want to continue utilizing the applications? Are third party maintenance providers an option?

The first step to answering these questions is to properly frame questions with IT to better determine if third party maintenance is a potential solution for your organization. Yesterday we provided you with the important Application Lifecycle questions. Today we address value from support, level of customization, and level of response.

  • Value from Support:
    • How often do we engage with the vendor support? Assuming you are in a stable environment that opens the door for third-party maintenance, consider the support/content you are receiving and utilizing from the software publisher directly.
    • Are we apt to upgrade with every release or do we tend to push off upgrades?/What are the pain points in upgrades and what is the perceived value we see from them? Third party providers provide break/fix support, troubleshoot bugs and typically provide tax/regulatory updates as well as potential support for customization, but you would not be eligible to receive updates and upgrades direct from the OEM. This is an opportunity to discuss with IT your organization’s typical appetite for change, e.g. do they immediately act on update/upgrade opportunities, or do you typically push these out for a few releases? It is not uncommon for OEMs to charge (or try to charge) back maintenance for some period of time when an upgrade is warranted, so you shouldn’t be cutting ties if you have planned upgrades or new version releases in your roadmap (assuming you are upgrading due to perceived value, as opposed to being forced off an older release by the OEM).
  • Level of Customization:
    • What level of customization does the system have and what support is in place for that custom code? When applications are highly customized, standard maintenance from the OEM is very unlikely to support those customizations. Many third party providers do include support for custom code in the cost of annual maintenance which may be an opportunity to alleviate the work of internal resources or other providers you may be utilizing to support customizations. Consider how customized your environment is and the level of effort IT resources (internal or external) spend to support that custom code; question your IT stakeholders on the systems that are most customized and any past issues they may have run into when it comes to customization (or if they already rely on an outsourced model to do so). Highly customization systems typically run into issues when it comes time to upgrade, so if your company has delayed upgrades or prefers to retain the current version because of the level of customization, this again may be an opportunity to look to third party maintenance.
  • Level of Response:
    • How happy are you with the level of support and responsiveness from the vendor? One final area to consider are the service levels/guarantees of your current support model. Third-party maintenance providers tout their strong SLAs and dedicated account management, with many offering 24×7 support and aggressive response and resolution timeframes. While some customers think this alone may be a reason to switch maintenance models, work with IT to try and quantify the frequency with which you engage the current support model and if there is truly a business impact or benefit that could come from stronger or more responsive support.

While third party maintenance providers boast large reductions in cost (many market a 40-50% decrease in annual maintenance cost), Procurement needs to work with IT to define if these providers can be used strategically given the considerations above. Considering compressed IT budgets and heavy reliance on ERP vendors, it may be high time to explore the options in the market, have the conversation with your IT leadership, and challenge third party providers to help you determine if they are a good fit given your current environment. At the very least, this option can be used as a leverage position with some of the software giants out there to negotiate maintenance percentage or mitigate increases to maintenance structures.

So now you need to decide, Should I Stay or Should I Go?

OEM Software Maintenance: Should I Stay or Should I Go? Part I

Today’s guest post is from Torey Guingrich, a Project Manager at Source One Management Services, who focuses on helping global companies drive greater value from their expenditures.

As a strategic sourcing consultant, the very broad category of “software” seems to always be an area in which companies are looking to reduce costs. The spend categorized as software is usually compromised of some net new licenses purchases, perhaps annual subscription based licensing, but almost always has a large portion of spend that is actually ongoing maintenance and support for previously purchased licensing. But is there an opportunity to substantially reduce maintenance costs if you want to continue utilizing the applications?

While third party maintenance providers are expanding their ground for many hardware and software solutions, one of the more prominent areas of expansion has been in managing annual support costs associated with ERP systems where the cost of maintenance can be a staggering, and ever-increasing, amount. While there are some conflicting opinions on the future of ERP third party maintenance given the ongoing legal battles in recent years, there is a strong case to be made that third party maintenance as a concept will not being going away anytime soon. While Procurement professionals may be enticed by the opportunity to slash a software budget, does it make sense for your company to cut to ties with native maintenance services from the software publisher and how should you go about evaluating this option for your company and/or discussing it with the stakeholders who manage those relationships?
The areas below will help Procurement frame questions and discussions with IT to better determine if third party maintenance is a potential solution for your organization:

Application Lifecycle:

  • What are the current owned licenses and associated maintenance costs/structures? Gaining visibility into the current software and maintenance environment is key to determining the scale of software maintenance costs as compared to other areas of spend within the IT budget.
  • What is the roadmap for the current software system in use? Once you have isolated the primary solutions that drive maintenance costs, it is important to set the stage for measuring stability in the environment. If a particular system is planned to be replaced or retired in the next few years, it may be a great opportunity to explore third party support for a limited time on the system being decommissioned before the new system is put in place.
  • How long has the solution been in place?/Have you recently launched or upgraded the solution in questions?/How stable is the environment? Immature and unstable environments tend to rely more heavily on OEM updates, upgrades, patches, and other content than those that have been in place for many years. Stability of the current environment is a key component in evaluating opportunities for third party maintenance as any change may be disruptive without the comfort of patches and regular updates from the OEM.
  • Is there a desire to keep the current system beyond the period the OEM offers support or are we being forced to upgrade where we would rather not? If you discover that the environment is very stable with no planned upgrades, you may have the option to actually extend the life of a certain application or release by leveraging third party maintenance where an OEM is no longer offering support.

These necessary questions are just a few of the key questions you need to ask. If the answers to these would allow a third party provider to be considered, the next step is to assess value, customization, and response. We will discuss these issues tomorrow in Part II.

One Hundred and Twenty Years Ago Today

One Hundred and Twenty Years Ago Today J.J. Thomson announced his discovery of the electron at the Royal Institution in London.

Without a good understanding of electrons, which play an essential role in electricity, magnetism, and conductivity (in addition to more fundamental gravitational, electromagnetic, and weak force interactions), we would never have made the advances we made in modern technology. For example, even though, based on the work of Goldstein and Hittorf, Sir William Crookes developed the first cathode ray tube back in the 1870s without knowing what they were, it was electrons that made them work — as determined by J.J. Thomson and colleagues through experiments they conducted in 1896 (based on the work of Lorentz and Schuster).

The visual computing revolution started with the cathode ray tube, and, moreover, as there is no computing without electricity, and no electricity without electrons, without the discovery of electrons, and a good understanding of what they enabled, we wouldn’t be where we are today.