Polymorphism: The Key to a Mass-Customized Procurement Organization and Technology Platform

molding clay

I want to talk about polymorphism. Yes, polymorphism. Right now, there are about seven technology programmers reading this wearing Grady Booch T-shirts that say “Right on!” For the rest of you, please read on.

Polymorphism is about being able to take multiple forms (the “morph” part of the term) and behave in different ways even though you are part of the same class of items. In biology, a polymorph can be the same species yet look very different and behave differently (e.g., a black jaguar and regular jaguar). In object-oriented computer programming, which is a key aspect of implementing artificial intelligence (AI) systems, polymorphism is about an object that behaves differently based upon what other object is “calling” it. In other words, these entities tune their behaviors based on the context that they operating within.

So, what does this have to do with procurement? Everything!

Toward Mass Customization

The first thing is to relate the idea to another idea of mass customization — the ability to run a supply chain that has the scale of mass production, but the customization of engineering to order. This is a well-known concept in supply chain management where flexible manufacturing systems within the factory can help crush down cycle times and help move the firm from a make-to-stock environment to a make-to-order environment. With additive manufacturing and 3-D scanning, the concept can be taken to new extremes. The basic idea, though, is that the products take different forms even though they come from one supply chain process.

The same goes for procurement services — whether delivered via internal business services from a procurement organization or information services from a cloud e-procurement solution provider. Procurement organizations need to tune their engagement models (operating models, terminology, metrics, processes, tools, etc.) to what stakeholders want from procurement in terms of getting the most supply value from their spend.

So, for example, a RACI model may differ for different category-specific processes, but the foundational model is the same. It is the opposite of a one-size-fits-all sourcing process, category taxonomy, roles/responsibility matrix or technology tool. Similarly, just as many technology applications give you a data dictionary with editable metadata to allow system terminology to change, procurement organizations can do the same to the terminology used in discussing procurement. For example, changing the term “cost” or “spend” to the term “investment” is an approach used at many firms and especially favored in marketing departments.

The Thesis (Skip to the Good Bit)

Polymorphism also naturally fits well in technology environments, and particularly well to procurement technology. In fact, if I may be so bold to say that flexible, intelligent technology applications will be nearly as important to revolutionizing business processes as flexible, intelligent manufacturing and warehousing systems have been to revolutionizing the supply chain. This is especially true for procurement processes that need to be “shape-shifting” supply provisioners that adapt to the context of any demand source needing external products and services to help deliver business outcomes.

For example, true cloud-based systems require a multi-tenant data model that exhibits polymorphism. In other words, the business logic in the application is dependent upon who you are and what company you're with rather than just a single set of global parameters that are set up with each separate implementation. That small change alone has helped create a huge inflection point for providers to re-code their old on-premise “one-to-many” solutions.

But, it is only just the beginning, and it’s my belief that the future, of which we’re beginning to see parts of now, will radically improve the mass customization capabilities of procurement systems so that they will be able to tailor user interfaces, terminology, application logic and data presented based on a complex set of predetermined business rules and machine learning (via “inference engines”) that are based on the context of what the user is trying to do and where.

The above idea is fundamentally core to the future of category-specific functionality, but more broadly to any functionality that must overlap a complex set of contextual data from which the system will need to understand and help the user make the right choices.

A Brave New World (Seriously!)

This is not just a huge topic that will impact the future of procurement technology applications, but also the future of service providers and procurement organizations themselves that are service providers. I will be writing more about this topic in the future, but it really provides a convergence area of AI, technology platforms and advanced service delivery models in an era of everything as a service (XaaS).

For example, it will key to the future of work intermediation platforms (WIPs) that my colleague Andrew Karpie has been writing about. It will also be a fundamental shift in the technology architectures out there that will become much more object-based and network-based versus hierarchical data models implemented via classic relationship databases. It's more than running columnar databases in memory.

Anyway, I’m getting ahead of myself, but if you’re a procurement practitioner, I would encourage you to think hard about how you “mass customize” your procurement services to your stakeholders. Do you talk the language of your stakeholders? Do you tailor your scorecard with them? Do you rightsize and configure your n-step sourcing processes to meet their deadlines and level of needed sourcing rigor? Do you tailor your RACI model to the model that works best for that stakeholder or relevant category?

If you’re a solution provider of any type, I would similarly encourage you to think about how you can maximize system flexibility via application logic that is tied to user-specific, action-specific and context-specific data that will become increasingly external and unstructured in nature. I touched on some of these ideas about 18 months ago here and here on our site and a webcast I did with a provider client, but if anyone wants to chat about this area before I slowly drip more detail about this critical area in the future, please don't hesitate to contact me.

Voices (3)

  1. Sujee Mampitiyarachchi:

    I enjoyed your article and insights put forward. I think the ability to rapidly configure, deploy and adapt processes are a standout feature in emerging procurement technologies. This will free the procurement practitioner to explore more dynamic and sophisticated strategies, which may have been discounted previously due to a ‘one-size fits all’ process or policy position.

  2. Pierre Mitchell:

    I think this is also about how practitioners similarly design all aspects of their operating model to be more flexible, which only then in turn requires more flexible master data, analytics, and workflow. To answer your question though, there is a trade-off if only one company does it. But, this is where the tech vendors and service providers can bring scale by using a platform to build higher level solutions (e.g., category solutions). For example, consider supplier management app providers who build metadata about various regulations into supplier questionnaire templates so that only the relevant questions are asked to the suppliers based on what’s peggable to unique regulatory requirement (which the buyer can opt in/out of). Also, analytics will continue to get smarter and domain specific too. Just like spend auto-classification gets smarter through training to help what is essentially “empty” BI app, service providers have an opportunity to build such knowledge into their solutions to offer up to customers who don’t want to roll their own.

  3. Matt Miller:

    Pierre, great article. Technology providers are definitely programming more flexibility into applications. Is there a trade-off between setup and user training and ROI and complexity? The challenge is hiding the complexity from ever day end users.

Discuss this:

Your email address will not be published. Required fields are marked *