Developing in-house solutions for the demands of a new project is a costly undertaking, so at first glance, a vendor package may seem like the easier, less-expensive solution.
Tom Mochal’s recent article “Why do packaged implementation projects take so long?" explored the cost issues of choosing a vendor’s IT packaged solution to satisfy project needs. In it, Mochal posits that in the long run, packaged solutions can end up being too expensive and frustrating to make them a good choice. And according to a current TechRepublic discussion, members agree. Here, they offer their suggestions and some considerations to ponder before you decide on a packaged solution.
According to member tjmiller, some people think packaged solutions are similar to common shrink-wrapped software that requires only a cursory read of a Quick Start guide and a quick download. “Yet most enterprise software today requires a great deal of configuration work, which equates to the analysis, design, construction, and test of a custom software development effort,” tjmiller wrote.
Based on his experience with packaged CRM solutions, Mark Schlepphorst, a former director of technical services for a Massachusetts-based company, contends that packages can also be shortsighted. He feels that “most executive teams believe that the packaged has anticipated all of the company’s needs for today and tomorrow.”
Feeling secure that the package will solve the problem, many executives distance themselves from the process, according to Schlepphorst. Then, after the solution has been in place and its shortcomings become apparent, the people who approved the packaged solution are surprised and frustrated with the necessary revisions and costly customization.
Obstacles to packaged solutions
So what are some of the issues that call for user involvement and customization? Member Ed Gooding, president of Merge Computer Group, Inc., cites two possible scenarios that “have the ability to make an ‘easy’ packaged installation a nightmare or even a disaster:
- · “The conversion of existing data into the new package’s databases
- · “Interfacing the new package with existing in-house systems (whether they be custom-developed or other packages), which may consist of a variety of databases and technologies”
Grappling with these issues requires significant understanding, planning, analysis, and testing. Not only are these time-consuming endeavors, Gooding wrote, but the organization also needs to have someone on board that can undertake them.
Project manager Glen Maxfield suggests, however, that many organizations may not have this in-house capability. “All of the technical staff have to be trained, and all of them must struggle through the implementation because they’ve never done it before. By definition, the project is staffed with rookies.”
And even if the existing staff is trained in dealing with a packaged solution and its implementation, the extra workload may cause stress throughout the rest of the IT organization. Maxfield spoke of a company that implemented Oracle Financials into its system where “the number of people dedicated to supporting financial systems went from four to eight. These people were just stolen from other support areas, and the positions were not back-filled.”
At the mercy of vendors
In addition to the myriad problems outlined above, member Dan Shatto, an IT manager, suggests that dealing with a vendor may jeopardize the organization’s autonomy.
“Ultimately, it may come down to a decision of control: Do I want my company to be at the mercy of a vendor, or do I want control over how my system is enhanced in the future?”
Member bogdincescu knows full well how an organization can become too reliant on a packaged solution. Bogdincescu saw a highly customized MFG/PRO 7.4—one of QAD’s Web-enabled core enterprise application packages—that became very problematic when his organization attempted to upgrade it. The initial customization of the package, which required costly funding and time, made it difficult to integrate the updated versions.
Are packaged solutions risky undertakings when compared to in-house developments? Are there additional risks that you’ve encountered when looking to vendors for solutions? Join the discussion and share your thoughts.