CRM systém - koupit nebo vytvořit na míru? |
 |
|
Klíčová otázka devadesátých let minulého století je v kontextu současné krize opět na stole Probíhající ekonomická krize, jejíž konec zatím neumí nikdo odhadnout, nám přináší další zajímavý fenomén v IT. Redukce nákladů, krácení rozpočtů a zefektivňování procesů je na denním pořádku v každé společnosti. Tato opatření, ať jsou jakkoli účinná, však společnosti nikdy nepřinesou další prostředky. Když si odmyslíme bankovní úvěry, jejichž získání může být v dnešní době velmi složité, jsou jediným možným zdrojem financí naši zákazníci. Předchozí období ekonomické stability přálo zejména výrobním, logistickým, skladovým či jiným podobným systémům. Důležité otázky, které v tomto období nejvíce rezonovaly, se ptaly na to, „Co vyrábět?“, „Jak vyrábět?“ nebo „Jak co nejefektivněji distribuovat výrobek ke spotřebiteli?“. Otázky typu „Kdo je můj zákazník?“, „Kteří z mých zákazníků jsou nejbonitnější?“ nebo „Jak si je udržet?“ zůstávaly v pozadí. Až do teď. Vzhledem k momentální situaci na trhu a kupní síle zákazníků nabírají tyto otázky stále více na aktualitě. Fenomén připomenutý v úvodu, který v současné době pozorujeme, spočívá ve změně přístupu směrem k řešení vztahu se zákazníky. Spojení ekonomické krize a potřeby poznat své zákazníky vyvolává u mnoha firem potřebu nasadit vhodné CRM řešení. I když samotný CRM systém výše zmíněné otázky nevyřeší, je vhodným nástrojem k uplatnění podnikové strategie řízení vztahů se zákazníky. Otevřenou otázkou však zůstává, jak na to? Zde se ke slovu dostává již zmíněný fenomén – koupit nebo nechat vytvořit na míru? Tato otázka byla poměrně často slyšet v devadesátých letech minulého století a vedly se kolem ní velmi dlouhé diskuze. Vývoj tohoto řešení by měl brát úvahu určité faktory, které můžou být klíčové, a které nejsou na první pohled vidět. A jdou až za rámec ceny samotného řešení. Koupit nebo vyvinout? Pár faktorů kde zvážení.To někdy může být velmi složitá otázka. Při její tvorbě je nutné mít na paměti několik bodů, které mohou při rozhodování pomoci. Strategie produktuŘešení vyvíjené na míru odráží specifické potřeby zadavatele. V takovém případě jsou procesy, stejně jako jednotlivé funkce, vyvíjené přímo na míru. Většinou neberou v úvahu standardy platné v daném odvětví. Naproti tomu řešení, které se prodává jako takzvané balíkové, v sobě nese inovaci a zkušenosti z daného odvětví a zohledňuje používané standardy a postupy. Velmi často jsou tato řešení doplněna o tzv. „best practices”, což jsou doporučené postupy a procesy, které zákazníkovi pomohou s nastavením běžným procesů pro danou oblast například v marketingu, v obchodě nebo v průmyslovém odvětví. InvesticeSprávně odhadnout velikost investice do řešení na míru je náročné. Je nutné zakalkulovat nejen návrh scénáře, ale také náklady na vytvoření základního architektonického modelu řešení, jeho fyzického naprogramování a následného otestování. Oproti tomu standardní řešení většinou znamená jednorázovou platbu za licence, případně pravidelné platby za údržbu. Investice do standardního řešení je na začátku projektu velmi snadno spočitatelná, zejména když řešení obsahuje různé licenční scénáře, které zákazníkovi umožní výběr toho nejvhodnějšího.
Doba vývoje produktuČasová náročnost vývoje produktu na míru závisí na rozsahu požadavků, které jsou zákazníkem definovány, stejně jako na počtu programátorů ve vývojářském týmu. Jiná situace nastává u standardních řešení, která jsou připravena na okamžitou implementaci podle definovaných požadavků, respektive podle připraveného cílového konceptu. Ověření vhodnosti produktuVývoj produktu na míru s sebou v praxi nese riziko vývoje aplikace, která v závěru nemusí splňovat všechny požadavky. V praxi se často uplatňuje metoda pokusu a omylu, což zpravidla značně zvyšuje původní investici. Je výhodnější a zejména bezpečnější ověřit si vhodnost řešení prostřednictvím testovací verze spuštěné na dobu určitou. Kromě toho existují softwarové verze i dema, které názorně předvádějí funkce řešení. Integrace procesůNávrh a integrace nových procesů jsou poměrně komplikovanou záležitostí. Při nevhodné architektuře mohou způsobit potíže, které se následně řeší kompromisy. Klasicky dodávaná řešení umožňují aplikovat jednotlivé procesy dle potřeby, a zároveň na sebe navazovat bez dodatečných integračních nákladů, v případě, že se jedná o stejného dodavatele, například CRM a ERP. Integrace s dalšími systémyIntegrace v pojetí vyvíjeného produktu často znamená také vývoj samotných rozhraní, vždy podle integrovaného systému. Představuje značné náklady, které jsou na začátku projektu jen velmi těžko odhadnutelné. Standardní řešení jsou dodávána s vyvinutými rozhraními na další běžné systémy nebo obsahují vrstvu tzv. middleware, která slouží právě k definici rozhraní externího systému a jeho napojení na dané řešení.  Obr 2. Integrace systémů Technologický a funkční vývojUdržení naprogramovaného produktu a jeho následné doplnění o další technologie, jako je například Web 2.0, flash video nebo PDF dokumenty a podobně, znamená další náklady spojené s inovací a rozvojem. Většina dodavatelů standardních řešení uvolňuje pravidelně tak zvanou roadmapu, která obsahuje hlavní body rozvoje řešení do budoucnosti, a to jak z pohledu rozšíření procesů a funkcí, tak z pohledu podpory nových technologií. Závislost na programátorechPři programování produktu je společnost plně odkázána na vývojový tým, ať už na svůj interní nebo externí u společnosti, u které si vývoj produktu objednala. Změny ve složení týmu mohou podporu produktu do značné míry ohrozit, zkomplikovat a prodloužit dobu potřebnou k implementaci nových rozšíření. Standardní řešení dodávané jako balíkové s „best practices“ a podporou partnerské sítě toto riziko výrazně zmenšuje. Ze zmíněných faktorů je třeba vyzdvihnout hlavně integraci procesů a integraci s dalšími systémy, což je zřejmé, když se dnes žádné řešení netvoří bez vztahu k okolnímu IT prostředí. To vede k závěru, že v dnešní době jsou misky vah jednoznačně nakloněny ke standardnímu řešení. V době, kdy se samotný software stává komoditou, je vývoj na klíč spíše rizikem než dobrou investicí a může znamenat další bezesné noci, kterých je v dnešní době v obchodě již mnoho. Jan Ferjo CEE Business Development Manager, SAP ČR |
Komentáře
Prečo?
Ľudia sú dnes zvyknutí, že dostanú všetko hneď. Nakúpia na internetovom obchode. Hneď. Objednajú tovar z Honkongu. Hneď. A rovnaký prístup potom aplikujú na CRM a im podobné systémy. To nemusí dopadnúť príliš dobre.
S CRM* si zavádzate do firmy nový nervový systém. Ak bude nefunkčný, paralyzujete si celú organizáciu na niekoľko hodín a nedajbože dní. Stavajte svoje procesy tak, aby dokázali fungovať bez tohoto podporného systému a tam, kde to najviac pomôže, tak systém aplikujte. Pomaly a selektívne. Stavajte procesy tak, aby ste sa dokázali zaobísť bez systému. Vývojári spravia chybu, vypadne elektrina, odíde server. Otázka nie je, či sa to stane, ale "kedy?".
Nezabudnite si vždy položiť otázku: "A skutočne potrebujeme tento modul/server/aplikáciu/inú-troj-písmenovú-skratku? Nedokážeme bez nej a jednoduchšie vyriešiť daný problém?" Ak okamžite odpoviete nie, skúste sa zamyslieť, možno sa vám podarí nájsť efektívnejšiu cestu.
PS: Pekne napísaný článok. Ďakujem
Určtite pak tento článek může dobře posloužit jako odkaz pro někoho kdo váhá nebo neví/není si vědom pro a proti oněch řešení.
Nicméně..,
PROČ onu skrytou ODPOVĚD na vyřčenou OTAZKU neuvést již v první intro větě či odstavci? S uvozujícím slovem/frázi třeba "většinou/často".
Takto je odpověď "RÁDOBY" skrytá. Zbytečně pak celý članek vyzníva (degraduje do) jaksi "záhadologicky".
Je navíc, řekl bych na první pohled zřejmé, že článek psal autor, ktery apriory bude/chce/musí doporučovat ono hotové řešení...
Namísto "opravdu dobré" argumantace (uvádění příkladů I PRO, nejenom proti), to pak "zlehka" spíše obaluje onou záhadnodností či -- rádoby nasměrováním čtenáře na "je to na Vašem rozhodnutí".
Přijde mě to jako balancování mezi objektivitou a (předem stanoveným) cílem/doporučením (té lepší pravdy) článku.
Musím ale jinak uznat, zaobalené je to dobře, cíl autora (záměr vyznění) určite splněn byl ;)