Monday, October 08, 2007

AXUG Summit 2007

As our post-implementation deployment is wrapping up, I am going to make a point of posting more to this blog now that my time is freeing up to do other things. On October 15-17, I will be attending the AXUG Summit in Orlando, FL. There appears to be some great tracks to attend. I will be attending the performance track to see if I can't return with some knowledge on how to speed up some slowness in our invoicing process. If any of you will be attending, let me know and I'll be looking to speak to you.

Just to fill you in now that things have calmed down, here's our implementation story:

My lack of posts for the last four months have not been because I was too lazy but rather because of being overwhelmed with work. Our implementation was rocky but we made it work and persevered as a result. We have a VP who in my opinion is always a stellar performer. He's the sort of guy that even if everyone is looking at doom and gloom, his head is still held very high. If you ever see this guy looking down you better cover your head because the sky is surely falling. In my opinion he had a lot to do with the project's success. When all seemed as if it were about to fall apart, he was there to encourage all of us on the project and cheer us towards success.

My shop is pretty small, less than eight regular IT employees and due to some recent departures is even smaller now. I was and am the only full-time developer for AX in our company during our implementation. I also have been the only person to become technically fluent with AX from installation to configuration to troubleshooting, etc. Why was our implementation this way? To some extent I can blame it on a lean budget but I can also point to our partner.

Hind sight is always 20-20, of course.

We were new to AX. I had just been hired in February 2006 and had the VPC of AX 4.0 Pre-Release given to me in June, no manuals, no documentation, just a job of learning it. Our Project Team was a who's who of the shining stars in the company, one from each functional area of the company. Not one of them had ever heard of AX, and only two or three had ever worked with or knew what an ERP system was. I was the black sheep being from a technical environment and actually having a two month head start on learning it.

Our partner rolled in and immediately setup a project timeline and a go-live date, which we ultimately missed and had to reschedule three times. All seemed as if it were going well until we began official software modification in October. Developer resources from the partner were not cutting it. Each of the three guys who all in total spent less than two weeks with us seemed to have no real idea what was going on. These guys were asking me questions about AX... a scary thought. But the more scary thought was that I actually had the answers. As a result we determined very quickly that either the seasoned resources were tied up (as we were being told, although each of the three guys we received were 'Senior Developers', or seasoned developers did not exist - my personal belief). Before long into the development/modification phase, we hired a previous contractor of another in-house developed system and cut a lower hourly wage for me to teach him AX and X++ and have him at our disposal as needed. This turned out to be a better decision than the partner's own developers.

In the end, we were still allowing our partner to make architectural decisions since they were the experts. They made decisions that I even knew were terrible although my experience in AX was lacking. At the time those design decisions were made, we accepted them and moved forward. Now looking back we all wished we had challenged their solutions.

I share a glimpse into our implementation to convey a notion to you if you are the customer: Know AX.

While I'm sure most implementations are packaged deals (like ours) where a team arrives and educates you first and then immediately begins the project, I suggest a different approach. If you can work it out, install the product first, allow your technical people and key functional people access to it and all of the training manuals for no less than a month. They need to understand what the product is, how it works in its pure state. Then and only then start the implementation project. If you as the customer rely on your partner 100% you, too, will experience modifications/business processes that were implemented but not fully thought out. The ramifications can be from as simple as a quick rewrite of a function to a complete overhaul in the next major AX release.

If you are a partner, I encourage you to encourage your client to learn what AX has to offer and how it works from the beginning. Even if the Sales Order process looks nothing like what your customer will expect in the end, still encourage them to create an Item that they sell, create a customer, create the ledger accounts, execute a sales order. Make them understand how AX works before you begin consulting them on Architectural changes. In the end you will profit from a long-lasting business relationship rather than a continous finger-pointing who-did-what-wrong conflict.

And in the end, isn't your goal a happy customer and continuous reference?

Hope this helps those of you either in or preparing to enter an AX implementation, or for that matter any ERP or large-scale software implementation project.

DB

P.S. Are we happy with AX? Of course we are, but we weren't there on July 1st, the day we went live. Much massaging, cleanup, multiple phone calls to Fargo, several 36 hour+ days, and six weeks of no weekends or weekdays off had to be experienced before happiness was achieved but all in all we have learned from our mistakes and it has made us a better shop in the end.

5 comments:

Anonymous said...

Hi Dave,
(I am French, so forgive my poor english)
I am a partner charged to implement AX in companies. Although I quite agree with you, I must answer your process of implementation is very costly from a customer point of view. We know an AX implementation is costly in time, but unfortunately, customers can not understand why it takes so much time to implement AX (as we are supposed to be some specialists). Even if I try to alerts my customer to spend some time on AX, I can not insist to much because I look like the pessimistic guy.

So, you are right, but this is not easy to sell such a method, and it really depends on the customer's experience.
LD

Anonymous said...

How many of these rules did your organization break?

DON'T award services based upon the lowest rate.

DON'T award services based upon the size of the partner.

DON'T forgot to closely review and check references.

DON'T assume all partners are equal.

DON'T underestimate the need for project management.

DON'T ignore “early” signs of trouble” – such as delays, excuses, scope creep and cost over-runs.

DON'T ignore the “voice of reason” – when you think things are going wrong; they usually are.

Finally, if it sounds too good, in most cases, it usually is.

AX-AID (Assist, Improve & Develop)
www.advancedsystemsintegration.com

David Bowles said...

I wanted to respond to the last comment.

I'll start out with a note that we used the most notable Partner in all of AX implementing.

They weren't the lowest rate.

They were a mid-sized partner.

We reviewed and checked references and the references were of businesses like our own.

Common sense tells you no two partners are alike

Our partner was contracted for leading the project management.

We did not ignore early signs of trouble but were told that everything was on time and it was on budget.

Overall had we had possessed a Crystal Ball, then we probably could have anticipated problems.

We didn't have a complete failure of a project, just many opportunities to that needed to be addressed post go-live and still managing some opportunities that we should have pushed back on our partner to manage more effectively while they were here.

Overall, I don't believe all partners are bad, I just believe that when you get a team of implementers it is a luck of the draw. Sometimes you get someone who is stellar, sometimes you get the average experience person, and sometimes you get someone who is less than stellar.

The point is all of the reviewing, monitoring, and references in the world will not always guarantee that you will have a successful project and on top of that the statistic of successful IT projects alone is already against you from the moment you set sail on a project.

David Bowles

Anonymous said...

Anonymous Response!

David I have been in the ERP business for almost 12 years. Five years delivering services with Big-5 and the last 7 selling solutions.

When we sell an AX solution our customers do not consider the quality of my teams’ deliverables to be a bi-product of luck or chance.

We teach our customers to monitor and manage project risk for variables we can't control such as:

1) customer resource quality
2) customer time commitment
3) customer turnover

As for your comments regarding “we didn’t ignore early signs of trouble” and “we didn’t have total project failure” and “IT project are doomed from the get-go” I am not sure I agree nor would our customers some of the largest and complex manufacturing sites in the channel many of whom have purchased from such "notable" partners!

Although no partner can guarantee 100% success, certain partners can consistently guarantee higher rates than others!

Unknown said...
This comment has been removed by the author.