Making a List and Doing it Right: The Power of the Checklist

A checklist is often seen as a user’s guide that creates robotic employees, mindlessly carrying out tasks. That is wrong. A checklist is not a sign of weakness nor does it indicate a lack of expertise. A checklist is designed to act as a reference in high-risk situations requiring controls because no one is perfect 100% of the time.

A high-risk situation can occur in any process, from maintaining critical aircraft equipment to generating accurate financial statements. Failure in each could lead to catastrophic consequences. A checklist of critical policies could prevent an aircraft from crashing or improperly reported income on financial statements.

When designed and implemented correctly, a checklist can reduce errors in the workplace that range from miniscule to disastrous. Companies wishing to take advantage of checklists should follow in the footsteps of the aviation industry—one of the first industries to fully utilize the power of the checklists.

Carefully consider audience, content and design when creating a checklist.

Consider the Audience

Designing an effective checklist requires a clear understanding of two things: end-to-end processes and all of the people involved in those processes. Understanding the end-to-end process is easy. Information can be gathered through basic observation and interviews. However, creating a checklist without direct input from the end users will miss steps and could end up being worse than ineffectual—it could actually create problems.

A pilot’s checklist that doesn’t include coordination with air traffic control, flight attendants and ground personnel would create chaos. The same is true of checklists that monitor high-risk business processes or a company’s internal controls.

Communication throughout the processes is key to developing a checklist that everyone will use. End-user training should not be the first time employees hear about new procedures.

Define the Right Level of Detail

The level of detail can quickly ground a checklist before it takes off. A checklist that is too vague or too detailed will either be misunderstood or overwhelming. A checklist needs to be both precise and simple. The right level of detail ensures repeatable success.

There are two basic types of checklists. The first is called a do-confirm. Once a task is complete, the user references the checklist to confirm that the steps were done as intended. In this scenario the user is acting upon experience and the checklist is a simple reminder. For example, a supervisor may review a process to ensure proper segregation of duties occurred before a journal entry was posted in the system.

The second type of checklist, read-do, is for rare or more critical events when steps may be unfamiliar and, if skipped, can be costly or harmful. Considering the criticality and familiarity of events will help organizations decide on the right type of checklist.

Personnel should be performing self-testing on a regular basis to support a robust internal controls environment. A COSO framework-based checklist can be used to ensure proper evaluation of internal controls.

Determine the Optimal Structure

The organization and structure of a checklist is critical. A good checklist will have 5-9 major points. If there are more than nine items, the list will seem too lengthy to use. If there are fewer than five points, the user may not have enough information.

The second key to mapping out a good checklist is locating and placing the pause points. This is the moment when users stop to reference the list, whether to confirm their recent actions or to see what steps are next. Deciding when and where to put the pause points is almost as critical as the content itself. If there are too many pause points, the checklist will not flow. If there are too few, and the likelihood of missing steps will increase.

The aviation industry started a phenomenon when it championed checklists in the workplace. Pilots use checklists daily because they work and help prevent potential disasters. The same can be said for internal control checklists, as a misstatement or audit note may have significant negative impacts on the business. In extreme situations, this could include depressing stock prices or overhauling current management.

How to Prepare for an IT Audit

With the euphoria of going public comes the responsibility and reality of audit boards, SEC/SOX regulations, and public scrutiny of internal policies. When a privately held company goes public, it must comply with an abundance of regulatory requirements. Auditors are required to examine company practices across an organization, including information technology.

IT controls are crucial to protecting the integrity of an organization’s financial data, third party applications, and primary accounting systems. Failing an IT audit could result in reported significant control deficiencies or material weaknesses, directly impacting a company’s valuation, attractiveness to investors, and public perception.

To prepare IT to meet public company regulatory requirements, an organization must assess risk, put a recognized controls framework in place, and establish a tone at top encouraging compliance with controls and ethical practices throughout the organization.

1. Start with an IT risk assessment.

Controls implementation begins with a top-to-bottom risk based diagnostic of the current technology environment. This includes understanding employee attitudes and the use of technology as well as hardware and software capabilities. A risk assessment should result in clear understanding of each risk and include a formalized prioritization process. The prioritization process should be co-developed with the business leaders who “own” many of the risks.

While IT is responsible for maintaining the technology that supports the business objectives, each business unit owns the risks within its purview.

For example, if a company’s controller runs a consolidated financial statement and one of the legal entity’s data is not integrated, accounting is primarily accountable.

The heavy lifting required to perform a thorough and well-documented risk assessment pays dividends when it comes time to write detailed policies and process flows. IT controls and policies serve as the clear and direct solutions to risks identified and are most useful when mapped to specific risks in the assessment.

2. Select the right framework.

IT audit frameworks have been updated in response to the ISASA (Information Systems Audit and Control Association) and the CISA (Certified Information Systems Auditor) technical standards and help clarify their meticulous technical specifications.

The scope of IT audit frameworks can overwhelm smaller organizations. Understand the purpose of each framework, select the relevant components, and build a fit-for-purpose solution best matching your company’s:

  • Historical controls
  • Current size
  • Projected growth
  • Business model
  • Industry and location

For instance, the COSO (Committee of Sponsoring Organizations) framework is strong regarding corporate governance. The ISO (International Organization for Standardization) has a stronger emphasis on risk. Neither framework is perfect for every organization. Depending on the organization’s issues and culture, selecting the right components from each framework should be a consideration.

A comprehensive approach to controls is a better long-term strategy than a rushed or provisional attempt to meet SOX standards. Ensure subject matter experts from the business are consulted, and appoint an IT project manager to supervise the rollout.

3. Tone at the top.

The CIO champions the IT governance process and appropriately engages peers on the management team and within his or her department to enable the process. The CIO’s actions, planning, and communications should provide the link between technology and business strategy. IT staff should understand the controls framework, be able to communicate the governance model and follow established polices.

When the business views IT governance as an enabler rather than a tollbooth, the organization can optimize the use of technology and minimize the control risks.

Implementing control frameworks may seem daunting. Properly implemented controls provide discipline, accountability, and a smooth audit process. Much like checking your tires and oil before a long road trip, IT controls can be a simple discipline that leading to a much safer and more efficient journey.

We’ve Created a Monster! How to Avoid Building a Frankenstein ERP System.

In Mary Shelley’s classic novel, Frankenstein, an eccentric scientist undertakes the bold—yet ill-advised—experiment of reanimating human life. While he succeeds in his endeavor, the outcome is not what he expected and more horrifying than he could have imagined. Dr. Frankenstein is left to deal with the consequences of his creation, and can only watch as the monster destroys everything that he holds dear.

While a poorly designed ERP system will not hunt down loved ones in a murderous rage, the consequences can be painful, significant, and downright miserable. Specifically when implementing a Tier 2 ERP system such as SAP Business One and Microsoft Navision, over-customization and patching a system together with numerous add-ons will almost always lead to a system that is unstable and unpredictable—prone to crashes, glitches, and performance issues. The steps below can help to ensure that your Tier 2 ERP system runs like a well-oiled machine, rather than a disjointed, unnatural monstrosity.

Focus on the Right Requirements

In any ERP system implementation, selecting the right system is half the battle. Many companies fall into the trap of identifying hundreds of “requirements,” most of which are actually nice-to-haves. They lose focus on the two most important requirements of an ERP system: ease of entering transactional data into the system, and ease of extracting data out of the system in the form of reports. Trying to create a system that will meet all of the nice-to-have requirements will often compromise those two most important requirements, and will require some Frankenstein-esque manipulation behind the scenes.

The idea of custom development and a system that is built specifically tailored to a company’s every wish is tempting. However, a general truth about Tier 2 ERP systems is: the more custom development a system has, the more easily it will glitch and break. Over-customization also limits a system’s ability to upgrade, meaning that the company will be stuck with the version of the system they originally purchase and forfeit any opportunity for free improvements in later versions. If a company legitimately does have a large number of custom requirements, they should consider implementing a Tier 1 system, like SAP ECC or Oracle, which allow for and encourage full customization and a ground-up design approach.

Do your Due Diligence with Bolt-On Products

For Tier 2 systems, there seem to be hundreds of available add-on modules, or bolt-on products, which offer functionality the standard system does not offer. While these products are usually built specifically for the base system and offer attractive bells and whistles, they are often developed independently of one another by different partner companies. This means that these add-ons work well by themselves, but may not play well together. When add-on modules are combined without proper due diligence, they have the tendency to step on each other’s toes and break each other’s code.

Add-ons are an important and beneficial part of any ERP System, but companies should work carefully to identify add-ons that are complementary of one another and exercise restraint when deciding how many are necessary. Some of the most valuable add-ons are those that enhance the two central requirements mentioned in point one. For example, a company can find significant benefit from a robust reporting tool, along with an advanced configuration module, which allows customization of the user interface, improving ease of use and user adoption.

Trenegy helps companies select and implement ERP systems that make reporting and analysis easier. The above recommendations can help prevent monstrous ERP behavior resulting from over-customization and a piece-meal add-on strategy.

What is the Right ERP Methodology to Use?

Solve this riddle: A project manager, system implementer, and a third-party developer each create a plan for implementing a new ERP system. Who has the best plan?

A. The project manager, who swears by the traditional waterfall methodology, delivers a 400-row Microsoft Project plan with dates and dependencies for each task.

B. The system implementer, who has never worked outside the Agile Methodology, is not familiar with Microsoft Project, but assigns dates for 3 iterations of development and testing for each key deliverable.

C. The 3rd party developer, who keeps up with annual SCRUM certifications, sets a daily schedule to discuss status updates and roadblocks with weekly milestones.

The answer: D. None of the above.

There is no single ERP implementation methodology that guarantees success. Each methodology— waterfall, Agile, and SCRUM­—has its strengths. However, each has deficiencies that arise in certain phases of implementation. Trenegy blends the best components of each method to successfully complete ERP projects on time and within budget.

The traditional waterfall methodology is a structured practice where progress is made in succession, only upon completion of the preceding phase.

The waterfall approach is the best methodology for identifying project dependencies, planning for necessary business decisions and establishing timelines for gathering requirements, all prior to configuration and development. It is overkill to develop an implementation plan that includes scheduling weekly data refreshes and granting user permissions before training, but when seemingly menial tasks are not accounted for up front, project deadlines will be delayed. In addition to proper planning, the waterfall methodology allows for consistent communication to executive teams on the status of the project.

The waterfall structure is rigid and involves significant upfront planning and requirements definition. Trenegy uses these components of the waterfall methodology during planning and design phases to ensure the implementation team has a clear vision for deliverables before development and testing begins.

Agile methodologies break projects down into tasks, which are completed in short iterations and delivered to stakeholders as packages of functionality. The deliverable evolves with each iteration of development, based on input from users.

Executing an Agile approach requires flexibility and the ability to deliver while operating under constantly changing requirements. Although little upfront planning is required, success is dependent on resource availability from project team members for testing new improvements as they are delivered.

Trenegy applies the flexibility of an Agile approach during construction and user acceptance testing, when there is difficulty prioritizing in a time crunch. Typically, the months leading up to a system go-live are hectic and more work remains than time or resources can keep up with. This method offers the flexibility to adjust scope to preserve budgets and timelines by delivering smaller pieces of functionality, knowing a future iteration for improvement will be necessary.

SCRUM is an even deeper form of the Agile Methodology, designed for rapid development and release updates in short, two- to four-week sprint cycles in order of stakeholder-defined priority.

SCRUM models are highly effective for rapid development and problem solving to address critical issues once the system is live. The first weeks of a system go-live can be overwhelming with busy support lines and a flood of help desk emails. This approach enables the project team to knock out blocks of open items by quickly identifying handfuls of the highest priority issues to fix during the next release cycle.

Trenegy practices the short release cycles and rapid issue resolution frameworks from the SCRUM Methodology during post go-live support. With this approach it is imperative to keep an up-to-date issues log to review during regularly scheduled sprint planning sessions. Reprioritizing improvements and sticking to defined release schedules is key.

There is no such thing as a one-size-fits-all methodology, but there is an optimal way to use each of the various implementation methods. Trenegy’s extensive ERP experience allows us to leverage the advantages of each to ensure successful go-live.

Why the Onboarding Process Matters and How to Make it Better.

Whether the oil and gas industry is booming or declining, organizations consistently shortchange the onboarding process. Many companies have abbreviated onboarding to a half day of skimming the employee handbook and receiving appropriate badge access.

This approach cheapens the new employee’s understanding of the company vision, compliance culture and performance expectations. It is critical for new hires to have immediate and meaningful exposure to the key components of a company’s culture, particularly regarding policies and controls.

With the right amount of planning and with limited but focused efforts, onboarding more than pays for itself in confident, loyal employees who understand the company’s culture and policies.

Why do it?


In highly regulated areas like SOX for financial reporting, compliance is non-negotiable. Public companies must ensure all new employees are aware of industry and company controls and are committed to abiding by defined policies. The financial investment in onboarding is preferable to receiving a significant deficiency or material weakness.

Accelerated Learning

Documented desk procedures will allow a new employee to move quickly up the learning curve. Well-written desk procedures boost a new employee’s productivity and will save experienced employees from spending significant time handholding.

Future Investment

Employees who have a clear understanding of job expectations can focus on delivering results rather than trying to learn job activities. An intentional and well-planned onboarding process can easily be repeated across functions with minor changes.

Key Components:

1. Desk procedures. A successful onboarding program includes detailed, current desk procedures. The procedural should include step-by-step explanations of the process the employee participates in. Process flows, roles and responsibilities, delegations of authority, controls and policies will all be included or referenced in well-written desk procedures.

2. System training. A new employee must understand how to perform his or her job tasks within the appropriate systems. How is an invoice entered? Where are particular contracts located? How are the required reports for month-end close run? What constitutes a hard error versus a soft warning, and what should an employee do in either case?

These questions should be clearly answered in system training documentation. Furthermore, a new hire’s supervisor, armed with clear training and defined training documentation, should be well-prepared to train staff in the systems.

3. Team introductions. New hires need a casual – but purposeful – introduction to the immediate team. This seems obvious, but many companies fail to encourage team leaders to build departmental camaraderie. Contrary to an isolated employee, an engaged team member makes a loyal employee.

4. Cross-functional understanding. A successful onboarding program includes cross-functional exposure. New employees must understand their roles within the immediate function and within the organization. Opportunities for cross-functional understanding come from lunch-and-learns, town hall meetings, and other cross-department sessions. A new hire should be made aware of these opportunities and encouraged to attend.

Onboarding is not an optional G&A expense, a mysterious formula or a waste of resources. With intentional planning and focused effort, onboarding is a simple, clean, repeatable process which wins the company enhanced controls compliance, increased return on employee investment, and loyal staff.

Making the Most of Your Controls Environment

Twin boys, one an optimist and the other a pessimist, awake Christmas morning with gifts in their bedrooms. The pessimist walks up to a pile of toys in his room and is irritated. “Do I have to read the instructions?” he wonders. “My friends will be jealous. The toys will break.” The optimist finds a pile of manure in his room and exclaims, “There has to be a pony in here somewhere!”

Public company executives often find themselves looking at the mounds of regulatory requirements created by Sarbanes Oxley and the PCAOB with disdain.

While mounds of manure are a reality, there is a pony!

A SOX 404 implementation program can be managed in such a way to gain organizational efficiencies and achieve more effective processes.

Eliminate Waste. During a controls and process mapping exercise, it is important to understand the purpose of all the steps in a process. Many fast-growing companies inherently have bad processes in place that worked for a small company.

A large oilfield services company spent an inordinate amount of time physically matching vendor invoices to checks for the Controller’s signature. This served the company well when they were small. As a larger public company, this was wasteful and did not serve a purpose. By implementing more efficient controls in the disbursement process, the company eliminated the paper matching process. Do not be afraid to look for ways to eliminate waste as a part of the SOX 404 implementation or review process.

Set Guiding Principles. The transition to the 2013 COSO framework implies a more robust and daunting control environment. Developing a set of guiding principles for the organization and each of the business functions links policies to strategy and sets the foundation for an effective control environment. Guiding principles capture intent, establish the tone from the top, and rally the organization toward implementing the right control activities.

A mid-sized exploration and production company used guiding principles as a motivation tool and a way to give each function a sense of purpose and identity in the new environment. The control, monitoring and risk management activities and policies were then tied into the guiding principles to ensure a common tone was established and integrated.

Integrate Risk Assessment and Planning. The mere sound of conducting a risk assessment wreaks drudgery. The risk assessment process should be integrated with the business planning process. One seamless, forward-looking process is more efficient than two separate processes.

A product of the business planning process is a financial budget for the upcoming year. Why not also make the risk assessment a product of the planning process? A public midstream company integrated the risk assessment with planning and budgeting and only added a week to the entire four-month planning and budgeting process.

Companies have no choice but to address the mounds of regulatory requirements to comply with SOX and SEC expectations. Why not use the compliance process to improve other processes in the organization?

Going Global: Overcoming Challenges in International ERP Implementations

An increasing number of today’s international companies recognize the benefits of connecting the entire organization through one accounting and operational platform. A global ERP system eases the pain of consolidated reporting, increases the speed at which the company communicates, provides innumerable efficiencies in terms of global master data, limits dual-data entry, and simplifies the intercompany transaction process.

However, with the many benefits of a global ERP system come the challenges inherent in launching an ERP system across borders, oceans, and cultures. The most common and significant challenges encountered during a global system implementation are outlined below.

1. A Global System Requires Global Support

The need for round-the-clock system support for offices overseas is often overlooked in a centralized company. Companies with centralized IT support underestimate the frustration employees across the world feel when waiting hours for assistance. If end users experience technical difficulties or are stumped by system functionality for hours at a time, productivity drops and the company loses money. Lack of support damages user acceptance and encourages “neglected” users to devise external, and often detrimental, work-arounds.

Companies launching a system overseas should be prepared to have on-site support in each regional office for two-three weeks prior to and post-go-live. Long-term, companies should offer at least one full-time system support expert in each time zone. System support experts can be new employees hired for the express role of system support, such as business analysts or system administrators. Alternately, existing employees can be identified as “superusers” during design and training. “Superusers” should be employees who demonstrate a strong understanding and comfort level with the new system and a knack for helping other users learn the system. At a minimum, there should be one system support expert in each hemisphere to ensure an increased overlap of business hours.

2. Don’t Bite Off More Than You Can Chew: Regional Rollout vs. Big Bang Theory

Many companies are overly eager to launch a new ERP system globally and are tempted to opt for the “big bang” approach to go-live, meaning all regions flip the ON switch at one time. This approach does offer benefits such as cost-savings, high levels of enthusiasm and momentum, streamlined processes and training schedules, and consolidated reporting efficiencies. However, companies should elect this approach with one key caveat: only go for “big bang” if you have the resources to support it.

Companies should only attempt the “big bang” launch if they have a large enough implementation team to put people on the ground in each region for go-live. In the vital weeks of training prior to launch and the critical weeks of operation post-launch, one of the most essential requirements is responsive, competent, and timely support. Without it, user adoption will suffer and the new system and its processes will struggle and eventually fail.

A company with a smaller implementation team is better suited to launch using a regional rollout model, which ensures one region is relatively self-sufficient before rolling out the next region. This phased approach usually means a longer timeline and increased implementation cost, but it mitigates the risk of launching everything at once and experiencing global failure because the implementation team’s attention and effort was spread too thin.

3. Be Aware of Cultural Differences and Leverage Them Wisely

One of the joys of working on international projects is making connections with people around the globe—appreciating similarities and learning cultural differences. Generally speaking, Westerners are generally less hesitant to express dissent, disagreement, or dissatisfaction. Companies should be aware of this tendency during the system design phase of the implementation and strongly encourage Eastern offices to contribute system requirements and design suggestions. An effective way to encourage this is to approach the system blueprinting as a collaborative effort instead of, “tell us everything that is wrong with the current system.”

End users in Eastern countries are often quicker to rely on training manuals and self-troubleshooting before reporting an issue. Conversely, end users in the West are inclined to reach out to system support immediately upon encountering an issue. Because of this dynamic, it is a best practice for companies to begin regional rollouts starting in the Eastern Hemisphere and progress west. The East’s propensity toward self-sufficiency means that they usually require less intensive post-go-live support, which will free up the implementation team to focus on the next regional launch.

In an international implementation, the increased size, scope, and complexity of the project increase the likelihood of complications. Trenegy has helped companies successfully implement ERP systems around the world.

7 Keys to ERP Implementation Success

System implementations are complex projects demanding much of an organization’s time, energy and resources. Companies desire projects of such magnitude to be done on time, one time, within budget and done well. As a consulting firm, Trenegy has witnessed companies go through system implementations with great success and great failure.

So, how does a company avoid becoming another failed system implementation statistic? Seven keys to implementation success are as follows:

1. Build Organizational Support

Organizations are often resistant to change, or at least hesitant. Create a groundswell of support for the new system by explaining to employees at each level why the change is beneficial. Executives can benefit from the support ERP systems provide to acquisition growth. Revenue accountants will have the opportunity to clean up data and streamline prior period adjustments. Operations will have access to timely production data and accurate lease operating statements.

Creation of a well-rounded implementation team is vital for organizational support and project success. The project team must have the right skill set and decision-making authority. Large-scale system implementations require a team of devoted project members who are committed to making the implementation a success. These members should have the right skills, a strong work ethic, and the ability to see the project to completion.

Subject Matter Experts (SMEs), such as the assistant controller or land manager, are also critical to change management and project success. SMEs are critical decision makers. They know where the business is going and can provide insight to ensure the system will meet future needs. Their knowledge of potential acquisitions and projected growth is invaluable. It is important for them to be aware as critical decisions are made throughout the project.

2. Understand Business Process Requirements

Automation applied to an inefficient operation will magnify the inefficiency.” –Bill Gates

In order to implement an effective system, an organization’s business process requirements must be clearly laid out, step by step. Initially, this requires asking the right questions, such as: What does the current process look like? How could it be improved for the future? What information is needed to quickly and successfully create an improved process? Specifics are important so processes can be revisited as little as possible. General ideas are subject to uncertainty, which leaves system implementers guessing.

This is where process flows come in handy and make understanding specific requirements easier. It is crucial to capture which steps occur before and after the process as well, because that heavily influences the process itself. Seek to understand what the process currently looks like and what changes need to be made to make it more efficient in the future.

3. Identify Critical Reporting Requirements

The importance of defining critical reporting requirements at the outset of an implementation cannot be overstated. Reporting is derived from the Flexible Business Structure— the backbone of data organization.

To create a system that pulls clean reports, an organization must predetermine the data hierarchy. Will budgeting occur by region or business unit? It is important to determine a standard method of booking certain costs. For example, management may decide that lease operating expenses (LOE) should be booked at the lowest level of detail (i.e. completion instead of well) to provide a greater level of accuracy in reporting.

Maintaining the integrity of the data model, reporting hierarchies and KPIs ensures that management reports will be consistent over time, giving decision makers valuable insight into performance trends.

At this stage, it’s important to take into consideration the trajectory of the business. If growth through acquisition is planned, understand that budgets and reporting views will need to accommodate additional divisions and support more transactional data.

4. Cleanse Data Prior to Conversion

The purpose of an ERP system is to provide accurate, timely and insightful reporting that helps managers and executives make better decisions. Clean data is needed to make the most efficient use of a system. Without clean master data, executives lack reporting confidence and are tossed back to square one: making business decisions with inaccurate information.

When critical master data comes from systems that are not integrated, major errors are prone to occur during data cleansing and validation. Merging master data requires experienced oversight and coordination–especially when different business functions own the systems being merged.

5. Practice, Practice, Practice

It is important to create training tools specifically designed for each organization. Standard technical documentation alone is not enough; it often leaves employees confused and frustrated. Tailoring training materials to the organization prepares employees to confidently acclimate to the new system.

Developing a training strategy that will facilitate learning and produce a change can be challenging. Training must be completed in a way that resonates with the audience and speaks to their learning style. What works for one person might not work for everyone.

Before the system is fully implemented, users should receive a broad overview of the system to become familiar with the interface. Then, prior to go-live, training sessions should be held specific to each function. Simulation training is more in-depth, as a system expert sits side-by-side with users to walk through daily processes.

However, it is unlikely that every possible scenario will be covered in training. Training should focus on critical elements and common scenarios. Training provides employees with the initial tools they will need to understand the system.

 6. Communicate Major Decisions

Too often, companies get into trouble by failing to document decisions, only to unnecessarily revisit them later. This ultimately results in rework and delays. Often, those affected by these decisions were not involved in the decision-making process.

Decisions should be clearly communicated and documented in a log maintained by the project manager. SharePoint is helpful for clearly recording when, why, and by whom decisions are made, as well as resulting task lists. These decisions should only be revisited when business changes require the project team to change course.

7. Motivate Your Team

System implementation is hard work! It can be easy to get tired and impatient, so keeping team members motivated is vital. Sitting together in an open room can keep teams energized and in constant communication. Urgent issues can be discussed immediately and when a problem arises, the entire team is aware of it. High cubicle walls and individual offices create physical and communication barriers.

There is value in ensuring project team members are able to get to know each other and relate on a personal level beyond a work environment. Knowing someone’s name and job description is one thing, but understanding their personality, learning style, and how they best relate to others lays the foundation for a more cohesive team. The most successful projects are completed by cohesive teams who communicate well, work hard to complete the tasks at hand, and share a common goal of seeing the project succeed.


Your ERP System is Live. Now What?

Congratulations! The ERP system you spent thousands of hours and millions of dollars on over the last twelve months is now live. If the proper implementation approach and project management methodology was applied, then this arduous task was completed on time and on budget.

So it’s smooth sailing from here, right? Unfortunately not.

There are a number of post-go-live challenges inherent in releasing a new ERP system, which will quickly derail the system’s launch if not addressed. The most common challenges are: project team burnout, limited end-user knowledge of the system, enforcing the data governance plan, and handling the myriad questions from end users.

Your organization can carry the successful implementation forward by following these steps:

1. Recognize and reward effort. The best employees from each department across the organization have spent nights and weekends building, testing and priming the system for go-live. The final weeks leading up to go-live can be the most challenging, and this same group will be heavily relied on to lead and support the organization during the first few months post-implementation.

Recognize the real, negative consequences of employee burnout and work to prevent its impact by:

  • Understanding the workload required to complete the tasks assigned to each individual.
  • Identifying supplemental resources early on.
  • Creating a clearly defined incentive plan before the project kicks off.
  • Rewarding each team member accordingly. Additional vacation days can be as valuable as cash or equity.

2. Keep training. User acceptance is a predictable challenge. Help users understand why and how the system operates to improve acceptance rates. Yes, there were a number of training sessions conducted before go-live, but those sessions alone will not suffice to prepare end users for day-to-day system tasks. More often than not, end users find training sessions held three to four weeks (a complete business process cycle) after go-live the most beneficial.

Post-go-live training sessions with participant-driven agendas are the most effective. This allows the trainer to focus on addressing the process steps and system functionality the user group is most concerned with. This approach will also increase attendance, as users will feel a sense of control over the utility of the training session.

3. Set up governance. Eight or nine months have likely passed since the process owners came together for design sessions and agreed to improve process efficiency and data quality through cross-functional collaboration. In reality, that cooperation will not be so easy to maintain once the system is live—a governance model for managing process changes must be in place.

However, the governance model should not be convoluted or overbearing. Create standard forms and workflows to approve proposed changes (e.g. new account, account structure change, new vendor, etc.) to help manage these requests. Ensure that proper security is applied and maintained to help eliminate rogue changes.

4. Create an issue resolution process. Regardless of how thorough the test plans or how diligent the testers, issues will arise post go-live. You must be prepared to manage and address them. The majority will be quick fixes, but a handful will impact closing the books or paying a vendor.

Establish a process to prioritize, resolve and communicate post go-live issues. Provide users with an easy way to submit issues and keep them in the loop as technical changes are made. Managing this well prevents users from working outside of the system or falling back into old routines.

Trenegy helps companies successfully manage ERP implementations all the way through go-live support. We help our clients get value of out their new system quickly and relatively painlessly. Read how to properly prepare an E&P company for implementation in our recent publication: E&P Company Systems: 4 ERP Implementation Land Mines to Avoid.