Diary of a project

Diary of a technology project

In this article I will explain chronologically the steps followed for a major technological changes which have been the main actor.

All department responsible for information technology can be immersed in a large technological change in your company, for this reason I will explain my personal experience in a project.

Project Concept

The project idea was to make a technical change in 3 different areas: area of systems, ERP + CRM and mobility tools. From this logical schema will explain chronologically the steps taken and decisions made with their differences or opinions.

Gráfico resumen 3 áreas cambio tecnológico

In this newspaper is to explain each of the following project stages:

Gráfico de resumen de las etapas de un proyecto tecnologico

Journal chronological events

August year 1: Start of project

- Starts the project.

- During the first weeks of August the management department gives me needs to make a technical change in the company to meet the objectives of consolidation and expansion of the company for the next five years.

- You start this month to gather all the needs or requirements of the company, in all departments. The embodiment of

- It was decided to start looking at the market that can fit the needs of the company. In this search we focus primarily on two areas: finding products that manage ERP and CRM , and products that manage mobility tools for 3 departments: distribution, sales and service.

September year 1: Search CRM and ERP products

- We started the search with products that manage CRM to meet the needs of the commercial department, which are a fundamental part of the company's business. In this search we contacted companies that distributed the following products CRM : MS Dynamics CRM , Salesforce , CRM on-demand , Sugar and vTiger .

- We started having contact with companies that suminstran these products. We must point out that before I came to the company, it had installed vTiger ( CRM free) but suspiciously stopped working the overnight and was forgotten for many months. We then focus on more robust products, we saw Sugar was another CRM and other payment free as Salesforce , CRM on-demand or MS Dynamics CRM .

- Salesforce offered us 1 month trial of the product, which we take to define exactly the needs of the company with a CRM because Salesforce is a CRM via Internet, as software as a service (SaaS), ie you pay a user fee and month. This is found that the share of abuse, was one of the reasons for its final disposal. Using Salesforce could define final requirements for the CRM even should be the user interface for business at ease. Note that Salesforce is a very configurable and adaptable to user requirements ( explain in future articles this product in more detail ).

- We interviewed companies parametrizaban Sugar to taste both as Vtiger, but discarded due to the large dependence on the partner as the standard of these CRM did not meet our real needs.

- We focus then on another Oracle product, on-demand CRM , other CRM software as a service, but given the option of having it on-premise, that is installed locally. This CRM was very much like Salesforce and also fully customizable, costs were slightly lower than Salesforce . We added to the list of options.

- In between Salesforce and on-demand CRM , we contacted several Microsoft partners through its website to meet and see the product in MS Dynamics CRM . At the end were 3 partners who visited us. During several meetings we conclude there was no point separates the CRM of the ERP , as the CRM must have access to much information possessed by the ERP . One of these consultants (Microsoft partner) who visited us according to our needs we recommended the use of the CRM module integrated into the ERP MS Dynamics NAV .

- We begin a new phase two needs to unite ERP and CRM in one integrated solution. We began to explore the market for ERP and we came across the following: MS Dynamics (AX and NAV), SAP (All-in-One and Business One), Sage (X3 and Logic Class), Nexus, ERP and other Marine who contacted us directly ( in future articles will explain these products in more detail ).

October Year 1: Interviews with partners of ERP

- We started with meetings with many partners, we went to find them first to the web from Microsoft, SAP and Sage, and chose certificates and local partners, although some of them were headquartered outside.

- We began conducting interviews of basic knowledge of the product, through presentations and demonstrations. We clearly saw that the option of joining ERP + CRM in a single integrated product, was the most correct decision.

- The Marine ERP Inology company found a good product, but we believe it meets the needs of our company, mainly because it is a very standard, but can be configured pretty, is not sufficient and would involve expensive developments. This product is considered quite expensive. Close to 130,000 € to implantation.

- The Nexus ERP SIE company is the current ERP we have in the company. We decided to give a vote of confidence and analyze the new versions (7.0 and 8.0) to see if they fit the needs of the company. Certainly the product in version 8.0 has evolved greatly, especially visually, but the background remains the same and the same limitations. EVALUATION follow his discarded.

- During this month also saw presentations from other ERP more "humble" than try to equal respect with others. Obviously not nearly did not meet the basic needs of the company or were adjustable.

- This month we begin to see mainly the solutions from Microsoft and SAP, probably the two companies with solutions ERP world's largest. We start with the largest SAP partner in Spain, the company INSA , we initially proposed the SAP Business-one. We did a session to view the product demo and others to give them the business requirements. We presented a first proposal we reviewed.

- We met with 8 consultants offering their services to implement ERP from Microsoft, MS Dynamics NAV , we saw several demos of the product, both in its classic profile as oriented roles. We found a very good product.

November year 1: interviews with partners of ERP systems area definition and mobility partners

- We continue this month interviewing us with technology partners related to the product MS Dynamics NAV . Together with these partners we also begin to define what had to be the area of systems to support new structural needs of the company.

- In the area of systems began to discuss possible plans in the end they decided to gamble by virtualization and analyzed two products: HyperV and VMware . In the area of systems opted for a scheme with consolidation (virtualization) and availability ( see virtualization articles on this blog ). Importantly, the issue of availability, as percentages for high availability triggers investment, which, based on our business and analyzing the possible failure scenarios availability is decided to opt for a solution concerning availability, price- benefits. 2 machines were chosen to support physical 5 virtual machines with high availability, Fibre 1 cabin storage, a backup device library, for a Cisco firewall to manage VPNs , and several core switches and access. The budget in this area amounts to about 60,000 euros.

- We started to attack also the issue of mobility tools. Let us first define the concept. It aims to provide various company departments, such as distribution and service of a mobility tool for managing the day to day work. For a technician for example, to manage all its working parts and all the information you need. Specifically, we interviewed 4 companies: Antay Mobile Solutions , JSV , ExpandIT and a Microsoft partner offering Mobile Solutions ( in future articles will explain these products in more detail ).

- We have seen different demos of these mobility tools, all of which were very similar although there were 2 that stood out above the others: Antay Mobile Solutions and ExpandIT . These two very powerful solutions offered products, covering almost 90% of our needs, and the other 10% could be heavily parameterized without any complications. These two tools also gave an added value as automatic locations (eg fleet management) or the management planning for service failures, very important.

December year 1: reflection

- At this time, with lots of information in the 3 project areas: area of systems, ERP + CRM and mobility tools, we are dedicated to internal reflection. We had before us the decision to make a first selection of products and partners. We had to report what partners would be finalists and which were discarded. Obviously this is a difficult moment, it is very difficult to rule out a company and give reasons, as long as you discuss them, is their right, I would do the same. Some of these companies do not take it well and asked for more meetings to demonstrate that they were valid to direct the project. The decision was made, and we should move forward and burning stages of decision.

- We decided to pick 5 finalists partners: 3 of them offered MS Dynamics NAV , 1 offered SAP Business-One and other SAGE Logic Class . All they offered mobility tools (those chosen were 3: Antay Mobile Solutions , JSV and ExpandIT , discarding the Microsoft tools, which have subsequently been out of print) and provided estimates for the area of systems within the premises checked.

- Christmas came and with it some detail of the partners, is the good of being responsible.

January year 2: meetings with partners finalists

- At New Year we proceeded to resume meetings with partners to begin proportional finalists more information about our functional requirements. We mentioned a document where all the functional requirements of the company, without going into much detail, since many of them are considered confidential, and we would only be disclosed to the 2 finalists partners in order to realize and present a final budget.

- In this second phase of meetings we wanted to analyze in detail the partner, not just how it works and what products and / or services offered, but how are the people behind the partner, how is the company itself and what added value we can give.

- During this month we get to define what was already outline the area of systems, define most of the functional requirements in the area of ERP and CRM , and also define how the tools needed to work mobility, all this work was thanks to the experience of all partners finalists.

February Year 2: new insight into the company

- We know that companies are living, ours is no exception, in our case are professionalizing all areas, therefore I was also hired me. The company decided to add a new actor to the project and the company. He hired someone to do the functions of "controller." This person is an expert in implementation and management procedures, and has many years of experience in implementation of technology projects. This caused a 360 º to the project ...

- This person found that the functional requirements analysis I had done the last few months was not sufficient to finalize budgets with partners. Reason is, is a previous analysis or superficial. With experience and knowledge during this month we carry out a thorough requirements analysis, it all consultancies engaged during the analysis phase before tackling any project. By this stage we wanted the budgets were closed and no significant deviations, which is one of the greatest risks in a technology project.

- This person also wanted to take another approach to the project, based on his personal experiences, suggested the entrance of a new company to add to the list of finalists. The company develops custom software.

March year 2: vs. custom software. configurable standard software

- The title says it all. During the last days of February and March the following weeks, we started an internal discussion great. Should we do a project as a project or develop a standard configurable? This caused great new hypothesis by infighting, endless meetings, the odd scuffle and only managed to enrich the knowledge of those present and the company, the final decision should be agreed (see article vs custom software. standard software ).

- What was my position? As head of information technology company, based in meetings with partners in the last 8 months, the functional requirements of the company and my technological knowledge, and I believe it is wrong to make a custom software project, if there is already on the market a standard product that meets the needs configurable. Those that do not cover needs to be developed. What is the cost of these developments? Is it higher than the cost of developing a 100% as? Many questions and some difficult to answer. But this decision is not weighed only technological issues, there were other key areas to assess: relationship with partner, initial project costs and annual costs for the expansion project nationwide company, ...

- On the technological front there was no doubt, as a solution was not ideal. Mainly because it caused a high dependence on partners, many hidden costs caused by the fact that as (any switching costs). I allow myself the luxury of a list of things to consider to decide on a product as a standard or configurable:

Relationship to partner:
- As SW: narrower as it is a very important customer and development limited and defined by the company
- Standard and configurable SW: is part of a standard tried and tested. The relationship is more fluid. Narrowing the development treat to do (verticalizaciones).
Difficulty of finding another partner to manage the project in case of problems (bad relationship, partner's disappearance, ...)
- SW as: Difficulty. Software as difficult to manage the size and design not normally follow a standard.
- Standard and configurable SW: low difficulty. There are dozens of partners who manage the software.
Hidden costs caused by any proposed changes
- SW as: not known a priori. Will appear in the light of new business needs.
- Standard and configurable SW: many improvements will not cost as they are integrated into the standard software but currently not used.
Integration with other tools (Example: collaboration tools, web portals, office, IP telephony, mobility tools, ...)
- SW as: nil. There is no native integration with other tools. This implies a high cost in wanting to interact with other tools. Sooner or later this will happen.
- Standard and configurable SW: usually has integration with most existing familiar tools. Such as MS Dynamics NAV ERP has native integration with: Offic with Sharepoint, web portals, mobility tools, ...
Management and operation of information:
- SW as Limited, previously annotated in the analysis. Normally the software can only be exploited as information reports, which involve additional costs to the project because they have to develop.
- Standard and configurable SW: many of these standards have built powerful management tools to exploit the information. Easy to use and users can generate reports in many ways, and especially get dynamic reports (with traceability).
Costs of growth / expansion of users:
- SW as: no licensing costs, as the software is owned by and usually creates it. The growth limitations may exist in the systems area.
- Standard and configurable SW: There inaludibles licensing costs. While it is true that there are web applications to limit these costs (gateways to the worker), although these solutions avoid licensing costs involve access to very basic functionality of the software. If you want access to all development involves a high cost.
Knowledge of the business sector by the partner: it is an important decision based on knowledge of the industry partner of our company. Your tips are always welcome. We can provide an important know-how to the project.
Project duration:
- SW as: the duration is usually much larger than a standard software. And many of these projects are never finished because as long as you want something more.
- Standard and configurable SW: initially limited duration. There is always cause undesired deviations from the requirements analysis stage of analysis made by the partner and the company just starting the project.
Other considerations: able to make investments in software partner, partner's ability to suggest improvements, technological capacity of the partner, engagement partner loyalty, human resources partner, partner established in the market, level of partner involvement, importance of company for the partner, ...

April Year 2: Final decision and negotiations

- After many meetings, many hours of disputes, exchange of opinions ... They had to take a step forward. The project was in an absolute phase locking, mainly because in the company had created two groups: some defended the software as the best solution and other standard software configurable. In the end I took a responsible step forward, I accepted that most people defended the custom software solution (mainly by a purely economic cost of expanding user licenses) and presents an initial project proposal.

Diagrama proyecto tecnologico

- It was decided to propose a technology project with diverse partners. This decision is to fulfill the entire opinion of the company, we are a political decision correctly. On the technology is intended to manage the area who is a company specialized systems and not the same partner that develops custom software. On the mobility, it is thought desirable to choose a partner with a configurable tool that standard covers 95% of the needs of the company and allows us to have a company with over 10 years in the field of mobility.

- This decision has some interesting points that I wish to comment below:

Diversified Partners: is to what each one does what it does. We'll see if it happens.
Diversification of risk: the target is as if the partner fails, limit the maximum error in the project. Hopefully this will not happen.
Difficulty of understanding: it is clear to see, that having 3 different communication partners and management will be complicated. There is a risk that some are culpabilicen others when problems arise. From our department will try to be the managers of these relationships.
Technological difficulties in integration: we must define our needs perfectly and that the partners do the same, to avoid problems of integration between the 3 levels of the project. A case would have problems with integration of mobility tools with standard ERP as. We avoid these problems with a good initial analysis.

- The last two weeks of April to negotiate with the dedicated each of the three partners are chosen. Try to fit all budgets, negotiating with different techniques, although not necessary, in our times partners need urgent projects and adapt to whatever it takes. The hardest part was adjusting the area of systems, as many had already discounted prices from the manufacturer that are difficult to cut even more. We review the issue of software, primarily Microsoft licenses ( see article in this blog ), to not let any and analyze in detail if we could save some.

May year 2: never say it's over

We had decided that the partner responsible for the change in mobility had to be a specialized partner, for the many benefits that entails, mainly because it is a tool previously tested and validated technology. Well, because the ERP + CRM must be a project as in the absence of the connectors between ERP + CRM and mobility tools, this entails an extra cost. This additional cost and the cost of licensing the standard mobility caused a schism in management. Our expansion project could not afford in these times, to spend a few euros on licenses. For this main reason, it was decided that the management tools would be developed as ALSO the same partner that develops ERP + CRM.

If you look, the decisions are very similar to those taken back when the ERP was ruled by one as standard. Obviously, I as the project in the technological, disagreed before, and I am now. I think it is wrong to develop a mobility tool from scratch, because this industry is very specialized, and there are problems in communications that will be solved one way or another. We will see over time if the chosen partner is or is not up to the company.

During this month we were discussing how to address the mobility decision, but we erre que erre in the project area systems (infrastructure). It was taken for this chapter closed months ago, but nothing. The company was cutting costs everywhere, and it was virtually impossible to defend my proposed infrastructure (valued at approximately € 49,000) compared to other proposed minimum (estimated at about 34,000 €). To give you an idea I present the two proposals in broad terms:

- The appropriate proposal, valued at € 49,000, consisted mainly of 2 servers HP Proliant ML380 with 18GB RAM each, with a MSA2310i storage array (iSCSI) with 9 disks 300GB and 1TB 2 of 2 Procurve switch 2610. Also bought a new firewall to improve security and manage VPNs, and a new backup device, HP StorageWorks LTO4 Autoloader. The main advantage of this structure was to mount a farm of 2 with 7 physical servers using VMware virtual servers. I firmly believe this structure allows the company an adequate business continuity needs, allows booting from our IT department new projects such as VDI, Blackberry server, web clients, ...

- The proposed minimum, valued at € 34,000, consisting mainly of HP Proliant ML350 2 servers with 20GB RAM each, with 6 disks each 146GB at 15K. 2 Procurve switch 2610. Also bought a new firewall to improve security and manage VPNs, and a new backup device, HP StorageWorks LTO4 Autoloader. This scenario eliminates the minimum cabin and virtualization with VMware, is virtualized with HyperV 3 services (licensing cost reduction), and mainly achieved a dramatic reduction in licensing Windows to buy Windows SBS 2008 (we saved € 6,000) since this software ( see article on SBS ) carries licenses: Windows Server 2008, Exchange 2007, SQL Server 2008, WSUS and Sharepoint 3.0. This scenario has many disadvantages as a minimum: have a package of licensing Windows drive (limitations of SBS), low availability and business continuity if a service falls.

These two proposals were presented and discussed for 2 weeks, even asked the partners in the area of systems and defend discuss these proposals. In the end they voted pretty democracy (¬ ¬), and it was decided by 4 votes to 2, which chose the minimum option, valued at 34,000 €. My second failure in the company. I say failure because in recent months I have been unable to defend my project, I have been unable to explain concisely and convince people with no knowledge (management), almost always comes down to cost. This word has me fried. It is an evil in many companies, the IT department is seen as an expense and not as an INVESTMENT. My project idea was based on the appropriate proposal (49,000 €), because I wanted to align the most of the IT department with the company. I wanted this department could provide new solutions to the company and also intervene in all departments and business flows possible, I wanted to after all, show that IF there is a ROI (return on investment) in these projects.

During this month, also began to develop project schedules, there were also two meetings to move forward in the CRM project, the first prototype we intend to release to boost sales department. These calendars are marked as specific dates or milestones to achieve by our partners and us. The objectives are:

Start the new area of systems (infrastructure) in July
Start the CRM in August
Implement mobility tools in September-October
Start the new ERP in January

June and July year 2: formalizing contracts and meetings

The next two months were defined as months of intensive meetings to close on one side contracts and to start and to make requirements for CRM. We will explain these two concepts:

- Formalization of contracts: this is a very important aspect of a technology project. It must be clear that the partner is a partner, and how important is the company. They have to define 2 contracts: contract for the project and contract data protection. The first contract is based primarily on detailing everything possible, all tasks that have to do the partner for the project will begin, the more detail the better. It also adds a few important clauses. The fundamental and creates more controversy in the partner are the penalties for breach of contract, in this aspect should be stressed and reach a point of agreement.

- Requirements CRM started making enough meetings to gather information about how it had to be the CRM and how it should operate. In previous months had collected a wealth of information on various CRM products, this helped to design the more standard CRM. The initial goal was to have a CRM prototype for the month of August, and during the holiday period to do performance testing and improvement of any commercial enterprise.

August Year 2: grants, holiday and CRM

August is usually a difficult month, many people have vacations and is complicated to program things. This and that the requirements of CRM began to cause some headaches, caused the first delay of the calendar, our goal (to my view unrealistic) to get a prototype CRM in August went to ruin. We should wait until September to start seeing an occasional display of the future CRM.

Another important issue is subsidies. Once we begin to realize in February budget, from management, I was asked the challenge of seeking grants for the project. After many days searching and searching, we found a grant available to our project. First decide ICO loan information for companies to finance the project cost without interest (you can get more info at this link: ICO Plan ). CIDEM found by a grant, the grant ran out the registration period in late February, this led to us to move very quickly to try to get something. CIDEM Company launched the INNO plan 2010, which for technological innovation projects worth over € 100,000 you can get to subsidize up to 50% cost of professional services and up to 15% of software / hardware. This grant scheme is managed by the autonomous community and there is a limit amount. In our case we start with a budget of 140,000 € of which we requested almost 50,000 € grant. We should now wait until September for confirmation or denial of the grant and the amounts.

Septiembre año 2: prototipo de CRM y subvención aceptada

Durante las primeras 2 semanas de septiembre empezamos a tener reuniones cada 2-3 días y empezamos a analizar ya el primer prototip de CRM. En dicho prototipo vimos ya cómo serían las futuras aplicaciones, su estilo visual, y cómo se usarían, la usabilidad de los usuarios. Cabe destacar que el CRM presentado no partía de cero, como inicialmente pensaba, la empresa de software a medida tenía ya para otro cliente un CRM hecho, cogieron este CRM y lo adaptaron al máximo a nuestras necesidades concretas. Yo pensé: “ya empezamos…”. Se paga por un software específico y se empieza usando uno de otro con adaptaciones, lo normal en software a medida para acortar plazos. Empezaron las primeras discusiones interesantes, sobre cómo tenía que ser el CRM, el responsable comercial de la empresa, el verdadero experto, empezó ya a dibujar cómo quería que fuera el producto, acotando ya su funcionamiento y configuraciones. A finales de mes obtuvimos ya el primer prototipo productivo del CRM, se empezó a montar en él la estructura de flujo de negocio que queríamos e incluso se probó en varios comerciales (pasado 1 mes estos aún no habían dicho nada referente al producto, señal que les interesa mucho a ellos y al responsable).

A finales de mes recibimos una llamada, era del CIDEM autonómico (en cada comunidad autónoma tiene un nombre, en Cataluña se llama Acc10.cat). Nos comunicaban que habían aceptado nuestro proyecto para ser subvencionado, y nos enviaron una documentación donde se nos informaba que se destinarían casi 40.000€ de subvención. Esta subvención no se da por adelantado sino se siguen los siguientes pasos:

1) Inscripción de la solicitud

2) CIDEM acepta o deniega la solicitud

3) A final de año se presentan las facturas del proyecto por el valor especificado y se presentan una serie de documentos explicativos

4) CIDEM acepta y valida estos documentos y entrega la documentación

En nuestro caso, ahora tocaba centrarnos en el desarrollo del ERP y CRM, y dejar este tema aparcado hasta Diciembre.

Octubre año 2: primeros módulos del ERP

Paralelamente al CRM empezamos a diseñar el futuro ERP. Durante los meses de Agosto, Septiembre y Octubre, se hicieron muchas reuniones internas en la empresa, para empezar a darle forma al futuro ERP. De estas reuniones internas se obtuvieron los diseños del futuro ERP para cumplir con los requerimientos específicos de la empresa. Esta informción se transifrió a la empresa de desarrollo de software y empezaron a proporcionarnos los primeros módulos del ERP para hacer nosotros pruebas: módulo de clientes, módulo de proveedores, módulo de contabilidad, módulo de seguridad, y algunos más. Obviamente como en el CRM, estos módulos no eran desarrollos específicos para nosotros, eran módulos de otros proyectos de esa empresa, adaptados a nuestras necesidades. Este punto a mi me empezó a molestar, porqué excusandose en el tiempo, el 1 de Enero del año 3, el ERP debe de estar en funcionamiento con sus módulos básicos para trabajar el día a día, ahorran en costes de desarrollo y nos desarrollan módulos del ERP adaptados. Por una parte mejor, ya que significa que dichos módulos han sido testados anteriormente por otros usuarios y empresas, y seguramente funcionen correctamente (habrá que verlo). Durante este mes se hizo también un paso importante en el proyecto, la primera migración de datos.

Todos sabemos que una migración de datos nos es sencilla. En nuestro caso partimos de un ERP con un gestor de bases de datos, SQL Server. Gracias en parte a mis problemas con este ERP, la migración ha sido bastante sencilla, la estructura de la base de datos no es complicada de entender, aunque esté mal distribuida y mal diseñada (el ERP en cuestión es Nexus). Hemos conseguido volcar las tablas de clientes, proveedor, artículos de forma satisfactorias, y más adelante haremos la migración definitiva.

Noviembre año 2: herramientas de movilidad y aplicaciones satélite

Un hecho es evidente, la fecha de 1 de Enero como fecha clave de inicio del proyecto cada vez está más cerca, y el proyecto lejos. Tenemos una ventaja en este sentido, hay muchos módulos como SAT, que no tiene poqué arrancar el 1 de Enero en su totalidad, ni muchos otros departamentos como reparto. Nuestra intención es arrancar el 1 de Enero (temas contables y fiscales) con el ciclo de facturación funcionando, con proveedores, clientes y artículos migrados, y con los ciclos básicos de funcionamiento de la empresa, principalmente los circuitos del día a día de la empresa. Esta labor no a sencilla, ya que heredamos una estructura y unos circuitos muy dañinos, y que por suerte los podremos eliminar de raíz.

Debido a la limitaciones de nuestro ERP, existen una gran cantidad de aplicaciones satélite (= aquella aplicación aparte del ERP que interactua con su base de datos, principalmente desarrolladas con .NET o Access) que se diseñaron para poder mejorar los circuitos de la empresa. Por ejemplo, generación automática de facturas/albaranes de venta de las PDAs de distribución, o listados de llamadas de clientes, etc. Estas aplicaciones son el día a día de la empresa, y son vistas por los trabajadores como parte del ERP, para mi son vistas como parches o chapuzas innecesarias.

Durante este mes tuvimos varias reuniones para explicar estas aplicaciones satélite en detalle, con ejemplos de listados en papel, y con diseño UML, para así facilitar la integración de estas aplicaciones en el futuro ERP (todas las aplicaciones deben de desaparecer, pero se integran como parte del futuro ERP aquellas que sean útiles). Mi acometido principal era crear un manual por cada aplicación, donde explicar con lenguaje UML el funcionamiento y diseño, para así poder facilitar las tareas a la empresa desarrolladora del software a medida.

Otro tema importante es la movilidad. Para el día de arranque del ERP, la movilidad debe de estar operativa. En nuestro caso la movilidad orientada al departamento de distribución-preventa. Dicho departamente se encarga de realizar los pedidos de los clientes. Por este motivo es importante que estén operativas las nuevas herramientas de movilidad para este departamento. Imaginemos que debemos de introducir 200 facturas diarias a mano con sus correspondientes detalles de línea… un infierno! Por este motivo este circuito debe de estar disponible para el arranque del ERP. En el futuro dotaremos al departamento de distribución de muchas más funcionalidades en movilidad, para que dispongan de mucha información y así puedan tomar decisiones.