Category Archives: Technology

Supply Management Technical Difficulty … Part II

A lot of vendors will tell you a lot of what they do is so hard and took thousands of hours of development and that no one else could do it as good or as fast or as flexible when the reality is that much of what they do is easy, mostly available in open source, and can be replicated in modern Business Process Management (BPM) configuration toolkits in a matter of weeks.

So, to help you understand what’s truly hard and, in the spend master‘s words, so easy a high school student with an Access database could do it, the doctor is going to bust out his technical chops that include a PhD in computer science (with deep expertise in algorithms, data structures, databases, big data, computational geometry, and optimization), experience in research / architect / technology officer industry roles, and cross-platform experience across pretty much all of the major OSs and implementation languages of choice. We’ll take it area by area in this series. In our first post we tackled standard e-Sourcing, and in this post we’re tackling standard e-procurement.

Requisition, Approval, and Purchase Order Management

Technical Challenge: NOTHING

There’s nothing challenging about creating a requisition, placing it in a, possibly bifurcating and reconnecting, approval stream, getting approvals, and flipping it into a purchase order. It’s literally just adding lines and data to a form, like building a survey or RFX, recording approvals, and generating a purchase order in an appropriate distribution format when the necessary (final) approval(s) have been generated.

Invoice Management

Technical Challenge 1: Automated Error Correction

It’s easy to create and distribute an invoice. It’s easy to run a set of verification rules to verify completeness and correctness and then reject an invoice if data is missing, incomplete, or invalid. It’s harder to determine when data is missing (such as codes, skus, etc.) what that data should be, harder still to figure out which data is likely correct when there is a mismatch between fields that should align, and even harder when data is incomplete and suggests multiple possibilities. The goal should be to not only determine when there are issues with an invoice and flip it back to a supplier for correction (to reduce the number of invoices that need to be manually reviewed and approved) from an average of 15%+ to 1.5%+, but to indicate what the acceptable corrections are / should be so that the supplier can accept and the invoice can be automatically accepted and processed on re-submit. This requires strong AR (Automated Reasoning) technology and it is not easy to not only identify 90% + of the bad data, but 90% + of the correct data to replace the bad / non-existent data with.

Payment Management

Technical Challenge: Working Capital Optimization with Multiple Options

While ACH integration can be a challenge because of the security requirements, it’s not that difficult (as the banks / payment providers did the challenging task of implementing the encryption, secure networks, etc.) and the vendor just needs to plug in, it’s just coding hoops and a well understood process. The challenge is how to optimize the payment schedule against net terms (to prevent penalties), early payment discount options (when it is cheaper to take the discount offered even if the organization has to pay interest at their preferred credit rate), co-factoring (where the organization helps the supplier factor the invoice and agrees to take an early payment cut to cover some of the supplier’s cost of factoring), and investment opportunities to make sure the organization has the cash on hand it needs while minimizing its supply management costs.

Taxation Management

Technical Challenge: NOTHING

While it’s the ultimate pain-in-the-backside to keep up with all of the requirements associated with tax-tracking across multi-level jurisdictions when taxes can be applied at the union, country, state, and city level, especially when the amounts, collection rules, and submission rules are always changing, it’s just data tracking. Nothing more.

IN SUMMARY

With the exception of automated error identification and automated corrective suggestions and of working capital optimization, as with basic e-Sourcing, basic e-Procurement is pretty much common fare today that can be bought off the shelf from dozens (and dozens) of providers, but, as you can see, it’s not all equal. Any provider with AR capabilities for advanced invoice processing and working capital optimization capabilities is leagues ahead of anyone else.

And, as per part I, in this series we’re not discussing the User Experience. While a good User Experience, while not always challenging to code, can be challenging to define, it doesn’t define Technical Difficulty on its own.

Next Up: Supplier Management!

Supply Management Technical Difficulty … Part I

A lot of vendors will tell you a lot of what they do is so hard and took thousands of hours of development and that no one else could do it as good or as fast or as flexible when the reality is that much of what they do is easy, mostly available in open source, and can be replicated in modern Business Process Management (BPM) configuration toolkits in a matter of weeks.

So, to help you understand what’s truly hard and, in the spend master‘s words, so easy a high school student with an Access database could do it, the doctor is going to bust out his technical chops that include a PhD in computer science (with deep expertise in algorithms, data structures, databases, big data, computational geometry, and optimization), experience in research / architect / technology officer industry roles, and cross-platform experience across pretty much all of the major OSs and implementation languages of choice. We’ll take it area by area in this series.

E-SOURCING – RFX

Technical Challenge: NOTHING!

I’m going to burst a lot of bubbles here, but there’s nothing technically sophisticated about the development and implementation of an RFX solution by any stretch of the imagination. In this day of age, one could pretty much implement a basic RFX application in HTML5, javascript, and MySQL with a bunch of open source libraries in a couple of days. Form elements, templates, basic branching workflow, weighting, etc. … you even see most of this in free survey tools. Even bulk file upload is just naming conventions. ( But it’s amazing how many vendors haven’t even figured this out. 🙁 )

E-SOURCING – e-Auction

Technical Challenge: NOTHING!

Again, more bubbles bursting by the dozens. Twenty years ago, implementing an e-Auction was a real challenge with relatively simple web technology, slow internet speeds, and lack of graphical frameworks that could be updated in real time. But today, there’s a host of cheap / freemium solutions that implement basic e-Auction functionality. Unless the vendor is tying in with an optimization solution in real time to create a optimization-backed auction solution, no reason you should pay much for these dime-a-dozen solutions.

E-SOURCING: Optimization

Technical Challenge 1: MODELLING

This comes in two forms.

1. Structured for “Easy” Definition

Creating one or more templates that allow a user to quickly define the entities of interest — suppliers, products, services, locations, lanes, etc., collect the bids, define the constraints, and solve unconstrained, and maybe default constrained scenarios (3 suppliers, geographic split, etc.). Making what’s hard easy is no easy task.

2. Free-Form for Custom Models

Not every model the organization will need to create will fit in a template — especially if the organization wants to optimize working capital, minimize risk, cross-optimize related categories, etc. This requires the ability to allow end users to define the models they want using a modelling interface, which will not be easy to build because how do you hand over all the power but still make it understandable by a non-programmer / non-mathematician.

Technical Challenge 2: SOLVING

It’s hard to build these models, but it’s much harder to solve them. First of all, you have to map them to a system of equations that can be solved by your, hopefully, mixed integer linear programming solver (as you want to use a solver that is mathematically sound and complete), optimize them, optimize the solver settings, and hope that everything was translated consistently and there are no conflicting or unsatisfiable constraints and the model can be solved in a reasonable amount of time. Given that solution time grows exponentially with model size, this can be quite a challenge even for moderate sized models.

E-SOURCING – Contract Management

Technical Challenge 1: Contract Analytics

A simple contract management application, which is nothing more than meta-data based contract indexing and tracking, can literally be built by a high-school student with an Access database and go head-to-head with most of the basic contract management modules out there today! In fact, most of the capabilities of most contract management modules are pretty simplistic and can be built in a matter of days with a good BPM configurator (and companies like Agiloft have done it). The exception is contract analytics (like that provided by the likes of Seal Software).

Using semantic analysis to figure out what contracts contain clauses of a certain type, what contracts are missing clauses that pertain to a certain regulation, and whether a certain clause is close enough to a required / suggested clause is not easy. Not easy at all! Semantic technology is still emerging, and trying to capture a user’s wants, even given a set of sample clauses, is quite computationally difficult!

IN SUMMARY

With the exception of decision optimization and contract analytics, baseline e-Sourcing is pretty much common fare today that can be bought off the shelf from dozens (and dozens) of providers, but, as you can see, it’s not all equal — any provider with true decision optimization or true contract analytics is leagues ahead of anyone else.

And, of course, in this series, we’re not discussing the User Experience, and in some cases, a good User Experience, while not always challenging to code, can be
very challenging to define.

Next up, baseline e-Procurement!

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?