Neutrality that protects your decision not a vendor’s quota.

Here are five core differences: In short: We optimize for efficiency and outcomes, not billable time. If you want the process in one place, see the Roadmap.

No. DECG does not sell software, receive vendor kickbacks, or design projects to steer you into a purchase. If a tool helps, we will say so. If it doesn’t, we will say that too. This is core to how we work. The details are spelled out on the Neutrality page.

Sometimes, yes, but only when it’s truly the simplest way to remove friction or reduce risk. A lot of problems are process issues wearing a “we need software” costume. When software is part of the answer, we will define requirements first, compare options objectively, and keep you in control of the decision. That approach is outlined on Neutrality and baked into the Roadmap.

I use a requirements-first approach: define outcomes, map workflows and exceptions, and identify what the tool must support. Only then do we evaluate platforms. That keeps decisions anchored to your reality, not my past projects. If you want the “no funny business” version of this policy, it’s on Neutrality.

Yes. We can help you translate your needs into clear requirements, run structured vendor conversations, and pressure-test proposals so you’re not buying a shiny tool that doesn’t fit your workflows. But we don’t become your implementation team. we help you choose wisely and set you up for success. That boundary is part of our Neutrality approach and shows up in the Services models.

DECG primarily focuses on analysis and recommendations rather than full implementation. This keeps our advice independent and ensures recommendations are based on what is best for the client rather than what generates additional consulting work. However, we can remain involved after the diagnostic if the client would like ongoing advisory support. In these situations, implementation is typically carried out by the client’s internal team or by consultants or vendors of their choosing, while DECG supports the process from an advisory perspective. This may include helping refine the implementation roadmap, updating workflow maps, assisting with the development of standard operating procedures (SOPs), and providing guidance as the team works through operational changes. Some clients simply want a clear plan and move forward on their own. Others prefer to have DECG available to review decisions, answer questions, and provide a neutral perspective as improvements are implemented. Both approaches work well and depend on the client’s needs and internal resources.

Usually not. In many cases the issues uncovered during a workflow diagnostic are related to how a process is designed rather than limitations in the technology itself. Often the most effective improvements involve adjusting the workflow, removing unnecessary steps, reducing handoffs, or making better use of the tools already in place. However, there are situations where a system, tool, or resource simply cannot support the level of complexity the workflow requires. When that happens, DECG evaluates the situation from multiple angles. One option may be simplifying or restructuring the process so the existing system can support it without requiring new software. Another option may involve introducing a new tool or system if the business needs truly require that additional capability. If a new system becomes part of the recommended path, a separate Statement of Work (SOW) is created to define the discovery process. During that phase we identify the operational requirements, budget constraints, regulatory considerations, and security requirements involved. From there, potential solutions are evaluated against those criteria. DECG does not promote specific vendors or software platforms. The workflow and operational requirements determine what solutions are appropriate. Our role is to present options that meet the client’s needs so the organization can make an informed decision based on facts rather than vendor preferences.

Before any tools or platforms are considered, we define the operational requirements based on how the process needs to function from beginning to end. If the diagnostic determines that technology may be required to support the workflow, a discovery phase is used to identify the specific requirements the solution must meet. This may include functional needs within the workflow, integration with existing systems, regulatory or security constraints, budget considerations, and the overall complexity of the process. Once those requirements are clearly defined, potential tools or platforms can be evaluated against them. The goal is to determine which solutions are capable of supporting the operational needs of the organization rather than trying to force the workflow to adapt to a particular product. DECG does not promote or resell software and does not receive compensation from vendors. This allows recommendations to be based entirely on how well a solution fits the client’s operational requirements.

Often, no. Many “system limitations” are really workflow, ownership, or rules issues. We start by fixing the process first. In many distribution environments, the problem is not the WMS or ERP itself. The issue is often how the workflow is designed, where ownership is unclear, how exception handling is managed, or what business rules are forcing unnecessary friction into the process. If tooling changes are truly needed, DECG defines the operational requirements first and then evaluates options without vendor bias. That keeps the decision anchored to how the distribution workflow actually needs to function rather than defaulting to a software purchase too early.