У цій публікації в блозі ми маємо честь поділитися знаннями запрошеного автора та експерта з аналітики Майка Норріса щодо планування та підводних каменів, щоб уникнути вашої ініціативи модернізації аналітики.
Розглядаючи ініціативу з модернізації аналітики, слід дослідити кілька питань ... Зараз справи працюють, то чому це робити? Який тиск очікується? Якими мають бути цілі? Чого слід уникати? Як повинен виглядати успішний план?
Навіщо модернізувати Analytics?
У Business Analytics інновації впроваджуються з безпрецедентними темпами. Існує постійний тиск, щоб використовувати "що нового" та гаряче. Hadoop, Data Lakes, Data Science Lab, Citizen Data Analyst, Самообслуговування для всіх, розуміння зі швидкістю мислення ... тощо. Звучить знайомо? Для багатьох лідерів це час, коли вони стикаються з великими рішеннями щодо інвестицій. Багато починають нові шляхи, прагнучи надати більше можливостей, і не встигають. Інші намагаються пройти шлях модернізації і намагаються утримати зобов’язання керівництва.
Багато з цих спроб модернізації призводять до додавання нових постачальників, технологій, процесів та пропозицій аналітики. Ця форма модернізації забезпечує швидший початковий виграш, але залишає технічні борги та накладні витрати, оскільки зазвичай не замінює існуючу частину аналітичної головоломки, а накладає їх. Ці типи «модернізації» є скоріше стрибком, а не тим, який я вважав би «модернізацією».
Ось моє визначення того, що я маю на увазі, коли я говорю про модернізацію в контексті аналітики:
«Модернізація - це вдосконалення аналітики, яку ми вже маємо, або додавання функціональних можливостей до існуючих технологій. Модернізація завжди робиться для досягнення мети вдосконалення. Цілі слід визначати шляхом партнерства між спільнотою користувачів та керівництвом ІТ/аналітики ».
Ці цілі можуть бути такими:
- Поверхневий - кращий сексуальний контент або покращений досвід користувача.
- Функціональний - покращена продуктивність або додаткові функціональні можливості
- Розширення - надання вбудованого досвіду або додавання додаткових проектів та робочого навантаження.
Протягом моїх понад 20 років у сфері бізнес-аналітики я працював із сотнями компаній та організацій, допомагаючи та консультуючи їх у питаннях встановлення, оновлення, конфігурації та стратегічних планів та проектів. Мені часто боляче, коли я спізнююся, бути носієм дози реальності під час проектів модернізації. Тому багато починають без плану або гірше, з планом і без підтвердження цього плану. На сьогоднішній день найгіршими є ті, які були поєднанням модернізації ІТ та Analytics як масштабного проекту «все в одному».
Тиск на очікування та подолання
- Все має бути Cloud & SaaS - Хмара має багато переваг і є очевидним вибором для будь -якої нової стратегії та інвестицій. Перенесення всього від локального до хмарного, тому що це стратегія компанії в поєднанні з «датою» - погана стратегія і походить від поганого керівництва, що працює у вакуумі. Переконайтеся, що переваги та будь -які наслідки зрозумілі перед реєстрацією на побачення.
- Єдине джерело всього - Так, є компанії, які можуть надати вам все необхідне. Постачальник з одного джерела може продати вам переваги, але вони реальні чи сприймаються? Простір аналітики в основному був відкритим і неоднорідним, що дозволяє вам бути найкращими в породі, тому зробіть розумний вибір.
- Новіші продукти краще - Новіші рівні краще можуть працювати для автомобілів, але зазвичай не з програмним забезпеченням, якщо це не еволюція пропозиції. Постачальники з багаторічним досвідом та історією в реальному світі не встигають, але це є вагомою причиною. Ці постачальники, як правило, мають надійну пропозицію, з якою інші не можуть зрівнятися, і ця пропозиція має значно більшу цінність протягом усього життя, оскільки їх використання зростає. Так, певні затримки, але це не завжди свідчить про необхідність заміни. У багатьох випадках може існувати кілька частин, якщо розділові лінії чіткі.
- Поспішаючи гігантського результату - На жаль, відведений час рідко буває точним, тому добре мати віхи та менші плани з визначеними перемогами, щоб показати значний прогрес та результати.
- Все буде набагато швидше - Це велика мета та прагнення, але не завжди реальність. Пропозиція архітектури відіграє величезний фактор, а також те, наскільки якісно виконана будь-яка інтеграція та спільне розташування навколишніх залежних та допоміжних послуг та функцій.
- Модернізація тепер майбутнього підтверджує нас - Як я вже говорив у відкритті, інновації летять, тому це сфера, яка продовжуватиме розвиватися. Завжди будьте в курсі того, що маєте, і переконайтеся, що оновлення плануються. Після будь -яких оновлень оцініть нові функції та функціональні можливості, які потрібно використати або зробити доступними.
- Модернізація - це лише «оновлення», і це буде легко - Його модернізація не модернізація. Це означає оновлення, оновлення, заміни та використання нових функцій та можливостей. Спочатку оновіть, а потім використовуйте нові функції та можливості.
Підготовка плану модернізації Analytics
Перш ніж робити будь -які зусилля з модернізації, я б запропонував зробити кілька речей, якими я поділюся, щоб допомогти покращити показники успіху.
1. Визначте цілі.
У вас не може бути такої мети, як "Надати швидке, безперебійне джерело красивої аналітики, що дозволяє легко споживати та створювати контент". Це чудово звучить мета отримати схвалення проекту, але це загальна мета, яка загрожує небезпекою та приреченістю… вона просто занадто велика. Зосередьтесь та створіть цілі для однієї технологічної зміни одночасно з бажаним результатом. Модернізацію у багатьох випадках потрібно проводити поштучно і досвід за досвідом. Це означає більше менших проектів та цілей.
Люди будуть стверджувати, що це означає більше часу та загальних зусиль і, можливо, забагато змін для користувачів. З мого досвіду, так, цей план буде виглядати довше, але він більше відображає фактичний час, який все одно займе. Що стосується частоти зміни користувацького досвіду, це можна вирішити, не передаючи результати до виробництва, поки у вас не буде повного набору змін, які мають сенс. Плани модернізації "зроби це все відразу", які я бачив, тривали на 12-18 місяців довше, ніж очікувалося, що пояснити набагато важче. Гірше - тиск, який чиниться на команду, яка виконує план, і постійний негатив, що виникає через труднощі на шляху. Це також призводить до великих обертів, що призводить до стрибків.
Найважливішою причиною зосередження уваги на менших змінах є те, що якщо ваша аналітика по дорозі ламається, то набагато швидше і простіше вирішувати проблеми та вирішувати будь -які проблеми. Менша кількість змінних означає швидше вирішення проблеми. Я знаю, що це звучить просто, але я скажу вам, що я працював з більш ніж однією компанією, яка вирішила докласти зусиль до модернізації монстрів, де:
- Аналітичну платформу слід було оновити
- оновлено технологію запитів
- аналітична платформа переміщена в хмару
- метод автентифікації замінено на веб -провайдера єдиного входу
- постачальник бази даних змінився і перейшов від локальної моделі, що належить та експлуатується, до рішення SaaS
Коли все не працювало, вони витрачали купу часу і зусиль на визначення того, що викликає проблему, перш ніж приступити до фактичного вирішення. Врешті -решт, ці проекти «зроби це все одночасно» протікали з часом та бюджетом і давали неоднозначні результати через часткові досягнення мети та негатив, що оточував проект. Багато з них до кінця стали проектами «якнайшвидшого запуску».
2. Побудуйте план для кожної мети.
План повинен включати дані ВСІХ зацікавлених сторін для прозорості, повноти та точності. Моїм прикладом тут може бути зміна технологій баз даних. Деякі постачальники пропонують сумісність з іншими постачальниками, і це допомагає у продажах, коли вони говорять про час для цінування. Кожен постачальник баз даних також намагатиметься відстоювати свою позицію про те, що він працює краще, ніж діючий. Питання в тому, що ці твердження не збігаються. Я ще не бачив переходу робочого навантаження від однієї технології бази даних до іншої, використовуючи сумісність постачальника та покращуючи продуктивність наявних робочих навантажень.
Крім того, при зміні постачальників / технологій баз даних ви майже напевно отримуєте різні рівні сумісності з SQL, відкриті функції бази даних та різні типи даних, що все може завдати шкоди існуючим програмам, які розміщені зверху. Справа в тому, що план має бути підтверджений людьми, які можуть вивчити та визначити ймовірний вплив такої серйозної зміни. Щоб пізніше усунути сюрпризи, необхідно залучити експертів.
3. Плануйте плани.
Оскільки всі цілі розриваються, ми можемо виявити, що деякі з них можуть працювати паралельно. Під час використання платформи аналітики ми можемо виявити, що різні групи чи бізнес -одиниці використовують різні базові компоненти, такі як бази даних, які мають бути модернізовані, тому вони можуть працювати паралельно.
4. Вивчіть усі плани аналітично та приберіть.
Це такий важливий крок, який багато хто пропускає. Я прошу вас використовувати будь -яку аналітику, яка у вас є, проти вашої аналітики. Це ключ до того, щоб не витрачати час і ресурси. Визначте, які дані мертві, який вміст у вашій аналітичній платформі більше не використовується або не є актуальним. Ми всі створили аналітичні проекти або контент для одноразового завдання, але більшість з нас також не в силах видалити його або прибрати за собою. це є digital вміст, який нічого не коштує просто залишити до того моменту, коли комусь доведеться його підтримувати, оновлювати або модернізувати.
Чи шокувало б вас дізнатися, що 80% вашого аналітичного вмісту мертво, не використовується, замінено новою версією або тривалий час порушується без скарг? Коли ми востаннє перевіряли?
Не розпочинайте жодного проекту, який вимагає перевірки аналітичного вмісту, не переглядаючи, що потрібно перевірити, а що очистити чи викинути. Якщо ми не маємо жодної аналітики для використання проти аналітики, то придумайте, як рухатись далі.
5. Оцініть, що проект модернізації та індивідуальні плани цілісно завершені.
Повернемося до поганої мети: «Забезпечити швидке, безперебійне джерело красивої аналітики, що дозволяє легко споживати та створювати контент», і зламаємо її з високого рівня. Ймовірно, відбудеться зміна інфраструктури для обробки пам’яті та диска, оновлення або зміна бази даних, перехід на сучасну технологію провайдера єдиного входу, наприклад SAML або OpenIDConnect, а також оновлення або оновлення платформи аналітики. Це все хороші речі і допомагають модернізуватись, але ми повинні пам’ятати про це кінцеві користувачі - зацікавлені сторони. Якщо ці користувачі отримують той самий контент, що й роками, але тільки швидше, то рівень їх задоволеності, ймовірно, буде мінімальним. Прекрасний контент не може бути призначений лише для нових проектів, і його слід доставляти до нашої найбільшої групи споживачів. Модернізація наявного вмісту рідко дивиться, але має найбільший вплив на користувачів. Це особливо важливо для адміністраторів або будь -кого іншого в команді, яка підтримує платформу аналітики. Не підтримувати цих кінцевих користувачів щасливими результатами в інших інструментах, щоб обійти те, що надає команда, і кінцеві результати, можливо, були катастрофічними. Я розгляну цю тему у своєму наступному блозі за кілька тижнів.
6. Остання порада.
Часто робіть резервні копії та не робіть проект модернізації лише у виробництві. Витратьте зусилля на створення імітованого виробничого середовища для великих масштабних змін. Це знову -таки допоможе мінімізувати змінні та відмінності між тим, що працює за межами та всередині виробництва.
Удачі вам у вашій власній подорожі модернізації!
Маєте запитання щодо власної ініціативи модернізації? Зв'яжіться з нами обговорити ваші потреби та як ми можемо допомогти!
