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 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.

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 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

SAP Enterprise Portals & Microsoft SharePoint

Like many companies, we are reviewing options for platforms on which to build our intranet. For years, we have used Lotus Notes Dominos as our intranet site. Our implementation is very good as a document library, but is limited in the collaboration aspect. It also requires more IT Administration than we would like to dedicate to it.

In 2004, we invested in the mySAP Business Suite which included SAP Enterprise Portals. Some of the business embraced it as we rolled out team rooms, supplier collaboration rooms, and customer collaboration rooms. But when we tried to implement anonymous logon for general users to view document libraries, we ran into security issues. This would not have been a problem if we had not used the same instance for customer and supplier portals (accessible outside our firewall). The problem is that even if we screen access, a supplier or customer, could play around with the url and potentially get into our intranet. I know there are ways to deal with this, but none that would work within our security policy. As the IT Applications team was working on this security issue, SAP announced it's support of Microsoft SharePoint at SAPPHIRE 2007 (SAP's annual trade show). This is good because our user base has been asking about using SharePoint as it had been heavily advertised by Microsoft.

We have installed a development instance of MS SharePoint and now are trying to build a site map. At this point, we like SharePoint's ease-of-use and we like SAP Portals connectivity to other SAP applications. We are using SAP EP to view dashboards from SAP BI and Single Sign-on (SSO) to SAP R/3, BI, APO, and ICH. Now we have the challenge of trying to integrate SharePoint and EP to get the best of both worlds.

I have found documentation at www.microsoft-sap.com that shows how to view SharePoint iViews through the SAP EP framework, but I have not found the opposite. To make use of SharePoint ease of navigation, we plan to offer EP iViews through the SharePoint framework. Documentation on this appears to be a little more difficult to find. But if we are to provide the best of both worlds to our user base, we need to find a way to do that. If any of you have experience with this, I am very interested to hear from you.

My idea is to utilize the SharePoint navigation to offer document libraries, department info pages and team rooms. I would also like to show tabs for dashboards and SSO to our Worldwide Systems launch pad in EP. When the user clicks on either of these tabs, they would be requested to logon to the portal. After they logon, we would like to show them these pages from EP as web parts in SharePoint.

This is the ideal. I will let you know how it goes.

Cheers,
Dan

IT Applications Strategy

In the fall of 2004 we decided to fully embraced the SAP NetWeaver platform and started by upgrading from SAP R/3 4.6C to 4.7. We continued in 2005 by implementing SAP's BW (Business Warehouse), EP (Enterprise Portals), APO (Advanced Planning Optimization), ICH (Inventory Collaboration Hub), and XI (Exchange Infrastructure). We were very successful in reducing the complexity of our applications environment. We have enjoyed the benefits of spending much less time troubleshooting connectivity issues allowing us more time to focus on other things.

That was just in time, because we went public again in 2006 giving us until the end of fiscal 2007 to be in compliance with Sarbanes-Oxley Act Section 404. We have spent the last year and a half helping to prepare our company for this. Luckily all but one of our facilities was already on a single instance of SAP, so we only had to implement SAP at this site in Brazil. But we also had to re-write all of our SAP Roles and put work flow tools in place for approving and monitoring access privileges. For this we chose Virsa's Compliance Calibrator, Access Enforcer and Fire Fighter. Virsa was acquired by SAP the day after we signed the deal with Virsa. These tools are now in place and working well. We also had several Application Controls to work out. These Application Controls refer to business process controls that are configured into and enforced by systems. We are almost finished replacing our Financial Consolidation worksheets with SAP's BCS (Business Consolidation System) which is a component of SEM (Strategy Enterprise Management). This will reduce the number of spreadsheets which need to be tightly controlled. We will wrap up our compliance projects with the implementation of GTS (Global Trade Server). This is not a SOX requirement, but it will help us with international trade compliance.

During all of this time focusing on compliance projects, we have not done a great job supporting the new requests from our business users. I am looking forward to this next fiscal year where I plan to make tremendous headway in system usability. Our focus for Fiscal 2008 will simply be on productivity. We have already started by offering BW reporting and dashboards over the intranet. We have also started offering access to applications via our intranet (Enterprise Portals). We will continue by creating wizards in EP for maintaining master data leaving very little room for error. We also plan to implement the Fusion Ops rules engine to decrease the work of our material planners letting them focus on the supply gaps. We may also undertake a supplier EDI initiative to reduce the manual pushing of documents between us and our suppliers. We will also be implementing a lot more work flow.

I am very excited about this coming fiscal year. The compliance projects definitely helped our corporation as a whole. These projects are not very glamorous and are not extremely appreciated by the common system user. With the compliance projects out of the way, we will be able to focus on enhancing the user experience. The productivity projects will help the individuals within our organization and within our supply chain. Productivity projects are definitely more fun and more self-rewarding.

IT Outsourcing

In the spring of 2004 my company spun off of Solectron. At that time, we considered IT Outsourcing as we were being courted by Satyam. We are a global high tech manufacturer with facilities in Malaysia, Puerto Rico, Dominican Republic, and Scotland in addition to our headquarters in Silicon Valley. Because we had facilities in low cost regions of the world, it was less expensive for us to build our own SAP Applications team in Penang, Malaysia than outsource to and Indian outsourcing company.

At the time the, we could hire 3 people in Penang for the cost of 1 in California. The global economy has since changed. Now the cost ratio is closer to 2 to 1. This makes the cost of outsourcing close to a wash.

If cost is no longer a factor in the outsourcing decision, we have to consider other factors. These factors include ease of communication and scalability.

When we were a part of Solectron, we had a team in Bangalore. We found it very difficult to work with this team from a pure time zone perspective. We also had a team in Munich. The time zone was not the issue for the German team. The time difference was only 3.5 hours from Germany to India. For the Munich team, language or rather accents created a communication problem. Eventhough they were only 3.5 hours appart, they never picked up the phone and talked to eachother because they could not understand eachother. In California, the time zone was the problem. Every time the team in Bangalore had a question, we would lose a day of development. This cause a degredation in the "quality of life" for the employees in both California and India. Team members had to work their normal business day to support the site plus work odd hours to talk to Both of these are examples of communication issues with offshore outsourcing. Therefore, communication issues land on the "con" side of the evaluation.

Scalability, however lands on the "pro" side. When outsourcing, the assumption is that if you need to scale up quickly, you can. During a down turn, if you need to scale down, you can do so without impacting your own employees.

Supply Chain Decision

Today in an IT Steering Committee meeting, we agreed to proceed with the Fusion Ops Supply Chain solution. This represents a significant change in our IT Strategy. I also announced that we plan to utilize MS SharePoint to supplement our implementation of SAP Enterprise Portals which also represents a significant change to our IT Strategy.



Three years ago we implemented the mySAP Business suite. We had already implemented SAP R/3 v 4.7. With this mySAP Business suite implementation, we added BW, APO, ICH, EP, and XI.



Before that, we had several applications that were patched together and to R/3 which became a nightmare to maintain. We were spending a significant amount of time maintaining the system connections and trying to keep the data in each system in sync. We had a supplier portal from RiverOne that was constantly out of sync with SAP - partly due to our buiness processes and partly due to complexity in the solution. Any time we needed a change in the supplier portal, we had to arrange the change with the vendor and pay extra for it. We were looking for a solution where data integrity was not an issue and where we were at liberty to make changes in house whenever the business required the changes. The SAP Netweaver platform was the perfect solution.



Over the past three years, however, we learned a lot of lessons. One is that even when we had extremely good data from our R/3 and APO systems, which allowed us to get reports showing exactly where our supply gaps were, it was not enough. Just having the data was not enough to change the habits of our material planners.



We also received complaints from our suppliers about the speed of our portal. We have exposed our instance of EP externally. The suppliers log into EP and via single sign-on, they can access supplier specific BW reports and they can commit to POs via ICH v4.1 (SAP's Inventory Collaboration Hub). They can also commit to their forcast via a custom EP application using BW data to recommend the forecast commit.



Today's decision to use Fusion Ops represents a change in our IT Strategy, because we are entering into a scenario where not all of our applications are SAP applications anymore. It's not too much of a stretch because Fusion Ops is a Powered by Netweaver product. As it runs on the Netweaver platform, we should not have many connection problems, however, it does run on a separate SQL database and therefore has the potential to get out of sync with R/3.



I have become disallusioned by all supplier portals. They are a nightmare for IT organizations to maintain. I think we should undertake a major suppier B2B initiative where we can communicate via EDI, XML or Rosetttanet PIPs. Our customer EDI programs are very solid and it is extremely rare for us to have support issues with EDI.



Inevitably I think we will have to offer suppliers both a portals solution and an EDI solution. I beleive that supplier don't want to have to log on to their customer's portals to commit to POs after they already had to do the same thing in their own ERP systems. They end up having to log into several customer's portals and learn how to use all of them. I think that is why suppliers would rather commit in thier own ERP systems and have those signals automatically sent to our ERP system.



The Fusion Ops solution, however is more than just another supplier portal. It is a rules-based engine that can act on MRP results on behalf of the material planners. Our MRP produces thousands of requisitions, some are no-brainers that should either be cancelled or converted to a PO. Today the material planners have to run reports to determine where the real gaps are and then act on those gaps. Fusion Ops could automatically take care of most of the MRP requirements based on rules that the Material team maintains. Fusion Ops then sends the POs to their supplier portal for suppliers to commit. That is the piece that I would like to handle via EDI.



Later I will explain why the addition of SharePoint represents a new strategy for us as well.