Staying OOB
I am part of a team that is defining an OMS solution using an industry leading OMS package for one of our clients. The client has indicated to us that they want to stay as close to the base product as possible. The client expects us to keep them honest and help veer them away from "unnecessary" customizations. While I was discussing this with my team quite a few members were of the view that while this was a laudable goal, it was difficult in practice since the user community insists that (a) this is part of current process and (b) they refuse to change
While we talked about this issue, I wondered why this happens...
I think the story plays out as follows.
User says: I want functionality 1,2,3,4,5,6,7,8,9,10
Solution Designer says: The issue is 3,4,8,9 requires customization, we will have to write this procedure and that code (oh I am so clever) and blah blah and we can achieve 1,2,3,4,5,6,7,8,9,10
User hears: we can achieve 1,2,3,4,5,6,7,8,9,10
Later when the designer explains that the customizations are complex and the user should evaluate their process, the designer usually gets the feeling that the user is not ready to budge. That is because based on the designers first assessment the user would have made commitments to stakeholders and the threshold for changing is higher.
What the designer should say: 1,2,5,6,7,10 is OOB and we cannot do 3,4,8,9
Once the users understand the clear distinction between what is OOB and what is not, then they will first negotiate with the solution design team rather than make internal commitments. This helps design teams provide real value to clients since unnecessary legacy processes get weeded out while only the really critical customizations are retained.
Processes evolve as a reflection of systems, however over time the system's role in the process' genesis is forgotten. It's the duty of solution design teams to help users figure out how best to transition from their current solutions (systems + processes) to the new world.
Comments
Hi Chandradeep,
You have mentioned “Processes evolve as a reflection of systems”. I think often, the vice -a- versa is more applicable. i.e. systems evolve as a reflection of processes. That is the reason why we have the term “OOB” and something which is not OOB and would have to be custom made to suit the unique process of an org.
One can substantiate this point based on the belief that organizations differ because of their business models.These could have been successful because of the processes that back the model.
Processes can evolve from systems if customers are more open to adopting best practices.
But I am fully with you on the valuable point you made in terms of the responsibility and communication philosophy for the solution design team. Do you think that we can go further from saying we can do 1,2,3,4,5 and cannot do 6,7,9,8 to 1,2,3,4,5 can be done, 6,7 needs work around and 8 needs some fundamental changes and 9 cannot be achieved. Or you think keeping it simple in black and white is better?
Posted by: Dawn Varghese | October 25, 2010 4:11 AM
I liked the blog and fully agree. However, what about the following scenarios?
1) The scenario described in the blog is one extremity where the customer "knows" what he is looking for and is asking us our expert opinion. The other extremity to this is where customer simply states at a very high level what he wants and by when he wants. Not caring if any or all of it is even possible. This happens in case of small companies where they are only recently getting forced to use packaged solution.
2) Between the above two extremities there can be other scenarios e.g. a customer says he wants 12345 for sure, 678 as desired and does not mention about 9 and 10 because he has "accepted the limitations" of the exising system / processes. Does it make sense to find out what he really wants?
In a slightly different twist, have we come up a situation where the customer says, "Show me what you got and then I will tell you what I really need"? Of course such cases will not be part of this blog though.
Posted by: Vilas Deshmukh | October 29, 2010 5:04 AM
Very valid points. Systems evolve as a reflection of processes in their infancy. Once systems go live they become active actors in the solution. The solution is influenced by both systems and processes. And over time, the systems tend to become more rigid and difficult to change - they lost agility. From this point onwards, the processes start evolving due to the systems.
About the communication model, its not that we never ever agree to do customization. Of course the business may need functionality that needs customization. However, its better to start from a clear position.
Posted by: Chandradeep Bandyopadhyay
| October 31, 2010 1:42 AM