Dummy Title http://example.com en-gb TYPO3 News Fri, 10 Jul 2020 21:49:53 +0200 Fri, 10 Jul 2020 21:49:53 +0200 TYPO3 EXT:news news-7 Sun, 29 Jun 2014 08:10:00 +0200 Webapps AngularJS & TYPO3 blog-details/webapps-angularjs-typo3 In den letzten Jahren haben wir bei netzrezepte mehr und mehr festgestellt wie immer mehr Logik von Server-Seite auf Client-Seite abwandert. Wenn vor 10 Jahren im typischen TYPO3-Projekt die größten Herausforderungen oft in der PHP-Programmierung lagen, so gibt es nun immer häufiger Projekte bei welchen es gilt, die eigentliche Funktionalität im Frontend umzusetzen.

In den letzten Jahren hat uns hierbei AngularJS einen unersetzlichen Dienst erwiesen und AngularJS wird ein immer wichtigeres Tool in unserer täglichen Arbeit. Da heute praktisch jede Website für zahlreiche Endgeräte optimiert wird und zugleich mehr und mehr funktionale Logik im Frontend abläuft verschwimmt aus unserer Erfahrung die Grenze zwischen „einfacher“ Responsive Website und „typischer“ Webapp mehr und mehr.

Ich hoffe, dass ich bald mal Zeit finde etwas mehr dazu zu schreiben…

]]>
news-8 Mon, 05 Jan 2009 07:14:00 +0100 Web und Desktop wachsen zusammen blog-details/web-und-desktop-wachsen-zusammen Auf golem.de erschien gestern der sehr interessante Artikel „Web statt Windows“ in welchem Jens Ihlenfeld sehr anschaulich erläutert, wie die Entwicklung von Javascript das Web in eine Plattform für Anwendungen verwandelt. Längst sind die Zeiten vorbei als Javascript nur für kleine Spielereien verwendet werden konnte und auch browserübergreifende Entwicklung ist heute kein großes Problem mehr. Teilweise ist es für viele heute bereits normal einige Anwendungen im Internet zu verwenden, die vor wenigen Jahren standardmässig noch auf dem Desktop liefen.

Als Beispiel wird in dem Artikel Gmail erwähnt. Der Artikel erläutert ausführlich die Verbesserung der Javascript Engines und was das für Webapplikationen bedeuten könnte. Es wird auf Ajax Franmeworks wie Dojo, YUI oder Ext eingegangen. Es werden die Bedeutung von Adobe Alchemy und dem Google Native Client besprochen. Es geht um HTML 5 und um Ansätze Web und Desktop miteinander zu verschmelzen (AIR, Silverlight, Prism und Titanium). Insgesamt ist der Artikel sehr komprimiert und auf den Punkt gebracht. Auf wenigen Seiten bekommt der Leser Hintergrund Informationen die es verständlich machen, warum Google beispielsweise einen eigenen Browser herausgebracht hat.

]]>
news-9 Mon, 29 Dec 2008 07:16:00 +0100 TYPO3 Preise durch Stundensatzkalkulation blog-details/typo3-preise-durch-stundensatzkalkulation Als Einstieg in die Kalkulation auf Basis von Stundensätzen möchte ich kurz die Kalkulation Aus Dienstleisterperspektive durchführen.

Stundensätze bei Freelancern

Der schlichteste Anbieter von TYPO3-Dienstleistungen ist ein einfacher Freelancer. Auf akademie.de gibt es einen ausgezeichneten Artikel von Robert Chromow zum Thema realistische Stundensätze berechnen. Robert Chromow beginnt seinen Artikel mit der bemerkenswerten Feststellung, dass viele häufig bei Dienstleistungspreisen aus Angestellten Perspektive denken. Robert Chromow gibt das Beispiel, dass das Brutto-Monatsgehalt eines männlichen Angestellten im Jahr 2004 4.133 Euro betrug. Weil davon auf dem Girokonto eines Ledigen jedoch nach Abzug von Lohnsteuer und Sozialversicherungsabgaben weniger als 2.400 Euro landen, ergibt sich bei einer durchschnittlichen 38-Stunden-Woche ein Verdienst von nur rund 14,50 Euro pro Arbeitsstunde. Robert Chromows richtige Schlußfolgerung ist, dass es aus dieser Perspektive kein Wunder ist, wenn man sich da über die Rechnung des Handwerkers ärgert, der 40 Euro pro Stunde veranschlagt; vom “unverschämten” Berater-Honorar über 100 Euro und mehr ganz zu schweigen? Ein toller Artikel von Herr Chromow, den ich nur wärmstens empfehlen kann.

Der Artikel kommt letztlich zu dem Ergebnis, dass auch bei knapper Kalkulation ein Selbstständiger mindestens 64.- Euro Stundensatz berechnen muss, um am Monatsende zumindest ein vergleichbares Gehalt des deutschen Durschnittsverdieners zu erzielen. Eine ähnliche Rechnung findet sich auch beim Ratgeber e-lancer nochmals speziell für den IT-Bereich. Diese Rechnung kommt zu dem Ergebnis, dass ein Selbstsständiger mindestens 85.- Euro die Stunde berechnen muss, um gleichviel zu verdienen wie sein Angestelltes Pendant.

Die gute Nachricht für alle Auftraggeber ist jedoch, dass die Selbstständigen im IT-Bereich durchaus andere Gründe für Ihre Selbsständigkeit zu haben scheinen als rein finanzielle Interessen. Vergleicht man beispielsweise die c’t-Gehaltsumfrage zu Gehältern im IT-Bereich mit den Ergebnissen der c’t-Befragung über die Einkünfte von IT-Selbstständigen, dann wird schnell deutlich, dass die durchschnittliche selbständige IT-Fachkraft insbesondere am unteren Einkommensrand sich durchaus mit weniger zufrieden zu geben scheint als ihr angestelltes Pendant. Jahreseinkommen unterhalb 20.000 Euro sind für über 37% der IT-Selbsständigen demnach wohl akzeptabel während nur weniger als 2% der IT-Angestellten zu einem solch niedrigen Gehalt arbeiten.

Und hiermit nun endlich zu den Zahlen aus dem wirklichen Markt. Fangen wir mal mit den Durchschnitssstundensätzen aller auf der Projektbörse Gulp gelisteten Freiberufler mit TYPO3-Spezialisierung an. Fast ¾ aller TYPO3-Freiberufler verlangen hier zwischen 50.- Euro und 70.- Euro. Auch die 60 bis 70-Stundenwoche ist unter Selbständigen durchaus normal wobei sich der Stundensatz den man eigentlich nehmen sollte ebenfalls nochmals nach unten korrigieren lässt. Die gute Nachricht ist somit für alle Auftraggeber, dass ein sehr großer Anteil der selbständige TYPO3-Dienstleister wohl mindestens 64 Euro, eher jedoch 85.- Euro je Stunde nehmen sollte, dies aber häufig nicht macht.

Aber selbst damit ist noch nicht der günstigste Bereich abgedeckt. Einen Einblick in die Preisgestaltung außerhalb des reinen Profibereiches findet man in den TYPO3-Foren in denen professionelle Freelancer mit Neueinsteigern diskutieren und Anbieter mit unterschiedlichem Erfahrungshorizont sich gegenseitig bei der Preisfindung behilflich sind (z.B.: im Mittwald-Forum hier oder hier). In diesen Foren findet man immer wieder einen Stundensatz von ca. 50 Euro, aber hin- und wieder gibt es auch mal Neueinsteiger, die 15.- oder 20.- Euro für realistisch halten. Letzteres sind jedoch aus meiner Sicht keine professionellen Angebote von Personen die davon Leben wollen/müssen, sondern eher Angebote von Studenten oder Schülern, die auch etwas TYPO3 können und sich gerne ein bisschen Taschengeld dazu verdienen wollen.

Stundensätze von Agenturen

Für den professionellen Agenturbereich helfen uns diese Quellen jedoch nicht weiter. Es gibt verschiedene regelmäßig  aktualisierte Honorarlisten aus der IT, Werbe- oder Designbranche, welche alle Webdesign einschließen und die durchschnittlichen Stundensätze der Branche widerspiegeln. Zu diesen Honorarlisten zählen der Rotstift, der ibusiness Honorarleitfaden, dann gibt es noch den Vergütungstarifvertrag Design der Allianz Deutscher Designer (AGD) und Verein Selbstständige Design-Studios (SDSt).

Diese Honorarlisten bestätigen für Webentwicklung und -design die Stundensätze der Freiberufler. Agenturstundensätze liegen in der Regel etwas darüber. Für die Arbeiten eines typischen TYPO3-Projektes könnte man hier wohl eher mit Stundensätzen zwischen 70.- Euro und 140.- Euro kalkulieren. Andererseits sind auch viele kleine sogenannte TYPO3-Agenturen nichts anderes als ein Freelancer mit einer Website bzw. zwei bis drei Freelancer, die sich zu einer Bürogemeinschaft zusammengeschlossen haben und liegen entsprechend mit Ihren Stundensätzen wieder eher bei 50.- bis 70.- Euro. Ebenso ist es durchaus üblich dass Senior Berater und Projektleiter einer renommierten Agentur gut mit Stundensätzen oberhalb von 200 € zu Buche schlagen.

Eine weite Spanne der Stundensätze

Es ist also eine sehr weite Spanne mit welcher wir es hier zu tun haben. Nehmen wir als Beispiel drei verschiedene Anbieter, die alle davon ausgehen, dass eine schlichte TYPO3-Website innerhalb einer Woche umgesetzt werden kann, so kommen wir mit Hilfe der hier gesammelten Daten zu folgenden möglichen Kalkulationen:

  • Es gibt im semiprofessionellen Bereich Schüler und Studenten welche einfache TYPO3 Aufgaben für 15.- Euro die Stunde umsetzen. So manch pfiffiger Schüler ist auch durchaus in der Lage eine einfache TYPO3-Website innerhalb einer Woche zum laufen zu bekommen. Bei 40 Stunden zu 15.- Euro erhalten wir somit eine Website für 600.- Euro.
  • Ein Großteil der professionellen Freelancer und günstigeren Agenturen lägen dann bei 70.- Euro Stundensatz und 40 Stunden bei 2800.- Euro.
  • Eine erfahrene Agentur kalkuliert ebenfalls eine Woche. Aber so manche Agentur wird völlig zu recht auch hierfür mindestens 2 Personen beschäftigen. Bei der Agentur die mit zwei Personen an der Website arbeitet und einem Stundensatz von 125.- Euro entstehen dann Kosten von 10.000 Euro.

Mal wieder haben wir einen Preisunterschied, der sich um mehr als das fünfzehnfache unterscheidet.

]]>
news-10 Fri, 19 Dec 2008 07:22:00 +0100 Die Entstehung der heute verbreiteten Tools blog-details/die-entstehung-der-heute-verbreiteten-tools Neulich hatten wir hier im Büro mal wieder die Diskussion CMS versus PHP Framework. Dabei fiel auf, dass die Unterschiede dieser Tools eigentlich nur vor dem Hintergrund der Geschichte von CMS und PHP Frameworks zu verstehen sind. Ich möchte hier im Blog mal versuchen diesen Gedankengang nachzuzeichnen.

Ein Rückblick

Es scheint noch gar nicht so lange her; doch erinnern wir uns: Im Jahr 2000 basierte ein Großteil der Websites selbst im professionellen Bereich noch auf statischen HTML-Dateien. Jeder kleine Rechtschreibfehler oder jedes vergessene Komma erforderte den Einsatz eines Entwicklers, der die Datei per FTP herunterlud, änderte und danach per FTP wieder auf den Server spielte. Endnutzer waren nicht in der Lage die Website direkt zu bearbeiten. Ein Relaunch einer gesamten Website in einem neuen Layout war eine große Herausforderung.

Selbstverständlich wurde auch damals schon ein wenig Funktionalität zu Websites hinzugefügt. Es gab frei verfügbare Gästebücher, Fotogallerien und Foren, die als PHP oder PERL Skripte häufig im CGI-Ordner eingefügt werden konnten. Selbst kleine Content Management Systeme, welche zumindest den Content eines Bereichs der Website verwalteten waren verbreitet. Auf den bekannten Skriptportalen fielen diese einfachen CMS in den Bereich Newsscripte.

Anspruchsvollere webbasierte PHP Anwendungen wurden von Grund auf neu entwickelt. In vielen Fällen hatten diese Anwendungen eine Website als Frontend und ein individuell entwickeltes Backend. Das Backend platzierte man typischerweise in einem /admin-Ordner direkt unterhalb der Root-Seite. Die ganzen individuell von Grund auf neu entwickelten PHP-Funktionen wurden unterhalb dieses Verzeichnisses platziert.

Zu dieser Zeit waren Entwickler gezwungen die gleichen Funktionalitäten immer und immer wieder zu schreiben. Programmierer verbrachten einen großen Teil Ihrer Zeit damit Standardfunktionalitäten wie Nutzerverwaltungen und Warenkörbe für die verschiedensten Projekte jedesmal neu zu entwerfen. Um sich diese Prozesse zu vereinfachen begannen viele einzelne Entwickler Code vom einen Projekt ins andere zu kopieren. Um den Code noch effektiver wiederverwenden zu können gab es sogar viele Programmierer die anfingen Ihre eigenen kleinen Frameworks zu entwerfen.

Es war zu dieser Zeit sehr offensichtlich dass großer Bedarf für zwei verschiedene Arten von Systemen bestand:

Es bestand Bedarf für professionelle Content Management Systeme, um Websites effizienter verwalten zu können. So dass Redakteure die Seiten bearbeiten konnten ohne für jedes zu ersetzende Komma beim Programmierer anfragen zu müssen.

Es bestand der Bedarf für professionelle Programmier-Frameworks um Entwicklern die ständige Neu-Entwicklung ähnlicher Funktionalitäten zu erleichtern.

Content Management Systeme erscheinen

Wie bereits angesprochen wurde ist die Idee eines Content Management Systems (CMS) sehr einfach. Es soll eine Plattform zur Verfügung gestellt werden, die es ermöglicht Inhalte zu erstellen, zu bearbeiten und zu verwalten. Diese Inhalte können danach in einer bestimmten Struktur wiedergegeben werden; beispielsweise als Website. Systeme die ausschließlich zur Verwaltung von Webinhalten verwendet werden bezeichnet man auch manchmal als Web Content Management Systeme (WCMS). Im Alltag ist es manchmal schwierig diese verschiedenen Systeme so klar zu unterscheiden. Viele der Systeme sind nämlich sowohl für online als auch für offline Content einsetzbar.

Meiner persönlichen Meinung nach ist TYPO3 bis heute das beste existierende Content Management System. Die Entwicklung von TYPO3 begann bereits 1998. Aber bis 2002 war es mehr oder weniger eine One Man Show von Kasper Skårhøj. Es war in etwa zu dieser Zeit als das System stärker in den Fokus der Öffentlichkeit rückte. Auch andere Content Management Systeme wie Drupal oder Mambo wurden im gleichen Zeitraum als Open Source Software veröffentlicht. Es war also wirklich erst 2001 und 2002 als Content Management Systeme in größerem Umfang der Öffentlichkeit zugänglich wurden.

Um nicht falsch verstanden zu werden. TYPO3 und die anderen genannten Anwendungen waren nicht die ersten professionellen Content Management Systeme. Auch vor 2001 waren bereits einige kommerzielle und proprietären Produkte auf dem Markt. Darüber hinaus hatten wir wie gesagt auch schon früher diese zahlreichen frei zugänglichen News-Skripte. Nichts desto trotz war es wirklich eine weltbewegende Veränderung für das Internet als plötzlich TYPO3 und die anderen Systeme frei erhältlich waren.

Es war eine zukunftsweisende Veränderung. Bereits kurz danach gab es kaum mehr eine Website die es dem normalen Redakteur nicht ermöglichen würde Inhalte über eine grafische Nutzeroberfläche zu erstellen und verändern. Die Trennung von Inhalt, Struktur und Layout war vollzogen. Non-Techies waren plötzlich in der Lage gesamte Websites selbst zu verwalten.

Ein weiterer Vorzug ging mit dem Aufkommen der Content Management Systeme einher. Funktionalitäten mussten von nun an nicht mehr als externe Skripte eingebunden werden. Content Management Systeme wie TYPO3 erlaubten das einbinden von Foren, Gästebüchern, Galerien, Shops und vielen weiteren Standardfunktionalitäten durch wenige Mausklicks.

Auch konnten Entwickler bereits damals eigene Funktionalität zu TYPO3 hinzufügen, indem sie existierende Dateien und Klassen innerhalb des existierenden TYPO3 Dateisystems erweiterten. Der nächste große Auftrieb kam als Kasper Skårhøj TYPO3 Version 3.5b1 in 2002 veröffentlichte. Diese Version beinhaltete einen Extension Manager und verwandelte TYPO3 in ein echtes Framework, welches das Hinzufügen neuen Codes und neuer Funktionalitäten wirklich sehr stark erleichterte.

Aber bevor ich irgendwann dazu auch noch was schreiben werde möchte ich heute noch gerne kurz erläutern wie es um die PHP Frameworks zu dieser Zeit stand.

Die ersten PHP Frameworks

Wenn Entwickler heute von PHP Frameworks sprechen, dann beziehen sie sich normalerweise auf Frameworks wir das ZEND Framework, Symfony, cakePHP oder CodeIgniter. 2001 und 2002 als die ersten Content Management Systeme populär wurden war noch keines dieser Frameworks verfügbar. Wenn wir jedoch den Begriff Framework ein wenig allgemeiner auslegen, dann können wir auch dann von Framework sprechen wenn wir bei eine Software in erster Linie dazu dient eine Struktur zur Verfügung zu stellen, die wiederverwendbare Komponenten bietet um Anwendungen effizienter entwickeln zu können.

Aus heutiger Sicht ist es dann zwar manchmal diskussionswürdig ob man einer bestimmten Software den Begriff Framework zuweist oder nicht. Doch hier soll jetzt erstmal interessieren was damals wie ein Framework genutzt wurde.

Neben den bereits oben erwähnten persönlichen Frameworks einzelner Entwickler, die Ihren Code strukturierten um darauf verschiedene Projekte aufsetzen zu können, war es aus meiner heutigen Sicht und Erinnerung insbesondere das PEAR Projekt, welches zu dieser Zeit gerade sehr populär wurde. PEAR steht für PHP Extension and Application Repository. Das Projekt definiert sich selbst auf der eigenen Website als ein „framework and distribution system for reusable PHP components“. Die Enwticklung von PEAR begann bereits 1999 mit dem Ziel Entwicklungsprozesse zu verkürzen und Code für Standardfunktionalitäten zur Verfügung zu stellen.

Neben PEAR war damals auch SMARTY sehr beliebt unter Entwicklern. Wieder ist es natürlich diskussionswürdig, ob man unter heutigen Gesichtspunkten SMARTY als Framework bezeichnen würde. Es ist in jedem Fall kein vollständiges Programmierframework. Doch zumindest als Templating-Framework erreichte es damals sehr hohe Popularität. Auch SMARTY begann bereits im Jahr 1999.

Es war auch möglich PEAR und SMARTY zu kombinieren. Es war erstmal ein kleiner Fortschritt. Es war für damalige Verhältnisse sehr effizient und fortschrittlich. Vielleicht war es noch nicht spektakulär. Der Gedanke Frameworks zur PHP-Entwicklung zu verwenden hatte aber somit bereits angefangen.

]]>
news-11 Mon, 15 Dec 2008 07:26:00 +0100 How it all began blog-details/how-it-all-began Around the year 2000 a large number of websites were still built with static HTML-Files. Every little spelling mistake or a missing comma that got discovered at a later point had to be replaced by the developer in the source code and uploaded again by FTP. End users were not able to edit the content of the website directly. A relaunch of the whole website in a new layout was a huge task.

Of course already at that time it was possible to add a little functionality to the website with the help of small PHP-Scripts like Guestbooks or Forums. Even tiny content management scipts (news scripts) were around, which allowed the user to be able to update and edit at least parts of the website dynamically.

The development of more advanced web based applications were usually done as custom programming from scratch. In most cases, these applications had the actual website as a frontend and a custom developed backend. The backend usually was located in an /admin folder directly under the root of the website. All the custom developed administrative functionalities were included in this area and were mainly aimed at giving the website administrator some control over the website and it's data.

Active developers at that time were forced to rewrite the same functionalities again and again for implementing stuff like handling user authentication, shopping carts and some simple tools to handle content. As many different projects or different parts of the same project required the same identical functionalities, developers usually copied and pasted code from one place to the other. To be able to reuse code more efficiently, many developers had already felt the need and started building their own little frameworks.

It was obvious that at that time, there was a huge need for 2 types of systems:

  • There was the need for more professional systems to manage the contents of a website more efficiently, so that the editors can manage the Contents of the Website without requiring a technical guy, each time they want to add a comma.
  • There was the need for more professional development frameworks, so that developers don’t have to rewrite the same code again and again.

 

The early days of Professional Content Management

As we have already seen, the basic Idea behind a Content Management System (CMS) is to provide a plattform to create, edit and manage content. This Content can then be used or displayed in a specified structure. For example, as a website. Systems that handle exclusively content for the Internet are sometimes also referred to as Web Content Management System (WCMS). In reality it is today sometimes difficult to really clearly differentiate between WCMS and CMS systems, as in most cases both systems can be used for both scenarios.

In my personal opinion, until today; the strongest existing CMS is TYPO3. Development of TYPO3 began already in 1998. But until 2002, it was a one man show by Kasper Skårhøj. It was only around that time, when this system attracted major public interest. Even other Content Management Systems like Drupal or Mambo had been released as Open Source Software around the same time in 2001.

Not to be misunderstood: TYPO3 and the other applications were not the first Content Management Systems. Even before that, there were already some commercial and proprietary CMS around. As mentioned above, we already had some freely available small News Management Scripts. However, it really changed the world for developers, when at the end of 2001, there was suddenly TYPO3 and a further selection of professional Content Management Systems easily available.

This meant a huge step forward. Very soon, there would hardly be any websites around anymore, which would not allow a normal editor to create and edit content. The separation of Content, Structure and Layout was achieved. Non-Techies, were suddenly able to manage whole websites through Graphical User Interfaces.

Another advantage came up in these early days of publicly available CMS. Functionalities did not have to be embedded anymore as external scripts. Content Management Systems like TYPO3 allowed including Forums, Guestbooks, Shops, etc just with a few mouse clicks.

Already in those early days, it was possible to add your own personal new functionality to TYPO3 by manually creating files and extending classes within the existing TYPO3 filesystem. The next boost happened, when Kasper Skårhøj released TYPO3 Version 3.5b1 in 2002. This Version contained the Extension Manager and turned TYPO3 into a real framework that made it really easy to develop new code and add new functionality to the system. But before we look into this in more detail, let us first see, what the PHP frameworks were doing around that time.

The early days of PHP Frameworks

If developers speak of PHP Frameworks today, they usually refer to frameworks like the ZEND Framework, Symfony, cakePHP or CodeIgniter. In the years 2001 and 2002, when the first Content Management Systems became popular non of these frameworks were available. However, looking at frameworks in a more general way. We can speak of a PHP framework whenever we have a base structure, that provides reusable components for developers to create applications more efficiently.
Besides all the numerous personal frameworks, that developers already used in 2001/2002 to reuse their own code, there was one particular framework that was standing out at that time. The PHP Extension and Application Repository (PEAR) is a framework and distribution system for reusable PHP components that started already in 1999. The idea of PEAR, was to shorten the development process, by providing code for standard functionalities.

PEAR was not the only framework that was popular at that time. Another very popular framework was SMARTY, a templating framework, that provided options to separate content from layout. Even SMARTY was already started in 1999.

It was possible and popular to combine these frameworks. There were some other frameworks available as well. It was nice. It was efficient. Maybe, it was not spectacular yet. However, that was more or less how the use of frameworks in the PHP world started.

]]>
news-12 Fri, 12 Dec 2008 07:31:00 +0100 Preisbildung durch betriebswirtschaftliche Überlegungen blog-details/preisbildung-durch-betriebswirtschaftliche-ueberlegungen In einem vorherigen Post habe ich mir darüber Gedanken gemacht, warum man bei TYPO3 Angeboten so eine weite Preisspanne erhält. In einem weiteren Post ging es dann darum, dass der Preis von TYPO3 Projekten zwar wie bei einem Auto durchaus von den Features abhängt, aber halt ebenso von vielen weiteren Faktoren. Wie in diesem letzten Post diskutiert wurde sorgt schon allein die Größe des Auftragsgebers für völlig verschiedene Anforderungen. Ich möchte diesen Gedanken heute mal etwas weiterführen…

Verschiedene Planung bei Großunternehmen und Pizzeria

Die Spanne an potentiellen Anwendern von TYPO3 ist ja wie bereits besprochen sehr groß. Nehmen wir also mal als vereinfachtes Beispiel ein imaginäres Großunternehmen aus der Telekommunikationsbranche dessen Jahresumsatz sich auf 8 Milliarden Euro beläuft und welches die komplette Website auf TYPO3-Basis betreibt. 5% der Umsätze werden direkt aus Vertragsabschlüssen über die Firmeneigene Website generiert. 400 Millionen werden also jährlich direkt über die Website eingenommen. Darüber hinaus hat unser imaginäres Unternehmen eine Studie in Auftrag gegeben, welche belegt, dass sich weitere 35% der Kunden zuerst auf der Website informieren bevor Sie einen Vertrag abschließen. Insgesamt ist also jährlich ein Verkaufsvolumen von 3,2 Milliarden Euro direkt oder indirekt von der Website abhängig. Wenn es diesem Unternehmen jetzt gelingt die Website beispielsweise ein wenig nutzerfreundlicher zu gestalten und sich dadurch die direkten und indirekten Verkäufe über die Website um 10% erhöhen, dann sind das bereits 320 Millionen Euro im Jahr. Hier kann man schon mal relativ bequem 60.000 Euro allein für eine Usability Studie ausgeben und weitere 240.000 Euro um die Maßnahmen umzusetzen.

Die kleine imaginäre Pizzeria aus dem letzten Post hat einen angenommenen Jahresumsatz von 65.000 Euro. Die meisten Gäste kommen in die Pizzeria, weil die Pizzeria in ländlicher Gegend direkt neben dem Freibad liegt. Kunden die direkt online bestellen gibt es gar nicht. Indirekte Verkäufe über die Website hat die Pizzeria gelegentlich schon. Das sind die Kunden welche eine Pizzeria im Internet suchen und dann direkt kommen. Dies sind in etwa 0,5% der Gäste. Das sind 325 Euro Umsatz im Jahr. Möchte jetzt auch diese Pizzeria Ihre Website nutzerfreundlicher gestalten, um dadurch die Umsätze über die Website um 10% erhöhen, dann besteht hier die Chance auf einen potentiellen jährlichen Umsatzzuwachs von 32,50 Euro. Betriebswirtschaftlich ist hier eigentlich gar keine sinnvolle Investition möglich. In der Praxis wird es häufig in etwa auf folgendes raus laufen: Der Pizzeriabesitzer gibt dem Webdesigner für 3,50 Euro ein Bier aus während dem die beiden über mögliche Optimierungen sprechen. Für die verbleibenden 28 Euro lädt der Pizzeriabesitzer den Webdesigner und seine Freundin auf eine Pizza ein. Dafür sitzt der Webdesigner nach Feierabend für ein paar Stunden mit dem Pizzeriabesitzer zusammen und Sie setzen die beim Bier besprochenen Optimierungen um.

Verschiedene Märkte

Mal abgesehen davon, dass das freundliche Arbeitsverhältnis zwischen Pizzeriabesitzer und Webdesigner irgendwo an der Grenze zur Schwarzarbeit liegt und sich die anderen Webdesigner des Dorfes beschweren werden, dass dieser Webdesigner die Preise kaputt macht, würde ich die hier beschriebene Preisfindungslogik in gewissem Sinne sogar als äußerst fair bezeichnen. Denn die kleine Pizzeria müsste gar keine 300.000 Euro ausgeben um die nutzerfreundlichste Gastronomie-Website im Dorf zu haben. Das Bier und die Pizza reichen als „Investition“ um die Website von der zweit freundlichsten Gastronomiewebsite im Dorf zur freundlichsten Gastronomiewebsite im Dorf zu machen. Selbst eine Investition von 5000.- Euro würde hier keine deutliche Umsatzsteigerung mehr erzeugen können. Beim Telekommunikationsunternehmer sieht das völlig verschieden aus. Alle Mitbewerber haben ein ähnliches Budget zur Verfügung. Der Kampf um die attraktivste Website findet hier auf einem viel höheren Niveau statt.

Faktoren der Preiskalkulation unter Berücksichtigung der Unternehmensgröße

Größe des Unternehmens und potentielle Gewinnerwartung durch eine Investition in eine TYPO3-Website sind entscheidende Faktoren für die Preiskalkulation. Verwaltungen, Vereine und Regierungsorganisationen können sich entsprechend fragen wie groß der Wert über ein bestimmtes Ziel zu informieren ist.

  • Je größer der Umsatz das ein Unternehmen über den Onlinevertriebskanal erwirtschaftet, desto größer der Gewinn, wenn dieser Umsatz um nur wenige Prozentpunkte angehoben wird. Je mehr sich jedoch ein Unternehmen in einem Markt befindet indem viel verdient werden kann, desto höher ist auch der Konkurrenzdruck, weil auch die Mitbewerber viel in ihre Onlinepräsenz investieren. Je nachdem wie diese Umsatzerwartung aussieht ergeben sich daraus eine Rolle von Folgefaktoren die ebenfalls den Preis beeinflussen.
  • Je größer der Konkurrenzdruck in dem Segment in welchem die Website entsteht, desto höher werden auch die allgemeinen Qualitätsanforderungen. Als Auswahlkriterium zählt dann hierbei die Erfahrung und Referenzen des Anbieters.
  • Je Anspruchsvoller das Projekt desto mehr Mitarbeiter und Entscheidungsträger werden benötigt. Dies sorgt für eine höhere Kommunikationsanforderung. Wie laufen die Kommunikationsprozesse ab? Wie viele Unterschriften braucht man beispielsweise auf Auftragsnehmer- sowie auf Auftraggeber Seite um eine Änderung abzusegnen?
  • Je größer die finanzielle Bedeutung des Projekts desto höher werden die Security Anforderungen. Welche Security Richtlinien liegen dem Auftrag zu Grunde?
  • Je komplexer das Projekt desto höher werden die Wartungsanforderungen. Wie hoch ist der Aufwand für Wartung und Pflege? Professionelle Projekte sind zudem fast nie eine einmalige Investition. Hier gibt es ein jährliches Budget. Denn das Projekt wächst weiter.
  • Je größer das Projekt desto größer sind im Normalfall die Anforderung an die Skalierbarkeit: Soll die Website mit dem Unternehmen wachsen?
  • Je höher der Konkurrenzdruck desto höher ist auch die Kreative Anforderung.
  • Je komplexer die bestehende IT-landschaft in welche das TYPO3-Projekt eingebettet werden muss desto höher die Integrationsintensität.
  • Je größer das Projekt desto höher die Schulungs- und Beratungsanforderungen von der Marktforschung bis zur Ausbildung der Redakteure.
  • Je größer all die vorherigen Anforderungen sind desto größer sind nomalerweise auch die Anforderung an den Featureumfang (und hier schließt sich der Kreis).
  • Je anspruchsvoller alle oben genannten Anforderungen sind, desto kleiner wird auch die Auswahl an Implementierungspartnern, welche diese Herausforderungen schultern können. Sie müssen also mit den besten arbeiten. Hier liegen dann auch die Stundensätze wieder höher.

 

Schlussfolgerung

Reine Kalkulation nach Feature-Umfang wie wir es im vorherigen Kapitel gesehen haben findet eigentlich nur bei sehr kleinen Projekten statt. Je größer die Projekte werden desto mehr muss an ein Projekt wie an eine richtige Investition angegangen werden. Überlegen Sie sich gemeinsam mit einem erfahrenen Partner welchen Umsatzgewinn oder welche anderen Vorteile Sie durch eine gewisse Investition erwarten können. Wie kann dieser Gewinn am besten erzielt werden. Die Implementierung von „Features“ wird hierbei einer unter mehreren Gesichtspunkten. Früher oder später macht es dann mehr Sinn für TYPO3 ein jährliches Budget zur Verfügung zu stellen, als mit einer einmaligen Investition zu rechnen.

]]>
news-13 Thu, 11 Dec 2008 07:35:00 +0100 Umgang mit Scope Creep blog-details/umgang-mit-scope-creep Ein insbesondere in der IT leider allzu verbreitetes Problem: Irgendwann hat das Projekt dann mal in etwa 2 Monate Verspätung. Den Aufwand für diese zwei Monate extra Entwicklungszeit trägt der Auftragnehmer wenn er zum Festpreis arbeitet und nicht aufpasst schnell selbst. Manchmal zu recht. Denn teilweise ist das auch eine selbst verschuldete Fehlkalkulation, was bedeutet, dass der Auftragnehmer den Aufwand an manchen Stellen schlicht unterschätzt hat. Was andererseits leider bei Projekten ab einer gewissen Größenordnung relativ leicht passieren kann. Teilweise hat das aber auch mit einem Phänomen zu tun, welches man im Projektmanagement und insbesondere bei IT-Projekten als schleichenden Funktionszuwachs oder als Scope Creep bezeichnet.

Was ist Scope Creep?

Dies ist ein sehr verbreitetes Problem, mit dem in der IT-Branche alle zu kämpfen haben. Im Projektmanagement ist das eine komplette Disziplin für sich. Es gibt auch schöne dicke Bücher, welche sich mit schicken mathematischen Formeln und Diagrammen zu diesem Thema auseinandersetzen. So sehr ich mir wünschen würde so etwas wegrechnen zu können hilft das aber leider zumeist auch nicht weiter.

Scope Creep kommt in der Regel durch neue Sichtweisen oder Erkenntnisse zu stande die sich erst während der Entwicklung ergeben. Diese neuen Erkenntnisse können wesentlich zur Verbesserung des Produkts beitragen. Schleichender Funktionszuwachs geht wie der Name schon sagt auch mit einem Zuwachs der Funktionalität einher. Das heisst nach Abschluß des Projekts erhält der Auftraggeber dann auch mehr als vorab abgesprochen wurde. Häufig realisiert der Auftraggeber auch erst während der Entwicklung, dass noch weitere Funkionen benötigt werden. Im Grunde genommen ist Schleichender Funktionszuwachs also nichts Schlechtes. In der Regel spricht man aber erst dann vom schleichenden Funktionszuwachs, wenn diese Erweiterungen nicht über formelle Prozesse sondern über informelle Absprachen in die Entwicklung einfließen. (Vergleiche auch die Definition im Projekt Magazin)

Vorab: Ich denke Scope Creep ist in fast allen Fällen nicht die Schuld von jemandem. Weder vom Auftraggeber noch vom Auftragnehmer. Es ist einfach das Problem, dass man vorab gemeinsam eine Spezifikation erarbeitet hat nach dem zu diesem Zeitpunkt besten Wissen und Gewissen und dann während der Entwicklung erhöht sich schleichend der Aufwand. Es ist meiner Meinung nach keine Schuldfrage. Aber es geht hier um ein “Phänomen”, welches alle Projektverantwortlichen anerkennen sollten.

Noch einfacher ausgedrückt ist das Problem, dass man vor dem Projekt ein Angebot auf Basis des besten zu diesem Zeitpunkt gegebenen Wissensstandes schreibt und die Projektkalkulation auch auf Basis dieser Definition durchführt. Während der Entwicklung kommen Funktionen hinzu die in der Spezifikation nicht beinhaltet waren, die aber für alle Beteiligten später Sinn machen. Der Aufwand steigt aber und wenn man nicht aufpasst trägt man diesen Aufwand als Auftragsnehmer allein.

Es mag absurd klingen. Aber ich denke fast jeder der regelmäßig an größeren IT-Projekten mit arbeitet wird im Grunde seines Herzens bestätigen, dass es manchmal auch schwierig ist eine eindeutige Antwort zu finden, warum ein Projekt plötzlich zwei Monate Verzögerung hat. Ob das jetzt ausschließlich an einer Fehlkalkulation, bzw Unterschätzung des Aufwands auf Auftragnehmerseite lag oder ob man es überwiegend mit schleichendem Funktionszuwachs zu tun hat. In der Praxis gehen diese beiden Perspektiven leider auch häufig nahtlos in einander über. Wenn man nicht aufpasst dann merkt man bei einem großen Projekt plötzlich lediglich, dass man zwei Monate mit dem Projekt hinten dran liegt und dass man diese Überschreitung der Entwicklungszeit gerade aus der eigenen Kasse finanziert.

Was tun bei schleichendem Funktionszuwachs?

Es gibt eigentlich nur zwei Möglichkeiten wie das gelöst werden kann. Entweder (und insbesondere für größere Projekte ist das irgendwann fast zwingend) man denkt über einen formellen Prozess für Änderungsanforderungen nach, oder man versucht den Verwaltungsaufwand möglichst gering zu halten und über eine Pauschale oder ähnliches einen Weg zu finden wie man die Last des schleichenden Funktionszuwachses zumindest gemeinsam tragen kann.

Während bei kleineren Projekten und ein wenig Kulanz auf beiden Seiten schleichender Funktionszuwachs tatsächlich mit gelegentlichen Pauschalzuzahlungen abgedeckt werden kann, kommt man bei großen Projekten in der Regel um ein professionelles Änderungsmanagement kaum herum.

Zudem gilt es von Anfang an wachsam zu sein. Denn wenn der Aufwand dann mal höher ist wie anfangs angenommen, kann man das leider nicht mehr ändern. Häufig ist der Aufwand dann auch nicht völlig über die ursprüngliche Kalkulation hinaus. Dennoch sollte man sich möglichst früh gemeinsam mit allen Projektbeteiligten fragen, ob man eher die minimale in der ursprünglichen Spezifikation vorgegebene Variante verwirklichen will. Oder ob man alle Features die erst während der Umsetzung einfallen auch verwirklichen will und ob man dafür in Kauf nimmt, dass der Aufwand wächst und in irgendeiner Form zumindest gemeinsam getragen werden muss.

Man muss dabei wirklich im Hinterkopf behalten, dass es sich ja dann auch nicht um einen höheren Aufwand für das gleiche Produkt handelt sondern um einen erhöhten Aufwand für ein dann besseres Produkt als ursprünglich geplant. Verhindern kann man diese Problematik leider nicht ganz. Man kann höchstens durch klare Kommunikation, Dokumentation und die entsprechenden Prozesse versuchen, dass das Problem maximal transparent wird und der Auftraggeber eine maximal transparente Entscheidungsgrundlage hat.

]]>
news-14 Thu, 04 Dec 2008 07:39:00 +0100 Preisbildung durch Summe von Einzelfunktionalitäten? blog-details/preisbildung-durch-summe-von-einzelfunktionalitaeten Vor ein paar Tagen hatte ich schon mal einen Beitrag geschrieben, dass es ein sehr breites Spektrum an TYPO3-Sites gibt, welches von sehr unterschiedlichen Anwendern mit sehr unterschiedlichem Budget eingesetzt wird. In meinem heutigen Artikel möchte ich gerne an das Thema „Wieviel kostet eine TYPO3 Website?” anschließen. Häufig wird aus meiner Erfahrung davon ausgegangen, dass sich die Preise einer TYPO3-Website ausschließlich über die Features festlegen lassen. Doch macht das Sinn?

Feste Einsteigerpreise

Meiner Meinung nach ist es ein Irrglaube, dass sich der Preis einer Website ausschließlich über die Summe von Einzelfunktionalitäten kalkulieren ließe, die man in einer sogenannten Featureliste zusammenfassen könne. Dadurch besteht recht häufig selbst bei großen Projekten oder in der Zusammenarbeit mit erfahrenen Agenturen die Erwartungshaltung, dass TYPO3-Dienstleister in der Lage sein sollten Preise in etwa wie folgt anzubieten:

  • Einfache TYPO3-Website kostet bei uns 2500.- Euro
  • TYPO3-Website mit Logo-Entwicklung 2750.- Euro
  • TYPO3-Website mit Shop und Logo-Entwicklung 8300.- Euro
  • etc.

 

Zwar ist dies so und in ähnlicher Weise für Einsteigerlösungen durchaus möglich und auch netzrezepte.de bietet ein TYPO3 Einsteiger Bundle und ein TYPO3 Umsteiger Bundle zum Festpreis an. Solche TYPO3 zum Festpreis Angebote bieten auch tatsächlich einen sehr guten und kompakten Einstieg. Solche Preise lassen sich aber nicht auf jedes Szenario übertragen. Ein solches Paket kann nicht die Anforderung jeder Website abdecken.

Wieviel kostet ein Auto?

Um zu einer allgemeingültigeren Betrachtung zu kommen muss etwas weiter ausgeholt werden. TYPO3 selbst ist wie gemeinhin bekannt Open Source Software und somit kostenlos erhältlich. Für den Dienstleister selbst hängt der Preis den er verlangen muss letztlich in erster Linie vom Stundenaufwand ab und dieser ist vorab schwer zu schätzen. Der Stundenaufwand hängt wie gezeigt werden soll nicht nur von der Featureliste ab, doch ironischerweise fördern Dienstleister in Ihrem Bestreben sich nicht auf einen Festpreis fixieren zu lassen diese rein Feature gebundene Erwartungshaltung häufig sogar noch, indem Sie auf die Frage „Wieviel kostet eine TYPO3 Website?“ mit ausweichenden rhetorischen Fragen wie „Wieviel kostet ein Auto?“ kontern.

Klar Auto ist nicht gleich Auto und TYPO3-Website ist nicht gleich TYPO3 Website. Somit weist diese rhetorische Gegenfrage auch durchaus korrekterweise daraufhin, dass Ausstattung, Leistungsumfang und ähnliche Faktoren auch in anderen Branchen völlig verschiedene Preise rechtfertigen. Gleichzeitig verstärkt diese Frage aber sogar den unzulässigen Eindruck, dass sich Preise nicht nur „unter anderem“ sondern „ausschließlich“ über solche mehr oder weniger quantifizierbaren Faktoren festlegen ließen.

In der Konsequenz fixiert sich der interessierte Kunde also noch mehr genau wie beim Autokauf auf den Wunsch nach existierenden Preislisten und wir sind genau wieder zurück beim Ausgangsproblem und der Forderung auch für ein TYPO3-Projekt anzugeben wie viel man für welches Modell mit welchen Features bezahlen muss.

Zum Beispiel Logo-Erstellung

Natürlich: Feature-Umfang ist ein entscheidender Faktor bei der Preisfindung. Aber bei weitem nicht der Einzige. Ich möchte das anhand eines kleinen Beispiels illustrieren. Betrachten wir mal nicht die Erstellung einer ganzen Website sondern betrachten wir mal nur ein einzelnes Feature. Oben hatten wir das Beispiel „Was kostet eine TYPO3-Website ohne Logo-Erstellung?“ und „Was kostet eine TYPO3-Website mit Logo-Erstellung?“. Greifen wir uns nur mal dieses einzelne Feature „Logo-Erstellung“ heraus, so wird der hilflose Versuch deutlich, eine Unbekannte mit der Hilfe einer zweiten Unbekannten zu definieren. Denn bereits dieses einzelne scheinbar kleine Feature Logo-Erstellung kann vieles heißen:

  • Ein Freund von mir arbeitet als Manager bei einem Großunternehmen und war letztes Jahr als Koordinator für die Erstellung eines neues Logos durch eine Werbeagentur zuständig. Hierbei entstanden externe Kosten von gut 22.000 Euro, welche die Agentur in Rechnung stellte und zusätzlich weiterer Aufwand, der durch verlorene Arbeitszeit der Mitarbeiter entstand. Mein Freund geht hierbei mindestens nochmals von der gleichen Summe aus. Bis das Logo endgültig abgesegnet wurde waren mehrere Vorbesprechungen nötig, sowie eine Analyse der Corporate Identity und der Logos verschiedener Mitbewerber. Es musste diskutiert werden was das Unternehmen mit dem neuen Logo ausdrücken will. Es mussten mehrere Entwürfe angefertigt werden und es gab wiederum zahlreiche Treffen bis das Logo letztlich von allen Entscheidungsträgern abgesegnet werden konnte. Für jedes einzelne dieser Treffen mussten offizielle Präsentationen vorbereitet werden und jedesmal mussten mehrere Mitarbeiter des Auftraggebers und der Agentur anreisen.
  • Wem ein solcher Aufwand schwer vorstellbar scheint, dem sei noch das Beispiel der Logo-Entwicklung bei der Partei „den Grünen“ ans Herz gelegt. Hier fehlen mir zwar leider die Zahlen doch der Aufwand bei der Einführung dieses Logos ist auch für Außenstehende sehr detailliert nachzuvollziehen weil in diesem Zusammenhang ein solcher Streit ausgebrochen ist, dass die Logo-Diskussion in die Öffentlichkeit hinein getragen wurde. Wie beispielsweise Spiegel Online berichtete wurde sogar ein 37-Seitiger Leitfaden vertraulich versandt , der den Umgang mit dem neuen Logo erklären soll. Laut SPIEGEL ONLINE heißt es dort über das neue Logo dieses sei „aufgeräumt, dynamisch, individuell, natürlich, organisch, ausführlich”. Die Sonnenblume sei „durch die radikale Vereinfachung expressionistisch”, der blaue Balken „ein geschichtliches Fundament”. Das Hintergrund-Grün gebe dem Ganzen eine „gefühlte Tiefe”. Ich habe keine Ahnung wie so etwas in einer Partei finanziert wird. Aber dass solche Aufwände Kosten erzeugen ist glaube ich selbstverständlich.
  • Dem gegenüber stehen Schüler und Studenten die sich ein wenig das Taschengeld aufbessern wollen, indem sie für Vereine und kleinere Unternehmen Websites entwickeln. Für die Erstellung eines Logos wird dann manchmal lediglich ca. 50 Euro berechnet. Dabei wird dann der Name des Unternehmens in einem Grafikprogramm geschrieben, farblich an die Website angepasst und in drei Versionen mit drei verschiedenen exotischen Schrifttypen abgespeichert. Auch hier sucht sich der Kunde dann eines aus diesen Logos aus. Für das Logo der Pizzeria um die Ecke sieht das zumeist professionell genug aus und viele solcher Kunden sind damit vielleicht auf Anhieb zufrieden.

 

Das einzelne Feature „Logo“ haben wir jetzt in völlig verschiedenen Preisklassen betrachtet. Übrigens halte ich die unterschiedlichen Preise alle für völlig gerechtfertigt. Das Großunternehmen ist glücklich über das neue Logo und dass die Agentur in der Lage war alle Entscheidungsberechtigten zufrieden zu stellen und die Pizzeria ums Eck ist ebenfalls glücklich. Die Agentur aus erstem Beispiel ist glücklich dass das Projekt ein Erfolg war und der Agenturstundensatz bezahlt wurde. Und auch der Student ist glücklich, dass er für zwei Stunden Arbeit 50 Euro bekommen hat, die er am Wochenende in seiner bevorzugten Studentenkneipe ausgeben kann.

Preislisten für den Service-Bereich

Im Service-Bereich gibt es wie in allen Bereichen Produkte mit verschiedenen Merkmalen und selbstverständlich hat auch im Dienstleistungsbereich der Feature-Umfang einen Einfluß auf den Preis. Dennoch wird es im Service-Bereich nie einheitliche Preislisten allein nach Featureumfang geben können. Selbst Produkte mit ähnlicher Spezifikation können in verschiedenen Szenarien einen komplett verschiedenen Aufwand bedeuten. Das gibt es zwar auch bei Autos, weil auch hier Faktoren wie Markenname und Qualität eine Rolle spielen im Service-Sektor scheinen jedoch Faktoren jenseits der Summe der Einzelfunktionalitäten einen relativ gesehen deutlich höheren Einfluss auf den Preis zu haben.

In Teil 9 dieser Serie werde ich versuchen diese Problematik nochmals anhand statistischer Zahlen zu belegen. Vereinfacht können wir das aber für jetzt nochmals an obigem Beispiel nachvollziehen. Das Großunternehmen wird vielleicht für eine TYPO3-Website mit Logo-Entwicklung 450.000.- Euro ausgeben und für eine Website ohne Logo-Entwicklung 428.000 Euro. Die Pizzeria wird für die Website inklusive Logo-Entwicklung 1.200.- Euro ausgeben und für die Website ohne Logo-Entwicklung 1.150.- Euro. Das Großunternehmen liegt also in beiden Fällen im sechsstelligen Bereich, knapp unterhalb einer halben Million. Die Pizzeria liegt in beiden Fällen im dreistelligen Bereich, knapp oberhalb 1000.- Euro.

Spontan könnte man hier bereits den Schluss ziehen, dass die Unternehmensgröße des Auftraggebers hier das Preissegment der Lösung stärker beeinflusst als die Featureliste. In den nächsten Tagen werde ich in einem weiteren Post das Ganze nochmals etwas genauer betrachten. Denn wenn sich der Preis also nur sehr begrenzt über die Summe aller Einzelfunktionalitäten berechnen lässt, wovon hängt er dann ab?

]]>
news-15 Tue, 02 Dec 2008 04:39:00 +0100 TYPO3 – Ein weites Spektrum blog-details/typo3-ein-weites-spektrum Wenn Sie sich Angebote für eine TYPO3-Website einholen ist es völlig normal, dass Sie für ein und dieselbe Ausschreibung eine unglaubliche Preisspanne an Angeboten bekommen. Preise die sich gut um den Faktor zehn unterscheiden sind durchaus die Regel. Es ist somit nichts ungewöhnliches wenn Ihnen auf den gleichen Anforderungskatalog zwei Angebote eintrudeln; eines für 1.500.- € und eines für 15.000.- €. Angenommen Sie wollen ein TYPO3 Festpreis-Paket. Selbst hier haben Sie eine Spanne von 500.- € bis gut 10.000.- €. Auf den ersten Blick scheinen diese Pakete sogar sehr ähnlich ausgestattet zu sein.

Ein weites Anwendungsfeld

Es gibt ein sehr breites Anwendungsfeld für TYPO3. Das wird schon deutlich wenn man das weit gefächerte Nutzerspektrum betrachtet. Einerseits findet TYPO3 bei Kleinstunternehmen und Vereinen Verwendung. Andererseits wird dieses Open Source CMS von sehr großen Unternehmen eingesetzt wie Philips, Lufthansa, Volkswagen, ThysenKrupp, Merzedes Benz, General Electric, Air France oder Ford (einige ganz nette Beispiele bieten Jean-Luc Henry und Yannik Pavard in ihrem Blog: Seite 1, Seite 2, Seite 3 ).

Total Cost of Ownership

Total Cost of Ownership jeder Website besteht zudem nicht nur aus den Zahlungen an den externen IT-Dienstleister sondern muss auch die hauseigenen Kosten miteinbeziehen. Auch nicht allzu selten dürften Unternehmen sein, die zwischen 5 und 20 qualifizierte Redakteure beschäftigen, welche beispielsweise im Bereich Öffentlichkeitsarbeit oder Produktpflege für einen e-Shop in Vollzeitbeschäftigung Daten über eine TYPO3-Website bearbeiten. Wenn man solche internen Kosten hinzunimmt, dann sind das über den Daumen gepeilt bei einer solchen Website wohl häufig bereits etwa 1 Million € Personalkosten pro Jahr.

Gleichzeitig gibt es auch bei den internen Kosten die kostenlose Variante. Als Beispiel sollen auch hier wieder die Vereine herhalten, bei denen ehrenamtliche Mitglieder kostenlos die Inhalte in die TYPO3-Website einpflegen.

Etat-basierte Preise

Es gibt Unternehmen die ihren Werbe- und Öffentlichkeitsarbeit-Etat prozentual vom Umsatz kalkulieren. Je nach Unternehmen kann ein solcher Etat heute häufig überwiegend für online Aktivitäten zur Verfügung gestellt werden, wovon bei einigen Unternehmen ein beachtlicher Teil in Anbetracht der enormen Verbreitung von TYPO3 bereits in Arbeiten rund um dieses CMS fließen dürfte. Jährliche Etats von über 100.000.- € dürften hierbei keine Seltenheit sein.

Gleichzeitig existieren nach wie vor genügend Studenten, welche mal hier und da für 100.- € oder 200.- € TYPO3-Websites komplett umsetzen für welche dann auch keine Folgekosten von mehr als 60.- € jährlich für Hosting entstehen. Der durschnittliche jährliche Etat liegt dann wohl um die 100.- €.

Eine weite Spanne

Um es hiermit also gleich vorweg zu nehmen: Es gibt zahlreiche TYPO3-Websites mit Budget von mehreren 100.000.- € und es sind wohl bereits TYPO3-Websites im Millionenbereich umgesetzt worden. Zugleich gibt es TYPO3-Websites welche kostenlos erstellt wurden. Es ist offensichtlich: Es gibt sehr verschiedene TYPO3-Websites.

Worin bestehen die Unterschiede zwischen diesen TYPO3-Projekten und wie sollten Sie kalkulieren, wenn Sie selbst eine TYPO3-Website erstellen lassen wollen? Worauf sollten Sie achten, damit Sie wirklich Äpfel mit Äpfel und nicht Äpfel mit Birnen vergleichen? Genau darauf möchte ich versuchen in dieser Serie „Was kostet TYPO3“ Antworten zu geben.

]]>