Блог

Полезные статьи и новости о жизни WaveAccess

Цифровизация крупных компаний: проблемы и перспективы

Отрасли российской экономики стремительно трансформиуются, создаются новые амбициозные программы. “Цифровая экономика” разработана в 2017 году, ее цель — создать условия для системного развития и повсеместного внедрения digital-технологий. “Электронное правительство” оказывает услуги госорганам, бизнесу, обычным пользователям: переводится “в цифру” документооборот между гражданами и органами власти, улучшаются системы поиска по государственным порталам.

Выполняя ИТ-проекты для регионально распределенных компаний в России, мы имеем возможность участвовать в этом прогрессе: занимались модернизацией федерального инвестпортала, создавали и интегрировали подсистемы и целые решения для портала Госуслуг РФ. В частности, недавно участвовали в разработке мобильного приложения для сбора биометрических данных при проведении верификации пользователя в Единой биометрической системе. С его помощью пользователь может дистанционно получать банковские услуги, авторизуясь путем сопоставления голоса и изображения лица с ранее созданным цифровым образом. Наши решения используются в самых разных отраслях: система с машинным обучением для обработки заявок на ремонт и обслуживание, решение автоматизации и мониторинга сельскохозяйственного производства, решение для мониторинга состояния оборудования вентиляции и водоочистки.  

Но на пути цифровизации крупных корпораций остаются препятствия: состояние инфраструктуры, сложные интеграции с существующими системами, объем работ (например, тестирования), необходимость использования только “разрешенного” стека технологий, зачастую — неготовность к цифровизации со стороны кадров и процессов заказчика. 

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

Возможности и преимущества перехода “в цифру” 

Технологии машинного обучения (Machine Learning, ML) и искусственного интеллекта (AI), Интернет вещей (IoT), виртуальная и дополненная реальность (VR/AR) имеют большой потенциал: автоматизация принятия простых решений освободит время дорогостоящих кадров, повысит оперативность, предсказание затратных событий сократит издержки. 

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

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

Препятствия при цифровой трансформации

Одним из препятствий для успешного внедрения технологий может стать неготовность адаптировать корпоративную культуру к изменениям. Встречается и проблема недостаточно высокого уровня организации работы внутренней ИТ-службы, и нехватки специалистов — а ведь для реализации высокотехнологичного проекта требуется вовлечение архитекторов, Data Scientists, Hardware-инженеров, QA-инженеров и других специалистов с редкими компетенциями. Лучше всего с проектом справится подрядчик, у которого в распоряжении достаточное число специалистов в разных областях программирования: от вполне обычного .NET до более редкого ученого по данным (Data Scientist). 

На случай нехватки у заказчика специалистов для успешного старта проекта, подбора технологий или оценки сроков у нас отработан подход “гибридных” команд: технические специалисты заказчика получают в свое распоряжение нашего эксперта, который работает наравне с ними, буквально в одной команде — передавая знания и двигая проект. Когда он свою задачу выполняет, или когда требуется еще какая-то редкая экспертиза, состав команды меняется. К этому подходу можно присмотреться, если не хватает толчка для продвижения проекта. В целом, мы считаем, что заказчика нужно развивать, передавать ему свою экспертизу. Так общий уровень проектов будет повышаться, а понимание вырастет. 

Сюрприз часто ждет разработчиков при столкновении с трудовым распорядком заказчика. У многих ИТ-компаний — гибкий график. Крупные компании, далекие от IT, следуют более традиционному распорядку: например, начинают работу ровно в 9 утра. А это дает 2-3 часа разницы во времени между заказчиком и исполнителем, даже если мы находимся в одном городе. А если прибавить к этому наличие у вашего заказчика региональной технической команды, которая должна проверить ваш релиз? 

“Центр тестирования клиента может вообще находиться в другой части России. Скажем, вы сдали релиз в 11:00 в четверг.  У технической команды заказчика уже 5-6 вечера — почти конец рабочего дня, а завтра — пятница. Но пятница, как мы все знаем, не лучший день для релиза. Хорошим тоном будет показать результат хотя бы в середине недели, давая заказчику люфт для ответа”.  

 —  Александр Азаров, старший вице-президент по разработке ПО в WaveAccess

Порой требования безопасности кажутся нелогичными: скажем, команда заказчика уже протестировала релиз, но обязана оставить его “отлежаться” на 3 дня. Почему? Потому что таков регламент тестирования. Стандарты безопасности — это не только про защиту данных, и они могут замедлить темп цифровизации. Многие компании хранят настолько ценные данные, что у них есть только внутренняя сеть, и передать им что-то онлайн совершенно невозможно. Релизы проходят в закрытой среде: продукт загружается на защищенный физический носитель, инсталлируется на территории заказчика. Если при этом нужно присутствие исполнителя, то при определении сроков нужно закладывать еще несколько дней на получение пропуска на территорию. Впрочем, сегодня уже существуют и успешно применяются практики DevOps, которые могут решить часть этих проблем: например, непрерывной доставки обновлений.

Фраза, которая не может не вызвать стресс, — “у проекта есть скрытые требования”. Это значит, что заказчик еще не решил, что ему нужно от определенной части проекта (какая технология, какая архитектура). И если решение принимается уже в тот момент, когда та самая часть проекта готова — а такое случается — предстоит значительный рефакторинг реализованных технологических решений без изменения сроков. К этому следует быть готовым: иметь дополнительные ресурсы, закладывать и оговаривать увеличение сроков, иметь грамотную команду DevOps, которая сможет реализовать непрерывную интеграцию, ускорить тестирование и передачу версий проекта заказчику. 

Коммуникация между проектными командами 

Мы нередко получаем проекты для восстановления после других команд, так и не  подошедших к желанному релизу. И самая частая причина провала — непонимание подхода к планированию и разработке, а также завышенные ожидания. Чтобы проект не  превратился в подобие империи Александра Македонского, которая пережила распад из-за невозможности скоординировать регионы, нужно грамотно организовать общение. Так, технические команды мы стараемся по максимуму освободить от поиска контактов, согласования звонков и прочей отвлекающей коммуникации: они должны получать конкретные задачи. 

Часто на стороне клиента присутствует много компетентных специалистов, которые могут дать консультацию по использованию уникальных для заказчика технологий, но не участвуют в проекте. Наше правило: разработчик не должен “ловить” специалистов заказчика за счет своего рабочего времени. Да, из-за этого менеджеру приходится вести десятки чатов с различными специалистами в разных мессенджерах. Зато на выходе это дает один самый важный звонок нашего тимлида с заказчиком и двигает проект вперед. 

Зачастую проекты разваливаются из-за завышенных или некорректных ожиданий: риск растет пропорционально количеству вовлеченных ЛПР (а их в крупных корпорациях может быть много). У технологии машинного обучения на этот счет есть отличное решение: на этапе пилотной версии можно заранее, до масштабной разработки, увидеть потенциал технологии, а главное — буквально определить, сколько в денежном выражении принесет внедрение проекта. 

Создав пилотную версию подобной системы, можно заранее увидеть ее потенциал именно в приложении к конкретной и задаче. С учетом стоимости полноценного проекта около 15 млн рублей, выделить 1-3  млн рублей на “пилот” означает вполне осознанное капиталовложение с предсказуемой отдачей (Return on Investment, ROI) и прогнозируемыми сроками.

Цепочка согласований 

Чем крупнее компания — тем сложнее прохождение цепочки согласований, даже если   задача — всего-навсего поправить слово на кнопке прототипа. 

Мы сталкивались и с тем, что согласования проектов у заказчика поручены отдельной службе. А в нашей практике некоторые проекты согласовывали несколько департаментов. Есть и такой момент как согласование стека технологий. На одном из наших недавних проектов по компьютерному зрению согласование заняло три недели, включая время на формирование, обоснование, демонстрацию работы и проверку совместимости с существующими сервисами. В дальнейшем свой регламент будет для большинства технических операций: открытие порта, получение доступа к базе данных, длительность  тестирования. 

Здесь важно обращать внимание разработчиков на регламенты команд заказчика и планировать время заранее так, чтобы его хватило на согласования. 

Производство большого объема документации 

Время команды потребуется еще и на изучение специфики документации: мало того, что объем ее большой, так еще и не с самыми прозрачными правилами оформления, с нетривиальными задачами. А значит, время команды потребуется на изучение специфики. И часто документация требуется к каждой контрольной точке проекта. Перед тем, как погружаться в проект, мы задаем себе вопрос: а хватит ли у нас ресурсов, чтобы подготовить документацию? Ведь порой разработчиков на проекте может быть ровно столько же, сколько технических писателей!

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

Выводы 

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

Управленческие ошибки зачастую ведут к гораздо более серьезным последствиям, нежели непонимание принципов работы той или иной технологии. Во многом успех цифровой трансформации зависит от грамотного планирования и своевременной корректировки завышенных или неверных ожиданий (расчет на мгновенный результат, ожидания по точности работы системы, ожидания по прибыли и др.).  

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

Мы будем рады рассказать о проектах подробнее!

Свяжитесь с нами:

hello@wave-access.com

+7 812 407 2350 

Заказать звонок

Удобное время:

Отменить

Пишите!

Присоединить
Файл не больше 30 Мб.
Отменить