Depends on what your timeline is for changes, but you can also learn how to use it and do it yourself.
My experience is that if an org decides to use <HIGHLY CONFIGURABLE TOOL> then they will do it wrong the first time without external assistance. This holds true even for popular tools like Postgres, AWS, Terraform, or even Git.
Anecdotally, I don't know of any tool that is highly configurable that makes it easy for users to set it up and then scale it over time without learning the specific domain knowledge. Jira is no different in that sense. If you have an example of a tool that bucks this trend, please share it, I would love to play with it and see what I can learn about how to better serve users in this type of use case.
I feel that Jira first adds a lot of restraints and red tape, and then makes those highly configurable. I prefer tools that don't have the constraints in the first place.
Ie if in the middle of the sprint a developer finds that some tickets are stuck waiting for some other team and he wants a column on the board to make that visible, he should just be able to add the column.
In Jira if I accidentally put the wrong issue in Done, I have no idea how to get it out... It's the complete opposite.
A physical whiteboard with post-its is rather good. You can use different colors, if each team member has one magnet with his/her name then it can't be on multiple tickets at once, you can draw lines and write words wherever, it's very flexible.
What an online tool should add, besides corona compatibility, is being a good issue tracker. Jira doesn't seem much different on that front compared to almost everything else I've used.
What Jira adds is lots of rules and constraints and imposed structure that gets in the way.
We are in the process of leaving it in favour of Github projects.
Re: the board thing, Jira has actually been trying to solve this problem for years now with a concept called Simplified Workflows. [1] This allows the project admin to create Statuses and adjust their workflow without needing to get a Jira admin involved. The problem with this approach is that every project does something completely different (often times even multiple teams within a project use different processes) and the people working to do higher level planning can't grok what is going on.
The rules get in your way, but as an entire org, they provide value. A lot of what we do is work with large orgs to actually enforce those rules top down on devs. The difference between our approach and most others is that while we agree with the idea of governance and top down rules, we drive the creation of those rules as a bottom up process. This way the devs get to agree on how they want to work, and as long as there is a degree of consistency, we get to tell management that this is the way forward, and we can now report on things while ensuring we're not getting in the way of the devs.
That's what we tried (our teams are self-organizing, as they are in Scrum, so we couldn't do it another way) but the things the teams wanted had hardly any consistency (partly because the products and projects are very different, partly because of the people).
This is where an experienced consultant can help. We often start with what you're describing here as the baseline, and then work to find a middle ground. I would say that 3/4 times we can find something that works for everyone. And it's ok that sometimes people need different workflows. Some Jira admins or managers trying to pull reports will be upset about this but they can be handled once you demonstrate why doing it this way provides more value to the org as a whole.
Large companies in many cases are systems in some local optimum of efficiency. If any part of the system improves, the overall system is worse off. Naturally, there is resistance to any change from the bottom. Change from the top is not done because they only perceive a cacophony of noise from below. Sometimes it is done in an existential crisis.
External consultants are kind of an organizational hack. In contrast to top management they can take the risk of being wrong. In contrast to the workers they are not part of the inter-department politics.
