Пилотные проекты больничного программного обеспечения часто выглядят успешными, поскольку тестируются в контролируемых условиях с мотивированной командой, ограниченным количеством рабочих процессов и повышенной поддержкой со стороны поставщика и руководства. Проблемы появляются при масштабировании системы на всю больницу, когда сталкиваются разные подразделения, устоявшиеся процессы, кадровые ограничения, интеграции и конкурирующие приоритеты. Во многих случаях проблема заключается не в самой технологии — организация оказывается не готова адаптировать процессы, распределение ответственности и ресурсы под новую систему.
Почему пилотные проекты успешны, а полномасштабное внедрение часто проваливается
Пилот показывает, что программное обеспечение способно работать в специально выбранных условиях, тогда как полномасштабное внедрение должно доказать, что вся больница способна изменить привычный порядок работы.
Пилотные проекты намеренно ограничивают.
Больница может внедрить новую медицинскую платформу в одном отделении с небольшой группой врачей и медсестёр, добровольно согласившихся участвовать в тестировании. Поставщик может оказывать непосредственную поддержку, руководство — внимательно следить за проектом, а возникающие проблемы — устраняться практически сразу.
Такие условия полезны для проверки технологии, однако редко соответствуют обычной работе медицинской организации.
При масштабировании ситуация меняется.
Система должна учитывать отделения с различными рабочими процессами, сотрудников с разным уровнем цифровой грамотности, устаревшее оборудование, несколько рабочих смен, временный персонал, внешние лаборатории, аптеки, диагностические системы, биллинг и уже существующие медицинские информационные системы.
Количество взаимосвязей резко возрастает.
Процесс, прекрасно работающий для 15 пользователей, может оказаться проблемным, когда от него начинают зависеть 1 500 сотрудников.
Пилотная команда также может получать уровень поддержки, который невозможно обеспечить всей организации. Если во время тестирования специалист поставщика лично решает каждую возникающую проблему, руководство больницы может ошибочно решить, что программное обеспечение практически не требует сопровождения.
Поэтому главный вопрос заключается не в том, был ли пилот успешным.
Важно понять, можно ли масштабировать организационную модель, благодаря которой этот пилот оказался успешным.
Основные причины провала больничных IT-проектов после пилотного этапа
Полномасштабные внедрения обычно сталкиваются с проблемами из-за того, что организации недооценивают различия рабочих процессов, управление изменениями, сложность интеграций, необходимость обучения и объём ресурсов, требуемых после запуска.
К наиболее распространённым причинам относятся:
- Попытка стандартизировать процессы, которые в действительности не стандартизированы. Два отделения могут формально выполнять одну и ту же процедуру, но по-разному организовывать согласования, документацию, передачу информации и обработку исключительных ситуаций. Программное обеспечение быстро выявляет эти различия, а попытка заставить все отделения работать по модели пилотной группы вызывает сопротивление и операционные проблемы.
- Недостаточное участие сотрудников, непосредственно работающих с системой. Руководители, IT-специалисты и ведущие врачи могут одобрить платформу, но значительную часть ежедневных операций внутри неё выполняют медсёстры, регистраторы, технические специалисты, младший медицинский персонал и другие сотрудники. Если их реальные процессы не учитывались при проектировании и тестировании, проблемы проявятся только после внедрения.
- Недооценка сложности интеграций. Больничное ПО практически никогда не существует изолированно. Оно может обмениваться информацией с электронными медицинскими картами, лабораторными системами, платформами медицинской визуализации, аптечными программами, расписанием, биллингом, системами идентификации, медицинским оборудованием и внешними организациями.
- Отношение к обучению как к разовому мероприятию. Презентация или короткое обучение перед запуском не способны подготовить сотрудников ко всем реальным ситуациям. Пользователям необходимы программы обучения с учётом их должностей, практические занятия, доступные инструкции, помощь непосредственно во время работы и дополнительное обучение уже после начала эксплуатации системы.
- Отсутствие долгосрочного владельца системы. Во время пилота ответственность обычно понятна, поскольку существует отдельная проектная команда. После запуска возникают более сложные вопросы: кто отвечает за конфигурацию? Кто утверждает изменения процессов? Кто контролирует использование системы? Кто определяет, относится проблема к IT, поставщику или медицинскому подразделению?
Каждая из этих проблем становится значительно серьёзнее по мере роста числа пользователей.
Небольшое неудобство для пяти участников пилотного проекта можно терпеть.
Но если с тем же неудобством сотни или тысячи сотрудников сталкиваются ежедневно, оно превращается в серьёзную операционную проблему.
Что меняется в работе больницы после масштабирования пилота
Масштабирование больничного программного обеспечения увеличивает не только количество пользователей — оно многократно увеличивает число зависимостей, нестандартных ситуаций, обращений в поддержку и последствия возможных сбоев.
Во время пилота проектная команда обычно может контролировать, кто использует программу, какие процессы в неё включены и в каких ситуациях она применяется.
После масштабирования значительная часть этого контроля исчезает.
Система внезапно становится частью экстренной госпитализации, ночных и выходных смен, перевода пациентов между отделениями, назначения лекарств, диагностики, выписки, выставления счетов и десятков других взаимосвязанных процессов.
Исключительные ситуации становятся повседневными.
Одному отделению может потребоваться информация, которую другое вообще не собирает. Врач может одновременно работать в нескольких подразделениях. Временному сотруднику необходим ограниченный доступ. Пациент может перемещаться между отделениями быстрее, чем системы успевают синхронизировать данные.
Небольшие предположения, заложенные при проектировании, начинают иметь реальные операционные последствия.
Резко меняются и требования к технической поддержке.
Во время пилота десять вопросов в день могут легко обрабатываться проектной командой. После масштабирования сотни пользователей способны одновременно обращаться с самыми разными проблемами — от забытого пароля до серьёзной остановки рабочего процесса.
Поэтому больнице необходима понятная система эскалации.
Часть проблем действительно является технической.
Другие связаны с недостаточным обучением.
Некоторые требуют изменения конфигурации.
А отдельные ситуации показывают, что необходимо менять сам медицинский или административный процесс.
Без чёткого распределения ответственности всё начинает восприниматься как «проблема IT-отдела». В результате техническая команда оказывается перегружена, а организационные причины остаются нерешёнными.
Должен измениться и подход к оценке результатов.
Успешность пилота часто измеряют уровнем использования системы, удовлетворённостью пользователей или тем, выполнила ли программа технически поставленную задачу.
При полномасштабной эксплуатации нужны более широкие показатели.
Увеличилось ли время заполнения документации?
Стали ли пациенты ждать дольше?
Создают ли сотрудники обходные процессы?
Появился ли повторный ручной ввод данных?
Стали ли врачи проводить больше времени за компьютером?
Изменилось ли количество ошибок?
Улучшает ли система тот процесс, ради которого её вообще внедряли?
Успешное внедрение должно работать не только технически, но и операционно.
Как планировать переход от пилота к полномасштабному внедрению
Переход необходимо рассматривать как отдельную программу организационных изменений, а не просто как следующий этап установки программного обеспечения.
Практический процесс масштабирования можно разделить на четыре этапа:
- Повторно оценить пилот перед масштабированием. Определите, какая часть успеха связана непосредственно с программным обеспечением, а какая — с необычно комфортными условиями пилота. Зафиксируйте объём поддержки поставщика, дополнительного персонала, ручной работы, обучения и внимания руководства, который потребовался для достижения результата.
- Описать процессы разных подразделений. Не следует считать, что процессы пилотного отделения представляют всю больницу. Изучите, как аналогичные операции выполняются в разных подразделениях, определите обоснованные различия, зафиксируйте исключения и решите, какие процессы необходимо стандартизировать ещё до настройки системы.
- Создать модель поддержки до запуска. Заранее определите, кто отвечает за вопросы пользователей, технические инциденты, права доступа, проблемы рабочих процессов, интеграции, изменение конфигурации и взаимодействие с поставщиком. Установите приоритеты обращений и убедитесь, что возможности поддержки соответствуют ожидаемому количеству пользователей.
- Масштабировать систему поэтапно и измерять результат. Если это возможно, внедряйте программу последовательно по отделениям, площадкам, процессам или группам пользователей вместо одномоментного запуска во всей организации. После каждого этапа анализируйте операционные показатели и исправляйте проблемы до дальнейшего расширения.
Такой подход может показаться более медленным, чем быстрый запуск сразу во всей больнице.
На практике он способен оказаться значительно быстрее, чем восстановление работы после неудачного внедрения.
Поспешный запуск также может сформировать негативное отношение сотрудников, которое сохранится даже после устранения технических проблем.
Если персонал однажды решит, что новая система только усложняет работу, восстановление доверия становится отдельной задачей.
Признаки того, что внедрение движется к провалу
Проблемные проекты обычно подают тревожные сигналы задолго до окончательного провала, однако руководство нередко воспринимает их как временное сопротивление сотрудников вместо признаков системных недостатков.
Один из первых сигналов — быстрое появление неофициальных обходных решений.
Если сотрудники ведут отдельные таблицы, записывают информацию на бумаге, передают данные через неофициальные мессенджеры или вынуждены вводить одну и ту же информацию сразу в несколько систем, официальный процесс, вероятно, не соответствует реальной работе.
Другой тревожный признак — чрезмерная зависимость от отдельных специалистов.
Если каждый сложный вопрос в итоге попадает к одному и тому же IT-специалисту, врачу, руководителю проекта или представителю поставщика, такая модель поддержки не сможет масштабироваться.
Статистика прохождения обучения также способна создавать ложное чувство уверенности.
Больница может сообщить, что 95% сотрудников завершили обучение, хотя реальные пользователи всё ещё не способны самостоятельно выполнять распространённые операции.
Пройденное обучение ещё не означает наличие необходимых навыков.
Особого внимания заслуживают повторяющиеся жалобы одной профессиональной группы.
Если медсёстры постоянно говорят, что оформление документации стало занимать больше времени, а врачи регулярно сталкиваются с проблемами при назначениях, опасно списывать всё исключительно на сопротивление изменениям.
Недовольство сотрудников, непосредственно работающих с системой, часто указывает на реальные недостатки процессов.
Даже показатели проекта могут стать тревожным сигналом.
Если руководство отчитывается только количеством активированных пользователей, подключённых отделений или проведённых обучающих мероприятий, организация может измерять активность внедрения вместо его реального результата.
Ещё один серьёзный признак — бесконечная кастомизация.
Когда каждое отделение требует уникальных изменений, организация рискует автоматизировать противоречивые процессы вместо того, чтобы сначала определить единые принципы работы.
Со временем такую систему становится всё сложнее поддерживать, а каждое последующее обновление обходится дороже.
Как успешные больницы по-другому подходят к масштабированию
Успешные больницы рассматривают внедрение программного обеспечения как организационные изменения, поддерживаемые технологиями, а не как IT-проект, к которому медицинский и административный персонал должен просто адаптироваться после запуска.
Они создают совместную ответственность.
IT-отдел отвечает за инфраструктуру, интеграции, безопасность и техническую надёжность, однако руководители медицинских и операционных подразделений продолжают отвечать за рабочие процессы и конечные результаты.
Сотрудники, непосредственно использующие систему, подключаются к проекту на раннем этапе.
Вместо того чтобы после внедрения спрашивать пользователей, нравится ли им интерфейс, успешные проектные команды заранее изучают, как в действительности выполняется работа, и только после этого принимают важные решения о конфигурации.
Они также разделяют необходимые различия и ненужную несогласованность.
Не все отделения должны работать абсолютно одинаково.
У скорой помощи, стационара и амбулаторного подразделения объективно разные требования.
Однако если пять отделений выполняют практически одинаковый административный процесс пятью способами исключительно потому, что «у нас всегда так было», внедрение новой системы становится хорошей возможностью сначала стандартизировать процесс, а уже затем его цифровизировать.
Успешные организации особенно много ресурсов вкладывают в первые недели после запуска.
Это может включать дополнительную поддержку непосредственно в отделениях, оперативные группы реагирования, ежедневный разбор проблем, временное увеличение численности персонала, расширенную поддержку поставщика и ускоренное принятие решений по критическим вопросам.
При этом сам запуск не считается финишной точкой проекта.
Через несколько недель или месяцев реальной эксплуатации процессы необходимо проанализировать повторно.
Часть предположений, сделанных во время внедрения, окажется ошибочной. Некоторые функции будут использоваться редко. Появятся новые узкие места. Сотрудники найдут более удобные способы работы с системой.
Организация должна быть готова адаптироваться.
Наконец, успешные больницы оценивают не только использование технологии, но и то, действительно ли она улучшает работу медицинской организации.
Уровень внедрения имеет значение, однако сам по себе он ещё не означает успех.
Системой могут пользоваться 100% сотрудников, но при этом она всё равно способна увеличивать объём документации, создавать задержки, раздражать врачей или формировать новые риски для безопасности пациентов.
Поэтому наиболее зрелые проекты связывают технические показатели с операционными и медицинскими результатами.
Они оценивают, экономит ли система время, сокращает ли количество ненужных действий, улучшает ли доступность информации, снижает ли количество ошибок, повышает ли качество взаимодействия между подразделениями и делает ли ключевые процессы более надёжными.
Именно поэтому многие перспективные пилотные проекты больничного программного обеспечения терпят неудачу после масштабирования.
Пилот проверяет продукт.
Полномасштабное внедрение проверяет организацию.
Больницы, которые понимают эту разницу заранее, с большей вероятностью создают систему управления, обучения, поддержки, проектирования процессов и распределения ответственности, необходимую для превращения успешного эксперимента в устойчиво работающий инструмент.