Getting Your ERP Project Off to a Good Start

Because ERP projects generally deliver similar core functionality, and your implementation team is already very experienced with Microsoft’s Sure-Step Methodology, it can be tempting to skip the formal Project Kick-Off Meeting and simply dive right into the work at-hand.

I’d like to make a strong case for holding a Project Kick-Off Meeting, regardless of the size/complexity of the project, or the experience level of the customer and the implementation team.

Covering key parameters at the beginning of a project in your kick-off meeting ensures team alignment to project objectives and approach. The materials can continue to be referenced throughout the life of the project as a touchstone for the team to check on progress, identify scope changes, and verify timeline and budget. Here are suggested components for your project kick-off deck, and associated benefits:

  • Introduce Project Team Members

Important that all ERP stakeholders and project contributors are invited in advance to the kick-off meeting (or receive the materials afterward, if they are truly not available to attend in person).

On the customer side, ensure project sponsor(s), system owner(s), business process owners, and other supporting team members from Finance, Operations, and IT are invited to the kick-off (especially if they will be asked later to participate / provide support or information). Core members of the ERP partner implementation team should also attend so they can be introduced.


  • Customer team sees executive leadership (sponsors) at the table, backing the project effort
  • Ensures all stakeholders are aware of the project and understand who will be assigned
  • Sets a foundation for working relationship between customer and implementation team
  • Review Project Scope

A typical ERP implementation scope might seem basic or perhaps inherently obvious; however, prior to an ERP project being approved, there may have been multiple ERP-related initiatives or features discussed internally by the customer during their evaluation or budgeting process.

This means some attendees may come to the table with different preconceptions about the project’s scope and deliverables. This could seriously derail a project later if not addressed up-front.


  • Ensure the approved project scope is clearly communicated and understood by entire team
  • Verify the scope is correct (as per the signed agreement) – any changes needed / allowed?
  • Reinforce upfront alignment among all players: what will be delivered vs what is out-of-scope
  • Include approved project budget here also – reinforce relationship between scope and budget


  • Share High-Level Project Approach (Implementation Phases) and Timeline

This is a key opportunity for the implementation partner to outline and describe, up-front, the various phases of the implementation or upgrade project in in relation to the overall project schedule and key milestone dates, particularly release/go-live.


  • Explain phases of the project where customer team should dedicate time to design or testing
  • Answer customer questions about the process, deliverables, dependencies, and timing
  • Agreement on how project will be executed and participation needed
  • Project Team Roles & Responsibilities

Now that the players have been introduced to each other and to the overall plan for executing the project, it is good to circle back and assign specific names to the various roles on the project team. Also key to confirm for customer team members who will be key decision-makers and subject matter experts on behalf of their business area and who will be playing supporting roles on the project.

At a minimum, there should be a Project Lead (or Project Manager) from both the customer side and the implementation partner who will work together to be a hub for project communication and guide the activities of their respective players. For smaller projects, this role may be played by the System Owner on the customer side and by the ERP Functional Lead on the implementation partner team.

The Project Sponsor should also identify whether they will be the overall decision-maker for the project, or if they have identified key System Owners from the business who will represent their departmental business process decisions and needs during critical design and testing phases of the project. Depending on the size of the project, additional customer subject matter experts will play a role on the Core Project Team providing design input, participating in testing or training tasks.


  • Identify early if there are key contributors or stakeholders who need to be added to the team
  • Build shared understanding of what is expected from each team member based on their role
  • Re-affirm how each team member will execute their role during the phases of the project
  • Alignment on responsibilities for key decisions, design input/approval, and test execution
  • Reinforce communication needed between Core Project Team and the business areas they represent – the goal is no surprises for the project team or for the customer organization
  • Next Steps

Great! Everyone is lined up and ready to play their part. This is the point in closing out the kick-off meeting to clearly list specific tasks / activities for the next 1-2 weeks and answer questions.

At this point, it’s also a good idea to decide as a group how often the project team should meet and how project status updates should be shared across the team and to senior management.


  • Kick-Off Meeting attendees leave with a clear understanding of what will happen next
  • Team provides input on frequency and style of project check-in meetings and progress reports
  • Time allowed for questions that were not addressed by the kick-off materials

A kick-off meeting that covers the topics above in high-level fashion can easily be completed in 30 – 60 minutes, depending upon the size of the project and number of players involved.

The reward is that the team will all have a clear understanding of the game plan and how they will be contributing to that plan at the beginning of the project. They will also have a foundation for identifying and communicating issues throughout the project that might impact scope, quality, or timing.

It really is a team huddle and “Go Team!” moment to build enthusiasm and support for your ERP project. Take the first step toward success and team-building with your next Project Kick-Off Meeting.

This article was written by Juanita Schoen, Dynamics Project Manager for Tridea Partners. Tridea is a leading Microsoft Dynamics provider.

Microsoft Dynamics AX: Testing a Process

Almost on a daily basis, I am asked to test a process. How can you easily prompt for input and run the test? In Dynamics AX, I would use the ‘Dialog’ class to build a prompt screen and request the input to run the test.

How? Simply create a job file that will build the interface for you. Depending on the fields your test will require, define a few fields, objects and then use the input in your test.

Dynamics will create a nice interface with the correct data types so you can focus on your test.

Dynamics AX

Here is the code:

Dynamics AX Test a Process

This article was written by David Munn, AX Technical Consultant for  Tridea Partners. Tridea is a leading Microsoft Dynamics provider.

Dynamics AX 2012: Understanding the Swings in the Running Average Cost Calculation

Everyone using Dynamics AX for inventory should be familiar with the concepts of physical inventory and financial inventory, as well as physical costs and financial costs. When receiving an item against a purchase order or when reporting an item as finished on a production order, the physical quantity is incremented using a physical cost that is understood to be based on incomplete information. Only when invoice matching has been performed against the purchase order can we be assured of having all the necessary information (price revisions, taxes, handling fees, etc.) to replace the original “placeholder” physical cost with the “true” financial cost. In the case of production orders, we need to wait until the production order is “ended” (when no more transactions can be recorded against it) to finally assign the financial cost.

In a similar fashion, when consuming an inventory item (for example on a sales order packing slip or a production order picking ticket), AX assigns a temporary physical cost that will ultimately be replaced with a financial cost that is based on the inventory valuation method selected for the item (FIFO, weighted average, etc.). The physical cost gets replaced by the financial cost only when the transaction is finalized (the ending of the production order or the invoicing of the sales order). Regardless of the inventory valuation method assigned to an item, the physical cost assigned when consuming inventory is always computed using a simple running average. Assuming that the “include physical” checkbox is selected on the Item Model Group, the running average is computed using the following formula: Running Cost Average = (physical amount + financial amount) / (physical quantity + financial quantity).

Many clients are surprised to find that the running average cost of any item can vary significantly from the actual cost of an item, often by much greater amounts than the wildest swings in purchase prices. The explanation is simple, as illustrated by the below example:

  1. Purchase 10 widgets @ $10 each for a total of $100
    • $10 cost is derived from the purchase order and is a physical cost
    • Running Cost Average = (physical amount + financial amount) / (physical quantity + financial quantity).
    • Running average calculation = ($100 + $0) / (10 + 0) = $10
  2. Issue 5 widgets to production pick ticket @ $10 each
    • Use running average calculation from above step as a starting point: ($100 + $0) / (10 + 0) = $10
      • Subtract $50 from physical amount and 5 from physical quantity
    • New running average calculation = ($50 + $0) / (5 + 0) = $10
  3. Obtain invoice for widgets – including fees, cost is now $11 each for a total of $110
    • Use running average calculation from above step as a starting point: ($50 + $0) / (5 + 0) = $10
      • Subtract $100 from the physical amount and 10 from the physical quantity; the quantity initially received is no longer a physical quantity, as it has now been invoiced.
      • Add $110 to financial amount and 10 to financial quantity (per the invoice)
    • New running average calculation = (-$50 + 110) / (-5 + 10) = $12
  4. The system has calculated a running average cost of $12, even though the only purchase price was for $11.

The reason for this is that we understated the value of the 5 widgets issued to production prior to obtaining the invoice that informed us of the true $11 cost per widget. We brought the 10 widgets in at $110, and issued out 5 of them at $50, so we now have to spread the remaining $60 over the 5 that are still in stock. So the undervaluation of the quantity issued to the production order is offset by the overvaluation of the quantity still in inventory. AX will eventually rectify this only when the production order that consumed that quantity of 5 has been “ended” and the correct financial cost of $11 can be assigned to the quantity consumed. This is because AX does not make adjustments to physical cost transactions, but rather leaves the initial physical cost amount intact until it can be replaced by a financial cost amount.

So, once the production order is ended, the new running average calculation will yield a result of $11, using the following logic:

    • Use running average calculation from above step as a starting point: (-$50 + 110) / (-5 + 10) = $12
      • Add back the -$50 physical amount and physical quantity of -5 (the quantity initially issued as a physical transaction is now issued as a financial transaction)
      • Subtract $55 from the financial amount and 5 from the financial quantity (the picklist transaction is now a financial transaction)
      • New running average calculation = ($0 + $55) / (0 + 5) = $11

It is important to point out that AX will ultimately always assign the correct financial cost to each transaction. We just have to recognize that until we can feed the system with all of the necessary data to produce true financial costs, our financials will necessarily reflect these “estimated” costs.

This article was written by Matthew Boese, Partner at Tridea Partners, a Gold Certified Microsoft Dynamics Partner.





Microsoft Dynamics AX: Tips to Viewing Inventory

Implementing any ERP system involves getting used to new procedures and learning to navigate throughout the system in the most efficient manner to save you time. Here are some helpful tips and tricks. We share these tips with our clients to allow them to hit the ground running and become quickly accustomed with the Microsoft Dynamics AX Inventory Module!

1. Add in your Inventory dimensions. You can usually find a “Dimensions Display” button is most inventory related areas.Microsoft Dynamics AX Inventory module

Select the dimensions that apply to your AX setup and click save setup checkbox.

Microsoft Dynamics AX Inventory module

Now you will be able to see the specific details for your inventory.

Microsoft Dynamics AX Inventory module

2.  I’d also recommend hiding fields you don’t need. You can right click on a field and hit “hide”. Very quick and makes your screen less cluttered.

Microsoft Dynamics AX Inventory module

Now your screen only contains fields that are relevant to the transaction you are performing.

Microsoft Dynamics AX Inventory module

3. You may catch yourself performing inventory transactions that require you to know what’s on-hand right now for a current item. Rather than hop back and forth from the on-hand inquiries screen, you can easily see this information in the transaction. Below I’ve used a movement journal as an example.

I want to move some quantity of an item out of warehouse 24, but I don’t know the total quantity in warehouse 24 off the top of my head. Click the warehouse dropdown and select the on-hand tab to view the available physical quantity.

Microsoft Dynamics AX Inventory module

You can do the same thing on location or batch number if those are inventory dimensions that you use.

This post was written by Laura Garcia, AX Application Consultant at Tridea Partners. Tridea is a leading Microsoft Dynamics provider.

Microsoft Azure Cloud – Can it be trusted

Considering moving your Dynamics GP or Dynamics AX application to the Microsoft Azure Cloud platform but wondering if your data will be safe and meet your industry’s compliance requirements?

A great source of information on these topics is available at the Microsoft Azure Trust Center website ( This site is loaded with material on all aspects of security and privacy with regards to using the Azure Cloud product offering.  The website is broken into five major sections:

  1. Azure’s embedded security and privacy model: It all starts here. Building security into the product from the start as opposed to a bolt-on after the fact. Learn about Microsoft’s Security Development Lifecycle (SDL), Operational Security Assurance (OSA) process, and Privacy by Design in this section of the site.
  2. Security: Keeping your data safe: Security is not just simply encryption. It is also about processes and procedures such as threat management, mitigation, and penetration testing. What value is encrypted data if you can’t access it? Read about Microsoft’s approach in this section.
  3. Privacy: Own and control your data: Microsoft vigorously defends your right to privacy protection demonstrated by their recent win of a major case in the United States Court of Appeals. The ruling prevented the U.S. government from requiring Microsoft to give them access to emails held in a foreign country. Read about Microsoft’s approach and over 20 years of commitment to privacy in this comprehensive section on the subject.
  4. Transparency: Know how your data is stored, accessed and secured: Critics say that CLOUD stands for Cannot Locate Our Users Data.  Microsoft has done their homework with this platform and is ready to earn your trust in this regard.  This section of the site describes Microsoft’s policies and procedures with regards to where your data is stored and how it is secured.  Are you a Canadian company that requires all data to be stored within the country? Learn how to specify that your data remain in the new Toronto or Québec City data center.
  5. Compliance: Conforming to global standards: It is one thing for Microsoft to assert your data is safe and secure but your motto should always be “trust but verify”. This section of the site details the international and industry standards met by Azure and the third-party audits required to verify those standards. It has a very easy navigation tool to enable you to focus on compliance that is relevant to your industry. In the Healthcare industry? Select Healthcare in the drop down box and learn how Azure can meet HIPAA/HITECH requirements.

Still have questions or concerns about leveraging Azure for your Dynamics GP or AX environment?  Consultants with Tridea’s Cloud Business Services practice are available to help you find the right solution to meet your needs.