Eleven videos

Typically when a customer has approached us to solve their performance problems, they understand that they have pain points, they know where things are, they're looking for direction and help to resolve them. They may have had their IT staff come in and see database issues but not know how to tie it into the actual system themselves. Maybe when they went live they put a number of orders in the system and things were going very well, but now that their business is scaling they aren't able to troubleshoot. What we try to do is approach that to show them in most cases its modifications that are actually causing them the problem. Either poorly written code which is not always the developers fault, but many times it's a training issue that goes on, so how do you diagnose the problems, how do you resolve the issues? Trying to add value to the customer so they can potentially serve themselves and help them develop the things, but guiding and providing knowledge to them so they can better perform their system and tune the things that need to be fixed.

If you engage the Client Strategy Group into helping with performance issues, we'll come in and take a holistic approach to solving this problem. We won't just look at the database or the code, we'll look at the entire environment. We'll look at the SAN, we'll look at the server set up, we'll look at the database to make sure all the settings are set correctly per what Microsoft recommends and we'll dig into the code very deeply. In addition we will come up with several recommendations around how to make the SQL Server perform much more efficiently, and we may be able to actually get in and figure out if there hardware deficiencies or there might be SAN deficiencies that we can get in there and actually help with those types of recommendations as well. The other side of the fence, on the code side of the fence, typically comes as a result of finding issues with the database. You will see things running extremely slowly, but what you will find is that yes there are some database tuning potentials there but a lot of times it's due to inefficient code setup.

AX upgrades start with CSG engaging with a client and beginning with an assessment. From the assessment we figure out how big, how much work, what needs to be done, by whom and we establish a relationship between our companies. My role with CSG is that of delivery. It's my responsibility to get things done. In doing so I need to work with the project manager or IT management staff for our customer to determine what resources we're going to bring to bear on the project and get these things done: at what times are these resources going to be available, and we work through the development cycle resolving code conflicts and compile errors, data migration and all the way through go live. And through this whole process we can also bring business analysts to the table that can help put together testing plans, conduct testing, conduct training with the client and then on go live weekend we can also support the customer when it comes to boots on the ground or remote support and we work that out with the customer to determine what's best for that go live weekend.

Data migration from an AX 2012 perspective can be a very complex creature. There is a comprehensive tool set that Microsoft has built, but there's a lot of upfront intelligence that we gather as far as the data distributions are concerned and the data errors that are intrinsic within the system. We try to fix those upfront and try to put a framework around that so that we can comeback to the customer and say hey this type of information is going to need to be cleansed before we even attempt to do a data migration. The tool set itself is very good but if there is bad data in the system then there is going to be a lot of hiccups along the way, and a lot more time is going to be spent going back and cleansing that data and rerunning all of the scripts that are necessary to move the data from whether it's 4 or 9 up to 12. The data migration in AX 12 is what's called a "source to target," which means much of the data pre-processing is done in an offline system, and not on the production system. That allows for the re-running of the cockpit several times, cleansing the data iteratively, and it allows us to bring the best data forward into the new AX 12 system.