Combinar los sistemas de contabilidad de una sucursal remota y su integración con la estructura matriz es una tarea bastante difícil, incluso dentro de Rusia. Y cuando el cliente está en el extranjero, todo el proyecto puede complicar la falta de experiencia en las leyes fiscales locales y el conflicto de mentalidad. Mi nombre es Stanislav Gotz, soy el jefe del departamento de desarrollo de sistemas ERP de Lamoda y en esta publicación les contaré sobre esta experiencia: sobre la implementación de un sistema ERP en nuestra sucursal alemana.
Nuestra filial alemana compra bienes y los vende a una entidad legal rusa. El sistema Tsenit utilizado en él permitía mantener registros solo a nivel de datos financieros: quién, quién y cuánto dinero debía, cuándo tuvo lugar la compra o venta, etc. Era imposible llevar a cabo la contabilidad de los bienes y las tareas logísticas utilizando las herramientas de Tsenit; para resolver estos problemas, se tuvieron que utilizar herramientas adicionales, que afectaron negativamente la velocidad y la confiabilidad de todo el sistema. Como resultado, los datos se dispersaron en varias bases de datos.
Además, la entidad jurídica alemana debe presentar informes, pagar impuestos y aprobar auditorías, y con los sistemas contables existentes no fue fácil resolver tales problemas.
Para comprender por qué esta o aquella transacción financiera se realizó en Tsenit y para responder preguntas simples de las autoridades fiscales o auditores, tuve que extraer manualmente grandes cantidades de datos en Excel y contactar al departamento de logística.
En algún momento, se decidió combinar la contabilidad y las finanzas con la logística en un solo circuito dentro del marco de un sistema ERP de una sola sucursal. Como el software principal se eligió Microsoft Dynamics 365, antiguo Dynamics AX, o incluso más fácil, Axapta. Casi no hay clientes rusos que utilicen la solución en la nube de este sistema (para ser más precisos, nos convertimos en el segundo), pero fue el más adecuado para nuestros propósitos.
Tiempo, presupuesto y creencia en un futuro brillante
Teníamos límites de tiempo estrictos: el lanzamiento de dicho sistema en medio de un año fiscal requería la transferencia de todo el conjunto de datos históricos, lo que sería una tarea imposible, porque en el sistema anterior, la contabilidad de bienes estaba prácticamente ausente y se mantenía en hojas de cálculo. Pero al comienzo del período del informe, es suficiente transferir solo saldos. Por lo tanto, fue necesario lanzarlo el 1 de enero de 2019 o posponerlo para otro año. Los procesos asociados con el comercio y la logística del almacén no son particularmente complejos, y nos pareció que no habría problemas con los plazos.
Además de los plazos, también hubo un problema de presupuesto: implementar y mantener su propia infraestructura de TI en Alemania y comprar licencias de software corporativo es demasiado costoso por usuario.
Dado que no más de 20 personas participan en los procesos comerciales alemanes, nos decidimos por la solución en la nube Dynamics 365. Para pequeñas sucursales remotas, el esquema SaaS es óptimo, le permite obtener todo el software y los entornos de desarrollo necesarios para comenzar la implementación inmediatamente después de firmar el contrato con el proveedor.
La política de licencias de Microsoft Dynamics 365 es extremadamente simple y supone un precio fijo para una licencia de usuario por mes, mientras que el número de usuarios se puede aumentar o disminuir. Este fue otro argumento para elegir este producto de software en particular.
Trampas
El principal problema estaba fuera del plano técnico: no conocíamos todos los requisitos de la legislación europea para mantener registros en dichos sistemas. Microsoft Dynamics 365 cubre una gran cantidad de procesos comerciales; Se lanzan los llamados paquetes de localización que le permiten personalizar de manera flexible la solución a los detalles de la legislación de un país en particular. Si el equipo de desarrollo estudió la versión rusa durante mucho tiempo, nunca encontramos una versión para Alemania. Establecer una solución de este tipo por su propio equipo sería una tarea difícil.
A la gerencia alemana le preocupaba que la parte rusa no pudiera hacer frente a la tarea debido a la falta de experiencia y conocimiento en impuestos y contabilidad locales. Como resultado, elegimos el término medio y atrajimos consultoría externa. Se suponía que debía cerrar las brechas asociadas con los requisitos legales europeos, proporcionar una auditoría de la migración del sistema financiero anterior, analizar las descripciones de los procesos comerciales, optimizarlos y adaptar la solución futura con el máximo uso de la funcionalidad estándar. Si es necesario, se planificó que se completaran, lo que gradualmente llevó al equipo ruso al desarrollo.
Inicio de implementación y transferencia de datos.
De manera predeterminada, tenemos derechos para tres entornos: BUILD, para ensamblar el código creado por diferentes desarrolladores en una sola aplicación, SAT (Prueba de aceptación estándar), para realizar pruebas de aceptación del usuario, y PROD, para la operación. Además, las máquinas virtuales dev-box se implementan para cada desarrollador en Azure. Toda la infraestructura se gestiona y supervisa a través de un único portal: servicios de ciclo de vida , y una característica del proceso de personalización es que cualquier mejora ingresa al entorno PROD solo a través del SAT.
Debido al hecho de que Microsoft Dynamics 365 fue elegido como el nuevo sistema, la transferencia de datos fue relativamente fácil de implementar utilizando los paquetes de datos disponibles en la caja. Dynamics 365 tiene una estrecha relación con los productos de Microsoft, incluido Excel: para el usuario, parecía una hoja de cálculo conectada a los servicios de Dynamics 365 a través de
ODATA . Mediante la extensión de Excel, los usuarios publicaron datos directamente en el sistema. El lado alemán preparó las plantillas, señalando las columnas requeridas en ellas. Los usuarios completaron estas plantillas y los consultores controlaron el proceso de importación.
Entre otras cosas, desde el antiguo sistema de contabilidad, los consultores transfirieron información sobre proveedores y clientes, así como los saldos de las cuentas del libro mayor. La transferencia directa de todos los datos sobre bienes requeriría un tiempo y esfuerzo considerables, y tratamos de resolver este problema de una manera más eficiente. Se implementó la integración del nuevo sistema de contabilidad de la sucursal alemana con el principal sistema ruso, en el que se ubican los datos maestros sobre bienes. Al final del año, no teníamos saldos físicos en Alemania y, como resultado, era necesario transferir del sistema anterior solo la información de fondo necesaria para una mayor distribución de bienes. Por lo tanto, fue posible prescindir de la transferencia de todos los datos históricos sobre bienes, lo que ahorró tiempo.
Half-outsourcing: conectando al equipo ruso
Después de comenzar la implementación en junio de 2018, esperábamos resolver todos los problemas antes de las vacaciones de Año Nuevo, pero además de los problemas de lenguaje natural en tales proyectos, aparecieron dificultades de comunicación. Los consultores alemanes han respondido durante mucho tiempo a las consultas. Un empleado no puede trabajar sin un descanso por más de 6 horas seguidas. Después de terminar el trabajo, debe tener un mínimo de 11 horas de tiempo libre del trabajo. Y cuando un especialista trata con otro cliente, no se le puede preguntar sobre nada. Tal enfoque formal ha afectado el momento. En algún momento, el contratista propuso para el nuevo año lanzar solo la contabilidad financiera, que ya funcionaba en el sistema anterior. Esto no nos vino bien. Desde 2013, hemos estado implementando Axapta de forma independiente en Lamoda, y en 2016 transferimos por completo toda la contabilidad de 1C. Los procesos en Rusia son mucho más complejos, por lo que sabíamos que el proyecto podría completarse a tiempo.
Decidimos atraer al equipo ruso, tomando de nuestros colegas de Alemania toda la personalización y el desarrollo de la funcionalidad del sistema. De hecho, dejamos al contratista externo solo consultoría, configuración de tareas y diseño funcional. Nos dijeron lo que había que hacer, lo hicimos, y luego probaron y aceptaron los resultados. La velocidad de implementación ha aumentado, pero pronto una organización de este tipo de flujo de trabajo requirió revisión: el consultor financiero alemán se fue de vacaciones durante tres semanas. Para el proyecto, este plazo se volvió crítico, las tareas principales para nosotros estaban relacionadas precisamente con las finanzas, los impuestos y similares. También tuve que asumir esta parte, como resultado, nuestros expertos descubrieron que la legislación fiscal europea no es mucho peor que la externa.
Además, constantemente había algunas tareas no estándar. Gracias a la profunda inmersión del principal equipo ruso en desarrollo, pudieron resolverlos relativamente rápido. Además, las soluciones se desarrollaron inicialmente teniendo en cuenta el conocimiento de todos los sistemas y procesos utilizados en nuestra empresa.
Una de estas tareas es la integración de un nuevo entorno de nube con el sistema ERP ruso existente. Ya implementó la funcionalidad relacionada con el trabajo de los compradores, y no queríamos duplicar el código para no complicar su soporte. Como resultado, los pedidos para la compra de bienes de proveedores extranjeros se crean en el ERP ruso y luego se transfieren a la nube alemana.
En el proceso de implementación, el equipo ruso ha dominado un enfoque de desarrollo completamente nuevo para nosotros y nuevas herramientas. Solíamos usar nuestro propio IDE para Axapta, pero aquí cambiamos a Visual Studio y Azure DevOps. Durante la implementación del proyecto, las versiones de software cambiaron y nuestros especialistas conocieron todas las delicias del desarrollo paralelo para entornos de nube; en términos técnicos, fue muy interesante.
SureStep vs Agile: problemas de lanzamiento
Los colegas de Alemania trabajaron según la metodología Microsoft SureStep. Este es un enfoque inflexible que está más cerca de la clásica "cascada". Implica en cada etapa la documentación de todo, la preparación de diseños funcionales y técnicos, pruebas rigurosas con el lanzamiento de protocolos, el registro de procesos en algún sistema de modelado, etc. Con una solicitud de dicha documentación, los colegas nos contactaron un mes antes del lanzamiento. El nuevo sistema ERP para ese momento ya estaba más o menos funcionando. Asumiendo su lanzamiento en seis meses, hemos elegido métodos de desarrollo más flexibles: stand-ups diarios, discusión de tareas y lanzamientos semanales. Para la documentación, utilizamos elementos de trabajo en Azure DevOps, también reflejaban el progreso del proyecto y confirmaban los resultados de la prueba.
Dado que el sistema está nublado, la decisión final sobre su lanzamiento en producción fue tomada por Microsoft, todos los contactos con los cuales fueron realizados por nuestros contratistas. Ellos, a su vez, no estaban listos para enviar una aplicación sin toda la documentación necesaria desde el punto de vista de la metodología SureStep. Como resultado, el lanzamiento oportuno del proyecto estaba en peligro.
Decidimos ponernos en contacto con el proveedor por nuestra cuenta y recibimos la aprobación para entrar en producción, luego de lo cual mejoramos de manera tranquila y sistemática la funcionalidad del sistema por nuestra cuenta. Los expertos alemanes nos ayudaron a transferir la configuración del entorno de prueba al supermercado. Después de eso, establecieron la contabilidad y corrigieron las deficiencias si teníamos algún comentario.
Prueba de batalla
Gracias a la participación oportuna de nuestro propio equipo, logramos cumplir con los plazos y lanzar el sistema el 1 de enero de 2019, como estaba originalmente planeado.
El nuevo sistema de contabilidad ha combinado la parte financiera y la logística, ya hemos pasado por informes trimestrales en Alemania. Antes de eso, logramos llevar a cabo el llamado cierre del mes sin pérdida significativa en términos. Al lanzar esta clase de sistemas, los retrasos son inevitables, pero en enero llegamos tres días tarde y en febrero, solo uno. Mientras recopilamos datos del sistema de forma manual, ahora el equipo de desarrollo ruso se dedica a la automatización de los informes. Los problemas están relacionados principalmente con el factor humano: es difícil para los empleados realizar nuevos procedimientos para ellos, y es seguro que surgirán algunas asperezas.
Ahora tenemos una imagen transparente de los productos a nivel de número de almacén individual (SKU) y datos sobre saldos en almacenes europeos intermedios. No fue posible cerrar una serie de tareas hasta el final: existen dificultades con la integración con un banco alemán y una serie de problemas menores para la resolución oportuna de los cuales los recursos del equipo interno no fueron suficientes; inicialmente se supuso que el contratista cerraría este frente. Básicamente, todo se reduce a la falta de un nivel adecuado de automatización y un cierto aumento en la cantidad de trabajo manual para los usuarios finales. Ahora estamos cerrando las brechas gradualmente con las fuerzas de nuestro equipo y con la ayuda de un nuevo socio con una sucursal en Rusia.
La ventaja de que nuestros desarrolladores trabajaron en el proyecto también fue el hecho de que inmediatamente en la etapa de implementación, se realizaron mejoras para mejorar la funcionalidad del sistema.
El equipo ruso ha desarrollado una determinación automática de impuestos sobre las órdenes de compra y venta. Por defecto, el sistema requiere que el contador establezca manualmente el esquema de impuestos cuando procesa la factura y registra las transacciones. En este caso, es necesario tener en cuenta el país de envío, el país de registro del proveedor, quien recoge los bienes (destinatario o proveedor), quien envía los bienes a la Federación Rusa (entidad legal alemana o rusa), ya sea que los bienes se lleven directamente del proveedor a Rusia o si la carga se consolida en Europa. El contador no tiene todas estas sutilezas para cada entrega. Hemos automatizado completamente el proceso en el sistema para que el proveedor logístico responsable introduzca los parámetros iniciales necesarios. Además, el sistema, en función de la configuración creada, determina el esquema de impuestos y las entradas contables necesarias. Todos los datos se consolidan automáticamente en los informes estadísticos necesarios para Alemania y la declaración de impuestos. Por lo tanto, las responsabilidades se distribuyen mejor entre los especialistas, aumenta la velocidad y la confiabilidad del trabajo.
Resumen
Inicialmente, esperábamos que la mayor parte del trabajo recaería en el contratista y, como resultado, todos los bloques clave fueron creados por nuestro propio desarrollo. Por lo general, el lanzamiento de ERP lleva de 1 año, pero logramos comenzar 6 meses después del inicio del proyecto, de los cuales el desarrollo activo duró solo 3 meses.
Como resultado, obtuvimos una experiencia única, que decidimos compartir. La cooperación con contratistas extranjeros que conocen las condiciones locales tiene sentido práctico, pero no debe esperar milagros de ellos. Si tiene
su propio equipo fuerte , debe externalizar solo la consultoría y la configuración de tareas, así como las pruebas.
Este no es el final de nuestra historia. Un nuevo desafío está asociado con la introducción en Rusia de un sistema nacional unificado para marcar productos. Los legisladores pospusieron su fecha de lanzamiento para 2020, pero a partir de julio queremos marcar cada par de zapatos con un código de barras único antes de pasar por la aduana. Además, siempre hay tareas relacionadas con la optimización del rendimiento. Bueno, hay muchas otras ideas y planes. En su implementación, ahora confiaremos más en nuestras propias fortalezas, para lo cual primero tendremos que "engordar" un poco.