I am thinking about a way to track improvements to our machining processes. When someone thinks of a way to decrease machine time, they write it on a form. Someone reviews the form and attempts to implement the changes. Generally the changes are to the machine programming. You know, remove a pause here, increase a speed there. After the changes have been tested and verified to not ruin everything, then the change is officially implemented by changing the programming for the machine.
We would like a way to track these accumulating improvements so that we can have a better idea of how to decrease (or increase) operation times, and so we can see how much money and time was saved based on these improvements.
My thought was to just start up a new UD table, linked on Part, Assembly, and Operation. Then I can begin storing the improvements in Epicor. Once I have enough data collected, I would start generating the report that shows the suggested new time per piece for each part/op.
Before I dive in headlong, does any feature like this exist in Epicor now? Has anyone else implemented a similar tracking system? Any bright ideas or warnings against my approach?
Thanks for your time!
Nate
I have but not with Epicor.
Microsoft Forms and Sharepoint site and Azure dev ops project to track the work items as cards.
User would fill out a Form and then using Power Automate fills out the sharepoint list and also creates an “issue” card on the dev ops project.
We currently use this process for our SDLC system change requests, but the same concept could be used for suggestions too.
I like @Craig’s recommendation a lot. If you want to get fancy, when the change request is “accepted” (pull request, whatever), then push the text to a Memo for the Part or Rev using REST/Efx.
For GitHub Actions, you can have a local runner on-prem. The machine that the runner is using can execute PowerShell. So if you download the text from Git, then you can call a PowerShell cmdlet that makes the REST call into Epicor.
I have been working on a job/part history for a few years - tweaking every year.
Lately I have been experimenting with standard deviation on the population of the jobs for the job.
The key is to take the estimate time (per job or operation) as your baseline and record the % difference of the actual time posted.
Create a aggregate grouping to get the standard deviation in a BAQ.
Tracking average will also get you how close your estimates are to actuals.
The whole of idea of the standard deviation is of time is if the processes are in control.
Small standard deviation means that process is in tighter control.