Generally, it is better to customize your business software to fit the way you work rather than change your business processes to fit a software package. For financial systems such as enterprise resource planning and accounting, however, there is a dark side to customizations that should make you think twice before you diverge from the products provided by vendors.
Early leaders in the ERP software market were known for telling customers to change their business processes to fit the software rather than customize the product, and they may have been correct to steer customers in this direction. There are many stories in the press about these ERP implementations which went over budget and schedule, some of them so much so that the projects were abandoned.
Just like any software development project, the scope of an ERP implementation must be managed to keep the cost and schedule under control. Requirements must be identified quickly and written down so they can be evaluated and approved.
Not all requirements are equal. The requirements should be categorized and prioritized so you can differentiate between “must-have” also known as ‘Need’ minimum requirements and “nice-to-have” also known as ‘Want’ optional requirements. The complexity of requirements and users’ stories varies significantly, and just counting them up doesn’t give an accurate sense of the time and resources needed for implementation.
Another important way to categorize requirements is their impact on the base product. Will the customization interfere with future product upgrades and releases? Will the customization have to be redone after an upgrade? Or does the enhancement such as a new report have no impact on the base solution and therefore does not add future risk?
Microsoft Dynamics 365 Business Central (BC) is the latest incarnation of Microsoft’s financial management system formerly called Dynamics NAV (and before that Navision). It has a rich legacy and has added more features and modules over time.
Dynamics 365 BC is a cloud native product, and the architecture has been changed so it can be a good cloud citizen. This means that it is built to allow for frequent updates from Microsoft, some which are noticeable to users and announced in advance and others that are “silent” and patched or upgraded behind the scenes with little or no fanfare, such as security patches.
To allow for embedded solution like Serenic Software’s Serenic Navigator, Microsoft has a layered approach to the solution so that products may be added to the base Dynamics 365 BC. This mechanism is called Extensions. Extensions may be simple, such as adding a new payment service, or extensive such as Serenic Navigator, which is a comprehensive, scalable ERP solution that includes robust functionality such as fund and encumbrance accounting, workflow management with approvals, revenue tracking and indirect cost management by program, grants, and other key financial segments of the business. Additionally, Serenic Navigator can be deployed in multiple languages while providing advanced tools for managing multiple currencies, online and offline donations, funding sources, complex budgets, payroll, human resources, analytics and reporting.
The final layer is customer-specific customizations. This means that a single customer can have a new field in the accounts screen, for instance, without affecting Dynamics 365 or Serenic Navigator. To a user, this customization is transparent and seems as though it were always part of the solutions. When upgrades are applied, however, it is treated differently so the customization is not overwritten.
The takeaway form this blog post is that customizations can create maintenance tasks in the future, and that making your solution different from a standard may incur costs later which should be factored into your customization decisions. The goal is to make sure that the benefits of the customization outweigh the combination of the initial implementation cost and the later costs of maintaining them.