Zawartość
- Zrozumienie debaty
- W domu lub po wyjęciu z pudełka
- Business Intelligence nie jest produktem towarowym (jeszcze)
- Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
- Partnerstwo, a nie jednorazowa transakcja
Źródło: Cybrain / Dreamstime.com
Na wynos:
Jeśli zastanawiasz się nad wbudowaną analizą, powinieneś wyjść poza standardowe rozwiązania „buduj” lub „kupuj”.
Ponieważ wbudowane analizy stają się coraz bardziej widoczne w środowisku Business Intelligence (BI), pytanie, czy firmy powinny budować, czy kupować wbudowane aplikacje BI, wydaje się bardziej aktualne niż kiedykolwiek. Liczne próby odpowiedzi na to pytanie ignorują podstawowy fakt, że samo pytanie jest mylące, ponieważ dla większości organizacji nie ma prostej odpowiedzi typu „tak lub nie”. Zamiast tego najlepsze praktyki dotyczące wbudowanych analiz nie są ani „budowane”, ani „kupuj” - ale w rzeczywistości są bardziej zbliżone do partnerstwa.
Zrozumienie debaty
„Embedded analytics” to ogólny termin, który opisuje integrację różnych funkcji narzędzi analizy biznesowej z innymi aplikacjami (często, ale nie wyłącznie, w SaaS). Na przykład firma, która opracowuje oprogramowanie CRM, może chcieć zapewnić bardziej szczegółowe informacje na temat gromadzonych danych w celu ulepszenia ogólnej oferty firmy lub sprzedaży usługi premium. Dlatego może wyglądać na włączenie funkcji, takich jak transformacja danych, szybkie wysyłanie zapytań do dużych zbiorów danych lub interaktywne wizualizacje do własnego pakietu oprogramowania CRM.
Gartner oszacował, że do 2015 r. Zostanie wbudowanych 25 procent funkcji analitycznych, zwiększając się z zaledwie 5 procent w 2010 r. Większość specjalistów w branży BI zgodzi się, że wbudowane BI stało się głównym obszarem zainteresowania zarówno biznesu, jak i technologii. Klienci wymagają samoobsługi, znaczącego dostępu do danych, a konkurencja zmusza firmy do sprostania tym wymaganiom, co z kolei prowadzi do większego skupienia się na budowaniu tego rodzaju możliwości.
W domu lub po wyjęciu z pudełka
Pytanie „budować czy nie budować” stało się przedmiotem gorących dyskusji przy rozważaniu osadzonego projektu analitycznego. Uruchom szybkie wyszukiwanie w Google hasła „buduj vs kup wbudowane analityki”, a będziesz bombardowany strona po stronie artykułów zadających i próbujących odpowiedzieć na to dokładne pytanie. Pokrótce przedstawię najczęstsze argumenty dla każdej strony debaty:
- Opracowanie wewnętrznych funkcji BI zapewnia firmom większą elastyczność i kontrolę nad produktem końcowym. Pierwotny twórca aplikacji jest najlepiej zaznajomiony ze swoim produktem i klientami, dzięki czemu będzie mógł precyzyjniej dostosować rozwiązanie. Wbudowanie wewnętrznych funkcji BI wymaga jednak znacznych inwestycji i często przynosi wyniki poniżej przeciętnej ze względu na wymagany poziom inwestycji i potrzebę specjalistycznych umiejętności.
- Zakup „gotowego” rozwiązania umożliwia firmie wykorzystanie ogromnych inwestycji już dokonanych przez dostawcę BI oraz daje dostęp do najnowocześniejszych możliwości BI.
W większości przypadków firmy, które starają się zapewnić swoim klientom znaczące możliwości analizy danych, lepiej byłoby osadzić istniejący produkt niż zacząć od zera. Chciałbym jednak podkreślić, że sposób, w jaki postawiono to pytanie, sam w sobie jest mylący: zdecydowanie bardziej powszechnym - i preferowanym - scenariuszem nie jest w rzeczywistości budowanie ani kupowanie, ale trzecie rozwiązanie, które można dokładniej opisać jako Współpraca.
Business Intelligence nie jest produktem towarowym (jeszcze)
Kiedy ludzie mówią o „buduj vs kupuj”, można odnieść wrażenie, że istnieje możliwość przejścia do trybu online i zakupu wbudowanego rozwiązania BI pod klucz, które można łatwo podłączyć do istniejącego produktu i presto! Natychmiastowa analityka skierowana do klienta. Niestety, jeśli chodzi o bardziej wyrafinowane potrzeby i produkty, prawie nigdy tak nie jest.
Nie chcę sugerować, że implementacje BI muszą być długie lub trudne, ale po prostu, że każda implementacja jest różne. Firma, która zazwyczaj chce przedstawić swoim klientom sto tysięcy wierszy danych, nie potrzebuje tego samego „mięśnia” technologicznego, co ten, który działa ze sto milionami wierszy; podobnie dane pochodzące z dziesiątek źródeł ustrukturyzowanych i nieustrukturyzowanych są zupełnie inne niż starannie uporządkowane tabele w bazie danych SQL. Wizualizacja danych na wysokim poziomie to jedna rzecz (na przykład aplikacja e-commerce, która wyświetla ruch i sprzedaż sprzedawcom), podczas gdy zaawansowane analizy, analizy i raporty z możliwością dostosowania wymagają zupełnie innych możliwości.
Jeśli chodzi o tego rodzaju bardziej zaawansowane przypadki użycia, koncepcja jednego uniwersalnego rozwiązania jest nierealistyczna: funkcje analityczne będą musiały zostać zintegrowane z istniejącą aplikacją i dostosowane do konkretnych potrzeb konkretnego produktu oraz baza klientów w zakresie modelowania danych, bezpieczeństwa, zarządzania i raportowania. Ponownie, nie oznacza to, że te wysiłki integracyjne muszą być nadmiernie skomplikowane lub wymagać obszernych zasobów programistycznych - będą jednak wymagały zrozumienia podstawowych danych oraz możliwości łatwego dostosowania i komunikacji z platformą BI za pośrednictwem dostępu API.
Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
Nie możesz poprawić swoich umiejętności programistycznych, gdy nikt nie dba o jakość oprogramowania.
Partnerstwo, a nie jednorazowa transakcja
Decyzja o wykorzystaniu zewnętrznego dostawcy do osadzania analiz jest bardziej podobna do partnerstwa niż do zakupu typu „weź i zapomnij”. Deweloper i dostawca BI współpracują w celu zbudowania wymaganego produktu danych i kontynuują współpracę w miarę dojrzewania produktów, dodawania nowych funkcji i pojawiania się nowych potrzeb.
Czy to oznacza, że programista będzie musiał polegać na dostawcy BI przy każdej zmianie lub dostosowaniu? Absolutnie nie - programiści powinni mieć całkowitą niezależność i kontrolę nad własnym produktem. Powinny być wyłącznym właścicielem produktu od początku do końca i móc je rozwijać we własnym zakresie, bez konieczności polegania na profesjonalnych usługach dostawcy lub zewnętrznych konsultantach. Aby osiągnąć taki wynik, programiści powinni współpracować z dostawcą BI, który jest aktywator, zawsze pamiętając o programistach. Najlepsze praktyki obejmują utrzymanie kompleksowego zestawu SDK z doskonałą dokumentacją i zaprojektowanie produktu BI jako otwarta platforma.
Otwarte platformy umożliwiają łatwy dostęp za pośrednictwem często używanych interfejsów API, zapewniając, że oprogramowanie BI jest wystarczająco elastyczne, aby bezproblemowo integrować się z istniejącymi systemami programistów, i uwzględniać określone potrzeby i wymagania dotyczące źródeł danych, bezpieczeństwa i podobnych kwestii. A w przypadku naprawdę złożonych, ciężkich wdrożeń - najlepsi dostawcy BI zapewniają profesjonalne zasoby potrzebne do jak najszybszego uruchomienia klientów i rozwiązania różnych problemów konserwacyjnych, które nieuchronnie się pojawią.
Ponadto obie strony powinny postrzegać swoje relacje jako długoterminowe - nowe funkcje wprowadzane na platformie BI powinny zawsze być budowane zgodnie z podejściem „najpierw API”, umożliwiając twórcom aplikacji szybkie i łatwe włączenie tych funkcji do własnej oferty; komunikacja między dostawcą BI a deweloperem aplikacji musi być otwarta i częsta, aby obaj mogli lepiej zrozumieć mocne strony i ograniczenia drugiej strony oraz odpowiednio dostosować działania związane z programowaniem, wsparciem i zarządzaniem kontem.
Zrozumienie wbudowanej analizy jako ciągłego partnerstwa, a nie jednorazowego zakupu, sprawi, że programiści będą zadawać bardziej odpowiednie pytania przed rozpoczęciem osadzonego projektu BI; i skłonić dostawców BI do poważnego zaangażowania w budowę naprawdę otwartych platform, utrzymując doskonałą obsługę klienta i dokumentację. W takich przypadkach wszyscy mogą skorzystać.