Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

The Build Buy Debate Expand / Collapse
Author
Message
Posted Monday, October 22, 2007 7:34 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: 2 days ago @ 12:34 PM
Points: 31,181, Visits: 15,626
Comments posted to this topic are about the item The Build Buy Debate






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #413636
Posted Tuesday, October 23, 2007 1:17 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, May 28, 2010 7:25 AM
Points: 1, Visits: 18
We are also in a build/buy debate but now considering the option where we take an Open Source ERP framework (Ofbiz) and customize it to our needs. One of the biggest advantages is that we can start with the basic functionality and only develop what's missing.

Jeroen van der Wal
Post #413707
Posted Tuesday, October 23, 2007 1:20 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, February 12, 2008 1:36 AM
Points: 113, Visits: 90
Funny this one.

I remember my former employer buying a multi-million $$ ERP system and giving up on a self-built Cobol-system. Not just because of the development overhead (12 staff!!), but more because Cobol programmers were becoming extinct and we were up for a huge brain drain (10 out of the 12 were to go in pension over the next 3 years). The ERP seemed like the sensible thing to do.

When we were starting the implementation, we were warned by people who had been there and seen it all to adapt our procedures to the ERP, not the other way around. Some responsibilities go to other departments, some come over from other departments, that's what's usually happening in an ERP implemantation. Needless to say things went just the other way because we were unable to convince people that they had to organize their way of working differently. But no: everything was to remain the same.

Five years later, the company's core processes were mostly run by self-built applications, based on VB and SQL server. The ERP being used as little more than a bookkeeping system and as a repository for the core data. All the intelligence residing in the VB applications. Now is that a bad thing ?

I guess I'm going to have to go with Steve here. It's the people that make the business. If one application doesn't get them to work together, get another one that will. Main thing is boxes are being shoved and bills are being sent, any which way but lose:)
Post #413708
Posted Tuesday, October 23, 2007 1:47 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Thursday, October 4, 2012 9:20 AM
Points: 583, Visits: 1,060
I worked for 7 years for a company where business support applications were custom built in-house.
Employing 1 then 2 full time software developers.

We had a sister company which bought in all of their software and employed no software professionals, custom spreadsheets in excel and a poor database application, built in access were used.

Our business turned over double the money for half the cost and all staff knew that the data in the database was correct and a true picture of operations could be got out of the systems in under 10 minutes.

our sister company was clueless and couldn't find its backside with both hands in daylight as far as the data was concerned.

The companies were eventually merged and in house development was dropped in favor of buy in.
The developers and other IT staff were all made redundant save for the network manager.
No doubt you can guess which set of Management now runs the merged business. Doh!


Hiding under a desk from SSIS Implemenation Work
Post #413726
Posted Tuesday, October 23, 2007 3:13 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 5:31 AM
Points: 159, Visits: 432
Jeroen van der Wal (10/23/2007)
We are also in a build/buy debate but now considering the option where we take an Open Source ERP framework (Ofbiz) and customize it to our needs. One of the biggest advantages is that we can start with the basic functionality and only develop what's missing.

Jeroen van der Wal


You have almost (but not quite) hit the answer to the "Build/Buy" debate. Open source is a great answer in many occasions but the "only develop what's missing" is the bit that should be "join the project and add what's missing" - that way you contribute back for the savings you have made in not having to develop the other bits and you also remove the problems of "re-merging" your enhancements whenever the core project updates.

Of course open source is not always the solution - but there is more and more quality open source software out there - what is often missing is the ability to contribute





James Horsley
Workflow Consulting Limited
Post #413752
Posted Tuesday, October 23, 2007 3:21 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Thursday, October 4, 2012 9:20 AM
Points: 583, Visits: 1,060
Although I agree wholeheartedly with you James I do not see many typical corporate types agreeing to publish 'their business advantage' back to the community/competition.

Open source does not agree with the insular capitalist mind set.


Hiding under a desk from SSIS Implemenation Work
Post #413754
Posted Tuesday, October 23, 2007 3:35 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 5:31 AM
Points: 159, Visits: 432
Yes - that is a real problem - they are happy to "snatch" the free code from the open source projects but don't give anything back - ironically they are happy to pay big money to to large software corporations that give them no "business advantage" at all - they need to recognise that content is the business advantage more than the tool - just like using Word doesn't help you but the documents you write in it might. My specialism is workflow - and though there are good, bad and mediocre systems out there the real thing that makes or breaks systems is the quality of the rules that are implemented.




James Horsley
Workflow Consulting Limited
Post #413759
Posted Tuesday, October 23, 2007 4:51 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, September 29, 2014 2:31 AM
Points: 207, Visits: 960
Most of my development experience is creating in-house solutions, but have had my fair share of "buy-ins" on both sides.

My instincts say that for any internal processes or business-specific requirements, write your own.
For any "common" functions, try to buy something in that best meets your needs. If you can't find any, make your own.

Of course, when buying anything, it's much easier to justify it if you're getting the source-code as well. I was able to sell an internal component I wrote to another company, almost single-handedly though a friend, and that was pretty straightforward as my company was willing to pass on the source code as well, (not sure if without the sale would've happened anyway, but it's a possibility).

Paul


Paul

Post #413799
Posted Tuesday, October 23, 2007 6:39 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, June 15, 2009 3:23 PM
Points: 198, Visits: 263
Jurriaan Themmen (10/23/2007)
Funny this one.

I remember my former employer buying a multi-million $$ ERP system and giving up on a self-built Cobol-system. Not just because of the development overhead (12 staff!!), but more because Cobol programmers were becoming extinct and we were up for a huge brain drain (10 out of the 12 were to go in pension over the next 3 years). The ERP seemed like the sensible thing to do.

When we were starting the implementation, we were warned by people who had been there and seen it all to adapt our procedures to the ERP, not the other way around. Some responsibilities go to other departments, some come over from other departments, that's what's usually happening in an ERP implemantation. Needless to say things went just the other way because we were unable to convince people that they had to organize their way of working differently. But no: everything was to remain the same.


Ah yes - the unwillingness to adapt to change and rather than change their ways, just change the software. I'm glad I jumped ship from where I was - an overly customized ERP system running on older technology. Looking at the ERP system's newer model, it would've worked great for their needs but they've gone overboard in their customizations and are so set in their ways that upgrading isn't an option.

Even though I'm a developer and should support the build option, there are times where I know the ROI in buying would be better than the ROI of having me build a certain application. And I tend to mention that there's a package out there that does it for x amount - why have me reinvent the wheel when it'd be better to use a package already out there? And sometimes, that's just the way to go. I don't take it personally as a dev - I see it as the cost of business.
Post #413854
Posted Tuesday, October 23, 2007 6:48 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Thursday, October 4, 2012 9:20 AM
Points: 583, Visits: 1,060
I can see this developing into a change the software to suit they way you work vs change how you work to suit the software debate, it is this that is the real issue not build vs buy

In 'build' you are still buying the resource to build, in 'buy' someone else has done the building.

How we work, and adapting to change in the business environment are the real issues.


Hiding under a desk from SSIS Implemenation Work
Post #413858
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse