Comments
Build Vs. Buy: A Dangerous Lie
Newest First  |  Oldest First  |  Threaded View
Page 1 / 3   >   >>
petey
50%
50%
petey,
User Rank: Strategist
2/7/2014 | 10:02:48 AM
Re: Go ahead, buy it
I'm saying they are becoming increasingly obsolete because of the current business model is cheap and fast AND the products on the shelf are getting much better.
RobPreston
50%
50%
RobPreston,
User Rank: Author
2/7/2014 | 9:42:06 AM
Re: Go ahead, buy it
So you're saying that most IT organizations are support and procurement organizations--they offer their companies no competitive advantage? Sounds like those kinds of organizations are prime outsourcing fodder...classic cost centers.
petey
50%
50%
petey,
User Rank: Strategist
2/7/2014 | 9:38:42 AM
Re: Go ahead, buy it
With due respect, I could not disagree more. Most business IT staffs were never intended and do not have the same development skill sets as say a software co. like oracle or MS. They are support organizations. Why invest in such a specialized development endeavor when you can buy off the shelf? Granted there may be exceptions to the rule but generally I believe the purchase gives you complete flexibility in terms of leveraging the staff support resources without the headaches of redesigning the platform based upon changing business practices. We agree to disagree and this topic will always be a great source of needed discussion in today's world of shrinking budgets and increased demand for more stuff.
RobPreston
50%
50%
RobPreston,
User Rank: Author
2/7/2014 | 9:09:15 AM
Re: Go ahead, buy it
That analogy doesn't hold up under scrutiny. It's apples and oranges. Consumers and businesses. We buy cars as consumers rather than build them because we don't have the capability to build them (for the most part) at anywhere near the sophistication and cost. We build applications and systems as businesses to gain a competitive advantage. You're not flushing money down the toilet if your company can develop an application or build a system that truly separates your company in the marketplace. No, we don't want to build PCs and email systems ourselves. But not every IT asset is a commodity.  
 
petey
50%
50%
petey,
User Rank: Strategist
2/5/2014 | 10:45:02 PM
Go ahead, buy it
In today's world of what have you done for me lately mentality, you would be flushing money down the toilet to build. Assuming you built something twice as good at a fraction of the cost of anything you could buy today, you will have just painted yourself into the obsolete corner in 5 years with lost flexibility and aging rockstar developers. I don't see the need to build my own car when I have 60 new models to choose from each year built by professionals.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
2/5/2014 | 9:30:50 AM
Re: Buy v Build
@Vinnie  I read your post about this article.  Appreciate the thoughtfulness.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
2/5/2014 | 9:26:39 AM
Re: Mobile
@ChrisMurphy:  History repeats.  Remember how the enterprise first reacted to the web?  Companies came in and charged $120K for 4 html pages-- dropping the jaw of every inhouse tech.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
2/5/2014 | 9:22:13 AM
Re: Does everyone need to build?
@TerryB.  Spot on.  If I were a radical editor, I'd nix everything in the original piece but the last line.
TerryB
50%
50%
TerryB,
User Rank: Ninja
2/4/2014 | 1:22:40 PM
Re: Does everyone need to build?
@sacalpha1  We are not as far apart as I originally thought from your first post. My objection to your original post was that you can take a package and "configure" it to do whatever you want. Or buy 3 different packages and "configure" them to work together. You are obviously intelligent enough to know that is not the case, I'm sure that is not what you meant now.

Everyplace I've worked has always been a Buy AND Build scenario. Of course you do not need to write the backoffice functions, things like G/L are highly configurable without source modifications. But that is not the case for the front end of business, if your goal is one truly integrated system. And once you get out of the G/L post interface, the integration points get harder and harder. A/R? Brings the entire Sales Order and Invoicing process into the mix. A/P? The 3-way match brings Item Master and Inventory Control (receiving) into it. So if you run one package to handle those backoffice functions but need a different package for your MES, each has an Item Master. So how do you "configure" your way into that integration? Surely you are not counting those middleware data transform packages as "configuration"?

The reality is you are lucky if you can Buy a package that supports 60-80% of the business, then Build to close the gaps and have one integrated system. Maybe someday these packages will be so API rich you can interconnect them without modification but I'll be cold in the ground before we see that.

So truthfully, how many places have you been that bought a single vanilla package and got 100% of their business on it? From the shop floor to the lab to the back office? Even in a Buy situation, you have to judge the efficiency the organization to know if you are successful. I've seen so many ERP implementations that needed low level clerks to handle the transactions, the level of automation is just not there. You can Build on top of that and increase the efficiency where those people are not necessary. That pays for the IT person you need to do it.

Coding and systems analyst work are not mutually exclusive. I was trained for both in college, have always done both. It sure helps the Buy when you know what you can Build on top of it to make fit the business. I don't believe in settling or compromising on efficiency. I write code but communicate with everyone in the business, from the President to the A/P data entry clerk. It's my job to understand the business, being able to write code just makes things more efficient and gives my company more value for their money. I've been doing that since the 80's, all for $30-$100 million SMB manufacturers. It works.

You throw out SAP so casually, like anyone can buy that. Really? Is cost no object here? One of our sister units uses SAP, it cost them $20 million to get it working and it is not vanilla. They have support staff of 5-6 people who tailored it to fit their business, the vanilla implementation was absolutely unacceptable to mgmt there, it nearly destroyed them in the beginning.

Neither myself or Coverlet is saying you always Build, that was not point of his article. But if you have the talent to Build on top of whatever you Buy, you are in a much better position to succeed than organizations who can not. So many of them have no idea what they bought until it is too late, then they are stuck in mediocrity forever.

 
Sacalpha1
50%
50%
Sacalpha1,
User Rank: Strategist
2/4/2014 | 12:56:02 AM
Re: Does everyone need to build?
@ TerryB

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.

@Coverlet

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.
Page 1 / 3   >   >>


Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Dec. 9, 2014
Apps will make or break the tablet as a work device, but don't shortchange critical factors related to hardware, security, peripherals, and integration.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of December 14, 2014. Be here for the show and for the incredible Friday Afternoon Conversation that runs beside the program.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.