Face-to-Face Consulting
We live in a digital world and remote work has become commonplace. Software consultants and developers can work remotely and many work out of their homes. However, is software consulting or training best done remotely or in person?
The answer to that depends on a lot of factors, but a strong argument can be made in favor of face-to-face consulting. The following work types we prefer to deliver in person:
1. Design - there is no substitute for seeing business processes, manufacturing processes, distribution processes and flows in person. One would be hard-pressed to design a solution without the understanding of the actual physical scene and what occurs. Setting up a warehouse efficiently would be impossible without seeing the spaces, bins, racks and flow throughout the warehouse. Additionally, one meets the key players in the organization and begins to build a rapport with them. This helps smooth over any eventual bumps in the implementation which are sure to occur.
2. Training - while training can be conducted remotely succesfully and we have done so in the past, we prefer to deliver training in person. When training in person, one can see the student’s facial expressions and know if they are grasping the subject or are confused. Students can ask questions and get their questions answered on the spot. One can observe the room and assist students as needed. This is very difficult to do over a Zoom meeting even with video and audio.
3. Go-Live - When we go live with new software, our resources are on the ground. A well-trained professional brings calm to the environment and this is needed during a new software rollout. Issues will occur, employees will forget their training, situations no one thought of will occur. A pro will be able to quickly resolve issues and instill confidence in the users.
Technology is wonderful and it is tempting to dive deep into the latest and greatest communication wizardry, but let us not neglect the tried and true, face-to-face communication. It’s worked for as long as humans have been around and will cotinue working in the future. It is a superior way.
Business Central Productivity Tips and Tricks
Here are some of our favorite tricks and tips, shortcuts and productivity enhancments in Business Central.
1. Return to your home role center - Click your company name in the top left corner.
2. Use more than one monitor. If you never tried this, it is a game changer. You can run Business Central in multiple tabs on your browser and drag and drop the tabs onto multiple monitors.
3. Switching environments/companies - near the top left part of the page, you will see “Environment Sandbox” or “Environment Production”. Click on this to quickly switch between environments and/or companies.
4. If you use lot or serial numbers - Press CTRL-Shift-i to quickly get into the Item Tracking page.
5. Copy data from cell from the row above - Press F8.
6. Tired of deep menu trees? - you can personalize your page and drag and drop your commonly used functions higher up on the menu tree.
7. Forget to enter fields on certain pages? - Personalize your page and move the field to a more useful position. You can move fields on both card and list pages.
8. Don’t like second level menu row disappearing? - After clicking on a top row menu item, click the push pin icon to the far right. This will prevent second level menu from disappearing.
9. Bookmark all of your commonly used pages by clicking the bookmark icon near the top right portion of the page. They will then show up on your home role center as menu items and are easily accessible.
10. Edit in Excel - if you want to mass update data, you can do so in Excel and publish the results back into BC. On a list page, click the icon that looks like an open box with an arrow pointing to the right in the upper right side of the page, then click Edit in Excel. You may also set filters before editing in Excel. Your data will load in Excel and you can make your changes. Click Publish to publish your changes back to BC. Recommended for advanced users.
Go Live Checklist
A Go live checklist is key to a successful go live. One would not fly a plane without one and one should not take an ERP system live without one!
A Go live checklist can be started at the beginning of the project and added to as the project progresses. This will ensure important tasks are not forgotten. Every project will have different tasks, but there will be some that are consistent with every project. These may include:
· Cutting off the old system
· Verifying set ups
· Verifying data conversions
· Ensuring users and security are set up
· Ensuring users can access the production environment.
· Printing out key reports such as aged accounts receivable, payable and inventory valuations and comparing against source data.
One should make a list of all key items and check them off once completed. One will not likely consider of every requirement while going through the stress of go live without such a checklist considered well in advance.
Business Central SaaS and Defaulting Printers
In Business Central SaaS, it is not so easy to set a report to print to a default printer as it was on on-premise versions. If one goes to Printer Selections and attempt to look up available printers, you will not see any network or local printers.
In order to do this, you will need to utilize a cloud service such as Microsoft Universal Print. However in this article, we are highlighting a product called "PrintNode".
PrintNode is very easy to install and configure and you may find the pricing very competitive. You can write your own API (they have good documentation) or you can utilize one from various third parties which already talk to Business Central.
Another benefit is it has scale integration to both HID and old COM port scales. PrintNode supports a wide variety of makes and models and will even add your model of scale if it is not on the list.
Three ways to Deploy Business Central
There are three different ways that Business Central can be deployed. We’ll cover each way and their pros and cons.
1) SaaS (Software as a service) - there is no software to install, no servers needed and is the easiest way to deploy Business Central. You are subscribing to a service. Backups are automatically made and automatic updates are rolled out periodically. The biggest benefit is you never have to perform a costly upgrade as updates are made automatically. If you do not want your data in the cloud, then this is not the method for you. Automatic updates have the potential of causing an issue, though this is rare. You also have very little ability to manage the environment as this is controlled by Microsoft. Since the software is on the cloud, if there is an internet outage, it may impact your ability to use the software.
2) Private cloud - you may purchase or subscribe to a Business Central license. The software would be installed on cloud server(s) as Azure to host Business Central. You will need Windows server along with SQL server and a web server. In this case, you can maintain the environment and have full control over it. This will be more costly than SaaS, as you will need to subscribe to multiple services and purchase licenses in addition to Business Central. You are responsible for backups and you may apply updates as you wish.
3) On Premise - you may purchase or subscribe to a Business Central license. In this case, the software is installed on your physical servers. You will need Windows server along with SQL server and a web server. You have full control over the environment. This will be more costly than SaaS, as you will need to subscribe to multiple services and purchase licenses in addition to Business Central. You are responsible for backups and you may apply updates as you wish. This method is ideal when you absolutely do not want your data on the cloud.
Your requirements will determine the best method. Seamless updates, automatic backups and no servers to worry about makes SaaS the ideal option for most.
Extending Business Central Functionality
In Business Central, an “Extension” extends the functionality of the core ERP software. Most ERP systems today handle the core business functionality such as accounting, sales, purchasing, inventory, manufacturing, etc. Solution providers such as ourselves will often extend the functionality by adding features or business specific rules to the software to meet specific business requirements. This could be as simple as formatting an invoice layout slightly or as complex as handling a robust commission structure.
Additionally, third party companies called ISV’s (Independent Software Vendors) may create their own extensions and provide them for sale on the “Extension Marketplace” where they can be installed directly into your sandbox environment, tested and rolled out to production.
The term “extension” is appropriate since it does not touch nor modify Business Central’s core software. Extensions can be easily installed or uninstalled. Yet, when an extension is installed, it is now a seamless part of Business Central. It is not a bolt on, nor does it require additional integration.
When Microsoft releases updates they are only updating their core product. Your extensions will automatically apply to the new release. Occasionally, Microsoft will make technology changes which may require an extension to be updated. Microsoft alerts partners to any potential issues so that they may be addressed prior to applying an update.
Your solution provider can help you choose the extensions that will best fit your needs or create extensions.
Business Central Cloud Gives Peace of Mind
Business Central SaaS (software as a service) is now easier than ever to implement. To spin up a sandbox and production environment is just a matter of a few clicks. One no longer has to concern oneself with server requirements, pre-requisite software, and backups since this is all taken care of by Microsoft.
Service packs, updates, and new releases are automatically installed while preserving customizations. This has worked reliably and consistently for all of our clients to date.
Business Central is easier than ever to configure. The user interface is intuitive and continues to improve over time as Microsoft releases new updates. All of this translates to lower implement costs for you the customer.
Customers and partners can request and vote on suggested improvements here. This gives you a say in how the software evolves and what it does. Microsoft does a great job in listening and carrying out these requests.
From a development side, we are able to customize the product to suit your business needs, whether it is a simple formatting change on an invoice or specific business rules.
Contact us today for more information.
What is Business Central?
Wow, it has been a couple of years since I wrote a blog! We’ve been quite busy delivering projects and services for Business Central and Microsoft Dynamics NAV and our business has grown organically over these very fast four years. Anyhow, let’s get on with the topic at hand!
Microsoft Dynamics NAV is a well-known ERP system which has been around for years and years. It has gone through many versions, the latest being NAV 2016, NAV 2017 and NAV 2018.
In April, 2018, Microsoft released Business Central. This is a replacement for NAV. No further NAV versions would be created and so NAV 2018 is the last version of NAV that will ever exist.
Basically, Microsoft renamed Microsoft Dynamics NAV to Microsoft Dynamics 365 Business Central. Now that is a mouthful, so we just called it “Business Central”.
Business Central does not have version numbers, per say, but is just referred to with release dates, such as the “April 2019 Release” or the “Oct 2019 Release” and so on.
Microsoft aggressively updates the product with monthly service packs (fixes mainly) and bi-annual updates).
One of the advantages of Business Central is the flexibility in licensing and deploying it. Here’s the breakdown:
Business Central can be licensed in several ways:
1) Perpetual licensing - one time purchase plus annual maintenance fee for the rights to service packs and upgrades.
2) Subscription licensing - lease the software and pay on a quarterly or annual basis.
Business Central can be deployed in several ways:
1) On-premise
2) Private cloud - this could be any cloud provider of your choice.
3) Microsoft Cloud (SaaS) - on the Microsoft cloud you will receive automatic updates.
There are pros and cons to each deployment method which I will cover in a another blog. It’s good to be blogging again, it is something I enjoy and shouldn’t neglect for so long. Look forward to seeing you at the next one.
Cloudy with a Chance of ERP?
The weather forecast today is cloudy with a 85% chance of ERP. Yes, here I go again, "borrowing from a movie title", but I can't help myself - my nine-year old son loves the movie and that's the end of that.
Should you run your business in the cloud? You probably are already to some degree and almost daily, a new cloud solution materializes in the ether. We are becoming more dependent on cloud-based services - banking, word processing, spreadsheets, payroll services, on-line tools and so on. ERP is undergoing the same evolution, though it has unique challenges. It is not a question of if, but when.
Microsoft Dynamics NAV is rapidly evolving and users are successfully running NAV in the cloud and with the release of Dynamics 365, Microsoft is clearly stating its intentions - cloud ERP is where we're going.
The main problem that needs to be solved is customization, though Microsoft is making great strides in this area. Customization may be a "feared" word with negative connotation, but I'm not one to mince words. Businesses are unique and therefore customization is often necessary to support a business in running efficiently. Being able to customize the software and at the same time receive automated updates and upgrades is the end-goal.
One school of thought states to change your business to satisfy the software. Wrong-headed approach in my humble opinion. Structure does not monitor function. Function monitors structure. In other words, your customers and your ability to satisfy your customer's needs are paramount. Everything else should be aligned in that direction.
Microsoft's latest release, NAV 2017 has some compelling features, leveraging Office 365. The In-Office 365 experience is a magical one. Here's a scenario - a salesperson receives an email from a new contact. Without ever having to leave Outlook, a contact is created and a Sales Quote is created and emailed using NAV in Outlook. Another scenario - your accounting department receives an email requesting a copy of an invoice. Within Outlook, with a single click, the invoice pops in view and is then sent to the customer by email. This is a game changer in increasing efficiency. Switching software and searching for documents takes time and this all but eliminates that time.
Microsoft Dynamics NAV has never been so cloud-enabled with deep Office 365 integration, improved Web client and continued improvements in supporting customizations without affecting the base product. Add to this the already excellent native phone and tablet apps for Android and iOS.
Embrace the cloud, but be smart about it. Research it and find a trusted partner who can advise you and steer you away from any pitfalls. There are many companies providing cloud hosting services, some are poor, many are mediocre and a very, very few are stellar. This can make all the difference in the world as you want your ERP experience to be fast, reliable and efficient. A lot of things need to come together properly to make this a reality.
Microsoft Dynamics NAV 2016 Top Ten Product Highlights
Having implemented our company internally on NAV 2016 and wrapping up a good sized NAV 2016 implementation from start to finish, we have a few opinions to share. NAV 2016 is by far, the best version of NAV to date, as it should be. Microsoft has put a lot of hard work into the product and it shows. Here are our top ten product highlights: (note: some of these features may have been introduced prior to NAV 2016.)
With proper hardware and configuration, NAV 2016 is snappy and responsive and is likely the fastest version-to-date.
The NAV tablet and phone apps work great and configuring screens is a snap.
End-users can configure Orders, Invoices and the like using Microsoft Word. This works quite well and users are easily trained on how to do this.
Bank reconciliations are very easy to perform. It is basically a matching game and nearly as fun as playing Tetris.
Security has always been a time consuming and cumbersome process to set up in the past. Not so in NAV 2016. Security can now be quickly and easily set up.
Company management – creating and copying companies has never been easier.
Improved integration with Excel, Word and Acrobat has markedly enhanced the user experience.
The development environment is the best-to-date. The development environment auto-predicts while you type, assisting the developer in writing code. It is almost as good as having the code written for you!
The upgrade tools continue to impress. The tools do an excellent job of merging customizations and converting data and run very quickly.
A huge technological leap was the addition of Events. This allows developers to make code changes in such a way so that the impact of the customizations on upgrades is dramatically reduced.
What to Avoid:
Don’t recommend the use of Extensions at this time. (Allows for non-code modifications to be loaded at run-time). In testing, we were able to corrupt the database and had to restore from backup. We’ve noticed a number of patches to this area in cumulative updates.
Don’t bother installing every cumulative update. They are released monthly and is far too often to be upgrading a production system.
Improving ERP Implementations - Part Two
In the last blog in this series, we covered some of the key areas in selecting the right ERP product. In this second part, we will discuss the implementation methodology. The first question to take up is “Why should you care what implementation methodology your ERP partner uses? Isn’t that their business?” After all, you may be shelling out a small fortune to have your ERP system implemented, so it should be akin to getting your car serviced or a room added onto your house. Sit back, relax and enjoy as your ERP system is implemented for you.
If only it were that easy. Successfully implementing an ERP system requires tight collaboration between the customer and implementing partner and it takes a lot of hard, dedicated effort on both sides. The relationship could be better envisioned as a partnership rather than strictly a client-vendor arrangement.
Consider a few of the key areas where your involvement is absolutely necessary:
- Requirements meetings
- Ensuring your business processes and requirements are communicated effectively to your implementation partner
- Providing data from legacy systems
- Obtaining data from third parties (Banks, other IT systems)
- Coordination, scheduling and management of internal project resources
- Attending training sessions
Not only that, you already have a full-time job! The implementation methodology used may impact not only the quality of the implementation, but your daily work-life for an extended period of time, and so should be given due consideration.
The two major implementation methodologies in use are:
- Waterfall
- Agile
Waterfall – the project is carried out logically in a series of steps. Once one step is completed, the next is taken up and so on. For example:
- Design requirements meetings are held
- Design specifications are written
- Design specifications are approved
- Configuration
- Data conversion
- Development (customization)
- User Acceptance Testing
- Training
- Final Data Conversion
- Go-Live
This is logical and fine and works well in smaller, simple implementations, where there is little to no customization. It also works fine for industry-specific software systems which very closely fits your business requirements. It is also fine for straight-forward cloud based software systems which are not customizable. It is not the best choice for complex ERP implementations as we shall soon see.
Agile – simply put, it is an incremental and iterative approach to product development. Work is delivered in periodic segments of time called “sprints”. For example, a sprint may be defined as two weeks. At the end of the sprint, it is expected that the work is functional and complete. From this, new feedback and understandings arise and the next sprint begins. Thus, each sprint takes the project closer to the end goal. The process is highly adaptable and anticipates and embraces change. Therefore, the term “agile” is well-chosen! Agile requires tight communication between customer and implementing partner and indeed, daily communication is one of its key benefits.
So, we can see if we are implementing a simple ERP system with little or no customization, Agile doesn’t make sense. Agile is for product development and we are not doing any development! If you are implementing an industry specific auto-repair shop system, you will simply use it out-of-the box and Agile doesn’t fit at all! A simple cloud-based payroll system - just plug in your employee data and start using it. Agile not required!
However, in a complex ERP implementation with customization, heavy data conversion, integration with third party systems, and so forth, development is required and Agile is ideal. Agile is best when complex requirements are not fully known up-front. At the outset of a project, the customer knows the least about the ERP system and the implementing partner knows the least about the customer’s business. The likelihood of writing a complete, and correct design specification as the first action in the project is low. Agile allows team members to adapt to change, new revelations come to light and feedback is used to improve to product.
There are several methodologies which fall under agile (Scrum, Extreme Programming, Crystal, are a few).
Agile is best for large, complex ERP implementations. Case closed. Whoa there! It may very well be, but it must be applied intelligently. Agile was originally developed for software product development. For example, a company creating an ERP software product. Therefore, its processes are internal to the company developing the product and not customer facing. An ERP implementation is customer-facing. The communication gap between the customer and implementing partner must be bridged as the customer will very definitely be involved.
With Agile, budget and timeline may be difficult to predict as a full design specification is not typically written up-front. Moreover, specifications and documentation are not highly-valued items in agile. Because change is embraced by Agile, the scope of the project may increase significantly and the budget blown. Moreover, with Agile, work is often estimated using obscure, arbitrary values which doesn’t translate well to real-world costs.
The bottom line is Agile must be adapted for ERP projects in an intelligent and thoughtful manner. Reading and following a book on Agile and applying the concepts strictly to an ERP project is inviting disaster!
So, if you are going to implement ERP using an Agile implementation methodology, the following guidelines may be of use:
The implementing partner must ensure customer team members understand Agile concepts and terminology. This is the biggest initial barrier to success. The customer team and implementation team must understand the concepts and terminology to be used in the implementation process. The good news is there is probably only a dozen or so common Agile terms that need to be understood.
Initial design meetings to create the initial product requirements list is highly recommended. Work should be estimated in terms the customer can understand which easily translates to dollars. This is likely, the good old faithful, hour. This gives you somewhere to start and will eliminate unnecessary and excessive change downstream provided the designer is competent and has a thorough and deep understanding of the ERP system being implemented. There is absolutely no substitute for this.
Ideally, the implementing partner has worked out all the kinks out of the Agile process and has adapted it for ERP projects. The biggest issue you may face with Agile is scope creep – the project scope expanding over budget, so both parties must keep a constant eye on this and use reporting metrics to predict and control the budget.
Use judgement when utilizing agile principles. Common sense and practicality override agile theory and principles.
Have fun. Implementing ERP Projects using agile can and should be a fun and rewarding affair.
Improving ERP Implemenations - Part One
ERP implementations often fall short of desired expectations. Indeed, the past-experience of an ERP implementation can leave a permanent mental scar of those involved, so much so that a new ERP implementation becomes a rather daunting and un-confrontable affair.
However, ERP implementations can be a positive experience from start to finish, with any minor bumps smoothed out by a strong partnership with those involved and backed with strong executive sponsorship. But let's cut to the chase, what can be done to ensure an implementation is successful?
Rather than attempting to address this broad topic in a single blog, we'll take this up in multiple parts. This will be part one of a series of blogs.
The first aspect of the ERP implementation is the software itself. Potential customers evaluating ERP software will review several products and will do its best to select the best possible product for the company.
The organization selling the product will naturally do its very best to sell the product. If the selling organization conducts itself ethically, it will not sell its products to a customer in which the product does not fit well with the potential customer's business or budget.
This is sometimes where trouble begins. In this case, the seller pushes the wrong product on the customer and the customer accepts the product. Although it may be possible to customize the product to fit the customer, the budget to do so is well outside the customer's reach. Nevertheless, the product is sold and implementation attempted and fails. Both parties lose.
One can avoid this major misstep by doing internal preparation for the demos, by selecting key personnel to represent the various departments of the company and having them determine how the software addresses their needs. This data can then be assembled and comparisons between products can be analyzed. Don't be swayed by salesmanship or promises, look at the data and evaluate based on the facts and the facts alone.
Find out what the system does out of the box, what requires customization, and approximately how much those customizations would cost. The selling organization may use terminology such as "configuration" and avoid the term "customization". It would be best to clarify these terms with the selling organization.
Configuration could be defined as something that can be accomplished by setting pre-built options within the software itself and requires absolutely no programming or modifying of source code. An example would be configuring a built-in approval system to approve purchase orders based on various dollar thresholds.
Customization could be defined as something that requires programming or source code changes to accomplish. Typically, customization takes longer than configuration and the cost is higher, sometimes significantly so.
In some cases, the software is not customizable at all or very difficult and expensive to, and you are expected to live with the functionality as-is. In this case, you are forced to modify your business processes to fit the software. This is not always possible and an important distinction and must be understood.
Another area that is worth delving into is third party add-on software. Be sure to clarify what functionality is standard and what is being provided by third-party vendors. ERP products, although rich in features and scope, typically do not do everything a potential customer needs and this is where third-party developed products can fill in the gaps.
The third-party products may be written in the native language of the ERP system itself or may be a completely standalone product interfaced with the ERP system. What is the track record of the third-party vendor? How many successful implementations have there been? How do upgrades affect the third party software? Who will be implementing the third-party software? Get references on the third party vendors/products as well as the ERP system.
Find out what implementation process the selling organization uses. Is it waterfall or agile? This will be covered in a future blog as this is an important topic. But for a few quick definitions: Waterfall is a traditional approach to project management where one step in the project follows after another in sequence. Agile is a cyclical approach to projects in which the delivery of the product occurs incrementally in predefined regular periods of time called 'sprints'.
How is the product deployed? Is the product installed on-premise or it is hosted in the cloud? You may not want your data exposed on the cloud or you may desire ERP hosted in the cloud. Many ERP products offer both options and some are cloud-only. You'll have to determine the best option for you.
Finally, ensure you get a detailed estimate of the software and implementation. Do not accept a general estimate which is just a range of service hours or dollar amounts. A detailed software estimate should include no. of users, software modules, third-party modules and recurring fees. A detailed service estimate should include design, configuration, customization, training, data conversion, user acceptance testing and support for the go live, at the very minimum.
This is by no means a full primer on how to select ERP software, but may give you some insights and things to look out for.
NAV Reporting Writing 101 - where to get your data
When one is new to report writing in Microsoft Dynamics NAV, one may wonder what tables to pull data from. There's a bountiful number of tables in NAV and so meandering through the list can be daunting. Here's my shortlist of favorite tables to pull data from when reporting:
17 G/L Entry - this is the table for pulling general ledger data.
21 Cust. Ledger Entry - this table stores invoices, credit memos, payments, etc. for customers. It does not contain line item detail. The aged accounts receivable report utilizes this table and several standard sales reports by customer pull from this table. Good for pulling overall sales data by customer which could include items, G/L accounts, fixed assets and resources. Although it contains fields for Profit, it is not reliable for profit data related to items. See 'Item Ledger Entry' below for more details.
25 Vendor Ledger Entry - this table is similar to the Cust. Ledger Entry, but is for vendors. It is utilized by the aged accounts payable report and several standard purchasing reports by vendor pull from this table.
32 Item Ledger Entry - this table stores all item related transactions (purchases, sales, adjustments, credits, etc.). It is quite versatile as inventory, sales and purchasing reports can be written using this table. It stores the customer/vendor no. as well, so it can be used to create sales/purchasing reports by customer/vendor. Note that it will not contain sales and purchase transactions related to G/L accounts, resources, or fixed assets. Therefore, if you compare sales reports that drive off the customer ledger vs. the item ledger, you will likely not get the same results. Table 5802 Value Entry is related to the Item Ledger and is useful when more detail is needed particularly relating to costs.
The Item Ledger is also affected by the Adjust Cost - Item Entries* process, so is the recommended table for getting the most accurate item cost and profit data vs. relying on the Profit fields in the Cust. Ledger Entry.
Tables I do not recommend writing reports where item costs or margins are important include:
113 Sale Invoice Line, 115 Sales Cr.Memo Line, 123 Purch. Inv. Line, 125 Purch. Cr.Memo Line
This is for two reasons: 1) you have to read two tables to get the full picture (e.g. invoice and cr.memo lines) 2) More importantly, they are not updated by the Adjust Cost - Item Entries process so it will not contain the most accurate item costing data.
Happy report writing!
*Adjust Cost - Item Entries process - this process is recommended to be run on a daily basis if you have inventory. This MSDN link describes this process in detail.
Functionality, Usability, User Experience and Software Releases
I have been recently immersed in the joys of software design and development. Namely, I took on what seemed like a simple task - modify Microsoft Dynamics NAV to automatically post batches of sales invoices and email them. Sounds innocent enough and NAV already has a function to post and email a single invoice, so it should be a simple task, or so I thought. As I designed and developed the solution, I realized I have been for some time operating in a particular cycle and that cycle carried out fully will inevitably lead to superior solutions and stopping short will lead to less optimum solutions. The cycle apparently is:
1) Functionality
2) Usability
3) User Experience
By functionality, I am referring to completing a basic particular function. In this case, batch posting and emailing a set of invoices. Ok, that is simple enough. Loop through each invoice post it and send out an email with the invoice attached.
However, NAV by default, always reuses the last email body text when sending emails making automation of emails unusable. So, this needed addressing. Here, the cycle repeated again - Functionality was lacking, so new functionality had to be developed to allow customers to have their own unique email body text for each type of document (quotes, orders, invoices, etc.)
Once the basic functionality was complete, the usability had to be addressed. In order to make the software more usable, it is desirable to allow users to make changes to the email body text on the fly prior to sending out invoices and giving them an option to save it. Now the modification was functional and usable.
Now the user experience could be addressed. How can the modification be easily used by the user? Adding error trapping, messages and convenient buttons to access the functionality rounds out the modification and markedly improves the user experience.
We now have the ability to set up default emails by customer. It is easy to use and intuitive. The screens display just what the user needs and no more. The interface is clean and aesthetic. Now we can continue where we left off and address the usability of the batch posting and sending of invoices.
Batch posting is now functional - emailing and sending invoices has been accomplished. However, the user is prompted twice for each invoice. Clicking two times for each invoice is not very usable, so this is addressed. The user is given an option whether to review each invoice before it is emailed. Now the user can automatically post and email all invoices in the background or review each one individually. Usability has been achieved.
The user experience can now be addressed. Adding buttons to post batch and send are added to the sales invoice list and sales invoice page. Error trapping and messages are added. The modification is now functional, usable and the user experience is excellent.
You can probably think of a dozen products, software or otherwise, which are merely functional. Take a garden variety computer mouse. It points and clicks, but tracks roughly on reflective surfaces. It has earned the status of functional. But functional is merely okay. Design into the mouse, smooth tracking across a great variety of surfaces and a satisfying click and now we have something more usable. Design into the mouse comfortable ergonomics, an aesthetic modern profile and now we have addressed the user experience.
The cycle of functionality, usability and user experience can and should be addressed during design. However, there is no escaping the fact that part of cycle will be iterative regardless of how much forethought is put into design. This is because one cannot always predict the outcome until it is actually seen and experienced.
Now back to the world of software. Far too often, I see software or functionality released which is merely functional as an effort to "get it out there". In my opinion, this is shortsighted. Greatness does not often result from "getting it out there". It comes from completing the cycle of functionality, usability and user experience. Regardless of methodology - waterfall, agile, etc., taking each and every function or product through the cycle to a shining, brilliant full user-experience is a standard well worth achieving.
Microsoft Dynamics NAV Design Evolution
Designing and developing a Professional Services vertical for Microsoft Dynamics NAV has been an experience. There were days of joy when a function worked just right and there were days of frustration when a piece of code simply refused to behave, but I soon came to realize that each day was simply another evolution. The product was evolving day-by-day, steered by obsession over quality, user-friendliness and efficiency. Because I was using the product to run my business, I became intimately aware of the user as I was the user and that has to be the prime element of sound software design - one has to put oneself in the shoes of the user while designing and developing.
There is much to be improved and simplified in Microsoft Dynamics NAV from a user's point of view in order to bring about the goals of efficiency, ease-of-use and user-friendliness. In no particular order, here are my thoughts on design evolution as it relates to Microsoft Dynamics NAV, though many of these points apply to software design in general and can be applied at any time through thoughtful design and development.
1. Automate activities that burden the user when there is really no reason to involve the user:
- Posting Warehouse Item Journal should also update Item Ledger rather than having user run a separate Item Journal, Calculating and Posting.
- When time sheets are posted, automatically integrate to the job ledger rather than having user a run a separate Job Journal, Suggest Lines function.
- Automate inter-company posting so that users do not have to monkey with inboxes and outboxes.
2. Greatly reduce the chance of data errors or omissions, by enforcing mandatory fields during master record set up (e.g. customers, vendors, items, pricing, etc.). The mandatory fields should be configurable by an admin not a developer!
3. Always give the user a message indicating if a process was successful, failed or was aborted. This should be a commandment!
4. Make warning and error messages user friendly in plain terms with suggested corrective actions where possible. I would like to see the message 'The update has been interrupted to respect the warning" permanently stricken from the database and replaced with a simple, "Operation aborted".
5. Hide, by default, all fields that are not likely to be used by the intended audience. Let's take the North American database for instance. The General Journal should be simple, but it is not! Hide the Gen. Posting Type, Gen. Bus and Gen. Prod. Posting Groups! Show the Debit and Credit Amount fields. Extra fields = Extra Clutter = Not User Friendly = Not efficient.
6. The opposite to 5 is just as important. Show, by default, all fields that are likely to be used by the intended audience. The Time Sheet approval screens are an extreme example of this. Out of the box, they are essentially useless if you are using resource numbers or job numbers. You cannot see the names of the resources or the names of the jobs that you are approving time for. Many default screens simply do not show, by default, necessary data that is needed by the end user. This sometimes requires developers to get involved, increases cost of the implementation and reduces efficiency.
7. Eliminate multiple tree selections. E.g. clicking Order, Drop Shipments, Purchase Order on the Sales Order is time consuming and cumbersome. Selections should be a one-button press or at most a two-level tree.
8. Make setting up master records easier. Setting up Customers and Vendors require users to select Posting Groups. Take the concept from the Item Card Category Code which defaults Posting Groups and other key fields and pay it forward!
9. Obsessively reduce keystrokes and clicks. My mantra is "Three clicks is painful, two is sufferable, one is good and zero is best!"
10. Make the interface intuitive, easy-to-use and fun! Fun and ERP software may be polar opposites, but it does not have to be that way!
11. This brings me to the long and short of it- you have to know your audience to design software for your audience. For example, I have not yet met an accountant who wants to see anything but the Vendor Name in the description in the General Ledger for payments to vendors, yet the NA version of NAV still to this day, uses a description that is of no use to accountants.
Professsional Services Powertrain Feature Comparison
We've just released our feature comparison chart so you can see at-a-glance some of the differences between our Professional Services Powertrain solution vs. the standard NAV 2016 product. You can download by clicking below:
Professional Services Powertrain Feature Comparison Chart
Introducing Professional Services Powertrain for Microsoft Dynamics NAV
ERP Efficiency Experts is proud to announce the release of our Professional Services Powertrain module for Microsoft Dynamics NAV! This landmark release fulfills a strong need in the professional services space. We not only leveraged the core functionality of one of the most powerful ERP systems available- we have literally transformed the product so it works seamlessly, effortlessly and powerfully for the professional service industry. And that is just the beginning. When designing the solution, we had several key concepts in mind:
Efficiency - the product is designed to enable users to increase their efficiency. Time entry is a simple intuitive affair. Approving time and invoicing and is a snap. The workflow has been meticulously streamlined and automated where possible. We are after all the "ERP Efficiency Experts" and our product lives up to our name!
Ease-of-use - we have simplified the user-interface so the product is intuitive and actually fun to use. The user is only presented data that is relevant to that users role. Correcting mistakes, such as crediting a project related invoice is no longer a chore.
Inexpensive - Relatively speaking, ERP implementations can be quite costly and often costs much more than anticipated. Our solution is orders of magnitudes less costly than traditional ERP implementations. This is because our product is pre-configured for the Professional Services industry. You can literally start plugging in your data and with a little training be on your way!
Contact us today to arrange a demo! 888-512-3195
Click to Download Brochure
Programming vs. Accounting - Rocky XII
No, I am not riding on the coattails of the recent release of Stallone's latest movie 'Creed' like I so unabashedly did with my blog on Star Wars and ERP Implementations. I will make no references to Rocky Balboa or Apollo Creed here and I will not conjecture on who would be the better developer.
With that said, programming solutions can conflict with accounting best practices and it can seem like a slugfest. But should one always "program" oneself out of an accounting problem?
Here's a common scenario. A transaction in Microsoft Dynamics NAV was posted with an incorrect date. A programming solution would be to go into the backend and correct the dates of all the related posted entries. Yes, it should work- but should the problem be solved in that manner?
From an accountants point of view, no. There is no audit trail by going into the backend and changing data. Additionally, it is risky even when one is confident of one's knowledge of the system involved.
Moreover, the users of the system may become dependent on a programmer's ability to make a quick fix and request future data entry errors to be corrected in such a manner. The correct way to solve this is to enter a correcting transaction to reverse out the original transaction and re-enter the new transaction.
What if 1000 transactions were posted with incorrect posting dates and it will likely take two personnel a full week to reverse and correct the transactions? In this case a programmer could come in handy, but how the problem is solved is key.
One could write a process to change all the posting dates of all the transactions involved. However, this has its risks depending on the system and transactions involved as it bypasses the normal validation of data. One should instead write a process which creates the reversing and correcting transactions as if the user had entered them. Thus a full audit trail is maintained. The programming solution "simulates" a user entering the transactions by hand and therefore, follows best practice.
There can be exceptions. For instance, 1000 orders were posted with a Text field incorrectly populated. It is 100% certain that the text field is not tied to any logic within the system and is purely informational. In this case, a programming solution to update the posted data directly is of no real risk.
Judgement is required, then to determine when a programming solution should be undertaken or not. In the majority of cases. if an issue can be solved by entering transactions, that will be the ideal solution.
Designing Microsoft Dynamics NAV Implementations - Part 2
The last blog on this topic covered pre-design activities. We'll pick up from where we left off and cover the design process itself. There are probably a number of ways to carry out design, so this is one potential methodology.
The design process roughly consists of:
1) Design requirements meetings
2) Analyzing the notes from the meetings.
3) Designing solutions and translating the concepts into functional and technical specifications.
4) Reviewing the specifications with the client, updating them until full agreement is reached.
We'll cover each step independently:
Design Requirements Meetings
A good way to structure meetings is to keep the number of attendees reasonable and to break them into 2-3 hour sessions. Schedule breaks. The designer should have ready access to NAV to be able to demonstrate out-of-the-box functionality. The client should have ready access to the legacy system to demonstrate current functionality.
It is vital to use a written guideline to drive the meetings. An agenda is only a start. A functional design template is best which is pre-written and covers all the topics that will be covered in the design with key data pre-populated in the template. Without a design template, it will be far to easy to "forget" to mention an important detail, get side-tracked and lose focus. The written guideline should be included as one of the pre-design activities. The design template should be tailored for the client prior to the meetings. Note any gaps between the standard product and client requirements and any pre-sales data gleaned from prior meetings.
With the pre-design activities in place - 1) Client has agreed-upon a design approach, 2) Client understands their internal processes, and 3) Client has been trained, the client is now in a position where design collaboration can be most effective.
The meeting starts with the process of the area being designed. For example, sales order entry. Review the as-is process and to-be process diagrams if you have them. Otherwise, you will need to capture, but not necessarily diagram these, during the meetings.
Have the client demonstrate their functionality. In this case, how to enter an order. Note any gaps. Demonstrate the same functionality in NAV. Note any gaps and get the requirements for the gaps. For example, the legacy order entry screen contains fields that are not in NAV. How are they used? it turns out they print out on the invoice and is required by certain customers in order to pay the invoices.
The designer notices the pricing in the legacy system operates quite differently than NAV. This was not brought up in the RFP stage or in any of the demos. NAV picks the lowest price available while the customer's system picks prices in a set hierarchical pattern. This is non-negotiable as prices are contracted with customers and therefore NAV requires customization. The designer asks questions until and notes the requirements down, preferably in the design template itself. Personally, I don't use pens or pencils in design meetings. It saves much time to simply type the requirements in the template itself.
NAV order entry is demonstrated and the client is satisfied it will meet their needs minus the previously mentioned items. The meeting is complete.
Analyzing Notes from the Meetings and Designing Solutions
Now is the fun part - designing the implementation. I like to work in small segments so I work on each segment of the design in turn. In some cases, design may involve converting notes into a clear statement of the requirements in plain, clear terms. In other cases, you will need to "figure out" how to accomplish a goal in the ERP system. Putting concepts on paper is a good way to visualize solutions and "trying" out various scenarios by entering transactions in NAV can be revealing. I find it successful to design in the physical universe - sketching, drawing, typing data into Excel, entering transactions and testing. I don't spend a lot of time "thinking" in me 'ead. And of course, Google may have passed up the dog as man's best friend. Don't be afraid to use it. There may be third party solutions or someone may have already solved the problem.
The end product will be functional and technical design specifications that effectively capture and communicate the requirements to its intended audience. The functional specifications must be understandable by the client and project personnel. The technical specifications should be thorough and clear so that developers can read them and execute without a lot of further discussion.
Reviewing the Specifications with the Client
It is now the responsibility of the designer to ensure the client and project personnel understand the design. This is best done in person and updating the document per client feedback. The document is sent back to the client for review and further iterations are made until the design is finally agreed upon.
Design Continues throughout the Project
It is fait accompli that the design will not be 100% accurate or complete and therefore one should expect that it will continue to evolve throughout the project. Development should be delivered iteratively with frequent client demos and feedback sessions. Client should be hands-on in the development stage. The product will then shape and mold to the client's requirements iteratively and the remainder of the project will have the greatest chance of success.
Summary
Design is not an art. It is a science and requires a number of skills- the foremost is the ability to communicate effectively and clearly verbally and in writing backed with extensive product knowledge and implementation experience. It requires the ability to ask questions so as to obtain requirements and to steer group meetings to achieve the goals of design. It requires the ability to research and come up with solutions to problems.
A good design communicates to all those will consume it- client and project resources. Functional specifications should be in simple, clear language, not peppered with a volley of technical acronyms. Technical specifications should follow suit and should be thorough enough so that developers can run with it.
Sufficient time should be spent on the design process. It is time well-spent and is necessary to ensure the success of the project.
Improving Efficiency with Mandatory Fields for Microsoft Dynamics NAV
One of the issues that has plagued all versions of Microsoft Dynamics NAV, is that there is no built-in enforcement of mandatory fields while setting up master records such as customers, vendors, items, fixed assets, etc. This can create interruptions in daily workflow as errors may not be encountered or discovered until a user tries to enter a transaction or worse - after posting a transaction. This often requires involving resources in multiple departments to correct the issue.
Let's take an example of a sales order where an item was setup without an item category and posted. To correct this in NAV would require crediting the order and copying the posted invoice onto a new order and re-posting the order. This could have been avoided had the item been validated as properly set up initially.
NAV 2013 added a feature where "mandatory" fields can be indicated with a red asterisk as a reminder to users. However, this is simply a "reminder" with no actual enforcement. Further, one has to use the Development Environment to mark fields as "mandatory".
The answer to this long-standing problem is a low-impact customization which allows a user to select mandatory fields for various master records such as customers, vendors, items, etc. within NAV and blocking master records unless all mandatory fields are populated.
The above fields are required when setting up a customer. Customer will be blocked until all fields are populated.
This customization can be embellished further by displaying a warning message should the user neglect to enter all required fields before leaving the master record page.
To make this more user-friendly, the mandatory settings can be pre-populated with the commonly expected mandatory fields for master tables.