Utilizing Scrum for non-Software Development

Concepts like "user story", "epic", "task", and "bug" can't be found in the Scrum Guide. In Scrum, any work needed to improve the product is a Product Backlog Item. Sometimes, teams may find it helpful to differentiate between different types. Using "epics" to describe large pieces of work that need to be decomposed or distinguish between "stories" and "bugs" to differentiate between desired features and fixing problems. However, the Scrum framework doesn't make this distinction. I would defer to the team to help define which terms best help them understand, order, and do the work.

What the team needs to come up with, every Sprint, is a Sprint Goal and a forecast of work. The items on a Product Backlog can be structured however the team likes, as long as they facilitate this conversation and enable the Product Owner to account for value.

As @Thomas stated, there is nothing in the Scrum Guide (https://scrumguides.org/scrum-guide.html) that dictates how items that make up the Product Backlog have to be created or named. In most of the teams I have worked with the desired format is to describe the problem that needs to be solved in any way that best conveys the message. I don't know if I have ever worked with a team that actually used the "As a <>, I want <> so that I can <>" format. Create the item in any way that can completely and clearly convey the need and accurately portray the work that will be done.

As for whether your team is a software development team or not, it doesn't matter. The Scrum framework is intended to be used by groups that have complex problems that need to be solved and can be done so incrementally so that feedback and adaption can occur frequently. I worked at an organization where the Scrum framework was used by the Events team. They created and managed trade shows for large number of vendors, attendees.  They found it very useful.  I also have an acquaintance that coaches Human Centered Agile to companies. She has used Scrum for many of her implementations in human resources/people administration divisions.

Scrum Guide dose not any terms you have mentioned neither it dictates them. But Scrum events like Sprint, Sprint planning, Sprint Review, Sprint Retrospective etc and artifacts like Sprint Backlog or Product Backlog and Product/Sprint goals. It dose not recommends terms like User Stories, tasks etc. You can research (https://scrumguides.org/scrum-guide.html) for details.

 It seems people are often getting hung in with names.  For example, they currently use User Stories like Tasks.  Anything that needs done is a User Story.  Epics are basically unheard of.

Hi Lance, in your situation the best option is to make them understand what Epics, Stories, Tasks mean and probably get them onto the same page so that there is some standardization (may be document it if needed). You may have to go one step ahead and review if they are being used as agreed as people might go back to their old ways of working.

As others have commented Scrum just says product backlog, sprint backlog and the team should decide on what they would like to use.

Good points have already been made. Scrum is intentionally lightweight and flexible, allowing it to adapt to various environments.

One of the key strengths of Scrum I like, is its emphasis on team self-management and empowerment. This means the team has the autonomy to determine how best to approach their work, including how to label and organize tasks. The specific terminology is less critical than ensuring the team has a shared understanding of what each term means and how it supports the workflow.

Introducing "Epics" as a way to group related tasks might help with larger objectives. However, what matters is not adhering rigidly to terminology but ensuring everyone understands the purpose behind the terms and uses them consistently.

The two aspects I personally like about scrum: team self-management (already mentioned) and working towards a Minimal Viable Product (MVP). These principles help teams prioritize and deliver value iteratively, no matter what the work is called or the environment they operate in. Scrum is intentionally non-prescriptive, so adapt it in a way that best serves your team's goals.

Work item granularity is one thing, you can name those items however you like. Currently the Task>Story>Epic>Theme or whatnots is a pretty popular one. 

I've been working with ITIL for some years and the nomenclature was different, yet it still followed a set of composite elements feeding to one bigger entity.

Ticket > Incident/Major Incident > Problem

To relate, I've been working with R&D hardware and Scrum was a bad idea for this type of work. 
I've read Scrum for Hardware by Mr. Paolo Sammicheli but imo it was of a limited use, even though the content was ok. 

So nomenclature is one thing, the work process being used is another story.