CRM- und PM-Prozesse mit SharePoint abbilden

SharePoint als Businessplattform
Kommentare

SharePoint ist eine mächtige Integrationsplattform, auf der durch Customizing nahezu alles abgebildet werden kann, was man sich ausdenken mag. Aktuell sehen wir SharePoint in vielen Unternehmen vor allen Dingen in kollaborativen oder dokumentenorientierten Szenarien im Einsatz, bisher jedoch noch selten in echten Business- (z. B. CRM) oder Businessintegrationsanwendungen (z. B. SharePoint 2 SAP). Daher konzentriert sich dieser Artikel auf die Abbildung von Businessanwendungen oder auch Projekt-, IT- und ITIL-Managementlösungen auf Basis der SharePoint-Plattform (Foundation oder Server) und soll den Einstieg in die Nutzung von SharePoint als Businessplattform erleichtern und neue Wege für die Umsetzung von Geschäftsanwendungen zeigen.

Gründe für SharePoint als Businessplattform

Es gibt mehr Gründe als Platz in diesem Beitrag, deshalb sollen nur fünf der zahlreichen Highlights genannt werden:

  1. SharePoint ist ein mächtiger Integrations-Hub zur Verbindung von bisher isolierten Systemen, Prozessen, Daten und Menschen
  2. Integrierte Business-Apps amortisieren die Investitionen in SharePoint in kürzester Zeit
  3. Businessanwendungen werden automatisch kollaborativ und beherrschen Dokumentenmanagement und Workflowautomatisierung
  4. Es gibt hervorragende Drittwerkzeuge, die Anbindungen an SAP (z. B. Theobald-Software), fertige SAP-Szenarien (z. B. Sitrion) oder das Management von Workflows (z. B. NINTEX) vereinfachen
  5. Reduzierte Rollout-Kosten, da die Anwender die Bedienkonzepte der Office-Welt kennen

Geschäftsanwendungen auf Basis von MS SharePoint können einfach mehr, stehen früher zur Nutzung bereit, bieten Office und SharePoint-Features und liefern meist intuitive Bedienkonzepte, die Benutzer schon von SharePoint und MS Office kennen.

Einschränkungen

SharePoint ist keine geeignete Plattform für massive Transaktions- oder Echtzeitsysteme. Wer also SharePoint als Ersatz für SAP oder Produktionssteuerungen einsetzen möchte, wird schnell auf Hindernisse stoßen. Aber auch für „normale“ Businessanwendungen wie CRM, Qualitätsmanagement, Projektmanagement oder Ähnliches hat SharePoint Features, die in Konzepten berücksichtigt werden sollten. Im Folgenden sollen nur einige von vielen genannt werden:

  • Daten liegen nicht lesbar in der Datenbank vor. Backup und Restore erfordern spezielle Konzepte.
  • Das Berechtigungsmodell von SharePoint ist für Geschäftsanwendungen zu einfach gehalten.
  • Im Standard fehlen wichtige GUI-Elemente, die in Geschäftsanwendungen unbedingt erforderlich sind.
  • Suchfunktionen in Listen und Daten sowie Druck-, E-Mail- und Navigationsfunktionen sind out of the Box wenig geeignet für Geschäftsanwendungen.
  • Anwendungsspezifische, administrative Funktionen müssen aufwendig entwickelt
  • werden.

Out of the Box ist SharePoint also nützlich, aber nicht nützlich genug. Deshalb bietet SharePoint zahlreiche Möglichkeiten, aus dem SharePoint-Baukasten durch Customizing das zu machen, was die Unternehmen wirklich benötigen.

No Code Solutions: SharePoint ermöglicht durch seine Architektur die einfache Ergänzung des Systems durch käufliche Bausteine (Web Parts), ganz ohne Programmierung. Mit dem SharePoint Designer können Poweruser viele Aufgabenstellungen auch ohne IT-Support umsetzen, zum Beispiel die Einbindung von Web Services, die zum Teil kostenlos nützliche Daten wie IBAN-Codes oder die Postleitzahl liefern. Drittanbieterlösungen bilden auch komplexe Themen elegant und günstig ab, zum Beispiel SAP-2-SharePoint-Szenarien von Sitrion, Workflowmanagement von NINTEX etc.

Out of the Box: Wer mit SharePoint die ersten Schritte gemacht hat, erkennt schnell, dass man trotz guter und flexibler Bordmittel bald an Grenzen stößt, wenn man mehr als ein wenig Dokumentenablage und Listenverwaltung nutzen möchte. Dennoch sind die erzielbaren Ergebnisse meist besser als der Zustand ohne SharePoint; und durch Ihre Einfachheit und die Möglichkeiten, dem Fachbereich Ad-hoc-Konfiguration ohne IT-Support zu bieten, auch beliebt.

SharePoint Designer und InfoPath: Abhilfe bei Mängeln schafft der kostenlose SharePoint Designer oder auch InfoPath. Die erzielbaren Ergebnisse reichen überraschend weit, erfordern im Detail aber bereits gute Planung, mindestens den Einsatz einer Scripting-Sprache und die Einbindung der IT und entsprechende Policies und IT-Governance.

Web Services und Feeds: Die Anbindung externer Dienste ist einfach und erspart die Mühe, selbst die Datenbereitstellung zu organisieren. Ohne Servicevertrag sollte man sich jedoch auf die angezapften Daten nicht verlassen, denn unerwartete Änderungen an der Quelle bringen bisher funktionierende Anwendungen schnell zum Erliegen.

Web Parts: Web Parts von Drittanbietern sind oft eine willkommene Abhilfe für fehlende Funktionen in SharePoint und es gibt einige Produkte, um schneller zum Ziel zu kommen. Die Kosten sind meist gering, in den meisten Fällen sogar wesentlich geringer als die Kosten einer Eigenentwicklung. Bei komplexeren Web Parts stecken aber nicht selten Bedienkonzepte, vorgedachte Abläufe oder Oberflächendesigns unter der Haube, die dann im Puzzlekasten der zugekauften Web Parts nicht gut in die vorhandenen Konzepte und Philosophien passen. Das stört nicht nur beim Datenaustausch, sondern besonders bei der konsistenten Bereitstellung von Benutzeroberflächen und bei automatisierten Tests.

Man kann jeden der genannten Wege einschlagen, sie müssen in der Praxis aber auch zusammen funktionieren: Sie müssen orchestriert, integriert und getestet, überwacht, erlernt oder geschult werden, um stabil, performant und verständlich mit durchgängigen Bedienkonzepten zu funktionieren. Man benötigt also eine gut funktionierende Organisation, strenge Governance und sehr gute Mitarbeiter mit viel Überblick, um die Vorteile nutzen zu können. Aber das schreit eher nach einem alternativen Konzept. Ist vielleicht doch Entwicklung die Lösung?

Customizing doch mit Entwicklung?

Früher oder später kommt man also zur Entwicklung mit Visual Studio, und Entwicklung mit SharePoint ist komplex. Die Bandbreite nötiger Kompetenzen ist groß, denn SharePoint-Entwicklung fordert ein Gesamtverständnis nahezu aller Plattform- und Office-Komponenten, gute Kenntnisse der Security- und Administrationskonzepte der Plattform und noch vieles mehr. „Normale“ Entwickler, die es gewohnt sind, eher funktionale Aspekte von Anwendungen umzusetzen, kapitulieren schnell vor diesem Aufwand. Nicht umsonst ist der SharePoint-Entwicklermarkt ein Paradies für Headhunter.

Entwicklung liefert zwar maximale Flexibilität, ist aber auch mit zahlreichen Schwierigkeiten verbunden. Und die End-User-Flexibilität ist auch auf einmal weg, wenn man konkrete Anwendungen baut. Deshalb stellen sich Unternehmen nicht selten die Frage, weshalb man dann nicht gleich bei den bisherigen Entwicklungsframeworks (z. B. Java) bleiben sollte. Es muss also bessere Wege zu Businessanwendungen für SharePoint geben.

Konfigurationsframeworks könnten ein guter Ansatz sein. Ziel eines Konfigurationsframeworks ist es, die End-User-Flexibilität von SharePoint auch beim Design komplexer Anwendungen so weit wie nur denkbar beizubehalten. Ein Konfigurationsframework liefert dabei nicht einfach ein paar funktionale Web Parts, sondern ergänzt SharePoint in seinen generischen Fähigkeiten an den Stellen, an denen SharePoint für den vom Framework adressierten Zweck Schwächen aufweist. Das Ergebnis ist dann immer noch SharePoint, nur besser. Anhand des BPA xRM Frameworks von BPA Solutions [1] soll an Beispielen gezeigt werden, was das in der Praxis bedeutet.

BPA xRM

BPA xRM liefert als Framework Ergänzungen zu SharePoint, die heute für die Gestaltung von Business- oder PM-Anwendungen fehlen. Der Kunde kauft jedoch keinen technischen Baukasten, sondern fertige Standardanwendungen, die mit der Installation auch das Framework mitbringen. Das Framework sorgt dafür, dass bei der Neuerfassung von Daten alle sinnvollen Kontextinformationen bereits ausgefüllt sind, sodass nur neue Informationen erfasst werden müssen. Grundsätzlich können Daten im Kontext einer 360°-Sicht angezeigt und bearbeitet werden. Im einfachsten Fall kauft der Kunde also das CRM oder PM und ist mit der Funktion zufrieden. Die Anwendungen sind funktional vollständig und decken in vielen Fällen die Wünsche der Kunden ab. Dank SharePoint sind als Betriebsmodelle SaaS, Cloud, ein eigenes DataCenter oder ein Mix davon möglich und durch das Framework weit über SharePoint-Standards hinaus kombinierbar. Das erleichtert das Umsetzen typischer Projekt- oder CRM-Anforderungen, zum Beispiel eine vollständige interne Projektplattform, eine reduzierte Projektplattform für Fremdmitarbeiter im Extranet und ein in der Cloud stehendes Serviceportal für Serviceanfragen.

Der konzeptionelle Unterschied zu den zuvor besprochenen Customizing-Ansätzen ist auf Basis eines Konfigurationsframeworks erheblich: Im Gegensatz zu klassischen Businessanwendungen erzeugt der Anpassungsbedarf keine Panik, sondern Aufbruchstimmung. Denn genau dafür werden solche Frameworks gebaut: Fachliche Anpassungen sollen zeitnah auch im System durch geschulte Konfiguratoren ohne IT-Unterstützung abgebildet werden können. Typische Anpassungsprojekte belaufen sich eher auf Stunden und Tage als auf Wochen und Monate, dabei kann die Konfiguration vollständig empirisch erfolgen. Man kann also einfach mal etwas ausprobieren, ohne dabei irgendetwas anderes zu beeinflussen. Was sich unglaublich anhört, ist einfach zu erklären:

  • Konfigurationen laufen vollständig innerhalb des bereits installierten Frameworks und SharePoint ab. Technische Deployments mit allen Konsequenzen entfallen völlig.
  • Die Praxis zeigt, dass etwa 90 Prozent aller Anforderungen immer die gleichen generischen Fähigkeiten im Framework erfordern.

Neben positiven Seiteneffekten des Frameworks kommen durchgängige Bedienkonzepte über verschiedene Anwendungen und Prozesse hinweg, Reduktion der Komplexität durch Wegfall der Programmierung, kurze Umsetzungs- und Einführungszeiten und eine technisch bedingte Compliance in der Anwendungsentwicklung hinzu, da alle Anwendungen mit den selben bereitgestellten Konzepten umgesetzt werden. Einmal geschulte Konfiguratoren können überall eingesetzt werden, Anwender verstehen intuitiv die Bedienkonzepte auch in anderen Geschäftsbereichen. Die dadurch geschaffene Entlastung ermöglicht der IT die Konzentration auf Betriebsaspekte, Datenquellen und Governance.

Wer SharePoint wirklich produktiv einsetzen möchte, ob für Businessanwendungen oder andere Zwecke, der profitiert in jedem Fall von einem Konfigurationsframework. Echte Haken im Sinne von „Vorsichtig Benutzer!“ haben Konfigurationsframeworks unserer Erfahrung nach nicht, denn Sie ergänzen und verbessern lediglich vorhandene Möglichkeiten in SharePoint. Einiges sollte jedoch vor dem Einsatz eines Konfigurationsframeworks berücksichtigt werden:

  • Der Einsatzzweck von Frameworks ist nicht beliebig, die Auswahl des Frameworks muss gezielt nach Zweck getroffen werden.
  • Ohne Schulung von Konfiguratoren sind keine Ergebnisse zu erwarten.
  • Bereitschaft zu konzeptionellen Innovationen hilft.
  • Sofort starten ist gut, aber es sollte ein langfristiger Einsatz des Frameworks geplant sein.
  • Der Start über Anwendungs-Templates garantiert Erfolg von Beginn an, ohne gleich ein vollständiges, neues Universum modellieren zu müssen.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -