It’s no secret that manual Procure-to-Pay (P2P) costs sap efficiency and drain budgets. When supplier invoice approval and processing lags, it’s tough to get requisitions in on time, checked against contracts and paid. Automating your P2P processes and refining workflows are critical for efficiency, reducing waste, and for tracking your key performance indicators (KPIs).
“More than 125 hours and $171,340 are wasted annually due to manual procure to pay issues.”
The Tungsten Network Global Study
What are some of the key metrics that you need to track after switching from manual to automated P2P solutions? The same things that you tracked during the manual processes: invoices received, processed and paid, contracts, discounts, supplier relationships and alliances. Tracking them electronically, speeds up the process, eliminating paperwork and reducing manpower hours.
Integrating refined Agile and Waterfall workflows within P2P-BPI solutions benefit enterprises by taking slow, inefficient workflows and transforming P2P productivity, ultimately leading to stronger supplier relationships that benefit both back-end and front-end P2P processes.
Defining Agile Scrum and Waterfall Workflows for P2P Automated Solutions
Agile Scrum (set of principles and practices that enable fast feedback, communication, continual improvement, and rapid adaptation to change), and Waterfall workflows (classical model using linear and sequential approach) may seem polar opposites at first glance. But once you delve into their workflows, you will notice that P2P teams incorporating both interfaces communicate delivering quality and value to the customer. How does this work when automation speeds up the P2P process? Refining which workflow works best with your company and your suppliers still requires human facilitation.
Notice that the term workflow is used, not process. Process is generic, an umbrella term. Workflow more accurately defines how teams utilize the relatively new agile and the traditional waterfall approaches in getting a P2P project from start to finish. However, it shouldn’t misconstrued that the terms are interchangeable. They aren’t–but they can coexist within the same project.
Why Aren’t They Interchangeable?
Think about how a marathoner trains as opposed to a sprinter. In order for a marathon runner to make it the 26.2 miles, training has to be very regimented, geared toward endurance. A sprinter trains to run in short, high intensity bursts. Each training method utilizes a particular set of muscles and uses certain breathing techniques. If the marathon runner trains as a sprinter, then it’ll be a struggle to finish 26.2 miles. If the sprinter trains as a marathon runner, then it’ll be tougher to accelerate off their mark and get that “punch” required to shave time off their sprint.
A marathon runners and a sprinter’s training are not interchangeable, although both require physical and mental stamina while focusing on the endgame. In this sense, their training is compatible. Somewhere in the middle is fartlek training–running slower, longer distances interspersed with sprints–reaping the best of both worlds:
• A traditional waterfall workflow is the marathon runner.
• Scrum is the rugby moniker for scrummage, which means restarting play. Scrum’s the sprinter.
• Waterfall-scrum workflow is the fartlek training.
Waterfall is predictive–slow and steady forward momentum wins the race. Scrum iteratively adapts to changing game. Momentum’s forward thrust stops and starts–often restarts–depending on what’s working and customer feedback. It’s predictably unpredictable, yet principled and forward-thinking.
Both workflows generally follow a four-phase game plan–how they utilize this game plan depends on which workflow you are using:
• Discovering requirements: mapping out need and goals
• Planning how to meet those requirements: development, testing, production, quality
• Build: production, testing
• Review: does it work, customer feedback
Discover, plan, build, review–that’s the traditional waterfall workflow from the start of a project to its finish. It’s focused, based on concrete, regimented rules and need; yielding to the will of customer change can take time and red tape. It’s often a tedious workflow.
Scrum’s iterations use the same game plan–except that the sequence restarts every 14 to 30 days–and at the end of each iteration, or sprint, there’s a project that provides some negotiable deliverable to the customer. Sprints allow teams to adapt to the 21st-century world of rapid change and product delivery. Combining refined workflows with automated BPI solutions provides maximum efficiency.
Hybrid Workflows within P2P-BPI Solutions
Integrating agile scrum and waterfall workflows with our iBundle Supplier Relationship Improvement (SRI) Solutions (iApprove, iPurchase, iManagePOs and iVoucher) provides scalable P2P processes and actionable KPIs that link people, workflows and platform. iBundle SRI bolts on to your existing ERP for use on-site or in the cloud. It’s highly configurable, mobile-ready and is the tool that will streamline your P2P process into maximum efficiency.
Part 2 of “Defining Waterfall-Scrum Workflows for Your P2P Process” will explore how waterfall-scrum workflows can curb issues such as approval problems and maverick spending. Contact us, we can help you decide if your P2P process is a marathon, a series of sprints or somewhere in-between.
