RE: Implementation timescales
Hi Sigita
I understand the recommendations today but they are not practical. In AX2012 you have competing ISV's with ompatibility issues per release and you have updates that do not impact on the core business of customers but cost time, delay and money to update. In todays world the customers, on the whole, will get to a point in Design and freeze on that version. They do this to ensure what they are testing during the UAT and deployment phases of the project is as static and stable as possible. Only when a specific issue is hit will the search for the KB be undertaken, and if this is part of a roll up KB all hell breaks loose with the costs and changes.
Average UAT should be three months. You say yourself that UAT is "when we want scope, code base and configurations to be locked from changes", also the cut-over period you would not move post UAT, the same statement applies. From commencement of UAT to go-live could be 6 months, you want the code base locked for changes but we are updating that code base monthly on recommendation so there is a conflict.
In past implementations working with automotive and Pharma they would simply not allow this, this would prevent them validating testing on the final solution because it is moving.
With the changes being pushed you say there are no new features or UI changes in any PU or major release. Clearly there are but I presume you mean all of this "added" functionality will be off by default - is that what you mean? That is fine for the major releases and it can be built in to assess and turn on new features. We do still get PU's monthly and this creates a moving code base. I understand that these are fixes with no features (not true in the past but I will believe this commitment).
I still do not see how a customer with a UAT implementation lifecycle >1 month can validate the code base they are on prior to live and be 100% sure, it is moving every month so by the time you have tested your UAT in 3 months you are 3 PU's behind. There are industries that would not like this.
Are we saying in conclusion that your UAT has to be streamlined to 2-3 weeks to ensure you can test the next version before it is released (like the time pressures being imposed on production and live I guess). Is it realistic for businesses with extensive business processes to fully test and accept all processes (ISV's, integrations etc.) in a 2-3 week period even if they did adopt the new VSTS automated testing? (This only covers task guides so all external elements of the test still need to be undertaken to ensure files are received in external systems correctly etc.). Alternatively are we saying that because everything is "backward" compatible in the new world the customer does not have to test because everything will simply work as it did before? :-)
Thanks
Steve
