Ziel

Wir wollen die Angebotserfassung vereinfachen, straffen, auswertbar und konfigurierbar machen. Datenstrukturen sollen einfach und logisch sein. Das Modell soll erweiterbar sein.

Mindest-Fragen, die einfach und nachvollziehbar beantwortet werden sollen:

  • wie hoch ist das Volumen der aktuell offenen Angebote?
  • wie ist die Wandlungsquote für das Produkt X?
  • welche Angebote sind letzten Monat ausgelaufen?
  • welche Angebote hat Kunde Y offen?

Wir haben 3 verschiedene Ansätze diskutiert:

1. der Queue-Ansatz

Beim Schreiben eines Angebots oder beim Versenden von Produktunterlagen wird ein Queue-Satz geschrieben, die zumindest die folgenden Werte enthält:

Deadline, Amount, Status, Offerdate

Wenn mehr als nur diese Felder verwendet werden sollen (-> komplexes Angebot), dann wird ein CRM_ORDER mit CRM_ORDERPOSsen geschrieben. An dem Order steht dann die process_queue_id von dem Angebots-Queue-Satz.

Vorteile

  • Angebote landen „automatisch“ in der Wiedervorlage
  • keine doppelte Datenhaltung für „einfache“ Angebote, weil alles am Queue steht
  • Erfassung super-einfach

Nachteile

  • zusätzliche Felder am Queue-Satz
  • Problematik des an-den-Kopfsatz-schreiben
  • aufwändigeres Lesen bei Statistiken (zumindest wenn Werte abgefragt werden, die nur im CRM_ORDER stehen wie z.B. CODE1)

 

2. der Order-Ansatz

Beim Schreiben eines Angebots wird ein Order-Satz mit Orderpos erzeugt (der gleiche, der im obigen Fall bei komplexen Angeboten auch geschrieben würde).

Vorteile

  • einheitliche Datenhaltung (alle Angebote sind CRM_ORDER mit Type xyz)
  • alle benötigten Felder gibt’s schon in CRM_ORDER
  • Angebotsdruck und -Verwaltung stets über eine Datenstruktur, keine Unterscheidung zwischen „einfachen“ und „komplexen“ Angeboten

Nachteile

  • Angebot ist nicht automatisch WV
  • aufwändigere Datenstruktur für „einfache“ Angebote

3. der Angebots (log) Satz

Grundgedanke: Ein Angebot ist ein zeitlich feststehendes Ereignis (createtime) mit einem fest forgegebenen Ablaufdatum (deadline) und einem Status. Ein komplexes Angebot (Mediapaket als CRM-Order) kann mehrfach in verschiedenen Versionen unterbreitet werden. Statistisch gesehen müssen – obwohl es inhaltlich der gleiche CRM-Ordersatz ist – diese Angebote als historische Ereignisse festgehalten und natürlich bewertet werden. Die heutigen Queue- und Queuelogsätze könnten das, haben aber eine Komplexität und Spezialisierung erreicht, die man nicht um einen weiteren Aspekt (Angebote) vergrößern will.
Ansatz daher eine eigene Tabelle CRM_OFFERLOG in der „nur“ der Angebotslebenszyklus  abgebildet wird und abgefragt werden kann.
Felder:
createtime: Angebotsdatum,
deadline: Ablaufdatum,

statuscode1: Open, Expired, Accepted,Rejected

statuscode2: bei Expired: Expired, bei Rejected: Ablehnungsgrund

amount: numerisch
orderedamount: numerisch
address_id: Pflichtfeld zeigt auf GP
ap_id: optional zeigt auf Ansprechpartner,
queue_id: optional (entweder queue oder order oder beides)
order_id: optional (entweder queue oder order oder beides)
sales_opportunity_id: optional
owner_app_user_id: „Eigentümer“ des Angebots, HV
code1…6: für statistische Auswertungen
documentdata: für alles weitere

Automatik

Egal mit welcher Speicher-Methode: es muss eine Funktion / Batch geben, die abgelaufene Angebote auf Expired setzt.

Stati

Die folgenden Angebotsstati werden benötigt:

Rejected, Open, Expired, Accepted

 

Festlegung der Vorgänge anhand der Beispielauswertungen

 

wie hoch ist das Volumen der aktuell offenen Angebote?

select sum(amount) from CRM_OFFERLOG where statuscode1=’Open‘

 

wie ist die Wandlungsquote für das Produkt X?

Für Wandlungsquote = Auftragsvolumen für Produkt X / erstelltes Angebotsvolumen für Produkt X

Auftragsvolumen für Produkt X: select sum(orderamount) from CRM_OFFERLOG where statuscode1=’Accepted‘ and sales_opportunity_id=’x‘

Angebotsvolumen für Produkt X: Achtung nicht direkt bekannt weil der statuscode1 ja wechselt – wenn man aber annimmt, dass alles irgendwann mal angeboten wurde:

select sum(amount) from CRM_OFFERLOG where sales_opportunity_id=’x‘

 

welche Angebote sind letzten Monat ausgelaufen?

select * from CRM_OFFERLOG where deadline between monatstart and monatsende and statuscode1 = ‚Expired‘

 

welche Angebote hat Kunde Y offen?

select * from CRM_OFFERLOG where statuscod1=’Open‘ and address_id =’y‘

 

Bonusfragen:

wie hoch ist die Wandlungsquote je Monat (Rückschau)

s. o. group by month(deadline)

wie hoch ist das Volumen der erstellten Angebote je Monat (Rückschau)

s. o group by month(deadline)

 

Offene Fragen:

Möchte man wissen, wie viele Angebotsvarianten/Nachbesserungen an einem Angebot erfolgt sind und wie sich die Angebotssumme geändert hat?

Ist es interessant, Terminverschiebungen (deadline) zu verfolgen bzw. welche Auswirkungen haben diese auf die Auswertungen?

 

(nur mit Buchungsjournal einfach zu beantworten)

welche Angebote hatte der Kunde Y zum Zeitpunkt Z offen?

welche Nachlässe wurden dem Kunden Y angeboten?

(eventuell als select amount , orderamount wenn der Auftrag erteilt wurde)

wie viele Angebotsvarianten wurden im Mittel je Berater erstellt?

welchen Nachlass je Berater und Monat wurde gewährt

 

Vorgänge:

wie erfolgt das archivieren der ausgelaufenen Angebote?

Batchlauf mit definierbarer karenzzeit (z.B. 7 Tage)

select * from CRM_OFFERLOG where deadline < heute – karenzzeit and statuscode1 = ‚Open‘

update set statuscode1=’Expired‘, statuscode2 = ‚ausgelaufen per Batch‘

 

Speichern eines neuen Angebots:

PUT CrmOfferlog description=’Angebot xy‘, amount=100, deadline=’2020-05-15′, statuscode1=’Open‘, actioncode=’Angebot erstellt‘

 

Annahme eines vorhandenen Angebots (mit ggf. abweichendem Betrag):

PUT CrmOfferlog  orderamount=80, statuscode1=’Accepted‘, actioncode=’Auftrag erteilt‘

 

Absage eines vorhandenen Angebots:

PUT CrmOfferlog  statuscode1=’Rejected‘, statuscode2=’zu teuer‘, actioncode=’Absage‘

 

 

Ideensammlung Angebotserfassung