«Верните как было»: чему нас научило внедрение системы Билдокс для работы с исполнительной документацией

Привет, Хабр! На связи команда автоматизации девелопмента — Карасева Лилия и Абражевич Ольга. Мы занимаемся цифровыми сервисами для строительной документации в ПИК и хотим поделиться историей одного внедрения, которое технически выглядело абсолютно правильным, но на практике оказалось намного сложнее, чем мы ожидали.

Эта статья не про «как выбрать систему» и даже не про Билдокс. Она про то, почему технически хорошее решение могут не принять пользователи, снижение рисков несоответствия законодательству не мотивирует бизнес, а внедрение новой системы и внедрение изменений — вообще не одно и то же.

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

Когда «нормально работает» — уже недостаточно

При реализации проектов девелоперы обязаны документировать выполняемые работы и соответствие стандартам качества. Такой тип документации называется «исполнительная» (то есть формируемая в процессе исполнения строительных работ). Несколько лет исполнительная документация у нас жила в «коробочной» системе Тесса, в которой был автоматизирован весь документооборот компании. 

Изначально это казалось вполне логичным решением: единое пространство для работы пользователей и одна система для поддержки технической команды. Но со временем стало понятно, что исполнительная документация слишком специфичная область для универсальной корпоративной системы — вокруг нее начали появляться кастомные процессы и сложные маршруты с большим объемом транзакций. На тот момент через Тессу проходило более 500 объектов строительства и 250 тысяч документов в год. Ежедневно с этими документами в системе работало более тысячи пользователей.

В какой-то момент мы поймали себя на мысли что не «слегка адаптировали систему», а фактически строили внутри универсальной системы отдельный новый продукт со специфическим функционалом, которого в «коробочной» системе документооборота не было.

Параллельно появилась еще одна проблема: в одной системе одновременно жили внутренние процессы компании и внешние подрядчики, что требовало дополнительной защиты информации.

Но стратегически нас догнала совсем другая история.

Стройка начала уходить в XML

Раньше исполнительная документация воспринималась как набор PDF-файлов (сканы). Но отрасль постепенно переходит от модели «документ как файл» к модели «документ как структурированные данные».

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

Он в другом: разумно ли продолжать инвестировать в модель, которая расходится с направлением отрасли?

В нашей ситуации «ничего не делать» не означало «ничего не тратить». Мы понимали, что если продолжим развивать собственную реализацию внутри универсальной системы, то нам придется:

1. постоянно отслеживать изменения законодательства;

2. обновлять XML-схемы;

3. поддерживать интеграции;

4. развивать специализированную функциональность;

5. тестировать все это своими силами.

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

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

С технической и экономической точки зрения решение выглядело абсолютно рациональным:

1. специализированный продукт;

2. регулярное развитие;

3. соответствие отраслевым требованиям;

4. отдельный контур для подрядчиков.

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

«Верните как было»

Технически проект двигался нормально, но «эмоционально» бизнес-пользователи изменения не приняли. 

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

Для команды внедрение выглядело как «мы упрощаем жизнь, убираем риски и готовимся к цифровизации отрасли».

Для пользователей это выглядело как «у нас забирают привычный инструмент, заставляют переучиваться и снова ломают процессы».

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

В Билдокс работа начиналась раньше. Необходимо было связать документ с объектом строительства, работами, материалами и другой документацией. С точки зрения качества данных это был шаг вперед. Но с точки зрения пользователя количество действий увеличивалось, а привычный способ работы менялся.

В какой-то момент мы начали слышать классическое:

• «в старой системе было удобнее»;

• «раньше мы делали это за 2 минуты»;

• «верните как было»;

• «зачем вообще это менять, у нас же работало».

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

Как это выглядело на практике

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

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

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

Из 34 участников опроса:

• только 4 человека оценили работу в системе как удобную;

• больше половины жаловались на скорость работы и увеличение количества действий.

В комментариях к опросу один из пользователей написал: «Серьезно увеличиваются трудозатраты для формирования привычного комплекта ИД».

И вот это слово «привычного» оказалось для понимания проблемы ключевым. Потому что пользователи сравнивали не две системы, а новый процесс с алгоритмом, по которому они работали годами.

Что можно было сделать иначе: взгляд через модель ADKAR 

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

Мы применяли большинство рекомендуемых практик, однако внедрение показало важную вещь: наличие мероприятий по organization change management еще не означает, что изменения будут приняты так, как это описано в методологии.

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

Awareness: пользователи понимают изменения не так, как команда внедрения

На этапе подготовки проекта мы довольно много внимания уделяли объяснению причин изменений.

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

Затем совместно с бизнес-лидерами начали серию коммуникаций с пользователями. Мы проводили встречи, на которых рассказывали:

1. почему компания рассматривает переход на специализированное решение;

2. как меняются требования законодательства;

3. почему отрасль постепенно переходит к работе со структурированными данными и XML;

4. какие ограничения накопились в существующем процессе;

5. что произойдет, если продолжать развивать текущую модель работы.

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

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

Однако мы столкнулись с важным ограничением подобных коммуникаций.

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

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

Лайфхак: не ленитесь сегментировать пользователей, чтобы определить стратегию работы с каждой группой.

Большая ошибка многих проектов — рассказывать всем одну и ту же историю изменений. Для определения стратегии коммуникации с разными пользователями мы рекомендуем упражнение Stakeholder Impact Assessment:

1. Соберите таблицу 

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

Desire: отсутствие сопротивления не означает поддержку изменений

Если Awareness отвечает на вопрос «понимают ли люди, зачем нужны изменения», то Desire показывает, готовы ли они действительно менять привычный способ работы.

Для снижения рисков внедрения мы решили начать с пилота. Вместе с бизнесом выбрали три объекта, на которых в течение трех месяцев тестировался новый процесс работы с исполнительной документацией.

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

Поэтому к моменту масштабирования проекта у нас сформировалось ощущение, что основное отношение пользователей к изменениям уже понятно.

На практике все оказалось сложнее.

После подключения сотен объектов и тысяч пользователей обратная связь стала значительно более разнообразной. Появились новые сценарии работы, новые категории пользователей и новые проблемы, которые не могли проявиться на ограниченной выборке пилота.

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

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

Обратная ситуация тоже возможна. Небольшое количество активных участников пилота может создавать впечатление, что изменения приняты всеми, хотя значительная часть будущих пользователей еще даже не столкнулась с новым процессом.

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

Неожиданный урок про бизнес-спонсора

Отдельно стоит сказать о роли бизнес-спонсора изменений. Согласно методологии спонсор должен не просто согласовать проект или выделить бюджет. Он должен публично поддерживать изменения, объяснять их необходимость, участвовать в коммуникациях и помогать преодолевать организационные барьеры.

Что было у нас

Формально бизнес-лидер у проекта был.

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

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

Лайфхак: ищите не руководителей, а лидеров мнений.

Чтобы найти амбассадоров на встрече, спросите руководителя: кому остальные звонят, когда что-то не работает? Очень часто это не начальник, а человек, который работает 10 лет и знает все процессы. Если амбассадор говорит:«Да, неудобно, но жить можно», то это работает лучше, чем 20 презентаций от проектной команды. Люди доверяют своим.

Knowledge: знания нужно поддерживать на протяжении всего внедрения 

Следующий этап ADKAR связан с формированием знаний о том, как работать по-новому.

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

Обучение началось еще во время пилота и фактически не прекращалось после запуска. Регулярные встречи проводились на всех этапах проекта: во время пилотирования, масштабирования на новые объекты и после полного перехода на Билдокс.

Мы использовали несколько форматов обучения:

1. Еженедельные онлайн-встречи, на которых разбирали реальные вопросы пользователей и демонстрировали работу функционала.

2. Короткие видеоуроки по каждому функциональному блоку системы, которые можно быстро просмотреть непосредственно перед выполнением конкретной операции.

3. База текстовых инструкций.

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

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

Лайфхак: учите задачам, а не системе и записывайте инструкции по сценариям. Например, вместо блока «Как работает раздел «Документы»» использовать блок «Как за 3 минуты передать комплект ИД».

Ability: знание процесса еще не означает возможность работать

Если этап Knowledge отвечает на вопрос «знает ли пользователь, что нужно делать», то Ability показывает, может ли он действительно выполнять свою работу в новой системе. 

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

Поэтому параллельно с внедрением Билдокс была организована полноценная поддержка пользователей. Это позволило структурировать поток запросов и контролировать сроки их выполнения.

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

Практика показала, что между «знаю, как работать» и «могу работать» находится большой пласт организационной работы.

Пользователь может пройти обучение, изучить инструкции и понимать новый процесс. Но если ему несколько дней оформляют доступ, не создан объект строительства или невозможно подключить подрядчика, то изменения фактически не работают.

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

Лайфхак: стройте User Journey до запуска чтобы проверить реальную готовность системы и процессов к работе. Очень часто пользователи знают, что делать, но не могут начать работу. Как проверить готовность? 

1. Нарисуйте путь пользователя, например: Получить доступ. Войти. Найти объект. Создать документ. Отправить на проверку.

2. Для каждого шага ответьте:

   1. кто отвечает;

   2. сколько занимает времени;

   3. что может пойти не так.

3. Попросите человека, который никогда не видел систему, пройти этот путь. Вы удивитесь количеству проблем, которые команда проекта давно перестала замечать.

Reinforcement: изменения становятся реальностью только тогда, когда к ним невозможно не адаптироваться

Последний этап ADKAR связан с закреплением изменений и предотвращением возврата к прежним способам работы.

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

Во время масштабирования переход на Билдокс происходил постепенно. При этом исполнительная документация в Тессе не исчезла полностью. Пользователи по-прежнему могли работать с историческими данными, просматривать ранее созданные документы и завершать уже начатые процессы. Ограничение касалось только создания новых документов — эта возможность была переведена в Билдокс.

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

Ситуация кардинально изменилась после полного отключения строительной документации в Тессе. Именно в этот момент начали активно проявляться пользователи, которые раньше практически не участвовали в переходе. Резко выросло количество обращений, запросов на подключение и вопросов по настройке процессов.

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

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

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

Лайфхак: заранее подготовьте план первых двух недель после перехода для отключения старого процесса.

1. Создайте War Room на первые 14 дней:

• отдельный чат;

• ежедневный мониторинг проблем;

• сводка для бизнеса;

• список топ-10 болей пользователей.

Считайте не количество обращений — считайте количество уникальных проблем. 100 обращений по одной проблеме лучше, чем 10 обращений по 10 разным проблемам.

2. Делайте еженедельный Pulse Survey

Раз в две недели отправлять пользователям три вопроса:

1. Понимаете ли вы, зачем нужны изменения?

2. Насколько комфортно работать в новом процессе?

3. Что мешает вам больше всего?

Ответ по шкале от 1 до 5 плюс свободный комментарий. Не делайте опрос больше 3 вопросов. После 5 вопросов большинство пользователей начинает отвечать случайно.

Что было дальше

Самый важный вопрос — удалось ли внедрение?

Да.

Но не так быстро, как мы ожидали. Полный цикл внедрения составил:

1. 3 месяца пилотного проекта;

2. 3 месяца масштабирования;

3. 4 месяца адаптации и закрепления изменений.

Через 10 месяцев после старта проекта нам удалось не просто перевести пользователей в новую систему, а добиться стабильной работы процессов:

1. более 800 активных объектов строительства были переведены в Билдокс;

2. соблюдение SLA достигло 99%;

3. затраты на техническую поддержку снизились более чем на 70%.

Именно этот этап показал, что первоначальное сопротивление не всегда означает провал внедрения. Если изменения последовательно доводятся до конца, а новая система действительно решает задачи пользователей, сопротивление постепенно сменяется принятием, а затем становится новой нормой работы.