GENERAL PLANNING OF PROCUREMENT SOFTWARE

This section describes the general planning and implementation decisions for the procurement software. The general planning includes strategic planning presenting the justification of the procurement software and integration planning describing the co-operation with other software, i.e.

the required interfaces towards the applications of the adjoining functions. The implementation decisions clarify the arrangements and decisions needed to develop the procurement software.

The general planning and implementation decisions at Pöyry Oyj were mostly made before the first software development round. The only exception was the interface for the working hour reporting, which took place in the last (sixth) development round. This additional interface was programmed for an automated procurement status estimation based on the estimated and working hours.

6.3.1. STRATEGIC PLANNING OF PROCUREMENT SOFTWARE

The basic goals for the procurement software were derived from Pöyry Oyj’s business strategies (see Section 2.1.). The Project Management Manual translates the business strategy as the success of the clients’ projects (Subsection 4.3.1). Thus, the procurement software should support smooth project implementation in time and within the budget.

Strategic planning guided the selections of the hardware and 4GL tool. The right hardware and 4GL tool helped develop the procurement software matching the business environment Pöyry Oyj. The software, in turn, gave and maintained the competitive edge of Pöyry Oyj in project management.

6.3.2. INTEGRATION PLANNING OF PROCUREMENT SOFTWARE

Originally, only scheduling was intended to have an import/export interface. Due to timetable pressures, the scheduling interface was not programmed to the first software version. This missing interface was the most important reason for the second software development round.

The interface for working hour reporting was needed for automated procurement status estimation.

The estimation based on estimated and actual working hours. Although the procurement software was decided to have working hour reporting features, it was decided that it would be unrealistic to expect all the projects to use them instead of the original payroll and working hour reporting software.

This interface was realised in the sixth software development round.

6.3.3. GENERAL IMPLEMENTATION DECISIONS

Pöyry Oyj had clarified best practices in project management. The best project management and procurement practices were described in the rewritten project manuals. The natural extension to the institutionalisation of the best practices was to support these best practices also with project management tools. The procurement tools were badly outdated and therefore the development of a new procurement application was initiated.

At first, the application was supposed to manage only the main procurement workflow as a stand-alone system. Later, the software was required to operate as a networked multi-user application.

Also the functionality of the software was extended; cost estimating, scheduling and documentation management were included. Some fairly independent and irregular project tasks were decided not to be included in the software. It was seen that the gains of computerisation did not exceed the programming costs of these irregular tasks.

The designing and programming of the procurement software was preceded with three general implementation decisions: (1) selection of the hardware, (2) selection of the 4GL tool, and (3) organising the programming and testing of the software. These decisions fixed the programming environment and guided the way towards the current procurement application.

Hardware Selection

The hardware selection was intertwined with the selection of the 4GL tool, i.e. the selected software should work on the hardware. The direct hardware requirements were easily listed: the hardware should be scalable from portables to office systems and it should be cheap to acquire and maintain.

The efficiency was thought to be achieved by purchasing decent hardware. The hardware requirements should at least exceed the minimum operational system with a safe margin.

The portable, networked PCs were considered to speed up project start-ups. The idea was that professionals would carry their laptops with pre-installed software to a site office, connect cables, and start working. The transferability of the applications made sense also from the learning point of view.

If the same tools are used both in offices and at sites, the users are familiar with the project tools.

This will make also data transfer from the office to the site a lot easier.

I was not involved in the hardware decision, but the software was decided to base on PC technology.

The PC hardware was cheap, available everywhere and most of the project professionals were able to maintain their own hardware and applications. The networking requirement could be also fulfilled with PC technology. A server was needed to connect two workstations, but the same server machine could well serve 50 workstations. The connected workstations could be very ordinary and cheap, equipped with a suitable network card. The client-server architecture of DataEase made the networking cheap, efficient and scalable.

4GL Tool Selection

I was not involved in the 4GL tool selection, either. The development tool was already selected when I started working for Pöyry Oyj. In retrospect, I think that DataEase was a reasonable choice.

It was among the first 4GL tools which could operate on the PC platform. It had very advanced features both in organising and retrieving data in databases. Furthermore, DataEase was one of the major 4GL tools on PC platform in the late 1980s.

DataEase was designed to use relational data structure, which made it possible to create a complicated and compact software. The relational data structure enabled data integrity; a piece of information was entered to the system only once and it was immediately in every one's use. The relational data structure also enabled the modularity of the software. The modularity was pursued, because it improved the efficiency of the software, helped in system maintenance, and facilitated modifications. Modularity also enabled installing only sub-applications, if the entire software was not needed. Finally, it speeded up the software development and learning of the software.

Furthermore, the relational data structure made data security much easier. It made it possible to use the record locking principle in data security. This was a vast improvement in data processing in local networks. Before 4GL, the most common data security setting was to lock the entire table in order to gain data security. The additional factor influencing the selection was that some employees were already familiar with DataEase. There was some experience of the 4GL tool in the company. According to their opinion, DataEase was very easy to learn, use and operate.

Organising Programming and Testing

Programming was carried out in three environments: development, test and production environment. Each environment had its own purpose and users, as presented in Figure 53.

Programs were created in the development environment, tested in the test environment, and used in the production environment. When a program was accepted in its environment and was seen to function properly, it is transferred to the next environment. If any problems were found there, the program would be transferred back to the development environment. The process was iterative and transfers backwards were very common.

The development environment was in a single PC with a full DataEase installation. When the program was supposed to be ready, it was delivered to the test environment. In the test environment the application was installed as an ordinary user version. Programs passing the testing were delivered to the production environment, normally a large industrial plant project.

Figure 53. Program Flow

6.4. REVIEW

My research regards the development of the procurement software as much wider work than programming useful software. This chapter described the management of information systems and the general planning of the procurement software. The Pöyry project management and procurement instructions had given me a clear picture of procurement in industrial projects. I used the project management instructions as environment descriptions and procurement instructions as functional definitions of the software. These manuals established the background of the general decisions for the procurement software.

A managerial view to information systems was given to present the systems generally. The view was presented from the angles of expanded system development life cycle, change processes and technochange approach. First, the ESDLC model is used to describe the entire life span of the software. Second, implementing and developing software is a change process from the old to the new solution. The change process approach gives the basic ideas of upgrading software concurrently in use and managing different software versions. Together, they describe the behaviour of the solution which has more than one active version. Third, the technochange approach is introduced to explain organisational behaviour before, during and after IT projects.

General planning included strategic planning, integration planning and general implementation decisions. Strategic planning presented general reasons, or justification, for the software. Integration planning deals with the interfaces to other project software. The general implementation decisions clarify the general hardware and software decisions and the general arrangements needed to develop the procurement software. The general implementation decisions included the selection of the hardware and the 4GL tool and the organising software development environment.

Implementation - system analysts - designers - programmers

Development

Testing

- programmers - testers

Maintenance - end-users System Testing

- testers - end-users

Test Environments Production

Errors, malfunctions and deficits