Business-Analyse

Sehr gebräuchliche Techniken der Ermittlung von Anforderungen sind Workshops und Interviews. Daneben gibt es weitere bewährte Werkzeuge, die Business-Analysten nutzen können; sie werden in Kapitel 2.3 vorgestellt.

Im Zuge der Anforderungsermittlung werden neben den Anforderungen auch geschäftliche und technische Restriktionen erhoben. Sie sind wichtige Bestandteile für das zu erstellende Anforderungsdokument, sollten aber getrennt von den Anforderungen dokumentiert werden. Die Unterscheidung zwischen Anforderungen und Restriktionen ist nicht immer trennscharf und bedarf daher in vielen Fällen einer Analyse durch die Business-Analysten. Anforderungen beschreiben die zu erstellende Lösung. Sie beziehen sich in vielen Fällen auf eine gewünschte Funktionalität einer Lösung. Restriktionen schränken die Möglichkeiten, eine Lösung zu erstellen, ein oder erzwingen bestimmte Lösungsbestandteile. Eine technische Restriktion kann zum Beispiel sein, dass die Lösung auf einer vorgegebenen technologischen oder IT-Plattform zu entwickeln ist. Eine typische geschäftliche Restriktion erzwingt, dass gesetzliche Bestimmungen einzuhalten sind.

Anforderungspriorisierung

Selbst bei einer vergleichsweise groben Ermittlung der Anforderungen treten in der Regel mehrere Anforderungen zutage. Grundsätzlich besteht natürlich die Möglichkeit, mit allen erhobenen Anforderungen in die weitere Analyse einzusteigen. Manchmal ist es aber besser, erst zu klären, ob alle den gleichen Stellenwert haben oder einige Anforderungen erst einmal zurückgestellt werden.

Agile Vorgehensmodelle setzen per se darauf, nicht gleich alle Anforderungen umzusetzen, sondern schrittweise Teilergebnisse zu produzieren. Dazu werden Anforderungen immer wieder priorisiert, um die wichtigsten und dringlichsten Anforderungen zeitnah zu analysieren und umzusetzen. Zentrales Kriterium der Priorisierung ist in aller Regel der Wert beziehungsweise der Mehrwert für den Kunden. Auch bei klassischen, stufenweisen Vorgehensmodellen fordert das Grundprinzip des rationalen Entscheidens, auf die Anforderungen zu fokussieren, die eine höhere Priorität besitzen als andere.

Unabhängig vom Vorgehensmodell übersteigen normalerweise die Wünsche und Bedürfnisse der Anforderungssteller die vorhandenen Kapazitäten für deren Umsetzung. Daher ist es sinnvoll, „die Spreu vom Weizen zu trennen“ und sich besonders um die Anforderungen zu kümmern, deren Umsetzung am wahrscheinlichsten und sinnvollsten ist, bevor die Anforderungen weiter detailliert und dokumentiert werden. Dazu legen Business-Analysten zusammen mit den Stakeholdern Priorisierungskriterien fest. Zur Priorisierung der Anforderungen können eine oder mehrere Techniken eingesetzt werden (Kapitel 2.4). Ergebnis der Anforderungspriorisierung ist ein klareres Bild, welche Anforderungen zu diesem Zeitpunkt zurückgestellt werden können und welche weiteranalysiert werden sollen.

Strukturierung, Spezifizierung, Modellierung

Business-Analysten stehen verschiedene Techniken zur Dokumentation von Anforderungen zur Verfügung. Grundsätzlich kann unterschieden werden zwischen textlicher Dokumentation von Anforderungen (Spezifizierung) und der Dokumentation von Anforderungen mittels Grafiken beziehungsweise Modellen (Modellierung).

Strukturierung ist die Wahl des passenden Werkzeugs oder eines sinnvollen Mix von Dokumentationstechniken und die Zusammenstellung der „richtigen“ Anforderungen für die Spezifizierung und Modellierung.

Während in der Praxis häufig Anforderungen freihändig in Textform dokumentiert werden, werden in Kapitel 2.6 die Vorteile einer systematischen textlichen Form aufgezeigt. Im darauffolgenden Kapitel 2.7 werden dann standardisierte Modellierungstechniken erläutert, die sich für die Dokumentation von Anforderungen besonders eignen.

Verifizierung, Validierung

Grundsätzlich sollten erhobene und dokumentierte Anforderungen geprüft werden. Fehler im Anforderungsdokument können sich ansonsten bis in die Lösung fortsetzen.

Verifizierung ist die formale Überprüfung von Anforderungen auf Fehler, Redundanzen, Lücken und Widersprüche. Im Sinne des Vier-Augen-Prinzips sollte idealerweise nicht allein der Autor des Anforderungsdokuments die Anforderungen überprüfen. Grundsätzlich können das auch die Stakeholder tun. Es hat sich bewährt, dass ein oder mehrere weitere Business-Analysten (sogenannte Peers) die Verifizierung übernehmen. Da hier die rein formale Überprüfung der Anforderungen im Vordergrund steht, benötigen die Prüfer in den meisten Fällen keine detaillierten fachlichen oder inhaltlichen Kenntnisse. Ganz im Gegenteil kann ein neutraler (nicht „betriebsblinder“) Blick sogar sehr hilfreich sein.

Validierung ist die Überprüfung der Anforderungen dahingehend, ob sie zielgerichtet sind. Business-Analysten sollten einerseits prüfen, dass keine übertriebenen Anforderungen eingebracht werden (Goldrandlösung). Andererseits überprüfen sie, ob die Ziele mit den Anforderungen voraussichtlich erreicht werden können. Die Validierung führt die Geschäftsanforderungen, die das „Warum“ und damit die erwünschten Wirkungen beschreiben, mit den Stakeholder-Anforderungen und Lösungsanforderungen zusammen, die den Weg zum Ziel beschreiben („Was“ und „Wie“).

Genehmigung

Genehmigung ist die formale oder informale Abnahme der dokumentierten Anforderungen für die weiteren Schritte, insbesondere für die Umsetzung. Business-Analysten haben in den seltensten Fällen das Recht, selbst Anforderungen zu genehmigen. In klassischen Vorgehensmodellen genehmigt das Gremium (zum Beispiel Lenkungsausschuss) oder die Person (zum Beispiel Sponsor), die dem Projekt vorsteht. In agilen Vorgehensmodellen wird die Genehmigung meistens durch eine Rolle durchgeführt; in Scrum zum Beispiel durch den Product Owner.

Anforderungsmanagement

Im Laufe der Business-Analyse werden in der Regel viele Anforderungen ermittelt und weiter analysiert. Es ist sinnvoll, diese Anforderungen über deren gesamten Lebenszyklus hinweg zu verwalten, sodass sie genutzt, gepflegt und bei Bedarf weiterverwendet werden können.

Handlungsfelder

Als berufliche Handlungskompetenz hilft Business-Analysten Teamarbeit und Konfliktmanagement. Viele Aufgaben im Requirements Engineering werden gemeinsam angegangen, beispielsweise in Workshops. Wenn dabei Anforderungen und Interessen nicht übereinstimmen, können schnell Konflikte entstehen. Dann sind Kenntnisse im Konfliktmanagement hilfreich.

Die Stakeholder – also diejenigen, die ein eigenes Interesse an der Lösung haben – sind eine wichtige Zielgruppe, da deren Anforderungen zu ermitteln, zu priorisieren und zu genehmigen sind. Ihre Beteiligung und Einbindung in die Business-Analyse entscheidet in vielen Veränderungen über den Erfolg und die Akzeptanz der zu entwickelnden Lösung.

Alle Schritte im Konzept des Requirements Engineering schlagen sich im Ergebnistyp Anforderungsdokument nieder. Abhängig vom Lösungsumfang und Lösungsansatz und auch abhängig vom Vorgehensmodell und den Standards im Unternehmen können diese Dokumente unterschiedlich strukturiert und unterschiedlich umfangreich sein. In agilen Vorgehensmodellen entsteht möglicherweise kein Anforderungsdokument im herkömmlichen Sinne, sondern die Anforderungen sind wenig strukturiert und wenig detailliert dokumentiert, zum Beispiel in Form von physischen Boards (etwa auf Pinnwänden) oder mithilfe entsprechender Tools auf elektronischen Boards.

Eine ausführliche Beschreibung des Konzepts Requirements Engineering findet sich in Kapitel 2.

G.3.4 Lösungseinführung

Abb. G.10: Lösungseinführung

„Papier ist geduldig, der Leser nicht.“

Von Unbekannt

Mit dem Konzept Business-Case-Erstellung wird eine Veränderung vorbereitet und u.a. auf Sinnhaftigkeit und Wirtschaftlichkeit untersucht. Requirements Engineering liefert als Ergebnistyp ein Anforderungsdokument. Beide Konzepte beschäftigen sich mit dem zentralen Anliegen der Business-Analyse, Anforderungen zu ermitteln und zu dokumentieren, die eine Lösung und damit eine Veränderung der Ist-Situation beschreiben.

Die Umsetzung dieser Anforderungen ist nicht mehr Bestandteil der Business-Analyse. Abhängig von der Art der beschriebenen Lösung setzen andere Rollen diese um. In vielen Fällen entwickeln Mitarbeiterinnen und Mitarbeiter der IT-Abteilung entsprechende Applikationen, Systeme sowie Infrastruktur und sorgen dafür, dass sie bereitgestellt werden.

Business-Analysten spielen eine wichtige Rolle auf dem „Hinweg“, dem Weg der Anforderungen von den Anforderungsstellern zu den Umsetzern. Es erscheint logisch und sinnvoll, dass Business-Analysten auch den „Rückweg“ begleiten sollten, den Weg der entwickelten/umgesetzten Lösung von der IT-Abteilung zu den Anforderungsstellern bzw. Nutzern dieser Lösung.

Das Konzept der Lösungseinführung in der ibo-Anforderungstür® beschreibt Aspekte, bei denen Business-Analysten sinnvoll zum Einsatz kommen, da sie mindestens mit den Anforderungen und häufig auch mit der Lösung vertraut sind.

So sollte durch die Bewertung der Lösung untersucht werden, ob die Lösung die Verbesserungen erbringt, die über die Geschäftsanforderungen im Business Case definiert wurden. Eine anschließende bzw. fortlaufende Leistungsüberprüfung stellt sicher, dass die Lösung auch künftig einen (Mehr-)Wert erbringt.

Eine Ermittlung, Dokumentation und Umsetzung von Transitionsanforderungen, die den Übergang vom Ist- zum Soll-Zustand beschreiben, erleichtert die Einführung der Lösung. Dazu gehören insbesondere Überlegungen,

 wie mit Daten im Ist (bzw. in den Altsystemen) umgegangen wird, z.B. Migration auf die neue Lösung

 welche organisatorischen Veränderungen der Betroffenen und Beteiligten sinnvoll und notwendig sind, z.B. Information oder Schulungen

 wie Aufgaben, Geschäftsvorfälle und Geschäftsprozesse fortgeführt werden, die im Ist (bzw. in den Altsystemen) begonnen wurden, aber vor Lösungseinführung nicht beendet wurden.

In vielen Unternehmen reichen die Umsetzungskapazitäten nicht aus, um alle Anforderungen zeitnah zu realisieren. Business-Analysten können durch eine Zuordnung von Anforderungen zu Releases dabei mitwirken, gezielt Mehrwert zu schaffen, auch wenn nicht alle Anforderungen „sofort“ umgesetzt werden können oder sollen.

Mit der Einführung der Lösung verschieben sich häufig die Verantwortlichkeiten. Personen, die für die Entwicklung der Lösung verantwortlich waren, haben ihren Beitrag geleistet. Wurde die Lösung im Rahmen eines Projekts entwickelt, so neigt sich dieses dem Ende entgegen oder wurde beendet und der Projektleiter trägt (künftig) keine Verantwortung mehr. Dennoch ist immer sicherzustellen, dass der Betrieb der Lösung technisch verantwortet und weiter begleitet wird. Dieser Übergang von „Build“ to „Run“ funktioniert in vielen IT-Bereichen gut oder ist zumindest hinreichend geregelt. Die Übernahme von Verantwortung auf fachlicher Seite ist nicht immer gleich gut geregelt. Business-Analysten unterstützen eine möglichst reibungslose Einführung und ein klares Rollenverständnis, indem sie beispielsweise Prozessverantwortliche oder Fachbereichsleiter darauf hinweisen, dass „jemand den Hut aufhaben“ sollte.

Handlungsfelder

Als berufliche Handlungskompetenz hilft Business-Analysten Change Management, um Veränderungen auch kulturell zu begleiten.

Wichtige Zielgruppe sind Beteiligte, die mit der neuen oder veränderten Lösung umgehen müssen.

Ergebnistyp dieses Konzepts ist eine Lösung, die erfolgreich eingeführt und weiter begleitet wird.

Eine ausführliche Beschreibung des Konzepts Lösungseinführung findet sich in Kapitel 3.

G.3.5 Business-Analyse-Planung und -Steuerung

Die drei Konzepte Business-Case-Erstellung, Requirements Engineering und Lösungseinführung der ibo-Anforderungstür® bilden eine sinnvolle Reihenfolge, um den Grundprinzipien „Vom Groben zum Detail“, „Von den Zielen zur Lösung“ und „Rationales Entscheiden“ zu folgen.

Abb. G.11: Business-Analyse-Planung und -Steuerung

Das Konzept Business-Analyse-Planung und -Steuerung „begleitet“ die anderen drei Konzepte und soll sicherstellen, dass die Business-Analyse selbst effektiv und effizient durchgeführt wird. Dies gilt für Business-Analysten, die alleine eine Veränderung begleiten, ebenso wie für ein Team von Business-Analysten, das zum Beispiel in einem Projekt zusammenarbeitet.

  Planung ist die geistige Vorwegnahme zukünftigen Handelns. In diesem Sinne strukturieren Business-Analysten ihre künftigen Tätigkeiten und stimmen deren Umfang und Inhalt ab.

  Ist-Erfassung ermittelt den Status und Fortschritt der Tätigkeiten, abhängig von der Planung hinsichtlich Leistung, Qualität und Termin.

  Diagnose prüft, ob es Abweichungen zwischen Ist-Werten und Plan-Werten gibt. Bei Abweichungen suchen Business-Analysten in diesem Schritt nach Ursachen und Zusammenhängen.

 Steuerung ergreift Maßnahmen, um bei einer festgestellten Abweichung mögliche Nachteile zu minimieren. Bei kritischen Abweichungen ist möglicherweise eine Eskalation an Führungskraft oder Projektleiter der Business-Analysten notwendig. In jedem Fall sollten Business-Analysten Lessons Learned betreiben, d.h. aus „der Vergangenheit lernen“, Bewährtes für weitere Business-Analysen standardisieren und begangene Fehler für die Zukunft vermeiden.

Die Planung der Business-Analyse umfasst die drei Komponenten Stakeholder-Analyse, Aufgaben und Anforderungsmanagement.

Stakeholder-Analyse

In der Stakeholder-Analyse klären Business-Analysten, wer durch eine Veränderung betroffen ist, wer auf sie Einfluss nimmt und welche Stakeholder für die Business-Analyse zu berücksichtigen sind. Die beste, technisch umgesetzte Veränderung droht an mangelnder Akzeptanz zu scheitern, wenn Personen sich übergangen fühlen, nicht ausreichend berücksichtigt wurden oder ihre Anforderungen nicht einbringen konnten.

Aufgaben

Die Planung der Aufgaben unterscheidet sich je nach dem gewählten Vorgehensmodell. In klassischen Vorgehensmodellen (z.B. Projekte nach Wasserfallprinzip) werden die künftigen Aufgaben der Business-Analyse vergleichsweise ausführlich vorab geplant, indem die Inhalte der Aufgaben beschrieben, Dauer und Termine festgelegt werden. Häufig wird die Planung formal abgenommen und später auch formal überprüft.

In agilen Vorgehensmodellen wird in der Regel lediglich die anstehende Iteration fein geplant. Weitere Iterationen werden umso gröber geplant, je weiter sie in der Zukunft liegen.

Anforderungsmanagement

Die Planung des Anforderungsmanagements umfasst unter anderem Überlegungen, in welchen Dokumenten Anforderungen hinterlegt werden und welche Software-Tools zur Verwaltung der Anforderungen genutzt werden. Sinnvollerweise planen Business-Analysten auch vorab, welche Attribute sie neben der eigentlichen Anforderung erfassen und verwalten wollen. Häufig genutzte Attribute sind eine eindeutige ID, Angaben zur Quelle der Anforderung, zum Versionsverlauf, zum Autor, zum Status der Anforderung.

Die Verfolgbarkeit (Traceability) der Anforderungen erfasst ihren Lebenszyklus, von ihrem Entstehen bis zu ihrem Ende (z.B. durch Umsetzung und Archivierung). Business-Analysten können die Verfolgbarkeit von Anforderungen unterschiedlich intensiv betreiben. Daher sollten sie vorab planen, in welcher „Ausbaustufe“ sie Traceability durchführen wollen.

Weiter ist festzulegen, wie mit Änderungen von Anforderungen umgegangen werden soll. Während agile Vorgehensmodelle eine Veränderung von vornherein vorsehen und akzeptieren, findet im Rahmen klassischer Vorgehensmodelle häufig ein explizites IT-Change-Management statt. In der Planung des IT-Change-Managements wird unter anderem festgelegt, wie über Änderungen entschieden wird und wie Anforderungen formal geändert werden (z.B. Prozess mit Change Request).

Ist-Erfassung

Die Ist-Erfassung ermittelt und dokumentiert Kennzahlen für eine effiziente und effektive Performance der Business-Analyse. Dies können z.B. Termine, Änderungshäufigkeit der Anforderungen, Anzahl benötigter Review-Zyklen für Anforderungsdokumente sein.

Diagnose

Die Diagnose vergleicht die Werte der Planung mit den Ergebnissen der Ist-Erfassung. Typische Fragen insbesondere bei Abweichungen sind:

 Wie war das Vorgehen?

 Wo bestehen Probleme in der Business-Analyse?

 Wo liegen Chancen für Verbesserungen?

Steuerung

Die Steuerung greift in die aktuelle Business-Analyse ein, um ungewollten Abweichungen von der Planung zu begegnen. Dazu ergreifen Business-Analysten korrigierende Maßnahmen, um sicherzustellen, dass Leistung, Qualität und Termine eingehalten werden.

Vorbeugende Maßnahmen mindern bei künftigen Abweichungen deren Eintrittswahrscheinlichkeit oder deren negative Auswirkung. Schließlich wird durch eine kontinuierliche Verbesserung der Business-Analyse das Vorgehen beziehungsweise der Geschäftsprozess der Business-Analyse aktualisiert.

In der Praxis sind die Schritte Ist-Erfassung, Diagnose und Steuerung kaum voneinander zu trennen. Zudem unterstützen viele Techniken gleichzeitig alle drei Schritte. Daher werden diese drei Schritte in Kapitel 4 eng miteinander verknüpft. Dort findet sich eine ausführliche Beschreibung des Konzepts Business-Analyse-Planung und -Steuerung.

G.4 Rollen und Stellen in der Business-Analyse

In diesem einleitenden Kapitel soll ein Überblick über die verschiedenen Bezeichnungen der Personen gegeben werden, die mit Anforderungen befasst sind. Anders als zum Beispiel im Projektmanagement wurden die Rollen- und Stellenbezeichnungen in der Business-Analyse (noch) nicht vereinheitlicht.

Ein Business-Analyst ist jede Person, die Aufgaben der Business-Analyse ausführt.

Die Definition berücksichtigt,

 dass Business-Analyse aus Aufgaben mit unterschiedlicher „Flughöhe“ besteht (eher strategischer, taktischer oder operativer Natur)

 dass diese Aufgaben in unterschiedlichen Themenfeldern anfallen, z.B. Automatisierung oder Geschäftsprozessoptimierung

 dass Business-Analyse in unterschiedlichen Kontexten stattfindet, in agilen oder klassischen Projekten, Veränderungsmaßnahmen großen oder mittleren Ausmaßes oder in kleinen Veränderungen im Tagesgeschäft.

Neben der weit verbreiteten Stellenbezeichnung „Business-Analyst“ gibt es weitere Rollen und Stellen, die verwandte Aufgaben rund um Anforderungen wahrnehmen bzw. die in eine Business-Analyse einbezogen werden. Die Abbildung nennt gebräuchliche Bezeichnungen dieser Personen.

Abb. G.12: Rollen und Stellen in der Business-Analyse

Rund um Anforderungen lassen sich zwei Personengruppen unterscheiden:

  Spezialisten, die sich hauptsächlich mit Anforderungen beschäftigen. „Business-Analyst“ ist hierbei eine verbreitete Stellenbezeichnung und wird im weiteren Verlauf des Buches verwendet. Darüber hinaus gibt es noch andere Bezeichnungen für Spezialisten rund um Anforderungen (vgl. linke Spalte der Abbildung G.12).

 Daneben gibt es Personen, die sich als Betroffene/Beteiligte einen Teil ihrer Arbeitszeit mit Anforderungen beschäftigen, sei es in Projekten oder im Tagesgeschäft (vgl. mittleren und rechten Teil der Abbildung G.12).

Die Aufgaben dieser Personen und ihre Verknüpfung zur Business-Analyse werden insbesondere in den Kapiteln 1 bis 4 erläutert. Die Schwerpunkte einiger Rollen werden im Folgenden skizziert.

Business-Case-Erstellung

Bei der Erstellung eines Business Case werden beispielsweise Unternehmensarchitekten oder Business-Planer tätig, die die Verträglichkeit von Lösungsansätzen und -ideen mit Architekturentscheidungen und -vorgaben des Unternehmens abgleichen. Multiprojekt- und Portfoliomanager prüfen, ob verwandte oder widersprüchliche Lösungsansätze vorhanden sind. Sie fügen nach einem erfolgreichen Business Case das Veränderungsvorhaben in das Portfolio aller Vorhaben ein, indem sie es zeitlich und inhaltlich einordnen. Produktmanager entwickeln Vorschläge, wie bestehende Produkte weiterentwickelt oder neue Produkte bzw. Dienstleistungen geschaffen werden sollen.

In plan-orientierten Vorgehensmodellen (z.B. nach Wasserfall) entscheidet ein Bewilligungsgremium oder Architektur-Board über den Business Case. In wandel-getriebenen (agilen) Vorgehensmodellen liegt diese Kompetenz z.B. beim Product Owner (als zentrale Rolle in Scrum).

Requirements Engineering

Je nach Unternehmen und Branche wird anstelle von Business-Analyst eine der anderen Bezeichnungen genutzt, wie z.B. Requirements Engineer, Anforderungsmanager, Systemanalytiker, IT-Koordinator, IT-Organisator. Unternehmen, die sich nach ITIL ausrichten, setzen häufig Demand Manager ein, die Anforderungen aufnehmen und dokumentieren.

In klassischen Projekten entscheidet ein Lenkungsausschuss oder ein Steering Committee über das Projekt im Allgemeinen und das Anforderungsdokument im Besonderen. In agilen Vorgehen bearbeitet ein Entwicklungsteam die Anforderungen und wird dabei von einem Scrum Master methodisch unterstützt.

Lösungseinführung

Bei der Lösungseinführung wird das Ergebnis des Vorhabens in die Linie bzw. in das Tagesgeschäft übergeben. Für prozessorientiert gegliederte Unternehmen spielen die Prozessverantwortlichen eine zentrale Rolle.

Sind mehrere Business-Analysten in einem Unternehmen tätig, müssen sie als Gruppe oder Team organisiert werden. Dabei können formal feste Rollen wie Senior-Business-Analyst oder Lead-Business-Analyst geschaffen werden. Es kann auch ein Business-Analyse-Center-of-Excellence oder Business-Analyse-Office eingerichtet werden, in dem die Mitarbeiter der Business-Analyse zusammengeführt werden. Ein solches Center of Excellence dient dann auch dem Informationsaustausch, dort werden Lessons Learned gezielt genutzt und es wird die Business-Analyse im Unternehmen weiterentwickelt.

Literatur zu Kapitel G

Carkenord, B. A.: Seven Steps to Mastering Business Analysis. Plantation 2009

International Institute of Business Analysis (IIBA): A Guide to the Business Analysis Body of Knowledge (Babok Guide). Version 3.0, Toronto 2015

International Institute of Business Analysis (IIBA): Business Analysis Body of Knowledge® – BABOK 2.0®. Leitfaden zur Business Analysis. 1. Aufl. in deutsch, Gießen 2012

Paul, D.; Yeates, D.; Cadle, J. (Editors): Business Analysis. 3rd Edition, London 2014

Podeswa, H.: The Business Analyst's Handbook. Boston 2008

Robertson, S.; Robertson, J.: Mastering the Requirements Process. 3rd Edition, Upper Saddle River 2012

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.