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.