Talk about luck. I’ve been fortunate (?) enough to have managed or assisted with the installation of products from both titans of the Enterprise Resource Planning world: Oracle and SAP (three if you count Peoplesoft, which Oracle swallowed in 2004). As I’ve come to understand at the cellular level that these types of projects are in a class by themselves, I’ve also discovered what I consider to be the most important success factors for project managers involved in ERP projects.
Type “ERP implementation nightmares” into Google and you’ll receive over 6000 results. CIO.Com recently listed several botched Oracle and SAP rollouts in their “25 Terrifying Information Technology Horror Stories” article, for example, not even including the cancelled 2007 Philadelphia water billing system project which ranks among the biggest Oracle catastrophes ever. The roll call of blown budgets and endless delays underscores the multifarious nature of ERP projects. These implementations can be among the most complex and challenging that an IT project manager will ever face.
This is hardly fresh news, but I want to provide my own take on some of the biggest ERP headaches and on the solutions that I actually helped implement. These lists are far from all-inclusive, but I hope they give potential PM’s some idea what they might be in for when they sign up for an Oracle or SAP installation.
The “Big Three” Issues
• Integration and Interface Development: How well does the new package link up to existing upstream and downstream systems (such as legacy data, data warehouses, external partner systems or reporting tools?) I’ve seen programmers tear their hair out trying to get data to transmit correctly using EDI, and struggle endlessly to chase down why information doesn’t display properly in reports.
• Customization: No off the shelf product is truly plug and play. ERP projects usually involve massive amounts of work to accommodate the system to each organization’s homegrown terminology, processes, workflows, and standards. Sometimes this feels like pounding a round peg into a square hole.
• Impact to Business Processes: An Oracle or SAP installation will usually force organizations to alter procedures and workflows, sometimes drastically, to accommodate the design of the package. This widens the net of stakeholders and boosts up the project risk level considerably. Yet some executives cling to the delusion that ERP products can simply be plugged in to host and enhance their current processes.
Success Factors
• Before even starting: The business needs to crunch the numbers and truly quantify the business benefits that ERP should bring. (You would think that this would be a no-brainer for a multi-million dollar investment, but I know of one organization that simply assumed that the benefits were “self-evident given the state of the current system.”) They should invest more time than ever defining requirements, success criteria, even entry-exit criteria by phase. Part of this will be choosing which elements of the vendor package are required to meet these requirements (SAP and Oracle have Financial, HR, CRM, and more components) and where gaps may remain. The business also needs to decide which parts of the company that the new system will be rolled out to, and negotiate strong terms and conditions in the contract for the system’s performance so the vendor can’t leave them in the lurch. All sound too basic? You’d be surprised how often enterprises skim over them in the name of expediency (and later pay the price.)
• Let the end users participate in the design process. This should be mandatory. After our Peoplesoft Global Financial implementation, for example, the accounting clerks pointed out that a journal voucher now took twice as long to enter is it did using the old system, thanks to a screen progression that we could have easily customized to flow better. (On the other hand, giving users too much control can have even worse results, as the PMs for the Philadelphia Oracle installation discovered.)
• Most important of all - find the right project manager. It’s not enough that the PM has sufficient ERP implementation experience for technical credibility. These projects also require much stronger business savvy then the manager of a smaller scope would ever need. The ERP PM will be a mini-executive negotiating with executive stakeholders and championing an effort that impacts the length and breadth of their organization. The Senior PM who ran our SAP CRM 3.1 install, for example, was interacting daily with Senior VPs and making decisions that profoundly impacted the operations of the company. A mere technician would have been in way over their head.
No comments:
Post a Comment