CG1307-Skype

Industrial Software: Collaborating Halfway Around the World

July 14, 2013
Skype Made it Possible for Three Companies to Work Together Halfway Around the World
Aboout the Author
Dan Hebert is senior technical editor for Control, Control Design and Industrial Networking. Email him at [email protected]. See his Google+ profile.Parsec Automation, a global software company in Anaheim, Calif., recently implemented a project for a local client, but the primary engineering resources were supplied by Parsec's certified partner Cimlogic in the U.K.

The project involved automating shop floor controls processes at Life Technologies, a life sciences and medical diagnostics company with 50,000 products and 30 manufacturing sites. Parsec's TrakSYS Manufacturing Operations Management software was installed across the enterprise.

Skype made it possible for the three companies to work together halfway around the world. "In this case, the time difference had no negative impact at all," says Scott Klages, VP at Parsec. "A daily project scrum Web meeting at 8 a.m. in the morning in California occurred at 4 p. m. in the U.K. The U.K. developers explained what features they had just developed during their workday. Then, while the U.K. team was going home to rest, the U.S. team was busy testing the day's enhancements and could fire off the next round of requests. Then while the U.S. team was sleeping, the U.K. team was busy working on the current enhancements."

"Since it wasn't practical to pull the team together for face-to-face meetings on a frequent basis, we had to take advantage of collaboration tools such as web meetings, sound project management skills, and other tools and techniques," Klages adds.

Mike Hodge, director of Cimlogic, notes, "Being 5000 miles away and never having seen the manufacturing facility itself, this was an interesting endeavor. However, with a 4 p. m. daily scrum meeting using Skype, we would discuss the day's progress and achievements and would agree on the requirements for the next day's work."

Rollouts in large plants typically occur in phases. Parsec used separate development and production servers, so that the next phase of a rollout could be developed and tested without impacting the production server. "In the Life Technologies case, we employed a complete waterfall environment, consisting of TrakSYS development, test, staging and production servers. The deployment and use of development servers was greatly facilitated by the now-common use of virtual machines."

The location of the development servers is not very important these days either, due to high-performance WANs that most manufacturing companies have in place. For Life Technologies, the development and test environments were deployed in a Maryland data center, and the staging and production servers were located in California at the clients' plant.

"Depending on the number of people that are collaborating and the security policies of the company we are working with, we sometimes use a development server that exists in the cloud," notes Klages.

Life Technologies' lead architect for manufacturing systems, Nick Rivette, provides this overview of the collaborative process used on the project. "The flexibility, attentiveness and responsiveness of both the Parsec and Cimlogic team members helped us to adapt to changes over the course of the project. This mitigated risk while giving us the flexibility to provide feedback and learn by actually building the system along the way."

"For instance, the user interface mock-ups that we provided to the design team, when compared to the actual screens developed for the application, were quite telling. Some of the mock-ups were quite similar to what we ended up implementing," observes Rivette.

"QC data collection, however, was vastly different, and what was truly needed only became apparent during the project execution. If we hadn't been communicating regularly, we would have got exactly the QC data collection experience we mocked up, and it would have been more or less useless to us. Instead, what was actually implemented started from a redefinition of what was actually needed, then some discussion of its difficulty and possible trade-offs, and finally an agreement on what could be accomplished to meet the need without vastly increasing the amount of effort and expense to produce it," sums up Rivette.

Collaboration tools have changed significantly during the last five years. "The upshot of all this technology is that the most experienced resources can collaborate to develop very sophisticated applications more rapidly, at lower cost and with a high confidence that the project will be completed on time and within budget. If the supplier is familiar with the customer's type of process, a detailed statement of work and vendor-supplied templates and questionnaires can be used to fully define a project without the implementers ever seeing the physical plant," explains Klages.