На сьогодні вже давно і міцно увійшли в наше життя хмарні (cloud) додатки. Чи не всі великі виробники ПЗ надають своїм клієнтам web-based програми поряд з класичними завантажуваними додатками для ПК, або мобільних пристроїв, що працюють з власною інфраструктурою підприємства (on-premise).
Важко уявити собі хоча б один день сучасної людини зайнятої в ІТ без використання, наприклад, Gmail. Точно також і сучасний Enterprise в силу сучасних вимог частину своїх процесів переносить в SaaS. Тут і далі під SaaS мною будуть передбачатися в першу чергу хмарні додатки, пропоновані різними компаніями по платній підписці. Такого роду сервісами можуть бути: поштові служби, CRM системи, офісні додатки тощо. Найчастіше системи, що віддаються на відкуп в SaaS, не вимагають складних інтеграцій з великою кількістю інформаційних систем підприємства, а значить, обсяг інформаційного обміну між SaaS платформою і корпоративним середовищем може бути мінімізований. Очевидно також, що хмарні додатки потенційно мають більший успіх серед підприємств меншого розміру в силу специфіки бізнес-процесів і спрощеної самої процедури впровадження.
Але я хочу зупинитися на іншому аспекті. Яким може бути головний ризик для підприємства передачі того чи іншого бізнес-процесу на відкуп в SaaS? Найперша проблема, яка лежить на поверхні і відразу озвучується клієнтами - витік внутрішніх даних на бік, тобто питання безпеки і довіри компанії-постачальнику SaaS рішення. Чи є що-небудь ще не настільки очевидне, але не менш значуще для компанії, яке разом може поставити хрест на міграції в хмару? Є, і я постараюся показати такий приклад.
Волею доль наша невелика компанія довгий час використовувала один популярний зарубіжний сервіс, скажімо так, онлайн-таблиці. На зорі запуску його можливості були не настільки вражаючими в порівнянні з тим же Google Docs. Але час минав, сервіс розвивався, зростав і ми користувалися ним регулярно. Скажу відразу, що сервіс закордонний і досить великий, отже, кількість його передплатників обчислюється десятками і сотнями тисяч. Безкоштовних підписок немає, тільки trial період, після якого обов'язково доведеться що-небудь купити. Сервіс орієнтований на бізнес користувачів, а не на приватних клієнтів, для них існує той же Google Drive. На сьогоднішній день він входить в TOP 3 у своїй ніші, тому його приклад найбільш показовий.
Як відбувається оновлення ПЗ у разі хмари? Існує два варіанти з тих, що я зустрічав:
Варіант 1 - компанія повідомляє своїх клієнтів про невелике вікно downtime тривалістю не більше 1-2 годин. Причому всі розуміють, що так як сервіс в першу чергу орієнтований на бізнес, то таке вікно, як правило, планується в ніч з суботи на неділю або з неділі на понеділок.
Варіант 2 - сервіс оновлюється без downtime, просто одного разу входячи в систему користувач отримує банер з підказками про нові функції (або віддалених старих).
Як би там не було, варіант 1 або варіант 2, проблеми виникають наступні:
1. Планування оновлення системи не залежить від користувача системи;
2. Користувач не знає заздалегідь як функції будуть додані, а які виключені;
3. Найчастіше про оновлення і новий функціонал користувач дізнається за фактом його звершення.
Якщо з першим пунктом ще можна змиритися, то другий і третій змушують задуматися: а як ризикує бізнес отримуючи оновлення функціоналу використовуваного ним сервісу? Як це може позначиться на його приватних бізнес-процесах (БП)? І, головне, що робити, якщо реалізований БП або його частина на SaaS сервісі раптом вийде з ладу?
У випадку з локальним ПЗ все вирішується дещо простіше, у бізнесу (а точніше в ІТ в його особі) існує як мінімум дві опції:
1. Тестування нової версії ПЗ в ізольованому середовищі (тестовій зоні) з метою відпрацювання основних сценаріїв;
2. Відкат на стару версію ПЗ, якщо в новій виявлені критичні для бізнесу недоліки. Благо повсюдне проникнення віртуалізації дозволяє здійснити цей процес за кілька хвилин.
Повертаючись до мого прикладу. У використовуваному нами Excel-подібному сервісі була така функція - ведення дискусій по рядку таблиці. Її особливістю було те, що в рамках дискусії можна було організувати кілька гілок обговорення. Передплатники отримували кожен свої повідомлення і якось це працювало, люди користувалися. Для нас особисто даний функціонал був не затребуваний, тому я на нього не звертав ніякої уваги.
В один прекрасний день компанія вирішила оновити сервіс і спростила користувачам життя, перейменувавши дискусії в коментарі і зробивши їх всі однорівневими. Тобто тепер на кожен рядок таблиці можна вести тільки одну гілку обговорення куди звалюється все. Більше того, всі старі дискусії були перетворені до цього нового виду і назад вже дороги немає. Зрозуміло, після оновлення всі користувачі отримали повідомлення про настільки прекрасну і зручну функції. І ознайомилися вони з ним, звичайно ж, у понеділок, коли прийшли на роботу. Виявилося, що багато користувачів (компанії) всерйоз застосовували гілки дискусій для якихось своїх внутрішніх процесів. Для них даний функціонал був бізнес-критичним. Що вони отримали після оновлення - зламаний бізнес-процес. У когось він був чисто внутрішнім, а у когось на нього було зав'язано обслуговування клієнтів. Про це все я дізнався прочитавши community форум після чергового оновлення, де люди в фарбах описували, як вони вибудовували свою роботу на попередній версії сервісу і чому вони не можуть працювати також тепер.
Що компанія, яка використовує даний SaaS сервіс, може зробити з цим? Тільки адаптуватися до нових правил гри, причому по живому. Де гарантія того, що одне з наступних оновлень не зламає що-небудь ще? Такої гарантії ніхто не дасть. І це тільки приклад досить простого табличного сервісу. У випадку з більш складними системами, такими як CRM, можна собі уявити з чим можна зіткнутися. Чи думали про таких клієнтів компанія-виробник SaaS? Можливо, але вважали їх кількість нікчемною і сам функціонал не настільки важливим.
В результаті компанії, що використовують цей сервіс, зіткнулися обличчям до обличчя відразу з двома проблемами, про які я говорив вище:
1. Нова версія сервісу ламає функціонал, який був доступний раніше. Клієнт дізнається про це тільки за фактом оновлення системи.
2. Відкат на стару версію ПЗ неможливий. У гіршому випадку дані вже перероблені в новий вид і повернути їх старому можливо тільки відновленням резервної копії.
Сервіси SaaS не підконтрольні клієнтам і їхня робота не прогнозована. Вони не можуть використовуватися як ключові для реалізації істотних БП компанії. Через об'єктивні причини компанія виробник SaaS не може задовольнити 100% вимог усіх своїх клієнтів, а значить, частина клієнтів неодмінно зіткнуться з обмеженнями і їм доведеться вирішувати, готові вони з ними миритися чи ні. Оновлення ПЗ в SaaS - це процедура, прихована від клієнтів, за нею можуть послідувати незворотні зміни в роботі сервісу, а також зміни в збережених клієнтських даних. Найгірше те, що клієнт дізнається про це тільки за фактом проведеного оновлення системи і повернутися назад він вже не зможе.
Можливо, в деяких SaaS системах передбачено якийсь graceful період, коли клієнт може змигрувати свої дані в нову версію платформи і випробувати її роботу. Але навіть якщо така можливість передбачена, то виробник не зможе довгий час підтримувати обидві версії - стару і нову, а значить, клієнт, зіткнувшись з обмеженнями нової версії, буде змушений приймати рішення - йти до альтернативного постачальника SaaS, або міняти БП під нові реалії платформи.
Враховуючи все вищесказане, робота з SaaS сервісами виглядає швидше як якесь тимчасове рішення для невеликих і динамічно зростаючих компаній, в яких БП ще не жорстко сформульовані і SaaS сервіс додає деякий ступінь автоматизації, в разі втрати якої компанія цілком може впорається ручною працею і міграція на іншу платформу не сильно витратна. Можна передбачити безліч позитивних відгуків про використання SaaS, але чи стикався реально хто-небудь з проблемами в оновленнях? Якщо поки немає, то, можливо тому досвід використання хмари суцільно позитивний?
