Enterprise resource planning (ERP) programs are commonly evaluated through technical milestones: configuration completion, test execution, data conversion, cutover, and system availability. These measures are necessary but incomplete. A system can be technically live while users remain unable to complete work reliably, understand exceptions, recover from errors, or preserve customer service under pressure. This integrative case study examines organizational resilience at the user-experience level across the transition from user acceptance testing (UAT) to production, using Stericycle’s multiyear enterprise transformation and SAP-centered ERP deployment as a public-record case. The analysis triangulates Stericycle’s annual reports and investor disclosures with scholarship on ERP implementation, organizational resilience, information-systems success, psychological safety, and high-reliability organizing. Public disclosures indicate genuine achievements: a standardized enterprise platform, process and data harmonization, retirement of fragmented legacy practices, and an operating foundation that supported broader transformation. They also document implementation-related disruption, elevated costs, operational inefficiencies, billing and service challenges, manual workarounds, and continuing optimization needs. The central argument is that these outcomes are not contradictory. They show that platform delivery and resilient adoption are different capabilities. Conventional UAT privileges requirement conformity in a controlled environment; resilient production readiness additionally requires representative user participation, end-to-end scenario testing, recoverability, exception handling, workload realism, observability, and rapid learning after release. The paper proposes a Resilient Experience Readiness framework linking user journeys, operational failure modes, control evidence, adoption signals, and recovery capacity. It concludes that ERP success should be judged not only by whether the software performs as designed, but by whether people and teams can sustain safe, accurate, and humane performance when real production conditions depart from the design.
Keywords: organizational resilience, user acceptance testing, SAP S/4HANA, ERP implementation, user experience, production readiness, Stericycle, change management
Introduction
The most consequential moment in an enterprise transformation is often described as “go-live.” The phrase is deceptively binary. It suggests that an organization moves from an old state to a new one when a technical switch is activated. In practice, production is not a destination but a period of intensified adaptation. Transaction volumes become real, interfaces encounter timing and data conditions that were difficult to reproduce, users work under customer and regulatory pressure, and small design compromises combine across functions. At that point, the question is no longer simply whether the system meets its documented requirements. The question is whether the organization can continue to perform when the new system, its users, and the surrounding operating environment interact in unexpected ways.
This distinction is especially important in SAP S/4HANA and other large ERP transformations. ERP platforms integrate finance, procurement, sales, customer service, asset management, human resources, logistics, and reporting. Integration generates value by reducing fragmentation, but it also creates tightly coupled dependencies. A data-quality problem in one process may become a billing problem in another; an authorization design may delay service recovery; a usability problem may cause workarounds that weaken controls. ERP implementation is consequently both a technology program and an organizational redesign (Davenport, 1998; Markus & Tanis, 2000).
Stericycle provides a revealing case. The company operates regulated waste, secure information destruction, compliance, and related services across large and geographically dispersed operations. Its transformation program sought to standardize processes and systems across a portfolio shaped by acquisition and legacy complexity. Public disclosures over several years describe ERP deployment as a major component of business transformation. They also disclose implementation costs, disruption, inefficiencies, customer-service effects, and the need for stabilization and optimization (Stericycle, Inc., 2020, 2021, 2022, 2023, 2024). These disclosures make the case useful, but they do not expose internal test evidence or permit a causal audit. Accordingly, this paper asks: How should Stericycle’s documented results be interpreted through the lens of organizational resilience at the user-experience level, and what practices should govern the transition from UAT to production in comparable SAP S/4HANA programs?
The analysis advances three claims. First, UAT is often too narrow because it treats acceptance as confirmation of prewritten requirements rather than evidence that work can remain effective under variable conditions. Second, post-go-live difficulties may coexist with strategically successful platform delivery; “success” and “failure” must be evaluated at different levels and over different time horizons. Third, user-level resilience can be designed and measured through a governance system that connects critical journeys, exception scenarios, operational controls, human capacity, production telemetry, and learning.
Method and Evidentiary Boundaries
This paper uses an integrative literature review and an explanatory public-record case study. Academic sources were selected from four intersecting domains: ERP implementation and benefits realization, information-systems success and technology acceptance, organizational resilience and high-reliability organizing, and psychological safety and change. Corporate evidence consists principally of Stericycle annual reports and regulatory filings issued during the transformation period. Company filings are appropriate for establishing management’s public descriptions of strategy, expenditure, risks, operational effects, and progress. They are not independent evaluations, and their language is shaped by legal and investor-reporting purposes.
Three safeguards limit overclaiming. First, the analysis does not present Stericycle’s internal SAP architecture, test coverage, defect history, or root-cause findings as known facts. Second, references to SAP S/4HANA are made at the program level; where a public filing refers more generally to ERP, the paper does not infer an undocumented module, release, or configuration. Third, proposed explanations are explicitly analytical. For example, billing disruption after an ERP release can be consistent with inadequate end-to-end testing, data conversion problems, training gaps, process ambiguity, or several interacting causes. Public evidence of the outcome does not prove which internal mechanism dominated.
This boundary matters ethically and analytically. A case study should generate transferable lessons without converting incomplete evidence into allegations. The resulting framework is therefore informed by the Stericycle record rather than represented as a forensic verdict on Stericycle personnel or vendors.
From System Acceptance to Resilient Experience
The limits of conventional UAT
UAT traditionally asks whether configured software supports agreed business requirements. Business representatives execute scripts, compare actual and expected results, log defects, and approve readiness. This stage is essential because developers and integrators cannot authoritatively determine whether the business can accept the solution. Yet conventional UAT has structural weaknesses.
First, scripted testing favors the “happy path.” Testers receive clean prerequisites, known master data, and instructions that reveal the intended route. Production users receive none of these advantages. They encounter incomplete customer records, duplicate vendors, unusual pricing, damaged containers, interrupted interfaces, disputed invoices, absent approvers, and time pressure. Second, project metrics reward test completion. A program may report a high pass rate while excluding low-frequency, high-consequence scenarios or repeatedly deferring defects as post-go-live enhancements. Third, UAT environments rarely reproduce production workload, organizational handoffs, identity controls, device constraints, or competing priorities. Fourth, participants may hesitate to challenge the design when leadership has publicly committed to a date.
These limitations reflect a broader problem in information-systems evaluation. Technical quality, information quality, service quality, use, satisfaction, and net benefits are related but distinct dimensions (DeLone & McLean, 2003). A platform may satisfy technical criteria while diminishing user performance or service quality. Likewise, perceived usefulness and ease of use influence adoption, but adoption alone does not establish operational reliability (Venkatesh et al., 2003). Users can be compelled to use an ERP system while relying on spreadsheets, email, shadow databases, and heroic effort to make it workable.
Resilience as adaptive capacity
Organizational resilience is the capacity to prepare for, respond to, recover from, and learn through disruption while preserving essential functions. Duchek (2020) conceptualized resilience as a process involving anticipation, coping, and adaptation. Weick and Sutcliffe (2015) emphasized characteristics of high-reliability organizing, including sensitivity to operations, reluctance to simplify, attention to failure, commitment to resilience, and deference to expertise. At the user-experience level, these ideas shift readiness from interface approval toward adaptive performance.
A resilient user experience is not an interface that never fails. It is a work system in which people can recognize abnormal conditions, understand consequences, obtain help, use safe fallback methods, restore the process, and feed learning back into design. This perspective aligns with sociotechnical reasoning: performance emerges from the joint behavior of technology, tasks, people, structures, and environment rather than from the software alone (Sittig & Singh, 2010). It also resonates with Universal Resilience Theory, which treats resilience as an interacting capacity distributed across systems rather than a single static property (Pirro, 2024b). Applied to ERP, resilience must exist across individual competence, team coordination, process design, data, interfaces, infrastructure, governance, and partner networks.
The difference can be stated simply. Acceptance asks, “Can an authorized user complete the designed transaction?” Resilience asks, “Can the operating system of people and technology sustain the business outcome when the transaction, surrounding data, timing, or organizational context is abnormal?”
Stericycle’s Enterprise Transformation Context
Stericycle grew through acquisitions, producing the kind of heterogeneous process and systems landscape that often motivates ERP consolidation. Its regulated services also create demanding operational conditions: geographically distributed field work, route and service execution, customer-specific requirements, recurring and transactional billing, material tracking, compliance obligations, and financial controls. In this environment, master data and process integration are not merely administrative. They influence whether service events are scheduled, performed, documented, billed, collected, and reported correctly.
Stericycle’s public reports described a multiyear business transformation that included an enterprise ERP platform, standardized processes, shared services, technology modernization, and related restructuring. Across the transformation period, management reported substantial investment and staged deployment. The disclosures also described implementation-related inefficiencies and disruption, including additional costs and effects on operational and customer-facing processes, while later reports emphasized progress, stabilization, and value capture (Stericycle, Inc., 2020, 2021, 2022, 2023, 2024). The progression is best understood as a transition curve, not a single event.
Because the company was acquired by Waste Management in 2024, the eventual strategic value of the platform should also be interpreted cautiously. A standardized digital and process foundation can make an enterprise easier to govern, integrate, and scale, but public acquisition outcomes do not isolate the value attributable to one technology program. The case nevertheless illustrates how transformation can simultaneously produce durable infrastructure and near-term operating stress.
Successes in the Stericycle Case
Enterprise standardization
The central success was movement away from a fragmented legacy environment toward a common enterprise foundation. Standardization can produce consistent data definitions, repeatable controls, common workflows, and consolidated reporting. These benefits are especially important in acquisition-built organizations, where local systems and practices encode conflicting assumptions. ERP research has long recognized that integration can improve visibility and coordination, although benefits depend on organizational assimilation rather than installation alone (Davenport, 1998; Shang & Seddon, 2002).
From a resilience perspective, standardization reduces certain forms of brittleness. A shared chart of accounts, customer model, vendor model, and process taxonomy can improve diagnosis during disruption because teams possess a common language. Centralized access control and monitoring can also strengthen governance. A platform that exposes cross-functional dependencies is more capable of supporting enterprise-wide learning than disconnected applications.
Completion under complexity
Large ERP programs are vulnerable to cancellation, indefinite delay, or piecemeal retreat. Stericycle’s sustained deployment across a complex operating landscape represents an execution achievement even though the journey included friction. Completion matters because partial standardization can preserve the cost of both old and new environments without delivering integrated benefits. The company’s later disclosures increasingly framed transformation activities in terms of stabilization, optimization, and benefit realization, indicating a shift from construction toward operation (Stericycle, Inc., 2022, 2023, 2024).
Foundation for process visibility and improvement
An integrated platform makes process performance more observable. It can link service execution to invoicing, cash collection, procurement, and financial reporting; enable consistent exception queues; and create a basis for automation. This is not an automatic benefit. Poorly designed metrics can obscure local realities, and standardized data can still be inaccurate. Nevertheless, the infrastructure creates an opportunity for feedback at enterprise scale.
Dynamic Value Networks Theory is relevant here because ERP value does not reside solely in an application. It emerges through exchanges among users, customers, suppliers, service operations, finance, regulators, and technology partners (Pirro, 2024a). Stericycle’s platform should therefore be understood as connective infrastructure. Its success depends on whether information and decisions travel through this network with sufficient accuracy and speed.
Evidence of organizational learning
Public acknowledgement of implementation impacts, continuing remediation, and optimization suggests that the organization did not equate technical deployment with completed transformation. Learning after launch is a core resilience behavior. ERP programs often experience a “shakedown” phase in which the organization resolves defects, rebuilds fluency, stabilizes performance, and develops improved routines (Markus & Tanis, 2000). Stericycle’s multiyear disclosures are consistent with such a lifecycle.
Documented Adverse Outcomes and Interpreted Failures
Operational and customer-facing disruption
Stericycle’s disclosures connected transformation activity with operational inefficiencies, incremental expense, and disruption affecting service and customer-facing processes during portions of the rollout (Stericycle, Inc., 2020, 2021, 2022). At the user-experience level, these outcomes are more meaningful than defect counts. A failed or delayed billing process can increase calls, rework, disputes, and cash-collection effort. A service exception that users cannot interpret can propagate into missed commitments. Each downstream effect increases cognitive load and reduces capacity to detect the next problem.
The analytical failure is not necessarily that disruption occurred. Complex migrations invariably produce variance. The more consequential failure would be insufficient containment: allowing localized issues to move across process boundaries faster than teams can detect and resolve them. Tight integration amplifies both good data and bad data.
A probable gap between test conditions and work conditions
Public filings do not reveal Stericycle’s UAT design, so it would be improper to assert that UAT was poorly executed. The reported post-deployment effects do, however, support a defensible inference: preproduction evidence did not fully predict production experience. That gap may have arisen from scenario coverage, data representativeness, interface behavior, role design, training transfer, workload, or cutover timing.
This distinction exposes a common ERP weakness. UAT frequently verifies transactions by module, while customers experience outcomes across modules. For Stericycle, an end-to-end journey might begin with a contract and customer record, pass through scheduling and route execution, require compliant service documentation, generate an invoice, produce a payment, and reconcile in the general ledger. Testing each component separately cannot establish the resilience of the journey. Nor can a successful invoice test establish that a service representative can explain and correct an unexpected invoice while a customer waits.
Manual workarounds and control debt
When a new platform does not accommodate real exceptions, users create compensating routines. Some are necessary and intelligent; frontline adaptation is often what protects customers. Yet workarounds can become control debt. Spreadsheet reconciliations, shared credentials, off-system approvals, manual re-entry, and untracked corrections increase error exposure and conceal true process capability. The visible system may appear stable because users absorb its deficiencies through invisible labor.
Resilience must therefore distinguish adaptive capacity from permanent workaround dependence. A safe workaround has an owner, trigger, authorization, expiration condition, reconciliation step, and path to elimination. An ungoverned workaround merely transfers risk from the platform to the employee.
Transformation fatigue and the human cost of stabilization
Extended transformation programs impose cumulative demands. Employees learn new roles while meeting existing service expectations; subject-matter experts divide attention among operations, testing, training, data remediation, and hypercare. If project reporting focuses on milestones, this load can remain invisible until attrition, errors, absenteeism, or disengagement appear.
Psychological safety is particularly important during UAT and hypercare. Employees must be able to report that a design is unusable, a control is impractical, or a go-live date is unsafe without being perceived as resistant. Edmondson (1999) showed that psychologically safe teams are more able to learn from interpersonal risk-taking. In ERP governance, silence can masquerade as acceptance. A signed UAT approval may reflect genuine confidence, constrained choice, or exhaustion; governance must determine which.
Benefits lag and ambiguous success criteria
ERP programs often authorize investment using long-term benefits but govern implementation using short-term delivery measures. This mismatch permits a program to be declared successful at go-live even as operating cost, user effort, and customer friction rise. Conversely, judging the entire program by early disruption ignores the time needed for stabilization and process learning. Stericycle’s record demonstrates why evaluation must be time-phased and multidimensional.
Opportunities for Stronger Resilience From UAT to Production
Reframe UAT around critical user journeys
Requirements remain necessary, but the primary unit of acceptance should be the critical user journey. A journey has a business outcome, customer or regulatory consequence, accountable owner, participating roles, systems, data prerequisites, controls, expected cycle time, and recovery route. In Stericycle’s context, representative journeys would include onboarding a regulated-services customer, changing service terms, executing and evidencing a pickup, resolving a service exception, producing and correcting an invoice, applying cash, and closing the financial period.
Each journey should be tested in four states: normal, degraded, recovery, and surge. Normal testing confirms the expected path. Degraded testing introduces missing data, delayed interfaces, unavailable approvers, device failure, or authorization conflicts. Recovery testing demonstrates that users can identify the state, resume safely, reconcile duplicates, and communicate consequences. Surge testing evaluates volume, time pressure, and support capacity. Acceptance then becomes evidence of business survivability rather than script completion.
Test with production-representative people and conditions
Power users are valuable but unrepresentative. They know project language, have privileged access to designers, and often possess more system fluency than the median employee. A resilient test population should include new employees, occasional users, field personnel, supervisors, service representatives, finance specialists, accessibility needs, different locations, and different shifts. It should also include upstream and downstream partners whose performance determines the outcome.
Role-based access must be exercised as configured for production. Synthetic master data should reflect actual complexity without exposing sensitive information. Interfaces should be tested at realistic timing and volume. Training should not reveal the exact test answer; otherwise the program measures script following rather than comprehension.
Establish risk-based exit criteria
A single pass-rate threshold is inadequate. Exit criteria should combine defect severity, journey criticality, control exposure, workaround maturity, user proficiency, support readiness, conversion reconciliation, and recovery performance. A low-frequency defect affecting regulatory documentation may carry more go-live risk than many cosmetic defects. Likewise, a workaround may be acceptable for a small, trained team but unsafe at enterprise volume.
Decision makers should receive residual risk in plain operational terms: customers affected, transactions exposed, maximum duration, manual effort required, financial or compliance consequence, detection method, and recovery owner. This discourages the administrative reclassification of defects simply to protect a date.
Treat hypercare as a high-reliability operating model
Hypercare should not be merely an enlarged help desk. It should be a temporary high-reliability organization with direct operational sensing, rapid authority, and disciplined learning. A cross-functional command structure should integrate business process owners, frontline experts, customer service, data, integration, security, finance controls, training, and implementation partners. Decisions should defer to the person with relevant expertise rather than the highest-ranking participant (Weick & Sutcliffe, 2015).
Signals should include more than ticket counts. Useful indicators include abandoned or reversed transactions, queue aging, duplicate records, billing adjustments, credit memos, manual journals, call reasons, service recovery events, access changes, interface retries, overtime, training searches, and workaround usage. These measures reveal friction that users may not formally report.
Build a controlled fallback architecture
Fallback planning is frequently treated as an infrastructure rollback decision. In an integrated ERP, technical rollback may become impractical after transactions accumulate. Operational fallback is therefore equally important. Critical journeys need predefined degraded-mode procedures, controlled forms or queues, decision rights, customer communication, reconciliation requirements, and limits on duration. The objective is not to preserve every feature; it is to preserve essential outcomes safely.
Universal Resilience Theory supports this layered approach: when one layer loses capability, another temporarily absorbs the load, but the transfer must not create hidden fragility elsewhere (Pirro, 2024b). Backup processes should be rehearsed before go-live and retired deliberately after stability returns.
Convert experience data into product ownership
After stabilization, ownership should move from a project structure to a durable product-and-process model. Process owners need authority over a prioritized backlog informed by operational telemetry, user research, control findings, and customer outcomes. Release decisions should consider the cumulative effect of small usability improvements. Reducing clicks is useful, but reducing ambiguity, handoffs, rework, and exception-resolution time is more consequential.
The Resilient Experience Readiness Framework
The proposed framework contains seven gates. It is designed for SAP S/4HANA programs but is platform independent.
Gate
Governing question
Required evidence
1. Outcome definition
What essential business outcome must survive?
Journey map, service obligation, control and customer consequence
2. Representative design
Does the configuration reflect real users and operating variance?
Persona/role coverage, field observation, accessibility and workload review
3. Scenario resilience
Can the journey function in normal, degraded, recovery, and surge states?
End-to-end results, exception tests, recovery time, reconciliation proof
4. Human readiness
Can users recognize, decide, act, escalate, and recover?
Demonstrated proficiency, not attendance; psychological-safety feedback
5. Operational containment
Can failures be detected and prevented from propagating?
Telemetry, thresholds, circuit breakers, accountable owners, safe workarounds
6. Production learning
Can the organization convert signals into rapid improvement?
Hypercare cadence, expertise-based decisions, backlog and root-cause discipline
7. Benefit endurance
Are gains sustained without hidden labor or control debt?
Customer, employee, financial, control, and adoption measures over time
Four principles govern the gates. First, evidence is cumulative: a later gate cannot compensate for an unexamined critical journey. Second, business owners accept operational risk; technology teams inform but do not unilaterally own that decision. Third, exceptions are first-class requirements. Fourth, employee effort is a system metric. If performance depends on chronic overtime or spreadsheet repair, the platform has not reached a resilient state.
Measurement From UAT Through Stabilization
A balanced scorecard should follow each critical journey across three horizons.
Before go-live, leading measures include end-to-end scenario coverage, severe defects by journey, data-reconciliation accuracy, role-provisioning success, demonstrated user proficiency, recovery drill performance, and unresolved workaround exposure. During the first production weeks, measures should emphasize containment: customer-impacting incidents, time to detect, time to restore, queue growth, error recurrence, escalation quality, manual effort, and support demand. During stabilization and optimization, governance should examine outcome trends: first-time-right performance, invoice accuracy, service completion, days sales outstanding, customer contacts caused by process failure, employee effort, control exceptions, adoption of standard work, and realized benefits.
Metrics require interpretation. A falling ticket volume may indicate improvement, fatigue, or loss of trust in support. High system usage may indicate adoption or compulsory dependence. Faster closure may reflect resolution or premature ticket disposition. Quantitative indicators should therefore be paired with structured user interviews, observation, and review of actual exceptions.
Discussion
The Stericycle case resists a simplistic label. Calling the deployment a success because an enterprise platform was delivered ignores documented disruption and human effort. Calling it a failure because stabilization was difficult ignores the strategic significance of standardization and the lifecycle of ERP benefits. The more credible conclusion is that Stericycle achieved substantial platform transformation while experiencing an uneven transition in operational resilience.
This interpretation has broader implications. First, ERP risk is not concentrated only in software defects. It exists in the mismatch among formal process, actual work, data, incentives, role authority, customer promises, and recovery capacity. Second, user experience is not cosmetic. In enterprise systems, confusing states and difficult exceptions can become financial, operational, compliance, and safety risks. Third, resilience is not synonymous with employee heroism. A system that works because experienced employees continually repair it off-system is consuming resilience rather than building it.
Finally, organizational learning must cross firm boundaries. SAP programs involve software vendors, systems integrators, contractors, internal technology teams, process owners, frontline workers, and customers. Dynamic Value Networks Theory suggests that value and risk circulate through these relationships (Pirro, 2024a). Contractual deliverables should therefore include outcome evidence, knowledge transfer, recovery testing, and post-release accountability rather than configuration completion alone.
Practical Recommendations
Organizations preparing an SAP S/4HANA release should take six immediate actions. They should define the ten to twenty journeys whose failure would materially harm customers, compliance, cash, or continuity; require each journey to pass degraded and recovery scenarios; place representative frontline users in acceptance decisions; publish residual risk in business language; operate hypercare through a cross-functional high-reliability structure; and maintain a visible register of manual workarounds with owners and expiration dates.
Boards and executive sponsors should also request evidence beyond red-amber-green dashboards. Useful questions include: Which production conditions were not represented in UAT? Which journeys depend on manual reconciliation? How quickly would the organization detect a silent failure? What are users afraid to report? Which benefits remain dependent on extraordinary effort? These questions direct attention toward resilience rather than milestone optimism.
Limitations and Future Research
This study relies on public disclosures and scholarly literature. It does not include interviews with Stericycle employees, customers, SAP, or implementation partners; internal system data; test artifacts; or independent operational audits. It cannot attribute a disclosed outcome to a particular design decision or implementation party. The period also includes external and organizational changes that complicate causal interpretation. The analysis should therefore be read as theory-informed case interpretation, not a definitive postimplementation review.
Future research could test the Resilient Experience Readiness framework through comparative cases and longitudinal data. Studies could examine whether degraded-mode UAT predicts post-launch incident severity, whether psychological safety predicts earlier defect discovery, and whether workaround telemetry improves benefits realization. Research should also investigate how generative AI and process-mining tools can identify exception patterns without replacing frontline judgment or creating surveillance harms.
Conclusion
The journey from UAT to production is the point at which an ERP transformation becomes an organizational reality. Stericycle’s SAP-centered transformation demonstrates both the strategic promise of enterprise standardization and the operational strain that can accompany it. Its public record supports a balanced assessment: completing a common platform and moving toward optimization were meaningful successes; disruption, inefficiency, customer-facing friction, and manual burden reveal opportunities where production resilience could be stronger. The available evidence does not permit a forensic assignment of cause, but it does illuminate a general failure of ERP governance when technical acceptance is allowed to stand in for organizational readiness.
Resilient acceptance requires more than scripts that pass. It requires proof that representative users can deliver essential outcomes across normal, degraded, recovery, and surge conditions; that failures can be detected and contained; that safe fallback procedures exist; that employees can speak candidly; and that operational signals become rapid learning. Under this standard, go-live is not the declaration of success. It is the beginning of an evidence-based obligation to make the new work system dependable for the people who use it and the customers who experience its consequences.
References
Aloini, D., Dulmin, R., & Mininno, V. (2007). Risk management in ERP project introduction: Review of the literature. Information & Management, 44(6), 547–567. https://doi.org/10.1016/j.im.2007.05.004
Davenport, T. H. (1998). Putting the enterprise into the enterprise system. Harvard Business Review, 76(4), 121–131.
DeLone, W. H., & McLean, E. R. (2003). The DeLone and McLean model of information systems success: A ten-year update. Journal of Management Information Systems, 19(4), 9–30. https://doi.org/10.1080/07421222.2003.11045748
Duchek, S. (2020). Organizational resilience: A capability-based conceptualization. Business Research, 13, 215–246. https://doi.org/10.1007/s40685-019-0085-7
Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383. https://doi.org/10.2307/2666999
Markus, M. L., & Tanis, C. (2000). The enterprise systems experience—From adoption to success. In R. W. Zmud (Ed.), Framing the domains of IT management: Projecting the future through the past (pp. 173–207). Pinnaflex Educational Resources.
Pirro, N. J. (2024a). Dynamic Value Networks Theory: A new framework for interconnected systems. Pyrrhic Press Publishing. https://doi.org/10.5281/zenodo.11120455
Pirro, N. J. (2024b). Universal Resilience Theory: A comprehensive framework for understanding and enhancing resilience in diverse systems. Pyrrhic Press Publishing. https://doi.org/10.5281/zenodo.10997597
Shang, S., & Seddon, P. B. (2002). Assessing and managing the benefits of enterprise systems: The business manager’s perspective. Information Systems Journal, 12(4), 271–299. https://doi.org/10.1046/j.1365-2575.2002.00132.x
Sittig, D. F., & Singh, H. (2010). A new sociotechnical model for studying health information technology in complex adaptive healthcare systems. Quality & Safety in Health Care, 19(Suppl. 3), i68–i74. https://doi.org/10.1136/qshc.2010.042085
Stericycle, Inc. (2020). Annual report for the fiscal year ended December 31, 2019. U.S. Securities and Exchange Commission. https://www.sec.gov/edgar/browse/?CIK=861878&owner=exclude
Stericycle, Inc. (2021). Annual report for the fiscal year ended December 31, 2020. U.S. Securities and Exchange Commission. https://www.sec.gov/edgar/browse/?CIK=861878&owner=exclude
Stericycle, Inc. (2022). Annual report for the fiscal year ended December 31, 2021. U.S. Securities and Exchange Commission. https://www.sec.gov/edgar/browse/?CIK=861878&owner=exclude
Stericycle, Inc. (2023). Annual report for the fiscal year ended December 31, 2022. U.S. Securities and Exchange Commission. https://www.sec.gov/edgar/browse/?CIK=861878&owner=exclude
Stericycle, Inc. (2024). Annual report for the fiscal year ended December 31, 2023. U.S. Securities and Exchange Commission. https://www.sec.gov/edgar/browse/?CIK=861878&owner=exclude
Venkatesh, V., Morris, M. G., Davis, G. B., & Davis, F. D. (2003). User acceptance of information technology: Toward a unified view. MIS Quarterly, 27(3), 425–478. https://doi.org/10.2307/30036540
Weick, K. E., & Sutcliffe, K. M. (2015). Managing the unexpected: Sustained performance in a complex world (3rd ed.). Jossey-Bass.