Implementing SAP is probably the single biggest IT/Business project undertaken by any organisation, and for members of SAP project teams over the years, this will probably be the most stressful (and hopefully rewarding) experience of their lives. While this blog is by no means intended to scare off potential new SAP customers, a variety of project implementation methodologies have been tried and tested over the last 20 years (some quite successfully) and this is an attempt to illustrate what works well in today’s world.

In today's environment every organization wants their IT project to deliver a solution which can cater to today's complex business needs with an adaptability to meet tomorrow's challenging and changing requirement with ease. This is where the ERP packages have taken the market, by providing all different functionality under the same roof. This in turn reduces the project implementation time by reducing integration points; it also enables easier support in the long run by reducing cost of managing different vendors for different applications.

Although this concept of the one-stop shop is applicable for most areas in an ERP environment, in certain areas like CTI, Resource Scheduling, Reporting etc., organizations still evaluate from the multiple options available to them. One reason for this is that the ERP application may not offer the "Best-in-Breed"capabilities in these specialist areas.

If you look back in the history of software, it has always been based on abstraction of the real world. The real world, however, is a place of continuous change. Most business applications have been written to support business processes that are fairly stable, hence providing the repeatability that is needed to perform tasks efficiently. Certain industries like Insurance and Banking are faced with business rules that need constant changes. This is because of a variety of factors like the nature of the business, compliance to local and global policies, government regulations etc.

Imagine a piece of code which represents business rules. As part of the evolution of software engineering, modularization techniques were introduced to make this piece of code re-usable,and easier to maintain.In the SAP ABAP world, a familiar technique was the use of function modules - certain input parameters were passed to the function module and certain output values were determined – much like the use of simple real life tools like the calculator. Business rules could be coded within this function module and could be called from other programs.

Resource Scheduling in the Service environment is an area that has been largely being viewed with a degree of apprehension by companies that have implemented SAP. This is in part because Service requirements are quite varied from one company to another, but largely due to the fact that there is limited understanding about what options are available for consideration, and which among these options meet the criteria of a) ease of use b) functional fit and c) cost to implement.

In a purely SAP ERP driven environment, the options for resource scheduling are limited, whether it is with the use of PS (Project System) and Work Force Planning or with the use of CS (Customer Service) or PM (Plant Maintenance) where the choices are not very easy to evaluate, and external tools were deployed to work in conjunction with SAP.