October 23, 2007 at 8:43 am
I do of course agree with you that you can't generalise - but many (most?) businesses do actually generalise by deciding they can't possibly share any changes they have made regardless.
As for SAP customisations - I am sure you will find these should in general be considered to be "content" rather than code - as I am quite sure you won't get you hands on SAP's source to make mods - customisations are generally rule-sets and are not really changing SAP per se.
James Horsley
Workflow Consulting Limited
October 23, 2007 at 9:24 am
There are several factors that came into play for us in this debate. Can we obtain and keep the developers needed to create and maintain this software? Are and will there be sufficient people who are knowledgeable about the tools used? Would this application give a significant advantage? Will there be asignificant advantage to tapping into the knowledge of the larger user base of the boughten software? Reviewing and modifying processes whichever the decision can have a significant impact, too.
October 23, 2007 at 9:46 am
Julie,
I agree with the importance of all the things you mention. Some of them I like to put in the basket of company strategic plan. Maintaining an IT department that is development capable is a part of the total company plan and in some ways is larger than a build vs buy decision. Two companies I am working with have made the deliberate decision not to maintain an IT department. Good for me as this equals billable hours. Out of curiosity I discussed IT positioning with knowledgable people in both companies. While one wasn't "sure what we want to do in the future" so they do nothing - IT is not included in corporate planning - which seems flawed to me but it is is what they want. The other has made the decision to "trust the market" and hire people to modify the custom components as they are needed. They make a long term plan and when there are enough modifications required, contract the best talent they can and execute the plan. SInce they are big on documentation they have been able to maintain this for a couple of decades and have figures to back up their cost savings. I found it to ba a fascinating approach to this challenge made even more interesting due to their success.
October 23, 2007 at 10:21 am
Great topic and good responses. I love reading these forums. (Steve you're awesome)
From a DBA perspective I am mostly concerned with the database when dealing with off the shelf solutions. Often times there isn't much a DBA can do to optimize or troubleshoot database issues with these apps. It can be very frustrating. Also, in some cases the data is locked in a proprietary system. Very sad indeed!
Whenever possible I'd rather build than buy - I like the flexibility of an in-house app. The ROI may take longer but in the long run, in many cases, I think it is the best approach.
October 23, 2007 at 12:04 pm
I started to write a reply but when the pop up ad with a picture of Hillary came up on my screen, it made me ill and I had to stop to clean my keyboard... :sick:
Sorry, off topic. But you should have warned me about pornography on this website.
We had our current ERP product customized by 3rd party. One day, that group went away and was eventually purchased by the ERP manufacturer themselves.
Due to our customizations, we could no longer get the updates/upgrades as they came out because of the unknown effect of the customizations. Our 3rd party vendor would first test those and then send us the update and any modifications needed. Worked well as updates only came out once or twice a year. Some of those same customizations that we developed later became incorporated in newer versions. Since we could not get the required support, we dropped paying the annual maintenance and have been trapped in a now older version with no upgrade path available.
So in this case, both the build and buy options were used and both came out bad in the long run. It did work very well in the beginning and was a cost effective solution. Building from scratch was not in the budget.
The problem is now resolving itself due to a buyout of our business and we are being forced to use their existing software, which is 10 years old, text based and runs on a Unix system. No more SQL.
Down the road, the larger parent is now developing a new CRM product which will be Oracle based.
Here we go again.
October 23, 2007 at 12:25 pm
Sounds like a painful rendition of That Ol' job Security" (Sung to the tune of That Old Black Magic)
" That old Job Security has got me Stuck Again
They haven't updated since - I don't know when
This thing is held together with tape and twine
And it comes apart when your upgrade touches mine.
There is no documentation that I can find
I should get out before I lose my mind
It is round and round I go, meetings just one more
I'm glad my office is on the ground floor."
So I mucked up the meter a little. What do you do in a Minnesota winter snowed in at work - rewrite torch songs for the technology era.
October 23, 2007 at 12:37 pm
As with any purchase what you are going to gain should drive the decision. If two to three years of development is acceptable and will put you ahead or at the same place as something you can purchase and you have the resources to devote to this, then building might make sense.
In our case we spent two years defining what we needed, researching available software before deciding to buy (we went from a home grown fox/dbase based program too). It would have taken us 3 - 5 years and probably 3-4 developers to get to the same spot as our purchase. We made a major leap, now have external support (which can be a blessing or a curse) and an amazing user group of folks doing a lot of the same stuff we do. That in and of itself was more valuable than the software. How do you process X number of orders a day, how did you automate month end, what controls did you put in place for this, etc. Do we customize - of course but we knew we would going in. I've yet to see a situation where customization didn't happen on any major software project. Our company is in a much better situation than before too because we can actually hire someone with experience on our software who can come up to speed relatively quickly on our customizations.
Always pros and cons. Did we have to change some of our work flows, yes. But honestly a lot of the changes forced us to formalize our processes and put better controls in place. Pain in the rear but long term very worthwhile.
October 23, 2007 at 1:37 pm
Great points and a nice reply from Jessica. Buying can work, especially when you need to save time.
I'm not completely opposed to buying, it's just that I see core pieces of your company better served by building. If you can afford the time.
October 23, 2007 at 3:55 pm
Well it is time to resort to the DBAs #1 answer on the list if the 'Top 10 Things' you do not want to hear from your DBA ... "it depends" ...
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
October 23, 2007 at 5:14 pm
The great software houses have forced the "User Experience" on us, and Open Source is only "Open" to a select few and "In-House" development can be an incestuous relationship between the two. There is not real right or wrong answer, just a level of risk. Either change existing management systems to allow for a ROI in the "bought in" solution, or endure the agony of customising it to suit the current business practices. BTW (Quality implemtenation and assoc process documents are horrendously expensive in their own right !) Thank God I don't have to make that call !! Personally, I enjoy the challenge of designing solutions, thats why I work, it's fun ! If your solutions outlast your current tenure then more kudos to you.
Just point to reflect "Have you been SAP'ed lately......"
CodeOn:P
October 24, 2007 at 2:28 pm
In a small shop (1-2 developer / dba / system support) we have had occasion to contract out software to our specs when it is too much to do on top of everything else. This is especially useful when going to a new paradigm (starting to use Visual Basic instead of the old Informix-4gl). We also contracted to have the source code as part of the deliverables.
One product we got was unusable the day we got it but was able to fix it to the point that it is an integral part of work. It took less time than if I developed from scratch and also learned new programming techniques that I probably would have not stumbled onto on my own.
Steve
October 4, 2012 at 1:37 am
Its funny looking back at a debate 5 years ago and seeing what has changed (very little). If you saw this first time around chances are your company has gone through a cycle either starting up at build not buy moving to buy not build then back again, or the other way around.
There are a few pointer here.
1. How good are your business users in producing a comprehensive and clear set of requirements?
If the answer is not very good then neither your inbuilt software or a bought in product is going to fulfill their expectations. There are no magic wands here.
2. How well does system 'X' play with system 'Y'?
If both are absolutely brilliant but won't play together then what is the point. All the time and effort saved by buying best of breed will be lost by building the mother of all integration points.
3. What are the technology trends?
Are there emerging players in the market that produce the software you need (obviously subject to points 1 & 2)?
4. What is the total cost of ownership?
Buying stuff, or acquiring the open source stuff is really easy.
On going licencing, support and maintenance can be very expensive. I've seen open source being touted as a massive money saver only to see the savings blown away in "professional services".
5. How well does IT know the business?
The people who built the UK Inland Revenue systems were the people who had operated its manual predecessor so had an intimate knowledge of what was being built. In many cases they were tax officers who moved into IT.
Today many of those people have either died, retired or left so IT is totally divorced from the service they are trying to deliver.
I'd bet that an IT department in a small to medium sized company is actually making business decisions and building code for what I call the NSRs (non stated requirements) simply because they know how the business works. If you know the way in which the business works then the apps that are built can be built quickly, cheaply and close to what the business wants.
October 4, 2012 at 2:50 am
I like designing my own systems and generally prefer using them to other peoples systems.
When I do have to buy in systems. It would be nice to get full access to the code and certainly I'd want full access to back end so we can do our own analysis of data as we see fit.
But yes wouldn't attempt - email systems / flexi systems / accounting systems.
Too many perfectly good solutions out there.
cloudydatablog.net
October 4, 2012 at 6:56 am
David.Poole (10/4/2012)
2. How well does system 'X' play with system 'Y'?
If both are absolutely brilliant but won't play together then what is the point. All the time and effort saved by buying best of breed will be lost by building the mother of all integration points.
An excellent point. Especially relevant to my role in the NHS, where interoperability and best of breed are hot topics.
October 4, 2012 at 6:58 am
Dalkeith (10/4/2012)
When I do have to buy in systems. It would be nice to get full access to the code and certainly I'd want full access to back end so we can do our own analysis of data as we see fit.
It is still amazing to me, with every new system we get in the NHS, how hard it can be to get data out. Sometimes we'll even get charged for, of all things, having access to our own data. Mental. It really is. Some of the companies are just a joke in this regard.
Viewing 15 posts - 16 through 30 (of 35 total)
You must be logged in to reply to this topic. Login to reply