October 22, 2007 at 7:34 pm
Comments posted to this topic are about the item The Build Buy Debate
October 23, 2007 at 1:17 am
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
October 23, 2007 at 1:20 am
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:)
October 23, 2007 at 1:47 am
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 :crazy:
October 23, 2007 at 3:13 am
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
October 23, 2007 at 3:21 am
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 :crazy:
October 23, 2007 at 3:35 am
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
October 23, 2007 at 4:51 am
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
October 23, 2007 at 6:39 am
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.
October 23, 2007 at 6:48 am
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 :crazy:
October 23, 2007 at 6:53 am
The problem with giving back to open source, in many cases, is that the competitive advantage you might gain from adding your own cool customization or bug fixes, is gone because you've now released that stuff to others. That ruins some of the advantage of going your own way.
And if you don't give code back, you've created a fork.
Personally I don't have a problem with someone using Open Source code or the MS platform, or anything else. Just pay for what you use, the base software. Give $50k to the open source project that you used as a license fee or so they can continue to develop more of the same type of software you used.
October 23, 2007 at 7:07 am
Steve Jones - Editor (10/23/2007)The problem with giving back to open source, in many cases, is that the competitive advantage you might gain from adding your own cool customization or bug fixes, is gone because you've now released that stuff to others. That ruins some of the advantage of going your own way.
I accept this is the perception many businesses have - but it is generally fallacious. Taking your example of the forum software - do you really think it is the bells and whistles of the forums that draws people? I doubt it - I am sure you will find it is the content - so a competitor who ended up with any enhancements to an O/S forum solution would still need to get the content right to benefit. And most of the other users of the forum software would not be in competition anyway. Now there will be exceptions - I know of some examples of software that is truly unique to a business so would never be released as open source - but this sort of software is almost inevitably not bought in from outside anyway and so the open source solution would never be on the table.
The original topic was comparing the pros/cons of bought in versus self built solutions. If bought in was ever an option then you could not have been relying on customisation for competitive advantage anyway as the bought in software would be available to all you competitors.
James Horsley
Workflow Consulting Limited
October 23, 2007 at 7:37 am
James,
I'd agree with you on something like the forums, but that's a very generic item. What about SugarCRM? I could easily add customizations, like phone/VOIP integration, automation to some customer process, links to something like Dynamics, etc. that would give me a competitive advantage. It would be up to me to decide to what extent that I'm helping competitors with that.
what about GIMP? Or some editing/rendering process. It might be that I gain some advantage I don't want to share.
I don't necessarily disagree that releasing back code is a bad idea. And lots of companies do release back stuff. But many are afraid and they're not sure they want to.
I can buy commerical software, like SAP, and customize it as well. That's more along the lines of what I was originally writing about. The forums might not have been a great example. They're somewhat open source. You can buy a license to get the code, but you can't freely release it.
October 23, 2007 at 8:28 am
There is another twist to this buy/build debate. I know of businesses that built there own software because they could not buy the software that would fit into their business model. Now they are in the software business. They realised the software they built was much more valuable as a product then the original business itself.
---------------------------------------------
[font="Verdana"]Nothing is impossible.
It is just a matter of time and money.[/font]
October 23, 2007 at 8:42 am
Two things to respond to:
Workflow I feel that the build vs buy decision (size and urgency plays a part as well) is really told in the process modelling. This is also something that is tragically missing from most vendors software documentation. The most difficult thing to do is not write software but change people habits. The cost of that should be added to the formula (intelligently - thumb suck guesses don't count) to make the BvsB decision. Every piece of business software has interaction and process assumptions built into it. If you can find software that matches your process (or desired processes) the buy decision is easy. I am currently assisting a company that is doing a large scale ERP upgrade. I was invited in after the crash was obvious to avert it (accomplished that) and one senior employ quit because she "couldn't go through this again." The chief pain point is none of this process work was done. The lesson here is that even when upgrading a current system B vs B uis a reasonable question. I had a sign on my office wall for a number of years that said "If you can't write it down, I can't build it." That includes processes. To paraphrase Joe Walsh "You can't know where you going if your don't know where you are"
Buying for Bells and Whistles - I must confess, I am not a pretty UI kind of guy. From years of working with marketing people, I find if someone is trying to impress me with features my instinctive response is to wonder what they are trying to cover up. Time always limits the final product. So if the vendor has invested in this what did they choose to leave behind. There are those vendors who, like street hucksters, like to do feature slight-of-hand. Thankfully I think they are few. However, a list of what it doesn't do is as important as a list of what it does when considering features.
Viewing 15 posts - 1 through 15 (of 35 total)
You must be logged in to reply to this topic. Login to reply