Método MoSCoW
Una manera uniforme de priorizar con el método MoSCoW
La elección e implementación de un nuevo software puede ser todo un trabajo. Las empresas que quieren tomar una buena decisión, deben saber exactamente lo que pueden esperar del software. Establecer las prioridades es, por tanto, primordial, pero este proceso no siempre es fácil. Por ello, Daig Clegg en 1994 ideó el método MoSCoW. Las consonantes de este acrónimo representan los diferentes tipos de deseos y requisitos que una empresa debería distinguir: Must-have (debe-tener); Should-have (debería-tener), Could-have (podría-tendría) y Won’t-have/Would-have (no-tendría).
Must-have (Debe-tener)
Los must-have son los requisitos mínimos que un software tiene que cumplir. Sin el cumplimiento de estos requisitos, se considera que el proyecto no ha tenido éxito. Por ejemplo, si una empresa se interesa primero por un 
Un sistema ERP (Enterprise Resource Planning) o sistema de planificación de recursos empresariales se hace cargo de distintas operaciones internas de una empresa, desde producción a distribución o incluso recursos humanos. Por tanto, este software gestiona los distintos procesos empresariales de una misma empresa. Existen muchos tipos de ERP: horizontales (generales) y verticales (sectoriales); para pequeñas, medianas y grandes empresas; nube, híbrido o en local; entre otros.sistema ERP porque su programación manual de la producción provoca errores semanalmente y, por lo tanto, conlleva pérdidas de tiempo, el 
La planificación de la producción consiste en establecer un plan de trabajo dependiendo de la cantidad de pedidos o de las ventas esperadas. Esta planificación se hace teniendo en cuenta: materiales disponibles o sus plazos de entrega; número de trabajadores; y capacidad de producción de las máquinas y los empleados.módulo de planificación de la producción será un must-have.
Should-have (Debería-tener)
Los should-have en un proceso de orientación, son aquellas funcionalidades que resultan altamente deseables. Sin embargo, el software también puede demostrar su valía sin estas funcionalidades. La adición de los should-have generalmente se encargan de conseguir un mayor
El retorno de la inversión (ROI, Return On Investment), sirve para calcular la eficiencia de una inversión. Es decir, con la fórmula de ROI se analizan los costes y beneficios de una inversión para estudiar si es o será positiva o negativa una inversión. Con la compra de un software, los jefes de proyecto reciben órdenes de la dirección para que realicen una estimación del ROI. En este caso, el retorno de la inversión es una medida de ayuda para determinar si una inversión de software concreta merece la pena. retorno de la inversión (ROI). También puede tratarse de funcionalidades que no tienen una prioridad tan alta en el momento, pero que será necesaria en un periodo de tiempo relativamente corto. Una empresa que ahora puede convertir los pedidos por correo electrónico en órdenes de producción de forma relativamente rápida puede seguir considerando la integración del correo electrónico como una should-have de proyección de crecimiento.
Could-have (podría-tendría)
A los could-have también se les conoce como nice-to-have. Estas son cualidades que gustaría añadir si entran dentro del rango de tiempo y dinero. Sin embargo, cuando suponen un esfuerzo extra, no tiene sentido contemplarlas. Por ejemplo, en el caso de una empresa de producción con una clientela baja de B2B, un could-have podría ser la 
El intercambio electrónico de datos (Electronic Data Interchange, EDI) es la tecnología que se encarga de que la comunicación entre empresas sea estándar y electrónica. Generalmente, las empresas mayoristas B2B y las del sector de producción son las que hacen uso del software EDI. La estandarización de la comunicación a través de EDI reduce la cantidad de documentos que se intercambian. Los mensajes que se mandan a través de EDI se llaman transacción. Esta transacción comunica claramente todos los detalles de un pedido o factura al proveedor o cliente. integración de EDI. El intercambio directo de datos puede acelerar el proceso de pedido y facturación, pero trae consigo un crecimiento realmente significante de los pedidos.
Won’t have/ Would-have (no-tendría)
Los won’t have son más bien deseos utópicos, o deseos que en el momento de la orientación no merecen aún la pena invertir en ellos. Por ejemplo, esto puede ser involucrar la recogida de pedidos a través de realidad aumentada. Es una tecnología muy interesante, pero para la mayoría de las empresas este sólo supone un coste enorme. A los won’t have también se les conoce como would-have, porque una empresa podría implementarlos bajo ciertas condiciones en el futuro.
Cambio de situaciones y prioridades de trabajo
Los deseos y requisitos nunca son estadísticos. Se diferencian por empresa, situación y momento. De esta forma, se puede prevenir que los deseos y requisitos de una empresa cambien de categoría después de un tiempo. Por ejemplo, al principio una empresa puede tener un pequeño almacén. Entonces, a los recogedores de pedido no les importa ir a un punto central para recoger el siguiente pedido. En ese momento, la recogida por voz es un could-have o, incluso, un won’t-have. Sin embargo, tan pronto como la empresa crezca y el almacén se vuelva mucho más grande, la recogida por voz puede convertirse en un should-have o, incluso, en un must-have.
Artículos relacionados TIC Portal:
