Cui Bono
So far, so good
- Desde
- 19 Jul 2007
- Mensajes
- 29.855
- Reputación
- 51.553
Esto viene de aquí:
Claro, hay que estar metido en el ajo o conocer a uno metido en el ajo al que dar la paliza para aprovechar un nicho.
Ejemplo:
Partimos de la base de que hay claves RSA en la aplicación. Eso permite:
- Cifras con la clave privada, otros (o tú mismo) descifra con la clave pública. También funciona al revés, otros cojen tu clave pública y te cifran algo, y tú lo descifras con la clave privada.
- Idem, pero para firmar.
Estoy haciendo una aplicación con Laravel (un framework PHP, tipo MVC). Tiene (tendrá) las tablas necesarias para el funcionamiento de una empresa de montajes, con clientes, curritos, ofertas y su estructura (partidas, unitarios, asignación de unitarios, reglas de cálculo), proveedores, partes de trabajo, diagramas Gantt de avance de obra, facturación (a pagar) por colección de albaranes, facturación a clientes, por avance de obra, etc..
La idea es que una vez instalado en un server LAMP o WAMP, la info quede cifrada en la base de datos, de manera que puedes tener una clave RSA del server, otra RSA del usuario, otra para cada obra (o capítulo) de cara a exportar info selectivamente, etc..
El intercambio de info sería por intercambio de claves.
Por ejemplo, un almacenista tiene su server (lógicamente cifrado en su parte accesible) y pasándote la clave pública llamada "De los productos de climatización con descuento B", eso te permitiría en tu aplicación de presupuestos coger sus precios, con el ahorro en mails, tener que atender ese mail de petición, atender el mail con la oferta de respuesta y procesarla, meterte en su web de listado de productos, etc.. Actualmente los almacenistas tienen su aplicación para que consultes sus precios, pero no acaba de funcionar, para lo importante se tira de teléfono y mails.
Para la difusión de ofertas funcionaría de la siguiente manera: Un cliente necesita oferta para una obra, necesita instaladores. Se conecta a la web de cualquiera de ellos, web que puede haber obtenido de algún directorio de empresas. Se da de alta como cliente y pone ahí su oferta o pide que se la ingresen (pagando). La misma info ingresada (descripción de capítulos, partidas, unidades de esas partidas) podría servir para trasladar esa oferta a otros instaladores, simplemente habilitando un protocolo con las claves públicas del server y de la oferta y otros instaladores cogerían esa info, la trasladarían a su propio server sin tener que reestructurar la información (porque no es un pdf o un excell), generarían claves de cifrado y el cliente inicial podría acabar con 5 ó 10 claves de otros tantos servers donde los presupuestadores ponen sus precios ocultos a los demás sobre la misma oferta, precios accesibles en red pero "solo para sus ojos".
Sería una especie de integración del sector, una especie de Web of Trust con un software en donde prima el cifrado y el que una empresa no se arriesgue a que le birlen la obra o la venta de productos y servicios. A su vez, hay muchas posibilidades por explorar, como que un exceso de stock del que haya que librarse pueda provocar un aluvión de producto conocido a un extraño bajo precio, rápidamente aceptado en la red, permitiendo el alivio de stocks de los almacenistas. Hay mucha sinergia en una integración sectorial con el mismo software.
Para el tema de, por ejemplo, un taller de coches, estamos en las mismas, en que hay una necesidad de producto de desguace o nuevo y un caos de referencias y proveedores de distinto pelaje a los que les gustaría simplemente soltar su stock actualizado y no depender de las búsquedas que hagan en Google los posibles clientes, sino tener un canal profesional, en donde cada quién controla, por medio de RSA, quién ve a quién, quién accede a qué y la seriedad de la petición de precios.
Hay un gran campo ahí. Instalar un ERP/CRM genérico es un auténtico ****** y cosas que deberían ser en un solo paso (como ingresar datos que ya están estructurados) se convierten en una recodificación de la estructura, a base de picar con la rata y escribir de nuevo lo mismo, pero con la estructura del modelo del ERP elegido. Eso echa para atrás a cualquier PYME, que no quieren ser esclavos de una aplicación costosa en integración, aprendizaje y en uso.
El primer paso, para mí, es tener una aplicación usable con tecnolgía actualizada para el tema de gestión de obras y presupuestos, ya que actualmente uso una mezcla de ms-access, plantilla html con PHP/jquery, mySQL y jasperreport, y quiero tener una sola aplicación uniendo todo el código y mejorando mi usabilidad, y luego crear el middleware de cifrado.
Todo el tiempo que se eche, es para algo nuevo, de posibilidad remota de triunfar, pero con una utilidad "de nicho" que puede ser el germen de algo más ambicioso, lo cual lo hace más práctico, porque hacer algo ya trillado cuando hay pros y aficionados "con mucho tiempo libre" que crean forks en GIT, salvo para autobombo, lo veo con poco retorno.
El problema, por si no lo he explicado, es que los ERP son demasiado complejos. Aún con su sistema de módulos, siguen siéndolo. El recelo de los que han de usarlo está más que justificado, porque la visibilidad de la información corre en contra del usuario (te controlan otros tus precios, te levantan la obra), con lo que se condena al sistema a ser cerrado y eso es un hándicap para las PYME en donde prima la relación estrecha con clientes y proveedores. Estas PYME acaban dedicando recursos que podrían evitarse con un cifrado inteligente de los datos y un control de la visibilidad de los datos, incluso para los diferentes usuarios de la misma empresa.
¿Monetización? Está en la creación de directorios sectoriales y su publi asociada, en la (difícilísima) integración, comisión mediante, de nuevos clientes a las carteras de almacenistas, en la provisión (con comisión por afiliación) de servers en la nube con VMs preparadas para la gestión y su mantenimiento, con la propia publi en el server, con comisiones con compras conjuntas, etc.. Con el software seguro que no, debe ser algo fácil de instalar y fácil de usar, liviano pero potente, con gran capacidad de tras*misión de info a terceros pero con una seguridad paranoica, por cifrado asimétrico.
Otra posibilidad de monetización es admitir a determinados clientes en tu web, que meterían datos cifrados y usarían tu sistema porque no quieren perder el tiempo instalándoselo para ellos. A la que usen tu base de precios y eso les dirija a un almacenista.. ese almacenista quedará agradecido, claro que sí.
Es una idea. Programas de facturación sencillotes triunfan en las PYME. Su secreto?, van al grano, no como los ERP genéricos, porque están preparados para un puesto de trabajo concreto, el de los contables de micropyme con aversión justificada a los ERP/CRM, esos monstruos.
Hola! gracias por los consejos.
No es un notepad++ inferior, dije que es de estilo/filosofia notepad++ pero no es para editar ficheros de texto. Con inferior me referia a algo mas sencillo sin tantas cosas como lleva notepad++
Lo de alguna app que facilite el comercio, que sea propicio para los adwords, la publi inyectada y demás, no lo he entendido ¿me puedes dar un ejemplo?
A veces he pensado sobre esto que recomiendas, pero sino tienes un tio que esté metido en el ajo ¿cómo vas a saber los requisitos de la aplicacion?. Es decir, de tu ejemplo ¿como voy a crear una aplicación para concesionarios de automóviles sino conozco el negocio y tampoco tengo contactos que lo conozcan?.:
Estaria bien crear un hilo con ideas de aplicaciones para micronichos
Claro, hay que estar metido en el ajo o conocer a uno metido en el ajo al que dar la paliza para aprovechar un nicho.
Ejemplo:
Partimos de la base de que hay claves RSA en la aplicación. Eso permite:
- Cifras con la clave privada, otros (o tú mismo) descifra con la clave pública. También funciona al revés, otros cojen tu clave pública y te cifran algo, y tú lo descifras con la clave privada.
- Idem, pero para firmar.
Estoy haciendo una aplicación con Laravel (un framework PHP, tipo MVC). Tiene (tendrá) las tablas necesarias para el funcionamiento de una empresa de montajes, con clientes, curritos, ofertas y su estructura (partidas, unitarios, asignación de unitarios, reglas de cálculo), proveedores, partes de trabajo, diagramas Gantt de avance de obra, facturación (a pagar) por colección de albaranes, facturación a clientes, por avance de obra, etc..
La idea es que una vez instalado en un server LAMP o WAMP, la info quede cifrada en la base de datos, de manera que puedes tener una clave RSA del server, otra RSA del usuario, otra para cada obra (o capítulo) de cara a exportar info selectivamente, etc..
El intercambio de info sería por intercambio de claves.
Por ejemplo, un almacenista tiene su server (lógicamente cifrado en su parte accesible) y pasándote la clave pública llamada "De los productos de climatización con descuento B", eso te permitiría en tu aplicación de presupuestos coger sus precios, con el ahorro en mails, tener que atender ese mail de petición, atender el mail con la oferta de respuesta y procesarla, meterte en su web de listado de productos, etc.. Actualmente los almacenistas tienen su aplicación para que consultes sus precios, pero no acaba de funcionar, para lo importante se tira de teléfono y mails.
Para la difusión de ofertas funcionaría de la siguiente manera: Un cliente necesita oferta para una obra, necesita instaladores. Se conecta a la web de cualquiera de ellos, web que puede haber obtenido de algún directorio de empresas. Se da de alta como cliente y pone ahí su oferta o pide que se la ingresen (pagando). La misma info ingresada (descripción de capítulos, partidas, unidades de esas partidas) podría servir para trasladar esa oferta a otros instaladores, simplemente habilitando un protocolo con las claves públicas del server y de la oferta y otros instaladores cogerían esa info, la trasladarían a su propio server sin tener que reestructurar la información (porque no es un pdf o un excell), generarían claves de cifrado y el cliente inicial podría acabar con 5 ó 10 claves de otros tantos servers donde los presupuestadores ponen sus precios ocultos a los demás sobre la misma oferta, precios accesibles en red pero "solo para sus ojos".
Sería una especie de integración del sector, una especie de Web of Trust con un software en donde prima el cifrado y el que una empresa no se arriesgue a que le birlen la obra o la venta de productos y servicios. A su vez, hay muchas posibilidades por explorar, como que un exceso de stock del que haya que librarse pueda provocar un aluvión de producto conocido a un extraño bajo precio, rápidamente aceptado en la red, permitiendo el alivio de stocks de los almacenistas. Hay mucha sinergia en una integración sectorial con el mismo software.
Para el tema de, por ejemplo, un taller de coches, estamos en las mismas, en que hay una necesidad de producto de desguace o nuevo y un caos de referencias y proveedores de distinto pelaje a los que les gustaría simplemente soltar su stock actualizado y no depender de las búsquedas que hagan en Google los posibles clientes, sino tener un canal profesional, en donde cada quién controla, por medio de RSA, quién ve a quién, quién accede a qué y la seriedad de la petición de precios.
Hay un gran campo ahí. Instalar un ERP/CRM genérico es un auténtico ****** y cosas que deberían ser en un solo paso (como ingresar datos que ya están estructurados) se convierten en una recodificación de la estructura, a base de picar con la rata y escribir de nuevo lo mismo, pero con la estructura del modelo del ERP elegido. Eso echa para atrás a cualquier PYME, que no quieren ser esclavos de una aplicación costosa en integración, aprendizaje y en uso.
El primer paso, para mí, es tener una aplicación usable con tecnolgía actualizada para el tema de gestión de obras y presupuestos, ya que actualmente uso una mezcla de ms-access, plantilla html con PHP/jquery, mySQL y jasperreport, y quiero tener una sola aplicación uniendo todo el código y mejorando mi usabilidad, y luego crear el middleware de cifrado.
Todo el tiempo que se eche, es para algo nuevo, de posibilidad remota de triunfar, pero con una utilidad "de nicho" que puede ser el germen de algo más ambicioso, lo cual lo hace más práctico, porque hacer algo ya trillado cuando hay pros y aficionados "con mucho tiempo libre" que crean forks en GIT, salvo para autobombo, lo veo con poco retorno.
El problema, por si no lo he explicado, es que los ERP son demasiado complejos. Aún con su sistema de módulos, siguen siéndolo. El recelo de los que han de usarlo está más que justificado, porque la visibilidad de la información corre en contra del usuario (te controlan otros tus precios, te levantan la obra), con lo que se condena al sistema a ser cerrado y eso es un hándicap para las PYME en donde prima la relación estrecha con clientes y proveedores. Estas PYME acaban dedicando recursos que podrían evitarse con un cifrado inteligente de los datos y un control de la visibilidad de los datos, incluso para los diferentes usuarios de la misma empresa.
¿Monetización? Está en la creación de directorios sectoriales y su publi asociada, en la (difícilísima) integración, comisión mediante, de nuevos clientes a las carteras de almacenistas, en la provisión (con comisión por afiliación) de servers en la nube con VMs preparadas para la gestión y su mantenimiento, con la propia publi en el server, con comisiones con compras conjuntas, etc.. Con el software seguro que no, debe ser algo fácil de instalar y fácil de usar, liviano pero potente, con gran capacidad de tras*misión de info a terceros pero con una seguridad paranoica, por cifrado asimétrico.
Otra posibilidad de monetización es admitir a determinados clientes en tu web, que meterían datos cifrados y usarían tu sistema porque no quieren perder el tiempo instalándoselo para ellos. A la que usen tu base de precios y eso les dirija a un almacenista.. ese almacenista quedará agradecido, claro que sí.
Es una idea. Programas de facturación sencillotes triunfan en las PYME. Su secreto?, van al grano, no como los ERP genéricos, porque están preparados para un puesto de trabajo concreto, el de los contables de micropyme con aversión justificada a los ERP/CRM, esos monstruos.
