ERP Project 101: Organizational Fit Gap

I think we can all agree that organizational fit is a key consideration for successful ERP selections and implementations.  However, mention the phase “fit/gap” or “gap analysis” and most people will fixate on the ERP software.  There are several examples of functional/software fit-gap templates/activities but very few organizational fit-gap templates/guides.  The goal of this blog is to shed some light on this very important activity.

 What is an Organizational Fit/Gap?

An organizational fit/gap analysis is a comparison of the customer’s existing organizational model that supports the business to the defined organizational model supported (or assumed) by the ERP system.  Consider the following illustration: 

Org Gap Analysis

Organizational Fit Gap Analysis

If you do not know what is changing in the organization then how can you manage organizational change?  Too often I see ERP projects only focus on the “To Be” model and expect business users to figure out how to transition. I have also observed that customers see organizational change activities as an opportunity to reduce implementation costs by performing the activity themselves – regardless of their capabilities. 

In order to effectively conduct an organizational fit/gap analysis there are two key sources of information that are required: 

Information   Source Comments
Customer’s Organizational Structure and Business   Processes A   majority of peers and customers believe that this exercise is a non-value-add activity given the imminent organizational change that will occur as part of   the ERP implementation.
ERP Business Process Maps Consider   ERP business process maps as a demonstration by the ERP vendor to show how   their ERP software supports business processes.

Just as you perform a formal Fit/Gap analysis on ERP functionality you should also consider performing a formal organization Fit/Gap analysis as illustrated below:

Organizational Gap Analysis for ERP

Template to identify possible organizational changes based upon predefined ERP roles/responsibilities

An organizational fit/gap analysis should be performed during the ERP selection stage and refined during the early design stages of the ERP implementation.  Do not limit yourself to performing this exercise only once.  The analysis performed during an organizational Fit/Gap will drive future decisions and implementation activities.

What Activities should an Organizational Fit/Gap Influence?

The organization fit/gap analysis will have a direct impact on your organization change management plan and communication plan.  In addition, this analysis will provide insight into user security requirements.  Utilizing this approach will highlight how well the predefined ERP user security profile(s) align to the organization’s existing users.  As a general rule, the majority of predefined ERP workflows are based upon predefined user security roles; therefore keep in mind that ERP user security profile changes may require additional testing for related ERP workflows. 

Why Do We Need a Formal Organizational Fit/Gap?

Conducting a formal organizational fit/gap enables you to quantify the level of change.  Instead of taking a broad stroke at managing change you can provide a focused effort to accomplishing your objective. Remember that people are the most important component of a business solution.  Given the importance I believe that formalizing this activity is worth the investment.

Summary

Predefined ERP implementation tools, templates, roles can provide limited value to an implementation.  Too often the ERP market wrongly perceives that these predefined components result in faster implementations.  This misconception is most pronounced in the ERP SaaS/Cloud arena.  At the end of the day, an ERP implementation should only move as fast as the customer can handle the change.  Conducting a formal organizational fit/gap can enable the customer to adapt faster by focusing on the specific changes required for success.

Troubleshooting ERP Projects

During my career in ERP consulting I  had several opportunities to be involved in deployment of emerging ERP products and services.  As with any innovation rollout there are challenges to overcome and I had to learn how to quickly triage ERP projects for success.  Troubleshooting an ERP project is more than just performing an assessment – it’s implementing a realistic action plan and making it work for all stakeholders involved.   Following is a tested and proven approach to jumpstart stalled ERP projects.

Method

Similar to a Forest Fire Hotshot I typically got dropped into a “hot” ERP project that had stalled or had serious show stoppers.   Time is always against you.  However, you must first put in the effort to objectively understand the situation and establish your credibility:

Troubleshooting ERP Challenges

Troubleshooting ERP Projects

Too often I see project managers jump into the details (WBS, Risks, Issues, CPI, SPI, Cost) without first understanding the context.  You cannot be perceived as a busy body looking for who dropped the ball.  Vendors, Customers, and System Implementers are made up of people.  People make mistakes – especially me.  People don’t care what you know until they know you care.   It will be people - not technology – that will play the biggest role in getting the ERP project back on track.

Before hitting the ground running you first need to do your homework.  As part of an ERP assessment it is important to review the key project artifacts generated and updated throughout the project.

Key Project Documents

Key Project Documents

This is the easy part and it is usually a simple process to review and evaluate.  If a project scope statement does not exist or is not well-defined then chances are this absence is contributing to the problem.  Creating or refining the project scope statement is a very small part of the action plan you need to execute.  Now, let’s turn our attention to the implicit artifacts and information that are harder to identify and resolve.

Understand the Underlying Drivers

ERP vendors,  System Implementers (SIs), and Customers want their ERP implementation to be successful.  Yet there are fundamental drivers for each stakeholder  appears to be in contradiction.  Consider the following illustration:

ERP Stakeholder Implicit Drivers

ERP Stakeholder Implicit Drivers

Understanding the fundamental drivers of your stakeholders enable you to relate, empathize and align the efforts of all project stakeholders.  It is important to note that you need the efforts from ALL stakeholders for success – regardless of who is at fault.  I humbly submit that it is extremely rare when a single stakeholder is responsible or is at fault.  On the flip side it is even more extreme to have a single stakeholder solely responsible for saving the day.

Strategy & Execution

It is a straight-forward exercise to develop a plan for troubleshooting an ERP project but providing a plan by itself does not add business value.  How you execute and implement the plan is more important than the plan itself.  Many of my project management colleagues may not agree with my assessment but I am  convinced that this is true.  Following are my guiding principles for ERP troubleshoot efforts:

  1. Create quick wins.  Triage is required to stop the bleeding.  You need to quickly seize the initiative  and  create positive events.
  2. Attack problems from multiple angles.  If you have one approach get stonewalled you still have other ongoing activities to continue the march forward.  This means that you have contingency plans in flight.  Be aggressive.
  3. Triage is not the time for lessons learned.  There will be opportunity for reflection after the immediate problem(s) have been addressed.
  4. Problem solving is not about assigning blame.  You need every individual to have laser focus on resolving the problem and not on how to protect them own interests.
  5. All stakeholders must be willing to stretch outside their comfort zone.       Customer and vendors limit their response based upon contractual arrangements.  Partners think outside the box for mutual success.
  6. The answer lies within the team.  Many times the greatest impact you can have is to enable the  key players to recognize the solution. Communication skills will be vital to your success:
Communication Skills

Survival Skill – Communications

Summary

There is a fair amount of information available in books, articles, and blogs related to avoiding ERP problems and I agree that you should take reasonable steps to minimize known ERP problems.  However, I believe that it is prudent to be prepared for the “unknown unknowns” that always occur with any ERP project.  Troubleshooting ERP projects require process knowledge of project management fundamentals, problem solving techniques, and most importantly – perseverance.  Just like the rudder steers the ship, finding small success(es) can get your ERP project back on the path for success.

BPR, BPM and ERP

I had a customer ask me about the relationship between BPM and ERP.  Does ERP implement BPM or do you need to have BPM before ERP?  Is an ERP implementation a BPR project?  Who’s on first?  As the ERP industry evolves it has become evident that additional disciplines like Business Process Management (BPM) and Business Process Reengineering (BPR) must be employed for a successful ERP experience.  In the following blog posting I plan to define and demonstrate the roles that BPM/BPR play in the ERP lifecycle.

BPR, BPM, and ERP Revisited

Allow me to establish some basic definitions for our discussion:

  • Business Process Management (BPM) consists of methods, techniques and tools to design, deploy, control, and analyze operational business processes involving humans, organizations, applications, documents and other sources of information.
  • Business Process Reengineering (BPR) is the redesign of business processes – and the systems, policies, and organizational structures that support them – to optimize the work flows and productivity in an organization.
  • Enterprise Resource Planning (ERP) is integrated business software that supports multiple business functions across an enterprise.  ERP implies the use of Commercial Off-The-Shelf (COTS) packaged software rather than proprietary software written by or for one customer.

There are a couple of key concepts we should review to compare/contrast BPR and BPM.

Compare BPM and BPR

Compare & Contrast BPM & BPR

BPM focuses on the business process model to monitor, identify, and implement incremental improvements.  These improvements or eliminations fall within the fundamental rules, parameters, and culture established by the existing business model.  However, there comes a point in time where the law of diminishing returns applies and a transformation to the underlying business model is required.  A more aggressive approach like BPR must be utilized to evolve to the next level of business process maturity.  Consider the following illustration to demonstrate how BPM and BPR interact along the Capability Maturity Model Integration (CMMI):

 

BPR, BPM within CMMI

BPR, BPM within CMMI

Allow me to provide an example.  Company A performed a CMMI assessment of their purchasing process.  Results from the assessment showed that the purchasing process was defined for certain business sales (revenue stream) but not for all purchasing events (direct & indirect).  Another key finding was that there was no formal integration between demand planning, supply planning and purchasing which resulted in reactive purchasing. From the above CMMI reference, it was determined that Company A’s purchasing process is at the Managed level.  Company A implemented several incremental initiatives (BPM) to improve process execution including documenting purchasing tasks for all purchasing events and conducting periodic purchasing planning meetings with operations. 

Company A realized process improvement yet the value was limited by following model constraints: (1) each revenue stream (business line) had its own unique purchasing process & rules and (2) Purchasing had limited visibility across the entire supply chain.  Two fundamental mindsets have to change:

  1. Move from unique purchasing processes to a common enterprise purchasing model that is flexible enough to address the competitive requirements for each business line
  2. Enable Purchasing to have visibility across the entire supply chain to support a process-oriented management model versus a function-oriented management model.

Implementing these changes will require a formal, projectized (BPM) effort that will redefine existing business rules, culture, and business process activities.   As Company A continues to evolve their purchasing process they will conduct both BPM within the CMMI maturity level and BPR as they move to the next CMMI maturity level. 

How Do BPR, BPM, and ERP Relate?

ERP provides the automation of business activities.   There are two fundamental value propositions that ERP provide to customers looking to move up the CMMI maturity model

  1. ERP reduces the effort required to perform tactical business activities so customers can focus on strategic activities. Expanding on our purchasing example, this would include basic functionality like automating the creation of purchase orders, approving purchase orders, and matching purchase orders with receipts & supplier invoices.
  2. ERP provides the opportunity for visibility across business functions to support business process management.  That said, there are several factors that determine the level of visibility. 
ERP Business Process Visibility

Factors Impacting ERP Business Process Visibility

A competent ERP solution should provide robust, closed-loop integration between the functional modules provided out-of-the-box.  As a practical note, there is always a need to integrate ERP to legacy systems and this requirement should be not overlooked.  A business solution is only as good as its weakest integration.  Process consistency will enable a relevant comparison of results and management of business processes.

A mature ERP solution should provide automation and integration support for both tactical and strategic business activities across the CMMI model.   

ERP Evolution within CMMI

Interaction of BPR, BPM, and ERP within CMMI

I am a firm believer that business should lead and technology supports.  Therefore, as the business model evolves it is important to identify the corresponding ERP functionality to support the business activities.   This model also communicates that the best approach to implement ERP is to follow a logical maturity path for business processes.

Common ERP Misconception and Mistakes Related to BPR & BPM

Allow me to address some common misconceptions and mistakes made during ERP implementations related to BPR and BPM.

BPR is part of the ERP implementation.

While I agree that the initial ERP implementation will result in major changes with existing business functions, BPR will not happen unless there is a concerted effort to redefine the holistic business model and organizational structure to be successful with the ERP software.

Implementing ERP will give us BPM.

The direct answer is no.  ERP does provide an information foundation that can support BPM.  BPM is more about a discipline for managing processes and less about software. 

Do I need ERP to mature my business processes?

Technically speaking, ERP is not a hard requirement for BPM.   However, manual routine tasks and limited visibility hinder strategic activities.  ERP can play a key support role in automating business tasks and provide visibility through integration.

Should I implement ERP features that support business activities at different maturity levels?

Business realities will necessitate that customers implement ERP features supporting different CMMI maturity levels.    The problem lies in two areas:

  1. Customer expectations are not appropriate set regarding the limited value realized from mature ERP functionality due to less mature business activities supporting strategic activities.  Example:  A procurement process scorecard measuring standard Key Performance Indicators (KPIs) will have limited value if there is not a standard, enterprise procurement process.
  2. Implementation partners and business solution advisors should provide a short-term strategy and roadmap to evolve the supporting business activities to same level of maturity.   This approach provides a “quick-win” opportunity for customers to drive additional value from the existing ERP investment.

Summary

Understanding how BPR, BPM, and ERP should relate to one another can be a challenge.  Some believe that it is an “either or” proposition.  I do not subscribe to this school of thought but rather believe that BPR and BPM are disciplines that should be interweaved as part of your ERP application strategy.  Knowing and appreciating these interdependencies will put you in a better position for ERP success. 

Business to IT Alignment – A Practical Discussion

Business to IT alignment is an objective that most technology and business leaders would agree as essential for agility.  However, ask for a definition of Business to IT alignment or how to implement an alignment strategy and the likely results are conflicting information and vague guidance.  In the following blog I will try to add clarity to this topic as well as provide practical guidance.

Definition

Let’s start with a basic definition of Business to IT alignment by addressing some common misconceptions.  Business to IT alignment is far more than just Project Portfolio Management (PPM).  Business to IT alignment consists of several domains:

Knowledge Map for Alignment

Business – IT Alignment Domains

Several Tier I & Tier II ERP software vendors provide software solutions to address certain Business to IT Alignment requirements, including PPM and Communications (social collaboration).  However, it is important to remember that technology alone is not the answer.  Collaboration tools can be used to generate more noise than effective communication.   Also consider that having strategic initiatives stored in a common platform (ex. PPM) does not mean the all stakeholders share a common interpretation.    

Just as Business – IT alignment is more than just PPM, enterprise governance is much more than just IT governance.  In simple terms, enterprise governance is a process that ensures that enterprise capacity (Business, Operations, IT) are working on the right things at the right time to enable business goals. It’s a set of guidelines that focuses on organizational success while managing associated risks.  Alignment is hard to achieve when governance is not consistent across the enterprise.  Knowledge transfer is the most underestimated and misunderstood area.  Effective knowledge transfer is more about education and trust than software and templates.  Before one can be successful with Business – IT alignment it is important to fully appreciate the scope and breadth of effective alignment.  A viable alignment strategy must address the key challenges listed in the next section.

The Challenges of Business to IT Alignment

Consider the following alignment model.  This is a very simple model that I would like to use for discussion purposes.

Governance Model

Business – IT Alignment Governance Model

Allow me to highlight some key challenges associated with the traditional alignment model provided.  First is the notion that Business and IT operate separate silos.  Notice in the example above that there are separate Business and IT goals.  Thus, there must be an exercise to reconcile Business goals and IT goals to identify commonalities and gaps.  Practically speaking, given the level of effort required to align these separate strategies, a reasonable conclusion is that alignments occur periodically based upon corporate milestones.  This is where the model breaks down because effective alignment must be a daily activity.  Every business request from strategic initiatives to daily support tickets is an opportunity to reinforce alignment.  Another possible concern implied in this model is that the majority of alignment effort happens at the enterprise level.  Sustainable alignment must happen at every level within the organization.

A results-oriented alignment strategy must address the inhibitors of alignment.  Consider the following relationship between alignment and communication:

Alignment and Communication Inhibitors

Alignment and Communication Inhibitors

Success alignment requires successful communication.  Successful communication requires the effective use of all the key communication skills

Key Communication Skills

Key Communication Skills

Process is important but the soft skills like communications, emotional intelligence (empathy), and knowledge transfer will have the greatest import on long-term alignment success.

Practical Steps to encourage Alignment

Before you can start implementing practical steps you need to assess the level of alignment within your organization.  The Strategic Alignment Maturity model referenced below was developed by Dr. Jerry Luftman and is based upon the Capability Maturity Model Integration (CMMI).

CMMI - Strategic Alignment

Strategic Alignment Maturity

Once you have identified your current maturity level then you can devise realistic, increment steps to move forward to the next maturity level.  It is also important to periodically assess your organization’s alignment.  What gets measured gets done!

Summary

Why is Business to IT Alignment so hard? Consider the following statements to highlight  the key challenge with alignment.

Business vs IT Value Perspective

Business vs IT Value Drivers

Is Business to IT alignment an impossible goal? No, as long as a practical, measured approach is taken to achieve tangible results.  Business to IT alignment is a strategic goal that can only be reached by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust. When alignment is achieved communication is effective resulting in valued partnership.

Progressive Leadership for ERP

Knowledge transfer is only the beginning to enablement.

Many implementation partners (including myself) have handled enablement as an event or milestone that occured as part of the cut-over to production.  We as implementation partners too often assume that the traditional, informal “do what I do” approach between consultants and customer was sufficient for customer enablement.  If the traditional approach was sufficient for customer enablement then one can argue that there should be no need of post production support. 

When ERP software is implemented in a production environment it is usually the first opportunity for the customer to lead in the support of a new business solution.  For the majority of customers that do not have hands-on experience with supporting external packaged software this can be a difficult challenge.  Customers typically ask their implementation partners to provide post-production support until the customer has confidence in their business solution support (technical, business) capabilities.  

There is a better way.  An approach that will more effectively provide the knowledge, experience, and capabilities the customer requires to be self-sufficient.  This enablement must be completed and validated during the implementation.  There will be less need for post production support to address the enablement gap for customers.  Let’s elaborate on one of the key processes that will prepare the customer to lead during the implementation.   

 Progressive Leadership Style

A key competency for any implementation partner is their ability to enable the customer to support and manage the new ERP software.  This will require the implementation partner to employ different leadership styles during the implementation.  There should be a logical progression in leadership styles that naturally transfers ownership from the implementation partner to the customer.  We will use the following illustration for our discussion.

Customer Enablement by Project Management Leadership Styles

Leadership Styles

Let’s discuss each leadership trait in more detail in the context of an ERP implementation life-cycle. 

  1. In the early strategy and planning stages of an implementation the implementation partner should use a directive leadership style to lead the customer.  The implementation partner leads in setting the direction and the pace of the implementation. 
  2. As the customer is educated on the packaged software and implementation approach the implementation partner moves towards a coaching leadership style to enable to customer to take a more active leadership role in the packaged business software implementation.
  3.  With the facilitating leadership style, the implementation partner has moved from an active leadership role to a passive leadership role.  The customer is leading and managing the implementation project.  
  4. The supporting leadership style is the final stage where the implementation partner provides what I’ll call ad-hoc/as needed support & guidance. 

 Summary

The first day of any implementation is the first day of transition from the implementation partner to the customer.  Many treat transition as a last step in a go-live event.  This approach results in customers not being ready or confident in supporting their business solution.  A customer should never feel that way!  Allowing the customer the lead will naturally drive the implementation partner to be more focused on knowledge transfer to the customer and results in better success rate for customer preparation.

Key Project Management Strategies for ERP implementations

I had a colleague ask me what are the key project management strategies for successful ERP/COTS implementations. I laughed and told my friend that I’m still learning! My friend is an experienced, certified project manager (PMP) so I spared him the foundational best practices (approved project charter, executive support, risk management, communications, etc). These core best practices are well known and documented. I wanted to go to extra mile and provide advice that may not be well known or understood. Following are the key strategies that drive my project management approach for ERP/COTS implementations:

(1) FOCUS

Need to have a clearly defined scope. This includes (a) what’s in scope, (b) what’s out of scope, (c) and who is doing what. Just as important to scope definition is to define constraints and assumptions. Example: for packaged software implementations (like ERP) I create scope statements with the following sections:

i. Packaged software features in scope (product scope)

ii. Packaged software features out of scope (product scope)

iii. Implementation activities and party responsible (project scope)

iv. Assumptions

v. Constraints

A clearly defined scope allows the project team to focus on the activities that have a direct impact on the project objective(s) while filtering out “out of scope” work.

(2) KNOW THE BUSINESS

How can you lead a project to generate value for a business if you do not understand the business? You may be able to perform project control/admin but you will not be able to lead a project team in their efforts. Analyzing whether your project is generating business value is difficult if you do not understand what results drive real value.

(3) ENABLEMENT OVER CONTROL

Would you rather have one person (PM) focused on project scope or the entire project team (including your customer) guarding project scope? It’s been my experience that undetected scope creep starts outside of project meetings – ex. water cooler discussions, off topic discussions. Addressing project scope changes in a change control process is reactive – you already wasted time/effort writing up the potential change. I educate the entire project team on the project management basics of scope, schedule, and resources. I also make the scope easy to understand so that every individual on the project team understands scope boundaries. Individual team members are your first line of defense – the project manager cannot be everywhere at once.

Governance by itself does guarantee business value – a project manager has to do more than just control.

(4) BE RESULTS-ORIENTED

Focus on the right results: On-time, On-Budget are good project metrics but it does not guarantee that business value is generated. Decisions drive projects forward – not action items. As your project evolves your meetings should start generating more decisions and less action items. Running software is a good beginning but is not the end of generating business value.

(5) CREATE AND PROMOTE TRUST

Like the old adage says “Trust but verify!” The only thing I would add to this is to build in an iterative approach so that verification is frequent versus a one-time event. Waiting to develop trust during the Testing phase (i.e. validation) is not a smart risk to take.

(6) BE ADAPTABLE

Do not confuse a plan with execution. A project plan is a simplified model of reality based upon many factors whose definition will further elaborate during the project. Change will occur – be flexible and adaptable to reach the desired goals. A process (methodology) supports achieving the desired results but the methodology is not more important than achieving the desired business results.

Effective project management must be more than coordination and control – it must include enablement and leadership. Always keep the end goal in sight and on the minds of your project team.

Accelerating ERP/COTS Implementations

Accelerating ERP/COTS implementations have been an elusive goal of vendors, implementation partners, and customers. For five years I worked for the #2 business software maker focusing on accelerating implementations. During those five years I chased the dream and learned many lessons along the way. Following are some of the key lessons I would like to share with you.

If you did a search on accelerated or rapid implementation you would most likely find the following enablers for rapid implementations:

  • Software with built-in best practices
  • Industry preconfigurations
  • Implementation tools and templates (Needs Assessment, Fit/Gap summary)
  • Deployment (ex. SaaS, Hosted)

Notice anything missing? It’s interesting to note that these accelerators are software-focused. Not to say that the above tools/templates are not important, however, there are more important factors that can have a greater impact on accelerating implementations.

Customer

It’s a known fact that the customer needs to provide the right resources (Business, IT) with deep knowledge and experience with the existing business solution. What I see lacking is guidance to customers regarding what they need to do to prepare for a rapid implementation. If the implementation partner and software vendor is serious about accelerating implementations then they will provide customers with a preparation checklist that enables the implementation partner to “hit the ground running” with the customer. At a minimum the customer should perform the following:

  • Take all required software training BEFORE the implementation partner arrives. This activity will enable the customer to effectively and clearly communicate with the implementation partner.
  • Document your existing business processes. For effective collaboration with the implementation partner the customer needs to EDUCATE the implementation partner on their current business solution. A picture is worth a thousand words and accelerates knowledge transfer!

Implementation Partner

Consultants that are successful at accelerating implementations are an elite group. These individuals are business solution experts that are both functional and technical. They have the ability to help the customer make both software and business decisions. At a minimum the consultant should understand how the ERP/COTS software supports an ENTIRE business process (Order to Cash), not just a specific business function (Expense Reporting).

Decision Making

The ability to make decisions quickly is one of the most overlooked aspects of accelerating implementations. Decisions move implementations forward. Following are the recommended methods you can use to speed up decisions:

  • Conduct prototyping during the sales cycle to define core requirements, validate software results, and eliminate options. The more questions you can answer during the sales cycle the faster the implementation can move.
  • A rapid implementation approach requires full-time dedication from business owners. Business owners will be the key decision-makers and must be empowered to make decisions within hours, not days or weeks.
  • Need to have a clearly defined scope. This includes (a) what’s in scope, (b) what’s out of scope, (c) and who’s doing what. Just as important to scope definition is to define constraints and assumptions.

At a minimum the ERP/COTS scope statement should contain the following sections:

  • Packaged software features in scope (product scope). This also includes restrictions on software features in scope (example: only five customer types will be included in the rapid implementation).
  • Packaged software features out of scope (product scope).
  • Implementation activities and party responsible (project scope).
  • A clearly defined scope allows the project team to focus on the activities that have a direct impact on the project objective(s) while filtering out “out of scope” work.

Methodology and Approach

I have observed two areas that slow down ERP/COTS implementations: customizations and evolving requirements (even with a predefined scope). From my experience my approach has been to minimize these areas by the following:

  • Only implement the software functionality that supports the business activity the customer performs TODAY. New business activities typically result in evolving requirements because the customer has no detailed experiences or agreed-upon expectations.
  • Take a solutions-driven approach to gathering requirements. Using a traditional requirements-driven approach will result in identifying more gaps (both value and non-value-add).

Summary

Not every project or customer is a candidate for a rapid implementation. Implementation partners and software providers should conduct an assessment to determine the FIT for a rapid implementation. One thing you can bet on is that there is no such thing as a STANDARD rapid implementation. Each instance is unique and requires an experienced implementation partner that understands rapid implementations.

Follow

Get every new post delivered to your Inbox.

Join 4,409 other followers

%d bloggers like this: