Mπορεί να χρησιμοποιηθεί SPF2010 για να καλύψει βασικές λειτουργίες CRM των μικρών επιχειρήσεων?

Μου φαίνεται ότι τα CRM Entities (όπως Cases, Opportunities, Accounts, Contacts, Tasks, Emails, Appointments) μπορούν να δημιουργούνται εύκολα με Custom Lists του SPF2010.   Εάν προσθέσουμε built-in workflows, document libraries και κάποια έξυπνα «lookup fields» που υπάρχουν νομίζω πως μπορεί να  φτιαχτεί ένα απλό CRM.

Σκεφτομαι να ξεκινήσω τέτοιο project (με περιορισμένες γνώσεις για SPF2010) αλλά σκέφτηκα να ακούσω κάποιους που έχουν εμπειρία σε περίπτωση που τα πράγματα είναι πολύ ποιο δύσκολα

 

Προφανός και μπορείς να κάνεις κάτι custom και να το πάς σε όποιο βαθμό θέλεις.

To Sharepoint έρχεται και με Free solution  για CRM . Δοκίμασε το ίσως με μερικές τροποποιήσεις σου κάνει.

Δεν θα το έλεγα. Και μία βάση δεδομένων μπορεί να δημιουργήσει τις κατάλληλες "δομές", αυτό δεν σημαίνει όμως ότι μπορεί να φτιαχτεί εύκολα και ένα CRM. Οι λίστες του SharePoint δεν αντιστοιχούν σε οντότητες ή πίνακες (άσχετα με όσα κακώς λένε κάποια sites). Επιπλέον, το SharePoint δεν έχει κάποιο template για CRM site. Είχαν βγει κάποια sample helpdesk templates για το SharePoint 2007 τα οποία όμως δεν υποστηρίζονται, δεν είναι διαθέσιμα σε source και δεν μεταφέρθηκαν στο Sharepoint 2010. Όσοι τα εγκατέστησαν δύσκολα θα μπορέσουν να κάνουν migrate σε 2010.

Το πιο σημαντικό ζήτημα είναι τί εννοείς CRM? Ναι, μπορείς να βάλεις μερικές λίστες με σχέσεις μεταξύ τους, αλλά η ταχύτητα και το στάνταρ UI του SharePoint κατά κανόνα είναι εντελώς ακατάλληλα για CRM που απευθύνεται σε Call Center. Αν η εταιρεία σου πάλι θέλει να εμφανίζει όλες τις πληροφορίες ενός πελάτη σε μία οθόνη, θέλει αρκετή δουλειά. Θα πρέπει να φτιάξεις μία composite οθόνη η οποία θα σου εμφανίζει ιστορικό κλήσεων, παραγγελιών (εφόσον έχεις παραγγελίες), συμβάσεων ή υπηρεσιών, στοιχείων του πελάτη, κλπ, κλπ, κλπ. Και φυσικά κάπως να βάλεις όλες τις πληροφορίες μέσα στο SharePoint.
  Άλλο pain point είναι το workflow. Το wf του SharePoint είναι κατάλληλο κυρίως για task automation καθώς είναι ουσιαστικά γραμμικό και περιορισμένο. Αν θέλεις κάτι άλλο θα πρέπει να γράψεις κώδικα ή να αγοράσεις κάποιο third party tool.
  Τέλος, εφαρμογή CRM χωρίς reporting δεν υπάρχει και το SharePoint παρέχει υποτυπώδειες λειτουργίες reporting. Θα χρειαστεί αρκετή δουλειά για να πετύχεις το reporting που παρέχει μία σοβαρή εφαρμογή CRM.

Από την άλλη, αν μιλάμε για μία μικρή εταιρεία με μικρή κίνηση ανά πελάτη, τα πράγματα είναι πολύ πιο εύκολα.

Πριν αποφασίσεις λοιπόν ότι θέλεις ή δεν θέλεις SharePoint για CRM θα πρέπει να σκεφτείς "Τί εννοώ CRM? Τί θέλω να κάνει η εφαρμογή μου? Πόσο χρόνο θέλω να ξοδέψω στη συντήρηση του?"

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

P.S. Original Post ηταν δικο μου πριν γινει activate το account μου στο forum : - )

Βασικά, σκέφτηκα καταρχάς ότι το SFP2010 είναι δωρεάν, και αρκετές μικρές εταιρίες (<20) που θα μπορούσαν να αγοράζουν Dynamics CRM δεν είναι σε θέση σήμερα να ξοδεύουν τα license fees. 

Είναι σίγουρο ότι δεν είναι δίκαιο να συγκρίνω το ένα προϊών με το άλλο, άλλο έχω την αίσθηση ότι για μικρές εταιρίες, με απλό business process ένα CRM είναι ένα πελατολόγιο με email integration, case management, και μια υποδομή για workflow (tasks, phone calls κλπ) ), και structured storage για τα έγγραφα τους.  

Όταν σκέπτομαι ένα SharePoint template με λίγο customization, έχω στο νου μου οι πελάτες που για αυτούς που αυτή τη στιγμή δεν έχουν οργάνωση στο γραφείο τους και από έλλειψη χρήματος παν για λύσεις open source (SugarCRM κλπ).

---

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.”
(Mosher’s Law)

Έχω ξεκινήσει http://sharecrm.codeplex.com/ με ενα draft Data Model για Brainstorming.

: - )

---

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.”
(Mosher’s Law)

Να επαναλάβω ότι το SharePoint ΔΕΝ είναι βάση δεδομένων, οι λίστες ΔΕΝ είναι πίνακες και συνεπώς ΔΕΝ μπορείς να φτιάξεις ER μοντέλο για κάποιο site. Επιπλέον, δεν υπάρχει κάτι που να λέγεται Out-Of-The-Box Custom List. Όλες οι λίστες έχουν την ίδια αντιμετώπιση, μάλιστα όλα τα default templates βασίζονται στην custom list template. Με άλλα λόγια, όλες οι λίστες "είναι" custom lists.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Καλησπέρα Παναγιώτη

Ξέρω πως έχεις δίκιο και ότι θα χρειαστεί πολύ δουλεία, και ελπίζω το Project θα μου δώσει αφορμή να μάθω τα βασικά.  Έχω ξεκινήσει ένα codeplex και ελπίζω να καταφέρω να αφιερώσω κάποιους μήνες το τον ανατήξω (και εάν βρεθεί και κάποια βοήθεια από εκεί θα ήταν ακόμα καλύτερα).

Μια ερώτηση, όταν λες πρέπει οι λίστες να φτιαχτούν με XML και όχι με SP Designer, διότι είχα την εντύπωση πως όλες οι λίστες είναι defined μέσα από XML (είτε φτιάχνονται με Internet Explorer, SP Designer, η ακόμα και μέσα από VS2010 SharePoint Solution.

 

---

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.”
(Mosher’s Law)

Προσωπική προτροπή θα ήταν να μην κλείσεις μια τέτοια αρχιτεκτονική μέσα στα "όρια και περιορισμούς" της πλατφόρμας του SharePoint - θα μπορούσες να έχει μια πλήρες σχεσιακή βάση μέσα σε ένα κανονικό RDBMS σύστημα και μέσω των Business Connectivity Services του SharePoint 2010 να προσφέρεις την πρόσβαση στα δεδομένα του συστήματος. Να προσπαθήσεις να πάρεις το καλύτερα που μπορείς να βρεις, όχι μόνο από το SharePoint, αλλά και από το RDBMS για μια τέτοια λύση.

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

George J. Capnias:

Προσωπική προτροπή θα ήταν να μην κλείσεις μια τέτοια αρχιτεκτονική μέσα στα "όρια και περιορισμούς" της πλατφόρμας του SharePoint - θα μπορούσες να έχει μια πλήρες σχεσιακή βάση μέσα σε ένα κανονικό RDBMS σύστημα και μέσω των Business Connectivity Services του SharePoint 2010 να προσφέρεις την πρόσβαση στα δεδομένα του συστήματος. Να προσπαθήσεις να πάρεις το καλύτερα που μπορείς να βρεις, όχι μόνο από το SharePoint, αλλά και από το RDBMS για μια τέτοια λύση.

 

George J.

 

Εάν μεταφέρω το domain model έξω από λίστες του SharePoint για να τα βάλω στο SQL, διάβασα κάπου ότι χάνω τα Data Validation Features αλλά και Workflow (http://www.sharepointanalysthq.com/2010/07/bcs-external-list-limitations/)

---

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.”
(Mosher’s Law)

Ναι, αυτό είναι αλήθεια, αλλά δεν είναι και απόλυτα δεσμευτικό - μπορεί να μην μπορείς να υλοποιήσεις στην External list workflows και versioning, αλλά μπορείς να το κάνεις με έμμεσο τρόπο. Αν η external list είναι κρυφή λίστα και ελέγχεται από μια άλλη κανονική μπορείς να το κάνεις - ένα τέτοιο παράδειγμα μπορείς να δεις στην δημοσίευση "Using SharePoint workflows with Business Connectivity Services (BCS)".

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Underwater:

Εάν μεταφέρω το domain model έξω από λίστες του SharePoint για να τα βάλω στο SQL,

Να ξαναεπαναλάβω, οι λίστες ΔΕΝ είναι πίνακες ούτε domain entities. ΔΕΝ μπορείς να ξεκινήσεις από ένα domain model για να σχεδιάσεις ένα SharePoint site. Αν κάτι πλησιάζει (πως λέμε Πάτρα-Αθήνα) τα domain entities, είναι τα content types. Πρόκειται όμως για απλή ομοιότητα. Το SharePoint ανήκει στις κατηγορίες των Enterprise Content Management και Document Management προϊόντων, όπου το domain modelling δεν έχει εφαρμογή, τουλάχιστον όχι όπως το εννοείς.

Καταρχήν, όταν μιλάς για entities μιλάς πρώτα για συμπεριφορά και μετά για δεδομένα. Στο SharePoint ΔΕΝ υπάρχει συμπεριφορά με αυτή την έννοια. Ο κώδικας που μπορείς να προσθέσεις είναι σε πολύ περιορισμένο επίπεδο, είτε Event Receivers είτε custom actions σε φόρμες ή μενού και πάντα ανεξάρτητος από συγκεκριμμένα instances. Τα workflows δεν τα αναφέρω γιατί ουσιαστικά συμπεριφέρονται είτε σαν event receivers είτε σαν actions, ανάλογα πως τα ενεργοποιείς.

Αλλά και οι λίστες διαφέρουν πάρα πολύ από τα τυπικά entities. Καταρχήν, δεν είναι όλες οι σημαντικές οντότητες λίστες ή έστω content types. Για παράδειγμα, οι χρήστες είναι μία demi κατάσταση - δεν είναι λίστα αλλά ένα υποσύνολο του functionality φαίνεται σαν λίστα σε κάποια σημεία. Το υπόλοιπο θέλει "τούμπες" και ειδικές κλάσεις για να εμφανιστεί. Από την άλλη, ένα "πεδίο" μπορεί να είναι αρκετά περίπλοκο, με πολλαπλά "πεδία" και συμπεριφορά, η οποία ορίζεται ανεξάρτητα από τη λίστα ή το content type του.
Να μην πω τώρα για τις βιβλιοθήκες που μπορεί να φαίνονται ίδιες με τις απλές λίστες εξωτερικά, σε επίπεδο API όμως πρέπει να κάνεις τούμπες.

Το μοντέλο του SharePoint γενικά δεν είναι τόσο καθαρό όσο το παρουσιάζουν σε courses και video. Δεν πρόκειται για μία πλατφόρμα αλλά για μία εφαρμογή που χτίστηκε σιγά-σιγά και μετά άρχισε να εξελίσσεται σε πλατφόρμα. Επιπλέον, πολλές λειτουργίες υπάρχουν μόνο στις server εκδόσεις και δεν παρουσιάζονται καν στο βασικό API. Εκεί οφείλεται η διχοτομία μεταξύ λίστας/βιβλιοθήκης (στο SP 2003 ήταν εντελώς ανεξάρτητες), το διάσπαρτο functionality για τους χρήστες (στο SP 2003 δεν υπήρχαν τα περισσότερα features και στο SP 2007 υπήρχαν στη server έκδοση).

 

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos