El producto mínimo viable

Deja un comentario

Ya hemos visto en un artículo anterior que cuando una empresa informática se inicia debe desarrollar una aplicación que pueda competir con muchas posibilidades de éxito en el mercado.

Competencia existe, y mucha. Y para ganar buen dinero hay que destacarse.

Sin embargo, aquí nos encontramos con un problema. Y es un problema MUY GRANDE.

¿Cuál es ese problema?

Que la competencia quizás ya hace muchos años que ha desarrollado su aplicación. La ha llenado de características que la hacen muy provechosa para sus clientes. Es muy completa, tiene de todo. Hace muchas cosas y todas esas cosas las hace muy bien.

¿Cuál es la solución?

Un gran error sería intentar desarrollar de entrada nomás una aplicación mejor. No podremos. Nos llevan años y años de ventaja. Tardaríamos años en hacer algo así y mientras tanto debemos ganar dinero para comer.

Ni soñar con desarrollar en pocos días una aplicación mejor que la aplicación de la competencia.

¿Y entonces?

Y entonces nuestra mejor opción es desarrollar un producto mínimo viable.

¿Qué es un producto mínimo viable?

Es un producto que tiene las características mínimas para que sea útil para algunas empresas y por lo tanto, vendible.

No es, ni de cerca, nuestro objetivo final. Es simplemente un producto con el cual ya podremos empezar a ganar algo de dinero. Poco dinero quizás, pero ya algo de dinero.

Desarrollando un producto mínimo viable

Recuerda que el objetivo final es superar a toda la competencia. Pero eso puede demorar muchos meses e inclusive varios años. No se consigue de un día para el otro.

Por lo tanto empezaremos con un producto que tenga las características mínimas como para ya ser vendible.

Ejemplo 1. FACTURACIÓN

Nuestro PMV (producto mínimo viable) tiene una tabla de PRODUCTOS, una tabla VENTASCAB (cabecera de ventas), una tabla VENTASDET (detalle de las ventas). No tiene fotografías de los productos, no permite vender a crédito, no calcula intereses por mora, etc. Tiene muy pocos informes (productos, ventas realizadas, y quizás alguno más).

Pero ya es vendible. Ya se lo podremos ofrecer a empresas que venden siempre al contado. Como kioscos, peluquerías, restaurantes, gomerías, panaderías, zapaterías, etc.

Después lo iremos mejorando para que tenga fotografías de productos, para que permita vender servicios o productos, para que permita vender a crédito, para que lleve el control del stock, etc.

Ejemplo 2. ABOGADOS

Nuestro PMV (producto mínimo viable) tiene una tabla de CLIENTES, una tabla JUICIOSCAB (cabecera de juicios) y una tabla JUICIOSDET (detalles de los juicios). En la tabla JUICIOSCAB registraremos los datos de cada juicio (el nombre del juicio, el demandante, el demandado, la fecha de inicio del juicio, etc.). En la tabla JUICIOSDET guardaremos los detalles de todo lo que va haciendo el abogado (fecha y hora de la comparecencia, escrito que presentó, resolución del juez, etc.)

Ya es vendible. A más de un abogado algo así le resultará útil.

Claro que luego lo iremos mejorando para que registre todo lo cobrado al cliente, lo que aún falta por cobrar, el estado del juicio, búsqueda de leyes, jurisprudencias, y un largo etcétera.

Ventajas del producto mínimo viable

  1. Como la aplicación tiene características mínimas, el tiempo para desarrollarla es muy corto.
  2. Ya se cobra algo de dinero.
  3. Hay muy poca competencia. La mayoría de la competencia se dedica a hacer y a vender aplicaciones más completas.
  4. Se la podemos vender a una gran cantidad de clientes que necesitan aplicaciones muy sencillas y muy fáciles de usar.
  5. Aseguramos la clientela. Esos mismos clientes a quienes les vendimos nuestro PMV luego nos irán pagando por las nuevas características que le vayamos agregando.
  6. Obtendremos mucho feedback o retroalimentación. Serán nuestros primeros clientes quienes nos irán diciendo lo que le está faltando a nuestra aplicación. Entonces, lo que iremos agregando serás cosas útiles y necesarias para ellos. Y serán nuestros mismos clientes quienes estarán trabajando (sin saberlo) para nosotros porque gracias a ellos sabremos lo que les gusta y lo que no les gusta. Lo que es necesario y lo que es superfluo.
  7. Tendremos aplicaciones para vender a un gran rango de clientes. Porque aunque nuestra aplicación vaya mejorando con los meses no por eso dejaremos de vender a nuestra versión 0.0.1, ella seguirá existiendo y seguirá dándonos dinero. O sea, la versión 0.0.1 es un PMV, solamente tiene lo mínimo necesario. Luego la mejoramos y creamos la versión 0.0.2, pero no abandonamos a la versión 0.0.1, así que ahora tenemos dos versiones que vendemos a dos precios diferentes. Luego mejoramos y creamos la versión 0.0.3, y entonces ahora tenemos tres versiones que vendemos a tres precios diferentes. Y así sucesivamente

Conclusión:

El objetivo final es superar a toda la competencia. A toda. Pero eso llevará muchísimo tiempo, no se consigue de un día para el otro. Entonces nuestra mejor política es empezar con un PMV (producto mínimo viable), que es una aplicación que tiene las características mínimas como para ser útil a alguien y por lo tanto vendible.

Entre las ventajas de desarrollar un PMV tenemos que el tiempo para hacerlo es muy corto y que ya empezamos a ganar dinero. No se cobra mucho dinero por él, pero se cobra algo. Así empezamos.

Artículos relacionados:

Fuentes del dinero

Aplicaciones horizontales y aplicaciones verticales

El caballo de batalla

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Hallando todas las ventas entre dos fechas dadas

6 comentarios

En ocasiones podríamos necesitar ver todos los movimientos (compras, ventas, cobranzas, pagos, etc.) que ocurrieron entre dos fechas dadas, pero queremos que si en una fecha no hubo movimientos nos muestre cero.

Eso no podemos resolverlo con un SELECT porque el SELECT solamente nos mostrará los movimientos ocurridos, y si una fecha no tuvo movimientos entonces no será mostrada.

La solución es escribir un stored procedure seleccionable, el cual nos dará la información que necesitamos.

Ejemplo. Ver todas las ventas realizadas entre los días 01/ENE/2014 y 07/ENE/2014

Nuestra tabla MOVIMCAB (donde registramos la cabecera de los movimientos) tiene estos datos (y varios más que ahora no nos interesan):

VENTAS1

Captura 1. Si haces clic en la imagen la verás más grande

Escribimos este stored procedure:

CREATE PROCEDURE VENTAS_DIARIAS(
      tdFecIni DATE,
      tdFecFin DATE)
   RETURNS(
      ftdFechax DATE,
      ftnTotalx INTEGER)
AS
   DECLARE VARIABLE ldFecha DATE;
BEGIN

   ldFecha = tdFecIni;

   WHILE (ldFecha <= tdFecFin) DO BEGIN
      ftdFechax = ldFecha;
      ftnTotalx = (SELECT SUM(MVC_TOTALX) FROM MOVIMCAB WHERE MVC_FECHAX = :ldFecha);
      ftnTotalx = COALESCE(ftnTotalx, 0);
      SUSPEND;
      ldFecha = ldFecha + 1;
   END

END;

Y como es un stored procedure seleccionable (sabemos eso porque tiene el comando SUSPEND dentro suyo) lo ejecutamos así:

SELECT
   *
FROM
   VENTAS_DIARIAS('01/01/2014', '01/07/2014')

Para que nos muestre todas las ventas ocurridas entre los días 1 de enero de 2014 y 7 de enero de 2014, agrupadas por fecha. Y este es el resultado que obtenemos:

VENTAS2

Captura 2. Si haces clic en la imagen la verás más grande

Donde, como puedes ver, se muestran todas las fechas del rango elegido, si en una fecha hubo ventas el total de las ventas de esa fecha y si no hubo ventas, entonces cero.

Artículos relacionados:

Entendiendo a los Stored Procedures

El índice del blog Firebird21

 

Ventas por caja

2 comentarios

Cuando diseñamos una Base de Datos que será usada para guardar (entre otros) los datos de las ventas realizadas en las cajas (caso típico de un supermercado) debemos tomar en consideración los siguientes puntos:

  1. No debemos preocuparnos por verificar si hay suficiente cantidad en stock del producto vendido. ¿Por qué no? porque la prueba de que hay suficiente cantidad del producto está en las manos del cliente.
  2. Debemos prever el uso de tablas locales. Si por algún motivo la red dejara de funcionar eso no debería evitar que desde las cajas se sigan registrando las ventas.  Más tarde, cuando la red vuelva a funcionar, se actualizarán las tablas remotas y se vaciarán las tablas locales, de ser necesario.
  3. Mientras una caja está usando tablas locales cualquier cambio en el precio de venta de un producto realizado en el Servidor no será conocido por la tabla local y lo mismo ocurrirá si se agregan nuevos productos para la venta. Por lo tanto en algún momento habrá que correr un proceso de actualización para que el contenido de la tabla local de PRODUCTOS coincida con el contenido de la tabla remota de PRODUCTOS.
  4. La tabla local no puede ser borrada sino hasta después de imprimir y de confirmar la impresión del “zeta”. Se llama “zeta” a los datos que se imprimen cuando se cierra la caja, entre ellos: fecha, hora, cantidad total de productos vendidos, cantidad total de productos devueltos, importe total vendido, importe total devuelto, impuestos a pagar, etc. Por una cuestión de seguridad y de auditoría es conveniente que aún después de imprimir la “zeta” los datos de los productos vendidos y devueltos permanezcan en la tabla local durante algunos días.
  5. Cuando un cliente después de registrarse la venta de un producto desiste de su compra (quizás porque no le alcanza el dinero) se marca ese producto como borrado pero en la Factura que se entrega al cliente se imprimen el producto y su correspondiente negativo. Así mismo en la tabla de ventas se registran la venta de ese producto y su devolución.
  6. Cuando una venta se cancela totalmente (quizás porque el cliente se dio cuenta que no tenía dinero) se procede como en el punto 5, para todos y cada uno de los productos.
  7. En la tabla de detalles de movimientos de ventas se debe tener una columna donde guardar la fecha y hora de la venta (o de la devolución) de cada producto. De esta manera se podrá conocer exactamente lo que sucedió en cada caja, segundo a segundo.

Tamaño de la tabla local de PRODUCTOS

Para que una caja pueda continuar registrando ventas aunque se haya cortado la conexión con el Servidor es requisito que tenga una tabla local con los datos de los productos que puede vender (identificador, código de barras, nombre del producto, precio de venta). Normalmente esas columnas ocuparán menos de 100 bytes. Un supermercado no suele tener más de 60.000 productos distintos para vender. Entonces, 60.000 productos por 100 bytes de cada producto nos da un total de 6.000.000 de bytes para la tabla de PRODUCTOS. En esta época eso es casi nada.

Tamaño de la tabla local de detalles de VENTAS

El tamaño de cada registro de la tabla de detalles de las ventas debe ser inferior a 50 bytes (identificador del detalle, identificador de la cabecera, identificador del producto vendido, cantidad vendida, precio de venta, fecha y hora de la venta o devolución, marca de “zeteado” o sea que se cerró la caja). Suponiendo que se realice una venta por minuto durante las 24 horas del día y que en cada venta haya una promedio de 10 productos, tendremos: 1440 ventas por 10 productos en cada venta por 50 bytes en cada registro, es igual a: 720.000 bytes. Poquísimo.

Consideraciones con las tablas locales

  1. La tabla de PRODUCTOS debe ser actualizada periódicamente para tener siempre registrados en ella los nuevos productos y los precios de venta actualizados. Generalmente lo más adecuado es hacer esto como primera tarea del día. El programa de ventas verifica si la fecha de la tabla PRODUCTOS es igual a la fecha actual. Si no es así, actualiza la tabla de PRODUCTOS. Esto debería ser cuestión de segundos, jamás debería tardar más de uno o dos minutos.
  2. Por seguridad y auditoría, es conveniente que la tabla detalles de VENTAS tenga los datos de los últimos 7 días, entonces si algún problema ocurre en el Servidor se pueden reconstruir las ventas realizadas en cada caja. Más de 7 días es innecesario porque se supone que habrá backups más nuevos.

Impresión de la Factura para el cliente

Una medida de seguridad es ir imprimiendo la Factura a medida que se van registrando los productos. Cuando se registra el primer producto de una venta se imprimen la cabecera de la Factura y los datos de ese primer producto. Cuando se registran los datos de otro producto (o una devolución) se imprimen los datos de ese producto o de esa devolución. Y así sucesivamente hasta cerrar la venta, en cuyo momento se imprimen los totales, los impuestos, etc. De esta manera nos aseguraremos que TODO lo que se hizo en una caja se registró en nuestras tablas y también se imprimió en papel. Para la auditoría, esto es excelente.

Artículos relacionados:

Registrar los cambios a los precios de venta

El manejo de los precios de costo y de venta

Registrando los productos borrados

El índice del blog Firebird21

Registrando los productos borrados

5 comentarios

Cuando se están cargando los datos de una venta el usuario (quizás cajero) va registrando ítem tras ítem los productos vendidos y la cantidad vendida.

¿Pero qué sucede si el cliente después de haberse hecho el registro decide que no va a llevar ese producto, quizás porque no tiene suficiente dinero?

Supongamos el caso de un supermercado: mientras se van registrando los productos vendidos y las cantidades vendidas, el cliente decide que no llevará uno de los productos. Normalmente en esos casos se llama al “Supervisor de cajas” o “Jefe del salón de ventas” quien introduce su clave de acceso con la cual se le permite borrar los productos no deseados por el cliente.

¿Pero cómo registramos esa acción en nuestras tablas de ventas?

Una posibilidad es guardar solamente los productos efectivamente vendidos. El problema con esto es que no quedarán registrados los productos que se borraron ¿Y es importante tenerlos registrados? Pues sí, porque eso le permitirá al Gerente o al propietario del supermercado detectar fácilmente y rápidamente todas las ventas donde se borraron productos. Si no tuvieran esa información entonces no podrían saber con cuanta frecuencia se borran productos, cuales son los productos que más se borran, quienes son los cajeros que más problemas tienen, etc.

Operativamente nuestra aplicación de ventas debería funcionar así:

  • Cuando se registra el primer producto vendido se imprime la cabecera de la Factura y los datos de ese primer producto
  • Cada vez que se registra un producto, se imprimen sus datos
  • Cuando se borra un producto, se imprimen sus datos
  • Cuando se cierra la venta, se imprimen los totales, los impuestos, y toda la demás información relevante

Alternativamente, se puede dejar la impresión de la Factura para el final, después de haberse cerrado la venta, pero siempre en ella deberían imprimirse los datos de los productos borrados.

Si una venta se cancela totalmente (quizás porque cuando iba a pagar el cliente se dio cuenta que no tenía dinero consigo), debe quedar registrada esa cancelación.

De esta manera TODO lo que se hizo en la computadora del cajero quedará registrado en nuestras tablas y podremos reconstruir lo que sucedió en ella, segundo a segundo.

Para poder conseguir esto último es requisito que una de las columnas de nuestra tabla de detalles de movimientos de ventas corresponda a la fecha y a la hora en la cual se registró la venta de ese producto.

Artículo relacionado:

El índice del blog Firebird21

¿Una Base de Datos o muchas bases de datos?

2 comentarios

Esta es una pregunta que quizás te hayas hecho alguna vez cuando estás desarrollando tus aplicaciones ya que Contabilidad, Compras, Facturación, Producción, Ventas, Sueldos, etc. tienen algunas tablas que pueden compartir, que pueden ser comunes.

Entonces: ¿cada aplicación debe tener su propia Base de Datos? ¿o es mejor usar una sola Base de Datos para todas las aplicaciones?

Aunque la respuesta podría variar dependiendo de cada circunstancia particular, en general lo correcto es lo siguiente:

  • Si en todas las aplicaciones se registrarán los datos de una sola Empresa entonces es mejor usar una sola Base de Datos
  • Si en alguna aplicación se registrarán los datos de dos o más Empresas, entonces una Base de Datos por cada empresa

Ventajas de usar una sola Base de Datos

  • Relacionar a las tablas entre sí (con JOIN, UNION, etc.) es muy fácil
  • Un solo backup copia todo
  • Un solo restore restaura todo
  • Los mismos metadatos se usan en todos los casos

Desventajas de usar una sola Base de Datos

  • Si allí tienes los datos de varias empresas, una fiscalización gubernamental a una empresa les mostraría los datos de todas las demás empresas porque ellos llevarán la Base de Datos completa, no solamente los datos que corresponden a una sola empresa
  • Si se corrompe la Base de Datos pueden quedarse inaccesibles los datos de todas las empresas
  • Si roban la Base de Datos se roban los datos de todas las empresas
  • El tamaño de la Base de Datos será muy grande
  • Algunos procesos pueden ser muy lentos
  • Si un curioso accede al nombre y la contraseña de un usuario puede ver, cambiar, o borrar los datos de todas las empresas

Ventajas de usar varias bases de datos

  • Los datos de cada Empresa se manejan de forma independiente. Una fiscalización gubernamental solamente afectará a una Empresa
  • Si se corrompe una Base de Datos solamente esa es afectada
  • Si se roba una Base de Datos solamente una Empresa es afectada
  • El tamaño de cada Base de Datos es menor
  • Ningún proceso será muy lento
  • Si un curioso accede al nombre y a la contraseña de un usuario podrá ver, cambiar o borrar los datos de una sola empresa

Desventajas de usar varias bases de datos

  • Los metadatos pueden estar desactualizados, ser distintos en cada una de las bases de datos
  • Hacer un backup completo lleva más tiempo
  • Restaurar todos los backups tomará más tiempo
  • Es más complicado relacionar tablas de una Base de Datos con las tablas de otra Base de Datos

Ejemplos:

  • Una aplicación de Contabilidad que será usada en un estudio contable y por lo tanto desde esa aplicación se contabilizarán los datos de varias empresas debería tener una Base de Datos por cada empresa.
  • Una aplicación de ERP que se instalará dentro de una empresa y que constará de los módulos de Contabilidad, Compras, Ventas, Facturación, Producción, Sueldos, etc., debería tener una sola Base de Datos