For those of you who are not familiar with Optimal, some quick background. Optimal is the largest pure-play SAP consulting firm in the US with a 15 year history of serving clients with their SAP implementations around the world.   Headquartered in Dallas, TX Optimal has offices throughout the US, as well as in India, Canada, and Germany, with over 300 employees.

Over the years, like many of our peer mid-market companies, our business has evolved and grown rapidly. With that, our operations have increased in complexity and today we find ourselves in the very same situation that many of our new SAP clients find themselves in: internal operations based largely on manual processes, often fraught with redundancies, and lack of access to quality data for effective decision making.

Given our experience in deploying SAP to middle market companies, we have decided to now turn our energies on ourselves and show the world that we can eat our own cooking by deploying SAP internally to run our own operations. 

Many of our customers often ask what an SAP implementation is like. In order to help answer that question, we’ve decided to take a unique approach.  Through a series of daily blog entries and weekly videos, we hope to capture the essence of what goes on in an SAP implementation.  In this process, we will try to be as transparent as possible, outlining both the successes and challenges associated with this effort. 

Over the next few months, we hope you will join us along in this journey.  We hope you will find this blog to be an interesting look at what everyday activities make up an project of this nature.  We also appreciate your feedback as we continue along in the process.  

In this post we’ll do a quick summary of the project methodology we use to implement SAP. Optimal’s project methodology is the framework for our methodology and is based on SAP’s own ASAP methodology for implementing SAP.  The methodology is deliverables based and relies on series of project phases with gates at the conclusion of each to ensure quality and repeatability in our implementations. 

At the beginning of the project we being with the Project Preparation Phase in which we work to create the project charter in which we define and document the core structure of the project – everything from the defining the business objectives, infrastructure approach, and project scope – to the project team resources, schedule, and costs.    It’s really important to have all of these items documented and agreed upon at the onset of the project to guide the project.  A steering committee with executive involvement is crucial to provide that guidance.  For our implementation that steering committee will consist our CEO and President who will both provide the necessary guidance. As the project is financially driven, our CFO will act as the project sponsor and primary champion for the effort.

At the conclusion of the Project Prep Phase, we have a checklist of deliverables that will be required to submit for approval and sign-off to the steering committee and project sponsor. 

But for now, it’s on to setting up the infrastructure necessary to support the project ..  Stay tuned for our next entry when we setup our project environment…

A key component of any successful SAP implementation is to have clear and active participation from the project's executive sponsor.  As part of that involvement, a group of select individuals -- i.e., the steering committee -- is appointed to guide the implementation and to manage and resolve important issues that inevitably arise. The steering committee serves as the tiebreaker when issues can’t be resolved at lower levels and provides feedback, resources, and direction during the entire implementation process.

The focus of our first steering committee meeting is to provide an update on progress made during the first few weeks of the project. Overall, our progress has been good, but we've run into a resource glitch with the finance team assigned to the project. Resource issues are common to all extensive SAP implementation projects. After all, business doesn't (cannot) stop because of an SAP implementation, and it is unrealistic to assume that no resource-based issues will crop up during the entire span of the project..

In our case, the person assigned to lead our finance team is being tugged at internally to work on several important, time-sensitive, client-facing issues. With that, his involvement in the project falls short of what is needed and for that matter, what had been clearly mapped out during our planning phase.  

As a result, we’re running a bit behind schedule – about a week. In the meeting we discussed several options to resolve this issue such as bringing on another resource from another office, hiring an additional resource, etc. By the end of the meeting, our resourcing strategy was decided – hire another resource to compensate for the shortfall in that particular area of the project. Our resolution strategy also included a plan that would help us catch up to our initial established schedule.  

This post will discuss the process of setting up the project environment.  This consists of several items including:

·          Setup up the SAP development and QA environments

·          ServicesOne All-in-One Installation

·          Set up the project repository

·          Establishment of the team structure and project governance structure

Setting up the SAP environments is a step that consists of several steps.  First we have to select the hardware that we’ll deploy the system to.  There are few options to select from here, whether we want to house the hardware environment ourselves or outsource to a hosting provider in which the application environment is hosted and managed for us.  Our preferred hosting provider is AT&T who is one of the largest hosting providers in the world.  For our deployment we have chosen to host the environment ourselves. 

For an SAP deployment project we’ll utilize three separate environments, Development, QA, and Production.  For our development environment we’re using a virtual machine on a server that already houses other SAP systems.   For our eventual production environment we will deploy a separate and dedicated server.  At this point in the project we’ll start the process to confirm the appropriate hardware and begin the procurement cycle as soon as that information is confirmed.  SAP BASIS resources (technical infrastructure specialists)  then perform the necessary installation to setup our environment.

The next step is to install our preconfigured ServicesOne product which will install the preconfigured business scenarios we’ve selected in our high level scope.  Through a series of automated scripts and data loads, in less than a day we’ll have over 40 preconfigured best practices for the Services Industry available to us to walk our users through blueprinting activities. 

Setting up the project repository is a critical step in ensuring we document our activities.  For that we’ll use SAP’s Solution Manager Tool which allows us to assign project documents to the applicable business scenarios we are implementing.  Our methodology provides the guidelines and template documents that assist us to rapidly complete and communicate our project requirements, specifications, and status.

Also critical to the project’s successful execution is the establishment of the appropriate methods for managing the project, including over team roles and responsibilities and project governance.  This includes the establishment of a project steering committee, issue tracking and resolution process, escalation process, change control process, scope management process, and project status reporting.  As you can see, these are all very important processes, but with the help of the methodology as our cookbook, we have a jumpstart on putting all these things in place.

The blueprint process begins with interviews of our key stakeholders. For the scope of our project this will include the key sales managers of our practices areas, Finance, and Human Resources.  For many of our key stakeholders, this will be a sort of role reversal, since many of them have been on the other side of these meetings as consultants in the past.  

These interviews key in on what high level requirements exist to drive the initial setup of the corporate structure in SAP as well as what key business processes and scenarios will be utilized in the implementation    Key decisions from our first meetings included how to setup the overall company structure, finance structure, including profit/cost center relationships, sales structure, which drives sales processing and reporting, and the logistics structures, which drives purchasing. These meetings also feature demonstrations of our preconfigured business processes from our ServicesOne All-in-One a key accelerator in our implementation.  These end to end business scenario demonstrations based on SAP Best Practices allow our users to see the SAP system in action and envision how their new world will look.  

Review sessions are a key part of blueprint validation, and today we held a review with key stakeholders and the entire project team. The review was held over two days and broken into in topic-specific, focused sessions.  

Once the Blueprint Phase is complete, the team transitions from the conceptual world into a series of build activities. Here requirement documents are turned into configuration and development activities in SAP.

Functional analysts configure the system by manipulating the various settings within SAP’s configuration tables to influence everything from how a specific sales order type works, to when and where invoice forms print.

Developers skilled in ABAP (SAP ‘s programming language) code what are known as RICEFW (Reports, Interfaces, Conversions, Enhancements, Forms, and Workflow) objects to conform to the requirements defined by the business. In most cases, they are able to leverage pre-existing objects and simply tailor them to suit the requirements. For example, many forms exist already in SAP and simply need to have company logos added and the look and feel (fonts, etc.) changed to suit that company’s specific form requirements.     
 
For our implementation, we’ve identified a total of 22 RICEFW items – about 1/3 of which are related to printed forms. We also have identified a few reporting changes to SAP delivered reports as well as our most complex requirement – workflow to support the approval process around time and expenses. Since we support our own projects as well as those of our consulting partners, the requirements around approval of time and expenses will be tricky. We plan to invest more resource time in this area.

We started the process of evaluating our RICEFW objects today in detail – starting with reporting requirements. ServicesOne, Optimal’s preconfigured All-in-One solution, contains over 125 reports for the Professional Services Industry. Therefore, this is a natural place to start. For the specific end-to-end scenarios we are using, nearly 50 of those 125 reports apply, so our process will be to review those reports with the business users to determine a level of fit.

From our initial walkthrough, it’s clear that there will be a few reports that will be the workhorse reports as well as the need to develop a few reports for a few of Optimal’s unique processes.

In the mind of the implementation purist, our project will not really have any true interfaces – since our processes today are completely manual. However we will be developing a series of data loads due to the unique requirements of our consulting partners. Optimal provides consulting resources to our partners for their SAP projects. In these cases, our partners require our consultant’s to report time to them directly for purposes of client billing. Optimal requires the same time reporting for invoicing our partners and paying the consultant.

In most cases, our consulting partners require our consultants to submit time and expenses to their proprietary systems. Since in these cases we cannot simply send a copy of our consultant’s time report, we have worked with those partners to be able to extract the data our consultants submit to their systems so we can load the same data electronically in our SAP system. In this manner we can eliminate the need for our consultants to duplicate their time reporting to Optimal for consultant payroll purposes. 

The single most important ingredient to the success of any enterprise system implementation is the data that will drive the new system. Therefore, the effective conversion of existing data is paramount in any SAP implementation. This is the case with Optimal as well.

As a business completely runs on spreadsheets, this exercise presents several challenges, especially in the areas of data cleanup, organization, and conversion into a common format.

Let’s consider data cleanup first. In this activity, we look at the sources of the data. In some cases there are multiple and sometimes redundant sources of the data. This must be reconciled in the “to-be” process. Then inconsistencies must be rooted out and corrected. This can include record count inconsistencies, spelling, level of detail, etc. To resolve this requires the intervention of those most familiar with the data – end users. Participation in this activity by those users is critical.

For the actual conversion of data into the new system our project team used tools such as WinShuttle and SAP’s LSMW which are data conversion tools that help make the task of data conversion faster and simpler for the team. 

Enhancements can often have a negative connotation in any SAP implementation. Generally speaking they are usually to be avoided since the term enhancement, in the context of an SAP implementation, refers to the development of a custom object that can’t be achieved via standard configuration, but yet does not modify an SAP core code.

Example of these types of enhancements might be – in modifying existing reports to include additional data or through utilizing user-exits in the SAP code to add additional logic. These “trap doors”,  known as user-exits, are pre-defined areas in the SAP code where you can add logic, validations, calculations, etc. to support your unique business requirements.

Forms refer to electronic and paper based documents within SAP to communicate or collect data. Several pre-defined forms come with SAP to support your business processes. These include things such as:  order acknowledgements, order confirmations, picking lists, packing lists, invoices, credit memos, debit memos, etc. By taking advantage of these pre-bundled forms, as well as the configuration needed to generate these forms, our technical team spent far less time on forms development than usual, since essentially all that needed to be done was to change the look and feel of the forms.

Our team also utilized an additional technology based on a joint effort between SAP and Adobe. In addition to the pre-defined forms mentioned above, ServicesOne also utilizes Adobe Interactive Forms to handle time and expense processing. Adobe Interactive Forms utilizes Adobe and SAP technology to deliver pre-defined forms to your users’ desktop through email (MS Outlook in our case). From there, the end user can easily populate their time and expense data and submit back to SAP without ever logging into to the SAP system.   The benefit to our organization of this alone was tremendous.

For one, the use of electronically validated charge codes for both internal and client activities cut down reconciliation activities associated with validating spreadsheet based time reports by a significant margin. Additionally, by taking this approach we were able to bypass having end users login to the SAP system – which made the transition to the new environment more seamless. Finally, we were also able to set up automated approvals for each activity time was charged against, thus adding additional control to our timekeeping.

In the last blog we mentioned workflow.  Workflow enables the SAP system to automatically route tasks in the system to specific individuals or roles in the system. In our case we chose to enable workflow to route our time and expense reports to the appropriate manager. Let’s take a look at how this works for us.

After an employee submits a time and expense report, the system looks at that report and the charge codes assigned to each task or expense. Based on either the approver for the project or internal activity the person reports their time to, the system routes their time/expenses appropriately to that individual via email. The approver then opens the email, clicks on a link which logs them into the approval transaction in SAP and they can then approve or reject the items. Once approved the items are then available for accounting to process them.

This is just an example of how workflow can work within the organization. Additional areas of applicability, also include purchasing, inventory movements, and new employee setup in the Human Resources module, to name a few. The benefit to us now, is the increased visibility this will provide to where time and expenses are allocated.

Training is a vital component to any new system’s ultimate success.  We tailor our training approach to each customer individually. Typically our strategy employs a Train the Trainer (TTT) approach whereby client business expert resources conduct the End User training classes. This approach reinforces knowledge transfer, lends credible introduction of new systems to users, and leads to organizational self-sufficiency.  Skilled, credible, and committed “Super Users” are recruited as trainers in this approach.

In order to accelerate learning, trainees (end users and project team) attend courses based on the roles assigned to their position. Roles are a composite of business functions and SAP transactions. Courses are then assigned to groups of Trainees who are assigned similar roles. Therefore, employees receive training on the new business process and how to facilitate the transactions for those business processes within SAP.

Training is then delivered at the appropriate time for the organization to make each user productive from the moment of go live. Timely training, which may begin several weeks before go live, assists employees in retaining knowledge between the training experience and practical application. The most complex and critical processes are prioritized for this training.

Some training classes may be scheduled after go-live for processes that will not be immediately performed upon go-live (e.g. financial year-end close). Achieving an established on-going training process to deliver continuous improvement is as critical as the success of the initial go live dates. To ensure continuous improvement, feedback is solicited from the Trainees and incorporated into future training efforts.

In our case, we had both internal and external users of the system, our internal employees and external field consultants, which increased the scope of training delivery from the perspective of having to deliver training in multiple formats (online, email, in person) as well as tailoring the training to several audiences (internal, field, 3rd party).  

Go-live execution actually begins well before the actual cutover event. During this phase of activities, the Project Management team works with the business to execute pre-defined shut down plans for critical activities affected by the decommissioning of legacy systems and subsequent cutover to the newly replaced systems.

A series of Go/No-Go decision points (with associated contingency plans) is inserted into the cutover plan to ensure that a successful cutover can be executed with minimal interruption to normal business operations. A contingency plan should also be in place to mitigate any unforeseen issues.

Finally, ramp-up activities are included in the cutover plan to bring all affected systems up in a controlled and orderly fashion with communication throughout the process, ensuring business users are kept informed as operations return to normal.

Testing is another key measure of the success of the project. During Realization, the majority of testing efforts is around integration and performance testing.

The purpose of Integration Testing is to perform end to end testing of all business processes implemented for this project, including regression testing on any business processes that may have been affected by this project. For example, if a development object or configuration was changed for this project, business processes that relied on that development object or configuration should be regression tested to ensure they are still working as they currently do.

All business scenarios and associated business scripts are tested in this portion of the project. This should include all development objects. A mock/trial cut-over may need to be included as part of the integration test. This mock cutover tests the cutover processes, procedures, and sequence of activities to be performed to shut down current systems and processes, build and migrate data to the new system, and “turn-on” the new system.

A batch schedule should also be set-up to run batch jobs that will be run in production. Data used in the testing should be a mixture of new data and current or converted data (if a mock cut-over is performed).  Any business processes that may have been affected by the project should also be regression tested.

We executed 3 cycles of integration testing, which is typical for an implementation of this type.   In the final cycle of integration test a User Acceptance Test (UAT) was performed. The purpose of the UAT is to obtain sign-off by the business, confirming that all deliverables are complete and accurate. In this test, end users from the business are engaged to perform comprehensive tests to simulate their new responsibilities with the new system including testing the security roles to which they have been assigned. Any defects that are found are logged, prioritized, resolved and retested accordingly.  Once sign-off has occurred from the end users, the project moves into the final stages of preparation for go-live.  

As mentioned before, cutover does not begin on the weekend we go-live, rather it’s a process of shutting down and closing out processes based upon a pre-defined schedule.  For example, before we can go-live with a specific month’s opening balances, we need to close out the previous month and hold all new transactions for the new month until we are live on the new system. Given our long financial closing time (1 month or longer) we had to accelerate the close of the previous month by putting in some long nights.

Once that’s completed, along with the other tasks on our task list, it’s time to begin. In preparing for our go-live we executed a mock cutover test, to test our cutover procedures, programs, data conversion, and timings. This assisted us in understanding how long it would take to perform the actual cutover from the point where all systems are taken down (in our case none since we were reliant exclusively on spreadsheets) to when all data is in the new system and we declare it “live”. In our case the planned elapsed time was about 40 hours.

The cutover weekend is a stressful time for any project team.  It requires strict adherence to the build schedule (a sequenced series of tasks) that are run on a 24 hour schedule. And generally something will go wrong at some point – so the team must stay focused and execute relentlessly.

The Super users are involved in the process as well.  After conversion of data from their old spreadsheets and databases, (customer, vendors, employees, orders, etc.)  they are called in to verify the data is correct in the new system.  At predefined checkpoint times, the project team and stakeholders are informed of the progress with the build and how far ahead or behind schedule the team is at that point in time. The final checkpoint is known as a Go/No-Go meeting in which the determination is made to go-live or continue with activities until specific criteria are met. Per our plan we were given the ok to Go-Live!

After the new systems is brought live, we decided to do a controlled ramp-up, or sequenced release of the system to key users prior to releasing the system to the rest of the user population. What this allowed us to do was to test key components of the transactional system in a controlled fashion to ensure key functions work as expected.  This prevents a flood of calls from coming in if a particular function is not working as expected.

In the weeks immediately following go-live, our team is focused on supporting the user population as they adjust to life with the new system.  As with any new product, there is an adjustment period, some issues are found, and inevitably there are some minor changes that are requested as people become more familiar with the new system. During this period of stabilization, a handoff of responsibility begins to take place from the project team to the business champions, who are now in charge of their respective processes in the new system.

Our system will ultimately also be supported by our Application Management Support (AMS) group, a service that we also offer to our customers to help manage the day to day support of SAP systems.

Finally, as a part of the closure of the project, we will conduct a post-project review to communicate lessons learned as well as understand what our envisioned upcoming needs are. As both SAP consultants and now a customer, we realize that SAP is not a destination, it’s a journey, and one that we are excited to continue.