Re: Does everyone need to build?
I have worked in chemicals, forest products, metals and mining, consumer products, assembly manufacturing, configrue to order, engineer to order, and high tech manufacturing operations, so your assumption is incorrect about my background. I know of companies who use package software quite extensively for rolled metal products like wire and for other wire products like fiber optics. The configure to order and dimensional characteristic and compound characteristic driven manufacturing is somewhat unique and often requires some enhancement to the package product to fully meet requirements. However, this is not unique to wire manufacturing. This same issue exists in other metal based manufacturing operations (say rolled steel) as well as in forest products, some plastics based configure to order operations and to some extent in chemical company operations. And by the way, SAP happens to be the defacto standard for core ERP/CRM processes for both forest products and chemicals. Pull a list of companies if you don't believe me.
Part of my point was that operations are less unique than people often think as I have pointed out above. And part of my point was that even when parts of the buisness may be somewhat unique, other parts are not. Why custom build core financial, HR, procurement, inventory, etc. solutions when a package can work just fine and then you can enhance the product for the things that are truly unique and differentiating.
I freely admit that hedging is more of a unqie business function and it is not typically supported in most ERP/CRM package products. Even though I am not an expert in hedging, enough companies do commodities hedging (again your company is not that unique as other metal companies, oil and gas, chemicals, and consumer products/food companies hedge commodities all the time) that I would bet there are some package products that would probably be worth invesitgating.
Comments and attitudes like "if you are just manipulating configurations, you aren't even real IT" are the things that get IT in trouble. The purpose of the IT organization is to meet a business case in support of a particular business function or set of functions. You should be looking for the best way, whether buy or build, to meet the business case - which approach best supports the business process(es) for the cheapest cost and highest benfit and least risk. If after proper analysis that is "buy", then that's the right decision. If after proper analysis that is "build", then that's the right decision. In my experience buy has and is more often the right base answer, but that view point would not preclude me from properly examing the buy vs build question for a particular solution and chosing build if appropriate. Opinions about "I'm not doing real IT work unless I am coding" are irrelevant and all they do is serve to reenforce the rest of the business' poor impression that IT is just a bunch of tech weenies that don't get it.
If you had limited your article to banking/financial services or even some set of service industries, I would have reactly less strongly or might not have even responded at all. You certainly have greater expertise in financial services than I do and maybe your article is spot on for that industry. But the article you wrote is a broad statement without reference to industry so by default would aplly to all types of businesses. I take exception because you are making a broad statement that you can not back up with relevant experience and because in my experience your premise is just wrong. Since you have freely admitted that you have fairly narrow experience, I would suggest that you not generalize your experience and viewpoints to industries/businesses in which you have not worked.