В одном из подкастов недавно услышал про сервис отзывов Capterra, на котором собраны проверенные отзывы пользователей о программном обеспечении. Повинуясь профессиональному интересу, решил тщательно изучить положительные и отрицательные отзывы про системы EHR (Electronic Health Record), чтобы по этой обратной связи понять, что наиболее важно для пользователей медицинских систем. За несколько дней удалось детально ознакомиться с более чем 600 отзывами по продуктам от разных разработчиков, из которых я выделял ключевые тезисы, после чего разделил их все по тематикам и сгруппировал схожие. В итоге попробую, как смогу кратко, изложить все свои наблюдения по основным моментам, на которые стоит обращать внимание разработчикам медицинских информационных систем, чтобы получить безграничную любовь пользователей.
Основные жалобы, связанные с финансовой стороной, относились к непрозрачному ценообразованию и непрогнозируемой стоимости владения подобных систем в период сопровождения.
На этапе внедрения очень сложно составить детальное ТЗ и учесть все моменты, которые будут необходимы в будущем, и какие-то вещи заказчики упускают из виду. А когда выясняется, что какого-то функционала в системе нет, то разработчики просят за него дополнительные деньги, хотя заказчики считают, что это должно было быть учтено в базовой поставке, поэтому возникает конфликт.
Когда взаимоотношения переходят на этап сервисного сопровождения также возникает много претензий со стороны заказчика по поводу того, что разработчик просит денег за любую незначительную доработку, если она не учтена в сервисном контракте.
Пользователи, столкнувшиеся с подобными проблемами, рекомендуют более внимательно подходить к подготовке технического задания и не верить на слово продавцам, которые рассказывают, что в системе будет все, что понадобится. Разработчикам же надо максимально прозрачно выстроить политику ценообразования и донести все ее тонкости до заказчика, чтобы в дальнейшем неожиданности не приводили к конфликтам.
Для того, чтобы любая информационная система заработала так, как задумывалось инициатором ее покупки, необходимо грамотно выстроить процесс внедрения.
Для начала, заказчик должен определить сотрудников внутри медицинского учреждения, которые наиболее лояльны к внедрению нового продукта и готовы конструктивно работать вместе с командой разработчика на этапе внедрения. Этих сотрудников необходимо обучать в первую очередь и наиболее углубленно, они должны составить основное ядро лидеров изменений, который будут помогать своим коллегам, когда разработчики закончат свою часть работ.
Основное обучение с сотрудниками необходимо проводить в очном формате, с теорией, практическими занятиями и проверкой того, как усваивается информация. Дистанционное обучение лучше оставить на будущее, когда пользователи уже хорошо знакомы с системой и им необходимо рассказать о каких-то изменениях в системе или новом функционале.
Совсем не лишним будет наличие учебного портала, на котором можно размещать актуальные ролевые инструкции и видеоматериалы по работе с теми или иными функциями системы, что позволит пользователям в любой момент обратиться в эту базу знаний. Еще лучше, если этот портал будет поддерживать функцию тестирования и автоматическую проверку знаний, чтобы прогонять через него всех новичков и проверять их подготовку.
Позаботьтесь также о наличии тестовой базы, на которой пользователи смогут опробовать весь функционал до того, как начнут работать в основной системе.
Внедрение сложных систем никогда не бывает быстрым и гладким, поэтому необходимо заранее настроиться на продолжительный и болезненный процесс.
Вот этот раздел в отзывах получился у меня самый большой, так как очень много негатива связано именно с постпродажной поддержкой.
Заказчик, покупая систему, рассчитывает получить в лице компании-разработчика партнера для продуктивных и продолжительных отношений и очень счастлив, когда именно так и складывается. Но в основной своей массе он получает обезличенную службу технической поддержки, сотрудники которой замотивированы только на выполнение собственных KPI по закрытию заявок в установленные внутренним регламентом сроки.
В основном в отзывах жалуются на очень медленную реакцию на заявки, на формальные отписки в заявках, на нежелание разобраться в проблемах пользователя, на неспособность говорить на одном языке, так как отсутствует понимание специфики работы пользователя и т.п.
Положительные отзывы дают ответ на то, какой должна быть идеальная службы технической поддержки. Каждая заявка пользователя — это его боль, и он хочет получить на нее ответ как можно быстрее, поэтому перезвоните клиенту в течение часа и выясните все подробности его обращения, вместо того, чтобы возвращать ее на доработку с уточняющими вопросами, чтобы получить ответы, на которые появятся очередные вопросы. Настройте сотрудников технической поддержи на то, что они не стена, защищающая компанию от злых и надоедливых клиентов, а партнеры с нежными объятиями, вся цель существования которых — помогать решать проблемы заказчика. Слушайте своих клиентов, говорите с ними, предугадывайте их желания и предвосхищайте их ожидания.
Здесь собраны те полезные функции, наличие которых точно выделит продукт на фоне остальных конкурентов на этапе выбора системы. Традиционный минимальный функционал, который требуется для ежедневной работы медицинского персонала, здесь не описывается, он и так, по умолчанию, должен быть в системе, которая претендует на звание медицинской информационной системы.
Так над реализацией каких фич стоит поразмыслить менеджеру продукта в компании-разработчике МИС, чтобы сделать свой программный продукт лучшим на витрине?
Очень много внимания в отзывах уделяется наличию портала пациента, где можно в удобном виде смотреть историю посещений врача и результаты анализов, на котором можно выбрать необходимого врача и записаться к нему на прием. Если у портала есть API, который позволяет выгружать данные в удобном для дальнейшей обработки виде, то это еще один огромный плюс в карму разработчика, т.к. такие данные могут, с разрешения пациента, использоваться сторонними приложениями. Также такой портал может поддерживать функционал чата с врачом, если у пациента возникли какие-то вопросы уже после приема, ну и конечно различные варианты удаленного взаимодействия (телемедицина, дистанционный мониторинг и т.п.)
Помимо портала пациента у некоторых разработчиков есть также внутренний портал для врачей, который позволяет создать виртуальное сообщество, обмениваться идеями и проблемами, давать разработчикам предложения по доработке и развитию системы, а также голосовать за реализацию нового функционала в МИС, чтобы наиболее важные для всех врачей функции реализовывались в первую очередь.
Что еще полезного может быть у вас в рукаве? Уведомления пациентов через СМС или сообщения в приложении (напоминания о приеме, о необходимости пройти плановую вакцинацию, о готовности результатов исследований или анализов и т.п), версии приложения для мобильных устройств, автоподставление слов при вводе данных в справочных полях, назначение быстрых клавиш для часто используемых фраз и голосовое заполнение текстовых полей.
Ну и не забывайте, что МИС — это в первую очередь большая база данных, а данные люди очень любят выгружать для дальнейшей обработки, складывать в отчеты или визуализировать в виде графиков. Поэтому обязательным условием успеха является возможность гибко и быстро настраивать требуемые пользователям отчеты, делать различные выгрузки и выводить информацию в виде графиков на дашбордах. А если эти возможности будут реализованы в виде простого инструментария, с которыми справятся сами врачи, то вы просто на целый корпус оторветесь от конкурентов.
Забудьте про уродливые интерфейсы из 90-х и 2000-х, наймите себе нормального UI/UX-дизайнера, который сделает красивую обертку для вашей системы, используя актуальные для наших дней рекомендации к графическому дизайну и юзабилити.
Что отмечают пользователи различных МИС как удачные примеры дизайна и юзабилити? Не перегруженный элементами интерфейс и возможность его конфигурации под нужды конкретного специалиста, настраиваемый рабочий стола врача, куда он может вынести основные используемые задачи, настраиваемые меню, легкость навигации в приложении, возможность настройки бизнес-процессов внутри системы, настраиваемые шаблоны и печатные формы и, желательно, чтобы все это можно было делать без помощи технической поддержки компании-разработчика.
А чего же следует избегать? Сложных процессов, которые интуитивно не понятны и требуют множества действий, экранов, которые необходимо протягивать ползунком, чтобы увидеть все их содержимое, нечитабельных шрифтов и большого количества вложенных меню.
Вот такой получился небольшой обзор по итогам чтения отзывов пользователей на сайте Capterra. Вроде все очевидно, но все же многие выбирают идти вразрез логики и делают то, что потом становится предметом длинных негативных отзывов от потребителей. Любите своих клиентов и делайте так, чтобы они любили вас и ваш продукт!
Больше интересного про ИТ в медицине на моем канале в телеграм t.me/it_medicine
Деньги
Основные жалобы, связанные с финансовой стороной, относились к непрозрачному ценообразованию и непрогнозируемой стоимости владения подобных систем в период сопровождения.
На этапе внедрения очень сложно составить детальное ТЗ и учесть все моменты, которые будут необходимы в будущем, и какие-то вещи заказчики упускают из виду. А когда выясняется, что какого-то функционала в системе нет, то разработчики просят за него дополнительные деньги, хотя заказчики считают, что это должно было быть учтено в базовой поставке, поэтому возникает конфликт.
Когда взаимоотношения переходят на этап сервисного сопровождения также возникает много претензий со стороны заказчика по поводу того, что разработчик просит денег за любую незначительную доработку, если она не учтена в сервисном контракте.
Пользователи, столкнувшиеся с подобными проблемами, рекомендуют более внимательно подходить к подготовке технического задания и не верить на слово продавцам, которые рассказывают, что в системе будет все, что понадобится. Разработчикам же надо максимально прозрачно выстроить политику ценообразования и донести все ее тонкости до заказчика, чтобы в дальнейшем неожиданности не приводили к конфликтам.
Внедрение
Для того, чтобы любая информационная система заработала так, как задумывалось инициатором ее покупки, необходимо грамотно выстроить процесс внедрения.
Для начала, заказчик должен определить сотрудников внутри медицинского учреждения, которые наиболее лояльны к внедрению нового продукта и готовы конструктивно работать вместе с командой разработчика на этапе внедрения. Этих сотрудников необходимо обучать в первую очередь и наиболее углубленно, они должны составить основное ядро лидеров изменений, который будут помогать своим коллегам, когда разработчики закончат свою часть работ.
Основное обучение с сотрудниками необходимо проводить в очном формате, с теорией, практическими занятиями и проверкой того, как усваивается информация. Дистанционное обучение лучше оставить на будущее, когда пользователи уже хорошо знакомы с системой и им необходимо рассказать о каких-то изменениях в системе или новом функционале.
Совсем не лишним будет наличие учебного портала, на котором можно размещать актуальные ролевые инструкции и видеоматериалы по работе с теми или иными функциями системы, что позволит пользователям в любой момент обратиться в эту базу знаний. Еще лучше, если этот портал будет поддерживать функцию тестирования и автоматическую проверку знаний, чтобы прогонять через него всех новичков и проверять их подготовку.
Позаботьтесь также о наличии тестовой базы, на которой пользователи смогут опробовать весь функционал до того, как начнут работать в основной системе.
Внедрение сложных систем никогда не бывает быстрым и гладким, поэтому необходимо заранее настроиться на продолжительный и болезненный процесс.
Сопровождение
Вот этот раздел в отзывах получился у меня самый большой, так как очень много негатива связано именно с постпродажной поддержкой.
Заказчик, покупая систему, рассчитывает получить в лице компании-разработчика партнера для продуктивных и продолжительных отношений и очень счастлив, когда именно так и складывается. Но в основной своей массе он получает обезличенную службу технической поддержки, сотрудники которой замотивированы только на выполнение собственных KPI по закрытию заявок в установленные внутренним регламентом сроки.
В основном в отзывах жалуются на очень медленную реакцию на заявки, на формальные отписки в заявках, на нежелание разобраться в проблемах пользователя, на неспособность говорить на одном языке, так как отсутствует понимание специфики работы пользователя и т.п.
Положительные отзывы дают ответ на то, какой должна быть идеальная службы технической поддержки. Каждая заявка пользователя — это его боль, и он хочет получить на нее ответ как можно быстрее, поэтому перезвоните клиенту в течение часа и выясните все подробности его обращения, вместо того, чтобы возвращать ее на доработку с уточняющими вопросами, чтобы получить ответы, на которые появятся очередные вопросы. Настройте сотрудников технической поддержи на то, что они не стена, защищающая компанию от злых и надоедливых клиентов, а партнеры с нежными объятиями, вся цель существования которых — помогать решать проблемы заказчика. Слушайте своих клиентов, говорите с ними, предугадывайте их желания и предвосхищайте их ожидания.
Функционал
Здесь собраны те полезные функции, наличие которых точно выделит продукт на фоне остальных конкурентов на этапе выбора системы. Традиционный минимальный функционал, который требуется для ежедневной работы медицинского персонала, здесь не описывается, он и так, по умолчанию, должен быть в системе, которая претендует на звание медицинской информационной системы.
Так над реализацией каких фич стоит поразмыслить менеджеру продукта в компании-разработчике МИС, чтобы сделать свой программный продукт лучшим на витрине?
Очень много внимания в отзывах уделяется наличию портала пациента, где можно в удобном виде смотреть историю посещений врача и результаты анализов, на котором можно выбрать необходимого врача и записаться к нему на прием. Если у портала есть API, который позволяет выгружать данные в удобном для дальнейшей обработки виде, то это еще один огромный плюс в карму разработчика, т.к. такие данные могут, с разрешения пациента, использоваться сторонними приложениями. Также такой портал может поддерживать функционал чата с врачом, если у пациента возникли какие-то вопросы уже после приема, ну и конечно различные варианты удаленного взаимодействия (телемедицина, дистанционный мониторинг и т.п.)
Помимо портала пациента у некоторых разработчиков есть также внутренний портал для врачей, который позволяет создать виртуальное сообщество, обмениваться идеями и проблемами, давать разработчикам предложения по доработке и развитию системы, а также голосовать за реализацию нового функционала в МИС, чтобы наиболее важные для всех врачей функции реализовывались в первую очередь.
Что еще полезного может быть у вас в рукаве? Уведомления пациентов через СМС или сообщения в приложении (напоминания о приеме, о необходимости пройти плановую вакцинацию, о готовности результатов исследований или анализов и т.п), версии приложения для мобильных устройств, автоподставление слов при вводе данных в справочных полях, назначение быстрых клавиш для часто используемых фраз и голосовое заполнение текстовых полей.
Ну и не забывайте, что МИС — это в первую очередь большая база данных, а данные люди очень любят выгружать для дальнейшей обработки, складывать в отчеты или визуализировать в виде графиков. Поэтому обязательным условием успеха является возможность гибко и быстро настраивать требуемые пользователям отчеты, делать различные выгрузки и выводить информацию в виде графиков на дашбордах. А если эти возможности будут реализованы в виде простого инструментария, с которыми справятся сами врачи, то вы просто на целый корпус оторветесь от конкурентов.
Удобство
Забудьте про уродливые интерфейсы из 90-х и 2000-х, наймите себе нормального UI/UX-дизайнера, который сделает красивую обертку для вашей системы, используя актуальные для наших дней рекомендации к графическому дизайну и юзабилити.
Что отмечают пользователи различных МИС как удачные примеры дизайна и юзабилити? Не перегруженный элементами интерфейс и возможность его конфигурации под нужды конкретного специалиста, настраиваемый рабочий стола врача, куда он может вынести основные используемые задачи, настраиваемые меню, легкость навигации в приложении, возможность настройки бизнес-процессов внутри системы, настраиваемые шаблоны и печатные формы и, желательно, чтобы все это можно было делать без помощи технической поддержки компании-разработчика.
А чего же следует избегать? Сложных процессов, которые интуитивно не понятны и требуют множества действий, экранов, которые необходимо протягивать ползунком, чтобы увидеть все их содержимое, нечитабельных шрифтов и большого количества вложенных меню.
Вот такой получился небольшой обзор по итогам чтения отзывов пользователей на сайте Capterra. Вроде все очевидно, но все же многие выбирают идти вразрез логики и делают то, что потом становится предметом длинных негативных отзывов от потребителей. Любите своих клиентов и делайте так, чтобы они любили вас и ваш продукт!
Больше интересного про ИТ в медицине на моем канале в телеграм t.me/it_medicine
Комментарии (14)
AlexVist
28.07.2019 08:13Если позволите, маленький комментарий из личного опыта.
Наибольший успех медицинской системы среди ее конечного пользователя достигался привлечением медицинских работников в организацию, которая выпускает программный продукт. На всех уровнях. И в службу поддержки, и в службу r/d .
gsnikitin Автор
28.07.2019 12:40Да, согласен полностью. Но у нас мало где это делается, если вообще делается
AlexVist
28.07.2019 12:47Я видел только в зарубежных компаниях. Постарался такой опыт внедрить в службе внедрения и сопровождения когда работал в медицинской организации. С успехом отработала схема и у нас. Но я больше там не работаю.)
AlexVist
28.07.2019 12:46Я видел только в зарубежных компаниях. Постарался такой опыт внедрить в службе внедрения и сопровождения когда работал в медицинской организации. С успехом отработала схема и у нас. Но я больше там не работаю.)
Am0ralist
Более того, они не могут предугадать изменение законодательства или регламентных документов в медицине.
Слава богу в Бухгалтерии есть 1С, если честно. Потому что ситуация с МИСами и ЛИСами — это феерический и постоянный ППЦ.
И к моменту внедрения которого их уже там не будет. А ещё лучше, если возложить обязанность на добавление фич в данную систему на данных специалистов. Тогда к моменту внедрения у вас будет ИС, заточенная под них.
И ничего, что стоимость этого портала будет сравнима с стоимостью ИС, ну или в половину оной, если делается под конкретного клиента. Кого должны смущать циферки в договорах?
Обычно работа в этот период описывается так: как выкачать из конторы побольше бабла, поменьше делая при этом.
Действительно, у врачей же куча времени свободного в основное рабочее время, давайте им соцсеть внутреннюю запилим!
Действительно, что может быть лучше чатика с ипохондриком в рабочее время (или не дай бог после него)?
Правильно. Положите болт на внутреннее наполнение. На рынке решают красивые
оберткирюшечки, которые будут тормозить на core i7!Озвученное выше личное мнение инженера ИС одной маааленькой медицинской лаборатории с уже боооольшим опытом костылей под одну ЛИС.
Который смотрит на 1С и завидует бухгалтерии, что там уже есть одна стандартная программа, которая позволяет её настраивать под бизнес и с легкостью менять того, кто будет под тебя её допиливать. На рынках всяких ЛИС/МИС, к сожалению, всё очень плохо.
gsnikitin Автор
Вот именно поэтому инженеров и нельзя подпускать к тому, что является продуктом. Разработчики должны получать на вход постановку на разработку и реализовывать функционал, который требуется заказчикам, а не который просто сделать и не заморачиваться.
Если вы заметили начало текст то это не личное мнение автора, а обобщенное мнение на основе отзывов клиентов.
Am0ralist
Без инженеров со стороны клиента все эти МИС/ЛИС вообще работать не будут. Это так, замечание по факту.
Есть ложь, большая ложь и обобщенное мнение по отзывам клиентов о том, как разработчикам надо разрабатывать продукт.МИС/ЛИС ничем не отличается от любой системы автоматизации на производстве, ERP и т.п.
Советы поварам, как готовить блюда, немного странно делать на основе обобщенных отзывов клиентов.
Поэтому хотелось бы посмотреть на ту МИС, которую вы разработали, используя свои прекрасные рекомендации.
gsnikitin Автор
Если повор готовит говно и ему говорят, что это говно, то наверное повару стоит подумать над своими навыками приготовления пищи.
Обратная связь от клиентов это то, что даёт продукту развиваться в правильную сторону. А ваш подход примерно такой: я инженер я эти МИС/ЛИС 10 лет делаю и мне лучше знать, какие они должны быть. Вы можете делатт информационную систему, да, но не с продуктовой точки зрения, если не обращаете внимания на мнение клиента об удобстве, эргономике, логике реализованных процессов и т п.
testopatolog
Прямолинейное мышление забавно.
Рассмотрите вариант: что бы повар ни приготовил,- официанты и менеджер способны убедить клиента в том, что это изыскано приготовленные редкие деликатесы, и тот с удовольствием повторит этот заказ в другой раз.
gsnikitin Автор
Забавно то, что вы верите в то, что человек по натуре идиот и манипулируя им, его можно убедить в том, что чёрное белое. Да, хороший менеджер выпятит достоинства и недоговорит о недостатках, но после того, как вы станете потреблять то, что вам положили в тарелку, рецепторы вам уже не обмануть.
onegreyonewhite
Думаю предыдущие ораторы хотели до вас разными способами донести, что ведомый различными чувствами и ощущениями человек может сегодня хвалить повара, а завтра поливать грязью и это не самый надёжный источник фидбека. Есть еще куча способов собрать обратную связь и те отзывы, которые вы получаете следует фильтровать так же с другими показателями, которые важны для бизнеса (медицинского в том числе), такие как: поддерживаемость, эффективность (вырасли ли необходимые показатели качества предоставляемых услуг), стоимость и т.п.
А самый первый оратор хотел сказать, как я понял, что отзывы тоже бывают разные в зависимости от коллектива.
gsnikitin Автор
Я понимаю, что до меня хотели донести. Но если оценивать состояния рынка МИС, в том числе и у нас в стране, к сожалению, большая часть обратной связи от пользователей отражает реальную ситуацию. Причем в посте описаны только самые очевидные проблемы, над которыми следует работать, но которые предпочитают списывать на непонимание пользователями процесса разработки, сложности системы и т.п.
А то, что не все требования пользователя сразу надо бежать реализовывать это и так понятно, только я сразу написал, что это не отзывы одного двух пользователей, а сотни отзывов от разных пользователей на разные системы, но которые очень схожи.
gsnikitin Автор
Заметьте, что прямо сейчас вы написали большой комментарий, указывая на проблемы в тексте и пытаетесь доказать, что именно в ваших устах правда. Так почему вы считаете, что так же и кто-то другой не может критиковать ваши "поделки" в виде МИС/ЛИС, просто исходя из такого же посыла — сказать вам, что вы сделали что-то не так?
И кроме того нигде в тексте нет ни слова про то, как разрабатывать информационные системы, принижая вашу роль как инженера или разработчика, лучше разбирающегося в этом. Текс только про то, что пользователи хвалят то, что им нравится и критикуют то, что им не нравится. А работа нормального менеджера продукта это разбирать обратную связь от пользователей и делать выводы о том, что в продукте хорошо, а что требует поправить
Am0ralist
И с кучкой МИС мы общались не однократно, ибо нам туда инфу отдавать надо. Страх и ужас. В духе: а давайте вы у себя изменения сделаете, ибо наши разработчики это будут делать долго и дорого.
А цикл разработки нередко такой: заказывается новая МИС, контора разработчик пилит её с годик, внедряют годик, ещё год поддержки и контракт закончился, после чего заказывается новая МИС у других разработчиков. Одна соседняя контора на наших глазах за третий год пошла уже на третий цикл такого развлечения: они внедряли МИС взамен старой, на текущий момент изменения внести в новую МИС уже невозможно, продлевать контракт они отказались и собираются искать новую МИС.
Именно сравнивая эту ситуацию с 1с я вижу убогость подходов большинства разработчиков, которые стараются по максимум привязать клиентов к себе и выдоить его посильнее, качество разработки никого не волнует, на крайний случай сделают веселенький скин, а то, что внутри будут костыли и велосипеды — никто и не узнает.
Пользователи — это такой забавный зверёк, которые полгода могут работать, потом не выдержать, прийти и высказать всё что думают по поводу того, как работает программа, а ты им в ответ: «А почему вы сразу не пришли? Завтра пнём программиста, через неделю исправим». И если бы это было однократно или только с одним человеком…
Далее, отзывы касаются только того, с чем работает сам пользователь, а это хорошо если 50% функционала ПО. Чаще всего ещё меньше.
В третьих, *ИС покупаются не по тому, как они нравятся пользователям. А потому, какие задачи они обещают решить Клиенту. Клиент и пользователи пересекаются минимально. Хорошо если клиент пошлёт к реальным пользователем своих специалистов обсудить вашу *ИС, а ещё лучше, если его специалисты будут понимать что либо в этом.
В четвертых. Пользователи хвалят одно и ругают другое, за частую не имея возможности даже представить, как и что может работать по другому. Или не умея работать в программе. Или поработав до этого много лет в другой ИС, а теперь новая всё делает не так.
Так что правильно для начала проанализировать отзывы IT-специлалистов, которые работают в этих ИС параллельно с медперсоналом.