×Закрыть

Як ми робили проект з digital transformation, або Про розуміння клієнта

Мабуть, я не відкрию великої таємниці, якщо скажу: коли вам обіцяють, що проект простий і ви тихенько зробите його за три місяці, не вірте. Краще множте терміни у 3-5 разів. Запасайте декалітри кави. Набирайтесь терпіння. Готуйтеся до пригод із документацією. Якщо обіцянки справдяться, то раніше відпочинете. А як ні — будете морально загартовані.

Отже, я працюю System Architect у EPAM Ukraine. Нещодавно ми успішно завершили проект з digital transformation однієї голландської компанії. Як ви вже, певно, здогадалися з попереднього абзацу, «успішно» не означає «просто». Розкажу, як ми допомогали трансформувати бізнес і міксували DevOps best practices з мистецтвом комунікацій.

Передісторія

Наш замовник — B2B-постачальник повнофункціональних метеорологічних рішень. Простіше кажучи, вони продають опрацьовані метеорологічні дані, в тому числі у вигляді гарних картинок, які ми потім дивимося у прогнозах на ТБ.

Спочатку було три різні компанії у трьох різних країнах. Потім голландці забрали дві інші під своє крило. І вже тоді встигли створити собі задачку на майбутнє. Головна компанія не стала перебудовувати інфраструктуру своїх надбань і залишила її, як є. Так само, як і людей. Новоутворений холдинг став схожий на клаптикову ковдру, де кожен шматок займався чимось своїм, а з іншими скріплявся грубими стібками. Через це, звичайно, виникало багато проблем із міграцією даних. Зокрема, з тією швейцарською компанією, яка згодом потрапила до нас у вигляді проекту.

Система підрозділу, який відповідав за збір метеорологічних даних, дуже складна. У їхню інфраструктуру потрапляють необроблені дані відразу з п’яти потоків. А три різні бази даних інфраструктури, до прикладу, були підключені до одного програмного забезпечення, яке в свою чергу підключене до іншого.

Дата-центр підрозділу обробляє сирі дані та розподіляє їх на два окремих продукти: дані з малюнками та анімацією, що продаються клієнтам, та відео із прогнозом погоди. А ще ж є показники, які отримують із супутників та метеорологічних станцій.

Справа в тому, що навіть після юридичного об’єднання ця підкомпанія продовжувала жити своїм життям. Вони розміщували інфраструктуру в дата-центрі буквально навпроти офісу, причому за шалені гроші. Тільки ISP коштував компанії сотні тисяч євро. А щомісячна плата складала десятки тисяч євро плюс додаткові витрати на його підтримку.

Життя новоутворених холдингів бентежне, але бізнес є бізнес. І наш майбутній замовник вирішив, що хоче не просто продавати метеорологічні дані, а створювати круті продукти на їхній основі. Наприклад, уточнювати та гіперлокалізувати прогнози до масштабу майже 2 на 2 км. Але перш ніж братися за інновації, необхідно було укріпити тили і навести лад у back-end. Для цього CTO замовника запустив програму Cost Saving. Її мета — через вихід у хмару відмовитися від інфраструктури, розкиданої по різних дата-центрах і зекономити кількасот тисяч доларів на рік. Причому то мав бути не лише перенос, а і грамотна оптимізація. Із цією задачкою вони прийшли в EPAM.

Неприємні сюрпризи

Проект потрапив до мене як терміновий. З клієнтом уже були попередні домовленості, залишалося розставити крапки над «і» та починати працювати.

Спочатку на проект виділили три місяці. Я поїхав до замовника, і його CTO відразу мене заспокоїв: «Не переживай, у нас кейс простий. Є дорогий дата-центр у Швейцарії, і нам треба швиденько перенести все, що там є, у клауд і таким чином зрізати кости». Він називав це «shift & lift». Я зрадів, але сказав: «Давайте подивимось». І почав дивитися.

Тут почалися сюрпризи.

З невідомих нам причин стейкхолдери почали залишати швейцарський дата-центр, у якому вони працювали і в якому утримувався шматок компанії. Пішов і CTO, замість нього взяли нову людину, яка тільки переймала справи. Переносити інфраструктуру без тестування було неможливо. Обіцяний «shift & lift» залишився у моїх мріях — людей, які могли щось розповісти, ставало все менше. До того ж нас чекав цілий букет із старого заліза, legacy-систем та рішень.

Оцінивши ситуацію, я зрозумів, що в три місяці ми не вкладемося. Зібрав команду із 7 людей. Ми по маленьких шматочках почали збирати інформацію щодо організації інфраструктури і вибудували часткову структуру. Але зіштовхнулися з однією великою проблемою — монолітністю: варто відключити один сервіс, помирають усі інші.

Щоб зрозуміти, що коїться із сервісами, необхідно було зрозуміти, звідки почати. Ми довго крутилися, зняли снепшоти з усіх існуючих машин, намагалися збагнути, що і як працює всередині, але даремно. Люди, які могли щось пояснити, то звільнялися, то йшли у відпустку або мало відповідали.

Ми зрозуміли, що чекати допомоги немає звідки. Треба було робити повний реверс інжиніринг.

Пробиваючи стіни

Через людський фактор ми мали найбільше веселощів. Так як у компанії офіційно оголосили digital transformation, у якому наш проект брав участь, люди думали, что їх просто звільнять після закінчення. І хоча насправді це було не так, ми скрізь натрапляли на «лежачих поліцейських».

У клієнта дуже багато всілякого legacy staff, який вони так і не мігрували у хмару та не автоматизували. Команда, яка займається data flow і сидить на всіх цих legacy, прекрасно розуміла, що ми можемо автоматизувати все, що вони нині роблять руками. І вони стануть просто не потрібні. Хоча в нас і в планах такого не було.

З командою operations виникали інші нюанси. Там є люди, які працюють багато років. І вони не дуже хотіли переїжджати на новий стек технологій Amazon, бо не особливо з ним знайомі. У них у дата-центрі кілька машин працювало на старому Oracle, і перемігрувати його на Amazon повністю вони не захотіли. Мовляв, хай буде, як є. Причина — «тому що ні».

Такий супротив ми зустрічали практично в кожному департаменті, поки не показували, як після міграції все автоматично працює. Врешті-решт, з усіма структурами це допомогло.

Інша причина — був окремий вендор, який займався виключно підтримкою Oracle. Замовник передав їм інструкцію, що необхідно зробити, щоб перенести Oracle. А фактично все зробили ми: підготували машину, засетапили, зробили в Amazon усі правила. Єдине, що зробили люди вендора — інсталювали Oracle и перенесли туди дані. На листування із вендором з поясненнями та переконаннями ми витратили в цілому близько чотирьох місяців.

Останню стінку ми пробивали лобом уже безпосередньо перед закінченням проекту, коли його треба було продовжити, щоб нормально закінчити та передати. Для цього нам дали ще одну частину інфраструктури. Це називалося broadcasting — коли картинки накладаються шарами один на інший, і завдяки даним повністю вимальовується прогноз погоди. На цьому етапі проект виглядав безхмарним, а ми були налаштовані оптимістично. Проблем ми не очікували, адже спілкувалися із knowledge keeper, який охоче ділився інформацією та обіцяв невдовзі передати всі необхідні дані.

Та скоро наш оптимізм погас. Knowledge keeper став невловим Джо, а обіцяні дані ми так і не отримали. Наша команда намагалася заходити з різних сторін, щоб отримати необхідну інформацію, якої не вистачало, та наші спроби розбила перевантаженість замовника. Як результат, фейлили дедлайни. Врешті, ми передали цю частину проекту фактично та практично готовою, але не переключеною до кінця в продакшин.

Смішно, але тут ми знову зустрілися з вендором по Oracle. Незважаючи на те, що один раз ми їх уже «перемогли», історія повторилася. Уявіть собі e-mail thread на 4-5 моніторів (у згорнутому виді). Отакий у нас був діалог по маленькій справі. Але ми люди терплячі, розуміли, що працюємо з різними людьми. І повільно, але впевнено все це рухали.

3 -> 6 -> 15

Ми поділили команду на шари: хтось займається скриптами, хтось — даними, хтось — потоками. Щоб покрити ризики всередині хоча б нашої команди, ми робили свої внутрішні сесії, де ділилися один з одним, хто що знає, як що працює. І все документували. Це допомогло підстраховувати один одного, коли хтось ішов у відпустку або був відсутній за сімейними обставинами.

Урешті-решт, ми знайшли, куди йдуть дані, і з цієї ниточки почали «розслідування». Оскільки компанія заробляє на постачанні консолідованих і оброблених даних, наша команда розбиралася саме з data flow. На цьому етапі було дуже важливо показати клієнту, що в нас є експертиза, що ми можемо з цим розібратися (до речі, за рахунок досвіду команда наша була в два рази менше, ніж та, яку зазвичай будують на таких проектах).

Коли ми повністю розібрали топологію мережі і те, що коїться в їхньому швейцарському дата-центрі, клієнт нам повірив.

Я одразу говорив, що це не буде просто і забере мінімум рік. Завжди давав апдейти, ходив на transformation-мітинги до клієнта. Розповідав усе, як є. Тому нам подовжували проект. Початковий контракт збільшили до півроку, а потім одразу ще на півроку.

Технології

Для Infrastructure-as-a-Code ми використовували SparkIFormation, для automated provisioning (CM) — Puppet, тому що він уже був присутній, але працював лише для створення юзерів і не був допрацьований у тому масштабі, щоб його можна було використовувати повноцінно.

Для моніторингу ми використовували Icinga. Для трекання карток беклогів — Trello плюс Confluence для зберігання даних та knowledge transfer. Для деплойментів — Jenkins та Bamboo. Бази даних у них були MySQL, ми перенесли їх в Amazon RDS. Також був Oracle, який ми теж перенесли та автоматизували (не без пригод, як я згадував трохи вище).

Результати

Проект закінчено у серпні. Ми переключили все на структуру Amazon. Повністю автоматизували все в DevOps best practices. Зробили повний reverse engineering до рівня бібліотек. Перемістили та перейшли на AWS, впровадили сучасний технологічний потік, зменшили ризики інфраструктури. Зробили так, як початково і хотів замовник: однією кнопкою все (або частина інфраструктури) піднімається та опускається. Ми залишили Disaster recovery plan, все задокументували і зробили knowledge transfer сесії.

Як я казав вище, за старий дата-центр компанія платила десятки тисяч євро на місяць плюс додаткові ресурси на підтримку. Після виходу в продакшн через півроку клієнт почне окупати інвестиції. Нам вдалося скоротити витрати в чотири рази. Також клієнт забув про головний біль мануальної роботи.

У цьому проекті величезну роль відіграла вся наша команда. І те, що ми всі разом працювали як один злагоджений механізм, дало нам можливість досягнути результатів, про які я зараз розповідаю. Не відкрию велику таємницю, коли скажу, що над командою теж треба працювати — створювати комфортні умови, ділитися знаннями, давати повне розуміння ситуації та підтримувати і мотивувати. Те ж саме треба вибудовувати і в стосунках із клієнтом. У нашій ситуації дуже важливо було знайти взаєморозуміння з клієнтом, а з самого початку це було достатньо складно. До нас приглядались, мовчали, говорили: «Ну, може бути». Треба було показувати результат, причому дуже хороший.

Один головний висновок

Треба зрозуміти клієнта.

Поділюся своїми трьома порадами у роботі з клієнтами, які я виніс з цього проекту:

1. Ставте себе на місце клієнта

Причому треба зрозуміти саме того клієнтського представника, з яким працюєш безпосередньо — власну точку контакту. Щоб побудувати з ним комунікаційний місток, треба зазирнути в його професійні бажання та страхи. А для повної картини — спілкуватися з людьми, які працюють у цій компанії. Це може звучати банально, але іноді банальностей треба просто дотримуватися — така собі дисципліна комунікацій, яка, як на мене, ні одній команді ще не зашкодила.

2. Дослідіть бізнес клієнта та слідкуйте за змінами

Треба розуміти всі процеси компанії, щоб зрозуміти, чому сталося саме так, хто винний і що робити. Іноді необхідно охопити значно ширші області. Наприклад, оцінити глобальне місце компанії на ринку, стан акцій, нещодавні угоди, загальне інформаційне поле. Можливо, це дасть підказки, які важелі саме зараз дадуть результат.

3. Інтегруйтесь у команду клієнта по максимуму

Щоб зрозуміти, що коїться з компанією-клієнтом, я спілкувався з різними менеджерами, які мали відношення до акаунту. Розпитував, знаходив кінці, вибудовував ланцюжки. Спілкувався з делівері-менеджером — він давав багато підказок, з ким як говорити, з ким можна, з ким не варто. Спілкувався із сусідньою командою сапорту і підтягнув її, щоб мотивувати її і їм було веселіше. Якщо зовсім чесно, ми з початку намагалися врахувати ризики, коли ми завершимо проект. Так і вийшло: ми пішли, а knowledge keepers залишилися, бо були залучені в цей процес.


Наостанок наголошу — communication skill дуже допомагає. Треба думати, розвиватися і дивитися ширше. Це бажано, якщо ви плануєте рости професійно. І абсолютно необхідно, якщо вже займаєте якусь координаційну роль у команді чи проекті. У такому випадку всі ниточки мають бути у вас у кулаці.

LinkedIn

33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

В цій історії цікавим є наступне ...
Ви стверджуєте, що перехід на aws скоротив витрати. Цікаво яким чином?

З свого досвіду, за інших рівних, своє залізо завжди дешевше. У нас один сервер в Волі за 2к$ + тисяча грн/місяць за collocation тягне стільки, що на aws ми б і в 500$ не вписалися б.

AWS може бути вигідно лише в ± динамічній інфраструктурі (сьогодні треба — підняли, завтра не треба — потушили — зекономили) чи в managed сервісах типу S3, lambda, тощо.

Ви ж описуєте досвід перенесення статичної архітектури ... по суті один сервіс на залізі перетворився в той чи інший instance в AWS.

З ваших слів зрозумілим є те, що в замовника, просто, в залізі був повний бардак ще й в овер дорогих датацентрах.

І зробили б ви все без AWS — було б ще дешевше мінімум в 1.5 рази.

Але втратили б, скоріше всього, в деяких процесах, що винрають із-за infrastructure as a service.

Тому, все таки ... на чому ви виграли в ціні, за умов статичної архітектури?

В цій історії, насправді, все дуже цыкаво.
Звачайно ві рахуєте оптимально залізо, а такж умови в Україні і без широкого канала. А тепер уявіть що ви оредуєте офіс і DC біля нього зі своїм залізом, треба оплатити bills + rent + ISP, а до всього ще й слідкувати за залізом, оновлювати його і тд. І це лише поверхня всього — після всього що було зроблено, порахували ROI і ось ця цифра.
Перед тим, як робити оптимізації та кудить щось переносити, треба все ретельно зважити та порахувати , і в даному варіанті ми не програли.
Архітектура була монолітна та скалдна, але після rreverse engineering ми не просто все перенесли, оптимізували, автоматизували — а ще й побили на різні layers, виграли за рахунок всього разом(DevOps bets practises, Cloud Strategy, Iaas, Paas, CM & etc) та досвідченній команді.

В цій історії, насправді, все дуже цыкаво.

Интересные истории надо рассказывать полностью. Например потому что следующая фраза:

А тепер уявіть що ви оредуєте офіс і DC біля нього зі своїм залізом, треба оплатити bills + rent + ISP, а до всього ще й слідкувати за залізом, оновлювати його і тд.

Наводит на мысль что снижения затрат было не за счет «профессиональной опытной скачать без смс команды», а за счет того что __заказчик сам__ отказался от операционных затрат на поддержание своего ДЦ и нанял ЕПАМ для миграции всего в Амазон.

Типичный ад имени отсутствия проектного менеджмента у заказчика

Все искусство заключено в умении давить на вендоров. Кто не умеет — тот разводит умные разговоры. Кто умеет тот давит.
Один быстрый поглощает двух умных

Ноль айти онли бузинесс

Що більше читаю подібні історії, то більше диву даюсь наскільки все це взагалі не пов’язано із ІТ чи навіть із Systems Architecture. TLDR: клієнт попросив digital transformation, і ВИКОНАВЕЦЬ тепер переконує ВСЮ компанію клієнта в тому, що це потрібно, чому це потрібно, як це зробити, і зрештою робить це за них. То може клієнту насправді і не потрібен був ніякий трансформейшен? Ніяк не розумію.
ІТ тут грає роль не більшу ніж кав’ярня в яку ходять «інженери» в перервах між емейл-листуванням. Дякую, не на це я вчився і не це уявляв собі в професії.

То може клієнту насправді і не потрібен був ніякий трансформейшен?

1) Тут пока не видно никакиго трансформейшена.
2) Как правило сотрудники заказчика не очень ради таким трансформациям и включают Генерала Лудда.

Важный момент в том что со стороны заказчика должен был быть высокопоставленный сотрудник, который овнит этот процесс и через которого надо общаться в подобных ситуациях

Цель статьи совсем не мат часть, а понимании всей ситуации, так же как и анализ как работать, с кем и тд. Данный проект был лишь частью трасформации и совсем не значительной, но его успех и результат говорят сами о себе, а для бизнеса еще и экономией денег.

но его успех и результат говорят сами о себе
за три місяці
Початковий контракт збільшили до півроку, а потім одразу ще на півроку.

Если вам пообещают сделать ремонт за 3 месяца, а сделают на 15, будете ли вы считать такой проект успешным?

Никто не говорит о том что дедлайн не был соблюден, его гипотетически выставил CEO клиента — комитмент был дан после полного анализа. Так что если вы хотите родить ребенка с 9-ю женщинами за 1 месяц, а не одной и за 9 — тогда тут возникает вопрос)

Как уже комментили ниже не очень понятно при чем тут «digital transformation» у клиента уже была ИС, которую надо было просто перенести в Амазон.
И тут начинается грусть, ибо я вижу ситуацию так:
От ЕПАМ требовалась экспертиза по AWS и настройка там окружения похожего на то что было.

І вони не дуже хотіли переїжджати на новий стек технологій Amazon, бо не особливо з ним знайомі. У них у дата-центрі кілька машин працювало на старому Oracle, і перемігрувати його на Amazon повністю вони не захотіли.

1) Если под стеком Амазон подразумиватся Аврора, то ЕПАМ «придумалал себе проблем». В чем была проблема просто насроить ЕЦ2 на которую поставят Оракл.
2) Не очень понятно кто был «овнером процесса». Если заказчик, то не понятно как появились емайл-треды. Если ЕПАМ, то почему подписались под работой не понимая/зная что есть другие вендоры.

Читайте внимательно про legacy software & hardware, это не просто переезд или экспертиза в како то области.
Что касательно Oracle — опять же читайте ниже, мы не овнали и даже не супортали(сам Oracle) его, а только готовили инфру и был 3rd party вендор с которым и происходили итеракция.

Читайте внимательно про legacy software & hardware

Я прочитал и не увидел, почему там должно быть что-то больше чем настроить виртуалки, задеплоить и проверить что не потеряли какие-то настройки по дороге.
Не исключено что просто забили на анализ и изученье того что уже есть и подписались под сроками.

Что касательно Oracle — опять же читайте ниже, мы не овнали и даже не супортали(сам Oracle) его, а только готовили инфру и был 3rd party вендор с которым и происходили итеракция.

Тогда к чему тут емейл-треды (если вы не отвечали за перезд Оракла). Подготовили доку, передали заказчику, пусть заказчик управляет процессом перезда.

Мы отвечали за работоспособность всего после переезда, а вендор достался нам в комлекте. Все самое сладкое было под капотом)

Мы отвечали за работоспособность всего после переезда, а вендор достался нам в комлекте. Все самое сладкое было под капотом)

Итого вы провтыкали с эстимейтами, потому что не учли коммуникацию со сторонним вендором.

Мы все сдали вовремя, так как учли все риски и заложили их

А можно в двух словах, что вы там трансформировали?

А можно в двух словах, что вы там трансформировали?

Блокчен трансформировался в АИ путем примененя МЛ на Голанг.

У вас особиста неприязнь до компанії чи автора статті?)

У вас особиста неприязнь до компанії чи автора статті?)

Неповерите, это совпадение. Почему-то сотрудники ЕПАМа очень часто публикуют полную лабуду под интересными мне заголовками.

да это не только епам, щас каждый утюг кричит, что мы там что-то трансформируем. Начинаешь задавать вопросы и получается анекдот:
-Правда ли, что шахматист Петросян выиграл в лотерею тысячу рублей?
— Правда, только не шахматист Петросян, а футболист «Арарата» Акопян, и не тысячу, а десять тысяч, и не рублей, а долларов, и не в лотерею, а в карты, и не выиграл, а проиграл.

Компания застряла в 2000х, как на железках и по софту, и по процессу и структуре и тд. Была выкуплена инвесторами которые инициировали процесс Digital Transformation. Данная статья — это один из подпроектов данного процесса.

Так а к вам это каким боком? Для жёлтого заголовка? Трансформация подразумевает, что вы придумали как из 1-2-3-4 сделать 1-4 и при этом ещё и маржинальность подросла. Переименуйте в «мы гребли рядом с пацанами, которые делали трансформации» будет честнее.

Мы занимались данным проектом в скоупе Digital Transformation, было сделано так что при меньших затратах(намного) клиент получил результат лучше, что собственно говоря и есть с 1-2-3-4 сделать 1-4, уменьшив затраты и увеличив маржинальность

ну так в двух словах расскажете про

1-2-3-4 сделать 1-4

? Все что я вижу в статье — через пень колоду перенесли что-то в cloud соблюдая рекомендации ведущих собаководов. Сорян, но это делает любая шаражка, что у вас тут уникального/интересного, ну кроме того, что вы привираете в заголовках :D
Добавлю, формулировка "

Як ми робили проект з digital transformation

" подразумевает, что трансформация входила в скоуп этого самого проекта и вы ее делали. Например, моделировали бизнес, анлочили там какие-то доп. сервисы или рынки с помощью тех. инноваций. Пока ничего такого в статье не видно.

Мы полностью перенесли DC со старой инфраструктуры и с полным реверс инженирингом в cloud без knowledge keepers, оптимизировали и адаптировали все элементы, так же как и автоматизировали все, положили все в SCM/VCS, описали документацией и сделали knowledge transfer, что позволило сэкономить 75% клиентского бюджета на выходе.
Уникальность в том что вам дали собрать авто и сказали вот сюда мы льем топливо, а на выходе получаем мощь — ну и дали набор деталей, а вы взяли собрали, да еще и оптимизировали и улучшили так, что меньше топлива потребляет, да и едет лучше.

ненене, Digital Transformation, это вот, например. 5 лет назад для вызова такси, мне надо было помнить их номера, обзванивать сколько-то служб, чтобы заказать машину, потом перезванивать если не пришел смс с номером машины и стоимостью поездки, бегать искать водителя по всем подворотням, принципиальная невозможность пошарить фидбек о конкретном водителе с народом и т.д. А теперь у меня есть OnTaxi, где все это делает в 2 клика с минимальным человеческим фактором. Разницу видите? А вы мне что продаете, оптимизировали инфраструктуру? это уже десятки лет как банальщина.

В данном ключе оно выглядит как тех прогресс, а не трансформация — Digital transformation can revolutionize the way you deliver value to your customers and internal end-users by fully harnessing the power of cloud(Microsoft as example) &
Digital Transformation

Digital Transformation (DT) is not necessarily about digital technology, but about the fact that technology, which is digital, allows people to solve their traditional problems. And they prefer this digital solution to the old solution(WiKi).

На примере, в данной ситуации мы взяли монолитную инфраструктуру и не просто перенесли ее в cloud, а поделили ее на layers, сбалансировали, автоматизировали, усовершенствовали и тд, стабилизировали работоспособность, навесили мониторинг — а по факту убрали клиенту головную боль по поддержке и еще −75% затрат.
Сама суть трансформации данного проекта в архитектурной трансформации а не просто перенос всего в cloud, что и есть value для клиента и его бизнеса.
Старая система была legacy и требовала много человекочасов суппорта + дорогой DC + обслуживание железа, да и без людей с особым знанием всего — так как они покинули компанию.

PS Статья не только о Digital Transformation, но и о понимании клиента, его бизнеса и проблем, которые успешно были решены.

в данной ситуации мы взяли монолитную инфраструктуру и не просто перенесли ее в cloud, а поделили ее на layers, сбалансировали, автоматизировали, усовершенствовали и тд

Вот только в вашей статье про это как-то не очень описано. Так же рассказано про то почему именно в вашем случае не сработал «shift & lift». Хотелось бы услышать (в статье) зачем была разбивка на лееры, при миграции в клауд (проект изначально планировали на 3 месяца).

а по факту убрали клиенту головную боль по поддержке и еще —75% затрат.

Еще одна очень интересная тема, не освещенная в статье: Как вы оценивали (на ранних этапах) комплекс мер который привел к такому сокращению затрат? Какие подходы дали наибольшое сокращение затрат?

Статья не только о Digital Transformation, но и о понимании клиента, его бизнеса и проблем

Вот тут проблема: В статье я (и скорее всего Евгений Напрягло тоже) не увидел ничего про Digital Transformation, а прочитал обычную менеджерскую мутотень про куммуникацию с отделами/вендорами компании, которые в этом незаинтересованы.

Скорее всего Digital Transformation в понимании людей разное, сколько людей столько же и мнений, а тем более трактований.
В части результаты есть достаточное описание, к сожалению, еще раз повторюсь, статья не о мат части а об общем и обширном понимании всего процесса и проблемы клиента. Конечно же фин часть, которая интересует бизнес и как считать ROI, безумно интересна — но на эту тему есть действительно много материала.
Можно конечно описать все к мельчайших деталях да и мат часть вписать, но вопросы все равно будут возникать.

вопросы бы не возникали, если бы не громкий заголовок. Я могу voip в офис поставить и сказать, вот Digital Transformation as it is. И формально буду прав. В реальности же, есть так называемые уровни maturity и то, что понимается под этим термином в современных реалиях находится на более высоких уровнях чем то, что изложено в статье.

PS Статья не только о Digital Transformation, но и о понимании клиента, его бизнеса и проблем, которые успешно были решены.

Я думаю вся проблема в тому що стаття написана System Architect-ом, а не ПМ-ом. Тому очікування були побачити технічні рішення, а не про якісь там переписки з вендорами.

Подписаться на комментарии