I've been traveling and heads-down so much in the past few weeks that I did not write Part 1 and Part 2 of this rant together (something I usually try to do for cohesiveness). But in this case, my delay was actually a good thing. As I sat down to write this second part on a late-night flight headed back from Oracle OpenWorld on Wednesday evening, I realized that I had the time to reflect on a number of inbound calls and discussions that resulted from my initial comments last week focused on the need for purpose-built procurement applications -- in contrast to the mass of generic capabilities that may work perfectly well for paperclips or the basic sourcing of a more complex category, but are unlikely to meet the needs of any nuanced spend areas in terms of total cost management. At a speech that I presented earlier this week at Consol's Thought Leadership Forum, a number of attendees voiced the same ideas around SOW spend (specifically) -- namely, that the generic, one-sized fits all solution often won't work.
Continuing on in this analysis looking at how Unilever's unique approach better tackles all aspects of transportation spend and links sourcing to execution to compliance in a manner that off-the-shelf Spend Management, TMS and logistics capabilities could not enable, let's first explore today the guidelines that would steer their solution ideation, roll-out and implementation for this complex category. In this regard, Unilever figured out that the essential challenge they needed to overcome was to combine the benefits of active contract management and visibility with an optimization-driven sourcing model while also creating the single version of truth where team members could measure and analyze ongoing costs and performance. Their strategy would also need to be able to adjust to the often-changing requirements and contributing strategies driving the evolution of their transportation spend profile.
From a data-driven architecture perspective, Unilever would need to consolidate information from their ERP system (SAP), TMS tools, payment data and other files in a consolidated database that would contain information in a range of areas -- shipments, requirements, contracts, performance and other data fields. And they would need to do this frequently to stay on top of changes in the underlying system information sets. This dynamic and targeted data warehouse would then feed their purpose-built Spend Management system which would include the ability to manage requirements, strategically source vendors (through an optimization-driven approach), manage contracts, provide reporting capability, enable both internal and external participants (e.g., carriers, auditors, team members, other stakeholders). And then, following information updates based on new sourcing exercise, contracts and process sign-offs (including the ability to manage changes by exception), the purpose-built application would need to feed updated information back into the original system or record, including SAP and TMS.
While the approach might sound complicated on paper, in practice it would ultimately enable Unilever to formulate a data-driven category strategy based on the right set of inputs -- regional/local requirements, essential data-elements such as rates, etc. As important, it would ensure data integrity by allowing Unilever to close the transportation spending loop through successfully planning, sourcing and executing from the ground up with a quality data foundation. Despite the effort required (as well as the cost savings the application could drive), the purpose-built application would also enable Unilever to become a preferred customer to its suppliers by enabling new levels of collaboration and better service through a shared understanding of information and the ability to have carriers focus on their specific areas of strength in specific markets/lanes. It would also foster better communication internally (and with suppliers) by providing a truly consolidated, centralized rate database without any inconsistencies. And this in turn would be a key engine to help drive compliance. The system would also support Unilever's geographic expansion by providing consistent and harmonized processes that would not only enable the decentralized implementation of best practices but also ensure local regulatory and legal compliance.
Unilever's success at rolling out a purpose-built application for transportation spend would exceed the sum of the individual solution parts (e.g., sourcing optimization). Moreover, the CPG giant realized that by pursuing specific and broad business outcomes at the category level that would need to encompass and transcend their operations, sourcing and logistics functions working as individual silos, that they would be able to drive a truly new level of savings, compliance and overall category success. Working with BravoSolution to dissemble core category enablement tools (e.g., data acquisition, master data management, analytics, contracts and sourcing) and then rebuilding them together into something entirely new (along with additional third-party tools and integration capabilities), Unilever proved the value in stepping back from the one-size-fits-all approach to an area of spend that could have game changing consequences for both the bottom and top lines of the business if they changed the way they pursued it.
Have you got a purpose-built category success story on your hands? Share it with us and we'll feature it in our continued coverage of how organizations can leverage the right combination of capabilities to get more from their most challenging spend areas. No generic solutions built on "best practices" need apply. After all, in the case of complicated categories, pursuing improvements incrementally and effectively through the most proven, traditional approaches won't break down the walls that are necessary to truly achieve a breakthrough. This requires thinking about the outcome and working backwards to what a solution must look like -- rather than pursuing and deploying what is simply being served up already on an a la carte basis.