Same Part, Same Op, Multiple Resources

This is more of a scheduling question, so I do suggest that you go over some of the training material. It is a wide topic with many parameters that can affect the outcome.

** In the example below I am assuming that there is no Split Operation , 1 scheduling block, Finite and backwards scheduling options are used.

Let’s take an example:

Calendar – 5days x 16hrs

RscGroup – EM_01 (Printer)

Rsc EM_A1 (capacity 16hrs/day)

Rsc EM_A2 (capacity 16Hrs/day)

Part EDU_DCD requires the above RscGrp and requires 20hrs to run 20pc (1hr/pc)

There are going to be two demands (releases) for this part.

  1. The first demand for parts EDU_DCD is required in two days (from today’s date), The second demand is required in 5 days:
    The schedule would assign EM_A1 for both parts; by the time the first demand is satisfied, and the second demand is required, EM_A1 is available again.

image001.png

  1. Your demand for two parts is for app. the same period:
    The schedule would assign EM_A1 for the early release for 20hrs and EM_A2 for the later release for 20hrs, because EM_A1 has no capacity

I was wondering if I started off on the wrong foot by treating all of our printers as though they are identical/interchangeable when they are not. I guess it was a grey area for me because they seemingly all do the same operation but strictly technically speaking they do not.

In my example the resources are identical, this is why they are under the same RSC/G EM_01. I took this example to answer your previous question: “If you define all the resources that could possibly run that part, what resource is it going to schedule on”.

If your printers are not identical and you do not have the Capabilities module, then each printer should be its own Rsc/G & Rsc, and each part should be engineered to run on a specific printer.

Typically I advise that all Resources within a single Resource GROUP, are “Like” each other… meaning that they are typically interchangeable. That would mean that you would not put a 3 axis CNC in the same group as a 4 or 5 axis CNC. For Simplicity, I describe it as: “Never put a screwdriver into the same resource group as a hammer”… they are different resources.
BUT also note that if you have the Advanced Scheduling module, you CAN also create “Capabilities”… with capabilities, you can describe a particular capability, and then assign resources to those capabilities (along with how efficient they are at that capability. Then in your routing, you can specify that you need a machine (or person) with that capability. Because the capability can span multiple Resource Groups, this gives a lot of flexibility. Note that you can also prioritize your resources inside the capability. I believe that @Gil_V has implemented this to make some of his resources that were not in the same resource group usable when needed.

2 Likes

That’s just plain awful. Software should work for people, not the other way around.

How in Gods green earth do you expect a software company to write software that works perfectly for every single different business and business need?!?!?!? There is absolutely no way that this is possible in any way shape or form. The closest you will ever get to this is excel.

That’s exactly my point. Trying to meet every single business need, or even a substantial subset of them, quickly leads to the Inner Platform Effect. One of the worst things about inner platforms is the rare and expensive specialization of knowledge required to effectively use them. The cost of adapting an inner platform to meet your needs often exceeds the cost of developing your own specialized solution using general purpose tools that can do anything you want and for which expertise is cheap, plentiful, and highly fungible. (Yes, like Excel.) And sometimes it’s simply impossible to make the inner platform do what you need it to. And that’s terrible.

So you’re saying that people shouldn’t use Epicor, and instead spin up their own custom system?

I can’t speak about really big companies. But for the two companies I’ve worked for (hundreds of employees, low millions in sales) every day further convinces me that Epicor is massive overkill and yes, rolling their own solutions from scratch would have been better, faster, and cheaper by far.

Good luck with that.

Until the programmer dies or gets fired, or hits the lotto, then they are stuck with whatever pile of crap code was thrown together by whomever wrote it who I am sure documented everything perfectly, wrote perfect code, had perfect design and never made any mistakes.

The point of standardizing into a well known, well maintained, supported platform with a large community (like Epicor). Isn’t just because its better than a home grown system (which it is), it is because it comes with (checks notes) 49 years of brain trust and experience and a massive and thriving community base.

Furthermore that brain trust (and the software) pushes you towards industry standards which allows you to scale and inter-operate with others which is essential for growth.

Your custom thrown together home grown system that perfectly matches “your” business practices means that the software will have ingrained in it the ridiculous idiosyncrasies that companies tend to fall into which leads to stagnation and inefficiency. “We’ve always done it that way” even if “that way” makes no sense but the software allows it without complaint so why change?

I don’t know Kevin. This may be true for some specific domain logic for the company. But I don’t see value in most companies, especially smaller ones, writing their own GL, AP, or AR functionality from scratch. I wouldn’t write my own payroll system either. You would need a large staff working on code that has little to do with the main problem we’re trying to solve.

Developer turnover is a real concern, especially at smaller companies. That’s why we have DevOps best practices, which Epicor is notorious for not facilitating. And I can understand the assumption that an in-house system will be a thrown together pile of crap. The vast majority of developers are complete idiots. Sturgeon’s Law is real and explains everything. But simply recognizing this is a big first step toward finding someone who actually knows what they’re doing. I cautiously think I do because I’ve received compliments from other developers on how well-structured and understandable my code is, and praise from managers for my ability to dive deep into other people’s messes and fix things that “couldn’t be fixed.” What keeps it from going to my head is that I think talent and productivity exist on a logarithmic scale, and being in the top 10%, 1%, or even 0.1% doesn’t make you the savior of the world when there are thousands like you and some who tower over you as you tower over others.

But we still have to grapple with the fact that most people are idiots. Given the way big business operates, I have zero faith that their business practices are any better than the “ridiculous idiosyncrasies” of small companies that are actually thriving and producing high quality products. They know their business better than anyone. Why should they conform to the way General Motors does things? General Motors keeps needing bailouts. Why should they conform to the way Google does things? Google is suffering a massive crisis of competence that is painfully obvious even to non-programmers. And it’s often hard to believe that Epicor’s own idiosyncrasies were intentionally designed. This isn’t just a programmer’s perspective. I’ve heard plenty people with very different expertise, like accountants and production managers, express similar views of the constraints that Epicor imposes, its annoying quirks, and the complexity of getting it to work at all.

Above all, I cannot comprehend calling Epicor well known, well maintained, or well supported. I can only assume that anyone who views Epicor this way has never experienced the sublime joy of tools, platforms, and projects that actually are those things. I go home and work on open source projects as a hobby to remind myself how much I love programming and not feel so perpetually outraged and disgusted.

About the only positive thing I can say is that Epicor support is slowly changing for the better. Bug reports are actually being acknowledged, which is the first step on a very long road to recovery.

Not sure why this thread keeps growing, I’m going to shut it down. Seems like we are going down a rabbit hole and not really contributing to the user base at this point.
Thanks for the opinions and insights.

1 Like