Aneb co se do všeobecných obchodních podmínek nevešlo.
Jak funguje spolupráce s námi?
Spolupráce s námi funguje na několika úrovních… někdy děláme komplexní implementace RAYNET CRM, jindy jen vyrábíme custom integrace a automatizace na základě konkrétního zadání, většinou ale před každým projektem děláme odborné konzultace, v rámci kterých se snažíme pochopit vaše potřeby, analyzovat procesy a datové zdroje, a navrhnout optimální řešení, abychom ho mohli následně realizovat.
Kolik stojí naše služby?
Nejmenší zakázky u nás začínají na částce kolem 8 750 Kč bez DPH. Jedná se např. o výrobu jednodušších dokumentů — vlastních tiskových šablon, jako jsou nabídky nebo smlouvy. Za tuto částku se dá realizovat i výroba menších automatizací a výpočtů, se kterými si neporadí samotné CRM. Cena zakázky mimo jiné reflektuje pracnost výroby a způsob předání, takže podobná zakázka může jiného klienta vyjít dráž než vás, protože bude potřebovat dodatečnou konzultaci / školení tam, kde vy si zvládnete výstupy převzít na základě telefonátu nebo popisu v e-mailu, samostatně otestovat a interně zaškolit kolegy. Snažíme se netahat z vás zbytečně víc peněz než je nutné a současně se přizpůsobit vašim individuálním potřebám a technickým znalostem. Na začátku spolupráce však tyto aspekty neznáme a proto není možné stanovit zcela fixní cenu zakázky.
Většina komplexních implementací CRM se pohybuje v rozsahu od 35 000 do 150 000 Kč bez DPH, což zahrnuje analýzu potřeb, procesů a datových zdrojů, návrh řešení, nastavení evidenčního modelu, výrobu integrací a automatizací a školení. Závazně jsme schopni cenu potvrdit nebo upřesnit po analýze potřeb, která probíhá formou úvodní konzultace.
Proč neděláme hodinové konzultace?
Důvodů pro toto strategické rozhodnutí je několik… především, za hodinu není možné seriózně pochopit potřeby a veškeré konsekvence daného businessu. Implementace CRM a výroba integrací a automatizací je do jisté míry kreativní činnost, nedá se říct, že pro situaci X je jediným řešením Y. Vždy záleží nejen na potřebách, ale i možnostech dané firmy a klíčových lidí. To, co se s někým dá vykomunikovat za 20 minut, se s jiným člověkem může řešit přes hodinu, dopředu to ale nevíme. Při konzultacích jsme 100 % soustředěni na dané téma a snažíme se k němu poskytovat komplexní informace a navrhovat řešení v kontextu konkrétního prostředí. Tříštit pozornost mezi více než 2 konzultace za den není efektivní a s ohledem na naši specializaci ani finančně zajímavé. Samozřejmě, existují výjimky… např. pro funkce Vlastní šablony v CRM nebo Konfigurace integrace CRM s SMS bránou máme speciální doplňková školení, ta jsou však podmíněna nákupem konkrétní služby. Nakonec je dobré říct, že z naší strany se jedná o závazný časový rámec, který z vaší strany nemusí být využit.
Jaké jsou výhody a nevýhody no-code / low-code oproti klasickému vývoji pomocí tradičních programovacích jazyků?
No-code / low-code platformy a jejich využití jsou jednoznačným trendem posledních let pro realizaci celé řady interních i klientských projektů. Kdybychom to měli k něčemu přirovnat, tak je asi lepší udělat si domácí pomalu tažený vývar, nakrájet čerstvou zeleninu a uvařit si chutnou pocitovou polévku. Jenže pokud máte hlad a nechce se vám čekat na dokonalý vlastní produkt, zasytí vás i polévka z pytlíku. Na trhu jsou dnes instantní polévky důstojné kvality, navíc v porovnání s vlastním řešením za rozumnou cenu. Když do toho navíc přidáte vejce a šnytlík, výsledný pokrm splní svůj účel v podobné kvalitě rychleji a levněji. Touto paralelou se snažíme popsat rozdíl mezi klasickým custom vývojem a výrobou prostřednictvím no-code / low-code nástrojů. Jednoduše jde o to, že ve většině případů dostanete požadované řešení prostě rychleji a levněji. Co je ovšem u obou přístupů stejné je analýza a návrh řešení, který výrobě předchází a testování, které po výrobě následuje. Ani z pohledu provozu a údržby koncový uživatel (vy jako klient) nepozná významné rozdíly. Pouze pokud v platformě nastane nějaký problém (výpadek, chyba, zpětně nekompatibilní změna), nemá poskytovatel řešení efektivní nástroje k jeho odstranění a musí počkat, až problém vyřeší vývojáři konkrétní platformy. U klasického vývoje má poskytovatel přímou kontrolu nad tím, co a jak kód vykonává a může aplikovat prakticky jakékoliv změny, které jsou v použitém jazyce dostupné. Nakonec je potřeba říct, že no-code / low-code je jenom vrstva pod kterou se nachází další programované vrstvy podobně jako např. u operačních systémů… asi by vás ani nenapadlo v dnešní době používat příkazový řádek, přestože je to stále možné.
Je lepší poskládat firemní ekosystém z více specializovaných aplikací nebo pořídit jeden systém na všechno?
Na tuto otázku neexistuje jednoznačná odpověď a svou roli v tom bude hrát mimo jiné i obor podnikání a velikost firmy. U nás jsme příznivci spíše sady menších specializovaných řešení, které jsou mezi sebou vzájemně propojené. Proč? Protože je lepší využít 85 % funkcionality „krabicového" produktu a zbylých 15 % si nechat vyrobit na míru, než využít jen 20 % funkcionality velmi robustního systému. Proč? Protože většina těchto velkých systémů má špatné a zastaralé uživatelské rozhraní, se kterým mají dnešní uživatelé i administrátoři problém efektivně pracovat. Dalším důvodem, proč je lepší mít firemní ekosystém poskládaný z dílčích částí, je nepředvídatelný vývoj vašich potřeb. Pokud se v některé oblasti časem zvýší vaše potřeby natolik, že z používaného řešení tzv. vyrostete, je možné ho nahradit vhodnějším a postupně tím pokrývat rostoucí potřeby. Ať už se rozhodnete pro jakkoliv velké řešení, pohlídejte si to nejdůležitější… otevřené programovatelné rozhraní s kompletní dokumentací a jeho pravidelnou aktualizací.
Jak prakticky probíhá typická implementace CRM?
Při implementaci postupujeme metodou Proof of concept (PoC), což znamená, že postupně analyzujeme jednotlivé obchodní procesy a s tím související datové zdroje. Začínáme typicky od začátku, tedy od sběru leadů. Následně stanovíme klíčové obchodní milníky — stavy OP, a při tom vytvoříme volitelná a povinná pole pro evidenci všech potřebných informací. Vytvoříme a popíšeme účel také všech aktivit, které jsou součástí obchodního procesu. Už během prvních hodin tedy vznikají velmi relevantní vzorová data v reálném prostředí, ze kterých je každému uživateli zřejmý tzv. evidenční model. Ten následně formálně popíšeme ve výstupním dokumentu. Součástí implementace bývají také různé vedlejší obchodní procesy, jako např. aftercare, reklamace apod. Následně je možné nad vzorovými daty vytvářet automatizace a tiskové výstupy. Dalším klíčovým prvkem implementace je příprava na datovou integraci CRM s dalšími systémy. Popíšeme scénáře užití, tzn. za jakých okolností (spouštěčů) se data přenesou ze CRM nebo do CRM. Pokud je to možné, jdeme až na úroveň jednotlivých polí a jejich hodnot. Výstupem analýzy je tedy specificky nastavené CRM obsahující vzorová data a dokument, ve kterém jsou popsány důvody tohoto nastavení a harmonogram pro výrobu integrací a automatizací na míru.
Co to obnáší a co je potřeba dodat, když si chcete nechat vyrobit integraci na míru?
K integraci (propojení) dvou či více systémů je potřeba, aby poskytovatel — tvůrce takového systému písemně deklaroval metody datové komunikace. Jednoduše to znamená, že musí být schopen poskytnout vám a nám dokumentaci k datovému rozhraní, v dnešní době typicky API (Application Programming Interface). Alternativně je možné integrovat pomocí přímého přístupu do SQL (Structured Query Language) databáze nebo výměnou datových souborů přes FTP (File Transfer Protocol). Pokud nemá nebo nechce tvůrce poskytnout API (či jiné metody datové komunikace) s dokumentací, nemohou externí vývojáři s takovou aplikací vytvořit žádná propojení.
Pokud máte k dispozici dokumentaci, můžeme spolu (nebo samostatně) definovat seznam atributů, které se mají přenášet ze systému A do systému B. Takže např. objednávka obsahuje číslo objednávky, datum vystavení, vazbu na odběratele a položky. Každá položka obsahuje kód položky, jednotkovou cenu, množství, sazbu DPH atd.
Nakonec je dobré se zamyslet, co bude spouštěčem integrace… může to být např. stisknutí tlačítka, změna hodnoty v nějakém poli, nebo se mohou data přenášet v pravidelných intervalech, např. každý den nebo každou hodinu.
Jak probíhá uživatelské testování a co byste o něm měli vědět?
Uživatelské testování je nedílnou součástí vývoje na míru… oblek od krejčího byste si taky měli několikrát vyzkoušet, než bude zcela dokončen. Počítejte proto prosím s tím, že vám uživatelské testování zabere nějaký čas i energii a může to ovlivnit termín dokončení.
U rozsáhlejších projektů je vhodné použít strukturovaný dokument, který vám pro tyto účely připravíme. U menších projektů může stačit dobře vedená e-mailová komunikace. V každém případě je nutné při hlášení chyb uvést konkrétní záznam v CRM, na kterém bylo testováno a ideálně k popisu situace přidat screenshot obrazovky. To ostatně platí i pro případné chyby a požadavky, které nám bude hlásit během ostrého provozu.
Je součástí výroby integrací / automatizací dokumentace?
Pojem dokumentace je potřeba nejprve rozdělit na dvě části… technická a uživatelská.
Technická dokumentace vzniká vždy a potřebujeme ji hlavně my, abychom byli schopni se v dodaném řešení orientovat. U menších projektů bývá součástí scénáře v Make, u větších projektů může vzniknout zastřešující dokument. Avšak ani technická dokumentace není všespásná a po mnoha měsících nebo letech si i sám autor musí udělat analýzu toho, co a jak vlastně funguje.
Uživatelská dokumentace je věc dohody a může být volitelně doplněna i po dokončení projektu. Zejména u větších projektů doporučujeme její objednání, přestože se může s ohledem na pracnost jejího napsání jednat o poměrně velkou investici. Je však potřeba si uvědomit, že s informačními systémy pracují lidé a lidé se v průběhu času mění. Pokud není nový uživatel dostatečně seznámen s obsluhou systému, a neví proč dělá to co dělá, mohou na míru vyrobené integrace / automatizace vracet neočekávané výstupy. Pro takového uživatele můžeme samozřejmě nabídnout individuální školení — konzultaci, ale i to je druh investice. Kterou z nich si vyberete je na vás.
Kdo bude projekt řídit (koordinovat), když je potřeba při výrobě integrace získat informace nebo data od více subjektů?
Představte si následující situaci. Chcete vyrobit automatizaci, která bude odesílat děkovné e-maily při vyplnění webového formuláře a zároveň zapisovat leady do CRM. Teoreticky může být ve hře celkem 5 subjektů… vy, my, webmaster — ten kdo se vám stará o web, ten kdo vám zajišťuje mail hosting a RAYNET. Není v našich možnostech vyjednat si s každým subjektem přístupové údaje, přístup k datům, správné nastavení aplikace apod. Bez vaší součinnosti se to neobejde.
Co ale máte dělat, když ničemu z toho nerozumíte a nechcete jen papouškovat informace od jednoho dodavatele k druhému? Pravděpodobně jste personálně nedostateční a měli byste si zajistit technicky orientovaného člověka, který za vás bude s IT dodavateli komunikovat. Může se jednat o interního člověka, nebo externistu. Pokud takového člověka ve firmě ještě nemáte, můžeme vám doporučit spolupráci s prověřenými projektovými manažery, kteří se na projekty tohoto typu specializují.
V některých případech jsme schopni komunikovat napřímo, nebude-li však součinnost zcela efektivní, projeví se to ve výsledné ceně projektu.
Proč stanovujeme cenu a termín realizace rozsahem?
Na začátku každého projektu existuje mnoho neznámých. Řadu faktorů dokonce nedokážeme sami ovlivnit a některé jsou dokonce výhradně ve vaší moci. Může se to týkat zadání, zabezpečení a autorizace do vašich systémů, nebo třeba vyčerpaných kreditů / operací / průběhů / limitů. Abychom mohli zaplánovat výrobu a tím pádem závazně slíbit termín, musíme mít z vaší strany všechny potřebné podklady a funkční přístupy. Do té doby nemůžeme alokovat na projekt žádné výrobní kapacity a tím pádem nemůžeme určit datum dokončení. Do výrobního procesu dále vstupuje fáze uživatelského testování a i v tomto případě je jeho efektivita závislá na spolupráci. Menší projekty lze předat k uživatelskému testování snadno a rychle, větší projekty se většinou předávají formou on-line konzultace. Tento agilní přístup vyžaduje také agilnější financování. Díky tomu jsme schopni začít projekt realizovat, aniž byste musel na začátku vynakládat značné prostředky na podrobnou technickou analýzu.
Kromě velmi malých projektů je praxe taková, že co jeden měsíc zobchodujeme, to druhý měsíc zanalyzujeme a zaplánujeme a třetí měsíc vyrobíme a předáme. Jinak řečeno, mezi analýzou, návrhem řešení a realizací je u většiny projektů minimálně měsíční odstup před zahájením výroby, protože potřebujeme čas na dokončení předešlých projektů.
Jaké jsou minimální náklady u dlouhodobé spolupráce?
Pokud je potřeba se o dodané výstupy dlouhodobě starat, tak kromě jednorázových nákladů na výrobu integrace nebo automatizace, je k tomu nutné zajistit:
- trvalý přístup do CRM (390 Kč za licenci — platí se RAYNETu),
- aktivní účet v Make (250 Kč za plán CORE — platí se Make.com),
- SLA (od 950 Kč za monitoring a údržbu — platí se nám).
U některých integrací a automatizací se provoz někdy neobejde bez funkce Automatizace v CRM, která je zpoplatněna nad rámec ceny za licence (650 Kč za plán STAVITEL — platí se RAYNETu). Celkové minimální náklady na provoz integrací a automatizací se tedy pohybují od 1 600 Kč měsíčně, resp. 2 150 Kč, pokud je potřeba využít i funkci Automatizace v RAYNETu. Pokud nechcete integrace a automatizace provozovat na vlastním účtu Make, rádi se o hosting postaráme u nás… v takovém případě minimální poplatek za SLA začíná na částce 1 750 Kč měsíčně a obsahuje balíček 10 000 operací v Make.
Jaké jsou výhody a nevýhody provozu scénářů na vlastním účtu a na účtu Bubble Development?
Jsou v zásadě dvě možnosti, jak můžete k rozhodnutí o provozu přistoupit. Pokud vás zajímá námi používaná výrobní technologie, pomocí které dodáváme řešení, pak je potřeba si k tomu něco načíst. Pokud vás námi používaná výrobní technologie nezajímá, postaráme se o vše, co souvisí s provozem a údržbou dodaného řešení, za vás.
Provoz scénářů na vlastním účtu
Výhody:
- Ke scénářům máte 100% přístup a kontrolu nad jejich stavem.
- Můžete převzít správu scénářů do vlastních rukou nebo ji svěřit jinému partnerovi.
Nevýhody:
- Hlídáte a platíte si vlastní plán v Make podle počtu operací (viz ceník).
- Všechny aplikace a služby použité ve scénáři, včetně pomocných, jsou registrovány na váš účet / e-mail a s některými z nich mohou být spojeny další poplatky.
- Pro výrobu a testování je potřeba zajistit dostatečné množství operací, které může být násobně větší, než při následném běžném reálném provozu.
Provoz scénářů na účtu Bubble Development
Výhody:
- Náklady na provoz integrací & automatizací (do 10 tisíc operací měsíčně) jsou zahrnuty v měsíčním poplatku za provoz a údržbu včetně pomocných aplikací a služeb. Na celou službu tedy dostanete jednu fakturu.
Nevýhody:
- Je to do jisté míry „vendor-lock". Větší závislost je ovšem oboustranná, protože i pro nás je prakticky nereálné vypovědět SLA u integrací & automatizací běžících na našem účtu.
- Přestože máte právo na vlastnictví scénářů v Make a technicky je možné zajistit jejich migraci na jiný účet, je s tím spojená určitá pracnost, která se projeví jako další náklad.
Pokud se rozhodnete pro provoz scénářů na vlastním účtu, doporučujeme registraci přes tento odkaz, díky čemuž získáte 10 tisíc operací zdarma pro výrobu a testování.
Proč je dobré platit pravidelný poplatek za provoz a údržbu (SLA)?
Máte-li interně k dispozici technicky orientovaného člověka, který je schopen se o dodané řešení v případě potřeby postarat, tak s námi SLA sjednané mít nemusíte. Jsme schopni dodat projekt i jako jednorázovou zakázku. SLA vám dává jistotu, že pokud se v dodané integraci nebo automatizaci něco pokazí, postaráme se o řešení problému. Samotná platforma Make stejně jako všechny cloudové aplikace jí propojené se neustále vyvíjejí a některé změny nemusí být zpětně kompatibilní. Přestože dodané výstupy procházejí důkladným interním i klientským testováním, mohou se během provozu vyskytnout situace, na které se během zkušebního provozu nepřišlo a které se projeví až v delším časovém horizontu. Nakonec i při samotném používání CRM můžete způsobit datové nekonzistence, které způsobí datovou kolizi, kterou bude potřeba ošetřit.
SLA si lze také představit i jako formu pojištění… havarijní pojištění pro automobil si taky nelze sjednat až v okamžiku dopravní nehody.
Jednoduše řečeno pod SLA se skrývá soubor činností, které zajišťují, že dodané řešení (řešení = integrace / automatizace / nadstavba) bude dlouhodobě funkční. Konkrétně se jedná o:
- monitoring běhů — sledování varování a chyb na platformě Make;
- e-mailová podpora při řešení vašich dotazů;
- řešení technických problémů v Make, RAYNET CRM a dalších aplikacích, které mají souvislost s dodaným řešením;
- opravy chyb, které se objeví po delší době používání a garance jejich odstranění ve lhůtě popsané v obchodních podmínkách;
- drobné úpravy v souladu s budoucími potřebami, které nemění principiální fungování aplikace.
Jaký bude postup v případě, že se rozhodnete pro provoz scénářů bez SLA a v budoucnu v nich budete chtít udělat od nás nějaké úpravy?
Faktické vyřešení některých požadavků může být rychlejší, než napsání tohoto odstavce. A v tom je ten problém… nemáme pro tuto operativní činnost jiný obchodní model. Drobné úpravy scénářů v Make řešíme v rámci SLA, z větších požadavků děláme projekty a u nejasných potřeb nabízíme konzultace. Pokud u vás byla výroba scénářů v Make realizována jako jednorázový projekt bez SLA, měli bychom vám s každým dalším požadavkem poslat nabídku, následně si nechat podepsat objednávku, pak vyžádat přístupy do Make a CRM, provést úpravu, nechat vás ji otestovat a následně potvrdit akceptační protokol, který slouží jako podklad pro fakturaci. Jenom kolem administrativy a komunikace by nás to stálo víc, než kolik je slušné si za takovou práci říct, a to máme většinu zmíněných kroků automatizovaných. Zkrátka, nemáme pro tuto operativní činnost jiný obchodní model, než SLA… je to strategické rozhodnutí, abychom svou práci mohli dělat zodpovědně a dlouhodobě pro desítky klientů ročně teď i v budoucnu.
Na co se SLA (ne)vztahuje?
Jednoduše řečeno, SLA pokrývá provoz a údržbu dodaných řešení prostřednictvím platformy Make. SLA se nevztahuje na nastavení RAYNET CRM, funkci Automatizace v RAYNET CRM ani na funkci Vlastní šablony dokumentů v RAYNET CRM. Automatizace v CRM vytváříme a školíme formou konzultací a vlastní šablony dokumentů vyrábíme a upravujeme samostatně na základě zadání.
Proč potřebujeme administrátorský přístup do RAYNET CRM a co dělat, když nám ho nemůžete nebo nechcete poskytnout?
Veškeré úkony v CRM se odehrávají prostřednictvím uživatelského účtu, včetně datové komunikace přes API. Bez administrátorského přístupu si nemůžeme vytvořit API klíč nezbytný pro navázání datové komunikace s CRM, nemůžeme zaregistrovat webhooky, které odesílají informace o změnách z CRM, nemůžeme vytvářet volitelná pole a nastavovat jejich parametry, nemůžeme vytvářet tlačítka vlastních akcí a nemáme možnost zobrazit si kompletní historii změn každého záznamu, což je důležité zejména pro hledání a odstraňování různých jevů v rámci integrace / automatizace, ale někdy také nežádoucího uživatelského chování. Administrátor nemá žádná omezení co se týče bezpečnostních úrovní, zamykání / odemykání záznamů a další práce s daty, tzn. vytváření, úpravy a mazání záznamů. To vše snižuje pravděpodobnost, že integrace / automatizace při vykonávání akce skončí chybou.
Asi byste nečekali, že budeme vámi poskytnuté informace a zpřístupněná data zneužívat, přesto je dobrým zvykem si potvrdit, že budeme s důvěrnými informacemi a daty zacházet opatrně a v souladu s dobrými mravy, což je předmětem článku 10 obchodních podmínek, který se věnuje tématu NDA.
Pokud vás ani tyto informace nepřesvědčily a současně máte o spolupráci zájem, nezbývá než si nechat vytvořit od RAYNETu klon vaší instance a odstranit z ní všechna data. Následně vytvoříme integraci / automatizaci na tomto bezpečném testovacím prostředí a předáme vám ji do uživatelského testování. Po jeho dokončení si budete muset provést napojení na produkční instanci sami. Nemůžeme to udělat za vás, protože bychom k tomu potřebovali přístupy, které nám nemůžete nebo nechcete poskytnout. S napojením na produkční instanci vám pomůžeme v rámci konzultace.
Z výše uvedeného vyplývá, že v takovém případě musí být výroba a provoz integrací / automatizací na vašem účtu Make a také, že z naší strany nemůže být poskytováno žádné SLA, tedy podpora při provozu a údržbě dodaného řešení.