Full Disclosure: I am a Sage Software Business Partner - while I don't deal in the MAS500 product line - I know plenty of people who do. So I am NOT independent with respect to the comments I am making.
Probably 75% of my business is rescuing the Digital Warehouse's of the world. It probably could easily be 100% - but we turn away 25% (or more) as salvageable.
Where do I see people go wrong? (I'll be brief)
1. Relying on a free demonstration - and not entering into a conference room (paid) pilot - not sure if this is the case here as the words "needs analysis" were used.
2. Trying to push a lousy existing system (that users hate) into a new system - feature for feature. The result - a lousy new system with similar features that users always hated.
3. Not checking references!
4. Relying solely on the vendor to make a recommendation of a consultant. I have a network of 45+ consultants that I have known for years. Some of them I talk to as many as 50 times per day via email. At least one of them probably would have done a better job.Heck I've been in meetings with my consultant network where they've turned down $150k+ deals and told the prospect it wouldn't work. Not many consultants will do that.
5. Realize that the sales team you deal with during the purchase - is going to disappear during the install. A new team takes over that has to implement what the sales team recommended.
6. The market for ERP software is greatly slowing industry wide. A new name added to the software license ranks is greatly prized. This does odd things to the integrity of consulting firms when they make their "needs analysis". And if the firm was only representing one software package (red flag) - how good could the analysis be? Rather than an "analysis" you want them to do a "conference room pilot" -- set the software up exactly as you want to use it and then YOUR COMPANY tests it. Talk about the rubber meeting the road!!
I could go on for quite some time here, but hopefully you get my message. It's that as a purchaser of ERP software you need to be very diligent in selecting the vendor, and that each side has responsibility to make this work.
I have had MANY users refuse to test or participate in the selection process. Those clients who take the most active role in testing and selecting are the happiest. You cannot rely on an outside consultant to learn your business in a week - no matter how expensive the suit is that they're wearing..
Wayne Schulz
PS - I rant a bit more about this directly from my web site -- though it is slanted more toward the Sage MAS90 product line (little brother of MAS500) -
|
Does Verizon's Voyager stack up to the iPhone? |
|
|
5 IT skills that won't boost your salary 
[1,407]
Women 4 times more likely than men to cough up personal info [589]
Japan's 10 funniest tech-related commercials [Videos] [407]
Throwing away a promo CD is "unauthorized distribution"? [1,265]
Adults too quick to dismiss educational video games [682]
Attack of the iPhone clones [Slideshow] [578]
10 things IT needs to know about AJAX [1,258]
This Year's 25 Geekiest 25th Anniversaries [Slideshow] [409]
|
|
Response to Mr. Schulz
I do agree with your analysis of what normally happens in these situations, but let me elaborate our experience:
1. We did pay the Sage reseller (who, by the way, was www.netatwork.com) to do a needs analysis to see if, in fact, their product met our needs. In addition, we choose two other products to evaluate as well - so we were not focused on just this particular software.
2. We actually liked our old system, however, it was end-of-life'd and support was no longer available, so we had to find a new system.
3. I wasnt involved in this process initally, so not sure if this was done.
4. Here is where we may disagree. As a vendor, don't you want to make absolutely sure your reseller partners are living up to your expectations? If I am the vendor and I hear my reseller is not providing the best service or solution to a client, I would reconsider having them as a partner.
5. This is accurate, however, wouldn't it make more sense to have the "implementation team" part of the sales process, since they are going to know the intricacies (or as Mark put it in his article "gotchas") of the program?
6. I would guess the cost of a "Conference Room Pilot", for most small businesses, is cost- prohibitive. We did pay Net@Work for the needs analysis for Mas-500.
My point with all of this is two-fold. First, I think we may have been oversold, as some of my competitors are using Mas-200 and it seems to work well. Second, what happens when a company, like mine, feels they have done their due dilligence in choosing a product to meet their accounting and/or inventory managment needs, but find out after the fact that it does not?
Stephanie Bice
Digital Warehouse USA Inc.
http://www.digitalwarehouse.com
The Perils of ERP Implementations
Stephanie,
I'm not familiar with your situation and the circumstances surrounding any work done by Net@Work out of New York - so I will only explain a little more the overall problem with the ERP software industry.
None of this is directed at your original consulting firm - or your company - because I have no idea about the details.
1. The way many people select accounting software is broken.
Here's how it looks from the consulting side of the fence.
As a consultant I am called into a conference room (often with 12 or more people) to explain my product.
These people have been at the company 10, 20, 30 years. I've been at the company 15 minutes.
If I'm lucky I'm offered a glass of water before the interrogation/meeting begins.
I call them interrogations because these meetings are often one step short of "bright lights in the eyes".
I'm typically asked rapid fire questions about "does it do this", "does it do that".
There's not enough time to respond "yes, but" and give a full hour long presentation of the caveats involved with each of my answers.
More than once I've left meetings knowing the "committee" who just interrogated me was unhappy that I wouldn't nod my head and agree that we'd make the software work to their specifications.
I lose deals all the time to consultants who nod their heads during these meetings.
You know what though, I'd much rather walk away than be stuck with an implementation that's gone bad.
Great Example:
About three years ago a 15 store chain contacted me to purchase MAS200. They already had made the decision to buy. They were in the process of purchasing a multi-million dollar industry specific point-of-sale system. The vendor on that system responded emphatically "no problem" to every question they asked about whether it would integrate to MAS200.
My advice to this prospect (who later became a client) was that the words "integration" have different meanings and they need to make sure they get a true definition of HOW this POS was going to integrate - what level of detail would be passed to MAS200, etc. The only way they'd know for sure how this integration worked was to setup a pilot test. The vendor said such a test was un-needed because they did this type of integration "all the time".
Fast forward a year - and the client dropped the contract for their POS because ultimately the vendor (when pressed) admitted they could not make the integration work to their specifications.
2. In a 4 hour initial free meeting I am expected to completely grasp the intricacies of a business, understand their industry jargon, processes and challenges - and propose a solution that my out-of-the-box / off-the-shelf accounting program will meet. Oh, and this should all be free, legally binding and able to be implemented within 3 days of proposal acceptance. I'm not kidding in any way about this.
I tell prospects that the only way to really know whether a solution is going to work - is to set up a conference room pilot and enter in their own data, check the output and make sure that it performs to THEIR requirements.
A pilot to me is different than a needs analysis. The pilot usually involves testing on the actual software. Needs Analysis are too often quotes that talk about the benefits but provide no testing (Note: This is not always the case and I have no idea about your specific situation - so I'm talking in broad generalizations here).
Nobody listens.
I've had exactly - zero - prospects take me up on this. I've been consulting on MAS90/MAS200 since 1986.
At last count I think I have 6 EXISTING users testing this year alone (one in Alaska, one in Florida, one inquiring from Michigan, and three others locally).
The only reason these 6 are willing to pay for testing is because they found out the hard way that a "free" demo just cannot go deep enough to uncover all of a companies true needs.
3. Needs Analysis - Schmeeds Analysis - When I hear that any vendor looking to sell something did a "needs analysis" which did not involve the client testing the solution - I want to throw up all over the floor.
What exactly is this needs analysis supposed to show -- that you should buy someone else's product? That their solution won't work? Talk about the mother of all conflicts of interest...
Please!
Again, the only way around this is to setup a test with your data (Remember this is testing - not simply an analysis report - testing is that time consuming expensive thing that I talked about which most people think is un-needed, nobody ever wants to pay for - yet is the single most effective way to determine whether a solution works).
All of this expensive.
I'm reminded of the title of a short book I once read - it is called "If you haven't got the time to do it right, when will you find the time to do it over?"
Instead of the word time, companies can substitute the word money.
Moral of the story:
ERP and Accounting Software is complex. The old rules of the game (4 hour demo then proposal) don't work anymore.
Yet because of competition and client expectations we all keep trying to play by the rules and are surprised when the outcome is a disaster.
Wayne Schulz
Schulz Consulting, LLC
http://www.s-consult.com
Question
Like Wayne, I too represent ERP software sales, including MAS90/200/500, SAP Business One and Microsoft Dynamics NAV.
The question I have is around this "needs analysis".
1) How much did it cost and how many hours did they spend
2) In broad terms, what was their process
3) In the end what was the output of the analysis, a report? discussions, meetings?
I agree with Wayne on the Conference Room pilot. It does have limitations in getting you to move forward in that it only proves that the software can materially fit the needs you request of it. However you still might not proceed because often a higher level person is required to "sign the check" and that person doesn't see the value in the solution. So when we do a Detailed Requirements Analysis, it is objective, it's very deep, it contains significant ROI calculations and then we show the gaps and fits of the software and the costs to fill the gaps with the recommended solution.
The key difference is if you pay for this analysis (And it typically is between $10k and $30k), you get a guarantee that the software will materially fit the needs in the document that you approved, or we have the right to fix it or refund your money. In addition we can even fix the price of implementation and programming. The only price we don't fix is training as that is very variable based on your peoples' ablity to learn.
Our larger smarter clients (about 30%) go for this and they make up a vastly higher percentage of our successful projects. Those that go with the "kung fu" demo where a bunch of var's representing one, maybe two products show off their "sex and sizzle" demo that shows things in the program that often don't even work as advertised, have a higher level of dissatisfaction. The Standish Group did a report that explains all the pain around this situation.
Go to this page and register: http://www.standishgroup.com/sample_research/register.php
Then select the Chaos report. It dates back to 1995 (the free copy) but little has changed since then around the mistakes people make and how to do this right.
Details
Stephanie,
I'm just curious at a high level, as the article doesn't discuss it, what the major areas of problem were and did you ever solve them or have you scrapped the project?
Since I'm familiar with MAS90/200/500 SAP B1 & Dynamics NAV, I could at the high level tell you if your thoughts about being oversold on MAS500 vs. MAS200 are reasonable.
If you want to private message me feel to do so at mchinsky(at)clientsfirst-us.com (the (at) is to prevent spam robots from scraping up my email address of this page.
not so wise Sage
Stephanie,
My condolences at your buying Sage's "pig in a poke" however, your frustration does NOT surprise me.
I have been setting up small business users with Act up through version 6.03. (I started even before it was acquired by Symantec which has spun it off to Sage). With version 7 the program became unstable bloatware because the "improvements and enhancements" made it unusable. Despite the obvious desire to enrich the program to make it more powerful and useful, instead the program was rushed out despite the need for too many fixes mostly to improve the company's revenue stream.
It was not a matter of the new version being beyond my ability to use or customize it. The program just did not work. While I am still using version 6 (which doesn't work with Vista - but I don't like Vista either), I and have gotten out of the software business and have told potential customers to go elsewhere.
Sage problems
I work in IT for a small regional bank and was put in charge of inventory of all tech assets. The bank purchased Sage FAS 100 asset accounting and inventory to do this.
So I learned the software, contacting "support" when I ran into problems. Like you said in your column, the devil is in the details. The software doesn't do normal things that even Microsoft Excel can do! I spent weeks on the phone back and forth with "support" trying to figure out something as simple as hiding/showing fields for various assets. Finally a tech agent was lucky enough to run into someone from development who told him, "FAS doesn't support that option."
I can only imagine the hell that is an ERP package from this company.
If you have any suggestions for asset inventory solutions, I'm all ears! (Although we are basically stuck with Sage...)
RE: Complex software? Plan to fail!
I find this article a bit irresponsible, one sided, and providing no enriching value whatsoever. Instead of taking the information that was provided to him and discussing ways that both the "complex software" vendor and the customer could work to make the relationship between the two better, he uses the article to "bash" a software community and make broad sweeping generalizations about the process of implementing an ERP solution.
These types of software solutions are never simple and anyone believing that they will be is simply deluded. They are complex because they touch all aspects of a companies business and in most cases require that the end user deal with a much broader change in their day to day life then that of say a migration to a new E-commerce engine.
An ERP solution is guaranteed to touch all aspects of a business and to believe that any sales person \ consultant can get all that information in the sales process is a little bit much in my mind.
It seems to me that there is a responsibilty on both ends that needs to be met. On the solution providers side, they need to be honest about what the software can and cannot do. On the customer's side they need to have already done their due diligence and know their own processes. If they do not, then situations like what is described in the article will occur. No matter what software package is chosen!
And finally, to write an article and specifically name the software package is utterly unprofessional. It takes whatever point there was to the piece and throws it out the window, leaving any future conversations that take place to be between those individuals who are defending the software package and those that have been "burned" by the software package.
The best safeguard is a good
The best safeguard is a good user group. I operate a major course management system for our school. This is complex software comparable to the accounting software you speak of. We use the ANGEL software. At the usergroup meeting in 03, we set up a listserv (angel-l@listserv.iupui.edu). If you check the archive at listserv.iupui.edu you'll find it's thriving. The software is excellent, but the users find plenty to talk about in discussing new ways to deal with features and bugs.
Jim
Followup
I've actually talked to both sides of this situation now that the company who was implemented actually named the VAR who did the implementation.
I again state, I have no actual hands on experience with the details.
The point being, there is DEFINITELY another side to this story. The company mentioned has a good regional reputation. I'm not saying they have no fault as we all make mistakes and are only as good as our people on the project.
As pointed out above, however, what seems very unfair is the author didn't seem to solicit any comment from the vendor or publisher on the situation. He played judge and jury in this and due to the internet world we live in, I'm sure this has cost alot of goodwill to both the VAR and to Sage.
The Standish Group Chaos report states 50% of all IT projects are way over budget and time with less functionality than expected. 25% of all projects are failed and ripped out and only 25% are successful. The reason for the 75% failure rate have as much (if not more) to do with the client than the actual software or the implementor.
Don't judge Sage or Net@Work by this article, but use it as a wake up call in general to do as Wayne stated above, a conference room pilot and make sure you aren't buying based on low estimates assuming they are a fixed price. There are many happy customers of both the VAR and the Sage that don't get articles written about them. The press likes "doom and gloom." I guess happy stories don't sell magazines.
You can probably find horror stories like this for virtually every product sold. Just Google Netsuite or the darling of wall street, Salesforce.com for example.
Complex software? Plan to fail!
Having read this article, I’m amazed that so little focus or insight is provided about the process used to select the software in the first place. The article correctly notes that “the devil is in the details,” but doesn’t begin to discuss how the details were defined during the purchase cycle. It just bewails how they were “found” during the aftermath. It’s always easiest to “find” the bugs in software when you use it “as you think it should run” not the way it was designed to run.
The simple solution to this problem is to define and specify the details BEFORE you buy the product, then follow a comprehensive and well-defined plan to choose appropriate vendors, evaluate each proposed system, and write a contract to acquire it. In fact, this solution is far easier to say than it is to implement. Like complex software itself, acquiring complex software is a complex process.
NOTE: The process of choosing significant, complex, and expensive software is labor intensive, time-consuming, and very expensive. I use the words “significant software” to indicate a level of work and cost that justifies a significant expenditure of resources (people, time, and money) just to define the requirements, evaluate the offerings, make the purchase, install the product, and evaluate the results. However, if you are going to spend $150,000 for a software package to support the financial functions of your entire company, it might be wise to invest $15–20,000 before you buy just to make sure you pick the right software and the right company.
Software Acquisition Process
1) Collect the requirements
2) Prepare a requirements / evaluation matrix. Define a weight factor for each requirement (I use a scale of 1 to 5) with respect to the requirement’s importance or value to the company. Be specific about what each requirement is and what it means to you and your company!
3) Conduct a first broad scan of potential vendors to select a “shortlist” of potential vendors and eliminate obvious non-contenders. Some sources of information include industry publications, the Internet, personal experiences of employees, and members of industry groups.
4) Prepare a Request for Proposal (RFP). Make sure to include ALL the requirements.
5) Give the RFP to the shortlist of vendors. Ask vendors to reply specifically to each and every line item.
6) Conduct a demonstration of the software by each vendor.
7) Evaluate and SCORE the proposals. Give each vendor a quantitative rating for each line item in the requirements matrix (again, I use a scale of 1 to 5). The score for each line item for each vendor is the vendors rating multiplied by the weight factor. (Note: This is NOT scoring the demonstration; it is scoring the proposal. Only use the demonstration to validate the vendor’s claims in the proposal.)
8) Decide which software to buy.
As a consultant to a large microchip manufacturer some years ago, my task was to help them acquire graphic user interface software to provide user interaction with one of their corporate databases. At the time I was engaged, the small development team had already narrowed the field of competitors to 6 or 7 potential vendors. They had also decided on approximately 30 “requirements.” It took about 2 weeks just to develop that requirements / evaluation matrix with more than 280 line items.
In fact, the development team charged with making the selection were all software engineers who focused solely on the technical requirements they needed to implement the software in their programming environment. What they had not considered were all the business requirements that come with any capital purchase: things like the health and quality of the vendor, the capabilities of the vendor’s support staff, the maintenance plan and cost for the life of the software, and training capabilities of the vendor and costs to train users.
The line items fell into broad general categories, and because we now had a two-level matrix, we decided to have a two-level weighting factor: the first level was the importance of the category of requirements to the company; the second level was the relative importance of each individual requirement within its group. The score for each value was the product of the two level factors and the individual product score. (Certainly we could have eliminated the two-level complexity and come up with a single value for each line item, but choosing a single value for each requirement out of nearly 300 becomes more geometrically more difficult as you add more categories and more requirements.)
While the article seems to attack Sage Software for overselling its product, I’m more inclined to blame Digital Warehouse for not investing the time and resources to adequately and accurately define its needs and more carefully evaluate Sage’s ability to meet them. While I don’t fully endorse “caveat emptor” as a business philosophy, in this case, I think a little more responsibility falls on Digital Warehouse’s shoulders. My sincere condolences to Stephanie Bice who inherited the wind of her predecessors bad decision making process.
Post new comment