Warning… I am going on a little rant here… wanting to correct bad practices that are continually put into place by various programmers, system “designers” and users.
Situation:
Customer “Walmart” has special rule for order entry that says “Lead Time = 3 days for all standard products”.
So… the user asks for BPM that looks for Walmart Customer ID (problem 1) to enforce the 3 day rule (problem 2) for all “standard products” (problem 3).
Programmer’s “solution”:
they write a BPM that looks for Walmart user ID (problem 1), just like the user requested.
They hard code a 3 day lead time (problem 2) for all products on the order that are a standard product based on the following rule:
They have a list of Product Groups (problem 3) that are “Standard” and hard code that into the BPM.
Problems with the Solution
Problem 1: Programmers should NEVER hard code a Customer ID into a BPM… the reason is that customer IDs are allowed to change in Epicor (by hard coding customer ID, you just deactivated base functionality). The customer NUMBER never changes… BUT WAIT, there is more… After the programmer got done, the user said, “Can you apply the same rule to Target Stores too?”… DOH!.. we have to find the BPM and add another customer (When will this end?).
Problem 2: The user gets a call from Walmart, and they are changing their lead time requirement… it is now 2 days (but target is still 3 days)… this hard coded lead time is turning out to be a bad idea. Now we have to make special hard coded rules for Target & Walmart.
Problem 3: Programmers should not hard code a list of product groups (or anything else like this)… Tomorrow, the accounting department adds several new product groups that are also standard… now we need to update the BPM again.
CORRECT Solution: Soft Code whenever possible… when the user asks for a solution, the programmer/designer should not simply give the user what they asked for… they should look for the root cause of the requirement, and apply best practices…
A new UD Field or Fields should be added, in this case, to the CUSTOMER table that holds Mandatory lead time… This way, when Walmart changes the lead-time, it is a simple date change… when Target asks for the same solution (but different days) it is just another data entry point. This solves problem 1 AND problem 2
a new UD Field should be added to the Product Group to hold the “Standard Product” flag. This way, as new product groups are added that are “Standard” the flag can be set to true. This solves problem 3.
The BPM would no longer be hard coded… it would look up the customer (by customer number) to determine if the customer has a leadtime set… then if it does, it would examine the product group to see if it is standard… then it would apply the leadtime.
Alternately, there could be a list of product groups added to the Customer table holding the list of product groups… but this all gets into advanced design. The point is… this should all be Data Driven… not hard coded.
Rant Over! Your turn to rant.(We now return you to your regularly scheduled program)
Sure but it’s 15 min vs 5 hours. No doubt configurable solutions are the best solutions, no argument there, but hey time is money and until we qualify a problem with a frequency I’m spending as little time as possible on it. Being a one man band with a list longer than War & Peace I’m not solving for situations that may never arise. I have to stop myself from over-engineering in the interest of time. Again your solution is certainly the best but unfortunately is not always the most practical or has the best ROI. It’s very much situational but something for sure to consider before charging forward.
It’s going to sound like fence-sitting but I too am a one man show with War and Piece (outlined on multiple post-it notes) to finish. I do a bit of both. Certain requests just scream for @timshuwy methodology and other just deserve a quick-fix solution because I know it will change again in a few months. I figure about 60% of my solutions are configurable, and the rest are simple mods (or band-aids until Epicor fixes them).
@jgiese.wci & @MikeGross, yes there are definitely times when a shortcut can be done… but in my case, I may have oversimplified the illustration, the Solution included 8-10 hard coded BPMs that were not all documented… so when Target came in, we had to find all former references to Walmart.
The idea is to take a moment an actually analyze the situation before jumping to a solution. Data driven will always be more flexible. (This COULD also be done with no custom fields by using "Customer Group or some other field that may be used for this purpose).
Isn’t there a field called Delivery days for that purpose?
We added a custo in the SO form that when the need by date changes, we read the delivery days of customer and reduce the date accordingly for the ship by date.
And better yet, we calculate the delivery date using the calendar so we do not have a delivery date during week-ends or holiday… (I actually wonder why this functionality is not vanilla from Epicor…to establish valid shipping dates… )
delivery days is defined as “how long it takes to deliver” said product… not necessarily a leadtime for the product (which may include additional production time).
And Yes, i totally agree that the delivery days SHOULD look at the calendar, and I too have done same type of customization.
I once spent WAY too much time setting up all the customer facing reports (Quote, Order, Packer, Invoice, etc…) to use a linked graphic. And then wrote instructions on how to “mass update” the company logo on those forms by simply replacing that image file all the forms were referencing. It was a slick solution. But not worth it in the end, as one of the logo changes required a significantly sized image box.
And I often find that asking whomever made the request, extra questions like, “Will all customers assume the lead time is in calendar days? Or should there be a flag to indicate the customer uses business days?” only leads to more confusion.
Most people want their specific problem solved. Looking towards future issues, is something not enough people concern themselves with.
One more thing that effects when a well planned solution without any “hard codings”, is needed, is if you have multiple people doing/maintaining these integrations.
I too am a one man shop, so the concern about somebody else being able to easily update one of my solutions, isn’t that pressing for me.
I do prefer to do things like @timshuwy describes and I agree that sometimes to get a quick solution is better than no solution. What I try to do in these situations is to document the solution and put a record of the technical debt somewhere. I used to be a one-person shop but now there’s a few others who help out. I can tell you that all the time saved by one of their solutions can be completely eaten up when I had to go in and change it!
We don’t do testing, documenting, etc. for ourselves, we’re doing it for those who come after us and don’t know what we did or why we did it.
Since I took over our Epicor system here, I’ve been on a quest to remove all hard coded values from all of our custom stuff. Like…what were the previous devs/admins of the system thinking??? Exactly the same scenario. Hard coded customer ID’s, sites/warehouse codes, part numbers. It goes on and on. I work to enhance the apps to add that general functionality to be controlled by the users, therefore they dont have to come to IT with “I need customer x to have this same function/logic as customer Y”. I develop the solution from the ground up and give the user’s the framework to make changes they need on their own.
totally agree with @timshuwy, i respect other people’s opinions, but do not agree with what they stated of excuses for using hard coding, also do not agree that the time difference is massive, it is obviously longer but robust and will save time in the future for the designer himself and others as well.
One man band but I want my end users to maintain stuff not least as I expect to move on and not be replaced. Agree with Tim, add UD fields or use the many data analysis grouping fields so that users can maintain themselves.
I feel it’s a pretty fair excuse. Interest of time is significant and you have to take into account the time spent on a minor change vs something that provides PI/CI. Again, optimally everything would be dynamic, but if I’m making a rule for a customer that is outside our market space and we likely won’t have more of them I’m not wasting the time, until 1. it’s necessary and 2. we have worked with them more so when I do customize it we don’t have to throw half of it away later. I’m of the belief users only think they know what they want, you can only ask so many questions to get them where you think they need to be and the first cut will still be 50% off the mark.
We live in an imperfect world and if you can tell me you have everything coded 100% configurable with nothing at all hard coded in I would be quite surprised.
Tim’s example would literally be the difference between 15 minutes and 4-5 hours (including damage control). By the time you do process discovery(vs a quick band-aid), add the UD fields and regen (maybe regen again becuase the first time decided it didn’t want to work), document the fields for CAB, fight with the two customizations because #anchors, deploy the customizations to production, listen to everyone bitch because their personalizations broke, train them on what they need to maintain that they will never remember (which is fine because it may never be used again) you will have blown 20x the time that could have been spent streamlining a production process.
My work queue P1. Every minute counts and if it’s a minor NVA rule i’m not going to give it the time of day over PI/CI.
Hi @jgiese.wci,
i am not going to argue with you mate, you have much greater experience than me, i am only saying my opinion, in my 8 years experience in designing ERP solutions, always had to go back and update/improve/ or upgrade my design to do more stuff or to cover uprising changes, and always found that configured design is the best solution even for small project, i only use hard code if there is an emergency catch up as temporary solution until i finalize my solution, then i go back and replace it.
Not really looking for a fight lol, I’m just trying to make sure, as much as the golden goose of perfection sounds nice, people think about the needs of their company and what will get them the best bang for their buck. I will do things to my detriment and for sure not to the standard I would like them to be just to ensure what I’m working on has the ROI for my company that is required to keep us moving upward and onward. Sometimes we nerds can get so buried in the solution at hand we will forget about the literal bottom line. Just a balance is all I’m trying to convey.
)
me neither, i agree 