Today I'm raising an old bugaboo, but I'm adding a new perspective. The bugaboo? Customizing packaged software. It's more expensive than either building your own apps from scratch or buying software off the shelve. But you all already know that because we've previously hashed that out at length here.
On to the new perspective. As many of you know, I've been up to my eyeballs in helping customers switch to the mobile responsive Newsfeed UX for Oracle's HCM Cloud Applications. And we're finding customers love it. The ease of use, the consistency of the user experience between mobile and desktop platforms, the overall look and feel, the short learning curve, the high levels of user acceptance smoothing the change management involved in the switch. Newsfeed UX is a huge hit. But I digress, so let me get back on track. We offer several tools for personalizing, extending and customizing this new user experience. Between the components of the HCM Experience Design Studio and Page Composer, customers can change the UX in pretty much any way their heart desires.
But just because you can do something doesn't mean you should do something. I'm seeing quite a few customers burn quite a few calories on customizations with relatively minor impact, mostly involving the user interface rather than the user experience. (What's the difference? The user interface is about the look and feel. The user experience is about the way you work. The latter has a much broader and more meaningful impact than the former.) Changing the color of the text in a button. Removing the category title from an event. Substituting a seeded icon for one of their own design. To sum up... making big efforts to change minor details, things that don't impact the ability to conduct critical business processes or provide meaningful business intelligence.
Changing minor UI details, in and of itself, is not so bad. I often think the energy expended is over the top in comparison to the return. But if it is important enough to a customer to burn their resources in that way, that is their choice to make. But the thing so few realize when implementing these changes is the cost going forward. That cost comes in testing and maintaining those customizations as part of each and every system configuration change. A new patch is applied? Better test our customizations. Implementing a new interface? Better test our customizations. A new release or update? Better test our customizations. And, by the way, redesign and reapply those customizations as needed. A change in application architecture? We need to redesign and reapply those customizations. Start thinking about the frequency of these and similar cases, then consider the resources involved. You'll get the idea.
One more time: just because you can do something doesn't really mean you should do something. Are there times when customizing is the right choice? Of course. If a customization is necessary in order for you to execute a critical business process using packaged apps or services, then that is what you do. Just consider it carefully first. Because the old bugaboo of customization is the gift that just keeps on taking.