Skip to Content

…especially the potential problems!

Remark: this article is about the ERP core scope (no CRM, SRM, BI etc) and focuses on so called “transactions” – components of processes having influence on the data base. The reports (visualizing in any form the collected data but not changing them) are separate area an may be changed in every moment – are not a subject of this article.

Due to my experience the blueprint is the most critical point of the ERP implementation project, building some kind of the fundament for the project and deployment of ERP. That is why blueprint has to be very good prepared, understood, considered and accepted by all responsible stakeholders.

In practice is that often the most important think at the end of Blueprint phase is … the deadline. That’s clear – in fact this is the first project (not organizational) phase and everybody likes to have the first success! The mood on the project is in this point very good and that can be also the reason to left the problematic points in the blueprint for later consideration. That may cost later a lot!

Due to my experience all projects with troubles I had to correct had something common: lack of proper blueprint (with open issues) and frivolous project management. In fact all the potential troubles on projects are already to be seen and predicted by evaluation of the blueprint. The problem is that the results in form of problems are separated from reasons in weakness of blueprint by the time. The weakness of the blueprint are mostly coming in spotlight not sooner than at the end of a realization phase. At that time they are sometimes also not seen as something significant and are left for correction in the next phase. In this way the “erosion” is damaging slowly the fundaments of the project.

The problems occurring in later stages of the project are damaging the mood – nobody recalls then the good mood by the blueprint closing. Especially the customer is claiming the vendor is not competent and the vendor is claiming that the customer is changing specification and thus is breaking the rules. It is clear that the only one responsible is the implementation vendor – the management of the project is on the vendors side.

SAP ERP is, as of my strong belief, based on experience – very tolerant in implementation. The embedded implementation tools and very good ASAP methodology are securing the implementation process. However if the project manager and/or other stakeholders are bypassing the steps and quality gates there is no “artificial intelligence” inside to mitigate them! In this circumstances it may produce a situation with the higher risk for the project and potential problems.

Please note that changes made after the respective phase closing are often made without the right consideration – in fact outside the quality gate. This especially is critical by ERP where the data stored and transactions using and changing the data are highly crossed through the whole scope and project teams are from various business units where the communication and integration between teams is a big issue for the implementation.

Changes in one area may influence many other areas. Project flow “orchestrated” by ASAP is requiring the right audience and right consideration on every step on the project. But in case some specification is changed already after the close of a blueprint phase it may be not considered right by all stakeholders. Especially in the situation of many changes in many areas – even not significant as it may be seen individually – can reach the critical mass and cause troubles.

EXAPLE: Implementing Retail functionality with change (extension) of characteristics of the goods (seeming not significant) may lead to significant grow of the data size that can be critical in both terms: transfer and storage. When not evaluated correctly may lead to disruption of the business – and sometimes as you may read about “ERP failures” is.

In fact the right remedy for above described problems is very simple and cheap:

1. To prepare the blueprint very carefully in order to ensure covering the full scope of the project and understanding and commitment by all responsible stakeholders;

2. To recommended taking an external (from outside of the project) solution architect or project manager and making review of the Blueprint or even wider the whole project in this point of time.

It is much more important to have the blueprint of best quality than to have it on time. In other words – some delay caused by blueprint preparation cost significantly less than the potential troubles caused by the wrong blueprint.

During my work by SAP the project audit by the end of blueprint phase was practiced sometimes with always very good result. Usually people involved – even project managers – are loosing a big picture view. That’s normal  – and may occur especially in the rush time of closing the phase. Always somebody experienced with fresh look will see open issues or not solved problems.

That I like to put as recommendation for ASAP team: to strengthen the ASAP tools force better control of blueprint quality.

That aspect is also my next one objection about the use of AGILE by SAP ERP implementation – what I explain in:

http://scn.sap.com/community/asap-methodology/blog/2012/10/14/i-am-sure-agile-is-not-for-big-sap-erp-implementations-part-ii

  1. PS. Dear Readers of this article –if you find it usable for you please award me wit “like” or even rank with stars! This is effect of my evaluations with the target to create small focused on most important aspects implementation handbook: I will be grateful for every critical comment – for the essential ones I can make award in the discussions:

http://scn.sap.com/thread/3251314

http://scn.sap.com/thread/3251313

best regards

Waldemar FaliƄski

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply