Lessons learned on SAP S/4 HANA implementation

I have just wrapped up managing the SAP S/4 HANA greenfield ERP implementation at Mizuho OSI.  I believe this was my 16th SAP implementation and it has been been a great experience.  We actually went live a day early and completed the project within budget.  I would like to thank Lindsay Neill, Director of IT Applications at Mizuho OSI, for giving me this opportunity.  I would also like to acknowledge the excellent job that KPIT did on this project as the implementation partner led by Bimal Brahmbhatt.

No matter how many times I implement SAP, I always come out of it with some lessons learned.  This being my first SAP S/4 HANA greenfield implementation, was no exception.

Below are a few of these lessons learned.

1)  I have heard that it would be difficult dealing with SAP HEC (HANA Enterprise Cloud) hosting service.  Thankfully this was not the case.  As with most hosting partners as long as you submit tickets, the work gets done quickly.  HEC also dedicated a representative to help guide us through the proper ticket coding.

2)  The BP (Business Partner) transaction is a one-stop-shop for maintaining all business partners (customers, vendors, etc,).  At first I thought this was great, because it shows that the module silos at SAP actually got together an agreed on something.  But, we soon found that does not have sufficient authorization objects to properly segregate the maintenance of customer, vendors, contacts, and employees (as vendors for paying expenses).  SAP recommends having centralized master data maintenance model rather than a distributed model.  This may work for some companies, but many companies will have to either change their model or live with a monitoring / detective control rather than a preventative control.

3) I always recommend starting data migration efforts early in the project.  In this project, there was a lot of data transformation even though the company was migrating from ECC to S/4 HANA.  I hate to admit that we were caught off guard on this project partly due to the data structure changes and partly due to the data cleansing effort.  We were able to go-live on time, but there was added effort and stress that could have been avoided if we had dedicated resources to data migration activities.

4) The security roles had to be re-developed mostly because the company wanted to tighter security than they had in ECC.  We should have started on the effort sooner and had the users test it more thoroughly during UAT.  Most of the post go-live issues were access issues, but they were resolved quickly during hyper care.

We managed this project using an agile-like project management methodology.  It was similar to SAP Activate, but I added some things I picked up working on Salesforce ERP implementations and luckily KPIT also wanted to use an Agile-like approach.  We completed the project in 6 sprints followed by 2 mock cut-overs which each led into UAT (user acceptance testing) sessions.

Over all, I am very happy with this successful SAP S/4 HANA implementation and I am proud to have been a part of this project.

Dan Raven
Raven Business Practice, LLC.
dan.raven@ravenbp.com
http://www.ravenbp.com

SAP S/4 HANA Implementation

I have been working as a project manager on a greenfield SAP S/4 HANA implementation.  It has been an exciting experience and very educational.  Dealing with SAP HEC is different than working with other SAP hosting partners.  Learning the differences between ECC and S/4 HANA has also been interesting.  I appreciate the opportunity that Mizuho OSI has entrusted me with.

SAP HEC (HANA Enterprise Cloud) is easy to work with once you understand their ticketing process.  I have not been able get on a conference call with all parties involved in a change.  The Basis team, network team, server team, etc. are different groups often from different entities.  All changes require creating tickets which is normal when working with hosting partners.  However, because there are multiple parties involved, you need to create a ticket for each group.  Luckily we were assigned and account manager that guided us through all of the tickets that need to be created for a change.

Most people know about the Business Partner functionality in SAP S/4 HANA and that it replaces the Customer Master account groups and Vendor Master records.  It includes pretty much all types of accounts.  If you pay expenses to employees, then you will need to create employees as BPs as well.  I like the concept that pretty much every entity that your business deals with is created as a BP in S/4 HANA.  However, this has resulted in a fairly complex object with many Business Partner roles.  Hopefully SAP will find a way to simplify this BP beast.

I really like the consolidation of tables in SAP S/4 HANA, but it has created challenges in data migration, even from a legacy SAP ECC environment.  I always recommend starting early with Data Migration activities in ERP implementations and this is no exception.

The success of any ERP implementation depends on the experience of the team.  The consultants' functional and technical experience as well as the business team's business process experience.  These are key to a successful implementation.  Managing change is critical.  Business Process flexibility is critical.  It always comes down to people, process, and technology.

Dan Raven
Raven Business Practice, LLC.
www.ravenbusinesspractice.com

ERP on the Salesforce1 Platform?

Everyone is talking about moving to the Cloud.  ERP companies such as SAP and Oracle have been on the path to the cloud for some time and hundreds of companies are running their ERP in a private cloud.  But running your ERP on a public cloud such as the Salesforce1 platform has been a concern especially for large companies.  For small to mid-sized companies that have not yet made an investment in ERP, a cloud-based ERP solution could be ideal.  But is the public cloud ready for ERP?

I have now seen first hand, how an ERP can work effectively on a public cloud.  I was the project manager on the Kenandy ERP implementation and Salesforce platform migration for which Dave McLain won a 2015 Consumer Goods Technology Industry Visionary award. (see the article).  Congratulations to Dave!  I think this was a well-deserved award.

Kenandy is one of a very few companies that has developed an ERP on the Salesforce platform.  As an independent consultant, I have now worked on 2 Kenandy implementations and I have learned quite a lot.

Prior to going into consulting I was an IT executive who was very successful rolling out SAP.  I developed a fast implementation approach using an agile project style to roll out SAP to new acquisitions for a large high tech manufacturer.  During my tenure, I migrated nearly every application the company used to the SAP NetWeaver platform.  My strategy was based on my belief that applications built on a single platform can be easily integrated with one another and require less maintenance to keep them working.  They also do not require a wide variety of skill sets to develop and maintain.  My IT Strategy was sound and it drove a very low TCO.  

At the time, the thought of paying a subscription for every user license really hit a nerve.  I could not imagine paying a never-ending fee for ERP software.  Until one day I realized that I had been doing so for years.  The annual maintenance fee on a large ERP package was such that I was basically re-buying the software every 4 to 5 years.  And this annual maintenance fee was never-ending.  I may as well have been paying an annual subscription fee for a cloud solution.  In fact, my ERP was already hosted on a private cloud which also came with a never-ending cost.  I had incorrectly compared it to buying or renting a home.  I thought you should always try to buy a home rather than throwing away money on rent.  But my analogy was not right.  When you buy a home you don't have to pay 20% annual maintenance on it.  You don't effective buy it over again every 5 years.

"It is always good to learn from your mistakes, but it is far better to learn from other people's mistakes." - Dan Raven       You can quote me on that, but unfortunately this was an occasion where I learned from my own mistakes, and perhaps you in turn, can learn from mine.

Now that you know a little about my background, you can better understand my thoughts on the public cloud's readiness for ERP.

My first Kenandy implementation for was a small company.  It was a company recently acquired by Del Monte and we decided to use it as a bit of a guinea pig.  That implementation was extremely fast.  In fact, we went live 90 minutes after the funds transfer for the acquisition.  The entire project only took about 3 months.  There were a few bumps in the road much like any ERP implementation, but kinks were worked out very quickly which is one benefit from being on the Saleforce platform.  Development on this platform is very fast.  The users of this small company really liked their new ERP.  It was far superior to their legacy applications.

This implementation gave us some experience and we found some functionality that would need to be added before rolling it out to a large company.  I won't bore you with the details of the large company implementation, but I will say that go-live went smoothly and the large company is now operating on the Kenandy ERP in the Force.com cloud.  In fact, I was very pleasantly surprised with the smooth cut-over which I attribute to an outstanding team that had a good plan and was well prepared.

The question remained, "How well would it work for a large company with many application interfaces and large volumes of data?".  The Salesforce1 platform is already an enterprise platform.  It was built to handle volumes of sales lead and opportunity data.  It was build to enable the development of many more applications that just CRM.  It was built to handle masses of users across many companies.  So in theory, we thought, it should be able to handle the data volume and complexity of an ERP for a large company.   

There are challenges for a large company running their ERP on the Salesforce1 platform.  Because this platform is a multi-tenant platform, there are governor limits that need to be complied with which presents some difficulties with batch job management and APIs used for interfaces.  We have worked through many of these issues and the company is operating within the governor limits.  We have now been live for over 4 months and through a fiscal year end. There is still some optimization that is underway, but this experience as proved to me that it can be done.

Witnessing this has made me very excited about the opportunities it brings to the SMB space.  If the Kenandy ERP can be run on a the Salesforce1 platform for a large company, I have no doubt that small and mid-sized businesses can benefit greatly from this as well.

Please note the disclaimer on this blog.  I would like to reiterate that this is a personal blog and the opinions in this blog are not meant to represent any company or brand that is mentioned in this blog.  I am only writing about my personal experience and my personal opinions.     
  

It's a Platform Play (Part II)

I have had the privilege of working with ERPs on a couple of different platforms.  The first ERP platform I worked with was SAP's NetWeaver platform.  As we implemented a series of SAP products on the NetWeaver platform we had tremendous success.  The applications built on this platform were built to work together.  We were able to simplify the IT architecture and lower the TCO (Total Cost of Ownership).  We ended up with a very lean IT applications team because the skill set required to maintain all of the applications concentrated on a single platform.  I took a few years, but by the time we were done, all of the applications except the shop floor control system (MES - Manufacturing Execution System) were on the NetWeaver platform.  Everything was humming alone rather smoothly.

The road to get there was a challenge.  As an IT executive, my job was to convince the business to go along with my IT strategy.  I was able to do so by partnering with the CEO and the CFO.  Showing the benefits of a unified platform and proving the savings, helped me to gain the support for my platform strategy.

At the time, I was blamed for drinking the "SAP Kool-Aid".  But I was able to prove that the SAP Kool-Aid was actually good for you.  I was also labeled as an "SAP Only" guy.  That was not completely true.  I was actually and "SAP First" guy.  Once I had the support of the executive team, business folks who brought solutions to IT had to have a very good reason for deviating from the platform.  It was a challenge to say the least, but when business team members brought solutions to IT, we would explore the business need and look to see if there was an SAP solution for that need first.  Sometimes that meant enlisting our ABAP developers to build a solution on the NetWeaver platform.  As a result of enforcing this IT Strategy, our company had one of the best and leanest IT footprints in the world.  We were a billion dollar global high-tech manufacturing and distribution business on a single globlal instance of each enterprise application on a single global private cloud platform.  Life was good.

But that was 10 years ago.

Now companies are taking a serious look at the public cloud offerings.  The public cloud offers the low cost of a multi-tenant environment.  On a private cloud, companies' enterprise applications are hosted on a dedicated set of hardware and therefore the company bears the cost of all of the hardware and support.  In a public cloud, companies share the cost of the multi-tenant environment, therefore the costs are lower.  Public cloud companies such as Amazon, Google, and Salesforce are leading the way.  Amazon and Google started with the public in mind and offered their solutions to individuals first.  Salesforce started with enterprise applications (such as CRM) in mind.  Now companies such as Kenandy, FinancialForce, and Root Stock are offering ERP solutions on the Salesforce platform.

The public cloud offering has its share of limitations for enterprise applications, but companies are already reaping the benefits.  Originally the public cloud offerings targeted the SMB (Small and Medium sized Businesses), but now the first large company has successfully implemented the Kenandy ERP on the Force.com platform.  (See Dave McLain on the Consumer Goods Technology link. http://consumergoods.edgl.com/news/2015-Visionaries100268)

With the Force.com platform, applications built on the platform are built to work together and are perhaps even more tightly integrated than my experience with the NetWeaver platform.

The moral of the story is regardless of the platform you move to, the platform itself must be a driving force within your IT Strategy.  Enforcing the "Platform Application First" stance politically difficult, but it must become a way of life within your organization.  You must be able to prove that the functionality cannot be achieved on your platform before you allow an application deviation.  Without an enforceable platform strategy, your company will end up with a messy, complicated and expensive architecture that may eventually become unmanageable.  Unfortunately I have seen this in many organizations.

If your company needs help to develop and enforce a platform strategy, please reach out to me.  I now have experience in both private and public cloud platform strategies.

It's a Platform Play

When companies are evaluating ERPs (Enterprise Resource Planning Systems), what should they be looking for?

During these evaluations, many companies overlook what I consider one of the most important aspects of an ERP - The Platform.

Why is the platform so important?
When implementing an ERP, companies almost always find that which ever ERP they chose, it does not have everything they wanted out of the box.  ERPs need to be customized to fit each company and even after customization, there still may be more functionality needed to satisfy the entire set of business process flows.  Companies generally do this by either adding custom code, custom applications, or interfacing with other applications to satisfy the gaps.

This is where the platform decision is critical.  The platform the ERP is on has to be one that is flexible and easy to develop on.  Companies should fill their process gaps with functionality that is developed on the same platform that the ERP was developed on.  This will ensure that the applications will work well with the ERP.

In my experience, I have found that interfaces between applications that reside on the same platform are easy to develop and maintain.  There is much less baby-sitting required.  The "baby-sitting" I refer to is what is required when interfaces break down and need to be periodically kick-started again.  That means that an expensive IT resource has to spend some time on it on a regular basis.  This can quickly become costly let alone frustrating to the business.

Each interface has a cost to build and a cost to maintain.  In order to keep the Total Cost of Ownership (TCO) down, interfaces should be fast and easy to build and maintain.  If they are built on the same platform as the ERP, the technical resource you have for your ERP system can likely be re-utilized for these interfaces.  The resources you have already invested in can build and maintain the interfaces and applications which have been built on the same platform.   Also, from my experience, I have found that applications that have been built on the same platform are generally built to work together and therefore require much less (if any) baby-sitting.

When considering ERPs, you should consider the ERP platform and consider the other applications that have been built on that platform.  If you need to grow your team or lean on consulting, consider the talent pool available for the platform development and maintenance.  Consider how that fits with your existing team and determine which team members will need to be trained on that platform.

Consider that fact that some ERP companies have built platforms for their ERP applications.  These are proprietary platforms and require expensive developers who know the platform.  Consider the fact that some ERP applications have been built on Platforms that already exist.  There are generally a lot more applications that have already been built on this platform and there are generally developers that are more readily available these more public platforms.

Finally, (but it should not be the last consideration), consider if the platform is a cloud platform.  If it is a cloud platform, is it on a public cloud or a private cloud and which one is right for your company and the direction you need to move to provide the best experience for your customers.   

Kenandy ERP on the Salesforce.com Platform

I have been working on a very exciting ERP project.  I managed the first implementation of the Kenandy ERP for a large company.  Big Heart Pet Brands, the company that makes brands such as Milk Bone, Kibbles 'n Bits, Gravy Train, 9Lives, Meow Mix, Nature's Recipe, Natural Balance, and many more, is the first large company to go-live on Kenandy's cloud-based ERP solution.

Please note the disclaimer on this blog.  I would like to reiterate that this is a personal blog and the opinions in this blog are not meant to represent any company or brand that is mentioned in this blog.  I am only writing about my personal experience and my personal opinions.

Kenandy is an ERP that is built on the Force.com platform.  (www.kenandy.com)  It is one of only a few ERP solutions built on the Salesforce platform and I am very impressed with with this PaaS (Platform as a Service).

As many people already know, data created in a Force.com application can be "made available" to other applications in the same Org (company environment).  For example, if you create a customer record in the SF CRM application, that record can be utilized by a say a credit management application that a company may download from the Saleforce App Exchange.

Now think of this from an ERP perspective.  Master Data Management has long been a major thorn in the side of many companies that utilize different applications for different functions within their organization.  Traditionally, you would create the master data record in one system and copy it to other applications that need the same information.  This was originally done manually and later automatically via programs.  The manual effort was always error prone and the automatic solutions still require the data to be located in multiple databases where keeping them in sync has been challenging.

Salesforce has resolved this by allowing the record to be created once and be "utilized" by other applications on the same platform.  With Kenandy's ERP application on the Force.com platform, companies can create records in CRM and utilize them in the ERP sales order and billing processes.  The records are not copied from one application to another, they are simply made available to other applications on the platform.

They have gone even further than master data.  Any record can be shared, including transaction records.  Companies can utilize sales history data from the ERP in a Trade Promotions Management application as long as they are both on the Force.com platform.  This is amazingly powerful.  The efficiency gains of this architecture is incredible.

In my past, while working for companies on SAP, my main goal was to migrate as many applications as possible onto the NetWeaver platform.  It is always less expensive and more efficient to maintain applications that are built on the same platform.  Now as a consultant, striving to gain a lower TCO, and ultra high efficiency for my clients, I am still convinced (now more than ever) that it is a platform play.  The best way to gain efficiency, increase business velocity, and reduce TCO (Total Cost of Ownership) is to migrate or build applications on a single platform.

Now, with Kenandy ERP experience on the Salesforce platform, I am in awe of the possibilities.  The data sharing / utilization for enterprise applications, in my opinion, is one of the best features of the Force.com platform.  

On Your Mark, Get Set, Go-Live! - Now available on Amazon.com

Hello Everyone,

You can now find my book on Amazon.com; "On Your Mark, Get Set, Go-Live!"  - The SMART Approach to implementing SAP.

 http://www.amazon.com/Your-Mark-Get-Set-Go-Live/dp/1477493247

I am very excited to now have this book available for people interested in rolling out ERP applications such as SAP in the most efficient way.  In this book I have shared many examples of project documents that can be used as templates to speed up your implementations.  Currently it is available in paperback.  I plan to have it available in the Kindle format soon.

I hope you enjoy the book and I am happy answer any questions that you post as comments on this blog. I look forward to hearing from you.



Enjoy.

Rapid SAP Implementations (part 4)

The High Level Project Plan

When I talk about my experience rolling out SAP following a 2 month project plan, many people simply refuse to believe it. But the fact is, I have implemented SAP at 15 manufacturing sites around the world and 10 out of 15 were done following this 2 month cookie cutter approach.

Throughout this blog series, I have included several golden nuggets of information, but in this post, we just may hit the mother load. Here I will share an outline of the high level project plan. I am working on a book, On Your Mark, Get Set, Go Live, where I will share the detailed project plan, so to get the real meat, you will have to wait for the book to come out.

Outline of the High Level Project Plan:

Week 1
Review the AS-IS processes of the new company plant and share the TO-BE processes with the Key users. Determine if there are any significant differences. Working through the differences is easier than you might think if you approach them correctly.

Week 2 & 3
Configuration and Unit Testing. During this time, the new company plant is configured in SAP and simple unit tests performed by the SAP team confirms that the new configuration is working properly in the development system.

Week 4
Master Data Load. In week 4, we begin to test the data loads in the development system. Master data includes information such as material masters (part numbers), customer masters, and vendor masters.

Week 5
Milestone - Transport to QA. In the beginning of week 5, the configuration is moved to the Quality System. Week 5 also marks the beginning of Integration testing in the QA system, and Business Process Procedures are updated in preparation for training the rest of the plant.

Week 6 & 7
Integration testing is wrapped up by the end of week 6 and user training is performed in weeks 6 & 7. At the end of week 6, marks another milestone - transport to the production system. This has to be done in preparation for loading data into the production system. During week 7, the master data is loaded into the production system. At the end of week 7, the final open data is extracted from the legacy system. Open data includes the load of information such as G/L balances, sales orders, and purchase orders.

Week 8
Open Data Load. This is it. During week 8 we load the open data and validate the data is correct in the production system. Once the validation is complete, the site is live on SAP and can commence business transactions.


Obviously this outline is at a very high level and there is a lot of detail that is not included in this here. If you have any questions, please feel free to post them and I will be happy to respond.

Rapid SAP Implementations (part 2)

How to Prepare a New Site for a Rapid SAP Implementation

The first step is to prepare a package to send to the managers of the new site. This package should contain a document describing the implementation approach. The approach document should contain tips on how the site can help get a jump start on some of the project activities. For example, one activity they can get started on is mapping their Chart of Accounts to the Corporate Chart of Accounts.

In addition to the approach document, the package should include samples of documents that will be used during the project. Below is a list of documents that I usually include in the preparation package.

• System Integration Questionnaire
• Currency Questionnaire
• Corporate Chart of Accounts
• Data Migration Templates
• Sample Contact List
• Sample User Authorization Template
• Sample Project Plan
• Sample Issues Log
• Sample Cut-over Plan
• Sample Post Go-Live Issues Log
• Sample Integration Test Scenarios
• Sample Integration Test Schedule

The project preparation package is important because it gives the new management team a flavor for what lies ahead. It also makes them part of the project early on in the process. They are given jump start action items which makes them feel as part of the team.

It is very important to make people part of the project. Bringing them in early gives them the opportunity to contribute to the success of the project. If you don't include them early, they will be resistant throughout the project and make an already challenging job even more difficult. Everyone knows that you need to get business buy-in on IT projects and this is just one of the ways of doing that.

Rapid SAP Implementations (part 1)

I am starting a new series on rapid SAP implementations. Over the years I have developed an approach to rolling out SAP in only 2 months. Most of you will not believe me until you read further, but I have implemented SAP 15 times and 10 out of the 15 implementations I completed following a 2 month project plan.

What's the catch? You have to start with a system or plant or company site / facility of record. What I mean is you start with a baseline configuration that is running all of your business processes effectively in at one facility. Then you must take a cookie-cutter approach to rolling in out to all other facilities in your organization.

Many people will say that this approach will not work in their company because each of the sites are too different from each other. I say prove it to me. I have heard many skeptics who say things like, “It may work for a small company, but not for one as large as ours”; or “This kind of implementation can only work if all of the stars are aligned which is not the case in real business.” The fact is that I have used this method in more than 10 successful SAP implementations with companies of various sizes manufacturing various products and services with various customer bases. One of the most important ingredients is a positive attitude. I ask you to keep an open mind while consuming the contents of this blog series. I have proven the approach many times. I have proved that it is repeatable.

I am in the process of documenting exactly how perform a 2 month SAP implementation in a book. I plan to call the book, "On Your Mark, Get Set, Go-Live". But this blog series will give you a sneak peek into the contents of the book. The book will contain project plans, cut-over plans, issues logs, and many other helpful examples. But throughout this blog series, you will find tips and trick and the basics on how to do this at your company.

It is just as important to understand why you should implement SAP this way as it is to understand how to roll out SAP in only 2 months.

I will start with the "why" and detail the "how" throughout the series.

The "why" is not very difficult to understand. Although I was an SAP expert and I brag of my accomplished project management career, I come from a business background and the reasons why to implement SAP with this approach are purely business reasons.

World class companies try their best to run the same business processes at every site throughout their company. Companies that achieve this are not only world class, but best in class. Having the ability to run the same business processes throughout every company entity allows companies to share resources which in turn allows them to reduce their costs and run extremely efficiently. Companies that have done this gain tremendous synergies throughout their organizations. If they are a manufacturer, it allows them to easily move the manufacturing of a product line from one plant to another. It allows companies to share human resources. Employees can land on the ground at a different plant and immediately start working effectively. There is extremely little learning curve if they have already been doing the same job at a different plant.

In this approach, companies end up running a single instance of all of their enterprise applications which brings synergies in the form of shared master data. They can easily extend materials and BOMs in their system from one plant to another. They use the same data fields for the same purpose. They use the same codes for the same purpose. This creates synergies in reporting and analytics. All of the sites can use the same set of reports and better yet, they read the reports in the same way. It avoids confusion in terminology.

Using the same terminology in itself builds synergies. Many people speak the same industry language within an industry. Many companies use the same terminology within a company at a high level. But these language synergies are brought to the ultimate level when companies use a single instance of enterprise applications using the same fields in the same way. For example, if all sites are using stock locations that begin with an "8" for RMAs (Return Material Authorizations) and stock locations that begin with a "9" for finished goods inventory, employees from different manufacturing plants can speak of materials in location 86473 and 90876 and there is no explanation required. When employees throughout the entire organization worldwide, can have detailed conversations without have to explain the basics every time, the company benefits dramatically.

All of these synergies together save considerable time and money. Then on top of that, add the cost savings to the organization gained in the IT department. It simply takes fewer IT resources to manage a single instance of each enterprise application than to manage several instances or several applications. IT workers who are familiar with working on a single platform such as the SAP NetWeaver platform can easily learn more than one SAP module or component. Therefore IT resource can be cross trained which saves even more money. Add this to the cost savings of implementing SAP in only 2 months compared to 4, 6 or 8 month implementations and you can easily carve $500K off every site implementation. When I roll out SAP to a site using internal resources, I usually budget the project at about $50K - $75K per site. Essentially this is the travel budget.

It is easy to see why this approach should be followed from a business perspective. In the next several blog posts, I will begin to detail how you can make this approach work for you and your company.

Please feel free to post any questions you may have along the way and I will be happy to answer or discuss your concerns.

Dan

SAP Hosting Migration

Our SAP Hosting Migration from SAP Hosting in Germany to Secure-24 in Michigan was a success! The down-time was only 42 hours from start to finish. We handed the system over at 7PM Pacific on Friday and we were up and running in the new production environment at Secure-24 by Sunday at noon. That was 4 hours ahead of schedule!

After the Production migration was complete, we started working on the DEV & QA system migrations. The QA systems were copied from Production so that was relatively easy. The DEV systems were restored from USB drives as exported from our original DEV systems at SAP Hosting in Germany. The exception was our DEV Enterprise Portals and DEV BI instances. Those we wanted "configuration only" copies of our production environment.

The only problem that we experiences was with the creating of our DEV BI instance. The BCS configuration was not copied correctly. BCS stands for Business Consolidation System. It is the financial consolidation tool that sits on BI. SAP is now promoting Outlook Soft for this, but we are fairly happy with BCS.
We had to re-do the restore of our DEV BI environment.

Overall, I am very happy with Secure-24. They are priced competitively and have a professional staff that has proved to be very knowledgeable.

We gained a significant cost savings with this move. Some of that was do to utilization of Virtual Servers in the DEV & QA environments. I though our DEV & QA environments are a good place to test the different virtualization solutions for HP Unix and Windows platforms. We may consider virtualization on our production landscapes when our existing contract is up for renewal in a few years.

I would like to congratulate Secure-24 on a job well done. I would also like to thank SAP Hosting for all they had done for use over the last few years. SAP Hosting had the best service we have ever experience from a hosting partner. We will see how well Secure-24 compares. So far, so good.

SAP Hosting Migration

I was a very happy SAP Hosting customer until SAP decided to discontinue their hosting offering. We looked at many SAP Certified Hosting partners before deciding on Secure-24.

Now we are in the middle of the migration and so far I am a fairly happy customer. We have a complex SAP NetWeaver environment including ECC 6.0 in a clustered environment, BI 7.0, BCS, GTS, Solution Manager, and an Enterprise Portals Environment with security for external as well as internal exposure.

We are scheduled to complete the migration the weekend of November 8, 2008. I will keep you posted on how it goes.

This is the second SAP Hosting migration I have undertaken. The first was a migration from HP Hosting in Atlanta to SAP Hosting in Germany. Now we are moving our data from SAP Germany to Secure-24 in Michigan.

I really like the approach this time. SAP Hosting has backed up our environment to USB drives and sent the to Secure24. S24 will receive the drives today, extract / decompress the data and restore it to new servers. In the mean time, SAP is collecting log files and sending them over the WAN on an hourly basis. Once S24 has completed the restore from the drives, they will begin to decompress and restore the log files. This will allow us to complete the migration over a weekend resulting in downtime of only 1 weekend for our users! We will hand over the system on Friday evening and S24 will give it back to us by Saturday at noon. This will allow us to complete the Single Sign-On configuration, test printers, perform a financial validation and our golden transaction all before our facility in Asia comes on line Sunday afternoon (Asia's Monday morning).

If this is successful, it will the fastest migration (with the least amount of downtime) we have done.

I will let you know how it goes.

SAP Maintenance Increase

There is a lot of hype about the increase of SAP's annual maintenance from 17% to 22%. Although the increase is gradual it is a very hard pill to swallow. At 20% annual maintenance, companies are essentially buying the software again every 5 years. Many IT executives and other corporate executives are upset about the increase. This increase in IT costs hits at a time when companies are trying to reduce their costs to regain some margins that have eroded in their industries. To make it even more frustrating, SAP plans to stop enhancing R/3 and ECC in the next few years. So as the maintenance increase over the next 4 years, SAP will stop enhancing the product. Instead, they plan to spend that money to develop new products to sell to their customers and then collect additional maintenance on these new software products! If SAP is not going to spend the revenue collected from maintenance on R/3 and ECC on updates for those products, they why should customers pay for maintenance on them. Isn't that the whole idea of what maintenance fees are all about? Software maintenance fees are supposed to pay for updates and enhancements to the software you already purchased.

As an SAP customer, the maintenance increase not a pleasant thing to deal with, but if you step back and look at it from the outside, it makes perfect business sense for SAP to do this - especially because their competition is already charging 22%. I think SAP should have come in just under Oracle (at maybe 20% - 21%). This would give their customers the idea that they still want to remain competitive and customers would still have a price advantage from being an SAP customer vs. an Oracle customer. If SAP had done that, I think there would be a less backlash from their customer base.

One thing that I think SAP did well was setting expectations. I think, at least in the US, SAP has been conditioning their customers for this for quite some time. I remember my SAP Account Executive telling me this was coming back in 2004. Since then, each of my other three SAP Account Executives have echoed the same. I am told that SAP's Account Executives do not get paid on software maintenance, but they have dedicated a lot of time discussing this issue with their customers. Plus a Senior VP of SAP met with me and my CEO to let us know we would be getting official notification a few weeks ahead of time. I don't know any SAP customer in the US that did not know this was coming. In fact, I am surprised that I did not see much about this in ASUG forums ahead of time. Reading about the European SAP User Groups, it sounds like they were not given as much warning. Who knows?

Your comments on the subject are welcome.

In my next entry, I plan to write about SAP's attempt to explain the benefits of their new Enterprise Support.

SAP Implementation in only 2 months!

I am currently working on my 15th plant implementation of SAP. Needless to say, I have a lot of experience implementing SAP. I have developed a cookie-cutter approach to implementing SAP. It is the fastest hence most cost-effective method of implementing SAP.

The bonus is that it results in all of our manufacturing sites using the same business processes (for the most part). Which allows us to have a very lean IT team and it allows easy transfer of products and resources from one plant to another. Everyone in the entire organization speaks the same business process language which enables plants to easily lean on each other of help and easily collaborate with each other on new business process ideas. I believe this gives our company a competitive advantage. It allows us to be agile in our response to customer needs globally. It allows us to act as a single company at a global level rather than act as sister sites. It allows us to present a single face to our customers and our suppliers.

Our original SAP implementation took 8 months back in 1998. We had to consider our AS-IS processes and create our To-Be processes. We had to create all of our training documents and we had no experience with SAP.

Now, when we have an acquisition, we roll-out SAP to the new company in 8 weeks. The exception was Brazil that took three months and some external consulting because we were not familiar with the Brazilian localization. But I have heard of no other company that has implemented SAP in Brazil in only 3 months.

I have shared my approach with companies such as KLA Tencor and IGT. People are amazed and skeptical, but we have proved it time and time again. In my opinion, there is no better way.

Companies / People believe that their business processes are too different to use a cookie-cutter approach. But the fact is that the basic Order-to-Cash and Procure-to-Pay processes are essentially the same. These are the processes that are core to SAP. Our company offers both manufacturing and services. Therefore, if we acquire a company that offers products or services, or both, our approach works.

I estimate that we save over $500K / plant with this approach. When you consider all of the benefits, the synergies of having your plants run the same business processes world-wide, the savings is far greater than $500K / plant. The savings on SOX audits alone is significant because all of the plants around the world are on a single instance of SAP. Therefore the IT Controls audit and the audit of all of the application controls is covered at corporate. The plants do not have to be audited individually.

A 2 month implementation is not easy. It is extremely draining on the individuals involved from both IT and the business. But it is achievable. It is repeatable. We are only a few weeks away from proving it once more. I will let you know how it goes.

If you have any questions, please feel free to post them. I will respond as my schedule allows.

SAP - Getting out of the Hosting Business

SAP has announced that they are getting out of the hosting business. They have signed a deal with AT&T and plan to migrate thier hosted customers to AT&T as each customer's contract expires.

I am very dissapointed to hear this news. My company has used SAP hosting for the past 4 years and it was the best experience we have had. Our monthly application availability was at 100% with the exception of 3 incidences over the past 4 years. Even in the months of those incidents our application availability did not drop below 99.5%.

Application Availability is defined as the percentage of time the application is available to users. It is sometimes comfused with server availability. If the servers are up, but the network is down or the application is down, it does not do you any good. Application availablity is the best measurement to use because it means that everything is up and running and users can actually use the systems.

SAP Hosting service are outstanding. We have never had a situation where the hosting side of the business said our problem required SAP Software involvement. With other hosting companies, our requests were often put on hold until the hosting partner "checked with SAP" on something. SAP Hosting was always able to handle such things internally and we never needed to deal with issues between hosting and software or professional services. SAP Hosting is the best at upgrades, and the installation of new SAP software. All of these types of projects were handled seemlessly. That says a lot given the complexity of our SAP environment.

We have implemented many SAP applications on the NetWeaver platform. Our upgrade from R/3 4.7 to ECC 6.0 only took about 10 weeks - and that included an upgrade from BW 3.5 to BI 7.0 which was done at the same time! The delays were on our side trying to get the downtime approved from all of our plants globally. It also included a unix and oracle upgrade! We have also upgraded our EP (Enterprise Portals) environment without a hitch. Our portals environment is used internally as an intranet site and it is exposed externally as our customer and supplier portals. The security is designed very well to ensure that customers and suppliers cannot see our intranet, but they can see thier reports and commit to orders and forecast on line. We are also running SAP APO and SAP GRC (Governance Risk and Compliance) Access Enforcer and Compliance Calibrator on our (SCM)Supply Chain Management server. We are also running BCS (Business Consolidation System) on our BI servers. Plus we are in the process of adding GTS (Global Trade Server) to the environment.

SAP Hosting has done an outstanding job implementing and upgrading all of these systems. They help keep these applications running together seemlessly on the NetWeaver platform. I am very sad to see them leaving the hosting arena.

They never had a hidden agenda. Hardware manufacturers that offer hosting services often use the hosting service as a venu for additional hardware sales. Professional Services companies that offer hosting service often use the hosting service to as a venu for additional professional services income. SAP, of course, is a software provider. But I never felt pressure from the hosting organization to buy more software.

I wish they would reconsider thier decision to leave the business.

Please feel free to share your thoughts on the subject.

Cheers,
Dan