In the past year I’ve gotten much more involved in Epicor at our company, and as I learn more about how Epicor works I’m constantly faced with how do I pass this information to other people, and how would we train someone new that needs to know what we just learned. For anything custom / specific to our company, we document how it works(work instructions of how to use the features, communicate with others employees, and add required training for the work instruction), but when it comes to general Epicor knowledge I’m very unsure how to capture this knowledge, as documenting how Epicor works does not seem to me to be a cost effective solution and I’m unaware of where to find documentation that would have answered most of the questions I have had or would have helped me to solve most of the problems I’ve encountered(this forum is essentially where I’ve accumulated most of what I know). How do other small companies(there’s about 50 of us) solve this problem, how do you retain Epicor knowledge so other employees and future new employees can benefit?
I’ve found that flowcharts are a great training tool and really help when describing a process. It’s also helpful when changing a process to refer to the flowchart and record changes to a process.
If you’re looking for tooling, I’ve tried to get some traction going with Teams and utilizing OneNote and Wiki’s within those to act as living documentation. OneNote is awesome because its really easy to work with and flexible for screenshots, etc., unlike static Word documents.
The biggest thing I’ve struggled with is changing the culture from “IT owns the process” to “the business owns the process” for basically anything relating to technology. We are 27 people big, so at 50 I can imagine you have the same problems.
I am fortunate to have a lot of influence in how and when I do things, but I also have worked hard over the last few years to only take on projects that the business is bought into and assigns proper stakeholders. If they can’t commit to that, then neither can I.
Placing the responsibility of defining, understanding, and ultimately owning ANY ERP process on the business rather than the technical team will have long term benefits.
EUPs we used Epicor Knowledge Mentor.
KB we used a Helpdesk Software and entered KBs.
I’ve wrestled with how detailed to make instructions or notes, as there is a very good chance something will change (upgrade of Epicor version, change of our business processes, customizations made afterwards, etc…)
Some things are done so infrequently (like Physical Inventory) that well detailed instructions are essential, as most will have forgotten all the details from the last time it was done, a year ago. But even those are hard to get accurate, as you don’t do it enough to test your instructions. And even if the Phys Inv process in E10 doesn’t change, there can be changes to the real world parts of Phys Inv, like control of tags, who is doing data entry, do we move misplaced materials to where they belong, or use a blank count tag with the location they were found, etc …
And I’ve taught people how to do some things, but they do them so infrequently they most certainly forget how to do it, by the next time they need to.
It’s a pretty in-enviable situation. These types of challenges are going to be always there in small to medium enterprise, particularly if there is the underlying culture that as @Aaron_Moreng mentioned “IT owns the process” he really does hit the nail on the head with his comments.
Cost pressures are the other issue, if you don’t have agreement and budget for putting tooling and process in place, there is probably more to worry about than just getting the stuff out of your head so another resource can serve as a backup.
I totally agree when it comes to the mechanics of how Epicor works and documenting it so it’s easy for others to understand simple flow charts and pictures are a good way to go. In actual fact there are quite a few in the help and educations course documents that might be useful. There is a good one in the Packout manual which I used to refer to a lot.
That’s my 2c
Many good answers here. I often find companies concentrate on only one part of the documentation life cycle and that’s creation. Rarely do companies think about updating or discovery. PDF files are easy to create but a pain to update and nearly impossible to bookmark unless you break it down to one topic per document. Even then, it can be difficult to link to other documents.
Many companies are turning to some type of Markdown solution (which this forum uses) and then publishes the resulting HTML. There are several open source tools. Some organizations like Pandoc, while Microsoft uses DocFx for maintaining for their online docs which customers can make suggested changes through GitHub pull requests.
I think for the SMBs who have an M365 subscription and buy into the Teams concept, adding pages to a Teams site collection is not a bad way to go. It’s easy to update by the users, easily searchable, and even provides revision history.
What level of detail are you documenting things at? As an example do you have instructions like create a new order, or more detailed instructions saying open Order Entry, then click on …? Our work instructions are generally very detailed(telling exactly where to click).
I’m a bit stumped as currently we are short handed, we’ve got more projects coming in that we have resources to complete those projects… @Aaron_Moreng really seems to hit the nail on the head of departments not wanting to own their processes… @Aaron_Moreng what you wrote piques my interest, could you explain a little more about “I also have worked hard over the last few years to only take on projects that the business is bought into and assigns proper stakeholders.”. I think this is a solution to the problem I’m facing but I’m not sure I understand how you solved it?
As a general rule, I think showing basic navigation in screenshots is good and flowcharts/concepts are better. If the training is only to the UI at the time, we both know UIs change and if the people don’t understand the concepts of “why” they are clicking things, they will not adapt to change well. It’s also a nightmare to maintain the documentation if the training is too focused on where the user clicks on the screen. Flowcharts are helpful to show the conceptual activity as well as the functional activity required.
I do have detailed documentation, but it’s something I think we could have done better.
Regarding changing the company culture; it’s unfortunately not an overnight activity. I think it might be good to identify some of the strengths you can play to.
Who is creating the projects? The worst position to be in is one where you are expected to be handed a task output by a group where you weren’t involved in as a stakeholder along the way to guide decisions and give input.
I think you’re in a leadership position at your company, which is obviously a huge lever to pull on. You can use your influence to act as a mediator between the requester and the solution, vs. just providing the solution. I’ve have good luck getting buy-in by not doing everything for them and instead farming out even small tasks to the people requesting it.
So they want “X”, great! Let’s work together on defining all the things that go into X and you can start by documenting the request, work with development along the way to show progress, do the UAT, helping to train your co-workers on it, and ultimately acting as the SME for “X”.
If X was needed, this approach works really well. If it wasn’t needed, well it’s really not going to get off of the ground if you don’t do all those other parts for them.
A little red tape can be used to slow the process down and to get buy in. People ultimately want to help and be utilized. It makes them feel valued as well as gives them a chance to feel committed and proud of the solution they helped enact.