The functional and technical design process begins once the analysis phase has been completed. By now, the project plan is ready, the requirements document has been signed off, Conference Room Pilot (CRP) has been completed, and the Fit/Gap exercise has been completed and documented as part of the analysis phase. Now, it is time for the implementation team to document the overall solution and produce the functional and technical design documents.
The following diagram shows the deliverables and activities in the design phase of the implementation project:
In this chapter, we will learn about the following:
The functional design documentation is created after the requirements document has been signed off and the Fit/Gap analysis is completed in conjunction with the CRP. This documentation describes the features of the desired customizations. The document can include things such as flowcharts, screenshots, wire frames, and so on. At a minimum, an FDD will contain an organized list of requirements that can be used for development, testing, and client signoff.
Functional design documents help developers, testers, and customers to understand customizations in detail. The following are the key benefits of functional design documents:
- FDDs help the development team to understand the feature and provide a clear scope and definition of what to develop. Function design documents streamline the development process. The development team working on the feature has a clear understanding and answers to all their questions to start development. Since this document is approved by the customer, the developers are developing customizations which are approved.
- FDDs help the testing team to understand the feature under development and to develop a test plan around it.
- FDDs provide the customer with a clear vision and definition of the feature being developed.
- FDDs provide the baseline of the training documentation for the application support team and business users.
The Fit/Gap document is the primary input document to write the FDD. It is very important to review the Fit/Gap document in detail before starting with the FDD. The following are a few pointers to take note of when conducting a successful Fit/Gap review session:
- The Fit/Gap review session should involve the functional and technical solution architect, project manager, and customer subject matter experts (SMEs).
- It is important to remember that this is a Fit/Gap session, so Fit should also be analyzed. Any degree of customization identified in Fit should be recorded.
- Oftentimes, you find gaps listed that aren't really gaps as the solution can handle the requirement. The review session should discuss each requirement in detail and discuss all possible alternate solutions.
- All gaps should be recorded and assigned a unique number. The Microsoft LCS Business Modeler tool provides the ability to document your business process and record gaps.
- Take a detailed look at how the gaps are going to be addressed. Outline the testing/review process for customizations and how the testing will be administered.
- By focusing on these topics, you will soon learn where the team stands with regard to the appropriate documentation and its approach to the customization process.
The following are a few pointer for project managers, to consider during design phase of the project:
- Fit/Gap, requirements, and the project plan need to be signed off to start the functional design phase. You can break them up into areas and start early if you have specific areas signed off.
- Make the team put together the overall functional architecture and the flow-across applications; review with the respective stakeholders.
- Start with the functional design for areas on which the rest of the solution has a dependency. For example, customer, product masters, and so on are important for the downstream supply chain, invoicing processes, and others.
- Dedicate resources for large, complex functional areas early on.
- Divide responsibilities by area and try to have smaller FDDs created for each area. This would help manage them better.
- Assign developers and a QA team to each area at this stage. Engage them in reviewing the functional design and in supporting the respective business analysts early on (do not start the coding).
- You need to plan for multiple iterations and reviews. Functional designs are very crucial. Upfront reviews can save a lot of development hours and rework and will also increase the overall quality of the deliverables.
- Identify all cross-functional requirements; the solution architect should lead them to suitable designs.
- Cross-functional reviews are very important in larger projects. Have recurrent meetings every week/twice a week (as needed) to review the functional designs with all the functional team members together. Prioritize reviews for foundational items (such as customer master and product master changes) that would impact other functional areas.
- Cross-functional reviews will help to improve solutions (the rest of the team may have inputs on doing the same thing in a better way or with less customization). Also, more importantly, you will be forcing the team to review each other's designs by pulling them together into a room.
- Engage business SMEs early on for reviews (set up a design walkthrough, provide deadlines for getting feedback, and seek a signoff for each of the functional designs).
- Depending upon the complexity, involve SMEs ,external to project, for an independent review and recommendations. Their presence itself will fix more than 50 percent of the issues. For example, when you start auditing the financial results of the company, your accounting practices will automatically improve as people know that they are going to get audited.
FDDs speak the application language and terminology, so business analysts writing functional design documents must understand the Dynamics AX application and functionality. Lack of product knowledge and understanding can keep the documents at a high level, pushing the design aspects to the developers, which deviates from the purpose of the documents.
Microsoft Dynamics Sure Step provides good templates to write FDDs. Create your own version with the sections relevant to your project and have the team follow the template.
The following sections discuss topics of common features and frameworks that business analysts need to be familiar with, while designing the solutions.
Party relations are one of the most normalized tables, and it's important to understand relationships with the customers, vendors, and other entities. This impacts the modelling of solutions for important business entities. The following diagram shows this:
This is the repository of people and organizations and their relationships with each other—whether they are internal or external to the enterprise.
The relationship between legal entities, COA, financial dimensions, and journal entries is shown in the following diagram:
With AX 2012, Microsoft has normalized tables to a large extent. Understanding data models is important to designing the solutions. Reverse engineering tool in AOT is a good resource to visualize data and classes in Microsoft Dynamics AX by creating UML data models, UML object models, and ERX ER data models. More information on the Reverse engineering tool can be found on MSDN at https://msdn.microsoft.com/en-us/library/aa499193.aspx.
In this section, we will discuss the key features that can be used across modules and are important to understand as you work through the design phase.
- Database logging
- The database log is a feature that helps in auditing.
- It keeps track of the changes made by users. You can enable track on specific actions, such as insert, delete, and update. For updates, you can turn on tracking for specific fields.
- It keeps track of who created or modified the record and when. In case of updates, you can see the previous value and the new value.
- This is typically used in areas where audit tracking is required, such as credit limit updates.
- Standard Dynamics AX Reports are useful to review any changes made. Reporting on this data outside Dynamics AX can be challenging.
- If changes are made directly in SQL through updates, these will not be visible to Dynamics AX AOS and will not be available in the Database log. It is one of the many reasons why Dynamics AX data should not be directly modified in the SQL database.
- Document management
- The document management feature (also known as document handling) enables users to attach documents to a particular transaction or a master data record in Dynamics AX. It can be used to attach supporting documents, such as the invoice copy received from the vendor, purchase order quotes, contracts, and so on.
- Different document types can be created and configured to be used across solution areas. Normally, separate document types are created for use by departments as you can limit who can see notes by document type.
- You can save notes and print them on output documents, such as packing slip and invoices.
- The files that are attached can be viewed using the Attachment option on the Dynamics AX screens.
- There are multiple ways of implementing this feature for storage, such as database, file share, and SharePoint are commonly used.
- If you have sophisticated needs, such as workflows to save documents, additional security or virus scans prior to saving documents, or Optical Character Recognition (OCR), you can integrate with an external document management system; there are also several ISV solutions available in this area. These are especially useful for AP invoice automation.
- The files can also be controlled for maximum size or file types.
- Cues
- Cues are visual representations of select information on transactions and are typically displayed on the user's dashboard/Role Center.
- There are many purposes to use them and managing exceptions is amongst the top ones.
- The foundations of cues are filtered queries that give the statistical input to be displayed graphically.
- Cues can be created for different types, and some commonly used ones are count and sum.
- Examples of cues include showing the sum of pending invoices that are due as of today, count of overdue invoices, count of delayed orders, count of POs past due that can be used by buyers, and so on. Users can drill into individual transactions and use this as a task list to address them.
- Alerts
- Alerts are one of the most popular notification features in Microsoft Dynamics AX.
- They can be set up to trigger notifications delivered on the Dynamics AX client and/or an e-mail.
- The alerts work on a trigger concept and are set up in the select table.
- They can be used for entire record-level change notifications, including create, edit, and delete and can also be used for field-level change notifications.
- Alerts are not meant for broadcast use; hence, the notification is sent to one user only. If you want a specific team to be notified, team e-mail (e-mail distribution list in exchange) can be used.
- A batch job in the system administration module delivers the alerts (usually, it is set to run every minute). Alerts tables can get very huge; clean up batch jobs should be scheduled as well.
- Alerts need to be carefully set only for actionable events. Otherwise, users often run into too many alert situations and get ignored. Alerts set up to generate huge numbers of notifications may also impact system performance.
- Personalization
- Personalization is the feature to tailor-make the screen per user or group of users.
- While the user can make the screens morph the way it suits them and helps their productivity, these personalization changes do not impact other users or the underlying code base.
- Typical usage lies in rearranging the information on the Dynamics AX screen to best suit the purpose of the user.
- Do not use this feature when you want to make screen changes across the board for all users.
- While personalization is a powerful tool for users to use, personalization is lost when you clear usage data for the user (it is one of the first troubleshooting steps and may have to be performed).
- Batch jobs
- Batch jobs is an automated work that Dynamics AX is capable of.
- Any transaction that needs to be executed on the AOS server, and in a scheduled way, can be set up in a batch job. You can set up the frequency in terms of days, minutes, and hours. Batch jobs can have an end date or can be scheduled for only one occurrence.
- If you want to run batch jobs in a specific window, for example. every 15 minutes from 7 A.M. to 6 P.M., you may want to put such jobs on AOS Servers, which are batch servers, during a specific time window. These AOS Servers need to be defined as batch servers; set up 0 batch threads between 6 P.M. through 7 A.M. for the AOS server and the batch job will be set to run every 15 minutes during the window that you defined.
- Consider the deployment window while defining the batch job frequency. Make all the batch servers have zero threads between 9 P.M. and 10 P.M., and don't schedule long-running batch jobs just before 9 P.M. This will ensure that you easily put all the jobs on hold for the deployment.
- Performance scaling of volume-intensive transactions or actions to be performed periodically are typical uses of batch jobs, for example, invoicing shipped orders every 15 minutes, daily export of positive pay file, and inventory recalculation or close process.
- In batch jobs, tasks are created to perform the necessary actions, and these tasks can be multi-threaded to fully utilize the available resources.
- You can also create dependencies using batch groups. For example, when you want products to be imported, the pricing information is received from the Product Management system before you start importing.
- Other usage of batch jobs include workflow execution, alerts trigger checking, scheduling reports execution, and so on.
- Partitions
- Considerations for partitions to be used are important for global projects with multiple legal entities. The decision for partitions to be created needs to be made in the early part of the design phase.
- In the glossary for Microsoft Dynamics AX, the formal definition of a partition is given as a division of an application's processing into logical or functional parts.
- Partitions divide and isolate the business data of an installation using special processing that the AOS applies to data queries. This special processing occurs immediately before the queries are sent to the underlying Microsoft SQL Server database when a system field named Partition is present in a queried table.
- The purpose of a partition is to logically separate the data within its boundaries from the data in other partitions. A partition enables AOS to isolate the data in the partition from users who are not authorized to access the data. For example, a holding corporation might have several subsidiaries or other legal entities. An installation of Microsoft Dynamics AX for the corporation can have several partitions, perhaps one for each subsidiary.
- Each partition contains at least one company or legal entity. A legal entity occurs in only one partition. When you create a legal entity, the system assigns it to the current partition. The legal entity can never be moved to another partition.
- With the installation of AX, a default partition is created and the system administrators and developers can create more as per their need. Partitions were introduced in Dynamics AX 2012 R2. While migrating from the previous versions, partitions need to be assigned to legal entities as part of the upgrade process. Do not create multiple partitions when data needs to be shared across companies, for example, in the chart of accounts, vendors, customers, and products.
- Virtual company
- A virtual company allows you to specify a group of tables (table collection) that need to be shared among a group of companies. When users save information in one of those tables, the data is available to the other company accounts.
- A virtual company is a good functional feature. However, it is difficult to implement and can cause data inconsistencies. It should be avoided if at all possible.
- Ideally, you should make decisions to define virtual companies upfront in the design process. Defining a virtual company after you have input data in multiple companies is tricky and may cause data integrity issues.
- Virtual companies play a key role in implementations involving a high number of legal entities.
- Only use virtual companies to share setup and master data across companies. Do not use virtual companies for transactional data. Here is a practical example of virtual companies—an implementation that has 70-80 legal entities, that is, tables for maintaining payment terms, fixed asset groups, fixed asset posting profiles, value models, depreciation books, and journal names can be created in a virtual company to make creating and maintaining new legal entities much easier.
- Use a number sequence of the type shared if number sequences are needed for the shared data.
- Workflows
- Workflows are the mechanism by which business rules and approval processes are implemented in the solution. You can direct certain transactions for approvals using workflows. Some examples of documents for which built-in workflows can be set up are AP invoice journals, purchase requisitions, expense reports, budget planning processes, general journals, customer payments, free text invoices, and so on.
- Always keep the workflow implementation as simple as possible. Many organizations move from paper or manual approval processes into systematic workflows and come up with complex rules. It becomes difficult to build and maintain such workflows as organizational changes occur and eventually these workflows are abandoned.
- While implementing workflows, show delegation functions to the larger user community as part of training. It needs to become a part of their out-of-office/vacation checklist to define delegates for time-sensitive workflows.
- The usage of workflows includes:
Assigning a transaction for review
Assigning a transaction for approval
Automation of a business step
Conditional decisions on business data, which the next steps are dependent upon
Multiple level of approvals
Approval type selection, such as based on role, based on position and managerial hierarchy, and so on
Workflows can be delegated and/or escalated after a certain timeframe
Big picture diagrams convey the entire solution map and flow in a way that is difficult to express in words. The following are the suggested and sample big picture diagrams that should be built and maintained for Dynamics AX and all other applications that are a part of the solution. It also helps get new resources up to speed with the overall functional architecture of the solution.
Put together the functional architecture of all the systems involved in their business functions. Try to minimize the number of systems any specific group has to use for their day-to-day work:
A big picture for complete business functions in one page
- Do not repurpose fields to avoid customization. You will end up causing unforeseen issues down the road or block future use of the functionality related to the field.
- Do not use smart numbering: You will be limiting functionality and developing a lot of dependency on reporting, and the like, based on smart numbering. If you have used a smart number in the past, this is the perfect opportunity to fix it. For example, say you have product numbers such as XXX-YYY-ZZZ, where XXX represents the category, YYY is for the Manufacturer, and ZZZ represents the product number. You will be better off having the product number as just a number rather than building logic into the number itself. Instead, use three separate fields on the item master, which will help drive business processes and reporting based on these fields.
- Keep the architecture simple and easy to follow. The more complexity you add to the solution, the more difficult it will be to implement and support.
- Try to reduce duplication of data in multiple places; avoid unnecessary/complex integrations.
- Design solutions around standard functionality, without touching the core system. For example, say the customer wants to automate the creation of allocation journals based on the allocation rules defined in the general ledger module. As a functional consultant, I will design a separate customization that will extend the functionality of the core Dynamics AX allocation process rather than changing the standard AX forms and features.