This interview is with Sam Gupta, CEO, ElevatIQ.
To kick things off, could you introduce yourself, your firm, and the types of ERP and transformation programs you lead?
I am Sam Gupta, CEO of ElevatIQ, a vendor-agnostic digital transformation strategy and change management firm. I have been in this field for more than 20 years, leading enterprise transformation initiatives that span multiple system categories, including ERP and CRM, and covering enterprise architecture, with budgets amounting to millions of dollars.
In my current role, my responsibilities include working with executives to help formulate a digital transformation strategy and build target operating models. I have also assisted with several ERP program rescues, saving over $100 million collectively with failed transformation strategies.
What key experiences or decisions shaped your path into vendor‑agnostic ERP selection and implementation advisory?
I started my career working with some of the largest system integrators, implementing large programs focused on business systems and enterprise architecture. One consistent frustration was that, despite knowing the program might encounter adoption and implementation challenges, we were asked to proceed with projects as long as we were billable. This generally leads to a loss of trust in clients’ digital transformation initiatives. By the time we were involved in these projects, it was already too late.
The RFPs we received were either too boilerplate or biased, as the companies that wrote them had active affiliations with software providers. The selected systems were too constrained to save realistically. I wanted to change that.
I believe that digital transformation, executed effectively, can change the world. We wanted to do the right things for the clients, the way they were supposed to be done, in a vendor- and solution-agnostic manner.
When you begin an ERP initiative, what’s the one Phase 0 deliverable you never skip to de‑risk the program?
One deliverable we never skip is the brief target operating model, which serves as the foundation for the entire program. The target operating model blueprint must include the basic definitions of the as-is and to-be states, along with how departments and entities would be organized.
It outlines how they would interact and their impact on their respective states. Additionally, it defines the roles and responsibilities of the different systems involved and their effect on the ERP’s overall status.
How do you structure a vendor‑agnostic selection so business capabilities—not feature checklists—drive the shortlist?
We look at this from an implementation perspective. This mindset enables us to understand product design constraints more deeply. While designing the target operating model, we translate proprietary knowledge bases and workflows into alignment with the enterprise software taxonomy. The final state provides us with the critical success factors balancing all perspectives: objectives, budget, timeline, and enterprise software constraints.
While building a target operating model, executives are coached on fundamental concepts of enterprise architecture and their implications for budget, timeline, and overhead. This approach also helps stakeholders focus on the factors that matter more, rather than superficial feature checklists that will fall flat once implementation begins.
For SMEs wary of cost and uncertainty, what iterative milestones have helped you unlock funding from CFOs with confidence?
For smaller engagements focused on SMEs, we recommend dividing them into at least three phases: strategy, selection, and implementation. The major challenge with these initiatives is the assumptions baked into the scope that generally fail both parties. Unless those assumptions are fully clarified, there will always be challenges with implementation and adoption.
Additionally, if you follow a solution-focused approach in earlier phases, the software is often blamed rather than identifying the right root cause. The easiest way to address this is to divide the project into manageable chunks with a clear stage-gate process. The role of earlier phases is to learn and bring the project to a state where it can be executed with greater confidence. This iterative approach also helps unlock funding for smaller phases and pivot quickly if the context changes.
CFOs appreciate this approach because the initial investment is predictable, even if it ends up being completely sunk costs to learn. They can leverage this learning in the future when the outlook improves.
Before any software demos, how do you align departmental taxonomies and processes so the future ERP reflects the operating model rather than current workarounds?
We follow a multi-pronged approach to develop a better understanding of current processes, especially their deviations. We use several methods and correlate information from sources such as datasets, interviews, surveys, demos, and site visits.
As stakeholders attend these workshops in an informal setting, they demonstrate their processes, and we walk them through our experience with similar business models. Then the process of negotiation starts. We present them with the taxonomy changes and the ideal state, including their pros and cons.
They review and assess their comfort level in making these changes as per our recommendations. Each decision impacts the state, requiring revisions until the final state is agreed upon by all stakeholders. This is done in a vendor- and solution-agnostic manner, without even referencing specific software, categories, or ERP vendors.
During implementation, how do you balance tightly connected processes with the realities of user adoption across functions?
Our goal is always to implement the same state that we have created in the strategy phase. If users have gone through the workshops, they will be empowered to think comprehensively rather than just focus on user experience. Depending upon the time spent in the strategy phase, users themselves identify these issues and drive the state.
However, the documented target operating model serves as a “North Star” for us as conflicts arise. We also use a decision-making framework throughout the process, ensuring a democratic process rather than allowing “loud voices” to hijack the project. Each proposed change must undergo scrutiny, especially if it has implications for the target operating model.
When integrating ERP with ecommerce, OMS, WMS, and 3PLs, what’s your most reliable approach to achieving financial inventory confidence?
Achieving financial inventory confidence requires enterprise-wide, cross-functional consolidation, which is typically achieved through ERP-centric processes. When integrating ERP with eCommerce, OMS, and 3PL, their state, roles, and responsibilities need to be clearly defined.
Which datasets would originate from these systems, and could they affect the financial condition of the inventory? For example, if a company cares about in-process cost control or if their pricing is driven by costs, their ERP processes might play a much deeper role, while the roles of eCommerce, OMS, WMS, and 3PL might be limited to executing specific, role-focused responsibilities as directed by the ERP.
For industries where the market dictates the price and transaction speed is more important than cost control, financial inventory confidence may not be as relevant. The key is to have clearly prioritized objectives, as consolidation generally leads to complexity. But consolidation is the foundation of financial inventory confidence.
In the first 90 days after go‑live, which leading indicators do you track to confirm the transformation is on course?
We look at this through an adoption lens. We measure this based on compliance with the target operating model. If we have 100% compliance with the target operating model, that’s a massive success, but it is rarely the case.
Generally, the target operating model needs to evolve even after going live, as stakeholders gain a better understanding of the new context and the governance process developed in response to the detected deviations.
The failure cases are far more chaotic. You can tell by working with users: they complain about the change and return to workarounds, claiming that the new system does not allow them to finish their jobs on time. So, they feel they have no choice but to revert to the workarounds.
When users like the system, it is the opposite. They can’t afford to lose the system, as they would not be able to finish their jobs as effectively without it.