SAP custom development

4. SAP or ERP Software Modification – Custom Development

Ultimately, every project needs some development work. And by development work, I mean custom-coded programs to address “FRICE” or “RICEF” objects (Forms, Reports, Interfaces, Conversions, and Enhancements).

When you have the right developers, your project will greatly benefit, delivering on time and on budget. On the flip side, inexperienced developers bring significant hidden costs to a project that can cause slipped timelines, blown budgets, and go-live production nightmares.

To ensure the success of your project, you need to make key decisions about how much software engineering and how much business process engineering you will do. For more background on the topic, please see the following articles:

Some Suggestions to Ensure a Smooth SAP or ERP Go-Live

1) Deliver a Blueprint with at least a first pass list of needed development objects.

2) Prioritize development items by when they will be needed in the project. For example, reports can sometimes wait until right at the end of the project, and a few can even be done after the system is live. However, interfaces and conversions will be needed much sooner.

3) Add a two more levels of priority to the development items: what is truly critical, and what may have a temporary manual workaround or mitigation.

4) Break the development work up into deliverables that can be monitored and tracked. For example, you might require a functional specification (verbiage of what must be developed), a separate technical specification (the detailed inputs, process, and outputs of the development including table, field, and pseudo-code requirements), first pass coding, a code review by a trusted senior coder, testing, etc.

5) Ensure your implementation partner provides you with a list, and samples, of the deliverables and tracking tools they use to monitor development progress. You should request these during the initial proposal process.

In the end, many projects have taught me that if you get the right folks doing the job, you can have a very successful implementation. The key is to make the transition to SAP a relatively smooth and pain-free process.

SAP Interfaces and Batch Jobs

If your project requires interfaces or batch processing jobs, you need to test them thoroughly during integration testing. Then at go-live, you need to verify their operation after they are run the first time.

After the first run of any interface in the live production system, the data records should be checked on both sides of the interface: the input side and after the data is brought into SAP. The first few times the interface or batch jobs run, the team needs to clear every record error. Otherwise, you can end up in a cascading situation where similar errors repeat each time the interface or batch job runs. You must correct each of these individual errors even if they are duplicates that occur from the same master data (bad customer master, vendor master, material master, or other data). Immediately working to resolve this will significantly reduce ongoing headaches and processing problems.

ERP and SAP Month-End Business Processes

Month-end close processes must be carefully tested and scripted during your integration testing. Afterwards, you need to produce a “checklist” and all of the necessary steps. Then, you need to resolve as many master data and posting errors as possible before the first month-end close. If you wait until your first month-end, you have waited too long and will struggle with processing issues.

Be proactive in testing and planning for all of your go-live processes and issues, and you will have a much smoother go-live. Neglect them, and you will pay the price.

An SAP go-live can be both successful and relatively smooth with the right preparation. However, no amount of planning, testing, or preparation can address every issue, so a few small things will always crop up. Even so, you can minimize the impact with good planning and testing.

Costs and Consequences of Inexperienced Developers

Inexperienced developers bring hidden but very real costs to a project. They consume a highly-paid implementation consultant’s time to constantly test and pseudo code the developer’s work. Their “lower” hourly rate needs to be added to the hourly rate of the implementation consultant’s time they waste. Their inexperience also drags a project’s pace, adding additional hidden costs. In the end, their inexperience costs you far more than their “lower rate” may initially lead you to believe.

If developers do not have enough experience to start identifying key legacy data based on the project scope, get new developers. Also, keep a close eye on developers who claim they have experience but need step-by-step, detailed specs for every bit of coding they have to do, or who have a difficult time testing their own data conversions and programs. A good developer should have enough exposure and experiences with the key transactions to do most of their own testing, and even make suggestions on how master data might need to be changed or set up in the new environment.

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1

(Introduction, Security, and Authorizations)

Planning For a Smooth SAP Go-Live: Part 2

(Master Data, Data Transformation Methods)

Planning For a Smooth SAP Go-Live: Part 3

(Process Issues, Blueprinting, Testing, and Change Management)

Planning For a Smooth SAP Go-Live: Part 4

(Custom Development, Costs and Consequences of Inexperienced Developers)

Related Posts: