Main page Telework Solutions for Promotion of
EU Cooperation in Business and Research
with the Commonwealth of Independent States
Project No IST-1999-29038
Business telework systems
  What's new
  Summary
  Objectives
  Consortium
  Partners
  Events
  Telework community
  
  Telework tools
  Training materials
  Countries' information
  Local web-sites
  Documents
  References
  Contact information
 EDNES

Examples of EU-CIS telework in business

Telework is mostly operational in the areas, where the subject of the work is either easily movable, or non-material. Information is one of such subjects; it can be easily moved from one place to another, or it can equally easily be transmitted over the lines of communication. Thus it is no surprise that telework is especially popular in the industries dealing with the information. In particular, the programming is one of the professions which are well positioned for the successful telework. A couple of similar to each other examples in teleworking in the IT area are companies Nicotech and Cinimex (Moscow, Russia) and their West-European counterparts.

Both companies were established with the programming as their core business. Both companies worked for West-European clients, both used telework as their main method of the work. So these are two examples of fully operational teleworking between EU countries and CIS countries. It can be interesting to consider and compare the experience of these two companies. Their examples can be the guidelines for the development of the other successful telework projects between EU countries and CIS countries.

    Concerning telework, we can outline three different periods:
  • Elements of telework. Traditional means of telecommunications
  • Low-speed Internet communications. Offline teleworking
  • Online teleworking via high-speed Internet connection.

First period. Elements of telework. Traditional means of telecommunications

Originally software projects for western clients were made in Russia, and company communicated with western counterparts by the traditional communication lines. The projects had to be well documented, very often in excess of the normal documentation level. This was especially valid for the initial documentation, which had to describe the project in all the details for the fear of the misunderstanding. The initial documentation and the designs made in Moscow traveled by conventional means, namely by DHL post or by the fax. The source code of the programs also traveled (in both directions) in hard copies, on the diskettes and on the tapes. For everyday communications the parties used the long-distance calls.

Each side had their own work procedures, and only the end-date was adjusted to the other side. After the end-date, i.e. after the moment when the programs were sent to the western counterpart, the customer has its own schedule for the testing and acceptation. And it could very well be that if the customer had any problems or questions in the testing phase, there already was nobody in Nicotech who previously developed this part of the program, and who would be able to resolve the problem. The parties had independent criteria for selecting the personnel, and independent programs for personnel development. Each party used its own calendar of holidays. Work in Moscow started at 8.30-9.00 hours (6.30-7.00 CET), so the parties had at maximum six hours for operational communications. We see that in this period the telework was virtually non-existent. It was a plain offshore software development with only slight elements of the teleworking.This period lasted until the moment when low-speed Internet became available in Moscow.

Second period. Low-speed Internet communications. Offline teleworking

In the second period Internet gradually replaced the conventional means of communication. At that moment Internet connection gradually rose from the speed 1200bod, to 2400-4800-14400-28800-33600-57600bod. At first the initial documentation, then short sources, and then all the sources were sent in both directions via Internet. And of course, everyday operational documentation, legal and financial documentation also traveled by Internet. It became possible to make the smaller projects and the projects not so thoroughly described. It also became possible to sign so-called frame contracts, which defined hour rates, responsibilities of the parties, other generic conditions, but left aside the descriptions of the particular work. Afterwards, work descriptions could arrive on a day-to-day basis, producing a permanent stream of work. This made things easier to all parties.

This type of work changed the demands for employees and for their development. Originally the employees had to have the definite software development skills, defined in terms of software platforms, programming languages and packages (i.e. AS/400, Wintel, OS/2, Cobol/400, Delphi, C++, etc). The development of their skills was also measured in terms of new platforms, new languages and new packages. In this period it became important, what knowledge and experience they have in particular programs of the particular customer. When they gained experience about the particular products of the customer, their value to the company increased.

The most obvious way to gain customer-specific skills was to send a programmer to a customer site for some period of time, and this way was widely used. A visit to the customer site was mostly used for joint testing, elimination of unclearly defined places, starting a new piece of work. During such trips, which lasted from several days and up to three months, personnel from both sides often established the strong personal contacts. What was more important for business, such trips led to closer business and cultural convergence between the parties. The work procedures in Moscow office resembled the work procedures of one or another customer.

Totally, because technical environment of the western client was different from the one in Moscow, this period brought a knowledge of new platforms, new languages and new programming tools, where all of them were exactly the same which were used by their western counterparts.

Other issues also became better synchronized. Start of working day was shifted to 10.30-11.00 (8.30-9.00 CET), what allowed full eight-hour period for communications with the western counterparts. At the very beginning, both sides made common decisions about e-mail package, use of Internet e-mail on AS/400 platform, FTP protocol for sending and receiving the files, etc. so all the information sent via Internet were absolutely compatible. Later on, in technical negotiations with potential clients, these agreements could constitute a ground for similar agreements with the new counterparts. This was important, because people working in a closed environment, sometime do not realize that the world is a bigger place, and the environments may change from place to place. The similar synchronization took place in the business area of the projects. The parties used the same Office packages, so the technical and business documentation traveled seamlessly. In many cases, the parties shared the reporting formats, thus the description of errors reported on a western side was easily incorporated into the rework assignments on a Russian side. Adversely, design problems and questions reported from Moscow, easily found a way to designers of the western counterpart. However, hardware, software and skills became more and more expensive, and many projects had to be abandoned for the economical reasons.

When permanent, low-cost and fast Internet connection became possible in Moscow, it became possible to start new types of work.

Current period. Online teleworking via high-speed Internet connection

In mid-1997, first direct online connection with the computer of one of the customers was established. Given the proper access rights, this had an effect of the person sitting before the computer in west-europe, when actually he was sitting in Moscow office. This was the start of new period – direct work via Internet.

A new type of telework had a lot of advantages; at the same time, it generated new problems and new issues, which had to be addressed. We shall just briefly outline the most important of both the advantages and new problems.

Identical work environments on the customer site and in Moscow now were easily achieved. In fact, there was a single work environment at the customer side, accessed from Moscow via Internet. Release maintenance became a much easier task. Previously, the customer had to carefully watch which sources were sent from Moscow side, then had to incorporate them into the total set of source code (production library). All this demanded a huge system of marking and numeration of the changes in the code, which had to be constantly synchronized with Moscow. This task became even more difficult in the case, when changes in the code were at the same time made by the customer itself. In online work, there was just one source code, corrected and updated from the both sides of the communication lines.

The time difference between West Europe and Moscow could be used positively. The capacities of the host computer were more fully utilized, and time-consuming tasks (such as compilation) were performed faster. In necessary cases, parties agreed about contact hours. New issue, which had to be addressed, was the security. Access to production libraries and source codes of the customers brought to the customers an additional risk of damage or unauthorized use of the sources. The problem was resolved by establishing in Moscow of the same security standards as the customer had. The similar issue was the privacy. The projects are often tested on the real data, which can contain the sensible information about the persons, companies, taxes, etc. In no circumstances this information could be accessed from another country. Thus the customers had a new task of preparing a false testing database.

An important technical issue was the access speed. This was dependent of a hardware platform. For AS/400 platform, where information is sent page by page, this proved to be no problem at all. This was different for Wintel and UNIX platforms, where the programmer can scroll the screen up and down. In the most difficult cases, the response time problem was resolved by making a hybrid combination between online and offline work: the programmer downloaded the necessary piece of the source code (for example, using FTP), worked on it, and uploaded the source code back; after that, he could compile and test it on a customer computer in online mode.

The work in Moscow became more transparent to the customers: they could easily see who is working at the moment, and what he is exactly doing. Thus the work procedures in the Russian companies became stricter and closer to the western standards. The Russian programmers also had to devote more time to program testing, than it is usually envisioned in Russia. They spent more time on planning and evaluation of their work, because the traditional ad hoc try-and-error method was not suitable to be seen by the customers. The same could be told about control of the quality of the work and of the team development.

Given all this, new method of work proved to be rather effective. Both companies successfully expanded. New three-tier system of telework was developed. Some projects, which demanded a work of many people, were first analyzed in Moscow, and necessary initial information was downloaded from the customer in Europe and placed on a server in Moscow. In the office there were only the project managers who evaluated the tasks, assigned them to the particular programmers, tested results, accepted and uploaded them to the customer server (or sent back to the programmer for rework). The programmers themselves sat in auxiliary offices (may be even at home) and used Internet connections for work on a server. Only once a week did they came to the main office for briefing and evaluation of the results.

There appeared new types of the projects available only with direct online method of work. First type was the testing projects, where teleworking party tested the programs, developed elsewhere. The second type was the maintenance projects, where the teleworking party underwrites to provide the support and maintenance for the software, developed earlier. Such work consists of the end-user wishes, correction of bugs, improvements etc. The amount of work can hardly be planned in advance, and capacity problem can be resolved by online connection with third party, which provides support.

World Science Association
Copyright © 2001-2005
EDNES Moscow