/nginx/o/2018/08/01/11147105t1h7899.jpg)
/nginx/o/2019/05/23/12193350t1hdcd7.jpg)
A former IT department employee of the postal company Omniva claims that the development of the state-owned firm’s information system spent uselessly millions of euros and that the problems, which have been disturbing the public, had been caused by mistakes made earlier. The enterprise answers that the development project launched several years ago had indeed failed but the money had been spent usefully.
The former Omniva employee, the IT expert Jaak (the newspaper does not disclose his real name) was seriously annoyed when seeing frequent news reports about Omniva’s problems with package delivery during the Christmas period and that home delivery of newspapers is troubled by lack of funds despite state subsidies.
He claims to know that the root of the problems is something not mentioned in the public before – a failed IT project.
“The worst thing is that no one wants to take responsibility,” he says.
Omniva could foresee in 2016 that the volume of package delivery will soar every next year. It is clear now that while the state postal company handled seven million packages three years ago, their number had increased to 14 million last year.
It was predictable that the existing IT systems would not be able to handle the coming flood. The logistics was controlled with the help of software named EPLIS (Estonian Post logistics information system). The program was ancient to put it mildly. Analyses showed that EPLIS would last two more years at best. And that forecast was optimistic.
Wise heads deliberated. It was decided to invest in new software. The development project was called Phoenix.
Phoenix was planned as a basic software to which all the necessary services could be linked as separate modules. Plainly speaking, the software was meant to handle all the tasks an IT system could in a postal firm.
Time was short and the IT team was handed an ambitions timetable. Phoenix had to be completed within a year and a half. The budget of the project was initially set at 3.5 million euros.
“Three years would have been a normal deadline for that volume of work,” the ex-employee says. “The haste was tremendous. Overtime was a usual thing. We worked day and night”.
But a serious row broke out between the Omniva management and the It team in spring 2017.
First, the cost of the project has increased by a million euros by that time. Secondly, the IT team wanted to launch a beta version, which required more calibration. The development team wanted to start a testing period over the summer to iron out all bugs.
Ansi Arumeel, board chairman of Omniva, says, however, that the management’s expectations had been different. They expected a complete product rather than a beta version by spring 2017.
On the other hand, the then IT manager Rain Kirjanen told Postimees that the schedule was so tight that there would not have been any other way to launch Phoenix.
According to him, that had been the plan all along. Arumeel is adamant that the beta version had never been mentioned at all.
The debate lead to no compromise and Kirjanen left the firm together with the leading architect.
Arumeel claims that Kirjanen’s team lost the management’s confidence, since it could not keel the schedule, but there had been other reasons as well.
“We had no confidence that the team can complete the developments,” he explains. “This was compounded by ignoring the principles we had agreed upon. For example, an enterprise covertly related to a key person of the team was chosen as subcontractor. Besides there were doubts whether the team is actually working in the interests of the enterprise.”
According to the ex-employees the management monitored the development of Phoenix via a process called steering. For example, Arumeel had to sign the decisions of the IT development team. Thus it was curious that the management found out in spring 2017 that the project did not conform to their expectations.
“This is why I am saying that the management should take at least part of the responsibility;” Jaak says.
The beta version of Phoenix cost 4.5 million euros. “But as far as I know they decided to burn money and rewrite most of the solution,” Jaak claims.
Arumeel does not confirm Kirjanen’s claims. He says that the incidents resulted only in lost time rather than wasted money.
“Even if it is true, then time is literally money. The cost of Omniva’s IT developments at the time we worked there was roughly 100,000 euros per week,” Jaak says.
The revenue of state company Eesti Post in 2017 was 1.1 million euros, meaning that the annual profit could pay for two and a half months of the IT team’s work.
According to the public procurements register, IT services worth 6.5 million euros were purchased for the development of Phoenix. The name Phoenix disappeared from the documents after an IT procurement in 2018 at an estimated cost of further 3.5 million euros. The salaries of the in-house working team, which amounted to roughly 30 percent of cost according to former team members, should be included to it.
Thus the estimated cost of the IT developments amounted to 13 million euros, nearly three times more than the initial estimate.
“All these problems should have been solved for 4.5 million,” Jaak claims. If that is true, the cost of the IT development increased by eight annual profits – a sum sufficient to hire some 600 mail carriers.
“These figures cannot be compared. They are not directly related,” board chairman Arumeel rejects the accusations. He explains the extra expenses with the fact that the needs for investment are reassessed every year ad it is logical that e-trade, being technology-centered, needs new developments all the time.
Omniva moved to tie new logistics center during last Christmas. The software solution of the package sorting line should have been one of the key functions of Phoenix. The logistics center was opened immediately before Christmas, the busiest time of the year. Omniva later admitted that the period after moving was riddled with problems: packages went missing and were constantly late.
“I am certain that the inadequate software screwed up their Christmas,” Jaak says.
The board chairman agrees only partially to admit the connection with the failed IT development.
“To some extent we can see connection between the delays of 2017 and the launching problems of 2018. The time for developing and testing the software was shorter,” Arumeel says. “A longer testing period might have revealed earlier some need for improvement, but we cannot be absolutely certain about it. The flaws emerged during full-scale operation, which we could not have tested even during a longer period”.
As said, the board chairman assures that no sum had been written off and most of the necessary software has been implemented: the workplace solutions for couriers and post offices, the automated package cells software, the sorting line software and the geographic portal.
But the outdated EPLIS has not gone anywhere yet. “We are transitioning gradually. EPLIS still runs, for instance, the business client solutions,” Arumeel says. “But the term “failed project” is definitely incorrect. You cannot say that. Most of the components are in use.