INTRODUCTION

opstream was founded in 2021 to bring enterprise level orchestration, previously only available to IT, to Procurement in a manner that supported all of Procurement’s needs regardless of what that need was. In the beginning, this was allowing Procurement to not only create end-to-end workflows from request through requisition through reaping, but also create workflows out into logistics tracking, inventory management, and supply chain visibility, as required. Workflows that incorporated not just forms, but processes, intelligence, and, most importantly, team collaboration.

In other words, not much different than most of the other intake-to-orchestration platforms that were popping up faster than the moles in whack-a-mole at an initial analysis, especially since every platform was, and still is, claiming full process support, limitless integration, and endless collaboration while bringing intelligence to your Procurement function. (There was one big difference, and we’ll get to that later.)

However, unlike many founders who came from Procurement and assumed they knew everything that was needed, or from enterprise IT orchestration solutions who thought they knew everything Procurement needed, the founders of Opsteam admitted day one they didn’t know Procurement, interviewed over 400 professionals during development, and also realized the one thing that their orchestration platform had to do when it came to Procurement intake and orchestration, if the platform was to be valuable to their target customers, was direct. And they were 100% right. Of the 700+ solutions out there in S2P+ (see the Sourcing Innovation MegaMap), less than 1/20th address direct in any significant capacity, and none of the current intake-to-orchestrate platforms were designed to support direct from the ground up on day one.

So what does opstream do?

SOLUTION SUMMARY

As with any other intake-to-orchestrate platform, the platform has two parts, the user-based “intake” and the admin-based “orchestrate”.

We’ll start with the primary components of the admin-based orchestrate solution.

Intake Editor

The intake editor manages the intake schemas that define the intake workflows which are defined by request type. In opstream, an intake workflow will contain a workflow process for the requester, approver(s), vendor, and the opstream automation engine as well as a section to define the extent to which the approvers can impact the workflow.

The workflow builder is form based and allows the form builder to build as many steps as needed, with as many questions of any type as needed, using pre-built blocks that can accelerate the process, any and all available data sources for request creation and validation, and any of these sources, from all integrated systems, can also be used for conditional logic validations. This logic can be used to determine whether or not a step, or a question, is shown, or what values are accepted, or if it will influence a later question on the form.

Building the workflow is as easy as building an RFX as a user is just selecting from a set of basic elements such as a text block, numeric field, date/time object, multiple choice, data source, logic block, etc.

The data source allows a user to select any object definition in the data source, select an associated column, and restrict values to entries in that column. And the form will dynamically update and adjust as the underlying data source adjusts.

In addition to having workflows that adjust as related systems and data sources change, the platform also has one other unique capability when it comes to building workflows for Procurement requests. It understands multiple item types: inventory item, non-inventory item, and service — which are understood by many platforms — other charge, which is a capability for capturing non PO spend that only a few deep Procurement platforms understand, and, most importantly, assembly/bill of materials, which is an option the doctor hasn’t seen yet (and which enables true direct support).

As long as the organization has an ERP/MRP or similar system that defines a bill of materials, then the opstream platform can model that bill of materials and allow the administrators to build workflows where the manufacturing department can request orders, or reorders, against part, or all, of the bill of material.

In addition, if the organization orders a lot of products that need to be customized, such as computer/server builds, 3D printer assemblies, or fleet vehicles, the admins can define special assembly / configurator workflows that can allow the user to specify every option they need on a product or service when they make the request.

The approval workflows can be as sparse or as detailed as the request process, and can have as few or as many checks as desired. This can include verifications against budgets, policies, and data in any integrated system. As with any good procurement systems, approvals can be sequential or parallel, restricted to users or opened to teams, and can be short circuited by super-approvers.

In addition, workflows can also be setup for vendors to get requests from the buyer, provide information, and execute their parts of the workflow, including providing integration information to their systems for automatic e-document receipt, transmission, update, and verification.

Finally, the automation workflow can be setup to automate the creation and distribution of complete requisitions for approval, complete purchase orders for deliveries, the receipt and acknowledgement of vendor order acknowledgements and advanced shipping notices and invoices, the auto-transmission of ok-to-pay and payment verifications.

But it doesn’t have to stop there. One big differentiator of the opstream platform is because it was built to be an enterprise integration platform at the core is that — as we’ve already hinted about in our discussion of how, unlike pretty much every other intake/orchestrate platform, it supports assembly/bill of materials out of the box by integrating with ERPs/MRPs — it doesn’t have to stop at the “pay” in source-to-pay. It can pull in the logistics management/monitoring system to track shipments and inventory en route. It can be integrated with the inventory management system to track current inventory and help a Procurement organization manage requisitions against inventory and guide buyers when inventory needs to be replenished. It can also integrate with quality management and service tracking systems to track the expected quality and lifespan of the products that come from inventory and warn buyers if the quality or number of service issues is increasing at the time of requisition or reorder.

Data Source Manager

opstream comes with hundreds of systems integrated out of the box, but it’s trivial for opstream to add more platforms as needed (as long as those platforms have an open API) as the opsteam platform has built-in data model discovery capabilities and support for the standard web connection protocols. This means that adding a new data source is simply a matter of specifying the connection strings and parameters and the source will be integrated and the public data source auto-discovered. The admin can then configure exactly what is available for use in the opstream solution, who can see/use what, and the synch interval.

Now we’ll discuss the primary components of the buyer-based orchestration solution.

Requests

The request screen centralizes all of the requests a user has access to which include, but are not limited to, requests created by, assigned to, archived by, and departmentally associated with the user. They can be filtered by creator, assignee, status, request type, category, time left, date, and other key fields defined by the end user organization.

Creating a new request is simple. The user simply selects a request type from a predefined lists and steps through the workflow. The workflows can be built very intelligently such that whenever the user selects an option, all other options are filtered accordingly. If the user selects a product that can only be supplied by three vendors, only those vendors will be available in the requested vendor drop down. Alternatively, if a vendor is selected first, only the products the vendor offers will be available for selection. Products can be limited to budget ranges, vendors to preferred status, and so on. Every piece of information is used to determine what is, and is not, needed and make it as simple as possible to the user. If the vendor is not preferred or the product not preferred, and there is a preferred vendor or product, the workflow can be coded to proactively alert before the request is made. The buyer can also define any quotes, certifications, surveys, or other documentation required by the supplier before the PO is cut. (And then, once the requisition is approved, the vendor work stream will kick-off). And, once the vendor work stream is complete, the final approvals can be made and the system will automatically send the purchase order and push the right documentation into the right systems.

Vendors

Vendors provides the user with central access to all loaded organizational vendors and provides a quick summary of onboarding/active status, preferred status, number of associated products, # of associated requests, and total spend. Additional summary fields can be added as required by the buying organization.

Documents

Documents act as a central document repository for all relevant vendor, product, and Procurement related information from request through receipt, vendor onboarding through offboarding, and product identification through end-of-life retirement of the final unit. Documents have categories, associated requests, vendors, and/or products, status information, dates of validity and other metadata relevant to the organization. Documents can be categorized into any categorization scheme the buying organization wants and can include compliance, insurance, NDAS, contracts, security reports, product specifications, product certifications, sustainability reports, and so on.

Analytics

The analytics component presents a slew of ready made dashboards that summarize the key process, spend, risk, compliance, and supply chain inventory metrics that aren’t available in any individual platform. Right now, there is no DIY capability to build the dashboards and all have to be created by opstream, but opstream can create new custom dashboards really fast during rollout and you can get cross-platform insights that can include, but not be limited to:

• process time from purchase order (e-Pro) to carrier pickup to warehouse arrival (TMS) to distribution time to the retail outlets (WIMS)
• contract price (CMS) to ePro (invoice) to payment (AP) as well as logistics cost (invoice) to tax (AP) to build total cost pictures for key products relative to negotiated unit prices
• risk pictures on a supplier that include financial (D&B), sustainability (Ecovadis), quality (QMS), failure rate (customer support), geolocation (supply chain risk), geopolitical risk (supply chain risk), transportation risk (OTD from the TMS), etc.
• compliance pictures that pull data from the insurer, regulatory agencies, internal compliance department, and third party auditor
• supply chain inventory metrics that include contractual commitment (CLM), orders (ePro), fulfillments (inventory management), current inventory (inventory management), commitments (ERP/MRP), etc.

In addition, since all data is available through the built-in data bus, if the user wants to build her own dashboards, she can push all of the data into a (spend) analytics application to do her own analysis, and with opstream‘s ability to embed third party analytics apps (PowerBI for now, more coming), the user can even see the analytics inside the opstream platform.

This is the second main differentiator of opstream a user will notice. The founders realized that not only is data key, so is integrated analytics and they built a foundation to enable it.

Which leads us to the third and final differentiator you don’t see, the data model. The data model is automatically discovered and built for each organization as their systems are integrated. Beyond a few core entities and core identifiers upon which the data model is automatically built and generated, opstream doesn’t fix a rigid data model that all pieces of data need to map to (or get left out of the system). This ensures that an organization always has full access to all of their integrated data upon which to do cross-platform analytics on process, spend, inventory, and risk.

CONCLUSION

opstream understands there is no value in intake or orchestration on its own, and that for it to be relevant to Procurement, they have to do more than just connect indirect S2P systems together. As a result, they have built in support for direct, dynamic data model discovery, and integration with end-to-end enterprise systems that power the supply chain, allowing an organization to go beyond simple S2P and identify value not identifiable in S2P systems alone. As a result, they should definitely be on your shortlist if you are looking for an integration/orchestration platform (to connect your last generation systems to next generation systems through the cloud) that will allow you to increase overall system value (vs. just increasing overall system cost).