October 4, 2012 at 7:02 am
I should add that in my role we often build software in-house. As the team is actually a data warehouse team that can also build software, we are acutely aware of the need to get data out. We design good data structures that facilitate this.
Without fail, the solutions we build in-house are always the easiest to report on.
It makes me wonder how much software is built without the user in mind beyond the actual software's UI.
October 4, 2012 at 7:44 am
So is this still the forum software you bought back in 2007?
How has it gone since then regarding the issues presented here?
October 4, 2012 at 7:52 am
Steve, I agree that you should develop in-house when you can gain a competitive advantage. But if it is something that everyone does the same way, like taxes and accounting, then buy a package and take that burden off your shoulders.
Tony
------------------------------------
Are you suggesting coconuts migrate?
October 4, 2012 at 9:23 am
Darn been 5 years! :w00t:
Hmm so Steve reopened this...
Hiding under a desk from SSIS Implemenation Work :crazy:
October 4, 2012 at 9:45 am
Custom software is for custom work process and product. General business requirements are not custom. Buy to solve the common but do not buy more than needed. You do not need to purchase Oracle Financials just to pay your electricity bill.
Build to solve the unique, but do not make it unique just to do it yourself.
Not all gray hairs are Dinosaurs!
October 12, 2012 at 1:31 pm
Miles - your comment interested me but I would like to expand to see if what I am thinking is aligned to your comment (I want to be sure I am taking your statement correctly). In the five or so years since I first touched this thread, I have been blessed with the opportunity to see the inside and help out several companies. Over that time I have become more and more convinced that it is not "buy or build" but "buy and build".
The current company I am at (I have moved from contractor to 'corner office') has been going through a lot of pain as they bought a whole ERP solution customized some within the parameters of its capabilities and even extended it somewhat but issues like maintenance and advancement were becoming more and more impossible. Further, if they had followed the tenants of this ('ERP') system it would have cost them dearly as the inflexibility of the system would have cost them greatly in sales and more than a few customers. (It is a ETO manufacturing enterprise). They followed good process when selecting the system (in 1998) but time and technology had eroded the value to the "should we just shut it off" point a couple of years ago.
Instead of doing that I took one highly talented developer and we focused on the middle ground (I believe this is now refered as EES?). We took the functions that didn't work and created an interface to the portion of the information source that was reliable, connected it to other systems and essentially packaged them as 'servers'. This lead to the creation of a dashboard-ish user interface that is now able to react to changes of use and environment without an interruption of service. This approach was validated when we upgraded the payroll and HR packages and completely replaced a section of the ERP application with a new system. There was practically zero loss in business or productivity time and we implemented the roll over in the middle of the work day. We are continuing to follow these guides with increasing success.
By focusing on building a fabric that lies between the major systems and creating what custom pseudo-APIs we are able to keep upgrades to major systems very 'vanilla' and avoid down time and most importantly we have helped to improve productivity and throughput.
Sorry for the overly long response but as someone who lived on the "Buy" side of the fence I now see more of the ways and how I was wrong.
Viewing 6 posts - 31 through 35 (of 35 total)
You must be logged in to reply to this topic. Login to reply