Slashdot Mirror
Business Software Needs A Revolution
An anonymous reader writes "According to a Businessweek Online article, today's high-end business software is bloated, buggy, and too expensive - no surprise to those of us who have paid our bills by adding pointless features to some piece of software arbitrarily priced at $100k. Evidently, firms are now re-evaluating their software purchases, and finding that they're not working out the way the sales guys told them they would."
it's no accident that Sales and Marketing is S&M.
They just chose who is in the bondage.
Dacels Jewelers can't be trusted.
There are some good points made in this article. Working at a
software company, there is quite frequently an incredible amount
of pressure to get new features in as quickly as possible.
However I don't think that phenomenon is ever going to go away.
To a certain extent there is market pressure to add new features
to your product, people always want the new bells and whistles.
There has been a tremendous market pressure over the last decade
to add bells and whisltes over bullet proofing your code.
Perhaps there will be some pressure now towards bullet proofing
your code, but until customers stop demanding more features and
start demanding quality code, software won't change.
There are some companies out there (M$ being the prime example)
that don't add much in the way of new functionality, but rather
repackage things, move buttons and menus around and make the new
incompatible with the old. At the same time they only fix
certain bugs, but leave others alone. Yet people buy their crap
at record rates.
I think most developers would love to see a move towards
software quality rather than software features, but until the
market dictates that as a priority it just won't happen.
Doug Tolton
"The destruction of a value which is, will not bring value to that which isn't." -John Galt
Marketing speak does not translate to real world performance.
Seems to me that if I was spending 100K plus on a software package (or system) I would test it first to make sure it fit my needs, as opposed to listening to a marketing drone...
So rise up, all ye lost ones, as one, we'll claw the clouds.
they're not working out the way the sales guys told them they would
What?!, a dishonest sales person? Never!
I have often regretted my speech, never my silence.
-Xenocrates
Film at 11.
They lie to their developers when they say 'All we need is this one feature to make customer 'X' happy'.
They lie to their customers when they say 'And this feature our developers just put in will make your life easier'.
The hell of it is that when developers put in 60-80 hour weeks coding bloat features, the salesmen are the ones who get bonuses for making a big sale.
The problem here is not so hard to see.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
I'd love to see a survey of how many people use the huge number of convoluted and complex review and version features provided by Microsoft Word. The addition of these feature seems to represent the only major change from one version to the next of this microsoft suite, nowadays...
You mean the Sales and Marketing department oversold the capabilities? Say it isn't so. On a former project, we needed to emulate a remote system for some testing. We wrote some code that responded for that system, as it was expected to, so that you always got the answer you wanted from it. It was affectionately called the Marketing Server.
I've wondered for a while what the point was. For the price of some of these packages, you can hire 2 developers (or more!) for a year and get them to code an application that does EXACTLY what you want. As long as you stick with a fairly standard architecture and document it well it should be just as effective. Using components that have already been developed (such as various jakarta subprojects) can really speed projects like these and make them worthwhile. Most importantly, it is custom tailored for your business.
Where's my lobbyist? Right here.
is bloated, buggy, and too expensive
Software has been following this general trend for years now (except the too expensive part). I know this is like the "when I was your age I had to walk 50 miles in the snow up hill to school at 4am" kinda whining, but I'm going to do it anyway.
Fact is, other than watching video files and ripping cd's, why is it that you need an OS that requires more RAM than you had HD space years ago for. If you map computing oomph (mips, ram, hd, video speed/resolutions) and software functionality (say on the y axis), you'd end up with an incredibly dissapointingly near flat line. With as much horse power that we have today, we should be able to create nearly bug free software because of all the majorly powerful development tools that put all this power to good use. Instead, we have majorly bloated development tools (Rational Rose et al) and environments that focus on letting people make pretty but ill conceived ui's and make a half hearted stab at helping to improve code.
Bah, humbug.
One of the key problems is that software vendors think that they should continue to add more and more features. Each time a software vendor solves some little bullshit problem for one customer, they decide to throw it into the next version resulting is feature creep. This might be kind of cool for the geeks but it sucks for most users, especially the typical users of the software. As most of us know, as you increase the number of features, you increase the complexity. As you increase the complexity, you decrease the usabilty. Thus, paradoxically, as you help some people you hurt a lot of other people. Stated another way, the harder these vendors try to help users the more they hurt them. Usability just keeps dropping.
How to Download YouTube Videos
Once the market cleans out the Boom chaff, look for more interesting apps to come out of the consolidation. This is a market issue, not a technology issue.
> finding that they're not working out the way the sales guys told them they would.
ok 2 old jokes:
Q: what's the difference between a used car salesman and a software salesman?
A: the used car salesman knows when he's lieing.
Q: how can you tell if a software salesman is telling a lie?
A: his lips are moving.
Evidently, firms are now re-evaluating their software purchases, and finding that they're not working out the way the sales guys told them they would.
re-evaluation doesn't mean refund. It means lets spend more money and hope it works this time! (or maybe the existing vendor has an upgrade solution! we can use our relationship to get a great discount!)
The revolution has to come from the businesses who buy the software. And the sound of that revolution would be "I know what I want, I want a,b and c". Venders would be in utter shock, many will fail because they are not used to actually making what is demanded only what they think/know it should be.
no need to do any research ...
A bit off topic, but related. I got tired of trying to find a really decent store suite for e-commerce. Most of the ones which did what I needed cost hundreds to thousands of dollars, and would require additional licenses as more features or bugs got fixed and made a new version release. Going from version 3 to version 4 would be a $200 upgrade, or buying the package to include coupons would be $150.
The free or low-cost solutions did little, were hard to use, and were buggy as well.
So people really had two options. Pay plenty for good software that they would have to continue paying if they wanted to keep up to date in modules and features, or pay little or nothing and get software they would have to invest additional money into making work how they need.
So, like those before me in the free software world, it made me start my own software suite for e-commerce, to be released free under the GNU GPL license, because I would already need it for my site, so why not give it to those already in my position.
I think this is where business software will be going. A small company or a programmer will find that there is a need for a software package or suite. There will be two options, expensive lock-in software or cheap hobbling software. They will probably decide in this economy it will be easier to either build off FSF-approved-licensed software to make it work how they need, or just build their own.
I'd love to see this option work out well. An alternative to Peachtree/QuickBooks for all platforms that is XML based. Linux-based POS software for stores. Inventory management and shipping database applications.
Why spend $100,000 on such a suite when you can just build off a free project, or start your own using the knowledge you already have with the suite you couldn't get working how you wanted, open it up and reap benefits from servicing contracts and support to other companies in similar situations.
Or am I just dreaming?
Human nature is the same everywhere; the modes only are different. -- Earl of Chesterfield
Analysts estimate business-software customers spend $5 installing and fixing their software for every $1 they spend on software.
.75 FTE for a Unix Admin for on-going support. This is about 5 times the need of any of our other Unix servers, and makes me wonder how much care & feeding the system will require just because of the buggy application. From my observations, the numbers quoted in the article for fixing software don't look high at all, and may in fact be too low.
The management mindset of "do it right now", as opposed to "do it right" is costing them more in both the short- and long-term. Until prevailing attitudes are changed on the part of those making the purchasing decisions, software makers will still have little motivation to change.
My employer is looking at a $1 million+ project for HR automation. $40k of that is for the unix server, the rest for software and "services". And this was, supposedly, the best software available. The vendor also recommended a
To be honest, at least 50-90% of the cost of big software packages goes into maintaining another company, paying that company's CEOs and sales staff, paying for first level support people to misdirect your call and other things that are, to a great degree, unrelated to the quality of the software you're getting.
Think about it: for $100k, you can get package X, which does half of what you need it to do in some areas and twice what you want it to do in others. Or, you can hire me & my buddy Josh for a year. We'll write you a custom piece of software integrating open source tools, work right along with your employees and give you all the code and a support contract for XxX hours over the next YyY years.
If there's an OSS package that already does most of what you need, you can probably hire their developers to customize it for you quickly and at a very minimum expense. You don't even have to tell anybody about your custom code, unless you intend to release the binaries outside your company.
And of course, if you can get three companies that need a similar piece of software, you can invest in a small business that does exactly what you want and split the cost. That's how my friend's firm works...the bills are paid for by the big guys, and anything they sell on top of it is a bonus. As a result, their rates are 1/2 to 1/10th those of their pay-for-our-big-name-CEO competitors.
That's your software revolution: customization, adaptation and competent small businessmen. And it's already happening.
Hey freaks: now you're ju
I'm sure you would, and I certainly would. Unfortunately in the corporate world these decisions are too often made, for "non-technical reasons" [1] by people who lack this apparently simple insight. I've seen too many inappropriate purchases made, of over-priced, under-functional software and systems that looked like it did what the purchaser thought he wanted, but in real life failed to do what the company acutally needed. Or had prohibitive costs. Or...
And I don't believe that my experience is particularly unusual.
[1] don't ask :-(
Paul "Say no to feeping creaturism"
It has imprecise layout options.
It second guesses your decisions.
It is ginormous for what it does.
It has encouraged use of Bold, Italics, and MS Comic Sans
It sucks CPU cycles like a 40-dollar whore.
It indexes every last damn file on your PC.
It saves information that you really don't want distributed in every file.
It has an annoying mascot.
It has been ported to mac.
It is used by mac users.
It gives you hell whenever you don't want to save as a
It is far too expensive.
It has too many features.
It encourages use of MS Comic Sans
and...
It encourages use of MS Comic Sans.
Thanks.
You see, one of the major problems is the cost of software. The more it costs, the more the suits want it. It's like having that uber-car with redicules horsepower that you will never be able to use because you live in the heart Chicago.
You wouldn't believe the number of times I've seen MySQL passed over for Oracle when none of the Oracle features will benefit the project.
And if you wanna argue about support, I think it's a non-issue. If you need help with Oracle, do you really think you're gonna get more help calling their customer support than you would doing a little google for info on MySQL? I think not.
Another problem is with sales of software. It's like for each new version, it is number one priority to have more bullet-points on the back of the box pointing out new features. How about one bullet point that just says "faster" and another that says "more stable." That'd tickle me just right. But I don't see it happening anytime soon.
Solution? It seems like marketing needs to change more than the actual software development. If the marketing groups were able to market stability/speed instead of the beaten-horse of new features, then we'd start to see a change in software quality.
Go here for teh [sic] funny.
Marketing people overstate the usefulness of their products in order to sell them.
Wow.
It is because software is supposed to bend to the will of the user, not the other way around. And that is why software is so feature-laden, so mandatorilly configurable.
If you wrote yourself a business app without configuration, you are dictating to your customers exactly how they will do the business they intend to use your software to do. That's great if your customer either does not do business in this area yet, or if they already do business the same way you expect them to.
But guess what! 99% of the target customers out there do or will want to do business differently!
For example? Let's pick something we can all agree on: source code management. Now how are we going to do business? Every shop will have a subtly different answer.
And that's the problem. Customers frequently don't know how they do business, and forcing them to articulate their current processes leads to them facing this unpleasant truth. Sometimes they tell you the wrong thing. Sometimes they deliberately tell you the wrong thing.
Sometimes management gets wind of all these neat metrics that the new system will be able to measure, and those get tacked on to the requirements sheet.
Sometimes there comes a requirement to seamlessly interface will all these legacy systems. Oh, and seamlessly sort, classify, access, and audit all the legacy data too.
You get the point.
The comparison with the auto industry is similarly bogus. The auto industry has a sharply restricted list of top level suppliers (Ford, GM, BMW), has the infrastructure to provide all routine supplies (like computer units, replacement hoods, etc), has a universal interoperability standard (the road), and a standardized operator interface.
Until the requirements for Business Software becomes simple and universal, the software fulfilling those requirements will never be either simple or universal.
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
The big business app vendors have mastered the buzzwords to impress the CxO's and boardrooms into believing they solve the problems. After all, if FORTUNE 100 software company whose software is used by everyone doesn't fix the problem, who can? The evaluators are shut off because the sale is predestined by the owner.
I saw this happen when my company evaluated a $2 million package by Big Software Company X and went away saying no way in hell. Then it came down from above to look into it, and $4 million and 2 years later it's still not done. The problem is, any project with that much money, and the big names on it can't (by definition) fail. So more money, more time, more frustration.
Of course, it's easy for someone so close to the implementor level to see it as management's fault. They turn around and see it as the implementors' fault for not doing it properly, since it works everywhere else so well.
They overruled the mechanics and bought the Jaguar, and don't want to look foolish and admit to the neighbors it's always in the shop. Articles like this are a positive sign though...
There's enough blame to go around to everyone in the enterprise software rip-off game:
* Buyers for not even applying common sense to outrageous claims
* Software companies for overselling and underdelivering
* The press for pandering to the software companies for ad $$$ a the risk of their readers
* Consultants and IT managers for using buggy implementations as job security
Shame on all of us.
-- $G
The Sprint PCS Vission support person told me to powercycle my phone when I was having connection problems. This was to flush the buffers and cache. They said that this is a common problem with all software and said that even Microsoft Servers have to be rebooted every few days.
If we hold companies' feet to the fire and and be demanding, they may change when we start demanding refunds for buggy software.
No bugs is good bugs!
Fight Spammers!
I suspect there is a small core of functionality that we all use in any given package. After that, different kinds of users use different sets of extra functionality. Just because most people use less than 25% of a program's functionality doesn't mean they are all using the same 25%.
You mentioned version control in Word as a useless example. I know people who need and use version control, and for whom the enhanced "differences" display is a great advantage.
One man's bload is another man's vital feature. Which makes my ID more ironic than usual, I suppose...
Paul "Say no to feeping creaturism"
There's an old saying in the automobile and housing markets - if you have to ask how much it costs, you probably can't afford it.
I think the same applies to software - if you can't find out, on the website, how much it costs - that is, if you have to deal with a salesweasel, not just to buy the damn thing, but just to find out how much it's gonna cost to buy the damn thing, you can't afford it.
Honestly, how many of you would buy a game for your PC if the price was listed as "Contact Your MegaGalacticGames Sales Rep for pricing." (Whereupon your MGGSR will promptly ask you what kind of car you drive, and charge you $49.99 plus $10/month if you drive a Ford, and $69.99 plus $12.99 a month if you drive a Boxster.) And in either case, you're going to be calling him back next week to find out how much the map editor and the multiplayer option costs. (The answer, of course, is that the add-on cost depends on whether you use a Bic pen or a Montblanc when you signed the check for the initial purchase.)
If you make purchasing decisions for your own company, don't you have an ethical obligation to handle your employer's money with the same sort of care you would your own? If you wouldn't trust a company like MGGSR with your $49.99 gaming dollar, why should you trust them with $499,999 of your boss' money?
Personally, I take the old rule one step further.
If I have to ask how much a piece of software costs (because the vendor gives me no other way to find out, short of calling his salesweasels) not only can I probably not afford it, but odds are pretty good the software isn't worth it, even if I could afford it.
It's that same question ALL OVER AGAIN.
o r comparable methods)
Software sucks because there is no demand for quality software - hence software vendors do not need to implement internal engineering processes which could ensure that the software is good (to a degree).
The problem happens when you get into the Enterprise "space", where companies are accustomed to spending huge amounts of money for products that are engineered to be bulletproof.
Then they settle for products which were coded the same way consumer companies coded their freeware.
Here's how to solve this problem:
Company X claims they sell "unbreakable" software.
Their software breaks.
They get their asses sued off, or handed to them by their competitors. **IF** their competitors use an engineering process to write their software, and IF they can show that process, and prove it to their customers that they use it, and show, with numbers, how it helps.
In other words, act like a REAL software company, instead of just another dotcom trying to make a quick buck before another dotcom is tricked into buying them.
What do I mean by "engineering process?"
http://www.sei.cmu.edu/cmm/cmm.html
(
Yes, it costs a LOT more to do these things. But they work, and should be a great selling point for people buying software. Unfortunately, the main reason we had a "computer revolution" in the 80's and 90's is because software was so cheap to produce - because it was being written, compiled and shipped. Not engineered.
If there was a demand for quality software, then it would be worth it for a software vendor to use these processes to ensure quality. And it would be profitable, because they could charge a lot more. Some vendors DO this, and get their asses handed to them by other vendors who do not. Which brings me back to the original problem. STUPID CUSTOMERS.
So, stop whining about sucky software.
Stop spending money on software in the "Enterprise" price range, without knowing that it is, in fact, Enterprise quality.
Stop listening to Gartner Group and other ANALists. Stop reading lame trade rags. Their corruption is what allowed this market to degenerate and devolve to the state it's in today. Their job was to educate responsibly, and they failed miserably. But they did make a lot of money from SUCKERS along the way.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
I've been a software Product Manager at some of the biggest software producing companies in the world since 1995. I'm the guy an awful lot of you coders seem to dislike so much. You know, the one always asking for just one more feature to be squeezed into the release, and, oh, can we get it two months early?
There is great truth in this article, and a great lie. Software companies publish buggy, bloated product all the time, but not because it's fun and not because we marketing weenies think it's such a good idea. It's because that's what the market wants. The idea that customers are asking us to stop is a load of crap created by journalists looking to write about the latest backlash.
Sure, as the article points out, Oracle 11i was bug-ridden, but how many millions did Oracle make off it? Claiming a 11% drop in revenue in 2002 is just a tad misleading--who *didn't* see a drop in revenue in 2002? Didn't some bubble burst or something? Bottom line, customer's bought the software, bugs and all. And you can bet an awful lot of them were screaming at Oracle to get the software out as soon as possible. So where's the motivation to do it any different?
Every customer will tell you he wants just one more feature, or just one critical (to him!) bug fixed, and then he'll be happy. Bunk. Fix the bug, add the feature, and get ready for the next demand. And since what Customer A wants isn't always what Customer B wants, we get lots and lots of features, many of them aimed at a very small subset of users. Add to that all the customers screaming since the customers want it *right* *now*, and we ship software with way too many bugs, and lots of silly features. Which customer pay for.
I work at a pretty large .com, one who actually survived the bust and maintains a profit, and has a pretty significant amount of traffic. We have used ATG Dynamo for our application server for several years, partially based upon the built-in ability it has to do an MVC architecture, personalization, pools, and so forth.
However, we just completed a web application that was built using many open source components, including Struts, Validator, JUnit, and others. By using open source components we have completely divorced ourselves from using the proprietary technologies used by Dynamo, and have opened ourselves up to the possibility of using a different, and of course cheaper, application server. This would not have been possible were it not for stable, performant open soruce initiatives.
Not only is management happy because we have (potentially) saved a bunch of money, but the developers are happy because they are much more friendly towards open source than closed technologies; it is far easier to get an answer to a question via Google than it is to pay for and go through the hassle of using a support contract of some kind.
I do not mean to denegrate Dynamo at all, because it is actually a fairly good application server. The licensing costs, however, just cannot be justified when so much of the functionality provided by it is already available elsewhere, for free.
Feature-creep is often caused by "the customer is always right" syndrome. The benefits of adding the feature are considered, but not the total cost it. It is sort of like cocaine, or a greasy burger: it might not kill you today, but eventually it will, or at least make you disfunctional in the longer run. But people ignore the downsides because they grow subtley.
Further, a lot of the tweaking is for vanity purposes IMO. I could build a system that could generate complex business applications mostly just by filling in values in a "data dictionary" set of tables that describe fields and relationships between them, plus a few event handlers. However, the interface would be so boring and predictable that it would be ignored. It would lack a WoW factor that people seem to want. Managers like to stand out from the crowd. They *do* pick a system simply because it looks cool.
Finally, too many places fail to design their databases well. They let slop creap in over time, resulting in bad, poorly normalized tables. Don't let your schemas slide. Don't duplicate columns and data if you don't need to, and don't make a bunch of tiny one-to-zero-or-one tables.
Table-ized A.I.
Exactly what Jakarta subprojects would you suggest for building an ERP system? Or CRM? Compiere? Please.
:)
I just spent 7 months with Epicor (ERP and CRM), which is one amazingly crappy piece of software. But where's the open source choice? I mean there's not even a viable OSS replacement for Quicken let alone a ERP, CRM, or real accounting system.
If you want tons of consulting bucks, write a *good* open source ERP or CRM platform and sell the consulting/support/training. But until there's a decent *enterprise* choice, we're stuck with the crap from the vendors.
One IT manager told me "All ERP solutions suck. And whichever one you choose sucks worst."
I've seen it first-hand in the aviation industry. I worked for a small aviation company that sold fractional ownership of airplanes, as well as provided executive jet services and medical flights. Aviation-related data was all entered into an ancient DOS program that stored data in a single .dbf file on a central server. The DOS program cost $125,000 and $15,000 a year for maintenance. This was in 2000! The company that made the software was shocked that we were able to share the application on a Citrix server (and they threatened to sue).
It is actually a chicken-and-egg problem to see who is at fault, the buyers or the vendors.
Let's start with the buyers, and their proxies, the press. What is the easy way to evaluate software to purchase? Surely not to take the time understand its architecture, algorithms, efficiency of code, etc. and to fully test whether it works in the environment for the intended purpose. No, it is to compare features. So, we got the "Feature List from Hell" and the trade press replete with exhaustive feature comparisons. As if they meant something.
So, as a vendor, to what are you going to build and sell? Of course, you want to be the first to be out there with just enough of each and every feature have the most filled column in the reviews (it barely matters that the features actually work). Sure, you'll also make noise about the rest, but we know it is all Marketicture. E.g., Microsoft has been talking about the benefits of code reuse since the 1980s and implying that Office was more efficient because of common elements, yet StarOffice is about the only suite that actually implements an OO component model.
The article makes an example of Oracle's bad release of 11a, because it was rushed to market. They overlook that this is repeating history -- Oracle almost went out of business in the early 90s because their software was so fundamentally rotten that they had major lawsuits from both customers and shareholders. Obviously, even the industry leaders don't learn. Or maybe they do -- Oracle did it to gain market share, and it worked; at the end of that period, the competitors with better products were fatally wounded, but Oracle "fixed it all" and came back. The lesson is obviously: "it pays screw your customers".
Then, after years of vendors rushing to market and bloating their products with useless bells and whistles that one in 10K people might ever use, and IT managers buying it all uncritically, we then get a new phenomenon.
Consolidation happens, and a few vendors gain market hegemony. Some exploit this by starting to create deliberate incompatibilities. Now, the purchasing decisions get taken out of the IT managers' hands by the business managers. Their primary concern is compatibility -- "I tried to send a critical file over to Bob Jones at our biggest customer and he couldn't open it -- I've had enough of this import/export nonsense, so, damnit, we're standardizing on Microsoft Office for everyone!". In the mid 90s, the major sales forces sold directly to top management; the goal was to go around IT, and it worked.
By not being critical and business-focused in the first place, IT management lost what little power it had. They had become plumbers. Then, they got outsourced to India.
Add to that a collection of bad or self-serving decisions on industry standards, and the mess is compounded. We now have TrueType fonts used broadly, but the more sophisticated Adobe fonts used by the serious graphics experts because John Warnock would not agree to Bill Gate's demand for zero royalties on the fonts shipped with Windows. Or, did you ever have to contend with all the incompatible International character sets and code pages on a variety of browsers and email clients? Everyone talks a good game of international standards, but when it comes right down to it, there is no one standard that is actually used everywhere -- local code is still needed for every locale. And, there are dozens of examples like this.
And, of course, this is all happening in an environment where there the vendors bear no responsibility for their product working. Marketed under "licenses" that would make a pirate blush, they can peddle crap that would generate FTC prosecution for fraud if it wasn't laughed off the shelves first. Do you know anybody that wants any kind of serious device, like a car or a plane, running a PC O
It goes back to the old adage that in theory there is no difference between theory and practice, but in practice there is.
I donâ(TM)t think it is simple to fix. Business processes tend to get complicated. Companies must try to meet the needs of many different customers. The end result never looks like something that was designed by one person but rather a conglomeration of the attempts of many people to make everyone happy. You canâ(TM)t just tell your customers to deal with it this way because the programmer doesnâ(TM)t want to spoil the elegance of his system.
You also have to take into account that you rarely if ever get to start from scratch and make everything simple, homogeneous, and elegant. You always end up having to get this file from the old Unisys machine, access this database on the AS/400, ftp this file from another old system, etc. Deal with this Perl script, that COBOL code, that piece of JAVA.
These âoepackagesâ that you implement end up being about 75% code from the vendor and about 25% glue and hacks implemented on-site to meet requirements. So the complexity arises from having to meet all of these needs when a software system is implemented. Each new project adds a few more goofy requirements.
When you start integrating with legacy systems and code from all of the place it is very difficult to adequately test. If you sit down and look at everything it is impossible to develop enough test cases to cover the full range of possibilities. They are practically infinite. Every machine, OS, OS patch level, language, library, communication protocol, file format, database, etc. throws another opportunity for a failure.
You also never have a stable target. Businesses merge, spinoff, develop new products and services, move, layoff, downsize, rightsize⦠At the drop of a hat. When you think about it, we are kicking butt to have anything working.
I don't want to seem mean but:
:-)
You admit that you lack accounting knowledge, but you wanted to code an accounts payable application yourself? Using open source software won't magically give you accounting domain knowledge. At least GreatPlains offered a framework for setting up an accounting system, even if your management mishandled the implementation.
As you now hack up some PHP+mysql app, you've hit the core problem mentioned by many, many others: users don't know what they want. ("The department that need(s) automation dont know what to automate and cannot come to conclusions.") But accounts payable is a *standard business function*. It's been implemented thousands of times before by companies like yours. Your staff don't need to know what to automate; in this task, they're hamstrung by 1) being accountants, not software or process designers, and 2) being used to the manual way they do their jobs.
So call up your suppliers, your trade association, the other companies in your building, whatever...someone who's done A.P. before. Ask who they used for implementation. Then call up vendors and ask how they handle the key requirements and pitfalls that you've heard. Stand on the shoulders of giants
(Or, if you insist on coding something yourself, consider this: if you're automating a department that is 100% manual today, there is bound to be some very simple feature (in your eyes) that absolutely blows the staff away. "You mean we can list all the accounts 30 days past due in Chicago? With one click? Wow, that used to take Marge half a day to work out.")
(Oh, and your management needs to take charge and decide if they're going with an external vendor or an in-house solution. With the best will in the world, it sounds like you're torn between two completely incompatible implementations right now.)
For years I have been wondering why business software hasn't evolved into a set of common building blocks. Business and accounting functions are so standard. Business software packages all do the same basic things: payroll, billing, accounts payable, inventory, order processing, etc. Why isn't there an ANSI standard for doing all these things? Why isn't there a universally used set of business objects by now? Back in the eighties I sort of had hopes that the ISO9000 people might push along these lines, but all they did was insist that every process be documented.
Every company seems to think their situation is unique; off-the-shelf software just doesn't fit the way they do business. But with the high cost of customization and one-off coding, it would really make sense to let software standardization drive business standardization. Maybe it's the same problem that doomed the big push to imitate Japanese business techniques in America. American managers were happy to show a few videos, hand out some pamphlets and say to their employees, "Okay now, go act Japanese." The thing they were reluctant to do was give mere workers the control necessary to accomplish that.
I have a feeling that if somebody wrote a complete, concise standard for business software, managers would hand it to their in-house developers and say, "Go code this, but make sure it lets us keep doing everything the way we do it now."