8 Lessons We Learned Implementing Procurement in Jira

[Vladimir Horev _Raley_]

Hello, Finance people!

As a vendor of a finance app Raley Purchase Orders, we’d like to share with you some of the lessons we’ve learned in the field of procurement in Jira.

About four years ago, we were approached by one of our clients who wondered if it would be possible to do procurement for their company in Jira. In particular, they were looking to support purchase requisitions approvals. As experienced Jira developers, we knew the possibilities of this platform were almost endless and that it could definitely be done. We also knew Jira would be an excellent choice for an effective and efficient procurement system. However, we also knew that few things are ever as easy as they seem. 

Jira is complex and corporate procurement matrices are often demanding. Although we've now helped many businesses with implementation of their own custom procurement processes in Jira, the journey wasn't always easy. 

Since we know firsthand how challenging and frustrating it can be to implement a procurement process successfully in Jira, we wanted to share part of our experience with others in the community. We hope it will encourage others to give procurement in Jira a try. The following eight takeaways are some of the most important lessons we learned along the way. 

1. Jira Service Management Is the Best Option for Procurement 

The implementation of a new procurement process in Jira begins with what can be described as a difficult decision to make. There are several Atlassian applications from which to choose and each one has its advantages. 

Any Jira-type platform can be used to support an organization's procurement process. However, based on our experience, we found that we prefer Jira Service Management (JSM) over Jira Work Management and other options. There are several reasons for this. 

Firstly, Jira is known for being very flexible software, but with that flexibility comes with the cost of added UI complexity. The user interface of JSM is more streamlined than some other options, offering basic functionalities that are sufficient to get the job done. 

Additionally, many organizations that use JSM with service desks already have users who are familiar with the software and use it regularly to communicate with different support teams. Such users require less training on the new process, leading to a faster adoption. 

In contrast, Jira Work Management and other options continue to be mostly used by IT departments. Therefore, business team users may face a more difficult implementation of a procurement process with these platforms, due to their unfamiliarity. 

2. Jira's Support for Customizable Workflows Is Key

Many systems for purchasing have inflexible workflows, but Jira does not have this problem. It's important to take full advantage of this great feature and get the maximum impact from your implementation. 

When we began implementing procurement in Jira, we realized how important it can be for an application to truly support an organization's purchasing process. A typical procurement solution normally has a predefined workflow with only a few options for customization. 

Mostly these customizations are superficial and consist of adding or skipping an auxiliary step. The workflow remains tied to the overall logic of the software determined by its developers. Yet there are countless ways in which businesses run approvals, and many need more flexibility. 

This is where Jira really shines. Customized workflows, transitions and post-functions are the very backbone of Jira, and can be used to the fullest to create the perfect workflow. Here's just one example: 

Ordinarily a purchase request is created, filled in with data and sent for approvals. However, the management team introduces a preliminary verification step to improve the quality of requests and eliminate obvious mistakes that can lead to denials and create extra work. 

 With this unique customization, an organization benefits from fewer incorrect requests, faster approvals and less time spent on requests overall. The savings of time and money then benefits other aspects of the business. 

3. JSM Request Types Adapt Easily to Business Processes

Precise requests are important in finance, but it can be a challenge enforcing quality data collection from users. Not only is the right data required, it must end up in the right place on the form. This can be tricky when a form contains multiple conditionally dependent fields or description fields that are too vague. 

We have found that the JSM portal's combination of multiple request types, highly customizable forms and validatable forms is a great way to make structured requests to business support teams, including finance teams. 

Here are just a few examples of what custom request forms can be used to accomplish: 

• Introduce a new vendor with custom fields to better describe the supplier and run a unique vendor approval process.
• Request a change in data in a purchasing request that is currently locked for modification. (This is a helpful feature to have when working within stringent approval change policies.)
• Introduce a discount or rebate to an already approved purchase request. 
• Request a price change in the registry of products and services or associate a cost center with specific department(s). (A good form would allow you to look up the product and specify a new price along with the justification.)

Since each of these examples would function as a separate business process related to procurement, it makes sense to separate them into different request types. Even so, with JSM, users will still have the ability to choose what they need from a single service window — the JSM portal. 

4. Purchase Request Forms Are Complex 

A well-designed purchase request form is more challenging to build than many think. Basic Jira and JSM forms are sufficient only for a very basic purchasing process, because they are static in nature. Even many smart forms developed by third-party vendors that feature multi-row entries and calculated fields are inadequate, because they lack the context of the users' limits, budget restrictions, approval logic and so on.  

We found there are generally two ways to approach this problem: 

1. Develop a custom purchase request form with integrations to look up users, budgets, vendors, products, departments, etc. Custom implementation of an approval logic and the routing of approval requests to the appropriate approvers will also be needed.
   
   Here’s what we found a good purchase request form should be able to do:
   
   
   • Allow the selection of departments and vendors. 
   • Expose your product registry for picking up products and introducing new products/services. 
   • Include several order lines per request so that, if needed, each line can be associated with a different cost center from which users can choose. 
   • Have the ability to enforce company policies, such as newly added products and services being required to undergo different verifications for legal, security or other reviews before a purchase is permitted.
   • Include a purchase order request view that's able to calculate multiple taxes/totals and assign approvals depending on the data submitted for a particular request.
     
     
2. Or for an easier alternative, use a specialized app like Raley Purchase Orders that is able to support all of the requirements outlined in 1) above right out of the box.

As a caveat to this topic, one thing we learned not to do is to attempt to implement multiple line item support for purchase requests via sub-tasks. To start, this is not supported in JSM. However, we also found it to be a huge headache managing several tickets instead of one and keeping child issues in sync with their parent issues (such as totals and approvals). 

5. Tracking Budgets, Vendors and Products the Right Way Is a Must 

Another difficulty of implementing procurement in Jira is the question of how to manage data for budgets, vendors and products. A purchase request cannot really exist on its own. It has to be connected to the appropriate departments, budgets, vendors and products. Arriving at the right solution to this question takes a bit of thought. 

Like many, our first thought was that Jira custom fields could be used to manage references to this kind of data. The necessary processes would synchronize pairs of ID-label fields for budgets, vendors and products, and the user would then be able to pick them up from their respective custom fields. 

However, we soon discovered some issues. Jira custom fields that represent departments could not be connected to particular users without custom implementation. The same applies to budgets and department associations. Vendors would have too much metadata to store in a custom field. Plus, the potential of having to put thousands of products into custom field options would be a simply horrible idea from a UX perspective. 

We discovered a much better approach is to use JSM Assets for keeping track of the above-mentioned items. While JSM Assets support is only available with a premium JSM subscription and taking this approach still requires some custom development, it does provide a solid foundation for keeping purchase request-related data better organized. Synchronization of cached data with master data should also be simpler as JSM Assets has a REST API. 

However, there can still be other pitfalls with this approach. Resist the urge to sync everything related to budgets and vendors, but stay with the minimum data you need.. Adding another field into JSM assets is simple, but requires constant maintenance. The calculation of totals and aggregates should be performed by ERP, not Jira/JSM. Because while duplication of data is not good, duplicating behavior is even worse. 

Finally, we have also had success using JSM Assets to keep track of received goods and services once the purchase request has been executed. In this scenario, JSM Assets is just what the name implies — an asset management system. 

6. External Purchase Order Numbers Require a Different Process

Every purchase order needs a unique number to identify it. While it's fairly easy to work with such numbers in Jira, a lot depends on the procurement process being implemented. A new process with internally managed numbering (aka Jira issue keys) is simple, while an established external process will require a few extra steps. 

For companies that do not already have an established process for generating, assigning or managing purchase order numbers, we found that a good practice is simply to use the Jira ticket number for the purchase order number. This keeps things simple and helps with tracking further on in the process. 

However, most companies moving their procurement to Jira will already have a formal purchase order numbering system in place. These numbers usually come from a third-party system, such as Netsuite ERP. In this scenario, the external purchase order number needs to be assigned to the internal Jira ticket representing the purchase order. We found that a custom purchase order number field that can be set using a Jira Automation hook is a good solution here.

Another good practice when dealing with purchase order numbers is to permit finance team users to assign or overwrite the value in the purchase order number field manually in the issue view screen. This tweak is easy to implement using native Jira/JSM capabilities. The purchase order number should also be included on any PDFs of the purchase order that will be sent to the vendor to have a common point of reference. 

7. Building in Flexibility Helps Minimize Common Issues 

No matter how polished the validation process, procurement process mistakes are inevitable. Miscalculations, typos and more can make even a streamlined process in Jira seem tedious. Building in an ability to update the data can help minimize delays and unneeded refusals. A dedicated role that can edit purchase requests or orders when they are locked for modifications is a must. 

One of the most frustrating scenarios is when a mistake is discovered after a purchase request has made it through a long approval process and received the final okay by C-suite executives. We have found that when a typo overestimates the amounts or description of goods or services needed, most companies prefer to have the ability to edit the request (instead of being forced to cancel the order and start over). Having a finance team member who is able to intervene in such cases speeds up the processing of requests and saves time for busy executives.  

Built-in flexibility can also minimize common issues such as a key approver falling ill or important Jira tasks being overlooked. Permissions can be granted to allow the modification of an existing purchase order as well as shortcuts for approving or rejecting it. A built-in system for reminder email notifications can minimize mistakes such as a user forgetting about a pending approval or the need to re-assign the ticket to the next link in the chain of approvals. 

The key to building in such flexibility is transparency and accountability. Modifications to an already locked purchase order should be auditable, such that it is possible to document which authorized user has made the change, view what changes were made and ensure the data is preserved automatically. 

8. The Right Approval Types in the Right Order Is Key

Approvals are central to any procurement process, but how they are handled is frequently a topic of debate. Key questions include which things must be approved and in which order they should be approved. 

Our experience has given us some insight on which best practices to follow with the approval process. While each company will have different needs, we most often see customers using the following approval types: 

• New vendor
• New product/service
• Department (such as requests originating from a specific department)
• Budget or project 
• Program (particularly when an expenditure exceeds a predefined threshold)
• Gross amount-based approvals

Some companies use all of these approval types and others use only one or two. If multiple approval types are required, we found that the following order is normally best: 

• New vendor approval
• New product approval
• Department approval
• Budget approval
• Program approval
• Approvals based on gross amounts, in ascending order 

Gross amount-based approvals normally need to ascend up the hierarchy of approvals to a level that meets the request's gross total. Several user profiles might be involved in approving a purchase request with the same upper limit. 

Notifications of approval requests should usually be sent out in the same order as the requests themselves. That may mean sending out a batch of emails for each approver in the same approval-type group. However, notifications for gross amount-based approvals seem to work best following the same hierarchy as the approvals themselves. For example, only after a CFO and Vice President receive a notification and approve a request should a notification email be sent to the CEO. 

More Lessons to Learn?

We have definitely learned a lot over the years implementing procurement processes in Jira and JSM, but there's still always more to know. We're curious what lessons others in the community have learned.  

Please share your own experiences. How did you approach your implementation? What worked and what didn't?