Software at the Core of Digital Design: Design-Centered Procurement (Part 3)

procurement technology cronislaw/Adobe Stock

Back due to popular demand: We're bringing this Plus series out from behind the paywall so all procurement professionals can start using design thinking to inform their procurement architecture — and learn how user-focused software enables this process. Read the first three installments in the coming weeks, or download the white paper today to get the full story all in one PDF!

In our last installment of this series on design-centered procurement, we discussed the importance of good design in products, the design of the supporting supply chain and the design of the supply management function. We used the example of a car design and contrasted the good design of a Tesla compared with the design of the ill-fated Pontiac Aztek.

But consider replacing the word “car” with “procurement system.” Traditional software development for procurement applications (or any packaged applications software, for that matter) looks uncannily like that of the Pontiac Aztek. “Feature 500” lists are developed that not only address incremental customer functionality requirements but also throw in new “bells and whistles” designed to keep up with the competitors’ software features, and the preferences of IT industry analysts who put providers on simplistic 2x2 quadrants. Yet the software itself doesn't necessarily align to the procurement outcome of driving business value from better supply management (and demand management as part of this).

Why? Here are the biggest issues that we see and how to address them:

  • Some software actually can introduce complexity because although functionality bloat is served up in the form of a one-size-fits-all, all-you-can-eat menu (even though the menu is split up into courses called modules), the tailoring of the software is fairly limited to things like field navigation, field name changes, bolt-on fields, color schemes and selected business logic that can be tuned to user groups and roles. But, when you consider the huge variety of user types, industries, terminologies and spend categories, you’re really just changing the shades of lipstick on the proverbial pig. The problem is even worse when a large solution provider owns a large pen of pigs that were farm raised or purchased from others. Your CIO may have a vested interest in that provider, but at the end of the day, you need to be farming some savings rather than herding pigs.
  • Even top-notch SaaS solutions that are componentized, open (via APIs), UI responsive, scalable, intuitive (i.e., you know where you are, where to go and how to do what you need with minimal training) and developed with heavy user involvement are still fairly traditional in how they are designed and developed. B2C solutions and emerging ones in B2B, however, are making use of more advanced elements in their underlying platforms:
    • Structured design metaphors and toolboxes that improve general user experience (e.g., material design, flat design, Bootstrap, Metro, iOS, etc.), but that also can personalized to multiple enterprise needs.
    • Designing in intangibles to maximize fulfillment in the experience. When you sit in an ultra-luxury car, sip a mind blowing cabernet, appreciate umami in a gourmet food, listen to an audiophile-grade music system, stand in a room with good feng shui or simply hold a well-designed smartphone, good design impacts you at a deeper level. While you might roll your eyes at the thought of bringing joy to a purchase order, it’s important to consider the humans at the center of the process (at least for now), and how to improve their experience. For example, gamification can be used to change behaviors of requisitioners or to design compelling competitive bidding events. A poorly designed bidding event will lead to very bad outcomes, so design matters here too.
    • If procurement is “all about talent,” and if “talent is all about engagement,” the engagement should be a design criteria to strongly incorporate adoption, whether it’s gamification features or using KPI-based incentives to keep users focused on the right things. The design of the system is not just about user delight, but also meeting corporate objectives. Good design tries to accomplish multiple, often competing, objectives at once.
    • More flexible data models than just traditional hierarchies (e.g., spend categorization is inherently multidimensional) and relational databases endemic in traditional enterprise applications. Such flexible data modeling can include semantic knowledge modeling (which helps support search capabilities), neural networks, columnar in-memory databases for fast analytics and so forth. This allows richer and deeper multivariate data modeling and discovery, which is key since spend categories are inherently multivariate.
    • New paradigms for managing data aren’t limited to analytics. Consider the impact of the blockchain approach of a massively distributed open ledger (accessible in a secure fashion) on transaction processing or perhaps supplier discovery.
    • Machine learning applied to analytics, predictive text entry, usability analysis (compared against persona attributes) and other area that help users learn from themselves; users learn from others; and system designers learn from all of the users. The death of “empty apps” is coming soon.
    • “JIT” functionality and data presentment that only reveals the functionality needed for the end users (who may have multiple roles) and that also pushes alerts intelligently to users versus relying on users to go into their big hairy dashboards and workbenches. You subscribe to the system and tell it what you need to know and it publishes what you need to focus on (or at least consider) next.
    • Application security and business functionality that is geared to the nature of the data and the context. For example, if you apply the design principle of empathy to the stakeholders called suppliers, you’ll find that their biggest issue is will remembering all the logins and passwords to their buyers’ portals and partner network providers. This in turn leads to security issues. But, is all content the same? Are all suppliers the same? Are all regulatory regimes being factored in flexibly? Do tail spend suppliers even need to access a portal or are there other ways to interact with them? In fact, do they even need accounts and passwords at all? Increasingly, outside-in data conditions applied against internal context-driven requirements will drive highly dynamic workflows that look nothing like a fixed assembly line approach to process automation. We’re already starting to see it in the supplier management arena. “Intelligent automation” can’t come soon enough.
    • Taking design cues from best-of-breed niche collaboration tools such as Slack for messaging, Asana for project collaboration, Doodle for event scheduling, IFTTT for self-service integration, DocuSign for digital signatures, Qlik Sense for analytic collaboration and so on.
    • Improving fit and function (and adoption) by using openness (e.g., open APIs) and de facto standards. If you want to develop highly adopted applications, you should not just “multiplatform” them to the platforms that your target users use but also integrate to the other applications that they use (e.g., integrating Microsoft Word into contract authoring or Excel into an e-sourcing application), and expose your applications via open APIs to others that could best use your solution. And if you can use open source tools or open standards, that’s a bonus.
  • Software is sold as an isolated capability rather than part of a business outcome. You buy the “empty apps” and are required to implement the applications in a way that hopefully delivers value rather than you buying the outcomes you’re looking for. But this is changing. Smart procurement organizations are increasingly sourcing technology-driven business outcomes rather than technology installation as the outcome. For example, in the procure-to-pay (P2P) space, this may be paying to get your supplier base onboarded and transacting. In the sourcing area, this can involve a transition from e-sourcing application uptime to managed services surrounding the e-sourcing events, including category guidance and sourcing strategy development (and execution of course).
  • Software applications are not extensions of an underlying platform. Going back to the automotive example, consider the fact that in the automotive industry, car model designs are now built on top of platform designs (or “architectures”).  For example, the Audi TT and Volkswagen Golf are very different cars, but they are built on top of the same platform. In the software world, the same “platforming” trend is occurring. SaaS products are increasingly built on PaaS elements in the same way that mobile consumer applications are built on Apple’s iOS or Google’s Android (or that B2B apps are developed in the CRM world on Salesforce’s By adopting platform-centered design where the platform elements (e.g., a flexible forms management capability that can be adopted by customers and partners to develop into re-usable category-specific templates) can be embraced, adopted and refined by the users themselves, then they can actively co-create the designs to better help themselves. SaaS providers in particular should embrace personalization capabilities that use metadata and data dictionaries that allow add-on forms, fields, labels, help text, API callouts and even business logic that seem custom in nature, but seamlessly get applied in cloud updates.

To this last point, “platforms” and “platform thinking” are not just for software — they are appropriate for any type of service that is being designed in an industrialized way. As software begins to encroach on previously labor-intensive service models in the BPO industry and even consulting, the software-based platforms are beginning to not just wrap and coordinate the buying of labor based services through work intermediation platforms (WIPs) in the same way that the Internet of Things is wrapping and orchestrating physical assets/products in the physical supply chain but is also digitizing those services themselves (in essence productizing them).  
So platforms are a key design approach that increasingly have software at the core, whether it’s a design of a car or a procurement organization.  

Discuss this:

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