Functionality
Have you gone down the functionality rabbit hole?
You have two choices when it comes to functionality: change the software to fit your business processes or change the business processes to fit the software. The less you change the software the better – over customizing the system is an expensive mistake.
But it’s a balancing act with opposing gravitational fields – changing the software is the right choice if it’s done for the right reasons.
Getting the right things right
The closer you can get to using the system as it was designed to be used, the more sustainable your implementation will be. Fitting your business processes to the software is the “Fit-to-Standard” approach.
Elements of your processes may represent a competitive advantage for you, or in some areas, the software may not represent best practice. “Fit-to-standard” is a bias, not a rule – but it’s a strong bias.
Navigating Functionality
The First Principle of Requirements Gap-Analysis
Will this work for you?
You might not recognize this tool unless you are an auto mechanic. It’s a diagnostic scan tool (OBD) – invaluable to a mechanic, but foreign to almost everyone else I am not in a position to evaluate OBD devices.
ERP systems are complicated, and before you can evaluate whether a process will work for you, you need a good deal of training on how the system works – from front to back.
Many ‘required’ customizations prove to be unnecessary once there is a sufficient understanding of how the system is supposed to work.
Think End-to-End, Not Department-by-Department
In evaluating fit gap, it’s always easier to work in small groups, but there is a risk to working at the departmental level.
Working in Silos
Departments will naturally optimize processes for their departments, which may not connect well with other departments, who are also trying to optimize processes for their departments.
End-to-End Process Ownership
Having a person own an entire end-to-end process, such as quote-to-cash, goes a long way towards resolving disconnects to promote organizational value.
The Elusive Nature of "Best Practice"
Change the Software or Change Your Business Processes
The ‘fit-to-standard’ idea, fitting your business processes to the software, is the recommended approach, and there are compelling reasons why:
Benefits of "Fit-to-Standard"
- Faster implementation and lower initial cost.
- Lower Total Cost of Ownership.
- A stable, secure, and vendor-tested system.
- Agility to adopt future releases and innovations (like AI) seamlessly.
Drawbacks of Modification
- Budget and schedule
- Release Risk: Modifications imply additional release risk, at a minimum requiring additional testing, or worse, modifications
- Higher TCO, Lower Stability
Best Practice vs. "Paving the Cowpath"
I have some disdain for the phrase “Paving the Cow Path”, and I never use it (except here, when I need it for recognition). For one thing, it’s not very flattering – it implies that users (who, in my experience, are typically following well-thought-out processes based on business need) are (like cows) acting solely out of habit. This is a tough pill to swallow..
Secondly, it is almost always presented (as I did in the title), in contrast to the ‘best practice’ represented by the software. In my experience, it is hard to sell an obviously awkward process as ‘best practice’ to an expert group of users who can plainly see the process is awkward.
The Realities of Best Practice
Complexities
- ‘Best Practice’ is aspirational. Software vendors try to write to an ‘industry standard’
- ERP software encompass many processes and workflows, some of which represent best practices, while others do not.
- Best practice is evolving. What’s considered best practice today may not be best practice tomorrow, especially in light of the emergence of AI.
- ERP systems are evolving to chase best practices to gain competitive advantage.
- Your processes may not be ‘cow paths’; they may represent competitive advantage.
Staying Out of the Robbit Hole of Extensive Functional Changes
Regardless of ‘best practice’ considerations, the reasons to stay out of the functionality rabbit hole are compelling.
Every functional change should be scrutinized by a change control board based on the value it provides. The next section, ‘Staying Out of the Rabbit Hole’, proposes a framework for this.
Staying Out of the Rabbit Hole
Vendors may promote their software as containing ‘best practices’ – a compelling story. But an ERP ‘best practice’ is a ‘standard practice.’ Adopting the same processes as all your competitors does not create competitive advantage; it creates competitive equivalence.
A well-thought-out strategy is not to standardize everything. It’s to standardize the right things. This requires a framework to analyze your processes before you begin. Each process should be assigned to one of the three categories below.
Differentiators
This is your “secret sauce”. These are the unique, proprietary processes that set you apart and help you succeed in the market.
Action: Adapt the Software (Carefully). These are the *only* processes that should be considered for adaptation.
Parity
Essential functions you must perform efficiently to remain competitive, but they don’t offer a unique advantage.
Action: Configure. Leverage the ERP’s standard flow but use its built-in, safe configuration tools to tailor it to your business rules.
Utility
These are necessary, non-strategic functions common to all businesses (e.g., payroll, general ledger, accounts payable).
Action: Adopt the Standard. The goal is maximum efficiency at minimum cost. Any customization here adds cost with questionable value..
Shift Reporting Left
Reporting Needs to Be Addressed Early
Assuming that reporting will work ‘the way it used to’ is a dangerous and incorrect assumption.
The Way it Used to Work (On-Prem)
In the on-premise world, organizations had direct database access. This provided a powerful safety net. If a report was missed, a developer could always write a custom SQL query to extract the data.
This was a blessing and a curse. You had the luxury of ‘putting off’ reporting – because if the information was in the system, you could be reasonably confident that you could get it out. The ‘curse’ was that “putting off” reporting often resulted in reports delivered after go-live.
The Way it Works Now (Cloud)
In the cloud world, for security and stability, you have no direct database access, making ‘the Old Way’ impossible. All database access is controlled by a layer of application program interfaces (API’s). If you have all of the access that you need, the ‘new reality’ comes with performance issues, and with access controlled by API’s, you no longer have the bag of performance tricks developers could use in the old reality. In short, the new reality makes reporting harder.
The Imperative
This constraints of the new reality forces a “proactive ‘shift-left’ approach”. Your entire data and reporting strategy must be defined, designed, and developed at the earliest stages of the implementation. You can no longer “bolt it on” later.
The Agile Advantage
The Agile ERP Implementation?
Agile methodologies promise speed, flexibility, and early ROI. But applying pure Agile dogma to a monolithic ERP implementation can be dangerous. “Monolithic” is a dirty word in the technology world, but with ERP systems, the ‘monolith’ is where the value is.
ERP projects are not custom software builds. After years in agile software development, I understand the value of the agile approach. Success depends on adapting agile to the constraints of an integrated system. Here is what works and what doesn’t.
Applying Agile Principles - What You CAN and SHOULD Do
An incremental approach is essential for reducing risk and maintaining momentum.
Shrink the Initial Release
The first release, and every release after that, should be as small as it can be, while still delivering value.
Work in Sprints
Work in sprints to gauge velocity, get feedback, adjust accordingly, and avoid the ‘deadline rush.’.
Work as a Team
The IT team and the business should work one team, collaborating daily.
Work Interatively
Work should be delivered iteratively, not in ‘one big reveal’. This is true of everything you do, particularly data migration.
Demonstrate Frequently
Functionality should be demonstrated frequently, in as realistic a fashion as possible. UAT is not the time for big surprises.
Deliver Future Functionaliy
After the first release, the MVP, work can be delivered in smaller pieces and still deliver value.
Why the 90-Day Go-Live is a Myth (What You Con't Do)
The idea of implementing your first ERP release in a few months is attractive—but almost always naive.
The Indivisible ERP
Much of the value of an ERP system comes from its integrated nature. Unless you’re in an environment with no legacy ERP system, providing a first release that adds value makes the first release inherently large.
If you make the first release too small, you end up creating expensive, risky, throw-away integrations, or worse, entering data and keeping it in synch in two systems.
The Taxonomy of Functionality Success
Getting Functionality right requires getting a hierarchy of things right. Explore the taxonomy of Functionality critical success factors below. Click the grey + to reveal more detail.
Functionality
Foundational Alignment- System Selection
- Formal Selection Process
- Business Processes Fit
- System Evaluation
- Business Requirements
- Clear Requirements
- Planning ("Phase Zero")
- Future-State Focus
- Strategic Priority
- System-to-Organization Fit
- Holistic Organizational Fit
- Strategic& Tactical Alignment
- Dynamic Adaptation
- The Process Imperative
- Business Process Reengineering (BPR)
- BPR as a Prerequisite
- Aligning Processes to the System
- Structured BPR Management
- Guided Reengineering
- Adopting a Future-State Mindset
- Prioritizing Transformation
- "Process-First" Sequencing
- Harmonization and Standardization
- Consensus on Future State
- Avoiding "Lift and Shift"
- The "Lift and Shift" Anti-Pattern
- Automating Inefficiencies
- Streamlining
- Governance
- Standardization
- Clean Core
- Clean Core
- Fit-to-Standard
- "Vanilla" Implementation
- Best Practices
- Avoiding Excessive Customization
- Low Customization as a CSF
- The Core Anti-Pattern
- Customization as Diagnostic
- Governance
- Standardization-Localization
- Balancing Standardization and Localization
- Local Requirements
- Integrating Technology, People, and Operations
- Cross-Functional Collaboration and Ownership
- Interdepartmental Cooperation
- Cross-Functional Project Team
- Clear Business Process Ownership
- Process-Oriented Thinking
- Designing for The Human Experience
- Prioritizing the Human Experience
- User-Centric Design and Usability
- The Barrier of System Complexity
- Criticality of User Involvement
- Technical Considerations
- Managing Integration Complexity
- Agile
- Cloud Considerations
- Governance
Functionality and the Project Lifecycle
An overview of \ activities for Functionality success, by phase, from the beginning of the project. Click any of the phase buttons below for a summary.
