The Production System we built for Nissan Mexicana

If I have to choose the most interesting project in which I have ever worked, this is it.

Everything started in 2007, with the inquire of a customer with whom we had been working for many years already. This client was based in Texas and he had received a request for proposal from Nissan Mexicana for a system called Broadcast Codes Administrator. The system was for the plant that Nissan has in Aguascalientes, Mexico.

The purpose of the system was to allow the Specifications Department to administer the Part Codes sent to the production line, each time a car entering in the trim shop.

Their old system only allowed 60 parts per vehicle. We increased that capacity to 2000 codes in 2008 and then to 4000 in 2013.

Aparte, we added the capacity to substitute parts, a process that was very hard to do with the previous system and that caused a lot of delays in the production line.

The discovery process

nissan production

Our customer travelled to Buenos Aires and he stayed for 1 week in the city. We met with him every day of that week analyzing the RFP and the project.

We created diagrams to validate our understanding and we documented everything. We had a few calls with Nissan to clarify very technical concepts and very specific to their business operation.

At the end of this intense work week we had a quite well defined Software Requirements Specification document. We suggested we could build a prototype for my client to present at Nissan the following month, in the opportunity of a business trip.

We created a quick prototype and obtained very valuable feedback from that. With that information we created new documentation requested by Nissan, a more detailed Requirements document and a Software Design document.

During that time we also started the development of some areas of the project that were well defined.

I also travelled to Mexico for one week after that to present all the documentation we had created. We met with all the involved  personnel there almost all day during one week. I presented the project and the proposed design and I received valuable feedback. We also planned how the installation and migration of their previous system was going to be.

After that trip, I get back to Buenos Aires to finish the project. It was a month of hard work but we have a tight deadline.

I travelled again to Mexico, this time to perform the final installation, training and support. It was almost 4 weeks there and this time I travelled with another of my developers.

working in nissan plant

After the successful launch of the system, in March 2008, we continued supporting the plant, and we released a whole new version in 2011 and another in 2013.

In 2011 we installed the same system at another Nissan plant in México, Cuernavaca, and in 2013 we installed it at the second plant in Aguascalientes.

Requirements

The Broadcast Codes Administrator system was required in order to increase the number of parts that the current systems at the plant were able to manage.

At the time we received the requirement, the existent legacy systems at the plant were able to manage only 60 part codes per vehicle.

The plant had the need to increase these value but also have the ability to perform changes in real time to the codes that were configured from the corporate office, in order to replace parts that are equivalent or to make requested changes to the vehicles configuration.

The system also needed to know what parts each vehicle have by default. This information varies every day, according to the corporate office information. So it was needed to automate the input of this information in the system.

The most important part of the system was the communications module which had to receive the realtime information of the vehicles in the different points of the plant, perform the replacement of the codes and then broadcast this information to the other various systems and printers.

It was also important to log all the information that wen through the system, from vehicles information, to parts used in each vehicle, and actions of the users like who made each change, who dismissed an alert or who activated the data files each date.

Solution

bca system

In order to automate the input of the information for the planned production for each day, the vehicles specifications and the parts for each one, we developed various Windows services that detect when the new files for each day production are copied to a special folder, from the corporate office. This information is read from the files and stored in a database with the proper normalization.

The administration of this information is made with a web application called MACS WEB. This application allows users to review the data received for the vehicles, perform all types of queries and make changes to the part codes, if necessary.

Broadcast Codes Administrator

For example, the users can search for a specific set of vehicles that share certain features, by color, position of the driving wheel, transmission type, etc. and apply the changes only to that set of vehicles.

The changes then can be programmed to be applied for a certain number of vehicles in the line, leaving an offset at the beginning and even serialize any number of changes one after the other.The query screen also allows filtering by the detail and export the data found.

This application also allows the users to perform administrative tasks and configuration.

The most important part of the system is the communications module. This is also a Windows service. The communications module is in charge of the reception of the information of each vehicle as it passes through the different achievement points in the plant. This module then communicates with a MACS web service in order to obtain the correct parts for the vehicle. With this information, the MACS constructs a new message, and sends it to the other systems in the plant, according to how it was programmed.

Installation

installationCentraldev also helped actively in the installation and startup of this and other systems in the car plant, in Mexico.

Task performed during the installation included:

  • Installation of the systems developed by us.
  • Configuration of the systems under Windows 2013 Failover Manager.
  • Configuration of the system under Network Load Balancing under WIndows 2013.
  • Technical support during the startup of the system and during the first weeks of use in site.
  • Monitoring of the system and server performance.
  • Training the plant personal.
  • Changes and corrections until the acceptance.

Technologies used

This project makes use of various technologies: C#, ASP.NET MVC, .NET Framework, JavaScript, jQuery, BootStrap, WCF, SQL Server 2012, and more.

servers

The result

Since the MACS resulted so easy and flexible to manage, it soon became a very important tool of the day to day operations of the plant. The system was designed in order to make it easy for other systems to integrate to it and consume the data it manages and at this time, the information that the MACS generates is shared by four other systems at the plant.

From 60 parts that the old system could manage at the beginning, the new system is now able to manage 4000 parts and also allows changes and historical records, among more than 50 new features.

bca result

Argentina’s full potential is still undiscovered

Thousands of tech students from small cities in Argentina spend several years attending to an University far from their home.

When they graduate, many want to return to the quiet life of their home towns only to find there are no tech jobs there.

Some succeed with small entrepreneurship or working remotely for some company in Buenos Aires or offshore.

These professionals have all great skills, good english level and they are willing to contribute to interesting projects with very competitive costs. This talent is under the radar and still needs to be discovered.

Since 2010 I decided myself that I would give priority to these professionals and I made many trips to cities around the country meeting them and discovering these people.

I’ve been in Resistencia, Santa Fe and Jujuy, And I met in Buenos Aires with people from Bahia Blanca, Mar del Plata and La Pampa, among other places, where I met incredible professionals. Some of them continue working with me while others have made their way to better jobs.

I’m proud to know that people who started working for me is now working in important companies in the United Kingdom, Netherlands or USA.

I still work to discover more of these talent every day.

Working with remote teams – The definitive guide

As a digital services provider I have been in both sides of the equation. I’ve hired remote and distributed teams and I have been hired to work remotely for clients of all over the world.

Remote work can definitely work and give you many benefits, but you have to clearly understand how to do it right. It is a process that involves discipline and good communications skills.

So, if you are considering to engage with a remote team or individual, this tips are for you.

 

1. Define your Process

ticket system

You don’t just outsource your project and expect the company or freelancer figures out everything. Either you or the company you hire must have a well defined scope and process to work towards your goal.

If you are hiring a company or an existent team, it is more likely they will already have a process in place. If you hire freelancers or building your remote team from scratch, you will have to spend a lot of time developing and refining the right process.

In any case, experienced professionals will have some experience in popular software development processes. Scrum or some sort of an agile methodology are good choices to start with. It’s a warning sign if the company doesn’t propose you any process or if they simply tell you they will adapt to whatever you want.

A process should define, at least:

  • Meetings: when and how meetings are held. What topics are treated.
  • Communication: how will you communicate and how often.
  • Responsibilities: clear definition of the responsibilities of each team member.
  • Workflow: how work will evolve through different stages from idea to done.
  • Tools: what tools will be used for remote work collaboration, share documentation, work assignments, bug tracking, etc..
  • Billing and Payments: how and how often will you pay to your remote providers.

 

2. Scope

Use case diagram

As in the previous case, you don’t just throw features to the company or freelancer and expect them to do it right.

If you work with an experienced team, they will probably help you define the scope. But some freelancers are just order takers. They will do exactly what you tell them but don’t expect more; they won’t read your mind.

I have learnt over the years of experience that the most important part of the development happens before the first line of code is written. That’s when a feature is defined with as much detail as needed, user interfaces are designed and everything is documented clearly for your programmers. You just need the right professional for each task.

Another sign of concern is with freelancers who just say “yes” to everything. A professional who never questions your decisions, proposes alternatives or better way to do things is probably not being professional. Go for the freelancers who can say “no” when appropriate. However, pay attention if their suggestions are merely to bill more hours.

 

3. Time zone and proximity

time zone overlapping

We use the term “nearshore” to refer to a provider that is close to our location both in distance and time zone.

Always consider to hire a team that can overlap with your time zone a minimum of four hours a day. If there is a bigger difference you’ll lose momentum and any blocking issue or question you have after your team ends their work day will have to wait until the next day to be attended. And when you start your day and see their response they will be less 3 hours or less until they leave again? No good outcome can come from this.

So, if you are based in the West Coast, the East most you should go is GMT -3 (Argentina, Brazil and Uruguay). If you start to work at 8 am, that will be 12 pm in Buenos Aires, where we typically work until 6 pm. That give you 6 hours of overlapping during DST or 5 during the rest of the year (Argentina and Uruguay don’t observe DST).

Proximity and connectivity is also a factor to consider. If you ever have to travel to meet your team, or your team has to travel, is good to have good connectivity and reach the destination with no more than one flight connection and no more than 4 or 5 time zones crossed.

A good parameter to measure is how many regular office hours can you overlap with your offshore team. For example, if you are located in Miami or New York, and your work hours are from 8 AM to 5 PM, you will overlap the full 9 hours with an offshore team located in Buenos Aires during Daylight Saving Time (which is most of the year). That’s because Buenos Aires is only 1 hour ahead, there is no DST in Argentina and the regular office hours there are from 9 AM to 6 PM; so it’s a total match.

On the other hand, if you outsource to East Europe or India, you get almost zero overlapping.

 

4. Communication and Trust

How do you know people are actually working? That is done through trust and communication. You will never have a successful remote relationship if you fail to this one.

Either you are the contractor or the client, you have to be always available, respond quickly and anticipate to the other party needs. Answer your phone or your IM’s even if you are busy or, at least, let the other party know when you are normally available. The communication challenges of a remote relationship must be compensated with an always available policy.

In my company we schedule every day quick meetings over Hangouts  with clients and team members. We follow a typical Scrum stand up meeting format to answer three basic questions: what we are working on, what’s next and if there are any blocking issues. Apart from that, we communicate all the time through Hangouts IM or Skype. I expect clients and team members to be always available during known work hours.

If you don’t communicate at least every day, you lose momentum, the team member lowers the productivity and everyone lose interest and focus in the project.

Another important action you should take towards a better communication and trust building is to meet with your team in person. It makes a big difference to meet your remote workers at least once although I would recommend to do it regularly. Your team (or part of it) can travel for a week or two and work from your office. Use this opportunities to meet the people better but, above all, keep it professional.

Make it clear in advance what expenses you are covering and what not. You want to consider that even if you pay meals and lodging, travelling has other associated expenses.

Don’t try to be best friends with your freelancers. It’s OK if you want to hang out once or twice after work, but you don’t want it to go further than that. Keep it clean, keep it professional.

If you find it difficult for you to travel or have your team members travel to your location, make sure you make video conferences at least monthly to see each other faces.

Speaking about trust, this is straight and simple. If you don’t trust your remote worker, change it. A remote relationship is based mainly in trust. Specially when your developers are billing you by the hour, you have to trust they are working. You can’t have doubts about this one.

On the other hand, if a remote developer tells the client he is working 8 hours a day when he is not, he’s just killing his business; he is shooting his own foot.

 

5. Price should not be the most important factor in the decision

Price is the main reason most companies start thinking of offshore outsourcing, but sometimes the cheapest is not always the better. Within all your candidates for offshore development, don’t just go for the cheapest; try to discover the most talented professionals out there.  You’ll be surprised how many skilled and experienced professionals are there waiting for you.

 

Conclusion

Hiring a remote worker can be painful. What I recommended here is based in 15 years of working with freelancers and remote developers and designers and even working myself as a remote developer for many companies around the globe. I’ve heard these tips many times during that period but they are hard to assimilate unless you experience them.

Meet the customer

Working remotely has its benefits but sometimes is good for certain projects, to have a closer contact with the customers. In fact, meeting our customers is one of the key aspects of our methodology and we believe it is important to meet us in person at least once, specially for long term projects and relationships.

In many occasions we have travelled to work at the customers’ offices and in other opportunities the customer has travelled down here to meet with us.

In 2005 we received the first visit of a customer from the UK. We were working in his startup idea and he decided to rent a place here in Buenos Aires. It was a very productive move because we had the opportunity to work together for three months with the customer and other of his collaborators on the same table.

Preparing a demo for the customer in our office in Buenos Aires.

Preparing a demo for the customer in our office in Buenos Aires.

We have a long record of travels to Mexico as well. We usually provide services to customers in the automotive industries for their plants in Mexico. So we travelled many times to cities like Aguascalientes and Cuernavaca, places where automotive plants are very important. We travelled approximately 15 times to México for meetings, installations and support to our customers in Mexico. So there you have another skill in our set: we support spicy food like the best!

Trabajando en Cuernavaca.

Working in Cuernavaca.

A punto de entrar a trabajar en Aguascalientes.

All set to work in Aguascalientes.

Working from the datacenter in Mexico.

Working from the datacenter in Mexico.

Other destination we have travelled to many times is Texas. Mainly for meetings, planning and support, we have travelled to Dallas to work from the customer offices. The first time we went there was for a GOT (General Operation Testing) of a project we were building for another customer. We spent two weeks working with the users of the system, testing, reviewing the work done and gaining important feedback.

Travel to Dallas

Travel to Dallas

The latest trips we have done have been to Costa Mesa, California. We are working in a new project for a customer who makes printers so we decided to boost up the project with three weeks of intense work from his office. I travelled there with Jose, one of my partners, and it was very positive because not only could we meet the customer but we could also see the printers we were working with closely, perform real life tests and also visit one of the beta users of the system we were building.

Working from the customer's office

Testing the project at customer’s office.

Our work place in Costa Mesa, California.

Returning home after 3 weeks of work in USA.

What’s the difference between cheap and fair price outsourcing?

A fair price outsourcer will probably have a decent office to work from. A cheap one will probably work from his bedroom.

A fair price outsourcer will probably be able to pay someone to clean his office. A cheap one will have spend time to do the housework.

A fair price outsourcer will probably have decent equipment, update it frequently and maintain it. A cheap one will probably have constant problems with his/her equipment.

A fair price outsourcer will probably be able to pay a good internet connection. A cheap one will probably suffer disconnections every day.

A fair price outsource will probably be able to focus in your project without distractions. A cheap one will probably have to find additional side projects to make ends meet.

So 2016 is ending in Centraldev!

Working at OmniPrint

You know, I’m always super busy and have no time to write in the blog, but I wanted to close the year (today is December 31st, by the way) with a summary of all we have done in 2016.

I started the year in Mexico, closing a deal for a new project that started in March and ended very abruptly in May. You will find odd clients from time to time and I’m used to that since I started in this business. I’m experienced enough to know it was not my fault, and I let my partners know that they are not guilty if we happen to run across one of this specimens.

Working at OmniPrint

At the same time, we continued working for OmniPrint, one of our customers in California in two projects. By July we were invited to travel to Los Angeles for reasons of these projects with my partner José. We spent 20 days of August having meetings, planning and working there. We continued working in the improvements discussed in those meetings and we are close to launch the products we are still working on.

We have also worked in projects for our customers in Argentina like the new websites of Consultora Paradigma, CICYP, Fundación Hábitat y Desarrollo and Print a Lot.

Finally, we have also worked in smaller gigs for some old and loyal customers: SoliSYSTEMS (10 years as customer this March!) from Texas, SiteJabber from San Francisco and Agilink from Louisiana.

Next year we expect the final launch of the products we have been working on during 2016 and many new exciting projects.

Happy new year!!