Hello All,
When someone asks for a customization or BPM/Data directive, what are some of the first questions you have? Do you usually end up doing the customization?
Are there any good reasons why you should or should not customize something? Any principles you have followed to determine whether you should proceed with a customization?
Would love to get some commentary on both sides of it.
Great question @utaylor!
First and foremost, is this request for something only going to benefit one person, or is it a legitimate enhancement to a business process? This question is meant to spark a wider discussion.
Second, does this request fit with how we run our business?
Third, what resources are required (can I do it myself in a few hours or do I need help or a lot more time)?
After those answers the path becomes a lot clearer.
A few obvious ones:
Does the functionality already exist?
Does the functionality affect other people\processes?
What problem does it solve?
I should probably also have addedâŚ
Did the requestor remember to bring donuts?
Bribery can get you anywhereâŚ
Hahah, thank you for your input!!!
Always the first question! Thanks for your input!
How much time will it save? Is it getting rid of an annoying pop-up for one user, or automating a multi-step process that a team robotically does daily?
Sometimes doing a customization that doesnât show much âbenefitâ on paper gets a lot of good will. Internally, we support our users, even if itâs a cosmetic change that doesnât show an ROI. But yes, we do have to say no also!
Nothing too formal, I just tend to categorize requests into general âlevelsââŚ
Level 1 - requests for BAQ, dashboard or report. As long as it is obvious to end users it is a non-standard view and the labor hours are approved by a manager, then I donât have much concern. Low risk, few consequences beyond system clutter. Iâm not even sure I consider these to be ârealâ customizations.
Level 2 - email alert requests. I investigate more. A little more care and resistance than for level 1 - since there is at least some risk of things going wrong,
Level 3 - minor form/process customization requests less than 8 hours labor. e.g. setting defaults, modifying/adding gridviews, automation, etc⌠This is where I start getting more serious and really âscrutinizeâ. i.e. ask for meeting (donuts) and try to verify the change REALLY makes sense. If a decision to proceed, then I always develop in a test system, thoroughly document and urge manager(s) to verify functionality and sign off on schedule deployment and end user notifications/training.
Level 4 - form/process customization requests requiring more than 8 hours labor.
This level and above Iâll ask many more questions, consider consequences, offer resistance⌠to the point of annoying managers.
In general I try to consider things from different perspectives
This is a great question.
I donât have all the answers of course, but I can speak from experience (prepare yourself for my ramblings).
In my early days here, I was (still am, but we are in the process of implementing a different ERP now) the sole developer after implementation. I took any and all customization requests in an effort to please people and increase adoption.
This was also with little regard to assessing whether base functionality existed to service the request or if training was needed.
What ended up happening was a jumbled mess of âfeaturesâ that were requested at one time by someone and the âfeatureâ became the official process.
This had the short term effect of gaining peoples confidence in the system (âwow, that little quality of life fix made my life easierâ), but had the long term effect of branching and fractured processes and mounds of technical debt.
We ended up with a system that, while custom tailored to the lowest common denominator, was technically complex and difficult to maintain. It forced me into a position of being the master of knowledge on both the business process and the technical processes used to support it. Not fun.
With this new implementation, the implementation partner analyzed our processes through lots of interviews and wrote up a high level business requirements document (BRD) for each functional area. The BRD does NOT include any solutions, only the requirements.
I feel writing a BRD for the functional area is an excellent way to communicate what needs to happen and separates the solution entirely from the requirement. Of course, some requirements might require a custom solution, but leading with the question of âwhat does the business needâ is much better than âhow can I solve this particular problemâ.
Additionally, having a BRD to review with a council of decision makers will also help to put up some speed bumps. The council will assess the BRD, decide if it is indeed a requirement, and then investigate if it is solved with people, process, and last but not least technology.
Lots of good answers here already.
I will say personally, how familiar I am with the requestors day to day informs my decision on how much I will âpush backâ on the request. The more I know, the more aware I am of the problem they are trying to solve, if something already exists, if the request is frivolous, etc.
If itâs an accountant (hazy mystery for me), for example, and what they are asking for is simple enough, I will usually just do it no questions asked
My first question is âwhat are you trying to accomplish?â. Digging into this can help determine if there is already other functionality to get to the goal, are they trying to recreate something just because itâs the way it was always done, or this is a genuine need with business value.
Next is evaluating the impact on the adjacent functional areas. Often a change in one area will cause ripples for others (e.g. changing sales order picking can affect shipping).
Third, what is the ROI for the overall business. Will the customization cost less in time/dollars/effort than the benefits of the customization?
Last, I prioritize the customization among all other requests to determine when it could be completed. Sometimes if a customization cannot be developed for a long time, the need will be pressing enough for the requestor that they will seek another solution or possibly a change in their process.
Well, hereâs my process:
WHY? Whatâs the reasoning behind it? Where does it fit in the process? Who does it benefit? How does it make your life easier? When you can get a really good picture of what is being asked and how it all fits in you can better address the issue and build out a solution. It may involve ideas and concepts which the asking person didnât even consider but you can bring up for consideration. Maybe a BPM isnât the best way to go to address the core issue. This is an action best taken interactively vs a written e-mail or form. You can ask questions and get immediate answers to rule in/out a line of reasoning.
What does it affect? If itâs altering or affecting data in the database BE CAREFUL! Once altered it maybe a bear to âfixâ if implemented and you hear the dreaded âoopsâ. If just cosmetic - MUCH less consequences.
Scope. Just about every time you implement a new ERP you can be almost 100% guaranteed that youâll get the question of âCan we re-label ⌠field to what weâre used to from the old system?â NOOOOOOOO! You have to change it on all reports, all UI panels, etc ITâS NOT WORTH THE EFFORT! It will take a couple of months and everybody is used to the new terminology. But if itâs just adding a field to say Sales Order Entry with a UD field mapping it might be simple. Except that you have to ask the question on where it should be seen on reports and/or dashboards and donât forget the tracker. I donât know how many times Iâve had a quote to add a field to a Maint UI and nobody mentions the tracker and when noticed âwell, that was just assumed to be includedâ.
4)Effort: While theoretically just about anything is possible given unlimited time, manpower and money reality is a cold, cruel queen/king. If the effort involved is going to take a lot of effort then come up with a legitimate guestimate of effort and ask the question of whether itâs worth it to go forward (both of the asking person and mgmt). If everyone is on board you can plod away and everyone knows it will take time, $ and potentially push out other activity. If it will require you taking classes or spending time researching how Epicor/Kinetic works in the affected area then lay that out as a starter with the proviso that you just donât know what it will take until you can get a better handle on the subject matter.
Lots of great answers here and principles I used to live by as a customer.
As a consultant the mindset is a bit different these days, especially as a freelancer⌠itâs much harder to say no to things when it directly affects your income⌠Gotta feed the monkey as Lebowski would sayâŚ
But you still need standards. Most important for me is never deploying a solution that is not technically sound/stable/performant. It will always come back to bite you.
Beyond that itâs mostly a matter of explaining pros and cons (dependencies, upgrade considerations, etc.) to the customer and trusting that they will make the right call for their business after youâve said everything you needed to say. I used to be afraid of talking customers out of doing work by emphasizing the downsides too much, but I have found that there is almost always a âletâs do this insteadâ request that comes through whenever I talk someone out of something.
Love this Tom, thank you so much for quoting this.
Great point. Thanks for taking the time to respond. I am hoping that many others can read through these posts and get an idea of how all of us work through this.