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

Raven Business Practice - Giving Back!

I was honored to be invited to join Burr Pilger Mayer in their annual community service day.

Each year, all BPM employees spend a day volunteering at several charities throughout the SF Bay Area.  I was proud to donate my time on behalf of Raven Business Practice joining a team of BPMers at the Alameda Point Collaborative.  We harvested produce, planted, and weeded their urban farm.

Check out the Alameda Point Collaborative at http://apcollaborative.org/

Burr Pilger Mayer https://www.bpmcpa.com/About/Community

Raven Business Practice http://www.ravenbusinesspractice.com/

How Agile techniques can improve enterprise software implementations

Chris Doig interviewed me for his CIO magazine article to gain insight on the benefits of using and agile-like ERP implementation methodology.  Check out the article:

How Agile techniques can improve enterprise software implementations

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.