If you’ve been around the block a few times with D365 F&O implementations (or even in the Salesforce world); you’ve probably heard the same mantra at the beginning of every project: "We will not customize the software."
Ah, the noble intention of keeping things out-of-the-box, utilizing what Microsoft or Salesforce has graciously provided, and avoiding the slippery slope of customization.
Yet, fast forward a few months (or sometimes even weeks), and what do we see? Customizations everywhere! It’s as if the project scope and the software have gone through a “DIY” binge, with modifications and tweaks that make the original plan barely recognizable.
Why Does This Happen?
There’s no single answer to this, but a few recurring themes explain why the original "no customization" intent falls apart.
The Perfect Fit Fallacy: Many organizations believe that out-of-the-box solutions will perfectly align with their unique business processes. The reality? No software can cater to every specific need right out of the gate. As businesses dig deeper into their processes during implementation, they realize that what’s standard just won’t cut it for certain mission-critical operations.
Stakeholder Expectations: Business stakeholders often have high expectations for what the system will do—sometimes too high. As they start to see the capabilities of D365 F&O (or Salesforce), they begin to think, "What if we just added this one little thing here?" This can quickly snowball, leading to a customization overload as every department wants their slice of the pie.
Legacy System Influence: The shadow of the previous system often looms large. Teams are accustomed to doing things in a certain way, and they’re reluctant to change those workflows. So, instead of adapting to the new software, they force the software to adapt to them through customization.
Incomplete Process Analysis: Early in the project, businesses might underestimate the complexity of their processes or overlook critical workflows. As these are uncovered during implementation, customization becomes the quick fix to address gaps that weren’t initially considered.
Consultant Influence: Sometimes, consultants or implementation partners might encourage customization to secure additional work or because it’s easier to customize than to fully explore out-of-the-box alternatives. While well-meaning, this can lead to a situation where customization becomes the default rather than the exception.
The Downside of Customization
Before we dive into solutions, it’s important to recognize the risks of excessive customization:
Increased Costs: Customization isn't cheap. The more you deviate from the standard, the more you spend—both initially and on ongoing maintenance.
Complexity in Upgrades: Every time Microsoft or Salesforce rolls out an update, customizations have to be tested (and sometimes reworked) to ensure they’re compatible. This can delay the adoption of new features and benefits.
Dependency on Specific Knowledge: Customizations often require specialized knowledge that might not be widely available within your organization. This creates a dependency on specific team members or consultants.
A Better Way: Embracing the Mindset Shift
So, how do we break this cycle? How can we shift our mindset to embrace out-of-the-box features and reduce our reliance on customization?
Focus on Process Over Technology: Start by thoroughly understanding and documenting your business processes before even looking at the software. Then, evaluate which processes are truly differentiating for your business and which are just “business as usual.” Only customize for the former; adapt the latter to fit the software.
Change Management is Key: Invest in change management from the outset. Help your team understand why adapting to the software is beneficial in the long run. This reduces resistance and fosters a culture of flexibility and innovation.
Set Clear Expectations with Stakeholders: Communicate clearly from the beginning that the goal is to use out-of-the-box features as much as possible. Set expectations around what the software can and cannot do without customization.
Adopt an Agile Implementation Approach: Use an iterative, agile approach to your implementation. This allows you to incrementally roll out features, test them with real users, and gather feedback. If customization is needed, it’s done in a targeted and controlled manner.
Leverage the Ecosystem: Instead of jumping to customization, explore third-party apps and add-ons available in the Microsoft AppSource or Salesforce AppExchange. These solutions are often more cost-effective and easier to maintain than custom code.
Reminder: Customizing isn’t inherently bad; it’s sometimes necessary to meet specific business needs. But the key is balance. By shifting our mindset to focus on process alignment, change management, and incremental implementation, we can achieve a faster adoption and quicker go-to-market while still meeting the core needs of the business.
And because no DynamicsDad blog is complete without a dad joke:
Why don't software engineers like nature? It has too many bugs!
コメント