Dan Raven is a consultant specializing in IT Strategy, Technology, ERP Project Management, and M&A activities.
Showing posts with label Rapid SAP Implementations. Show all posts
Showing posts with label Rapid SAP Implementations. Show all posts
Thursday, September 10, 2015
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:
Monday, June 8, 2015
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.
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.
Wednesday, December 26, 2012
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.
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.
Friday, March 4, 2011
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.
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.
Thursday, April 23, 2009
Rapid SAP Implementations (part 3)
The Project Team
There are many people involved in an SAP implementation. There are people from the business who are critical to the project because they understand the business very well. They know what is required to satisfy the needs of the business partners. They know the "AS-IS" processes. During an SAP implementation, these people are commonly referred to as "Key Users". Usually there are one or two key users from each department within an organization that are assigned to the project. Their participation in the project ranges from 50% to 100% depending on the stage of the implementation cycle.
The SAP team is obviously critical to the implementation as well. These people are the SAP experts that configure the system, write the code for programs and reports, and load the data into the system. This group is a mix of technical resources and functional resource. They are usually very business savvy and capable of understanding and recommending business processes based on the requirements from the Key Users.
It is extremely important to have a lean SAP team. There should only be one SAP team member per module making the configuration decisions. There can be additional people at different locations to provide local support, but the configuration decisions should be made in a centralized manner. Often you can find one person that can handle multiple modules and responsibilities in a project. I strongly believe that one of the reasons that companies have problems rolling out SAP is that there are too many cooks in the kitchen. SAP is extremely versatile. There are often multiple ways to configure the system to get the same business results. With more people involved in each module time will be wasted arguing over the best approach. Moral is negatively effected and the project is delayed. It is hard enough to coordinate configuration between SAP modules without adding complexity within a module.
For companies that have already implemented SAP in at least one site and are rolling it out to new sites, there is a third team of people that is critical to the success of a fast implementation. These people are business people from a site that is already on SAP. Usually there is one person from each department who use SAP on a daily basis. These are hands-on department leaders. They are the "Go To" people within the department. They are the ones that everyone else in the department leans on for support. I like to call these people the Champions. I offer them extra training and they act as the front line support for SAP questions within a department. IT organizes meetings for the Champions to get together and discuss inter-department business processes.
One of the keys to success of a fast SAP implementation is the "Buddy System". I pair up Key Users from the new site with their Champion counterpart from a sister site. Because these people do the same job, they understand each other. The Champion can easily explain how and why business processes are run in SAP. The Champions help train the people in the new site. They help the new site through the integration testing and they become the "Go To" people providing front line support to the new site acting as a buffer between the new Key Users and the SAP team after go-live. Most of the questions or issues after go-live are training issues that are best handled by the Champions.
After an implementation, the Key Users from the new site become Champions and in the future, they may be able to help roll out SAP to a new site themselves.
There are many people involved in an SAP implementation. There are people from the business who are critical to the project because they understand the business very well. They know what is required to satisfy the needs of the business partners. They know the "AS-IS" processes. During an SAP implementation, these people are commonly referred to as "Key Users". Usually there are one or two key users from each department within an organization that are assigned to the project. Their participation in the project ranges from 50% to 100% depending on the stage of the implementation cycle.
The SAP team is obviously critical to the implementation as well. These people are the SAP experts that configure the system, write the code for programs and reports, and load the data into the system. This group is a mix of technical resources and functional resource. They are usually very business savvy and capable of understanding and recommending business processes based on the requirements from the Key Users.
It is extremely important to have a lean SAP team. There should only be one SAP team member per module making the configuration decisions. There can be additional people at different locations to provide local support, but the configuration decisions should be made in a centralized manner. Often you can find one person that can handle multiple modules and responsibilities in a project. I strongly believe that one of the reasons that companies have problems rolling out SAP is that there are too many cooks in the kitchen. SAP is extremely versatile. There are often multiple ways to configure the system to get the same business results. With more people involved in each module time will be wasted arguing over the best approach. Moral is negatively effected and the project is delayed. It is hard enough to coordinate configuration between SAP modules without adding complexity within a module.
For companies that have already implemented SAP in at least one site and are rolling it out to new sites, there is a third team of people that is critical to the success of a fast implementation. These people are business people from a site that is already on SAP. Usually there is one person from each department who use SAP on a daily basis. These are hands-on department leaders. They are the "Go To" people within the department. They are the ones that everyone else in the department leans on for support. I like to call these people the Champions. I offer them extra training and they act as the front line support for SAP questions within a department. IT organizes meetings for the Champions to get together and discuss inter-department business processes.
One of the keys to success of a fast SAP implementation is the "Buddy System". I pair up Key Users from the new site with their Champion counterpart from a sister site. Because these people do the same job, they understand each other. The Champion can easily explain how and why business processes are run in SAP. The Champions help train the people in the new site. They help the new site through the integration testing and they become the "Go To" people providing front line support to the new site acting as a buffer between the new Key Users and the SAP team after go-live. Most of the questions or issues after go-live are training issues that are best handled by the Champions.
After an implementation, the Key Users from the new site become Champions and in the future, they may be able to help roll out SAP to a new site themselves.
Wednesday, February 18, 2009
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.
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.
Wednesday, February 11, 2009
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
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
Subscribe to:
Comments (Atom)

