12 причин не использовать самописную программу в клинике

В этой статье подробно и аргументированно рассмотрим минусы, которыми наполнена каждая самописная программа для медицинского центра и 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-системы:

CLINIC ERP — это многолетний опыт разработки и внедрения медицинских информационных систем для частных клиник, который избавит вас от проблем «самописа» или недостатков существующего на рынке ПО.

Узнать подробности и задать вопрос по программе CLINIC ERP