Cloud Services 4

 

Pues sigamos

Empresas con procesos estándar y algunas adecuaciones mas locales

Con esto me refiero a las empresas que manejan los procesos mencionados anteriormente pero incluiremos aquí las “especializaciones” como podría ser IEPS, Retenciones, addendas especializadas y control de importaciones.

El primer tema es mas contable pero afecta la funcionalidad de una manera importante, los impuestos retenidos y el IEPS. Para el caso de NAV el IEPS no es controlado de forma automática, en si ni siquiera lo conocen por lo que el desarrollo es imperativo y se debe hacer un Add On.

Para el caso de importadores la típica respuesta de un partner seria “usa lotes” y con eso consideraría resuelto el problema; lo que no se toma en cuenta es que para los importadores se debe cumplir con ciertos anexos de la ley. Debemos tener seguimiento de pedimentos (eso lo hace lotes), debemos poner un numero de pedimento (eso lo hace lotes), debemos establecer una fecha de pedimento (eso ya no lo hace lotes, deberemos agregar el campo), debemos saber el puerto de entrada (tampoco lo hace lotes pero igual se agrega el campo), llevar el control de rectificaciones de pedimento (es decir el historial de estas rectificaciones), para el caso de importación directa solo aplica un pago de impuestos pero para la importación mediante almacén fiscal el proceso cambia por tener que calcular el costo de impuestos de extracción, provisionar dichos adeudos, pagarlos y entonces si transferir de almacén, para el caso de empresas de vinos se requiere un control de marbetes adherido a los pedimentos y un largo etcétera que no se arregla con lotes. otra respuesta a esto dada por un partner sin experiencia sería “llévalo por fuera en Excel” y esto solo resulta en mayor carga administrativa al personal del cliente y una mayor probabilidad de errores.

El Add On modifica y/o complementa la funcionalidad natural de NAV por lo que una versión W1 o la especifica para México no contará con esto por lo que un servicio en la nube solo podrá ser ofrecido por un proveedor de app con especialización. Para un proveedor SaaS seria mas factible hacerlo dado que incluye en sus esquemas de trabajo el uso de verticales con el pago correspondiente (siempre y cuando exista dicho vertical).

Ahora bien, entonces no podre utilizar cloud  debido a que tengo procesos críticos como los mencionados?

El proceso de implementación seria similar al anterior (empresa estándar) pero se deberán agregar los add ons a la implementación en caso de que el partner tenga dichos add ons a la venta o en su caso, hacer el desarrollo de las funcionalidades de acuerdo a lo requerido por el cliente. Aquí entra en juego la especialización o verticalización el partner, si se cuenta con un partner que tenga en experiencia en la industria en la que existe el cliente, la solución ya tendría que estar desarrollada y probada por lo que solo habría que migrar objetos o en el mejor de los casos (que es cuando la funcionalidad ya esta bien diseñada y probada) instalar los objetos en la base destino.

En caso de que el partner no cuente con esta especialización, es mejor buscar a alguien que la tenga, ya sea en esa industria o si no existe, al menos un partner con amplia capacidad de desarrollo que pueda con el trabajo.

Como es lógico, se requerirá mas tiempo de consultoría para realizar el diseño y desarrollo de estos requerimientos ya sea para verificar que cumpla con lo requerido o para adecuarlo a la operación.

Finalmente se tendría que definir si se despliega todo en una nube privada hosteada por el partner, una nube publica hosteada por un SaaS y el método de acceso a la solución.

Aquí partiremos un poco el análisis de tipos de empresas para dejarlo para otro post y mejor iniciar con un pequeño análisis de los tipos de despliegue para cloud.

Primer Caso

“100% cloud con un proveedor online.”

  • El acceso a la app será mediante streaming de RTC o cliente Web
  • La base residirá en los servidores del proveedor cloud.
  • El sistema estará natural, es decir sin customizaciones.
  • El cliente  se registrará ante el proveedor cloud.
  • El cliente se hará cargo del aprendizaje de la herramienta además de la preparación de la misma y de los catálogos maestros y carga de saldos iniciales.
  • En dado caso de que el proveedor cloud venda add ons que el cliente pueda agregar y configurar, los podrá utilizar por su cuenta.
  • No habrá personalización de reportes fuera de lo que permita el proveedor cloud con las herramientas básicas de la app.
  • El cliente podrá adquirir el servicio y dejar de utilizarlo (y pagarlo) cuando le sea conveniente.

Segundo Caso

100% Cloud con proveedor online con soporte básico de Partner

  • El acceso a la app será mediante streaming de RTC o cliente Web
  • La base residirá en los servidores del proveedor cloud.
  • El sistema estará natural, es decir sin customizaciones.
  • El cliente podrá adquirir el servicio y dejar de utilizarlo (y pagarlo) cuando le sea conveniente.
  • El Partner pudiera apoyar en el registro ante el proveedor cloud
  • El Partner pudiera apoyar en la preparación de la herramienta y de los catálogos maestros y carga de saldos iniciales.
  • El Partner pudiera apoyar en la capacitación
  • En dado caso de que el proveedor cloud venda add ons que el cliente pueda agregar y configurar, el Partner pudiera apoyar en la selección, implementación y puesta en marcha de los mismos
  • Se podría generar una personalización de reportes fuera de lo que permita el proveedor cloud con las herramientas básicas de la app mediante el apoyo del Partner.

Como es lógico, las tareas que el Partner absorba tendrían un costo por la consultoría y apoyo.

Hasta aquí porque ya va largo este post

Cloud Services 3

Continuación Parte anterior aquí

 

Retomando el tema, entonces, qué es un esquema Cloud?

De acuerdo a lo que vimos en el Taller con Juan Antonio Herrero, la nube debe darnos muchas cosas y además debemos de saber que es lo que queremos y esperamos de la misma.

Deberemos desaprender lo que sabemos en cierta medida y cambiar las formas de pensar y trabajar.  Durante el taller nos pusieron un video buenísimo de como debe cambiar nuestra actitud con la nube y que directrices debemos tomar en cuenta.

Video

Cloud Computing Experts

 

Como dicen en el video, “la información no esta almacenada en mi computadora está en la nube”

Esto implica que la idea preconcebida de que la información esta mas segura en mi equipo debe cambiar, las políticas de seguridad de los servicios en la nube son mejores dado que cuentan con personal experto y certificaciones.

“Y esta nube puede ser accesada desde cualquier computadora, en cualquier lugar del mundo.”

Pensemos en oficinas remotas, sucursales, sin necesidad de tener que ir a cada lugar a instalar programas. Pensemos en vendedores que acceden mediante una Ipad, un Windows phone, ver toda la información que requieren para su trabajo.

“Y para una empresa, como si toda esa gente trabajando en sus computadoras pudiera logearse a una base de datos que tiene todos los programas que necesitan”

Pensemos ahora en que aun que en mi equipo no tenga office, pueda usarlo, que al abrir sesión cuente con todos los programas que necesito, ERP, Office, impresoras, etc.

Para terminar aquí tomemos esta ultima parte

“Se trata de poder de procesamiento. Es acceso sin el costo de propiedad. Es alta velocidad y escalabilidad, análisis avanzados y acceso mas rápido a los datos”

El juego ha cambiado

La nube permite grandes juegos a las empresas de cualquier tamaño, en cualquier industria.

Es la fuerza de las ideas no el tamaño de la compañía lo que importa”

Deberemos de cambiar de paradigma en muchos casos, en otros adecuar nuestros paradigmas a una nueva versión mas ad hoc a la nube.

Como adecuar un ERP a la nube?

Inicialmente queremos que este en la nube, esto lo podemos lograr mediante el uso de hosting o co-ubicación de servidores (para nubes privadas), contratación de SaaS para nubes publicas. La base de datos almacenada ahí arriba, el medio de acceso puede ser mediante un stream de RTC utilizando Hyper-V y App-V de Microsoft como SaaSplaza, teniendo un buen ancho de banda en nuestras oficinas y desde nuestras casas y dispositivos móviles.

Si la empresa requiere adecuaciones del ERP a sus procesos, es sencillo, hablemos de un proceso híbrido, ni 100% cloud ni 100% on premise, definamos las etapas de análisis, diseño y desarrollo y al momento del despliegue, crear una nube privada para dicho cliente por parte del Partner.

El método de entrega de la aplicación dependerá de lo que mas convenga la app, puede ser mediante stream (sencillo con las herramientas pero el partner debe contar con personal capacitado para crear, instalar, administrar y dar soporte a esta plataforma)  o mediante Web (se pueden utilizar tecnologías de Sharepoint para esto).

Así, podríamos dividir a las empresas en varios rubros y comenzare a una lista que puede crecer, disminuir o variar de acuerdo al gusto de cada uno.

Empresas con procesos estándar

Por procesos estándar me refiero a que se acoplen a lo que hace el ERP (un poco de acuerdo a la filosofía SAP), sus necesidades son vender y comprar productos y servicios dejando un registro contable y llevando el control de CxC y CxP. Sin aspectos fiscales complicados (es decir IEPS o transportistas con retenciones), un esquema de facturación simple sin particularidades de addendas. Con necesidades básicas de reporte que puedan ser generadas por NAV y mediante extracción de datos a Excel (no por básico debe de entenderse simple, las capacidades de reporteo estándar de NAV son extensas).

Este tipo de empresas podría en teoría utilizar un servicio 100% cloud con NAV BE estándar siempre y cuando el proveedor del servicio le ofrezca la facturación electrónica ya que este es un requerimiento para México (o sea que una versión W1  podría no funcionar, deberá ser la especifica de México). Claro que podría utilizar un partner para ayudar con este rubro. Necesitará también establecer una estrategia de capacitación que le permita aprender NAV para lo cual puede remitirse al Customer Source (habrá que ver si hay acceso a este sitio para clientes cloud) o que el proveedor de la app tenga manuales y/o videos en línea.

El trabajo a realizar seria subir sus catálogos maestros, seguir las guías de configuración (pensemos en metodología RIM), subir sus saldos iniciales y comenzar a operar.

Utilizando un partner para la “implementación”, sería necesaria una pequeña consultoría para definir la configuración a utilizar, la capacitación a usuarios, la preparación de información para catálogos maestros, implementación de factura electrónica, subida de datos y apoyo en puesta en marcha.

Aquí cabe aclarar un punto, me he encontrado con empresas que no entiendo la razón pero prefieren pagar 500 horas de consultoría a 50 USD que 50 horas de 200 USD.

Cloud Services 2

Continuación, articulo anterior aquí

Ahora comencemos a establecer como es una implementación normal de un ERP (de acuerdo a SureStep)

La implementación se divide en etapas a grandes rasgos:

  • Análisis
  • Diseño
  • Desarrollo
  • Pruebas
  • Despliegue
  • Cierre

Cada una de estas etapas se deben seguir para asegurarnos que la aplicación cumple con las necesidades del cliente.

Análisis.- Para revisar los procesos del cliente y definir como debe trabajar la aplicación.

Diseño.- Para establecer un flujo de operaciones en el ERP que se adapte lo mas posible a los procesos de cliente y en algunos casos, se debe adaptar a procesos específicos que no pueden ser cambiados o dejados de lado.

Desarrollo.- Aquí se procede a customizar la aplicación para cumplir con el diseño.

Pruebas .- Realización de bancos de pruebas con el cliente para liberación de aplicación.

Despliegue.- Poner en marcha la aplicación.

Cierre.- Termino de trabajos.

En el caso especifico de un sistema 100% en Cloud, las etapas cambian por decirlo de alguna manera dado que no hay análisis por parte de un partner, el cliente se conecta y escoge la aplicación, si puede se registra e inicia una etapa de pruebas para ver si le es conveniente el uso de dicha app.

Durante estas pruebas, puede ver si es factible customizar su app y que procesos debe cambiar, también es cuando se da cuenta de las diferencias entre un proceso estándar y su propio proceso de trabajo. Este debería de ser el breakpoint, decidir si continua con la app o busca otra que se asemeje mas a lo que necesita lo que en el caso de un ERP en Cloud no será fácil debido a que los ERP´s están diseñados en base a las mejores practicas bla bla bla.

Lógicamente, el proceso descrito lleva su tiempo y su trabajo ya que habrá que subir datos reales e clientes, proveedores y productos. Además hay que agregar la curva de aprendizaje de la persona que esta probando, las ayudas que el sitio pueda prestar son importantísimas ya que deben basarse en casos de negocios no en funcionalidad para que el posible cliente pueda entender el uso. Y si finalmente se decanta por esa app, iniciar un proceso de autoaprendizaje tanto de él como de su personal.

Que tan práctico o viable es este escenario?

A mi punto de vista funciona bien para empresas de menos de 10 usuarios donde el Dueño o Director o el IT Manager controla la operación, no tiene procesos de producción o si los tiene son basados en listas de materiales, la persona que analiza la posibilidad de uso del ERP tiene el tiempo suficiente o necesario para revisar a fondo la app. Cuantas empresas pueden contar con esto?

Ahora bien, el esquema contable, normalmente cada contador en México utiliza un derivado del catalogo de cuentas de COI mismo que normalmente utilizan para todo. en la solución Cloud deberá ser posible utilizar este esquema contable a fin de que no se cause al contador una paradoja irresoluble.

Se debe considerar que la app maneje el IVA como en México y para ciertas empresas, el IEPS.

No debemos dejar de lado el esquema de facturación electrónica en ambas vertientes, tanto CFD como CFDi ya que las empresas que estén en CFD al día de hoy no tienen ninguna obligación de cambiarse a CFDi pero en un futuro deberán hacerlo ya que existe la posibilidad de que el SAT requiera dicho cambio.

Derivado de la factura electrónica, vienen las famosísimas addendas, no hay una utilización estándar de la addenda ya que cada cliente de los clientes (los autoservicios y tiendas departamentales en México) solicita información de acuerdo a sus necesidades requerimientos y caprichos por lo que la addenda de AMECE se usa como base para infinidad de combinaciones y personalizaciones así como diferentes métodos de entrega (EDI, HTML, FTP, WebService).

El método de carga de datos también influye de sobre manera ya que la carga de cierta cantidad de productos puede hacer fácil o difícil la utilización de la app; cuantos artículos son factibles de capturar? mil, cinco mil, diez mil??

Actualmente estoy cargando una base con 46 mil artículos diferentes, como es lógico, la preparación de la información lleva su tiempo al cliente pero en lo que a mi respecta, me tardaré tal vez dos minutos en subirla una vez terminada; la app deberá contar con alguna funcionalidad que permita realizar esto.

Aunque parezca que estoy en contra de la Nube, la realidad es que quiero poner aquí todas las opciones y poder reflexionar sobre el mejor esquema para la entrega de los servicios a los clientes

Hasta aquí en este documento.

Cloud Services 1

Bueno, en días pasados asistí a una
plática-curso la cual se trató de cloud services y vimos varias cosas relacionadas
a este esquema de trabajo por lo que me pondré a hacer varios artículos sobre el tema.

Que es la nube?

Según se explica en Wikipedia “La computación
en la nube
concepto conocido también bajo los términos informática en la
nube
, nube de cómputo o nube de conceptos, del inglés
Cloud computing, es un paradigma que permite ofrecer servicios de computación a través de Internet.”

Es decir, el servicio está ahí para
cuando uno quiera utilizarlo y podrá hacerlo mediante una cuota por el uso o de
plano de forma gratuita en algunos casos. Si vemos los servicios de Google
donde nos permiten utilizar aplicaciones similares a office de forma gratuita o
el web App de office de live podremos entender la parte gratuita; usar Excel en
live y poder guardar los archivos generados, compartirlos y verlos en cualquier
momento es una gran característica además de ser gratis.

Ahora bien, que implica que sea
“gratis”? en algunos casos significa funcionalidad limitada. Para el
caso de los servicios de pago, podemos escoger alguna funcionalidad más
avanzada o completa mediante módulos que se van pagando.

Por ejemplo el office 365 permite
utilizar más funcionalidad que la versión web, por ejemplo la parte offline,
lync y Exchange; sin embargo seguimos limitados a lo que nos ofrezca el proveedor.

Como aplicaría esto para un ERP?

Esta es la parte difícil o más
complicada, pensemos en la aplicación más vendida de este tipo, hay ocasiones
en las cuales el flujo de trabajo no se asemeja a la operación real de la
empresa, cual es la solución? cambiar el proceso de la empresa para que se
asemeje a lo que el sistema puede hacer ya que “los sistemas ERP están
creados en base a las mejores prácticas bla bla bla”. Esto es un buen
argumento de consultoría y ventas pero ya en la vida real no siempre es tan
fácil, sobre todo cuando un cliente está pagando una gran cantidad de dinero.

Qué hacer entonces?

Actualmente existe algún grado de
personalización en las aplicaciones actuales en Cloud, por ejemplo en el caso
de Dynamics CRM Online que permite agregar campos, desarrollar módulos más
específicos, crear flujos de trabajo, etc., sin embargo, para aplicaciones más
grandes esto es más complicado. Lo importante es poder probar la aplicación,
ver las posibilidades de customización de la misma, la facilidad de hacerlo y
sobre todo, que la herramienta pueda adecuarse a los procesos
“buenos” y “específicos” de la empresa.

Veamos la situación desde el punto de
vista del proveedor inicialmente.

  • La aplicación debe ser lo más estándar posible para
    que pueda aplicar para muchos clientes.
  • Debe ser fácil de administrar
  • Debe ser factible rentar la licencia (no usar on
    premise)
  • Debe ser multitenancy

Lo anterior es algo que importa al
proveedor y no nos meteremos más en este punto, mejor veámoslo desde el punto
de vista del cliente (alguna vez fui cliente).

  • Que sea fácil de usar
  • Que sea fácil de configurar
  • Que cumpla con los requerimientos de la empresa
  • Que sea barata
  • Que haga lo que necesito
  • Que me permita controlar la empresa
  • Que me permita saber dónde estoy gastando mas
  • Que me diga que es lo que se vende mas
  • Que no me permita cometer errores
  • Que pueda reportear fácilmente
  • Que me controle las compras
  • Que me permita controlar a los clientes,
    vendedores, productos, almacenes, producción
  • Y un largo etcétera.

Difícil no?, y hacerlo con una
aplicación estándar es un poco más difícil, hacerlo sin soporte incrementa la
complejidad y, finalmente, que pueda ejecutarse en cualquier equipo sin
importar que este sea un teléfono, una pc, una ipad, etc.

Cambiemos un poco de tema para poder
establecer que es la nube actual (por lo menos lo que entendí de la tecnología
de Microsoft y su plan)

Las aplicaciones en la nube de
Microsoft se basan principalmente en modelos como Office 365 y Dynamics CRM.
Para el caso de bases de datos tenemos Azure.

En Office 365 tenemos precios desde 6
USD por usuario por mes y lo que necesitamos es simplemente descargar las
aplicaciones, instalarlas en nuestro equipo (esto para la parte offline),
configurar nuestro espacio en la nube y sincronizar los archivos. Para el caso
de empresas, crear el sitio de sharepoint donde compartiremos los archivos.

En el caso de Azure, es una plataforma
de desarrollo en la nube que nos permite entre otras cosas, crear bases de
datos, desarrollar en .Net, distribuir todo lo anterior en internet mediante
clientes web y todo por una módica cuota.

Dynamics CRM es el producto en nube más
avanzado a mi parecer, es una aplicación de renta, configurable, administrable,
modificable y sencilla de entender, aunque realmente es un CRM, también permite
“extenderlo” para operar como ventas y compras, crear flujos de trabajo y
controlar los procesos de ventas de una empresa (claro que también compras e
inventarios además de servicios y varios etcéteras), pero contabilidad no.

Ya viendo la oferta de Microsoft actual
(ya sé que me falta Intune y Windows Server Hyper-V), dónde entran los ERP´s?

Para el caso de Ax, la plataforma está
bastante avanzada y podremos encontrar más información buscando en internet,
para el caso de NAV (que es el que realmente me importa), Kirill Tatarinov
(Presidente de la división de Business Solutions) mencionó en el Convergence
2011 que:

Dynamics NAV 2009 R2. Dynamics NAV remains one of the largest products
in our portfolio, and in many geographies the largest product in our portfolio,
and we have a very vibrant and growing group of Dynamics NAV customers.

Last December, ahead of schedule, we delivered
an update to an already great product, really deepening capabilities in
business intelligence and providing an enormous depth of report and analytics
that customers can get from Dynamics NAV deployments.

This was also a release that took
interoperability to a completely new level by connecting Dynamics NAV with a
broad range of Microsoft products such as Dynamics CRM, but also connecting
Dynamics NAV with the cloud, and enabling a new, broad set of scenarios for our
existing and new Dynamics NAV customers, scenarios like online payment
processes, scenarios like running Dynamics NAV from the partner-hosted cloud,
and SaaSplaza is one of those successful partners who are now successfully
hosting Dynamics NAV for any of our customers, taking advantage of application
virtualization technology that is now part of the Dynamics NAV product.”

Que es lo importante de este extracto
que puse?

Conectando Dynamics NAV con la nube y
habilitando un gran conjunto de escenarios como ejecutar NAV desde nubes
hosteadas por partners, y SaaSplaza es uno de los partners exitosos que hostean
NAV para cualquiera de sus clientes tomando ventaja de la virtualización que
ahora es parte de NAV

Revisando el site de SaaSplaza me
encuentro con un esquema SaaS (Software as a Service) y NAV se entrega streamed
(lo cual me parece de lujo, aquí el video http://www.youtube.com/user/herbprooy#p/u/14/_okvCvd95Hg).
La entrega se ve rápida, pero en México contamos con enlaces de baja velocidad
y el ancho de banda es caro lo que impactaría en los costos finales de utilización
del ERP, eso sí, la tecnología de virtualización es bárbara y necesito ponerme
al día en eso.

Revisando más a fondo, este esquema de
SaaS permite utilizar verticales desarrollados y comercializados a nivel
mundial pero esto no resuelve muchas de las peticiones de los clientes en México
ya que son verticales estandarizados. Se podría hablar con SaaSplaza y “subir”
un “vertical”  pero tendría uno como Partner
que desarrollar todo, probar en sitio y después negociar con SaaSplaza la
subida para crear la base de datos y aplicar los objetos. Finalmente el cliente
tendrá un NAV personalizado ejecutándose en la nube pero aclaremos que esto no
es estrictamente “nube” ya que es realmente un esquema hibrido de
implementación, es decir, se sigue el proceso de implementación normal de NAV y
se monta en un servicio externo al cliente final.

 Hasta aqui  ya que el post esta largo.