By: Jason Chomic
Understanding "Out of the Box" (OOTB) in EAM: Definitions, Configurations, and Expectations
The term “Out of the Box” (OOTB) is frequently used in the implementation discussions surrounding Enterprise Asset Management (EAM) software. While vendors often present EAM systems as fully functional upon installation, the reality is that most EAM solutions require varying degrees of configuration to meet specific business needs. This article delves into the different “flavors” of OOTB functionality, highlights the crucial role of consultants in defining OOTB expectations, and clarifies the distinction between configuration and true customization. Understanding these nuances is essential for setting realistic expectations and ensuring successful EAM implementations.
The Siren Song of "Out of the Box"
“Of course, our software does it out of the box!” This is a familiar refrain often heard during demonstrations and initial discussions about Enterprise Asset Management (EAM) software. The promise of immediate functionality is undoubtedly appealing, painting a picture of seamless integration and rapid deployment. However, the reality of implementing and utilizing an EAM system is often more nuanced. The phrase “out of the box” (OOTB) can carry different meanings and expectations, leading to potential misunderstandings between vendors, customers, and implementation teams.
What Does "Out of the Box" Really Mean in EAM?
To truly understand the implications of OOTB in the EAM landscape, it’s crucial to examine the definition from different perspectives.
EAM OOTB Reality
In stark contrast to the initial impression, the practical reality of most EAM systems is that they do not perform any specific business functions immediately after installation without some level of configuration, unless it’s a highly specialized package like a Facilities edition. An EAM system in its initial state is more akin to a “blank coloring book with a LOT of crayons”. It provides a powerful platform and a wide array of tools (the crayons), but it requires significant effort (the coloring) to define workflows, establish data structures, and tailor the system to the organization’s unique operational requirements.
The Spectrum of "OOTB": Decoding the Flavors
The term “OOTB” is not a monolithic concept. Instead, it exists along a spectrum of configuration effort. Understanding these different “flavors” of OOTB is crucial for setting realistic expectations and planning implementations effectively.
OOTB – Expected Configurations
These represent the normal set of configurations that are typically required to even begin using the fundamental functionalities of the EAM system. Examples of expected configurations include setting up work types, user groups, classes, and statuses/status authorizations. These are considered foundational elements necessary for basic operation.
OOTB – Minor Configurations
Moving beyond the absolute essentials, minor configurations are usually required for specific processes to flow within the EAM system. These involve adjustments that tailor the user experience and facilitate day-to-day operations. Examples include screen design per user group (unhiding and making fields required), creating global or user group-specific dataspys, and setting up basic inboxes or KPIs. While these configurations go beyond the initial setup, they still leverage the standard front-end capabilities of the EAM system.
OOTB – Advanced Configurations
These configurations involve more complex EAM functionalities and often require the expertise of a technical resource. Examples of advanced configurations include working with Flex fields, Alerts, User Defined Grids (UDG)/User Defined Searches (UDS), email notifications, and generating basic Cognos Reports. These functionalities are native to the EAM but require a deeper understanding of the system’s technical aspects to implement effectively.
OOTB – Major Advanced Configurations
This category encompasses configurations that utilize complex EAM functionality and necessitate technical expertise. Examples include complex Flex or Alerts, complex UDS, integrations with other systems, leveraging the Extensibility Framework, and utilizing scripting languages like Python within the EAM environment. These configurations often involve significant technical effort and a thorough understanding of the EAM’s architecture.
OOTB – Co-opting Functionality
This “flavor” of OOTB involves using functionality within the EAM system that was originally designed for one business purpose to accomplish an entirely different business purpose. This approach often comes with significant limitations. A key drawback is that the original intended functionality might become unusable. The example provided in the source illustrates this point: a customer repurposed their parts table to track suppliers by setting the Average Unit Price (AUP) to $1.00 to “issue” costs to work orders via P-cards. This workaround prevented them from accurately tracking actual parts data later.
OOTB – Consultant Expectations
For EAM consultants, understanding the “flavor” of OOTB is critical for successful project delivery. Consultants are expected to check the Statement of Work (SOW) to ensure the anticipated level of configuration aligns with the project scope and any underlying assumptions. They also need to verify with the Project Manager (PM) that the necessary resources and time have been allocated correctly. A crucial step involves documenting the proposed design and confirming it with both the PM and the Solution Architect/Project Leads. Furthermore, consultants are responsible for documenting the potential impact of the chosen design on the system’s functionality and obtaining sign-off from the customer. This rigorous process helps to manage expectations and avoid misunderstandings regarding what constitutes OOTB functionality and the effort required to achieve it.
When to Use the Term “Customization”
The term “customization” should only be used for work that involves direct database-level modifications outside of the EAM application, such as creating custom procedures or establishing direct database connections. For anything that occurs within the EAM environment or is designed to work with it (like APIs or Business Object Documents – BODs), the term “Advanced Configuration” should be used instead. This distinction is important for accurately representing the level of modification and the potential implications for future upgrades and maintenance.
Key Takeaways
Understanding the nuances of “Out of the Box” functionality is crucial for all stakeholders involved in an EAM implementation:
- For Customers:
- Don’t take “OOTB” at face value. Probe for specifics regarding the level of configuration required to meet your specific needs.
- Actively participate in defining requirements and ensure they are clearly documented in the SOW.
- Engage with the implementation team to understand the design choices and their potential impact.
- Be wary of “co-opting functionality” as it can lead to limitations in the future.
- For Implementation Teams (Consultants):
- Thoroughly analyze the SOW and clarify any ambiguities regarding OOTB expectations.
- Document all design decisions and obtain customer sign-off.
- Educate the customer on the implications of different configuration approaches.
- Use the term “Advanced Configuration” for EAM-internal technical work, reserving “Customization” for database-level modifications.
Conclusion
The term “Out of the Box” in the context of EAM software is far from a simple yes or no proposition. It encompasses a spectrum of configuration efforts, ranging from basic setup to complex technical implementations and even potentially problematic workarounds. By understanding the different “flavors” of OOTB, recognizing the perspectives of implementation teams, and clearly distinguishing between configuration and customization, organizations can navigate the EAM implementation process with greater clarity, set realistic expectations, and ultimately achieve a solution that truly meets their operational needs.
