The Battle between Products and Processes

Ever since I read the book Business Process Re-engineering and many other interesting articles on business processes, way back in college, I've been a strong believer in the concept of tweaking products to meet business process needs rather than tweaking processes to meet the product design and requirements. I've passionately argued against deploying products without a thought for existing organizational processes and sometimes even flicked a few specks of dust from my sleeves during these arguments ;-). So far so good, Nimmy. But a recent experience makes me re-look at my beliefs.

It's not been hard for me to understand that if you're talking about a really 'good' product (brilliant because of the minds behind it or something that has had time on its side and has evolved into a very mature version), then the organization deploying it must definitely consider studying and comparing the ways of the product with its own. If the organization has been a laggard in the innovation and improvement of its processes, it truly doesn't make sense to stick to them and say that the product must be turned upside down to meet the former's requirements.

Without rambling on aimlessly, here's what I think organizations could do to avoid this "business process ego" trap! If the fear is that of being brainwashed by the product features, why plunge into it without appropriate preparation? A few days of unbiased brainstorming, introspection and analysis of the existing set of processes and what they lack in, before considering products for deployment may do the trick! Post this exercise, When you actually look at the product and its features, you are ready to accept and admit its brilliance (if any) and are prepared to stoutly refuse to accept some of its features as not apt for the organization and the way it works.