RFQ workflows in Upchain

In this lesson, we’ll explore and build a supplier RFQ workflow and discuss how this enables collaboration with external suppliers.

Building an RFQ workflow

In this video, we’ll discuss and plan out an example supplier RFQ workflow and demonstrate its creation.

00:10

In this video, we'll discuss and plan out an example supplier RFQ workflow and demonstrate its creation.

00:18

So let's take a look.

00:24

Investigation requests fall into two categories, design and supplier RFQ.

00:31

Design types are meant to capture investigation type processes that stay within your organization,

00:38

such as scoping out initial designs, feasibility studies, incorporating customer feedback,

00:44

red lines from a shop floor technician, design change instructions, and so on.

00:51

Supplier RFQs are used when you wish to share information with specific external suppliers,

00:58

and have them send you a quote if they wish to work with you.

01:05

Importantly, when you create a new investigation request,

01:09

you can select any of the workflows that have been created regardless of their intended purpose.

01:15

Therefore, it is important that you name your workflows,

01:19

so that it is clear whether they are intended for design investigation requests or supplier RFQs.

01:29

There is nothing inherently different about planning a workflow intended to be used for a supplier RFQ versus a design investigation request.

01:40

The key thing to keep in mind is the sort of communication you wish to send to the supplier,

01:45

and correctly instructing them on how they should respond.

01:51

For our supplier RFQ workflow, we need to include the following steps.

01:57

An email must be sent to the supplier to notify them of the new RFQ.

02:03

It must be clearly communicated that they should review the attached data and if they wish to proceed, must complete two steps.

02:13

They must attach a quote to the item in the supplier viewer,

02:17

and they must mark their task as "Complete" in the Business Processes tab of the supplier viewer.

02:25

If they do not wish to proceed, then they can reject the RFQ in the same Business Process tab.

02:32

This will send an email to the RFQ creator and the project manager to let them know of the decision.

02:38

The workflow will end, and the RFQ is marked as "Canceled".

02:43

For these two steps, we are going to use the notification, decision, and update primitives.

02:54

Assuming they did wish to proceed, once the supplier completes their part,

02:59

a notification email should be sent to the RFQ creator and the project manager that the supplier has sent information back.

03:08

This will use the notification primitive.

03:12

The project manager should then review the documentation that they have received,

03:17

and decide if they wish to proceed or request further information from the supplier.

03:22

For this, we'll use the decision primitive.

03:30

If the quote is approved, an email is sent to the supplier indicating as such and to expect further communications in the future,

03:39

and the RFQ is marked as complete.

03:43

If the quote is rejected or sent back to the supplier, the supplier can then decide if they wish to attach something new,

03:51

update their quote or just reject the RFQ outright, which follows Step 1 above.

03:59

For these steps, we will use the notification and update primitives.

04:08

And of course, all workflows must have a start and stop primitive.

04:16

Let's build our workflow.

04:19

We're going to create it from scratch since our workflow doesn't really match the system workflow.

04:29

Let's call it RFQ supplier workflow to make it very clear that this workflow is intended to be used for the RFQ investigation request type.

04:52

We'll start by adding the start primitive and the stop primitive since they are always required.

05:01

And now let's begin building our workflow.

07:30

There is our happy path.

08:29

Now we simply need to connect all these primitives together.

09:16

This should give you another example of how you can bring in external supplier collaboration into your projects using a workflow in Upchain.

09:24

Using workflows like this allows for consistent communication,

09:28

that your suppliers can continue to expect from anyone sending these RFQs from your organization.

09:34

And full traceability of these interactions are stored within Upchain.

Video transcript

00:10

In this video, we'll discuss and plan out an example supplier RFQ workflow and demonstrate its creation.

00:18

So let's take a look.

00:24

Investigation requests fall into two categories, design and supplier RFQ.

00:31

Design types are meant to capture investigation type processes that stay within your organization,

00:38

such as scoping out initial designs, feasibility studies, incorporating customer feedback,

00:44

red lines from a shop floor technician, design change instructions, and so on.

00:51

Supplier RFQs are used when you wish to share information with specific external suppliers,

00:58

and have them send you a quote if they wish to work with you.

01:05

Importantly, when you create a new investigation request,

01:09

you can select any of the workflows that have been created regardless of their intended purpose.

01:15

Therefore, it is important that you name your workflows,

01:19

so that it is clear whether they are intended for design investigation requests or supplier RFQs.

01:29

There is nothing inherently different about planning a workflow intended to be used for a supplier RFQ versus a design investigation request.

01:40

The key thing to keep in mind is the sort of communication you wish to send to the supplier,

01:45

and correctly instructing them on how they should respond.

01:51

For our supplier RFQ workflow, we need to include the following steps.

01:57

An email must be sent to the supplier to notify them of the new RFQ.

02:03

It must be clearly communicated that they should review the attached data and if they wish to proceed, must complete two steps.

02:13

They must attach a quote to the item in the supplier viewer,

02:17

and they must mark their task as "Complete" in the Business Processes tab of the supplier viewer.

02:25

If they do not wish to proceed, then they can reject the RFQ in the same Business Process tab.

02:32

This will send an email to the RFQ creator and the project manager to let them know of the decision.

02:38

The workflow will end, and the RFQ is marked as "Canceled".

02:43

For these two steps, we are going to use the notification, decision, and update primitives.

02:54

Assuming they did wish to proceed, once the supplier completes their part,

02:59

a notification email should be sent to the RFQ creator and the project manager that the supplier has sent information back.

03:08

This will use the notification primitive.

03:12

The project manager should then review the documentation that they have received,

03:17

and decide if they wish to proceed or request further information from the supplier.

03:22

For this, we'll use the decision primitive.

03:30

If the quote is approved, an email is sent to the supplier indicating as such and to expect further communications in the future,

03:39

and the RFQ is marked as complete.

03:43

If the quote is rejected or sent back to the supplier, the supplier can then decide if they wish to attach something new,

03:51

update their quote or just reject the RFQ outright, which follows Step 1 above.

03:59

For these steps, we will use the notification and update primitives.

04:08

And of course, all workflows must have a start and stop primitive.

04:16

Let's build our workflow.

04:19

We're going to create it from scratch since our workflow doesn't really match the system workflow.

04:29

Let's call it RFQ supplier workflow to make it very clear that this workflow is intended to be used for the RFQ investigation request type.

04:52

We'll start by adding the start primitive and the stop primitive since they are always required.

05:01

And now let's begin building our workflow.

07:30

There is our happy path.

08:29

Now we simply need to connect all these primitives together.

09:16

This should give you another example of how you can bring in external supplier collaboration into your projects using a workflow in Upchain.

09:24

Using workflows like this allows for consistent communication,

09:28

that your suppliers can continue to expect from anyone sending these RFQs from your organization.

09:34

And full traceability of these interactions are stored within Upchain.

Key takeaways

  1. Creating a workflow for supplier RFQs is no different from creating any other type of workflow. You must first plan it, figure out the appropriate primitives to use for each step, and then finally build it in Upchain.
  2. Workflows meant for supplier RFQs are only distinguished from workflows meant for design IRs based on their name. In other words, any workflow can be selected regardless of the IR type chosen.
Was this information helpful?