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

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.  

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