The elements of a high-level project plan for designing, building and testing the technical solution, assuming FRICEW elements will be required for every major area

The High Level project plan that any SAP global implementation, which can follow any project management methodology should fall in the following categories. I myself had implemented one complete global SAP implementation for an UN agency and had followed SAP prescribed ASAP methodology. The steps are

o   Project Preparation

o   Business Blueprint

o   Realization

o   Final Preparation

o   Go Live and support

Before going in to the details of the technical solution, which predominantly happens in the realization phase, I need to make sure the following four facts are considered even during the business blueprint. Even though in many occasions, the business blue printing may be software agnostic, when considering SAP suite as a solution, I’d like to point out the following facts, which I strongly believe and follow, to demystify the whole process and the need for a ‘technical solution’ expert to handle them.

• The first and foremost fact is the SAP IS-PS software, off the shelf product, how best maps to the requirement of your business process. Even though the golden rule of a SAP application implementation is to have minimal customization to avoid the complexity and the total cost of ownership; it is unavoidable to get in to the discussion of what amount is considered as safe for the organization to undertake the customization.  The new SAP application architecture provides some interesting and compelling features that can manage this argument effectively, because the out of the box software (SAP IS-PS) is either too much or too little, and is always not enough.
• The next fact that needs to be understood is that the core business process of a public sector is completely opposite of the conventional industry. The significance of the application component integration within the public sector solution is more pronounced as against the others. The integration of Funds management and budget control system is a distinct example of this. This tight integration needs higher degree of technical understanding in providing the solutions for the process or business issues. The ‘technical solution’ that is taken as an overarching principle in all areas of the project stream.
• The third fact is the need of real-real time reporting and the availability of real time data across the platform. Even though this requirement is pronounced in the UN agencies is traditionally undeserved, lacks competency and depth. And also the global SAP implantation projects take years of implementation, years of stabilization demands the nature of the technical solutions to be able to handle the business requirement for a considerable future.
• Finally, it is the subject of sustainability and making the project reflect that we are socially responsible as the organization and its mission. There are certain functions that UN requires are not in part of the SAP’s core system. This will require buying and installing bolt on systems either belonging to SAP’s suite or third party systems. In either way these decision incur a set of hardware, software, processing and maintenance. This increases not only the total cost of ownership, but also the greenhouse gas emissions. Utmost care should be taken to avoid any bolt on system as long as they are unavoidable. Sensible architecture approach will eliminate majority of these requirements

The Major elements of the development comprise of the FRICFW components, which would have been identified in the business blue print phase. But in reality, it is a process of progressive elaboration. In my experience, there were instances that some of the business requirements that were not possible, some of them had to change and some of them were created after understanding the possibility. The following are the steps I insisted, followed and believe in the realization phase, where the technical solutions are designed, build, and tested.

·         General Project Management (Realization Phase): This needs to be created based on the outcome of the business process blueprinting

·         Organizational Change Management: Is a key component that needs to be addressed upfront. This includes the increasing the awareness, managing the user expectation, keeping the scope of the project intact and focusing the milestones.

·         Training and Documentation (Realization Phase): This process needs to be taken seriously, as this is addition with the project communication plan will affect the end users directly. Development od end user training templates, modes of delivery and creation of the content are to be performed here.

·         Developments, User Interface, Integration: This is the key area where the technical solution plays an important part. All agreed and approved developments are managed here. I’d followed and insisted to have one project plan for the entire development effort, but would split it in to multiple streams of business functions (Programme. Finance, HR, Supply and common functions). I’ll detail the development process in the next section (Managing the technical solution)

·         Baseline Configuration: SAP System is configured with the baseline information and is pretty much ready for the unit testing

·         Quality Assurance Installation: Testing instances are created. And both functional tests (unit test, Integration test, User acceptance test, Systems integration test, Data test & Security tests) and performance tests (Volume testing & stress testing) are performed to validate the final product. All defects that are identified in each cycle are classified, prioritized and remediated. Care should be taken to differentiate the defects and the change requests.

·         Cutover and Go-Live Planning

·         Lifecycle Data Management

·         Authorizations and Security Implementation

·         Final Integration Test

Managing technical solution and Design Thinking in all areas (FRICEW)

• Any business requirement that has been established in the blue print may convert in to the one of the following during the realization phase. The following should be the sequence of actions while providing a technical solution:
• Standard product supports the process
• Standard product supports the process with enhancement
• Standard product does not support the process, go back to business and suggest change in the process
• Standard product does not support the product and the business cannot change the process, then think of ‘custom development’
• The talk about of the Custom development is treated, as a sin in the SAP implementation world, is partly true and partly exaggerated. The true part is that the any custom development that needs to be built by the customer poses a risk of future upgrades and loss of SAP’s standard support. But the no-so true part is the increase in the total cost of ownership. This is because the lack of knowledge in this area and the lack of the understanding of the architecture of the SAP product itself. A typical global implementation solution would be somewhere 80% standard configuration combined with 20% of custom development to reflect the agreed upon business process requirements. But because of the lack of knowledge of how and where to implement and provide custom enhancement had greatly affected the implementations. The core principles that needs to be followed are:
• Aligning with SAP’s architectural components and (to eliminate upgrade risk)
• Non-destructive construction of custom developments (for SAP’s support)
• The biggest challenge that is faced by any SAP implementation, in particular is to go back to business to explain them that their genuine, simple requirement can’t be reflected in the system quite simply because the underlying software does not allow the change. This was very acceptable argument till last few years, when SAP was considered as the collection of business processes that are ‘the’ benchmarked practices and should be followed unequivocally by all businesses. But recently SAP they themselves understood their non-rational statement and rebuilt their product on enterprise service oriented architecture (e-SOA). This enables the customer who is implementing this process to orchestrate their business process in the way they want and to focus and minimize the custom development. If one follows this methodology and build the final product, this will yield highest business buy-ins and ultimately reduce the total cost of ownership (TCO).
• SAP’s Accelerated SAP (ASAP) implementation methodology supports these custom developments and encourages the business to start this ‘design thinking’ even during the blue printing phase. In reality they themselves do that with many customers. I had worked with them in developing the SAP-HR and payroll for NPO solutions and have a first-hand knowledge of how SAP build the solution as a customer development and merge the CDP solutions into them in their own future products.