ERP delays give CFOs a headache

But what's causing them and how can businesses keep these giant projects on track?


By Tim Ferguson

Published: 25 September 2009 10:01 BST


Cost over-runs on the largest ERP implementation projects can reach tens of thousands of pounds per month - so what are the classic stumbling blocks that delay the roll out of these gigantic projects.

The late completion of ERP projects can create problems in terms of additional cost, delayed savings and potential loss of revenue, meaning the CFO has a real interest in reducing these delays. According to research commissioned by ecommerce technology maker GXS, 84 per cent of businesses it surveyed had experienced ERP roll-out delays due to integration issues with suppliers and partners.

The research also found that when the biggest ERP deployments are delayed this can waste as much as $45,000 per day - more than $1m per month.

Tony Lock, programme director at Freeform Dynamics told silicon.com: "There are certainly delays in ERP projects but that, I think, is not specific to ERP projects, it's rather a symptom of IT projects in general. There are very few major projects that go off perfectly on time with few challenges along the route."

One big issue is that ERP implementations significantly change business processes - meaning people have new responsibilities and are working in new areas - something Lock said also has political connotations that can be tricky to resolve.

Christian Hestermann, research director for ERP at Gartner, said that many ERP projects suffer from delays as they involve a large number of different people within the business and "a lot of distributed responsibility".

He added: "Normally it does not only have to do with technology. It's more things like poor planning, unclear responsibilities, people pointing at each other. These implementations look like a technology project but it's much a business and people kind of thing."

To minimise the potential for problems, Hestermann said these projects need management buy-in and good planning. They also need to have clearly defined objectives and processes in order to reach the right conclusion.

Freeform Dynamics' Lock added there aren't actually that many people with the necessary experience around big ERP projects, so it's hard to find the right people and even if you do, their services come at a cost.

"Changing technology is difficult, changing processes is more difficult, changing people is the hardest task of all," he said.

Another problematic area is the scope of the ERP project. The GXS research found that 34 per cent of data in ERP systems originates from outside the enterprise - for example from customers and suppliers - adding further to the complexity.

Lock said: "ERP by its very nature tries to embrace quite a wide swathe of the infrastructure so the actual technical integration aspects of it can be quite challenging in and of themselves."

Angela Eager, senior analyst at the Ovum Butler Group, added: "The complexity of the system in terms of scale (functionality, users, instances, physical and virtual locations), and integration to other systems are also significant factors."

Eager said the scope of this kind of project isn't often "set in stone" so is subject to change during implementation. The need to be flexible therefore means completing projects in a set timeframe is often difficult.

Despite these concerns, Lock feels the issues affecting ERP rollouts are increasingly becoming well understood.

He said: "I don't think that the delays are getting worse. I think that we are getting more experience with big ERP projects and we are beginning to learn not to reinvent the wheel each time but to take the best practice that's already been established and exploit that."

Ovum Butler Group's Eager added there is a trend away from "big bang" implementations which "virtually guarantee delays" to more incremental approaches which make ERP implementations more manageable and likely to be delivered on time. She said many businesses she works with have found this approach more successful.



Giannis Giataganas
IT related

οι εξαρτήσεις πανε περιπατο όταν...

Aκούμε συνεχώς για οργανωσιακές εξαρτήσεις: πως ορίζονται, που υπάρχουν ποια τα χαρακτηριστικά τους μπλα μπλα μπλα... ολα αυτά είναι θεμιτά αλλά τι γίνεται στη πραγματικότητα και πως μπορούμε να ανταπεξέλθουμε σε ηδη υπάρχουσες εξαρτήσεις. ακολουθώντας το μοντέλο malone & Crowston(1994) και θεωρώντας ως εξαρτήσεις προς διερεύνηση μόνο αυτές μεταξύ tasks-Resources μπορούμε να αναφερθούμε σε κάποιους μηχανισμούς συντονισμού το καθήκον αυτών είναι να συντονίζουν τις εξαρτήσεις που έχουμε εντοπίσει και χρειάζονται εξομάλυνση. ακολουθούμε όμως μια συγκεκριμένη μεθοδολογία για να εντοπίσουμε και να εξομαλύνουμε αυτές τις σχέσεις ?
Προφανώς έχουν ορισθεί κάποια βήματα που θέλουμε να ακολουθήσουμε.
παρόλα αυτά σκοπος μου είναι να δούμε συγκεκριμένα παραδείγματα στις συνήθισμένες καταστάσεις.

Προβλημα ανάθεσης πόρων σε μια δραστηριότητα-->resource allocation mechanisms

εντοπισμός αναγκών--> εξειδίκευση στην αγορά/ εξειδίκευση στον οργανισμό/εξειδίκευση στο δίκτυο

εντοπισμός πόρων--> στην αγορά δημοσιεύουμε ενα RFP και αναμένουμε
στην ιεραρχία χρησιμοποιούμε ενα γνωστό σετ απο πόρους
στο δίκτυο χρησιμοποιούμε ενα σετ πόρων που υπάρχουν σε αυτό

επιλογή πόρων: --> στην αγορα αξιολογούμε τις προσφορές
στην ιεραρχία εξετάζουμε την ειδίκευση και το φόρτο εργασίας
και στο δίκτυο εξετάζεται η εξειδίκευση

ανάθεση πόρων:--> στην αγορά με συμβόλαιο
στην ιεραρχία με τις εργασιακές σχέσεις
στο δίκτυο με την συμμετοχή σε αυτό



πρόβλημα διαμοίρασης πόρου: mutual exclusion

Μη διαμοιράσιμοι επαναχρησιμοποιήσιμοι πόροι

Ο μηχανισμός που μπορούμε να έχουμε εδώ έχει να κάνει με ειδοποιήσεις τύπου flag που ενημερώνουν για τη διαθεσιμότητα ή όχι κάποιου πόρου. πολλές φορές αυτός ο μηχανισμός δουλεύει από μόνος του όπως για παράδειγμα η απασχόληση ενός υπολογιστή συνήθως εμφανίζεται από τον άνθρωπο που είναι μπροστά του και δουλεύει(βέβαια αυτό δεν είναι απόλυτο αφου μπορεί ένας υπολογιστής να απασχολείται από απόσταση). Άρα λοιπόν θα μπορούσαμε να εκφράσουμε ενδιαφέρον για τη χρήση του πόρου και να περιμένουμε μέχρι να ελευθερωθεί. Σε άλλες περιπτώσεις όπως είναι ο προγραμματισμός συναντήσεων πολλών τμημάτων (ή ομάδων έργων μιας εταιρείας), μπορούμε να αντιμετωπίσουμε αυτή τη εξάρτηση με την δημιουργία μιας λίστας όπου και φαίνονται οι διαθέσιμες μέρες και ώρες που υπάρχουν στις αίθουσες.

Διαμοιράσιμοι επαναχρησιμοποιήσιμοι πόροι

Μηχανισμοί παράλληλης χρήσης πόρου έχουμε simultaneity constraints σε αυτού του είδους τις εξαρτήσεις. Ένα παράδειγμα αυτού είναι πως όλοι οι συμμετέχοντες μιας συνάντησης θα πρέπει να παρακολουθήσουν τη συνάντηση ταυτόχρονα. Άρα θα πρέπει να μοντελοποιήσουμε τη συνάντηση σα πολλές ξεχωριστές δραστηριότητες συναντήσεων και να τους αποδώσουμε ένα περιορισμό ταυτόχρονης υλοποίησης. Παρόλα αυτά φαίνεται πιο απλό να κάνουμε μια μοντελοποίηση μιας δραστηριότητας τύπου meeting που απαιτεί πολλούς πόρους ταυτόχρονα.
Σκεφτείτε λοιπον πως με αυτή τη λογική θα μπορούσαμε να χρησιμοποιήσουμε ίδιους μηχανισμούς και για την ανύψωση ενός πιάνου από 2 εργάτες. Περιέχει τον περιορισμό της ταυτόχρονης ανύψωσης αλλά είναι όμως αυτό σωστή αντιμετώπιση?? θα μπορούσε κάποιος να ισχυριστεί πως αυτή η αντιμετώπιση μας βάζει να σκεφτούμε την εννοιολογική δημιουργία μιας επιπλέον ενοποιημένης δραστηριότητας. Η απόφαση εξαρτάται από την περίπτωση στην οποία κάνουμε τη παραπάνω προσέγγιση.

Τρόποι Επιβεβαίωση shared-resource εξαρτήσεων

Ένα αρκετά δύσκολο πρόβλημα είναι να μπορέσουμε να επιβεβαιώσουμε την χρήση της ίδιας έκδοσης ενός πόρου, όπως είναι οι εκδόσεις λογισμικού και κάποιων εγγράφων. Πώς όμως λύνουμε αυτό το πρόβλημα για να επιβεβαιώσουμε πως δυο δραστηριότητες έχουν χρησιμοποιήσει την ίδια έκδοση? Έχουν δηλαδη μια shared-resource dependency!! Μια δραστική λύση είναι να καταστρέψουμε όλες τις παλιές εκδόσεις ή να τις τοποθετήσουμε σε σημεία που να μην είναι προσβάσιμα για χρήση. Μπορούμε να ακολουθούμε de facto πολιτικές κωδικοποίησης των εκδόσεων που θα μας ενημερώνουν για τη κατάσταση. Επίσης μπορούμε να ανεχτούμε να γίνει χρήση διαφορετικών εκδόσεων και να μπορέσουμε μετά να βρούμε μια ανεκτική λύση.

Θα αφήσω τους επόμενους μηχανισμούς για τις υπόλοιπες δημοσιεύσεις μου
Θέλω να πιστεύω πως έδωσα αρκετό υλικό για προβληματισμό και τριβή με το θέμα



Giannis Giataganas
IT related

Aναζητώντας τέλειους Project Managers

Δε θα κουράσω πολύ αυτή τη φορά, απλά θα αναφέρω τι πρέπει να έχει και να κατέχει ένας project manager. Αν και είναι φυσικό να αναζητούμε κάθε φορά συγκεκριμένα χαρακτηριστικά σε ένα διαχειριστή έργου(ανάλογα με τη φύση της εργασίας και τη φιλοσοφία της εταιρείας), πολλές φορές αυτά που ψάχνουν οι κηνυγοί των αυριανών project manager είναι λιγο πολύ τα παρακάτω:
-Ηγεσία
-Ικανότητα διαχείρησης(εκπλήρωσης διαδικασιών). H διαχείρηση δεν έχει μια κατέυθυνση(managing in four directions, Boddy & Buchanan 1992)
-Καλές σχέσεις με τους πελάτες
-Ικανότητα επίλυσης τεχνικών ζητημάτων
-Διαχείρηση συγκρούσεων
-Διαχείρηση Ομάδας
-Διαχείρηση Ρίσκου και αλλαγών


κάποιοι μπορεί να αναρωτηθούν αν η γνώση αρκεί για να μπορέσουμε να ανταπεξέλθουμε σε όλα τα παραπάνω. η απάντηση είναι πως δεν αρκεί αλλά χρειάζεται ταλέντο και προσωπικότητα για να μπορεί κάποιος να υποστηρίξει κάποιες από τις παραπάνω απαιτήσεις/ικανότητες/δεξιότητες' πείτε το όπως θέλετε. έστω τώρα αν υποθέσουμε πως εκεί έξω υπάρχουν άτομα που είναι γεννημένα για αυτή την απαιτητική θέση, το ερώτημα που τίθεται είναι πως θα μπορέσουν να καλλιεργήσουν αυτό το ταλέντο. Η απάντηση δεν είναι άλλη απο την απόκτηση εμπειρίας και τη τριβή. Η άποψη μου είναι: όσο νωρίτερα τόσο καλύτερα.
Πριν κλείσω θα ήθελα να αναφέρω πως η απαιτητική αυτή θέση έχει και πολλές ευθύνες προς όλες τις κατευθύνσεις:
-προς τον ίδιο τον οργανισμό
-προς το πελάτη
-προς τα μέλη της ομάδας του
-πρός τους ανωτερούς του που δε θέλουμε σε καμμία περίπτωση να τους εκπλήξουμε αρνητικά

Θα επενδύσω λίγο απο το χώρο μου για να αναφέρω τα δημοφιλή γνωρίσματα του καλού διαχειριστή έργου κατά τους Meredith & Mantel(2000)
-καλό τεχνικό background
-ώριμο άτομο
-διαθέσιμο πάνω απο όλα
-κάποιος που τα πάει καλά με τη διοίκηση
-κάποιος που μπορεί να κρατά την ομάδα χαρούμενη
-κάποιος που έχει εργαστεί σε πολλά διαφορετικά τμήματα
-κάποιος που μπορεί να περπατήσει πάνω στο νερό...

αυτό είναι που θέλουν οι εταιρείες στο τιμόνι ενός έργου! έναν άνθρωπο που μπορεί να καθοδηγήσει και να ηγηθεί της αλλαγής. Ενα μικρό επαναστάτη απέναντι στη ρουτίνα..

εύκολο; καθόλου.. Εφικτό; ναι!!


Giannis Giataganas
IT related