В этой статье подробно и аргументированно рассмотрим минусы, которыми наполнена каждая самописная программа для медицинского центра и 12 ключевых причин по которым стоит воздержаться от выбора подобных решений.
Чаще всего, самописные программы для клиник возникают как «наш ответ Чемберлену» — в силу неудовлетворенности функционалом или архитектурой существующих медицинских информационных систем. В большинстве случаев этот путь выбирают крупные и сетевые медицинские организации (но бывают и исключения) — в какой-то момент, в порыве максимализма, один из руководителей, многие дни проведший «в обнимку» с какой-либо системой, озаряется — «Сколько ещё можно возиться с этим хламом?! Я знаю, как сделать лучше!» День за днём вынашиваемое «Я знаю!» превращается в твердую уверенность «Я могу!». И вот уже, спустя какое-то время, новоиспеченная проектная группа, заразившись идеей светлого будущего, начинает делать первые, неуверенные шаги в сторону создания своего собственного глиняного колосса.
Самописная программа для клиники — медицинская информационная система, разрабатываемая по заказу ЛПУ и поддерживаемое автором-разработчиком или небольшой проектной группой.
Под понятием «самописная МИС» подразумевается не массовый продукт, а индивидуальную разработку, предназначенную для решения бизнес-задач в отдельно взятой организации, учитывающую сложившуюся специфику бизнес-процессов и их автоматизацию.
1 Привязка к одному разработчику
Представьте себе автомобиль, покупку запасных части и обслуживание которого, можно найти только в одном автосервисе страны.
Ситуация с самописными МИС выглядит точно таким же образом – внедрив такую систему, клиент попадает в полную зависимость от разработчика.
— доработки и любые изменения могут быть реализованы только автором;
— ошибки в договоре с разработчиком могут повлечь проблемы с авторскими правами и лицензированием;
— развитие системы или завершение проекта зависит исключительно от автора;
Всё это позволит автору-разработчику стать в некотором роде монополистом и диктовать свою ценовую политику.
Учесть всех юридические тонкости в начале разработки кажется невозможным, с другой стороны — разработчик не согласится на жестко регулирующими его деятельность пунктами в договоре.
Проект и Перец
Что лежит в основе отраслевого «самописа» – почти всегда это наработки какого-то Проекта и делавшего его Перца.
Позвали Перца пилить Проект. Дали стол, компьютер и оклад (даже премию обещали по итогу). Через месяц принесли ТЗ на информационную систему. Уложились в три страницы А4 – давай дружище начинай, остальное по ходу дела поймем. Каждый представлял проект по-своему, но время шло – проект пилился. Долго ли коротко ли — сделали свою програмулину по типу MVP, пользователи в полном ступоре от сего чуда, а теперь давай углы стачивать, да блоки заново переписывать.
Перец пилит-пилит, никак не выпилит. То задачка новая от руководства прилетает, то оглобли поворачивают, не так говорят, переделай вот это заново, а здесь логику поменяй.
«Проектность» у Перца уже изо всех щелей чудо-системы лезет. Где-то кнопочки не работают, а местами у пользователей окно программы с ошибкой закрывается. Отчеты не сходятся, данные куда-то пропадают, сервер падает в перегрузку… От былой архитектуры ядра и следа не осталось.
Погоревали собственники над потраченными деньгами и временем, а поделать-то нечего.
Возможно Перца выгонят и на его место найдут нового, а потом ещё одного. Месяц-другой провозятся Перцы-новички в софтине с кодом недокументированной разработки и быть может один из них возьмёт на себя храбрость заявить о необходимости переписать всё с 0.
Ещё больше опечалилось начальство. Пересчитали убытки – прослезились. Денег, потраченных не вернуть. Время упущено впустую. Данные с трудом в excel выгружаются.
Сказка-ложь, да в ней намек – собственнику клиники урок: «Если опыта разработки и внедрения отраслевой информационной системы у вас нет, тогда путь «самописной программы для клиники» — не ваш.
2 Проработка системной архитектуры и выбор платформы
Такая важная вещь, как выбор платформы и архитектуры в DIY информационных системах часто обусловлена квалификацией программиста и его умением убедительно довести свою позицию до собеседника.
Заказчик, незнакомый с нюансами технологий создания программного обеспечения, в большинстве случаев оказывается не в силах самостоятельно провести анализ тенденций на рынке разработки ПО и как следствие принять верное решение начиная длительный и дорогостоящий проект.
Ошибка выбора платформы для будущей программы медицинского центра будет стоить очень дорого.
Ещё одна из фундаментальных ошибок кроется в архитектуре информационной системы. Начинать проект можно в том случае, когда детально проработан состав модулей, функциональные возможности составляющих компонентов и взаимосвязи между ними. Процесс создания ТЗ на медицинскую информационную систему требует глубоких познаний не только в медицинской составляющей программы, но и в широком диапазоне сопутствующих элементов: складской и финансовый учёт, основы построения CRM и документооборота, расчет заработной платы, анализ бизнес-процессов и многое другое.
Без детально проработанного технического задания со стороны инициатора разработки программы 99% ИТ проектов заканчиваются провалом.
3 Отсутствие полноценной пользовательской документации
При разработке кастомизированного программного продукта редко уделяется внимание созданию полноценной документации для пользователей системы. Это достаточно непростой процесс. Что бы подготовить инструкции или видео-инструкции мало быть программистом, знающим как, работает тот или иной модуль в системе. Необходимо уметь доступным языком объяснить неискушенному пользователю какая последовательность действий необходима в определенной ситуации, рассказать о нюансах и ошибках.
Если программа для клиники находится на стадии отладки или доработки, при этом в логику работы или интерфейс вносятся изменения – это в большой степени влияет на качество документации и поддержание её в актуальном состоянии.
Такой расклад крайне замедляет процесс внедрения программы или обучение нового сотрудника. Основная нагрузка по обучению пользователей может лечь на программиста или руководителя. В худшем же случае знания будут передаваться между сотрудниками по принципу «из уст в уста», что всегда влечет за собой копирование ошибок и отнимает время на их исправление.
4 Отсутствие профессиональных тестировщиков
Как и любое другое программное обеспечение, медицинская информационная система на стадии разработки и внедрения требует качественное тестирование. Пользователь системы, выполняющий рутинные задачи не способен выявить недостатки программы. Отработка кода на работающем бизнесе может не только существенно подпортить жизнь рядовым сотрудникам, но и в целом навредить работе клинике, нарушив или замедлив работу с клиентами.
Работа профессиональных тестировщиков программного обеспечения достаточно затратная статья бюджета при разработке программ, но обойтись без таковых не получится.
5 Проблема безопасности данных
В понятие безопасность данных входит не только контроль несанкционированного доступа с целью кражи информации, но и надежность хранения и обработки данных, защита от потери данных в результате технического сбоя или компьютерного вируса.
Об этом вопросе задумываются многие собственники медицинских центров, но мало кто сможет досконально разобраться в этом вопросе при проектировании медицинской программы. Поэтому чаще получается, что безопасность хранения и обработки информации клиники будет зависеть как от навыков программиста, так и его желания тратить время глубоко погружаясь в проблему.
Безопасность информации в клинике обеспечивается не только на уровне программы, многое определяется грамотно выстроенной инфраструктурой и внутренней политикой организации.
Выстроить инфраструктуру, внедрить политику обработки информации и защитить данные от утечки или вируса непростая, но наиважнейшая задача. Допущенные ошибки могут дорого стоить медицинскому бизнесу и его собственнику.
6 Качество кода и документирование разработки
Приходится часто сталкиваться с одной из существенных проблем «самописных» или доработанных программ в клиниках – отсутствие документированной разработки.
Работала группа разработчиков или штатные специалисты, вносились изменения в код программы, а по итогу полное отсутствие дорожной карты разработки.
В коде мелькают комментарии с фамилиями специалистов, в лучшем случае указано назначение того или иного блока, а что и для какой цели вносилось в программу или удалялось никто уже не знает.
Логика различных специалистов может идти вразрез друг-другу, а опыт и умения способны как улучшить работу программы, так и угробить её напрочь.
В итоге, такие программы становится сложно и дорого обслуживать. Любому специалисту или компании-разработчику проще отказаться от сопровождения «чужого» продукта-франкенштейна, чем тратить время на изучение «творчества» предшественников.
Бывает так, что код программы испорчен и запутан настолько, что встает вопрос о переходе на новый продукт с дорогостоящим переносом данных или повторную разработку с исправлением ошибок, что обойдется не дешевле.
7 Сложность интеграции с внешними платформами и сервисами
Ни одна современная программа для медицинского центра или клиники не может эффективно работать без внешних интеграций. Автоматизация процессов клиники подразумевает активное взаимодействие с внешними сервисами, будь то медицинский агрегатор, банк, сервис онлайн-записи, сайт клиники или крупный государственный проект ЕГАИСЗ.
Наладить взаимодействие со всеми сервисами задача не из простых. Интеграции всегда имеют двойную направленность обмена данными и каждый сервис может иметь свои особенности взаимодействия.
Одним из необходимых условий разработки информационной программы для клиники является собственное API. Внедрение такого решения объемная и не менее сложная задача, которая займет отдельную и вполне ощутимую по весу строку бюджета на создание программы.
Постоянно появляются новые полезные сторонние платформы и сервисы, интеграция с которыми потребует новых затрат, а ошибки в архитектуре программного продукта или недостатки API потребуют очередного финансирования. Так как «самописное» ПО крайне специфичное, то найти специалиста для решения задач на рынке будет сложно или дорого.
8 Проблемы внедрения
Как не странно, много программ для автоматизации клиник провалились именно на этом этапе. Важнейшая из всех частей проекта любой автоматизации – это внедрение.
Что бы программа работала без сбоев, данные были полными и достоверными, а отчеты актуальными и точными, требуется приложить много усилий именно на этапе внедрения.
Для этого помимо компетенции в медицине, человеку, внедряющему МИС в клинике нужно хорошо разбираться в вопросах управления персоналом. Человеческий фактор одно из проблемных мест автоматизации.
Может случиться такое, когда часть сотрудников, понимая, что новая программа сделает прозрачной их работу, начнут саботировать внедрение и всячески ему препятствовать.
Не для кого не секрет, что в отечественном здравоохранении, в том числе и частном очень большая проблема с руководящими кадрами. Слабый менеджмент в 50% случаев становится причиной провала любого проекта автоматизации в медицине.
Есть и общая проблема для всех медицинских организаций. Она кроется в отношение к проекту со стороны руководителя клиники. Как минимум 70% успеха внедрения зависит именно от него.
9 Большая длительность проекта
Как бы того не хотелось, длительность проекта разработки своей собственной медицинской программы от старта до пред финального этапа занимает не менее одного года, в реальных же случаях длится от полутора лет и до бесконечности.
Время уходит, с ним меняется экономическая ситуация и рынок. Не каждый частный медицинский центр или сеть клиник готовы к такому длительному сроку ожидания.
10 Высокая стоимость разработки и внедрения
Работа команды опытных и компетентных специалистов по разработке, тестированию и внедрению по определению не может стоить дешево.
Умножим средний бюджет расходов для двух-трех специалистов на минимальную длительность проекта (1 год) и получим цифры от 2,5 до 4,5 млн руб.
Есть ли уверенность что такая программа окупит вложения? Есть ли гарантии, что она будет работать как задумывалось изначально или проект перерастет в бесконечный долгострой?
11 Недостаточный опыт управления проектами разработки
У собственника или внутреннего специалиста
Не всегда медицинский центр имеет возможности самостоятельно внедрять программы, решая вопрос привлечением для этой задачи сторонних специалистов, например, консультантов по внедрению информационных систем и автоматизации.
Находясь на стадии выбора решения для автоматизации клиники и поставщика или разработчика. Встречаясь с консультантом, который будет руководить вашим проектом выясните важные для себя детали: Сколько проектов он сопровождал или реализовал? Что это за клиники? Насколько успешным был результат?
Хороший консультант по внедрению информационных систем и автоматизации – этот человек, которого хочется взять к себе на работу.
12 Ошибки в постановке цели разработки МИС
Этот пункт логично напрашивается в вершину списка, хотя после всех предыдущих, значимость его только возрастает.
Ключевой вопрос выбора или разработки программного обеспечения для любой частной медицинской организации кроется именно в целях её внедрения. Какие задачи необходимо решить при использовании программы в клинике. Какие модули и функции должны быть в ней заложены. Что руководитель или собственник ожидает получить от информационной системы. Эти и многие другие вопросы часто могут остаться не проработанными, а как итог: напрасный расход значительного объема средств и потеря самого ценного ресурса – времени.
Подытоживая публикацию позволю сделать короткий вывод. Разрабатывать «самописную МИС» это:
Крайне дорого
Очень долго
Неоправданно рискованно
Что же делать, когда существующие программы не позволяют оптимизировать и автоматизировать бизнес-процессы клиники, а разрабатывать свою нецелесообразно?
Есть два варианта решения проблемы:
- Взять за основу коммерческий «коробочный» вариант с открытым исходным кодом и не снимая с поддержки поставщика достроить «под себя» за счет расширений и внешних модулей;
- Обратиться к нам для внедрения медицинской информационной системы CLINIC-ERP.
CLINIC ERP – программа для медицинского центра или сети клиник, построенная с использованием модульной архитектуры и открытым исходным кодом. Учитывает индивидуальные особенности бизнес-процессов клиники. Обладает самой глубокой аналитикой среди прочих программ на рынке.
В программном комплексе учтён функционал полноценной медицинской ERP-системы:
ЭМК | Стационар |
Индивидуальные шаблоны протоколов | Технологические карты |
Лабораторный блок | Мобильная версия для врачей на выезде |
Интеграция с оборудованием | Интеграции с личным кабинетом на сайте |
Касса (онлайн, сайт, банк) | Медико экономические стандарты |
Склад | CRM и интеграция с АТС |
Аналитика по медицинским данным | Сквозная аналитика |
Регистратура | Работа со страховыми компаниями |
Учет по группе компаний любой сложности | Управленческий учет |
Блок контроля | Управленческий баланс, P&L |
Продажи (прямые, реферальные) | Финансы и бюджетирование |
CLINIC ERP — это многолетний опыт разработки и внедрения медицинских информационных систем для частных клиник, который избавит вас от проблем «самописа» или недостатков существующего на рынке ПО.
Узнать подробности и задать вопрос по программе CLINIC ERP