Do Not Wait for the Perfect ERP: Modernize What You Control Today

How Institutions Can Reduce Risk, Improve Operations, and Prepare for the Future While the ERP and SIS Market Continues to Mature

By David Kent, President and Founder, David Kent Consulting, Inc.

Blog 3 of 5  |  3,849 words  |  Approximately 18 minutes

——————————————————

This is the third article in our five-part series, ERP Strategy in a Re-Sorting Market.

In the first article, “Your Vendor’s Roadmap Is Not Your ERP Strategy,” we discussed why colleges and universities must define their own institutional direction rather than allowing incumbent-vendor pressure, product roadmaps, or artificial deadlines to determine their future.

In the second article, “The Higher Education ERP Market Is No Longer a One-Way Road,” we examined the growing number of credible ERP and SIS paths available to institutions, including continued investment in current platforms, public-cloud modernization, incumbent SaaS offerings, Workday, Oracle, domain-by-domain replacement, and more composable enterprise architectures.

The central message of those first two articles was that institutions should not be rushed into a major, irreversible decision before the evidence supports it.

But strategic patience must not become operational stagnation.

An institution may have valid reasons to delay selection of its next ERP or SIS. Emerging products may need more time to mature. Peer references may still be limited. Pricing may remain uncertain. Institutional leadership may not yet have the capacity for a broad transformation.

Those are legitimate reasons to avoid a premature platform commitment.

They are not legitimate reasons to stop modernizing.

There is a great deal institutions can do now to reduce risk, improve service, strengthen resilience, lower cost, and prepare for whatever path they eventually choose.

The key is to distinguish between decisions that determine the final destination and improvements that make every future destination easier to reach.

Waiting for Clarity Does Not Mean Standing Still

When the market is uncertain, institutions often fall into one of two traps.

The first is to move too quickly. Leaders feel pressure to choose a new platform, follow the incumbent vendor’s roadmap, or launch a broad transformation before the product, institution, or business case is ready.

The second is to do nothing. Leaders conclude that because the long-term answer is unclear, meaningful progress must wait.

Both approaches create risk.

Moving too quickly can produce lock-in, cost overruns, organizational disruption, and years of commitment to a product or delivery model that has not been fully proven.

Doing nothing allows technical debt, brittle integrations, aging infrastructure, security gaps, staffing dependencies, poor data quality, and inefficient processes to become more deeply embedded.

The better approach is to modernize what the institution controls while preserving flexibility around what it cannot yet know.

That means moving aggressively on foundational capabilities while remaining deliberate about major platform commitments.

Modernization Is Not the Same as Replacement

A common misconception is that modernization requires a new ERP or SIS.

It does not.

A new product may eventually be necessary, but many of the most important modernization activities are independent of product selection.

Institutions can modernize:

• Infrastructure
• Operations
• Security
• Disaster recovery
• Integrations
• Data governance
• Identity and access management
• Business processes
• Testing and release management
• Monitoring and observability
• Documentation
• Staffing models
• Vendor management
• Decision governance

These improvements create value whether the institution remains on its current platform for three years or ten.

They also reduce the complexity and risk of a future transition.

An institution with documented integrations, governed data, rationalized customizations, automated infrastructure, tested recovery procedures, and clearly defined business processes is far better prepared for change than one that has simply selected a new product.

Modernization should therefore be viewed as an institutional capability-building effort, not merely as a software project.

Cloud Relocation Is Not Necessarily Modernization

The word cloud is often used as though it automatically implies modernization.

It does not.

An institution can move an aging, inefficient, manually administered environment into a public cloud and preserve nearly every problem it had before.

The same oversized servers remain oversized.

The same manual processes remain manual.

The same fragile integrations remain fragile.

The same security gaps remain security gaps.

The same technical debt remains technical debt.

Only the hosting location has changed.

In most cases, the institution may now be paying more for that inefficiency because public-cloud consumption charges make poor design more visible and more expensive.

A lift-and-shift migration may be appropriate as a temporary step in some situations, but it should not be confused with the end state.

True cloud modernization should improve the way the environment is designed, operated, secured, monitored, scaled, and recovered.

That work does not always require years. When the migration is properly designed from the beginning, infrastructure modernization, automation, resilience improvements, and cloud transition can be executed as one coordinated effort. A focused 14-week modernization and migration can move the institution forward quickly without forcing a premature decision about its eventual ERP or SIS platform.

The objective is not simply to move the environment.

The objective is to make it materially better.

Modernize the Infrastructure Foundation for Higher Education Cloud Readiness

Infrastructure is one of the clearest areas where institutions can act without predetermining their future ERP or SIS.

Many higher education environments still depend on aging hardware, manual provisioning, inconsistent configurations, and recovery procedures that are rarely tested under realistic conditions.

The good news is that this work does not necessarily require a multiyear transformation. With the right scope, architecture, and preparation, an institution can modernize and migrate a core ERP environment to public cloud in a matter of months. In our experience, a well-planned modernization and migration can often be completed in approximately 14 weeks.

For institutions running Ellucian Banner, our guide on moving Banner to the public cloud explores the specific infrastructure and architectural decisions that apply.

That does not mean cutting corners or simply relocating existing servers. It means combining migration with deliberate improvements in automation, resilience, security, monitoring, capacity management, and operational discipline.

Institutions should assess:

• Hardware age and supportability
• Capacity utilization
• Storage performance and growth
• Backup integrity
• Recovery time and recovery point objectives
• Operating system currency
• Database support status
• Network resilience
• Environment consistency
• Security configuration
• Monitoring coverage
• Single points of failure

From there, institutions can establish a more modern operating foundation.

Automate Provisioning

Infrastructure should be created through repeatable, documented processes rather than one-off manual work.

Infrastructure-as-Code can help ensure that environments are built consistently, reviewed, versioned, and recreated when needed.

That reduces configuration drift and dependence on individual administrators.

Right-Size Capacity

Many enterprise environments are sized around historical assumptions rather than current demand.

Institutions should analyze actual usage and adjust computing, storage, and database resources accordingly.

This is especially important in the public cloud, where unused capacity still carries a cost.

Manage Nonproduction Environments Deliberately

Development, testing, training, and quality-assurance environments often consume resources continuously even when they are not being used.

Institutions should establish schedules and automation for starting, stopping, refreshing, and decommissioning nonproduction environments.

Improve Observability

Modern environments should provide meaningful visibility into performance, availability, security events, capacity, and application behavior.

Monitoring should identify issues before users do.

Standardize Configuration

Operating systems, databases, middleware, and supporting tools should follow documented standards.

Exceptions should be deliberate, justified, and tracked.

These improvements create a stronger foundation for the current system and make future migrations more manageable.

Strengthen Disaster Recovery and Operational Resilience

Many institutions have backup procedures.

Fewer have a tested and realistic recovery capability.

Backups are not disaster recovery.

A disaster-recovery strategy should answer:

• Which services are most critical?
• How quickly must each service be restored?
• How much data loss is acceptable?
• Where will systems operate if the primary environment is unavailable?
• How will users connect?
• How will identity services function?
• How will integrations resume?
• Who has authority to declare a disaster?
• How will recovery be coordinated?
• How often will the plan be tested?

Recovery planning should include the full service, not merely the database.

An ERP or SIS depends on:

• Application services
• Databases
• Identity systems
• Networks
• Integrations
• File transfers
• Reporting tools
• Document management
• Payment services
• External partners
• Operational procedures
• People who understand how the environment works

If any of these dependencies are missing, the system may be technically running but operationally unusable.

Institutions should conduct regular recovery exercises that test actual procedures, timing, dependencies, and decision-making.

The purpose is not to produce a document stating that recovery is possible.

The purpose is to prove it.

Treat Cybersecurity as Part of the Higher Education ERP Strategy

ERP and SIS environments contain some of the institution’s most sensitive data and support some of its most critical processes.

Security should not be treated as a separate technical project.

It is part of the enterprise strategy.

EDUCAUSE has identified “cybersecurity as a core competency” as central to institutional resilience. That framing is important. Cybersecurity is not simply a collection of tools, technical controls, or vendor certifications. It is an institutional capability involving governance, risk management, staffing, architecture, continuous investment, and a deliberate balance among risk, cost, and opportunity. 

Institutions should modernize security across several areas.

Identity and Access Management

Access should be based on role, need, and least privilege.

Institutions should review:

• Privileged accounts
• Shared credentials
• Dormant users
• Service accounts
• Emergency access
• Multifactor authentication
• Segregation of duties
• Access-review processes
• Third-party access
• Administrator activity

Patch and Vulnerability Management

Unsupported or poorly maintained components create institutional risk regardless of where they are hosted.

Institutions need clear ownership, schedules, testing procedures, and escalation paths for security updates.

Logging and Monitoring

Security-relevant activity should be collected, retained, reviewed, and integrated with broader incident-response processes.

Environment Separation

Production and nonproduction environments should be appropriately isolated.

Sensitive data should not be copied into lower environments without controls.

Incident Readiness

Institutions should know how they would respond if ERP or SIS credentials, data, integrations, or administrative access were compromised.

These capabilities matter whether the institution remains on-premises, moves to public cloud, or adopts SaaS.

The division of responsibility may change.

The institution’s accountability does not.

Rationalize ERP Integrations Before They Become a Migration Crisis

Integrations are often the least visible and most underestimated part of an ERP or SIS environment.

Over time, institutions accumulate:

• Point-to-point interfaces
• Custom scripts
• Scheduled file transfers
• Manual uploads
• Vendor connectors
• Database queries
• Middleware workflows
• Unofficial data extracts
• Processes known only to one employee

Many of these integrations are poorly documented.

Some no longer have a clear owner.

Others support critical operations but have never been formally reviewed.

During a major transition, this hidden integration landscape becomes a crisis.

Institutions should not wait for a replacement project to begin understanding it.

Build an Integration Inventory

For each integration, document:

• Source system
• Destination system
• Data exchanged
• Frequency
• Business owner
• Technical owner
• Authentication method
• Error-handling process
• Monitoring
• Dependencies
• Criticality
• Replacement plans

Eliminate What Is No Longer Needed

Some integrations exist only because no one has revisited them.

Others support obsolete processes or duplicate newer capabilities.

Removing unnecessary interfaces reduces risk and future migration work.

Establish Integration Standards

Institutions should define preferred approaches for APIs, messaging, file transfer, authentication, monitoring, error handling, and documentation.

Separate Business Logic From Individual Systems

Where practical, institutional rules should not be buried inside fragile scripts or custom application code.

Making business logic more visible and portable preserves flexibility.

Monitor Integrations as Services

An integration that fails silently can disrupt financial aid, payroll, registration, identity, or reporting.

Critical integrations should be monitored with clear alerts and ownership.

A well-governed integration environment is one of the strongest forms of ERP optionality.

It allows applications to change without forcing the institution to recreate every connection from the beginning.

Improve Data Governance Before Moving It

No new platform can repair poor data governance by itself.

Moving inconsistent, duplicated, poorly defined, or unreliable data into a modern system produces a modern system with many of the same underlying problems. In some cases, it makes those problems more difficult to resolve because old assumptions become embedded in new configurations, integrations, reports, and business processes.

Data governance is not simply a data-cleanup exercise conducted before conversion. It is the institutional framework for deciding what data means, who is responsible for it, how it may be used, how its quality is maintained, and how disagreements are resolved.

EDUCAUSE describes data governance as the foundation for broader data management and transformation efforts. It coordinates people, processes, and technology across functional and technical areas to improve data quality, security, availability, consistency, and institutional trust.

Institutions should begin strengthening that foundation now.

Establish Ownership and Decision Authority

Every major data domain should have clearly identified institutional ownership. Student, finance, human resources, payroll, advancement, and other data should not be treated as belonging exclusively to the application or department that currently stores it.

Institutions should define:

• Who has authority to establish policies and definitions
• Who is responsible for the quality of each data domain
• Who approves access and appropriate use
• Who maintains the data operationally
• Who resolves disagreements that cross departmental boundaries
• Who is accountable when known data problems remain unresolved

These responsibilities may be assigned to data trustees, data owners, data stewards, custodians, or similar roles. The titles matter less than having clear authority, accountability, and escalation paths.

Create Common Definitions and Authoritative Sources

Institutions frequently discover that different departments use the same term to mean different things or rely on different systems and spreadsheets for what should be the same information.

Terms such as enrolled student, active employee, instructional cost, retention, completion, and full-time status may produce different answers depending on who runs the report.

Institutions should:

• Establish common definitions for critical data elements and measures
• Identify the authoritative source for each category of data
• Document how information moves among systems
• Create shared data dictionaries and business glossaries
• Establish a process for approving and communicating changes to definitions
• Clarify which reports and datasets should be used for institutional decision-making

Without this work, a new ERP may consolidate technology without creating a consistent institutional understanding of the data.

Improve Data Quality Systematically

Data quality should not depend on periodic cleanup projects or individual employees recognizing that something looks wrong.

Institutions should establish repeatable processes for:

• Identifying incomplete, inaccurate, duplicated, or inconsistent records
• Recording and prioritizing known data-quality issues
• Determining the source of recurring errors
• Assigning responsibility for correction
• Establishing validation rules at the point of entry
• Measuring whether data quality is improving
• Preventing corrected problems from reappearing

The goal is not simply cleaner data for conversion. It is an operating model that continues to produce reliable data after the new system goes live.

Govern the Data Lifecycle

Not all historical data should be moved into a replacement platform.

Institutions should determine:

• What information must remain operationally available
• What must be retained for legal, regulatory, audit, research, or accreditation purposes
• What can be archived in a separate repository
• What is obsolete, duplicated, or no longer useful
• What should be securely destroyed
• How archived information will be searched and retrieved
• Which privacy, security, and access requirements apply throughout the data lifecycle

Retaining everything can increase conversion cost, security exposure, and long-term storage complexity. Discarding too much can create operational, compliance, and institutional-history problems. Those decisions require governance, not merely technical judgment.

Begin Before an Implementation Creates Urgency

A future ERP or SIS implementation will require decisions about which data should be converted, how it should be structured, who approves it, what historical information must remain accessible, and how information will be governed across the new environment.

Institutions that postpone those questions until implementation will have to answer them under schedule pressure, often while functional leaders and technical staff are already overloaded with configuration, testing, process design, and change management.

Institutions that begin now will reduce conversion risk and cost, improve current reporting, strengthen security and privacy, and enter a future implementation with fewer unresolved institutional questions.

Data governance is therefore not merely preparation for a new system.

It is modernization work that creates value today while making every future platform decision easier to execute.

Reduce Unnecessary Customization

Customizations often begin as reasonable responses to legitimate institutional needs.

Over time, they accumulate.

Some remain essential.

Some compensate for poor processes.

Some reproduce functionality that later became available in the delivered product.

Some exist because “we have always done it that way.”

Every customization creates a future obligation.

It must be:

• Understood
• Documented
• Tested
• Secured
• Supported
• Upgraded
• Recreated or replaced during a transition

Institutions should establish a formal customization review.

For each customization, ask:

• What business requirement does it support?
• Is the requirement still valid?
• Is the functionality now available in the standard product?
• Could the process be changed instead?
• How many users depend on it?
• What would happen if it were removed?
• What does it cost to maintain?
• Would it need to be recreated in a future platform?

The goal should not be zero customization at any cost.

The goal should be to retain only customizations that provide clear institutional value.

Reducing unnecessary customization makes the current environment easier to operate and the future environment easier to implement.

Document Business Processes and Institutional Rules

Many institutions do not fully understand their own business processes until they begin replacing a system.

That is too late.

Processes are often distributed across:

• Policy documents
• Application configuration
• Custom code
• Spreadsheets
• Email instructions
• Individual employee knowledge
• Informal exceptions
• Department-specific practices

A modernization effort should document:

• The current process
• The intended process
• Policy requirements
• Decision points
• Approvals
• Exceptions
• Data inputs
• Outputs
• Responsible roles
• System dependencies
• Known pain points
• Opportunities for simplification

This is not merely process mapping.

It is institutional knowledge preservation.

It also helps institutions distinguish between genuine requirements and habits that have been embedded in the current system.

A future platform should not automatically reproduce every historical process.

It should support the processes the institution actually needs.

Modernize Testing and Release Management

ERP and SIS changes are often tested through informal, inconsistent, or last-minute efforts.

That creates risk in the current environment and becomes a major obstacle during transformation.

Institutions should establish repeatable testing practices now.

These should include:

• Defined test ownership
• Documented test cases
• Regression testing
• Integration testing
• Security testing
• Performance testing where appropriate
• Data-validation procedures
• User-acceptance criteria
• Release approvals
• Rollback procedures
• Post-release review

Automation should be introduced where practical, especially for repetitive and high-risk functions.

Improved testing provides immediate operational benefit and creates a critical capability for any future ERP or SIS implementation.

Address Staffing and Key-Person Dependencies

Many institutions depend heavily on a small number of people who understand the ERP, SIS, integrations, database, or business processes.

That dependency is often invisible until someone retires, leaves, becomes unavailable, or is pulled into a major project.

Institutions should identify:

• Systems with only one knowledgeable administrator
• Integrations known by one developer
• Business processes understood by one functional expert
• Undocumented operational procedures
• Areas dependent on contractors without knowledge transfer
• Skills that are difficult to recruit
• Roles likely to be affected by retirement or turnover

The response may include:

• Cross-training
• Documentation
• Managed services
• Shared support models
• Succession planning
• Process standardization
• Automation
• Targeted recruitment
• External partnerships

Staffing strategy should also anticipate the future.

Even if the institution moves to SaaS, it will still need expertise in:

• Enterprise architecture
• Integration
• Identity
• Data governance
• Security
• Vendor management
• Testing
• Business analysis
• Process design
• Change management

SaaS may reduce some technical responsibilities.

It does not eliminate the need for institutional capability.

Improve the User Experience Without Waiting for Replacement

Students, faculty, and employees should not have to wait years for a better experience simply because the institution has not selected its next ERP or SIS.

Institutions can make targeted improvements now.

These may include:

• Simplifying forms
• Reducing unnecessary approvals
• Improving mobile access
• Consolidating navigation
• Clarifying communications
• Reducing duplicate data entry
• Improving search
• Introducing workflow
• Automating notifications
• Improving knowledge bases
• Adding self-service capabilities
• Fixing the highest-friction processes

These changes may occur within the current product, through surrounding applications, or through process redesign.

The institution should be careful not to create new technical debt through a collection of disconnected short-term tools.

But targeted improvements can provide meaningful value while the larger strategy develops.

Establish Modernization Guardrails

Not every modernization initiative is equally valuable.

Institutions should use guardrails to ensure that near-term investments support long-term flexibility.

A modernization initiative should ideally:

• Reduce operational risk
• Improve security or resilience
• Lower recurring cost
• Eliminate manual effort
• Improve documentation
• Strengthen integration
• Improve data quality
• Reduce unnecessary customization
• Build reusable institutional capability
• Avoid deeper vendor lock-in
• Remain valuable across multiple future platform paths

Institutions should be cautious about investments that:

• Depend on unsupported customization
• Create new proprietary dependencies
• Duplicate capabilities likely to be replaced soon
• Solve one department’s problem while increasing enterprise complexity
• Lack clear ownership
• Cannot be integrated or monitored
• Make future data extraction more difficult
• Commit the institution to a long-term platform decision indirectly

The question should be:

Does this improvement move us forward while preserving our ability to choose?

A Practical ERP Modernization Sequence for Higher Education

Modernization should begin with a focused, near-term infrastructure effort, while broader institutional improvements continue as parallel workstreams.

Institutions do not need to solve every enterprise problem before modernizing the environment. The work can be organized into three coordinated tracks that move at different speeds without waiting on one another.

Track 1: Immediate Assessment and Mobilization

The first track should be brief and practical. In the opening weeks, the institution should establish governance, confirm scope, assess the current environment, validate dependencies, document critical integrations, and identify immediate security or recovery risks.

This work supports the modernization and migration. It should not become a prolonged planning exercise or a prerequisite-filled transformation program.

The institution should quickly confirm:

• The systems and environments included in scope
• Current infrastructure, database, application, and storage requirements
• Critical integrations and external dependencies
• Recovery objectives and continuity requirements
• Security, identity, and network requirements
• Nonproduction environment needs
• Current capacity and opportunities for right-sizing
• Key technical and functional owners
• Testing, cutover, and decision responsibilities

The purpose is to establish enough clarity to move confidently, not to spend months documenting every detail of the enterprise.

Track 2: 14-Week Cloud Modernization and Migration

A properly scoped modernization can move the core ERP environment to public cloud in approximately 14 weeks.

That effort can combine migration with meaningful architectural and operational improvement, including:

• Infrastructure redesign rather than simple server relocation
• Infrastructure-as-Code and repeatable provisioning
• Right-sized compute, database, storage, and network resources
• Automated deployment and environment management
• Improved monitoring and observability
• Security hardening and stronger access controls
• Resilient application and database architecture
• Improved backup and disaster-recovery capabilities
• Automated scheduling of nonproduction environments
• Structured testing, cutover, and stabilization

The result is not simply the same environment in a different location. It is a more automated, resilient, secure, and operationally efficient platform.

Just as important, the migration does not force the institution to select its eventual ERP or SIS destination. It improves the foundation now while preserving the ability to make a different application decision later.

David Kent Consulting provides cloud solutions and migration services designed specifically for Ellucian Banner environments, combining infrastructure modernization with operational improvement.

This is the practical middle path between premature replacement and institutional paralysis: modernize the environment quickly, reduce known risks, and retain strategic flexibility.

Track 3: Ongoing Institutional Readiness

Other improvements can proceed alongside the migration or continue afterward. They should strengthen the institution’s future options, but they should not delay the cloud modernization.

These parallel workstreams may include:

• Integration inventory, rationalization, and governance
• Data ownership, quality, retention, and governance
• Business-process and institutional-rule documentation
• Customization review and reduction
• Testing and release-management improvement
• Staffing, succession, and key-person risk planning
• User-experience and workflow improvements
• ERP and SIS market evaluation
• Long-term decision sequencing and decision gates

Some of this work may be completed quickly. Other elements will continue over time as institutional priorities, staffing, and market conditions evolve.

The important point is that these activities are not prerequisites to modernizing the infrastructure foundation. The institution can move forward with the 14-week modernization while continuing to improve readiness for whatever comes next.

What the Three-Track Model Accomplishes

This approach avoids two common mistakes.

First, it prevents the institution from turning modernization into an enormous, multiyear program in which nothing meaningful happens until every process, data issue, integration, and governance question has been resolved.

Second, it prevents a rapid cloud migration from becoming a superficial lift-and-shift exercise that merely relocates technical debt.

The three-track model allows the institution to:

• Move the ERP environment to a modern cloud foundation quickly
• Improve security, resilience, automation, and operating efficiency during the move
• Continue improving data, integrations, processes, and staffing in parallel
• Avoid forcing a premature ERP or SIS product decision
• Preserve optionality while the market continues to mature

You do not need to solve every enterprise problem before modernizing the environment. Modernize the foundation now, then continue improving institutional readiness while the ERP and SIS market matures.

What Should Not Wait

While many long-term platform decisions may benefit from patience, some actions should not be deferred.

Institutions should not wait to address:

• Unsupported infrastructure
• Serious security gaps
• Unrecoverable systems
• Uncontrolled privileged access
• Critical staffing dependencies
• Unknown integration landscapes
• Poor data ownership
• Expiring contracts
• Major operational failures
• Regulatory or compliance risk
• Unsustainable manual processes
• Costs that are clearly unnecessary

Market uncertainty is not a reason to tolerate preventable risk.

What Modernization Should Accomplish

A successful modernization effort should leave the institution:

• Safer
• More resilient
• Better documented
• Less dependent on individuals
• More automated
• More cost-aware
• Better integrated
• More capable of using its data
• Better prepared for organizational change
• Less dependent on unsupported customization
• More able to evaluate vendor claims
• More flexible about its eventual destination

Modernization is not successful merely because a project was completed.

It is successful when the institution becomes more capable and more in control.

Keep Moving Without Predetermining the Destination

Institutions do not need to know exactly which ERP or SIS they will use ten years from now in order to make intelligent progress today.

They do need to know which capabilities will matter under nearly every plausible future.

Security will matter.

Resilience will matter.

Integration will matter.

Data governance will matter.

Process discipline will matter.

Institutional knowledge will matter.

Testing will matter.

Architecture will matter.

Strong governance will matter.

Those investments are not wasted if the eventual platform changes.

They are what make change possible.

The market may need more time to mature.

The institution should not spend that time standing still.

Modernize what you control.

Reduce the risks you already understand.

Build the capabilities every future path will require.

And preserve the flexibility to choose the destination when the evidence is strong enough.

Coming Next

In the fourth article in this five-part series, we will examine the sequencing of ERP and SIS decisions.

We will identify which decisions institutions can make now, which should be investigated now but decided later, and which should deliberately wait for greater product maturity, institutional readiness, or market evidence.

The goal is not to delay action.

It is to make each decision at the point when the institution has the information, capacity, and leverage to make it well.