News & Views

We now have about 50 systems participating in our free on-line service that will match the Top 10 ERP Systems to your requirements based on a short online survey. 

We continue to enhance our tools and have just completed the development of an RFP tool that will automate the creation of RFPs as well as the % fit calculations based on vendors’ response. The system will make it easier for us to create RFPs. It will also be easier for vendors to respond to our RFPs as their responses to standard questions will default based on previous RFP responses.

June 2010 from ProjectTimes written by IAG – “…Our objective in each case was to describe, in detail, all of the data flows,, the business rules, processes, an functionality needed as if our client’s next step was to build the system in-house regardless of whether the system is a commercial purchase package…”

180 View – We agree with the article on the importance of gathering business requirements, but disagree strongly with the approach. If you’re selecting a commercial ERP system used by hundreds if not thousands of organizations, it’s a waste of time to gather detailed requirements on basic functionality.

June 2010 from CAmagazine written by Michael Burns – “Before replacing any system, you need to document your requirements. Obvious, right? You just have to talk to the people working with the existing system and ask them for the requirements. But that would be a huge mistake, for a number of reasons.  If employees are afraid the new system will automate a big part of their job, they might be reluctant to tell the whole story. Also, they might be unable to think outside of their own box, or they might think certain tasks are not worth mentioning. There is a better way…”

March 30, 2010 from InfoWorld – “When the economy is bad, businesses hold off on buying new enterprise apps and instead try to prolong the life of the ones they have. But there’s still the significant expense of vendors’ support contracts. Third-party support contracts may be the answer to reducing that cost.

 Software vendors don’t want to lose those support revenues, especially since they’re making less in new and upgrade sales. Some even have tried to raise their support income through schemes such as tiered support (a debacle at SAP) or all-or-nothing support (Oracle’s most recent approach to extracting more money from customers) — but doing so risks driving customers even faster to third-party offerings…

 Is third-party support right for you?

The answer depends mainly on two factors, says Forrester Research analyst Paul Hamerman: where the application is in its lifecycle and how important it is for you to stay current with software upgrades. “If [a user] has an installation that’s a couple releases back, customized, and difficult to upgrade, third-party support is a more viable option,” he says. “If it’s an expanding business or a new installation, third-party isn’t a good option because you’re off the enhancement pack…”

180 View – Even if you’re not interested in third party support, the article does provide advice on maintenance agreements.

March 2010 from IndustryWeek – IndustryWeek posed the following hypothetical problem inviting solutions to the problem which have also been published on their site.

“One year ago my company embarked on an enterprise-wide implementation, selecting an ERP system and a suite of software to address our primary business functions. This decision was not made lightly. Lestornia Lighting is a $120 million manufacturer of commercial and industrial lighting fixtures and components (e.g., sockets, lampholders, wiring harnesses, reflectors). We’ve grown incrementally over the past two decades, and our business practices and processes — and the information technology (IT) that supports them — has grown piece by piece as well. I finally concluded that the Frankenstein IT infrastructure we had cobbled together needed to be destroyed. Now I greatly regret my decision…”

Literally from the outset of our enterprise implementation, the scope of functionality, customizations, and departments and personnel engaged in the effort have spread like wildfire. Lestornia expected to be operating with our new systems six months ago; now we cannot get a projected date for when we will hit the switch. The escalation of costs specific to software licensing and the implementation have blown beyond anything I’d ever imagined. And with the infectious spread of applications and department-specific functionality and customization, our training and maintenance costs are doubling by the day.

I swear that every person in the company is working on this system and software implementation in some way or another, and no one is focused on making lighting products or focused on our customers. I am afraid that this project will, quite simply, kill Lestornia before we ever see a dime of return from our investment. How can we subdue the new monster we’ve created?”

180 View – Although the problem is hypothetical, most people have heard of similar nightmares. Our opinion is that the risks of these problems occurring have been significantly reduced, but not eliminated. There are many ways to reduce the risks but the one that seems most relevant in this case is lack of scope and requirements definition prior to the selection of the new system.

October 2009 from IBM via ProjectTimes – These are the traps with descriptions and how to avoid them in the linked article:

1. Scope creep
2. Asking customers what they want
3. Inability to adapt to change
4. Failure to communicate effectively
5. Failure to communicate frequently
6. Unwieldy documents and too much information
7. Hidden project artifacts
8. Ambiguous requirements
9. Failure to measure and assess requirements processes
10. Isolating your requirements

180 View – Although the article was written for getting requirements for software development, it also applies to getting requirements for a software selection project. The key difference between requirements definition in software development and software selection is in the level of detail.

One would not expect “asking customers what they want” to be a trap. The article claims that “customers tend to talk about features, not what they truly need. The truth is that people often don’t know what they want.” The article says the solution lies in asking customers why they need a particular solution. I agree with the problem but not the solution. It would be better to ask the customer to describe their existing business process and its problems. In this way, the customer exposes the strengths and weaknesses of the existing system, and the business analyst can suggest alternative ways to solve the problems. The business analyst should know what is possible in software development and what is possible in existing systems but also needs to understand the business impact of a particular problem. There is no point in creating or implementing an expensive solution to a problem that causes a few minutes to be wasted a week for one person even though the customer finds it annoying.

November 5, 2009 from Forbes – “Minimalist design has been in vogue for decades. But when did we become enamored of the stripped-down business practice? When did business really start to leverage the power of less?

Google has led the way here. Remember the first time you landed on that spare, slightly dorky page, with just a multicolor logo and an empty box? We take it for granted now, but at the time it was revolutionary; every other search portal was competing to cram as many links, categories, ads and blinking gifs into 800×1200 pixels as it could…

But the art of less got a significant boost since economic conditions deteriorated, and less became the one thing we all had plenty of. In the best case scenarios, creative “power of less” responses to dramatic budget cuts have resulted in outcomes much better than the status quo, especially when technology was leveraged…”

180 View – When assisting organizations with software selection, the tendency for most organizations is to create a substantial list of requirements. We ask our clients to prioritize the requirements so as to just focus on the most important ones. We ask the vendors to just respond to the high priority items. It’s our way of doing more with less by nailing the most important requirements and not getting bogged down with less important requirements.

As well, when designing the to-be businss process, it’s a good idea to keep it simple if possible. This is a huge challenge for organizations with multiple profit centres each with their own unique way of doing things. If the profit centres could share the same business processes, you also achieve more with less.

May 18, 2009 from ComputerWorld – “…Epicor’s representatives were given the Requirements list prior to entering any contract negotiations, and Epicor represented its product would be able to perform all of Ferazzoli’s requirements,” the complaint states…

In June 2007, Epicor officials visited Ferazzoli’s headquarters to learn about the business and demonstrate its software. The officials made further assurances that Epicor’s technology would be satisfactory, according to the complaint…”

180 View – There are many reasons for failed implementations, and we can’t speculate what happened here. However, we think the problem is not likely the software but more likely the selection and implementation process. In the article, a suggestion is made – “You want to make sure that all demos, marketing materials, and assurances are put into the (contract) document.” We partly agree with this recommendation. But demo’s and assurances are too vague. Better would be to include specific requirements from an RFP to which the vendor responded.

February 19, 2009 from InfoWorld – “The recession has companies worldwide scrambling to rein in technology costs with desperate vendors responding in turn, offering deep license discounts, providing low-cost financing and proclaiming ever more shrilly that their products in fact save customers money…”

180 View – It’s going to be a tough sell for companies to invest in technology if they have just been forced to lay off part of their work force. However, there are companies that will want to scale back their on-going IT costs. They may be able to do this by renegotiating terms with their vendor and in optimizing certain inefficient business processes. Another possibility is replacing a costly system. Costs of the existing system could be high based on annual maintenance fees calculated on the original license fee. Costs could also be high for the internal and external costs to support the system. And costs could be high if substantial work is required for upgrades. But be careful with replacement strategy as the internal costs to implement a new system can be very high too.

January 1, 2008 from CFO Magazine “Ever since 1963, the year it first issued shares in New York, Japanese electronics giant NEC Corp. has proudly reported its financial results according to U.S. generally accepted accounting principles. The $42 billion (in revenues) maker of computers, monitors, and semiconductors was so steeped in U.S. GAAP, in fact, that its Tokyo-based finance staff had little knowledge of Japanese accounting standards.

Then, in 2006, NEC’s auditors from Shin Nihon Ernst & Young began questioning how the company had recognized revenue for contracts that included multiple items such as hardware, software, maintenance, and support services. At issue was the company’s approach to a one-two regulatory punch: SOP 97-2, which governs how companies that sell software recognize the revenue; and VSOE, or vendor-specific objective evidence, a method for determining the individual value of each item within a contract in order to recognize partial revenue before the entire contract is fulfilled…”

180 View – Revenue recognition requirements often lead to manual systems for many companies. When seeking new systems and you have revenue recognition requirements, look for systems that are able to automatically move revenue from deferred to recognized according to business rules so there is no need to back it out of the general ledger and re-allocate it manually.

December 2007 from CAmagazine and written by Michael Burns – “For many companies, replacing a system is like going to the dentist: necessary, but potentially painful. Often, you can stave off the need for replacement with preventive action such as upgrades. But if the system is no longer supported, or if there has been a change in the business that renders it inadequate, you have no choice but to go to market. And when you do, it’s easy to make big mistakes. Here are the biggest ones…”

December 17 from TEC – “It is daunting for corporate IT buyers to discern the true capabilities, strengths, and weaknesses of a given enterprise application suite. Buyers’ project teams are inundated with marketing information from vendors struggling to differentiate themselves. Functional cross-over and software integration have caused product overlap and a lot of confusion in the market. Mergers and acquisitions are also creating problems, as companies cannibalize the competition to gain access to a client base or functionality, which may result in solution overlap or forced migration. As a result, organizations are surrounded by ambiguity when making their implementation decisions.

Evaluating and selecting enterprise software is a complex process characterized by both striking potential and dramatic risks. Executed properly, this process and its outcomes can deliver exceptional benefits. If executed poorly, however, the results can range from disappointing to devastating. Organizations that select the wrong hardware, middleware, or software will learn the hard way that the money they’ve lost is a result of inadequate vendor information and evaluation processes. Such losses are increasingly apparent within price-sensitive, small and medium enterprises, which require accurate IT information to be collected quickly and cost-effectively during the software evaluation process. Vendor’s hype, consultants’ conflicts of interest, user doubt, tediously long selection processes, and unclear decision rationale are some of the unfortunate watchwords for most selection processes.”

180 View – The article is clearly self serving to TEC in that they offer a potential solution to avoid the problems that they describe in the article. “TEC’s evaluation centers (online decision support tool) support the analysis and comparison of thousands of criteria on hundreds of vendor solutions that have been vetted by TEC’s analysts, using industry standards and benchmarks. Because vendors respond to TEC’s RFIs without a project in mind, the responses are more typical of their capabilities.” TEC also lets users “prioritize their needs in a manner that gives greater priority to criteria that are considered more important.”

You should know that TEC is in some ways a competitor of 180 Systems. We have not spoken to any of their customers about the usefulness of their services or used it ourselves. Our first impressions are that we find it hard to believe that they have vetted thousands of criteria on hundreds of vendors. Second we don’t think that the vendor’s responses will be more typical of their capabilities because they are responding to TEC’s RFI. Rather, we think the vendor will be more forthright when respondong directly to a customer RFP if the questions are specific. The vendor must be honest or trust will be lost, and the decision in the end is mostly about trust. We also note that their priority system is at a very high level – for example financial systems rather than at a more detailed level, which we believe could lead to misleading results. Nevertheless, we recognize that TEC may have a useful role to play in a selection project even if it means that a potential client would use their services rather than the services of 180 Systems.

Lately we have been thinking that we should also provide a similar service to TEC based on our extensive knowledge base. We would like to hear from our readers about their experience with TEC and whether we should offer something similar.

August 29, 2006 from InfoWorld – “The road to new software can follow a strange and convoluted course. I was feeling optimistic as I began a new consulting engagement for a national retailer, as part of a team developing an RFP (request for proposal) for a new HR/Payroll application. True, there were 12 divisions, and each one required a detailed process-flow-and-requirements definition. But having met with the key users in each area, I was confident we’d be able to sort everything out. In addition, we enjoyed the support of the VP in charge of HR, which helped us avoid many of the stalling tactics that typically occur during such efforts.

Months later we ended up with two three-inch binders of requirements, which we mailed out to vendors. Then we waited for their responses. Two vendors I’ll call “HRC” and “Acme Software” made the cut. Several weeks later they came in to show off their performing dogs and ponies.

The IT people immediately saw the technological advantages and superior functionality of HRC’s Windows-based offering. We also saw that Acme was trying to sell us a hasty retrofit of their mainframe software sitting in “a window.” Unfortunately, the users we were working for thought both offerings were essentially identical. In fact, since Acme had a persuasive representative with vast experience in payroll, and as our user team had a strong payroll (vs. HR functionality) bias, the retailers were starting to lean toward Acme.

Then, Harry, our project manager (whom I knew for a fine programmer, but no politician) surprised us all with a brilliant play. For some reason, he was always at odds with Bob, the key HR staffer who was leading the evaluation. Harry and Bob always took opposite positions. Anyway, during a lunch break, I overheard Harry confiding to Bob how much he liked Acme’s offering. A few minutes later, back in the conference room, the user team flipped its position and voted for HRC — our IT team’s choice!

From that point on, the evaluation moved steadily forward to select the vendor we knew would be superior. I thought we were home free. No such luck.

HRC submitted a two-page license agreement to be reviewed by the legal department and the users. By the time the negotiations were completed, the document had blossomed to 26 pages of performance guarantees, special clauses, and a dazzling array of stipulations.

Just as this process seemed to be winding down, we received word from the corporate executives that the deal was off! Too expensive, we were told; we’d have to purchase too much high-end hardware to support the system.

We were devastated. Our baby was dead. All we had to show were two three-ring binders of requirements. And I was out of a job. As it turns out, those binders were important. Several months later the information they held was used to redefine job descriptions and create critical enhancements to the existing in-house HR software.

Ultimately, 60 developers were hired to handle that workload. Sadly, I wasn’t one of them. But that’s not the end of the story. Nearly three years later, after a change of CIOs, a new management team (which still had a bias for payroll functionality) took over the reins of power. And guess what? They went right out and bought Acme’s HR/Payroll package.”

180 View – This article is a good case study of what not to do:

1. There is something terribly wrong if you have “two three-inch binders of requirements”. You’re not designing a system from scratch. You should be including only what’s important and what differs across systems.
2. The RFP was mailed. It should be sent electronically as a turnaround document.
3. Only 2 vendors made the cut from the RFP. You should be doing more diligence before cutting it down to only 2.
4. The 2 vendors “came in to show off their performing dogs and ponies”. The vendors should be given instructions to tailor the demonstration.
5. “Just as this process seemed to be winding down, we received word from the corporate executives that the deal was off! Too expensive, we were told; we’d have to purchase too much high-end hardware to support the system.” – Whatever happened to total cost of ownership? This should have been understood earlier in the process.
6. “Ultimately, 60 developers were hired to handle that workload. Sadly, I wasn’t one of them.” The so-called consultant had no business participating in the selection process if he also wanted to be involved in the implementation.

Whitepaper from QuickArrow – “Billable Services Organizations can benefit greatly from the use of a Professional Services Automation (PSA) solution. Choosing the correct PSA application is one of the most important decisions a services organization can make; as such, it can also be a daunting challenge. Many factors should be taken into account when comparing PSA solutions – some related to technology and others based on functionality. The goal is to select a solution that is compatible with your business goals and is easy to use.”

180 View – Although this article is written by one of the PSA vendors, you will find useful information that is written without the typical marketing spin.