Go Live: Are We Ready?

The clients I work with frequently ask me this question once we are deep into the implementation. I never give a straight answer. You see, I believe you should know if you are ready and with the right preparation you will. So let's take a high level look at what must happen before you will be confident enough to go live.

Initial Training

Successful project teams have a leader who knows something about the operational aspects of every department in the business and more importantly how they should work together. While sometimes this is an IT person it is important to keep in mind that this is not an IT project, or accounting for that matter, it is a project intended to knit together all of the operations of the business and seamlessly record their activities in the financial records. For this reason, xTuple application training, specifically the xTuple 101 course, Implementing and Managing xTuple ERP, should be attended by the project manager, the financial controller and ideally the operations manager.

Training Pilot

The next step is the training pilot. This is a pilot built on the training database but with a very small subset of your data. Yes, that's right, it is built on the “Yellow Truck” database. Why the training database? Because it works and it has just about one of everything in it. You can quickly add items, customers, and suppliers configured to match your business but on a database that will enable you to successfully process transactions. Remember, at this point you are still learning and making decisions about how to configure xTuple to support your business while experimenting and practicing with different business process flows. You will also be defining your chart of accounts and establishing account mappings.

Small Pilot

You will quickly gain confidence and grow tired of having your data mixed up with toy trucks. You are now ready to stand up your “go live” database with either the empty or quick start database and conduct “small pilots.” As you determine configuration settings throughout the piloting process, they can be “documented” in the go live database. Note! You should create a special user in this database for this purpose that has privileges limited to static setup and configuration screens. This user should not have privileges that enable it to create orders of any kind, inventory or financial transaction.

So where does the small pilot come into play? This is where we create our first “carve off” database. Postgres makes it very quick and easy to copy a database. Your small pilot database “carve offs” will be derived from your go live database. You are likely to make numerous small pilots as you make changes in the go live database and then want to see the effect they have through piloting. In the small pilot databases you will enter a very limited subset of your operating environment, much as you did in the training pilot, but this time without the “training wheels”. You will then execute and refine business process flows and the configuration settings that support them, once again documenting the changes as you go in the configuration settings on the go live database.

Scaled Pilot

Now that you have performed small pilots and made the corresponding changes in the go live database, you are ready to move on to the scaled pilot. This is, once again, performed on a carve off of the go live data base. But, instead of manually entering information into it, you will perform any imports that you have developed. Frequently we are importing customers, vendors, items, bills of materials and beginning balances, but first a word on importing.

The previous pilots should be performed with an eye towards how the full data set will get into the go live database. We almost always assume that it will be through imports but importation is not always the best method. Don't get me wrong, imports work well and the xTuple CSV Import tool in conjunction with the API views can make this a smooth and easy process but only when the data from the old system is:

• clean
• complete
• relevant

...but it is rare that this is the case.

Often, implementing xTuple is the impetus for cleaning up after the sins of the past when it comes to company data. The data may be spread across multiple places and be in a format that is not conducive for importation. It is likely that it does not contain settings that a robust application likely xTuple requires for functions such as MRP, and bills of operation and advanced credit control and vendor management to name just a few. It may be dated and no longer valid. For these and a host of other reasons, it may make sense to key enter some data into xTuple. There is a big benefit to this that is not obvious at first. The project team should recognize that key entry of data by end users provides an opportunity for them to get more comfortable with xTuple and most importantly, for them to take ownership of a part of the implementation and the supporting data.

The scaled pilot normally does not happen all at once. Frequently I am working with clients at this stage and one day we might carve off the go live database, import the item master, then manually create a customer and vendor and run through the business process flows to validate the items. Lessons are learned, the import source may be tweaked and the process is repeated until finalized.Later, the same process may be repeated when the customer data is being entered or imported. Eventually all data that will be key entered into the go live database has been and the import maps and source files have been finalized so that we can carve off the go live database, perform the remaining imports and have a database that is mapped for accounting and ready to go.

Once we can create a finalized and complete scaled pilot from the go live database, we are ready to conduct end user training. It is at this point that we gather together individuals from various departments to train them on their part of the system. But we need to go further. That is where the scripted pilot comes in.

Scripted Pilot

The scripted pilot is conducted on a complete scaled pilot. The project team writes a very simple script for each of the departments that reflects “a day in the life of” for each with page breaks by department — you'll see why in a moment. The end users have now completed hands on training so the script should be very high level: “create a sales order for this customer with these items in these quantities,” for example should be enough detail. The first time you conduct the scripted pilot, you do so with everyone in a conference room taking turns at the computer while others watch and discuss. Once the process flow can be completed smoothly in the conference room it is time to break the group up and conduct a “dress rehearsal”.

Throughout the scripted pilot, accounting is doing two things: monitoring the transaction flow to the G/L and financial reports to validate their account mappings and planning for opening balances which include four areas:

• beginning G/L balances
• open A/P
• open A/R
• initial inventory balances

This topic is a blog post in itself but suffice it to say that the scripted pilot is the time to take a dry run at these as well.

Next you physically break the script into its departmental sections, this is why we page break by department. Hand out the sections and send everyone back to their normal work area.Set a time by which the scripted pilot must be completed and schedule the group back in the conference at its conclusion. This is the closest you will come to going live without being live.

As many of you know, I am not a proponent of going parallel — again another candidate for a blog post. However, running scripted pilots each day for several days gives the group the confidence it needs to take the leap and make a clean break from the old systems. You can gradually embellish the script each day to include more complex business requirements and exception processing but at some point the team may even revolt and say “enough already, lets do this for real!” When I played football this was the team's sentiment by the end of training camp; “we're tired of hitting each other coach, let's go play a game!” That's when you know you are ready. I've watched it happen many times. The group gets comfortable with the pilots and xTuple. Often they long for the new functionality that they are currently lacking but have in the pilots. Their desire to move ahead exceeds their trepidation for change and they are ready to transform the way the business operates.