Editor’s note: Scott Robinson is an IT consultant who has worked on several dynamic SAP implementations. This is a series of “talking points” he’s developed to help consultants explain the benefits of such an approach.

There you sit, facing a harried IT manager. You’re being interviewed for a lead position on an SAP R/3 implementation. The manager is under considerable pressure: Senior management has high expectations for this project and an SAP implementation is new territory for the person who’s thinking of hiring you.

You’re asked a pivotal question: “What would your approach be to an implementation like this one? What method do you feel would be best?”

And you say, with confidence, “A dynamic implementation, unquestionably …”

Why dynamic?
An SAP R/3 implementation, by definition, upsets the routine of every department and virtually every employee in an organization that implements it. Dynamic SAP implementation allows for flexible, adaptable, interactive development that’s robust enough to withstand constant changes in requirements and inevitable shifts in resources and project scope.

Dynamic SAP R/3 implementation is a European innovation, but is appropriate in just about any context. As SAP R/3 broke open the U.S. market for ERP in the mid-90s, the reasons for dynamic implementation strategies became obvious and are quite prevalent (the traditional SAP model is still used, but isn’t as effective). The reasons include:

  1. System requirements that change, sometimes drastically, as many users submit and refine their input in defining them.
  2. The need to accommodate a client’s fixed schedule (for budgetary and other reasons).
  3. The need to reuse system components, once developed.
  4. The need to integrate many heretofore nonintegrated business processes (e.g., orders and shipping documents).

If you can find an SAP R/3 implementation that doesn’t include these components, you’re in uncharted territory. This list practically defines SAP.

A quick sketch of the plan you’ll present
A dynamic approach, you can tell your potential client, will include several key components:

  • Empowerment of team members to make design decisions and to eliminate managerial bottlenecks
  • Perpetual testing throughout the complete life cycle, so that a robust system is delivered
  • Heavy user/customer participation in feasibility study, business study, system design, and testing, to ensure deliverables of maximum utility
  • Restriction of system modifications to reversible changes, as in the case of database reconfiguration to allow for new fields or pointers, to minimize the impact of design and programming errors on schedule
  • Accommodation of modified requirements in every phase of system development (a practical necessity, because these modifications are inevitable)
  • An iterative design paradigm, across cyclic functional model development and system build, to allow for rigorous review throughout system design and prototyping

You’ll get a long stare at this point. This distribution of resources will seem unusual to a traditionalist. But if you’re well prepared, you can impress on your future boss your understanding of the issues that threaten the efficiency of the project.

Why it’s the best
Here’s your rationale, point by point.

  1. Requirements will change frequently. In any ERP implementation, SAP R/3 or otherwise, this will be true. For example, I implemented a simple upgrade of a purchase order processing system with a client in a complex supply chain, to enable an EDI step—subsequent purchase order modifications. As simple as this seems, it went through three rounds of changes in the requirements before implementation began. Dynamic development methodology exists mainly to accommodate this.
  2. A high-to-low prioritization of system features can be generated and agreed on by senior management. In creating a fully integrated system, processes not only change, they sometimes vanish, to be replaced by new ones. This occurs as new business possibilities emerge in the planning, and old processes become unnecessary. This is the very definition of dynamic; and it is certainly the rule, not the exception, in any SAP implementation.
  3. Dynamic development requires clear differentiation between departments. To integrate business units, functional groups of users must be distinct; otherwise, integrating them becomes a process exceedingly difficult to define. In SAP R/3, all business processes have unique interfaces, specific to distinct user groups.
  4. System functionality is defined by end-user needs. This is an SAP R/3 fundamental. The emphasis on ease-of-use and increased functionality is what has made systems integration possible. Dynamic development requires this obvious interface-driven functionality; when it is not present, functional requirement changes become a bottleneck.
  5. Dynamic methodologies accommodate fixed schedules. They must, or all such projects would oscillate out of control. This is especially important in an SAP R/3 implementation, in which you (as a lead consultant) must work with highly-paid hired guns. Senior management has probably already pounded into your interviewer the need to deliver on time and on budget.
  6. Large-scale systems can only be dynamically developed if they can be defined in terms of small, functional components. This should be obvious, but often isn’t to senior management. However, it’s not a problem here: SAP R/3 is built on the premise of well-integrated modularity.

Taking the plunge
If an SAP implementation were easy, clients wouldn’t need you. If they knew the best way to do it, they’d pay a lot less to have in-house staff do what they think best.

When it comes to SAP, few in-house people are going to understand the best roads to take when implementation time comes. The consultant has a chance to take his client by storm, resolving issues before they become problems, and helping to steer the project home when the skies aren’t all that clear. With this robust and flexible approach, you’ll get it there.