We manage a process in Jira and need to share the results of the process with a wider audience, how can we do this in an inclusive manner? By inclusive, I mean- with the people in our organization that are not Jira. We’ll see here how integrating Jira with Confluence might be the best way to do that. This integration brings you the best of two worlds. A structured process in Jira, and full transparency on Confluence. Let’s see how this works in a supplier management process.
When designing an internal service procedure, our first focus is the process. Exactly like in the case of an IT support desk, we create a predictable flow for submitting and fulfilling requests on time. What we often miss is the second part. Requests result in data that has long-term value for the team.
- In a suppliers onboarding process: The process intake is requests to approve a new supplier. An efficient process gets them onboarded before they need to start. The second part is to spread the word: anyone who needs to buy needs to know who our approved suppliers are. As default, we prefer to buy from approved suppliers that were vetted by other people in the organization.
- In a hiring process: The process intake are requests for new hires. With a good process, we’ll have the perfect newbie sign within six weeks. The second part is to link this information to the list of staffers. When someone signs, they need to appear on our employees lists.
Are you using Jira Service Management for Enterprise Service Management? This second part of sharing the process results with everyone becomes easy. And no, you do not need to buy everyone a Jira license to achieve this. This is true even if most of your team does not have a Jira license.
We’ll deep dive to see how Confluence with the Jira Snapshots app can be the 5 minutes route for solving this second part of process optimization.
A quick overview of the suppliers’ management process in Jira Service Management
Jira Service management (JSM) is a very effective platform for supplier management. Especially for growing organizations that need to evolve more structured purchasing habits. A supplier management process can help them scale up without losing control.
Adding a new supplier is one of several request types available on the finances team portal. There are also requests to create orders, change the scope for a supplier, and others.
Let’s first look at how to configure JSM for supplier management. In the next section, we’ll see how to share the list of approved suppliers with everyone. Yes, even if most of your team is not on Jira. The suppliers’ management process uses a new custom Jira issue type. A “Supplier” issue type. We have a single Supplier issue for each supplier. This issue transitions through several statuses:
|TRIAGE||The request for a new supplier has just landed in the service desk.|
The finances team needs to review it and decide how to proceed.
|IN APPROVAL||The request for a new supplier has just landed in the service desk.|
The finances team needs to review it and decide how to proceed.
|APPROVED||All required people have approved the supplier.|
|IN REVIEW||In some cases, suppliers that have already been approved need to be re-evaluated. For example, critical suppliers may require an annual review.|
|CANCELLED||This supplier was rejected or is discontinued.|
|WAITING FOR CUSTOMER||Action is required from the user who requested to approve this supplier. For example, during the TRIAGE status, the submitter is requested to add more information about the supplier.|
We collect a lot of information for each supplier: administrative, financials, legal and more. Most of it is only used internally- by the finances team. But only few data items are of interest to people outside of the finances team.
A good way to manage such a situation- where you have a lot of data items that are only used by the service management team is to use a form. This avoids Jira configuration from an explosion of fields. It also makes it easy to adjust over time because the form is configured by the project team.
As for the data that everyone needs access to, these are configured as Jira fields:
- Summary: This standard Jira field is the name of the supplier. It does not need to be the legal name- it should be whatever the popular name of the supplier is.
- Department: the department that is responsible to vet the supplier and doing most of the transactions with them.
- Description: the scope of purchasing from this supplier. Any other free form information.
- Sponsor: the main contact person within our organization.
- Next review date: the date when a re-evaluation of this supplier is due.
Suppliers list for anyone who needs to buy: Sharing Jira data with Confluence
We now have an epic suppliers list management process. It will be a miss to need to answer a constant drip of questions like:
- Who do we buy printer papers from?
- Where to order catering for our team party?
- Where can I get an extra outsourced development capacity?
Much better would be to have a list of suppliers that anyone can use whenever they need to buy something. It’s a non-issue if everyone is on Jira. You create a shared filter or even a dashboard. But how to do this if many people are not on Jira?
One option is to go old school: export the list from Jira and put it somewhere that everyone has access to. Repeat this to keep the list up to date. If Confluence is your central hub then you can avoid old-school and go for an easier solution. Use the Jira Snapshots app for a stronger integration of Jira with Confluence. It’s a bit like using the native Jira Macro in Confluence with one important difference: Jira macro will show an empty table to anyone who does not have Jira access. Jira Snapshots is different because it shows exactly the same data to everyone. Anyone with view permission to Confluence sees the same list.
Two configurations control the content of the suppliers list in Confluence:
- A criteria to filter select the suppliers issues. Define this using the powerful Jira Query Language , like so:
project = SUPL AND issuetype = Supplier AND status = Approved
- The list of fields. Each field generates a column in the report. Custom fields are also supported.
There is an advanced option and we’ll mention it here. If contracts are also managed as Jira issues, then the table in Confluence could include also the contracts of each supplier. This is because Jira Snapshots supports multilevel reports. It squeezes even more from the integration of Jira with Confluence.
Squeeze every bit of value from your Jira investment with Confluence.
Jira Service Management is the ultimate platform for internal service desk. From IT to finances to human resources and all the rest. But do not settle for a 90% solution. Leverage the data from Jira issues and share it with everyone in Confluence. This will put more power in the hands of your users, and create more time for you to focus on the real problems.